数据治理的坑你遇到过几个？

    我一直在思考怎么避免这些问题，所以今天就跟大家分享一下我们曾经遇到过的坑，希望对大家会一些指导意义。

    技术部门牵头，大而全的管理

    数据治理当前大部分的立项都是信息技术部门，原因在于业务部门往往觉得数据治理和我没什么关系，技术部门大多是以数据中心或者大数据平台为出发点，受限于组织范围，不希望扩大到业务系统，只希望把自已负责的范围管好。

    这种情况呈现出的状态，即客户遇到了数据质量的问题，也意识到要通过数据治理来解决，很多时候，客户所立的项目就叫数据治理，殊不知数据治理是一个很大的概念（这里指广义的数据治理），包括很多内容，想在一个项目里就做完是不可能的，很多人认为我们只做了元数据、数据质量、数据标准，内容不算多，但其实内容真的不少。很容易导致最后哪个也做不好，用不起来。

    我们仔细分析一下客户的问题。

    第一，范围不聚焦。有时候我们认为已经减少范围了，就拿元数据为例。元数据管理的类型很多种，业务元数据、技术元数据、管理元数据三大类，技术元数据又包括：表、字段、视图、存储过程、作业、数据流向关系、作业依赖关系、索引、分区等几十种技术元数据。从管理范围讲，管理系统的元数据范围又很多，包括大数据中心各层、以大数据中心的上游来源系统、下游的应用分析系统，很多公司有上百个信息系统，每个系统里上百张表，每张表两三百个字段，其中还涉及到人工梳理的工作。如此大量的元数据，里面还需要涉及到怎么管，流程、人员、工具、制度规范等。这样多的内容想一个项目都做了，而且还没讨论数据质量、数据标准的内容，怎么可能都做好，没有办法聚焦。况且就算花了很多钱，加班加点做了许多的工作，最后，所做的工作没办法短期见效，也得不到领导的认可，很难再开展二期的计划，从而失去信心。

    第二、需求不明确。很多客户看似需求明确，其实是没有想清楚自已真正想解决的问题。从我们的经验看，以具体的数据问题或应用需求为出发点是比较合适的切入点，例如我们可以找数据质量问题比较突出的，反馈问题比较多的业务部门，收集数据质量问题，根据问题进行分析，最后发现导致这些问题的原因有数据标准的问题、元数据的问题、主数据的问题等，然后再根据这些问题去开展数据标准，元数据、主数据等工作。所展开的工作也是有方法的，例如梳理的数据标准范围也仅是以这次问题所涉及的信息项去做，最后这些问题得到了解决，也获得了业务部门的认可，总结经验，再逐步扩大范围。

当然，很多时候，需求并不总是清晰的，如果想不清楚需求，建议先启动一个小型的咨询项目，通过专业的团队，大家一起找到切入点，其实很多时候并不是大家没需求，只是需求是笼统的，模糊不清晰的，而单纯的请来公司做交流，企业都是抱着自已的心思来的，都是有意引导到对企业自已有利的方向中，但真正是不是适合客户自已的情况就不一定了，结果客户听了很多观点，觉得自已经搞清楚怎么弄了，其实不知道，数据治理哪能仅靠几次售前交流就都能弄清楚的呢。就像近几年为什么付费内容这么火一样，免费的不一定就好，付费了，企业可以花费时间和精力帮助客户找到真正目标，这样才不致于后续花更多的钱来交学费。

    业务部门牵头，专做流程

    传统数据治理很多是信息技术部牵头来做的，但是往往效果不好，于是业务部门决定牵头来做，那是不是业务牵头就会好了呢？业务部门提出，要做全生命周期的管理，业务部门决定从流程入手，开始建立流程，从需求、设计、开发、测试、上线，运维，将所有环节都用统一的流程来管理。结果导致流程超级复杂，为开发人员实际增加了很多工作量，遇到紧急需求，要求当天必须上线，于是领导一纸公文，跳过流程直接上线。最终的结果是：一方面由于增加了操作人员的工作量，另一方面领导没有见到实效，于是逐渐边缘化，最后束之高阁。

    第一、全生命周期管理不是万金油。其实，做数据的全生命周期管理没错，但问题是很多时候，业务人员只是单纯的知道一个名词，对怎么做数据治理没有一个完整的认识，只是按照自已想象的去做。那么如何避免呢，是不是完全不要流程就是效率了呢？不是的，流程还是要做的，为了效率而不考虑后续的管理，会带来更大的低效。例如说上线时ETL流向关系设计信息缺失，参考码值没有维护，导致后续业务变更时，难以理解之前的设计，业务变更困难，只能重新开发。

    第二、做流程不要执念线上化。其实流程工具只是手段，他并不能约束人的活动，就像我可以不走流程直接上线，流程只能是提高我们工作效率的技术工具而，因此，建议先从线下流程开始，先把流程走通，不断获得反馈，不断改进，当流程稳定下来后，再去做线上化的流程工具支撑，这样做才能真正做到务实的管理。

    第三、单一部门难落地。只有业务部门或技术部门部分参与也是不行的。我们知道数据是流动的，数据的问题涉及多个部门，仅有技术部门的参与是很难推动数据治理的活动，只有让技术和业务部门都参与进来，以业务为导向，技术部门配合，才能够达成较好的结果。例如以某几个关键业务指标为切入点，针对这几个指标加工数据流向所涉及的方面去梳理，结果是这几个指标的数据质量得到了大幅提高，同时也积累了治理的经验。

    完全依赖工具，唯工具论

    很多公司都认为，数据治理就是买一些工具，认为工具做好了，数据治理就没问题了。结果是：一方面功能越做越多，另一方面实际上线后，功能复杂，大家使用不起来。其实这是错误的想法，数据治理本身包含很多的内容，制度规范、流程、组织、工具四项缺一不可，工具只是其中一部分内容，大家在做数据治理最容易忽视的就是组织人员，所有的活动流程、制度规范都需要人来执行、落实和推动，没有对人员的安排，后续工作很难得到保障。一方面治理推广工作没人做，流程能否坚持执行得不到保障。另一方面没有相关的数据治理培训，导致大家对数据治理的工作不重视，认为与我无关，从而导致整个数据治理项目注定会失败。建议大家在做数据治理的时候将组织人员放在第一位，有组织的存在，就会有人去思考这方面的工作，怎么去推动，持续把事情做好，以人为中心的数据治理工作，才更容易推广落地。

    为了做数据标准而做标准

    很多公司上来就说要做数据标准，却不知道数据标准的全面梳理，范围很大，很难以一个项目的方式都做完，而且就算是花很大精力梳理，也没办法看到效果，结果是客户只看到了一堆文档，这是最普遍的问题。

    数据标准落地困难。很多客户觉得数据标准落地难，问我怎么能让业务系统改标准，其实数据标准落地有几个方法，有源系统落地、大数据中心落地、数据接口规范落地。要不要在源系统落地是取决于具体的数据标准问题，而不是泛泛的谈论落地。企业数据标准的落地，应该细化到数据标准项，再分析其必要性，涉及面、重要程度等方面，只有把这些问题都搞清楚，才能够做出改和不改的意义。例如有些字段客户编号，涉及多个系统范围广、重要程度高、影响大，因此需要针对这个标准信息项制定一个可行的数据标准落地方案，如此才具有可落地的可行性。

    企业做数据治理切忌贪大求全，要做小而精。把一个具体的数据标准问题，从前到后都理清楚，真正把这一个标准项所涉及的问题都理顺，这样一个数据标准问题才能够得到真正的解决。同时也要注意优先级，因为数据标准问题很多，需要根据重要性、紧迫性来进行选择。

    总结一下

 企业做数据治理，要避免大而全，要做小而精

 业务部门与技术部门合作，协同推进数据治理工作

 重视数据治理组织，避免唯工具论

 要明确需求问题，不要盲目做数据标准