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

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

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

01. 關于平臺化思維

1）什么是平臺化思維？

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

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

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

2）ITSM為什么要平臺化？

① 系統(tǒng)復雜度因素

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

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

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

② 甲乙方協(xié)同因素

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

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

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

從業(yè)務視角看：

自主建設或?qū)で蟮谌角?/span>，不應該被固定的供應商捆綁束縛。
因此，從市場需求和發(fā)展來看，ITSM也應該考慮平臺化的建設思路。

02. ITSM平臺化架構參考

1）架構參考

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

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

2）擴展模式

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

03. ITSM復雜應用場景

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

1）運維請求服務化

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

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

2）工作流端到端自動化

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

基于平臺之上實現(xiàn)端到端的流程，我們?nèi)匀灰源鎯U容場景為例，如下圖9所示，此過程利用ITSM平臺的可擴展性、可集成性來將CMDB（獲取主機信息）、運維人員（填寫主機信息）、存儲系統(tǒng)（新建存儲實施）進行連接，端到端地完成存儲擴容的價值場景交付，避免“流程孤島”。這里的復雜度變化是由“幾個流程環(huán)節(jié)”變化為“數(shù)十個流程環(huán)節(jié)”。

3）管理策略數(shù)字化

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

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

以變更風險評估為例，我們可以將專家經(jīng)驗沉淀到系統(tǒng)中，實現(xiàn)風險的自動計算。

以事件分派為例，我們可以將規(guī)則沉淀到系統(tǒng)中，實現(xiàn)事件處理的自動派發(fā)。

04. 總結(jié)

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

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