隨著ITSM理念在全世界的普及，應運而生的一個獨立的軟件市場也在形成，即ITSM軟件工具提供。下面是筆者所知的國內外一些公司的ITSM軟件（估計仍有不少漏項）

這些軟件的性價比不同，適用的對象亦有所區(qū)別，從數(shù)萬到數(shù)百萬不等，目前ITSM軟件市場規(guī)模尚且有限，同時帶著初生的氣息，即混亂而充滿生機，相信在未來的幾年，ITSM的成熟與應用規(guī)模的壯大，ITSM軟件市場也會成長。為什么會這樣呢，難道引入ITSM方法就必須得有一款相應的ITSM軟件才行嗎？這其中道理是什么呢？

以下將從幾個方面來探討在ITSM過程中，軟件支持的不可或缺：

一、ITSM的數(shù)據(jù)記錄

以ITIL理論為主導的服務管理過程中，每個流程都有大量的數(shù)據(jù)產(chǎn)生，尤其是配置管理中的配置信息，事件管理中的事件信息，還有諸如問題信息、變更信息、能力信息、服務級別信息等，這大量的記錄彼此還存在關聯(lián)，以紙質記錄不現(xiàn)實，電子表格無法有集成關聯(lián)，搜索查詢同樣是大問題，僅僅一個CMDB都快成為一個獨立的軟件產(chǎn)品了，還有大量的基礎數(shù)據(jù)，比如客戶信息與支持團隊的信息，這些都是組織與人的數(shù)據(jù)，還有大量的分類基礎數(shù)據(jù)。所以在服務過程中產(chǎn)生的大量數(shù)據(jù)，這些數(shù)據(jù)首先要解決記錄的問題，然后是查詢的問題，最后是分析統(tǒng)計的問題。

二、ITSM的邏輯運算

在具體的服務過程中，為了保障服務級別的執(zhí)行，需要在許多數(shù)據(jù)之間做關聯(lián)與計算，比如當一個應用系統(tǒng)發(fā)生故障時，服務臺需要將此故障記錄下來并調度工程師解決，這時就產(chǎn)生一個問題，這個故障需要派給哪一個工程師解決（服務體制、忙閑狀態(tài)），工程師需要多久完成故障排除？這里就需要有一個約束，為了保障服務級別得到真正的執(zhí)行，需要設置這個故障的解決要求時間，同時還要考慮到服務時間的問題，即我們承諾客戶的服務是5*8，還是7*24，甚至5*8中，這8小時，分別幾點至幾點，才是服務時間。只有這些數(shù)據(jù)參與邏輯運算，才能得到故障（事件）的處理時長，才能將時長與要求時間進行比較，以計算出按時解決率。僅僅一個事件，就需要日歷數(shù)據(jù)、服務級別數(shù)據(jù)，與單據(jù)的創(chuàng)建時間與工程師的完成時間記錄，進行綜合運算，甚至在故障過程中，還需要考慮到分派的問題（從一個工程師轉給另一個工程師處理），還需要考慮到等待時間，最后還要考慮事件的責任歸屬，這些都是保障服務的基本要求。

關聯(lián)性的問題同樣是需要做比較復雜的運算，比如這個事件與哪一個配置項有關系，這個事件導致了哪一些變更，或者導致哪一個問題的產(chǎn)生。做得比較好的ITSM軟件，還會考慮事件升級，即在一個事件處理時，如果達過某一個限定條件（事件長時間沒有人響應，事件超過要求解決時間仍沒有得到解決，發(fā)生一個嚴重事件），系統(tǒng)會發(fā)出郵件與短信通知處理者與相關的領導。這還僅僅是從單一事件本身出來，就有非常復雜的邏輯關系。

三、ITSM的流程執(zhí)行

無數(shù)的管理者最頭痛的一件事就是制度或流程的執(zhí)行問題，我們很多時候，花費很大的精力與資源去設計出一套制度流程，但真正實施時，在日后漫長的作業(yè)過程中，要么是制度流程被丟在一邊，要么執(zhí)行得變了樣。這里面一方面的教育與素質的問題，還有就是我們沒有找到一種有力的方法來監(jiān)管制度流程的執(zhí)行，為流程的執(zhí)行去花費巨大的監(jiān)督成本，這并不是絕大多數(shù)公司可以承受的。事實上管理軟件問世，很大程度可以較好的幫助解決這一問題，ITSM作為管理軟件的一種，同樣有此功效。而且由于ITIL的流程界定相對比較清楚，因此帶來的流程執(zhí)行幫助會更大。

以變更流程為例，變更管理的核心在于評估授權，即評估一個變更能不能做，該如何做，在什么時間點做，做完后如何驗證，同時導致的關聯(lián)信息需要管理。當變更流程利用軟件管理起來后，可以事先定義好，哪一些人有權力可以提出變更請求，哪一些有權力進行變更的審批，哪一些人有資格執(zhí)行變更的實施，哪一些負責變更結果的確認檢查，定義好這些角色后，結合服務體制的設置，這樣當一個具體的變更發(fā)生時，各個控制點都是無法逾越的，同時大家的作業(yè)時點可以控制，同時變更導致的配置項變化，可以在變更過程中進行關聯(lián)，這樣避免變更與配置的流程分裂。

四、ITSM的分析決策

在具體的服務過程中，我們經(jīng)常需要去許多管理改善，有一些管理改善是顯而易見的，比如發(fā)生一個重大故障發(fā)生完成緊急處理后，我們一般都會進一步深入分析故障的原因，并針對性的做一些預防措施，以避免再次發(fā)生，或發(fā)生后的危害如何降低。但有一些管理改善，我們缺乏方向感，這一點做為IT服務商這種感受尤其強烈，我們總是覺得我們的管理迫切需要提升，我們總是覺得我們還存在許多問題，所以我們不斷的在做管理改善，但最終總體的效果并不好，甚至方向是錯的，一是許多管理改善，真正深入后會發(fā)現(xiàn)并非是一個點造成，而是許多原因交織在一起，是成體系性的，二是ITSM眾多的流程全部是可以PDCA的，我們改善的流程可能反而不是我們的最短板，三是我們的改善缺乏一個方向與指標，具體改善什么流程，改善流程的哪一個點（績效），改善達到的水平。

對于管理而言，分析與決策占有很大權重，當管理者的轄區(qū)范圍較小、洞悉力強，他憑個人日常感受到與接受的信息就可以很好分析并做出正確的決策，這種類型的管理者仍然占絕多大數(shù)，基層的管理者更多是這一種類型。但一旦管理范圍擴大，組織架構較具縱深時，這時管理者會無法采集到大量的具體作業(yè)過程的信息，同時再也無法以個人的“感覺”來做分析決策了。好象在現(xiàn)實的管理活動中，有一個普適的規(guī)律，我們可以看一家公司在大時間跨度做規(guī)劃與計劃，就能最直接看出這家公司的管理成熟度與科學性，凡是那種做年度規(guī)劃或下一個年度的管理計劃時，以拍腦袋進行制定的，多數(shù)是不會基于歷史的數(shù)據(jù)分析，這樣的計劃即便做出來，執(zhí)行的可能性是極低的，所以每到年底時，回顧對比年初的規(guī)劃是差距甚遠的，這里面就是缺乏一個有效的PDCA機制，如果我們下一個年度的重心是放在提高事件按時解決率或客戶滿意度提高10個百分比，那么我們非常需要按這一指標設定在日常的管理活動中，或者周期性的進行匯報與分析，并進行改善。

上述的作業(yè)過程中，必不可少的就是數(shù)據(jù)的支持，你作業(yè)過程中的表單設計決定了你的數(shù)據(jù)素材有哪一些，你的報表設計決定了你的分析結果。當有一個作業(yè)平臺去貫徹與指示你的管理指標時，會很有效的讓整個組織形成一種共識，大家的注意力也會集中一起。這樣我們管理工作才會每年一個腳印，具有很強的持續(xù)性與科學性，而不是東來一下西來一下，好象每個層面的問題都在做，但豪無理性與戰(zhàn)術可言。

五、ITSM的作業(yè)協(xié)作

在服務過程中，由于服務的不同，或對象的不同，亦或專業(yè)的不同，會形成多個服務團隊與多種職能組，比臺常見的IT服務商中，會有服務臺、IDC、軟件應用、終端類這種職能單位，但具體一個服務時，許多時候會在使用這幾個職能單位的資源，即一個流程會貫穿整個組織內部，這時就形成一個悖論，如果我們服務要更有效率，我們應該打破職能，將資源更緊密的組織在一起，如果我們的質量、管理要更有序，我們需要按專業(yè)技能劃分團隊管理，以保證專業(yè)性，一個管理再優(yōu)秀的公司，幾個部門在協(xié)作做一些具體的事務時，一定會發(fā)生糾紛、溝通問題、職能不清的問題，那假設一個場影，如果一個客戶的系統(tǒng)出現(xiàn)了一個BUG，需要服務商解決時，首先客戶需用電話到服務臺，然后服務臺需要收集信息，然后告訴軟件應用人員，這時軟件應用人員需要做程序修正，然后提交測試部門測試，沒有問題后，要向IDC人員提出發(fā)布申請，最后發(fā)布后還需要同客戶解釋原因與驗證解決是否成功，這是一個很典型的故障類型，事實上為了講解的方便還簡化了許多環(huán)節(jié)與人員，這時我們可以看到，這其中的信息需要充分讓每個參與處理者與審批者清楚，依靠郵件與電話是多么不現(xiàn)實，這些人員是不同的部門，有什么方式可以更有效的約束他的作業(yè)配合與時間呢，這時一個統(tǒng)一的作業(yè)平臺是可以很好的發(fā)揮作用的。這樣就相對的解決了那個悖論，我們不在現(xiàn)實組織架構中打亂專業(yè)職能管理，但我們在平臺中實現(xiàn)虛擬組織，按最利于客戶與效率的方式組建技能組。

六、ITSM的作業(yè)透明

IT或IT服務一直以來，有一個不好的傾向，神秘化有些象一個黑匣子，這里面帶來許多不好的現(xiàn)象，客戶不清楚IT服務商要這么多錢到底在搞些什么，IT服務管理者不清楚底下的員工具體在忙些什么，也不清楚為什么一個服務吞沒了這么多人力，下屬主管還在不斷喊人力緊張，不同的職能人員也不清楚為什么上一下環(huán)節(jié)或下一個環(huán)節(jié)為什么這么慢，而橫向的，一個故障解決到底是做了一些什么動作也是不清不楚的。這些現(xiàn)象造成的惡果是成本居高不下、人員提升難以進行、人員更替培養(yǎng)困難、組織的知識難以有效成長、管理決策依賴是少得可憐的信息。同時這其中會造成一種綁架效應，IT服務商綁架了客戶，員工綁架了管理者或公司。

在我的理念中，ITSM軟件首先是一個平臺，它應該象一面鏡子，可以照射出所有服務環(huán)節(jié)，暴露出所有的灰色地帶與問題。每一個服務人員每天在做些什么，每個故障與作業(yè)處理到底是些什么動作，花費多少時間，全部需要透明化，一名基層管理者不應該把信息封閉在局部，我們應該可以取到任何一名服務人員或主管的作業(yè)信息，我們也應該清楚每個故障的詳細解決方法與動作步驟。當我們真正構建部署好這個平臺，并開始有效運行后，我們會發(fā)現(xiàn)許多的我們以前不知道的信息，甚至是謊言。我們也會發(fā)生其實IT服務其實并不復雜，我們的工程師的資源并沒有充分的利用起來。效率與成本此時才真正攤開在我們面前，我們也會發(fā)生以前我們對主管們的工作評價原來是不公正的，當我們真正把成本、質量、效率、利潤這幾者的真實數(shù)據(jù)分析時，才知道我們之前的認知與管理假設的基礎是荒唐的。

七、ITSM軟件的選擇

對于大多數(shù)的IT服務商而言，國外的ITSM軟件還是太貴了，難以承受。而國內的ITSM軟件真正成熟的也是相當少，我沒有機會對國內每一款軟件做測試評估，只能通過接觸過一些來推斷目前的現(xiàn)狀，國內的ITSM軟件最大的缺失是，軟件本身的設計者并不具備扎實的ITSM知識與管理理念，我個人一直的認知是，一款管理軟件的規(guī)劃者或設計師如果對管理本身沒有一定的認知，再精深的專業(yè)知識亦是無用，這不是ITSM軟件一個通病也是中國管理軟件的一個通病，缺乏管理思想。而國內真正對ITSM有深入認識的人目前并不多，同時對ITSM與軟件設計二者都有一定基礎的人才更是少之又少，這里我們可以想象，國內有幾家公司有這樣的開發(fā)團隊，對管理、ITSM、軟件設計三者同時有一定專長的，這三者還只是一個必要條件，不是充分條件，因為還要有扎實的開發(fā)實力與實施經(jīng)驗，這五者組成在一起才有可能使一個ITSM軟件項目成功。國內的ITSM軟件，一般是兩條路，要么模仿起家，要么是依靠自身的業(yè)務經(jīng)驗跌跌撞撞成長，以這么短短的幾年時間，離真正的成熟還有很長的路要長，除非有大量的客戶可以來試驗，這樣可以飛速的積累知識經(jīng)驗，來做產(chǎn)品的升級換代。

ITSM軟件的獲取是兩條路，要么自己開發(fā)，要么買一款。這兩條路，無論是選擇哪一條路，建議還是從長計議。比較實際的是花點錢請一個專業(yè)人員或公司幫助做選型評估或軟件規(guī)劃，這樣可以少走不少彎路。規(guī)模大些的公司選擇國外知名的ITSM軟件同樣要慎重，因為這些不是光花錢買一個好軟件就夠了，還需要有很好的實施顧問才行，從我看到的幾家購買了國外知名ITSM軟件的公司的情況來說，效果實在一般，可以用失敗形容，主要原因要么是實施顧問沒有真正深入實際業(yè)務做出很好的咨詢意見，要么是實施顧問能力所限，再加上客戶本身的執(zhí)行力不足，導致了和中國企業(yè)現(xiàn)在上廈門OA類似的情況。

選擇一款ITSM軟件，就等于選擇了未來許多年的作業(yè)平臺，整個IT服務管理就依附于它了，要從許多方面去思考與評估，往往這些國內的IT服務商是沒有專業(yè)能力來做的，就如讓一個沒有上過廈門OA的企業(yè)去選擇一款廈門OA一樣，最終變成誰的演講公關能力強就誰中標了，最核心的對軟件本身的深入評估分析反而是沒有做的，所以對意欲購買ITSM軟件的公司而言，多測試評估分析或者請外部專業(yè)人員來協(xié)助是保險之舉。