我過去很長一段時間都在做IT服務管理。說得直白一點很多團隊過得其實不像IT團隊更像消防隊。工單就是火警鈴鈴一響不管手頭在干什么都得先放下一切沖出去。白天剛撲完“賬號登錄不了”晚上又來了“報表卡住了”業(yè)務在群里圈人領導在電話里要人所有人都在救火火卻越救越多。后來我花了一個周末認真看了一遍ITIL4框架里的“服務目錄管理”實踐回來帶頭把服務目錄落地才真正把團隊從救火隊一點點變成了“服務專家”。這個轉變不是換了一套流程而是改變了整個IT團隊說事的語言、排優(yōu)先級的標準和跟業(yè)務對話的底氣。如果你也整天處于被動響應、需求靠人肉排期、出了事只能靠誰的嗓門大誰先修的狀態(tài)這篇文章就是為你寫的。1. 救火隊的代價為什么“響應夠快”反而讓團隊越陷越深1.1 救火隊的四張典型面孔先別急著否認對照一下你們團隊有沒有這幾張面孔。第一張面孔是所有需求聽起來都一樣統(tǒng)統(tǒng)是“幫我看看”。業(yè)務同事不會說“我需要申請一個數(shù)據(jù)庫只讀賬號請走標準流程”他們只會說“我這邊報表連不上了快點幫我看看”。至于這到底算故障、算請求、還是算變更沒人分類全靠接電話的人臨場判斷。第二張面孔是知識只存在于少數(shù)幾個“大神”腦子里。數(shù)據(jù)庫只有一個人能調(diào)網(wǎng)絡配置只有一個人熟中間件出了問題只有某位老工程師見過類似場景。這些“人形單點”平時是救火主力可一旦休假整個團隊就半癱。我見過一個真實的場景某天下午數(shù)據(jù)組的人直接沖到機房找網(wǎng)絡工程師說有張報表跑不出來當時網(wǎng)絡工程師正在處理財務的另一個問題報表的事情被晾了四十分鐘。事后一查所謂“報表跑不出來”只是權限過期兩分鐘就能解決。但因為所有事情混在一起誰也說不清優(yōu)先級一個低級問題最終演變成了“重大事故”。第三張面孔是優(yōu)先級的判定依據(jù)非常樸素誰的嗓門大誰先修誰跟IT關系好誰先被處理。業(yè)務部門會私下給IT打“內(nèi)部加急電話”導致真正影響核心業(yè)務的事件被排在后面。這不是某個人不負責而是整個團隊沒有一個客觀標準來回答“為什么先處理這個、后處理那個”。第四張面孔是沒有明確的交付承諾?？蛻魡枴岸嗑媚芎谩眻F隊只能說“我盡快”。這個“盡快”到底是兩小時還是兩天沒有定義于是業(yè)務只能反復催單。一旦催單成為常態(tài)整個團隊的時間就被碎片化溝通吃掉了真正干活的時間反而更少。這四張面孔疊在一起就形成了一個惡性循環(huán)響應越快業(yè)務越依賴臨時求助越依賴臨時求助團隊就越?jīng)]有時間做結構化的服務定義越?jīng)]有定義就越只能繼續(xù)救火。1.2 救火模式最大的成本你說不清自己在做什么救火模式最可怕的地方不是累而是所有人都說不清自己到底在做什么。我在做服務盤點的時候讓各小組回答一個問題你們?nèi)粘９ぷ骼镒畛＝拥降娜愓埱笫鞘裁唇Y果很有意思沒有一個小組能立刻答上來。大家的日常真的就是“接一個處理一個”接了三個月樣本都在工單系統(tǒng)里躺著但沒有人做過歸類。再往下問這些請求分別服務哪些客戶平均處理時長是多少依賴哪些系統(tǒng)出了問題該找誰升級答案幾乎都是憑感覺。說不清楚代價是具體的。我算過一筆賬一次“幫忙看看”的臨時求助看起來只是聊幾句但實際成本是發(fā)起人中斷手頭工作、接單人中斷手頭工作、可能還要拉上第三方一起看。如果三個人每人花三十分鐘接力解決一個原本兩分鐘的權限問題那這趟“幫忙”的實際投入遠超問題本身的體量。更不用說業(yè)務人員等待期間的閑置成本。這個階段在向領導匯報的時候也只能說“我們在保障系統(tǒng)穩(wěn)定”。可什么是穩(wěn)定穩(wěn)定到什么程度用多少資源保障的這些問題全都答不上來。預算和人力投入自然也就說不清楚IT團隊在決策層眼里就是個“成本黑洞”不透明、不可預期、無法評價。1.3 為什么服務目錄是第一步而不是第五步ITIL4給“服務”下過一個定義服務是一種促進價值共創(chuàng)的載體它通過促成客戶想要獲得的結果而讓客戶不必承擔特定的成本和風險。說得白話一點業(yè)務部門買賬的不是你的技術本身而是你幫他們搞定的結果。業(yè)務用戶真正關心的是“新員工入職當天就能登錄系統(tǒng)”而不是“AD域賬號同步有沒有成功”?？涩F(xiàn)實里IT團隊習慣用自己內(nèi)部的系統(tǒng)和動作去描述工作業(yè)務用戶只能靠猜。兩邊語言不通所有交互就只能退化成“幫我看看”。服務目錄管理這個實踐解決的就是這個“語言不通”的問題。它要求IT組織把面向客戶展示的服務做成一冊清晰的目錄每個條目都寫清楚你能得到什么結果、什么時間交付、達到什么標準、我負責什么、邊界在哪。這很像餐廳經(jīng)營?？腿丝吹降牟藛问恰凹t燒排骨”“清蒸鱸魚”后廚看到的是豬肉、蔥姜、燃氣、爐灶。菜單和后廚之間必須有一一對應的關系?？蛻舨粫χ髲N的食品原料下單IT團隊也不該讓業(yè)務直接面對你的基礎設施清單。服務目錄就是那張菜單把后廚能力翻譯成客戶聽得懂、點得著的菜。所以服務目錄不是所有問題解決之后再做的錦上添花它是讓IT從被動響應走向主動管理的第一個抓手。沒有它后面談SLA、談服務改進、談成本核算都像是沒有地基的樓。2. 放在桌面上談先把“客戶看得懂”和“團隊接得住”對齊2.1 服務目錄不是一張Excel表而是一份契約我發(fā)現(xiàn)一個很普遍的誤解提到“服務目錄”大家第一反應是弄一張共享表格把現(xiàn)有系統(tǒng)列一遍比如“OA系統(tǒng)、ERP系統(tǒng)、人力資源系統(tǒng)”各自是什么、找誰維護。這不是服務目錄這充其量是“系統(tǒng)和聯(lián)系人列表”。真正的服務目錄每一個條目都必須是一份可執(zhí)行的契約。它回答的是這幾個問題客戶需要什么樣的結果我要在多長時間內(nèi)交付交付到什么水平算達標客戶通過什么渠道獲取哪些需求不屬于這個服務范圍出了問題找誰舉個例子同樣一張表格里“OA系統(tǒng)”這四個字不是什么服務條目“員工日常辦公所需OA系統(tǒng)的賬號開通、權限調(diào)整與使用支持新賬號在1個工作日內(nèi)交付”才是一個服務條目。前者描述的是系統(tǒng)本身后者描述的是客戶能得到的結果。我所在的團隊在重新設計目錄的時候反復被這個原則校正。凡是描述里帶系統(tǒng)名稱但沒有客戶結果的全部打回重寫。這個過程很痛苦因為很多技術負責人習慣寫“負責XX系統(tǒng)的維護”而不是“保障XX業(yè)務結果在約定時間內(nèi)可用”。但這恰恰是整個轉變的關鍵。2.2 一個服務條目里到底該寫什么能落地的字段模板基于我們的實操經(jīng)驗一個成熟可靠的服務條目至少要包含下面這些字段。我以“員工入職/離職辦理”這類高頻服務為例給出一份可以直接套用的模板。字段說明示例服務名稱業(yè)務視角可讀不出現(xiàn)內(nèi)部系統(tǒng)代號員工入職/離職IT服務服務描述一句話說清服務達成的結果在規(guī)定時限內(nèi)為新員工開通賬號與設備為離職員工回收權限并歸檔數(shù)據(jù)服務對象明確哪些客戶可以使用全體員工、人力資源部門服務級別響應時長、解決時長、交付時限標準請求1個工作日完成賬號開通緊急賬號4小時完成獲取方式自助入口、電話、郵件等服務臺門戶提交“員工入職/離職”申請單排除項哪些內(nèi)容不屬于本服務范圍不含電腦采購預算審批、不含外部線路中斷升級依賴項需要哪些底層組件和上游服務支撐AD域、郵箱系統(tǒng)、辦公設備庫、人力資源系統(tǒng)責任角色服務Owner、交付團隊、升級路徑服務Owner基礎設施負責人交付團隊服務臺升級二線系統(tǒng)組成本歸屬是否計費、如何分攤按人均年度結算不單獨計價這個模板看著簡單落地的時候最難的是“排除項”。業(yè)務用戶申請賬號的時候會很自然地把“幫我裝個特殊軟件”“幫我把電腦內(nèi)存升個級”也塞進同一個工單。如果服務描述里沒有排除邊界這類需求就會稀里糊涂地接進來最后沒人負責成了一筆糊涂賬。還要注意的是語言。描述里千萬不要出現(xiàn)“AD域賬號同步失敗”“數(shù)據(jù)庫連接池溢出”這類技術黑話要用“登錄系統(tǒng)”“打開報表卡頓”這種結果型語言。技術細節(jié)留給內(nèi)部的交付步驟去寫面向客戶的部分必須讓客戶一眼看懂。2.3 業(yè)務服務目錄和技術服務目錄別讓業(yè)務去翻你的機器ITIL4里會把服務目錄分成兩個視角業(yè)務服務目錄和技術服務目錄。這兩個東西的讀者完全不同。業(yè)務服務目錄是給業(yè)務用戶看的按“客戶想要的結果”組織比如“員工入職/離職辦理”“辦公終端支持”“數(shù)據(jù)報表查詢”。平時用戶登錄門戶看到的就是這個它必須簡潔、友好、能夠直接下單。技術服務目錄是給IT團隊內(nèi)部看的按“支撐業(yè)務服務的技術組件與動作”組織比如“AD域賬號同步”“郵件系統(tǒng)集群維護”“備份任務執(zhí)行”。一線二線人員在日常運維里看的是這個。兩者之間必須保持映射關系。一個業(yè)務服務條目通常由多個技術服務條目、多個技術組件、多個操作活動共同支撐。我舉個例子。業(yè)務條目“員工入職/離職辦理”在技術視角下至少拆成AD域賬號開通、郵箱創(chuàng)建、協(xié)同辦公軟件組織架構調(diào)整、設備登記與發(fā)放、各類業(yè)務系統(tǒng)權限分配。其中任何一項出了問題都可能導致“入職IT服務”無法在規(guī)定時限內(nèi)交付。建立這個映射有什么好處兩個場景就能說明。第一事件診斷更快業(yè)務反饋“新員工登錄不了系統(tǒng)”一線人員通過映射表能迅速定位到底是AD域同步失敗還是郵箱創(chuàng)建卡住了不用再造輪子。第二變更影響分析更準底層某個組件要升級通過反向映射能算出這次變更會影響哪些業(yè)務服務、哪些客戶群這是變更評審里非常關鍵的一環(huán)。沒有這個映射每次出問題都像在黑箱里撈魚。3. 從0到1落地服務目錄一次預謀已久的“破墻”行動3.1 盤點先看看手里到底有什么牌真正動手做服務目錄之前先要回答一個殘酷的問題我們手里到底有哪些服務很多團隊對這個問題心里沒底因為服務就像暗物質(zhì)一直存在但沒人見過全貌。我建議的做法是把各個支持團隊負責人拉進一間會議室開一次“服務盤點會”。網(wǎng)絡、基礎設施、應用運維、數(shù)據(jù)、安全一個都不能少。讓每個人獨立回答五個問題你這邊日常接到最多的三類請求或事件是什么這些請求和事件服務的客戶群是誰你對外承諾過時限嗎哪怕只是口頭承諾實際做到?jīng)]有這些服務依賴哪些關鍵系統(tǒng)和供應商哪些工作其實根本不該由你來做這些問題足夠暴露出大量“隱藏服務”。我盤點的時候就發(fā)現(xiàn)很多團隊在默默承接一些不屬于任何流程邊界的活兒比如幫某個業(yè)務部門手工修復錯亂的數(shù)據(jù)、幫領導臨時導出一份口徑奇怪的分析報表。這些工作不一定都要進服務目錄但至少要擺到臺面上讓大家意識到“資源是被這么耗掉的”。盤點的產(chǎn)出物是一份“候選服務清單”。先不管格式漂不漂亮把名稱、客戶群、頻率、耗時、依賴組件列出來即可。這一步最忌諱追求完美因為盤點本身就是在給下一步設計提供素材。3.2 設計三層結構的服務目錄盤點結束之后就是歸類與設計。我們最終采用的是三層結構服務族、服務、服務項。第一層是服務族對應業(yè)務視角的大類比如“終端與辦公服務”“賬號與權限服務”“數(shù)據(jù)中心與基礎設施服務”“應用系統(tǒng)運維服務”。這一層的數(shù)量別太多六到八個足夠目的是讓高層和客戶能快速建立全局觀。第二層是服務也就是可以對外訂購、可以承諾SLA、可以獨立評價的條目。比如在“賬號與權限服務”下面可以放“員工入職/離職IT服務”“內(nèi)部系統(tǒng)賬號申請服務”“外部合作伙伴賬號服務”等。第三層是服務項是團隊內(nèi)部執(zhí)行層面的動作和技術任務比如“AD域賬號開通”“郵箱創(chuàng)建”“組織架構同步”。這一層不需要面向客戶公示但它是服務交付的底層支撐。三層結構解決了一個很實際的問題不同角色需要不同的抽象層級。高層領導不需要看到幾十上百個具體條目業(yè)務用戶只需要在服務族里點到自己能下單的那一項一線團隊則需要落到第三層去執(zhí)行。如果只有兩層業(yè)務層面會淹死在技術細節(jié)里執(zhí)行層面又找不到可落地的指令。我還用一個簡單的表格來支撐設計討論層級讀者典型數(shù)量示例服務族高層領導、業(yè)務部門負責人6-8個終端與辦公服務服務業(yè)務用戶、服務臺20-50個員工入職/離職IT服務服務項IT二線團隊、運維執(zhí)行100-300個AD域賬號開通這個數(shù)量級只是參考核心邏輯是每一層都有自己的讀者和用途層級之間的歸屬關系必須清晰且穩(wěn)定。3.3 流程配合服務目錄要和請求管理、事件管理打通服務目錄如果只是掛在門戶上的一張展示頁那它本質(zhì)上還是一件“裝飾品”。真正讓它發(fā)揮作用的是和其他服務管理實踐一起形成閉環(huán)。首先是請求管理。服務目錄里的每個條目都應該對應請求管理里的一個工單模板。用戶從門戶找到“員工入職/離職IT服務”點進去之后自動帶出這個服務的申請表單不需要重新選擇分類、描述問題。這樣既降低了用戶的操作門檻又保證了工單數(shù)據(jù)服務的口徑一致。然后是事件管理。事件工單里至少要有一個字段叫“影響的業(yè)務服務”。一線人員接單后第一件事不是急著問“你怎么操作的”而是先選“這個報錯影響了哪個業(yè)務服務”。這個字段一旦填起來服務目錄的數(shù)據(jù)基礎就有了某個業(yè)務服務這個月被事件影響了幾次、平均恢復時長多少全都能統(tǒng)計出來。變更管理同樣繞不開服務目錄。每次變更評審的時候變更單里應該寫明“本次變更會影響目錄中的哪些服務條目”。這會讓變更對業(yè)務的影響變得清晰可見而不是只停留在技術層面說“我們要升級一個組件”。我見過太多變更上線后業(yè)務毫無感知結果半夜炸了才被發(fā)現(xiàn)原因就是變更評估階段根本沒有關聯(lián)服務目錄。這三個流程一旦和服務目錄接上目錄就不再是靜態(tài)清單而是一個每天被工單數(shù)據(jù)持續(xù)喂入的活系統(tǒng)。3.4 試點與上線為什么我建議先放在一個服務上服務目錄是改變IT團隊和業(yè)務交互方式的變革我強烈建議先挑一個服務試點而不是一次性把整個目錄全面鋪開。否則極有可能陷入一個典型的失敗場景所有條目同時上線用戶找不到入口團隊也接不住新流程負面反饋鋪天蓋地最后只能灰溜溜退回去。我選擇試點的服務是“賬號與權限申請”。理由很簡單頻率高、路徑清晰、業(yè)務價值能很快被感知。幾乎每個部門每個月都會有人申請新賬號或者調(diào)整權限它不是一個“一年碰一次”的冷門服務而是能天天被用戶使用的入口。試點的操作路徑大概是這樣的把“賬號與權限申請”的服務條目、SLA和責任矩陣先定下來在服務臺門戶上配置這個目錄條目和對應的申請表單同時保留原來的臨時應急通道對服務臺人員和一、二線團隊做培訓重點是告訴他們工單進來之后怎么歸類、怎么計時、什么情況走升級跑上兩周每天記錄幾個關鍵數(shù)據(jù)用戶能不能自己找到入口、平均響應時間、平均解決時間、有多少工單因為分類不清被退回復盤數(shù)據(jù)調(diào)整條目描述和流程再把整個服務族慢慢擴展上去。試點最大的價值是允許你以較小的代價暴露問題。我們當時就發(fā)現(xiàn)不少用戶提交申請時根本說不清楚自己需要的是“新增賬號”還是“調(diào)整權限”表單里的必填字段也沒有引導清楚。這個問題如果一次性鋪到全目錄光是解釋成本就夠團隊喝一壺的。3.5 工具選型表格、ITSM平臺還是自研門戶很多人在啟動服務目錄時第一句話就問“用什么工具”。我的建議是先別急著買系統(tǒng)。先想清楚階段目標再選工具。我們當時經(jīng)歷了三個階段。第一步用在線表格和知識庫頁面做盤點把服務條目理清楚。第二步上了服務臺門戶的功能先在一個試點服務上跑通“目錄-工單-SLA”聯(lián)動。第三步隨著條目增多、考核要求細化才發(fā)現(xiàn)試用期的表格工具扛不住了沒法和工單、SLA數(shù)據(jù)打通才開始認真評估正式ITSM平臺。三種主要方案的實際體驗如下方案優(yōu)點缺點適合階段在線表格/知識庫頁面零成本、上手快、靈活調(diào)整沒有工單流轉、無法自動計算SLA、權限管理弱服務目錄起步期、條目數(shù)量少、主要是梳理思路商業(yè)ITSM平臺目錄和工單、SLA、資產(chǎn)自動聯(lián)動開箱即用價格不低、需要配置定制、流程固化中大型團隊、有明確SLA和審計要求的正式運行階段自研門戶流程引擎定制靈活、能和無縫嵌入現(xiàn)有業(yè)務系統(tǒng)開發(fā)成本高、維護工作量大、生態(tài)弱大型團隊、有專門平臺研發(fā)力量、定制需求強烈這里要提醒一句如果直接買一套商業(yè)ITSM平臺然后把所有服務條目一次性灌進去大概率會得到一個“僵尸目錄”。系統(tǒng)是好系統(tǒng)數(shù)據(jù)卻是拍腦袋填的沒人維護也沒人敢承諾覆蓋的條目。順序應該是先有對服務的清晰定義再有系統(tǒng)支持而不是買系統(tǒng)來逼著大家定義服務。4. 服務目錄上線之后才是真正的“服務專家”考驗4.1 SLA的設計不是越嚴越好而是靠譜服務目錄上線后SLA就成了所有話題里最燙手的一個。我第一次牽頭定SLA的時候犯過一個典型錯誤為了讓目錄顯得專業(yè)恨不得每個條目都寫上“99.99%可用性”“15分鐘響應”。寫完自己都心虛因為團隊根本達不到結果第一個月就被打臉。后來總結下來的經(jīng)驗是SLA設計要遵循幾個原則。第一分類分級。不能所有問題一個指標。我們按照業(yè)務影響把請求和事件分成四級P1是核心系統(tǒng)不可用業(yè)務整體停擺P2是主要功能受損有臨時規(guī)避方案但業(yè)務受影響明顯P3是局部功能異常影響少數(shù)人P4是標準服務請求和一般咨詢。不同級別配不同的目標和處理路徑。第二指標要少而準。別搞二十個指標聚焦在響應時間、解決時間和可用性上就夠了。指標一多采集和解釋成本會把團隊淹沒。第三必須定義清楚計時的起點和終點。響應時間從哪里開始算是從工單提交開始還是從派給一線團隊開始解決時間的終點是“系統(tǒng)恢復可用”還是“用戶確認接受解決方案”這些細節(jié)不定義清楚考核時一定打架。我見過有團隊花了半天爭論一張工單算不算“及時響應”就是因為起點定義模糊。第四可用性要和業(yè)務時段綁定。不要一刀切承諾“7×24小時可用”要看業(yè)務真正需要什么時段。內(nèi)部系統(tǒng)如果只在工作日上午八點到晚上十點使用那可用性考核就應該按這個窗口來算而不是拿全星期去衡量。否則一次凌晨的自動升級就可能導致整個月的可用率失守。一個相對務實的SLA表可以是這樣的優(yōu)先級響應目標解決目標典型場景P115分鐘響應4小時內(nèi)恢復或臨時規(guī)避核心系統(tǒng)不可用影響全部用戶P21小時響應下一個工作日內(nèi)解決主要功能受影響有規(guī)避方案P34小時響應3個工作日內(nèi)解決局部功能異常影響少數(shù)用戶P48小時響應5個工作日內(nèi)解決標準服務請求、賬號開通、權限調(diào)整這套指標不是拍腦袋定的而是從歷史數(shù)據(jù)里篩出來的。盤點工單系統(tǒng)里過去三個月的解決時長取個中位數(shù)再加一點余量讓它“跳一跳才夠得著”。先做到再逐步收緊才是可持續(xù)的路。4.2 別讓工單量成為KPI的“毒藥”服務目錄上線之后團隊負責人很容易盯著一個數(shù)字工單量。仿佛工單變多了就是壞事工單減少了就是服務變好了。這個想法極具誤導性。工單量上升很可能是因為服務目錄做得好。業(yè)務用戶終于知道該從哪里申請、申請入口足夠方便于是原來在線下偷偷解決的需求都愿意走正規(guī)通道了。這明明是成效卻被當成問題來治理。反過來如果考核團隊“減少工單”他們會想盡辦法讓用戶不來提單甚至用桌面溝通、微信群聊離線解決。工單數(shù)字好看了服務的可見性和合規(guī)性全沒了出了事連個記錄都沒有。我后來更關注三個指標。第一個是服務目錄條目覆蓋率。統(tǒng)計一下過去一個月的高頻服務請求里有多少比例能通過服務目錄找到對應的標準入口。這個比例越高說明“菜單”越貼合真實需求如果大量高頻請求入口找不到說明目錄該補項了。第二個是首次解決率。一線服務臺人員在第一次接觸工單時就能解決的問題所占比例。這個指標衡量的是知識復用和一線能力而不是轉手速度。第三個是SLA達成率而且一定要按服務和優(yōu)先級分層看。只看一個綜合達成率沒有意義因為很可能P1拉高了整體數(shù)據(jù)P3、P4卻在持續(xù)失守。分層看才能暴露具體哪個服務、哪個級別的問題。指標怎么算為什么值得關注服務目錄條目覆蓋率高頻請求中可通過目錄自助發(fā)起的比例檢驗目錄是否真實貼近業(yè)務需求首次解決率一次接觸即解決的工單比例檢驗一線能力和知識復用水平SLA達成率按服務/優(yōu)先級分層各服務各自級別下的達標比例檢驗具體服務的交付穩(wěn)定性還要提醒一句指標要設“合理區(qū)間”不是越高越好。比如首次解決率高得離譜就要警惕是不是服務臺人員在人工代錄工單或者業(yè)務人員干脆私下聯(lián)系二線“刷臉”解決。數(shù)字反而不真實。4.3 讓目錄活起來評審節(jié)奏與知識庫聯(lián)動服務目錄最怕的就是上線之后躺在那里吃灰。它必須像一套活物一樣被定期維護、定期評審。我們當時的節(jié)奏是這樣安排的。每個月做一次數(shù)據(jù)評審把各服務的SLA達成率拉出來凡是低于80%的服務逐個分析原因到底是SLA定得不合理還是團隊支撐能力不足。每個季度做一次目錄評審邀請各服務負責人和業(yè)務關鍵用戶一起把目錄條目過一遍有沒有新增的重復請求有沒有已經(jīng)停用的服務還在里面占位子有沒有條目的描述和現(xiàn)實脫節(jié)了該合并的合并該下線的下線。知識庫聯(lián)動這件事是讓目錄從“入口”升級成“專家”的關鍵。每個服務條目下面掛上知識文章比如常見問題的自助排查步驟、已知問題的臨時方案、常見報錯截圖和解釋。一線服務臺在處理事件時直接從這個條目的知識文章里檢索答案能在一線解決掉大量簡單問題。我印象很深的一次服務目錄上線三個月后一個新的服務臺同事接到一個“共享盤訪問不了”的工單。放在過去他大概率會直接轉給二線存儲團隊然后等二線排隊處理。但因為目錄條目下掛了一篇“共享盤訪問異常排查指南”他照著指南一步步看發(fā)現(xiàn)用戶的電腦沒有連接內(nèi)網(wǎng)認證鏈接成功后問題直接解決。那一單沒有轉手十分鐘內(nèi)關閉用戶給的滿意度評分是滿分。這個場景就是我理解的“服務專家”不是某個技術大神的個人能力而是整個團隊通過目錄、知識庫、流程把專業(yè)能力沉淀下來讓每一個接觸用戶的人都能表現(xiàn)得像專家。5. 五個讓服務目錄“白做了”的坑我?guī)缀跞冗^5.1 坑一目錄一旦上線就成了“僵尸文檔”我們第一版服務目錄上線的時候聲勢還是挺大的會議室里掛了大屏幕各部門都派了代表來參加宣貫。結果三個月后我打開目錄一看里面至少兩個系統(tǒng)已經(jīng)停用下線了還有三個條目的負責人早就換了人。目錄完全沒有更新成了一具漂亮的僵尸。后來我們指定了專人擔任服務目錄負責人并且把更新權限和評審節(jié)奏固化下來任何系統(tǒng)下線變更完成后必須同步檢查服務目錄中的關聯(lián)條目并更新狀態(tài)。服務目錄不是一份靜態(tài)文檔它是有生命周期的要有人對它負責。5.2 坑二照抄行業(yè)模板不以真實需求為準第二版服務目錄我參考了一份非常完整的行業(yè)模板里面分了十個服務族、四十多個服務條目每個都寫得很工整。結果業(yè)務用戶根本不買賬因為在他們的認知里IT只有三件事賬號、網(wǎng)絡、電腦。那些漂亮的分類和術語對他們來說全是噪音入口多了反而不知道點哪個。后來我把高頻工單數(shù)據(jù)全部拉出來按真實需求重新歸類命名并請業(yè)務部門的代表一起參與起名字。目錄的條數(shù)從四十多個砍到了二十幾個但用戶找到相應用入口的路徑明顯短了。模板可以借鑒但一定要拿自己的數(shù)據(jù)做底稿。5.3 坑三邊界切得太細一個動作就建一條目有個同事在設計“共享文件夾服務”的時候把“創(chuàng)建共享文件夾”“修改共享文件夾權限”“刪除共享文件夾”拆成了三個獨立服務條目。看起來邏輯清晰但客戶的實際需求往往是“我要和這個團隊共用一個文件空間”他根本不確定自己到底該選哪一個結果每個入口都點一遍試試。這個問題的本質(zhì)是把“客戶想要的結果”錯當成了“內(nèi)部執(zhí)行動作”。正確的做法是對外一個條目“共享文件夾服務”描述為“創(chuàng)建共享空間并管理團隊訪問權限”對內(nèi)再拆成創(chuàng)建、變更權限、刪除三個執(zhí)行項。入口給客戶一個動作留在內(nèi)部。5.4 坑四SLA寫得太猛寫完不敢拿出來我最早起草SLA的時候滿腦子想著“寫嚴一點顯得專業(yè)”于是給核心系統(tǒng)寫了“99.99%可用性”給P1事件寫了“15分鐘響應、10分鐘現(xiàn)場到達”。簽完字的那周正好趕上專線運營商光纜被外部施工挖斷客戶那邊業(yè)務斷了三個多小時。那一個月所有SLA達標率全線飄紅團隊被業(yè)務部門追著開了三次復盤會信心幾乎打沒了。真正的SLA應該是基于數(shù)據(jù)的不是基于理想的。先拿歷史記錄算實際水平定一個比現(xiàn)狀稍緊的目標持續(xù)改進后再逐步收緊。承諾一個不敢兌現(xiàn)的SLA比沒有SLA更傷信任。5.5 坑五責任矩陣不明確目錄里寫“負責人”等于沒寫服務目錄每個條目都會寫“負責人”但如果不把責任分到具體層級這個字段就只是擺設。我們早期有一個條目只寫了一線服務臺結果出了問題一線把它傳給網(wǎng)絡組網(wǎng)絡組說是安全策略問題安全組又說是軟件配置問題繞了一大圈又回到服務臺?？蛻粼谥虚g除了等待什么都做不了。后來我們規(guī)定每個服務條目至少要寫明三層角色服務Owner對最終交付結果負責交付團隊對具體動作負責升級路徑明確超過SLA時限后的處理渠道。責任只要模糊一寸執(zhí)行就會混亂一丈。最后再說一點個人體會。我做服務目錄管理這件事最直接的收獲不是那張漂亮的清單而是團隊第一次可以理直氣壯地對業(yè)務說“這個結果我們負責什么時間給到標準是什么如果做不到我們會告訴你補救方案?！蹦苷f出這句話你才算真正從救火隊變成了服務專家。如果這篇文章能讓你少走幾個我踩過的坑那這些年的手忙腳亂也算沒白費。