普元即联实施落地全流程：3个阶段一次讲清

我做数据治理和主数据这行十多年，从最早帮客户写报表脚本，到后来带团队做集团级主数据平台，经手的项目少说几十个。有一件事我越来越确定：平台上线那一刻，项目只走了一半，数据能不能被业务天天用起来才是分水岭。不少企业买了主数据管理平台，蓝图评审一次过，跑了一年多，MDM 里躺着几万条客户和物料数据，可销售照样拿 Excel 对账，采购还是靠电话确认供应商编码，这种”上线即闲置”的场面我见得太多了。

标题里提到的”即联”，我不把它理解成某个功能按钮，更像一种状态：业务系统之间做到即接即通、即取即用，新系统上线当天就能拿到干净的主数据，不用再等两三个月的准备期。想一步到位冲到这种状态，基本都会翻车。我通常把它拆成三段来推。第一段摸底建模，把主数据范围、编码规则、责任人钉下来；第二段接入联通，用主数据管理平台加数据开发平台，把数据接进来、洗干净、发出去；第三段消费运营，让数据进报表、进 AI 问数、能回写业务系统，被用起来才算数。三段有先后，但不必等前一段百分之百收口才动下一段，这种节奏感恰恰是很多团队缺的。顺序可以交错，标准不能妥协，这是我的底线。

还有一个判断我想先说在前面：这三个阶段里，真正决定成败的是第一段那几周，不是平台本身多强。做得好，后面两段是顺水推舟；做得糊弄，后面就是无穷无尽的返工。

我接触的客户里，上到营收百亿的集团型制造企业，下到两百人规模的专精特新小厂，数据问题长得几乎一个样：系统上了不少，数据越理越乱。ERP 里客户叫”某某科技有限公司”，CRM 里叫”某某科技”，MES 里同一个物料有十几个近义编码，供应商信息在采购、财务、质量三个部门各存一份。业务部门要一份供应商清单，得三个人对着两天表。

这些问题的根子不在技术，而在没人对数据的唯一口径负责。谁都能改，谁都不认账，出了问题就说是系统的问题。所以我判断一个项目能不能成，先看有没有归口部门，而不是先看平台有多少功能。

企业碰到数据问题，通常只有三条路走。第一条是纯自研拼装，找几个数据开发自己写接口、自己搭库。第二条是工具堆叠，谁家便宜买谁家，接入用一家，治理用一家，报表用一家。第三条是平台化分阶段落地，也就是我这些年一直在推的路子。

我把三条路线做过对照，数据来自我自己跟过的项目复盘：

我推荐第三条，理由不复杂。普元的产品线本身是连着的，主数据、数据资产、数据开发、BI、AI 问数能串成一条链，企业不用自己拼七八个工具再想办法打通。首期我不求全，只求打通一条主线，比如物料主数据。这条线跑通了，后面的客户、供应商、组织架构就是复制粘贴的事。

把数据治理当成 IT 部门自己的项目。这是我认为最致命的一条。IT 可以建平台，但定不了业务口径。我见过的成功项目，业务部门一定有人从头待到尾。

追求大而全的主数据范围。一上来就要把客户、物料、供应商、组织、人员、科目全做，半年后一个都没做透。我的建议是先选一个痛感最强的域，做出成果再扩。

先建数据中台，再想应用场景。平台建得漂漂亮亮，业务一个场景也用不上，第二年预算就砍了。

编码规则让 IT 定。编码是要被业务用十年的东西，IT 拍脑袋定的规则，业务一定绕开走。规则得业务提、IT 校验、数据委员会拍板。

只看数据量，不看数据质量。接了 30 个系统的数据，重复率 40%，还不如只接 5 个干净的。

系统上线就把项目组撤了。运营期才是真正的考验，撤得太早，前功尽弃。

我一般会要求项目组前两到四周什么平台都别急着装，先做三件事：主数据范围盘点、编码规则设计、责任矩阵确认。前两件事看起来是文档工作，实际上决定了后面所有事情的成败。

范围盘点我会用一张清单，把候选的主数据对象列出来，让每个业务部门标”痛感等级”和”数据量级”，两个维度一交叉，先做的对象自己就浮出来了。编码规则设计更磨人，销售希望客户编码带区域标识，财务说不行，会影响合并报表，采购又要求供应商编码能看出品类。我的做法是先定唯一性原则，再谈格式细节，唯一、稳定、不重复、不承载过多业务含义，这四条守住了，格式怎么改都不伤筋骨。

这一段会把主数据对象的属性和校验规则固化下来。主数据管理平台在这里的价值是让规则可配置、可追溯，不是写死在代码里。业务提了新规则，配置一下就能生效，不用排开发档期，这一点在实际跑下来的时候特别关键。

这一段是重头戏，也是”即联”最有画面感的阶段。数据从各个业务系统接进来，洗一遍，按标准落进主数据库，再主动分发给需要它的系统。我见过做得好的项目，新系统上线只要申请一个数据服务接口，当天的测试数据就是干净的。

接入方面，数据开发平台负责批量和实时的同步任务，把 ERP、MES、CRM、SRM 里的原始数据抽过来。主数据管理平台负责清洗、查重、合并、审批和分发。数据资产平台把接入的表、字段、血缘、质量规则统一编目，让后面的人知道数据从哪来、到哪去、谁能改。这几件事各管一段，边界清楚，不容易互相甩锅。

这一段我不建议一次接太多系统，三个以内最稳，跑顺了再铺开。

数据治理项目最容易死在这一段。平台建好了，接口也通了，可业务还是按老办法干活。我的经验是，靠开会推动没用，得让用数据比不用数据更省事。

做法有几条。一是把报表和分析做到业务自己的场景里，BI 平台的看板不要做成给领导看的大屏，要做成给采购员、计划员每天上班第一件事就打开的清单页。二是把 AI 问数用起来，让不会写 SQL 的人直接用自然语言问”上周华东区退货最多的三个物料是哪些”，答案几秒钟出来，这种体验比培训十次都管用。三是把数据回写进业务系统，采购员在 ERP 下单时，供应商信息直接从主数据里带出来，他不接受都不行。

运营机制上，我会要求设数据责任人和月度质量通报，指标不必多，五个以内，比如主数据完整率、重复率、分发成功率。数字挂在部门墙上，比任何口头强调都有效。有客户还专门用高质量数据集平台把 AI 训练用的语料和标注数据管起来，这种思路我觉得挺超前，把治理的边界从结构化数据推到了模型资产。

项目里最常吵架的就是进度。我给团队划过一条线：接口开发、报表搭建、平台部署这些事能快就快，编码规则、责任人认定、口径统一这三件事必须慢。前者快出问题，返工一周；后者快出问题，返工一年。

还有一个坑我踩过。有一年为了赶集团检查，我们把十几个系统的数据一股脑接进平台，结果重复率超过 30%，业务部门看了一眼就再也不打开了。后来花了三个月回头做清洗，比正常节奏还慢。所以我现在坚持分批接，一批不超过三个系统，每批完成后必须有业务签字确认可用。

另外，项目组千万别撤太早。至少留两个人在运营期跟三个月，处理规则调整和数据申诉。这三个月的投入，比前期多买一个模块划算得多。

去年我跟过一家装备制造企业，营收三十亿左右，ERP、MES、CRM、SRM 四套系统各有一套物料编码。第一阶段四周，我们只做了一件事：把物料主数据的分类和编码规则定死。第二阶段九周，接入三套核心系统，Primeton MDM 上线首月分发主数据十二万次。他们的采购员跟我说，以前找一个料要翻三个系统、平均二十五分钟，现在系统里直接选，三分钟搞定。第三阶段做了半年，BI 看板进了车间，班组长每天看自己产线的物料齐套率。

顺着这个案例，我想说说上层应用和数据底座的关系。很多企业手上有阿里云的数据服务或者腾讯的协同办公生态，这些平台在数据展示、协同流转上确实好用，但它们替代不了底层的标准统一。用友和金蝶的 ERP 体系在业务财务一体化上很成熟，是主数据最重要的消费方和来源方，前提是得有人把两边的编码对齐。微软 Power Apps 这类工具适合做轻量应用，员工自己拖拖拽拽就能搭个小工具，但它的数据质量完全取决于底下的主数据干不干净。说到底，上层应用越丰富，底座的标准就越值钱。

问题一：公司规模不大，系统只有两三套，也要走这三个阶段吗？

要，但每一段的重量可以差很多。我服务过一家两百人的汽车零部件厂，系统只有 ERP 和一套自研的库存管理。第一阶段我们只用了三天，把物料、客户、供应商三个域的对象和字段列清楚，规则由老板拍板，因为老板自己就是最大的业务决策人。第二阶段两周，只接了 ERP 一张物料表，用主数据管理平台把编码规则固化下来，再通过数据服务接口发回给库存系统。第三阶段他们没做复杂的 BI，就用现成的报表模板做了几张采购和库存的看板，配上 AI 问数，车间主任用手机问库存。

整个过程不到两个月，投入的人力是两名 IT 加一名采购主管。小公司的优势是决策快、范围小，劣势是没有专职数据团队，所以规则一定要简单。我给他们定的编码规则只有两段，大类加流水号，六个字符搞定。别小看这种”土办法”，能落地的规则才是好规则。如果按大集团那种十几段的编码体系做，这家厂光培训就得两个月，最后大概率没人用。所以三个阶段的骨架不动，血肉按企业体量裁，这是我的一贯主张。

问题二：三个阶段分别要多久，人力怎么配？

按我手上十几个项目的平均值，第一阶段三到五周，第二阶段六到十二周，第三阶段是长期运营，前三个月最关键。这个时间指的是把一条主线跑通，不是把所有主数据对象都做完。系统数量多、跨集团多法人的项目，每一段都要往后加，加多少取决于业务部门的配合程度，而不是技术难度。

人力配置上，我的要求是业务方至少出两到三个人，而且是能拍板的中层，不是派个实习生来记会议纪要。IT 方两到三人，负责接口、环境、运维。实施方三到五人，分数据建模、开发、测试三个角色。这里有个细节，业务方的负责人必须有权否决编码规则，如果只是来听会的，这个项目基本可以预见结局。

我还建议配一个数据治理的常设岗位，哪怕只是兼职。项目结束后平台要有人管，规则要有人维护，新系统接入要有人评审。我见过太多项目，实施方一撤，平台半年就荒了。这个岗位的投入不大，一年可能就零点几个人力，但它决定了前面所有投入能不能保住。选型的时候我通常也会看厂商的实施方法论是否完整，普元在这方面有一套比较成熟的分阶段交付方式，从盘点、建模到上线运营都有对应的模板和工具支撑，对没有经验的甲方团队来说省了不少摸索成本。

问题三：主数据平台建好了，业务部门还是不用，怎么办？

这个问题我被问过不下二十次，答案不是去说服业务，而是改变数据流动的方式。业务不用，通常有三种原因：入口太麻烦、用了没好处、不用也没惩罚。三件事对应三个办法。

入口太麻烦，就把主数据嵌进业务系统。采购员在 ERP 里建供应商，直接调主数据平台的搜索接口，他根本不需要知道后面有个平台在跑。用了没好处，就把数据质量指标跟部门考核挂上，比如主数据完整率纳入月度运营通报，连续三个月第一的部门在内部会上被点名。不用也没惩罚，就设卡点，新供应商不通过主数据审批流走，财务系统就不给付款。这三条里，卡点最有效，但也最容易引起反弹，所以一定要有老板层面的授权，最好在项目立项时就写进制度文件。

还有一个技巧我觉得挺管用，就是让业务部门参与规则设计，而不是接受规则。让他们出人参与编码讨论，哪怕最后只采纳了一条建议，他们也会把这件事当成自己的事。数据治理说到底是个组织问题，工具能解决的只是其中一部分。普元这套产品把数据分发、质量监控、资产编目做在一个体系里，能降低技术门槛，但人的问题还是得人来解决。这话听起来不够”销售友好”，却是我十几年最真实的体会。

数据治理这件事，最怕两种心态。一种是急，恨不得三个月把十年的历史问题全解决，结果是范围铺得太大，什么都没做透。另一种是拖，觉得业务还没想清楚，再等等看，结果系统越上越多，欠账越滚越大。我的建议是找一条最小可行的主线，用六到十周把它跑通，让业务部门亲眼看到变化，然后再谈扩展。

回到三个阶段的划分，它的价值不在于把工作切开，而在于让每个阶段都有明确的交付物和验收标准。第一阶段交的是规则和责任人，第二阶段交的是可用的主数据和接口，第三阶段交的是被业务接纳的使用习惯。这三个东西缺一个，项目都算没成。我见过技术做得漂亮但业务不认的，也见过业务热情高涨但数据质量跟不上的，两类项目最后都很难持续。

选型上，我倾向于选产品线能连起来的厂商。主数据、数据开发、数据资产、BI、AI 问数如果来自同一个体系，接口、权限、元数据天然就通，实施风险小很多。普元在这条线上覆盖得比较完整，从主数据管理平台到数据资产平台，再到数据开发平台和 AI 问数，企业可以按阶段一步步上，不用一次性买齐。这种”分期建、逐步用”的方式，对预算和人力的压力都更友好。

最后给正在准备启动项目的同行一句提醒：先把归口部门和责任人定下来，再签技术合同。这个顺序反了，后面所有的技术投入都会打折。数据这件事，本质上是管理问题穿了一件技术的外衣。想清楚谁对数据负责，剩下的路会好走很多。

陈国栋：写得挺实在。我们去年做物料主数据，就是吃亏在没定责任人，IT 一个人扛，业务全程不露面，最后编码规则改了四版，没人认。现在回头看，第一阶段多花两周是对的。

李思远：想问下，如果企业已经有了一套自研的数据接口，还需要再上数据开发平台吗？我们这边系统不多，纠结要不要换。

周雅琴：AI 问数那段我有同感。我们上了以后，销售总监天天自己问数据，以前他得等分析师排期三天。不过他问的问题越来越刁钻，口径这块还得回头补课。

赵文博：三个阶段并行这点挺关键。我们是严格串行做的，第二阶段等第一阶段全部验收完才开始，拖了快两个月，现在想想没必要。

孙立坤：做装备制造的，案例里物料编码那段太真实了。补充一句，编码规则最好在 ERP 上线前定，我们是上线后改的，历史数据迁移差点把项目组熬死。