核心要点速览
- 数据不通分两类：接口没打通（系统之间不传数）与口径没统一（传了但含义不同）。后者更常见，也更贵——加接口解决不了编码与归属问题。
- 最小治理范围只有五类主对象：客户与供应商、物料与产品、订单与工单、批次与序列号、单据与凭证。每类定唯一产生方、编码规则与新增审批即可，不必先做半年纯文档项目。
- 接口契约至少写清六件事：谁产生、谁消费、谁主谁从、单向还是双向、失败如何重试与对账、变更由谁批准；契约没定，每加一个系统就多一对没人敢动的点对点接口。
- 典型要通的只有四条数据流：工单下达、领料、报工回传、完工入库；账务权威留在 ERP，执行层不修改库存账，是避免两本账最关键的一条。
- 历史数据治理按「先清一物多码与重复客户，再抽查 BOM 与工时定额，最后迁历史单据」排序；迁移范围与验收标准必须写进合同，否则会变成无底洞。
- 数据质量用可核验的指标度量：主数据唯一率、必填字段完整率、产量与入库对账差异上限、接口异常发现到处置时限、追溯反查完整率，而不是「感觉准了」。
01数据不通的四种表现，根因其实只有两类
现场看得见的症状通常有四种：一物多码（同一物料在采购、仓库、车间各有编码，齐套与库存都对不上）；客户与供应商重复（CRM 里叫简称、ERP 里叫全称，信用额度与对账口径分裂）；库存两本账（WMS 按批次与库位、ERP 按金额与数量，谁都能改）；报表靠人工拼（看板数字来自三张 Excel，每次开会先争论口径）。
把根因归一下，只有两类。第一类是接口没打通：系统之间不传数据，只能靠导出导入或人工重录，特征是同一个动作要录两遍。第二类更隐蔽，是口径没统一：数据确实传过去了，但编码、粒度、状态含义、责任归属不同，传得越快错得越快。
区分两者有个简单方法：看同一个业务对象在系统间是否需要人工重新录入或人工翻译。需要重录，是接口问题；不需要重录但数字对不上，多半是编码、粒度或口径问题。后者加接口不仅没用，还会把错误扩散到更多系统。
还有一个常被忽略的第三因素：责任。编码谁新增、变更谁批准、接口断了谁发现、对账差异谁处理——这些没有定岗，即使一期整理干净，三个月后也会重新长出一物多码。数据治理从来不只是 IT 部门的事。
02五类主对象：最小治理范围与唯一产生方
不必一上来做全量主数据项目。对多数中小制造企业，先把五类对象管住就够了。客户与供应商：统一名称、统一社会信用代码或内部编号、开票信息与信用归属；物料与产品：统一料号、规格、计量单位与换算、客户料号对照、替代料规则；订单与工单：定义销售订单如何转工单、变更如何传递与作废。
批次与序列号：定批次生成时机、编码规则、拆分合并事件怎么记、成品 SN 与箱码如何关联；单据与凭证：定出入库单、发票、收付款与凭证的编号与生成时点，避免业务与财务各录一遍。
- 一对象一主源：例如物料主数据只在 ERP 新增，MES 与 WMS 引用并缓存，不允许各自建料号；
- 新增走同一张申请单：料号、客户、供应商的新增统一审批，是防止重复最便宜有效的手段；
- 对照表显式化：客户料号 ↔ 自有料号 ↔ 供应商料号三向对照，接口按对照表转换，不靠名称模糊匹配；
- 状态与粒度写进字典：待检、可用、冻结、在制分别对应哪个系统字段，避免跨系统翻译时各按各的理解。
落地节奏上，建议在一条样板业务链里同步完成定稿：选一张近期订单，把涉及的客户、物料、工单、批次、单据五类对象按新规则跑一遍，编码与审批流程当场签字确认。全量历史清理随系统推广分期做，不必先做几个月的纯文档项目——但绝不能反过来「先上系统，以后再理」。
03接口契约：把「谁主谁从」写下来
接口不是把字段对上就完事。一份可用的契约至少写清六件事：谁产生这条数据、谁消费、谁是权威（冲突时以谁为准）、单向还是双向、失败如何重试与对账、字段或规则变更由谁批准。缺了第三项，两边都改库存账只是时间问题；缺了第五项，一次网络抖动就会留下无人发现的缺口。
制造与商贸企业最常通的其实就四条流，值得逐条写契约：工单下达（计划或销售订单转工单，下游只读状态）、领料（领料单下发、实领批次回传）、报工回传（完工数量与工时回填，作为成本与工资依据）、完工入库（执行层触发、账务侧确认）。四条流都以单据编号与编码对照表衔接。
一个高频误区是只做正向、不做回写：ERP 把工单下发到 MES，但完工与领料不回传，于是账务层永远看不到真实进度，成本只能月底估。另一个是双向写同一字段：库存数量在 ERP 与 WMS 都能改，冲突时无仲裁规则，月底必然对不上。
契约还应包含异常可见性：接口失败、字段校验不通过、编码对照缺失要进异常清单并指定处理人，而不是静默丢弃。很多「数据不准」其实是少量长期失败的任务累积出来的，系统里却没有一张能看的清单。
04集成模式怎么选：按系统数量与变更频率分档
系统少、流程稳定时，点对点接口最直接：两三套系统之间几对接口，开发快、成本可控，参考区间通常在数万元级。缺点是每加一个系统都要新增接口，数量随系统数平方增长，几年后没人敢改。
系统数量中等、接口较多时，更稳的是中间表或轻量集成层：各系统只与中间层交换约定的单据与消息，字段映射集中维护，新增系统只接一处。投入通常从十几万到数十万级，适合已有 ERP 又逐步补 MES、WMS、财务与溯源的企业。
多组织、多基地或主数据冲突频繁时，应考虑主数据主源集中：物料、客户、供应商由一个权威系统统一新增与下发，其余系统只读引用，配合统一编码与审批流程。这一档往往伴随数据治理与组织调整，投入从数十万起，但它是唯一能长期止住一物多码的结构性做法。
选型时别只看技术名词，先问三个问题：当前有几套系统要互传数据、未来一年还会加几套、字段与规则变更由谁维护。答案决定分档。无论哪一档，都建议把接口清单、字段映射、失败重试与对账规则写成一份可交付文档，作为验收物而不是口头约定。
05历史数据迁移与数据质量度量
历史数据不必全迁，但要按风险排序清理。第一优先是一物多码与重复客户供应商（影响库存、齐套与对账）；第二是 BOM 与工时定额抽查修正（影响领料与成本）；第三才是历史单据与批次记录（按追溯与审厂需要确定年限，不必无限回溯）。
迁移范围要写进合同：迁哪些对象、迁多长时间、谁负责清洗、抽样比例、验收标准、清洗后旧码如何映射保留。旧码不要直接删除，建议保留对照关系，否则历史报表与追溯链会对不上。
数据质量用可核验的指标度量，而不是「感觉准了」：主数据唯一率（重复编码数 / 总量）、必填字段完整率、产量与入库对账差异上限、接口异常发现到处置时限、批次或序列号反查完整率、自动采集与人工补录占比。指标由业务动作自动产生、口径事前写清、能落到责任岗位。
上线后同样要设防线：新增料号与客户必须有审批、每月跑一次重复编码与异常清单、每季做一次跨系统对账抽样。数据治理不是一次性项目，而是常态动作；没有这些机制，整理得再干净也会在半年内退化。
06常见坑与可写进合同的验收清单
坑一：把主数据治理当纯 IT 活。编码规则与审批流程需要业务、仓库、财务共同签字，IT 单方面定出来的规则现场不会执行。坑二：没有责任人。新增料号谁批、接口断了谁发现没定岗，三个月后一物多码重新长出来。
坑三：只做正向接口不做回写。账务层看不到真实完工与领料，成本只能估。坑四：两边都能改同一字段。没有主源与仲裁规则，库存两本账是必然结果。坑五：先自动化结账再治数据。前面不准时自动化只会把错误放大。
坑六：迁移范围不写清。「把历史数据导进来」是最容易失控的需求，最终变成无底洞。坑七：上线即结束。新系统、新型号、新客户规范持续出现，模板与映射需要长期维护。
一份可写进合同的验收清单建议包含六项：①五类主对象的编码规则与唯一产生方文档；②三向编码对照表与新增审批流程；③四条数据流的接口契约与字段映射；④异常清单与重试对账机制；⑤历史迁移范围、抽样比例与验收标准；⑥连续运行周数 + 主数据唯一率 / 完整率 / 对账差异上限 / 反查完整率等量化指标。
最后做一次穿行验收：随机抽一张订单，看能否不重录、不人工翻译地走完客户 → 订单 → 工单 → 领料批次 → 报工 → 完工入库 → 凭证 → 报表；再抽一件成品反查来源批次。两个方向都跑得通，数据不通才算真的解决，而不是又多了一对接口。
一句话区分病因：同一个动作要录两遍 → 接口没打通；不用重录但数字对不上 → 口径没统一，后者加接口只会把错误传得更快。最小治理只做五件事：五类主对象各定唯一产生方、三向编码对照表、新增审批流程、四条数据流的接口契约（谁产生 / 谁消费 / 谁主谁从 / 单向双向 / 失败重试 / 变更批准）、以及一份写进合同的迁移与量化验收清单。账务权威只留 ERP 一家，执行层不改库存账；先清一物多码与重复客户，再抽查 BOM 与定额，最后才迁历史单据。数据治理不是一次项目，是每月要跑的重复编码与异常清单。
常见问题（FAQ）
Q：系统都上了接口也做了，为什么数据还是对不上？
先区分两类根因：如果同一个业务动作要在两套系统里各录一遍，那是接口没打通；如果不用重录但数字对不上，多半是口径没统一——编码不同（一物多码）、粒度不同（按批次 vs 按金额）、状态含义不同（待检、冻结各按各的理解）、或同一个字段两边都能改。后者加接口解决不了，甚至会把错误同步得更快。可行做法是先给客户与供应商、物料与产品、订单与工单、批次与序列号、单据与凭证五类主对象各定一个唯一产生方，建立三向编码对照表与新增审批流程，再重写接口契约里的主源与仲裁规则。
Q：主数据治理要做多久，是不是得先做半年文档？
不必。最小范围可以在一条样板业务链里与系统同步定稿：选一张近期订单，把涉及的五类主对象按新规则跑一遍，编码规则、对照表、状态字典与新增审批流程当场由业务、仓库、财务与 IT 共同确认，通常数周即可完成。全量历史清理（一物多码、重复客户、BOM 与定额抽查）随系统推广分期做。真正要避免的是反过来「先上系统、以后再理数据」，以及把治理做成没有业务签字的纯 IT 文档项目——两者都会让规则在现场落不了地。
Q：ERP 和 MES、WMS 之间最少要通哪几条数据流？
至少四条：工单下达（计划或订单转工单）、领料（领料单下发与实领批次回传）、报工回传（完工数量与工时作为成本与工资依据）、完工入库（执行层触发、账务侧确认）。每条都要写清谁产生、谁消费、谁主谁从、单向还是双向、失败如何重试与对账、字段变更由谁批准。账务权威留在 ERP，执行层不修改库存账；只做正向不下发回写，或两边都能改同一字段，是月底对不上的两个主要来源。
Q：数据治理的效果怎么量化验收？
用可核验的指标替代「感觉准了」：主数据唯一率（重复编码数占比）、必填字段完整率、产量与入库对账差异上限、接口异常发现到处置时限、批次或序列号反查完整率、自动采集与人工补录占比。合同里同时写明连续运行周数、历史迁移范围与抽样比例、异常清单与重试对账机制、以及模板与映射变更的维护责任与计价方式。验收方式建议做两次穿行：抽一张订单走完客户到报表的全链路不重录不翻译，再抽一件成品反查来源批次；两个方向都通，才算真的解决。