当10年BI老司机遇到烂需求、烂数据时，他做了这几件事…
IT人的职业生涯中难免会遇到烂项目。有些项目是你加入时就已经烂了，有些是自己从头开始亲手做成了烂项目；有些是从里到外的烂，以为工程浩大表面光鲜，实际跳进去才发现是个“焦油坑”；有些是还没烂，但问题已经很明显了，是个摇摇欲坠的“危房”……
BI作为IT项目的一个重要分支，自然也会有相似的问题，比如以下这位老哥的经历。
李哥才30多岁，一直在互联网混迹的他，抱着试一试的态度应聘了某知名服装公司的BI经理，惊喜的被录用了。正式上岗后，才发现接手的是个烂摊子，前任花了1年多做的BI系统看似满足了领导的所有需求，其实根本就是个摇摇欲坠的“危房”。
系统倒是挺全，ERP、MES、CRM该有的都有了。报表也挺丰富，从业务个性化需求报表到以各部门固定使用的查询报表，汇总报表。
但是，熟悉了几周，李哥发现BI系统上线了半年多，当初设计的报表浏览和使用量屈指可数，就连常规要求的月度经营分析和绩效考核必须从BI中取值这两点都没有实现，依然需要业务部门从各个系统中导出数据再自行计算统计。
另外，业务经常反馈业务系统与BI数据报表中相同维度的数据会出现的一些差异，会议上各部门争得面红耳赤，导致大家对BI数据的信任度严重下降。
而自己带得BI团队，7、8个人每天抱怨提过来的烂需求，不断地取数做报表，需求排到一个月之后，数据整合筛选、归类、分析全都得停留在各业务系统，只能低效的靠人工手敲成百上千行的SQL。
现在李哥反应了过来，为何自己能如此顺利的“捡漏成功”，原来是有一堆烂摊子：
数仓是搭建了，但底层的数据都没有处理好，指标口径对不上，导致最终做出来得报表数据质量一塌糊涂…
当初设想的各业务围绕经营和绩效的分析报表规划，但实际落实后业务仍就围绕个性需要提需求，且90%都是报表需求业务需求整理出来，只是报表需求，现在库里有1000多张报表…
另外，实时就不谈了，原本每天早上要看报表的，搞了个ETL和其他相关计算，报表一周才出，下面的人还得忽悠需求方，服务器性能不够、数据库系统内存太小…
报表也是，用了某开源工具，简单的都会，但一到极其复杂的多主题、复杂的统计就瞎了，业务的需求有时候比较怪异，非要把完全不相干的东西整到一张报表中，你还必须实现。工具实现不了，最后还是回到写SQL吧…
意识到当下要跑路已经来不及了，可是从头推翻公司整个BI规划又绝非易事，互联网做BI那一套一时难以套用，李哥陷入了僵局。
找出路还是得先诊断问题。李哥花了10多天时间走访调研各业务部门，管理层、业务基层，虽然收集了一堆问题和吐槽，但好在公司上下对BI的价值和信心度未垮，和组内小伙伴以及CIO多次研讨，决定改变眼下的实施思路，确定了下一步的优化方案。
1、首先，停下技术工作，重新梳理需求，重点放在数据质量治理上
第一个就是主数据的治理。也就是说企业经营管理过程会用到哪些主数据？这些主数据是如何产生、如何进行分发、会标记哪些维度形成派生主数据？随后在BI中单独搭建一个主数据中心库，抽取业务系统的主数据按照分类原则存放，并开发主数据一致性校验程序与主数据分发日志表。
第二个是指标梳理，建立指标体系。定义每个分析过程中的使用的业务指标，建立评价标准，以及计算方法，将业务管理逻辑进行更加直观的呈现，销售环节出现了数据波动就可以直观的呈现出来，通过指标的呈现，可以追踪哪部分业务发生的问题。
第三个就是规范数据产生的入口以及数据取值的出口的标准。明确所有数据的录入产生的作业标准，建立各个系统到BI的接口规范，公司现在经营活动中产生的几乎所有数据都要进数据仓库，并由BI系统统一进行数据抽取与数据加工。另外针对所有业务部提交的月度经营分析、绩效考核、日常管理分析的全部数据需求进行评估分析，搭建相应的数据模型，要求任何所有应用数据都从BI系统取值，有了入口与出口的规范才能保证数据的一致性与唯一性。
完成以上三个动作后，又简单编订了公司数据管理制度，定义了主数据产生、指标体系的结构与算法、数据录入与输出的标准等。
2、其次，建立信心，优先解决分析需求中的刚性需求，即真正的高优先级需求
先做好需求调研。需求实在是太重要了！此前的调研过于粗放，上线后暴露了不少问题，这一次调研基于以往再做了指标和分析点的补充以及口径的确认。
通过问卷和访谈形式对各业务部门经理进行了摸底，收集了他们对于报表的要求以及关心的指标。比如财务部门通过平衡记分卡的引入，希望能够得到他们平时的分析方法和关注点，来形成一个分析体系，最终财务部门也梳理出一条以现金流为主的价值链。另外后续访谈过程中，尽可能讲需求细化到取数口径、维度和度量级别粒度，并作好确认。
一个BI项目的重新启动需要杠杆。这个杠杆即是优先解决甚至遗漏用户企业分析需求中的刚性需求，即真正的高优先级需求。
调研过程中，财务部门的表现最为积极，一方面分析需求多，一方面财务也面临着高层质问的压力。并且财务作为公司的核心部门，对于IT来讲也是树立标榜的最佳队友。于是和财务部门展开了“深入合作”，梳理分析模型，开发了财务经营等多张分析型报表。。
另外，搞定顶层，管理者对公司经营指标最为关注，设计驾驶舱是一个重要手段。管理者透过驾驶舱与关键考核指标组合报表可以快速阅读自己的KPI指标以及关注和的经营指标的变化，因为每个管理岗位应该关注的什么内容在体系上梳理很清晰了。从公司经营决策者角度来讲，通过驾驶舱可以快速看到企业的业务全局，及时掌握公司的经营状况，通过数据钻取透视看到整体业务的变化过程。
3、上线成熟的BI报表工具，解决手工报表问题，重新梳理报表体系
报表是BI项目的最终呈现，最需要关注的是报表生成的效率和对需求的响应速度。开源工具虽然不要钱，但是对人的要求高。要看得懂一堆英文文档，对不能处理的需求能灵活的想到做接口开发或SQL处理，但能应付的人毕竟少数，7、8个水平参差不齐，低水平重复工作使得人员流失大，带人成本也就大了。需要把应付报表需求的能力依附在工具上。
这个环节不必省，毅然决然上了商用报表帆软FineReport，且报表分析体系、驾驶舱、以及数据的权限等问题，需要一个BI决策平台来承载，充当公司的经营数据门户。
制作上，finereport的的聚合报表制作模式基本解决了绝大部分的复杂报表开发，需求调整只需修改报表模板；另外，填报流程可用链接分享或者挂载到决策平台上处理，基本pass掉了手工Excel。整个操作层用户的工作效率提高了很多，大家都在一个频道，用同一种数据来源做汇报，再也不需要像过去需要临时加工一些乱七八糟的报表了。
另外，此前围绕不同业务主题规划了不同数据分析体系，层次上从低到高分为：业务基层报表（填报、查询类）——业务分析型报表（针对业务决策层）——经营管理决驾驶舱。将原本1000多张报表压缩到200多张报表模板，均用FineReport开发，然后挂载到finereport的数据决策平台上，形成了公司的数据门户，再配合平台本身提供的数据上报，流程审批，权限管理等一系列功能，形成了一整套完整的系统。
最终成果
至今公司的经营分析报表以及KPI考核的数据取值，都是由BI提供的，用户对BI系统的日常使用频率仅次于核心业务系统，平台日均浏览在3000多人次（公司1000多人）。公司的管理理念也发生了深刻的变化，从上至下不再用定性的语言表达，形成了用数据说话习惯。
END
立即沟通
