ISO 9001：2026 的變更，是要讓管理系統活過來 — 系統變更，不是新增文件，而是重新檢視企業營運的連動性

2026/06/09

最近在閱讀 ISO 9001：2026 FDIS 版本時，我們自己特別有感的一個方向，是標準開始更明確強調「系統變更（Changes to the management system）」。

但同時我們也認為，這會是這次改版中很容易被錯誤解讀的地方。

因為條文使用了「A planned manner」這個用語，且明確提到，為確保變更的有效性，企業在進行系統變更時，應將變更的目的與潛在後果、管理系統的完整性、職責與權限的分配或重新分配，以及變更溝通等事項列入考量，並進一步思考如何監督、評估變更的有效性，以及如何審查變更後的結果。

也正因為條文把這些事項寫得相對具體，所以很容易讓顧問、稽核員或企業產生一個直覺反應：
那是不是只要新增一份「系統變更管理程序」，再設計一張「系統變更申請表」或「系統變更評估報告」，就可以符合要求了？

不要急著新增一份系統變更程序

如果只是這樣理解，我們認為反而偏離了這次改版真正的精神。

因為系統變更真正要談的，不只是「變更有沒有被申請、審查與核准」，而是企業在發生明顯變化後，有沒有重新回到原本的管理系統，確認相關流程、權責、文件、風險與目標是否仍然適用。

這件事其實可以從很多企業常見的「設計開發」和「設計工程變更」看出來。

很多企業在執行品質管理系統時，會把設計開發和設計工程變更分成兩份文件撰寫，然後將這兩份文件當成兩條平行線在管理。但設計工程變更，很多時候其實也是啟動新一輪設計開發的來源之一。

不管企業是依據哪一種新產品開發流程，例如 APQP、NPI 或 C-FLOW，當開發完成並移轉量產後，如果發生需要設計工程變更的情況，企業若只是完成 ECR、ECN 就結案，卻沒有追溯至原開發流程所產出的技術文件，進行變更後相應的審查、驗證或確認，就有可能發生「原規劃」和「變更後放行基準」不一致的問題。

所以我們自己會建議企業，未來在面臨改版時，針對系統變更不用急著新增一份「系統變更管理程序」。

可以試著先從營運治理的面向下去思考，當企業發生明顯變化時，哪些既有的管理機制應該被重新檢視？哪些既有的管理系統文件，應該被同步補充或調整？例如：

條文編號^【註1】	條文名稱^【註1】	可能對應文件^【註2】
4.1	了解組織及其環境	組織背景分析管理程序
4.2	了解利害關係人的需求與期望	利害關係人調查管理程序
4.3	確定品質管理系統的範圍	品質手冊
4.4	品質管理系統	品質手冊
5.1	領導統御及承諾	品質手冊
5.2	品質政策	政策及目標管理程序
5.3	角色、職責與權限	組織權責管理程序
6.1	應對風險和機會的行動	風險及機會管理程序
6.2	品質目標及實現目標的計劃	政策及目標管理程序

註1：上表條文編號及條文名稱，係依 ISO 9001：2026 FDIS 版本內容進行對照與整理。
註2：上表所列文件僅為可能對應之管理系統文件舉例，企業仍應依自身組織架構、營運模式及實際管理需求進行適當調整與對應。

經營計畫管理，才是系統變更的重要連結點

我們要特別再次提醒，上面表格列出來的文件，不是要嚇倒大家，也不是要讓大家覺得有這麼多文件都要重新修訂。

因為在我們的實務輔導經驗中，這些章節多半都屬於「經營管理」的範疇，不一定要被拆成很多份獨立文件來處理。很多時候，一份設計得好的「經營計畫管理程序」，就應該能夠涵蓋這些條文背後的管理精神。

畢竟，經營管理本來就是一氣呵成的。

條文編號^【註1】	條文名稱^【註1】	條文對經營計畫的意義
4.1	了解組織及其環境	取得影響公司經營過程中可能發生的議題，知道議題的來源，了解要做到什麼程度。
4.2	了解利害關係人的需求與期望	了解客戶、法規、供應商、員工、股東及其他相關方對公司營運的要求，判斷哪些需求與期望會影響經營方向及品質管理系統。
4.3	確定品質管理系統的範圍	決定公司經營過程中有控制權的營運邊界，包括產品、服務或活動，以及組織邊界，包括場址或地點。
4.4	品質管理系統	盤點和規劃公司營運邊界或組織邊界內有哪些任務、工作或作業。
5.1	領導統御及承諾	將品質管理系統融入公司的經營活動，並提出承諾。
5.2	品質政策	經營階層要給出公司經營的策略方向
5.3	角色、職責與權限	針對營運邊界或組織邊界的每項任務、工作或作業，指定負責的單位和人員。
6.1	應對風險和機會的行動	各項任務、工作或作業的指定負責單位和人員，針對公司營運所屬業務下的任務、工作或作業進行風險和機會分析，確定要採取什麼行動。
6.2	品質目標及實現目標的計劃	針對各項任務、工作或作業的重大風險和機會，決定好：要完成什麼？要看到什麼效果？要取得什麼？要做到什麼程度？