ITSM（IT服務管理）建設通常被認為僅僅把幾個核心ITIL流程設計好，并通過工單系統來承載流程的審批和流轉即可。這種方式可能是大多數企業的最初做法，用于滿足運維管理的合規性需求，以確保工作過程有審批和記錄可查。在這種要求下，一個ITSM系統確實只要具備了提單、審批、處理等基本的流程功能就已足夠，相當于一個電子工單系統。

然而，隨著企業數字化轉型的深入，對IT運維和服務的效率要求日益提升。如果企業繼續沿用傳統的工單系統思維來構建ITSM，僅僅考慮合規而沒有兼顧效率，那么長遠來看容易陷入比較被動的局面。因此，如何在建設初期就打好ITSM的基座，能靈活應對未來業務側數字化轉型不斷發展所帶來的挑戰就非常重要了。

本文將介紹什么是平臺化思維，以及如何在ITSM中應用平臺化理念，以更好支撐數字化時代下的服務管理建設。

01. 關于平臺化思維

1）什么是平臺化思維？

通俗來講，平臺化思維就是在構建業務場景之前，先把“舞臺”搭好，而不是一開始就堆場景功能。平臺應該具備兩個核心能力：

• 允許業務場景橫向擴展，而不需侵入到系統核心代碼。
• 支持將公共能力抽象到下層，供上層場景復用。

實際上，這種理念并非新穎獨特，是相當常見的。操作系統、PaaS、業務中臺等，各種新名詞背后本質上都是同樣的邏輯，也就是軟件工程中經常提到的“高內聚、低耦合”的設計原則，用于構建模塊化的、可維護性和可擴展性更高的軟件系統。

2）ITSM為什么要平臺化？

① 系統復雜度因素

如果一個軟件系統所需承載的業務不復雜，功能很簡單，那當然不需要考慮“平臺化”這個事情。過往ITSM建設的復雜度在于管理規范的建立和落地，而不在工具系統。也就是如何基于ITIL實踐來設計貼合自身管理訴求的流程，并能夠很好落地運轉，這是管理者頭疼的問題。咨詢團隊會給出大量的文檔和規則，而這些大部分并不需要落地到系統中。對ITSM工具的要求更多是類似工單系統，有提單、有記錄，能滿足合規審計即可。所以過往很多企業甚至沒有ITSM系統，僅僅是線下紙質或者在類似OA等具備流程功能的系統上跑運維流程也問題不大。整體來說，ITSM工具的要求通常是簡單的，復雜度并不在這里。

數字化時代下，不僅業務側需要積極推進數字化轉型，運維側也同樣面臨著轉型的迫切需求。業務系統架構正逐漸趨向敏捷化，而在各類互聯網服務的沖擊下，員工對于工作的認知和審美標準也悄然發生了轉變，這無疑進一步加速了運維側的轉型步伐。最簡單的例子是，難道你的系統還不支持移動端嗎？那簡直是不可思議。ITSM作為運維管理的重要部分，其數字化轉型也是非常重要的，最新的行業實踐ITIL4、VeriSM等的到來也印證了這一點。

所以，在IT運維數字化、敏捷化、自動化、智能化的趨勢下，ITSM工具系統不僅變成了剛性需要，而且建設的復雜度遠比過往要高很多。那么，在構建百層的高樓大廈之前，相應平臺的基座是不是得先建設好？

② 甲乙方協同因素

甲乙方一直存在一個矛盾，乙方作為服務的提供方，更希望標準化交付。甲方作為服務的消費方，更希望個性化服務，這是顯而易見的。尤其ITSM這類管理型軟件更為明顯，每個企業有不同的發展階段、團隊文化和管理訴求，雖然有類似ITIL這樣權威最佳實踐的指導，但細節是千差萬別的，因此也帶來了很大協同建設的挑戰。

為滿足甲方個性化訴求而定制的軟件版本，會在后續難以跟隨軟件的主版本進行持續升級換代。且不談功能更新的復用，當出現一些疑難缺陷問題，雙方投入的維護成本都是很高的，如：舊版本可能存在一個嚴重的缺陷隱患，當這個問題出現時，乙方需要投入重復的成本去修復它。即使甲方無需為此缺陷的修復付費，也會為此帶來業務上、用戶滿意度上的損失。無論如何，最終的結果大概率是雙輸的。

所以，我們提出以下建議：

從業務視角看：

02. ITSM平臺化架構參考

1）架構參考

通過前面的介紹，我們對平臺化理念和必要性有了一定的理解。那么這個平臺具體應該怎么搭建呢？如圖4所示，提供了一種架構設計的參考。這個架構的特點是不僅僅考慮了場景可擴展和能力復用，還引入了低代碼引擎能力，用以進一步提高平臺的靈活性。

• 平臺核心引擎能力：主要將“管理場景”高度復用的能力抽象到平臺下層，使得平臺上層的管理場景構建能夠更加敏捷、成本更高。
• 場景層與平臺層完全解耦，并提供應用模塊級的擴展開發框架，以實現復雜業務場景擴展或與第三方系統打通融合。
• 提供插件商店，作為持續沉淀海量集成插件，用戶按需自助安裝/卸載。

2）擴展模式

以上的架構設計最終強調的是平臺需要提供極致的可擴展性和靈活性，我們將這種特性抽象成3種模式，參考如下表格可以判斷一個ITSM平臺能力的成熟度。

03. ITSM復雜應用場景

如前面章節所述，ITSM平臺是為了實現更復雜的服務管理場景而生，那么我們通過幾個典型場景的前后對比來感受下。

1）運維請求服務化

基于ITSM平臺，我們可以將單一的請求流程進行場景化拆分，以結構化服務目錄的方式對外提供，這種轉變帶來的好處是運維服務一目了然，用戶也能夠更好地找到自己所需。這里的復雜度變化是由“單一流程”變化為“成千上百個流程”。

另外很重要的一點是，流程進行場景化拆分后，如圖7所示，存儲擴容申請需求的描述可以由非結構化變為了結構化，也為后續實現請求履行的自動化做好準備。這里的復雜度變化是由“手工填寫的簡單表單”變化為“集成度更高的復雜表單”。

2）工作流端到端自動化

所謂工作流的端到端，是指將某個工作目標實現過程中涉及的人與系統進行連接，以高效地完成最終價值交付。如果是工單系統思維，更多只是體現審批、處理等人工流程環節，如圖8所示，僅僅是滿足一種管理規范。

基于平臺之上實現端到端的流程，我們仍然以存儲擴容場景為例，如下圖9所示，此過程利用ITSM平臺的可擴展性、可集成性來將CMDB（獲取主機信息）、運維人員（填寫主機信息）、存儲系統（新建存儲實施）進行連接，端到端地完成存儲擴容的價值場景交付，避免“流程孤島”。這里的復雜度變化是由“幾個流程環節”變化為“數十個流程環節”。

3）管理策略數字化

管理過程不僅僅是固定的工作流程，還有人思考和決策。例如：變更管理的風險評估環節、事件管理的影響分析環節、請求管理的任務分派環節，都涉及運維人員在線下進行溝通、判斷和決策，而這類動作過往在過ITSM工單系統上是很難實現線上化的，或者說成本非常高，IT部門要么內部擁有開發團隊，要么依賴廠商高價定開，這樣不僅建設成本高，后續的持續維護成本也很高。

基于平臺化的架構，我們可以在低成本地擴展更多的能力組件，以承載這些管理細節。

以變更風險評估為例，我們可以將專家經驗沉淀到系統中，實現風險的自動計算。

以事件分派為例，我們可以將規則沉淀到系統中，實現事件處理的自動派發。

04. 總結

在數字化時代，服務管理的需求已經發生了顯著變化，對ITSM工具的要求也隨之升級。我們不再滿足于僅僅將審批和協同等少數動作進行線上處理，而是需要將服務管理過程中的更多環節，如任務分配、問題跟蹤、知識共享等，全面線上化，擺脫對傳統文檔和人力記憶的依賴，以提高效率、減少錯誤，并更好地適應快速變化的業務需求。

因此，如果繼續以工單系統的傳統思維，僅僅局限于滿足管理合規性的基本要求來構建ITSM，那么在未來，這樣的系統將難以適應業務側對效率和用戶體驗日益增長的需求。為了保持競爭力并應對這些挑戰，將平臺化理念融入ITSM建設中將是一個更為明智和前瞻性的選擇。這樣的做法能夠更好地支撐業務增長，提升運維效率，并為用戶提供更優質的體驗。