接前文，牛牛爸在Part 1解释了BI元素框架（BI Component Framework）里的基础部分（Foundation），现在由下及上继续聊。首先还是先温习一下前面的架构图：
数据搬来了，工具选好了，实施就能成功？
前面我解释了大多数以技术为主导的IT部门做不好BI项目。如果说那些关键点是一个公司始终都要注意的，那么在实现部分（Enablement），我要提醒几个特别的风险点。
首先是业务部分或者管理层的过度期待（over expectation）。随着BI项目的推进，我相信很多以前没有听说过商业智能的人会多多少少地去网络了解这个新事物。IT有一个特点，那就是“坏事不出门，好事传千里”。我想您要是去百度搜索商业智能，看到的更多是“优秀产品”、“开创者”，等等神乎其神的宣传和各种如科幻片一样的图表分析。因此很多没有项目基础和实际经验的人容易对BI产生幻觉，认为只要公司拥有这样的系统，就好似有了一个超级大脑来保驾护航。或者认为BI同excel一般灵活，随便改一下公式就可以看到结果。
其次是IT或者BI实施团队的过度承诺（over promising）。相对于传统的商业系统，BI算是一个新生事物，因此很多公司的实施团队经验有限，容易乐观地估计项目的结果。例如当项目组在基础阶段发现底层数据的质量高于预期时，便容易乐观地认为项目时间会大大缩短，或者过早地保证实现某种高级分析。BI项目的铺垫一般都很长，业务用户只有等技术人员把分析结果投影到幕布上时才能真正看到问题的所在。在这个阶段因为数据或者模型缺陷而把BI应用推倒重来的案例比比皆是。因此过早或过度地承诺可能会在后期给实施团队带来巨大的压力。
再次是用户需求变更（user requirement changes）。因为BI属于新事物，很多业务用户在初期的需求收集阶段无法给出准确的意见，只有等看到演示（demo）时才大致明白BI是什么东西，并且会随着应用的完善而不断地提出修改意见。此外BI用户通常包含部门经理和一般业务人员。不同级别的人对公司业务的侧重点会有不同，因此BI团队经常要面对完全对立的修改意见。如何控制好用户意见和修改原则是BI团队要早早考虑的问题。
最后是项目范围蔓延（scope creep）。基于国内项目的特点和从我个人的经验，没有一个交付的BI应用是完全按照设计文档来实施的。不是因为我们没有能力做好设计，而是当用户看到A功能后会立刻要求B功能，甚至提出C功能的预想。对于一般业务人员提出的新需求我们可以找些不明觉厉的理由来拒绝，但是面对管理层，我们可能会失去话语权（BI项目碰到高级经理的机会要远大于其他项目）。因此BI团队要按照项目实施方法论和自身的特点尽早做出调整。
BI框架之实现部分（Enablement）
不知道大家是否注意到实现部分的三层顺序。为什么分析会放在报表之后哪？其原因就是防止过度期待和过度承诺而最终导致大家不欢而散。
通常BI项目会在后期碰到各种各样无法预先准备的问题，例如数据无法打通，模型设计缺陷，维度交叉造成的错误，或者无法达成某种分析结果等。此外BI应用是基于业务流程和数据的，IT测试人员仅能够检查计算结果是否准确，但无法判断分析图表是否符合业务要求，数据结果是否有商业意义等。这些功能上的测试必须在后期业务人员的配合下才能完成，也就是UAT。因此实施团队如果过早地承诺分析功能，那么将来等用户提出质疑的时候，我们很难判断这是数据的问题，逻辑理解的问题，模型的问题，还是前端代码的问题。如果在时间压力下开发人员开始补丁叠补丁，那么离恶梦就不远了。
因此牛牛爸强烈建议BI项目先从简单的报表（reporting）开始！一张报表看似简单，实际上我们可以发现底层数据的问题，数据仓库和模型问题，系统性能如何，工程师是否合格，业务和算法的理解是否到位等等。公司报表一般都有固定的格式和业务流程，因此报表开发不会招致大量的用户需求变更和范围变更。快速实现报表自动化还可以拉近BI项目组和业务人员的关系，并增强管理层的满意度（buy in）。
除了报表，范围小、用户少、需求明确的任务也可以作为我们初期的着力点。例如单一产品MTD， QTD， YTD， YoY的销售数据汇总，一些简单的目标达成率等。简单任务完成之后，我们可以逐步加入例如竞品数据，然后就可以和业务部门坐下来制定一些相对复杂的分析功能了。
报表是测试数据质量和理解业务的好机会。当报表完成之后，BI团队和业务人员可以继续挑战复杂灵活分析（analysis）。复杂分析的范围千变万化，有的是把PPT图表自动化，有的是根据业务经验提出更优化的分析（可能需要外部业务专家的介入）。BI团队可以和业务人员坐在一起共同研究和讨论分析方法，并当场向用户演示开发结果。BI团队也可以依赖自有经验和业务专家的能力，先内部设计，开发，然后再向业务人员演示，并收集意见。从我目前的项目经验来看，效率最高的方法是和专家初步制定设计方案，简单开发之后再和业务用户确认。
大数据（big data）是时下流行的概念。很多公司的高层可能会要求实施团队直接完成大数据项目。但是我认为直接从零到大数据的跳跃基本是自讨苦吃，除非公司有富有意义的海量数据，拓展的兴趣，和富有经验的实施人员和用户。因此我是在报表和复杂分析完成之后才建议公司去尝试探讨大数据项目。但请记住，大部分的公司在现阶段是不需要上马大数据项目的！请做好充分的调查和选型之后再考虑是否做这样的投资。
如果报表和分析都一帆风顺，那么恭喜您，可以开始挑战目前BI行业里的最高难度：预测分析（prediction）。预测什么哪？如果您负责销售，那么BI可以预测未来的市场空间和合理的销售目标。如果您从事投资，那么BI可以预测公司未来的现金流甚至估值。目前受限于预测的复杂程度，绝大多数公司还是通过线下的方式，使用excel模拟多种参数，然后反复论证，最终敲定某业务的预测值或者目标值。因此牛牛爸到目前为止还没有这类项目的成功案例。我的经历更多是相对简单的情景（scenario）分析。
所谓情景分析，就是在现有数据的基础上，通过手动或自动调整某些参数而达到检查其他指标的目的。例如我们可以通过调整工厂里某个环节的生产率来计算产品在未来市场可能的占有情况。无论是公司的一般业务人员还是高层，情景分析的用户参与度最高，得到的反馈也最丰富。作为实施者，能看到BI工具在实打实地帮助业务部门制定公司战略，心里还是很满足的。
从工业角度而非学术角度，我认为预测分析和人工智能（artificial intelligence）在某种意义上存在交叉。人工智能既然是通过计算机来帮助和扩展人类的智能，那么通过对现有数据的分析和挖掘，然后做出对公司最优化的建议无疑就是最高等级的预测分析。当然AI不仅限于此，例如我们可以通过它来更高效地收集数据，通过它来建立业务模型，甚至通过它来编写算法程序等。这个话题目前还太遥远，因此我就不多介绍了。
后文将会给您介绍传统BI项目框架中余下的部分。
