一般業界認爲"ITSM工具不是萬能的，但是ITIL沒有軟件工具是萬萬不能的“。難道引入ITSM方法就必須得有一款相應的ITSM軟件纔行嗎？以下將從幾個方面來探討在ITSM過程中，軟件支持的不可或缺：
1.1 ITSM的數據記錄
以ITIL理論爲主導的服務管理過程中，每個流程都有大量的數據產生，尤其是配置管理中的配置信息，事件管理中的事件信息，還有諸如問題信息、變更信息、能力信息、服務級別信息等，這大量的記錄彼此還存在關聯，以紙質記錄不現實，電子表格無法有集成關聯，搜索查詢同樣是大問題，僅僅一個CMDB都快成爲一個獨立的軟件產品了，還有大量的基礎數據，比如客戶信息與支持團隊的信息，這些都是組織與人的數據，還有大量的分類基礎數據。所以在服務過程中產生的大量數據，這些數據首先要解決記錄的問題，然後是查詢的問題，最後是分析統計的問題。
▶數據的發現能力
傳統配置數據難以維護的根本原因，主要是過分依賴人工收集、維護。由於人的自有惰性，時間久了數據會失去鮮活性，變成一團散沙。所以數據維護應該採用技術手段來降低管理負擔，多依賴於自動化發現與調和能力，來源可以兼顧多重途徑獲取，結合內置算法、人工修正、自動學習，對發現結果進行調和，最終形成可以感知實際IT環境的配置數據。
目前自動發現的渠道主要有：
（1）遠程協議獲取：主要包含ICMP，SNMP，WMI，SSH等協議，例如ICMP主要是看IP可達，掃描全網的在網IP。SNMP主要是網絡設備的採集，WMI是Windows的操作系統，利用網絡連接跟蹤腳本發現應用端口的關係。
（2）安裝代理：在被管機器上安裝代理程序，通過代理內置的發現能力，可擴展的腳本，來發現主機硬件、操作系統、安裝的數據庫、中間件等配置信息。
（3）和第三方工具集成：例如，可以利用APM監控系統，APM通過交換機端口鏡像，分析網絡中的7層協議，可以分析得到業務系統的服務路徑關係，並將關係數據送至CMDB調和。
通過合理的模型顆粒度和自動發現能力配合，可以解決IT運維中70%左右的信息獲取，再通過人工維護來進行補充、校驗完善。
▶數據的感知能力
互聯網+時代的雲化數據中心，爲快速響應業務的需求，應用需要隨時應對擴容的需要，因此，配置及關係是動態變化，然而CMDB的本質就是爲了真實、實時、反映數據中心的架構，這樣使得CMDB能否實時捕獲和感知數據的變化顯得尤爲重要。對於變化的內容，需要向訂閱用戶和第三方系統實時推送。
▶數據的分析能力
CMDB建設成功帶來的另一個未來價值是作爲配置元數據的價值，可以爲運維大數據分析提供可信基礎，促進運維走向大數據分析、智能決策階段。例如，我們在做變更的時候，需要去看該變更的影響範圍是多大?變更將引起什麼樣的情況發生？曾經這樣的變更是否引起故障？如果有故障是怎麼修復？
1.2 ITSM的流程執行
無數的管理者最頭痛的一件事就是制度或流程的執行問題，我們很多時候，花費很大的精力與資源去設計出一套制度流程，但真正實施時，在日後漫長的作業過程中，要麼是制度流程被丟在一邊，要麼執行得變了樣。這裏面一方面的教育與素質的問題，還有就是我們沒有找到一種有力的方法來監管制度流程的執行，爲流程的執行去花費巨大的監督成本，這並不是絕大多數單位可以承受的。事實上管理軟件問世，很大程度可以較好的幫助解決這一問題，ITSM作爲管理軟件的一種，同樣有此功效。而且由於ITIL的流程界定相對比較清楚，因此帶來的流程執行幫助會更大。
以變更流程爲例，變更管理的核心在於評估授權，即評估一個變更能不能做，該如何做，在什麼時間點做，做完後如何驗證，同時導致的關聯信息需要管理。當變更流程利用軟件管理起來後，可以事先定義好，哪一些人有權力可以提出變更請求，哪一些有權力進行變更的審批，哪一些人有資格執行變更的實施，哪一些負責變更結果的確認檢查，定義好這些角色後，結合服務體制的設置，這樣當一個具體的變更發生時，各個控制點都是無法逾越的，同時大家的作業時點可以控制，同時變更導致的配置項變化，可以在變更過程中進行關聯，這樣避免變更與配置的流程分裂。
1.3 ITSM的分析決策
在具體的服務過程中，我們經常需要去許多管理改善，有一些管理改善是顯而易見的，比如發生一個重大故障發生完成緊急處理後，我們一般都會進一步深入分析故障的原因，並針對性的做一些預防措施，以避免再次發生，或發生後的危害如何降低。但有一些管理改善，我們缺乏方向感，這一點做爲IT服務商這種感受尤其強烈，我們總是覺得我們的管理迫切需要提升，我們總是覺得我們還存在許多問題，所以我們不斷的在做管理改善，但最終總體的效果並不好，甚至方向是錯的，一是許多管理改善，真正深入後會發現並非是一個點造成，而是許多原因交織在一起，是成體系性的，二是ITSM衆多的流程全部是可以PDCA的，我們改善的流程可能反而不是我們的最短板，三是我們的改善缺乏一個方向與指標，具體改善什麼流程，改善流程的哪一個點（績效），改善達到的水平。
對於管理而言，分析與決策佔有很大權重，當管理者的轄區範圍較小、洞悉力強，他憑個人日常感受到與接受的信息就可以很好分析並做出正確的決策，這種類型的管理者仍然佔絕多大數，基層的管理者更多是這一種類型。但一旦管理範圍擴大，組織架構較具縱深時，這時管理者會無法採集到大量的具體作業過程的信息，同時再也無法以個人的“感覺”來做分析決策了。好象在現實的管理活動中，有一個普適的規律，我們可以看一家公司在大時間跨度做規劃與計劃，就能最直接看出這家公司的管理成熟度與科學性，凡是那種做年度規劃或下一個年度的管理計劃時，以拍腦袋進行制定的，多數是不會基於歷史的數據分析，這樣的計劃即便做出來，執行的可能性是極低的，所以每到年底時，回顧對比年初的規劃是差距甚遠的，這裏面就是缺乏一個有效的PDCA機制，如果我們下一個年度的重心是放在提高事件按時解決率或客戶滿意度提高10個百分比，那麼我們非常需要按這一指標設定在日常的管理活動中，或者週期性的進行彙報與分析，並進行改善。
上述的作業過程中，必不可少的就是數據的支持，你作業過程中的表單設計決定了你的數據素材有哪一些，你的報表設計決定了你的分析結果。當有一個作業平臺去貫徹與指示你的管理指標時，會很有效的讓整個組織形成一種共識，大家的注意力也會集中一起。這樣我們管理工作纔會每年一個腳印，具有很強的持續性與科學性，而不是東來一下西來一下，好象每個層面的問題都在做，但豪無理性與戰術可言。
1.4 ITSM的作業協作
在服務過程中，由於服務的不同，或對象的不同，亦或專業的不同，會形成多個服務團隊與多種職能組，比臺常見的IT服務商中，會有服務檯、IDC、軟件應用、終端類這種職能單位，但具體一個服務時，許多時候會在使用這幾個職能單位的資源，即一個流程會貫穿整個組織內部，這時就形成一個悖論，如果我們服務要更有效率，我們應該打破職能，將資源更緊密的組織在一起，如果我們的質量、管理要更有序，我們需要按專業技能劃分團隊管理，以保證專業性，一個管理再優秀的公司，幾個部門在協作做一些具體的事務時，一定會發生糾紛、溝通問題、職能不清的問題。
假設一個場景，如果一個客戶的系統出現了一個BUG，需要服務商解決時，首先客戶需用電話到服務檯，然後服務檯需要收集信息，然後告訴軟件應用人員，這時軟件應用人員需要做程序修正，然後提交測試部門測試，沒有問題後，要向IDC人員提出發佈申請，最後發佈後還需要同客戶解釋原因與驗證解決是否成功。
這是一個很典型的故障類型，事實上爲了講解的方便還簡化了許多環節與人員，這時我們可以看到，這其中的信息需要充分讓每個參與處理者與審批者清楚，依靠郵件與電話是多麼不現實，這些人員是不同的部門，有什麼方式可以更有效的約束他的作業配合與時間呢，這時一個統一的作業平臺是可以很好的發揮作用的。這樣就相對的解決了那個悖論，我們不在現實組織架構中打亂專業職能管理，但我們在平臺中實現虛擬組織，按最利於客戶與效率的方式組建技能組。
1.5 ITSM的作業透明
IT或IT服務一直以來，有一個不好的傾向，神祕化有些象一個黑匣子，這裏面帶來許多不好的現象，客戶不清楚IT部門要這麼多錢到底在搞些什麼，IT服務管理者不清楚底下的員工具體在忙些什麼，也不清楚爲什麼一個服務吞沒了這麼多人力，下屬主管還在不斷喊人力緊張，不同的職能人員也不清楚爲什麼上一下環節或下一個環節爲什麼這麼慢，而橫向的，一個故障解決到底是做了一些什麼動作也是不清不楚的。這些現象造成的惡果是成本居高不下、人員提升難以進行、人員更替培養困難、組織的知識難以有效成長、管理決策依賴是少得可憐的信息。同時這其中會造成一種綁架效應，IT部門綁架了客戶，員工綁架了管理者或公司。
在我的理念中，ITSM軟件首先是一個平臺，它應該象一面鏡子，可以照射出所有服務環節，暴露出所有的灰色地帶與問題。每一個服務人員每天在做些什麼，每個故障與作業處理到底是些什麼動作，花費多少時間，全部需要透明化，一名基層管理者不應該把信息封閉在局部，我們應該可以取到任何一名服務人員或主管的作業信息，我們也應該清楚每個故障的詳細解決方法與動作步驟。當我們真正構建部署好這個平臺，並開始有效運行後，我們會發現許多的我們以前不知道的信息，甚至是謊言。我們也會發生其實IT服務其實並不複雜，我們的工程師的資源並沒有充分的利用起來。效率與成本此時才真正攤開在我們面前，我們也會發生以前我們對主管們的工作評價原來是不公正的，當我們真正把成本、質量、效率、利潤這幾者的真實數據分析時，才知道我們之前的認知與管理假設的基礎是荒唐的。
1.6 ITSM的邏輯運算（智能調度）
在具體的服務過程中，爲了保障服務級別的執行，需要在許多數據之間做關聯與計算，比如當一個應用系統發生故障時，服務檯需要將此故障記錄下來並調度工程師解決，這時就產生一個問題，這個故障需要派給哪一個工程師解決（服務體制、忙閒狀態），工程師需要多久完成故障排除？這裏就需要有一個約束，爲了保障服務級別得到真正的執行，需要設置這個故障的解決要求時間，同時還要考慮到服務時間的問題，即我們承諾客戶的服務是5*8，還是7*24，甚至5*8中，這8小時，分別幾點至幾點，纔是服務時間。只有這些數據參與邏輯運算，才能得到故障（事件）的處理時長，才能將時長與要求時間進行比較，以計算出按時解決率。
僅僅一個事件，就需要日曆數據、服務級別數據，與單據的創建時間與工程師的完成時間記錄，進行綜合運算，甚至在故障過程中，還需要考慮到分派的問題（從一個工程師轉給另一個工程師處理），還需要考慮到等待時間，最後還要考慮事件的責任歸屬，這些都是保障服務質量管理的基本要求。
關聯性的問題同樣是需要做比較複雜的運算，比如這個事件與哪一個配置項有關係，這個事件導致了哪一些變更，或者導致哪一個問題的產生。做得比較好的ITSM軟件，還會考慮事件升級，即在一個事件處理時，如果達過某一個限定條件（事件長時間沒有人響應，事件超過要求解決時間仍沒有得到解決，發生一個嚴重事件），系統會發出郵件與短信通知處理者與相關的領導。這還僅僅是從單一事件本身出來，就有非常複雜的邏輯關係。