“Annually, more than 70 percent of IT projects fail to meet expectations or become shelfware. Reasons for failure range from business intelligence (BI) projects not being completed on time and within budget to not being completed at all. Alternatively, BI initiatives may satisfy IT‘s needs, but may not address those of end users. ”
以上的文字摘选自DM Review Online，简单的说商务智能应用就像其他的IT应用实施一样充满了各式各样的失败的例子。我在今年3月同IBM和SAP合办的商务应用研讨会上就商务智能项目实施中的陷阱进行了一些探讨，希望能同大家一起共享，在具体项目实施中能够避免或帮助解决类似问题。
项目实施的方法论与过程
当前各家BI的软件厂商都有各自不同的BI实施方法论和过程，他们大多大同小异。以SAP BW的实施方法论为例子，大约需要经历5个不同的阶段。各个阶段的目的和具体的内容因项目的不同而略有差异，但大致相同。因此，我就以此ASAP过程为例， 来探讨项目实施过程中的陷阱和对策。
项目准备和计划阶段
在项目准备和计划阶段，考量项目是否已经“万事俱备”可以从3个方面入手。
1. 用户需求是否清楚？
2. 是否已经明确BI的技术标准？
3. 业务部门是否有所准备？
在这3个方面中尤为重要的是，用户需求是否清楚。而在这个阶段可能的陷阱有以下这些：
1. 缺乏高层领导的支持。BI的目标用户不同于ERP，它覆盖的面从高层领导到一线员工都有，并且更侧重于管理层。他们可能是BI的最终用户，并且直接介入管理层的日常工作。如果领导层不理解项目的意义并支持项目的实施，将对项目产生巨大的不利影响。
2. 没有制定BI的技术标准。BI的项目实施是一个长期的过程，分阶段来实现，通常不会一个项目就解决所有的问题。因此在选择BI软件，硬件，架构等问题上必须有长期的考虑，为企业制定可扩展的BI技术标准是关键。
3. 没有获得业务部门的资源支持。BI项目同ERP一样需要大量的业务部门的资源，IT只能负责其中的一部分，业务部门必须承诺在项目中投入相应的资源。
4. 在项目准备阶段没有相应的咨询公司的参与。大多数的企业对于BI应用的认识仍然处于相对初级的阶段，因此在项目准备阶段就选择咨询公司并让他们参与规划对项目的实施有重要的意义。
设计阶段
设计阶段是BI项目最重要的阶段，其重要性甚至超过了具体的开发阶段。该阶段大致需要覆盖以下方面：
本阶段中的关键的关键是业务分析和模型设计。我将稍稍具体的来探讨一些关键点。 第一，应该如何展开业务分析？业务分析事实上包括了两方面，源系统分析和用户需求分析。以下图示是我们所推崇的业务分析方式：
业务分析人员应该同时从用户需求和源系统两端同时展开分析，并且其中的重点在于源系统的数据是最终该BI应用可以满足多少用户需求的必要条件。一个好的业务分析应该在充分理解源系统数据的基础上，不但能满足用户的需求，并且能超越或预见用户未来可能的需求从而予以相应的考虑。
业务分析所产生的文档将直接指导数据仓库的模型设计。模型设计与业务分析经常是同一个人来负责，但也因此对建模师的要求抬高了。目前数据仓库建模基本上有两种模式，一种是Bill Inmon所首先提出的ER模型，另一种是Kimbal的维度建模方式。数据集市一般都是维度建模的（也叫星型模型）。也有将这两种模型混合使用的。我在此并不打算详细分析此两者的优劣，这可以是另外一个很大的题目来讨论。
这里针对我们今天的题目，我想提出的问题是应该如何判断建好的模型的质量？在我们所经历过的项目中，客户经常反复检验的是报表或分析的质量而非常少的来检验模型的质量。殊不知，模型的好坏很大程度上将影响前端分析的质量，系统的速度，ETL开发的难易等一系列的问题。可见，检验模型质量是如何重要了，但是目前而言还没有一个业界公认的标准方法和流程来检验模型的质量。而对客户而言，仅仅依赖于咨询顾问而没有亲自检验模型，则很容易在后面的开发阶段同咨询顾问产生疑义。然而问题是通常客户的IT或关键用户并没有建模的技术能力和经验，所以该如何检验模型就成为难点。我在此提出的方法也仅是提供大家一种借鉴，也希望大家能有更好的方法共享。
上面这3个步骤可以用于ER或维度建模。简单的说，第一步：如果是ER模型则首先应检验是否所有的实体表已经在模型中正确的建立了。比如，项目包含了销售主题的分析，那么销售相关的实体表是否已经包含在了模型中？（假设发现销售订单表或客户表没有包含，那么显然有问题）。如果是维度建模，那么总是首先确认是否所有的维度表已经明确。接下来，就要检验实体表之间的关系（ER建模）或维度和事实表之间的关系（维度建模）。
第二步中，如果是维度建模那么检验事实表和粒度是相当显而易见的，如果是ER建模同样要检验是否在ER模中包含足够细的数据粒度。同时在这一步中可以检验是否因为系统性能优化的需求而进行了相关的设置，比如增加了某些聚合表，或进行了索引的优化，或进行了分区等等。
第三步，如果是维度建模在重点在检验模型对于缓慢变化或快速变化的维度是如何解决的。如果是ER模型，则需要考虑基于该模型的数据集市应该如何管理维度的变化。最后应该尝试对模型使用相应的业务需求来进行检验，通常可以通过提问回答的方式来检验（因为此时前端和ETL还没有完成）。比如，提问：客户需要产生月度的销售报表，并可以按产品进行分类。回答：模型中已经包含了月度的销售聚合表，可以按产品维度进行分析。
以上3步并不需要客户拥有太多的技术，通常关键用户和IT能够胜任。当然，这样的检验也只能在某种程度上保证模型质量，真正的问题还是在于咨询顾问方是否拥有深厚的建模功底。
现在让我回到主题，什么是设计阶段可能的陷阱呢？
1。在用户需求分析和设计的时候没有同时从源数据和用户需求出发。
2。忽略了架构设计
3。忽略了对数据模型进行检验的重要性
4。数据建模时没有对缓慢变化和快速变化的维度进行适当的处理
5。为满足用户需求在前端设计时加入了过多的客户化或额外编程的要求。
这些陷阱看上去并没有什么特别，但是许多项目就还是为这些几乎显而易见的陷阱所阻。
开发阶段
完成设计以后的开发阶段是BI项目中占用大多数人工和时间的阶段，在这个阶段项目将进行一系列的开发，比如ETL的开发，前端报表或分析的开发，元数据管理，权限设置等等。但是有意思的是，在这个阶段最有难度的并不是具体的开发有如何的难度，最难以控制的是这样一个问题：“我们开发的是否正是用户需要的？”
听上去这个问题不是应该在设计阶段已经解决的吗？没有错，设计阶段应该要解决这个问题，通过理解用户的要求和源数据的状态。但是相比于用户对于数据模型的无法理解，用户对于前端报表和分析的要求通常是非常高，并且经常变化的。随着BI项目的进展，用户对于他们想要得前端报表和分析的要求是在不断变化的，我们并不能通过一个设计阶段就期望能够确定所有前端的需求。可以说，设计阶段只能够给我们一个前端需求的基础版本，它的最终确定会随着项目的进展而变化，而我们需要做的就是要不断地发现这些变化并在开发阶段更新我们的设计来满足这些变化。
最糟糕的事情莫过于等到用户做完用户测试，然后告诉你有一大堆的报表和分析你需要重做。
上图简单的列出了开发阶段的主要部分，而其中的重点部分是ETL和前端开发，如何来安排ETL和前端开发正是回答应该如何来解决上面问题的关键。
开发阶段的陷阱大致有如下这些：
1。缺乏项目变化控制流程
2。缺乏项目质量控制尤其是数据质量监控
3。在开发阶段没有让最终用户参与
在这里，我已经解释了为什么要让最终用户参与开发，目的就是要及时反馈用户对开发结果的意见，并通过项目变化控制流程来决定是否要改变设计文档以反映最新情况。问题是如何才能有效地来让最终用户参与？
下图，是我们在项目中经常采用的一种方式,我们称之为：Concurrent Development, Incremental delivery (同步开发，分步验收）
简单的说在这种开发方式下，ETL队伍和前端开发队伍需要协同工作，将所有的开发需求先分成几个组，每个组包含开发前端所需要的ETL。如此，前端开发团队就无需等待ETL团队开发完所有的ETL才进行开发。当前端团队开发完第一组前端报表时，ETL团队就可以配合加载真实数据，这个时候就可以让最终用户马上参与进来检验前端报表是否符合他们的需求，以及数据是否正确。
当然，我现在描述的只是一个大致的流程，具体的安排根据项目的不同需要大量的细节需要安排。
这种开发方式的最大优点就是，它减少了在测试阶段用户有可能提出的需求变更，并增加了用户对项目结果的信心。
测试和部署阶段
测试和部署阶段最重要的任务是检验整个项目的结果。大致有以下的关键点：
除了集成测试以外，需要特别指出的是性能优化和业务流程重组是容易被忽略的部分。特别是业务流程重组，普遍的误解在于BI项目由于其产出是报表和分析，不同于ERP，似乎不涉及业务流程变化。其实不然，BI项目的根本目的不在于仅仅产出报表，重点是通过使用BI应该如何优化企业的决策流程。也就是说，有了更多更强大的数据和分析，应该如何改变企业的行为？比如，销售经理应该通过BI的分析来指导他的销售员进行具体的销售活动？每周或每月的销售会议在有了BI之后应该如何改变以最大化的利用BI？
在BI项目中应该同SAP项目一样引入专门的业务流程变更人员或顾问，帮助企业来重新审视业务决策流程，并将BI的影响传播到企业的相应层面。
在这个阶段的陷阱通常是：
1。缺乏业务流程变更的准备和没有相应的资源
2。缺乏足够的用户培训和推广
3。在最后一分钟，对项目的需求进行修改
特别想提一下就是最后一分钟需求发生变化是许多失败的项目的共同点。
系统上线
最后我们来到系统上线阶段，不过这并不是BI项目的结束。BI应用对企业来说不是一个或两个项目，而是一个长期的实施和不断优化过程。系统上线阶段，除了要对已经完成的项目进行总结和安排系统维护的流程以外，重要的是应该重新来审视企业的BI战略，调整长期的规划，预算下一阶段的项目。
这里的陷阱就是：
1。认为BI实施已经结束
2。缺乏长期的规划
最后，也是最后一个陷阱：BI项目的实施没有捷径，试图跳过以上的关键阶段，盲目的压缩项目的时间和资源都将不可避免的带来失败的危险。
（全文完）
这里针对我们今天的题目，我想提出的问题是应该如何判断建好的模型的质量？在我们所经历过的项目中，客户经常反复检验的是报表或分析的质量而非常少的来检验模型的质量。殊不知，模型的好坏很大程度上将影响前端分析的质量，系统的速度，ETL开发的难易等一系列的问题。可见，检验模型质量是如何重要了，但是目前而言还没有一个业界公认的标准方法和流程来检验模型的质量。而对客户而言，仅仅依赖于咨询顾问而没有亲自检验模型，则很容易在后面的开发阶段同咨询顾问产生疑义。然而问题是通常客户的IT或关键用户并没有建模的技术能力和经验，所以该如何检验模型就成为难点。我在此提出的方法也仅是提供大家一种借鉴，也希望大家能有更好的方法共享。
上面这3个步骤可以用于ER或维度建模。简单的说，第一步：如果是ER模型则首先应检验是否所有的实体表已经在模型中正确的建立了。比如，项目包含了销售主题的分析，那么销售相关的实体表是否已经包含在了模型中？（假设发现销售订单表或客户表没有包含，那么显然有问题）。如果是维度建模，那么总是首先确认是否所有的维度表已经明确。接下来，就要检验实体表之间的关系（ER建模）或维度和事实表之间的关系（维度建模）。
第二步中，如果是维度建模那么检验事实表和粒度是相当显而易见的，如果是ER建模同样要检验是否在ER模中包含足够细的数据粒度。同时在这一步中可以检验是否因为系统性能优化的需求而进行了相关的设置，比如增加了某些聚合表，或进行了索引的优化，或进行了分区等等。
第三步，如果是维度建模在重点在检验模型对于缓慢变化或快速变化的维度是如何解决的。如果是ER模型，则需要考虑基于该模型的数据集市应该如何管理维度的变化。最后应该尝试对模型使用相应的业务需求来进行检验，通常可以通过提问回答的方式来检验（因为此时前端和ETL还没有完成）。比如，提问：客户需要产生月度的销售报表，并可以按产品进行分类。回答：模型中已经包含了月度的销售聚合表，可以按产品维度进行分析。
以上3步并不需要客户拥有太多的技术，通常关键用户和IT能够胜任。当然，这样的检验也只能在某种程度上保证模型质量，真正的问题还是在于咨询顾问方是否拥有深厚的建模功底。
现在让我回到主题，什么是设计阶段可能的陷阱呢？
1。在用户需求分析和设计的时候没有同时从源数据和用户需求出发。
2。忽略了架构设计
3。忽略了对数据模型进行检验的重要性
4。数据建模时没有对缓慢变化和快速变化的维度进行适当的处理
5。为满足用户需求在前端设计时加入了过多的客户化或额外编程的要求。
这些陷阱看上去并没有什么特别，但是许多项目就还是为这些几乎显而易见的陷阱所阻。
开发阶段
完成设计以后的开发阶段是BI项目中占用大多数人工和时间的阶段，在这个阶段项目将进行一系列的开发，比如ETL的开发，前端报表或分析的开发，元数据管理，权限设置等等。但是有意思的是，在这个阶段最有难度的并不是具体的开发有如何的难度，最难以控制的是这样一个问题：“我们开发的是否正是用户需要的？”
听上去这个问题不是应该在设计阶段已经解决的吗？没有错，设计阶段应该要解决这个问题，通过理解用户的要求和源数据的状态。但是相比于用户对于数据模型的无法理解，用户对于前端报表和分析的要求通常是非常高，并且经常变化的。随着BI项目的进展，用户对于他们想要得前端报表和分析的要求是在不断变化的，我们并不能通过一个设计阶段就期望能够确定所有前端的需求。可以说，设计阶段只能够给我们一个前端需求的基础版本，它的最终确定会随着项目的进展而变化，而我们需要做的就是要不断地发现这些变化并在开发阶段更新我们的设计来满足这些变化。
最糟糕的事情莫过于等到用户做完用户测试，然后告诉你有一大堆的报表和分析你需要重做。
上图简单的列出了开发阶段的主要部分，而其中的重点部分是ETL和前端开发，如何来安排ETL和前端开发正是回答应该如何来解决上面问题的关键。
开发阶段的陷阱大致有如下这些：
1。缺乏项目变化控制流程
2。缺乏项目质量控制尤其是数据质量监控
3。在开发阶段没有让最终用户参与
在这里，我已经解释了为什么要让最终用户参与开发，目的就是要及时反馈用户对开发结果的意见，并通过项目变化控制流程来决定是否要改变设计文档以反映最新情况。问题是如何才能有效地来让最终用户参与？
下图，是我们在项目中经常采用的一种方式,我们称之为：Concurrent Development, Incremental delivery (同步开发，分步验收）
简单的说在这种开发方式下，ETL队伍和前端开发队伍需要协同工作，将所有的开发需求先分成几个组，每个组包含开发前端所需要的ETL。如此，前端开发团队就无需等待ETL团队开发完所有的ETL才进行开发。当前端团队开发完第一组前端报表时，ETL团队就可以配合加载真实数据，这个时候就可以让最终用户马上参与进来检验前端报表是否符合他们的需求，以及数据是否正确。
当然，我现在描述的只是一个大致的流程，具体的安排根据项目的不同需要大量的细节需要安排。
这种开发方式的最大优点就是，它减少了在测试阶段用户有可能提出的需求变更，并增加了用户对项目结果的信心。
测试和部署阶段
测试和部署阶段最重要的任务是检验整个项目的结果。大致有以下的关键点：
除了集成测试以外，需要特别指出的是性能优化和业务流程重组是容易被忽略的部分。特别是业务流程重组，普遍的误解在于BI项目由于其产出是报表和分析，不同于ERP，似乎不涉及业务流程变化。其实不然，BI项目的根本目的不在于仅仅产出报表，重点是通过使用BI应该如何优化企业的决策流程。也就是说，有了更多更强大的数据和分析，应该如何改变企业的行为？比如，销售经理应该通过BI的分析来指导他的销售员进行具体的销售活动？每周或每月的销售会议在有了BI之后应该如何改变以最大化的利用BI？
在BI项目中应该同SAP项目一样引入专门的业务流程变更人员或顾问，帮助企业来重新审视业务决策流程，并将BI的影响传播到企业的相应层面。
在这个阶段的陷阱通常是：
1。缺乏业务流程变更的准备和没有相应的资源
2。缺乏足够的用户培训和推广
3。在最后一分钟，对项目的需求进行修改
特别想提一下就是最后一分钟需求发生变化是许多失败的项目的共同点。
系统上线
最后我们来到系统上线阶段，不过这并不是BI项目的结束。BI应用对企业来说不是一个或两个项目，而是一个长期的实施和不断优化过程。系统上线阶段，除了要对已经完成的项目进行总结和安排系统维护的流程以外，重要的是应该重新来审视企业的BI战略，调整长期的规划，预算下一阶段的项目。
这里的陷阱就是：
1。认为BI实施已经结束
2。缺乏长期的规划
最后，也是最后一个陷阱：BI项目的实施没有捷径，试图跳过以上的关键阶段，盲目的压缩项目的时间和资源都将不可避免的带来失败的危险。
（全文完）
