如何追蹤SOP的變更
如何追蹤 SOP 的變更：一條修訂歷史項目必須記錄甚麼——改了甚麼、誰改的、何時、為何，以及取代了哪個版本——加上安全關鍵的加急分流。
追蹤 SOP 的變更，即是記錄一條有日期的修訂歷史項目——改了甚麼、誰改的、何時、為何，以及取代了哪個版本——而不是依賴文件內的追蹤修訂標記。
簡而言之
- 一條修訂歷史項目需要五個欄位：受影響的 SOP／步驟、改了甚麼與為何、生效日期、作者，以及它取代的版本。
- 安全關鍵步驟走加急審閱路徑；其餘一律走標準審閱周期。
- 起草新項目之前，先查核紀錄冊裡有沒有同一份 SOP 的待處理項目——兩條待處理項目會產生兩個互相競爭的版本號。
- 把一條項目定案，會鎖定它的日期、審批人與版本編號，令這份紀錄之後不能被悄悄改寫。
- 對一份以圖表為本的 SOP，QueryChart 的變更日誌會自動記錄每一次欄位級修改——見 /features/version-control。
紀錄是一條項目，不是一條追蹤修訂標記
「追蹤修訂」是 Word 與 Google Docs 的語言：一個留言氣泡、一條刪除線，活在檔案本身裡面。一份借用了這個詞、卻沒有借用其機制的 SOP，最終會令變更歷史散落在電郵串與沒有人合併過的追蹤修訂副本裡，而程序負責人無法肯定地說出上一次修訂改了甚麼、何時改的、為甚麼改。SOP 裡的「追蹤一項變更」，意思較窄，也較持久——是修訂歷史紀錄冊裡一條有日期的項目，記錄改了甚麼、誰改的、何時、為何，以及取代了哪個版本。
無論由誰撰寫、改動了甚麼，每一條項目都需要同一組欄位：受影響的 SOP 與步驟、以淺白語言寫的變更描述與原因、生效日期、作者，以及——大部分紀錄冊都漏掉的一個欄位——這條項目確切取代的版本編號。一次安全關鍵步驟的變更，會掙得一條加急審閱路徑，不用排在例行隊伍後面；而在起草開始之前，紀錄冊本身會先被查核：這份 SOP 是否已經有一條待處理項目？同一份程序有兩條待處理項目，就會產生兩個候選版本號，這是紀錄冊必須先解決、才有人會信任它的問題。
一份在 QueryChart 建立、以圖表為本的 SOP，不需要為修訂歷史存在的目的所要捕捉的那些欄位，另外手動維護一本紀錄冊。圖表的每一次修改，已經逐個欄位自動記錄在它的版本歷史面板裡——打開它，比較版本畫面會準確顯示任何兩個已儲存版本之間改了甚麼、誰改的，一鍵還原就能取回較早的一個，而不會失去其後所做的工作。下面的手動項目，在 SOP 的內容活在圖表以外，或者某個標準把修訂歷史紀錄冊本身指名為一項獨立成果時，仍然重要；那個內建版本在無人手動維護的情況下，底下實際在做甚麼，見 /features/version-control。
一項擬議變更，一路追蹤到定案的項目
一份 SOP 的一項擬議變更，逐列追蹤，由它被識別的一刻，到點名它取代了哪個版本的定案紀錄項目。
在其他一切之前，先記錄甚麼
圖表由「已識別 SOP 需要變更」開始，然後是「描述擬議的變更及原因」——涉及哪份 SOP、哪個步驟、改甚麼、為何改，以及生效日期——之後「變更是否影響安全關鍵步驟？」才決定這條項目走哪一條審閱路徑。
加急分流與重複檢查
安全關鍵變更會「把項目標記為加急審閱」，其餘則「把項目送經標準審閱周期」；兩者其後都會遇上「修訂歷史紀錄冊是否已有這份 SOP 的待處理項目？」，然後才由「檔案」形狀的列寫下「起草修訂歷史項目：日期、變更摘要、作者、被取代的版本」。
一條項目要被信任，先要經過兩重查核
「審閱人對照現行 SOP 內容查核項目」在先；「審批前是否有待了結的意見？」會把未了結的項目循環送回 SOP 編寫人重新審閱，之後審批人才會對照「SOP 主檔及所取代的版本」查核它。
定案之後，才結清舊版本
「在修訂歷史紀錄冊中把已批准的項目記錄為定案」，會在 SOP 本身的版本號與生效日期更新之前，鎖定日期、審批人與版本編號，而「撤回或存檔被列為已取代的版本」則結清新版本所取代的那一項。
運作方式
每一條項目都記錄那五個欄位
寫下受影響的 SOP 與步驟、改了甚麼與為何、生效日期、作者，以及這條項目確切取代的版本編號。一條漏寫被取代版本的項目，會在紀錄冊裡留下一個事後沒有人能補回的缺口。
把安全關鍵變更送上快速通道
在送去審閱之前，先問這次變更有沒有觸及安全關鍵步驟。如果有，把它標記為加急審閱，不要讓它排在例行變更後面；如果沒有，就送經標準審閱周期。
起草之前先查核有沒有待處理項目
在開始一條新項目之前，先在紀錄冊裡搜尋同一份 SOP 是否已經有一條待處理項目。同一份程序有兩條待處理項目，會產生兩個候選版本號——要跟另一位作者協調，或者把變更排出先後次序，而不是各自平行起草。
獲批之後就鎖定項目
把已批准的項目記錄為定案，然後更新 SOP 的版本號與生效日期，並撤回它取代的版本。一條在獲批之後仍然可以被編輯的項目，不是紀錄，只是一份印上審批人名字的草稿。
對以圖表為本的 SOP，交由變更日誌負責記錄
如果 SOP 本身就是一張 QueryChart 流程圖，圖表上已經捕捉到的內容就不用另外手動記錄：每一次修改已經逐個欄位被追蹤。打開版本歷史，用比較版本查看兩個已儲存版本之間改了甚麼，一鍵還原較早的一個——見 /features/version-control。
應避免的錯誤
沒有被取代版本的項目
一條修訂歷史項目，只記了改了甚麼，卻沒有記它取代了哪一個版本，日後就無法重建成一條時間線。在起草開始之前，就把被取代版本定為必填欄位，而不是一則可有可無的附註。
同一份 SOP 有兩條待處理項目
兩位作者在同一個星期，為同一份 SOP 各自開一條修訂歷史項目，會產生兩個互相競爭的版本號。起草之前先查核有沒有待處理項目，並互相協調，而不是等兩者都獲批之後才去調解衝突。
用追蹤修訂標記代替紀錄冊
以電郵傳來傳去的追蹤修訂檔案，會把誰在何時改了甚麼的真實次序，散落在各個收件匣裡。一條有日期的紀錄冊項目，或者一張圖表自己的變更日誌，才是紀錄；留在某人收件匣裡的一份追蹤修訂附件不是。
把一條項目跟整個制度混為一談
把一條項目做對，並不會修好一套會漂移的編號方案，或者一個沒有人追蹤的檢討周期——那是 /yue/guides/如何管理sop修訂 那一層管治。本頁講的是一條項目；那一頁講的是所有項目共同的節奏。
建立你的 SOP 修訂歷史紀錄冊
把修訂歷史紀錄冊示例開成你自己的圖表，訂下你的項目要記錄的欄位，此後每一次修改都交由版本歷史自動追蹤。
相關指南
常見問題
「追蹤修訂」跟 SOP 的版本控制是同一回事嗎？
不完全是。「追蹤修訂」是文書編輯器的語言，指的是一個檔案內部的追蹤修訂標記與留言。SOP 的版本控制，是為程序每一個獲批狀態各配一個獨立識別版本，並保留它們之間改了甚麼的紀錄這種做法；修訂歷史項目，正是這份紀錄被寫下來的方式。更完整的分別見 /yue/guides/如何為sop做版本控制。
一條修訂歷史項目需要記錄甚麼？
無論由誰撰寫，都是同一組五樣東西：受影響的 SOP 與步驟、以淺白語言寫的變更描述與原因、生效日期、作者，以及這條項目確切取代的版本編號。漏寫被取代版本，是修訂歷史紀錄冊裡最常見的單一缺口。
所有 SOP 變更都走同一套審閱嗎？
不是。安全關鍵步驟的變更會走加急審閱路徑，不用排在例行變更後面，其餘一律走標準周期。兩條路徑在起草之前，都會匯合到同一個重複檢查：這份 SOP 是否已經有一條待處理項目？
這跟一般管理 SOP 修訂有甚麼分別？
本頁講的是一條項目的機制——它需要的欄位、審閱分流、重複檢查。編號方案、檢討周期，以及誰擁有所有 SOP 共同的時間表，那一層管治見 /yue/guides/如何管理sop修訂。
QueryChart 會取代手動紀錄冊嗎？
對一份以圖表為本的 SOP，凡是圖表本身捕捉到的內容，答案是會：每一次欄位級修改都自動記錄在版本歷史裡，並附有比較版本畫面與一鍵還原——見 /features/version-control。在 SOP 的內容活在圖表以外，或者某個標準把修訂歷史紀錄冊本身指名為一項獨立成果時（例如 /yue/templates/受控標準作業程序範本 那套更完整的生命周期），手動紀錄冊仍然值得保留。
