從階段放行、反覆驗證到設計輸出，讓設計開發真正接上量產與品質管理
ISO 9001：2026 已於 2026 年 9 月 16 日正式公告。這次改版在設計與開發的要求上，有幾個變化我覺得很值得企業重新思考。
過去輔導 ISO 9001 時，我看過很多公司的設計開發流程，基本架構都很類似：規劃、輸入、審查、驗證、確認、輸出。 不能說這樣錯，因為它確實來自 ISO 9001 的條文架構。但問題是，公司的產品真的都是照著這六個步驟一路走到底嗎？
實務上往往不是。
有些產品會先做概念設計，再打樣、試作、測試、客戶承認，最後才進入量產；有些軟體或服務，可能一邊開發、一邊測試、一邊取得使用者回饋，再回頭修改需求。 所以我認為，這次 ISO 9001：2026 對設計開發帶來的一個重要訊號，就是：
設計開發不應該只是按照條文管理，而應該按照公司的「專案」管理。
設計開發，本來就不是一條直線
新版 8.3.1 的備註提到，產品與服務的設計開發可以透過審查、驗證、確認及回饋等循環，在整個設計開發過程中保持彈性。 而 8.3.3 的備註也進一步提醒，設計輸入不一定從一開始就能完全定義或全部知道，而可能隨著設計演進、反覆開發及循環驗證持續變化。 這兩段我認為非常貼近企業真正的開發現場。因為很多事情，本來就不可能在專案第一天全部想清楚。
客戶需求可能會改、測試可能發現原本的規格不可行、供應商可能提出材料替代方案，甚至做到樣品之後，才發現原本沒有想到的使用問題。 所以「輸入會變」本身並不可怕，真正需要管理的是：為什麼變？變了什麼？誰確認？又影響了後面哪些設計內容？ 這才是設計開發真正需要的管理。
與其按照條文切流程，不如按照里程碑設關卡
因此，每次我在協助企業規劃和設計 8.3 的管理方式或規範時，我反而不會急著先問：「8.3.2、8.3.3、8.3.4 要各做哪一張表？」，我會先問：
你們一個產品從想法到量產，中間到底會經過哪些重要階段？
因為概念確認、設計定案、樣品完成、工程驗證、客戶承認、試量產、量產移轉，都可能是企業自己的專案里程碑。 接下來才是在每一個重要階段確認：進到下一關以前，哪些事情必須完成？哪些結果必須審查？哪些功能需要驗證？哪些使用需求需要確認？最後又由誰決定可以往下一階段走？ 這樣一來，ISO 所要求的審查、驗證、確認，就不會變成三張為了稽核而存在的紀錄，而是真正嵌進公司的專案管理。 要注意：
結構化不代表僵化，而是可以反覆修正，但每一次往前走，都要知道自己為什麼可以往前走。
設計輸出，不應該只為了「設計結案」
另一個我在輔導現場很常看到的問題，是設計部門完成了圖面、BOM、規格書，專案就準備結案；但到了量產，製造、品保、採購又開始重新整理自己需要的文件。 真正好的設計輸出，不只是證明「我們設計完成了」，而應該能直接成為後續營運的依據。 例如圖面與 BOM 可以銜接採購與生產；製程條件可以轉成作業標準；產品特性與允收條件可以轉成檢驗規範；設備、治工具需求可以銜接量產準備；使用限制、警語及維護方式，也可以進一步成為使用說明與客戶溝通資訊。
而當後續發生工程變更時，這些輸出也應該跟著影響評估同步更新，而不是只改了一張圖面或一個料號。 設計做完之後，後面的人拿得到、看得懂、接得起來；設計改變之後，後面的人也知道什麼跟著改，這才叫真正的「輸出」。
工程變更，可以有自己的流程，但不能脫離原來的設計開發
談到設計開發，我覺得還有一件事情很值得企業重新思考，就是「設計工程變更」。 實務上，有些公司會把設計開發與工程變更整合在同一套流程裡；也有很多公司在產品量產之後，另外建立工程變更管理程序，透過 ECR（Engineering Change Request）、ECN（Engineering Change Notice）進行申請、評估、核准與通知。 這兩種做法，我認為都沒有問題，但不管工程變更是獨立管理，還是整合在設計開發流程裡，我在輔導時都會要求企業回頭確認一件事情：
這一次的變更，對原始設計開發到底造成了哪些影響？
因為 ECR、ECN 只是承載工程變更資訊的工具，完成表單的簽核，也不代表變更管理就已經完成。例如材料替代，可能影響產品性能；零件尺寸調整，可能影響組裝、治工具與檢驗方式；軟體版本變更，可能讓原本已經驗證過的功能需要重新測試；製程或設備改變，也可能影響原來設定的產品特性與允收條件。 所以真正要判斷的，應該是：原來的設計輸入有沒有改變？風險需不需要重新評估？哪些設計輸出受到影響？原來做過的審查、驗證與確認，哪些仍然有效？哪些必須重新執行？
從這個角度來看，工程變更其實可能重新啟動一輪品質規劃與設計開發。
而且依照變更的程度不同，需要重新走的階段也不一定相同。小幅度變更可能只需要重新驗證其中幾項性能；重大變更則可能從需求、設計輸入、風險評估、試作、驗證、確認，一路重新走到量產放行。因此我常提醒企業：
設計開發歷經哪些階段，工程變更就可能重新歷經哪些階段。
差別只在於，不是每一次變更都要全部重來，而是要先做好影響性評估，再決定應該「回到哪一站」，以及從那一站開始，哪些里程碑需要重新確認。
所以工程變更程序可以獨立，表單也可以不同，但管理邏輯不能與設計開發切斷。真正成熟的工程變更管理，不是把 ECR、ECN 簽完，而是能夠回答：「這次改了什麼？影響了原來哪些設計條件？因此，我們需要重新走哪些設計開發階段？」
這也正好呼應 ISO 9001：2026 對設計開發循環與彈性的思維——設計不是量產後就宣告結束，而是在產品生命週期中，隨著需求、問題與變更，必要時重新回到適當的設計階段，再一次確認產品仍然符合原來預期的要求。
關於新版標準對「變更」的整體思維，可延伸閱讀 ISO 9001：2026 的變更，是要讓管理系統活過來。
設計開發真正要管理的，是產品從「想法」走到「成熟」的過程
所以回頭來看 ISO 9001：2026 這次對設計開發的調整，我認為真正值得企業注意的，不是哪一張表單要增加、哪一個程序要改版，而是我們怎麼看待「設計開發」這件事情。 產品從一開始的需求與構想，到設計、試作、驗證、確認、量產，本來就不是一條只往前走的直線。過程中會遇到新的資訊、測試結果、客戶回饋與技術問題，有時候往前走，有時候也必須回頭修正。
即使進入量產，也不代表設計開發從此結束。當材料、零件、製程、設備、軟體或客戶需求發生變更時，我們仍然要回頭確認：原來的設計條件還成立嗎？哪些結果仍然有效？這一次又需要回到哪一個階段重新確認？
因此，我認為真正好的設計開發管理，應該像一張有「里程碑」的專案地圖。 我們可以反覆修正，也可以因為變更回到前面的某一站，但每一次準備往下一站走之前，都應該知道該完成什麼、確認什麼，以及憑什麼可以繼續往前。
標準給我們的是管理架構，但企業真正要建立的，是一條符合自己產品與專案特性的開發路徑；而品質，就是在一次次的確認、修正與放行之間，逐步被設計出來的。 如果我們能做到這件事，「不設計不良」就不再只是一句品質口號，而會真正成為後面「不接收不良、不製造不良、不流出不良」的起點。