如何建立變更控制流程
如何設計變更控制流程：定義變更類別，把預先批准的清單保持精簡，要求每項變更都有回滾方案，並如實畫出緊急通道，而不是當它不存在。
變更控制流程規定一項擬議變更如何評估、授權、實施、驗證與結案——由變更類別決定每項變更要接受多嚴格的審查。
簡而言之
- 三個類別：標準、常規、緊急——按風險與影響範圍劃分，而不是按規模。
- 預先批准的標準變更清單要短到有人願意維護。
- 評估紀錄要包含甚麼，屬於流程的規定，而不是提交人的判斷。
- 每項變更都要有回滾方案，而回滾之後回到規劃階段，不是就此結束。
- 把緊急通道畫出來；否則就會有一條沒有紀錄的緊急通道。
按變更對象選擇流程
類別決定了這個流程會不會有人用
變更控制的成敗，取決於它的類別劃分。把每一項變更都送進每週一次的變更委員會，同事就會想辦法不提出變更，於是控制問題變成了看不見的問題。預先批准的範圍放得太寬，委員會審的又全是無關痛癢的東西。類別定義——標準、常規、緊急——才是真正的設計工作，而它們通常寫得最遲，也最含糊。
第二件值得做好的事，是評估紀錄。變更諮詢委員會的水平，不可能高於呈到它面前的材料；而把步驟名稱寫成「評估影響與風險」，幾乎必然換來參差不齊的提交內容。明確訂明這份紀錄必須包含甚麼——受影響的服務、停機時段、風險評級、依賴關係、測試方案與回滾方案——才能令委員會的決定由一種印象變成一次真正的審核。
下面的示例是一個橫跨五條泳道的變更控制流程。它包含任何可用流程都需要的三條通道：完全繞過委員會的標準變更、經過評估與 CAB 的常規變更，以及有自己授權人的緊急通道——再加一條回到規劃階段而不是就此結束的回滾路徑。
這個示例以 IT 服務變更為主。若要改的是已發布的實物零件、圖紙或 BOM，請看 /yue/templates/工程變更申請流程 的 ECR-014：除了評估與授權，還須記錄零件版本、生效批次、舊存貨的已批准處置與首件驗證。獲批後的文件修訂接到 /yue/templates/文件變更控制流程，再把發布證據交回變更負責人結案。
一個流程，三條通道
由提出到結案的變更控制流程。留意分流決策如何把三個類別送上三條不同的路徑。
分流決定了下游的一切
提出變更、登記入變更登記冊，然後是一個三向的類型判斷。標準變更直接進入實施，常規變更進入評估，緊急變更走自己的授權通道——一個決策就決定了整項變更的成本。
評估就是委員會的輸入
評估影響與風險、確認範圍與停機時段、記錄評估結果，然後是 CAB 審核與批准。如果沒有訂明這份紀錄必須包含甚麼，委員會就會把會議時間花在追問資料上，而不是作決定。
被駁回是一條通道，不是終點
CAB 的意見回到提出人，提出人可以修改後重新提交，也可以接受押後——緊急通道帶著自己的授權在這裡匯入。沒有修改迴路的流程，只會令變更被放棄，而不是被改好。
在變更之前先規劃回滾
實施方案與回滾方案一起規劃，安排時段，然後實施變更。回滾方案與變更同時規劃，才會是真的；事後補寫的回滾方案，只是一段沒有人試過的文字。
驗證，失敗就回到迴路
測試與驗證，失敗則執行回滾並退回規劃階段，之後是實施後檢討與結案。以實施為終點的變更控制流程，根本無從知道自己的變更是否奏效。
運作方式
定義你們的三個類別
寫下在貴機構裡甚麼算標準變更、甚麼算常規變更、甚麼算緊急變更，依據是風險與影響範圍，而不是工作量。對支付系統改一行設定不是標準變更；一次規模很大但已反覆演練的例行部署，反而可能是。
預先批准的清單要短，而且要有人負責
標準變更只有在清單獲持續維護時才成立。為它指定負責人與覆核日期，並要求一項常規變更反覆證明自己之後才可加入清單。無人維護的標準清單，最終會變成所有變更都走的那條路。
訂明評估紀錄的內容
把評估這一步變成一張檢查表：受影響的服務與用戶、停機時段、風險評級、依賴關係、測試方案、回滾方案，以及已諮詢過誰。這是對變更諮詢委員會用處提升最大的一項改動。
指定變更授權方及其會議節奏
誰批准、多久開一次會、議程的截止時間。然後另行指定緊急授權人——有權批准非辦公時間搶修的，很少是整個委員會，而把這一點留白，正是緊急變更最終無人批准的原因。
要求回滾方案，並訂明由誰下令
每項變更都要有一份，與實施方案一起規劃。事先決定誰有權觸發回滾、需要多長時間，以及達到甚麼門檻就下令——事故進行中，沒有人想還在解讀一份政策。
如實畫出緊急通道
每間機構都有緊急通道。給它準則、指定授權人，並要求事後在固定期限內補上檢討紀錄。畫出來並附帶文件義務的緊急通道是一項控制項；沒畫出來的那一條，只是凌晨兩點實際發生的事。
應避免的錯誤
所有變更走同一條路
把瑣碎變更也送進每週的委員會，只會教會大家繞開流程，於是真正重要的變更反而看不見。
評估要求含糊
委員會變成追問資料的場合，而不是作決定的場合，而批准的質素取決於誰的提交材料寫得最好。
回滾方案在規劃之後才補
事後想出來的回滾方案未經測試，而且往往根本行不通。兩者一起規劃，否則等於沒有。
當作沒有緊急變更
拒絕把緊急通道寫下來，並不會令它消失——消失的只是準則、授權人與紀錄。
建立你們自己的變更控制流程
把變更控制示例打開成你們自己的圖表，寫入你們的類別定義，並指定你們的變更授權方。
相關指南
常見問題
變更控制與變更管理有甚麼分別？
變更控制是程序的那一部分：一項具體的擬議變更如何提出、評估、授權、實施、驗證與結案，並在每一步留下紀錄。變更管理的範圍更闊——流程本身的策略、類別、角色、溝通與改善，在有些機構裡還包括組織變革中與人相關的全部工作。大家首先需要畫出來的流程圖幾乎一定是變更控制，因為那是日常真正要遵循的東西。
標準變更、常規變更與緊急變更分別是甚麼？
標準變更是預先批准、低風險而且可重複的變更，因此不經委員會，直接按既定程序執行。常規變更要經過評估與授權。緊急變更由一個精簡的授權方批准，因為等待常規通道所造成的損害，會大於這項變更本身的風險。三者都應按風險與影響範圍界定，而不是按規模，並要求緊急變更在固定期限內補齊紀錄。
變更諮詢委員會應該由誰組成？
應該是能夠評估影響、並能代表受影響服務發言的人：服務負責人、營運、有需要時的保安人員，以及一位代表客戶或業務影響的成員。人數要少到可以作決定，並設一位有決定權的主席。十五人的委員會不會認真審核任何事——而如果某位成員從未提出過任何疑問，那他只是在出席，不是在審核。
變更驗證不通過時應該怎麼辦？
執行回滾並回到規劃階段，而不是在時間壓力下硬要向前修補。這正是回滾方案要與變更同時寫好、觸發回滾的權限要事先指定的原因。恢復之後，這項失敗的變更帶著學到的東西重新走一次評估——把它當成一項沒有歷史的新變更，只會令同樣的失敗換一批人再發生一次。
變更控制與版本控制有甚麼分別？
版本控制識別並記住同一份成品的連續狀態——哪一個是現行版本，以及之前是甚麼。變更控制範圍更廣，是決定一項擬議變更究竟獲不獲准發生的評估、授權、實施、驗證與結案流程，一旦獲批，通常就會產生一個新版本。這個概念上的分別，詳見 /yue/guides/版本控制與變更控制的分別；而這個相同形狀落在不同文件類型上的具體變化，見 /yue/templates/文件變更控制流程 與 /yue/templates/標準作業程序變更控制流程。
