作者：秦鴻林 紫羚雲 CGO兼SaaS負責人

筆者在最近發表的一篇文章《大中型企業實施IT服務管理（ITSM）的幾大難題》中，談到的“十一個”難題的第一個就是“關鍵干係人的支援不夠”，之後又寫了一篇關於ITSM的價值的文章《數字化時代，如何認識和對齊ITSM價值》，希望是幫助大家認識ITSM的價值，對完成專案的立項有幫助。其實在專案立項時，大家最終對問題和價值會比較容易達成共識，但是如何做會有一些爭論。

具體來說就是兩個問題：

能否用現成的OA來做？不都是流程嘛。

能否利用低程式碼平臺來構建ITSM，來替代已經商業化的ITSM產品呢？

回答第這兩個問題，我們就需要理解什麼是ITSM、什麼是ITIL、什麼是低程式碼平臺、什麼是OA？他們與OA、低程式碼有什麼聯絡與區別。

一、首先，就幾個概念做一個簡要的說明：

OA

OA，即辦公自動化（Office Automation，簡稱OA），是將現代化辦公和計算機網路功能結合起來的一種新型的辦公方式。現代意義的OA系統，指的是利用先進的計算機技術，網路通訊技術，處理單位內部的工作，實現協同審批，輔助辦公管理，實現辦公效率的提高和管理規範化的軟體系統。

ITSM

ITSM （IT Service Management，IT服務管理），包含一組策略和實踐，這些策略和實踐可用於為終端使用者實施、交付和管理 IT 服務，以滿足終端使用者的既定需求和企業的既定目標。

在此定義中，終端使用者可以包含員工、客戶或業務合作伙伴。 IT 服務可以包含組織提供給使用者使用的任何硬體、軟體或計算資源，從公司膝上型電腦、軟體資產或 Web 應用程式，再到移動應用程式，用於開發或其他服務的虛擬伺服器、計算、儲存、網路和基礎設施等。

ITIL

資訊科技基礎設施庫（IT Infrastructure Library，簡稱ITIL）由英國政府部門CCTA在20世紀80年代末制訂，現由英國商務部OGC負責管理，主要適用於IT服務管理（ITSM）。ITIL是實施和記錄 ITSM 的最佳實踐指導框架，已經得到廣泛使用。 從ITIL V2進入國內，到2019年釋出的ITIL 4，已經兼顧到了穩態和敏態，涵蓋了 34 個 ITSM實踐（比ITIL V3的26個有所增加），其中通用管理實踐14個，服務管理實踐17個，技術管理實踐3個。

ITIL非常詳盡，但組織的 ITSM 專案不需要實施其涵蓋的所有內容，組織只需挑選自身需要的 ITIL 流程和實踐。

ITSM軟體

ITSM（IT Service Managemen）軟體是一套幫助企業對IT系統規劃、研發、實施和運營進行有效管理的高質量的解決方案產品，是將ITSM的先進理念進行固化和落地實施的工具。

在IT運維管理中發揮的作用是提供一套良好的流程機制，能夠將運維部門中的人與人、人與工具很好的協同起來，以控制變更風險、快速響應事件、排除系統隱患、持續最佳化改進，從而支撐業務連續性的目標。

目前，市場上至少上百種 ITSM 軟體工具，國際上知名的ITSM代表有ServiceNow、BMC Remedy等，國內則是以紫羚雲ITSM為代表。

總結一下《數字化時代，如何認識和對齊ITSM價值》這篇文章裡講到的實施ITSM的價值有：

為CIO服務，讓CIO的管理決策有依據，讓科技運營更有序，讓生產更安全；

IT基礎設施和數字化產品的運維，那保障高可用及業務連續性；

建立面向共享式服務運營中心，提升使用者滿意度；

統一IT和業務部門的服務介面；

規範和固化IT服務管理流程；

降低系統的執行風險，管理成本和技術成本；

量化考核併為持續改進服務提供洞見。

二、其次，我們再看看ITSM與OA的區別：

三、最後，我們稍微總結一下，從更深層次和維度看看ITSM和OA的不同：

ITSM和OA本質上完全不同的東西，儘管都有流程，但是ITSM不僅僅只有流程，而且流程的表單定義和流程定義能力在多數的OA都有能力實現，但是應用理念、架構都不同。除此之外，ITSM和OA體現在流程之外功能模組層面頗為不同。

以紫羚雲ITSM產品為例：紫羚雲的ITSM實現了服務檯、事件管理、請求管理、問題管理、變更管理、釋出管理、知識管理、配置管理、服務目錄和排班管理、配置及資產管理等模組。這些模組大部分不能透過OA的表單和流程自定義能力來實現。比如比較常用的事件管理模組，實現瞭如下功能：

支援工單的多渠道發起，提供郵件、簡訊、移動端、PC端等9種報單方式；

工單應該記錄工單的來源、使用者、時間、現象、影響度、故障發生實體的配置資訊等相關要素，並對部分要素自動填充例如：提交人、提交部門、提交/登記時間、優先順序、中斷時長、關閉人、關閉時間等；

支援管理全過程：新建、歸併、分派（包括自動分派，轉派，二次分派）、回退、處理、審批、會籤、加簽、掛起、確認、關閉（多種方式）、升級（技術升級和管理升級2種策略）、作廢、強制辦結；

支援多維度條件查詢：型別、狀態、緊急程度、發起人等不同要素；

當工單的狀態發生變化時，對相關人員有相應的通知策略，並支援多種通知方式；

在工單的管理過程中，支援知識庫的預檢索，智慧知識推送並支援處理完成的工單自動沉澱到知識庫；

透過影響範圍、緊急程度等元素，支援相應演算法確定優先順序，根據優先順序制定相應策略（包含工單處理告警時長、提醒間隔時長、上報時間間隔等）；

支援與問題管理流程、變更管理流程、CMDB關聯，在觸發其他流程時自動建立工單並填充相應資訊；

處理過程中的所有關鍵點和操作需要記錄到系統中。

實現重大事件的生命週期管理等等。

這還只是事件管理，變更管理則更復雜，還有變更視窗，變更日曆的概念，在實施時，也可能涉及到和CMDB的聯動，則更為複雜，不是通用的低程式碼平臺可以實現的。

整合能力上，ITSM更多要整合IT管理相關的系統，例如：

服務檯需要和callcenter整合，實現來電自動彈屏和建單；

實現和IT管理相關的基礎監控、業務監控等監控系統的整合，實現告警資訊自動生成工單；

實現和自動化運維、DevOps、AIOps等實現整合，實現服務請求或變更的自動化執行，甚至是故障的自愈；

對於銀行等金融客戶，可能還需要和堡壘機的整合，實現變更管理、釋出管理流程和堡壘機的聯動；

和研發過程平臺整合。

這些對OA涉及的整合介面太多，而且還可能跨越辦公和生產網段，對於OA系統有些不堪重負，這些對於OA產品可能缺乏標準、內建的介面，對於OA廠家來說，可能也缺乏相關案例支撐。

另外，ITSM系統是IT或者說數字化部門的ERP、eHR系統，是“數字化”的數字化平臺，在IT部門單獨建設更可控，OA作為集團的協同門戶和流程協同平臺，不要攪和在一起為好！

筆者經歷的很多客戶，從中發現一個特點就是：大部分OA的Owner是行政部門或者IT部門的流程組，他們的技能更偏向於定義流程和業務架構層面，從精力和技能上，真不一定擅長建設基於ITIL思想的ITSM系統這樣的複雜的事情。

在下一篇《為什麼說OA和低程式碼平臺都不能代替專業ITSM（二）》，再來嘗試探討低程式碼平臺來構建ITSM是否可行的問題。

TAG: ITSMOA管理流程ITIL