数据治理之死(一)

最近这两年一直在做报表开发，从起先的PC端，到之后的大屏、手机、PAD，做来做去，其实差不多，很多报表是重复性的，只是表现形式上变化而已，而且多是那种中国式报表，领导又想做的和国外的报表一样好看，又想功能全面，在一个图里展现复杂的数据结构，并且有非常丰富的交互，即是数据都不达到，全是红色，也要那种深浅不一的红（我叫它五颜六色的红）。
--------------------------

一个柱状图，柱子要叠起来，可以拖动时间，并且有两个纵轴指标，点击可以下钻，鼠标移上去要提示出一张表来，即要表示出当月，还要表现出同比，环比，即要有实际值，也要有完成率，即要切换不同机构，又要切换不同渠道，还要日、周、月季地切换，可想这么一张图有多复杂；一个表格有大几十个字段，而且列是动态不固定的，表头要冻结，左侧某些列也要冻结，表体有些格子要合并，还要进行格式化，甚至还要进行编辑（在表格里直接编辑，不是弹出对话框来编辑），表内容可能有很多行，有时还要排序，可想这么一张表有多复杂；这——就是中国式报表，问题是你还不能做的比别人丑，又要和国外的报表一样简洁，一眼能看出问题，又要比国外的报表丰富的多。

报表是用来展示数据的，数据的准确性、完整性、及时性是报表的灵魂。很多报表没有用起来就是因为展现的数据并没有赢得用户的信任。数据不可靠也许是诸多历史问题造成的，也可能是没有数据仓库造成的，也许是各业务部门之间都未打通，业务部门之间开会尚切吵成一团，IT部门如何去做？有时某个业务人员找到IT说某个地方显示的数据不对（问题可能会首先抛给前端工程师），之后前端工程师查询接口说后台返回的数据就是这个值，然后问题到了java工程师那里，java工程师仔细检查了sql之后说数据库里的数据（DM层）就是这样的，然后问题走到了数据开发工程师那里，数据开发工程师检查了整个ETL逻辑，并且导出一张明细数据和业务提供的参考数据（这套参考数据可能是来自另一个系统或者业务自己手工整理的）做对比，最后发现某一个机构的一条数据不匹配，沟通之后发现，这条数据是业务输入某系统时手误造成的，虽然最终问题还是来自业务人员，但他本身并没有能力发现这种问题，经过层层追踪（这个过程可能要花费半天到几天），虽然找到问题了，但整个过程是低效的，而且领导可能主观地认为数据报表是不可靠的，久而久之，就很少看这些报表了。

报表并不是纯粹的查数据并显示，做报表的过程实现上是梳理业务的过程，有些不该做的要拒绝掉，不合理的要改掉。比如一个显示各部门业务的报表，有些部门由于业务很不规范，月末汇报时，很多数据不合格，就用Excel手工改掉，再给领导看，这种情况在做报表时要坚决拒绝掉，报表就是要反映真实情况，想怎么改就怎么改，欺骗领导的事情不可做，否则到头来还得IT背锅。如果在报表开发过程中，伴随着业务的深入变革，那么最终的收获也将是满满的，业务的变革促使数据更加准确可靠，而报表的展现则有助于管理效率的提升。

另外，报表的开发也应该尽量避免数据线下手工干预，避免Excel导入，避免数据修改，所有数据都应来自业务系统，经过ETL处理，合理的建模，按主题详细分类，建立完善的指标体系，在DM及PR层形成易于理解，便于分析的宽表，只有这样，才能使做出来的报表更加可信，少受指责。为什么要避免Excel导入呢？因为Excel中的数据可以随意编辑，难以跟踪，而且对导入数据的校验是个巨大的工程，对业务人员定期导入数据也是一种“无聊而烦恼”的工作，我常常听说的是：导数据的人觉得看报表是领导的事，不是他关心的，甚至整理数据并导入的工作并未纳入他的日常绩效考核中，属于额外的工作。另外，时间一长，做这项导入工作的业务人员可能换人了，或者其领导换了，新任领导可能并不关心以前的报表。如果数据不是来自线下，那么就可以通过调度自动完成，即使有人员变动，报表一直在那里，数据一直能稳定供应。

以**[项目]的方式做报表，而非从[产品]**层面上统一规划稳扎稳打，会造成报表过度与业务紧耦合，通用性降低，用户群减少，使用频率下降，极大可能造成做好的报表没什么人用，时间一长，就只能扔垃圾桶里了。不仅如此，很多业务部门都有报表需求，他们有很多报表或者数据是相同的，或相通的，但业务规则又不一样，若不从产品层规划，就会造成重复建设。即便同一个部门，不同的接口人，不同的领导，或不同的时期，对报表的要求也大不相同，更莫说公司政策调整、外部环境变化等因素的影响。

不过，上面的问题不是不能解决的，只要有统一的标准规范，完善的数据监控链路，高效的数据血缘查询系统（元数据管理系统），这个过程可经缩小到十分钟，甚至出现异常时系统自动报警。但是… …要做到这种程度谈何容易。

固定式报表并不能满足所有数据分析的需求，它只适合那些已经相对固化的管理流程，将来的发展方向是自助化分析，每一个业务管理者都是数据分析工程师，他可以根据需要从数据仓库中抽取自己需要的数据进行分析，通过拖拉拽的方式快速发现问题，定位原因，采取策略，这样的工具包括Tableau和FineBI等，要做到这些必须建设好数据仓库，各种主题的数据分门别类，形成易于分析的大宽表，维度建设完整。

无论如何，报表是最容易出业绩的，它是看得见的图表，不像数据治理、数据中台等工作藏在幕后，而且短时间难以见成效。

IT并不想跟在业务屁股后，业务说做什么报表就做什么报表，而是要面向“解决公司管理的什么问题”，也许业务做一个复杂的表格只是为了给领导看，但这个表格解决了领导的什么问题呢？ 也许业务人员本身也不知道要什么样的，只好先做出来一些，看到东西了再去想怎么改，这往往耗费大量的时间。[当然可以先设计拿设计稿去沟通需求，可是有些奇葩业务说设计稿看不出来东西，/笑哭].

真正的数据需求很难深挖出来，要看业务和领导的配合程度，有的部门领导只是把活儿全权交给某个业务人员（A），A往往按照自己的想法安排IT实现一些功能，，比如做一个复杂的报表，A说他每月/周做这个表要花两三天时间，如果IT帮他做了，就省去了他的这项工作，相当于为公司省了成本，IT组织团队花了一周两周或三周来实现，费了九牛二虎之力才完成，这时A又说，要准备这张复杂表格他还需要准备十几张报表，分别从CRM、SAP、SCM、ERP等系统中导出，再经过一系列的加工才能完成，所以等这项工作完成，那张复杂的报表也基本出来了，因此，IT还必须帮他把这十几张报表也做了，于是IT又做了很多报表，等所有都做完了，可能事情就变了，比如人员变动（A走了换成另外的接口人B，或A的领导也按了）、公司政策（公司根据市场下发新规，有些组织变动，或有些渠道调整，或有些规则要求），总之，做好的十几张报表要重新调整，又花了几天或几周时间。也许做好了这些工作，也未必真的解决业务本身的问题，即便释放了A的手工劳动，也有可能被A的领导否定，说这些并不是真的他想要的，他想要的可能是解决更高层面的问题。

更不要说我们的数据是否准确、完整、及时，逻辑是否复杂，来源是否统一，是否都是从系统里处理，还是说有些是人工干预，EXCEL导入的；更不要说外源系统多复杂，业务系统不能协同共进；更不要说服务器不稳定，供应商支持不给力；更不要说历史遗留问题有多少，有多少是牵不动，理还乱的；

所以建数仓在传统企业里没几个成功的，传统企业不可能会为了建数仓的同时不去做报表，做项目的同时建数仓，只会让数仓的建设更难，因为数仓是产品，是基础，即使策略是横向设计纵向实施，也难以保证建设过程中能遵守设计的规范，因为项目是紧迫的，重要的，有时不能不折中地处理问题，而产品是基建性的，原则强约束的，项目不服从产品设计约束而为了交付违背产品设计是常有的事，最后就是，项目一个个做完了，产品并没有沉淀下来，即时有所沉淀，也常常因为项目+产品同时做造成周期过长，外部技术和市场都已经明显变化 ，不得不推倒重来，这时，领导再也不会容忍产品建设的长周期，而决定从外部购买别人已做好的产品了，买的产品最大的缺点是难以和自己的业务贴合，与现有的各系统对接也困难，后期支持也有风险。

有的情况是，高层接触到各企业的数据建设，深受感动，觉得自己也要重视，对下面提了很多要求和企望，但是没有清晰的路子，没有相应的组织调整，甚至没有正式的任命，中层管理者不知所措，基层更晕头转向，即要背负领导的企望，又要拿出KPI，不得不找业务做很多报表交差。

无疑，数仓或数据中台的建设对企业的做用是巨大的，企业如果建成了数据中心（数仓或数据中台，或其他的名字whatever），管理的日常数据可以很快从数据中心查出，可以做各种维度的数据分析，不需要IT，业务自己可以根据需要对销量、成本、库存、毛利、制造过程进行跟踪和分析，快速找出问题，解决问题，对市场快速反应，降本增效，缩短库存周期，提高周转率，甚至按需制造，智能智造。这时，固定式报表显示没那么重要，更多的是自助式分析。

但是，这只是个梦想，阿里的数据中台被反复提及，奉为典范，而成功者寥寥无几，究期原因，大概有几点：

1、雷声大，雨点小，口号喊的响，没有实质的行动

有的领导到处去考察，也积极地了解市场，很想解决企业各种管理问题，比如管理层不能及时看到数据，等问题出现才有反应等，看到别的公司做的花花绿绿的报表，觉得自己也应该有，对数据的重要性也算深有体会了，于是号召公司上下成立数据建设部，专职负责数据治理、数据建设、数据分析、数据展现等工作，看似没有毛病，实际上却是最大的问题。

数据治理和数据中台全权交给一个小部门是不行的，也不是喊口号，只说给全力支持就行了，试问在会议上哪个人会说他不支持的？但实际中，数据部门如果没有被完全赋权，各业务部门如果没有指定好责任人，这项工作就难以开展，比如，当数据部门去找各业务部门商谈时，业务领导指出某个业务小B来负责，而小B又有自己的工作要做，这个配合数据部门的事他根本没当自己的本职工作，也不会纳入到他的绩效考核之中，他怎么会上心呢？

高层可能隔三差五的问下进展，下面有所回答就算过去了，这样是不可能建成数据中台的。

2、历史包袱重，牵一发而动全身，而全身又动不起来

对于非互联网企业，有很多数据是非“线上”的，比如没入系统的，由专人定期制作的，Excel收集的数据，当这些数据需要和线上的数据进行匹配，整合，计算时，只能由人手动完成，通过一系列逻辑处理，再出报表给领导看。为什么会有很多不上系统的数据存在呢？因为业务系统几经换人，能接手的人也不多了，在很老的技术上做新的需求也很困难了，比如CRM,ERP,SCM,SAP,SRM，OA等系统可能是10年前建的，已经到了所有人都想推翻重来的地步了，工程师看见那老的代码乱的一比，维护起来像吃屎，程序跑起来像踩钢丝，出了问题只能糊泥巴，新的业务需求只好退而走线下，多花些人去做苦力，等到领导要报表时，数据只好东拼西凑了。
对于有历史的业务系统，数据治理谈何容易？没有几个工程师能改的动，可能由于架构的原因，改个东西会动摇整个系统， 也很难让领导决定因为数据治理而重做业务系统。

3、建设周期长，投入成本大，没有坚定的决心和持久的恒心

建设数据中台和数据仓库，或者数据治理的工作都是长期的，这取决于企业数据的复杂程度，少些一两年，多则五六年，期间花费很大。任何一个领导都是怀着热切的期望提出要进行数据治理的，这种期望造就了乐观的估计，觉得自己不需要等太多就可以有显著成效，一旦执行下去才发现事实并非如此，要把供应链、生产制造、财务、销售、物流、人员等相关的主数据全部收集起来，规范统一并不容易，往往是神仙打架，各自有理。

举个例子，就拿人员主数据来说，员工的入离调信息源头可能来自EHR系统，再由EHR同步到OA和SAP，OA系统主导公司的各种日常办公流程，但是由于公司有很多外包人员，这些外包人员没有公司的邮箱，更不可能在EHR系统中，但他们同样有些日常办公事项，需要录入到OA中，因此OA中手动加了一些人，虚拟了一些组织，并新增了一些字段，SAP中的组织架构涉及到生产计划，财务结算，因此字段信息又有些不同；公司同时还有企业微信，在企业微信里保存有用户ID，微信号、工号、邮箱等信息，但由于很多信息是不全的，比如来自外包人员可能没有工号、邮箱，一些人邮于在海外办工，可能使用另一套邮箱系统，由于某些历史原因，工号也不是人人都有的，结果就是，要把这一套东西整合起来都难，更不要说涉及到一些账号管理，邮箱变更，有些员工调岗，企业中的子企业员工调动，有些人离职又重新入职等。
如果没有坚定的决心和持久的恒心，很难想象一个涉及到所有业务部门，所有业务系统的大项目能够顺利落地，把数据治理的像新做的系统一样闪闪发光，让数据成为企业的明珠。

4、业务变革 vs. 产品建设

数据仓库或数据湖或数据中台，是整个企业层面的产品，它有关企业所有业务系统和业务领域，基于这些系统又超越它们的范围，它的数据来源是是各个业务系统，基础统盘考虑，现有的业务系统数据还不够，要有很多补漏，首先是数据治理，把已有的业务系统中不规范的规范，不统一的统一，这往往涉及到各业务系统的巨大变化，而各业务系统的变动势必要花费很多人力、物力和财力，站在业务系统本身的角度来看，别人关注的并不是数据规范不规范，而是系统本身是否满足快速弯化的业务需求，市场在变，业务系统也在变，有的数据库里存在着大量的废表废字段，更不说命名乱七八糟，格式花样繁多，比如对于百分比这样的数，可能存在着：18%，.18，0.18，“0.18”，“18%”，“-”，“-.5”等很多种形式。

业务系统的首要目标是满足业务需求，而不是满足数据治理规范，业务需求的开发面临着时间周期短，建设任务重的难题，而数据治理、数据中台的建设则是受促于管理需要，满足管理层的各种问题。两者虽然本质上不矛盾，但在落地时，考虑到时间和成本，就产生了冲突。即使有了数据治理的规范，业务领导也会说：遵守了你的规范给我带来什么好处？我要多加好多人，花几个月来改造，那边业务需求却要马上交活，影响我的KPI完成… …，这也不能怪业务领导没有数据意识，没有全局观念，很多时候更上层没有给他更多的人力资源，也留不出对业务系统改造的空档期，也许业务系统停一天就损失几十万甚至上百万的收入，怎么能毫无顾忌地去改造业务系统呢？即使这样的改造对他后期的管理是有所帮助的。这样一来，数据治理的规范就成了一纸空文，难以落地了。

再说数据中台的建设，本身涉及整个企业，是个高成长，长周期，高风险，高收益的产品，对于谨慎的领导来说，很难撸开膀子放心干的。像阿里、京东这样的企业，他们的成功得益于互联网企业数据基本都是线上的，即使如此，也是老板亲自指挥才取得了成效，否则，当业务需求与数据规范冲突出，当管理需要与KPI考核博弈时，没有更高层的干涉，各方只会相互争执，互相甩锅。

5、组织结构不配套，没有跟着变

数据治理的首要目标是组织结构的变革，至少先成立强有立的数据治理团队，建立起推进的规则，做好策划与监督。在数据治理过程中，组织要相应调整，阻断进程的，该合并的合并，该取消的取消，该建立的建立。
有人会想，数据治理和企业的组织结构有什么关系呢，似乎不沾边呀？

实际上，我觉得这正是很多人忽视的一点。难受CEO把数据治理扔给一个可信的手下，就可高枕无忧了吗？一个企业级的项目，当然需要一个企业级的执行团队。如果只是成立一个二级或三级部门来主导数据治理项目，不用想它起初就面临失败的风险。想想古代皇帝派一个七品小官去查各个巡府大臣，要是不给个尚方宝剑，并且这个人的执行力又很强，那是很难成功的。数据治理团队如果不能架设在各业务部门之上，那么在数据调查期就会处处碰壁，因为别人也有很多工作要做，别人要完成业务成绩，不可能在配合数据治理的工作上花费太多。
除此之外，还要指定好每一个对接人，把数据治理纳入到对接人的业绩考核中。

另外，数据治理和中台建设不是把所有数据合并起来，做个折中就行了，其中必然牵涉到与业务流程冲突的地方，这些冲突点就是变革中要解决的问题，如果避重就轻，总是中庸地处理，其结果也就是会生成一个可有可无的数据湖，只不过把垃圾收集在一起而已。

6、以为数据治理和数据中台可以解决所有的问题

负责数据治理项目的组长告诉我，他每次开会都发现大家的意识出现了问题，以为数据治理能解决企业管理中的所有问题，只要有个数据中台，所有问题就没了。
这正是一个很大的误区，没错，数据治理、数据中台可以解决很多管理上的问题，但绝不是所有问题，阿里有了数据中台，但未必就没有自己的问题。
数据治理是为了解决数据问题而生的，它把孤立的，凌乱的数据统一起来，做的准确、实时、完善，这样管理者可以及时了解问题，分析问题，进而解决问题。这是管理水平的提升，能够助力企业发展壮大。但不能解决所有问题，比如一个销售型企业如果产品做的不咋地，数据中台做的再好也未必能赚钱；如果管理者从数据中找到了问题却无法解决发现的问题，那还不是一样？

以上六点是数据治理，数据中台建设中核心的几点，这些问题普遍存在，也许早被发觉了，只是解决起来困难重重，数据治理是数仓和数据中台的基础，但谁也不愿等数据治理好了再去做报表，因此，报表开发就伴随着整个过程，由建烟囱的方式逐渐过渡到自助式分析，希望那时，我已转变成一个人工智能方面的攻城狮。

知道了问题，想必解决方案和思路也就有了，虽然每个人，每个企业或方案提供商都有自己的噱头，但对于同一件事情，正确的道路只有一条，所以每个宣称的方案都是合理的，正确的，或者从很大比例上来说是正确的，但是，最关键的是执行，是落地。比如下面一张图是从直播平台上截下来的：

图中的第一步，就是数据治理，任何解决方案都不建议在一个凌乱的数据垃圾场上出报表，而数据孤岛，数据垃圾却是很多企业都在存的，所以第一步是数据治理，数据治理又很难一蹴而就，在治理的过程中，没人原意“干等”，报表还要继续做，在一堆数据问题上面做。

第二步可以看做数据中台建设，数据治理好了，还要有相应的平台给人用，使用起来的数据才有价值。有了平台才能给更多的管理者使用，让人们随时随地都能看到想要的数据，分析出现势性的问题，及时处理。
前两步做好了，第三步自然有了，所以第三步是废话，它是理想，是目标，是一个新的高度，很多公司高层就是看到了这个目标，于是心潮澎湃，下决心要去做，可是都死在了前两步上。

一个公司，要做好数据仓库或数据中台，首先，无疑是高层领导牵头，并且怀有巨大的决心和不移的恒心，持续的跟踪，其实，是根据需要为数据治理、业务系统改造，铺路，神挡杀神，及时清除各种绊脚石，让项目尽快落地；再次，要给数据仓库和中台建设提供足够的时间支持，不能像催做报表那样，说要就要，限死日期，影响长期规则，只顾眼前利益，造成做出来的东西问题百出，不能长寿。有了这几点，才能说到战术问题：使用什么方法，什么技术手段，如何划分里程碑，如何访谈，如何兼顾一些重点业务报表需求，如何让团队高效率地运作，如何保障人力资源的稳定可靠，等等。

行百里者，半九十。

世上并不缺少能规划，善想象的人，世上稀缺的是那些能把远大目标完美落地的牛人。