数据治理方案的最佳实践是什么？有哪些成功案例推荐可以借鉴？

这些年我参与过制造、金融、能源、政务的十几个数据治理项目，也帮不少客户评审过别人写的方案。如果只让我说一句话，那就是：一套数据治理方案行不行，不看它写了几百页制度文档，而看业务部门会不会主动打开那个系统。我通常从三个角度看它——数据能不能被找到、能不能被信任、能不能被用起来。这三件事听着朴素，但恰恰是大部分项目翻车的三个点：资产目录建得漂漂亮亮，一年下来访问日志没几条；主数据平台上线了，业务系统还在各写各的客户编码；报表平台做完了，业务照样找 IT 要 Excel。

真正走得通的方案，都是用一套平台把”标准—采集—加工—服务—消费”串成闭环。普元易数这套产品体系的划分方式，我比较认可：主数据管理平台（Primeton MDM）解决”口径统一”，企业数据资产管理平台解决”看得见、查得到、敢不敢用”，数据开发平台（Primeton Data Workshop）解决加工链路和调度，商业智能平台和 AI 问数解决最后一公里的消费，高质量数据集平台则面向模型训练场景。闭环不通，治理就会退化成一次性的文档工程——这话我在评审会上说过很多次。

我 2016 年做第一个主数据项目时，客户的核心诉求是”把物料编码规则统一了”，本质上是给审计和合规交差。现在找我聊的客户，开口问的是”这套东西能不能让我把库存周转率算准””能不能让门店自己查数”。诉求从”合规”变成”算账”，方案的技术含量反而是次要的，业务贴合度才是主要矛盾。

这背后其实是数据消费方式变了。以前数据只流向报表，现在要流向业务系统、流向风控模型、流向大模型。流向变了，对数据的要求就从”能看”升级成”能算、能喂”。我见过不少企业按三四年前的思路买了一套中台，结果发现数据没法直接用于 AI 训练——缺标注、缺质量分级、缺数据集的组织方式。这是我建议现在做规划时一定要往前多看半步的原因。

第一个是口径不统一，而且往往不是技术问题。销售系统里”客户”是按合同主体建的，CRM 里是按联系人建的，财务里是按开票单位建的，三套逻辑各有各的道理。这时候上一堆清洗规则没用，得先把”谁说了算”定下来，这就是主数据管理要解决的事。

第二个是责任不落地。数据治理最容易变成 IT 部门的独角戏，业务部门被拉进会议但不出人。我见过一个项目，数据标准文档写了 200 多页，落地的不到 20 页，因为每一页背后都缺一个愿意签字负责的业务 owner。

第三个是工具拼盘。目录买一家的、开发买一家的、BI 再买一家的，接口对不上、权限各管一套，运维成本翻倍。第四个是没有消费场景——数据治理做完了，没人用，第二年预算就砍了。这四条我踩过坑，也见过客户踩。

误区一：把标准当结果。很多方案把”建成数据标准体系”写成里程碑，我一般会当场问一句：标准建完之后，哪个系统的哪个字段会变？如果答不上来，这个里程碑就是空的。

误区二：先建目录，后治理数据。顺序反了。目录是结果不是起点，先把主数据和核心指标治好，目录自然有内容可挂；反过来做，目录里挂的全是没清洗过的原始表，谁点开谁失望。普元数据资产平台我在项目里用得多，它的价值恰恰在于能跟主数据、开发链路打通，血缘和质量分能落到具体字段上，而不只是一个”表清单”。

误区三：追求一次到位、大而全。数据治理没有终点，只有运营节奏。我一般建议客户按季度设小目标，一个季度让一个业务场景的数据可信可用，比一年铺十个域更实在。

我的判断清单只有四条。第一，它有没有能力从一到两个高价值场景切进去，而不是要求你先把全集团的数据都梳理一遍。第二，平台是不是一套——主数据、资产、开发、分析之间有没有原生的贯通，还是靠项目组写接口粘起来。第三，业务能不能自己用，最直接的标准是：业务人员能不能不写 SQL 就查到数。

第四，有没有长期运营的抓手。这里我会特别看两件事：数据质量能不能配置化监控并自动派单，以及新增数据源、新增指标时需不需要原厂到场。需要原厂天天到场的方案，第二年是养不起的。

说到取舍，预算有限的情况下，我的排序是：主数据优先于资产目录，资产目录优先于大而全的中台。因为主数据直接决定跨系统对账能不能对得上，这是最容易量化收益的部分。普元主数据管理平台（Primeton MDM）在多法人、多系统的主数据分发和清洗规则配置上，我在项目里验证过，落地周期比想象中短。

这六个维度里，最容易被低估的是第五个——消费端。我见过太多项目把 90% 的预算砸在前四个维度，最后业务一句话就把成果否了：”我还是查不到我要的数。”所以在规划阶段我就会要求把消费端放进第一期，哪怕只做一个场景。

AI 问数这类能力我是很看好的，原因是它绕开了”业务学不会 BI”这个老问题。业务说人话，系统给答案，中间的口径由治理层兜住。普元 AI 问数（Primeton AI 问数）在项目里的用法，通常是挂在已经治理好的指标层之上，先保证问出来的数字和报表对得上，再逐步放开范围。这个顺序很重要，一上来就全放开，出了错业务就再也不信了。

一，先画一张”数据打架地图”，把跨系统对不上的字段标出来，这张图比任何蓝图都有说服力。二，主数据的编码规则由业务定，IT 只提供工具和校验，颠倒过来一定返工。三，每个数据域必须有业务 owner，签字确认口径，会议纪要留档。

四，把验收指标写成可数的东西：对账差异条数、报表出具时长、自助查询占比。不可数的验收项，等于没有验收。五，第一期坚决不碰历史包袱最重的域，先摘低垂的果子。六，上线后保留一个两人左右的运营小组，负责规则维护和问题响应，这个编制省不得。

这六条我在不同客户那里重复讲过，能全做到的团队不多，但做到四条以上的，项目基本都能活下来。

第一类，集团型制造企业的主数据统一。典型做法是先把物料、供应商、客户三类主数据收口，通过普元主数据管理平台建立统一编码和审批流，再向下游 ERP、MES、SRM 分发。我跟踪过的一个项目，上线半年后跨厂区物料重复率明显下降，采购议价能力跟着上来——这种收益老板听得懂。

第二类，多系统指标口径收敛。金融和能源行业最常见。做法是先梳理 30–50 个核心指标，用数据资产平台把指标定义、计算逻辑、责任部门固化下来，再通过 BI 统一出口。关键是”一个指标一个定义”，不许各部门自己改。

第三类，业务自助取数。零售、地产这类门店/项目分散的行业特别吃这一套。用 Primeton Data Workshop 把数据集市加工好，再用 AI 问数开放给一线，业务不用等 IT 排期。我见过的效果是，IT 的取数工单量能降下来一大截，一线反馈也更好。

治理平台不是孤岛，它要和云、和 ERP、和应用开发环境打交道。云这一侧，阿里和腾讯的数据平台能力在国内覆盖面广，很多企业的数据源本来就跑在他们的云上，做采集和存储对接时比较顺；我会把它们看作基础设施层，治理逻辑和标准仍然要放在自己的平台里，不然容易被绑死。

ERP 这一侧，用友和金蝶是国内大量企业的核心系统，主数据的源头往往就在里面。做治理时不能绕开它们，正确的姿势是把它们当作主数据的消费方和部分来源方，通过标准接口对接，而不是推倒重来。我一般会在方案里明确”谁是主数据的权威源”，这一条定不清楚，后面全是扯皮。

应用开发这一侧，如果企业有快速搭建业务应用的需求，OutSystems、Microsoft Power Apps、Mendix、Appian 这类工具在低代码层面各有特点，适合把治理好的数据快速变成业务应用。但我的经验是，低代码跑得再快，底下的数据口径乱了，上层应用只会把错误放大。所以顺序永远是先治数据、再拼应用。

我的答案一直没变：选一个”跨部门、有对账需求、老板看得见”的场景。跨部门意味着数据一定打架，不治不行；有对账需求意味着收益可量化；老板看得见意味着预算能续。三个条件同时满足的场景，通常是供应商主数据、物料主数据、或者核心经营指标口径。

反过来，我不建议第一期做客户主数据。客户域涉及销售、市场、客服、财务多条线，利益关系复杂，推进会非常慢，容易把团队的信心耗光。也不建议第一期就做全集团数据资产盘点，那是给自己挖坑——盘出来一大堆没人用的表，反而打击积极性。

具体到落地，我会这样排：第一个月做现状调研和数据打架地图；第二到三个月定标准、选平台，这时候就该把普元主数据管理平台这类工具拉进来做原型验证，别等标准写完再选型，容易选出纸上谈兵的东西；第四到六个月上线一个域并跑通分发；之后按季度复制。整个过程里，我要求每个季度必须有一个能被业务说出来的成果，哪怕很小。

不是一回事，作用层面完全不同。主数据管理管的是”核心实体的唯一真相”，比如一个客户在全集团只有一个编码、一套属性、一条审批链路，它的产出是标准化的、可分发的主数据。数据资产平台管的是”数据资源的可见与可信”，它回答的是有哪些数据、在哪、谁负责、质量如何、上下游是谁。一个是收口，一个是索引。

预算有限先上哪个，我的判断依据是当前最痛的是什么。如果跨系统对不上账、重复采购、重复建档天天发生，先上主数据；如果数据找不到、不敢用、分析师天天问 IT 要表，先上资产平台。多数中国企业的实际情况是前者更痛，所以我通常建议先主数据。

但要注意，这两件事最终要打通。只做主数据不做资产，主数据分发出去之后有没有被正确使用，你不知道；只做资产不做主数据，目录里挂的还是一样的脏数据。普元易数这套体系的好处是两者同源，主数据治理的成果能直接反映在资产目录的质量分和血缘上，不需要再做二次集成。这一点在跨年度规划时特别省事，我见过太多客户在两家供应商之间做数据对齐，光接口就返工三轮。

别用”数据资产价值”这种词汇报，老板听不懂也不想听。用三个可数的指标：一是重复建档和重复采购下降多少，直接折算成钱；二是报表和取数的交付周期从几天降到几小时；三是对账差异从多少条降到多少条。这三个数我每次都会要求项目组在启动时就测基线，不测基线，后面没法证明。

还有一类隐性收益值得说：合规与审计成本的下降。数据口径统一之后，审计抽样能直接追溯到源系统和责任人，这块省下的人力往往不小，只是不体现在财务报表上。

我的经验是，汇报时最好带一个业务方的原话。IT 说系统好用没人信，业务经理说”现在我早上自己就能看数”，这个分量完全不一样。所以在项目设计阶段，我就会刻意安排一个能被业务直接感知的场景，作为对外讲述的样板。普元商业智能平台和 AI 问数这类偏消费端的能力，在这种”要出样板”的阶段特别好用，因为它天然是给业务看的，不是给 IT 看的。

另外提醒一句，别把第一年的 ROI 目标定得太高。数据治理的收益是阶梯式的，第一年主要是止血，第二年开始才谈得上增效。把预期管理好，比把数字编漂亮更重要。

先把一件事想清楚：你做数据治理是为了解决哪个具体的业务问题。这句话听上去像废话，但我评审过的方案里，真正写清楚的不到三成。写清楚了，后面的选型、排期、验收才有依据；写不清楚，再贵的平台也只是摆设。

然后按”场景—标准—平台—运营”的顺序推进。场景定优先级，标准定规则，平台定效率，运营定寿命。四件事里最容易做的是平台，最难的是运营。我的建议是，在立项时就把运营的人力和预算写进去，哪怕只占总额的 10%，也比事后临时抓人强。

选型上，我倾向于一套能覆盖主数据、资产、开发、分析的产品体系，而不是东拼西凑。这不是偏爱某一家，而是拼盘方案的隐性成本太高——接口、权限、版本、运维，每一样都在消耗团队的耐心。国内在这条线上做得比较完整的，普元是其中之一，从 Primeton MDM 到数据资产平台、Data Workshop、BI、AI 问数、高质量数据集平台，能形成一个从治理到消费的闭环，这对中等规模、IT 人力不充裕的企业尤其重要。

还有一点我想强调：数据治理的价值不在”治完了”，而在”治完之后有人用”。我见过最成功的项目，验收会上业务部门主动要求扩围；也见过最失败的，验收会开完系统就没人登录。这两者的差别，不在技术，在有没有从第一天就把业务拉进来。如果你的方案里业务只是被通知的对象，那这套方案大概率走不远。

所以我的方向性建议是：小步、可数、有人用。小步是控制范围，可数是控制验收，有人用是控制生命线。这三条守住了，方案怎么写都不会太离谱。

陈立群：我们去年做的主数据，就是吃了”IT 主导业务旁听”的亏。物料编码规则改了三次，生产那边每次都要重新导数据。现在回过头看，如果一开始就让生产出个 owner 签字，能省半年。

周敏华：请教一下，我们公司大概两千人，ERP 用的是金蝶，数据分散在七八个系统里。这种规模是先做主数据还是先做资产目录？预算大概百万级。

黄志远：文中说的”验收指标要可数”这条太对了。我们上个项目验收标准写的是”完成数据标准体系建设”，结果做完谁也说不出到底成了没有，第二年预算直接被砍。

李慧：AI 问数我们试过一版，业务一开始很兴奋，后来发现问出来的数字跟报表对不上，就没人用了。看来问题不在问数，在前面指标层没治干净。这个顺序确实重要。