自由读 — 第三节、Y公司BI项目案例

某制造零售企业Y决定实施BI系统，初步的诉求是提高财务、经营等职能部门做报表的效率和质量，提升数据分析能力和决策效率。

由于我们本章主要是讲数字化再造过程中如何通过系统实现构想的，因此，前面招投标及商务的过程从简。本项目从策划到招投标，项目启动前大致经过了半年左右的前期准备，选择了内外部结合的咨询+实施的模式，外部聘请一线咨询团队，同时内部招聘具备一定潜力的员工参与到整个过程中，这样在外部团队撤场之后，内部团队能够成长为一支成熟的队伍，能够承接后续的持续优化、二开及运维工作。

方案阶段以外部团队主导，内部除了经营、财务等相关职线的主管之外，还从信息化部门选派了包含项目管理、流程优化、数据分析相关岗位的人员，配合外部团队并学习他们的方法和经验。方案完成后，由外部咨询方的战略合作伙伴深化系统设计并主导实施，内部组建开发团队一同实施，实施完成后承接后续二开及运维工作。

咨询阶段体现的正是对流程变革的过程。BI这类项目看似就是做报表而已，但实际上报表就是一个公司管理理念的集中体现，怎么获得数据、怎么看数据、怎么用数据，基本上将这个公司大多数的流程、系统串联起来，能够反映公司流程数字化的水平。

一、需求转化，企业痛点分析

该项目中，顾问团队在对企业高中基层大量员工进行了调研访谈。做过调研的读者会明白其中的难处，用户部门在表达系统需求时确实存在要么过于粗略，要么过于细致的问题。这种现象普遍存在，且对项目的成功实施有重大影响。

管理层往往关注大方向，对细节的东西不熟悉，对系统功能缺乏全面理解，需求往往提得过于“高层级”。这种需求表达可能导致最终系统无法满足“证明”是否满足了实际需求，容易造成需求的变更。

另一方面，具体的执行者又往往缺乏“流程思维”，经常专注于执行细节，对现有系统、流程，或者说行为习惯过度依赖，试图通过细节上的增增减减来解决自己手头上的问题。

比如下面是该项目当时调研某分公司得到的需求，

图表 60 某公司调研记录

发现：

 公司各部门存在大量的手工报表，表哥表姐们压力巨大，经常要应付临时、紧急、重要的报表要求

 IT人员经常要SQL取数，压力同样巨大

 原始数据质量差，数据获取后需要大量二次加工

 数据口径不统一，各部门同一个数据给出的答案不一样，影响经营决策

 中基层管理者需要快速对一线业务进行分析处理，但缺乏足够的数据

 高层和一些职能线一方面被过多的数据淹没，抓不住重点，另一方面又进场觉得没有数据，需要分析人员临时进行分析

这些问题互相关联，因为线上数据质量差，不得不需要表哥表姐手工二次加工；因为存在多人的、大量二次加工，不可避免存在口径不统一的问题；因为口径不统一，管理者面对不同的经营数据，却仍然难以做出决策。手工报表只够应付管理层的要求，顾不上满足中基层管理者，造成需要数据的人没有数据。

从上面的问题分析我们可以看出，我们BI项目要解决的不是“做报表”，而是如何给各级管理者提供有用的数据以帮助其经营管理。系统是管理的体现，是流程再造的落地载体。

从这一思路出发，我们首先回答的是，各级管理者在哪些方面需要数据辅助决策？经过一系列的调研分析，我们判断数据报表的需求集中在以下热点区域：

图表 61 Y公司管理“热区”

颜色块展示了不同业务线下的角色层次

在明确业务需求热点区域的基础上，进一步梳理得到用户所需求的报表的概要内容。

图表 62 Y公司报表主题规划

这样的需求对于系统开发来说还不够，我们还要明确每个报表中需要有哪些字段，如何展示等信息。因此，和业务人员进一步讨论，以表单的形式列出每张报表的需求。

图表 63 销售进度表规划设计

图表 64 库存分析表规划设计

这还没有完，还需要解决需求描述中关于指标字段的定义的问题。因此，接着，我们对指标进行梳理，解决口径方面的问题。

图表 65 指标管理中存在的问题及建议

具体的梳理结果以指标清单的形式体现，和各个相关部门讨论消除歧义之后确定下来。

系统上建设企业数据仓库，将各个业务系统中的数据，先按原来的样子集中到数据仓库中，然后对数据进行清洗、转换和整合,形成主题导向的数据集，最后再按照具体的分析需求，为用户和应用程序提供各种数据视图和接口。

为了建设这样的数据仓库，我们就需要在需求阶段提前设计。

图表 66 ODS层的主题设计（示例）

这个企业级数据仓库是之前没有的，在此基础上，又建设了BI系统，从DW中获取数据，快速的通过拖拉拽的方式生成报表。IT人员从临时的SQL取数工作，转为提供较为稳定的数据包；分析人员不再需要依赖IT人员先取数，通过BI工具能够更快的进行分析做出报表，从做报表慢慢向着真正的数据分析师发展；数据口径在数仓层面得到统一，只要是通过这套系统做出来的报表，数据口径一定是统一的；各级管理者明确了自己要看什么数据，报表需求从大量的临时性需求转变为以固定报表为主，临时报表为辅；报表真正被应用起来，报表和数据越来越有用。

这种新的报表的制作形式形成了业务和IT人员之间新的协作模式，为了保证开发和设计方面的协调，在需求/方案的阶段，项目组在开发开始前，制定了《BI开发及优化设计规范》，包括，

 模型规范化：通过严格的模型设计和命名规范，项目确保了数据的一致性和可用性。这使得用户在使用系统时能够更容易理解和访问所需的数据。

 报表界面标准化：统一的报表设计和数据展示方式提高了用户的操作效率和体验。标准化的界面元素和交互方式减少了用户的学习成本，使他们能够更快速地获取所需信息。

 部署规范：通过规范化的部署流程，项目确保了系统的稳定性和可靠性。这减少了用户遇到系统错误或不可用的情况，提高了整体使用体验。

 性能优化：项目在多个层面（Report Studio、Framework Manager、Transformer和Cube）实施了全面的性能优化策略。

这些优化措施显著提升了系统的响应速度和数据处理能力，使用户能够更快速地获取分析结果。以便提高开发风格和质量的一致性，改善系统的性能和可用性，从而提升了整体用户体验。

图表 67 业务需求转化至系统需求的逻辑示意

二、项目控制，计划做深做实

前期商务阶段，项目组通过综合评分方法，确定了本次项目的供应商，以及整体项目预算。这里并没有采用功能点等方法，因为业务需求此时还存在较大的不确定性，要做什么、做到什么程度、怎么做，这些问题，需要等到项目进场之后，在业务优化过后才能够基本确认，但是乙方的进场又需要合同的明确，因此，作为甲方，此时从业务价值出发，制定了项目的总体预算上限，后续成本控制转化为甲乙双方参与人员的范围和进度的控制和激励。

技术标