AdvancedITIL: ITIL 的目標
主办者:
ITIL 的目標
變更管理目標
第 3 章
如果您不熟悉 ITIL 變更管理，則您需要了解「變更管理」與「在 ITIL 架構下變更控制」的差異處。只有在您完全了解之後才能真正建立一份有力的「ITIL 變更管理」論點。
ITIL 將「變更控制」定義為：
確保所有變更都能加以掌控的程序，包括變更的提交、分析、決策、核准、建置，以及建置後檢討。
相反地，ITIL 將「變更管理」定義為：
對基礎架構或是任何服務面向的變更作掌控的程序，以充分掌控的情況下允許核准的變更在最小的干擾上建置。
「變更管理」與「變更控制」的差異點出在每項定義的開頭。「變更控制」僅僅是一項程序，而「變更管理」則是一項全面性的程序。換句話說，「變更管理」程序可以控制許多變更。每項變更都需要有效的「變更控制」，而「變更管理」程序則負責監控所有的變更。
雖然您擁有良好的「變更控制」，如果沒有有效的「變更管理」，也可能導致失敗。例如，兩組不同的 IT 團隊正同時為相同的伺服器進行不同的變更。兩組人員都有效地控制變更，但是在建置階段卻都出現問題，因為兩組之間沒有溝通的管道導致某一方的變更造成對另一方有害的影響。運用了「變更管理」之後，兩組團隊同時注意到對方要變更相同伺服器的情況，進而互相徵詢意見以減少變更失敗的可能性。「變更管理」同時也管理許多受控制的變更的生命週期與現狀，因為「變更控制」是「變更管理」的一項元素。
因為「變更管理」範圍廣泛，也難怪 ITIL 目標是相當全面性的：
「變更管理」程序的目標是確保使用標準化方法與程序，有效且立即處理所有的變更，以減少由「變更」引致相關的「事件」造成對服務品質的衝擊，並進而改善企業的每日運作。
要針對「變更」請求做出適當回應意味著對風險與商務持續運作、變更衝擊、資源需求與變更核准時必須具備審慎考量的評估方式。要維持「變更」的需求與「變更」的衝擊之間的平衡，這樣謹慎的方式是絕對必要的。
「變更管理」程序必須擁有非常高的透明度與開放的溝通管道以便能平順地進行「變更」。
讓我們將此冗長的目標細分為基本元素，並找出能夠充分支持 ITIL 觀點的項目：
“減少由「變更」引致相關的「事件」造成對服務品質的衝擊”： 這項說明清楚地量化了「變更管理」範圍廣泛的責任。問題是：“在您所做的變更中，是否有些失敗的例子導致產生新的事件或問題，或是有些成功的變更但卻導致其他 IT 基礎架構元件的事件或問題？例如，您成功地新增軟體應用程式，但卻沒有足夠的記憶體，導致效能降低。如果您不確定這個問題的解決答案，請分析您的「事件」與「問題資料庫」看看是否存在指出變更失敗的證據。利用這項資料來顯示您已經偏離「變更管理」目標。向「服務台」人員詢問範例則不失為一個好方法，因為如果變更失敗的話，他們將會非常樂意幫忙。
“有效且立即處理所有的變更”：在這裡我們關心的是變更的排程與時間掌控。如果您清楚知道「變更請求」的註冊與管理事項，則您應該橫向檢查請求內容以決定有多少比例的變更太慢執行或遭到延遲。
這樣將在您確定是否符合「變更管理」目標的元素時提供所需的資料。如果您尚未採用「變更管理」，您將很難量化這個項目。您可以試著詢問客戶並徵詢他們對目前變更管理的效率看法，或是收集並分析目前不同 IT 位置所收到的變更請求。然而，當您取得資料後，這就變成一項重要的議題，因為變更排程與時間控制對「變更管理」的成敗有關鍵性的影響。
倘若您尚不清楚「變更請求」的註冊與管理事項，則驗證了「變更管理」的存在必要性，因為如果您不知道所要變更的基礎架構項目為何，或是變更的時間點，則您無法有效管理變更。
“確保使用標準化方法與程序”：每個 IT 部門都習慣使用自己的方法，將變更週期控制在自己的領域裡。然而，當不同部門同時進行相同的變更時，這樣的方式就不足取。針對變更事項，需求最高的變更項目就是不僅要成功執行變更，更要確保變更周圍的環境能成功接受這些變更。例如，網路瀏覽器的變更需要對諸如軟體與記憶體的基礎架構元件進行升級，同時需要教育使用者。如果這些項目沒辦法在變更進行階段完成，則變更將會失敗或產生問題。這就是為甚麼標準化方法與程序非常重要的原因。這是一項很容易檢查的目標，因為您一定擁有化為文字或是實際執行的標準化方法或程序，或是根本不擁有。如果不擁有的話，您應該假設如果不同的團隊同時進行相同的變更就是未遵守標準化方法與程序，而且變更失敗的機率會相對提高。您可以利用變更失敗的資料來佐證您的觀點。
“對風險與商務持續運作時必須具備審慎考量的評估方式”：此處所傳達的訊息就是在一小塊區域進行變更可能會對商務整體產生巨大的衝擊。所有將改變 IT 基礎架構的決定都必須集中進行，並納入所有受影響的相關單位的意見。通常，當變更的投資報酬率 (ROI) 在沒有納入其他 IT 團隊對變更所做的努力時，計算數據就會不準確。如果 IT 不知道變更的實際成本，如何能夠規劃預算與投資呢？
如果 IT 不清楚總共投入多少人力進行變更，如何能夠決定需要的人員編制人數？如果 IT 沒有共同評估變更的衝擊，「服務台」就會接到更多的來電。在今日的架構裡，就算是簡單的變更，一旦失敗仍會對企業造成嚴重的衝擊，有些甚至會動搖根本。為達到目標，我們應該著重在列出錯誤的變更可能導致的潛在商務衝擊，而不是為了證明錯誤而去找證據。
“維持「變更」的需求與「變更」的衝擊之間的平衡”：變更的潛在衝擊、好處與結果，與建置該變更的成本之間必須存在某種平衡。例如，可能會有一項「變更請求」要求移除某項「問題」，因為該問題造成「服務台」每日接到三次電話，而該問題對商務的衝擊卻是極小。剛開始時，建置這項變更聽來是個不錯的辦法，但是如果代價是 $200,000 呢？這個例子有點誇張，但是主要告訴我們在衡量衝擊與成本的得失之間需要充分的考量。這不是一件容易達到的目標，因為不容易取得有事實證明的硬資料來印證您的觀點。同樣地，您必須集中來管理「變更請求」。這樣一來，當您將相同變更的團隊的意見收集起來時，就可以找出真正的成本，而且還可以依據不同屬性的 IT 與客戶的綜合觀點來審核變更。
“擁有非常高的透明度與開放的溝通管道”：簡單地說，就是要求所有相關部門定期提供狀況的意見回饋，包括 IT 與商務部門。這是一項很容易評估的目標，因為您去做就對了，如果您不去做，剛好給「變更管理」一個正當性的理由。
「變更管理」促成企業內 IT 成功的重要關鍵之一。IT 現已是商務程序的重要一環，並已完全整合至正常商務活動的網絡中。失敗的、延誤的、超出預算的、資源不足的、溝通不良的、隔離的以及處理不良的變更都不能被容許。同時，記得要注意「變更控制」與「變更管理」之間的差異。
> > 第 4 章 - 組態管理目標