文件修訂紀錄範本
文件修訂紀錄範本，又稱變更日誌：追蹤一份受控文件的變更，由申請、待處理項目、實施與核實，直到一條已結案、帶日期的紀錄。
甚麼是文件修訂紀錄流程
文件修訂紀錄，有時亦稱變更日誌，是一份獨立的紀錄，解答的問題與文件本身的修訂歷史不同。它問的不是「現行版本寫甚麼」，而是「在一套品質系統管制的每一份文件裡，發生過甚麼、由誰做的、幾時做的」。它獨立於任何單一檔案而存在，因為文件登記冊、審核員或流程負責人需要一次過看到幾十份政策、程序、表格與工作指引的變更活動，而不是逐一打開每一份文件，再捲到它自己的歷史表格。在這張圖裡，真正走過整個流程的是紀錄項目本身，而不是文件：一項變更被申請、開立為待處理項目、實施、描述、核實，然後結案。
這個生命周期在寫入任何東西之前有一道關卡，在之後又有一次查核。一項變更只有在獲批准可以記錄之後，才會開立為待處理項目；而它亦只有在審閱人把項目對照實際實施的內容核對之後，才會結案。這道核實步驟之所以存在，是因為一份紀錄冊的可信程度，取決於它最弱的一條項目：一段沒有人對照真實文件查核過的前後描述，價值不會高過一項未經查核的聲稱，而日後抽查的審核員亦無從分辨哪一條已經查核過、哪一條沒有。
這不是完整的文件管制流程——起草、技術審閱與正式簽署，發布文件之前的整套程序——也不是只綁定某一種文件類型，例如標準作業程序。它是伴隨任何受控文件而存在的一本帳簿，無論該文件本身的起草與審批由甚麼機制管治，這本帳簿都會記錄之後對它作出的每一次變更：誰申請的、誰實施的、改了甚麼，以及那項變更有沒有經過核實。把它當成紀錄冊本身來用，而不是用來取代最初授權那項變更的審批。
本流程圖涵蓋的內容
本範本包含
- 五條泳道，涵蓋接觸修訂的角色：申請人、紀錄冊負責人、作者、審閱人與審核員，橫跨五個階段：申請、紀錄（待處理）、實施、核實與紀錄（已結案）。
- 受理與把關：針對一份受控文件申請一項變更，連同原因與目標文件一併提交，然後「變更是否獲批准記錄？」這道判斷，要麼開立一條待處理項目，要麼把申請結束在「申請被拒絕，不予記錄」。
- 待處理項目本身：「開立一條待處理紀錄項目」，為它編配一個連結到該文件的項目編號，並把這項變更指派給一位作者，令一項變更在真正寫入文件之前，已經先存在於紀錄冊裡。
- 實施與憑證：作者在文件中實施變更，然後「記錄前後描述、作者與日期」，捕捉改了甚麼、誰改的、幾時改的——令人可以在不打開文件自身歷史的情況下，重構那項變更。
- 核實：審閱人把項目對照已實施的變更查核，「是否已對照文件核實？」這道判斷，要麼結案，要麼導向「差異出在文件還是紀錄項目？」，把修正送回重新實施，或者送回更正項目，而不是預設一定是作者的錯。
- 結案與審核：「結案紀錄項目」、通知申請人，然後定期審核在審核員泳道裡抽查已結案的項目，而不是逐一覆核。
何時使用本範本
- 你們需要一本單一的紀錄冊，追蹤許多受控文件——政策、程序、表格、圖則、範本——的變更，而不是分別嵌在每份檔案裡各自的修訂歷史。
- 你們現時的變更日誌，只是登記冊試算表裡隨手加的一欄，你們想把它畫成一套自己的生命周期：記錄之前有一道關卡，結案之前有一次查核。
- 審核員或流程負責人不斷追問一項變更幾時做的、誰做的、有沒有查核過，而今天誠實的答案是：這些資料散落在一堆電郵對話裡。
- 你們正在為一種沒有正式起草與審批流程的文件類型——一張參考表、一份供應商名單、一項政策——設定變更追蹤，需要的是一本輕量的紀錄冊，而不是一整套文件管制流程。
運作方式
把泳道改成你們自己的角色
把申請人、紀錄冊負責人、作者、審閱人與審核員，換成你們實際擁有的角色。在小型團隊裡，紀錄冊負責人與審閱人往往是同一個人；把它們合併成一條泳道，而不是畫一道永遠不會發生的審閱。如果不止一個人可以撰寫一項變更，就把作者保留為一個角色而不是具名個人，令這張圖經得起人員流轉。
決定甚麼算是需要記錄的變更
不是每一次編輯都需要一條項目：改正一個錯別字，跟改動一個管制限值是兩回事。在「變更是否獲批准記錄？」這道判斷上定下門檻，例如對範圍、職責、數字或要求的實質改動要記錄，排版或拼寫修正則不用，並把這個門檻寫低，因為「實質」正是這道判斷每一次爭議都會回到的字眼。
定下你們的項目編號方案
在「編配項目編號並連結文件」這一步，決定項目編號是按每份文件各自計算——例如「這份政策的第 4 號變更」——還是整本紀錄冊用同一個序列。按文件編號在單一文件自己的歷史裡讀起來更順；單一序列則在整本登記冊裡更易搜尋與報告。
寫明前後描述的標準
「記錄前後描述、作者與日期」只有在每條項目都達到同一個標準時才有用。要求依次列明：原本的字句或數值、新的字句或數值、誰做的變更，以及日期，令審核員抽查時，無論由誰撰寫，讀到的都是同一種格式的紀錄。
定下核實實際查核甚麼
在「把紀錄項目對照已實施的變更查核」這一步，給審閱人一個具體的測試：打開文件、找到那項變更，並確認項目的前後描述文字，與文件裡實際的內容一致。一項只是校對紀錄項目本身文字的查核，不算是對照文件的核實。
定下你們的審核抽查規則
「在定期審核中抽查已結案項目」需要訂明頻率與樣本量，例如每季十條項目，或者所有高於某個風險等級的項目，並把它寫進你們的審核計劃裡，而不是每次有人要求證據時才臨時決定。
常見問題
甚麼是文件修訂紀錄？
它是一份按時間順序記錄一份受控文件每一次變更的紀錄，與文件本身分開：誰申請了這項變更、誰實施的、改了甚麼的前後描述、日期，以及有沒有對照實際文件核實過。有些機構把同一份紀錄稱為變更日誌；兩個名稱描述的都是一段持續更新的變更歷史，而不是文件目前的內容。
文件修訂紀錄與變更日誌是同一件事嗎？
是的，在兩者都描述一段持續的變更紀錄、而不是目前內容這一點上是相同的。「修訂紀錄」在與某一份特定受控文件相關的品質與法規場合較常見；「變更日誌」用得更廣泛，由單一政策到一張共用的參考表都可以用。本範本畫的正是兩個名稱背後共通的一般生命周期：申請、待處理項目、實施、核實、已結案項目。
這與文件本身的版本歷史有甚麼分別？
文件的版本歷史通常存在於檔案本身或其中繼資料裡，顯示已發放的一連串編號版本。修訂紀錄則是一本可以同時橫跨許多份文件的獨立登記冊，記錄的是變更活動本身——誰改了甚麼、幾時改的——而不只是最終的版本號。許多機構兩者都保留：文件本身帶着版本號與生效日期，紀錄冊則帶着產生這些版本的每一次變更的敘述。
應該由誰核實一項已記錄的變更？
應該是實施那項變更以外的人。「是否已對照文件核實？」這道判斷的重點，是一次獨立查核，確認項目裡的前後描述，確實與文件中實際改動的內容相符，而不是由同一個人對自己寫的兩份東西給出第二個意見。在非常小的團隊裡，這可以由紀錄冊負責人而不是專任審閱人擔任，但不應該是作者查核自己那條項目。
