{售后服务}ITILv3服务运营篇中文

《{售后服务}ITILv3服务运营篇中文》由会员分享，可在线阅读，更多相关《{售后服务}ITILv3服务运营篇中文（30页珍藏版）》请在金锄头文库上搜索。

1、ITIL v3-服務運營篇,ServiceStrategy,Demand Management,Service Portfolio Management,ServiceDesign,Financial Management,Service Catalog Management,Service Level Management,Availability Management,Capacity Management,Supplier Management,Information Security Management,IT Service Continuity Management,Transit

2、ion Planning & Support,Change Management,Configuration Management,Release Management,Service Validation & Testing,Evaluation,Knowledge Management,Event Management,Incident Management,Request Fulfillment,Problem Management,Access Management,Service Desk,Technical Management,IT Operations Management,A

3、pplications Management,Service Measurement,Service Reporting,Service Improvement,目的：是為了交付已商定的服務級別給客戶和用戶，並且管理支持服務交付的應用程序、技術和框架。 服務：是為業務實現價值，服務運營的人員有責任保証該價值是否實現。 對於服務運營、平衡目標間的沖突是非常重要的： 1、內部IT與外部業務的觀點 2、穩定與響應 3、服務質量與服務成本 4、被動與積極主動的行動 服務運營人員需盡可能使兩者保持平衡，過分強調某一部分都會使服務的質量降低。,概 述,Service Operation,Event、Inc

4、idents and Service Request,Incidents,Event,Service Desk,Service Request,Incident management（事故管理）,事故 ( Incident ) 是指對一項IT服務或一項IT服務品質減少的非計畫中斷。 事故管理流程的主要目標是根據服務級別協定的要求，在盡可能小地影響客戶和使用者業務的情況下盡可能快地將服務恢復到“正常狀態” 。,2,2,2,2,3,緊急度1,影響度1,1,用戶能承受的等待時間,“主動告知”,事故管理流程： 事故由技術員工報告和記錄，但並不是所有的事件都是事故，許多的事件並不與中斷相關，而僅是正常運

5、營指標或一些簡單的資訊。儘管事故和服務請求都報告給服務台，但兩者並不相同， 服務請求並不代表協定服務的中斷，而是滿足客戶需要的方法，當然也可能是SLA中協定目標。 經常發生的故障建立“故障模型”。（email不能收發） 故障單（狀態ing）（選擇、填空、論述）（字段）,事件管理,事件(Event)可被定義為任何可察覺和可識別的，對 IT 基礎設施管理或者 IT 服務造成影響和背離的重要現象。事件通常由 IT 服務、配置項或者監控工具產生。 事件管理流程的目標是為了確保正常運營而進行的對 IT 基礎設施中發生的所有事件進行監控的流程，事件管理也負責對例外情況進行偵測並進行必要的升級。 有效的服務

6、運營需要對IT 設施運行狀態的及時掌控和任何對服務偏移的識別，這依賴於有效的監控管理系統。 事件管理流程用於需要被控制和可自動化的服務管理的各個方面。事件管理的監控範圍包括配置項，環境條件（如，機房煙火的監測） ，軟件許可和使用情況監控，安全及標準活動（如，對應用或對伺服器操作行跟蹤） 。 事故（Incident）:事故往往來自多方的輸入，包括來自事件管理的輸入、最終用戶的直接反饋。 而事件的來源通常是自動化的檢測工具、系統，於是IT部門便有可能在最終用戶發現之前首先發現問題。,Informational,Warning,Exception,Alert,事件管理流程圖,服務請求,該流程主要針對

7、“服務請求”類事件，指的是IT 部門向用戶提供的一系列不同種類的普通的需求，這些請求大部分可以分為幾類: 一類是低風險、經常發生且成 本低的微小變更；比如重置口令，對某個特殊的工作站進行額外軟體安裝的請求等；另一類為資訊諮詢請求。因為這些請求是經常發生、低風險，因而需要採取一個 單獨的流程來進行管理，而不是混雜于正常的事件和變更管理流程，變成一種累贅和障礙。 請求實現流程的主要目標是： 對於某些預定義的申請和需求，為用戶提供一個管道來獲得這些標准服務； 為客戶和使用者提供服務請求管理流程服務和程式資訊； 獲得和交付請求的標準服務元件； 協助處理一般資訊、抱怨或者投訴。,服務請求流程圖,問題管理

8、,問題：是一個或多個不知原因的事件。 問題管理流程的主要目標是預防問題和事故的再次發生，並將未能解決的事故的影響降低到最小。 事故管理關注解決事件的速度。 問題管理強調找事件出根源，定制解決方案預防再次發生。 問題管理與知識管理，以及諸如已知錯誤資料庫等工具有著緊密聯繫 問題管理流程由兩個主要類型的流程： 被動問題管理是服務運營通常執行部分 主動問題管理是由服務運營發起的，但通常是由服務改進驅動的 重復發生的事件或重大事故一般升級為問題管理。 在尚未查明事故產生的原因前，事故所對應的潛在原因被稱為問題，而找到事故產生的根本原因後，問題就成為一個已知錯誤，隨後可以提出一個變更請求來消除該已知錯誤

9、和防止類似事故再次發生。,Problem,Workaround,Known Error,RFC,Solution,問題管理指標,下列指標應該用來判斷問題管理有效性和效率： 一段期間問題總數量 百分比的問題，解決的SLA目標（及百分比是沒有） 超出目標解決時間問題的數目。（用百分比表示） 未關閉問題數量和發展趨勢（靜態，減少或增加） 處理問題的平均成本 問題的數目（打開和關閉和積壓） 有多少已知錯誤添加到已知錯誤資料庫（KEDB） 已知錯誤資料庫（KEDB）準確程度的百分比 主要問題評價順利完成的百分比，並列出明細分類：處理時間，影響的嚴重性，緊急度和優先級。,訪問管理,訪問管理流程是授權給合適

10、的使用者合理的使用服務，同時也限制未授權使用者的訪問。訪問管理也被稱為許可權管理或者身份管理。 訪問管理流程提供使用者權限能夠使用一項或一組服務。因而，它是對安全和可用性管理定義的政策和行動的執行。 訪問管理流程是可用性和資訊安全管理有效地執行。訪問管理不是一個單獨的職能，所有的技術和應用程式管理職能都應該執行該流程。為了能對訪問管理的協調有 一個單一控制點，經常由運作管理或服務台來控制。訪問管理也能由服務台的服務請求發起。 訪問管理流程的主要活動如下： 訪問請求 驗證： 許可權提供 監控身份狀態 記錄和跟蹤訪問 移除或限制許可權 組策略,服務台(Service Desk)在用戶支持方面扮演了

11、重要的角色。一個成熟的服務台可作為其他IT 部門的前臺，能夠在無需聯繫專家的情況下處理一些客戶詢問。對於使用者來說，服務台為他們提供了聯繫IT 部門的單一聯繫點，從而可以確保他們能找到合適的支持人員來幫助解決其問題或請求。換句話說，使用者再也不需要不停地尋找能夠解決其問題的支持人員。通常， 服務台也負責跟蹤來自IT 部門內部的呼叫。 “服務台類似一個路由器+應答機+滅火器+發布機”服務台目標目標：儘快恢復使用者正常服務 記錄事件、服務請求、分配優先順序 提供一線調查和診斷 解決事件、服務請求 向用戶通報進展 關閉解決事件、服務請求及其他請求 開展用戶滿意度調查 更新CMS,服務台,服務台結構：

12、有多種選擇。常見的方式包括： 集中式服務台：作為所有用戶的單一聯繫點，可能還單獨設立了一個服務台來處理使用者在業務應用系統方面的問題。 本地式：服務台分佈在多個地方。通常，將服務台劃分為多個本機服務台將會導致更加難以管理。 虛擬式服務台：並沒有實質性的位置，這是由於使用了通信技術。 這裡具體討論集中式服務台。 集中式服務台是企業最實用最多的一種類型。 這種方式可以與運營組織的其他功能組織緊密結合使用以方便服務台和運營管理(生產、運營)之間的直接溝通，這裡所指的生產(Production)包括網絡管理、電腦運營等。這種直接溝通可以保證在出現服務台不能立即解決錯誤的情況下仍然能夠作出快速回應。,服

13、務台角色 服務台經理 服務台主管 服務台支援 超級用戶 服務台對技術要求電話： 自動呼叫分配系統 電腦電話介面系統：自動從CMS記錄中識別呼叫者和調用詳細資訊 VOPI：降低國際和遠端使用者通訊成本 統計軟體：統計收到的號碼、回應時間、呼叫處理率、呼叫失敗率、平均話時間 支援工具 已知錯誤資料庫 診斷腳本 網頁自助介面 遠端工具 ITSM工具的IT服務連續性計畫,服務台設立時需要考慮的幾個方面 客戶服務的期望 業務需求，如預算，呼叫回應時間等 大小，相對年齡，設計和複雜的IT基礎設施和服務目錄 - 例如，事故數量和類型，定制的程度相比，標準的現成軟體部署等 支援的客戶和使用者數量，及其他如有關

14、的因素： 語言種類、技能水準 事件和服務請求類型（和適當的RFC種）：各類型呼叫所需的時間期限；內部或外部的專業知識要求 ；事故、服務請求的數量和類型 滿足需求所要提供的支援，包括： 時間範圍、非工作時間支援、支援時區、現場支持、移動的時間與地點、工作時間模式、服務等級目標 服務台反應類型：電話； E-mail/fax/voice郵件/視頻；物理席位；線上訪問/控制 訓練等級 現有技術的支援（如電話系統，遠端支援工具等） 工作人員的現有技能水準 服務台人員所應具備的技能水準 關於所需的技能水準決定往往是由目標；解決時間；複雜性和業務的代價。一般來說，目標時間越短，成本更高，因為需要更多的資源。

15、可以通過提供有效 的基礎知識；診斷腳本和集成支援工具；培訓和提高認識，使第一線解決率逐步增加。服務台人員應具備以下技能： 人際技巧，如電話技巧，溝通技巧，積極傾聽和客戶服務培訓。 商業意識：該組織的業務領域，驅動，結構，優先事項等具體知識 服務意識：對企業關鍵IT服務 技術認識（和更深入的技術培訓到適當的水準，這取決於尋求解決問題的比率） 提供的支援程度而定，一些診斷技能 支援工具和技術 意識培訓和新系統上線前培訓 程式和流程 打字技能,應對服務台建立衡量指標來定期考核服務台的工作效率與品質如何正確的選擇考核指標指標包括：一線解決率： 服務台第一次接觸得到解決的比率，服務台一線單獨解決比率，

16、一線與二線聯合解決的比率 一線解決事件平均時長 事件升級平均時長 服務台處理事件平均成本 服務台費用/受理數量計算受理成本。但不能反應不同類型事件受理的成本。可用於規劃 服務台總費用與總受理時間計算通話成本。 SLA或客戶期望時間內解決事件比率 審查、關閉已解決呼叫的平均時長 日或周呼叫接通失敗的數量與平均通話量來決定員工數量 總結與思考 問題：服務台受理數量上升，是工作存在不穩定性，還是服務台受到認可使用使用者上升。在選擇指標時不應單方面的去考慮問題。 關注：應關注服務台一線人員培訓和流失的問題。,服務台指標,需求,開發/採購,上線,硬件/網絡,日常維護,Application層,Application/technical層,Application/technical層,technical層,Technical/Operations層,對於IT運營來說IT服務的管理系統是必須的。 IT運營管理的技術總需求 自助：向使用者提供自助服務相當有用，利用一些網頁形式提供一個自助服務範圍和服務要求的功能表並與後繼流程連接 工作流：工作流程是對流程預先定義和控制。事先定義職責、活