“数据治理”这个词，在最近这几年时间一下子火了起来。不知从何时起，江湖中流传出了：“数字经济转型、治理发展先行”的说法。
但只有真正做到数据治理的人才知道: 数据治理不仅是辛苦，还吃力不讨好，往往要承担责任，领导还看不到你做的价值。
为什么说数据治理是脏活累活呢？
1. 源数据
•
烟囱式开发： 业务繁多、数据库多而乱，系统与系统之间错综复杂。
•
数据库种类： 架构经历多次变迁，切换不完全，需要从Mysql、oracle、hbase甚至excle表中跨库、跨实例、跨种类才能获得有效业务数据。
•
数据结构混乱： 同一字段，类型、命名都不一致。
•
文档缺失： 无数据库文档或文档陈旧。
2. 变迁
•
系统版本升级： 每一次升级都只是掩盖之前的错误，数据治理需要从源头。
•
人员变更： 梳理过程中的大部分问题最终答案： “不清楚，原来维护人已离职”。
•
数据流转： 数据从源头经过很多次不规范的同步。
3. 存量
•
各自为政： 各业务部门已有自己的统计逻辑和报表，同一指标汇总维度又不一致，梳理、治理、输出还要尽量不影响已有报表结果。
•
半途而废： 前任都知道数据治理、统一出口的重要性，但只完成一部分就放弃了。 问题在于“完成的一部分”有人还在用。
数据治理是一项长期而繁杂的工作，很多时候数据治理厂商做了很多工作，当把咨询成果落地到实处的时候，但客户却认为没有看到什么成果，这是因为在进行数据治理时存在了各种误区。
1客户需求不明
客户既然请厂商来帮助自己做数据治理，必定是看到了自己的数据存在种种问题。但是并没有考虑做什么，怎么做，做多大的范围，先做什么后做什么，达到什么样的目标，业务部门、技术部门、厂商之间如何配合做这些问题，也就是说很多客户其实并没有想清楚自己真正想解决的问题，很难在数据治理方面找到一个切入点。
2问题来源不明
在大数据时代，很多组织认识到了数据的价值，也成立了专门的团队来负责管理数据，有的叫数据管理处，有的叫大数据中心，有的叫数据应用处，名称不一而足。这些机构往往由技术人员组成，本身的定位也属于技术部门，它们的共同点是：强技术，弱业务。当数据治理项目需要实施的时候，往往就是由这些技术部门来牵头。技术部门大多是以数据中心或者大数据平台为出发点，受限于组织范围，不希望扩大到业务系统，只希望把自己负责的范围管好。但数据问题产生的原因，往往是业务>技术，可以说大部分的数据质量问题，都是来自于业务。
3数据标准难行
很多客户一说到数据治理，马上就说我们有很多数据标准，但是这些标准却统统没有落地，因此，我们要先做数据标准的落地。数据标准真正落地了，数据质量自然就好了。我们首先需要全面梳理数据标准，而数据标准的全面梳理，范围很大，包括国家标准，行业标准，组织内部的标准等等，需要花费很大的精力，甚至都可以单独立一个项目来做。所以，首先需要让客户看到梳理数据标准的广度和难度。其次，就算是花很大精力梳理，也很难看到效果，结果往往是客户只看到了一堆Word和Excel文档，时间一长，谁也不会再去关心这些陈旧的文档，这是最普遍的问题。
