企业BI项目蓝图规划建设方案
BI——商业智能，一个高大上的名字，一直被很多人认为是企业信息化中的“面子工程”。
什么是面子工程？“面子工程”是“形象工程”的意思，内含只做表面形象，不解决实际问题，在当今社会成为了一个贬义词。
01
BI是什么？
为什么会成为面子工程？
02
做好BI，
要从需求调研开始！
大致需求与详细需求
明确大致需求，就是要弄清楚当前企业中各方人员的痛点，找到必须建设BI项目的理由和共识，并确定项目范围。
由于不同行业的企业价值诉求点并不相同，因此在项目前期要注意收集和整理，多跟企业领导层、业务部门沟通，挖掘他们的关注点，弄清楚他们真正想要的是什么，再整理出项目的应用场景、功能需求、交互需求、管理需求，预估项目周期等。
BI项目成功与否，最终要看项目完成后企业能不能将它用起来。很多企业的BI项目之所以失败，就是因为没想清楚需求就开始建设，导致一步错，步步错，做出来的系统并不能解决企业的问题，甚至根本用不上，领导也会质疑IT部门的价值和BI系统的意义。
所以，上BI项目前，要准备好，瞄准目标再出发。
要大致了解BI系统是哪些部门用，用在哪些场景中，用了后能够带来多少价值，最好能带来企业整体业绩或者利润的提升（即有可见的、可量化的价值）。
有了大致的需求，就可以进行需求调研，收集和明确详细需求进行项目蓝图方案的设计了。
详细需求设计是对大致需求的深入和细化，要具体到可执行的粒度，例如每一个业务指标的分析与展示的维度和单位等。这个过程涉及业务、技术、数据等方面，需要通过细致的需求调研来完成。
总体来看，大致需求确定BI项目的核心价值和边界，详细需求确定BI项目的落地和验收，两者相辅相成，前者指明出发的本心，后者规范前行的里程碑。
需求调研的方法和步骤
收集和明确需求并非易事，尤其是挖掘需求方详细的、深层次的需求。
很多企业在做需求调研时，经常由于双方对问题描述和理解上的差异，使得需求在不断传递的过程中发生较大的偏差，最终开发出来的功能与原始需求大相径庭。
图1 需求的传递偏差
（1）调研业务部门分析场景
需求调研从三个层面展开：
首先是管理层面，主要调研与企业战略相关的指标分析需求，方法是将企业战略目标层层拆解到不同的层级。例如，将战略目标拆解到某个部门后，该部门就需要通过BI系统分析部门的KPI或OKR（Objectives and Key Results，目标与关键成果）、项目进度、部门业绩，以及人员各项指标的完成情况等。可以参考表1拆解企业战略目标，并进行分析和记录。
其次是调研业务部门在一些日常分析场景中的需求，可以通过表2进行收集。
在完成这些需求调研后，可以依据场景维度指标化与数据体系化的原则，对收集的所有场景需求进行总结。
（2）调研数据质量
数据质量的好坏是导致BI项目是否成功的最关键的因素。
企业中的数据按来源主要分为业务系统数据、手工数据、外部数据等。对数据质量的调研也从这三个来源展开，本质是梳理企业已有的数据。
对业务系统数据进行调研时，项目团队需要明确各业务系统对接人，获取相关数据接口和数据字典，若无法获取则需要协商，制订应对策略。
对于手工数据，项目团队可先行收集历史手工数据资料，此项工作可与业务部门的需求调研同步进行。
对于外部数据，可参考业务系统数据的调研方式，重点关注数据的可获取性和使用场景。
需要注意的是，在调研数据质量阶段，需要清晰地定义组织架构、用户及权限体系等项目的核心架构数据。其中，权限不仅包括模块功能权限，还包括数据权限，即不同的用户、角色能够看到哪些数据，例如城市销售经理能够看到所负责城市的销售数据，区域销售经理则能够看到所负责区域的销售数据等。
（3）设计、确认及修改数据体系
设计数据体系时主要考虑原始表和基础宽表两个层级，结合之前调研时所考虑的数据使用要求的最小粒度，以及分析中可能用到的维度、指标，尽可能做到对分析场景的全覆盖，满足各类数据粒度要求。
对数据体系的确认和修改主要包括数据维度、指标、粒度的增/删/改，字段含义及逻辑口径统一。
03
做好BI，
一定要做好蓝图规划！
好的项目蓝图规划能有效提升开发人效，缩短项目周期，实现项目预期目标。围绕项目蓝图规划，企业需要确定三件事：做什么、谁来做，以及怎么做。下面我们一一展开来谈。
做什么：确定项目范围
项目规划的第一步是根据项目需求和目的确定项目范围，这时在项目初期收集和明确的需求就派上用场了。对于项目管理者而言，只清楚项目范围的含义是不够的，最重要的是正确、清楚地定义项目范围。
如果项目范围划分得不够明确，会直接导致项目内容意外变更，有可能造成项目最终成本提高、进度严重延迟、偏离原定目标，以及影响整个项目发展和项目团队成员积极性等不良后果。
具体来说，项目范围包括组织、功能、业务、数据、接口等5个方面的范围。
（1）组织范围框定的是实施项目的主体，企业需要明确当期项目是否只需要在总部实施还是要在总部和所有子公司都实施，实施的内容又涉及哪些业务部门。
（2）功能范围指BI项目所包含的功能模块及具体功能。IT开发人员可以根据功能范围提前学习和掌握BI工具，在做开发时更有针对性、更高效。
（3）业务范围描述企业需要通过BI系统实现的日常业务处理和分析任务，主要对业务模块、分析应用、分析维度、分析形式等内容进行定义。
（4）数据范围包括数据源范围和数据关联规则等，其中数据源范围不仅描述数据来自哪里，还包括对源数据的理解、源数据质量保障、数据抽取等。表5给出了确定数据源范围的示例。
表5 确定数据源范围
谁来做：组建项目团队
项目团队是企业BI项目建设过程中的“大脑”，分工明确、配合有序的项目团队是项目成功的关键。
由于BI项目的建设涉及企业内部多个部门，需要高层管理者与业务部门的认同及参与，因此项目团队通常以几位企业高层管理者为核心，设立项目领导委员会来统筹整个项目，其他成员则由企业IT部门负责人牵头，与各部门对接人一起，设立不同的小组，全程参与BI项目的规划与实施。
项目团队的角色分为团队领导者、业务精通者、方案设计者、技术落地者等4类。每一类角色又可以进一步细分，例如技术落地者可以包括数据仓库（简称数仓）开发团队与应用开发团队等。
如果企业采用引入BI厂商或者外包商的方式来建设BI项目，就需要根据企业、BI厂商或外包商的实际情况来组建项目团队。不过需要注意的是，项目领导委员会都需要企业自己派遣成员设立，以保证对项目的整体把控。
怎么做：设计实施方案
项目实施方案是在项目开展后为规范项目开展过程而制定的指导性方案，它定义了项目的进度安排、业务和技术方案、关键产出、交付标准及各环节中可能需要的管控措施等，是项目实施过程的行动指南。主要包括3项主要内容，即项目计划、蓝图方案和项目管理方法。
1．项目计划
2．蓝图方案
前文提到，企业建设BI项目时需要收集和明确详细需求，蓝图方案是经过详细调研后拟定的具有实际指导意义的文档，可以将它理解为更具体的解决方案，即将解决方案中的各类框架细化到可设计、可执行的粒度。对蓝图方案有两大要求，即可行性与全面性。
可行性指蓝图方案的整体设计符合企业业务发展的需要，不能过于理想化，要考虑实施的难度。全面性则指项目团队不能局限于单个模块，而要在项目实施范围内解决企业的关键问题，并且考虑系统后续的可扩展性。
项目的蓝图方案一般包括3个部分，即整体方案、系统环境方案和详细方案。
（1）整体方案包括业务、技术和数据三个方面。
业务方案主要是基于业务需求分析结果，设计业务分析模型，例如财务和人力等部门的分析体系、美工特色、报表权限体系等，可直接提供业务系统原型供企业参考。一般的业务方案为：首先准备数据源接口；再到数据处理层，搭建基础数据平台和业务分析平台，梳理各个业务板块的内容；最后，搭建决策管理平台，通过报表、驾驶舱、移动端、大屏等多种方式展示数据，达到最终目标——信息共享、信息对称。
技术方案是支撑业务分析的整体技术框架，包括特殊技术预演结果、相关代码整合等内容。BI项目的技术架构一般如图3所示。首先，利用ETL工具抽取业务系统的明细数据，进行数据转换之后，载入企业数据仓库。接着，在数据仓库的基础上形成数据集市，用于企业不同主题业务数据的整合分析。最后，利用BI工具在不同门户与终端上实现仪表板、固定报表、自助分析等功能。
数据方案则包括对数据获取方式、数据血缘关系的梳理与描述，以及数据校对功能的设计、数据校对策略的制订等。
（2）系统环境方案描述软件环境、网络与服务器环境的配置要求。其中，软件环境包括客户端软件、BI应用、中间件、数据库管理系统及操作系统等。网络与服务器环境主要是参考BI系统的要求，描述ODS（Operational Data Store，操作数据存储）服务器、OLAP服务器、Web应用服务器，以及整个网络的配置情况。
（3）详细方案是在整体方案的基础上对每个模块的方案进一步细化，例如数据仓库建设方案、数据集成方案、数据补录方案、数据分析平台建设方案、多平台集成方案等。企业可以根据自身的需求，在技术、业务和数据方案上进行拓展。
以数据仓库建设方案为例，一般包括架构规划、数据模型、数据库灾备、扩展性方案等4个部分的内容。其中，在架构规划部分，需要明确数据仓库的建设理念和建设原则。
一般在设计数据仓库时，要遵循易用、实用、高可用、灵活扩展、可靠、可配置、安全等多项原则；同时，还需要对数据仓库的逻辑架构和技术架构进行规划。对于数据模型，一般情况下建议采用星型模型，雪花模型则适用于维度表数据量较大、业务逻辑较复杂，需要节省空间和分清层次的情况。
数据库灾备部分主要包含网络拓扑、硬件清单和集群等内容，用于确定数据库备份的方案以应对突发情况。另外，面对企业中激增的数据，在数据仓库的基础之上，需要用MPP等扩展方案来提高数据仓库处理海量数据的能力。
3．项目管理方法
04
做好BI，
还要管好开发和交付过程！
敏捷BI开发
敏捷BI开发（敏捷开发）有优点也有缺点，优点在于灵活应对需求变化，快速交付，其缺点也很明显，即需要牺牲一定的技术稳定性和美观性。
所以，企业在考虑开发模式的时候要想清楚，自身的需求是变化较快还是长期不变？如果是前者，则项目必须快速交付，如果是后者，则可以慢慢开发。
例如，绩效类项目就更适合敏捷开发，因为这类项目的需求一般变化频率都很高，如果在一个考核周期内没有完成开发，下一个周期需求肯定会发生变更。
企业领导临时提出的一些需求也是如此，由于是领导提出来的需求，IT部门一般会尽心尽力加班加点去实现，但最后开发出来的项目，领导可能用过几次就不用了。对于这种情况，如果采用敏捷开发，先满足领导的需求，等到后续项目功能被持续使用，再优化升级会更加高效。
项目风险管理
任何项目都存在不确定性，因此尽管有完美的规划做指导，但也不可不考虑不确定性带来的风险。对风险的管理以事前管理和事中管理为佳。
做项目规划时准确预测风险，实施项目时有效管控风险，都能够最大限度地避开风险或减小损失，保障项目最终落地。
就BI项目而言，风险一般存在于管理、需求、数据质量、原型、硬件环境等方面，如表8所示，表中也描述了相应的规避措施。
表8 BI项目风险及规避措施
类 别 | 风 险 | 规避措施 |
管理风险 | 项目中XX方组织松散，缺乏有效的协调和沟通，导致项目工作效率低下 | 需要公司领导密切关注，发挥强大推动作用，提高执行力，促进交流，提高效率 |
目标偏差：各级人员对项目目标的理解不一致，存在潜在第二目标 | 通过培训、交谈等方式进行互动，在对目标的理解一致后进行下一步行动 | |
业务人员不配合：业务人员工作繁忙，无法投入足够精力参与项目 | 项目实施期间，通过制度保证业务人员投入BI项目的时间 | |
需求风险 | 项目业务分析主题不明确，可能造成项目实施宽度和深度不确定 | ① 对各部门加强培训，组织内部讨论，协调资源，组建需求挖掘小组② 协调顾问，对业务进行梳理和引导 |
目标偏差：各级人员对项目目标理解不一致，存在潜在第二目标 | 通过培训、交谈等方式进行互动，在对目标的理解一致后进行下一步行动 | |
数据质量 | 数据来源：多数据源不一致、潜在的数据录入错误 | 加深对业务系统的理解，发现数据质量问题，提出合理的解决方案 |
类 别 | 风 险 | 规避措施 |
数据缺失：系统需要的数据无法获取或需要补录 | 通过完善业务系统、二次开发补录系统、直接补录等方式解决 | |
信息缺失：各业务系统管理软件的厂商无法提供数据源字典和技术上的支持 | 尽量获取技术支持，如果由于特殊原因无法获取支持，可以由熟悉业务系统的IT人员和实施小组共同解决 | |
控制失效：数据质量控制失效，业务系统负载过重，失去对脏数据来源的跟踪 | 设立业务系统隔离区，生成数据抽取批次日志，设立时间窗口，采取数据分区控制 | |
原型风险 | 原型设计：对业务理解不足，验收模型的基础维度和指标设计偏离正确方向 | 通过培训加强双方对业务的理解，以及对维度模型设计方法的理解 |
原型验证：过于关注报表样式而忽略业务含义，忽视对多维模型结构的验证 | 明确验证任务，划定讨论范围，讲解模型逻辑 | |
硬件环境 | 目前机房、网络及服务器的实际情况不是很理想 | 在当前条件下，优化机房资源和网络，努力保证服务器性能 |
需求变更管理
项目需求与项目风险类似，前期做的需求分析再完善，受到众多不确定因素的影响，项目需求也很难保证一成不变，因此项目实施过程中经常会遇到需求突然变更的情况。
既然需求的变更不可避免，应对的关键就在于对变更进行更有效的控制，若控制不当会对整个项目的进度、成本、质量等产生较大影响。
需求变更管理同样要求项目团队事先做好规划，避免需求变更时没有完善的应对方案而影响项目整体的进度和质量。在发生需求变更时应及时做好管控。
通常情况下，需求变更要经过变更申请、变更评估、决策、回复等4个步骤，若变更申请通过则需要增加实施变更和验证变更这两个步骤。
需要注意的是，变更需求时一定要先申请再评估。对于发生变更的需求，首先需要识别其是否在既定的项目范围之内。如果变更在项目范围之内，项目团队应评估变更所造成的影响，并将信息传达给受影响的各方人员，然后再根据影响程度决定是否变更。若确定变更，就制订相应的应对措施，解决变更的需求。如果变更在项目范围之外，项目团队就需要与用户进行沟通和谈判，讨论是否增加费用或放弃变更。
项目验收管理
推荐阅读：
不是你需要中台，而是一名合格的架构师（附各大厂中台建设PPT）