第4章 IT服務規劃設計

第4章 IT服務規劃設計

4.1 概述

規劃設計處于整個IT服務生命周期中的前端,可以幫助IT服務供方了解客戶的需求,并對其進行全面的需求分析,然后通過對服務要素(包括人員、資源、技術和過程)、服務模式和服務方案的具體設計,最終形成服務級別協議(Service Level Agreement, SLA),包括服務的內容、連續性、可用性、服務能力和服務費用等。
如果未進行有效的規劃設計,那么倉促而就的IT服務難以滿足客戶的真正需求,很可能造成客戶滿意度低下、IT服務可用性低、預算超支或IT系統功能喪失。
規劃設計的范圍不僅包括新的服務,還包括服務連續性保障、服務水平的滿足和對標準、規則的遵從,以及在服務生命周期過程中為了保持和增加服務價值所做的必要變更。

規劃設計的主要目的在于:

(1)設計滿足業務需求的IT服務。

(2)設計SLA、測量方法和指標。

(3)設計服務過程及其控制方法。

(4)規劃服務組織架構、人員編制、崗位及任職要求。

(5)識別風險,并定義風險控制措施和機制。

(6)識別和規劃支持服務所需的技術及資源。

(7)評估IT服務成本,制訂服務預算,控制服務成本。

(8)制訂服務質量管理計劃,以全面提高IT服務質量。

優秀的規劃設計會為IT運維服務、數據處理和存儲服務及運營服務帶來如下益處。

(1)減少總體擁有成本(Total Cost of Ownership, TCO):通過對人員、過程、技術和資源的規劃與設計,可實現有效的服務成本控制,并在成本上做出有效的分析。如果沒有實現規劃設計,那么突發的災難、意外的資源超標都會造成不可挽回的經濟損失。

(2)使新的或變更的服務的實施更便利:在傳統的組織中,一旦有了新的服務需求,許多重擔便壓在系統規劃與管理師身上,系統規劃與管理師除了對項目本身負責外,還需要大量的時間去分析與新的或變更的服務相關事宜,包括與其他組織的溝通等。有效的規劃設計方法將指導系統規劃與管理師從更全面的角度去思考這些規劃層面的事宜,提升效率。

(3)改進服務流程:規劃設計模塊中提供了有效的服務過程設計建議,為服務過程的改進奠定了基礎。

(4)服務執行更有效:緣于有效的整體規劃設計,服務的執行更明確,也意味著服務執行力更強。

(5)提升IT服務管理:指標不僅讓服務的執行更明確,對于管理者來說,績效考核也要有依據。這里不僅包括對人員的管理規劃,還包括對過程、技術和資源的管理規劃與設計。

(6)服務管理更有效:有了具體的方向和指導,服務管理除了具有明確的目標性外,還具備了可審計、可追溯、可改進、可視性等多重效率性提升。

4.2 IT服務規劃設計活動
4.2.1 規劃設計的活動

規劃設計流程中的主要活動包括:服務需求識別、服務目錄設計、服務方案設計(含服務模式設計、服務級別設計、人員要素設計、過程要素設計、技術要素設計、資源要素設計)、服務成本評估和服務級別協議設計。

整個規劃設計流程中的各項主要活動如圖4.1所示。規劃設計從服務需求出發,終點為設計出符合業務需求和成果的服務方案。在需求階段,客戶結合服務目錄的定義和自身要求,提出服務級別需求,服務供方根據服務需求,進行服務模式設計、服務級別設計、服務要素設計等關鍵活動,同時兼顧成本控制和定價,最終形成服務級別協議、運營級別協議和支持合同。

在這里插入圖片描述

4.2.2 關健成功因素

要確保規劃設計的有效實施,需充分考慮如下內容:
(1)確保規劃設計考慮全面,使規劃設計包含IT服務的所有活動及與業務相關的接口。
(2)當服務變更或補充規劃設計的任一獨立元素時,都要綜合考慮有關職能、管理和運營等層面的問題。
(3)明確重點,充分溝通。
(4)策劃、實施、檢查和改進(Plan-Do-Check-Act, PDCA)。

規劃設計是一個不斷循環的過程,服務供方在IT服務規劃設計過程中應對服務進行整體策劃,提供必要的人員、資源、技術和過程支持并實施服務內容,保證交付質量滿足SLA的要求,對IT服務規劃設計的過程和結果進行監視、測量、分析和評審,并實施改進,如表4.1所示。
表4.1 規劃設計之PDCA

目的內容
策劃對規劃設計過程進行整體策劃,提供必要的資源支持根據業務定位和能力,策劃針對特定服務對象的服務內容與安全要求,設定服務目標、服務模式、服務目錄;對服務資源進行規劃,建立相適應的指標體系和服務保障體系;策劃如何管理、審核并改進規劃設計內容和結果(包括SLA、OLA和UC),并建立內部審核評估機制
實施設計服務方案,保證交付產品的質量滿足服務需求與客戶就服務需求達成共識,明確SLA或質量要求;按照服務需求、標準和法律法規的標注進行規劃設計,確保規劃設計的過程可追溯和結果可計量;提交滿足服務需求的交付物
檢查檢查規劃設計的結果是否符合服務需求和質量目標按進度安排評審規劃設計過程交付物及相關管理體系,以確保其適宜性和有效性
改進改進規劃設計過程和交付方案的不足,以持續提升服務質量不斷總結經驗和教訓,修改和優化規劃設計過程和服務目錄;對不符合策劃要求的行為進行總結分析;對未達成的服務需求的指標進行調查分析;根據分析結果確定改進措施,制訂服務改進計劃

在進行規劃設計時,只有充分考慮上述內容,才會看到成效——客戶滿意度的不斷提升,IT服務穩定、實用性強,IT服務與業務之間便能建立真正的良性循環。

4.3 服務目錄管理

服務目錄是梳理服務產品和管理客戶期望的重要工具,是服務供方為客戶提供的IT服務集中式的信息來源,以確保業務領域可以準確地看到可用的IT服務及服務的細節和狀態,如圖4.2所示。
在這里插入圖片描述

服務目錄是公開的,不論是客戶還是服務供方都應該能方便地查閱這些資料,在某些場合下甚至會由一個專門的內部網站來完成這項任務。服務目錄一般會利用一些來自質量控制系統的信息和文檔(這些質量信息需要進行定期回顧),及時做出調整,以適應客戶或者業務的具體需求。

服務目錄定義了服務供方所提供服務的全部種類和服務目標,但是在很多情況下,由于涉及的內容很可能已經在其他文檔(如SLA)中被提及,為了避免文檔的重復,服務目錄往往不再單獨列出。

雖然不同的服務供方的服務目錄及相關文檔和方式會有所不同,但是有一個大家都應遵守的原則,即服務目錄要避免信息處理過程中產生的冗余,要得到妥善管理,而且方便查閱。

服務目錄主要有兩種:業務服務目錄和技術服務目錄。業務服務目錄包含提交給客戶的所有IT服務細節,并將其關聯到依靠IT服務的業務單元和業務流程,是客戶視角的服務目錄。技術服務目錄包含提交給客戶的所有IT服務細節,并將其關聯到提供給業務的必需的支持服務、共享服務、組件和配置項,支撐業務服務目錄,是技術視角的服務目錄,通常客戶不關注技術服務目錄。

4.3.1 設計服務目錄的目的

服務目錄設計的目的是為所有商定的服務提供單一、連貫的信息來源,并且確保所有獲準使用相關服務的人能夠知道這些信息。服務目錄管理中的核心信息的主要輸入,來自服務組合和通過業務關系管理(BRM)或服務級別管理(SLM)流程了解到的業務情況。

促使IT服務目錄制訂的原因有很多,其中最重要的一點是,它能促使IT部門與客戶之間建立起一種長期穩固的關系。實施一套正規IT服務目錄時,所獲取的總體效益會隨部門的不同而不同,潛在效益應包括:
(1)促進部門同外部及內部溝通。
(2)對業務要求和挑戰有更好的理解。
(3)能有效地把適當的成本分配給某個具體的業務部門、單位。
(4)服務供方能積極、有效地改變終端用戶的消費量及其消費行為。
(5)增強客戶的需求意識,提高IT服務供方的市場可視性。
(6)提高IT服務和流程的效率。
(7)把IT資源重新分派到核心業務系統中。
(8)降低服務提供的出錯率。
(9)降低IT部門的操作成本。

4.3.2 服務目錄設計活動

設計一套巧妙而有效的IT服務目錄需經過深思熟慮,因為這樣可以確定服務目錄應當包含哪些服務及特征,并分出優先級。IT服務目錄的設計一般按照如下步驟進行,這都需要與服務供方的總目標和服務能力相一致。
(1)確定小組成員:參與人員至少應包括需方業務代表、系統規劃與管理師、IT服務工程師,以確保制訂服務目錄時的視角是全面的。
(2)列舉服務清單:小組應當列出一個包括所有IT服務在內的清單,不管它們是否真的被包括在現有的IT服務內。
(3)服務分類與編碼:對服務清單中的內容,按服務對象的技術維度或服務性質維度進行分類,如硬件、軟件、環境、響應支持、例行操作、優化改善、調研評估等。
(4)服務項詳細描述:詳細描述各服務項包括的內容、價值、目標、服務級別指標、技術實現方法等。
(5)評審并發布服務目錄:服務目錄在經修改、評審、定稿后,就可正式在供方組織內部發布,作為服務交付和服務管理的基準。
(6)完善服務目錄:根據客戶服務需求或行業要求,繼續改進服務目錄,包括服務時間、服務方式、服務人員、服務定價等,并保持與需方服務需求或供方服務能力的一致性。

在服務目錄使用的過程中,如果服務需方的反饋結果與服務目錄有差別,可以有針對性地對服務進行選擇性修改,從而制訂正規的SLA。
不同的組織針對IT服務目錄的制訂成本、復雜性及實施難度會有所不同,這完全取決于最終存檔的服務目錄的服務項數量。因此,只有在服務目錄中的服務項逐一實施并被客戶認同之后,服務目錄的條款才能最終確定。

服務目錄包含眾多條款和變量,可以為IT組織和部門創造更多、更有意義的附加價值。以下是服務目錄中可能包含的一些變量及促進因素:
(1)對服務進行統一收費(如針對每個服務傳遞者、人員或業務單位)。
(2)確定服務使用費或基于服務能力的收費額(如根據服務呼叫數量來確定費用情況)。
(3)增加循環過程中服務消費的數量或單元。
(4)確定相似服務提供時的優先次序。
(5)獲取新的服務或添加附加客戶的流程及程序。

4.3.3 關鍵成功因素

(1)確保向需方提供的每個服務都是獨立的,而不是某個大服務的一部分。

(2)可以根據客戶的需求和內部情況,對服務內容進行控制和衡量。

(3)服務成本可以根據客戶需求的不同而進行改變。

(4)客戶容易認可和感受對服務成本有較大影響的服務。

4.3.4 參考實例

參考實例如表4.2所示。
表4.2 參考實例

服務代碼服務名稱服務內容服務描述服務方式服務時間服務級別
4020101網絡設備應急響應服務包括故障排查服務、設備維修服務、重大事件保障服務。通過該服務能有效地診斷并發現故障情況,及時定位故障位置,對故障進行處理,直到故障解決,快速有效地恢復網絡系統的正常運行故障排查:可提供各類網絡設備的故障排查及處理解決服務現場+遠程5X8
7X9
7X24
響應時間10/30分鐘,到達現場時間 2/4/8/24小時,故障解決時間4/8/24/48小時
4020102設備更換:可提供各類網絡設備及其配件更換服務現場5X8響應時間10/30分鐘,到達現場時間2/4/8/24小時,故障解決時間4/8/24/48小時
4020103重大事件保障:可提供警衛任務、節假日或其他重大任務時,指派網絡系統運維服務工程師到客戶指定現場進行值守,保證重大事件活動期間網絡系統的正常運行現場5X8
7X9
7X24
響應時間10/30分鐘,到達現場時間2/4/8/24小時,故障解決時間4/8/24/48小時
4020104網絡設備例行維護服務包括日常工作值守服務、巡檢服務、清潔服務。通過該服務能有效預防故障的發生,降低故障發生概率,大幅度提升網絡正常穩定運行的平均時間,提供更可靠、更及時的保障,延長設備使用壽命,節約資源成本巡檢:可提供網絡類設務告警信息及日志查詢和診斷、系統配置參數校對、風扇運行狀態檢查、設名運行狀態檢查、基礎環境溫濕度檢查等服務;巡檢過程中發現有故障設備,可及時進行備件更換恢復業務現場+遠程5X8響應時間10/30分鐘,到達現場時間2/4/8/24小時,故障解決時間4/8/24/48小時
4020105實時監測:可提供網絡設備安放基礎環境溫濕度等指標、設備運行狀態指標傳輸網絡拓撲連通性、出口帶寬、數據轉發速率設備溫度、設備硬件資源占用情況等性能指標的實時監測服務駐場+遠程5X8
7X9
7X24
響應時間10/30分鐘,到達現場時間2/4/8/24小時,故障解決時間4/8/24/48小時
4020106清潔保養:各類網絡設備的清潔及養護服務現場5X8響應時間10/30分鐘,到達現場時間2/4/8/24小時,故障解決時間4/8/24/48小時
4020107網絡設備優化改善服務包括隱患排查服務、性能優化服務通過該服務能升級設備軟件系統配置功能,精簡配置有效發揮網絡系統的最佳性能系統升級:可提供各類網絡設備的系統軟件版本升級服務現場+遠程5X8響應時間10/30分鐘,到達現場時間2/4/8/24小時,故障解決時間4/8/24/48小時
4020108性能調優可提供各類網絡設備的系統配置優化服務現場+遠程5X8響應時間10/30分鐘,到達現場時間2/4/8/24小時,故障解決時間4/8/24/48小時
4.4 服務級別協議
4.4.1 服務級別協議介紹

服務級別協議(Service Level Agreement, SLA)是在一定成本控制下,為保障IT服務的性能和可靠性,服務供方與客戶間定義的一種雙方認可的協定。
一個完整的SLA也是一個合法的文檔,包括涉及的當事人、協定條款(包含應用程序和支持的服務)、違約的處罰、費用和仲裁機構、政策、修改條款、報告形式和雙方的義務等。同樣,服務供方可以對客戶在工作負荷和資源使用方面進行規定。

運營級別協議(Operational Level Agreement, OLA)是與某個內部IT部門就某項IT服務所簽訂的后臺協議,OLA在IT內部定義了所有參與方的責任,并將這些參與方聯合在一起提供某項特別服務。各方就所提供服務的質量和數量等級達成一致。例如,如果SLA中包含了一個針對恢復某個具有高優先事件的總目標,則OLA中就應該包括針對整個支持鏈的每個環節的具體目標(如針對服務臺響應呼叫、進行事件升級的目標,針對網絡支持人員啟動調查和解決網絡相關事件的目標等)。OLA支持IT部門提供各種服務。

支持合同(Underpinning Contract, UC)是指組織與外部服務供應商之間簽訂的有關服務實施的正式合同,是SLA中的重要部分。如果IT服務不由內部部門提供,而由外部服務供應商提供,那么這一環節相當重要,因為SLA只是內部或對客戶的協議,不具有法律效力,UC則是與外部服務供應商或組織簽訂的合同,是正規的、具備法律效力的協議。從內容上看,UC主要由依據SLA的內容加上法律條文中的責任、權利和義務構成。

4.4.2 服務級別協議內容

服務級別協議框架如表4.3所示。

表4.3 服務級別協議框架

要素說明和示例
需方需方單位名稱
供方供方單位名稱
第三方第三方單位名稱
項目名稱IT服務項目全稱
生效時間協議生效時間
終止時間協議終止時間
服務簡介提供項目的背景,項目的目標和項目的重要性等
服務范圍如設備清單等
服務時間約定可提供服務的時間,需明確例外時間段以及對例外時間段提供服務的協商方式,如5X8、7X24等
服務受理渠道客服熱線電話,客服郵箱、網上問題提交地址等;如有必要可增加非工作時間服務通道及方式等
投訴渠道投訴熱線等
服務交付計劃啟動會時間、巡檢時間、總結時間等
服務交付方式現場交付要求,遠程交付要求等
服務交付內容例行操作、響應支持、優化完善、調研評估等具體服務交付內容
供方人員需明確參與服務的人員崗位、職責、姓名和聯系方式等,如客戶經理、系統規劃與管理師、信息技術支持工程師等
需方接口需明確接口服務的人員崗位、職責、姓名和聯系方式等,如系統規劃與管理師、責任工程師等
第三方接口需明確接口服務的人員崗位、職責、姓名和聯系方式等,如系統規劃與管理師、責任工程師等
供方服務流程故障申報流程、巡檢流程、升級上報流程等
第三方服務流程第三方支持流程等
服務交付成果需明確服務階段中需要提交的各類交付成果等,如故障報告、總結報告、巡檢記錄等
保密要求相關信息嚴禁透露,服務人員應簽署保密協議等要求
服務考核要求服務質量考核的時間周期、考核的關鍵要素、考核好壞對應的獎懲條款等
協議變更控制協議內容變更的流程和要求等
各方代表簽字供需雙方代表簽字,如需要第三方簽字,可增加簽字方;需提供姓名、職務和簽署時間等

參考示例如下。

本協議經過甲方: 乙方: 友好協商達成。
本協議涉及由乙方向甲方提供和支持的服務(服務名稱)。
本協議自 年 月 日起到 年 月 日止,有效期為 年。
服務描述XXX服務包括…(全面描述服務包括業務職能、功能、性能、容量和其他相關信息,用于描述該服務及其規模等)
服務時間描述議定的服務提供時間方面的描述(如7X24X365或周一至周五09:00~17:30等,如需考慮節假日等根據應用環境適當描述)
服務可用性議定服務時間內的可用性目標,通常以百分比表示,應規定計算周期、計算方法,通常采取統計服務不可用數據來計算不可用性,再得出可用性
服務可靠性議定計算周期內可容忍的服務中斷次數或平均故障間隔時間等,應定義“服務中斷”并描述如何對此監控和記錄
服務支持客戶支持評價指標特殊情況說明
描述如何聯系服務臺、服務臺可用時間、可用于提供支持的時間及在這些時間外要獲得幫助應該怎么做,定義 “響應”的具體方式(如電話反饋、發送響應確認信息等)議定可接受的響應時間性指標(如5分鐘內響應,響應及時率達到90%, 2小時內到達現場等)議定應考慮特殊處理的異常情況時,如惡劣天氣、需要借助第三方支持等,應做如何調整
投訴渠道描述投訴受理方式(如熱線、郵件、傳真等)、投訴升級流程等
服務交付描述服務交付方式(如現場交付、遠程交付等)、交付地點(交付地點的詳細信息)、交付物(如軟件、硬件、文檔等)
服務費用描述收費期、引入的收費方案文檔、收費公式、發票開具程序和支付條件等詳細信息
責任和義務描述服務各階段雙方各自應承擔的責任、各自責任限制(如甲過錯導致損失不應乙方承擔責任)、可免除責任(如不可抗力)、應履行的義務等
補償描述若服務目標未達到,將支付或返還的經濟賠償的詳細信息
服務報告描述服務報告內應呈報的內容、報送時間、報送頻率、報送范圍和分發方式等
審查描述對SLA和相關服務目標進行審查、審查頻率、修改方法和時間,可能涉及時間、對象、容量等
保密條款定義保密信息、非保密信息,議定雙方保密義務、保密條款的有效期限等
備注備注其他需要說明的信息
本協議每年將進行審查,如需變更應遵循本協議約定的變更管理流程。
簽署人:
姓名: 職位: 日期: 年 月 日
姓名: 職位: 日期: 年 月 日
4.5 服務需求識別

考慮提供一個新的IT服務時,首先需要了解客戶對于IT服務的需求。那么,站在客戶的角度來看,他們對于IT服務究竟會有什么需求呢?通過對客戶業務和IT服務需求的了解,可以劃分為可用性需求、連續性需求、能力需求、信息安全需求和價格需求;然后對IT服務進行具體的設計,包括連續性設計、可用性設計、能力設計、收費模式和定價、IT服務報告設計,最終形成IT服務方案。圖4.3描述了IT服務需求與規劃設計的關系。
在這里插入圖片描述

4.5.1 服務需求識別的目的

(1)了解客戶的基本需求,分析潛在客戶的不同需求,為IT服務方案設計打下基礎。

(2)了解客戶對系統可用性和連續性的需求。

(3)進行合理的IT服務資源配置。

(4)為預算IT服務成本、設計定價和收費模式奠定基礎。

4.5.2 服務湍求識別的活動
  1. IT服務可用性需求識別
    在進行可用性需求識別的過程中,要將客戶的業務需求轉化為IT可用性需求,內容如下。
    (1)IT服務不可用對業務的影響,即客戶可以承受多長的停機時間。
    (2)從業務角度分析,IT服務不可用(或質量下降)時造成的成本損失。
    在SLA中明確規定可用性要求,并傳遞下去,如涉及運營級別協議或支持合同,需要將相關的可用性要求傳遞下去,以保證客戶的可用性需求被滿足,如表4.4所示。
    表4.4 可用性指標(示例)

    可用性指標標桿備注
    平均無故障時間5.0小時平均無故障時間=系統運行時間/系統在運行時間的故障次數
    平均無故障時間越長,系統的可靠性越高
    平均故障修復時間0.5小時平均故障修復時間=系統故障耗時/故障次數
    平均故障修復時間越短,表示易恢復性越好
    平均故障間隔5.5小時平均故障間隔=平均無故障時間十平均故障修復時間
    平均故障間隔越長,表示可靠性越高

    場景1: 在某電子交易平臺的IT服務規劃設計過程中,客戶對于該平臺的運行時間有明確的要求,要求7X24小時不間斷運行,任何短暫的系統宅機都會給客戶業務帶來很大的影響和商業損失。

    • 平均無故障時間(Mean Time Between Failures, MTBF):從一次事件中恢復到下一次事件發生之間的平均間隔時間,也稱為正常運行時間。該指標與IT服務的可靠性有關。

    • 平均修復時間(Mean Time To Repair, MTTR):故障發生和IT服務恢復之間的平均時間,是檢測時間與解決時間之和,也稱為宕機時間。該指標與IT服務的可恢復性和可服務性相關。

    • 平均系統事件間隔時間(Mean Time Between System Incidents, MTBSI):兩次相鄰事件之間的間隔時間。平均系統事件間隔時間(MTBSI)等于平均修復時間(MTTR)與平均無故障時間(MTBF)之和。

  2. 業務連續性需求識別
    組織業務是由多種業務流程和信息系統的支撐組成的,信息系統的連續可用是業務作為整體得以存活的關鍵。在系統運行過程中,災難發生比突發事件更嚴重,因此必須考慮信息系統的連續性需求,并編制災難恢復計劃,以應對災難發生。
    在進行連續性需求識別的過程中,可以通過風險評估找出那些潛在的威脅,然后引入風險降低的措施或恢復等手段達成這個目的,同時為了確保其有效性,必須持續維護恢復能力。
    進行風險評估可以確定可能造成信息系統中斷、災難的潛在威脅,包括具有負面影響的事件、存在安全隱患的環境因素等。風險評估可以預測這些威脅可能造成的損失, 并且評估控制措施是否能有效防止威脅的發生,是否能有效防止威脅發生后造成的損失。表4.5為某信息系統的風險評估表。
    表4.5 風險評估表(示例)

    風險服務器硬件網絡設備系統軟件應用軟件服務
    斷電---
    火災---
    水災---
    人為錯誤----
    無法登錄---
    病毒攻擊---
  3. IT服務能力需求識別
    IT服務能力是指保證信息系統的性能和IT服務能力可以以最及時、最有效的方式滿足服務級別協議(SLA)中所有當前和未來的需求。IT服務能力需求分析要對客戶的業務需求、客戶現狀和信息系統有清晰的了解,保證所有對能力的需求都以合理的成本加以滿足,尤其是對于未來能力需求的把握,從某種程度上來說,這是能力管理對于組織的競爭力產生積極作用的主要體現。

  4. 信息安全需求識別
    越來越多的組織對于IT服務的需求會包含信息安全要求。通常來看,信息安全需求主要包括如下3方面。
    (1)機密性(或保密性):信息僅可以被授權的人訪問和使用。
    (2)完整性:保護信息防止未授權的修改。
    (3)可用性:在協議規定的時間內,信息都應該是可獲取且可用的。這些信息安全需求的優先級和重要性一般由信息系統的數據和其包含的業務內容所決定。

  5. 價格需求識別
    在考慮IT服務需求和相應解決方案時,對成本和價格的考慮是必不可少的一個環節。在價格問題上,雙方往往會進行反復溝通和確認。因此,在IT服務需求階段,對IT服務內容確認后,估算IT服務成本并進行IT服務定價會變得尤為重要。從IT服務供方的角度來看,IT服務成本主要包括如下幾部分:設備成本、系統與應用、軟件成本、人力成本、第三方支持成本、管理成本和其他成本等。

  6. IT服務報告需求識別
    為了有效溝通和制定決策,在IT服務需求識別過程中需要對IT服務過程中提供的各類IT服務報告的需求進行識別。
    IT服務報告需求識別要素包括:
    (1)需要對客戶的具體業務需求和局部情況進行分析和考慮。
    (2)在進行服務報告設計時,要明確服務報告產生的前提條件和服務報告內容的要素。

    不同環境下的典型服務報告包括如下內容。

    (1)按照既定服務水平目標衡量的服務績效。
    (2)主要工作的績效報告,如定期的服務概況、事件、變更匯報。
    (3)工作的特點和工作量信息,如突發事件、問題、變更和任務、分類、位置、客戶、季節性趨勢、優先級的混合以及要求幫助的數量。
    (4)某段時間的趨勢信息,如一天、一周、一個月或其他長度的一段時間。

    (5)報告中要包含未來計劃工作的信息。

4.5.3 關他成功因素

(1)明確服務范圍、服務內容和服務目標。

(2)識別客戶對于可用性、連續性、信息安全、服務能力、價格和服務報告方面的需求,以便對規劃設計進行規劃。

(3)與需方進行充分的溝通,全面了解明示的和隱含的服務需求。

4.6 服務方案設計

在識別出需方的IT服務需求后,就可以開始設計相應的IT服務方案,IT服務方案的設計需求同時考慮服務模式的選擇,服務級別的設定和人員、過程、技術、資源要素的管理策略。IT服務方案設計是整個規劃設計階段的核心工作,系統規劃與管理師需要綜合考慮IT服務供需雙方以及第三方的能力和要求,設計出讓各方滿意的IT服務方案。

4.6.1 服務模式設定

根據用戶實際需求,IT服務供方應提供各類不同模式的IT服務,結合IT服務需求分析的結果,對IT服務模式進行分類設計,根據客戶需求和IT服務內容,做到隨需而變。
目前,常見的IT服務模式劃分方法如下:
?是將IT服務模式劃分為遠程支持(電話或郵件)、現場服務(上門技術支持、常駐現場)、集中監控等多種技術支持服務模式,如表4.6所示;
?是將IT服務模式分為IT外包(ITO)、業務流程外包(BPO)和知識流程外包(KPO)等外包服務和新興服務模式,如Saas (Software as a Service)、云計算 (Cloud Computing)等。

表4.6 IT服務模式的分類(示例)

分類IT服務內容
遠程支持通過電話、遠程登錄,在客戶配合下進行IT服務請求的處理和系統故障的排除,包括呼叫中心、遠程幫助臺等技術支持
現場服務(上門技術支持) 遠程技術支持不能成功而必須現場服務時,提供上門的技術支持,包括到客戶現場進行巡檢工作
現場服務(長駐現場)指派專人常駐客戶現場,和客戶IT人員一起工作,隨時響應客戶服務請求,處理系統故障
集中監控通過特定的監控平臺,對客戶信息系統進行實時監控,如發生任何異常,及時介入處理或告知客戶
  1. IT服務模式設計的目的
    IT服務模式設計的目的是為了更好地滿足客戶需求,提升客戶滿意度。

  2. IT服務模式設計的活動
    IT服務模式的設計與客戶需求的匹配。在IT服務模式的設計過程中,需要充分考慮IT服務需求識別中客戶對于可用性、連續性、安全、能力等方面的需求。
    例如,客戶對于系統的可用性需求是每天24小時不間斷運行,提供的IT服務模式就可以選擇常駐現場的服務。當然,需要考慮的因素還有IT服務價格等方面。
    (1)根據客戶需求和IT服務供方的自身業務能力,對客戶服務模式進行設計,主要包括IT服務的可用性、連續性設計。
    (2)可用性設計是IT服務模式設計的重要內容之一,它確保IT服務的可用性級別可以得到滿足。
    (3)連續性設計,一般會考慮到風險控制和災難應對措施。
    (4)針對設計的IT服務模式與客戶進行討論、改進。

    (5)針對不同的IT服務模式進行匹配。

  3. 關鍵成功因素
    (1)選擇的IT服務模式與客戶需求一致。
    (2)跟蹤客戶需求的變化,及時調整IT服務模式。
    (3)IT服務供方具備同時提供多種IT服務模式的能力。
    (4)IT服務供方人員配置和資源配置與IT服務模式匹配。

4.6.2 服分級別設定

服務級別(Service Level)是指服務供方與客戶就服務的質量、性能等方面所達成的雙方共同認可的級別要求。
服務級別設定是服務供方與需方一起協商適度的目標,經商定后進行文檔記錄,以便在服務運營期進行監測,把服務交付實際情況和商定的服務級別進行比較,衡量服務質量與價格。服務級別設定的結果在確認后通常會形成服務級別協議,如圖4.4所示。

在這里插入圖片描述

服務級別設定的目標是確保對服務供方所有運營中的服務及其績效以專業一致的方式進行衡量,并且服務過程和生成的報告符合業務和客戶的需要。

  1. 服務級別設定的目的
    (1)通過對IT服務績效的協商、監控、評價和報告等一整套相對固定的運營流程,來維持和改進IT服務的質量,使之既符合業務需求,又滿足成本約束的要求。服務級別的設定有助于IT服務供方更好地對其服務水平做出正確的決定,還能夠通過調整客戶對更高服務水平的需求而對成本產生影響,限制用戶需求的膨脹。
    (2)采取適當的行動來消除或改進不符合級別要求的IT服務。設定服務級別的另外一個輔助作用就是避免期望蔓延,即對客戶未成文要求的服務進行有效管理和限制。對于用戶來說,對現狀提出更高要求是很正常的。服務級別協議(Service Level Agreement, SLA)一旦制訂,協議將成為文檔。雖然用戶會不斷地提出更高的服務要求,但是協議只能在規定的范圍內發揮作用。服務級別中規定承擔的義務可以進行變更,但是每次變更都需要重新進行協商。
    (3)提高客戶滿意度,以改善與客戶的關系。進行服務級別設定最主要的目的是明確客戶的期望、滿足客戶的需要。首先要在IT服務供方和客戶之間建立一個對話途徑,這就需要服務供方必須了解客戶到底需要哪些服務,同樣,客戶也須闡明其需要或希望得到哪些服務。當IT服務供方與客戶之間達成某種共識之后,就建立了一個衡量IT服務質量的標準,IT服務供方也就有了明確的目標,以滿足客戶的需要。
    (4)督促IT服務供方。只要把服務級別設定得恰當,無論是客戶、IT服務供方,還是與他們相關的組織,都會從中受益。服務級別的設定能夠調整用戶需求和高水平服務之間的關系;反之,服務級別能夠督促IT服務供方必須提供承諾的義務,為客戶提供目標明確的服務。

  2. 服務級別設定的活動
    (1)了解服務內容:服務供方充分了解自己所能提供的各種服務,以及相關優先權和業務重要程度。
    (2)確定服務范圍、服務對象和服務內容:可以參考服務目錄,但是對于不同用戶,具體的服務級別設定又要有針對性和獨立性。
    (3)定義服務級別目標:在服務級別設定的過程中,服務供方和客戶需要仔細地推敲指定合適的服務目標,既要考慮到客戶的需求,又要兼顧到經濟效益和成本因素,力求服務級別可行。一般來說,SLA中最關注的是關鍵服務的關鍵指標。
    (4)明確雙方職責:服務本身并不是單方面的工作,服務級別設定后在許多服務實施過程中的失敗,其原因就是因為忽略了客戶在服務提供過程中的角色,以及相應的權利、義務、職責等。經過雙方確認,除了在服務供方任命專人對口客戶,在客戶方亦需要有專人負責,對服務供方進行監督。
    (5)識別風險:充分識別實現服務級別的技術能力、資源配置、信息安全、服務成本等風險。
    (6)對服務級別設定的評審和修改:服務級別設定后需要在IT服務供方內部進行評審,評審過程除應召集服務過程相關方外,還應有質量管理人員,必要時需邀請法務人員和財務人員進行評審。
    (7)服務級別談判和溝通:在最終形成文檔的SLA中,每個細節都是經過談判、雙方同意并被記錄在案的;及時溝通服務級別設定的每項內容,對整個服務級別管理過程有著重要的作用。

  3. 關鍵成功因素
    (1)重視服務級別設定,投入足夠的資源和時間。
    (2)在服務級別設定過程中,服務級別應盡可能地獲得多數人的同意和認可,以獲得必要的支持。
    (3)充分考慮客戶需求,服務級別是根據IT與業務需求的結合面設定的。

    (4)驗證服務目標是否可實現,在簽約SLA前對這些服務目標進行核實。

    (5)正確識別供方服務能力,得到足夠的運營級別協議或支持合同的支持。

    (6)在設定服務級別過程中各方的責任定義明確。

    參考實例:表4.7列舉了常規服務級別說明書中所包含的內容。

    表4.7 常規服務級別說明書的內容

    服務名稱桌面支持服務
    描述提供桌面支持服務,包括軟件安裝、計算機配置、病毒防護、網絡配置和硬件支持,提供現場、電話或在線服務
    負責人提供負責服務的負責人姓名
    用戶包括客戶方的財務部和人力資源部的人員

    詳細細節

    輸入客戶聯系信息、全面的問題描述,包括需要的任何錯誤信息
    輸出問題被解決或按照需要升級,結果將關系到客戶的滿意度,必要時需要提供相關服務報告
    服務時間桌面支持服務時間為:周一~周五,08:00~17:00
    性能標準響應時間10分鐘到達現場時間2小時故障解決時間4小時,要求90%的服務可以在上述時限內完成
    啟動、變更或終止服務的客戶規程用戶可以通過撥打客服電話提出需求,號碼為400-123-4567
    費用支持服務不產生任何費用,如果服務過程中涉及硬件設備更換,則需要另外計費。另外,軟件的許可由客戶提供
4.6.3 人員要素設計

在規劃設計過程中,服務人員配置是必不可少的一個環節。服務供方要根據客戶的需求或潛在需求適當地配置服務人員,以最大限度地滿足客戶需求,提高客戶滿意度。服務供方在選擇人員和配置人員時,需要對人員能力和服務工作量進行評估。首先,IT服務人員能力評估應結合客戶需求和客戶特點,選取符合IT服務工作要求的評價指標,知識、技能和經驗是主要要素。其次,評估IT服務人員能力素質現狀,用以衡量IT服務人員能力素質水平;識別IT服務人員能力素質差距,用以指導IT服務人員能力素質培養方向。例如,在配置桌面現場服務人員時,需要選取的人員不僅應具備一定的基礎知識和技能,面對客戶的服務態度和語言表達也是人員配置時要衡量的內容。服務工作量的評估不僅關注IT人員的績效指標,還從服務人員工作崗位的職責等方面進行評估,也會影響成本方面的設計。

  1. 人員要素設計的目的
    (1)確保服務團隊組織架構與業務需求和服務模式相適應。

    (2)確保配置的服務人員數量能同時滿足服務和成本兩方面的需求。

    (3)確保服務人員的能力持續滿足服務的需求。

    (4)保持服務人員穩定的工作狀態。

    (5)保持服務人員的連續性。

  2. 人員要素設計的活動

    (1)人員崗位和職責設計。一個完整的IT服務團隊應包括管理崗、技術支持崗、操作崗等主要崗位。

    管理崗:

    • 管理IT服務的人員可以是供方的人員或需方相關人員。

    • 規劃、檢查IT服務的各過程,負責IT服務的策劃、實施、檢查、改進的范圍、過程、信息安全和成果。

    技術支持崗:

    • 在IT服務中負責技術支持的人員,包括網絡、操作系統、數據庫、中間件、應用開發、硬件、集成、信息安全等方面的專業技術人員。

    • 基于專有的對IT服務過程中的請求、事件和問題做出響應,保障信息安全并對處理結果負責。

    操作崗:

    • 在IT服務中負責日常操作實施的人員。

    • 根據規范和手冊,執行IT服務各過程,并對其執行結果負責。

    • 系統規劃與管理師需根據具體服務項目結合客戶需求設計相應的人員崗位、職責及工作規范。在職責及工作規范設計上,除要定義各崗位本身的職責和工作規范外,還需定義為配合服務交付需要的流程銜接、信息傳遞及反饋等工作規范要求。如對于7X24小時輪班的工作崗位,工程師須在崗位交接時就未完成工單或需后續跟進的內容進行交接說明;操作崗需要技術支持崗提供技術支持與解決的信息,還需要向技術支持崗提供相應的信息,避免重復詢問用戶。

    (2)人員績效方案設計。為建立公平、公正、公開的績效考核文化,應定期對人員績效進行考核評估,以達到積極高效的工作績效的目的。

    人員績效設計主要包括以下活動:

    • 人員績效指標的識別及定義:依據IT服務人員崗位、工作職責的不同定義不同的績效管理目標,如一線支持崗位與問題解決專家團隊工作職責不同,績效指標也不相同。因此,人員績效指標的設定要符合SMART原則。

    • 明確人員績效指標的計算考核方法:依據SMART原則設立人員績效指標后,需進一步詳細說明指標的計算及考核說明。

    • 定義考核信息來源:確定考核信息的采集方式,如系統故障日志、服務系統中記錄的客戶滿意度反饋等。

    • 定義人員績效考核周期:績效指標的定義要有一定的期限,一般IT服務人員的考核周期為每季度1次,高級別IT服務管理人員可定義為每半年或一年評價1次。

    • 設計績效考核策略:針對IT服務人員績效指標及可能的達成情況,設計績效考核和策略,以確保績效考核方案能實現人員的正向激勵。

    【實例】人員績效指標考核。
    公司針對熱線工程師設定了服務投訴次數1次/季度的指標,并進一步明確說明了投訴必須是客戶通過投訴信箱、投訴熱線進行的投訴,其他非直接表達的投訴不計為投訴,且給予熱線工程師面向客戶投訴進行申訴的機會,如客戶同意,可撤銷投訴。工程師被投訴次數超過1次,就要受到相應的懲罰,且每超1次扣除當季獎金的10%,最高扣除當季獎金的50%。
    SMART原則:

    • 明確的(Specific):清楚地說明要達成的行為標準。很多團隊不成功的重要原因之一就是因為目標定得模棱兩可,或沒有將目標有效地傳達給相關成員。如“增強客戶服務意識”的描述就很不明確,有很多增強客戶服務意識的方法,且增強客戶意識到底要達到什么樣的程度,這里都沒有具體定義,不明確就沒有辦法評判、衡量。

    • 可以衡量的(Measurable):指目標是量化的,且驗證這些目標的數據或信息是可以獲得的,無法量化就無法衡量和考核。如熱線服務滿意度大于85%,就是一個可衡量的指標,而將KPI定位為服務效率高,就不是合理的指標,其沒有具體量化,無法測量和考核。

    • 可以達到的(Attainable):指目標在付出努力的情況下可以實現,避免設立過高或過低的目標。如要求客戶滿意度為100%,那么該指標訂立得很不現實,雖然服務質量本身是一致的,但不同的客戶在不同的情形下,服務感知不同,因而很難達到100%的滿意。

    • 可實現的(Relevant):指在現實條件下是否可行、可操作。如希望將到場時間由2小時降低為30分鐘,這在既定的成本、資源約束上是不現實的,為了達成這個指標,在投入比實際收益要多很多的情況下,KPI指標訂立得就不現實。

    • 時限性(Time-bound):指標的訂立要有明確的時間期限說明。如將在2015年5月31日之前完成某事,5月31日就是一個確定的時間限制。沒有時間限制的目標沒有辦法考核,或帶來考核的不公正。

    無論是制訂團隊的工作目標還是員工的績效目標都須符合上述原則,五個原則缺一不可。

    (3)人員培訓方案設計。為保障服務人員持續具備滿足SLA要求的服務能力,需要通過培訓來輔助IT服務人員的技術能力持續滿足IT技術發展的需要,確保IT服務管理能有效實施,并滿足IT服務人員的成長需求。人員培訓方案設計主要包括以下活動。

    培訓需求分析

    • 調查:沒有調查就沒有發言權,通過各層面的調查獲取培訓需求,通過內部調查了解各層面員工需要什么培訓、什么時候需要、對培訓的關切程度、需要什么形式的授課。

    • 管理層訪談:通過高層訪談和參與管理層會議的形式,了解管理層所需要收獲的知識,如何提高IT服務管理水平、開拓管理層事業,如何提高IT服務的效益,如何提升管理層自身價值的認可與企業歸屬感等。

    • 數據分析:分析、整理前期人員服務過程數據,培訓調研的數據,歷次課程、培訓考試的數據,最終獲取當期培訓的真實需求。

    培訓內容設計

    • 管理培訓:企業IT服務的生存和發展,從一定意義上講取決于IT服務管理人員對于IT服務的管理水平和能力,做好管理培訓是IT服務發展的有力保證。IT服務中的管理培訓主要培養執行IT服務過程的管理人員,應該具備優秀的溝通能力、執行能力、合理規劃能力、過程管理能力、IT服務管理過程中良好的承上啟下的能力等。

    • 技術培訓:技術是IT服務活動中質量保障的一個重要前提,IT服務人員技術培訓重在學習專業技能尤其是專業領域的技術,要求每位IT服務人員有扎實的專業技能,以解決IT服務過程中的請求、事件和問題為契機,不斷提升其專業技能和實踐能力,進而全面提升其IT服務能力。

    • 工具培訓:生產力的提升離不開工具,IT服務能力的提升更離不開工具的使用。在IT服務活動中往往重視各種工具的建立,而忽略工具在改造、升級、人員交接過程中造成的使用和規范性問題。所以,關于IT服務工具的培訓無論是監控工具、過程管理工具還是專業工具,基本的使用問題是工具培訓中必不可少的要素,還應該考慮到工具使用的規范性培訓。

    • 過程培訓:過程管理是IT服務能力計劃制定后到IT服務執行前的一系列管理工作,主要對象是IT服務活動中的操作人員以及與之相關的其他人員。過程培訓包括IT服務活動中各個過程的規范、與SLA相關的指標、考核制度等。

    • 交付和應急培訓:通過對交付崗位人員培訓,使交付人員明確交付職責、分工、指標及關鍵管理節點,減少交付人員錯誤、提高質量。在交付過程中,為了降低設備在運行維護過程中發生的故障,制訂應急預案,并組織應急培訓,包括對各環節應急預案的響應規范、故障發生頻率和周期性知識、風險意識、應急演習等,使人員能夠在IT服務過程中領會交付和應急管理的重要性,提升崗位人員的交付、應急素質和處理能力。

    設計培訓計劃

    • 培訓計劃:根據企業一定時期的IT服務發展需要,將培訓需求進行客觀分析并轉變為企業IT服務培訓的總體計劃。培訓計劃和經營計劃一樣是企業實施經營的必要保證,沒有計劃的培訓會導致培訓秩序重疊、效果差、成本高,所以實施培訓的前提是需要一份培訓計劃。例如,結合企業IT服務的目標,了解員工知識、技能的現狀及未來發展的愿望;將IT服務目標分解到培訓的指標體系中,確定培訓內容及要求;初步制訂培訓計劃,上報審批;執行過程中定期檢查發現的問題,及時修正培訓計劃;階段性總結,結合培訓效果,提出新的要求并及時修正。

    • 培訓形式:在IT服務活動中,培訓要想達到好的效果,形式的選擇非常重要。根據課程目標的需要選擇不同的培訓形式,合理利用企業資源優勢、員工特點和需求以及培訓內容,選擇適合所需的培訓形式,達到最終的培訓目的。通常的培訓組織形式有授課式培訓、實操示范、研討會、在線視聽學習、討論等。

    • 培訓紀律:良好的紀律是培訓質量的有力保證,在培訓體系建設過程中往往局限于設計好的培訓課程,實際培訓紀律才是培訓本身有序進行的前提。除了從培訓設計本身吸引員工注意力,還創造良好的氛圍,因為員工的學習習慣各有差異,保證培訓質量要從培訓紀律規范性上加以管理。

    設計培訓效果評價方法

    • 評價的形式和方法:培訓效果評價有助于完善培訓制度,改進培訓質量,從而提升整個IT服務團隊的績效。IT服務活動中培訓的形式一般包括調查問卷、考試、課堂表現和實際操作,如表4.8所示。

      表4.8 IT服務活動中的培訓形式

調查問卷用于評價講師、課程安排、組織者在對學習過程中的執行情況以及學員的認可度
考試用于測試對知識的掌握情況,以及敘述技能的操作要點與程序
課堂表現用于測試對知識或技能的學習情況,以及在互動教學中的技能測試情況
實際操作用于測試對技能的操作熟練程度,以及實際環境的應變能力
  • 評價的內容:主要包括課程內容、課程安排、講師、個人收益,如表4.9所示。
    表4.9 培訓評價的內容
課程內容與崗位業務需求的匹配程度
課程安排課程的時間、教材、環境、設施、組織以及組織方的工作情況
講師講解思路、表達、積極性、控場能力
個人收益對培訓內容的掌握情況
  1. 關鍵成功因素
    (1)是否具有成熟的知識管理體系。
    (2)崗位培訓是否充足且適用。
    (3)進行服務意識及溝通能力培訓。
    (4)團隊內人員能力的互備性。
    (5)人員考核指標設定是否符合SMART原則。
    (6)人員考核結果應用是否真正落地有效。
    (7)建立良好的溝通協作機制。
    (8)設計有效的人員儲備管理措施。
    (9)引導積極向上的團隊文化,舉行團隊活動或其他方式進行團隊建設。
4.6.4 資源要素設計

在規劃設計過程中,根據已經識別的服務需求和設定的服務級別,IT服務供方需要進行服務資源配置,確保服務供方具備提供足夠資源的能力,以滿足與需方約定的及需方未來的IT服務需求,包括對服務工具、服務臺、備件庫、知識庫的設計。

  1. 資源要素設計的目的
    (1)確保服務供方具備提供足夠資源的能力,以滿足客戶的服務需求。
    (2)確保服務供方可以使用有效手段和方法受理客戶的服務請求,及時跟蹤服務請求的處理進展,確保達到SLA要求。
    (3)分析當前的業務需求并預測將來的業務需求,確保這些需求有足夠的服務資源進行保障。
    (4)確保當前的服務資源能夠發揮最大的效能,提供最佳的服務品質。

  2. 資源要素設計的活動

    1)服務工具選擇
    隨著IT資源規模不斷增加、業務復雜度的不斷深入,IT服務人員只通過人工手段來維護已不能滿足業務的需求,因此需要借助自動化的工具和手段來提高自己工作的有效性和效率。常見IT服務工具包括監控類工具、過程管理類工具和其他工具,工具間的關系如圖4.5所示。
    (1)監控類工具:監控對象的狀態數據,為過程管理提供數據支撐,在基于硬件/軟件平臺、虛擬化、業務、用戶感知以及基礎設施等這些監控對象的基礎上,實現諸如事件管理、性能管理、視圖管理、告警管理、統計分析、日志管理等功能。通過此類工具,IT服務人員能夠對組織IT環境中的資源進行監控,及時了解IT資源的基礎信息、動態信息、告警信息。

    在這里插入圖片描述

    (2)過程管理類工具:IT服務過程管理(簡稱過程管理)實現了從技術管理到服務過程的流程化管理,解決了傳統IT管理以技術管理為中心的問題。過程管理以“流程”為主線,以標準化為框架,以管理為核心,有機結合了流程、人員和技術三要素。過程管理類工具提供了面向最終用戶的服務臺及IT服務運營層次的流程,即服務級別管理、服務報告管理、事件(故障)管理、問題管理、配置管理、變更管理和發布管理等。

    (3)其他工具:通過此類工具,IT服務人員能夠進行重復或批量工作的自動化管理,提高IT服務效率和效果。包括應用程序進程管理工具、補丁管理工具、軟件分發工具、遠程桌面管理工具、網絡訪問管理工具、接入安全管理工具、桌面設置管理工具、外設管理工具、預警管理工具、知識管理工具和安全管理工具等。

    系統規劃與管理師應根據實際需求、服務成本等相關因素,判斷是否需要服務工具。如果需要,在選擇時需注意以下兒點。
    (1)根據服務內容:所有的IT服務項目都需要建設使用一些同類的工具,但不同的IT服務項目所需要的工具會稍有差別,IT服務項目經理應根據項目的特點選擇重點建設的內容,如下所示。

    • 所有IT服務項目:服務臺、配置管理平臺、過程管理工具、知識管理工具、文檔管理工具。

    • 咨詢項目:知識管理、文檔管理。

    • 桌面運維服務項目:服務臺、配置管理、防病毒管理、補丁管理平臺。

    • 數據中心場地服務項目:服務臺、環境監控、閉路監控、網絡監控。

    • 應用系統運維服務項目:服務臺、網絡監控、操作系統監控、業務應用服務監控。

    (2)考慮成本:現在市場上有很多的工具可供選擇,當由客戶出資時,必須根據客戶可接受的成本選擇不同的工具(不同行業的企業可接受成本不同)。例如,政府、金融行業因為資金充足,會以采購市場上已成熟的產品為主,要求高可用性、高穩定性、良好的技術支持;互聯網公司為節省資金,會以采購開源工具為主,要求低費用、可自我二次開發。若是全外包的項目,則需要重點考慮成本,此時工具的投資已是IT服務項目本身的成本。

    (3)考慮客戶的期望:根據客戶關注的重點服務或關鍵應用選擇成熟度高、實用性高的工具。

    (4)考慮工具的技術架構及團隊的技術水平:系統規劃與管理師都希望所選擇的工具能夠切實提高IT服務支持的水平,能夠持續滿足在管理制度建設方面的發展需求,服務管理平臺類的工具應該高于當前的項目管理需求而建立。基于B/S結構的工具易用性較高,在訪問方式上靈活,契合當前的互聯網時代,同時在同一界面中包含盡可能多的功能和信息,操作簡單。因此,在工具選型中應考慮盡可能選擇B/S架構的工具。同時,應將IT服務團隊自身的技術水平列入考慮范圍之內,團隊技術水平高可選擇開源等需要大量維護開發工作的產品。

    (5)考慮工具的通用性和集成性:除非一個項目十分特殊,否則一般在工具選擇時要考慮工具的通用性。例如,選擇過程管理平臺時要考慮工具對IT服務過程的支持力度,以及對項目現有流程制度體系的支持力度。工具對流程制度體系的支持越高,工具帶來的效益越明顯。IT服務管理離不開軟件工具的集成性,這種集成性主要體現在:服務管理工具與項目管理工具的集成,服務管理工具與監控預警工具、配置管理工具的集成, 以及與項目相關的辦公自動化(OA)系統的集成。

    2)服務臺設計
    服務臺也稱為幫助臺(Helpdesk)或呼叫臺(Service Desk),其概念起源于傳統服務業,當信息技術大規模應用于服務行業后,服務臺概念也被引入。
    服務臺不是一個服務過程,而是一個服務職能,目的是為用戶和IT服務組織提供一個統一聯系點。如一名普通技術支持人員完全可以利用從該系統中獲得的信息,協助用戶解決簡單的數據庫問題,而不一定要將用戶轉交給專門的數據庫工程師。
    在規劃設計階段,一旦設定了服務級別和服務內容,服務供方就需要在服務臺中配置相關的服務信息,包括相關的客戶信息、服務內容和服務級別等基礎信息,以便于服務提供。圖4.6描述了服務臺在整個IT服務過程中的位置。

    在這里插入圖片描述

    供方應使用有效手段和方法受理需方的運行維護服務請求,及時跟蹤服務請求的處理進展,確保實現服務級別協議要求,包括:

    (1)設置專門的溝通渠道作為與需方的聯絡點,溝通渠道可以是熱線電話、傳真、網站、電子郵箱等。

    (2)設定專人負責服務請求的處理。

    (3)針對溝通渠道整合服務過程,建立管理制度,包括服務請求的接收、記錄、跟蹤和反饋等機制,以及日常工作的監督和考核。

    3)備件及備件庫設計

    備件庫主要是為IT服務的客戶提供設備備件。一般來說,IT服務供方應具備自己的備件庫,或者有外部備件支持方來保證備件資源。
    一旦確認IT服務需求和服務級別,就需要及時地配置備件資源,主要是配置備件響應方式和級別定義。另外,從IT服務供應方整體來看,規范備件采購流程、出入庫管理流程也是在備件庫配置前期需要考慮的內容。

    應具備并有效管理運行維護服務活動所需的備件資源,為所運行維護的設備或系統提供備件服務,按照SLA要求恢復設備或系統的正常運行。對備件庫的管理設計包括:

    (1)備件響應方式和級別定義,能夠滿足SLA所約定的備件支持。

    (2)備件供應商管理,能夠規范備件的采購過程,對供應商進行選擇和評價。

    (3)備件出入庫管理,能夠對入庫備件進行標識,規范備件的使用和核銷,備件物品的賬務管理。

    (4)備件可用性管理,能夠定期對備件狀態進行檢測,以確保其功能滿足運行維護需求。

    在備件庫管理中,要注意以下指標:備件庫信息真實性、備件運作管理規范性、備件庫出入庫賬務管理制度完備性、備件可用率。

    4)知識庫設計

    應具備IT服務活動相關的知識積累,以保證在整個組織內收集、共享、重復使用所積累的知識和信息,包括:

    (1)針對常見問題的描述、分析和解決方法建立知識庫。

    (2)確保整個組織內的知識是可用的、可共享的。

    (3)選擇一種合適的知識管理策略。

    (4)知識庫具備知識的添加、更新和查詢功能。

    (5)針對知識管理要求制定相關管理制度,并進行知識生命周期管理。

  3. 關鍵成功因素

    (1)服務人員能力達標,能正確使用各種服務工具。

    (2)服務臺的職能明確、服務過程規范。

    (3)備件管理規范與SLA中的條款相一致。

    (4)有效的監控平臺能提高主動發現事故或事件的概率,提前做好預防工作。

    (5)及時根據服務級別和服務需求的變更調整服務資源的配置。

    (6)如備件庫由第三方提供,第三方的支持服務級別充分滿足服務需求。

4.6.5 技術要素設計

技術是為保證IT服務的正常交付所應具備的關鍵技術,或者提供IT服務過程中所必需的分析方法、架構和步驟。
在提供IT服務過程中,可能面臨各種問題、風險以及新技術和前沿技術應用所提出的新要求,服務供方應根據需方要求或技術發展趨勢,具備發現和解決問題、風險控制、技術儲備以及研發、應用新技術和前沿技術的能力。
根據服務對象的技術特征和客戶的業務特征,識別出服務中需要使用的關鍵技術,并且根據設計的服務模式識別出服務中的常見活動,對識別出的關鍵技術和常見活動安排人員研發標準作業程序(Standard Operating Procedure, SOP)、應急預案、監控指標及閾值、解決方案、技術規范等。在部署實施階段應不斷識別新的關鍵技術或常見活動,持續新增或變更技術研發活動,并積極使用研發成果。

  1. 技術要素設計的目的

    技術是IT服務中的核心要素之一,也是完成IT服務的必要條件,任何IT服務都有相應的核心技術的支撐,只有掌握了這些核心技術,才可能完成IT服務,從而才有可能提供IT服務的質量。通過技術管理系統的建立,能夠對技術管理的成效進行總體評價,幫助IT服務管理層分析技術管理不善的原因,制訂改進措施,不斷提高IT服務的技術水準,從而提高IT服務水平。
    技術要素的設計在IT服務中的目的包括:

    (1)提高服務質量。

    (2)減少人員流失帶來的損失。

    (3)提高IT服務的效率。

    (4)降低服務成本。

    (5)對各類IT服務所需的技術進行統一管理,可以做到對成熟技術及時進行推廣,并隨時研發新的技術。

    (6)給IT服務供方和需方提供一致的技術標準。

    (7)對技術和方法進行說明,可根據自身需求挑選IT服務項目所需的技術。

  2. 技術要素設計的活動

    1)技術研發
    編制技術研發預算:IT服務供方要根據業務和市場分析,針對快速發現問題、快速解決問題、提高業務效率的新方法等制訂研發規劃,并配備與規劃相適應的研發環境和相適應的研發隊伍。系統規劃與管理師應估算技術研發的成本情況,編制技術研發預算,為運營階段的技術研發活動提供資金方面的保障。

    2)發現問題的技術

    (1)識別監控對象,制訂設備監控指標及閾值表編制計劃:根據組織業務和IT服務需求識別出各類監控對象的監控指標和閾值,是監控工具能提供有效監控的基本要求,系統規劃與管理師應識別出需要被監控的各種設備,為后期能制訂和變更設備監控指標及閾值表制訂編制計劃,并投入資源保障計劃的實施。
    (2)制訂測試環境建設計劃:仿真測試環境通過模擬真實應用系統環境中的場景,為各類測試和分析提供必要的條件,以驗證技術的可行性和可靠性。系統規劃與管理師應根據服務內容,在考慮服務成本和客戶期望的前提下制訂仿真測試環境建設計劃,為IT服務運營階段的問題分析和技術管理提供技術保障,規避IT服務的潛在缺陷,增加客戶和服務提供方的信心。

    3)解決問題的技術

    (1)識別常用技術,制訂常用技術活動標準操作步驟編制計劃:技術活動標準操作步驟就是將某一事件的標準操作步驟和要求以統一的格式描述出來,用來指導和規范日常的工作,系統規劃與管理師應識別出IT服務可能涉及的技術活動,根據技術活動的頻率和影響程度,列出需要標準化操作的技術活動,制訂技術活動標準操作步驟編制計劃,以保障在IT服務實施和運營階段建立起標準化的技術操作規程,指導IT服務人員進行標準化的操作,以降低風險、提高效率。

    (2)識別突發事件類型和等級,制訂應急預案編制計劃:由自然災害、基礎設施故障、核心應用故障、安全事件等引發的重大突發事件,將對IT服務的運營產生嚴重影響,為了避免出現這些事件或出現后及時恢復,應建立相關的應急預案并演練。系統規劃與管理師應在IT服務規劃設計階段識別出重大突發事件的類型和等級,制訂風險評估和應急預案編制計劃,并確保在IT服務實施和運營階段有足夠的能力實施該計劃。

    (3)識別知識轉移需求,制訂知識轉移計劃:完備的知識可提高IT服務技術支撐能力,降低風險,縮減成本,提升效率。系統規劃與管理師應別識過往IT服務中產生和使用的歷史運維資料、基礎架構資料、應用系統資料、業務資料等,以便完整地轉移到現有的服務團隊中,并為實現知識轉移提供支持和保障。

  3. 關鍵成功因素

    (1)服務人員技術能力達到崗位要求。

    (2)正確識別服務需方要求或技術發展趨勢。

    (3)重視技術方面的使用、管理和維護,建立發現和解決問題的技術體系。

4.6.6 過程要素設計
  1. 過程管理模型

    1)過程/規程管理

    過程是指為達到某個目的或目標,而以確定的方式執行或發生的一個或一系列有規律的行動或活動。

    規程,也稱為標準作業程序(Standard Operation Procedure, SOP),是指將某一事件的標準操作步驟和要求以統一的格式描述出來,用來指導和規范日常的工作。簡單地說,規程可理解為”規則+過程”。

    過程是較寬泛的概念,描述層級相對較高,而SOP是過程的細化和落地,除約定活動執行的方式和順序外,更強調了各活動的具體標準、執行條件、執行規范等。SOP的精髓是將細節進行量化,即對某一程序中的關鍵控制點進行細化和量化。一套好的SOP是確保產品或服務質量的必要條件。SOP不僅是一套技術性范本,更重要的是涵蓋了管理思想、管理理念和管理手段。

    過程管理是指為了使過程活動更有效,對過程采取的測量、考核、計劃和控制措施。客戶IT服務需求是通過一個個過程及相關活動實現的,過程要素是IT服務需求實現的保障,過程活動的貫穿使服務更加軌道化、標準化、規范化,進而服務產出更加標準、穩定。

    過程的產出是由客戶需求決定的,過程產出是否符合約定的客戶服務目標表明過程是否有效,過程投入的多少表明過程的工作效率。

    2)過程管理模型

    過程通常定義了活動、關系、順序、產出標準等信息,如圖4.7所示。

    在這里插入圖片描述

    過程管理模型包括一下特征。

    (1)有明確的目標:過程存在的原因是為了交付特定的結果,結果必須具有獨立性和可計量性,如可統計客戶支持事件的個數。

    (2)可重復性:過程不是一次性的,過程通常為解決具有重復性特征的服務需求而定義,這樣可以確保發揮過程持續性的應用效用。

    (3)可衡量性:過程除了可依據交付目標衡量外,還可以根據管理控制需求對過程活動的成本、質量、持續時間進行衡量;同時,過程還可以對重復性事件進行統計衡量與評估,如各活動及跨活動持續的平均時間、活動執行的時間方差、過程在特定時間段內的產出率等。

    (4)明確的服務提供者和服務對象:過程是為最終客戶服務的,沒有客戶的過程是沒有意義的,是對服務組織資源的浪費。過程在為最終客戶服務的同時,其每個活動都有自身的客戶,活動的客戶可能是IT服務團隊成員,也可能是最終客戶,在一定程度上,活動是未進行更細致展開的子過程。

    (5)對特定事件的響應:雖然一個過程可能是持續性的或重復性的,但其都有相應的驅動原因,如客戶對平臺穩定性的要求等。

    (6)本身的執行需要相應的信息輸入:包括過程執行結果的反饋及既有知識、操作規程、數據信息等。

  2. 過程識別和定義

    過程作為IT服務的核心要素之一,與其他要素相比具有一定的獨特性,在多數情況下,過程不是顯性的,通常看不見、摸不著,甚至說不清、道不明。但在面向客戶的服務過程中是實實在在存在的,為了交付特定的IT需求,如未明確定義和說明具體過程,服務組織、第三方、客戶之間通常會“滋生”相應的過程去實現交付目標。

    過程及過程管理的優劣直接關系服務效率和效益。未明確識別定義的過程在服務實踐中難以標準化,服務質量難以把控,也無法準確衡量,因此需要對過程進行識別和明確定義。

    1)目標

    過程識別和定義的目標主要包括:

    (1)過程符合可行性、適用性。

    (2)過程穩定,可重復使用。

    (3)過程符合效率要求。

    (4)過程符合效益要求。

    (5)過程可被監控和管理。

    (6)過程可追溯、可審計。

    (7)過程可被衡量和評價。

    2)活動

    (1)識別客戶服務內容、范圍、目標、管理要求過程的最終目標是交付合格的服務結果,過程的識別和定義要圍繞客戶服務內容、范圍、目標、管理要求而展開。

    (2)識別需要的過程及過程目標常用過程包括需求管理、事件管理、問題管理、變更管理、發布管理等管理過程。不同的服務協議需要配套不同的過程來實現。在具體IT服務項目中,應選擇合適的過程服務去實現相應的目標。如客戶協議中僅需要提供電話方式給予遠程技術支持,則只需要建立配套的事件管理過程即可。選擇合適的過程,同時要識別出合適的過程衡量標準,這些標準一般在服務協議中有著明確的定義,如熱線接通率、熱線解決周期、滿意度等。

    (3)定義角色和職責對應選擇的過程定義相應的角色,如服務臺支持工程師、現場工程師、二線支持專家、后臺工程師等,并對各角色的職責進行詳細的職責描述。

    (4)識別過程的活動,定義活動的相互關系、順序、活動目標、活動的資源限制及管理要求,在實踐中,應根據客戶管理要求和服務協議的不同而進行細致的定義,包括識別過程需要的活動、各過程需要的輸入/輸出目標、活動間的關系及執行順序。其中涉及與客戶互動的活動環節,需要參考客戶的意見來共同定義。

    (5)定義相關活動詳細操作規程及衡量標準過程活動的定義是相對高級別的操作匯總,為保障過程活動的目標達成,需要選擇和定義更細致的操作規程,如服務器系統安裝操作規程、服務器重啟作業操作規程等。具體操作規程依據服務實踐中對風險的管理和接受要求來定義,如在無相關操作規程描述的情況下,風險仍在可控范圍,則無須對所有場景都制訂出嚴格的操作規程。最佳的服務實踐靠行為模式文化引導,而不是嚴格的過程和制度,所有的過程都細化到SOP是不經濟的,也是不可取的。

    (6)定義過程的表單及信息記錄保存要求。過程定義應包括詳細描述過程各活動的信息記錄,一是標準化過程的輸入、輸出及處理,二是確保過程具有可追溯性和可審計性。

    (7)定義過程評價、評估及改進機制對過程的評價衡量可結合服務協議約定的報告周期進行。但過程定義后,在服務實踐中會因客戶需求變化、過程本身設計等原因致使過程不再適用,需要對過程進行重新評估和改進。過程本身需要一定的穩定性,所以評估和改進的周期可以是半年或一年進行一次。

    【實例】 桌面系統重置操作規程。

    來源:客戶熱線電話派單、客戶現場等。

    步驟1:禮貌問候。

    步驟2:詢問客戶故障現象,進行故障識別判斷,如可通過維護解決,與客戶協商直接維護,若客戶堅持,則進入系統重置流程。

    步驟3:與客戶確認桌面設備外觀狀態(避免外觀有損等現象導致后期出現爭議)。

    步驟4:與客戶確認備份內容,必須提示用戶備份郵件、通信錄、常用網址、文檔、輸入法字庫等;如客戶需要支持或備份空間,給予備份空間協助;備份確認狀態,獲取客戶簽字確認。

    步驟5:與客戶確認需要安裝的操作系統并簽字后,方可進行。

    步驟6:使用DSL最新GHOST文件恢復系統,重置過程中,按順序嚴格填寫《桌面系統重置操作進度表》。

    步驟7:系統重置完成后,依據《XX裝機標準》中相關內容進行配置和檢驗。

    3)參考示例

    A公司為解決日常大量的重復性客戶桌面支持問題,將桌面支持服務外包給了B服務商。B在服務實踐中,建立了統一標準的IT服務臺,經與客戶的磨合溝通,確立了如圖4.8所示的三級客戶支持體系。

    B公司分別就服務臺工程師、二線專家、廠商定義了其角色及職責描述,其中服務臺工程師職責定義為:

    • 服務呼叫的接受、記錄、跟蹤和優先級排序。

    • 已注冊呼叫或投訴的處理狀態跟進。

    • 及時通知用戶事件或請求的狀態和處理進展。

    • 對用戶的請求做出評估,嘗試解決或將其指派給合適的人加以解決,保持服務級別。

    • 監控客戶支持事件并進行事件處理的升級管理全過程必須滿足服務協議的要求,才能根據此升級管理全過程來管理用戶需求,包括記錄、處理、結束和檢查;根據實際情況,就服務級別的任何變動及時與用戶溝通。

    • 與二線人員和第三方支持組織進行合作。

    • 服務總結,為服務水平的改進提供參考和建議。

    • 為問題管理提供相關的事件信息。

    • 安排用戶/服務臺培訓計劃。

    • 在獲得用戶的確認后關閉客戶支持事件。

    在這里插入圖片描述

在操作規程方面,對服務臺工程師設定了以下要求。

支持前

  • 應了解需要支持的內容、支持時間要求、SLA、之前的支持情況及遺留問題,并與需方確認。
  • 如果工作較復雜或存在風險,應提前做好預案經過審核后再實施。
  • 應確保支持所需的工作條件滿足安全、穩定和可用的要求。

支持過程中

  • 應嚴格按照服務臺客戶用語規范要求。
  • 應按照約定的時間要求提供遠程支持。
  • 應與需方保待溝通。
  • 應嚴格遵守需方的管理制度。
  • 應根據交付實施的安全要求提供遠程支持服務。
  • 應只完成確認的工作內容。
  • 如果遇到無法解決的問題或需方提出額外要求,應及時通知上級獲取支持,得到授權后再處理。

結束支持前

  • 應就遺留問題的處理建議和需方達成共識。
  • 應做必要的安全檢查,如清除臨時賬號、避免數據未授權復制等。
  • 應在獲得需方許可后才能結束遠程支持工作。

結束支持后

  • 應調查交付服務的規范情況。
  • 應調查交付服務的客戶滿意度。
  • 應更新交付服務記錄。
  • 應就遺留問題尋找解決方案,跟蹤解決。

客戶支持服務表單及信息記錄至少包括以下信息。

  • 事件單據號、事件狀態。
  • 創建人信息:創建人、創建時間、登錄賬號。
  • 申請人信息:申請人、申請人郵箱、聯系電話、所在公司、服務級別、辦公工位。
  • 事件總體信息:事件標題、事件描述、事件來源、事件重要程度、事件緊急程度、解決方案、事件解決人、解決時間、解決方式。
  • 事件處理歷史信息:轉移人、處理人、診斷及補充信息、所采取的支持及操作、開始時間、解決時間。
  1. 過程KPI設計

    1)目的

    通過KPI的設計,實現對過程及其活動的監控與衡量,進而保障過程目標的達成。過程KPI設計的目標包括:

    (1)通過分層細化過程KPI,確保過程可管理性、可衡量性。

    (2)控制風險,消除因未明確定義而引發的潛在風險。

    (3)對過程進行定期評價與衡量,改進調整KPI設計,保持過程的有效性。

    2)原則

    過程KPI指標應符合SMART原則。

    3)活動(過程KPI設計方法)過程KPI設計通常采用如下過程。

    (1)確定過程KPI指標。通常在與客戶的服務協議中已有明確的指標說明,在服務實踐中,服務團隊為了保障服務質量,自身會補充設置更多關聯性的KPI指標,這些指標未寫進服務協議中,但對服務協議各項目標的達成起到了實際的操作級保障,可以采用如圖4.9所示的分解法進行KPI指標設計。

    在這里插入圖片描述

    • 定義整體過程KPI:可直接將服務協議中的指標作為過程的KPI指標進行轉換定義,如服務協議中的工作時間、客戶滿意度、解決周期、穩定率等。

    • 定義各過程角色KPI:如定義一線問題解決率、一線錯誤轉移的事件比率、一線未解決30分鐘內實現轉移比例等。

    • 定義活動及子過程KPI:同角色KPI設計,為更有效地保障最終客戶服務協議目標的達成,需要在各活動風險點設定相應的KPI指標,以確保各環節的風險在可控的范圍內。針對活動的指標可定義為:Linux系統裝機周期小于3小時,設備送外修時間小于1周等。

    (2)明確KPI計算方法。KPI指標的計算方法應明確定義,避免產生爭議,如客戶滿意度計算,客戶未填寫反饋信息的服務事件是否納入統計中,是否列入滿意范圍等,以及客戶投訴的界定,是否撥打投訴電話都界定為投訴,是否給予申述機會等。

    (3)明確KPI信息來源。KPI考核指標的衡量需要獲得供需雙方共同信任的信息來源,如滿意度來自于系統平臺的客戶滿意度反饋、故障解決周期基于系統的時間記錄等。

    (4)定義KPI考核周期。依據SMART原則,指標的制訂要有明確的時間期限說明,時間期限即KPI考核周期,不同過程的KPI的考核周期不同,日常監控管理要求越高,統計數量級越大,考核的頻度要求越高,如熱線平均解決周期可以周為單位進行考核。反之,日常監控管理要求低,且數量級很小,KPI考核周期相對設置較長,如對投訴,可以季度為單位。

    (5)定義過程KPI評價、評估及改進機制。按協議約定的報告周期對過程KPI進行評價和評估。在服務實踐中會因客戶需求變化、過程KPI本身設計、過程各級活動及子過程的管理控制要求不同等原因,引發過程KPI設計的調整,需要對過程KPI進行重新評估和改進。

    4)參考實例
    客戶支持過程KPI(示例)如表4.8所示。

    在這里插入圖片描述

    注:

    VIP客戶:指經A公司正式發文任命的總裁、高級副總裁、副總裁、助理總裁人員。

    重要客戶:指經A公司正式發文任命的總經理、副總經理、總監人員。

    普通客戶:不屬于VIP及重要客戶的A公司正式員工。

  2. 過程監控設計

    過程定義完成后,需要在控制管理下才能正常發揮作用,處于良好控制下的過程可以持續發生效用,可管理性更強。沒有控制的過程會流于形式、形同虛設,無法真正發揮效用。

    1)目標

    (1)確保過程執行的規范性、有效性,進而確保服務質量的達成。
    (2)及時發現過程執行中的問題,采取應對及改進措施。
    (3)對過程本身進行評估,持續改進優化過程。

    2)活動

    (1)過程監控的執行,并及時采取干預應對措施。在辦公過程電子化的今天,IT服務過程KPI通常設定到電子流程中,如數據中心核心交換機報警信息在5分鐘內仍無人處理,將自動短信升級通告到上級主管。
    (2)過程審計。通過事后審計的方式也可加強IT服務過程執行的約束力,如對于核心應用故障處理流程,可按照核心應用故障處理過程中的約定,面向業務方應用管理員調研、查閱故障處理報告、應用系統日志、郵件及網絡發日志等了解是否嚴格執行了處理過程。
    (3)過程KPI考核。通過對單一事件或一定周期內事件處理進行綜合統計分析,以便確認KPI指標是否達成,如服務協議約定事件解決周期不超過4小時,但每月有3個事件解決周期可超過4小時,但最長不能超過8小時,通過對當月所有事件的統計分析,可考察整體過程目標是否達成。

  3. 常見IT服務管理過程設計

    1)服務級別管理過程設計

    目的:設計服務級別管理過程,明確角色與職責,梳理過程活動和順序,設計過程管理指標和改進機制,該過程須確保供方通過定義、簽訂和管理服務級別協議,滿足需方對服務質量的要求。

    (1)過程中應當充分考慮以下事項。

    • 建立服務目錄。

    • 需方簽訂服務級別協議。

    • 根據需方的考核評估要求,建立SLA考核自評估機制,包括SLA完成情況、達成率等;在SLA評估后制訂改進內容及改進措施。

    (2)服務級別的關鍵指標至少應包括以下內容。

    • 服務目錄定義的完整性。

    • 簽訂服務級別協議文件的規范性。

    • SLA考核評估機制的有效性和完整性。

    2)服務報告管理過程設計

    目的:設計服務報告管理過程,根據服務需求和項目干系人的需要,設計報告內容和頻度,特別是報告中的數據來源和計算公式,以及數據準確性的校驗機制。
    該過程須確保供方應通過及時、準確、可靠的報告與需方建立有效的信息溝通,為雙方管理層提供決策支持。

    (1)過程中應充分考慮以下內容。

    • 與服務報告過程一致的活動,包括建立、審批、分發、歸檔等。

    • 服務報告計劃,包括提交方式、時間、需方接收對象等。

    • 服務報告模板,包括格式、提綱等。

    (2)服務報告的關鍵指標至少應包括以下特性。

    • 服務報告過程的完整性。

    • 服務報告的及時性、準確性。附服務報告分類及模板。

    3)事件管理過程設計

    目的:設計事件管理過程,根據服務對象的技術特性和工具配備情況設計事件發生分類和分級,設計處理各類事件的活動和順序(應包括合理的事件升級機制),根據SLA的要求設計各類事件的考核指標,設計事件處理情況的定期回顧機制,通過數據分析發現服務改進機會,并為服務報告提供信息支持。該過程須確保供方具有檢測事件、盡快解決事件的能力。

    (1)供方應根據事件管理的過程要求建立以下活動機制。

    • 與事件管理過程一致的活動,包括事件受理、分類和初步支持、調查和診斷、解決、進展監控與跟蹤、關閉等。

    • 事件分類、分級機制。

    • 事件升級機制。

    • 滿意度調查機制。

    • 事件解決評估機制,包括事件解決率、事件平均解決時間等。

    (2)事件管理的關鍵指標至少應包括以下特性。

    • 事件管理過程的完整性、有效性。

    • 事件解決評估機制的有效性。

    4)問題管理過程設計

    目的:設計問題管理過程,根據客戶業務的特性和服務人員的技能情況,定義什么是問題,什么情況下啟動問題處理過程,設計問題分類和分級,重點關注事件與問題轉換的處理方式,規劃處理問題的人員與工作機制,設計必要問題管理過程和順序,考核機制,在運營類服務中問題管理與研發、變更和發布的關聯關系,考核機制應關注預防措施的實施比例。

    該過程須確保供方通過識別引起事件的原因并解決問題,預防同類事件重復發生。

    (1)供方應根據問題管理的過程要求建立以下活動機制。

    • 與問題管理過程一致的活動,包括問題建立、分類、調查和診斷、解決、錯誤評估、關閉等。

    • 問題分類管理機制,包括問題的影響范圍、重要程度、緊急程度并確定優先級。

    • 問題導入知識庫機制。

    • 問題解決評估機制,包括問題解決率、問題平均解決時間等。

    (2)問題管理的關鍵指標至少應包括以下特性。

    • 問題管理過程的完整性。

    • 問題解決評估機制的有效性。

    5)配置管理過程設計

    目的:設計配置管理過程,根據提供的IT服務特性以及IT資產的管理權限,設計配置管理的范圍和顆粒度,梳理IT資產的分類和分級,設計資產的狀態屬性和連接關系屬性,根據工具的配備情況設計配置信息的收集方式,以及配置信息的增、刪、改的活動過程,設計配置信息的考核指標和計算方式。

    該過程須確保供方維護運行維護服務對象的必要記錄,并保證配置數據的可靠性和時效性,關聯支持其他服務過程。

    (1)供方應根據配置管理的過程要求建立以下活動機制。

    • 與配置管理過程一致的活動,包括識別、記錄、更新和審計等。

    • 配置數據庫管理機制。

    • 配置項審計機制。

    (2)配置管理的關鍵指標至少應包括以下特性。

    • 配置管理過程的完整性。

    • 配置數據的準確、完整、有效、可用、可追溯。

    • 配置項審計機制的有效性。

    6)變更管理過程設計

    目的:設計變更管理過程,根據服務模式的特征,定義變更管理的控制范圍,定義變更的分類和分級設計變更控制活動和順序,特別注意變更控制與事件和問題的關聯關系,應與變更控制活動有機結合,關注由變更帶來的連鎖反應,當產生重大變更時可能要重新做服務規劃設計,制訂變更管理考核指標,持續優化過程。

    該過程須確保供方通過管理、控制變更的過程,確保變更有序實施。

    (1)供方應根據變更管理的過程要求建立以下內容。

    • 建立與變更管理過程一致的活動,包括請求、評估、審核、實施、確認和回顧等。

    • 建立變更類型和范圍的管理機制。

    • 對變更完成情況進行統計分析,包括未經批準變更數量及占比、不同類型的變更數量及占比、不成功的變更數量及占比、取消的變更數量及占比、變更關聯的配置數。

    (2)變更管理的關鍵指標至少應包括以下特性。

    • 變更管理過程的完整性。

    • 變更記錄的完整性。

    7)發布管理過程設計

    目的:設計發布管理過程,根據變更管理的設計、工具的配置情況(如備件庫、專用工具、最終軟件庫等)和對IT資產的管理權限,設計發布過管理的范圍、分類、分級和活動順序,如需外部資源協同發布的實施時,還需要設計與外部資源的溝通和約束機制,并寫入OLA或UC中,設計發布管理考核指標、計算方式和回顧機制,關注發布管理與事件管理、問題管理、配置管理的關聯。

    (1)為確保一個或多個變更的成功導入,供方應根據發布管理的過程,要求如下。

    • 建立與發布管理過程一致的活動,包括規劃、設計、建設、配置和測試等。

    • 建立發布類型和范圍的管理機制。

    • 制訂完整的方案,包括發布計劃、回退方案、發布記錄等。

    • 對發布完成情況進行統計分析,包括發布成功率、發布及時率、是否更新配置管理數據庫等。

    (2)發布管理的關鍵指標至少應包括以下特性。

    • 發布管理過程的完整性。

    • 發布過程記錄的完整性、準確性。

    8)信息安全管理過程設計

    目的:設計信息安全管理過程,根據客戶業務特征和服務管理要求,識別服務中的信息安全風險,定義信息安全管理范圍,定義信息安全事件的特征和等級,分析信息安全風險,制訂應對措施,如制度信息安全管理制度、對信息系統做安全加固、采用信息化手段防控、制訂應急預案并定期演練等,并文件化、常態化。

    (1)為確保供方提供符合信息安全要求的服務,供方應根據安全管理的過程要求建立:

    • 建立與安全管理過程一致的活動,包括識別、評估、處置和改進等。

    • 建立與運行維護服務要求一致的信息安全策略、方針和措施。

    (2)安全管理的關鍵指標包括以下特性。

    • 運行維護服務過程中信息的保密性。

    • 運行維護服務過程中信息的可用性。

    • 運行維護服務過程中信息的完整性。

【練習題】

一、單項選擇題

  1. 下列不屬于服務規劃設計主要目的的是( )。

A.設計滿足業務需求的IT服務
B.規劃服務組織架構、人員編制、崗位及任職要求
C.識別和規劃支持服務所需的技術及資源
D.服務方案設計

  1. 下列屬于服務設計關鍵成功因素的是( )。

A.服務成本可以根據客戶需求的不同而進行改變 B.確定相似服務提供時的優先次序
C.獲取新的服務或添加附加客戶的流程及程序 D.把IT資源重新分派到核心業務系統中

  1. 下列對服務級別協議(SLA)描述不正確的是( )。

A.要有一定的成本控制
B.保障IT服務的性能和可靠性
C.降低IT部門的操作成本
D.服務供方與客戶間定義的一種雙方認可的協定

  1. 下列不屬于服務需求識別活動的是( )。

A.服務可用性需求識別 B.網絡安全需求識別

C.價格需求識別 D.信息安全需求識別

  1. 服務級別設定的目標是( )。

A.確保對服務供方所有運營中的服務及其績效以專業一致的方式進行衡量
B.對客戶未成文要求的服務進行有效管理和限制
C.把服務級別設定得恰當,無論是客戶、IT服務供方,還是與他們相關的組織,都會從中受益
D.正確識別供方服務能力,得到足夠的運營級別協議或支持合同的支持

【參考答案】:D A C B A

二、案例分析題
某銀行是中國第一家向社會公眾公開發行股票并上市的商業銀行。經過20年的快速發展,該銀行綜合實力日益增強,自身規模不斷擴大,市場份額與品牌知名度得到不斷提升,為公司客戶搭建起跨時空、全方位的銀行服務體系。
該銀行建行以來,始終堅持狠抓信息化建設,大力開發綜合業務處理系統,不斷創新電子化服務手段,基本實現了業務處理電子化和網絡一體化。在系列改革措施的推進下,該銀行業務轉型穩步進行,風險控制全面加強,資產質量明顯提高,資本實力顯著增強,使得信息化建設成為該銀行自身建設的核心內容。
隨著該銀行業務的不斷壯大與發展,客戶服務請求事件數量的不斷增多,給該銀行
IT部門帶來了極大工作量,由于缺乏統一的運維管理,一旦發生事故,IT內部人員像“救火隊員”一樣四處去“滅火",無法快速定位故障原因,故障不能及時解決,業務部門的意見很大,業務部門往往用影響業務生產與IT部門進行交涉,使IT服務非常被動。為改變IT現在被動局面,經領導決定通過招標的形式確定,“長遠科技”為其提供IT咨詢服務。

問題:
(1)如果你是“長遠科技“負責該項目的項目經理,在服務規劃設計階段,服務目錄設計應具有哪些活動。
(2)請根據案例介紹簡要設計出該項目的服務目錄。
(3)請根據案例介紹簡要設計該項目的服務級別協議(需列出關鍵要素)。
(4)請根據案例介紹該項目應采取哪些服務模式,并寫明原因和服務范圍。

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/web/42932.shtml
繁體地址,請注明出處:http://hk.pswp.cn/web/42932.shtml
英文地址,請注明出處:http://en.pswp.cn/web/42932.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

OpenHarmony4.x 系統模擬器環境

先下載源碼和編譯程序: 首先查看 OpenHarmony4.1源碼下載、編譯,生成OHOS_Image可執行文件的最簡易流程 準備在QEMU模擬器中運行ARM Cortex-M4的輕型開源鴻蒙系統 官方支持的開發板和模擬器種類-編譯形態整體說明OpenAtom OpenHarmony 已支持的示例工…

ArduPilot開源代碼之AP_MSP

ArduPilot開源代碼之AP_MSP 1. 源由2. Library設計2.1 啟動代碼2.2 支持特性2.3 MSP DisplayPort v.s. DJI FPV OSD 3. 重要例程3.1 AP_MSP::init3.2 AP_MSP::loop3.3 AP_MSP::init_backend 4. 實例理解5. 總結6. 參考資料 1. 源由 AP_MSP是處理MSP協議格式的報文數據應用類。…

反向業務判斷邏輯

業務功能需求: 根據id扣減用戶余額 包括:判斷用戶狀態是否正常判斷用戶余額是否充足 正向邏輯: 判斷用戶為正常下,判斷用戶余額充足,進行余額扣減; 》正向邏輯,多重嵌套,代碼不美觀…

??一文帶你入門【NestJS】

??引言 在現代Web開發領域,框架和技術的迭代速度令人咋舌。其中,NestJS作為一款基于Node.js的后端框架,以其卓越的設計理念和強大的功能集,迅速吸引了眾多開發者的眼球。本文將帶你深入了解NestJS的起源、發展,以及…

SpringIOC原理

SpringIOC原理 1.概念 Spring通過一個配置文件描述Bean及Bean之間的依賴關系,利用Java語言的反射功能實例化Bean并建立Bean之間的依賴關系。Spring的IOC容器在完成這些底層工作的基礎上,還提供了Bean實例緩存、生命周期管理、Bean實例代理、事件發布、…

AI提示詞:AI輔導「數學作業」

輔導孩子作業對許多家長來說可能是一件頭疼的事,但這部分工作可以在一定程度上交給AI來完成。 打開ChatGPT4,輸入以下內容: # Role 數學輔導專家## Profile - author: 姜小塵 - version: 02 - LLM: Kimi - language: 中文 - description: 專門為小學生…

加密算法詳解:對稱加密、非對稱加密、Hash算法

對稱加密、非對稱加密和哈希算法是信息安全中的三種主要加密技術,它們各自有不同的特點和用途: 對稱加密(Symmetric Encryption) 工作原理:使用相同的密鑰進行加密和解密。速度:通常非常快,適…

Elasticsearch:Node.js ECS 日志記錄 - Morgan

這是之前系列文章: Elasticsearch:Node.js ECS 日志記錄 - Pino Elasticsearch:Node.js ECS 日志記錄 - Winston 中的第三篇文章。在今天的文章中,我將描述如何使用 Morgan 包針對 Node.js 應用進行日子記錄。此 Morgan Node.j…

包裝器 std::function

使用前&#xff0c;包頭文件&#xff1a;#include <functional> std::function 是 C標準庫 中的一個通用函數包裝器&#xff1b; 它可以儲存、復制、調用任何可調用的對象&#xff0c;包括&#xff1a;函數指針、成員函數、綁定的成員函數、lambda表達式、仿函數等。 1…

Selenium Grid- 讓自動化分布式執行變得可能

什么是 Selenium Grid&#xff1f; Selenium Grid 是 Selenium 的三大組件之一&#xff0c;允許用戶同時在不同的機器和系統上測試不同瀏覽器。 也就是說 Selenium Grid 支持分布式的測試執行。它可以讓你的測試用例在一個分布式的執行環境中運行。 由上圖可見&#xff0c;測試…

linux:基礎知識及命令[圖表]

lsof:查找文件 普通文件、目錄、進程&#xff08;/proc&#xff09;、輸入輸出設備&#xff08;/dev&#xff09;、網絡字節流socket、鏈接文件、管道文件 基本用法 lsof&#xff1a;列出所有打開的文件。lsof /path/to/file&#xff1a;列出打開指定文件的所有進程。lsof -…

大話光學原理:4.散射:瑞利、拉曼、米氏和布里淵

這是一縷柔和的光&#xff0c;在空氣的舞臺上輕盈地跳躍。它悠然自得&#xff0c;在寧靜的空間中緩緩前行。然而&#xff0c;一片細薄透明的介質擋住了它的腳步&#xff0c;它毫無預兆地撞上了這片障礙。在這短暫的接觸中&#xff0c;它被分解成無數微小的粒子&#xff0c;被迫…

增強現實(AR)與虛擬現實(VR)的區別?

隨著科技的飛速發展&#xff0c;增強現實&#xff08;AR&#xff09;與虛擬現實&#xff08;VR&#xff09;技術在各個領域展現出巨大的潛力和應用前景。這兩種技術雖然在體驗和實現方式上有所不同&#xff0c;但都為用戶提供了全新的感知體驗。本文將詳細解析AR和VR的概念、區…

機器視覺/自然語言/生成式人工智能綜合應用實驗平臺-實訓平臺-教學平臺

AIGC是人工智能1.0時代進入2.0時代的重要標志&#xff0c;MIT 科技評論也將Al合成數據列為2022年十大突破性技術之一&#xff0c;甚至將生成性Al(Generative Al) 稱為是AI領域過去十年最具前景的進展。同時&#xff0c;AIGC領域崗位需求數量暴漲。高校方面在人工智能專業與機器…

javascript 處理###分隔的字符串

在 JavaScript 中&#xff0c;可以使用 split 方法將字符串按 ### 分隔成數組。以下是一個示例代碼&#xff0c;展示了如何處理由 ### 分隔的字符串&#xff1a; 示例代碼 // 示例字符串 let str "part1###part2###part3###part4";// 使用 split 方法按 ### 分隔字…

DEJA_VU3D - Cesium功能集 之 122-體元渲染(官方Voxels)

前言 編寫這個專欄主要目的是對工作之中基于Cesium實現過的功能進行整合,有自己琢磨實現的,也有參考其他大神后整理實現的,初步算了算現在有差不多實現小140個左右的功能,后續也會不斷的追加,工作原因可能無法像以前那樣周更2-3篇,但是閑下來還是會不定期的更新,Cesium…

tensorflow張量生成以及常用函數

張量tensor&#xff1a;多維數組&#xff08;列表&#xff09; 階&#xff1a;張量的維數 維數 階 名字 例子 0-D 0 標量 scalar s 1&#xff0c; 2&#xff0c; 3 1-D 1 向量 vector…

How do I format markdown chatgpt response in tkinter frame python?

題意&#xff1a;怎樣在Tkinter框架中使用Python來格式化Markdown格式的ChatGPT響應&#xff1f; 問題背景&#xff1a; Chatgpt sometimes responds in markdown language. Sometimes the respond contains ** ** which means the text in between should be bold and ### te…

Python數據分析-天氣類型預測分析

一、研究背景 近年來&#xff0c;隨著全球氣候變化的加劇&#xff0c;天氣預報和氣象預測變得越來越重要。準確的天氣預測不僅能夠幫助人們做好日常生活的安排&#xff0c;還能在農業生產、防災減災等方面起到關鍵作用。隨著大數據技術和機器學習算法的快速發展&#xff0c;利…

科普文:深入理解負載均衡(四層負載均衡、七層負載均衡)

概敘 網絡模型&#xff1a;OSI七層模型、TCP/IP四層模型、現實的五層模型 應用層&#xff1a;對軟件提供接口以使程序能使用網絡服務&#xff0c;如事務處理程序、文件傳送協議和網絡管理等。&#xff08;HTTP、Telnet、FTP、SMTP&#xff09; 表示層&#xff1a;程序和網絡之…