工程变更申请流程图（ECR 到 ECN）
工程变更申请流程图：ECR 的问题与理由、形状配合与功能评估、成本与库存评估、变更控制委员会决策、ECN、生效点与旧库存处置。
什么是工程变更申请流程图（ecr 到 ecn）流程
工程变更申请（ECR）是一份提案，要求更改某个已经发布的对象：一个零件、一个组件、一张图纸、一份物料清单、一种材料，或一个已批准的供应商零件。ECR 承载问题与理由。如果变更控制委员会批准了它，产出就是一份工程变更通知（ECN，在许多企业里称为工程变更单或 ECO）。ECN 是授权新修订版本的那份指令：它写明受影响的零件、图纸与物料清单，说明变更何时生效，并规定按旧版本已经制造出来的库存该如何处理。
这不是 IT 变更管理。ITIL 式的变更请求把一项变更推入正在运行的服务，衡量的是停机、回滚与服务风险，那是 IT 变更管理工作流与变更控制流程这两份模板所覆盖的内容。ECR 把一个实物修订版本推入生产，它必须回答完全不同的问题：零件是否仍然可以互换、工装要花多少钱，以及已经在仓库里和在订单上的那些产品会怎么样。它也不是文件控制——文件控制管的是程序与政策的版本，而不是产品定义本身。而且这条流程从设计发布之后才开始：产品仍在开发期间所做的更改属于设计与开发流程，而由不符合项引发的变更则通过 CAPA 调查，ECR 只是把已确定的解决方案落到图纸上的那个机制。
多数工程变更程序在技术评估上很扎实，在其他每一处都很单薄。可行性得到了像样的评审，随后旧料呆滞、工装与供应商交期的成本在走廊里被随口估一估，生效日期被记成“尽快”，而采购员要等到一批来料在收货处被拒收时才知道。这份模板正是为此画成五条泳道：申请人、研发、变更控制委员会、制造与供应链。成本、库存与呆滞风险在委员会表决之前，在供应链泳道里成为独立的一步；生效点与库存处置也成为明确的步骤，而不是默认的假设。
本流程图涵盖的内容
本模板包含
- 五条泳道（申请人、研发、变更控制委员会、制造、供应链）分布在五个阶段：申请、技术评估、委员会决策、变更通知与发布，以及实施与验证
- 申请人与研发泳道中的受理：提出工程变更申请、写明原因与理由、把 ECR 登记进变更台账，随后是委员会的初筛决策“申请是否完整且理由充分？”——它在投入研发工时之前，把内容单薄的申请退回补充细节
- 一项分三部分的评估，每条泳道一步：研发评估可行性以及对形状、配合与功能的影响；制造评估对工装与工艺的影响；供应链评估在库存货、在制品、在途货物与未结供应商承诺上的成本、库存与呆滞风险
- “是否批准该变更？”这一决策带有三个具名结果：批准并进入变更通知、在申请人泳道被驳回并关闭，或者暂缓——暂缓会把变更留到日后的发布批次，并把它退回委员会，而不是让它一直开着
- 研发与制造泳道中的发布：签发工程变更通知（ECN）、更新图纸与物料清单、设定变更生效日期，随后是“现有库存如何处置？”这一决策，通往用完、返工或报废
- 实施与验证：向供应商通报新版本、更新作业指导书与工装、制造并检验首件，随后是“首件是否合格？”——不合格会回到图纸与物料清单的更新，合格则关闭该变更
何时使用本模板
- 你们要为一家制造、硬件或按单设计的企业编写或重做 ECR/ECN 程序，尤其是当现在的流程只有一张表单、背后没有约定路径时
- 你们要就谁进入变更控制委员会、他们在决定之前看到什么、以及哪些变更研发经理可以不召开委员会就批准，达成一致
- 你们打算在 PLM 或 ERP 系统中配置变更工作流，希望先梳理流程，让工具固化的是人们已经约定的路径，而不是软件暗示的那一条
- 你们要给设计工程师、计划员、采购员与质量人员做入职培训，他们需要知道自己签字之后这项变更会怎样，以及自己的那一步在哪里
- 客户或审核员询问设计变更是如何受控的，而你们还要落实供货协议中关于向客户通报变更的义务
运作方式
把泳道改成你们真实的角色
把申请人、研发、变更控制委员会、制造与供应链，换成你们实际拥有的职能。在规模较小的企业里，变更控制委员会可能就是每周碰一次面的两个人，而制造工程与生产计划也许是同一条泳道。请合并泳道，而不是发明角色，并把总数保持在五条或以内，让这张图仍然读得下去。
定义什么样的 ECR 才算完整
只有当“完整且理由充分”指向某份写下来的内容时，初筛决策才起作用。一个可用的最低要求：受影响的零件号及其当前版本、原因（缺陷、降本、客户要求、供应商或元器件停产、安全或法规）、支撑它的证据、紧急程度，以及这项变更是否触及任何与安全相关的内容或客户已批准的特性。
写下你们关于形状、配合与功能的判定
评估这一步要判断的是：更改后的零件是否仍然与旧零件可以互换。请记下你们自己对“可互换”的规则，以及由此带来的后果——因为一项破坏互换性的变更，通常需要一个新的零件号，而不是把现有零件号升一个版本。配置管理的实践把这件事挂在互换性上，而不是挂在变更看起来有多大。
让成本评估覆盖旧库存所在的每一个位置
给供应链那一步一份清单：在库存货、在制品、在途货物、未结采购订单与供应商承诺、成品、寄售库存与服务备件。呆滞是多数变更申请最容易低估的成本，而它通常正是把一项明显有益的变更变成暂缓变更的那个因素。
订下生效与处置的规则
决定生效点是用日期、序列号或批号，还是旧库存用完的那一刻来表达，并把这个选择写在 ECN 上，而不是留给排产工单的人。然后约定由谁批准用完、返工与报废，以及各自的成本记在哪里。
定义首件验证的含义，并发布这张图
写明由谁制造首件、由谁检验、检查哪些特性、由谁签署；在航空领域这由 AS9102 规范，其中一项设计变更通常至少触发一次部分首件检验。然后把这张图与 ECR 表单放在一起共享，并保留历史版本，使你们能够说明程序是何时改的、为什么改。
常见问题
ECR、ECN 与 ECO 有什么区别？
工程变更申请（ECR）是提案：什么出了问题或可以做得更好、为什么这件事重要，以及它触及哪些零件。它是向变更控制委员会提出的一个问题。工程变更通知（ECN）是答复，只在批准之后签发：它授权新的修订版本，列出受影响的图纸、零件号与物料清单，设定生效点，并说明现有库存的处置方式。工程变更单（ECO）在许多企业里与 ECN 混用，也有一些企业用 ECO 指内部作业指令、用 ECN 指发给客户与供应商的通知。请选定一种约定并写进程序里，因为同一家公司里混着用，会让“到底授权了什么”产生真实的混乱。
它与 IT 变更管理或一般的变更控制流程有什么不同？
形状相似（申请、评估、批准、实施、验证），内容却不同。IT 变更管理把一项变更推入正在运行的服务，因此评估围绕受影响的服务、停机窗口、回滚方案与影响范围，通常由变更经理和 CAB 主持。工程变更把一个修订版本推入实物产品，因此评估围绕互换性、工装、成本、供应商交期，以及按旧版本已制造的库存怎么办，通常由包含研发、制造与供应链的变更控制委员会主持。如果你们要记录的是代码或基础设施如何进入生产环境，请改用 IT 变更管理或变更控制模板。
什么时候一项变更需要新的零件号，而不是新的版本？
通常的判定是互换性。如果按新定义制造的零件，能够在每一种应用中替代旧零件而不需要任何其他改动，并且旧零件也能替代新零件，那就是一次版本升级。如果不能——因为形状、配合或功能已经变了——那通常需要一个新的零件号，使两个版本能够在库存、物料清单与售后服务中并存。配置管理实践与图纸版本标准把这条规则建立在互换性上，而不是建立在变更看起来有多大上；这也正是为什么在这张图里，形状、配合与功能的评估位于委员会决策之前，而不是之后。
按旧版本已经制造出来的库存怎么办？
那就是“现有库存如何处置？”这一决策，它需要在 ECN 上有一个明确的答案，而不是一个默认的假设。用完意味着旧库存先被消耗，生效点设在用尽的那一刻——这是最省钱的选项，而当变更是为了修复一个缺陷或一个安全问题时，它是错误的选项。返工意味着把现有库存提升到新版本，其成本与工时记在这项变更上。报废意味着把库存核销。同样的问题也适用于在制品、在途货物、存放在供应商处的库存，以及——对于与安全相关的变更——已经在客户手中的产品，这可能把变更升级为一次针对已交付产品的现场处置行动，而不再是一份例行的 ECN。
谁应当进入变更控制委员会？每一项变更都需要经过它吗？
委员会需要那些能够动用资金与产能的人：研发、制造或工业化、供应链或采购，以及质量；当一项变更对客户可见时，还要有销售或项目管理参与。它不需要所有人。多数企业会设一条界线，使低风险的变更（一条图纸备注、一次公差澄清、一项没有成本影响也不影响互换性的变更）由一位具名的研发授权人批准，只有越过这条界线的变更才提交完整委员会。请把这条界线写在批准决策旁边，并像记录批准一样认真地记录暂缓的决定——因为一项被暂缓的变更，通常会在那批卡住它的库存或合同了结之后再回来。