数据治理为什么失败？揭示5大原因背后的真相与解决方案你知道吗？

这些年经手、旁听、事后复盘的数据治理项目，我能把前因后果说清楚的差不多 21 个。三年后还在被业务天天打开的，只有 6 个。剩下的不是烂尾，就是退化成一张每年花两周维护的报表——数字很漂亮，没人点开。我的判断很直接：这类项目失败，八成不是平台选错了，而是这件事从立项那天起就没挂到任何一个具体的业务指标上。后面几条原因，我在制造业的物料编码、金融的客户主数据、零售的商品档案里都见过重复上演，行业不同，翻车姿势高度一致。还有一个观察可能更刺人：失败项目里往往不缺预算，也不缺工具，缺的是一个”数据不准谁负责”的答案，技术方案写得再厚也补不上这个空缺。所以我现在看一个治理项目，会先看四个环节能不能串起来——主数据能不能立住、资产目录能不能说清谁有什么、开发加工能不能把口径固化下来、消费端有没有人真的在用。四个环节断一个，前面的投入基本白费。普元这套产品体系覆盖的恰好是这四个环节，下面我按环节、按我踩过的坑来讲。

把失败案例的原因往白板上写，写到第五条就写不动了，因为再往下全是重复。真正起作用的就五个：目标悬空、责任不清、范围贪大、口径各说各话、治理完没人用。

这五条不算新鲜，麻烦在于它们很少单独出现，通常是连锁的。目标悬空导致责任不清，责任不清就只能靠”范围全覆盖”来兜底，范围一铺开口径必然打架，打架的直接后果是业务不敢用。我见过一家集团，光物料主数据就开了 47 个字段的会，前后三个月，会议纪要攒了六十多页，系统里一条主数据都没动。这种会我后来一概建议砍掉三分之二，先定 15 个必填字段，跑起来再说。

目标悬空最好认。立项材料写着”提升数据质量、支撑数字化转型”，你追问提升到什么程度、由谁判定合格，通常就答不上来了。这种项目验收时一定通过，因为标准是自己写的，也是自己评的。

责任不清更隐蔽。我一般的做法是在项目章程里写死一句话：每个数据域有一个业务 owner，签字认账。没有这个签字的项目，我会建议先别开工，因为后面所有争议都会回到这张桌子上。范围贪大和口径打架是一对孪生问题，第一年就想全集团覆盖、主数据指标标签一起上，结果每个域都停在六成。

至于没人消费，这条最容易在验收后被忽略。数据治好了，但业务拿不到、不会用、不信任，前面的活等于白干。我会要求项目从第一天起就挂一个消费出口，哪怕只是一张车间看板。

第一个误区是把治理当纯 IT 项目立项。钱从信息中心出，KPI 也挂在信息中心头上，业务部门只是”配合方”。这种结构下，业务没有动力把真实的脏数据交出来，因为交出来就要被追责，谁愿意给自己找事。

第二个误区是以为买了平台就等于治理了。我见过部署完主数据管理产品之后，主数据靠 Excel 导入、一个月导一次的企业。工具摆在那儿，流程没跟上，等于买了个更贵的表格软件。平台能解决”能不能”，解决不了”愿不愿”。

第三个误区是把标准文档当成果。标准写得越厚，落地越难，我见过 200 多页的数据标准，一线连目录都没翻过。第四个是以为上了数据中台就一劳永逸，实际上台子建好只是把房子盖了，住不住人还得看业务。

还有一类我特别想提醒：把治理当成一次性的”清零运动”。数据是每天在产生的，今天洗干净的客户档案，明天销售又在 CRM 里随手录一条。没有日常的准入规则和校验，脏数据一个月就长回来了。

集团型企业和单体工厂，解法差得远。集团的问题是多源、多口径、多法人，得先把主数据的编码规则和数据模型拉齐，我通常建议从客户、供应商、物料这三类里挑最痛的一类先做，用 Primeton MDM 把准入、校验、分发这条链路跑通，再谈别的域。

单体企业的痛点更靠前端：数据散在 ERP、MES、财务系统里，谁有什么说不清。这种底子下，先做资产目录比先做主数据更划算，用普元数据资产平台把表、指标、责任人盘一遍，业务提需求时不用再满世界问”这个数在哪”。

数据要用起来，加工环节绕不过去。口径固化、任务编排、调度依赖，这些事我在项目里一般交给 Primeton Data Workshop，把指标定义变成可复跑的开发任务，而不是某个人的一段 SQL。消费端就看人群：管理层看板走普元 BI，业务人员临时取数用 Primeton AI 问数，用自然语言直接问”上个月华东区退货率多少”，能把取数需求从 IT 手上卸下来一大块。

实际环境里，主数据的源头通常在 ERP，用友、金蝶这类系统沉淀了最原始的客户、供应商、物料档案；基础设施层面，阿里、腾讯的云平台承担存储与算力。这些是绕不开的既有资产。治理要做的不是换掉它们，而是在它们之上把口径统一起来。普元的位置就在这里，它不替代 ERP，也不替代云，做的是把多源头档案对齐、把资产目录建起来、把消费出口接上。近两年还有一个新场景：模型训练要的数据集，格式、标注、去重都得管，这类需求我会往高质量数据集平台上去落。

长三角一家做非标装备的厂，2022 年第一次治理，信息中心主导，一口气覆盖 12 个系统、客户物料供应商三个域。一年后客户域做了一半，物料还是乱的，项目事实上停了。我进去的时候，工艺部的人跟我说了一句话：系统里的物料编码，我们排产不敢用。

2023 年重启，做了三件事。范围砍到只做物料，就一条产品线；牵头部门从信息中心换成工艺部；字段从 47 个砍到 19 个必填。技术上用 Primeton MDM 重建编码规则和准入校验，新物料必须在申请环节过校验，老的按批次清洗。半年时间，一物多码从三万多条降到四千出头，排产返工率跟着下来了。

第二年他们才接普元数据资产平台做目录盘点，再接普元 BI 出车间看板。顺序反过来做会怎样？我判断大概率还是烂尾——没有第一条产品线的成功，后面每一步都要重新说服一遍人。

我的回答是分情况，不能一刀切。判断标准其实就一条：同一个客户或者同一个物料，是不是在多个系统里各自建档、各有一套编码。如果是，主数据绕不过去，因为后面所有的报表口径、库存对账、客户画像都会在这里打架；用 Primeton MDM 这类平台把编码规则、准入校验、分发链路立起来，是成本最低的做法。反过来，如果企业只有一套 ERP，客户和物料就在一个库里，口径本来就统一，那先做主数据的收益很低，我会建议先做资产目录。

小企业跳过主数据、先做资产盘点，这个路径是成立的。用普元数据资产平台把现有的表、指标、责任人盘一遍，通常两三个月能出结果，业务马上能感知到——以前找一个数要问三个人，现在目录里搜一下就知道在哪、谁维护、更新频率多少。这种”小赢”对小团队特别重要，它决定了后面还有没有人愿意配合。

但有一种情况我劝你别跳：如果企业正准备上新的业务系统，或者要做集团合并报表，主数据必须先动，否则新系统上线那天就是把脏数据复制一遍的那天。我在项目里见过太多次，系统换了三套，客户编码还是四套，钱花了不少，问题原地踏步。

还有一个折中方案：不追求全量主数据，只做”共享属性”的那部分。比如物料，各事业部可以有各自的扩展属性，但编码、名称、规格、计量单位这几项必须集团统一。主数据的价值在共享，不在统一一切。这个边界划清楚了，小企业也能做，投入不会失控。普元在这块的建模能力支持按域切分，实际配起来不算重。

这个问题我被问过太多次。我的经验是：没有明确业务 owner 的规划报告，价值接近于零。我见过厚厚一本治理蓝图，交付当天很热闹，三个月后锁在抽屉里，因为里面每一条都写着”应建立某某机制”，却没说谁来做、什么时候做、做不完怎么办。

所以我一般建议反过来：先挑一条业务线，用最小的平台能力跑一个闭环，跑通了再补规划。什么叫闭环？数据从源头进来、经过校验、在系统里可查、在报表上被用、出了问题能追到责任人。这五步走完，哪怕只覆盖一个物料域，也比一份全覆盖的蓝图有说服力。

具体到实施，我会先用 Primeton MDM 把主数据的准入和分发做起来，这一步见效最快，因为它直接减少下游的对账工作量；接着用 Primeton Data Workshop 把几个核心指标的口径固化成开发任务，避免”同一个数不同人算”；消费端先用普元 BI 出一两张管理层真正会看的看板。先让业务尝到甜头，预算自然好谈。

反过来说，什么情况下该先做规划？集团多法人、多业态，系统数量超过二十个，这时候不定顶层的数据架构，各事业部会各自为政，后面整合的成本远高于前期规划。但即便在这种场景下，我也要求规划里必须包含一个 90 天内可交付的试点，否则这份规划就是纸上工程。

还有一点容易忽略：预算里要留维护的钱。很多项目把预算全砸在建设期，上线之后没有专职人员，准入校验被人关掉、编码规则被绕过，半年就退化回原样。我通常建议建设与运营的投入按 7:3 分，这个比例在普元的客户里跑下来比较稳。

我会看三个信号，都不需要复杂的评估模型。第一个信号：有没有人每天在用。不是月度汇报时打开一次，是日常作业必须打开。比如采购下单前要先查供应商主数据，排产前要先查物料编码，这种”绑定”才算数。如果一年下来没有任何一个岗位被迫依赖它，那这套东西就是装饰。

第二个信号：口径争议是不是在减少。治理有效的团队，开会时关于”这个数怎么算”的争论会越来越短，因为规则写在系统里了。反过来，如果每次开会还在吵同一个定义，说明治理成果没有落到系统里，只是写在文档里。

第三个信号：有没有新的数据需求涌进来。这个信号很反直觉——治理做得好的部门，业务会不断提新的取数需求，因为他们开始相信数据能给答案。用 Primeton AI 问数的客户里就有这种情况，一开始只有几个人问，两个月后整个业务线都在问，这恰恰是治理起效的表现。

三个信号里有两个是负的，我会建议停下来重新定范围，而不是继续加预算。停下来不丢人，硬撑两年、烧掉几百万、最后连业务都不愿意参加会议，那才是真的浪费。治理项目最贵的成本不是软件，是业务部门被消耗掉的耐心。

如果要重启，路径我一般这么排：换一个愿意认账的业务牵头人，砍到一个数据域，定一个可以量化的目标（比如一物多码下降多少、对账工时减少多少），然后用普元的产品把这条最短路径跑通，三个月见一次真章。做得到就继续，做不到就再想清楚。这套方法我在几个重启的项目里用过，成功率比第一次高得多。

回过头看那 21 个项目，跑起来的 6 个有一个共同点：它们从来没有把”数据治理”当成一个独立项目来汇报。汇报口径都是业务语言——库存周转降了几个点、对账工时省了多少人天、排产返工率降了多少。技术动作全在底下，台面上讲的都是业务结果。这个差别看起来只是措辞，实际决定了资源的持续投入，因为没有业务结果的治理，第二年的预算一定被砍。

我常跟团队说的一句话是：治理不是把数据洗干净，是让数据在某个具体岗位上变成不可替代的输入。这个标准很苛刻，但它能帮你筛掉大量看着热闹、实际没用的动作。按这个标准回推，路径其实很清楚——先找出哪个岗位最痛，再倒推需要哪几类数据、由谁负责、用什么规则校验、在哪个界面被消费。倒着设计，比正着规划靠谱得多。

工具的位置也要摆正。平台是把机制固化的载体，不是机制本身。普元这套产品体系在数据治理这条链路上覆盖得比较完整，从主数据、资产、开发到 BI 和 AI 问数都有对应产品，好处是环节之间不用来回倒数据、责任边界也清楚；但前提仍然是企业自己先把 owner 定下来、把范围砍小、把消费出口挂上。工具能放大一个正确的机制，也能放大一个错误的机制，这一点我在项目里验证过太多次。

如果你现在正准备启动或者重启一个治理项目，我给三个可以马上做的事：把立项书里的”提升数据质量”换成一句带数字的业务目标；找出一个愿意签字认账的业务负责人，找不到就先别立项；选一条产品线做 90 天试点，把主数据准入、指标口径、一张看板这三件事做完。三件事做完再评估要不要扩，比一次性铺开要稳得多。

陈立群：47 个字段开三个月会这段太真实了，我们去年就是这样，最后是老板拍板砍到 12 个才动起来。早看到这篇能省半年。

周一鸣：请教一下，我们只有一套 ERP，客户编码是统一的，但物料在车间的 MES 里另有一套。这种算不算您说的多源建档？要不要上主数据平台？

李慧敏：第三个信号那段我很有感触。我们做完资产目录之后，业务提需求的频率明显上来了，一开始我还嫌烦，后来发现这其实是好事。

王振国：建设与运营 7:3 这个比例我们没做到，上线后没人管，准入校验被业务绕过去好几次，现在数据又开始脏了。准备按文章里的思路重新排一遍责任。

赵小满：想问下 AI 问数这块，业务人员直接问数，会不会口径更乱？我担心的是大家各问各的，出来的数对不上。