IT部門當然是業務輔助部門，但這並不意味着IT部門只能充當被動救火員的身份。規範好，管理好IT業務，讓IT管理員從簡單的修機器、收郵件等低級勞動中擺脫出來，真正成爲爲IT管理服務的典範。這就是IT服務管理的概念。
其實，實現IT服務管理，並不難。
1. 夏忙，28歲，2004年4月進入滾滾來貿易公司，負責IT工作。滾滾來貿易公司以做進出口爲主，這幾年發展尤其快，從最初的幾十人到了現在的200多人，而且基本上是人手一臺PC。網絡、郵件已經逐步替代了以前的電話、傳真，成爲最新的辦公手段。
IT部門有三個人，夏忙一來就發現這三個人基本都不在自己的座位上，因爲公司的200多臺機器，總有這樣、那樣的問題報過來。於是，夏忙也就很快投入了戰鬥一線，修機器、調郵件、殺病毒，成了被拎來拎去的“八抓魚”。
忙歸忙，可是每到月底填寫考覈表的時候，夏忙就一點都想不起來這個月幹了什麼。好像每天都沒閒着，也好像每天都當救火隊員，但是看看這個月有什麼進步？除了撲了幾次一樣的火，修了幾次機器以後，再也沒有什麼可以書寫的記錄了。
最讓他鬱悶和委屈的是，累死累活一個月下來，雖然忙得手腳不着地，可挨領導的批評也更多了，因爲雖然問題是解決了，卻收到了更多的投訴：找不到人、反應速度太慢、相似的問題總出現、沒有預防措施......
總之，每天早晨，夏忙最擔心一件事，今天會不會發生災難性事件；每個月底，夏忙擔心另外一件事，這個月因爲遭遇投訴工資被扣了多少錢。
2004年8月31號，工資發下來之後，夏忙發現被扣了很多錢，IT部門的其他同事也是一樣。後來才知道，主要原因是他幫大家修機器時不在座位，別人有事打電話總找不到人，自然提意見。
從加盟滾滾來公司到現在已有半年時間，夏忙越來越忙，因爲單位人員在不斷增加，系統越上越多，加上最近病毒等“天災”頻頻光臨公司，事情也越來越多。時下IT部門只有3個人，人手實在是太少了，有時候大家一起打電話求助，夏忙苦於應付，遇到不該自己管的事情，夏忙就總是告訴打電話者該找小歐，放不下手裏活的小歐只好說，你找小王，結果是被集體投訴推託責任。
夏忙也有委屈，一個人分身乏術，人家業務部門的人一打電話來肯定得衝到一線，三個人都放出去，一旦活夠複雜，電話沒人接也就成了常有的事。
從8月中旬開始，夏忙陸續接觸了IT服務管理的“一站式”服務概念。所謂“一站式”服務，就是業務部門可以一次性獲取IT熱線、IT現場等各種形式的IT服務，解決所有日常辦公IT問題。“一站式”服務的精髓是IT服務檯。IT服務檯是用戶與IT服務部門的中心聯絡點，客戶的IT問題通過IT服務檯獲取答案和幫助。對於夏忙，通常來說，IT服務檯可以有兩種表現形式，一是電話申請服務，當用戶的系統出現問題時，可以撥打服務檯電話，根據語音提示選擇不同的問題類別；二是網絡申請服務。在IT網絡服務中，夏忙建立了一個簡單的基於Web形式統一入口，業務部門可通過Web的形式提出問題，問題自動提交到相應的IT工程師並進行解答,工程師之間也可以互相轉移。作爲一種很好的互動式服務渠道，是電話服務的補充。
建立IT服務檯之後，夏忙他們三個人針對分工不同，排除了接了電話亂找人的情況，並定義了首問負責制：哪位工程師最先接到業務部門的電話，就成爲該CASE的責任人，他需要自己或者協調相關人員解決並關閉這個“CASE”。這也解決了工程師間互相推委的現象。
服務檯建立起來後，並非萬事大吉。大家還是覺得電話方便，隨叫隨到。夏忙只好向老闆申請，把IT部門新的服務方式形成制度，大家來學習和維護。
機器加人工，基本上滿足了同事們的救援需求。
小貼士1：
問題響應方式固然重要，但讓大家知道並且習慣也是一個過程。對於IT人員來說，要公示響應方式，讓業務部門能夠主動使用、願意使用並滿意使用。
2. 建立了服務檯管理之後，夏忙從八爪魚變成了隨需應變的百變神形。因爲響應及時，夏忙最近沒聽見什麼抱怨。
一天，電腦提示收到一封事件警報郵件，同時，另外三封事件報警郵件也發到了夏忙的信箱。桌上的電話刺耳地響起，另外兩位同事的電話聲此起彼伏。
銷售部的同事反映無法接收郵件。夏忙剛剛撲到銷售部查問題，不多久，人事那邊也找夏忙，人事部的PC系統崩潰了，夏忙指揮同事去人事部處理這一問題。事情還在處理中，忽然又接到一個報警，說財務的機器上不了網，現在是月底要報稅，事情緊急。於是IT部門最後一個人去了財務部。夏忙忙亂得一頭大汗，他不知道假如再來一樁突發事件，他該怎麼辦。此時，一直有人在找夏忙，有的機器中毒，有的機器藍屏了等等。夏忙只好不停地說，“稍等——，稍等——”，一位急脾氣的同事不耐煩了，“我急着要一份數據，硬盤卻壞了，能不能先給我看看？”
“手邊有緊急的事沒處理完呢。”
“那你得分個輕重緩急啊。”夏忙一聽，覺得有理，層出不窮的技術故障讓IT部門的人疲於奔命，成了“救火隊”。可狀態不能老這麼持續下去，需要有一套流程和方法來有序地處理。他決定把手邊的事情忙完之後，好好思考一下。
經過緊張的排查，夏忙得出的結論是，網絡中心的一臺交換機出了故障，夏忙迅速聯繫網絡中心並啓用了備用的交換機。20分鐘後，網絡恢復正常。
趁着塵埃暫定，夏忙趕緊翻資料，能給目前無序的忙亂狀態理出一個解決思路。他發現，對於突發事件，最重要的是避免業務中斷。對此，首先要確定突發事件管理流程，通過區分突發事件的優先級來確保流程的有效執行。顯然，每個人都會認爲自己故障是最緊急的，因此必須理清是”火燒眉毛”還是”常規慢性病”。
夏忙反思，網絡中心那臺出故障的交換機上連接着公司的銷售部郵件服務器、庫存數據庫服務器、人力資源服務器，這一事故將直接影響到公司內關鍵部門的正常生產，應該屬於緊急一級，如果不盡快處理將發生一級生產事故；而急脾氣同事的事件則屬於一般級別。因此先處理網絡中心交換機問題是對的。但是自己在緊急事件的處理工時上把握不夠，剛纔用了大約3個工時來處理交換機的問題。那麼如果當自己在規定的時間內不能解決或沒有解決某個突發事件時，又該怎麼辦？一般來說，如果不能在規定時間內解決，需將處理任務交給更有經驗的支持人員。這叫突發事件升級，通常有兩種方式：一、職能升級，安排更多的專家或授予更多的特權以解決事故；二、層次升級，出現在所需的權限和資源不夠的時候。
突發事件管理可以幫助IT部門更加系統、快速地處理突發事件，但是隻是規範處理過程，以儘快恢復故障。好比是急診搶救，治標不治本。 要使突發事件管理有質的提高，治標也治本，一種切實有效的方法就是問題管理流程。
小貼士2：
當IT服務檯必須同時處理數個突發事件時，由於受時間、資源和人力等的限制而無法實現時，首先要排定處理的先後次序，針對不同的優先級處理。確定突發事件處理優先級，需要綜合考慮突發事件的影響、緊迫性、大小、範圍、複雜程度和當前可供資源。
3. 解決了突發事件，正趕上十一放長假，夏忙去了趟華山，徹底休息了一下。
10月8日一大早，夏忙的電話就響個不停。也難怪，一上班大家就忙着收郵件，積累了幾天的郵件把服務器搞得巨慢；許多節前已經預約的客戶需要儘快聯繫，可郵件一遍一遍就是發不出去；網絡更是不知犯了什麼病，很多機器死活上不去網......一整天，夏忙都在忙來跑去解決問題，面對抱怨，連解釋的時間都沒有。
晚上10點，總算有點頭緒。夏忙坐下來，纔想起自己幾乎一天沒吃飯、沒喝水了。其實想象得到，每次長假後的第一天對IT人員來說都是黑色的，這和過節一樣已經成爲慣例。 喝了一杯水、吃了點麪包、點上一支菸，夏忙回憶起這一天所幹的事。長假過後，收郵件高峯會有網絡堵塞，南方潮溼悶熱的天氣也會使得本來條件就差的機房服務器出現接觸問題。
趁着發牢騷的時間網管們開了個小會，自學了幾天IT服務管理的夏忙發現，事實上，今天他和其他兩位同事的很多工作具有一定的重複性，業務等幾個部門出現的IT問題幾乎都是一樣的。既然有規律可以循，是不是有辦法加強防範，結局豈不皆大歡喜？ 夏忙想起幾天前做過的ITSM的培訓，其中有一段說的就是問題管理，說白了就是“歸堆兒之後再分類”，要求建立一個知識庫，把以前發生的衆多問題進行歸納總結，找出規律對號入座，同時總結經驗不斷豐富。
大道理誰也會講，但夏忙還是不太理解。每天記錄發生的問題，隔段時間再進行歸納總結和分類，多麻煩啊！本來工作量就大，哪有時間寫日誌呢？正因爲有這樣的想法，夏忙一直沒當回事。不過今天看來，如果有這樣的一個知識庫就不至於這麼狼狽。
其實無論什麼公司，員工對IT的需求都有一定的共性。只處理不分析、不總結、不改進的IT永遠只能是重複勞動。而如果通過引入問題管理，建立一個知識庫，將衆多問題歸納總結，找出規律加以實踐，同時加強防範，不僅提高了效率，活也在一定程度上“少幹”了。夏忙越考慮越覺得有意思，於是打電話給上次給他講課的蔣得明老師。面對渴求上進的夏忙的困惑，老師打了幾個比方：事故管理是“救火”，問題管理是“消防”；事故管理是有病治病，問題管理是預防和保健。具體來說，滾滾來貿易公司在IT管理上，目前僅僅解決了如何規範地消除事故，而沒有做到找出導致事故的原因並徹底解決問題。
蔣老師還說，在現實中，問題是無法避免的，有技術架構、產品缺陷、操作失誤等等很多原因。夏忙又頭疼了，這麼多的原因怎麼分類呢？
蔣老師繼續說，對問題的歸類直接決定着問題管理的效果，問題歸類涉及五個方面：確定與問題相關聯的領域，比如硬件、軟件等；影響度，問題對業務流程的影響程度；問題需要得到解決的緊急程度；優先級，綜合考慮影響度、緊迫性、風險和可用資源後得出的解決問題的先後順序；狀態，描述事故目前所處的狀況。
另外就是找原因，包括現實的原因和潛在的原因，當發現更好的或新的應急措施時，問題管理還要將其在記錄中更新以便事故控制使用。
從此，滾滾來公司IT部門的公共文件夾多了一個文件夾，網管們記錄每個問題的現象、原因和解決細節。一個月下來，居然積累了300多個問題，共分了16大類，700多個原因。看着眼前的成就，夏忙有了底。
有了這個草創的“知識庫”，夏忙的工作進入了快車道，進入了“主動治本”階段。此後，大家對夏忙所在的IT部門有了好評，意見明顯少了。
小貼士3：
問題管理乍看起來對於IT人員來說是個費時間的活，但磨刀不誤砍柴功。有了這些積累，加上分類、分析、預防等工作，效率明顯提高了。對於IT人員來說，關鍵是排除抵觸和爲難情緒。
4. 11月1日，總經理召集各業務部門開會，簡直就是一個批判會，總經理對10月各個部門的表現都不滿意，特別是銷售部門，惟獨對IT部門提出了表揚，這讓夏忙有一些寬慰.
第二天.好不容易輕鬆一點的夏忙晚到了公司一會，半路接到公司裏電話，這個說有一封很緊要的郵件一直沒法收；那個說說好要給一個重要客戶把報價發過去的，但是現在也不能發......
原來是公司的郵件服務器出問題。可是昨天下班的時候這郵件服務器還好好的呀，夏忙趕緊給輪值的小歐打了個電話，問他昨天晚上都幹什麼了。
原來在總經理訓話結束以後，銷售經理就立刻召集了銷售部門人員開了個會。爲了改變目前的狀態，銷售部門討論的結果是改變現有的工作流程。昨天晚上加班開完會確認了新流程後，銷售經理把小歐找來要求系統也隨着這個新流程做些更改。於是，小歐就根據銷售經理的需求更改了幾個參數。“改完後我仔細檢查了一下，沒發現什麼問題呢。誰會想到郵件系統會出現問題呢？”小歐也很委屈。
夏忙明白了怎麼回事以後，趕緊親自到服務器上去恢復原來參數，讓郵件服務器先正常工作。這一天夏忙沒幹別的，他花了整整一天的時間處理銷售經理遞交過來的需求。夏忙發現，銷售經理拿過來的需求，有一些根本就不合理的。於是，夏忙又去找來銷售經理“論理”。兩人分析了半天，才討論出了雙方都滿意的解決方案。
這事就已經夠折騰的了。但是，由於11月份IT部門在忙着一個新系統的安裝，所以這事完了以後夏忙一直沒來得及跟整個IT部門討論。
哪裏想到這個月聽了總經理一通訓話以後，各個部門都比較積極地革新業務流程。採購部、人事部、財務部......在那幾天紛紛都來找IT部門來改流程、改參數。這下慘了，幾乎每次更改後都出現了問題。接連幾天夏忙更忙了，接連解決更改後出現的問題。
累得一塌糊塗的夏忙一閒下來就尋思：這不行呀，總經理訓一次話就出現了那麼多問題，萬一他再訓一次話，豈不是又完了；再說了，就算是總經理不訓話了，業務部門還是會經常提出要修改系統配置等問題的，畢竟對業務部門來說，“變”是件好事。如果還是像過去那樣隨便變更，IT部門遲早要被這無數的“變更”給折騰慘了。
夏忙心想，還不如趁這個機會建立一個變更管理的機制。這樣，一旦業務部門有了新業務、新變化、新流程，需要IT根據這新情況進行變更的時候，IT部門可以事先知道。
緊接着，夏忙就針對變更管理這個問題看了很多專業書籍，同時還虛心向同行請教。忙了半個月後，夏忙終於設計出了自己的變更管理流程。
夏忙自己動手給IT部門制定出了一個明確的需求變化表。用戶有變化需求時必須按照手續提交。拿到需求表以後，IT人員也不能馬上修改程序，而是應該判定此需求是否合理，是否會對以前的系統以及其他系統造成影響，必要的時候要與業務部門召開專題討論會，討論具體修改事情。同時，在內部網站中的IT服務專欄發佈IT作業公告。相關部門如果有異議，可以在反饋期之內反饋。
如果判斷通過，也不隨便就做更改，而是提出明確的時間表、修改方法和意見，徵求業務部門同意後，按時按量完成。
變更實施完畢以後，還要對變更的實施情況進行總結和評價：變更是否成功實施，業務部門是否滿意等；變更是否還有遺留問題，是否存在副作用。
“雖然總經理的訓話害得我那麼苦，但是就這個機會完善了變更管理流程以後，就再不怕其他的變更了，也算是沒有白忙乎。”對於這個月的工作，夏忙還是很有成就感。
小貼士4：
實施變更管理流程過程中，有兩個要素很重要。
其一，要轉變IT工程師的觀念和行爲。變更管理流程的實行，剛開始的時候，對IT工程師的行爲是一個約束。工程師對系統做任何修改、調整，都需要在變更管理系統申請、備案。因此，需要加強對IT工程師的宣傳和要求，轉變觀念，使其能夠接受並習慣。
其二，要明確職責。變更管理包括諸多流程，也涉及不同部門、不同崗位的人員。因此，需要界定各方人員的職責。如變更管理經理的職責，相關部門人員的職責，等等。只有職責清楚，各項職責執行到位，變更管理流程纔能有效落實。
5. 前幾個月一直表現亮眼的IT部門最近成了老闆的心頭好，員工們的抱怨沒了不說，還進行了好幾項突破性的改革，一派鳥槍換炮的新貌。年關將近，夏忙他們幾乎看到了可觀年終紅包的招手。
這天，本該春風得意的夏忙長嘆了口氣：“唉！”其他人忙問：“小夏，你怎麼了？連變更管理、突發事件管理......這樣的頭疼事件都能解決，你還會被難倒不成？”夏忙又嘆了口氣，說：“各位有所不知，萬里長征也不過走出了幾小步。前幾個月的工作儘管卓有成效，但跟接下來這個月要面對的事情一比，簡直就是小巫見大巫。一不小心，我們全體同仁煮熟的鴨子紅包恐怕就要飛了。” 這可不是夏忙小題大做，讓他頭疼的正是號稱IT服務管理最大難題的—服務級別管理(SLM- Service Level Management)。
對此，夏忙可有切膚之痛。得到同事們肯定了的IT部門是更加勤快了，但有時候卻揀了芝麻丟了西瓜—一次，在他忙着花半小時修理打印機的時候，服務器由於病毒***而癱瘓了整整20分鐘！公司的網上交易也因此停頓半天，老闆的雷霆發了足足有90分鐘。
什麼是服務級別管理？簡單地說，建立一套規則，當企業中有多個不同需求同時發生時，應該先響應誰的；以及對於不同的需求應該分配多長的時間。
“還是服務級別管理沒搞好啊！”夏忙感嘆。“我們IT部門應該有一個清楚的清單，列舉出我們能夠提供哪些服務，以及定義好各種業務部門要求提供的服務的級別。哪個級別高，哪個級別低，級別高的優先響應，級別低的等一等；規定問題的響應時間極限，哪個問題可以等上2個小時，或者等4個小時，哪個一秒鐘也不能等......”
聽來很不錯，不過要想搞好服務級別管理，可不是IT部門自己關上門來定一套規矩就行的，夏忙之所以談“服務級別管理”色變，就是因爲知道：服務級別管理的最大難度，在於定義各種服務的級別，而且不同企業也大不相同。因此，IT服務級別的制定必須是業務部門與IT部門共同溝通的結果——服務級別協議(SLA-Service Level Agreement)。IT服務部門在對IT基礎架構進行服務級別設計時，就必須充分調查和了解真實的業務需求。夏忙花了大量的時間和業務部門進行全面溝通。
他不僅調查了業務部門對當前服務級別的體驗(Perception)，還在這個基礎上幫助他們分析和梳理那些真實存在卻又還未明確的業務需求。
爲了避免重蹈其他公司推行服務級別管理失敗的覆轍，夏忙歸納出了幾條“黃金法則”：1.在服務級別協議中業務部門看不懂的日常術語需要學習；
2.把握好重點業務流程、定期的監控和回顧、適當簡化服務級別管理的流程；
3.綜合考慮資源水平和成本，避免對服務水平不切實際的承諾；
4.IT與業務部門持續分享流程經驗，不斷進步。
總之， SLM 的任務就是要在 IT 服務質量、客戶關係、以及 IT 服務成本三者之間博弈，尋找最有利的平衡點。
小貼士5：
在實際運行中，服務級別管理是個動態的過程，是可以調整的，大可以先簡單制定，然後根據實際情況進行調整。
經過小半年的忙活，眨眼到了年底，夏忙的年終紅包豐厚了許多，他也從一個PC修理工成長爲IT管理員，“夏忙”成了“夏工”，修機器、扯皮、投訴離夏忙越來越遠，轉而代之的是IT解決方案、項目管理、數據挖掘……
其實，夏忙知道自己離真正的IT服務管理還有不少的路要走，比如合理化規劃目前的系統資源，開發新的應用，比如進行企業的資產管理，再比如怎麼才能讓IT爲管理搭好橋。
這就是夏忙從瞎忙的IT網管成長爲合格的IT規劃者的道路，也是IT服務管理的靈活運用。
itilxf