梦开始的地方（二十六）

ERP系统成果的体现，就是数据，而呈现数据的载体，就是报表。这里所指的报表是广义的，非系统定义的，既包括report的形式，也包括form的形式，就是说哪怕你点击了一个查询的按钮以后，出现了一个新的页面，上面反映了你所要看到的相关数据内容，这也应该列为报表。

哪怕是再智能的东西，其实也需要我们去制定其逻辑，不是说你在系统里面看到了1011这个会计科目，往上面填写一个数字100万，就说他是现金资产100万，前提是我们顾问做好了系统设置。首先是1011这个科目被我们预先设定好了属于资产类（更深层次的属性定义是设置好资产类科目发生数据变化时的借贷关系，这个是原先系统就按照会计规则拟定好了的），同时在设计会计报表里面要求它能口统计到这个数，你才能在最终的财务报表看到——哦，原来我们企业有100万的货币资金。

Oracle的强大在于数据库，我是外行，听大家这么说，我也就这么说了。事实上，我们往系统里面录入企业的数据，如果不加以筛选和整理，那么这堆数据就是垃圾，只有通过一定的组合筛选条件过滤出我们所要的数据才具有实用的价值，所以报表的关键之一就是要知道怎么把数据按照我们的需要抓出来。

涉及到很多IT的东西，比如数据库、比如表、比如字段……我们不是搞技术，不用去深究，实施顾问（功能顾问）和技术顾问的分工，在这里就有了一个很好的体现。

举一个极端而简单的例子，比如客户需要看一份报表，比如大豆的总价值，那么我们首先要确定计算的逻辑，即：

大豆的总价值=大豆的单价*数量

这时候问题来了，之前提到的Oracle EBS存在模块的概念，即大豆的单价数据出现在AP模块（应付帐款模块），大豆的数量出现在PO模块（采购模块），在这个时候，功能顾问就需要写一份用户需求文档或者功能需求文档，里面要讲清楚，要做一份报表，分别是几行几列，抬头怎么写，每一行每一列要显示什么数据，结尾要不要显示生成报表的时间等等，同时最重要的，是要写清楚：

大豆的总价值=AP模块的大豆的单价*PO模块的大豆数量（实际上没这么简单，从简了）

功能顾问把报告完成以后，转交给技术顾问，技术人员就按照上面的计算和取数逻辑进行报表设计。

如何实现跨模块之间的数据关联，其实是有桥梁的，专业的说法就是把数据中储存数据不同的两个表关联起来——前提是都有共同的字段——在上述的案例里面，共同字段就是采购订单的编号。财务人员在AP模块录入的采购发票需要输入一次订单编号，业务人员在他们另外的办公室录入PO数据的时候也要输入一次订单编号，两次订单编号的一致性就把AP和PO两个模块的数据关联了起来。至于怎么用SQL语言去编程来实现，那是技术人员的事情，这里没有必要阐述了。

总而言之，报表做出来了，但是不是马上可以投入使用的，需要测试。首先给你一套克隆的ERP系统，把这个报表放进这假系统里，让你随便蹂躏它，不断地录入乱七八糟的数据去进行测试，看看报表运行的时候会不会出错，这种测试有时需要你走极端，比如单价输入负数，或者数量输入成0，看看会有什么意想不到的结果。真的出了问题，就需要进行进一步的修正，看看是当初设计计算逻辑的时候有遗漏，还是技术人员的程序写的有漏洞，总之测试出来的问题越多越好，不经过测试的报表绝对不是好报表。

经过测试以后，得到客户方的认可，报表就可以放入正式的系统投入使用了，这点要说明的是，后期客户要求的新增报表，属于新的业务需求，是要另外算钱的，所以简单的抓几个数做十几张报表对顾问来说可能不是什么难事，但是却真的很创造效益，做个二三十张报表卖个十几二十万的案例貌似也有听过。

说到这，在第二十五集里面说到的报表数据不对的问题，根源找到了一半——报表在运行之初就已经有问题了：

1、设计逻辑有误：有没用弄清楚具体业务状况不认真跟客户调研就开始瞎设计的，也有自己头脑发热设计错的；

2、代码有误：有一味按照文档错错误的逻辑进行编程不加思索的；有自己业务不精、马虎大意设计疏忽的；

3、没有经过有效地测试——直接导致上述2点问题无法及时的发现。

可以说，如果第3点没有做到，那么最后一道关就没有把严，问题就这样流出了。

当然，CT项目的报表问题也有其他的客观因素，客户方在之前从来没有能力掌握即时数据的情况下，急于把不成熟的产品投入使用，盲目签字确认，造成了大量遗留问题。从我们实施方来说，人员变动频繁，很多人接到的都是前任的半成品，逻辑思路无法对接，特别是技术方面，程序员要读清楚前任的复杂的计算机语言，确实很费神，难免有疏忽。

但总而言之，把没有测试的半成品直接投入使用，是问题产生的第一根源。