【BI】 商业智能（BI）项目的介绍 Part 3：BI项目贯穿

BI项目介绍 Part 3

前面两部分我介绍了传统BI项目框架的左半部分：基础（Foundation） 和实现（Enablement）。接下来和您聊聊右边剩下的，也是BI项目核心的重要元素。先回顾一下BI项目元素构架图：

传统BI项目框架

BI框架之贯穿始终的要素

基础和实现部分的元素都可以在某个时间单独拿出来考虑，而接下来的三个要素我认为是BI项目成败的关键，要贯穿始终。

团队配合

我所说的团队包含小大两个范围：BI实施团队和公司。BI实施团队一般会包括项目经理（PM），业务专家（domain expert），商业分析师（business analyst），架构师（architect），开发人员（developer），数据处理人员（data analyst），测试人员（tester）等。一个BI项目团队的配合情况决定了这个项目的时间和质量。例如数据人员没有弄清楚某个数据的清洗规则，那么后期的开发人员就要花费大量时间去检查和修改程序。如果架构师，业务专家和商业分析师不能完全理解对方，甚至误解，那么后期的模型将会异常地难用，甚至作废。作为BI项目经理，最大的挑战是统筹协调项目组和业务人员之间的关系。只有和业务人员以及管理层建立充分的信任，BI团队才有可能顺利地获取用户需求，后期合理的修改意见，和最终的验收。

之前我们提到很多部门视数据为私有财产，如果贡献给BI项目，那么别的部门很可能也会拿到这些数据。各部门之间有时也会互相推诿分析结果。如何打破公司内部的各种壁垒，使得各个团队之间能够互相配合，发现问题的时候能够心平气和地坐下来分析成因，便成了公司掌舵人和BI团队的当务之急。在项目启动初期，公司高层就应该意识到BI的重要性，并通过命令或授权等方式打通项目组可能会遇到的各种障碍。另一方面，BI经理也应该随着项目的推进，逐步建立和提高开发人员和业务人员之间的信任，并使双方进入良性循环。如果在实施阶段业务和技术双方的配合度能达到最高，那么所开发出来的产品就最为有效，公司也能从中获得最大的投资收益。如果双方的信任被打破，逐渐进入恶性循环，那BI应用最终可能会沦为少数人的数据采集工具而已。

数据管控和质量

国内做项目就不得不先强调人，因为人最难协调，出的问题也最多。但是在国外的行业总结里，数据管控和质量永远是放在第一位的。数据管控考虑的是数据的所有权，更新频率，访问权限，数据安全，风险，数据的敏感度等等。您可能要问我为什么在项目初期，而不放在数据建模的时候才考虑管控。在初期当业务部门还心存戒心的时候，如果我们能够明确提出数据所有权和将来的访问权限，那直接获取全部数据的可能性会非常高（避免了高层出面）。如果在当初没有确定各部门的数据所有权和义务，等BI上线，实施团队解散之后，我们会尴尬地发现一个新的荒草地又诞生了（想想您的公司有多少无人认领的荒废系统？）。此外，站在工作的角度，如果BI的所有权不属于本业务部门，但是要求业务人员在忙碌之余还要去维护系统内的数据，然后分析的结果供其他部门使用，凭什么？！如果在项目初期没有解决此类问题，那么积累到后期就会非常麻烦。

数据质量就不用多解释了，基本的道理大家都懂。数据质量不仅存在于单个数据本身，也存在于多种数据整合之后是否能达到预期的效果。有两个环节可以提高数据质量。一个是同过ETL过程，在抽取和转化阶段根据业务定义好数据的清洗规则（data rules），例如如果一家经销商当月上报的汽车销售数据是一亿台，那我们很直观的就知道这是个“脏数据”。另一个提高的地方在数据仓库层面。我们可以根据存储规则或某些工具对数据进行预先处理，例如把销售MTD和YTD的数值先计算好之后再存入数据仓库，这样的话架构师就可以构建更有针对性的模型。

垃圾进，垃圾出（rubbish in，rubbish out）！如果您不从源头控制好数据质量，不在乎这个事情，那么等错误的结果给公司造成损失的时候则为时晚矣。

工作流程和文化的改变

牛牛爸遇到过很多类似的尴尬要求：经理看到BI后说这个好，然后要求下面员工把最新的截图放到PPT里然后发给他看。您已经拥有访问权限了，为什么不自己直接查看哪？当我们调研用户需求时，很多业务人员会信誓旦旦地问BI页面能不能做的和现有PPT一样。现在很多BI工具，例如Tableau，可以把界面做的非常灵活。您为什不在下次会议上直接把BI图表投出来，而还在手工制作那些滞后的片子哪？

这里又给BI团队带来了新的挑战：从一开始就应该慢慢地引导用户转变思维，并最终带领公司在工作上和文化上做出革新。其实想通过一个程序就改变公司的做事风格，说起来容易，做起来太难。在过去实施SAP这种大型的瀑布式BI项目时，用户往往要等很久才能看到BI应用。由于高昂的顾问费用，很多用户基本上看几次就正式接收了，完全没有一个过度的过程。好在现在的工具都支持敏捷开发，我们可以快速地理解用户需求，建模，拉图表，设权限，然后交付给用户试用。我们会引导用户在实战中使用这些工具，这样拿到的反馈和修改意见也最有意义。工作思维的转化需要一个漫长的过程。但愿在不久的将来大家会习惯这种新的工作方式。

两种实施策略

框架介绍完了，基本上都是我的经验理论，您要是实战的话可能没有什么帮助。因此接下来我会介绍两种BI项目实施方法论。

第一种是由上而下（Top-Down）的项目实施方法。第二种是由下而上（Bottom-Up）的方法。由上而下首先关注的是某一个部门或者团队的BI解决方案。其目的是解决数据相对简单，范围清晰的业务经理（business unit manager）的分析任务。由下而上一般由IT部门牵头，先从公司的系统和数据着手，分析清楚之后再建立统一的BI平台，然后在平台之上搭建适合各部门的应用。我会在Part 4继续介绍由上而下的实施方法。