BI项目的实施过程

开发阶段的陷阱大致有如下这些：
1.缺乏项目变化控制流程 2.缺乏项目质量控制尤其是数据质量监控 3.在开发阶段没有让最终用户参与 让最终用户参与开发，目的就是要及时反馈用户 对开发结果的意见，并通过项目变化控制流程来 决定是否要改变设计文档以反映最新情况。问题 是如何才能有效地来让最终用户参与？
同步开发，分步验收 在这种开发方式下，ETL队伍和前端开发队伍需要 协同工作，将所有的开发需求先分成几个组，每 个组包含开发前端所需要的ETL。如此，前端开发 团队就无需等待ETL团队开发完所有的ETL才进行 开发。当前端团队开发完第一组前端报表时，ETL 团队就可以配合加载真实数据，这个时候就可以 让最终用户马上参与进来检验前端报表是否符合 他们的需求，以及数据是否正确。 这种开发方式的最大优点就是，它减少了在测试 阶段用户有可能提出的需求变更，并增加了用户 对项目结果的信心。
应该如何展开业务分析？ 业务分析事实上包括了两方面，源系统分析和用 户需求分析。以下图示是比较通用的业务分析方 式：
业务分析人员应该同时从用户需求和源系统两端 同时展开分析，并且其中的重点在于源系统的数 据,是最终该BI应用可以满足多少用户需求的必要 条件。一个好的业务分析应该在充分理解源系统 数据的基础上，不但能满足用户的需求，并且能 超越或预见用户未来可能的需求从而予以相应的 考虑。
SAP BI项目实施的大致流程
项目计划和准备
在项目准备和计划阶段，考量项目是否已经“万 事俱备”可以从3个方面入手。 • 用户需求是否清楚？ • 是否已经明确BI的技术标准？ • 业务部门是否有所准备？
在这3个方面中尤为重要的是:用户需求是否清楚。
实际情况是用户在开始阶段并不能完全清楚自己需要什么,可能会在 以后的过程中修正自己的需求,故在设计阶段需要充分考虑到扩展性. 但一些主要的需求必须要在项目计划阶段搞清楚
精选课件12设计阶段可能的陷阱在用户需求分析和设计的时候没有同时从源数据和用户需求出发数据建模时没有对缓慢变化和快速变化的维度进行适当的处理为满足用户需求在前端设计时加入了过多的客户化或额外编程的要求
BI项目的实施过程
BI项目实施的方法论与过程
当前各家BI的软件厂商都有各自不同的BI 实施方法论和过程，他们大多大同小异. 这里 以SAP BW的实施方法论和微软BI通用流程为例， 来阐述BI项目实施的基本过程和需要注意的事 项
模型验证，根据已建立的维度模型验证是否能满足所 有的报表需求。同上，此步骤必须要有BI经验的人做。如 果模型满足不了统计的要求则重新建模。这里是需要一个 反复迭代的过程，每次迭代的结果都要沉淀下来并且形成 文档。 反向确认数据仓库结构，手动或者系统自动均可，自 动生成来说SQLServer从2005就已经支持了，不过为了命 名规范，还是手动来生成数据仓库比较有必要。 分析数据来源及SSIS开发。最好是由相关模块的开 发人员参与，因为开发人员是对数据结构比较了解的，并 且有SQL功底，而且还掌握业务。这一步的目的是填充数 据仓库。可能需要适当SSIS培训。不过，这一步公认是最 耗时的。同时，不是所有的统计项就是能从业务那边解释 的了的，比如某些统计概念，可能在业务系统从来就没出 现过，但是通过基本数据组合都可以计算出来。所以类似 概念，确认计算公式等就需要BI人员承担起需求的工作去 确认。
测试和部署阶段
测试和部署阶段最重要的任务是检验整个项目的结果。 大致有以下的关键点： 除了集成测试以外，需要特别指出的是性能优化和 业务流程重组是容易被忽略的部分。特别是业务流程 重组，普遍的误解在于BI项目由于其产出是报表和分 析，不同于ERP，似乎不涉及业务流程变化。其实不 然，BI项目的根本目的不在于仅仅产出报表，重点是 通过使用BI应该如何优化企业的决策流程。也就是说， 有了更多更强大的数据和分析，应该如何改变企业的 行为？比如，销售经理应该通过BI的分析来指导他的 销售员进行具体的销售活动？每周或每月的销售会议 在有了BI之后应该如何改变以最大化的利用BI
如何进行模型设计 业务分析所产生的文档将直接指导数据仓库的模 型设计。模型设计与业务分析经常是同一个人来 负责，但也因此对建模师的要求抬高了。目前数 据仓库建模基本上有两种模式，一种是Bill Inmon所首先提出的ER模型，另一种是Kimbal的维 度建模方式。数据集市一般都是维度建模的（也 叫星型模型）。也有将这两种模型混合使用的。 如何验证所建模型的好坏
客户经常反复检验的是报表或分析的质量而非常少的来 检验模型的质量。殊不知，模型的好坏很大程度上将影 响前端分析的质量，系统的速度，ETL开发的难易等一 系列的问题。可见，检验模型质量是如何重要了，但是 目前而言还没有一个业界公认的标准方法和流程来检验 模型的质量应检验是否所有的实体 表已经在模型中正确的建立了。比如，项目包含了销 售主题的分析，那么销售相关的实体表是否已经包含 在了模型中？（假设发现销售订单表或客户表没有包 含，那么显然有问题）。如果是维度建模，那么总是 首先确认是否所有的维度表已经明确。接下来，就要 检验实体表之间的关系（ER建模）或维度和事实表之 间的关系（维度建模）。 • 第二步:如果是维度建模那么检验事实表和粒度是相 当.显而易见，如果是ER建模同样要检验是否在ER模 中包含足够细的数据粒度。同时在这一步中可以检验 是否因为系统性能优化的需求而进行了相关的设臵， 比如增加了某些聚合表，或进行了索引的优化，或进 行了分区等等。
• 在项目准备阶段没有相应的咨询公司的参与。大多数的企业对于BI应 用的认识仍然处于相对初级的阶段，因此在项目准备阶段就选择咨询 公司并让他们参与规划对项目的实施有重要的意义。
设计阶段
设计阶段是BI项目最重要的阶段，其重要性甚至超过了 具体的开发阶段。该阶段大致需要覆盖以下方面：
设计阶段的注意事项 本阶段中的关键的关键是业务分析和模型设计
设计阶段可能的陷阱
• 在用户需求分析和设计的时候没有同时从源数据和用 户需求出发 • 忽略了架构设计 • 忽略了对数据模型进行检验的重要性 • 数据建模时没有对缓慢变化和快速变化的维度进行适 当的处理 • 为满足用户需求在前端设计时加入了过多的客户化或 额外编程的要求。
开发阶段
完成设计以后的开发阶段是BI项目中占用大多数人工和时间的阶段， 在这个阶段项目将进行一系列的开发，比如ETL的开发，前端报表或 分析的开发，元数据管理，权限设臵等等。但是有意思的是，在这个 阶段最有难度的并不是具体的开发有如何的难度，最难以控制的是这 样一个问题：“我们开发的是否正是用户需要的？ 听上去这个问题不是应该在设计阶段已经解决的吗？没有错，设计阶 段应该要解决这个问题，通过理解用户的要求和源数据的状态。但是 相比于用户对于数据模型的无法理解，用户对于前端报表和分析的要 求通常是非常高，并且经常变化的。随着BI项目的进展，用户对于他 们想要得前端报表和分析的要求是在不断变化的，我们并不能通过一 个设计阶段就期望能够确定所有前端的需求。可以说，设计阶段只能 够给我们一个前端需求的基础版本，它的最终确定会随着项目的进展 而变化，而我们需要做的就是要不断地发现这些变化并在开发阶段更 新我们的设计来满足这些变化。
在这个阶段的陷阱通常是：
1.缺乏业务流程变更的准备和没有相应的资源
2.缺乏足够的用户培训和推广 3.在最后一分钟，对项目的需求进行修改
系统上线
系统上线阶段，不过这并不是BI项目的结束。BI 应用对企业来说不是一个或两个项目，而是一个 长期的实施和不断优化过程。系统上线阶段，除 了要对已经完成的项目进行总结和安排系统维护 的流程以外，重要的是应该重新来审视企业的BI 战略，调整长期的规划，预算下一阶段的项目。
SSRS等其它开发。这一步需要参与的人员可以灵 活来定，因为是需要一定的MDX经验，而且有可能 需要对团队进行报表开发培训。
数据验证，等同于测试的过程，观察统计出的 数据是否有异常，比如通过单个SQL查询的方式对 报表数据进行验证。如果出险问题，根据问题的 实际情况再去确认是哪个环节出的问题。
生产环境的部署
SQL SERVER BI项目实施过程中的四最
• 最关键的部分：维度建模，这里准确与否将决 定整个项目的成败，这里也最需要经验。 • 最有难度的部分：主题确认。对于业务复杂的 系统来说，这是一个需要时间的过程，而且需 要反复迭代。 • 最累人的部分:SSIS开发。SQL脚本工作比较多， 很累人，而且也需要耐心。 • 最需要的支持：客户最高领导，记住一定要是 说话好使的，遇到问题能当机立断的，否则项 目失败的危险很大
BI项目过程中产生的文档
• • • • • • • • • • • • • • • • 项目需求说明书(甲方提供) 初级数据质量评估报告 项目需求分析说明书 项目计划 数据仓库管理需求分析说明书 数据仓库模型设计说明书 数据仓库数据质量报告 数据采集需求说明书 数据采集程序设计说明书 项目OLAP系统设计说明书 报表设计说明书 项目业务需求测试简报 项目单元测试报告 项目集成测试报告 业务需求测试简报 培训计划
这里的陷阱就是： 1.认为BI实施已经结束 2.缺乏长期的规划
总结
BI项目的实施没有捷径，试图跳过以上的 关键阶段，盲目的压缩项目的时间和资源 都将不可避免的带来失败的危险。
微软BI项目实施的通用流程
首先，从报表下手可以很容易的掌握用户所 关注的东西，结合业务系统以及数据结构可以有 助于对主题有个大体的印象，同事对一些用户比 较关注的维度和度量才能有个概念。 但是理解业务是个需要经验和理解能力的过 程，不同行业都会有不同的特点，所以这里需求 人员和业务专家的参与就比较重要。另外同样也 不可忽视掉包括项目相关的文档的重要性。 前四个步骤要求一定是有BI经验人参与的。 这样看过报表以及系统后，对主题，度量维度等 才能有个大体的规划。试想如果连主题，度量维 度都不清楚为何物，那么此处根本无法进行，包 括后续的维度建模。
BI人员需要与业务开发人员协同制作开发数据增 量的方案，以配合SSIS的开发。还有一种比较好 的方法就是开发人员写SQL然后BI人员用BI的方法 将其整合到方案中，总之方法很灵活，关键的就 是跟开发人员的沟通。
SSAS开发，生成多维数据集，确认分区，增量等 操作，建议这里一定要符合SSAS的规范，命名约 定等，这样会给后续工作减少很多麻烦。
• 数据仓库管理程序使用手册
这个阶段可能的陷阱有以下这些：
• 缺乏高层领导的支持。BI的目标用户不同于ERP，它覆盖的面从高层 领导到一线员工都有，并且更侧重于管理层。他们可能是BI的最终用 户，并且直接介入管理层的日常工作。如果领导层不理解项目的意义 并支持项目的实施，将对项目产生巨大的不利影响。 • 没有制定BI的技术标准。BI的项目实施是一个长期的过程，分阶段来 实现，通常不会一个项目就解决所有的问题。因此在选择BI软件，硬 件，架构等问题上必须有长期的考虑，为企业制定可扩展的BI技术标 准是关键。 • 没有获得业务部门的资源支持。BI项目同ERP一样需要大量的业务部 门的资源，IT只能负责其中的一部分，业务部门必须承诺在项目中投 入相应的资源。
• 第三步:如果是维度建模在重点在检验模型对于缓慢 变化或快速变化的维度是如何解决的。如果是ER模型， 则需要考虑基于该模型的数据集市应该如何管理维度 的变化。最后应该尝试对模型使用相应的业务需求来 进行检验，通常可以通过提问回答的方式来检验（因 为此时前端和ETL还没有完成）。比如，提问：客户 需要产生月度的销售报表，并可以按产品进行分类。 回答：模型中已经包含了月度的销售聚合表，可以按 产品维度进行分析。