如何為SOP做版本控制
SOP 版本控制，即為每一次程序修訂編號，把安全關鍵變更送經實機重新培訓與簽署核對表，而不是閱讀確認，並把被取代的副本退役。
運作方式
在第一次修訂之前，先訂定 SOP 編號方案
為每一份 SOP 派一個識別碼與一個整數修訂號，連同生效日期與審批人一併印在每一頁的頁首。只需要決定一次，因為日後重新編號，會弄斷每一份引用過舊編號的培訓紀錄與審計軌跡。
把申請記在它所改動的那個修訂之下
在任何人動手改草稿之前，先開一項申請，寫明要改的確切步驟與原因——一宗事故、一次虛驚、一項偏差。把它輸入圖表的「方框文字」欄，用「連線至」指向把申請記在現行修訂之下的那一列，令申請繫於一個版本，而不是憑空浮動。
明確強制作出安全關鍵判斷
給工作流程一列「決策」形狀，問是否影響安全關鍵步驟，並在「連線文字」欄寫上兩條標籤分支。把「是」送去有記錄的安全影響評估，「否」送去標準適用性審閱——絕不讓申請人或審批人憑假設略過這個問題。
安全關鍵路徑要卡在實機重新培訓，而不是確認回條
獲批之後，安排強制實機培訓，並要求一張已簽署的能力核對表，變更才可以上線。一列只寫「閱讀並確認」的，屬於標準路徑，不屬於安全關鍵路徑——把兩者保持為獨立的列，令這個分別在日後重排時仍然存在。
把兩條路徑匯合到同一次登記冊更新
無論變更走了哪一條分支，都要把它送進同一列「檔案」形狀的列，更新 SOP 登記冊並把上一個修訂標示為作廢，然後才把新版本發布為現行版本。單一個匯合點，代表只有一個地方需要檢查每一條路徑是否真的令舊副本退役。
確認每一位受影響的操作員，不只是排更表上的那些
發布之前，對照每一個更次、每一位承辦商，逐一核對重新培訓或確認是否完成，而不只是變更獲批那一刻剛好在場的那一隊。漏掉一個夜更，正是每個審核周期都會重複出現的發現。
常見問題
SOP 版本控制跟一般文件版本控制有分別嗎？
有，而且分別很具體：SOP 的版本控制必須回答的是新修訂生效之前誰需要重新培訓，而不只是哪一份副本是現行的。一般文件版本控制——見 /yue/guides/如何為文件做版本控制——管治的是任何受控文件的編號、審批與撤回。SOP 在此之上多加一個能力問題：修訂編號遞增了，並不會阻止操作員沿用舊方法，除非他已經接受過新版本的重新培訓，所以 SOP 的版本控制紀錄，除了一般的審批軌跡，還必須帶有培訓或確認狀態。
安全關鍵的 SOP 變更，應該跟輕微變更走不同路線嗎？
安全關鍵變更——即做錯這個步驟會有受傷、不合格產品或違反法規風險的變更——需要一次有記錄的安全影響評估、一個 QA 把關的審批，以及附簽署能力核對表的實機重新培訓，才可以上線。非安全關鍵變更則可以走標準適用性審閱、一般審批與閱讀並確認。把兩者都送進同一條輕量路徑，結果就是一次措辭微調跟一次上鎖步驟的改動，被要求提供同一套憑證——對前者太多，對後者太少。
培訓紀錄跟 SOP 的版本控制是同一回事嗎？
不是——兩者回答的問題不同，一套 SOP 流程兩樣都需要。版本控制追蹤哪個修訂是現行的、誰批准了它、它取代了甚麼；培訓紀錄追蹤誰已經證明了在那個修訂上具備能力。QueryChart 在 /features/version-control 的版本歷史覆蓋第一項：帶欄位級差異的變更日誌、比較版本畫面與還原。上文提到安全關鍵變更所需的簽署能力核對表，覆蓋第二項，而兩者需要引用同一個修訂編號，否則審核員無從判斷受訓的人，是否對應現行的程序。
審核員對一次 SOP 修訂，期望看到的最低限度憑證是甚麼？
印在文件上的修訂編號與生效日期、誰在何時批准的紀錄、一個繫於啟動它那項申請的、有記錄的變更原因，以及——對任何安全關鍵的情況——一份有日期、有簽署、點名誰接受了重新培訓、對應哪個版本的能力紀錄。SOP 文件本身的路由與審批機制，見受控 SOP 範本 /yue/templates/受控標準作業程序範本；兩個修訂之間確切改了甚麼這個較窄的問題，見 /yue/guides/如何追蹤sop的變更。