在此希望總結或強調一下ITSM的三個固有基本特性，以及其相應的核心流程及釋意：

• 共性——ITSM是一種基于ITIL標準的信息化建設的國際管理規范。ITIL體系提供了“通用的語言”，為從事ITSM的相關人員提供了共同的模式、方法和同樣的術語，使用戶和服務提供者通過有共性的工具深入討論用戶的需求，很容易達成共識。

• 中立——ITSM為IT管理提供了實施框架，這樣可以讓用戶不會受制于任何單獨的服務提供商。ITSM不針對任何特殊的平臺或技術，也不會因下一代操作系統的發布而改變。

• 實用——ITSM是一種以流程為導向、以客戶為中心的方法，它在兼顧理論和學術的同時，非常注重實用和靈活。

并且ITSM的核心流程包括：

1. 服務級別管理：它的目標是通過定義、協商、訂約、檢測和評審提供給客戶的IT服務，實現特定的、一致的、可測量的服務水平，為客戶節省成本，提高生產率。

2. 可用性管理：通過分析用戶和業務方的可用性需求，優化和設計IT基礎架構的可用性，從而確保以合理的成本滿足不斷增長的可用性需求。

3. 能力管理：指在成本和業務需求的雙重約束下，通過配置合理的服務能力，使組織的IT資源發揮最大的效能。

4. 服務連續性管理：在盡量少中斷客戶業務情況下提供IT服務，并在IT系統出現問題時以可控的方式恢復。

5. 財務管理：確定IT服務的預算，監督預算執行情況，根據服務收取費用。

6. 事件管理：在出現事件時盡可能快地恢復服務的正常運作。避免它造成業務中斷，以確保最佳的服務可用性級別。

7. 問題管理：旨在找到問題的源頭，積極地預防問題的再次發生。

8. 變更管理：它確保使用標準方法和規程有效且迅速處理所有變動，旨在提高組織的日常運作水平。

9. 配置管理：識別、控制、維護和檢驗現有的包括基礎設施和服務在內的IT資產。

10. 發布管理：目的是為了保證發布的成功，主要應用于大型的或關鍵硬件、主要軟件及打包或批處理一組變更。

服務臺：服務臺不是服務過程，而是一個服務職能，目的是為用戶和IT服務組織的提供一個統一聯系點。

正是通過這十個核心流程和一個服務職能，實現了IT服務管理的規范化、流程化。

現今隨著ITSM理念在全世界的普及，應運而生的一個獨立的軟件市場也在形成，即ITSM軟件工具提供服務。

目前ITSM軟件市場規模尚且有限，同時帶著初生的氣息，即混亂而充滿生機，相信在未來的幾年，ITSM的成熟與應用規模的壯大，ITSM軟件市場也會成長。為什么會這樣呢，難道引入ITSM方法就必須得有一款相應的ITSM軟件才行嗎？這其中道理是什么呢？

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

以ITIL理論為主導的服務管理過程中，每個流程都有大量的數據產生，尤其是配置管理中的配置信息，事件管理中的事件信息，還有諸如問題信息、變更信息、能力信息、服務級別信息等。

這大量的記錄彼此還存在關聯，以紙質記錄不現實，電子表格無法有集成關聯，搜索查詢同樣是大問題，僅僅一個CMDB都快成為一個獨立的軟件產品了，還有大量的基礎數據，比如客戶信息與支持團隊的信息，這些都是組織與人的數據，還有大量的分類基礎數據。所以在服務過程中產生的大量數據，這些數據首先要解決記錄的問題，然后是查詢的問題，最后是分析統計的問題。

在具體的服務過程中，為了保障服務級別的執行，需要在許多數據之間做關聯與計算，比如當一個應用系統發生故障時，服務臺需要將此故障記錄下來并調度工程師解決，這時就產生一個問題，這個故障需要派給哪一個工程師解決（服務體制、忙閑狀態），工程師需要多久完成故障排除？

這里就需要有一個約束，為了保障服務級別得到真正的執行，需要設置這個故障的解決要求時間，同時還要考慮到服務時間的問題，即我們承諾客戶的服務是5*8，還是7*24，甚至5*8中，這8小時，分別幾點至幾點，才是服務時間。只有這些數據參與邏輯運算，才能得到故障（事件）的處理時長，才能將時長與要求時間進行比較，以計算出按時解決率。

僅僅一個事件，就需要日歷數據、服務級別數據，與單據的創建時間與工程師的完成時間記錄，進行綜合運算，甚至在故障過程中，還需要考慮到分派的問題（從一個工程師轉給另一個工程師處理），還需要考慮到等待時間，最后還要考慮事件的責任歸屬，這些都是保障服務質量管理的基本要求。

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

無數的管理者最頭痛的一件事就是制度或流程的執行問題，我們很多時候，花費很大的精力與資源去設計出一套制度流程，但真正實施時，在日后漫長的作業過程中，要么是制度流程被丟在一邊，要么執行得變了樣。

這里面一方面的教育與素質的問題，還有就是我們沒有找到一種有力的方法來監管制度流程的執行，為流程的執行去花費巨大的監督成本，這并不是絕大多數公司可以承受的。事實上管理軟件問世，很大程度可以較好的幫助解決這一問題，ITSM作為管理軟件的一種，同樣有此功效。而且由于ITIL的流程界定相對比較清楚，因此帶來的流程執行幫助會更大。

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

IT或IT服務一直以來，有一個不好的傾向，神秘化有些象一個黑匣子，這里面帶來許多不好的現象，客戶不清楚IT服務商要這么多錢到底在搞些什么，IT服務管理者不清楚底下的員工具體在忙些什么，也不清楚為什么一個服務吞沒了這么多人力，下屬主管還在不斷喊人力緊張，不同的職能人員也不清楚為什么上一下環節或下一個環節為什么這么慢，而橫向的，一個故障解決到底是做了一些什么動作也是不清不楚的。

這些現象造成的惡果是成本居高不下、人員提升難以進行、人員更替培養困難、組織的知識難以有效成長、管理決策依賴是少得可憐的信息。同時這其中會造成一種綁架效應，IT服務商綁架了客戶，員工綁架了管理者或公司。

在我的理念中，ITSM軟件首先是一個平臺，它應該象一面鏡子，可以照射出所有服務環節，暴露出所有的灰色地帶與問題。每一個服務人員每天在做些什么，每個故障與作業處理到底是些什么動作，花費多少時間，全部需要透明化，一名基層管理者不應該把信息封閉在局部，我們應該可以取到任何一名服務人員或主管的作業信息，我們也應該清楚每個故障的詳細解決方法與動作步驟。

當我們真正構建部署好這個平臺，并開始有效運行后，我們會發現許多的我們以前不知道的信息，甚至是謊言。我們也會發生其實IT服務其實并不復雜，我們的工程師的資源并沒有充分的利用起來。效率與成本此時才真正攤開在我們面前，我們也會發生以前我們對主管們的工作評價原來是不公正的，當我們真正把成本、質量、效率、利潤這幾者的真實數據分析時，才知道我們之前的認知與管理假設的基礎是荒唐的。

對于大多數的IT服務商而言，國外的ITSM軟件還是太貴了，難以承受。而國內的ITSM軟件真正成熟的也是相當少，也暫時沒有機會對國內每一款軟件做測試評估，只能通過接觸過一些來推斷目前的現狀，國內的ITSM軟件最大的缺失是，軟件本身的設計者并不具備扎實的ITSM知識與管理理念。我個人一直的認知是，一款管理軟件的規劃者或設計師如果對管理本身沒有一定的認知，再精深的專業知識亦是無用，這僅不是ITSM軟件一個通病也是中國管理軟件的一個通病，缺乏管理思想。

而國內真正對ITSM有深入認識的人目前并不多，同時對ITSM與軟件設計二者都有一定基礎的人才更是少之又少，但Servicehot有這樣的開發團隊，對管理、ITSM、軟件設計三者同時有一定專長的，這三者還只是一個必要條件，不是充分條件，因為還要有扎實的開發實力與實施經驗，這五者組成在一起才有可能使一個ITSM軟件項目成功。國內的ITSM軟件，一般是兩條路，要么模仿起家，要么是依靠自身的業務經驗跌跌撞撞成長，以這么短短的幾年時間，做出來效果比較好的也還是只有Servicehot 旗下的ITSM系統。

其實ITSM軟件的獲取是兩條路，要么自己開發，要么買一款。這兩條路，無論是選擇哪一條路，建議還是從長計議。比較實際的是花點錢請一個專業人員或公司幫助做選型評估或軟件規劃，這樣可以少走不少彎路。規模大些的公司選擇百萬級別的軟件同樣要慎重，因為這些不是光花錢買一個好軟件就夠了，還需要有很好的實施顧問才行，主要原因要么是實施顧問沒有真正深入實際業務做出很好的咨詢意見，要么是實施顧問能力所限，再加上客戶本身的執行力不足，導致了和中國企業現在上ERP類似的情況。

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