在硬體產品開發的過程中，我經常會碰到 RD、採購或其他團隊提出各式各樣的設計變更需求。
例如，某顆 IC 因為價格太貴，希望更換成其他供應商的料件；或是機構 RD 發現原本的設計有些問題，需要修改模具；甚至是產品都快準備量產了，卻突然發現某個功能還需要進一步優化。
這些需求乍聽之下似乎都不難，不就是換一顆料、修改一下設計嗎？
但實際參與過硬體產品開發的人應該都知道，電子產品的設計往往牽一髮而動全身。
一個看似不起眼的修改，背後可能牽涉好幾個部門的重新驗證，甚至影響整個產品的量產時程。
也因此，在科技業中，我們會透過一套稱為 ECN（Engineering Change Notice）的工程變更管理機制，確保每一次設計修改都經過適當的評估、審核與執行。
今天就從硬體 PM 的角度，帶大家了解 ECN 是什麼，以及為什麼產品開發過程中的設計變更，遠比想像中還要複雜。
看完這篇文章後，你會有以下三點收穫：
- ECN 是什麼？在硬體產品開發中扮演什麼角色？
- 為什麼修改一顆零件，就可能影響整個產品的開發？
- 硬體 PM 該如何管理設計變更，避免影響成本與量產時程？
ECN 是什麼？為什麼硬體開發需要工程變更管理？
ECN 的全名是 Engineering Change Notice，中文稱為「工程變更通知」，是硬體產品開發中用來管理設計變更的一種機制。
簡單來說，當產品原本已經定義好的設計、料件或工程文件需要修改時，就可能需要透過 ECN 流程來進行管理。
以我在品牌廠的工作經驗來說，公司內部就有專門的系統，讓 RD 或 PM 可以在上面發起工程變更，並由相關單位依照內部流程進行審核與管理。
舉例來說，假設某款手機原本使用 A 供應商的 IC，但因為價格、供貨或技術問題，我們決定改用 B 供應商的產品。
這時候，就不能只是 RD 私下跟採購說一聲，然後請工廠直接更換料件。
因為這項變更可能牽涉 BOM、電路設計、功能驗證、庫存管理，甚至連工廠的生產作業都需要跟著調整。
因此，一個完整的工程變更管理流程，通常會包含以下幾個階段：
提出變更需求 → 評估影響 → 審核核准 → 更新工程文件 → 正式導入
在這個過程中，除了確認修改內容是否正確，更重要的是釐清變更原因、受影響的產品版本，以及何時開始正式生效，避免不同部門使用到不一致的設計或料件。
順帶一提，科技業還有一個常見名詞叫做 ECR（Engineering Change Request，工程變更申請），主要用來提出工程變更需求，並進行初步評估。
有些公司會區分 ECR、ECO（Engineering Change Order）與 ECN 等不同階段，但每家企業的作業方式不盡相同。
以我自己的工作經驗來說，平常比較常接觸的是 ECN，因此這篇文章也會以 ECN 為主進行介紹。
為什麼硬體產品改一個小地方這麼麻煩？
我認為，這是整篇文章最值得分享的地方。
一台智慧型手機可能由數百甚至上千個零組件組成，而這些零件並不是各自獨立運作的，它們在電路、機構、散熱、軟體等方面，往往存在密切的關聯。
RD 花了好幾個月，才讓各個功能達到預期的表現，並通過一連串的驗證測試。
但這時候如果突然要修改其中一個零件，就可能破壞原本好不容易達成的設計平衡。
以下分享三個在硬體產品開發中常見的情境。
1. 更換一顆 IC，可能需要重新驗證整個功能
假設某顆 IC 因為價格上漲，採購希望 RD 評估能否改用其他供應商的產品。
乍看之下，只要新 IC 的規格相近、功能一樣，應該就能直接替換了吧？
其實沒那麼簡單。
首先，RD 必須確認新 IC 的工作電壓、Pin Definition、功耗與通訊介面等規格是否相容。如果不相容，可能還需要修改 PCB Layout，甚至連帶調整其他電路設計。
即使硬體規格相容，也不代表軟體就不需要修改。不同供應商的 IC 可能使用不同的 Driver 或 Register 設定，這些都需要軟體團隊協助評估。
更麻煩的是，原本已經完成的功能驗證，可能需要針對受影響的項目重新執行。
如果涉及 RF、EMC 或其他法規相關功能，甚至可能需要重新評估認證是否受到影響。
所以在硬體開發中，我們不會單純因為某顆料比較便宜，就貿然決定更換供應商，而是必須把修改成本、驗證時程與潛在風險一起考慮進去。
畢竟，如果省下幾塊錢的 BOM Cost，卻因此造成產品 Delay 一個月，那可就得不償失了。
2. 修改機構設計，可能影響模具與生產時程
另一個常見的情境，就是機構件的修改。
例如，產品已經完成模具開發，但在組裝驗證時發現某個零件的公差不符合預期，導致組裝困難。
這時候，機構 RD 可能需要修改設計，並請模具廠進行修模。
但問題來了，修模不只需要額外的費用，更可能影響原本的開發時程。
修改後的零件需要重新試模、量測與驗證，確認問題已經解決，而且沒有產生新的干涉、強度或可靠度問題。
如果修改幅度較大，甚至可能需要重新開模，讓成本與時程進一步增加。
更重要的是，如果原本已經安排好工廠的試產時程，這次修改還可能導致整個 Build Schedule 被迫往後延。
有時候真正花時間的不是 RD 修改設計，而是後續等待供應商重新製作樣品、安排驗證，以及工廠重新排程。
所以一個看似不起眼的機構修改，背後可能牽涉模具費用、驗證資源、供應商交期，以及整個產品開發時程。
這也是為什麼 PM 在評估設計變更時，不能只問 RD「改這個要多久」，而是必須把相關單位的影響全部考慮進去。
3. 量產後的設計變更，還要處理庫存問題
前面兩個例子主要發生在開發階段，但如果產品已經進入量產，事情可能更加複雜。
假設某款產品已經量產半年，現在 RD 希望導入新的 PCB 版本，以改善某項功能。
除了重新驗證新版本之外，PM 還需要考慮一個非常現實的問題：
舊版本的庫存怎麼辦？
可能品牌廠、EMS 工廠與供應商手上，都已經有一定數量的舊版物料。
如果直接切換新版本，舊料可能就變成呆滯庫存，甚至需要報廢。
因此，實務上我們通常會討論幾種做法：
- Running Change（自然切換）： 在不影響品質與功能的前提下，先消耗舊版庫存，再逐步導入新版本。
- 立即切換： 如果涉及重大品質或安全問題，可能必須立即停止使用舊版料件。
- Rework（重工）： 如果舊版物料可以透過修改或重新加工滿足新規格，也可能考慮重工，而不是直接報廢。
這些方案沒有絕對的好壞，必須依照變更原因、庫存數量、品質風險與成本綜合評估。
而且如果新舊版本之間存在相容性問題，還必須清楚定義哪些零件可以混用、哪些不能混用，避免工廠在生產或維修時使用到錯誤的組合。
這也是為什麼我認為，產品進入量產後，設計變更管理反而更加考驗 PM 的跨部門協調能力。
因為這時候要考慮的已經不只是技術問題，還有實際的庫存、現金流與供應鏈管理。
硬體 PM 如何管理 ECN 設計變更？
前面講了這麼多，大家應該可以理解，為什麼產品設計變更需要一套正式的管理流程。
但從 PM 的角度來看，我認為真正重要的不是熟悉 ECN 系統怎麼操作，而是能否在變更正式執行前，充分掌握這項修改會帶來哪些影響。
我通常會從以下三個面向進行評估。
1. 這項變更真的有必要嗎？
並不是所有改善建議都必須立即執行。
如果是影響產品安全、法規或主要功能的問題，通常就需要優先處理。
但如果只是一些使用者不容易察覺的小幅優化，我們就需要思考，是否值得為此付出額外的成本與時程。
特別是在產品即將量產的階段，任何設計變更都可能產生很大的連鎖效應。
我自己在評估這類問題時，通常會先思考：
「如果現在不改，會有什麼後果？」
如果不改也不影響產品正常使用，那麼是否能夠等到下一次改版，甚至下一代產品再導入？
不是每一個可以改善的地方，都值得我們立即投入資源去修改。
2. 這項變更會影響哪些單位？
這是我認為硬體 PM 最需要發揮價值的地方。
RD 可能比較關注技術上能不能修改，但 PM 必須站在更全面的角度，確認這項變更對整個專案的影響。
例如，RD 認為修改電路只需要三天，但新料件可能需要四週才能交貨；或者新設計已經驗證完成，工廠卻還需要額外準備治具。
如果只關注設計本身，而忽略其他部門的工作，最後還是有可能造成專案 Delay。
所以我認為，PM 的價值不在於比 RD 更懂技術，而是能夠整合各個團隊的資訊，提前找出可能影響專案的風險。
3. 什麼時候導入最合適？
即便變更方案已經確定，也不代表一定要立即執行。
有時候，我們會選擇在下一次試產時導入；有時候則會等到下一批量產，甚至下一代產品才進行修改。
尤其是涉及庫存、認證或生產流程的變更，導入時機往往比修改本身更加重要。
舉例來說，如果某項變更可以降低產品成本，但需要花費大量時間重新驗證，我們就必須評估這項修改帶來的效益，是否足以彌補額外投入的資源。
如果距離產品 EOL（End of Life，產品生命週期結束）只剩下幾個月，那麼這項修改可能根本無法回收投入成本。
相反地，如果產品預計還要銷售好幾年，那麼即使短期需要投入一些驗證費用，長期下來仍然可能相當划算。
因此，PM 必須根據產品的生命週期、銷售預估與專案時程，協助團隊決定最合適的導入時間。
結語：產品開發是一門不斷取捨的藝術
在科技業工作一段時間後，我越來越能體會到，硬體產品開發其實是一門不斷取捨的藝術。
工程師希望產品設計能夠持續優化，採購希望成本越低越好，工廠希望生產流程越穩定越好，而業務則希望產品能夠準時上市。
每個人的出發點都沒有錯，但這些目標並不總是能夠同時滿足。
而 PM 的工作，就是在不同團隊的需求之間找到平衡，確保每一次設計變更，都能為產品帶來足夠的價值，而不是單純為了改善而改善。
我認為，ECN 的存在不只是為了讓產品變更有紀錄，更重要的是讓每一次修改都經過充分的討論與評估，確保相關團隊知道自己需要做什麼，以及這項變更可能帶來哪些風險。
有時候，知道什麼地方不該改，比知道怎麼改還要重要。
這也是我認為硬體 PM 最需要累積的能力之一：不只是管理專案時程，更要學會判斷每個決策背後的成本與風險。
如果你對硬體產品開發、PM 工作實務或科技業的運作方式有興趣，歡迎持續關注巫師札記，也可以訂閱我的電子報，未來我會持續分享更多第一線的工作經驗。
另外，我也將過去在品牌廠累積的部分經驗整理成硬體 PM 電子書，希望能幫助想進入這個產業的朋友，更快理解真實的工作內容，少走一些冤枉路。
