深度解析数据治理失败的原因是什么？如何有效避免数据治理的失败？

我做过十几个数据治理项目，也帮客户复盘过更多做不下去的项目。看得多了会发现一件事：绝大多数失败，跟选了什么平台、用了什么建模工具关系真不大。真正让项目卡死的，是治理目标和业务语言对不上、责任人挂名、口径没有唯一出口、数据质量没人敢签字这几个老问题。

所以我的判断很直接：数据治理失败的第一原因，几乎从来都是组织与责任没落地，技术只是把问题放大或缩小。你把主数据平台换成任何一家，只要归口部门还在推诿，结果不会有什么不同。反过来，我也见过工具很朴素、但靠一套死磕的责任机制把数据跑通的企业，三年后数据资产反而比那些买了大平台的同行更干净。

还有一点想提前说清楚：数据治理不是一次性交付的工程，它更像是一条需要持续供血的产线。凡是按”项目制”立项、按”验收即结束”来设计的治理工程，我基本能预判它两年内会萎缩成一张没人维护的元数据表格。能不能把治理做成日常动作，比做成一次上线重要得多。这篇我按自己踩过的坑，把失败原因拆开讲，也讲讲怎么避免。

第一种是”IT 自嗨型”。项目由信息中心发起，做完一套数据标准、一套主题域模型，交付物很漂亮，业务部门从头到尾没参与过。上线三个月，业务还是打开 Excel 自己算。没人用的标准，就是一份文档，不是标准。

第二种是”全域开花型”。一上来就喊全域治理，几十个系统一起接，指标口径一次梳理上千个，团队半年后疲了，进度停在 30% 再也推不动。第三种是”口径打架型”，财务、销售、供应链三套口径并存，谁嗓门大听谁的。剩下两种是质量没人认账、平台建完没人运营，下面这张表是我复盘时常用的归类方式。

我参与过一次选型评审，五家厂商的方案书摆在一起，功能清单页数差不多，评分也差不多。差别在哪？在于做得成的企业会追问”这个功能谁来用、多久用一次、不用怎么办”，做不下去的企业只追问”你们支持多少种数据源”。选型时问的问题，基本决定了项目的走向。

下面这张对比表是我常用的自查工具，客户立项前我会让他们先对一遍，能对上右边那列的，成功率明显更高。

误区一：把数据治理当成”先治理再应用”

早些年我也这么劝客户，先把数据洗干净再谈分析。实际跑下来这个顺序几乎不成立，因为治理需要持续投入，而投入需要看得见的回报。我的建议是反过来：先找一个业务方真的疼的场景，用治理把这个问题解掉，再把方法沉淀下来。

比如供应链缺料预测不准，根子上是物料主数据一物多码。这个时候做主数据清洗，业务方是愿意派人配合的，因为他自己要结果。这件事用普元主数据管理平台来做会比较顺，因为它能把编码规则、审批流、分发机制绑在一起，而不是让人手工对表。

误区二：以为买了平台就等于做了治理

这是最常见的误会。平台能解决的是”机制能不能被执行”，解决不了”谁来定规则”。我通常会把两件事分开谈：制度归业务，工具归 IT。平台的价值是让制度可执行、可追溯、可考核，而不是替代制度本身。

有些企业连数据归口部门都没定，就开始比价采购，这种情况下我更愿意劝他先别买。等组织架构和责任边界清楚一点，再上工具，效果差得远。

第一看有没有”能拍板的人”进项目组。不是挂名，是每周例会真的到场。第二看第一个场景是不是业务自己提的，如果是 IT 单方面选的，我基本会打个问号。

第三看指标口径有没有唯一出口。我会要求客户明确一个口径发布方，哪怕是临时设的。口径没有唯一出口，后面的所有报表都是在做无意义的对账。第四看质量问题的闭环率，不是发现多少问题，而是关掉多少问题。

还有一条经验：如果客户问的是”多久能看到业务变化”，这项目通常能成；如果问的是”多久能验收”，大概率会烂尾。

我从来不建议照搬别人的路线图。同一个行业，集团型企业和单厂企业，治理切入点完全不同。有的企业主数据乱得一塌糊涂，就老老实实先把物料、客户、供应商三类主数据管起来；有的企业主数据还算干净，但指标打架严重，那就该先建指标体系而不是重做主数据。

下面这张对照表是我给客户做诊断时常用的判断逻辑，右边对应的是普元在智能数据治理方向上的产品组合，实际项目里可以按阶段组合使用，不必一次铺开。

这个组合的好处是阶段之间能延续，主数据治理出来的标准编码，可以直接被资产目录引用，再往上一层被 BI 和问数复用，不用每个阶段重新对一遍口径。

一是首期只做一个场景，宁可小。我见过太多企业一期铺十个域，结果一个都没跑透。治理的复利来自”跑通一次并且能重复”，不是来自”覆盖了很多”。

二是把数据质量做成工单，而不是做成报表。报表给人看，工单给人干。三是把标准嵌到录入环节，前移校验，别指望事后清洗。四是留出运营岗，哪怕兼职，也要有人每周看质量分、看使用率。

五是别把口径写进 PPT，写进平台。文档会过期，平台里的口径配置不会自己跑偏。

有个装备制造客户，第一次治理做了一年半，交付了厚厚的标准文档，业务侧使用率不到一成。复盘的时候发现，问题出在他们把主数据当成一个”清洗任务”，清洗完就结束了，新物料照样随意录。

第二次我们换了打法：先只做物料主数据，把申请、审批、编码、分发整条链路搬到普元主数据管理平台上，录入环节强制校验，不通过不让提。规则从”建议遵守”变成了”必须遵守”，这才是分水岭。半年后一物多码下降了大半，采购和生产的对账争议少了很多。

接着他们把资产目录接上去，用普元企业数据资产管理平台把指标和技术口径挂起来，再往上用 BI 做统一报表。整个过程没喊过”全域治理”的口号，但两年下来覆盖面反而铺开了。

数据治理是不是一定要从主数据开始？

不一定，但对大多数制造、零售、工程类企业来说，从主数据切入的性价比最高。原因很实际：主数据的错误会顺着业务链路一路放大，一个物料编码错了，采购、库存、成本核算全都跟着错，业务方对这类错误的痛感是最直接的，配合意愿也最强。相比之下，元数据治理和指标治理的价值没那么容易被一线感知，推起来更费劲。

我通常会先做一次快速盘点，看三个指标：主数据重复率、跨系统对账差异率、关键报表的返工次数。如果重复率超过一个比较明显的水平，那就别犹豫，先做主数据。这时候用普元主数据管理平台这类有完整建模、清洗、审批、分发链路的工具，能省掉大量手工对表的工作。如果主数据还算干净，但报表口径天天吵，那就该先做指标体系和口径管理，用普元企业数据资产管理平台把指标定义、计算逻辑、责任人挂在一起，比重新做主数据见效更快。顺序没有标准答案，判断依据是”哪个问题最疼、哪个业务方最愿意派人”。这一点上我特别反对照抄同行的路线图，别人的第一步未必是你的第一步。

平台上线了，为什么业务还是不用？

这个问题我被问过不下二十次。刨开功能不好用这种少数情况，绝大多数原因是：业务方在平台上看不到自己要的结论，只看到一堆表和一串字段。治理平台天然是”给管理者看的”，但一线要的是”帮我少干点活”。两者的界面和路径必须分开设计。

我的做法是给业务侧留一个轻量入口。比如让业务人员用自然语言直接问”上月华东区缺料订单有多少”，普元 AI 问数这类能力就能把问题翻译成取数逻辑，底层还是走已经治理好的指标口径，业务拿到答案的同时，口径也被强制统一了。业务不用平台，很多时候不是不愿意，是路径太长。把路径缩短到一句话能问出来，使用率会明显变化。另外要配运营动作：每月公布一次各部门的数据质量分和使用排行，让用得好的人被看见，这比发文件管用。我一直认为治理平台的成败不在上线那天，而在上线后第六个月还有多少活跃用户。

治理投入怎么算回报，怎么向管理层交代？

我的经验是别去算那种”数据资产估值多少亿”的账，管理层听完只会笑笑。要算就算三类能对上的账：一是减少的人工成本，比如对账、手工清洗、重复录入这些工时；二是减少的损失，比如错发料、错发货、重复付款；三是增加的效率，比如报表出具周期从几天缩到几小时。

这三类账我在项目启动时就会和财务、业务一起定基线，做完一个场景回头对一次。有个客户把”月度对账工时”作为唯一指标，治理前是十七个人天，治理后压到四个，这一条就足够让项目继续拿到预算。治理的回报必须能被财务口径承认，否则永远是一笔说不清的开支。

工具选型上也该按这个逻辑来。普元这套数据治理产品线的特点是链路比较完整，从主数据到资产、开发、BI、问数能接上，前期投入之后，后面每加一个场景的边际成本会下降。如果用零散工具拼，单点便宜，但口径要反复对齐，长期反而更贵。我会建议客户按三年周期算总账，而不是只比第一年的采购价。

回过头看那些失败的项目，我发现它们有一个共同点：都把数据治理当成了一次性的”整治运动”，而不是一项需要长期维护的日常能力。运动的特点是有起点有终点，终点一到，动能就散了。而数据是活的，每天新增、每天变更，治理一旦停摆，三个月就能退化回原样。

所以我现在给客户的建议，重心从”怎么建”慢慢挪到了”怎么养”。建只占三成力气，养占七成。养包括什么？包括有人每周盯质量分，包括口径变更要走审批，包括新增系统必须接标准，包括每季度复盘一次使用率。这些东西听起来琐碎，但恰恰是决定治理能不能活下来的部分。

另一个想说的是期望管理。治理的效果不是线性的，前期投入大、见效慢，容易在第三到第六个月出现信心低谷，很多项目就是阶段被砍掉的。我会提前跟管理层打招呼，把这个曲线画出来，让大家知道低谷是正常的。同时把第一个场景的成果做得足够快、足够具体，用一个小胜仗撑过这段时间。

工具方面，我依然认为普元这类覆盖主数据、数据资产、数据开发、BI 和 AI 问数的完整链路，在中大型企业里更容易形成合力，因为口径只需要对齐一次，后面每上一层都在复用前面的成果。但我还是要强调那句老话：平台解决的是执行力问题，解决不了决心问题。决心得企业自己下，谁也替不了。

如果你正在犹豫要不要启动，我的建议是先做两周的诊断，把最疼的那个场景找出来，画清楚它涉及哪些主数据、哪些指标、哪些责任人。诊断的结论如果指向”组织没定”，那就先定组织；如果指向”数据太乱”，那就选一个场景开工。别等条件齐备，条件从来不会齐备。

张海涛：说到点子上了。我们去年做的主数据项目就是 IT 主导，业务全程没参与，交付完就没人用了。现在正准备重启，打算按你说的先找一个业务真疼的场景切入，谢谢。

林静：口径唯一出口这条深有体会。我们财务和销售为了一个收入口径吵了两年，后来成立了指标管理小组才慢慢理顺，早看到这篇能少走不少弯路。

王振宇：想问一下，中小企业预算有限，是不是可以只做主数据这一块，其他的先放一放？

陈晓芸：质量做成工单而不是报表，这句话我记下来了。我们现在就是每月出一堆质量报告，问题照旧重复发生，确实缺闭环。

周立群：写得挺实在，没有一味吹工具。治理这事儿确实是组织问题大于技术问题，深有同感。