SOP 修訂歷史範本

運作方式

1. 把泳道改成你們真實的角色

   把流程負責人、SOP 編寫人、審閱人、審批人與文件管理員，換成你們實際採用的職銜。在小型團隊裡，SOP 編寫人與流程負責人往往是同一個人——把這兩條泳道合併，而不是留一條空置的；如果品質主管同時做審閱和簽署，就改為合併審閱人與審批人。

2. 定下安全關鍵的判斷準則

   寫低甚麼情況會令一項變更被送去加急審閱，而不是把「變更是否影響安全關鍵步驟？」交由個人判斷：涉及上鎖步驟、關鍵控制點或法規規定查核的變更，應該一律合資格；其餘一律預設走標準周期。

3. 定下每條紀錄項目必須包含的欄位

   在起草這一步，定下登記冊所需的確切欄位：項目日期、SOP 編號、以淺白語言寫的變更摘要、作者，以及被取代的版本號。無論加急還是標準項目，欄位都保持一致，令紀錄冊不會因為走哪條路線而有出入。

4. 決定重複項目如何解決

   定下「修訂歷史紀錄冊是否已有這份 SOP 的待處理項目？」背後的規則：第二項變更是等待第一項結案、合併進同一條項目，還是另行記錄並附上交叉參照？三種做法都可行，只要紀錄冊不會出現兩條同時聲稱同一個版本號的項目。

5. 定下你們的版本編號與生效日期規則

   固定版本號如何遞增——常見做法是已發放的修訂用整數、草稿用小數——並定下生效日期需要預留多長時間，好讓文件管理員可以在生效之前更新總登記冊，並淘汰被取代的副本。

常見問題

甚麼是 SOP 修訂歷史紀錄冊？

它是一份日期登記冊，列出一份 SOP 的每一個版本，以及版本之間改了甚麼：項目的日期、誰提出這項變更、變更摘要、誰審閱與批准了它，以及它取代了哪個版本。它與 SOP 本身的審批簽署是分開的——SOP 記錄誰批准了現行版本，修訂歷史紀錄冊則記錄令它走到這一步的整個版本序列。

這與 SOP 本身的審批流程有甚麼分別？

/yue/templates/受控標準作業程序範本 那個受控 SOP 範本，把程序內容本身送經起草、審閱與審批，產生一個現行的、已簽署的版本。這張圖則是那套流程每次產生新版本時寫入的登記冊——一份只可新增的歷史，記錄日期、作者、摘要與被取代的版本號，作為獨立的一份文件保存，令這個序列可以獨立於文件本身留存下來。

為何在起草新項目之前，要先查核是否有待處理的項目？

因為兩個人可以在同一個審閱周期內，各自對同一份 SOP 提出變更而互不知情，如果兩條項目各自獨立走到審批，紀錄冊最終就會出現兩行，各自聲稱取代同一個版本。在起草之前的最初階段就查核，可以令第二項變更協調進第一條項目，而不是等到審批階段才發現有衝突。

是不是每一項 SOP 變更都要走加急路線？

不是。加急路線是為安全關鍵步驟的變更而設，因為由識別變更到生效之間的時距必須短。其餘的——澄清用字、排版、非關鍵的程序性變更——都應該走標準審閱周期，因為把所有變更都當成加急處理，會令設有兩條路線的意義盡失。