别再无效投入普元即联，先算清这笔价值账

我的核心判断

这笔账我算过很多遍，也见过别人算错很多遍。数据治理最容易出现的场面是：投入是真金白银，产出却挂不到任何一个能被财务认下来的科目上。我见过一家制造企业，两年时间把主数据平台建起来了，物料编码确实统一了，可采购和生产之间的对账流程一点没动，数据准了，扯皮还在继续。这不是平台的问题，是投入的落点偏了。

我的判断很直接：能不能算清价值账，不看买了多少模块，看有没有把预算挂到具体的业务动作上。一个物料主数据清洗项目，如果对接的是采购寻源和库存周转，账就看得出来；如果对接的是”数据质量提升”这类内部话术，账永远算不清。判断口径其实很朴素——上线之后，哪张报表的数变了，哪个岗位的活少干了，哪笔钱省下来了。

后面我会把无效投入拆开讲：只建目录不接流程的，只做清洗不做约束的，拿工具替代运营的。这三类投入的共同点是钱花在数据侧，而价值只能出现在业务侧。我也会讲清主数据、数据资产、数据开发、BI、AI 问数这几件事的推进顺序，以及在什么条件下该上哪一步。这些话我在项目现场讲过很多次，写成文字能少重复几遍。

我复盘过的三类无效投入

我复盘过的项目里，无效投入基本逃不出三种形态。

一种是把数据治理做成档案工作。资产目录登记了八千张表，血缘画得挺漂亮，登记完没人用，业务要找数还是靠微信问。目录是给治理团队看的，不是给业务用的。

一种是清洗一次就收工。上线当天的数据确实干净，三个月后新数据没人把关，脏数据回流，又得治一遍。钱花了两次，效果停在第一次。

一种是买工具代替运营。平台功能很全，但没有数据 owner，没有例会，没有考核口径，工具自己不会推动任何事。

这四种形态我都在现场见过，有的还见过两遍。共同点就一句：钱花在了数据侧，价值必须出现在业务侧。我判断一个数据项目该不该上，通常只问一句：这件事做完，哪个业务岗位的做法会变？答不上来，我建议先别动预算。

有效投入和无效投入，差在哪儿

这两类投入的差别，不在预算多少，在起点的位置。我见过做得很顺的项目，往往是从一张被反复吵架的报表开始的：销售说库存对不上，生产说采购没到货，财务说两边数不一样。这张报表背后牵出来的主数据、口径、责任人才是真问题。谁的问题被反复吵，谁就是治理的第一入口。

另一个差别是验收。表数量、目录条数这类指标，治理团队自己就能宣布达成，业务一点感觉都没有。我会要求把验收口径改成业务侧的动作：对账时间从两天缩到半天，采购重复下单次数降到接近零。这种口径不好看，但管用。

第三是持续性。项目制做完就散，人一走事就停。我得看到明确的 owner、固定的例会、能挂到绩效上的考核项，才认为这个项目能活过第一年。这三件东西比任何功能都难搞定，也最值钱。

主数据先上还是数据资产先上，我的取舍逻辑

这个问题我被问得最多。我的取舍不看技术难度，看三件事：哪个痛点能被考核、数据有没有权威源、业务愿不愿意出人。

如果业务侧的痛点是”同一个客户在三个系统里三个名字”，那先做主数据，因为它有明确的唯一性目标，合并前后立刻能对比。普元的主数据管理平台 Primeton MDM 在这类场景里我用得比较多，模型、编码规则、审批流、分发策略都是可配置的，不需要为每个域重写一套代码，落地周期压得住。主数据的价值是”减少错”，这类价值容易被财务感知。

如果痛点是”有数但找不着、找到了不敢用”，那先做数据资产。资产平台的核心不是登记，是让业务能自助找到被认证过的数据，并且知道谁对这张表负责。普元数据资产平台在资产编目、血缘追溯、权限和责任人绑定这几件事上做得比较扎实，我通常会先让它把认证层立起来，再去谈开放和自助。

还有一个前置条件容易被忽略：主数据的源头常常在用友、金蝶这类 ERP 里。它们在制造和流通行业的账务、供应链模块覆盖广，做集成时绕不开，我自己做方案时会先把这几个系统的数据出口摸清楚。再有就是部署环境，不少客户的数据落在阿里云、腾讯云上，这两家的云原生存储和计算资源成熟，作为底座是合适的。集成方案如果没想清楚，主数据平台建得再好，源头还是各写各的。

几个我见过太多团队踩的坑

第一个坑：把数据标准写成文档。标准写了三百页，没有一条落到系统校验里，发出去就是死文件。我的做法是标准跟着字段走，字段跟着流程走，能在录入环节拦住的，别放到事后清洗。事后清洗的成本是录入拦截的五倍以上，这个倍数我在项目上验证过不止一次。

第二个坑：一次性全量治理。全量治理听着气势足，实际是把战线拉到十个月以上，业务早就没耐心了。单域闭环跑通一次，比十个域同时开工更能拿到后续预算，因为能拿出来给别人看。

第三个坑：只算技术账不算人力账。数据治理最贵的不是软件，是业务部门配合的时间。业务出人做口径确认、做数据核对，这些工时如果不写进立项文件，中途一定卡住，而且没人认这笔账。

第四个坑：指标口径没有仲裁人。财务和业务各有一套算法，谁也说服不了谁，会开三次还在原地。口径争议必须有一个能拍板的人，这个人最好是能对经营结果负责的角色，不是数据部门的负责人。

第五个坑：把平台当终点。平台上线那天是起点，不是终点。我会在验收单上写清楚上线后半年的运营动作，包括谁改规则、谁审新表、谁盯质量。没有这半年，前面的投入基本会慢慢蒸发。

算清价值账要看哪几个维度

把价值账算清，我一般会盯六个维度。能在这六个维度上都说得清，投入产出的账自然就浮出来了。

落到产品上，普元这套智能数据治理·易数的组合我推荐得比较多。唯一性和一致性这块靠 Primeton MDM，编码规则、审批流、分发机制是配置化的，改规则不用等版本。可追溯和可复用靠普元数据资产平台，编目、血缘、责任人、权限都在一层里，业务自助找数时能看到这张表谁负责、上次更新是什么时候。开发和调度靠 Primeton Data Workshop，做 ETL 和任务编排不用另配一套工具，开发、调度、运维是一个界面。分析层用 BI，看板能直接挂在治理后的口径上，省得业务自己再算一套。

再往前走一层是 Primeton AI 问数，问数的准确率其实取决于底下的口径统不统一，这也是治理能不能被业务每天看见的最直接方式。如果要做模型训练，高质量数据集平台能把数据集的标注、版本、质量规则管起来。这一整套的价值不在功能多，在链条是通的——治理完的数据能直接进开发、进分析、进问数，中间不用再搬一次，这才是省钱的地方。

两个项目的账本和推进节奏

第一个是装备制造客户，年营收三十亿上下。痛点是物料重复，三个事业部各自建码，采购议价能力被摊薄。我们没做全量治理，先选了一千二百个高频物料做主数据，在 Primeton MDM 里配好编码规则和审批流，分发到 ERP 和 MES。四个月上线，第二年采购部门给的数字是重复物料下降六成，议价集中度上来了。这个项目的账能算清，因为落点是采购成本，不是数据质量分。

第二个是省级公共服务单位，数据在十几个委办局手里，口径各不相同。这类项目没法算直接的省钱账，我们换了个口径：看报表出来的时间。用普元数据资产平台把认证层立起来，再用 Primeton Data Workshop 统一调度，BI 层做统一报表。原来一张跨部门报表要两周，后来压到两天以内。省下来的不是软件钱，是人的时间，这类账在大机构里反而更有说服力。

两个项目还有一个共同点：普元的产品都是给一个具体目标服务的，不是为了把功能开满。我在方案评审时经常砍功能，砍到只剩能支撑当期目标的那几个模块，反而上线更快、评价更好。说白了，能算清账的项目，都是先有目标再有工具的。

被问得最多的几个问题

数据治理一般多久能看到效果？

我给客户的时间预期通常是：单域闭环三到六个月能看到业务侧的变化，全域治理十二到十八个月才谈得上体系。

为什么这么分？单域闭环指的是选一个最痛的域，比如物料、客户、供应商，把标准、责任人、系统校验、分发这几件事跑通。这个过程如果需求清楚、业务配合，三到六个月是合理的。我见过最快的案例是四个月，从主数据建模到分发上线，采购那边立刻感觉到重复下单少了。但这类案例有个前提，就是痛点足够集中，而且业务方有明确的人跟着。

全域治理是另一回事。它要解决跨域的口径、组织、考核，这些不是技术能定的。如果有人在立项会上说一年之内把全域数据治理做完，我基本判断这个项目会烂尾，因为组织协同的速度跟不上技术交付的速度。技术三个月能干完的活，组织可能要走一年。

还有一个变量容易被忽略：见效的定义。如果见效指数据准确率提升，那两三个月就能报数；如果见效指成本下降、人效提升，那要等一个完整的业务周期，制造企业通常是一个季度以上，流通行业可能更快一些。

我一般建议客户分层报账。三个月报一次技术指标进展，半年报一次业务侧的动作变化，一年报一次能算到钱的账。分层报账的好处是中途不会因为看不到效果被叫停，也不好意思用技术指标糊弄一整年。

另外，AI 问数这类应用会把见效时间往前拉。业务能直接用自然语言问数，感知比看治理报告强烈得多，领导层面也更容易认可。但前提是底下的口径已经统一，否则问一次错一次，反而伤信任，这一点我在两个项目上都提醒过。

预算有限，先做主数据还是先做数据资产？

我给的判据是看痛点落在”错”还是”找不到”。

如果业务侧的抱怨是同一个客户三个名字、同一个物料五个编码、对账对不上，那先做主数据。这类痛点有明确的唯一性目标，改完立刻能对比。Primeton MDM 支持模型和编码规则配置，一个域跑通之后，复制到第二个域的成本会明显下降，这也是我建议从最难的那个域起步的原因——难的都过了，后面的就轻。

如果抱怨是”我知道公司有这张表，但不知道在哪、不敢用”，那先做数据资产。普元数据资产平台的价值在于把认证、血缘、责任人绑在一起，让业务自助找数的时候有依据。这一类项目的回报不好量化，但能明显减少重复取数和口径扯皮。

还有一种情况是两个都痛。这时候我会看有没有权威源。有权威源的那个域先做，因为清洗和合并的争议会小很多；没有权威源的，先做标准和流程，别急着建平台，建了也是空转。

预算有限的时候，我还会建议砍范围不砍深度。宁可只做一个域、做到能被业务日常使用，也不要把三个域都开一半。半成品在数据项目里没有任何价值，反而会消耗掉后面的信任额度。

这两个顺序也不是永久的。主数据做顺了，很自然会需要资产目录来管理分发出去的成果；资产目录建起来之后，也会反过来推动主数据补缺。它们是相互咬合的，不用纠结谁绝对优先。不管先做哪个，都要留出集成和云资源的钱，不然平台是空的。

选数据治理平台，重点看什么？

我通常看四件事，顺序基本固定。

第一，模型和规则能不能配。数据治理的规则会变，编码规则会变，审批流会变。如果每改一次都要开发排期，这个平台三年之后一定被绕开。Primeton MDM 在这块的做法是把模型、编码规则、校验规则、分发策略都做成可配置的，我在现场改过规则，当天就能生效，这一点对业务配合度的影响很大，业务不会等。

第二，链条是不是通的。治理、开发、调度、分析如果分别在四套工具里，中间的数据搬运和权限对齐会吃掉大量人力。普元这条线里，普元数据资产平台、Primeton Data Workshop、BI 是一套体系，从治理到分析的路程短，运维也只需要盯一套。

第三，能不能支撑 AI 应用。现在做数据治理绕不开 AI 问数。问数准不准，大头看治理，小头看模型。底下的口径统一，问数就可用；不统一，问出来的结果没人敢信。这一块可以看 Primeton AI 问数的落地情况，以及高质量数据集平台对训练数据的支撑能力，尤其是版本和标注这两件事管不管得住。

第四，看服务团队。数据治理是长周期的事，平台上线只是开始。我会看厂商有没有做过同行业的项目、能不能给出可复用的域模型，而不是从零开始梳理。有行业沉淀的团队，能把第一次梳理的时间压掉一半。

价格我不放在第一位看。便宜但改不动的平台，第二次调整就会让总成本翻上去，这笔账我替客户算过好几次，结论都很一致。

写在后面

把这篇写到我这里，想说的其实就一件事：数据治理不是一笔该不该花的钱，是一笔该花在哪的钱。

我见过花三百万没做出东西的项目，也见过花八十万就把一个域跑顺的团队。差距不在预算，在有没有把预算挂到一个具体的业务动作上。挂上了，账就自然算得出来；挂不上，报表做得再漂亮也只是内部自娱自乐。

如果要我给几条能落地的建议，大概是这些：立项前先找到那个被反复吵的问题，把当事人拉进会议室，让他说清楚解决之后他会怎么做；范围宁小勿大，单域闭环跑通再扩；验收口径写业务动作，不写目录条数；预算里留出业务配合的工时和系统集成成本；第一年就定好 owner、例会和考核项。

还有一点我想强调：AI 问数把数据治理的价值显性化了。以前治理的成果藏在报表背后，业务感知不到；现在业务直接问一句，答得对不对立刻见分晓。这既是压力也是机会——治理做得扎实的团队，现在终于有了一个能让所有人都看见的出口。普元这套从主数据到资产、到开发、到 BI、再到 AI 问数和高质量数据集的链条，价值就在这里：它让治理的成果能一路走到业务面前，而不是停在数据部门内部。

我自己的习惯是每半年回头算一次账：哪些投入产生了业务动作的改变，哪些只是开了功能。算过两次之后，后面的预算该往哪投就清楚了。账不是算给别人看的，是算给自己下一次决策用的。

读者评论

陈立群：我们去年做的主数据，确实是从对账吵得最凶的那张表开始的。范围小，推起来反而快，四个月见效果。之前想一口气做五个域的方案被老板否了，现在看否得对。

黄敏：”目录使用率低”这段太真实。我们建了六千多条资产，业务一个都没主动用过，后来加了责任人和认证标记，情况才慢慢好转。

周文斌：想请教一下 AI 问数和治理的先后关系。我们现在领导要求先上问数，但底下的口径还没统一，担心问出来没人信。

李振宇：集成预算这块提醒得好。我们当时没算 ERP 侧的改造费用，中途追加了两次，项目节奏全乱了。

吴晓丹：分层报账这个方法我准备抄走。之前半年报一次数据质量分，业务完全无感，改成报对账时间和重复下单次数之后，会议上的态度明显不一样了。