虽然当我们说“需要到某某客户那边收集单据”时也包括收集报表，但要知道报表跟单据是有本质区别的。单据是在业务处理过程中用户填写的纸质文件，往往是一个信息采集、传递的过程，而报表则是根据一定的规则对批量数据进行检索、统计、汇总，是一个信息加工、分析的过程。随着计算机的普及，虽然在业务处理过程中纸质单据还大量存在，但在纸张上直接制作报表的情况越来越少见了，即使没有使用信息管理系统，也会使用一些常用的办公工具制作，如Word、Excel、Access等。
轻视报表分析是初学者比较容易犯的错误，轻视的理由是，只要我们的信息全了，没有什么报表做不出来。乍一看，这种想法有一定的道理，一个熟练的程序员，用一个趁手的报表工具，一天可能做出好几个报表（当然不是太复杂的），为什么要那么重视呢？因为有了这种想法，就容易把系统开发的过程人为分成两部分，一是功能开发部分，一是报表开发部分，并且认为报表开发是个相当不重要的工作。一个需求分析者，是不能有这种想法的。
问题的关键是如何才能保证信息是全的呢？必须承认，要做到这一点是非常难的。笔者曾经见过大量的案例，在需求分析时对客户的报表不重视，浮光掠影般地浏览一下就算过去了，等到功能开发完成后才进行深刻的报表分析，却发现报表中需要的许多信息无法获得，于是不得不对已经开发的功能进行大面积的变更，不但增加了开发成本，还带来了大量的质量隐患。只有先分析报表，仔细分析报表，才能保证信息足够，当然，这是必要条件，不是充分条件。
一个组织为什么要开发管理软件？无非就是为了管理方便。信息系统对领导来说，最有作用的地方就是这些报表了。领导发起这个项目，领导决定验收是否通过，领导决定付款，重视报表自然就是重视领导。领导们需要通过以前无法获得的，或者可以获得却需要投入大量人力物力的报表，进行决策分析。
如果分析好现在使用的这些报表，那么就可以深入管理者的管理神经，弄清楚当前公司管理者感兴趣的信息，最终给各级管理者带来真正的价值。报表是一个信息系统的集大成者，提前做好报表分析，可以加深理解管理脉络，理解信息系统的最终需求，理解这个系统的奋斗目标——报表当然不是仅有的目标，但绝对是最重要的目标之一。
如何分析报表呢？可以从这几个方面入手：生成报表的触发条件，报表中每个字段的信息来源，生成报表需要的各种运算公式及统计方式。
从业务层面看，报表生成的触发条件一般有这样几种方式：一是领导有临时要求时，相关责任人根据收集的信息制作，例如领导临时要求统计一下今年的职工离职情况；二是到了某个周期性的时间点时，例如随处可见的日报、周报、月报、季报、年报等；三是发生了某件事时，例如订单完成后，需要给客户出具一个与这个订单相关的分析报表。
对于信息系统而言，报表生成的触发条件一般有这样几种方式：一是根据用户录入的查询条件（例如日期范围、部门等）生成报表。这种方式是最常用的一种方式，绝大部分报表都是这么制作的。不过需要注意的是，在实际工作中，这个条件有可能隐含在业务过程中，在做报表分析时，一不小心就会忽略。
案例：隐含的报表生成条件
小王在分析收集到的报表时发现，有几种关于材料用途的统计表很类似，一车间有个《一车间材料用途统计表》，二车间有个《二车间材料用途统计表》，辅助车间有个《辅助车间材料用途统计表》，根据对报表信息与统计逻辑的分析，小王认为这其实是同一种报表，它们的信息来源、计算方式都相同，什么一车间、二车间、辅助车间，其实只是这个报表的生成条件之一：部门。
二是到了某时间点时，系统自动生成报表储存在数据库中，这种情况往往是因为需要统计、记录某些业务某时点的实时状态，因为数据在不断变化，过了这个时间点就很难得到。
三是在空闲时间段运算生成报表储存在数据库中，这往往是因为运算量太大，可以利用系统空闲时间计算生成报表，提高运算效率。
当然，还有一些报表是混合型的，如根据用户录入的查询条件生成报表，但其中有部分（可多可少）数据是系统在某时间段自动计算生成的。
分析当前使用的报表时，需要考虑如何将当前的触发条件转换成信息系统的触发条件。对于信息系统而言，生成报表的触发方式与业务层面的触发方式是完全不一样的。例如，“领导有临时要求”这种触发方式，在业务层面相当普遍，但在信息系统中，根据报表需求，有可能是根据查询条件生成报表，有可能是时间点触发，有可能是空闲时间段生成；对于那种日报、周报、月报之类的报表，首先想到需要在某时间点定时计算，但如果统计的信息不需要实时性，运算量也不大，宁可采用根据查询条件生成的方式，毕竟这种方式做起来最容易，开发成本最低。
报表生成的触发方式，在需求分析时需要仔细考虑，不同的触发方式有不同的优缺点，需要根据需求合理处理。根据查询条件生成报表的方式最普遍，实现最容易，没有特殊情况一般优先考虑这种方式，但缺点是实时生成，对于需要消耗大量资源的大型报表，或需要反应时点状态的报表，就难以处理。
正如分析单据一样，也需要分析报表中各元素的数据来源，使用的方法也类似于单据分析法中的处理方式，但也有很大的不同点：报表一般不需要过多考虑报表本身的流转过程，分析的重点应该在于出现在报表中的数据从什么地方获得。报表中出现的数据，看上去是死的，但其实每个数据元素都是有一系列关于它的产生过程的——作为需求分析者，应该有这种职业敏感性。
报表中的数据来源是有背后的业务场景的，不能仅满足这些数据在哪里，重点是要根据这些数据的要求考虑如何在系统中安排功能，使之切合业务要求，在相应的业务场景下录入数据。说得简单点儿，除了一些简单的数据，如打印时间等，大部分数据都不是无缘无故产生的，需要由工作人员在工作过程中录入。这个数据由谁、在什么时候、在处理什么业务时、通过什么方式录入系统——这几个问题是需求分析者在分析报表的数据来源时需要随时敲打自己的。
在需求获取阶段，研究报表的主要目的不是怎么制作报表，而是根据报表的需求考虑如何采集数据。一个企业对信息的综合性需求主要体现在报表中，对报表中的每个字段都需要进行深入的分析，直到确信可以为它提供数据来源，如果能把所有报表的数据来源问题都处理好，这个信息系统就成功一大半了。
案例：不认真分析报表字段会带来大麻烦
甲车间里需要一个报表《员工产量统计表》，见表2-3。
刚开始调研的时候，需求人员小王粗略看了下这个报表，然后做出如下判断。
（1）员工、加工物料、产量、质量等级：可以从生产汇报数据中获得。
（2）单价：可以从成本数据中获得，因为这个系统的成本模块设计得相当完善，每个工序的加工成本都有数据，这个自然不是问题。
（3）金额：产量乘以单价可以算出。
等到后来实际开发这个报表时才发现，这个“单价”非常难以获得。这里的物料单价是跟质量等级相关的，车间需要根据不同的质量等级给员工计算计件工资，由于这个问题在开始设计时没有仔细考虑，导致需要对前面开发完成的成本核算功能进行大幅调整。以前总以为不管产品的质量等级如何，加工过程是一模一样的，成本当然也是一样的，现在才知道，质量等级低的，支付的员工计件工资也低，预示着不同质量等级加工成本其实是不一样的。这是个令人非常痛苦的调整。
通过对报表数据来源的分析，刨根问底地分析，可以顺藤摸瓜分析出大量的功能需求。任何一个看上去非常简单的报表，都有可能隐藏着一大堆的需求，分析报表的数据来源就是挖掘需求之井，只要肯花工夫，总是可以挖出甘泉的。有时候看报表中一个字段非常不起眼，可一旦仔细分析下去，可能会发现，为了这个字段，需要从若干个地方采集数据，而在这些地方采集数据，又不能安排专门人员录入，它需要切合到业务运行过程中。为了在业务运行过程中获得这个数据，需要有这个那个的功能支持，需要进行这样那样的工作流程重组。
案例：从报表挖掘功能需求
某单位刚刚安装了指纹考勤机，考勤机可以提供原始打卡数据：某人在某时间某地点打卡了。管理方需要一个报表《员工异常考勤统计表》，统计每个班次有多少员工迟到、早退、旷工。假设我们的需求获取就从这张报表开始，那么如何思考呢？
怎么定义员工的迟到、早退？是不是需要一个定义的规则呢？
不同班次的员工，迟到、早退的规则是不是一样？是不是需要一个班次管理功能？
怎么知道员工属于哪个班次？怎么安排班次？由谁来安排班次？是不是需要一个排班的功能？
如何根据员工的打卡记录分析他是不是迟到、早退？他重复打卡了怎么办？是不是需要一个员工考勤分析功能？
外勤员工怎么办？卡坏了怎么办？忘打卡了怎么办？是不是需要一个异常考勤处理功能？
仅分析报表的数据来源是远远不够的，还有大量的运算逻辑需要分析清楚。有些报表没有什么运算逻辑，只是对一些数据的汇总显示罢了，有些报表逻辑却是相当复杂的，如果这个报表的专业性非常强，而你又对这个领域一窍不通，那么光弄明白这些逻辑就很麻烦。要理解报表逻辑，可以考虑以下这些方法：
1.使用常识判断
有的报表比较简单，通过一些基本常识就可以判断它的运算逻辑了。例如，报表中有字段“数量”、“单价”、“金额”，根据常识自然可以想到“金额=数量×单价”这个公式。随着经验越来越丰富，所掌握的知识越来越多，理解客户报表也会变得越来越容易。不过，无论自认为自己的知识多么丰富，对这个领域多么精通，都需要跟客户人员确认自己的判断是否正确，有很多貌似是常识的东西，实际上远不是想象的那样。
2.研习客户文档
有些特别复杂的报表，客户可能也会有特定的文档阐述，如技术文档、管理文档、操作手册等，此类文档需要认真收集，仔细学习。
案例：研习关于如何制作报表的管理要求
某生产企业要求每个车间每个季度给公司管理层报送一份生产季报，公司有一份管理文档详细阐述如何填写这个报表，在细则中详细写明了每个字段的数据来源是什么，计算公式是什么。小王通过研习这个文档，非常高效地理解了这个报表的运算逻辑。
当然，研习客户的文档也需要小心，大部分企业这种管理要求都没有得到严格执行，有名无实的例子比比皆是，这种管理文档中载明的算法，可以将它当成入门工具，具体是不是真正如此执行的，还需要更多的调研。
3.听客户讲解
报表逻辑复杂了，就需要客户人员给你讲解，具体可以参见访谈法。虽然客户人员有义务讲解清楚所有的运算逻辑，但要注意，一者客户人员的讲解水平未必那么高，二者你的理解能力也未必那么强，所以还是建议在要求客户人员讲解前最好先使用自己的常识做一下分析，认真研习下可以找到的相关管理文档，如果需要相关的专业知识，还需要先准备点儿业务知识。这个过程其实就跟上学时听老师讲课类似，如果能够提前预习，就可以提高学习效率。先预习，抓住重点，再根据自己难以理解的地方准备好问题，然后再去听讲解，这样可以大大提高效率。在这里要特别提醒，听讲解这个过程相当重要，客户人员可以理解你不是这个领域的行家，不了解这些逻辑当然是应该的，但是，如果他讲解后或者多次讲解后，你还是迟迟理解不了或理解错误，他就会对你的能力产生怀疑，导致你在他心目中的地位逐渐下降，这会导致后面的工作越来越难做，因为你丧失了某种权威性。
4.研习电子表格公式
一般情况下，客户会有两种介质的报表，一种是纸质报表，另一种是用电子表格做出来的电子报表。在收集报表时，如果拿到的纸质报表是从电子表格中打印出来的，那么要让客户提供原始电子表格，原因很简单，很有可能在其中嵌入了诸多公式，直接看公式了解报表的生成方式比让某个人给你解释要方便得多，也准确得多。要分析好Excel之类的电子表格中的运算逻辑，首先得熟练掌握这个工具，因此，精通Excel之类的办公工具是一个需求分析者的必备素质。有些电子表格中的公式是相当复杂的，有些Excel高手设计出来的工作簿会让你看得云里雾罩，一个公式可能有几千字符，这里引用那里嵌套的，要分析清楚并不容易，这时候还是需要相关人员对着这个工作簿详细讲解设计思路与运算过程。
不管怎么样，有了电子表格，确实可以大大降低需求调研的难度。
报表的开发工作一般都是在功能开发完成后进行的，所以在功能开发之前分析报表运算逻辑的主要目的，还是在于通过分析做好功能设计的准备。分析报表的运算逻辑，一般可能在以下这几个方面对功能设计产生重要影响。
1.为了提高报表的效率，可能采用引入中转数据的方式
有些报表的运算逻辑非常复杂，会有大量的计算过程，牵涉到数据库里各种各样的数据，这些数据来自于数据库的各个地方，要把这些数据组织起来在这个报表中展现，需要消耗大量的资源。一般情况下，可以通过合理设计表结构、建立索引之类的方法来处理，但不能不说这类方式并不总是管用，使用中转数据来处理有时候也是一个不错的方案。
所谓引入中转数据，就是通过计算或者筛选，将一部分数据进行预加工后生成新数据存放到另外一个地方，或者打上一些数据标志，从而降低需要使用这些数据的功能的运算难度，或者减少资源开销。例如，一个银行账户月报，其中有一个字段是上月账户余额，为了避免每次生成报表时都计算一遍这个账户余额，可以在每个月初进行一次计算，将每个账号的上月余额计算好保存起来，当报表中需要某个月的结存金额时，直接从这个保存下来的数据中获得，而不需要根据用户的账号交易记录从头计算。这种保存下来的新数据就是中转数据，中转数据的主要特点是，不是原始数据，如果这个数据丢了，一般情况下经过重新计算还是可以生成的。
如何生成中转数据，这是需求分析者在进行功能设计时应该仔细考虑的。有时候，这个中转数据纯粹就是为了报表的性能，这可以考虑使用调度任务来完成，由于不需要用户干预，设计过程相对简单，例如上面提到的银行账户余额，就可以考虑设计一个计算程序在系统空闲时计算并保存月账户余额；有时候，中转数据的生成需要人工干预，这时候就需要设计使用场景了，由谁，在什么时候，通过什么功能进行。
案例：引入中转数据提高报表效率
计划部每个月需要一个报表《机器闲置分析表》，用来分析上个月车间机器的运转情况，检查计划人员计划安排中可能出现的问题。报表的格式见表2-4。
其中：
总能力：指每台机器理论上可以运转的时间。用工作日历的小时数减去保养、修理时间可以获得。
实际运转时间：来自生产单的汇报数据。每个生产单完成后，都有人汇报在哪台机器上生产的，什么时候开始的，什么时候结束的。
闲置率：（总能力-实际运转时间）÷总能力×100%
需求人员仔细分析这个报表背后的运算逻辑后，发现这个实际运转时间的计算是个相当麻烦的事情。情况大概是这样的：一个生产单在一台或多台机器上生产，一般情况下，一台机器同时只针对一个生产单生产，但有时候也会有一台机器同时加工多个生产单的情况，这时候就要注意不能重复计算机器的运转时间；另外，这个报表是按月统计的，可每到月底会有大量的跨月生产单，这些跨月生产单如何占用前一个月的机器能力是个问题，需要进行计算分解；还要考虑一些异常情况，如这段时间明明工程部登记了这台机器在修理中，可偏偏在工作汇报的记录中显示它还在运转。
由于数据量庞大，运算逻辑复杂，使用直接生成报表的方式明显不可行，需求人员决定引入中转数据，策划在每个月月初的时候，计算出每台机器上个月的实际运转时间，存储在某个表中。当需要生成这个报表时，直接从该表中获得数据，避免每次打开报表都进行一番“搜山检海”般的运算。但由于生产汇报数据是可以修改的，如果运算完成后，生产汇报数据被修改了，就会造成结果失真，于是决定引入生产汇报数据冻结机制。统计人员每月打印工作统计表，核对无误后执行生产汇报数据锁定功能，锁定后该月的生产汇报数据就不能修改了。然后，才可以计算机器实际运转时间。为了防止误操作导致的错误锁定，还需要提供有条件的解锁功能，解锁过程中需要同时清除机器实际运转时间的计算结果。
2.有些用电子表格制作的所谓报表，其实就是个功能模块
有些用Excel之类的电子表格制作的工作簿，客户可能称之为某报表，可仔细分析后，也许会发现，这个所谓的报表包括大量的数据录入、存储、计算、展现的过程，几乎具备了一个小型信息系统的所有特点，虽然它的最终目标只是生成某个报表，但这个过程是相当复杂的——这个工作簿就是一个软件系统。有的时候，甚至也会支持多人操作，有些人负责这部分数据的录入，有些人负责那部分数据的录入，有些人负责维护一些基础数据，最终通过公式什么的计算生成管理需要的报表。Excel还提供VBA编程、服务器之类的方案，这已经是专业软件开发的思路了。
笔者曾经遇到过一个比较厉害的成本会计，自己设计了Excel工作簿用以计算产品标准成本。Excel中存储了各种产品的标准结构树（BOM），各种标准工艺路径，各种机器的小时成本，各种原材料、半成品的标准价格，等等。每当技术部设计了一个新产品，他会从技术部获得产品BOM及工艺路线，复制到这个工作簿中，然后立即就生成了这个产品的详细标准成本报表，包括原材料成本、加工成本、所需各级半成品的标准成本等。这其实是个标准成本系统，做个软件系统也不是那么容易的。如果他告诉你，他需要一个标准成本报表，如果不能了解清楚这个报表背后的一切，那么后面的工作恐怕只能自求多福了。
如果客户提供了这种Excel工作簿，要明白一点，这对你的工作既是帮助也是挑战。帮助在于，这种工作簿往往比较全面地体现了某些岗位对信息的综合需求，只要分析清楚了这里面的功能、规则、数据流向，然后将之在系统中处理好，那么基本上就不会存在需求分析的严重漏洞，对于涉及多人操作的工作簿，仔细调研清楚他们的工作方式、场景后，再来设计系统功能，由于具有很强的参考性，可以少走许多弯路。挑战在于，这种工作簿作为一个小型系统，其实是个信息孤岛，做软件的都知道，解决信息孤岛的问题比从头开始在白纸上描绘要难，设计的系统要解决这个信息孤岛问题，就要考虑到以前的工作场景、数据的编码方式、数据的结构组织、数据的规范化、数据的关联关系等一系列问题，要解决好这些问题并不容易。另外，还有个Excel的灵活性的问题，使用习惯Excel的人，习惯了它灵活处理数据的方式，复制、排序、筛选、嵌入公式等，你的软件的录入功能很难与之相比，用习惯了Excel的用户，使用你的系统处理他原来在Excel中处理的问题，容易产生怀旧心理。
3.报表并不仅仅是生成显示，有时候是需要保存报表数据的
有的时候，报表并不仅仅是加载显示打印那么简单，可能需要将报表本身所生成的部分或所有信息保存下来，这时候报表充当了某种数据流节点的角色。这时候，可以把报表理解成某种生成数据的功能点，通过报表生成的数据保存到某些表中，或者方便以后的查询，或者方便重现报表。
案例：保存报表数据
某组织在全国有许多分支机构，总部要求每个月各分支机构报送一些经济分析报表到总部，总部把这些报表汇总后生成总报表，然后会把这些报表印刷成报表小册子分发给相关人员。需求人员分析后发现，这些报表的生成并不复杂，但是因为有些数据是活动的，如何保证系统报表跟印刷出来的小册子上的报表始终一致却是个大问题。
例如，报表中有一项叫“创新产品本月收入”，根据现在对数据与功能的设计，可以从系统中获得每个产品的月收入情况，但如何定义一个产品是“创新产品”并没有明确的规则，一般由市场部根据感觉确定哪些产品是创新产品，哪些产品不是创新产品，创新产品并不是一定的，某产品可能这段时间被确定为创新产品，一段时间后又被确定为非创新产品。3月份时，某产品因为被确定为创新产品，所以收入就计入了“创新产品本月收入”，可是到了4月份，该产品并非创新产品，收入没有计入“创新产品月收入”。由于产品是否创新产品是在生成报表时确定的，等到5月份，再打印3月份的报表时，很难做到跟那时候的小册子一致。另外，这个印刷的小册子还会提供给组织外的人阅读，有时候为了利于宣传，让数据好看，在印刷前还需要对某些数据做调整。
在这种情况下，要想保证重现小册子上的历史数据非常困难，需求人员经过权衡，对于确定创新产品的问题，决定增加功能点，由市场人员确定在某个时间段哪些产品是创新产品，而不是仅指明某产品是不是创新产品。对于报表数据的调整问题，决定引入报表数据的保存机制，生成报表后，用户将报表数据保存下来，对于保存下来的数据允许进行修改，修改后再印刷，这样可以保证任何时候都可以生成历史报表。
4.另类报表会产生意想不到的功能需求
有些报表，背后有着你不知道的规则，说它暗箱也好，说它潜规则也好，反正就是它背后隐藏的东西跟你看到的、了解到的、想到的不一样。这些报表，我们不妨称之为另类报表，另类报表会产生意想不到的功能需求。
案例：另类报表产生了意想不到的需求
客户提供了一个报表《销售统计表》，统计每个月的产品销售情况。小王认真分析了这个报表的生成方式，数据来源，走访了若干相关人员，觉得自己已经了解得非常清楚了。在准备终结这项工作之前，他抽查了自己收集的某些报表，他发现，根据他手头掌握的原始数据，以及客户提供的规则，怎么都计算不出这个报表中的结果。开始他想可能是做报表的人计算有错误吧，毕竟手工计算犯错在所难免，可继续分析后发现，好多结果都是错误的，然而，奇怪的是，其中的钩稽关系又是正确的，这可真是见了鬼了。于是去找相关人员追问，他支支吾吾后才说出真实的原因，原来这是企业制作的专门用来应付税务检查的，他们自己内部用的是另外一套报表。
小王知道他的软件回避不了这个问题，可是怎么处理呢？他陷入了深深的沉思。