變更管理流程圖（ITIL）

甚麼是變更管理流程圖（itil）流程

本範本裡的變更管理，指的是資訊科技服務的變更管理：每一項對生產服務的變更都要走的那條固定流程，由提出變更請求開始，直到變更紀錄結案為止。它不是組織變革管理——那是與人相關的學科，通常與 ADKAR 或科特八步這類模型連在一起——儘管兩者在中文裡經常被混着叫作「變更管理」。這裡畫出來的，是由變更經理與變更諮詢委員會（CAB）持續運作的、ITIL 風格的營運流程。

大部分價值集中在靠前的一個決策上：這是哪一類變更？把所有變更都送進同一套完整評估、同一個每週例會，只會排出一條隊；而隊列正是把人推到流程以外去改動系統的原因。所以這張圖只分流一次，而且分得很早。標準變更依據一份成文的變更模型預先獲批，直接進入排期。常規變更接受風險與影響評估，然後送 CAB。緊急變更由緊急 CAB 加急授權，之後重新匯入完全相同的排期、實施與檢討路徑，因此一次緊急修復永遠不會變成一次沒有紀錄的修復。

圖可以定下來的另一件事是誰負責，這也是它被畫成泳道的原因：申請人、變更經理、CAB、實施團隊與服務負責人。服務負責人單獨佔一條泳道，因為驗證正是各團隊最常略過的一步。「已經部署了」與「服務是好的」是兩個不同的說法，而兩者之間的差距，就是回滾路徑存在的全部理由。在這張圖裡，驗證不通過會觸發回滾方案，而成功的變更與已回滾的變更同樣都要走到實施後檢討與結案。

本流程圖涵蓋的內容

本範本包含

• 橫跨申請人與變更經理兩條泳道的受理：提出變更請求、把 RFC 登記入變更登記冊，然後是「請求是否完整並在範圍內？」這道完整性過濾——內容單薄的請求會退回申請人補齊細節，再回到同一道檢查
• 「變更類型？」處的三向分流：標準變更直接進入變更日曆，常規變更進入風險與影響評估，緊急變更進入 ECAB 授權
• 評估與審批：評估風險與服務影響，把評估結果與回滾方案記錄成一份完整文件而不是一串工單留言，然後是 CAB 檢討以及批准或駁回的決策，被駁回的變更止於申請人泳道中的「變更已駁回並結案」終止節點
• 排期：已批准、緊急與標準三條路徑在變更日曆上匯合，並遇上一次與其他已排期變更的衝突檢查，撞期的變更會退回重新排期
• 實施團隊泳道中的建置與實施：建置並測試變更，然後在獲批的時段內實施
• 驗證與結案：服務負責人驗證服務並回答「變更是否成功？」，失敗則執行回滾方案，兩種結果都匯合到實施後檢討與變更紀錄的結案

何時使用本範本

• 為服務台、平台團隊或基礎設施團隊撰寫或更新一套 ITIL 風格的變更管理程序，而這些團隊目前靠的是習慣與聊天紀錄
• 在 ServiceNow、Jira Service Management 或 Freshservice 裡設定變更類型之前，先就甚麼算標準、甚麼算常規、甚麼算緊急達成共識，讓工具承載你們已經作出的決定，而不是替你們發明一個
• 帶新任變更經理、CAB 成員或候命工程師上手，他們需要知道哪些變更需要審批、由誰審批，以及非辦公時間怎樣處理
• 向審計員或客戶說明變更如何評估、授權、測試與回退，例如對照 SOC 2 的 CC8.1 準則或 ISO/IEC 27001:2022 附錄 A 的 8.32 控制項。圖記錄的是程序；證據是它產生的那些變更紀錄
• 在一個很差的季度之後降低變更失敗率，需要看清驗證與回滾究竟在哪一步、由誰負責

運作方式

1. 把泳道改成你們實際有的角色

   把申請人、變更經理、CAB、實施團隊與服務負責人換成你們真實的職能。不少機構由同一個人兼任變更經理與 CAB 主席，規模更小的團隊根本沒有獨立的實施團隊。與其畫一個你們並不存在的架構，不如把泳道合併，並把泳道控制在五條以內——再多，這張圖就無法一眼讀懂。

2. 在分流決策處定義你們的三種變更類型

   在「變更類型？」這個決策旁邊寫清楚甚麼算標準、甚麼算常規、甚麼算緊急，並按風險與影響範圍而不是按工作量或工單大小來劃界。把預先批准的標準變更清單保持得夠短，短到真的有人願意維護它，並為每一項標準變更配一份必須遵循的成文變更模型。

3. 指定變更授權方、它的會議節奏，以及它的緊急對應方

   在 CAB 檢討這一步記下審批人是誰、多久開一次會、上議程的截止時間。ECAB 要另行定義：有權批准非辦公時間修復的，很少是整個委員會。多數團隊最後採用的規則是：幾分鐘內口頭授權，當天補回紀錄，在下一次 CAB 上檢討。

4. 寫明評估紀錄必須包含甚麼

   把「記錄評估與回滾方案」變成一份真正的檢查表：受影響的服務與用戶、風險評級、依賴關係、停機時段、測試方法、回滾步驟，以及由誰執行回滾。CAB 的決策不會好過這份紀錄的質素，而它正是審計員幾個月之後會來索取的那份文件。

5. 把排期與衝突規則寫清楚

   寫清楚你們的凍結期、最短前置時間，以及變更日曆由誰負責。這張圖裡的衝突檢查刻意畫成一個決策而不是一道手續，因為大多數撞期是兩個團隊碰到了同一個共用依賴，而不是碰了同一個系統。事先決定：撞期意味着重新排期，還是意味着升級。

6. 定義甚麼叫成功，然後發佈並為程序做版本管理

   說清楚「變更是否成功？」在你們這裡代表甚麼：哪些冒煙測試、服務負責人觀察多久、甚麼情況下下達回滾指令。然後把圖放到工作真正發生的地方——變更申請表旁邊或者運作手冊裡——向圖中點名的人收集審批，並保留舊版本，好讓你們可以說明程序是甚麼時候改的、為甚麼改。

常見問題

這是資訊科技變更管理，還是組織變革管理？

是資訊科技變更管理。兩者共用一個名字，此外幾乎毫無關係。這張流程圖畫的是 ITIL 風格的生產服務變更營運流程：提出 RFC，分流、評估、授權、排期、實施、驗證、結案。組織變革管理是與人相關的學科，幫助員工接受一種新的工作方式，通常圍繞 ADKAR 或科特八步這類模型來組織，它沒有 CAB、沒有變更日曆，也沒有回滾方案。如果你們要找的是持份者分析與溝通規劃，那就找錯圖了。

標準變更、常規變更與緊急變更有甚麼分別？

標準變更風險低、執行頻密，並且依據一份成文的變更模型預先獲批，因此無須逐項審批，直接進入排期。常規變更是指必須就事論事地評估與審批的變更，走的是由風險與影響評估到 CAB 的那條路。緊急變更是指等到下一次 CAB 所造成的損害會大於變更本身風險的情形，因此由緊急 CAB 加急授權。在這張圖裡三者都匯入同一個變更日曆、同一套實施與檢討，因為類別改變的是審批路徑，而不是紀錄。

每一項變更都要上 CAB 嗎？

不需要，而且把所有變更都送上去，是令人繞開流程的最快辦法。CAB 存在的意義，是檢討那些風險尚未摸清的變更。當某一類變更執行的次數已經多到有了可靠的程序與已知的失效模式，就把它升為帶成文模型的標準變更，並從議程上拿走。一個把會議時間花在為日常工作蓋章上的 CAB，其實甚麼也沒有檢討；而它造出來的隊列，會把真正有風險的變更推向緊急通道。

變更失敗了應該怎麼辦？

它走的是與成功變更完全一樣的那條結案路徑。在這張圖裡，「變更是否成功？」處驗證不通過會觸發實施團隊泳道中的回滾方案，隨後這項已回滾的變更同樣進入實施後檢討與結案。令這一點在實務上站得住的有兩件事：回滾方案是在變更執行之前就寫好並獲批的，而不是在事故當中臨時想出來的；以及檢討既問變更是否奏效，也問當初的變更類型判斷對不對。第二次嘗試是一份新的 RFC，因此失敗的那一次保留着它自己的紀錄。