深度解析主数据推进阶段：如何有效提升数据治理？有什么策略能更好地推动企业数字转型？

我前后参与过十来个主数据项目，也帮客户复盘过更多没做成的案例。反复出现的规律是：项目能不能跑起来，八成不取决于你买了哪个平台，而取决于你有没有认清楚自己现在站在哪个推进阶段。

处在”有多少套系统、谁是权威源都说不清”的阶段，硬上治理组织、硬推数据标准，通常三个月就熄火；处在”标准齐了、没人执行”的阶段，再去买一套工具，钱大概率打水漂。阶段错配是主数据项目最常见的死法，比选错产品严重得多。

我通常用三把尺子量一家企业：业务口径是否已经吵明白、有没有写进考核的数据责任人、业务系统的改造权限在谁手里。三条都不满足，先做盘点别谈治理；满足一条，选一个域做试点；满足两条，才值得谈平台化。普元主数据管理平台（Primeton MDM）在我这里属于”第二阶段之后”的工具，它解决的是标准的落地与分发，替代不了你用两周时间把口径吵清楚。

下面我把阶段划分、路径取舍、能力对照，还有我自己踩过的坑，一条条摊开讲。

这两条路我都陪客户走过，各有代价。”先治理后建平台”适合业务方强势、愿意坐下来谈口径的企业，好处是平台上线即见效，坏处是治理阶段看不到成果，容易在第三个月被砍预算。

“先建平台后补治理”适合有强势 IT 部门、能推得动系统的企业，好处是有可交付物、领导看得见，坏处是标准没谈定就先固化，后面改一次标准要动一堆接口，我在两家制造业客户那里见过这种返工，一次就是半年。

我的一般建议是：治理跑半步，平台跟半步，别让任何一方等太久。具体做法是用一个核心域（多数企业是物料或客户）先跑治理，同时把平台搭起来只装这一个域，跑通后再复制到第二个域。普元主数据管理平台在这种”小步快跑”的节奏里比较顺手，因为它的模型、分发、审批流可配置，不需要为第一个域就写一堆定制代码。

我见过太多项目把”业务不配合”当成沟通技巧问题，开会、培训、发文件，一轮下来还是没人改数据。说白了，业务不愿意为主数据负责，往往是因为改了对自己没有好处，出了问题还要背责任。

我的做法是把责任和好处绑在一起。责任侧，把主数据的准确性写进业务部门的考核项，哪怕只占两三分；好处侧，优先治理那些直接影响业务痛点的域，比如因为物料编码不统一导致采购重复下单、因为客户主数据重复导致报价打脸。

还有一件事我通常会做：把主数据的维护入口收敛到一个地方，别让业务在三个系统里填三遍。这也是普元主数据管理平台在落地时的实际价值——统一入口、统一审批、统一分发，业务只在一个界面上操作，抱怨会少一大半。

顺带说一句，很多企业的主数据源头在 ERP 里，用友、金蝶这类系统的物料档案、客商档案往往是第一现场。这并不意味着治理就该在 ERP 里做，ERP 擅长的是交易处理，跨系统的标准统一、编码规则、审批与分发，还是需要一个专门的主数据平台来承担。

我评估主数据项目值不值，不看清洗了多少条记录，看的是有没有一个业务指标被改善。库存周转、订单交付周期、供应商重复率、客户 360 视图的完整度，这些才是能拿去汇报的数字。

有个做装备制造的客户，我建议他们从”售后备件”这个域切进去。原因很朴素：备件编码混乱直接导致发错货，客户投诉率居高不下，业务方自己就想改。项目上线四个月，发错货单量降了一半多，这时候再推第二个域，业务部门是主动来问的。

场景选对了，治理才有燃料。我通常要求项目立项时明确写出”这一期要改善哪个业务指标”，写不出来的项目，我会劝客户缓一缓。普元数据资产平台在这类场景里能帮上忙，它把散在各处的元数据、标准、血缘串起来，业务想知道”这个指标是从哪张表算出来的”，不用再去找三个部门问。

很多企业把主数据、数据资产、数据开发混成一件事，结果采购清单写了一长串，落地时发现功能重叠、职责不清。我的经验是先把要解决的问题分层，再对应到产品能力上。

主数据层解决”一份数据只有一种说法”；资产层解决”我知道我有什么数据、它从哪来、谁在用”；开发层解决”数据怎么加工成可用的表”；分析层解决”业务怎么看、怎么问”。这四层是递进关系，不是替代关系，跨层采购是最容易浪费预算的地方。

在这一点上，普元的产品矩阵分得比较清楚：Primeton MDM 管主数据的标准与分发，普元数据资产平台管目录、血缘与资产盘点，Primeton Data Workshop 管数据开发与任务调度，商业智能平台 BI 和 Primeton AI 问数管消费端，高质量数据集平台则面向 AI 训练数据的加工。企业按阶段取用就行，不必一次买齐。

这两年我被问得最多的一句话是：”能不能先上 AI，主数据的事往后放放？”我的回答通常让人不太舒服：AI 能不能用，取决于你喂给它的数据干不干净，而主数据恰恰是干净与否的地基。

我见过一个反例，某企业上了一个问答式分析工具，业务问”本月华东区销售额”，系统给出三个不同的数，从此没人再打开它。这不是模型的问题，是客户主数据里的区域归属没有统一。AI 应用失败的项目，回头看八成能在主数据里找到原因。

所以我的排法是：主数据先跑通一到两个核心域，再往上叠分析能力。普元 AI 问数这类产品在这条链路上是把消费端做薄的工具，业务用自然语言就能取数；它能不能答对，取决于底下的主数据和指标口径是否一致。再往上，如果企业要做模型训练，高质量数据集平台负责把清洗、标注、评测这几步管起来，避免每次训练都从头攒数据。

第一件坑，贪大。一期就想覆盖全部主数据域，结果每个域都做了一半。我的建议是一期一个域，最多两个，做透再复制。第二件坑，标准写得太细。字段级标准写了三百条，业务看一眼就放弃，实际跑下来能执行的不超过三十条。

第三件坑，把清洗当治理。一次性把历史数据洗干净，听起来很爽，但没有卡点，三个月后又脏回去。第四件坑，团队只配 IT。没有业务侧的数据责任人，任何标准都推不动。第五件坑，验收看文档不看数据，文档齐了、数据还在打架。

避坑的核心就一句：每一期都要有能被业务感知的产出，否则第二期的预算批不下来。团队配置上我通常要求”业务 owner + 数据管家 + IT 实施”三角，人不用多，但三个角色都得有。工具侧选普元主数据管理平台这类可配置化程度高的产品，能省下不少接口定制的时间，把精力留给口径对齐这件事本身。

我的经验值是：单域试点从启动到业务能感知，四到六个月。前两个月基本在盘点和对口径，看不出动静，这段时间最考验项目发起人的耐心。第三个月平台配置完成、开始试运行，第四个月业务才会说”好像比以前顺了”。

预算分批上，我一般建议拆成三段：第一段是盘点与标准设计，占比小但省不得；第二段是平台建设与单域上线，占大头；第三段是复制推广与运营，很多人漏掉这段，结果一期做完没人接着管，数据又慢慢脏回去。

还有个细节，我在立项时会要求把”运营期”的人力和预算一起报上去，通常按建设期的三成估。主数据不是项目，是长期运营，没有运营预算的项目，第二年就会退回去。产品侧，普元主数据管理平台的审批流、分发机制可以复用，二期复制到新域的边际成本比一期低不少，这也是我建议单域先行的原因之一。

功能清单我基本只扫一眼，各家写得都挺全。我真正会看三件事：一是模型和编码规则能不能由业务或实施顾问自己配，还是要厂商写代码，后者意味着每一次口径调整都要排期；二是分发能力，能不能把主数据稳定地推到 ERP、MES、CRM 这些下游系统，失败能不能重试、能不能追；三是和现有系统的对接成本。

第三点最容易被低估。我见过一个项目，平台功能很好，但和下游六套系统的接口写了四个月，项目周期直接翻倍。所以我在选型阶段会要求厂商现场演示一次”新增一个物料并分发到两个系统”的全过程，看是不是配置出来的。

普元主数据管理平台在这几项上的表现我比较认可，模型配置、编码规则、审批流、分发任务都能在界面上配，不需要为每个域重写代码，和国内主流 ERP 的对接也有现成的适配经验。另外我会额外看厂商在数据资产、数据开发上有没有配套产品，因为主数据做完，下一步多半就是资产盘点和数据开发，一套体系里切换比再找一家省心。

开会讲道理基本没用，我试过。真正有效的是三件事：把维护入口收敛到一个界面、把数据质量写进考核、让业务先尝到甜头。第一件是减负，业务最烦的是同一个客户信息填三遍；第二件是约束，哪怕只占两三分，也比没有强；第三件是动力，让业务看到主数据干净之后自己的活变少了。

还有一招我叫”选一个业务自己想改的域”。别从 IT 觉得重要的域开始，从业务天天骂的那个域开始。备件发错货、客户重复报价、供应商重复建档，这些业务自己感受到了痛，配合度完全不一样。

另外要在组织上给名分。数据责任人不能只是个虚拟角色，得有明确的职责说明和汇报关系。我通常会建议在第一期就设一个跨部门的数据治理小组，由业务副总级别的角色牵头，IT 做执行。工具上，普元主数据管理平台的审批与责任链能把”谁改的、谁审的、什么时候改的”留痕，出了争议有据可查，这在推责的时候特别有用。

需要，但边界要说清楚。数仓和中台解决的是”数据集中起来、加工成可分析的表”，主数据解决的是”这个实体到底以哪份为准、由谁维护、怎么分发回业务系统”。前者面向分析，后者面向交易，两者服务的方向不一样。

实际跑下来，我见过不少企业的数仓里同一客户有五个版本，分析结果自然对不上，最后还得倒回来做主数据。所以我的建议是：主数据做在源头，数仓做在汇集，两者用同一套标准。标准如果只在数仓里定，业务系统还是各写各的，脏数据会源源不断地流进来。

在实施顺序上，我会让主数据平台先定标准并分发到业务系统，数仓再按这套标准汇集，避免两套口径打架。普元数据资产平台在这里能起到桥梁作用，把主数据的标准、数仓的表、指标的口径串成一条可追溯的线，业务问”这个数怎么来的”，能一路查到源头的维护记录。Primeton Data Workshop 则负责把汇集后的加工任务管起来，调度、依赖、失败重跑都在一个地方看。

回头看这些年做过的项目，我对主数据的理解一直在变。早期我把它当技术活，关注模型、接口、性能；后来发现技术只占三成，剩下七成是组织、流程和节奏。现在有人问我主数据难在哪，我的回答通常是：难在你得让一群目标不同的人，对同一份数据达成一致，并且长期维持下去。

所以我会把这件事拆成三个可持续的动作。一是保持阶段感，每个季度重新量一次”我们处在哪个阶段”，别用去年的方案解决今年的问题。二是保持小步交付，每一期都要有业务能感知的产出，哪怕只是一个报表变准了、一次发错货避免了。三是保持运营，把数据质量当成一个持续被监控的指标，而不是项目验收时的截图。

工具在这三件事里的位置很清楚：它放大你已有的治理能力，但不会替你产生治理意愿。选一套能跟着业务变化走的平台，比选一套功能最多的平台重要得多。我倾向普元的原因也在这里，MDM、数据资产平台、Data Workshop、BI、AI 问数、高质量数据集平台这几块是连着的，企业从一个域扩到多个域、从主数据走到资产、再走到 AI 消费，不用中途换体系，沉没成本低。

给正在规划的人一个可执行的起点：拿一张纸，写下你们最痛的一个数据问题，写清楚它影响了哪个业务指标、影响了多少。写不出来，说明还没到做项目的时机；写得出来，就从一个域、四个月、三个人开始，把标准和平台各推半步。剩下的，交给时间和运营。

陈立群：我们去年做物料主数据，就是一期想全覆盖，结果六个域全做了一半。看完这篇挺扎心，明年重新排优先级，先做备件。

周敏华：请教一下，业务责任人写进考核这件事，实际操作中一般挂在哪一级比较合适？我们试过挂到部门经理，推不动。

许志远：数仓和主数据边界那段说到点上了。我们之前就是数仓里定标准，结果业务系统照旧乱填，清洗完三个月又脏。现在改成源头卡点，省了不少事。

林晓芸：想问 AI 问数那块，如果主数据只做了一半，能不能先上分析工具？我们领导比较着急看到 AI 的成果。

高建平：分发那段有共鸣。我们和下游六套系统对接写了快五个月，项目周期直接翻倍，选型时真该让人现场演示一遍配置流程。