文件變更控制流程圖
文件變更控制流程圖，涵蓋小改／大改分類、審閱人的影響評估、審批、加蓋版本印記、更新分發清單，以及正式把上一版本標示為作廢。
甚麼是文件變更控制流程
文件變更控制，範圍比文件管制窄，性質亦與 IT 變更管理不同，值得把三者分清楚。一份管治性文件由頭到尾的完整生命周期——申請、起草、審批、簽發與定期檢討——是 /yue/templates/文件管制流程 那張文件管制流程圖。一項擬議變更對某個系統或服務要經過的關卡——影響評估、CAB 審批、回滾方案與部署時段——是 /yue/templates/變更控制流程 那張變更控制流程圖。這張圖兩者都不是。它是那個特定的子程序：當一份已經生效的文件需要變更那一刻啟動——修訂如何被分類、審閱、審批、編定版本並推送出去，以及它所取代的副本如何被正式撤回。這裡沒有 CAB，沒有回滾時段，也沒有部署用語，因為文件修訂不是系統變更。
多數成文程序在最前面就略過的那道判斷是：「變更分類為小改還是大改？」一個字句修正、排版更正或錯別字，不需要與改動文件實際要求的變更受到同樣程度的審視，把每一項變更一視同仁，結果要麼令瑣碎的編輯拖着走完整的審閱周期，要麼讓一項實質變更，混在為錯別字而設的快速通道裡溜過去。這張圖把這個分岔明確畫出來：小改迅速備妥並審批，大改則先交變更審閱人做一次有記錄的影響評估，然後才到達同一個審批關卡。
最能把這套流程與一般修訂流程分開的兩個步驟，都發生在審批之後。「更新版本號與分發清單」把版本印記和現時持有現行副本的名單，當成一個動作而不是兩個，因為一份版本改了、分發清單卻沒有跟着改的文件，正正就是有人手上拿着落後一版的副本的原因。而「撤回並把上一版本標示為作廢」，令舊副本有一個明確、有記錄的退場，而不是任由它自行淡出使用，分發清單上的持有人亦要確認收到撤回通知，令「誰被告知了」有紀錄可循。
若修訂源於工程變更，先取得已批准的 ECN／ECO，列明受影響圖紙、BOM 與作業指引的舊／新版本及生效點，再走本圖的審閱、審批、編版與分發。ECR-014 的示例把 D-014、BOM-100 與 WI-014 同步至 P-014 rev B、L-015；發布及舊副本撤回記錄交回變更負責人。文字小改的快速通道不能取代工程對產品定義與存貨處置的授權。
工程決策與文件發布的交接
本流程圖涵蓋的內容
本範本包含
- 五條泳道，申請人、文件負責人、變更審閱人、文件管理員與分發清單持有人，橫跨五個階段：申請、評估、審批、版本與分發，以及取代。
- 受理：「識別到受控文件需要變更」帶入「提交文件變更申請」，捕捉文件編號、現行版本與變更原因，然後「把申請記錄在文件檔案上」。
- 分類分岔：「變更分類為小改還是大改？」把小改直接送去「備妥快速通道編輯」，大改則先送到「變更審閱人評估完整影響」與「記錄對相關文件及表格的影響」。
- 兩條路徑都匯合到「是否批准？」這道判斷，其「駁回」分支返回「修訂草稿並重新提交審閱」，回到審閱人階段，而不是就此結束申請。
- 版本與分發階段，由文件管理員擁有：「更新版本號與分發清單」、「把新版本發布到受控位置」，然後「通知分發清單持有人有新版本」。
- 正式取代：「撤回並把上一版本標示為作廢」與「分發清單持有人確認收到撤回通知」，結束於「文件已在正式變更控制下重新發放」。
何時使用本範本
- 你們正在寫一份具體的子程序，說明單一受控文件如何變更，並希望它與更廣的文件管制生命周期分開，以免在審核時把兩者混為一談。
- 已作廢的副本不斷與現行版本一同出現，你們需要一個明確的編版與撤回步驟，而不是寄望大家自己發現舊版本已經不見了。
- 現時所有變更都經過同一套重量級審閱，瑣碎的字句或排版修正，堵在真正改動要求的變更後面。
- 你們的分發清單是一張沒有人記得更新的試算表，你們想把版本印記與清單更新變成同一個步驟，而不是兩個會漸行漸遠的步驟。
- 審核員或認證機構問你們怎樣知道每一位受控文件的持有人都被告知一次修訂，你們需要把這次通知與確認畫成一個步驟，而不是假定它有發生。
運作方式
把泳道改成你們真實的角色
把申請人、文件負責人、變更審閱人、文件管理員與分發清單持有人，換成你們實際擁有的角色。在小型團隊裡，除了大改之外，文件負責人與變更審閱人往往是同一個人；把這兩條泳道合併，而不是畫一道從不獨立發生的審閱。
寫明甚麼算小改、甚麼算大改
分類判斷的好壞，取決於它背後的規則。列出例子：錯別字與排版修正、更新聯絡資料、修補失效連結屬於小改；任何改動要求、職責、審批限額或所引用管制措施的，都屬於大改。把規則放在判斷旁邊，讓申請人在送到文件負責人手上之前，已經可以自行分類。
定下你們的版本編號方案
在「更新版本號與分發清單」這一步，決定慣例：例如已審批的大改用整數，快速通道的小改用小數。訂明每一頁必須出現的內容：文件編號、版本、生效日期，以及批准人，令單憑編號就能告訴讀者他們看的是不是現行版本。
定義分發清單，以及由誰維護
指名這套流程更新的是哪張清單：誰在名單上，按角色而不是按人名；有人加入使用這份文件的團隊時如何加進去；有人離開時又如何移除。決定通知是單向廣播，還是需要這張圖在「分發清單持有人確認收到撤回通知」所畫的那種確認。
列出已作廢副本可能存活的每一個地方
「撤回並把上一版本標示為作廢」只有在背後有一張清單時才做得到：共用磁碟、使用現場的印本、內聯網頁面、入職資料包、供應商或客戶手上的副本。在保存期內保留一份標示為作廢的存檔副本，而不是直接刪除。
定下甚麼會觸發完整的影響評估
在「記錄對相關文件及表格的影響」這一步，列出變更審閱人必須查核的類別：所引用的程序、連結的表格、培訓材料，以及任何引用了正在改動那部分的其他受控文件。每一項受影響的，都需要自己的一次變更申請，而不是悄悄在這一項裡順手改掉。
常見問題
甚麼是文件變更控制？
它是專門在一份已經審批並在使用中的文件需要變更時運作的程序：如何申請變更、如何分類為小改或大改、按分類對應的深度審閱、審批、加蓋新版本、推送給持有副本的人，以及它所取代的版本如何被正式撤回。它是更廣的文件管制生命周期底下的一個子程序，而不是取代它——文件管制亦涵蓋一份文件在任何變更發生之前，第一次起草與審批的過程。
文件變更控制與 IT 變更管理有甚麼分別？
兩者形狀相似——申請、評估、審批、實施——但對象不同。IT 或 ITIL 式的變更管理管治系統與服務的變更：它需要一個變更諮詢委員會、一次風險與停機評估、一個排定的變更時段和一套回滾方案，因為改動的對象，是可能在變更期間出事的運行中基礎設施。文件變更控制管治的是一份成文文件的變更：一項政策、程序、工作指引或表格。這裡沒有停機時段，也沒有回滾方案，因為文件修訂不像部署那樣「上線」；它取代的是一份已作廢的副本。兩者分開記錄的原因，與一間工廠把設備變更日誌和程序變更日誌分開存放是同一個道理：風險不同、審閱人不同、憑證亦不同。
如何決定一項文件變更屬於小改還是大改？
看這項變更對文件要求做了甚麼，而不是看改動痕跡看起來有多大。錯別字修正、排版更正、更新職銜或修補失效連結，無論改動了多少行，都屬於小改。任何改變文件要求某人做的事、某個步驟的責任誰屬、審批門檻、所引用的標準或安全指示的，即使只改了一個字，都屬於大改。把規則寫在判斷旁邊，而不是留待當天憑感覺判斷，令同類變更無論由誰提出，都得到同一個分類。
為何要把分發清單和版本號同一時間更新？
因為版本號改了、分發清單卻沒有跟着改，正正就是一份受控副本在某人手上變舊的方式。分發清單，是誰有資格持有現行副本的紀錄；如果它比版本印記分開更新，或者更新得較遲，就會出現一個空窗期：新版本已經存在，但需要它的人還沒有被加進去，又或者已經離開相關崗位的人仍在收到它。把兩者當成一個步驟，正是為了不讓文件上的版本，與持有清單漸行漸遠。
此流程所處的位置
在大多數機構中，此流程緊接文件審批工作流程決策樹之後，並交接給政策檢討審批流程圖（由觸發到閱讀確認）。
它是文件管制中的其中一個步驟。
第 1 步: 文件管制流程圖
第 2 步: 文件版本控制範本
第 3 步: 文件審批工作流程決策樹
文件審批工作流程的決策樹：編輯性修改還是實質性修改、按文件類別而定的必審審閱人、第二審批人，以及發布時的已閱並理解要求。
第 4 步: 文件變更控制流程圖 當前位置
文件變更控制流程圖，涵蓋小改／大改分類、審閱人的影響評估、審批、加蓋版本印記、更新分發清單，以及正式把上一版本標示為作廢。
第 5 步: 政策檢討審批流程圖（由觸發到閱讀確認）
政策檢討審批流程圖：按到期日或事件觸發、確認負責人、差距分析、諮詢、法律與員工代表審核、分級審批、發布與閱讀確認。