ITSM，又名IT中的ERP。出發點是讓IT向服務型組織轉變，合理利用開發資源，完善配套IT流程，並沉澱IT能力。ITSM普遍採用ITIL理念，分爲事件、問題、變更、配置、發佈五個核心模塊。公司全員對於IT的認知，80%來自運維服務人員。客觀來講，運維人員，一般與“服務”二字很難沾上邊的。且方式較野路子，有問題，電話直接call，技術人員直接解決。特別涉及到桌面問題，很可能是重裝個系統，按照打印機驅動，服務人員每日響應呼叫，奔波在現場。應用系統問題，大問題到還好，需要BA定位。小問題，例如bug、權限、賬戶開通，也是直接打到開發人員獲取支持。有的產品不穩定，總有bug，問這一週做了什麼？技術答曰忙於運維，可到底出了什麼問題，保留記錄有限。因此急需ITRP，IT資源規劃管理。
ITSM是個有意思的項目，業務方爲IT內部。業務調研只需在大屋子內轉一圈，挨個調研各產品/項目團隊需求。項目總會涉及到數據、組織、流程。藉着項目，推出需求變更流程、問題處理流程等IT流程；彙總、整理保存在本地、SVN的知識文檔；整理問題分類，細分到三級，一級爲四大類，基礎架構支持、應用系統、桌面支持、信息安全，二級爲應用系統或處理單元，三級爲功能模塊或功能點。這樣一份清單即可看出IT能力的全貌。
系統上線運行效果不如預期，沒有得到IT內部用戶的認可。這就很值得反思，IT做給IT的如此簡單系統，都不好用，那做給其他部門或企業級的大項目呢？原因，一是普遍問題，立項時沒有想清楚，當初是由運維部門主推，其他部門、應用系統團隊參與意願不高（現狀也是如此，變成了運維服務接收、指派工單的系統）；二是調研不充分，場景沒有想全。有的團隊人少，三四個人。而變更流程長達七個節點，經常是BA一人填寫、審批三四個節點。有的產品自帶缺陷收集、跟蹤功能，用戶已習慣在上面提交，如何ITSM對接欠缺考慮。事件問題收集後沒有考慮如何轉爲story，造成團隊收到問題後，現在ITSM接收，再在項目管理軟件創建任務做過程管理，解決後再登錄到ITSM關閉。造成了額外的工作量；三是用戶的業務成熟度不夠，具體來說流程有問題，同時管理不夠規範；四是僵化階段政策力度不夠，沒有讓用戶養成習慣。每週只是發報表通報，記錄每一位掛了多少已解決/未解決的事件及問題，沒有對應獎懲機制，也沒有部門發文；五是上線後缺少持續迭代優化。
核心功能點
-
事件：員工自助申報，通過結構化字段收集事件信息；細分優先級評分標準，合理安排開發資源。公示排序結果，有疑問組織需求方評審，讓業務掐架，IT記錄；事件解決後調查滿意度，反饋服務質量
-
問題：確定重複出現的事件或重大事件的根本原因，決定採用的解決方案並反饋實施效果。事件與問題如果所有系統都能用起來，累計一定時間保證質量的數據後，極具價值。例如找到共性問題，作爲年初項目立項依據。作爲團隊、成員的績效評估參數。成果量化數據的展示。
-
知識庫：可自主創建，亦可根據事件或問題創建知識文章。知識庫的難點有兩條，一是有效的審批機制，否則時間一長，爲了KPI或獎勵，什麼垃圾文章都會有人上傳，用戶搜索成本極高，整個知識庫失去了價值；二是如何鼓勵工程師將日常解決的問題，保留到知識庫中。若是設立激勵獎，大的申請不下來，申請下來了一時可以，支撐不了長期工程。小的沒有驅動力，尤其老同事，不會爲了每月兩三百花時間輸出。若是靠制度，那就是得罪人的事了，一個部門的，犯不着。
-
變更
-
呼叫中心：開發服務熱線。可過濾大部分初級問題。但要引導用戶使用系統提單。
-
服務目錄
-
桌面管理
-
CMDB
-
監控報表：工程師處理單據排行、時效性分析、應用系統問題排行、未解決單據排行