BI项目的实施过程.pptx

BI项目的实施过程.pptx

《BI项目的实施过程.pptx》由会员分享，可在线阅读，更多相关《BI项目的实施过程.pptx（27页珍藏版）》请在冰豆网上搜索。

BI项目的实施过程BIBI项目实施的方法论与过程项目实施的方法论与过程当前各家BI的软件厂商都有各自不同的BI实施方法论和过程，他们大多大同小异.这里以SAPBW的实施方法论和微软BI通用流程为例，来阐述BI项目实施的基本过程和需要注意的事项SAPBISAPBI项目实施的大致流程项目实施的大致流程项目计划和准备项目计划和准备在项目准备和计划阶段，考量项目是否已经“万事俱备”可以从3个方面入手。

用户需求是否清楚？

是否已经明确BI的技术标准？

业务部门是否有所准备？

在这3个方面中尤为重要的是:

用户需求是否清楚用户需求是否清楚。

实际情况是用户在开始阶段并不能完全清楚自己需要什么实际情况是用户在开始阶段并不能完全清楚自己需要什么,可能会在可能会在以后的过程中修正自己的需求以后的过程中修正自己的需求,故在设计阶段需要充分考虑到扩展性故在设计阶段需要充分考虑到扩展性.但一些主要的需求必须要在项目计划阶段搞清楚但一些主要的需求必须要在项目计划阶段搞清楚缺乏高层领导的支持。

BI的目标用户不同于ERP，它覆盖的面从高层领导到一线员工都有，并且更侧重于管理层。

他们可能是BI的最终用户，并且直接介入管理层的日常工作。

如果领导层不理解项目的意义并支持项目的实施，将对项目产生巨大的不利影响。

没有制定BI的技术标准。

BI的项目实施是一个长期的过程，分阶段来实现，通常不会一个项目就解决所有的问题。

因此在选择BI软件，硬件，架构等问题上必须有长期的考虑，为企业制定可扩展的BI技术标准是关键。

没有获得业务部门的资源支持。

BI项目同ERP一样需要大量的业务部门的资源，IT只能负责其中的一部分，业务部门必须承诺在项目中投入相应的资源。

在项目准备阶段没有相应的咨询公司的参与。

大多数的企业对于BI应用的认识仍然处于相对初级的阶段，因此在项目准备阶段就选择咨询公司并让他们参与规划对项目的实施有重要的意义。

这个阶段可能的陷阱有以下这些：

这个阶段可能的陷阱有以下这些：

设计阶段设计阶段设计阶段是BI项目最重要的阶段，其重要性甚至超过了具体的开发阶段。

该阶段大致需要覆盖以下方面：

设计阶段的注意事项设计阶段的注意事项本阶段中的关键的关键是业务分析和模型设计应该如何展开业务分析？

应该如何展开业务分析？

业务分析事实上包括了两方面，源系统分析和用户需求分析。

以下图示是比较通用的业务分析方式：

业务分析人员应该同时从用户需求和源系统两端业务分析人员应该同时从用户需求和源系统两端同时展开分析，并且其中的重点在于源系统的数同时展开分析，并且其中的重点在于源系统的数据据,是最终该是最终该BIBI应用可以满足多少用户需求的必要应用可以满足多少用户需求的必要条件。

一个好的业务分析应该在充分理解源系统条件。

一个好的业务分析应该在充分理解源系统数据的基础上，不但能满足用户的需求，并且能数据的基础上，不但能满足用户的需求，并且能超越或预见用户未来可能的需求从而予以相应的超越或预见用户未来可能的需求从而予以相应的考虑。

考虑。

如何进行模型设计如何进行模型设计业务分析所产生的文档将直接指导数据仓库的模型设计。

模型设计与业务分析经常是同一个人来负责，但也因此对建模师的要求抬高了。

目前数据仓库建模基本上有两种模式，一种是BillInmon所首先提出的ER模型，另一种是Kimbal的维度建模方式。

数据集市一般都是维度建模的（也叫星型模型）。

也有将这两种模型混合使用的。

如何验证所建模型的好坏如何验证所建模型的好坏客户经常反复检验的是报表或分析的质量而非常少的来检验模型的质量。

殊不知，模型的好坏很大程度上将影响前端分析的质量，系统的速度，ETL开发的难易等一系列的问题。

可见，检验模型质量是如何重要了，但是目前而言还没有一个业界公认的标准方法和流程来检验模型的质量。

下面是一个经常用到的方法:

第一步：

如果是ER模型则首先应检验是否所有的实体表已经在模型中正确的建立了。

比如，项目包含了销售主题的分析，那么销售相关的实体表是否已经包含在了模型中？

（假设发现销售订单表或客户表没有包含，那么显然有问题）。

如果是维度建模，那么总是首先确认是否所有的维度表已经明确。

接下来，就要检验实体表之间的关系（ER建模）或维度和事实表之间的关系（维度建模）。

第二步:

如果是维度建模那么检验事实表和粒度是相当.显而易见，如果是ER建模同样要检验是否在ER模中包含足够细的数据粒度。

同时在这一步中可以检验是否因为系统性能优化的需求而进行了相关的设置，比如增加了某些聚合表，或进行了索引的优化，或进行了分区等等。

第三步:

如果是维度建模在重点在检验模型对于缓慢变化或快速变化的维度是如何解决的。

如果是ER模型，则需要考虑基于该模型的数据集市应该如何管理维度的变化。

最后应该尝试对模型使用相应的业务需求来进行检验，通常可以通过提问回答的方式来检验（因为此时前端和ETL还没有完成）。

比如，提问：

客户需要产生月度的销售报表，并可以按产品进行分类。

回答：

模型中已经包含了月度的销售聚合表，可以按产品维度进行分析。

设计阶段可能的陷阱设计阶段可能的陷阱在用户需求分析和设计的时候没有同时从源数据和用户需求出发忽略了架构设计忽略了对数据模型进行检验的重要性数据建模时没有对缓慢变化和快速变化的维度进行适当的处理为满足用户需求在前端设计时加入了过多的客户化或额外编程的要求。

开发阶段开发阶段完成设计以后的开发阶段是BI项目中占用大多数人工和时间的阶段，在这个阶段项目将进行一系列的开发，比如ETL的开发，前端报表或分析的开发，元数据管理，权限设置等等。

但是有意思的是，在这个阶段最有难度的并不是具体的开发有如何的难度，最难以控制的是这样一个问题：

“我们开发的是否正是用户需要的？

听上去这个问题不是应该在设计阶段已经解决的吗？

没有错，设计阶段应该要解决这个问题，通过理解用户的要求和源数据的状态。

但是相比于用户对于数据模型的无法理解，用户对于前端报表和分析的要求通常是非常高，并且经常变化的。

随着BI项目的进展，用户对于他们想要得前端报表和分析的要求是在不断变化的，我们并不能通过一个设计阶段就期望能够确定所有前端的需求。

可以说，设计阶段只能够给我们一个前端需求的基础版本，它的最终确定会随着项目的进展而变化，而我们需要做的就是要不断地发现这些变化并在开发阶段更新我们的设计来满足这些变化。

开发阶段的陷阱大致有如下这些：

开发阶段的陷阱大致有如下这些：

1.缺乏项目变化控制流程2.缺乏项目质量控制尤其是数据质量监控3.在开发阶段没有让最终用户参与让最终用户参与开发，目的就是要及时反馈用户对开发结果的意见，并通过项目变化控制流程来决定是否要改变设计文档以反映最新情况。

问题是如何才能有效地来让最终用户参与？

同步开发，分步验收同步开发，分步验收在这种开发方式下，ETL队伍和前端开发队伍需要协同工作，将所有的开发需求先分成几个组，每个组包含开发前端所需要的ETL。

如此，前端开发团队就无需等待ETL团队开发完所有的ETL才进行开发。

当前端团队开发完第一组前端报表时，ETL团队就可以配合加载真实数据，这个时候就可以让最终用户马上参与进来检验前端报表是否符合他们的需求，以及数据是否正确。

这种开发方式的最大优点就是，它减少了在测试阶段用户有可能提出的需求变更，并增加了用户对项目结果的信心。

测试和部署阶段测试和部署阶段测试和部署阶段最重要的任务是检验整个项目的结果。

大致有以下的关键点：

除了集成测试以外，需要特别指出的是性能优化和业务流程重组是容易被忽略的部分。

特别是业务流程重组，普遍的误解在于BI项目由于其产出是报表和分析，不同于ERP，似乎不涉及业务流程变化。

其实不然，BIBI项目的根本目的不在于仅仅产出报表，重点是项目的根本目的不在于仅仅产出报表，重点是通过使用通过使用BIBI应该如何优化企业的决策流程。

应该如何优化企业的决策流程。

也就是说，有了更多更强大的数据和分析，应该如何改变企业的行为？

比如，销售经理应该通过BI的分析来指导他的销售员进行具体的销售活动？

每周或每月的销售会议在有了BI之后应该如何改变以最大化的利用BI在这个阶段的陷阱通常是：

在这个阶段的陷阱通常是：

1.缺乏业务流程变更的准备和没有相应的资源2.缺乏足够的用户培训和推广3.在最后一分钟，对项目的需求进行修改系统上线系统上线系统上线阶段，不过这并不是BI项目的结束。

BI应用对企业来说不是一个或两个项目，而是一个长期的实施和不断优化过程。

系统上线阶段，除了要对已经完成的项目进行总结和安排系统维护的流程以外，重要的是应该重新来审视企业的BI战略，调整长期的规划，预算下一阶段的项目。

这里的陷阱就是：

1.认为BI实施已经结束2.缺乏长期的规划总结总结BI项目的实施没有捷径，试图跳过以上的关键阶段，盲目的压缩项目的时间和资源都将不可避免的带来失败的危险。

微软微软BIBI项目实施的通用流程项目实施的通用流程首先，从报表下手可以很容易的掌握用户所关注的东西，结合业务系统以及数据结构可以有助于对主题有个大体的印象，同事对一些用户比较关注的维度和度量才能有个概念。

但是理解业务是个需要经验和理解能力的过程，不同行业都会有不同的特点，所以这里需求人员和业务专家的参与就比较重要。

另外同样也不可忽视掉包括项目相关的文档的重要性。

前四个步骤要求一定是有BI经验人参与的。

这样看过报表以及系统后，对主题，度量维度等才能有个大体的规划。

试想如果连主题，度量维度都不清楚为何物，那么此处根本无法进行，包括后续的维度建模。

模型验证，根据已建立的维度模型验证是否能满足所有的报表需求。

同上，此步骤必须要有BI经验的人做。

如果模型满足不了统计的要求则重新建模。

这里是需要一个反复迭代的过程，每次迭代的结果都要沉淀下来并且形成文档。

反向确认数据仓库结构，手动或者系统自动均可，自动生成来说SQLServer从2005就已经支持了，不过为了命名规范，还是手动来生成数据仓库比较有必要。

分析数据来源及SSIS开发。

最好是由相关模块的开发人员参与，因为开发人员是对数据结构比较了解的，并且有SQL功底，而且还掌握业务。

这一步的目的是填充数据仓库。

可能需要适当SSIS培训。

不过，这一步公认是最耗时的。

同时，不是所有的统计项就是能从业务那边解释的了的，比如某些统计概念，可能在业务系统从来就没出现过，但是通过基本数据组合都可以计算出来。

所以类似概念，确认计算公式等就需要BI人员承担起需求的工作去确认。

BI人员需要与业务开发人员协同制作开发数据增量的方案，以配合SSIS的开发。

还有一种比较好的方法就是开发人员写SQL然后BI人员用BI的方法将其整合到方案中，总之方法很灵活，关键的就是跟开发人员的沟通。

SSAS开发，生成多维数据集，确认分区，增量等操作，建议这里一定要符合SSAS的规范，命名约定等，这样会给后续工作减少很多麻烦。

SSRS等其它开发。

这一步需要参与的人员可以灵活来定，因为是需要一定的MDX经验，而且有可能需要对团队进行报表开发培训。

数据验证，等同于测试的过程，观察统计出的数据是否有异常，比如通过单个SQL查询的方式对报表数据进行验证。

如果出险问题，根据问题的实际情况再去确认是哪个环节出的问题。

生产环境的部署SQLSERVERBISQLSERVERBI项目实施过程中的四最项目实施过程中的四最最关键的部分：

维度建模，这里准确与否将决定整个项目的成败，这里也最需要经验。

最有难度的部分：

主题确认。

对于业务复杂的系统来说，这是一个需要时间的过程，而且需要反复迭代。

最累人的部分:

SSIS开发。

SQL脚本工作比较多，很累人，而且也需要耐心。

最需要的支持：

客户最高领导，记住一定要是说话好使的，遇到问题能当机立断的，否则项目失败的危险很大BIBI项目过程中产生的文档项目过程中产生的文档项目需求说明书（甲方提供）初级数据质量评估报告项目需求分析说明书项目计划数据仓库管理需求分析说明书数据仓库模型设计说明书数据仓库数据质量报告数据采集需求说明书数据采集程序设计说明书项目OLAP系统设计说明书报表设计说明书项目业务需求测试简报项目单元测试报告项目集成测试报告业务需求测试简报培训计划数据仓