项目如何起死回生，BI系统老司机做了这几件事！
IT人一生中，烂项目一定是绕不过的坎。有些烂项目是你入手时就已经烂了，有些是自己亲手把项目做烂了；有些是金玉其外败絮其中，也就表面光鲜，里面其实已经烂透了；有些是还没烂，但已经在埋雷了，就等着哪一天会爆发。
BI系统也是IT项目的一个重要部分，当然也会有一样的问题，比如下面这位老哥的经历。李哥年方三十，却已经有多年混互联网的资历，他抱着碰运气的态度去应聘某知名服装公司的BI经理，意外的被录用了。当他蹦蹦跳跳去上班后，才发现这是一个大坑：前任花了一年多做的BI系统看似光鲜，符合领导期望，其实里面塞满了雷。
系统倒是看起来什么都有，MES、ERP、CRM也都有了。报表也还不错，很丰富，从业务个性化需求报表到部门查询报表、汇总报表也一个不少。
摸索了几周，李哥震惊地发现BI系统上线了半年多，系统报表浏览量和使用量寥寥无几，连月度经营分析和绩效分析报表取值自BI系统的规定都没法遵守下去，依然要业务部门自行采集数据自行分析，根本没有BI系统的事。
除此之外，工作人员经常反馈业务数据和BI系统报表中相同维度的数据有一些出入，这种问题造成了各部门之间的数据传递不畅和数据分析错误，导致了各部门之间的不睦和对BI系统报表的不满，也就没法用数据说话了。
而自己带的BI团队，每天都有七八人来抱怨，按各部门的烂需求反复取数重复报表，事务都得排到一个月之后，数据筛选归类和分析都只能靠业务系统，员工加班加点敲下成百上千行的SQL代码。
至此李哥终于明白了，为什么自己能顺利上位成功，原来是让自己来当冤大头：
数仓搭建是搭建了，但底层的数据都没有处理好，不符合指标要求，做出来的报表没人能看得懂…
当初设想的围绕各业务经营情况的绩效分析报表的计划，但完成计划后业务部门仍然以个别情况提需求，这些需求整理后发现其中90%都只是报表需求，然而库里有一千多张报表等着完成…
还有就是，连实时报表都做不到，本来要求每天早上要看报表的，但搞了ETL以及相关计算，都要一周才能出，下面还得找借口推诿：服务器计算慢，数据库内存不足…
再者就是开发报表，用了开源工具，简单的能应付得来，但到了复杂的多主题统计就手忙脚乱，有时候业务需求还特奇怪，非要把一些完全没联系的东西都塞进一张报表里，于是工具直接废了，结果还是只能靠加班加点写..
等他明白过来的时候就已经晚了，跑路不了，可推倒重做BI系统也难以如愿，互联网做BI那一套也一时用不上，李哥左右为难。
想要摆脱眼前的困境，还是得先抓住问题的中心。李哥花了十多天去了各部门，在管理层和业务层收到了一堆意见和吐槽，但公司上下还没失去对BI系统的信心，这给了李哥一根救命稻草。和组内小伙伴以及CIO反复讨论，决定改变策略，确定优化方向。
1、暂时放下技术工作，重新梳理需求，把重点放在提高数据质量上即数据治理
第一个就是主数据治理。也就是说要先知道企业管理过程中会需要哪些主数据？这些主数据是如何收集、如何进行分类、会标记哪些维度形成派生主数据？然后在BI系统中单独搭建一个主数据中心库，抽取业务系统的主数据分类存放在主数据中心库里，为此并开发主数据一致性校验程序与主数据分发日志表。
第二个是梳理指标，建立指标体系。定义分析过程中的用得到的业务指标，建立评价标准，以及计算方法，使业务管理逻辑得到更加直观的呈现，销售环节出现了数据波动就可以直观的呈现在员工面前，通过指标的呈现，业务员工可以追踪哪个业务环节发生的问题，业务员工之间也就可以用数据说话了。
第三个就是完善数据产生入口以及数据取值出口的标准。明确所有数据的录入产生的标准，建立系统到BI的接口规范，公司经营活动中产生的几乎所有数据都要放进数据仓库，并由BI系统统一进行数据抽取和加工。此外还要针对所有业务部提交的日常管理分析、月度经营分析、绩效分析报表的需求进行评估分析，搭建相应的数据模型，要求所有应用数据都是从BI系统取值，有了入口与出口的规范才能保证数据的一致性与唯一性。
完成以上三个步骤后，又简单编订修改了公司数据管理制度，定义了主数据产生方法、指标体系的结构与算法、数据录入与输出的标准等。
2、建立信心，优先解决需求中的刚性需求，即真正的高优先级需求
先做好需求调研。需求实在是太重要了！此前的调研过于粗糙，上线后破绽百出，问题频出，这一次调研借鉴了以前的经验，又做了指标分析和补充以及口径的确认。
通过对各业务部门的问卷和访谈形式对情况进行了摸底，收集了他们对于报表的需求以及关心的指标等各种意见。比如财务部门通过平衡记分卡的引入，希望能够了解他们平时的分析方法和要求，来形成一个分析体系，最终财务部门也梳理出一条以现金流为主的价值链。在后续访谈过程中，他们还要求尽可能将需求细化到取数口径、维度和度量级别粒度，并进行了确认。
要重新启动BI项目需要杠杆。这个杠杆即是优先解决用户企业分析需求中的刚性需求，即真正的高优先级需求。
调研过程中，发现财务部门响应热烈，呼声也最高，其实是他们一方面分析需求多，一方面也面临着高层责问的压力。而且财务作为公司的核心业务部门，对于IT来讲也是重新树立IB系统形象的最佳队友。于是和财务部门展开了“深入合作”，梳理分析模型，开发了财务经营等多张分析型报表，建立了数据门户，圆满完成了财务部门的需求。
下一步就是搞定高层，管理者最为关心公司经营情况，所以设计驾驶舱是一个打动管理层的很好的手段。管理者通过驾驶舱与关键考核指标组合报表可以快速了解自己公司的KPI指标以及所关注数据和经营指标的变化，因为每个管理岗位应该关注的内容在体系上有一目了然的显现。就决策层和管理层来看，通过驾驶舱可以快捷了解企业业务的全貌，及时掌握公司的经营状况，通过数据钻取透视看到整体业务的变化过程。
3、使用先进的BI报表工具，重新梳理报表体系，解决手工报表问题
报表是BI项目的最终成果，报表生成的速度和需求响应速度是最值得上心的。开源工具虽然免费，有利于削减成本，但是对业务员工的要求过高。员工不仅要能看得懂一堆英文文档，还要对难以处理的需求进行接口开发或SQL开发，所以能满足这些要求的人还是少数，其他人也是良莠不齐，低效率高压力的繁琐工作使得组内员工流失多，新人成本也越来越高。所以我们需要把针对报表需求的技术依托在工具上。
在思考良久后，我把目光投向了企业报表工具帆软FineReport，再说了报表分析体系、驾驶舱、以及数据的权限等事务都需要一个BI决策平台来承载，充当公司的经营数据门户。
FineReport的的聚合报表制作模式解决了大部分复杂报表开发难点，需求有变化时只需修改报表模板；另外，数据填报可用链接分享给别人或者挂载到决策平台上处理，基本pass掉了手工Excel录入。整个操作层用户的工作效率提高了很多，大家都在一个频道，用同一种数据来源做汇报，再也不需要像过去需要临时加工一些乱七八糟的报表了。
除此之外，我们也针对不同业务规划了不同数据分析体系，在层次上从低到高分为：业务基层报表（填报、查询类）——业务分析型报表（针对业务决策层）——经营管理决策驾驶舱。将原本1000多张报表压缩到200多张报表模板，均用FineReport开发，然后挂载到FineReport的数据决策平台上，形成了公司的数据门户，再配合平台本身提供的数据填报，流程审批，权限管理等一系列功能，形成了一套完整的系统。
最终成果
至今公司的经营分析报表以及KPI考核的数据取值，都是由BI系统提供的，用户对BI系统的日常使用频率仅次于核心业务系统，平台日均浏览在3000多人次（公司1000多人）。公司的管理理念也发生了深刻的变化，从上至下不再用定性的语言表达，形成了用数据说话习惯。当管理维度与经营业务发生变化的时候，也形成了通过数据治理体系来进行相应修订调整的习惯。
立即沟通
