2. 基础概念
在工程变更数字化的语境里，ECR、ECO、ECN 是三个出现频率最高、也最容易被混用的术语。很多企业的变更流程之所以混乱，根源并不在系统功能，而在于没有把这三个对象的职责边界定义清楚：谁负责提出、谁负责批准、谁负责执行、谁负责通知。本节从概念、对象属性、流转关系以及在 PLM/ERP 中的位置四个角度，把这三个概念彻底拆开。
一、核心原理：三个对象分别解决什么问题
ECR（Engineering Change Request，工程变更请求）是变更的“提案”。它回答的问题是：为什么要改？ECR 通常由设计、工艺、质量、采购、售后或客户提出，内容偏描述性和论证性，包括问题现象、变更原因、影响范围初判、期望完成时间、提出人。ECR 阶段的核心动作是评审与决策——批准则进入执行，驳回则关闭并记录理由。ECR 本身不直接修改任何物料、BOM 或图纸数据。
ECO（Engineering Change Order，工程变更订单）是变更的“执行指令”。它回答的问题是：具体改什么、怎么改、谁来改？ECO 由 ECR 批准后转化生成，携带明确的执行清单：受影响物料号、BOM 行项增删改、图纸版本、工艺路线、生效方式（立即生效/指定日期生效/用完旧料生效）、执行责任人。ECO 是真正驱动 PLM 中数据发生版本跃迁的对象。
ECN（Engineering Change Notice，工程变更通知）是变更的“发布与告知”。它回答的问题是：改完了，谁需要知道？ECN 在 ECO 执行完成、数据发布后生成，面向下游制造、采购、仓储、品质、供应商等角色，说明变更内容、生效批次、切换要求、旧料处理方式。ECN 是信息同步载体，通常不承载审批流，但承载签收确认。
一句话记忆：ECR 决定“要不要改”，ECO 决定“怎么改”，ECN 决定“让谁知道改完了”。三者是同一变更事件在生命周期不同阶段的三种形态，而不是三个可以互相替代的审批单。
二、对象属性与流转关系
从数据模型看，三者共享一个“变更主数据”根节点，通过状态机串联。ECR 批准后派生 ECO，ECO 执行完成后派生 ECN，形成 1:1 或 1:N 的派生链（一个 ECR 可能拆成多个 ECO 分批实施，一个 ECO 也可能对应多份 ECN 面向不同工厂）。
三、方法流程：从请求到通知的标准路径
一个规范的数字化变更流程通常包含以下步骤，每一步都对应明确的对象状态与系统动作：
- 提出 ECR：在 PLM 中创建 ECR 对象，填写问题描述、变更原因、初步影响范围，关联受影响的物料或图纸。
- ECR 评审：变更评审委员会（CCB）评估技术可行性、成本、交期、质量风险，给出批准或驳回结论。
- 生成 ECO：ECR 批准后系统自动派生 ECO，工程师在 ECO 中填写具体变更内容——BOM 行项增删、图纸版本升级、工艺路线调整、生效方式。
- ECO 审批与下达：ECO 经过多级审批后下达，PLM 中相关对象进入“变更中”锁定状态，防止并发修改。
- ECO 执行：设计人员完成图纸改版，工艺人员更新路线，系统记录版本跃迁与变更前后差异。
- 生成并发布 ECN：ECO 执行完成后自动生成 ECN，向 ERP 及下游角色发布，触发物料主数据与 BOM 的同步更新。
- 签收与闭环：下游确认签收，ERP 完成旧料切换，执行结果回写 PLM，变更事件关闭。
四、PLM 与 ERP 中的位置分工
理解三者区别之后，还要理解它们在系统版图中的位置。PLM 是变更的“源头与大脑”，负责 ECR、ECO 的对象管理、审批流、版本控制和影响分析；ERP 是变更的“执行与落地”，负责接收 ECN 后的物料主数据更新、BOM 切换、采购与工单调整。两者通过变更发布接口衔接，形成“PLM 定义变更、ERP 执行变更”的分工格局。
| 对比维度 | ECR | ECO | ECN |
|---|---|---|---|
| 核心问题 | 为什么要改 | 改什么、怎么改 | 让谁知道 |
| 主要提出方 | 设计/工艺/质量/客户 | 由 ECR 派生 | 由 ECO 派生 |
| 是否修改数据 | 否 | 是，驱动版本跃迁 | 否，仅发布告知 |
| 审批强度 | 评审决策 | 多级审批 | 通常免审批，需签收 |
| 主要系统 | PLM | PLM | PLM 发布 → ERP 接收 |
| 典型状态 | 草稿→评审中→已批准 | 已下达→执行中→已完成 | 已发布→已签收 |
五、案例场景：一次物料替换的完整流转
某电子企业因某电容停产，需要将 A 物料替换为 B 物料。质量部在 PLM 中提出 ECR，说明停产风险和替代方案；CCB 评审后批准。系统派生 ECO，工程师在 ECO 中填写：受影响 BOM 共 3 个产品、A 物料停用、B 物料新增、生效方式为“用完旧料生效”、执行责任人为设计主管。ECO 审批下达后，设计人员完成图纸标注更新，PLM 记录版本从 A 版升至 B 版。ECO 执行完成后生成 ECN，发布至 ERP 和采购、仓储部门。ERP 接收后更新物料主数据，设置 B 物料为有效、A 物料为限制使用，采购按新物料下单，仓储按“先用旧料”原则发料。整个链路中，ECR 解决“要不要换”，ECO 解决“怎么换”，ECN 解决“换完了通知谁”。
数字化要点：ECR、ECO、ECN 不应是三张孤立的表单，而应是同一变更主数据下的三个状态节点。系统设计时用一条变更编号贯穿始终，才能实现从请求到通知的全程追溯。
六、常见误区与复盘
- 误区一：把 ECR 当 ECO 用。在 ECR 里直接填写 BOM 修改内容并执行，导致变更未经充分评审就落地，质量风险失控。正确做法是 ECR 只做论证，具体修改在 ECO 中完成。
- 误区二：ECO 执行完不发 ECN。PLM 中数据已改，但 ERP、采购、仓储不知道，导致继续采购旧料、发错料。ECN 是 PLM 与 ERP 之间的关键握手。
- 误区三：ECN 也走完整审批流。ECN 是通知而非决策，若再走多级审批会拖慢信息同步。ECN 应轻量化，重点是发布范围和签收确认。
- 误区四：三者编号不统一。ECR、ECO、ECN 各自编号、互不关联，追溯时无法还原完整变更链路。应使用统一变更主编号加阶段后缀的方式管理。
复盘提醒：变更管理数字化的第一步不是上系统，而是把 ECR、ECO、ECN 的职责边界、状态流转和系统归属定义清楚。边界不清，系统只会把混乱自动化。
总结来看，ECR 是变更的起点与决策依据，ECO 是变更的执行载体，ECN 是变更的发布与同步手段。三者在 PLM 中完成定义与审批，在 ERP 中完成执行与切换，通过统一的变更主数据和发布接口形成闭环。理解这一层关系，是后续学习变更流程建模、影响分析和系统集成的基础。