2.6.5　报表对功能设计的重要影响

报表的开发工作一般都是在功能开发完成后进行的，所以在功能开发之前分析报表运算逻辑的主要目的，还是在于通过分析做好功能设计的准备。分析报表的运算逻辑，一般可能在以下这几个方面对功能设计产生重要影响。

1．为了提高报表的效率，可能采用引入中转数据的方式

有些报表的运算逻辑非常复杂，会有大量的计算过程，牵涉数据库里各种各样的数据，这些数据来自于数据库的各个地方，要把这些数据组织起来在这个报表中展现，需要消耗大量的资源。一般情况下，可以通过合理设计表结构、建立索引之类的方法来处理，但不能不说这类方式并不总是管用，使用中转数据来处理有时候也是一个不错的方案。

所谓引入中转数据，就是通过计算或者筛选，将一部分数据进行预加工后生成新数据存放到另外一个地方，或者打上一些数据标志，从而降低需要使用这些数据的功能的运算难度，或者减少资源开销。例如，一个银行账户月报，其中有一个字段是上月账户余额，为了避免每次生成报表时都计算一遍这个账户余额，可以在每个月初进行一次计算，将每个账号的上月余额计算好保存起来，当报表中需要某个月的结存金额时，直接从这个保存下来的数据中获得，而不需要根据用户的账号交易记录从头计算。这种保存下来的新数据就是中转数据，中转数据不是原始数据，如果这个数据丢了，一般情况下经过重新计算还是可以生成的。

如何生成中转数据，这是需求分析者在进行功能设计时仔细考虑的。有时候，这个中转数据纯粹就是为了报表的性能，这可以考虑使用调度任务来完成，由于不需要用户干预，设计过程相对简单，例如上面提到的银行账户余额，就可以考虑设计一个计算程序在系统空闲时计算并保存月账户余额；有时候，中转数据的生成需要人工干预，这时候就需要设计使用场景了，由谁、在什么时候、通过什么功能进行。

案例：引入中转数据提高报表效率

计划部每个月需要一个报表——机器闲置分析表，用来分析上个月车间机器的运转情况，检查计划人员计划安排中可能出现的问题。报表的格式见表2-4。

总能力：指每台机器理论上可以运转的时间。用工作日历的小时数减去保养、修理时间可以获得。

实际运转时间：来自生产单的汇报数据。每个生产单完成后，都有人汇报在哪台机器上生产的，什么时候开始的，什么时候结束的。

闲置率：（总能力-实际运转时间）÷总能力×100%

需求人员仔细分析这个报表背后的运算逻辑后，发现这个实际运转时间的计算是个相当麻烦的事情。情况大概是这样的：一个生产单在一台或多台机器上生产，一般情况下，一台机器同时只针对一个生产单生产，但有时候也会有一台机器同时加工多个生产单的情况，这时候就要注意不能重复计算机器的运转时间；另外，这个报表是按月统计的，可每到月底会有大量的跨月生产单，这些跨月生产单如何占用前一个月的机器能力是个问题，需要进行计算分解；还要考虑一些异常情况，如这段时间明明工程部登记了这台机器在修理中，可偏偏在工作汇报的记录中显示它还在运转。

由于数据量庞大，运算逻辑复杂，使用直接生成报表的方式明显不可行，需求人员决定引入中转数据，策划在每个月月初的时候，计算出每台机器上个月的实际运转时间，存储在某个表中。当需要生成这个报表时，直接从该表中获得数据，避免每次打开报表都进行一番“搜山检海”般的运算。但由于生产汇报数据是可以修改的，如果运算完成后，生产汇报数据被修改了，就会造成结果失真，于是决定引入生产汇报数据冻结机制。统计人员每月打印工作统计表，核对无误后执行生产汇报数据锁定功能，锁定后该月的生产汇报数据就不能修改了。然后，才可以计算机器实际运转时间。为了防止误操作导致的错误锁定，还需要提供有条件的解锁功能，解锁过程中需要同时清除机器实际运转时间的计算结果。

2．有些用电子表格制作的所谓报表，其实就是个功能模块

有些用Excel之类的电子表格制作的工作簿，客户可能称之为某报表，可仔细分析后，也许会发现，这个所谓的报表包括大量的数据录入、存储、计算、展现的过程，几乎具备了一个小型信息系统的所有特点，虽然它的最终目标只是生成某个报表，但这个过程是相当复杂的——这个工作簿就是一个软件系统。有的时候，甚至也会支持多人操作，有些人负责这部分数据的录入，有些人负责那部分数据的录入，有些人负责维护一些基础数据，最终通过公式的计算生成管理需要的报表。Excel还提供VBA编程、服务器之类的方案，这已经是专业软件开发的思路了。

笔者曾经遇到过一个比较厉害的成本会计，自己设计了Excel工作簿用以计算产品标准成本。Excel中存储了各种产品的标准结构树（BOM），各种标准工艺路径，各种机器的小时成本，各种原材料、半成品的标准价格，等等。每当技术部设计了一个新产品，他会从技术部获得产品BOM及工艺路线，复制到这个工作簿中，然后立即就生成了这个产品的详细标准成本报表，包括原材料成本、加工成本、所需各级半成品的标准成本等。这其实是个标准成本系统，做个软件系统也不是那么容易的。如果他告诉你，他需要一个标准成本报表，如果不能了解清楚这个报表背后的一切，那么后面的工作恐怕只能自求多福了。

如果客户提供了这种Excel工作簿，要明白一点，这对你的工作既是帮助也是挑战。帮助在于，这种工作簿往往比较全面地体现了某些岗位对信息的综合需求，只要分析清楚了这里面的功能、规则、数据流向，然后将之在系统中处理好，那么基本上就不会存在需求分析的严重漏洞，对于涉及多人操作的工作簿，仔细调研清楚他们的工作方式、场景后，再来设计系统功能，由于具有很强的参考性，可以少走许多弯路。挑战在于，这种工作簿作为一个小型系统，其实是个信息孤岛，做软件的都知道，解决信息孤岛的问题比从头开始在白纸上描绘要难，设计的系统要解决这个信息孤岛问题，就要考虑到以前的工作场景、数据的编码方式、数据的结构组织、数据的规范化、数据的关联关系等一系列问题，要解决好这些问题并不容易。另外，还有个Excel的灵活性的问题，使用习惯Excel的人，习惯了它灵活处理数据的方式，复制、排序、筛选、嵌入公式等，你的软件的录入功能很难与之相比，用习惯了Excel的用户，使用你的系统处理他原来在Excel中处理的问题，容易产生怀旧心理。

3．报表并不仅仅是生成显示，有时候是需要保存报表数据的

有的时候，报表并不仅仅是加载、显示、打印那么简单，可能需要将报表本身所生成的部分或所有信息保存下来，这时候报表充当了某种数据流节点的角色。这时候，可以把报表理解成某种生成数据的功能点，将通过报表生成的数据保存到某些表中，或者方便以后的查询，或者方便重现报表。

案例：保存报表数据

某组织在全国有许多分支机构，总部要求每个月各分支机构报送一些经济分析报表到总部，总部把这些报表汇总后生成总报表，然后会把这些报表印刷成报表小册子分发给相关人员。需求人员分析后发现，这些报表的生成并不复杂，但是因为有些数据是活动的，如何保证系统报表跟印刷出来的小册子上的报表始终一致却是个大问题。

例如，报表中有一项叫“创新产品本月收入”，根据现在对数据与功能的设计，可以从系统中获得每个产品的月收入情况，但如何定义一个产品是“创新产品”并没有明确的规则，一般由市场部根据感觉确定哪些产品是创新产品，哪些产品不是创新产品，创新产品并不是一定的，某产品可能这段时间被确定为创新产品，一段时间后又被确定为非创新产品。3月份时，某产品因为被确定为创新产品，所以收入就计入了“创新产品本月收入”，可是到了4月份，该产品并非创新产品，收入没有计入“创新产品月收入”。由于产品是否创新产品是在生成报表时确定的，等到5月份，再打印3月份的报表时，很难做到跟那时候的小册子一致。另外，这个印刷的小册子还会提供给组织外的人阅读，有时候为了利于宣传，让数据好看，在印刷前还需要对某些数据做调整。

在这种情况下，要想保证重现小册子上的历史数据非常困难，需求人员经过权衡，对于确定创新产品的问题，决定增加功能点，由市场人员确定在某个时间段哪些产品是创新产品，而不是仅指明某产品是不是创新产品。对于报表数据的调整问题，决定引入报表数据的保存机制，生成报表后，用户将报表数据保存下来，对于保存下来的数据允许进行修改，修改后再印刷，这样可以保证任何时候都可以生成历史报表。

4．另类报表会产生意想不到的功能需求

有些报表，背后有着你不知道的规则，说它暗箱也好，说它潜规则也好，反正就是它背后隐藏的东西跟你看到的、了解到的、想到的不一样。这些报表，我们不妨称之为另类报表，另类报表会产生意想不到的功能需求。

案例：另类报表产生了意想不到的需求

客户提供了一个销售统计表，统计每个月的产品销售情况。小王认真分析了这个报表的生成方式，数据来源，走访了若干相关人员，觉得自己已经了解得非常清楚了。在准备终结这项工作之前，他抽查了自己收集的某些报表，他发现，根据他手头掌握的原始数据，以及客户提供的规则，怎么都计算不出这个报表中的结果。开始他想可能是做报表的人计算有错误吧，毕竟手工计算，犯错在所难免，可继续分析后发现，好多结果都是错误的，然而，奇怪的是，其中的钩稽关系又是正确的，这可真是见了鬼了。于是去找相关人员追问，他支支吾吾后才说出真实的原因，原来这是企业制作的专门用来应付税务检查的，他们自己内部用的是另外一套报表。

小王知道他的软件回避不了这个问题，可是怎么处理呢？他陷入了深深的沉思。