PLM 和 ERP 到底谁管 BOM：EBOM、MBOM、工程变更与物料主数据的系统边界

一、一批旧版零件，揭开了两个系统的"内战"

深圳一家做工业视觉设备的公司，去年出过一次让采购经理差点离职的事故。

他们的相机模组要升级：镜头座的固定方式从两颗 M2 螺丝改成三颗 M2.5，结构件图纸和 BOM 在 PLM 里走完了工程变更，9 月 1 日正式生效。研发工程师在 PLM 里点了"发布"，这事在他看来就结束了。

但 ERP 里没人动。旧版螺丝 M2×6 的采购申请是 8 月 28 日提的，供应商 9 月 5 日到货 5 万颗；新版 M2.5 的采购申请直到 9 月 10 日才在 ERP 里建出来。更糟的是，旧版镜头座的库存还有 8000 件，ERP 没做任何冻结或消耗策略，新老版本混在同一个料号里继续发料。等产线发现拧不上的时候，新旧零件堆了一托盘，呆滞库存 6 万多块。

复盘会上三个部门互相甩锅。研发说："我 PLM 里变更都发布了，流程走完了。"采购说："ERP 里没收到变更通知，我按原计划买有什么错？"仓管更委屈："领料单上就一个料号，我怎么知道哪盘是新哪盘是旧？"

我被请去看他们的系统。看完之后我说，这不是哪个人的问题，是系统边界根本没划清：PLM 认为"发布即完成"，ERP 认为"没收到就不存在"，中间的工程变更同步、版本生效、库存甄别全靠人肉，不出事才奇怪。

PLM 和 ERP 的集成，是工厂信息化里最古老也最容易打起来的边界之争。争来争去就争三样东西：BOM、物料主数据、工程变更。这篇我把这三样掰开讲。

二、先对齐概念：BOM 不止一张，常见的有三种

很多争论源于大家嘴里说的"BOM"根本不是同一张表。离散制造里至少有三种 BOM，它们结构不同、用途不同、归属系统也不同。

BOM 形态	全称	视角	典型结构	归属系统
EBOM	Engineering BOM，设计 BOM	这个产品由哪些零件按什么设计关系组成	按功能模块划分，含图纸件、标准件、电气件	PLM
MBOM	Manufacturing BOM，制造 BOM	车间按什么顺序、用哪些物料把产品造出来	按装配工序重构，含毛坯、耗材、工装、虚拟件	PLM/工艺模块，下发 ERP、MES
SBOM	Service BOM，服务 BOM	售后维修要换哪些备件	按可更换单元（FRU）组织，含备件替代关系	PLM/售后系统，同步 ERP 备件库存

拿一台六轴机械臂举例。EBOM 里"底座组件"下面挂着底座本体、四个减震垫、一对外罩；但 MBOM 里，底座本体是从一块铸铝毛坯经 CNC 加工而来的——毛坯、切削液消耗、加工用的夹具都出现在 MBOM，却不出现在 EBOM。装配时要先把伺服电机压进关节、再整体装入大臂，这种工艺顺序和合件关系，EBOM 完全不表达。

所以"EBOM 到 MBOM"绝不是复制一份改改数量，而是一次结构重构：合并虚拟件、拆分工艺合件、补充毛坯耗材、重排装配顺序。这个动作的产出物归属谁？我的答案是仍然归 PLM（或 PLM 中的工艺模块），ERP 和 MES 只是消费 MBOM。因为工艺结构的变更同样需要评审和版本管理，放 ERP 里就失去了工程视角的可追溯性。

一个 BOM 行最少要回答的问题

不管哪种 BOM，落到表设计上，一行 BOM 明细至少要有这些字段：

• 父项物料、子项物料、用量、单位、损耗率；
• 序号（设计位号，电子行业还要有 reference designator）；
• 替代组和替代策略（主料缺料时能不能用替代料）；
• 版本号 + 生效起始时间 / 失效时间；
• 关联的工程变更单号（这行为什么存在、哪次变更引入的）。

最后两组字段是 PLM 的灵魂，也是大多数 ERP 原生 BOM 的短板——ERP 的 BOM 通常只关心"当前有效的那一份"，对历史版本和未生效版本是弱管理。这就是为什么 BOM 的主数据源头应该放在 PLM。

三、物料主数据：一条物料的"出生"和"户口"

比 BOM 更容易乱的是物料主数据。

物料是工厂里唯一一个 PLM、ERP、MES、WMS、QMS 全都要用的基础对象，所以它也是最容易被各建一套的对象。我见过最夸张的厂，同一个 M3 内六角螺丝在四个系统里有四个编码、四种描述，采购按重量买、仓库按个数发、财务按盒结转——计量单位都不统一。

物料主数据的治理，核心是三条原则。

原则一：一物一码，创建权唯一

任何物料的"出生登记"只能有一个入口。研发型离散制造企业，这个入口应该是 PLM：工程师在完成选型、挂上规格书和图纸后提交申请，经过标准化工程师审核（重码检查、命名规范、分类属性），审批通过后生成正式物料编码，再通过接口下发给 ERP。

ERP 这边必须做硬控制：没有 PLM 发布记录的物料，不允许采购、不允许入库、不允许建 BOM。这条规则听起来粗暴，但它是堵住"应急物料""临时物料"野蛮生长的唯一办法。临时需要怎么办？走 PLM 的快速通道，几小时内完成编码，而不是在 ERP 里留一个永远转不了正的"临时码"。

原则二：一个物料，多套视图

物料在不同系统里看到的属性不同，但身份必须是同一个：

• 工程视图（PLM）：名称、规格、材质、图号、版本、重量、设计者；
• 采购视图（ERP）：采购组、默认供应商、提前期、最小起订量；
• 库存视图（ERP/WMS）：计量单位、批次/序列号管理标志、保质期、库位策略；
• 成本视图（ERP）：标准价或移动平均价、成本要素；
• 质量视图（QMS）：检验方案、AQL 抽样规则、必检项；
• 制造视图（MES）：投料方式、过站规则、是否关键件追溯。

好的数据架构是一段主数据 + 多段扩展属性：物料的身份字段（编码、名称、大类、基本单位）只有一份、由 PLM 持有；各系统存自己关心的扩展属性，用同一个编码关联。坏的架构是每个系统各建一张物料表，靠人工对照——这张对照表三个月后必然失真。

原则三：编码规则要"傻"

关于物料编码要不要带含义（分类码 + 规格码 + 流水号），业界吵了很多年。我的经验很明确：中小厂直接用无含义的 7~8 位流水号，把含义全部放进分类和属性字段，靠系统检索而不是靠眼睛解读编码。

带含义的编码在实践中必死：规格升级一位、分类调整一次，编码含义就名存实亡，然后各种"近似码""特殊码"长出来。流水号 + 严谨的属性体系，才是能活十年的方案。

四、工程变更：PLM 里"点发布"之后，世界要跟着动

回到开头那批螺丝事故。核心问题是：工程变更（ECO）的生命周期，在 PLM 点下"发布"的那一刻只走完了一半。

变更的两个阶段：ECO 与变更执行

完整的工程变更链路是这样的：

1. 问题/需求（ECR/ECN 上游）：客户投诉、降本、工艺改进触发变更申请；
2. 工程变更单 ECO（PLM 内）：影响分析——改哪个零件、影响哪些 BOM、哪些在制品和库存受牵连；方案设计、图纸改版、多级评审、审批发布；
3. 变更执行（跨系统）：这才是事故高发段——
   • ERP：新物料建采购信息、旧物料状态改"冻结采购"、BOM 版本按生效日期切换、在途订单评估；
   • WMS/库存：旧料盘点、冻结、制定消耗策略（先用旧后用新 / 退回供应商 / 报废）；
   • MES：工艺路线、作业指导书、在制批次甄别规则更新；
   • QMS：检验标准、量具、抽样方案更新；
   • SRM：给供应商发变更通知（PCN），确认切换批次和时间。
4. 闭环验证：首件确认、变更后批次质量跟踪、旧料消耗归零、ECO 关闭。

PLM 应该是这条链路的指挥中枢：ECO 发布时生成一张"变更执行任务清单"，按系统拆成可跟踪的任务项，每个任务项有负责人、状态和回写。下游系统执行完动作回写结果，PLM 据此判断 ECO 能不能关闭。没有这张任务清单，变更就是一封发出去没人敢说收没收到的邮件。

生效性：时间点、批次点还是序列号点

"新版什么时候开始用"有三种策略，必须在 ECO 里显式写明：

• 时间点生效：某日零点起，新工单一律用新版。简单，但在途工单和库存旧料处理粗暴；
• 批次/库存点生效：旧料消耗完自然切换（phase-in / phase-out），适合螺丝这类通用低风险件；
• 序列号点生效：从某个产品序列号起切换，配合精确追溯，适合安全件、法规件（医疗、汽车行业必须如此）。

ERP 的 BOM 和 MES 的投料规则都要支持按这三种口径展开，否则一线永远会拿到错版本的料。

数据模型上的关键手法：版本不可变 + 生效区间

我自己做 PLM 的时候有个原则：已发布的版本只读，任何修改产生新版本。BOM 行上挂 [effective_from, effective_to) 的半开区间，MRP 展开和车间领料按工单计划日期取当时有效的版本。这样设计有两个立竿见影的好处：

• 任何一张历史工单都能还原出"当时应该用的 BOM"，质量追溯和成本复盘有据可查；
• 变更可以预先发布、定时生效，不用工程师半夜守着系统切换。

变更单和 BOM 行强关联（每行记录由哪个 ECO 引入、由哪个 ECO 失效），审计时一条链拉到底——过 ISO 9001、IATF 16949 审厂时，这是审核员最爱看的东西。

五、集成架构：点对点、接口表，还是主数据中台

道理讲完，落到工程实现，PLM 和 ERP 之间怎么连？我按企业规模给三种形态。

方案	做法	适合	主要代价
点对点实时接口	PLM 发布即调 ERP 的 REST API，失败重试	系统少、规则简单的小厂	系统多了变成蜘蛛网，耦合紧
接口表 + 定时同步	双方各写 staging 表，定时任务搬运，带状态和重放	绝大多数中小厂首选	有分钟级延迟，要处理脏数据
消息事件 / 主数据中台	PLM 发布领域事件（物料发布、ECO 发布），各系统订阅；或建 MDM 主数据平台	多工厂、多系统的中大型集团	基础设施和治理成本高

我个人偏爱中小厂从接口表起步：PLM 发布物料时往 ERP 的 mdm_material_staging 写一条记录，ERP 侧定时任务校验、落正式表、回写处理状态；ECO 同理。接口表的好处是一切故障都有现场——哪条记录卡住了、报了什么错、重放过几次，写个 SQL 就能查。等系统超过五个、工厂有两三个了，再把接口表升级成事件订阅，演进路径平滑。

无论哪种方案，有几条军规：

1. 方向不可逆：主数据只能 PLM → ERP，ERP 端不提供"新建物料"的业务入口（技术上可以有，但要封权限）；
2. 幂等：以物料编码 + 版本为唯一键，同一条消息重放 100 次结果一样；
3. 全量对账：每天凌晨跑一次 PLM/ERP 主数据差异比对，差异报表发到质量群。接口一定会抖，对账是最后防线；
4. 人工兜底入口留痕：极少数紧急情况下允许管理员在 ERP 直接改数据，但必须走审批、留日志、次日被对账报表发现。

六、小厂没有 PLM 怎么办

不是所有企业都养得起独立 PLM。如果产品结构简单（几十个料号、变更一个月一两次），务实方案是：在 ERP 里划出"工程区"，用 BOM 版本 + 工程变更单模块把版本和生效期管起来，物料创建走独立审批流。很多主流 ERP 都有工程变更模块，用得克制、流程执行到位，能顶上小半个 PLM。

但如果你的企业出现这些信号：料号过万、图纸和实物对不上是常态、每月变更超过十次、多部门为"哪版是对的"吵架、客户开始要批次级追溯和变更记录——那就别将就了，BOM 和变更的复杂度已经超出 ERP 的舒适区，PLM 该上了。

这两年我基于开源的 Cascadia PLM 做过一版完整的产品生命周期管理系统，核心思路就是把 Git 的分支模型搬进工程变更：ECO 在 PLM 里像开一个分支，图纸、BOM 的修改在分支上进行，评审通过再"合并"到主干并对下游发布；配合 14 类 Item 的领域模型、revision 的原子分配和版本只读，把上面讲的版本、生效、协同问题在数据层解决掉。整个从零搭建的过程，包括 ECO-as-Branch 引擎、TypeScript 到 Java 的适配层、BOM 树可视化、并发冲突处理，我在专栏《用 Cascadia PLM 搭建产品生命周期管理平台》里用十篇文章拆完了。

而 ERP 那一侧怎么接物料、怎么按版本展开 MRP、库存账怎么跟着切换，可以对照《ERP 进销存与订单中台》连载里的采购、库存台账和财务结算链路一起看。

BOM 之争的本质，不是 PLM 和 ERP 两个软件谁功能强，而是企业愿不愿意承认"产品数据需要一个唯一的、讲版本的、对变更负责的源头"。源头立住了，下游所有系统都轻松；源头立不住，买再贵的系统也只是在各自的孤岛上各记各的账。