工程變更申請流程圖（ECR 到 ECN）
工程變更申請流程圖：ECR 的問題與理由、形狀配合與功能評估、成本與存貨評估、變更管制委員會決策、ECN、生效點與舊存貨處置。
甚麼是工程變更申請流程圖（ecr 到 ecn）流程
工程變更申請（ECR）是一份提案，要求更改某個已經發布的對象：一個零件、一個組件、一張圖紙、一份物料清單、一種材料，或一個已批准的供應商零件。ECR 承載問題與理由。如果變更管制委員會批准了它，產出就是一份工程變更通知（ECN，在許多企業裡稱為工程變更單或 ECO）。ECN 是授權新修訂版本的那份指令：它寫明受影響的零件、圖紙與物料清單，說明變更何時生效，並訂明按舊版本已經製造出來的存貨該如何處理。
這不是資訊科技變更管理。ITIL 式的變更請求把一項變更推入正在運行的服務，衡量的是停機、回退與服務風險，那是資訊科技變更管理工作流程與變更管制流程這兩份範本所涵蓋的內容。ECR 把一個實物修訂版本推入生產，它必須回答完全不同的問題：零件是否仍然可以互換、模具與工裝要花多少錢，以及已經在倉庫裡和在訂單上的那些產品會怎樣。它也不是文件管制——文件管制管的是程序與政策的版本，而不是產品定義本身。而且這條流程由設計發布之後才開始：產品仍在開發期間所作的更改屬於設計與開發流程，而由不符合項引發的變更則透過 CAPA 調查，ECR 只是把已議定的解決方案落到圖紙上的那個機制。
多數工程變更程序在技術評估上很扎實，在其他每一處都很單薄。可行性得到像樣的檢討，其後舊料呆滯、模具與供應商交期的成本在走廊裡被隨口估一估，生效日期被記成「盡快」，而採購員要等到一批來貨在收貨處被拒收時才知道。這份範本正是為此畫成五條泳道：申請人、工程部、變更管制委員會、製造與供應鏈。成本、存貨與呆滯風險在委員會表決之前，在供應鏈泳道裡成為獨立的一步；生效點與存貨處置也成為明確的步驟，而不是預設的假設。
本流程圖涵蓋的內容
本範本包含
- 五條泳道（申請人、工程部、變更管制委員會、製造、供應鏈）分佈在五個階段：申請、技術評估、委員會決策、變更通知與發布，以及實施與驗證
- 申請人與工程部泳道中的受理：提出工程變更申請、寫明原因與理由、把 ECR 登記入變更登記冊，其後是委員會的初步篩選決策「申請是否完整而且理由充分？」——它在投入工程工時之前，把內容單薄的申請退回補充細節
- 一項分三部分的評估，每條泳道一步：工程部評估可行性以及對形狀、配合與功能的影響；製造評估對模具與工藝的影響；供應鏈評估在庫存貨、在製品、在途貨物與未結供應商承諾上的成本、存貨與呆滯風險
- 「是否批准該變更？」這個決策帶有三個具名結果：批准並進入變更通知、在申請人泳道被駁回並結束，或者暫緩——暫緩會把變更留到日後的發布批次，並把它退回委員會，而不是任由它一直開著
- 工程部與製造泳道中的發布：簽發工程變更通知（ECN）、更新圖紙與物料清單、訂定變更生效日期，其後是「現有存貨如何處置？」這個決策，通往用完、返工或報廢
- 實施與驗證：向供應商通報新版本、更新工作指引與模具、製造並檢驗首件，其後是「首件是否合格？」——不合格會回到圖紙與物料清單的更新，合格則結束該變更
何時使用本範本
- 你們要為一家製造、硬件或按單設計的企業編寫或重做 ECR/ECN 程序，尤其是當現時的流程只有一張表格、背後沒有議定路徑時
- 你們要就誰進入變更管制委員會、他們在決定之前看到甚麼、以及哪些變更工程經理可以不召開委員會就批准，達成共識
- 你們打算在 PLM 或 ERP 系統中設定變更工作流程，希望先梳理流程，令工具固定下來的是眾人已經議定的路徑，而不是軟件暗示的那一條
- 你們要為設計工程師、計劃員、採購員與品質人員做入職培訓，他們需要知道自己簽署之後這項變更會怎樣，以及自己的那一步在哪裡
- 客戶或審核員查問設計變更是如何受控的，而你們還要落實供貨協議中關於向客戶通報變更的責任
運作方式
把泳道改成你們真實的角色
把申請人、工程部、變更管制委員會、製造與供應鏈，換成你們實際擁有的職能。在規模較小的企業裡，變更管制委員會可能就是每星期碰一次面的兩個人，而製造工程與生產計劃或許是同一條泳道。請合併泳道，而不是發明角色，並把總數保持在五條或以內，令這張圖仍然讀得下去。
界定甚麼樣的 ECR 才算完整
只有當「完整而且理由充分」指向某份寫下來的內容時，初步篩選決策才起作用。一個可用的最低要求：受影響的零件編號及其現行版本、原因（缺陷、降低成本、客戶要求、供應商或元件停產、安全或法規）、支撐它的證據、緊急程度，以及這項變更是否觸及任何與安全相關的內容或客戶已批准的特性。
寫下你們關於形狀、配合與功能的判斷
評估這一步要判斷的是：更改後的零件是否仍然與舊零件可以互換。請記下你們自己對「可互換」的規則，以及由此帶來的後果——因為一項破壞互換性的變更，通常需要一個新的零件編號，而不是把現有零件編號升一個版本。組態管理的實務把這件事掛在互換性上，而不是掛在變更看起來有多大。
令成本評估涵蓋舊存貨所在的每一個位置
給供應鏈那一步一份清單：庫存貨、在製品、在途貨物、未結採購訂單與供應商承諾、製成品、寄售存貨與服務備件。呆滯是多數變更申請最容易低估的成本，而它通常正是把一項明顯有益的變更變成暫緩變更的那個因素。
訂下生效與處置的規則
決定生效點是用日期、序號或批號，還是舊存貨用完的那一刻來表達，並把這個選擇寫在 ECN 上，而不是留給排生產工單的人。然後議定由誰批准用完、返工與報廢，以及各自的成本記在哪裡。
界定首件驗證的含義，並發布這張圖
寫明由誰製造首件、由誰檢驗、檢查哪些特性、由誰簽署；在航空領域這由 AS9102 規範，其中一項設計變更通常至少觸發一次部分首件檢驗。然後把這張圖與 ECR 表格放在一起分享，並保留舊版本，令你們能夠說明程序是何時改的、為甚麼改。
常見問題
ECR、ECN 與 ECO 有甚麼分別？
工程變更申請（ECR）是提案：甚麼出了問題或可以做得更好、為甚麼這件事重要，以及它觸及哪些零件。它是向變更管制委員會提出的一個問題。工程變更通知（ECN）是答覆，只在批准之後簽發：它授權新的修訂版本，列出受影響的圖紙、零件編號與物料清單，訂定生效點，並說明現有存貨的處置方式。工程變更單（ECO）在許多企業裡與 ECN 混用，也有一些企業用 ECO 指內部作業指令、用 ECN 指發給客戶與供應商的通知。請選定一種約定並寫進程序裡，因為同一家公司裡混著用，會令「到底授權了甚麼」產生真實的混亂。
它與資訊科技變更管理或一般的變更管制流程有甚麼不同？
形狀相似（申請、評估、批准、實施、驗證），內容卻不同。資訊科技變更管理把一項變更推入正在運行的服務，因此評估圍繞受影響的服務、停機時段、回退方案與影響範圍，通常由變更經理和 CAB 主持。工程變更把一個修訂版本推入實物產品，因此評估圍繞互換性、模具、成本、供應商交期，以及按舊版本已製造的存貨怎麼辦，通常由包含工程、製造與供應鏈的變更管制委員會主持。如果你們要記錄的是程式碼或基礎設施如何進入生產環境，請改用資訊科技變更管理或變更管制範本。
甚麼時候一項變更需要新的零件編號，而不是新的版本？
通常的判斷是互換性。如果按新定義製造的零件，能夠在每一種應用中替代舊零件而不需要任何其他改動，並且舊零件也能替代新零件，那就是一次版本升級。如果不能——因為形狀、配合或功能已經變了——那通常需要一個新的零件編號，令兩個版本能夠在存貨、物料清單與售後服務中並存。組態管理實務與圖紙版本標準把這條規則建立在互換性上，而不是建立在變更看起來有多大上；這也正是為甚麼在這張圖裡，形狀、配合與功能的評估位於委員會決策之前，而不是之後。
按舊版本已經製造出來的存貨怎麼辦？
那就是「現有存貨如何處置？」這個決策，它需要在 ECN 上有一個明確的答案，而不是一個預設的假設。用完意味著舊存貨先被消耗，生效點設在用盡的那一刻——這是最省錢的選項，而當變更是為了修正一個缺陷或一個安全問題時，它是錯誤的選項。返工意味著把現有存貨提升到新版本，其成本與工時記在這項變更上。報廢意味著把存貨撇賬。同樣的問題也適用於在製品、在途貨物、存放在供應商處的存貨，以及——對於與安全相關的變更——已經在客戶手上的產品，這可能令變更升級為一次針對已交付產品的現場處置行動，而不再是一份例行的 ECN。
誰應當進入變更管制委員會？每一項變更都需要經過它嗎？
委員會需要那些能夠動用資金與產能的人：工程、製造或工業化、供應鏈或採購，以及品質；當一項變更對客戶可見時，還要有銷售或專案管理參與。它不需要所有人。多數企業會設一條界線，令低風險的變更（一條圖紙註記、一次公差澄清、一項沒有成本影響也不影響互換性的變更）由一位具名的工程授權人批准，只有越過這條界線的變更才提交完整委員會。請把這條界線寫在批准決策旁邊，並像記錄批准一樣認真地記錄暫緩的決定——因為一項被暫緩的變更，通常會在那批卡住它的存貨或合約了結之後再回來。