變更管理流程圖（ITIL）
ITIL 變更管理流程圖：RFC 受理，標準、常規與緊急變更的分流，CAB 審批，變更日曆排期，實施、驗證、回滾與實施後檢討。
運作方式
把泳道改成你們實際有的角色
把申請人、變更經理、CAB、實施團隊與服務負責人換成你們真實的職能。不少機構由同一個人兼任變更經理與 CAB 主席，規模更小的團隊根本沒有獨立的實施團隊。與其畫一個你們並不存在的架構，不如把泳道合併，並把泳道控制在五條以內——再多，這張圖就無法一眼讀懂。
在分流決策處定義你們的三種變更類型
在「變更類型？」這個決策旁邊寫清楚甚麼算標準、甚麼算常規、甚麼算緊急，並按風險與影響範圍而不是按工作量或工單大小來劃界。把預先批准的標準變更清單保持得夠短，短到真的有人願意維護它，並為每一項標準變更配一份必須遵循的成文變更模型。
指定變更授權方、它的會議節奏，以及它的緊急對應方
在 CAB 檢討這一步記下審批人是誰、多久開一次會、上議程的截止時間。ECAB 要另行定義：有權批准非辦公時間修復的，很少是整個委員會。多數團隊最後採用的規則是：幾分鐘內口頭授權，當天補回紀錄，在下一次 CAB 上檢討。
寫明評估紀錄必須包含甚麼
把「記錄評估與回滾方案」變成一份真正的檢查表：受影響的服務與用戶、風險評級、依賴關係、停機時段、測試方法、回滾步驟，以及由誰執行回滾。CAB 的決策不會好過這份紀錄的質素，而它正是審計員幾個月之後會來索取的那份文件。
把排期與衝突規則寫清楚
寫清楚你們的凍結期、最短前置時間，以及變更日曆由誰負責。這張圖裡的衝突檢查刻意畫成一個決策而不是一道手續，因為大多數撞期是兩個團隊碰到了同一個共用依賴，而不是碰了同一個系統。事先決定：撞期意味着重新排期，還是意味着升級。
定義甚麼叫成功，然後發佈並為程序做版本管理
說清楚「變更是否成功？」在你們這裡代表甚麼：哪些冒煙測試、服務負責人觀察多久、甚麼情況下下達回滾指令。然後把圖放到工作真正發生的地方——變更申請表旁邊或者運作手冊裡——向圖中點名的人收集審批，並保留舊版本，好讓你們可以說明程序是甚麼時候改的、為甚麼改。
常見問題
這是資訊科技變更管理，還是組織變革管理？
是資訊科技變更管理。兩者共用一個名字，此外幾乎毫無關係。這張流程圖畫的是 ITIL 風格的生產服務變更營運流程：提出 RFC，分流、評估、授權、排期、實施、驗證、結案。組織變革管理是與人相關的學科，幫助員工接受一種新的工作方式，通常圍繞 ADKAR 或科特八步這類模型來組織，它沒有 CAB、沒有變更日曆，也沒有回滾方案。如果你們要找的是持份者分析與溝通規劃，那就找錯圖了。
標準變更、常規變更與緊急變更有甚麼分別？
標準變更風險低、執行頻密，並且依據一份成文的變更模型預先獲批，因此無須逐項審批，直接進入排期。常規變更是指必須就事論事地評估與審批的變更，走的是由風險與影響評估到 CAB 的那條路。緊急變更是指等到下一次 CAB 所造成的損害會大於變更本身風險的情形，因此由緊急 CAB 加急授權。在這張圖裡三者都匯入同一個變更日曆、同一套實施與檢討，因為類別改變的是審批路徑，而不是紀錄。
每一項變更都要上 CAB 嗎？
不需要，而且把所有變更都送上去，是令人繞開流程的最快辦法。CAB 存在的意義，是檢討那些風險尚未摸清的變更。當某一類變更執行的次數已經多到有了可靠的程序與已知的失效模式，就把它升為帶成文模型的標準變更，並從議程上拿走。一個把會議時間花在為日常工作蓋章上的 CAB，其實甚麼也沒有檢討；而它造出來的隊列，會把真正有風險的變更推向緊急通道。
變更失敗了應該怎麼辦？
它走的是與成功變更完全一樣的那條結案路徑。在這張圖裡，「變更是否成功？」處驗證不通過會觸發實施團隊泳道中的回滾方案，隨後這項已回滾的變更同樣進入實施後檢討與結案。令這一點在實務上站得住的有兩件事：回滾方案是在變更執行之前就寫好並獲批的，而不是在事故當中臨時想出來的；以及檢討既問變更是否奏效，也問當初的變更類型判斷對不對。第二次嘗試是一份新的 RFC，因此失敗的那一次保留着它自己的紀錄。