数据治理团队如何组成，有几个小组，职责是什么？谁为治理结果负责，又是谁来推动治理？数据治理是否能够落地需要关注哪些问题？作者对以上问题进行了一个总结，并分享了一些自己的感悟探索和认知迭代。

前言

这是我数据治理系列文章的最后一期，回顾1-4期内容，我们分别以数据治理的完整性、规范性、唯一性、及时性、准确性和安全性这6性为目标，然后介绍资产中心、DQC、SLA和安全中心这四大治理工具，按理数据治理也就这些内容，没有它途，但为什么我还想再开一期话题，这主要是我在参加各家单位组织的数据治理分享的时候发现，大家的治理方法、策略、手段和工具基本都是一致的，但却很少有分享数据治理的落地核心问题，即组织问题。

我每次参与这类分享的时候，我必问的一个问题，就是你们数据治理团队，产研是如何组成的，分成几个小组，各自什么定位和职责？我问这些问题，本质不是我想挖他们的组织架构，我其实是关心，数据治理在对方团队内是如何定位和落地的，需求方是谁？供给方是谁？平台方又是谁？谁为治理结果负责，又是谁来推动治理？这些问题，才是数据治理能否落地最核心的问题，反而治理工具倒相对是简单的了。

因此，针对以上灵魂拷问，简单聊一聊我自己的一些感悟探索和认知迭代，作为我数据治理系列文章的收官吧。

01 核心结论

第一，数据治理是一个系统性工程，需要解决用户心智、组织保障和生产管理提效问题，如果仅靠组织授权往往曲高和寡，调子起的高但往往陷入运动式治理，领导问到哪就治理哪，业务感知上可能觉得问题非但没解决，还徒然增加各类做表统计、应对调研等的工作负担；如果仅靠运营case by case跟进，短期虽然容易见效果，但投入大、战线长，往往只能头疼医头脚疼医脚，长期陷入被动，无法根本解决问题；如果仅靠开发工具或者购买第三方治理套件，则短期成本暴增，但见效慢，业务可能会因短期看不到效果而失去耐心，且谁来使用工具也是一个问题。

因此，数据治理是一个需要组织保障、运营实施和工具建设三位一体跟进的工作。

第二，数据治理又是一个抓大放小的工程。世界本质是一个熵增的过程，即任何事物本质是一个自发的由有序向无序发展的过程，这个既是人性也是客观规律，而数据治理本质是减熵的过程，也就是要建立秩序，但任何秩序的建立本身都是逆人性和逆客观规律的，需要源源不断投入能量（资源）才能维持熵值平衡。

但问题就在于，人性天然有建设性和破坏性两面，想要秩序的存在并维持下去，本身就是需要投入非常大的建设精力和成本的，而且这个成本还不是一成不变的，它是随着公司资产的累加而增加的，也是会随着公司战略、制度和文化的革新变化而变化的。

因此，数据治理工程中追求完美主义是不可取的，我们要学会分类分级，学会判断优先级，学会抓大放小，允许有序和无序的并存。

第三，数据也是一种商品，是商品，自然就存在生产商品的供给侧，消费商品的需求侧，以及提供商品售卖的货架，也就是平台侧。类比现实生活，如果消费者投诉一家超市售卖变质蔬菜，那市场监管部门处罚的应该是超市而不是菜农，菜农，或者蔬菜运输和仓储物流环节应该由谁来监管和处罚呢，应该由超市来处罚，怎么处罚，可以退货，可以要求赔款，可以中断合作选择其他供应商，但无论这样，消费者只关心花钱买到的蔬菜是新鲜的，市场监管部门只关心超市没有售卖劣质食品。

如果数据是蔬菜，那生产“蔬菜”的菜农，应该指的就是数据采集和开发团队，自然售卖“蔬菜”的超市就应该是数据应用开发团队，这些团队平时负责提供的工具有报表工具、画像工具、AB工具等分析工具，最后，消费“蔬菜”的自然就是我们的业务运营、分析师、销售等业务团队了。

因此，与现实生活类似，如果数据出现质量问题，首要负责团队是平台团队，但最后真正为数据质量负责的，却应该是数据生产团队。

02 问题分析

结论部分，第一个结论和第二个结论，相信大家也比较好理解，我就不进行进一步拆分分析了，但第三个结论，却实实在在涉及到数据治理是否能够落地，还涉及到各方应该如何分工合作，因此，我就针对结论部分的第三个结论，做一个详细的问题分析。

数据不是凭空产生，需要经过埋点采集——加工生产——指标定义——分析应用，最后才会呈现到业务手上作为可参考的分析依据，甚至可以直接应用于业务流程，正因为数据生产环节链条长，涉及多方团队。

因此，数据质量出现问题，从全局看，不单单只是某一方的责任，但实际运行过程中，我们应当理解，业务其实并无法知道数据背后这么长的生产逻辑，用户在哪消费的数据，就认为谁应该为数据负责！

所以，无论数据的口径定义、计算统计是否由平台方来负责，最终为数据指标负责的，一定首先是平台方，这个是怎么也脱不掉干系的，如果平台方遇到用户反馈数据问题，只是简单的做工单转移，或者做问题汇总，都无法解决数据质量问题，这就好比超市只是把顾客对蔬菜变质的投诉传达给供应商或者菜农一样，这次出现质量问题，下次一定也会继续出现。

那平台方到底应该是一个什么角色？目前部分公司将平台方定义为数据治理的主R，主要手段就是开发和提供相关治理、监管工具，以期通过治理和监管工具达到数据治理的目的，但落地效果往往不佳。

为什么数据治理落地不佳，这里我们就要看另外一个问题了，平台侧不推卸责任，主动主R起治理的职能，也投入资源去开发治理工具，但为什么最后还是难落地？

超市买了很多检测蔬菜是否新鲜的测试仪，确实是可以检测出蔬菜是否可以售卖，但数据平台与超市的区别在于，超市检测出不合规蔬菜，是可以退货的，强势的是超市方，但数据平台因为不生产数据，且公司内基本不可能有存在可替代的其他数据生产团队。

所以平台侧光靠数据监控工具，数据治理工具，但你缺乏数据内容，你没有治理抓手，就算你有组织保障，你也很难持续性去从根本上解决质量问题，最后只能落不着好，生产团队会抱怨你不干实事，只会抛问题。

因此，此时，我们发现，就因为公司内部，平台侧不负责数据生产，不负责数据内容本身的建设，如果只负责制定标准和监管标准执行的话，其实是很难有抓手去持续推动数据质量优化的。

最后，让我们来看一张图，以数据质量的好坏为飞轮的起点，数据质量一旦无法得到及时保证，会慢慢的开始侵蚀供给团队和平台团队在用户群体中的口碑，进而产生信任危机。

如果要让数据正向流转起来，核心本质就是要首先保障数据质量，先让用户对数据产生信任和依赖，进而再去挖掘供给，不断丰富供给才是有意义的，那数据质量的好坏，对谁有核心利益的相关信性，我认为是对数据生产团队。

因此，这就是我结论三里说的，如果数据出现质量问题，首要负责团队是平台团队，但最后真正为数据质量负责的，却应该是数据生产团队，这也就是部分公司做数据治理，方向跑偏了的原因，为了解决质量问题，成立中台团队，开发很多治理工具，但只要数据内容不在中台手里，中台其实很难对质量治理的落地最终负责。

03 策略概述

核心就一句话，数据治理，首先应该围绕数据内容生产建设才能玩得转！也就是，做数据治理，核心还是要抓住数据内容生产建设，如果公司规模较小， 不存在多个生产团队，或者数据内容并不是分散在多个部门中，则直接由数据生产团队做数据治理比较合适。

如果是公司规模较大，数据内容分散在不同的数仓团队，或者分散中不同的部门中，则应该成立一个数据中台团队，由这个中台团队负责汇总各个分散团队的数据内容，然后统一进行加工、定义和认证，平台为经过认证的数据质量负责。

这样，数据的出处，以及数据内容的定义全部统一到中台团队，此时中台团队自身就是一个数据生产和服务团队，自然有动力去丰富数据供给，去保证数据质量，也能从全局的视野去管控数据流程。