我在前面几部分介绍了传统BI项目的7层结构和关注点。内容以经验总结为主，偏理论。在接下来的部分我会介绍BI项目的两种实施方法，算是对理论的落地。
介绍前，我想先说一下由上至下（Top-Down）和由下至上（Bottom-Up）的区别。由上至下可以简单的认为是某个业务组、部门老大、或者公司老大来授权或者牵头的“轻量级”BI实施项目，目的是解决某个小组，某项业务，或者某个部门的业务痛点或者需求。在您写此类项目的标书或者启动报告时会深有体会。
由下至上的项目正相反。其目的是优先摸清整个公司的数据，系统，流程，组织结构，业务重点等，然后通过数据和业务的整合，统一建模，开发出集中的数据仓库或平台，然后通过这个平台来解决不同用户的业务痛点或需求。由下至上的BI项目一般是“重量级”的，其用时长，资源耗费大，单一业务部门很难驾驭，通常由IT部门发起并管理。
本文重点是介绍由上至下的BI实施方法。
项目建立
由上至下的项目目的一般都很明确，某个业务组，某个经理，某个部门老大都可以牵头实施这样的项目。它主要有以下几个特点。
首先是实施团队比较灵活。可以是内部IT帮助实施，也可以聘请外部顾问或者实施团队来完成。由于此类项目的时间、范围、和涉及的业务都相对较小，聘请外部团队会更加合算。一般4到5人的小团队就足够了（采用敏捷方式和新型BI工具。对于SAP等传统大型项目要另行考虑），有业务专家助阵的话还可以事半功倍。如果是业务部门自己牵头的项目，聘请外部团队在数据、资金、和产品所有权方面可以灵活操作。完成之后要么交付给IT，要么继续由外部公司来维护，应该都不是问题。（『牛牛爸的专栏』出品，请勿转载。）
其次是需求明确。第二部分重点描述了过度期待、需求变更、和项目范围蔓延等BI项目常见的问题。我认为这些是国内大部分BI项目失败的主因之一。由上至下强调的是“小范围”，“小流程”，“小部门”。业务部门一般都带着明确的痛点或者需求，不会无厘头地要求项目组跑东跑西。另外此类项目大多是老大牵头，只要优先满足老大的意见和方向，其他人都好说。因此需求分析会相对简单。
数据是BI的灵魂。由上至下因为范围相对小，项目组在先期可以把数据的功课做足，这样项目经理可以更准确地预估时间和风险。此外由于此类项目是业务老大牵头，遇到突发的或者范围外的数据，由业务部门帮忙获取的成功率一般要高于IT或者外部顾问去获取（如果您的公司正相反，IT很强势，那您现在就约饭吧，打好关系嘛）。
由上至下的项目在时间上大多有明确的起点和终点，不会纠缠没完。起点可能就是老大的一句话，或者某个部门的RFQ，终点就是测试完成，解决了用户痛点或需求，并成功上线。由于项目时间相对短，用户不必等很久就能享受分析的结果。对于外部公司，参与这种项目的风险要远小于由下至上的项目。
具体的项目操作流程
介绍完特点之后我们上干货。先看看牛牛爸总结的项目实施7步骤：
1.了解用户需求和优先级（Understand Business Needs and Priorities）
由上至下的BI项目目的明确，启动快。因此项目组在初期就可以直奔主题：收集客户需求。我的建议是从“头”开始，先单独了解组长或者经理的目的，痛点，或者需求，然后再接触下面的业务人员。
很多人会建议通过讨论会（Workshop）的形式一次性地收集需求，但从我目前的经验来看，讨论会效率非常低，大多都会演变成吐槽大会。另外管理人员和业务人员坐在一起，很多话不好说，也不会说。因此如果有条件的话，一对一或者小范围的面试（Interview）是最高效的。这里有一个例外：如果公司已经有BI系统，或者大家对BI很熟悉，那么集中起来开讨论会还是可以的。
一个容易被忽视的地方是优先级。80/20原则大家都知道。掌握了用户尤其是经理的优先级，项目组就可以从重点着手，优先分析数据，尝试整理模型，早发现问题早解决。只要达成80%的目标，尤其是高优先级的目标，到后期项目时间或者资源紧迫时，我们可以忽略不重要的内容来避免项目延迟和用户不满。
2.分析相关系统和数据（Analyze Linked Applications and Data）
很多业务人员没有BI或者技术基础，因此他们会完全站在业务的角度提出需求或者痛点 。这就需要项目组分析用户需求，找出背后所隐含的业务流程，系统，和数据，逐一分析它们，并最终转化为技术人员能够看得懂的文档。
此外业务人员往往会重点描绘自己的部分，而忽略别人的部分。因此项目组还要分析了解流程的上游和下游，关键点和瓶颈在哪里，每个点都涉及到哪些人和部门，每个环节会涉及到哪些数据，数据权限如何，访问权限如何等等要素。
系统分析的困难可能会多一些，例如没有访问权限，帮助文档不足，系统所有者不配合，IT不配合，或者大量技术缺陷等。如果系统很老或者是内部开发的，就涉及到将来怎么抽取数据的问题，以及数据质量问题。这些都要在这个阶段分析并解决。
数据的分析是最费功夫的，例如业务人员会简单地要求项目组做出PPT里的某张图，但是他不知道也不关心后面包含了多少历史数据，数据质量如何，数据所有权，有没有手动调整的痕迹，数据维度有哪些，维度是否有变化，多数据整合问题，数据口径问题等等。这些都需要项目组辛辛苦苦地去发掘和注意的。
先码到这。下一部分会介绍操作框架里的第3到第7步骤。