从一个BI项目的失败，看到数据治理的重要性

编辑导语：BI项目主要分为3个部分：梳理需求、技术设计、实际开发，每个部分都有一个项目里程碑；所以项目组和业务人员之间的关系非常重要，BI项目经理要协调各方关系，才能顺利进行；本文作者分享了从一个BI项目的失败看数据治理的重要性，我们一起来看一下。

很多企业在做BI项目时，一开始的目标都是想通过梳理管理逻辑，帮助企业搭建可视化管理模型与深化管理的精细度，及时发现企业经营管理中的问题。

但在项目实施和验收时，BI却变成了报表开发项目，而报表的需求往往和个人习惯有关；一旦人员发生变动，尤其是新入职的高层，会把前公司的内容搬过来，这就需要重新开发一大堆报表。

如果不从源头进行控制，被动服务模式下的IT不可能满足所有人的报表需求。

接下来我们要讲的这个案例就真实反应了这个过程，同时也为大家解析问题产生的原因并找到解决问题的方法，建议所有有计划或已经实施BI项目的企业，认真阅读本文。

01

2011年底至2012年初，笔者在某女装公司组织实施BI系统，项目第一期就花了100多万，长达6个月的周期，经历了业务需求调研、数据清理、指标体系梳理、数据模型构建等等一系列中规中矩的项目实施过程。

从业务个性化需求报表到以经营指标为导向的数据模型、数据驾驶舱等等，在项目组看来，除移动化展现，几乎覆盖了当前所有业务需求；在多次宣导并召开上线动员大会后，BI终于正式运行了。

然而现实却给了项目组一个响亮的耳光，在BI系统上线后，3个月内不仅使用次数屈指可数，就连最初要求的月度经营分析和绩效考核必须从BI中取值这两点都没有实现，依然需要业务部门从各个系统中导出数据再自行计算统计。

第一期项目很快就被宣判失败，这让整个项目组深受打击，实施方法论是没有问题的；也针对上述状态的可能性做了很多短期过渡的报表，还有最大自由定义的万能报表，但最后用户们依然不满意。

这究竟是什么原因呢？

02

项目组进行反思，并用一周时间去做了用户调研，进行深入地讨论总结。

1）大部分用户反馈BI系统操作缺乏便利性，使用起来特别麻烦；因为每个用户只需查看自己日常工作的数据即可，这第一期BI系统实施把所有业务特性进行了归纳，按照其基础职能设置指标组合与自主选择的时间跨度栏位。

用户因此产生一个印象就是需要的报表全部堆砌在一起，你需求什么自己去找，而且部分派生指标取值需要重新计算后产生，报表展现的效率低下，BI操作起来就很痛苦。

其实每一项体系既要有决策层的视角，也要有管理层的视角，虽然按照操作层的指标体系与时间自定义几乎涵盖一切，但这样并没有针对每一个岗位进行相应的配置；要想得到用户认可，首要要素需要满足各层级用户在某一时间周期内的数据所见即所得

2）指标体系的管理逻辑梳理不清晰，需要用户凭经验去寻找数据背后的逻辑；BI的价值是提升管理的精准度，通过数据构筑一个企业管理模型。

BI系统实施的最大能力就体现在如何梳理管理逻辑，帮助企业可视化展现管理模型与管理的精细度。

3）主数据定义的一致性问题，用户经常反馈业务系统与BI数据报表中相同维度的数据会出现的一些差异，导致大家对BI数据的信任度严重下降。

综合上述调研的问题，项目组征得公司信息决策委员会的同意，于2012年8月启动了第二期的BI系统实施；项目组经过商讨决定改变实施思路，先暂停技术性工作，首要任务是进行公司的数据治理。

03

那么数据治理要怎么开展呢？

第一个就是主数据的治理，也就是说企业经营管理过程会用到哪些主数据？这些主数据是如何产生、如何进行分发、会标记哪些维度形成派生主数据？

随后在BI中单独搭建一个主数据中心库，抽取业务系统的主数据按照分类原则存放，并开发主数据一致性校验程序与主数据分发日志表。

第二个是指标的梳理，建立指标体系，定义每个分析过程中的使用的业务指标，建立评价标准，以及计算方法；将业务管理逻辑进行更加直观的呈现，销售环节出现了数据波动就可以直观的呈现出来，通过指标的呈现，可以追踪哪部分业务发生的问题。

第三个就是规范数据产生的入口，以及数据取值的出口的标准；明确所有数据的录入产生的作业标准，建立各个系统到BI的接口规范，企业经营活动中产生的几乎所有数据都要进数据仓库，并由BI系统统一进行数据抽取与数据加工。

另外针对所有业务部、职能部提交的月度经营分析、月度绩效考核、年度关键考核指标、日常管理分析的全部数据需求进行综合评估分析；搭建相应的数据模型，要求任何所有应用数据都从BI系统取值，有了入口与出口的规范才能保证数据的一致性与唯一性。

04

完成上述三个动作后由项目组协同企管部门编撰公司数据管理制度，进行全公司范围的发文；数据管理制度定义了主数据产生、指标体系的结构与算法、数据录入与输出的标准等，是一项公司完整数据管理规范。

发文同时还明确了公司数据治理小组的组织架构与职能，治理数据小组有4种角色：

• 数据操作员，是业务部门的操作人员，主要发起主数据的调整、BI系统的维护、指标体系的修改申请等等；
• 数据审核主管，往往是部门领导；每个数据是由不同部门负责的，首先由数据操作员提出第一级的申请，其次是数据负责的部门进行审核；
• 数据的分析员，他对数据审核主管的审核进行分析，看修订的要求是否合理？是否影响其他主数据、指标和数据模型；
• BI系统的管理员，经过审批审核后修订要求必须由系统管理员操作才能进行调整，即使这样每隔一个时段还是会有很多业务指标需要调整；比如新的业务出现或是新业务发生变化，甚至要调整公司组织架构，这个流程申请就是项目管理形式进行。

公司OA中也配置相应的三个流程：

• 主数据的修订流程；
• 管理指标和KPI指标调整的流程；
• 报表优化的流程。

通过数据治理实施过程，IT团队的数据中心部门基本实现公司数据的统筹工作，整体上也形成了PDCA的循环。

05

数据治理进行了一个月时间后，项目组又重新针对BI系统进行了优化，关键点有以下几个：

梳理业务分析体系：先从纯业务角度总结和梳理，分析各个业务中的流程和思路、常用角度、导向、评价标准，以及业务背后的原因；此体系的建立，是业务分析的总览，也是业务流程环节的真实需求，为后续的指标体系、系统实现打下基础；同时在业务分析体系建立的过程中，收集分析业务、数据的痛点和需求。

重新整理分析需求：根据收集的需求，业务分析的流程和思路，以及系统中的报表进行匹配和提炼，形成新的分析需求。

针对公司零售业务的变化特性，以月度为单位记录业务调整导致的指标比重系数发生调整和变化的历史数据，比如新店变成次新店、次新店升级为老店的时间维度差异。

将指标体系的业务管理逻辑进行更加直观的呈现，销售环节出现了数据波动就可以直观的呈现出来，清楚的知道到底是哪部分业务发生的问题。

更加细致精准划分管理层级的数据展现，针对业务操作层的用户也可在日常应用、周度汇报、月度绩效、年度关键指标上进行数据的直观呈现，所见即所得；虽然开发工作量增加，但是用户体验直线上升。

06

公司的管理理念也发生了深刻的变化，从上至下不再用定性的语言表达，形成了用数据说话习惯；当管理维度与经营业务发生变化的时候，也形成了通过数据治理体系来进行相应修订调整的习惯。

IT团队的数据中心部门设置5个岗位：

• 数据中心经理负责管理工作；
• 数据分析师负责数据模型的设计以及指标的分析；
• 有两个BI系统开发师负责数据仓库维护与数据模型开发；
• 一个H5开发工程师负责移动端开发。

07

从整个BI项目的实施价值上来讲，有这样几点内容可以分享：

从公司经营决策者角度来讲，通过驾驶舱可以快速看到企业的业务全局，及时掌握公司的经营状况，通过数据钻取透视看到整体业务的变化过程。

经营层面出现的任何问题，都能透过数据预警反馈到业务管理逻辑上，也非常容易找到关联的业务动作，也就是哪些业务出现了问题。

管理者透过驾驶舱与关键考核指标组合报表可以快速阅读自己的KPI指标以及关注和的经营指标的变化，因为每个管理岗位应该关注的什么内容在体系上梳理很清晰了。

数据仓库，通过建立数据仓库，进行企业的数据治理，将企业的数据打通，形成可以分析和复用的数据资产。

整个操作层用户的工作效率提高了很多，大家都在一个频道，用同一种数据来源做汇报，再也不需要像过去需要临时加工一些乱七八糟的报表了。

BI系统第2期的实施大大丰富了IT团队的知识结构，尤其是数据中心团队的归纳总结、分析问题以及对公司主营业务的认知和理解能力有很大进步；也让业务部门清楚地认识到IT对企业管理的价值，更加配合今后信息系统的实施与部署，IT部门的影响力得到了直观体现。

 

作者：商业智能研究，专注企业数据化运营和数字化转型，公众号：商业智能研究，分享有关企业数据建设的一切知识！

本文由 @商业智能研究 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。