如何為SOP做版本控制
SOP 版本控制，即為每一次程序修訂編號，把安全關鍵變更送經實機重新培訓與簽署核對表，而不是閱讀確認，並把被取代的副本退役。
SOP 版本控制，是把每一次程序修訂，繫於一個編號、一份審批紀錄與一項重新培訓要求的紀律，令操作員永遠不會依照一份已作廢的副本，去執行一個安全關鍵步驟。
簡而言之
- 為每一次 SOP 修訂編號，並印在每一頁上——這個編號正是培訓紀錄與審計軌跡共同指向的東西。
- 把安全關鍵變更送經有記錄的安全影響評估與實機重新培訓，而不是閱讀並確認。
- 一張簽署過的能力核對表，是重新培訓的憑證；一張已讀回條，只證明有人打開過檔案。
- 安全關鍵與標準這兩條審閱路徑，最終仍會匯合到同一步：把上一個修訂標示為作廢。
- QueryChart 的變更日誌與比較版本畫面（/features/version-control）顯示誰改了哪個欄位，不需要另一本登記冊。
過時的 SOP，不是歸檔問題
SOP 記錄的不是一般情況下應該發生甚麼——它是此刻當值的人正在跟從的確切次序，這正是為甚麼 SOP 的版本控制，比一份政策或試算表範本承擔更大的風險。一份過時的市場簡報修訂版，頂多令某人白費一個下午。一份過時的上鎖掛牌程序或批次放行核對表修訂版，卻可能令某人失去一隻手，或者放行一批不合格產品，因為操作員一絲不苟地跟從牆上那張紙，做的正正就是流程要求他做的事——即使那張紙已經落後兩個修訂版。
一般的文件版本控制，見 /yue/guides/如何為文件做版本控制，問的是哪一個檔案現行、誰批准了它。SOP 版本控制則為每一次變更多問一個問題：在有人改用不同方式執行那個步驟之前，誰需要先接受重新培訓，以及你如何證明他們確實接受過。登記冊上遞增一個編號，並不會阻止操作員繼續用舊方法；只有一份已完成、有日期、有簽署、並且繫於新修訂編號的培訓紀錄，才做得到——這正是為甚麼一份受控 SOP 的審批工作流程（見 /yue/templates/受控標準作業程序範本）必須交接到重新培訓這一步，而不是止於「已批准」。
下面的圖表正正在這個判斷上分岔——「是否影響安全關鍵步驟？」——因為兩個答案要求不同的憑證。安全關鍵變更會經過一次有記錄的安全影響評估、一個 QA 把關的審批，以及附簽署能力核對表的實機重新培訓；非安全關鍵變更則走標準適用性審閱與閱讀並確認。把兩條路徑合併成一條，或者把一張已讀回條當成安全關鍵步驟的能力憑證，正是這套流程存在的目的所要防止的審核發現。QueryChart 自己的版本歷史——見 /features/version-control——讓 QA 團隊用變更日誌與比較版本畫面，查核每一個修訂是否真的走了這條路，而不需要另一本與圖表實際記錄脫節的平行試算表登記冊。
安全關鍵分岔，逐階段拆解
一項 SOP 變更由申請開始，經一個判斷把它送進安全審閱與實機重新培訓，或者標準審閱與已讀回條。
一項申請，記在某個修訂之下
「已提出 SOP 變更」開始這條鏈，然後「提交變更申請並附上原因」與「把申請記錄在現行 SOP 修訂之下」，在「評估擬議變更的運作影響」開始之前，把申請繫於一個具體版本——到這裡都還未有人評判這項變更，只是記錄了它是甚麼、取代了甚麼。
決定嚴謹程度的分岔
「是否影響安全關鍵步驟？」令流程分岔：答「是」會經「進行有記錄的安全影響評估」，再到「提交變更套件作 QA 把關的審批」，由第二個「是否批准？」判斷把關，駁回會直接返回安全評估，而不是繞過它。
實機重新培訓對標準審閱
獲批的安全關鍵變更走到「安排強制實機重新培訓」與「完成實機培訓並簽署能力核對表」——一次有監督、有簽署的實地操演，不是一張已讀回條——而「否」分支則走「完成標準適用性審閱」，進入自己的「提交變更套件作審批」與「是否批准？」關卡。
兩條路徑匯合到同一次登記冊更新
標準路徑仍然以「派發更新後的 SOP 作閱讀並確認」與「閱讀並確認新版本」結束，而兩條路徑會在「更新 SOP 登記冊並把上一個修訂標示為作廢」匯合，然後「把新修訂發布為現行的受控版本」令它成為現行版本。
運作方式
在第一次修訂之前，先訂定 SOP 編號方案
為每一份 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的變更。
