数据治理到底该怎么做？这个问题问的我是一时语塞。因为是在客户现场，我只能根据他的实际情况，针对性的提了一个方案。
不过，这客户还真的是做了一些工作，然后就开始讨论起来：那谁谁谁，都是这么做的，我们能不能也这么做？
说实话，我是比较喜欢这种客户的，因为这代表他在思考问题。我最害怕的客户是把你丢一边，啥支持也不给，最后管你要高质量的结果。这八成是要坏事的。
当时跟客户聊了很久，但都是聊到哪算那，也不系统，今天趁着有点时间，整理一下，贡献给大家，仅供参考。共分为8种方法，分别是：顶层设计法、技术推动法、应用牵引法、标准先行法、监管驱动法、质量管控法、利益驱动法、项目建设法。
事先声明，这些方法论都是向各位大佬学习来的，也有部分是项目中实操得来的，并非老彭原创。
一、顶层设计法
顾名思义，顶层设计法就是先做一个数据治理顶层设计的规划，然后按照规划执行即可。做过咨询的彭友都知道，顶层设计、战略咨询都会根据战略目标拆解KPI，然后设立对应的支撑项目，并且根据优先级别进行排序，最后形成一个执行的路径。今年做什么，明年做什么，先做啥，后做啥，都规划的清清楚楚明明白白。
这样的好处很明显，先有面，再有线，最后是各个点状的项目，一点点的落实，效果自然没的说。
但是这样的方案是非常非常奢侈的，因为这种方案见效慢，对组织的要求非常非常高。耐得住性子的组织很少，通常都要快速见效。
基本上也只有一些政府单位和极少数的企业使用这种方式获得了数据治理的成功。
二、技术推动法
有敏感的朋友已经察觉出来了，这里叫“技术推动法”，而不是技术引领啥的。其实这种方法是绝大多数企业采用的数据治理方法。要说原因么，其实很简单，因为数据治理项目大多是在信息部门立项和实施的。
既然是技术部门的事儿，那当然是技术部门推动了。讲真，我见过太多类似的事情，很少有效果很好的。《华为数据之道》里说要“业务主导”，话是真没错，但几乎没有做到的。原因很简单，屁股决定脑袋。业务负责人的主责主业是搞业务，根本不会野不可能要主动做数据治理的事情。技术驱动的套路没啥说的，就是针对数据问题，从技术层面进行解决。套路就是信息系统建设的逻辑，立个项，做调研，各种概要设计、详细设计，各种开发、集成、测试、部署，然后验收。
效果么，一般吧。因为大多是问题导向，频繁“打补丁”式的建设。到最后往往就是各种爆炸，报表爆炸，指标爆炸，数据问题爆炸。然后开始上指标系统、数据质量系统，一个补丁贴一个补丁，到最后谁都不敢动了。归根结底，就是因为数据的问题是一个系统性的，技术层面的原因只是其中之一而已。造成这种现象的原因就是业务参与度不够。在企业，谁挣钱，谁的话语权就大。业务自然是利润中心，而技术一般都是成本中心。纯让技术去推动数据治理，就像是让儿子督促爸爸戒烟一样不靠谱。三、应用牵引法
如果说技术推动是小孩推车，那么应用牵引则是壮牛拉车得心应手啊。有应用在前面牵引，后面的各种事情就显得非常自然。
很多企业建数据体系都喜欢先弄一个大屏不是没有道理的。因为没有“用”的东西是没有价值的。大屏虽然用户比较单一，实用价值比较低，但毕竟还是有使用场景的，比单纯没有使用场景的纯技术开发建设强的不是一星半点。
以数据应用为牵引，反向要求各链路的数据高质量供给，促进数据治理体系的建设，也是一个很好的选择。
但是这种方式做数据治理，始终还是会陷入到片面、局部胜利的结果。有应用的地方，数据质量就能得到治理，没有应用的数据质量就没人管了。四、标准先行法
讲真，标准现行法的真实案例我只遇到过极少数的几个，其中就有某部委。我当时接手做这个项目的时候，把甲方情况跟彭友们分享，他们都惊呆了！居然有这么好的客户！甲方在建业务系统的时候，把数据标准和业务系统绑定起来。所以他们在做信息化建设的时候，就已经把所有的数据标准都已经建立好了。我过去的时候，发现数据治理真的就这么简单，完完全全就是一个纯技术活儿，不用考虑人的因素。
所有表都是按照统一的数据模型建设的，所有字段中的键值都在最新发布的数据字典里，甚至为某个“主数据”单独建了一套管理系统。
我过去就是按照标书里的要求，建库建表，开发ETL，把数据收上来，然后整个规则引擎，按照配置结果，自动计算数据质量，定期出数据质量报告。
其实为什么有那么多的数据质量问题？很简单，没有标准。没有标准就没有对错，自然就会乱到一塌糊涂！
标准有了，就能确定什么是对的，什么是错的。后面的执行、监测和控制就有了依据，数据质量才有保障。
