誰動了網管de紅包 - IT 服務管理五個心得

  Q：誰動了網管de紅包 - IT 服務管理五個心得
  A：IT 部門當然是業務輔助部門，但這並不意味著 IT 部門只能充當被動救火員的身份。規范好，管理好IT業務，讓IT管理員從簡單的修機器、收郵件等低級勞動中擺脫出來，真正成為為IT管理服務的典范。這就是IT服務管理的理念。

　　其實，實現IT服務管理，並不難。

　　夏忙，28歲，2004年4月進入滾滾來貿易公司，負責IT工作。滾滾來貿易公司以做進出口為主，這幾年發展尤其快，從最初的幾十人到了現在的200多人，而且基本上是人手一台PC。網絡、郵件已經逐步替代了以前的電話、傳真，成為最新的辦公手段。

　　IT部門有三個人，夏忙一來就發現這三個人基本都不在自己的座位上，因為公司的200多台機器，總有這樣、那樣的問題報過來。於是，夏忙也就很快投入了戰斗一線，修機器、調郵件、殺病毒，成了被拎來拎去的“八抓魚”。

　　忙歸忙，可是每到月底填寫考核表的時候，夏忙就一點都想不起來這個月干了什麼。好像每天都沒閒著，也好像每天都當救火隊員，但是看看這個月有什麼進步？除了撲了幾次一樣的火，修了幾次機器以後，再也沒有什麼可以書寫的記錄了。

　　最讓他郁悶和委屈的是，累死累活一個月下來，雖然忙得手腳不著地，可挨領導的批評也更多了，因為雖然問題是解決了，卻收到了更多的投訴：找不到人、反應速度太慢、相似的問題總出現、沒有預防措施……

　　總之，每天早晨，夏忙最擔心一件事，今天會不會發生災難性事件；每個月底，夏忙擔心另外一件事，這個月因為遭遇投訴工資被扣了多少錢。

　　1一站式服務 少干活多掙錢

　　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部門新的服務方式形成制度，大家來學習和維護。

　　機器加人工，基本上滿足了同事們的救援需求。

　　小貼士：

　　問題響應方式固然重要，但讓大家知道並且習慣也是一個過程。對於IT人員來說，要公示響應方式，讓業務部門能夠主動使用、願意使用並滿意使用。

　　2 突發事件管理 擺平漏子不罰款

　　建立了服務台管理之後，夏忙從八爪魚變成了隨需應變的百變神形。因為響應及時，夏忙最近沒聽見什麼抱怨。

　　一天，電腦提示收到一封事件警報郵件，同時，另外三封事件報警郵件也發到了夏忙的信箱。桌上的電話刺耳地響起，另外兩位同事的電話聲此起彼伏。

　　銷售部的同事反映無法接收郵件。夏忙剛剛撲到銷售部查問題，不多久，人事那邊也找夏忙，人事部的PC系統崩潰了，夏忙指揮同事去人事部處理這一問題。事情還在處理中，忽然又接到一個報警，說財務的機器上不了網，現在是月底要報稅，事情緊急。於是IT部門最後一個人去了財務部。夏忙忙亂得一頭大汗，他不知道假如再來一樁突發事件，他該怎麼辦。此時，一直有人在找夏忙，有的機器中毒，有的機器藍屏了等等。夏忙只好不停地說，“稍等——，稍等——”，一位急脾氣的同事不耐煩了，“我急著要一份數據，硬盤卻壞了，能不能先給我看看？”

　　“手邊有緊急的事沒處理完呢。”

　　“那你得分個輕重緩急啊。”夏忙一聽，覺得有理，層出不窮的技術故障讓IT部門的人疲於奔命，成了“救火隊”。可狀態不能老這麼持續下去，需要有一套流程和方法來有序地處理。他決定把手邊的事情忙完之後，好好思考一下。

　　經過緊張的排查，夏忙得出的結論是，網絡中心的一台交換機出了故障，夏忙迅速聯系網絡中心並啟用了備用的交換機。20分鐘後，網絡恢復正常。

　　趁著塵埃暫定，夏忙趕緊翻資料，能給目前無序的忙亂狀態理出一個解決思路。他發現，對於突發事件，最重要的是避免業務中斷。對此，首先要確定突發事件管理流程，通過區分突發事件的優先級來確保流程的有效執行。顯然，每個人都會認為自己故障是最緊急的，因此必須理清是火燒眉毛還是常規慢性病。

　　夏忙反思，網絡中心那台出故障的交換機上連接著公司的銷售部郵件服務器、庫存數據庫服務器、人力資源服務器，這一事故將直接影響到公司內關鍵部門的正常生產，應該屬於緊急一級，如果不盡快處理將發生一級生產事故；而急脾氣同事的事件則屬於一般級別。因此先處理網絡中心交換機問題是對的。

　　但是自己在緊急事件的處理工時上把握不夠，剛才用了大約3個工時來處理交換機的問題。那麼如果當自己在規定的時間內不能解決或沒有解決某個突發事件時，又該怎麼辦？一般來說，如果不能在規定時間內解決，需將處理任務交給更有經驗的支持人員。這叫突發事件升級，通常有兩種方式：一、職能升級，安排更多的專家或授予更多的特權以解決事故；二、層次升級，出現在所需的權限和資源不夠的時候。

　　突發事件管理可以幫助IT部門更加系統、快速地處理突發事件，但是只是規范處理過程，以盡快恢復故障。好比是急診搶救，治標不治本。

　　要使突發事件管理有質的提高，治標也治本，一種切實有效的方法就是問題管理流程。

　　小貼士：

　　當IT服務台必須同時處理數個突發事件時，由於受時間、資源和人力等的限制而無法實現時，首先要排定處理的先後次序，針對不同的優先級處理。

　　確定突發事件處理優先級，需要綜合考慮突發事件的影響、緊迫性、大小、范圍、復雜程度和當前可供資源。

  　3 問題管理 主動預防沒風險

　　解決了突發事件，正趕上十一放長假，夏忙去了趟華山，徹底休息了一下。

　　10月8日一大早，夏忙的電話就響個不停。也難怪，一上班大家就忙著收郵件，積累了幾天的郵件把服務器搞得巨慢；許多節前已經預約的客戶需要盡快聯系，可郵件一遍一遍就是發不出去；網絡更是不知犯了什麼病，很多機器死活上不去網．．．．．．一整天，夏忙都在忙來跑去解決問題，面對抱怨，連解釋的時間都沒有。

　　晚上10點，總算有點頭緒。夏忙坐下來，才想起自己幾乎一天沒吃飯、沒喝水了。其實想象得到，每次長假後的第一天對IT人員來說都是黑色的，這和過節一樣已經成為慣例。

　　喝了一杯水、吃了點面包、點上一支煙，夏忙回憶起這一天所干的事。長假過後，收郵件高峰會有網絡堵塞，南方潮濕悶熱的天氣也會使得本來條件就差的機房服務器出現接觸問題。

　　趁著發牢騷的時間網管們開了個小會，自學了幾天IT服務管理的夏忙發現，事實上，今天他和其他兩位同事的很多工作具有一定的重復性，業務等幾個部門出現的IT問題幾乎都是一樣的。既然有規律可以循，是不是有辦法加強防范，結局豈不皆大歡喜？

　　夏忙想起幾天前做過的ITSM的培訓，其中有一段說的就是問題管理，說白了就是“歸堆兒之後再分類”，要求建立一個知識庫，把以前發生的眾多問題進行歸納總結，找出規律對號入座，同時總結經驗不斷豐富。

　　大道理誰也會講，但夏忙還是不太理解。每天記錄發生的問題，隔段時間再進行歸納總結和分類，多麻煩啊！本來工作量就大，哪有時間寫日志呢？正因為有這樣的想法，夏忙一直沒當回事。不過今天看來，如果有這樣的一個知識庫就不至於這麼狼狽。

　　其實無論什麼公司，員工對IT的需求都有一定的共性。只處理不分析、不總結、不改進的