變更控制流程圖（change control）
變更控制流程範本：提出申請、影響與風險評估、CAB 審批、帶回滾方案的實施、驗證與結案，另附一條成文的緊急通道。
甚麼是變更控制流程圖（change control）流程
變更控制就是介乎「有人想改點甚麼」和「變更已經上線」之間的那一連串關口。每一道關口都留下一條紀錄：申請了甚麼、影響評估發現了甚麼、由誰批准、幾時執行、驗證是否通過、檢討得出甚麼結論。在 IT 與工程團隊裡，它通常以 ITIL 式的變更管理運行，配一個 CAB；在受規管的品質管理體系裡，它是那套防止已驗證流程出現偏移的受控變更程序。兩處的流程形態是一樣的。
變更控制的失敗大多是交接的失敗，而不是流程本身的失敗。申請人不知道評估需要哪些資料，CAB 看的是一串工單留言而不是一份評估紀錄，實施人做出一個沒有回滾的方案，事後又無人把紀錄結案。這也是這個範本被畫成泳道的原因：申請人、變更負責人、CAB、實施人與 QA 各自擁有特定的步驟，而圖令工作在哪裡易手變得一目了然。
團隊最常不寫下來的兩條分支，剛好也是事後爭議最多的兩條：緊急通道，以及被駁回的變更該怎麼辦。這張圖把兩者都畫了出來。緊急變更由 CAB 主席作出加急授權，並匯入完全相同的實施與檢討路徑，因此它們永遠不會成為沒有紀錄的變更。被駁回的變更帶著 CAB 的意見回到申請人，並進入一個決策點：要麼回到重新評估，要麼把申請結案為押後。
本流程圖涵蓋的內容
本範本包含
- 申請人與變更負責人兩條泳道上的受理與分流：提出變更申請、登記入變更登記冊，然後是一個三向的變更類型決策，把標準變更直接送往實施規劃，把常規變更送入影響評估與 CAB 審議，把緊急變更送到 CAB 主席
- 評估：評估影響與風險，與申請人確認範圍和停機時段，並把結果匯總成一份評估紀錄，令 CAB 審的是一份文件，而不是一串留言
- CAB 泳道中的決策點：CAB 審議變更申請，隨後批准它進入實施規劃，或者把它駁回給變更負責人
- 駁回與押後分支：CAB 的意見返回申請人，申請人要麼修改後重新提交——回到影響評估——要麼把申請結案為押後
- 緊急通道：緊急變更透過 CAB 主席的加急授權跳過常規的 CAB 議程，隨後匯入完全相同的規劃、實施與檢討路徑
- 實施人與 QA 泳道中的實施與驗證：規劃實施方案與回滾方案、安排變更時段、執行變更，然後由 QA 測試並驗證。驗證不通過會觸發回滾方案並回到規劃；驗證通過則進入實施後檢討並結束變更紀錄
何時使用本範本
- 你們要為 IT 營運或平台團隊記錄一套 ITIL 式的變更管理程序，包括誰在 CAB 之中、以及他們在作決定之前看到的是甚麼
- 你們要為品質管理體系編寫受控變更 SOP，當中對已驗證流程或產品的變更需要一份成文的影響評估和一位具名批准人
- 你們要帶新的變更負責人、CAB 成員或當值工程師上手，他們需要知道哪些變更需要審批、哪些不需要
- 你們想在 Jira、ServiceNow 或某個 QMS 中把它設定成工作流程之前，先把誰批准甚麼定下來，令工具承載一個已達成共識的流程，而不是自行發明一個
- 客戶或審核員問變更是如何獲批准、測試與回滾的，你們需要一份可以指過去的成文流程
運作方式
把泳道改成你們真實的角色
把申請人、變更負責人、CAB、實施人與 QA，換成你們實際擁有的角色與團隊。如果同一個人既是變更負責人又是 CAB 主席，就把這兩條泳道合併，而不是扮作它們是分開的。把泳道數目控制在五條或以下，圖才保持可讀。
在分流決策處定義你們的變更類別
變更類型決策已經分出標準、常規與緊急三類。寫下在你們機構裡各自的資格條件，並把這些界線放在決策旁邊。按風險與影響範圍劃分，而不是按工單大小；並且令預先批准的標準變更清單短到真的有人願意維護。
指定變更授權方及其會議節奏
在 CAB 審議這一步記下：批准人是誰、他們多久開一次會、進入議程的截止時間是幾時。另行說明緊急授權方，因為有權批准非辦公時間搶修的，通常不是整個委員會。
寫明評估紀錄必須包含甚麼
把評估這一步變成一張真正的檢查表：受影響的服務與用戶、停機時段、風險評級、依賴關係、測試方案與回滾方案。CAB 的決定不可能好過這份紀錄，而它同時也是這次變更留下的審計軌跡。
訂定回滾與驗證的規則
決定由誰執行回滾、需要多長時間、甚麼條件觸發這個決定。然後定義驗證在你們這裡代表甚麼：冒煙測試、迴歸測試套件，還是服務負責人的簽署確認。如果你們的政策是立即回滾而不是重新規劃，就相應調整驗證失敗的迴路。
把它發布出去，並保持版本管理
把圖分享到工作真正發生的地方——變更申請表單旁邊，或者操作手冊裡。每當有一次變更出了問題，就把它重看一遍；並保留歷史版本，以便說明程序是幾時改的、為甚麼改。
常見問題
變更控制與變更管理有甚麼分別？
變更控制是狹義的、程序性的那一部分：一項具體的擬議變更如何被提出、評估、授權、實施、驗證與結案，並在每一步留下紀錄。變更管理的範圍更闊，包含策略、類別、角色、溝通，以及流程本身的持續改善。這張流程圖畫的是變更控制程序，而它通常是最先被記錄下來的東西，因為它才是大家日常真正遵循的。
誰應當批准一項變更，是不是所有變更都要過完整的 CAB？
不是。把每一項變更都送過整個委員會會製造排隊，而排隊會促使大家繞開流程。多數團隊採用三檔：有成文操作方式、無須審議的預先批准標準變更；送交 CAB 的常規變更；以及由單一具名授權方（通常是 CAB 主席或當值主管）批准的緊急變更。按風險與影響範圍劃界，而不是按工單大小，並把它們寫在分流決策旁邊。
緊急變更怎樣才可以既走得通、又不架空流程？
緊急變更壓縮的是審批，而不是取消審批。在這張圖裡，緊急分支跳過了常規的 CAB 議程，但仍然要取得明確的授權，仍然要走帶回滾方案的實施規劃，也仍然會落到實施後檢討與結案。多數團隊最終採用的實用規則是：在幾分鐘內口頭批准，但當日就把變更紀錄寫好，並在下一次 CAB 會議覆核每一項緊急變更，確認這個類別用得是否站得住腳。
被 CAB 駁回或押後的變更會怎樣？
它們需要一個明確的結局，否則會以無紀錄的工作重新冒出來。在這個範本裡，變更負責人把 CAB 的理由帶回給申請人，申請人隨後面對一個決策：修改並重新提交，從而回到影響評估和第二次審議；或者接受這個結果，把申請結案為押後。記下理由和記下決定同樣重要，因為押後的變更通常會在阻塞的依賴關係解除之後再度回來。
這是否與文件或 SOP 的變更控制不同？
是。這是變更控制的通用版本，帶有 IT 營運色彩：設有 CAB、回滾方案，以及一個實施與驗證步驟，專為系統與服務的變更而設。/yue/templates/文件變更控制流程 與 /yue/templates/標準作業程序變更控制流程 是同一形態但範圍更窄的變體，專為特定文件類型而設，當中 CAB 由文件審閱人與審批人取代，回滾方案則由撤回已作廢版本取代。如果你們真正想要的，是版本控制與變更控制之間的概念分野，而不是一張圖，請參閱 /guides/version-control-vs-change-control。