ITIL V3 服務轉換篇之變更管理中篇

變更管理的主要活動

變更的規劃和控制
變更和發佈的調度
溝通
變更決策和授權
確保有補救計劃
度量和控制
管理報告
瞭解變更影響
持續改進

變更管理流程圖

變更管理流程各環節

創建和記錄變更請求

變更是由發起者通過一個請求發起的。對於一個能給組織或財政帶來重大影響的重大變更，變更提議需要被完整說明，並連同從業務和財政角度來說明。

變更記錄，記錄了變更的所有歷史痕跡，從變更請求和隨後已設定的參數記錄中獲得信息。如優先和授權，執行和檢查信息。

變更記錄的定義應在流程規劃和設計時完成。

變更文檔的各類屬性藥儘量標準化。變更文檔，相關記錄和相關配置項都由CMS系統來更新。所以預算，實際資源，成本和結果都被管理報告記錄。

變更請求審覈

應過濾一下變更：

不合理的變更請求
過期、已接受、被拒絕或仍再審議中的被重複提交的變更請求
提交不完整變更請求

這些變更請求應退回給發起者並連同拒絕理由及簡單細節描述同時在日誌中記錄這一事項

變更評估

失敗的變更引發的潛在影響和對於服務資產和配置的影響需要被考慮。對於變更一下7個問題能對變更進行評估

誰提出的變更
變更的原因
變更的回報
變更帶來哪些風險
變更所需要的資源
誰來負責建立、測試和實施變更
變更之間的關心

變更的風險

分配優先次序

用來確定變更順序的。每一個變更都包括發起人對影響的評估和變更的緊迫性。變更優先是來自於影響性和緊迫性。最初的影響性和緊急度是由發起人提供的，但在變更授權流程中優先次序可能會被修改所以風險評估在這一階段就很重要。變更顧問組織爲了評估實施或者不實施變更所引發的風險時需要業務影響信息。影響是基於有利於業務的變更或由於錯誤變更造成損失和成本。影響無法用絕對數值表示，但可以取決於某些事情或某些情況的可能性。

1. 優先級的確定

以下是一個優先級編碼系統的例子：

低優先級: 些變更很值得，但是需要等待很長時間，
一般優先級: 沒有很緊急或者重大的影響，但是變更不能被推遲。
高優先級: 影響許多用戶的嚴重錯誤，或影響大量用戶的困難錯誤，或與其他緊急事件有關的錯誤。這種變更將在CAB 的下一次會議上給予最高優先級。
最高優先級: 變更請求(RFC)關注嚴重影響用戶使用潛在服務的問題，或者緊急IT 變更具有這種優先級的變更被劃分爲緊急變更。

2. 類別的確定

類別由變更管理決定，在與CAB 的磋商中很有必要，它顯示了變更的影響和IT 組織的需求。以下是類別的一些例子：

次要影響: 要求很低，且造成重大服務問題的風險也極低的變更。變更經理可以無須將它們提交給CAB，就批准這些變更。
實質影響: 需要做大量的工作，且對服務有切實的影響的變更。這些變更在CAB 會議上討論以決定所需的工作和潛在的影響。在會議之前，相關的文檔會在CAB 成員，可能包括專家以及開發人員之間傳閱。
重大影響: 需要做很大量的工作，且會影響到組織的重要部分的變更。變更經理需要有IT 管理或IT 籌備指導委員會的優先級授權，在此之後，變更必須提交給CAB。

變更的規劃和調度

仔細的規劃變更確保變更管理流程中每一個任務都是明確的；其他流程所包含的任務；給那些變更和發佈的供應商或項目提供多少流程接口。許多變更可能是屬於一個發佈裏的，有可能是設計、測試和發佈。也有許多獨立的變更組成一個發佈，這可能造成複雜的依賴關係難以管理。建議變更管理中，調度變更時優先考慮業務而不是IT的需求。

事先商定和已確定的變更和發佈窗口能幫助組織改善計劃和整個變更發佈。只要有可能，變更管理應安排授權，進行發佈目標變更或部署軟件包和分配相應資源。變更管理協調產品和變更日程的分配和預計服務中斷。變更日程包括所有授權實施變更及實施日期的詳細信息。預計服務中斷包含SLA協議和可用性中的變更細節。

變更的授權

特定類型變更的授權等級取決於變更種類、規模或風險。權力下放的程度可能存在於一個授權程度。

預期業務風險
對財政影響
範圍變化

協調變更執行

已授權的變更會被提交給執行變更的相關技術組，建議使用正規的方式來實現，便於對其追蹤。變更管理應確保變更如期完成，管理主要起到協調作用，具體實施由其他人員負責。每個變更都應提前準備修復程序並將其文檔化。因爲實施期間或實施後發生錯誤時這些程序能以對業務最小影響下進行快速恢復。變更管理有監督的作用，確保變更是經過測試的。對於沒有經全面測試的變更需要在執行時特別關注。

變更回顧、關閉

變更完成後變更管理者應對結果進行評估。評估還要包括由變更引起的任何事件。變更回顧應確認變更是否達到目標，應吸取的經驗對今後的變更進行改進。變更若沒有實現目標，變更管理應決定後續的行動，如果達到目標應關閉變更。

緊急變更

緊急變更是被預留給那些旨在修復那些嚴重影響到業務的緊迫程序高的IT服務故障。一個緊急變更的授權級別和權力下放程度應清楚的被記錄和了解。在緊急情況下，由ECAB批准。

緊急變更的建立、測試、實施

已授權的變更會有相關技術組去建立，在時限內變更經理與技術經理協作確保足夠的人力與資源來完成工作。
緊急變更的測試有可能要進行，應避免那些完全未經測試的變更。
變更的實施未能解決錯誤時可能需要有修補程序來迭代嘗試。變更管理應確保業務是被優先考慮的。每次迭代都應在控制下並確保失敗的變更被及時退出。

緊急變更文檔

它有可能無法在緊急行動時對所有變更管理記錄進行更新。但重要的是能儘早對這一階段進行記錄和對所有記錄進行回顧。爲了避免一些事故可以在未經事先授權情況下向事故管理員、計算機和網絡管理員下放權力。但這些下放的權利應限於不改變服務資產規範和不嘗試修復軟件錯誤。要解決軟件造成的事故首選方式是回退到以前的狀態或者受信版本，而不是試圖進行一個無計劃或者有潛在危險的變更。

緊急變更程序將遵循除正常變更外的一下規則