[原創(chuàng)]面壁ITIL之變更管理

申請免費試用、咨詢電話：400-8352-114

在ITIL中，事件從服務臺到事件管理再到問題管理是一個解決力度逐步加強的過程，但也是一個治標未治本的過程。要真正做到防范于未然或者減少事件影響，必須實施一定的變更以消除事件產生的根本原因。有變更必然會有風險，因此，加強對變更過程的控制，以防變更過程中的疏忽、資源短缺、準備不足等等原因造成變更失敗或產生新的事件已經成為IT服務提供者必須重視和認識考慮的問題。

圖1是客戶服務中心的ITIL服務支持框架，細心的讀者會發(fā)現在服務支持中缺少了變更管理一項。有人會問：沒有變更管理如何做好問題管理，找到了問題的根本原因應該如何變更？沒有變更管理，發(fā)布管理又依何而生？這個問題長久以來也一直縈繞在筆者的腦海中?？蛻舴罩行木烤褂袥]有變更管理的需求？如果有，在哪里？如果沒有，那又在哪里？

圖1－客戶服務中心ITIL框架 

目前的IT服務提供者分為兩種，一種是企業(yè)內部的IT部門，一種是第三方的IT服務提供商。隨著業(yè)務的發(fā)展，IT技術也越來緊密地深入到業(yè)務管理過程，而IT服務商們則面臨著一個急需解決的問題：企業(yè)或者外包方購買的軟硬件產品越來越多地來自不同的外部廠商。不論是IT部門還是IT服務商，以一己之力獨立地完成軟硬問題根源性的解決變得越來越困難，甚至不可行。當IT服務發(fā)展到問題管理無法在內部解決根源性問題，變更變得越來越不可控時，變更管理在哪里控制，如何控制就需要好好琢磨了。同樣，客戶服務中心現在也面臨這個問題。

4月初，某個區(qū)的許多用戶頻頻出現掃描商品時出現一碼多品的現象，即掃描商品條形碼時會跳出4，5個商品品名。由于事件涉及面比較廣，該事件迅速地升級到問題管理員的桌面。問題管理員將該問題轉至軟件提供商。軟件提供商費了幾番周折找到了問題根源：每日由服務器下發(fā)的基本信息中一些商品的條形碼信息被修改，導致不同的商品品名存在同一個條形碼的問題。這種變更沒有任何記錄，也沒有任何形式的通知。加之變更的過程不在客戶服務中心的可控范圍之內，在排除軟件故障、數據通訊故障和服務問題之后才找到根源所在。此時，距事件發(fā)生已過去一周的時間。

客戶服務中心為客戶提供零售系統的軟硬件外包服務。如圖2所示，當事件發(fā)生并升級為問題，提交到問題管理時，問題管理對問題做出簡單的判斷并分類。硬件問題轉硬件提供商，軟件問題轉軟件提供商。在收到他們的變更后，問題管理安排變更計劃，準備變更。由此我們看到的變更管理出現在外部軟硬件變更管理流程中，只是變更的最后實施在客戶服務中心的管理范圍之內。也就是說，變更的過程管理是存在的，但主要的變更控制不在客戶服務中心。筆者曾下過一個片面的結論：客戶服務中心不需要變更管理。這么看來這句話好像是對的，但是，再仔細琢磨這句話好像又有些不對。

圖2－客戶服務中心變更處理流程

變更是什么？變更是指在維護過程中對系統或服務所作出的各種改變，包括增補、移除和其他修改。說的再具體一點，變更的對象是兩個，一個是IT基礎架構，一個是IT服務（包括與流程和文檔），與這兩個對象相關的改變都要歸入變更的范圍?？蛻舴罩行臎]有變更管理，果真如此嗎？不是，IT基礎架構中的軟硬件變更的確不在客戶服務中心的管理范圍，但是IT服務的變更是存在于客戶服務中心的管理范圍之內。筆者之前把變更的認識局限在IT基礎架構上，而忽視了對IT服務的變更認識。因此，從變更的對象來看，客戶服務中心不僅存在著變更管理的需求，而且還必須建立起變更管理控制。

不論是企業(yè)的IT部門，還是第三方的IT服務商，都認識到協調好與軟硬件供應商之間的關系是做好IT基礎架構變更管理工作的前提。我們甚至可以把這種關系進一步深化為變更協作管理，充分運用SLA（服務水平協議）、OLA（服務支持協議）和UC（支持合同）來協調、約束各方面的這種協作關系，確保變更的可控。變更管理的要求、流程和相關的文檔由軟硬件供應商和IT服務商之間事先商定并共同遵守。內部的問題管理根據協商確定的格式和要求提交變更請求表，由外部的軟硬件供應商接受并記錄、登記，之后變更管理流程由外部的軟硬件供應商負責變更請求的篩選、接受、變更優(yōu)先級確定、變更規(guī)劃、變更實施和中止。當變更走完外部的變更流程再次回到內部的問題管理流程時，問題管理協同發(fā)布管理安排變更計劃和實施變更。由此筆者認為，在IT基礎架構的變更控制過程中，問題管理已經嬗變?yōu)閱栴}與變更協調管理。這也是在客戶服務中心的服務支持框架下，看不到變更管理蹤跡的原因。

如果變更的對象僅僅是指IT基礎架構，那么對IT服務提供商而言是可以考慮不再設置變更管理流程了。但是，IT服務變更的存在使得這樣的考慮不得不審慎。服務單據格式的變更、維護時間的調整、客戶的搬遷等等都可以作為內部IT服務的變更請求。如果不設置變更管理，那么這些變更請求應該如何提交？變更應該如何控制，是事件管理、問題管理還是發(fā)布管理？

也許這個問題需要具體情況具體分析。比如，服務單據格式的變更請求可以歸入到事件管理，由事件管理負責發(fā)起服務單據變更討論協調會，將最后的變更結果再提交至發(fā)布管理。IT服務的變更控制此時就體現在事件管理；問題管理在受理事件的升級報告時發(fā)現原有的升級流程比較繁瑣，效率不高。于是提出事件升級流程的變更，經過一番的討論后，如果認可變更，那么執(zhí)行變更。如果不被認可，變更中止，繼續(xù)使用原有的事件升級流程。此時，IT服務的變更又可以在問題管理控制。不論使用哪一種管理流程來控制變更，其間都不能省略一個環(huán)節(jié)：變更討論。這就是變更管理提到的變更影響和資源評估。

作為第三方的IT服務商，變更影響和資源的評估需要根據實際情況作出調整。對于客戶服務中心而言設立變更委員會是解決變更控制問題的一個途徑。凡是需要變更的內容，不論是IT基礎架構還是IT服務的最終發(fā)布都必須在變更委員會上確定。IT基礎架構的變更經變更委員會確定后統一安排變更計劃并實施變更；IT服務的變更由相關的管理流程提出并變更，最后也需要經變更委員會確定后統一安排變更計劃并實施變更。

在一個“變”作為惟一不變的環(huán)境中，變更管理尤顯重要。有變更就有風險，有風險就必須控制。而變更管理的空缺，也從一個側面說明作為IT服務主體的客戶服務中心，其變更管理認識以及變更風險控制意識仍需要進一步提高。