如何实施有效的报表治理？

自己以前是个表哥，虽然现在不做了，但对于报表很有感情，今天就跟大家聊聊报表治理吧。

数据质量是报表的生命线，任何一个企业的报表在发展到一定阶段后，都会出现一系列不可用问题，包括报表体系混乱、报表口径不一致、报表口径不透明、报表冗余度不断加大等等问题，报表系统是典型的熵值不断增加的系统。

在报表越来越多，越来越复杂的同时，报表的边际效应却越来越低，存在典型的2/8现象，甚至比这个情况更严重。

一般公司的报表之所以不会有什么大问题，往往是以大量报哥的血泪付出为代价的，很多人耗尽了自己的职业生涯，但大多是在补数据管理不完善的坑。

什么叫做管理不完善？

举个例子，假如公司没有明确谁是报表体系的管理者，报表的分类就会乱七八糟，报表的使用门槛就会变得很高。

假如没有明确报表归属责任人，意味着这个报表对应的指标口径就会缺乏权威性，不一致现象马上就会出现，这些都是问题的根源。

公司可以躺倒不作为，报表的混乱大多时候要不了公司的命，因此如果要自救，表哥一般自己先要站出来，主动去推动数据治理项目的实施。

这里讲一个自己很久以前对流量报表体系进行治理的一次尝试，希望大家能从这个案例获得启示。

数据治理一般都建议公司组织先行，但实际大多数企业是很难具备条件的，因为这种事情在公司看来都是小事。

跟你说个笑话，IT系统运维你如果从来不出事，可能公司会认为理所当然，对你的重视程度甚至会下降，哪天你顶不住了突然跑出来向公司说我要钱提升运维自动化水平，可能公司还不太认可，原来不是好好的吗。

报表其实也会陷入这样的困境。

在这个案例中，并没有推进什么公司级组织保障，只是找到相关的核心业务人员（有某一类报表的话语权），阐明做这件事情的价值，获得认可后就可以做了，只要人家不反对，就有治理的可能，这也是一种组织的保障。

当然你一定要努力打造出一种双赢的局面，不能光说给IT带来了多大的价值，比如降低了多少冗余，减少了多少运维人员投入，这个其实跟业务人员没有关系，你得说我给你带来了多少好处。

1、报表体系梳理

整个公司的存量报表体系往往非常庞大，很难毕其功于一役的进行梳理，因此一定要限制治理的业务范围，比如我们原来有市场经营、政企业务、全业务、数据业务、客服服务等10大类报表，本次就选择了公司最为关注的市场经营下的流量经营报表为试点治理的对象，如下图所示：

为了进一步缩小范围，还需要对当前存量的流量经营分析报表进行点击量等的分析，对于无访问或访问量极低的报表进行下线，减少后续的梳理工作量，如下图所示：

报表体系治理的前提是理解好业务，比如流量经营业务总体上将用户的上网行为区分为无线上网和有线上网（有线宽带），无线上网中区分WLAN和移动数据流量，移动数据流量包括手机上网、数据卡、上网伴侣和物联网等业务，业务的具体分类如下：

在理解业务的基础上，我们才能抽象归纳出符合业务实际的分类体系，如下图所示，我们把报表划分为三大类，综合分析、产品分析和专项分析，综合分析侧重基本面，只保留基本的分析维度，产品分析和专项分析侧重对业务的某一角度进行深入分析。

笔者一直的观点是：IT要比业务往前多走一步，虽然不能说IT能比业务更懂业务，但IT的逻辑一般会更严谨一点，因此去梳理报表体系是很自然的事情。

你当然可以一厢情愿的让业务人员去梳理这个体系，但因为业务一般不会配备专门的报表人员，因此能投入的精力也是极其有限的，而作为表哥的你，或者作为管理表哥的你，报表可能就是全部。

现在有种ITBP的说法，就是IT前置到业务部门，我觉得蛮好，既然屁股大多时候能决定脑袋，那就挪一下吧。

2、标杆指标提炼

报表要解决口径一致性问题，核心就是指标体系的标准化，因此需要通过梳理、归纳、总结出报表所含指标特征，提炼共性数据指标，并树立标杆指标，也就是共性指标。

当然存量报表还存在大量难以标准化指标的个性报表，这个可以保留，但需要跟共性指标分开管理，不要搞什么一刀切，那是不可能的，下图是梳理指标的示意：

指标的标准化包括口径的统一，你需要对于模棱两可的指标进行鉴别，比如以下是关于移动数据流量和忙闲时流量的定义：

移动数据流量定义：移动数据流量是指GPRS协议上网，不包括WLAN上网，移动数据流量业务类型包括手机上网、物联网、上网伴侣、数据卡。

忙闲时流量定义：指用户在闲时时段（23点-7点）产生的移动数据流量。

指标的标准化也包括指标命名和编码的标准化设计，如下图所示：

3、重构报表体系

在梳理完报表的指标体系以后，就会涉及到落地实施了，这个时候就要统一数据模型，确保这一套报表指标是由同一套数据仓库模型生成的。

大量的存量报表由于历史原因，往往不遵循开发规范，比如绕过数据仓库模型直接从源表汇总，这些都为报表数据的不一致埋下了祸根。

假如底层模型不一致，即使技术口径和业务口径完全一致，也可能导致最终会不一致，因为不同的底层模型的生成逻辑可能是不同的。

比如同一张源表，由于拍照时间的不同，数据量就可能有差异，因此大家不要期望逻辑上的一致能确保数据的最终一致，很多外行的人就是搞不懂。

下图示例了流量经营报表依赖的数据仓库的统一模型，模型表设计的烂可以改，但违规了就是不行，这是需要遵循的原则。

而要让这些模型支持标准化的指标，又会涉及到大量模型的改动，同时为了确保一线未来能够基于标准化指标进行二次加工，记得当时要求所有的报表指标生成过程中的清单表要予以保留和开放，这是开发需要付出的代价。

开发完成模型只是第一步，挑战更大的其实是存量报表和新改报表的横向比对稽核，记得当时发动了一线的报表人员来帮助做数据质量的稽核，稽核完一批才能上线一批，工作量很大。

当然这样还是不够的，因为新改报表如果无法追溯历史对于业务人员就意味着不可用，因此还需要做大量的历史数据还原工作，大家都要尊重历史。

4、完善报表描述

为了避免业务部门对相同指标的理解歧义，达到数据可理解、可追溯的目标，还需要完善报表的业务、技术元数据，提高报表指标透明化程度。

当时主要做了两个事情：

一是从需求模板获取报表需求描述、维度指标的业务口径等业务元数据，纳入元数据平台，使报表使用者清楚报表的背景，了解业务规则，业务口径等。

二是解析数据仓库库表结构和应用程序日志，获取报表相关技术元数据，纳入元数据平台，提供血统分析和影响分析，做到报表数据可追溯，这种方式其实是很落后的。

效果如下图所示：

5、重构开发流程

报表治理不是一棍子买卖，你这次治理完了，如果没有出台相关的管理规范，几年后也许又恢复到了老样子，因此一定要强化运营。

比如我们当初就制定了一个基于全局标准指标的报表开发流程，如下图所示，确保新增报表能够遵循标准化的规范。

步骤如下：

（1）业务部门向IT部提出报表需求；

（2）需求管理员进行需求分析后，将报表中的指标纳入指标库，进行全局标准口径定义；

（3）基于数据仓库模型开发标准指标；

（4）对于指标库数据粒度能覆盖的报表直接引用指标库指标生成报表；

（5）（6）对于指标库粒度不能覆盖的报表引用指标库指标口径，基于数据仓库模型进行报表开发；

（7）（8）将报表开放给业务部门，报表数据保持全局一致性。

当然这个开发流程对于业务方和报表方人员都提出了很高的要求，包括如何快速判定是否可以用标准化指标实现，如果指标只满足部分怎么处理，维度不对齐又怎么处理，业务方等不及怎么处理等等。

报表在规范化的同时必然会降低灵活性，开始的时候甚至还降低效率，这也是一种代价。

以上五步就是大致的报表治理内容。

但无论是报表体系梳理、标准化指标提炼、统一数据模型、完善报表描述还是重构开发流程，其实每一项都极富挑战性，很多人来跟你谈报表治理，大多时候是他自己都不知道自己不知道，做了才发现巨坑。

最终你会发现，数据治理最大的问题不是什么方法论，而是能否结合自己企业实际走出一条可行的路，并能带来有感知的业务价值，而你能依赖的靠谱的资源往往又有限，这实在是太难了。