ISO 四階文件是什麼？品質管理系統四階文件與程序書怎麼寫才能被系統執行

我們在做 QMS 系統開發時，最常卡住的地方在讀程序書，技術問題反而好解。有一次讀到一條寫著「本作業以系統電子版本為準」，回頭一問才知道，那套系統還沒有，條文先寫上去了。這種句子一旦進了程序書，下次稽核就是現成的把柄。

品質管理系統的四階文件，指的是品質手冊、程序書、作業指導書、表單與紀錄這四層。它決定了你的系統最後做得出什麼：程序書寫得能判定，系統就跑得起來；程序書寫得模糊，工程師只能來問你，或者自己猜一個。

四階文件是什麼，先看這張表

四階文件是一個由上往下、愈下面愈具體的金字塔。上面兩層講規則，下面兩層留證據。

這裡先講一個多數人沒注意到的事實：四階文件是台灣的慣例，ISO 9001 條文本身並沒有規定你一定要分四階。2015 年改版之後，強制的品質手冊與六大程序書就取消了，改成「文件化資訊」這個統稱，文件要多深、用什麼格式，由公司自己決定（可參考領導力企管整理的改版問答）。話說回來，稽核員與客戶端的二方稽核還是照這個結構在看，所以架構留著沒問題，麻煩的是內容。

程序書寫了「以系統電子版本為準」，系統卻還沒有

這是我們看過最危險的一種寫法，而且相當常見。公司決定要導系統，顧問或品保就先把程序書改成電子流程的敘述，可是系統要半年後才上線，中間這段時間現場仍然在跑紙本。

文件說的是 A，現場做的是 B，這在稽核裡是標準的不符合事項。台灣工廠最常見的 ISO 管理問題整理裡，「程序寫 A、現場實際做 B」被列在第一條，成因多半是文件由顧問或品保單方面編寫，沒讓實際操作的人參與確認。

安全的做法只有兩種：要嘛程序書暫時保留紙本與電子併行的敘述，等系統驗收完成再改版；要嘛在改版單上寫清楚生效日期，並讓生效日晚於系統上線日。改版生效日與上線日對不起來，是稽核最好抓的一種落差。

文件的版次、生效日與簽核紀錄要能在系統裡查得到，靠的是文件管制這一段做得夠完整；這部分要自己開發時怎麼抓規格與預算，可以看文件管理系統（DMS）開發指南。

過渡期的三種寫法，稽核風險差很多

系統上線前的那段空窗，程序書怎麼寫，決定稽核當天有沒有話講。把常見的幾種寫法攤開來比，差別相當清楚。

四種寫法的分水嶺只有一條：文件描述的狀態，跟稽核員走進現場看到的狀態，對不對得起來。最省事的做法是把文件改版計畫與系統驗收里程碑放進同一張時程表，改版生效日直接掛在驗收通過之後，這一題就不會發生。導入專案的階段怎麼排、每一段該交出什麼，可以參考導入八階段的交付物與負責人，QMS 的時程邏輯跟 ERP 是同一套。

程序書這樣寫，系統做不出來

先給結論：程序書裡每一個「適當時」「必要時」「視情況」，都是一個工程師無法轉成程式的條件。系統要的是可判定的輸入：時間、次數、金額、角色、狀態。

改寫的原則就三條：把形容詞換成數字、把泛稱換成角色、把「應該做」換成「什麼情況下一定要做」。這件事誰來做？由寫程式的人來改是最糟的選項，因為他改的是文件，卻沒有品保的授權。正確的順序是品保先改程序書，系統照著改過的版本做。

表單跟程序書打架時，以哪一份為準

答案很明確：以程序書為準，表單要跟著改。程序書是二階，表單是四階，階層高的說了算，這在稽核邏輯上沒有模糊空間。

實務上打架的情況比你想的多。常見的長相是表單上印死了一個數字（例如效果追蹤欄位固定寫三批），但程序書寫的是「依風險等級決定追蹤範圍」。兩份文件放在一起，稽核員會問：那到底是幾批？

這一題在導系統的時候會被放大，因為系統必須選一邊做。我們的做法是先攤開兩份文件比對，把不一致的地方整理成清單交回品保，由他們決定改哪一份。廠商主動指出這件事，比上線後才被稽核抓到便宜太多。

中英文版本不同步，是最常被抓的那一條

有海外廠或外商客戶的公司，程序書通常有中英文兩個版本，而改版時只改一邊，是台灣製造業最常見的隱藏風險之一。

原因很單純：中文版是品保自己改的，英文版要等翻譯，翻譯回來又沒人再看一次。三、五次改版之後，兩個版本的判定條件已經不一樣了，客戶稽核拿英文版來對，現場拿中文版在做。

系統能幫上忙的地方在這裡：把同一份程序書的兩個語言版本綁在同一個版次上，其中一個語言沒更新完，這個版次就不能生效。這是一個很小的設計決定，卻能擋掉整類問題。如果你正在評估要走套裝、ERP 模組還是客製，這一條會直接影響選擇，我們在品質管理系統軟體怎麼選那篇有整理三條路的差別。

程序書裡藏著的系統需求，報價時常常漏算

程序書裡只要出現「每月彙整」「定期上傳」「季報」這類字眼，幾乎都代表系統要多產出一張報表，而這件事在報價時常常沒人算進去。

這類條文的長相很好認：有週期（每月、每季）、有動作（彙整、上傳、通報）、有對象（客戶、主管機關、集團總部）。三個要素湊齊，就是一張要開發的報表或一支要做的匯出功能。

實際做法很簡單，在需求訪談時拿著程序書逐條掃一次，把所有帶週期的條文抄下來變成報表清單。這份清單交給廠商報價，數字才不會在開發到一半的時候往上跳。功能範圍怎麼拆，可以參考客製化 QMS 品質管理系統開發指南。

帶週期的條文長這樣，一條就是一張報表

掃過幾本程序書之後會發現，被漏算的報表幾乎都長同一個樣子。下面這幾種最常見，可以直接拿去對自己手上的文件。

最右邊那一欄才是真正花錢的地方。週期跟對象通常寫得清楚，口徑、格式與門檻卻幾乎都留白，開發做到一半才回頭問品保，時程就是這樣被拖掉的。訪談時把這一欄一起問完，報價的數字才站得住。從訪談到驗收中間會經過哪些節點、每一段要簽收什麼，系統開發流程的七個節點那篇有拆得比較細。

動工前先做這份四階文件盤點

系統開工前該做的盤點只有五題，做完再找廠商，報價會準很多。

• 模糊條文清單：把所有「適當時、必要時、視情況、相關人員」圈出來，逐條改成可判定的條件。
• 表單與程序書的矛盾清單：印死在表單上的數字，跟程序書的敘述對一次。
• 語言版本對照：中英文版的版次與生效日是否一致。
• 週期性條文清單：每月、每季要產出什麼，對應成報表需求。
• 生效日規劃：哪幾份程序書要等系統上線後才改版，寫進改版計畫。

這五份清單同時也是驗收依據。上線那天拿出來一條一條對，系統做到的跟文件寫的才會是同一件事。四階文件與 CAPA、8D 這些流程怎麼接，我們正在把 QMS 是什麼、ERP 與 MES 的分工、ISO 9001 與 IATF 16949 的差異寫成一整個系列，這篇談的是文件這一層。

回到盤點這件事本身，它做完還會給你一個副產品：這套系統真正的規模。多數公司在詢價階段講的是「我們要做一套 QMS」，廠商手上真正在算的是條文數量、判定條件數量與報表數量。這三個數字攤在桌上，雙方對範圍的認知才會一致，開發到一半也不會冒出「這個當初有講吧」的爭執。

誰來做這份盤點，答案通常也很清楚：品保出人，廠商出問題清單，兩邊各花兩三個半天把程序書逐條過一次。品保知道哪一條是客戶硬要求、哪一條是歷年稽核被開過的老傷；廠商知道哪一種寫法系統做得出來、哪一種要多花一倍工。這幾個半天的成本，跟上線後回頭補開發的成本擺在一起看，幾乎可以忽略。

我們怎麼看

品質文件接下來幾年會往「條文即設定」的方向走。程序書寫下的判定條件，會愈來愈直接變成系統裡的參數，改條文等於改系統行為，中間不需要再開一次工。這代表程序書的寫法會變成一種技術能力，寫得含糊的公司，系統就跟著含糊。

我們的取捨是在做 QMS 系統開發時，把「讀程序書、標出做不出來的條文」當成專案第一階段的正式產出，而不是開發途中順手處理的雜事。給品保主管與廠長一個判斷工具：拿你們最常用的那本程序書，數一數裡面有幾個「適當時」和「必要時」。這個數字，大致就等於你的系統上線後需要回頭補的開發量。

我們做過這件事 恆遠是一支會自己做產品的開發團隊，目前有 40+ 企業客製案落地，做的多半是簽核、表單與內部營運這類每天在跑的系統。我們在做 QMS 系統開發時，第一件事就是把程序書的條文逐條翻成系統做得出來的規則，這一段做得夠細，後面的開發跟驗收才不會吵架。 如果你手上的程序書正打算配合系統改版，可以把目前的文件架構與卡住的條文丟過來，我們很樂意聽你聊聊現在的實際情況，一起看看哪些地方要先改。

想討論你的四階文件怎麼配合系統改，可以從聯絡我們開始。