如何管理 SOP 修訂
如何管理 SOP 修訂：在需要之前先訂定編號方案，按風險而非統一日期設定檢討周期，為整本登記冊指定一位負責人，並把「沒有變更」的檢討也記錄為憑證。
管理 SOP 修訂，即是管治這些修訂所居住的那本登記冊本身——它的編號方案、檢討節奏與負責人——而不只是描述某一條項目改了甚麼。
簡而言之
- 在登記冊的第一條項目之前，先訂定編號方案——日後為一個已在運作的檔案庫重新編號，會弄斷每一份引用過舊編號的交叉引用與培訓紀錄。
- 按風險設定檢討周期，不要不分每份 SOP 管治的是甚麼，一律套用同一個周年日期。
- 為整本修訂登記冊指定一位負責人，跟任何一份 SOP 的作者或審批人是不同的人。
- 把一次沒有發現需要變更的檢討，記錄為它自己一條有日期的項目——審核員抽查的是有沒有檢討的憑證，不是有沒有變更的憑證。
- 在重複的待處理項目相撞之前先攔截它們，否則同一份 SOP 會出現兩個候選版本號。
- QueryChart 自己的變更日誌與比較版本畫面（/features/version-control），給登記冊本身，配上它要求每份 SOP 都要保留的同一種歷史。
登記冊，比任何單一項目都大
一本修訂歷史紀錄冊，可以有十一條完美無瑕的項目，卻仍然是一項審核發現的成因——因為第十二條項目，在兩位 SOP 作者同時開立時，從未獲派編號；或者因為沒有人說得準去年三月那次既定檢討有沒有真的發生過。會寫 SOP 的機構，通常都很擅長描述某一條項目改了甚麼。出錯的，是那些項目周圍的登記冊：編號方案、每份 SOP 到期檢討的周期，以及其中任何一環出岔子時，誰要負責。
這幾個詞常被鬆散地混用，值得在往下講之前先分清楚。一次修訂，是一條有日期的項目——SOP 內容的一次變更，連同作者與原因一併記錄。它的版本，則是那條項目所產生的編號，印在現行已發放副本上的那個。修訂控制，是隨時間管理那一連串項目；它坐落在較廣泛的文件管制之內，後者同時管治分發與撤回。本頁講的是把整本登記冊當成一個整體去運作；記錄單一項變更的機制，見 /yue/guides/如何追蹤sop的變更。
下面的圖表，是一次修訂在那本登記冊裡走一遍，由變更被識別的一刻，到 SOP 重新發放的一刻，橫跨五條泳道：流程負責人、SOP 編寫人、審閱人、審批人、文件管理員。QueryChart 為自己的圖表提供同一種管治：每一次儲存都寫進變更日誌，附上誰改了甚麼的欄位級差異，比較版本畫面把任何兩個版本並排顯示，一份過時的版本一鍵就能還原——全部見 /features/version-control。
一條項目，由識別到重新發放
一項修訂申請，走過五條泳道——由流程負責人到文件管理員——成為登記冊下一條編了號的項目。
一項變更被識別，並按風險分流
起點是一個事件，「已識別 SOP 需要變更」，其後是「描述擬議的變更及原因」，在任何人起草一條項目之前發生。「變更是否影響安全關鍵步驟？」是登記冊自己的風險分流，決定這條項目走加急審閱還是標準周期。
路由、重複檢查，然後才是草稿
「把項目標記為加急審閱」或「把項目送經標準審閱周期」定下節奏，然後「修訂歷史紀錄冊是否已有這份 SOP 的待處理項目？」，在第二條待處理項目與第一條相撞之前先攔截它。到這裡，「起草修訂歷史項目：日期、變更摘要、作者、被取代的版本」才會被寫下並提交。
審閱人與審批人都會查核那個編號
「審閱人對照現行 SOP 內容查核項目」可以透過「審批前是否有待了結的意見？」把草稿送回；「審批人對照 SOP 主檔及所取代的版本查核項目」是針對同一個被取代編號、獨立的第二重查核，而一次駁回會循環返回跟審閱人意見同一個更新列。
登記冊負責人定案並重新發放
「在修訂歷史紀錄冊中把已批准的項目記錄為定案」，會在「更新 SOP 的版本號與生效日期」與「撤回或存檔被列為已取代的版本」執行之前，先鎖定這一列，最終以「SOP 以新版本重新發放」結束——這四步全部由文件管理員負責。
運作方式
在第一條項目之前，先訂定編號方案
一次過決定已發放的修訂用整數（1、2、3），還是用一套把草稿與已發放副本分開的主版本.次版本方案，並把規則寫下來。絕不要為修正一個舊有的不一致，而重新為一本正在運作的登記冊編號——重新編號的序列，會令每一份引用過舊編號的交叉引用、培訓紀錄與之前的審計軌跡全部失效。
按風險設定檢討周期，不要用一條通用規則
安全關鍵的 SOP 應該有比低風險 SOP 更短的周期；圖表本身的「變更是否影響安全關鍵步驟？」分支，正是套用在個別變更上的同一種分流，檢討節奏也值得用同一套邏輯。把周期寫進 SOP 的頁首本身，成為一個到期日，令它不用依賴某人記得一項政策。
為整本登記冊指定一位負責人
SOP 的作者起草它的項目，審批人為它簽署，但兩者都不對登記冊整體負責——不對逾期三週的項目負責，也不對沒有人設定檢討日期的 SOP 負責。把這份工作交給一個具名角色，通常是文件管理員或品質經理，由他們去追蹤逾期的項目。
把「沒有變更」的檢討，記錄為它自己的一條項目
當一次既定檢討確認一份 SOP 仍然正確，就把這個結論連同日期與審閱人姓名寫進登記冊，方式跟記錄一次真正的修訂一樣。一本只有在內容改動時才會增長的紀錄冊，在審核員眼中，讀起來就像一份自寫成以來沒有人看過的文件。
在重複項目相撞之前先攔截它們
起草一條新項目之前，先查核這份 SOP 是否已經有一條待處理項目——登記冊裡「修訂歷史紀錄冊是否已有這份 SOP 的待處理項目？」這個問題之所以存在，是因為兩位作者在同一份主檔上工作，常見到值得特意繞開。把變更合併，或者為項目排出先後次序，令紀錄冊永遠不用為同一份文件調解兩個候選版本號。
應避免的錯誤
為修正一個舊有的不一致而重新編號
一旦修訂 4 已經被一份培訓紀錄或供應商資料包引用過，現在把它改成 4.1 去遷就一套更整齊的方案，就代表同一段日期範圍，對應着兩個不同的編號。一次過決定方案，然後管治例外，而不是重整整個序列去遷就它們。
所有 SOP 都用同一個十二個月檢討日期
在同一個周年日檢討每一份程序，會產生一疊沒有人有時間仔細讀的文件，檢討淪為一個橡皮圖章。像圖表的安全關鍵分支對待個別變更那樣，把周期按風險錯開，令審閱人真正有時間逐一處理。
沒有變更的檢討，沒有留下項目
一本只在內容改動時才有項目的登記冊，在審核員眼中，看起來就像一份自發放以來沒有人打開過的文件。把檢討日期與「不需要變更」這個結論，記錄為它自己獨立的一行，跟一次真正的修訂區分開來，但同樣真實。
沒有單一負責人的登記冊
當任何一位 SOP 作者都可以開立一條新項目，而沒有人在看管登記冊整體，重複的草稿與錯過的檢討日期，都會一直不被發現，直到一次審核揪出它們。這個問題周圍的完整文件生命周期——包括誰擁有主登記冊——見 /yue/templates/文件管制流程。
建立你自己的 SOP 修訂登記冊
由這張圖表開始，QueryChart 會把每一次儲存都記錄在一份你可以比較與還原的變更日誌裡。
相關指南
常見問題
SOP 的「修訂」跟它的「版本」有甚麼分別？
修訂，是一條有日期的項目——SOP 內容的一次變更，連同作者與原因一併記錄。它的版本，則是那條項目所產生的編號，印在現行已發放副本上的那個。實際上兩個詞常被當成同一回事使用，但登記冊本身是圍繞修訂來組織的：每一列是一次修訂，而版本，是最新一次修訂獲批之後 SOP 所處的狀態。QueryChart 自己的版本歷史（/features/version-control）用「版本」的方式也一樣——一次儲存所產生、帶編號、可比較的快照。
一份 SOP 應該多久檢討一次？
沒有一個適用於所有程序的單一周期——正確答案取決於這個步驟一旦失效，代價有多大。安全關鍵或面向法規的 SOP，通常一年檢討一次，甚至更頻密；低風險的行政性 SOP，兩到三年檢討一次也是安全的。比具體數字更重要的是，每一份 SOP 都要有一個檢討周期，寫進它的頁首成為到期日，而不是留給剛好發現它逾期的人。
誰應該擁有 SOP 修訂登記冊？
一個跟任何一份 SOP 的作者或審批人都不同的人——通常是文件管理員或品質經理，正是上面圖表自己一條泳道裡，負責為每一條已批准項目定案的角色。作者與審批人各自對一次修訂負責；登記冊則需要一個人對整體負責：追蹤逾期的檢討、攔截重複的項目，並保持編號方案穩定。
一次沒有發現需要變更的檢討，仍然算數嗎？
算數，而且需要它自己的紀錄去證明。審核員抽查一本修訂登記冊時，找的是檢討有沒有按時發生的憑證，不是 SOP 有沒有改動的憑證——一份寫得正確的程序，理應維持多年不變。把檢討日期與「不需要變更」這個結論，記錄成一條有日期的項目，否則兩次修訂之間的空白，讀起來會像疏忽，而不是穩定。
這跟追蹤 SOP 每一次個別變更有甚麼分別？
追蹤個別變更，是項目層面的事：改了甚麼、誰改的、取代了甚麼，這是 /yue/guides/如何追蹤sop的變更 討論的主題。管理 SOP 修訂，則是登記冊層面的事：每一條項目都要跟從的編號方案、每份 SOP 到期檢討的周期，以及其中任何一環出岔子時的具名負責人。一本登記冊可以把每一次個別變更都記錄得完美無瑕，卻仍然因為沒有人擁有那份時間表而管理得很差。本頁以外更完整的一套管治做法，見 /yue/guides/sop版本控制最佳做法。
