如何实现主数据ERP集成？有哪些有效的方法论可供选择？

我做过十几个主数据项目，真正把进度拖垮的，很少是接口写不出来。ERP 那侧的 BAPI、IDoc、中间表、Web Service，方案早就成熟得很，随便找个顾问都能给你列一套。难的是前头那堆事：物料编码到底谁定，是研发提还是工艺提？供应商是采购部一家说了算，还是财务、法务都得签字？同一个集团法人，在 ERP 里挂着三个客户号，是合并还是保留历史？这类问题一天不拍板，接口就得改八遍。

所以我给同行的建议一直很直白：主数据与 ERP 集成，本质是一次治理授权的落地，不是一次系统对接。你得先把三个答案摆到桌面上——谁是数据的所有者、用哪套编码规则、变更从哪儿发起。这三个答案基本决定了后面的技术选型，而不是反过来让技术选型去倒逼业务妥协。

反过来，如果一上来就拉技术团队开会讨论走什么协议、用哪个中间件，八成会演变成”能同步就行”的样子工程。半年后业务再抱怨数据不准，你会发现根子还在一开始没治的地方。我的经验是，编码规则和责任边界定清楚，集成工作量能砍掉近一半；定不清楚，接口写得再漂亮，也只是给脏数据修了一条高速路。

还有一层容易被忽略：主数据和 ERP 不是平级关系。ERP 是被服务方，主数据平台是供给侧。供给侧要负责数据的完整性和唯一性，需求侧要负责消费时的合规使用，这个分工一旦模糊，后面所有的分发策略都会打架。我见过太多项目，就是因为两边都想当”老大”，硬生生把一个三个月的活拖成了两年。

路径选择这件事，我一般不让团队直接争论，而是先摆一张表，把实时性、耦合度、可追溯性、适用规模四列填满，再谈偏好。因为很多时候争的不是技术，是各自背的 KPI 不一样。

直连中间表这条路，很多团队起步时都走过。快，两三天就能跑通。但我踩过一次坑：ERP 打了补丁，物料主表加了两个字段，视图全废，半夜爬起来改存储过程。从那以后我对直连就很警惕。它适合做 PoC，不适合做生产主干。

ESB 中转的好处是解耦，坏处是主数据的语义容易在中转环节丢掉——比如你原本设计的”一物一码 + 版本号”规则，到了 ESB 那一层往往被压成一条平铺报文，谁改的、为什么改，全没了。平台分发的好处正在这儿：分发动作本身是可订阅、可回执、可重推的，出了问题能查到哪一条、哪一刻、给了哪个目标系统。这也是我在选型时最看重的一点。

普元的主数据管理平台 Primeton MDM 在这块做得比较扎实，分发策略可以按目标系统分别配置，物料走准实时、供应商走批量，不必一刀切。实际跑下来，这种”按域配策略”的能力，比一个笼统的”支持实时同步”要实用得多。

我见过的所谓方法论，大致能归成四类。第一类是字段映射驱动，拿两张表比字段，一一对应，写映射文档。这办法上手快，但它假设两边模型都是对的，而现实中往往两边都缺胳膊少腿。第二类是单一事实源，先定一个系统做主，其余全部订阅，这是最正统的思路，也是我在大多数项目里推荐的方向。

第三类是事件驱动，以变更为核心，任何一次主数据改动都产生一个事件，由订阅方消费。它适合数据变更频繁、下游系统多的场景，但对事件治理的要求高，事件定义不清就会变成消息洪水。第四类是资产摸底先行，先把现有数据资产盘一遍，知道有多少张表、多少条主数据、谁在用，再决定治哪儿。

我的实际做法是把后两类揉进第二类里去：用资产摸底确定治理范围，用单一事实源确定权威，用事件机制保证变更能追。这套组合拳在制造业和金融都跑得通。落到工具上，普元数据资产平台可以用来做前期摸底，元数据采集和血缘一铺开，很多”以为只有一张表”的事就露馅了；主数据建模和分发则交给 Primeton MDM。

完整的闭环我会拆成六步：定标准、建模型、清存量、控增量、准分发、常监控。六步里最容易偷工减料的是”控增量”和”常监控”，因为这两步不出活、不上线仪式感，但它们决定了半年后数据会不会重新变脏。这一点我在无数个项目验收会上强调过。

排期这件事，我一般按五段走。摸底两到三周，重点是搞清主数据域边界和系统清单，别急着画 ER 图。建模和规则设计四到六周，把编码规则、唯一性约束、审批流定死，这一段的产出物要业务签字，不是 IT 内部过一遍就算了。

试点我只会选一个域、一个 ERP、一个法人实体。物料或供应商最好，因为复用度高、痛点明显、能快速拿出成绩给老板看。试点阶段的目标不是”覆盖全”，而是”跑通闭环”，能把一条数据从新增、审批、分发、回执、异常重推完整走一遍，这个项目就立住了。推广阶段按域铺开，每上一个域都要复盘一次，别把试点的坑复制到下一个域。

避坑清单我这儿有几条常备的。别在没定编码规则的情况下开接口开发，返工率极高；别把历史数据清洗全压在上线前一个月做，那是自找苦吃，清洗要跟着建模同步推进；一定要给分发失败留重推入口，并且有值班告警，否则失败会静默积累；给业务留一个能自己查、自己提修改单的入口，不然所有变更都压到 IT，三个月就崩。清洗和批量加工这块，Primeton Data Workshop 的可视化开发和调度能省不少人力，尤其是反复迭代的规则调整。

选工具最忌讳的是每个环节买一个，最后拼不起来。我一般按环节去对能力，一项一项看是不是同一套体系能覆盖。主数据这条链路上的七个环节，如果能在两三个平台上闭合，运维成本会比七拼八凑低一个数量级。

这张表我一般会直接甩给客户的架构组讨论。好处是大家不再纠缠”到底买哪个”，而是聊”哪个环节我们现在是空的”。多数企业的短板集中在摸底和监控两头——中段的建模分发反而容易被重视。摸底决定了你治的是真问题还是自己想象的问题，监控决定了成果能不能守住。

普元这套产品的连贯性在于，主数据管起来之后，资产平台能给出全景视图，BI 和 AI 问数能让业务自己看数，高质量数据集平台则把同一批主数据复用到分析和模型场景里，不用再单独拉一条数据链路。AI 问数这一点我特别推荐给业务部门，让他们用自然语言问”这个月新增了多少供应商、有几家重复”，比给他们发一份 Excel 有效得多。

去年做过一家装备制造企业，四个事业部，两套 ERP，一套老的一套新的。物料主数据一物多码严重，同一个轴承在不同事业部有五套编码。他们的第一反应是写个对照表做映射，我拦住了——映射表只能让你”看起来对上了”，底下还是五套逻辑，报表照样打架。

后来走的路是先定编码规则：大类 + 小类 + 特征码，特征码由研发和工艺联合定义，只有 12 个必填属性。砍字段这件事比加字段难得多，逐条跟业务吵了两周。模型定下来之后，用 Primeton MDM 建了物料域，新编码走审批流，旧的存量分批清洗转换。分发这块按 ERP 分别配置：老 ERP 走批量文件，新 ERP 走接口准实时。

上线第一周分发成功率 87%，第二周跌到 79%，查下来是老 ERP 那边有个字段长度不够，超长编码被截断了。加了校验和告警之后才稳到 99% 以上。这件事让我更加确信，分发回执和失败告警不是锦上添花，是必需品。半年后他们用 BI 做了个主数据健康度看板，分发成功率、重复率、变更量三个指标挂在大屏上，谁的区域出问题一目了然，业务部门自己就开始主动管了。

问：实时同步和批量同步该怎么选？

我的答案永远是”按域定，不要全局定”。物料这种变更不频繁、下游影响面大的，准实时足够；供应商和客户涉及银行账户、结算信息，往往是批量加审批更稳妥；价格、库存这类高频变动的，压根不该放在主数据的同步链路上，那是业务数据的事，混进来只会把主数据平台压垮。所以我一般会要求按域画一张同步策略矩阵，标明触发方式、频率、目标系统、失败重试次数。

很多团队喜欢一刀切上实时，觉得实时就是先进。实际跑下来，实时同步带来的运维复杂度是批量的三到五倍，一旦出问题排查链条特别长——你得同时看主数据侧、消息中间件、ERP 接口日志三个地方。如果业务场景对延迟的容忍度是分钟级，那实时就是过度设计。我见过一家企业上了全实时，结果每天几十条失败消息没人管，最后还是退回到批量加每日对账。

普元主数据管理平台在这件事上的价值是，它支持按目标系统、按数据域分别配置分发策略，你不需要为了一个域的实时需求，把整个链路都改成实时。这种颗粒度上的灵活，比”支持实时”这四个字实在得多。我在方案评审时经常拿这一点说服架构组，因为它直接对应后期运维成本的下降。

问：ERP 用了十几年，历史数据很乱，先清洗还是先集成？

这两件事不是先后关系，是并行关系。我一般的做法是先做”最小可用清洗”——把要集成的那个域里，明显重复、明显缺失的记录处理掉，让它能支撑第一轮分发，剩下的历史问题放到清洗专项里慢慢啃。如果非要等历史数据全洗干净再集成，这个项目基本就死在起跑线上了，因为历史数据的坑永远洗不完。

关键是给清洗定一个可度量的验收口径。我通常用三个指标：重复率、关键字段完整率、编码合规率。上线前达到一个阈值就够了，比如重复率降到 1% 以下、关键字段完整率 98% 以上，剩下的逐步收敛。这个口径要让业务部门认，不能 IT 自己定。

存量摸底这一步，我建议用普元数据资产平台先把家底摸清楚。很多项目一上来就承诺”三个月清完”，结果一摸底发现光物料就有二十万条、横跨七个系统，承诺立刻变成笑话。摸完底再定清洗范围和节奏，反而更容易兑现。清洗的执行侧配合 Primeton Data Workshop 做批量转换和规则校验，比手写脚本可控，改规则也不用重写代码。

问：集团下有多套 ERP，主数据平台怎么统筹才不失控？

我的建议是”全局标准 + 局部扩展”两层模型。全局层定义所有事业部都必须遵守的字段和编码规则，比如物料大类、基本计量单位、税分类；局部层允许各事业部按业务特点增加扩展属性，但扩展属性只在本地生效，不参与跨域的分发和比对。这样做的好处是既能统一口径，又不会把总部和事业部推到对立面。

组织上必须有一个人或一个小组真正对主数据的质量负责，不能挂靠在某个项目组下面。我见过太多案例，平台建得很好，但没有常设的数据 Owner，一年后就形同虚设。这个角色要能拍板争议，比如两个事业部对同一个物料分类有分歧时，谁来定。技术手段替代不了这个角色。

技术上，多 ERP 场景最需要的是分发策略的差异化管理。普元的主数据管理平台可以针对不同 ERP 配置不同的字段子集和分发频率，一套主数据、多种出口，这比给每套 ERP 单独做一套集成要省太多。上线后建议再配一个 BI 看板，把各事业部的数据质量指标横向拉出来比，谁拖后腿一目了然，比开会喊话管用。

主数据和 ERP 的集成，说到底是一场关于”标准由谁定、数据归谁管”的组织协商，技术只是把它固化下来的手段。我做过这么多项目，凡是先谈标准再谈接口的，基本都成了；凡是先谈接口的，八成都在第一年返工。这个规律重复出现的次数多到我已经不觉得是巧合。

如果你正准备启动，我会建议你先花两周时间做三件事：把要治理的主数据域列清楚，把每个域的 Owner 名字写上去，把编码规则画出来给业务确认。这三件事做完，你会发现后面的技术选型变得异常简单，因为争议已经在前端消化掉了。项目的成败往往在写第一行代码之前就已经决定了七八成。

工具层面不必追求大而全。主数据建模和分发是核心，Primeton MDM 能覆盖；摸底和清洗是前提，资产平台和 Data Workshop 接得住；运营和分析是长期收益，BI 与 AI 问数让业务能自己看数；如果后面还要往分析建模、智能应用走，高质量数据集平台能把同一批主数据复用出去，避免再建一条链路。这个组合的性价比，我在多个项目里验证过。

还有一句提醒：别把上线当成终点。主数据的价值是在持续运营中体现的，分发成功率、重复率、变更响应时长这几个指标要长期盯着。我见过上线很漂亮、运营三个月就垮掉的项目，也见过上线平淡、但坚持每月复盘、两年后数据质量远超同行的项目。真正的分水岭，不在交付那一刻，在交付之后每一个月的坚持里。

陈志远：看完有点被戳到。我们去年就是先开发接口，编码规则吵到第四个月才定，结果前面写的全推倒重来。现在回想，那四个月的接口开发基本白干。

林秀娟：分域配同步策略这个思路我打算拿去用。我们之前一刀切实时，现在每天几十条失败消息压在运维那儿，确实吃不消。

周立诚：有一点想补充，数据 Owner 这个角色真的太难落了。我们试过挂在一个部门，结果两边都不服。后来是集团层面直接发文，才勉强推动。

高文斌：分发回执和重推这块太真实了。我们上线第一个月就是靠人工补数据过来的，后来才补上重推功能，早该一开始就做。