在软件项目开发中，最头疼的就是报表系统。整个项目的工期经常由于报表问题而延误。问题的主要原因是报表技术已经涉及OLAP技术，而一般软件开发和数据库技术只适合解决OLTP问题。

解决的方法是引入BI技术，但不是把BI当做一个独立项目来立项、开发，而是把BI技术嵌入到项目中来应对报表需求。

报表需求难以满足的主要原因是客户常常对报表提不出一个完整的需求。项目做到最后，客户认为你的报表开发不到位，不能满足需求，这个需求准确地说是潜在需求。

开发人员认为客户需求变化太频繁。如果根据客户要求不断调整或增加功能，实施成本无法控制。

有经验的公司一般采取两种方式来应对，一是根据报表数量来收费，二是提供报表设计工具，由客户自己开发报表。

虽然这样有利于限制客户对需求的变动和无限制的需求延伸，但毕竟最终还是没有满足客户的需求。虽然项目成本和进度有保证了，但客户不能满意。对项目来说，总是一个瑕疵，不利于维持与客户的长期合作关系。

OLTP应用和OLAP应用的本质区别是，OLTP应用的用户是一般员工，需求与现有业务的人工处理流程是一样的，基本固定。如果一个企业业务流程没有规范的话，也不会去开发软件。这样的话，需求就是对自己日常工作流程的描述，因此范围是可控的。

统计报表属于OLAP应用，涉及到决策支持层面，用户是管理人员。管理人员的职责是处理突发或偶发事情，有些事情以前可能从未出现过。因此他的需求不确定，或者说，无法全面描述出全部需求。

那么，没有需求如何开发软件呢？这里就出来一个看似奇葩的理论：统计报表开发应该先有程序，后有需求。

这个理论是有书为证的，这就是比尔·恩门的《数据仓库》。比尔·恩门是数据仓库之父，作为决策支持系统开发手段的BI技术，就是基于他的理论发展起来的。

没有需求依托，统计报表开发也不是无章可循。

统计报表开发是在信息系统开发的后期，需求已经融合在其它业务功能之中，数据中已经记录和反映了客户的需求。任何一张报表都会与数据相关，因此可以用金博尔的维度建模方法去组织数据，就可以开发出面向用户的程序，再听取用户意见进行完善。

任何的数据本质都是多维的，所以每张报表都是模型中的数据被多个维度的条件过滤后，在一个维度上的展开（比如时间的月份）。因此，通过二维形式展示多维数据，永远只能是个子集。

如果统计报表或BI项目的开发，是从需求开始的，那么困难和失败是可以想象的。

相关文章