變更控制流程圖（change control）
變更控制流程範本：提出申請、影響與風險評估、CAB 審批、帶回滾方案的實施、驗證與結案，另附一條成文的緊急通道。
運作方式
把泳道改成你們真實的角色
把申請人、變更負責人、CAB、實施人與 QA，換成你們實際擁有的角色與團隊。如果同一個人既是變更負責人又是 CAB 主席，就把這兩條泳道合併，而不是扮作它們是分開的。把泳道數目控制在五條或以下，圖才保持可讀。
在分流決策處定義你們的變更類別
變更類型決策已經分出標準、常規與緊急三類。寫下在你們機構裡各自的資格條件，並把這些界線放在決策旁邊。按風險與影響範圍劃分，而不是按工單大小；並且令預先批准的標準變更清單短到真的有人願意維護。
指定變更授權方及其會議節奏
在 CAB 審議這一步記下：批准人是誰、他們多久開一次會、進入議程的截止時間是幾時。另行說明緊急授權方，因為有權批准非辦公時間搶修的，通常不是整個委員會。
寫明評估紀錄必須包含甚麼
把評估這一步變成一張真正的檢查表：受影響的服務與用戶、停機時段、風險評級、依賴關係、測試方案與回滾方案。CAB 的決定不可能好過這份紀錄，而它同時也是這次變更留下的審計軌跡。
訂定回滾與驗證的規則
決定由誰執行回滾、需要多長時間、甚麼條件觸發這個決定。然後定義驗證在你們這裡代表甚麼：冒煙測試、迴歸測試套件，還是服務負責人的簽署確認。如果你們的政策是立即回滾而不是重新規劃，就相應調整驗證失敗的迴路。
把它發布出去，並保持版本管理
把圖分享到工作真正發生的地方——變更申請表單旁邊，或者操作手冊裡。每當有一次變更出了問題，就把它重看一遍；並保留歷史版本，以便說明程序是幾時改的、為甚麼改。
常見問題
變更控制與變更管理有甚麼分別？
變更控制是狹義的、程序性的那一部分：一項具體的擬議變更如何被提出、評估、授權、實施、驗證與結案，並在每一步留下紀錄。變更管理的範圍更闊，包含策略、類別、角色、溝通，以及流程本身的持續改善。這張流程圖畫的是變更控制程序，而它通常是最先被記錄下來的東西，因為它才是大家日常真正遵循的。
誰應當批准一項變更，是不是所有變更都要過完整的 CAB？
不是。把每一項變更都送過整個委員會會製造排隊，而排隊會促使大家繞開流程。多數團隊採用三檔：有成文操作方式、無須審議的預先批准標準變更；送交 CAB 的常規變更；以及由單一具名授權方（通常是 CAB 主席或當值主管）批准的緊急變更。按風險與影響範圍劃界，而不是按工單大小，並把它們寫在分流決策旁邊。
緊急變更怎樣才可以既走得通、又不架空流程？
緊急變更壓縮的是審批，而不是取消審批。在這張圖裡，緊急分支跳過了常規的 CAB 議程，但仍然要取得明確的授權，仍然要走帶回滾方案的實施規劃，也仍然會落到實施後檢討與結案。多數團隊最終採用的實用規則是：在幾分鐘內口頭批准，但當日就把變更紀錄寫好，並在下一次 CAB 會議覆核每一項緊急變更，確認這個類別用得是否站得住腳。
被 CAB 駁回或押後的變更會怎樣？
它們需要一個明確的結局，否則會以無紀錄的工作重新冒出來。在這個範本裡，變更負責人把 CAB 的理由帶回給申請人，申請人隨後面對一個決策：修改並重新提交，從而回到影響評估和第二次審議；或者接受這個結果，把申請結案為押後。記下理由和記下決定同樣重要，因為押後的變更通常會在阻塞的依賴關係解除之後再度回來。