成功实施BI项目的几大要素.pdfVIP

成功实施BI项目的几大要素

接前文，一文读懂商业智能（BI）：企业数据分析的中枢，文章

解释了BI元素框架（BIComponentFramework）里的基础部分

（Foundation），现在由下及上继续聊。首先还是先温习一下前面的

架构图：

数据搬来了，工具选好了，实施就能成功？

前面我解释了大多数以技术为主导的IT部门做不好BI项目。如果

说那些关键点是一个公司始终都要注意的，那么在实现部分

（Enablement），我要提醒几个特别的风险点。

首先是业务部分或者管理层的过度期待（overexpectation）。

随着BI项目的推进，我相信很多以前没有听说过商业智能的人会多多

少少地去网络了解这个新事物。IT有一个特点，那就是“坏事不出门，

好事传千里”。现在的很多商业智能厂商会出很多神乎其神的宣传和

各种如科幻片一样的图表分析。因此很多没有项目基础和实际经验的

人容易对BI产生幻觉，认为只要公司拥有这样的系统，就好似有了一

个超级大脑来保驾护航。或者认为BI同excel一般灵活，随便改一下

公式就可以看到结果。其实懂行的知道，BI的成功7成在于业务，3成

在于技术。如今的BI只要稳定，自助，以及对数据分析技术以及大数

据有良好的性能支撑，其他就看业务分析员如何驾驭工具和运用分析

逻辑了。（这里笔者常参与帆软FineBI的项目实施，类同于Tableau，

都是值得考虑的BI产品）

其次是IT或者BI实施团队的过度承诺（overpromising）。相对

于传统的商业系统，BI算是一个新生事物，因此很多公司的实施团队

经验有限，容易乐观地估计项目的结果。例如当项目组在基础阶段发

现底层数据的质量高于预期时，便容易乐观地认为项目时间会大大缩

短，或者过早地保证实现某种高级分析。BI项目的铺垫一般都很长，

业务用户只有等技术人员把分析结果投影到幕布上时才能真正看到问

题的所在。在这个阶段因为数据或者模型缺陷而把BI应用推倒重来的

案例比比皆是。因此过早或过度地承诺可能会在后期给实施团队带来

巨大的压力，建议在选型BI时要考虑乙方的项目实施能力和业务经验。

再次是用户需求变更（userrequirementchanges）。因为BI属

于新事物，很多业务用户在初期的需求收集阶段无法给出准确的意见，

只有等看到演示（demo）时才大致明白BI是什么东西，并且会随着

应用的完善而不断地提出修改意见。此外BI用户通常包含部门经理和

一般业务人员。不同级别的人对公司业务的侧重点会有不同，因此BI

团队经常要面对完全对立的修改意见。如何控制好用户意见和修改原

则是BI团队要早早考虑的问题。

最后是项目范围蔓延（scopecreep）。基于国内项目的特点和从

我个人的经验，没有一个交付的BI应用是完全按照设计文档来实施的。

不是因为我们没有能力做好设计，而是当用户看到A功能后会立刻要

求B功能，甚至提出C功能的预想。对于一般业务人员提出的新需求

我们可以找些不明觉厉的理由来拒绝，但是面对管理层，我们可能会

失去话语权（BI项目碰到高级经理的机会要远大于其他项目）。因此

BI团队要按照项目实施方法论和自身的特点尽早做出调整。

BI框架之实现部分（Enablement）

不知道大家是否注意到实现部分的三层顺序。为什么分析会放在

报表之后哪？其原因就是防止过度期待和过度承诺而最终导致大家不

欢而散。

通常BI项目会在后期碰到各种各样无法预先准备的问题，例如数

据无法打通，模型设计缺陷，维度交叉造成的错误，或者无法达成某

种分析结果等。此外BI应用是基于业务流程和数据的，IT测试人员仅

能够检查计算结果是