关注并将「大鱼的数据人生」设为星标
分享数据驱动业务的思想
业务部门会抱怨报表数据不够及时和准确，IT部门则会抱怨业务部门需求太多太急，这种矛盾在大部分企业都会存在，这些问题的解决不是仅靠资源的投入、技术的提升能解决的，往往涉及到企业组织、机制和流程等更深层次的问题。
今天就来跟大家聊聊如何提升做报表的效率。
1、组织优化：在业务部门建立小IT团队
业务部门提报表需求，IT部门实现报表需求的“授人以鱼”的传统支撑模式速度是很难起来的，因为管理成本太高（比如需求分析、流程审批、资源分配、运维调度等等），如果业务部门能自己进行报表开发，则可以从根本上解决问题。
业务部门不可能成为IT部门，但业务部门却可以拥有自己的小IT团队，从而自给自足的解决报表开发问题，这个在数据中台建立起来后变得非常现实。
数据中台可以为业务部门的小IT团队提供三种能力：数据仓库模型、开发工具和BI工具。其中数据仓库模型解决报表数据生成效率问题，数据开发工具解决业务人员操控数据的问题，BI工具解决业务人员设计和发布报表的问题。
中台确保了业务部门的小IT既不会导致IT系统的重复建设问题，也能给予业务部门足够的自由度和自主权。
现实中最大的挑战其实不在技术上，而是在观念上，让业务人员自力更生并不是那么容易，即使你提供了很好的平台或工具，但的确“在业务部门建立小IT”是很好的方法。
正如现在的HRBP一样，ITBP也该出现了。
2、业务归口：实现报表的集中管理
报表的口径混乱导致业务部门花费巨大的精力去核对数据，IT部门为了配合数据核对也需要投入巨大的成本，这是企业报表支撑效率低下的一个原因，我们不是在做报表的路上，就是在核对报表的路上。
报表口径混乱的根源当然不是IT问题，而是业务问题。公司的某个业务也许可以归口到某个部门管理，但并不代表这个业务的报表有了归口部门管理，任何跟这个业务相关的组织或个人都是有权利向IT部门提出该业务的报表需求的，这是成千上万报表产生的一个原因，也是口径混乱的根源。
比如集团总部要看省公司维度的的报表，而省公司要看地市公司维度，虽然大家关注的是同一个业务，但你会发现IT不得重复去实现一遍。
但只要有重复实现就会产生不一致问题，因为不同的组织或个人对于同一事务的理解肯定有偏差，特别是业务口径，一字之差，谬以千里，即使业务口径一致，实现方式的不同也会导致不一致。
企业与其花费巨大的精力去核对报表，还不如针对每个业务的报表去明确下归口管理部门，跟IT部门做个协同，比如不允许IT部门接收非归口管理部门的报表需求，在这个前提下IT部门去开展报表治理的工作才有些意义，否则垃圾还在不停的进来，怎么治？
现实中IT往往成了背锅侠，这是挺扯淡的事情，只能说IT在很多企业太弱势了，业务部门从来就不曾真正的解决问题，它永远是要求当下IT必须给我正确的数据，至于如何才能从根本上解决问题，下次再说吧。
3、指标统一：实现报表的中台能力
有了报表的业务归口的前提，才轮得上去谈技术的解决方案。有人总是强调指标的神奇作用，但如果没有业务管理上的支持，说用指标的方式来提升报表的开发效率也是美丽的泡沫，长远来讲难以坚持。
从纯技术的角度讲，报表都是由指标组成，只要指标能够标准化，理论上任何新增报表都可以由标准化的指标组装生成，这是典型的中台化的思想。可惜的是，指标不是功能，其牵涉的维度和粒度太多，变化太快，基于指标搭建的这个报表中台就有点脆弱。
报表的中台化实现方案可以参考阿里的的数据中台DATAPHIN，其对于指标的实现有严格的控制，但前提是需要公司顶层的支持，因为整个数据的支撑模式将发生巨大的变化，开始的时候成本是巨大的，而未来则是不确定的。
比如当业务人员提一张报表需求的时候，IT会先评估下是否有现成的指标可以支撑，如果没有，则要先实现这些指标，而为了确保这些指标的共享性，指标的设计和实现过程将花费