IT服務管理是一套為最終用戶設計和交付IT服務的政策和程序。其范圍超越了IT支持/幫助臺，擴展到持續改進IT服務以滿足業務需求所需的所有監控、管理和故障排除功能。
如果實施得當，IT服務管理(ITSM)可以降低IT資產和管理成本，提高員工的工作效率和滿意度，并讓管理層深入了解IT資源如何推動業務發展。
關于ITSM
IT服務管理(IT service management，簡稱ITSM)是一套為最終用戶設計和交付IT服務的政策和程序。其范圍超越了IT支持/幫助臺，擴展到持續改進IT服務以滿足業務需求所需的所有監控、管理和故障排除功能。
ITSM起源于IT基礎架構標準庫(IT Infrastructure Library，簡稱ITIL)——由英國政府部門中央計算機和遠程通信局(CCTA)在20世紀80年代末開發的一套IT服務管理標準庫，旨在提高IT資源的利用率和服務質量。
ITSM的三大要素：
- 人員：設計服務，定義流程;
- 技術：實現流程的自動化、電子化，并監測服務;
- 流程：對服務的規劃、開發和部署進行管理和支持;
有效的ITSM需要確定哪些技術組件(如服務器和數據庫)支持哪些應用程序，正確地將這些知識文檔化并調整優化支持流程。隨著時間的推移，這些關系和依賴項正變得愈發復雜，ITSM可能會變得過于昂貴，并且過于關注技術而非業務。
ITSM常見錯誤
以下是ITSM可能出錯的一些常見方式以及相應地解決方案：
1. 好高騖遠，搞假大空
哥本哈根機場IT資產及服務管理負責人Christian Hjortjaer解釋稱：
ITSM實踐過程中切忌好高騖遠，不要貪多求快。以我們自身為例，在使用ServiceNow的ITSM管理平臺時，我們先從核心ITSM(例如事件管理和變更管理)開始，并將使用范圍限制在筆記本電腦和軟件等平臺內。隨后再逐步將其擴展到其他服務，例如門禁卡和停車許可證等。可以肯定地說，如果我們從一開始就提供所有服務，一定會慘敗收場，因為這個過程需要大量時間和資源提供支持。
Hjortjae補充道，不過，我們在創建用戶知識庫方面確實是操之過急了，以至于未能制定適當的升級和維護流程。在處理問題的過程中，篩選不準確和過時的信息并予以糾正可能都需要耗費大量的時間和精力。
Gartner高級研究總監Chris Matchett建議：
從核心功能入手，并定期對其進行審查。在開始更高級的活動(如人工智能)之前，一定要確保這些成為IT組織文化的一部分。務必要先記錄和優化流程，然后再考慮自動化它們。如果流程本質上是存在缺陷的，那么自動化也只會一遍又一遍的輸出錯誤的結果。
Hjortkjaer的第一步行動就是利用ServiceNow來創建一個通用數據源，通常被稱為配置管理數據庫(CMDB)，具有與業務應用程序的詳細記錄鏈接。例如，使用CMDB來追蹤哪些服務依賴于哪些服務器，有助于IT人員判斷哪些服務中斷是最關鍵的，以便快速恢復它們并及時通知用戶相關問題。
Applus(一家檢測和測試服務公司)CTO Ruben Avila Calvo表示，使用ITIL框架做ITSM的客戶應該確保創建一個清晰、定義明確的IT服務目錄和管理流程。ITIL的應用前提是您對流程、角色和職責都有明確的定義，其中每個階段都有完善的文檔記錄，保持職責分明，并且有適當的流程來確保服務按約定的服務級別協議(SLA)交付，否則會因服務問題被導向錯誤的人員而導致更高的成本和更低的服質量。
2. 忽視業務
人們很容易將ITSM的核心聚焦在“IT”，但其實它的真正目標是提供業務服務。未能在設計ITSM時充分考慮業務因素，并且無法用業務語言來描述其技術優勢，可能會影響ITSM的采用率，并增加使用過程中的混亂度和困難度。
Hjortkjaer表示：
如果我在業務部門，我不會關心IT有多少個故障要處理，我只關心我的應用程序——我的應用程序有多少個故障，我應該如何解決？我需要給CEO提供有意義的報告，這需要我把故障和正確的配置項關聯起來，然后將其聯系到正確的業務應用程序，并說明這些服務如何幫助改善整個機場的運營。
Corteva公司業務服務集成負責人Kshitij Bahadur介紹稱，Corteva使用ServiceNow ITSM解決的其中一個挑戰就是將不相干的IT組件關聯起來，以便應用程序所有者不必為了給業務構建應用程序而四處去追服務器、數據庫、和防火墻團隊，這樣無疑會浪費大量時間。
亞利桑那州Gilbert鎮的代理CTO Eugene Mejia和他的團隊將改善該鎮1600名員工的體驗作為其ITSM活動的關鍵業務驅動力。他和IT領導團隊利用月度員工調查來評估新開發功能的成功度，例如Web界面或是支持遠程工作的移動應用的質量。他們使用Cisco Unified Communications Manager和Webex Contact Center來管理服務請求以及故障排除服務的呼叫隊列。
Forrester分析員Will McKeon-White表示，對那些需要給ITSM提供資金支持的C級高管來說，這種對員工體驗的關注非常具有說服力。
3. 無效的溝通
不明確的溝通會增加向業務部門解釋ITSM的價值、合理組織ITSM活動、為系統部署設定預期以及獲取資金支持的困難度。
Hjortkjaer建議使用CMDB將IT組件映射到業務應用程序，將這些應用程序的所有權分配給IT和業務負責人，并要求這些負責人來解釋每個應用程序對業務的作用、如何最好地使用它以及何時需要更換它。
Service Corp International公司電信及IT支持總監Thomas Smith建議，要對日程安排保持坦率。他解釋稱：
我們曾經犯過的，并且還在犯的最大的錯誤之一，就是說‘我們將在三個月內搞定它。’結果四個月后，每個人仍然希望再有三個月。你需要了解自己的ITSM工具和服務的所有不足，然后告訴業務流程負責人‘我們有解決它的計劃’。
Calvo表示，服務級別協議(SLA)中定義的條款，例如用BMC的Helix ITSM平臺所創建的那些，可以幫助設定預期并降低“認為所有問題都應該盡快解決”的用戶的挫敗感。
McKeon- White認為，清晰的溝通還可以幫助業務負責人就定制化和由此產生的維護難題達成共識。每一個人都試圖以自己理解的方式來滿足組織的需求，但這可能會與客戶成果、降低風險管理等方面產生沖突。
Smith說，在ITSM支持工具上(例如他使用的Ivanti Neurons for ITSM平臺)描述清楚用戶究竟需要什么，同樣非常重要。例如，這可能包括用戶在他們的W-9表格上看到的內容，或者他們所說的“屏幕總是崩潰”是什么意思。這些需求可能難以確定，例如，一個人力資源工作者可能不理解故障和服務申請之間的區別。為了解決這些問題，Smith與IT和業務用戶協商并分享關于這些術語和定義，以確保每個人對每一個需求都充分理解并在優先級上達成一致。
4. 過度定制
McKeon- White認為，過度定制是他在ITSM項目中遇到的最大挑戰之一。客戶會根據“他們認為的正當理由”去修改ITSM系統。隨著對系統修改次數不斷增加，并且那些進行修改的員工相繼離開公司，想要重構這些變更或者理解為什么進行修改，幾乎成了不可能的事，這也使得ITSM系統的管理和升級變得愈發困難……
問題不在于被定制的單一功能，而是所有這些定制如何協同工作。鑒于ITSM平臺中各組件之間接口的數量和復雜性，你可能沒有辦法實施你需要的變更，因為這會牽一發而動全身。
Bahadu也同意這一觀點，并表示：
我們曾經犯過的，并且還在犯的最大的錯誤之一，就是說‘我們將在三個月內搞定它。’結果四個月后，每個人仍然希望再有三個月。你需要了解自己的ITSM工具和服務的所有不足，然后告訴業務流程負責人‘我們有解決它的計劃’。
5. 缺乏可持續性
Matchett表示，ITSM不能作為一個有時間限制的項目來一次性完全實施。缺乏持續的管理和培訓會降低ITSM的效率，尤其是在業務需求和ITSM工具本身發生改變的情況下。
大多數ITSM工具以“軟件即服務”(SaaS)的方式提供，這就意味著由軟件供應商而非客戶來維護底層基礎設施。但是McKeon- White認為，客戶應該安排一到兩個人員來進行持續的優化工作，無論是服務客戶、提高彈性、降低變更風險、更好的事件管理流程，還可以確保每一個協助解決問題的人都能獲得準確的信息，并理解正在進行的工作狀態。
Hjortkjaer認為，ITSM需要對用戶進行有關新流程的持續教育和培訓工作，尤其是在遷移至更先進的平臺時。這可以展示很酷炫的功能，以及ITSM可以對你日常工作產生的積極作用，從儀表板到報告到快捷方式……你可以通過很多方式設置自己的ITSM界面，以提升你的工作效率和日常使用體驗。
和許多IT活動一樣，服務管理要做到最好，需要圍繞業務需求進行設計，清晰明確溝通價值，不要制造長期的、隱藏的“技術債務”，并隨著時間的推移不斷完善管理機制。
本文翻譯自：https://www.cio.com/article/305067/5-itsm-hurdles-and-how-to-overcome-them.html
京公網安備 11010802036102號