SOP 版本控制最佳做法
超越一般文件管制的 SOP 版本控制最佳做法：把安全關鍵修訂卡在強制重新培訓之後、每份 SOP 只有一位負責人、在每一個存在的地方退役已取代副本，並按風險設定檢討周期。
SOP 版本控制最佳做法，是疊加在一般文件版本控制之上、專屬於標準作業程序的紀律——安全關鍵修訂的重新培訓關卡、SOP 本身的單一問責負責人、由每一個使用點撤回，以及按營運風險設定的檢討周期。
簡而言之
- 把安全關鍵修訂卡在實機重新培訓與簽署能力查核之後，不是閱讀並確認——見 /yue/templates/標準作業程序變更控制流程。
- 為 SOP 本身指定一位問責負責人，跟誰起草最新修訂無關。
- 從每一個使用點——工位活頁夾、告示板、共用磁碟——撤回一份已被取代的 SOP，不只是登記冊。
- 按營運風險設定檢討周期，不要不分每份 SOP，一律套用同一個周年日期。
- QueryChart 的變更日誌與比較版本畫面（/features/version-control），不需要額外流程就給你誰改了哪個欄位的憑證。
一般清單會略過的四項紀律
本頁假設機制已經在運作。如果你的修訂歷史紀錄冊仍然需要一套工作流程——誰起草一條項目、誰審閱它、誰簽署——那見 /yue/guides/如何追蹤sop的變更，令項目按時推進的節奏見 /yue/guides/如何管理sop修訂。這兩頁都沒有問的是：這套做法一旦運作起來，是否真的做得好；而對 SOP 來說，「好」的意思比對一份政策或試算表範本更窄。
/yue/guides/文件版本控制最佳做法 覆蓋的是一般紀律——一個穩定的識別碼、一個權威位置、一個有具名負責人的檢討周期——這些規則每一條仍然適用於 SOP。額外的地方在於，SOP 告訴某人如何用雙手實際執行一項工作，所以一次改動程序的修訂，改變的是一個人雙手實際做的事，不只是檔案上寫了甚麼。由這個分別衍生出四項做法，一份通用文件清單完全沒有理由提及其中任何一項：安全關鍵修訂上線前的能力關卡、繫於 SOP 本身而不是最後一位起草人的負責歸屬、能觸及工位而不只是登記冊的撤回，以及按風險而不是統一日曆日期設定的檢討周期。
四項之中有三項，直接出現在下面示例走一遍的修訂歷史紀錄冊裡：一條把部分項目導向不同路徑的安全關鍵分支、一次查核同一份 SOP 有沒有已開立的重複項目，以及一個必須觸及使用中副本、不只是紀錄冊的撤回步驟。第四項——單一問責負責人——是一條關於誰被記名在紀錄上的規則，而不是靠某種圖表形狀強制執行的東西。QueryChart 自己的版本歷史，為圖表本身給文件管理員同一種憑證：帶欄位級差異的變更日誌、比較版本畫面，加上一鍵還原，全部免費並且預設開啟，完整說明見 /features/version-control。
這些做法，在一本真實紀錄冊裡出現在哪裡
同一本 18 列的修訂歷史紀錄冊，早前兩篇指南已經走過一遍，這次讀的是它在負責歸屬、路由與撤回這幾方面做對了甚麼。
負責人在任何人起草之前，先標記風險
起點列是一個事件——「已識別 SOP 需要變更」——流程負責人泳道會先描述變更及其原因，然後「決策」列「變更是否影響安全關鍵步驟？」才把它送往兩條路線之一。
一份 SOP 一條項目，不是一位編輯一條項目
「修訂歷史紀錄冊是否已有這份 SOP 的待處理項目？」查核是否有一條正在進行中的重複項目，「與待處理項目的負責人協調」則把它合併或排序，而不是任由兩條待處理項目產生兩個候選版本號。
審閱與審批查核的是項目，不只是草稿
審批人那一列，會對照「SOP 主檔及所取代的版本」查核項目，不單是草稿；一次被駁回的「是否批准？」分支，會返回跟審閱人未了結意見同一個返工列。
鎖定，然後在每一個地方撤回
「記錄為定案」鎖定日期、審批人姓名與版本編號，令這一行之後不能被悄悄改寫，然後「撤回或存檔被列為已取代的版本」必須觸及工位的列印本，不只是這條紀錄項目，SOP 才會重新發放。
運作方式
為安全關鍵修訂加上重新培訓關卡
任何觸及安全關鍵步驟的修訂，上線之前都要送經實機重新培訓與簽署能力核對表，而不是閱讀並確認。/yue/templates/標準作業程序變更控制流程 把這個關卡呈現為一個 QA 審批分支，在每一位受影響的操作員簽署之前，擋住上線。
為每一份 SOP 指定一位問責負責人
把負責人的名字，放在 SOP 紀錄本身一個跟任何一次修訂作者分開的欄位裡。負責歸屬應該撐得過人事變動或起草交接；如果「負責人」是最後編輯這個檔案的人，就沒有人真正對這份文件的一生負責。
按使用點建立一張撤回清單
在發放之前，列出一次修訂會觸及的每一個地方——工位活頁夾、告示板、共用磁碟、入職資料包——並在被取代副本撤下時逐一剔除。一條標記為「已撤回」、牆上卻仍然貼着列印本的登記冊項目，並沒有真正被撤回。
按風險分級檢討周期，不要用統一日曆
給安全關鍵的 SOP 比低風險行政性 SOP 更短的周期；為每一份文件蓋上同一個周年日期，會把檢討變成一項沒有人有時間認真做好的形式。在 SOP 發放時就設定周期，不要等登記冊剛好標記出來才決定。
用變更日誌證明這套做法，不要只靠登記冊自己的說法
在圖表上打開比較版本，準確看到哪個欄位改了、由甚麼值改成甚麼、誰批准的，而不是依賴修訂歷史紀錄冊自己對自己的說法。QueryChart 在每一張圖表上都免費保留這份版本歷史——見 /features/version-control。
應避免的錯誤
一個甚麼都證明不了的簽名
一張閱讀並確認的回條，證明有人打開過檔案，不證明他能夠正確執行新方法。把它保留給低風險變更，凡是安全關鍵步驟，一律要求附簽署核對表的實機重新培訓。
隨每一次修改而改變的負責歸屬
如果問責預設落在最後碰過草稿的人身上，一位離職的作者，會令 SOP 完全沒有負責人。在 SOP 上一次過指定負責人角色，並且刻意去更新它，而不是任由作者身份自然漂移進這個角色。
登記冊裡已撤回，牆上卻仍然在用
在紀錄冊裡把一次修訂標示為作廢，對貼在工位上的膠面副本沒有任何作用。在信任那張撤回清單之前，先親自走一遍——你找到的每一份副本，都是流程漏掉的一個地方。
所有 SOP 不論風險都用同一個周期
一個統一的周年檢討日期，會把高風險的 SOP 變成低優先次序的文書工作，也會把低風險的 SOP 變成浪費掉的檢討產能。按 SOP 管治的內容分級周期，不要按它剛好到期的日子。
建立你自己的 SOP 修訂歷史紀錄冊
把 SOP 修訂歷史示例開成你自己的圖表，並把安全關鍵分支、負責人欄位與檢討周期，改成你自己 SOP 的版本。
相關指南
常見問題
SOP 版本控制跟一般文件版本控制有分別嗎？
機制是一樣的——一個穩定的識別碼、一份權威副本、一個檢討周期——/yue/guides/文件版本控制最佳做法 已經覆蓋。分別在於出現缺口的後果：SOP 告訴某人如何用雙手實際執行一項工作，所以一份過時或未撤回的副本，改變的是一個人實際做的事，這正是為甚麼 SOP 的做法要多加一個重新培訓關卡與一個使用點撤回查核，是一份政策或表格不需要的。
一次修訂何時需要重新培訓，而不是閱讀並確認？
當這次變更影響安全關鍵步驟——任何用舊方法做會造成受傷、不合格產品或違反法規的情況。/yue/templates/標準作業程序變更控制流程 把這種情況送經 QA 把關的審批與附簽署能力核對表的強制實機重新培訓；其餘的可以走較輕量的閱讀並確認路徑。
SOP 的負責人跟 SOP 的作者，應該是同一個人嗎？
不一定，把兩者分開通常是較耐久的安排。作者起草某一次具體修訂；負責人則對這份 SOP 一生所有修訂負責，包括原作者離職之後，由其他人起草的那些。
SOP 版本控制跟 SOP 變更控制是同一回事嗎？
不是。版本控制是你如何識別與追蹤修訂；變更控制則是一項擬議變更在成為一次修訂之前，要經過的工作流程關卡。一般的分別見 /yue/guides/版本控制與變更控制的分別，而專屬於 SOP 的部分，/yue/templates/標準作業程序變更控制流程 正是產生出本頁這些做法其後所管治的那個版本的變更控制關卡。
