【正文】 u 為變更進(jìn)行適當(dāng)?shù)姆诸?、為變更分配?yōu)先級等屬性u 檢查事件記錄的處理進(jìn)度，保持與事件報告人的聯(lián)系，適時通知事件處理進(jìn)展u 確定并分析變更需求和內(nèi)容u 填寫變更請求單并提交給相關(guān)相應(yīng)變更主管戶的基本信息。q 和配置管理流程的關(guān)系變更管理涉及到的配置改變應(yīng)當(dāng)在配置管理數(shù)據(jù)庫中得到體現(xiàn)，改變的數(shù)據(jù)可能包括配置項、配置項間的關(guān)系或配置項的某些屬性 ；變更的評估需要從配置管理數(shù)據(jù)庫中獲取相關(guān)的信息進(jìn)行分析。待決N變更請求被解決，不能重返待決狀態(tài)。 當(dāng)前狀態(tài)為已解決時狀態(tài)變化為合法性事件描述相關(guān)信息已分派的N變更請求被解決，不能重返已分派的狀態(tài)。已關(guān)閉N變更已執(zhí)行，不能再取消變更請求 當(dāng)前狀態(tài)為待決時狀態(tài)變化為合法性事件描述相關(guān)信息已分派的Y請求在待決狀態(tài)并且該請求尚未經(jīng)過審批人審批時，可以被重新分派到其他流程控制員通知新的變更主管準(zhǔn)備處理請求，并告知請求提交人請求的新的分派結(jié)果計劃中的Y請求被審批人駁回，流程控制員可以重新制訂變更執(zhí)行計劃。待決Y對于變更請求，變更控制員可根據(jù)實際情況設(shè)置狀態(tài)到待決，以了解更多的變更信息通知請求提交人，準(zhǔn)備更多的變更信息已解決N變更流程未執(zhí)行。已關(guān)閉N變更流程沒有執(zhí)行，不會被關(guān)閉 當(dāng)前狀態(tài)為已分派時狀態(tài)變化為合法性事件描述相關(guān)信息已分派的Y接收到變更請求的變更控制員可以將該請求轉(zhuǎn)給其他的控制員通知新的變更主管準(zhǔn)備處理請求，并告知請求提交人請求的新的分派結(jié)果計劃中的Y接受變更請求,設(shè)定變更計劃進(jìn)行評估變更啟動N沒有進(jìn)行計劃評估的變更請求不會進(jìn)行實施啟動進(jìn)行中的工作N沒有進(jìn)行計劃評估的變更請求不會進(jìn)行實施待決Y對于變更請求，變更控制員可根據(jù)實際情況設(shè)置狀態(tài)到待決，以了解更多的變更信息通知請求提交人，準(zhǔn)備更多的變更信息已解決N變更流程未執(zhí)行。處理中變更請求正在處理當(dāng)中等待流程控制員等待變更請求審批或變更處理過程中需要收集進(jìn)一步信息，信息可能來自請求提交用戶或其他。為了提供足夠的控制使風(fēng)險最小化，同時允許變更在流程中快速的處理，變更管理定義了二種不同的執(zhí)行路徑，分別為：? 標(biāo)準(zhǔn)? Emergency執(zhí)行路徑用途標(biāo)準(zhǔn)規(guī)劃中的變更。若結(jié)果不夠滿意，將執(zhí)行后續(xù)工作。一旦獲得實施授權(quán)，則根據(jù)日程安排實施變更。 評估amp。 安排IT和業(yè)務(wù)審批完成后，RFC納入變更安排，該安排結(jié)合多個變更以對生產(chǎn)環(huán)境的影響最小化。 流程圖附圖12. 變更流程 該流程從一個變更需求開始，終止于變更的結(jié)束，包含下列子流程： 啟動、接受和分類變更請求 (RFC) 可根據(jù)用戶的需求由內(nèi)部啟動（通過IT專家、配置管理流程、事件管理流程）。 變更管理的差距分析 目前沒有變更流程，人員對變更管理沒有系統(tǒng)的概念。因為變更管理將涉及到多個部門，在本期項目中，流程只覆蓋到XX內(nèi)部。 CAB通過開會討論等手段來評估變更請求(RFC)的：q 潛在風(fēng)險和影響q 實施變更需要的資源q 是否批準(zhǔn)變更q 如果批準(zhǔn)，什么時間實施CAB也負(fù)責(zé)變更實施后的回顧以考察：q 變更是否成功?是否產(chǎn)生其他副作用?q 實際所用的資源和預(yù)期的是否一致?批準(zhǔn)后，變更將進(jìn)入計劃，測試/構(gòu)建和實施階段。非常規(guī)變更指需要經(jīng)過其他部門或人員進(jìn)行審批流程，方可實施的變更。變更管理應(yīng)該由管理工具來支持，管理的范圍可包括軟件，硬件，網(wǎng)絡(luò)設(shè)備和文檔等的變更。q 和變更管理流程的關(guān)系問題管理流程的解決方案常常需要通過變更管理流程來完成，因此問題管理將會提出變更申請給變更管理流程。7. 關(guān)閉 一旦找出問題根本原因，并實施了解決方案，確認(rèn)已解決了問題，問題記錄可以關(guān)閉。4. 根本原因分析 被分派的小組人員將調(diào)查問題以期找出其原因，制定解決方案、變通方法或提出預(yù)防性措施，以消除產(chǎn)生原因，或在重發(fā)時使其影響力最小化。 在系統(tǒng)中生成問題記錄并把所有相關(guān)事件與此記錄關(guān)聯(lián)起來 問題管理流程總圖附圖11. 問題管理流程其中，紅色虛線標(biāo)識的部分不在本期項目中實施。 沒有事件與問題的關(guān)聯(lián)，不能評估出該問題的嚴(yán)重性，影響程度。 設(shè)立虛擬問題經(jīng)理、問題分析專家角色并根據(jù)目前現(xiàn)有人員進(jìn)行人員角色匹配。問題通常具有以下特征中的一個或全部：216。 對于趨勢性事件的分析，形成問題。 問題流程 問題的理解問題是一個或幾個已暫時處理但根本原因尚不明確的事件， 許多事件往往是由同一個問題引起的。下表列舉了應(yīng)用所需的角色，組的ID編號和具體細(xì)節(jié)將在系統(tǒng)設(shè)計階段定義。知識經(jīng)理u 負(fù)責(zé)將支持人員處理完成事件的解決方案進(jìn)行審批，并加入知識庫u 定期查看統(tǒng)計報表，對知識使用狀況進(jìn)行評估事件經(jīng)理u 作為事件管理流程的負(fù)責(zé)人，負(fù)責(zé)制定流程的規(guī)則、策略、步驟.n 事件生命周期中的幾種狀態(tài)n 事件的分類n 根據(jù)運維人員的實際技能與事件分類進(jìn)行匹配，確定合適的人處理對于的事件。u 根據(jù)優(yōu)先級的設(shè)定規(guī)則，及時提供有效解決方案u 與其他小組合作，確定解決方案u 必要時進(jìn)行具體的解決方案的實施u 已解決的事件轉(zhuǎn)回幫助臺，由幫助臺關(guān)閉事件u 如果二線認(rèn)為不能在規(guī)定的解決時限內(nèi)解決這個事件，應(yīng)當(dāng)將事件進(jìn)行升級到主管領(lǐng)導(dǎo)及事件經(jīng)理。u 對于一線支持人員轉(zhuǎn)派過來的事件信息進(jìn)行確認(rèn)，必要時應(yīng)直接聯(lián)系用戶詢問相關(guān)情況。負(fù)責(zé)提供對一線支持人員以及地區(qū)管理員無法解決的問題進(jìn)一步進(jìn)行調(diào)研，找出解決方案并盡快恢復(fù)服務(wù)。應(yīng)當(dāng)將之前進(jìn)行事件解決的過程和測試結(jié)果記錄在流程中供二線人員參考。u 負(fù)責(zé)記錄用戶直接提交的事件請求并進(jìn)行分派處理。桌面應(yīng)用可以直接進(jìn)行處理。 二線支持組：客服系統(tǒng)維護(hù)組、系統(tǒng)主機(jī)維護(hù)組、數(shù)據(jù)庫支持組、安全支持組、網(wǎng)絡(luò)支持組、存儲支持組等252。r 技能設(shè)置的建議 根據(jù)目前事件的處理狀況及XX整合后運維人員可能發(fā)生的變化，建議人員技能組的劃分以此為依據(jù)。 支持人員分屬于不同的組，一個支持人員可以有多項技能，即屬于多個技能組。 事件流程角色、技能組和權(quán)限定義 服務(wù)支撐平臺設(shè)定的目的之一是要將人員技能進(jìn)行合理劃分。 事件管理流程與其他管理流程間的關(guān)系附圖10. 各流程間關(guān)系q 和問題管理流程的關(guān)系事件管理流程將提供事件的詳細(xì)、精確的記錄信息給問題管理流程來定位問題及分析問題的趨勢，以及在優(yōu)先級為緊急的事件解決并恢復(fù)服務(wù)后做為問題進(jìn)行進(jìn)一步的分析和處理。關(guān)閉N客戶未撤銷請求，事件不能被關(guān)閉 當(dāng)前狀態(tài)為已解決時狀態(tài)變化為合法性事件描述相關(guān)信息新建N新建確定為初試值，不可逆已分派Yes客戶不認(rèn)可解決方案，重新打開請求通知被分派的組成員準(zhǔn)備處理請求，并告知請求提交人請求的重新分派結(jié)果，同時通知經(jīng)理請求被重新打開進(jìn)行中的工作N請求被重新分派狀態(tài)。 當(dāng)前狀態(tài)為待決時狀態(tài)變化為合法性事件描述相關(guān)信息新建N新建確定為初試值，不可逆轉(zhuǎn)已分派Y相應(yīng)的支持人員處理請求過程中，可以重新將請求分派給其他人員進(jìn)行處理通知被分派的組成員準(zhǔn)備處理請求，并告知請求提交人請求的重新分派結(jié)果，同時通知經(jīng)理請求被重新分派進(jìn)行中的工作Y當(dāng)所有待決狀態(tài)下的問題都被解決后，支持人員可以開始正式處理請求。通知被分派的組成員事件請求被撤銷。進(jìn)行中的工作N事件請求已被撤銷，處理流程結(jié)束。待決Y表明接單人響應(yīng)請求，在請求處理過程中發(fā)現(xiàn)相關(guān)信息需要進(jìn)一步確認(rèn)或其他關(guān)聯(lián)信息已解決Y問題解決并等待客戶最終確認(rèn)通知請求提交人問題已解決，需要進(jìn)行結(jié)果確認(rèn)。通知被分派的組成員可以停止事件處理操作；同時通知事件請求提交人事件請求已被撤銷。 狀態(tài)圖表附圖9. 事件狀態(tài)表 狀態(tài)轉(zhuǎn)移表狀態(tài)新建已分派進(jìn)行中的工作撤銷待決已解決關(guān)閉新建 YNNNYN已分派NYYYYYN進(jìn)行中的工作NYYYYN撤銷NNNNNN待決NYYYYN已解決NYNNNY關(guān)閉NNNNNN 狀態(tài)轉(zhuǎn)移 當(dāng)前事件狀態(tài)為新建時狀態(tài)變化為合法性事件描述相關(guān)信息已分派Y用戶提交事件請求，分派到相應(yīng)的處理人員或組通知被分派的組成員準(zhǔn)備處理請求，并告知請求提交人請求的分派結(jié)果進(jìn)行中的工作N未經(jīng)過分派的過程，是不可能處于正在處理的狀態(tài)的。事件請求結(jié)束后應(yīng)由系統(tǒng)自動派生本次服務(wù)的滿意度調(diào)查，并以郵件方式發(fā)送給事件提交者，提交者填寫完畢后可以直接回復(fù)到系統(tǒng)中，由系統(tǒng)對調(diào)查結(jié)果進(jìn)行歸檔并作報表統(tǒng)計數(shù)據(jù)源。解決措施一旦成功，可以根據(jù)事件的處理過程難度、發(fā)生頻率等因素判斷生成知識案例庫的解決方案，通過提交知識沉淀有效經(jīng)驗。對于服務(wù)故障，則需要確立該故障的優(yōu)先級、影響度、緊急度和分類。此步驟的目的是在事件發(fā)生時快速準(zhǔn)確地發(fā)現(xiàn)故障，以協(xié)助事件的診斷和解決并通知相關(guān)支持人員。 設(shè)立事件自動關(guān)閉時限，在事件處理完成后，沒有得到客戶確認(rèn)響應(yīng)一段時間后，事件可以實現(xiàn)自動關(guān)閉。當(dāng)電話、Web事件同時進(jìn)入幫助臺，根據(jù)優(yōu)先級進(jìn)行決定受理順序，同優(yōu)先級以創(chuàng)建時間作為受理順序 面對幫助臺技能方面存在的壓力，本期統(tǒng)一幫助臺可以由現(xiàn)有XX幫助臺部分人員和客服支持幫助臺人員共同組成，通過語音技能設(shè)定，分揀來自客服座席的支持號碼給客服系統(tǒng)代維人員，閑時也可以支持其他IT客戶端問題 各管理員歸納一些常見事件的描述信息給幫助臺，幫助服務(wù)臺人員熟悉業(yè)務(wù)的基本概念。如果用戶遵循了我們的規(guī)范，卻發(fā)現(xiàn)事件解決的效率降低了，在系統(tǒng)該啟用的時候很容易出現(xiàn)這樣的現(xiàn)象，如何規(guī)避這樣的風(fēng)險？ 固有習(xí)慣事件處理方式的克服。 因為沒有流程，很多人并不清楚自己在事件處理中應(yīng)當(dāng)擔(dān)當(dāng)?shù)慕巧鞘裁矗?缺乏知識共享，導(dǎo)致處理一些常規(guī)突發(fā)事件時必須找到某個人才可能將事件解決，導(dǎo)致事情延誤。 事件管理的差距分析目前來說，除了桌面維護(hù)部分有一個hp openview helpdesk流程外，其他各崗位的事件處理都沒有流程系統(tǒng)進(jìn)行約束，從而造成了以下的一些問題： 雖然設(shè)立了XX服務(wù)熱線，但其功能僅僅局限在XX集團(tuán)內(nèi)部的桌面系統(tǒng)的維護(hù)上，面對網(wǎng)絡(luò)、系統(tǒng)數(shù)據(jù)庫等的事件處理，并沒有發(fā)揮統(tǒng)一受理的職能。 實現(xiàn)突發(fā)事件的緊急程度劃分，根據(jù)事件緊急程度不同，響應(yīng)時間不同，解決時間不同，升級機(jī)制不同。附圖7. 事件處理閉環(huán)流程 設(shè)立幫助臺、一線支持人員、二線支持人員、事件經(jīng)理等流程角色，并將現(xiàn)有運維人員與流程角色進(jìn)行匹配。 本期事件管理實現(xiàn)的目標(biāo)雖然XX的主要服務(wù)對象是XX集團(tuán)內(nèi)部，如何確立XX部的標(biāo)牌服務(wù)形象，同時為XX的整合提供更好的運維支持，在現(xiàn)階段，我們需要確立以下目標(biāo)： 確立服務(wù)熱線的標(biāo)牌，在XX集團(tuán)內(nèi)部實現(xiàn)有IT事件發(fā)生找XX部的局面。不是所有的突發(fā)事件都由用戶產(chǎn)生，監(jiān)控管理平臺產(chǎn)生的告警也可引發(fā)事件。 事件的理解事件可以分為：突發(fā)事件和服務(wù)請求。經(jīng)廠家求證，Remedy本身并不提供與XX現(xiàn)有呼叫中心的成熟接口套件，需要另行開發(fā)。如圖：附圖6. 服務(wù)臺模式方案四230。換句話說原XX服務(wù)臺職能變更為XX部對外統(tǒng)一受理服務(wù)臺230。 設(shè)置統(tǒng)一服務(wù)臺熱線，現(xiàn)有呼叫中心利舊利用現(xiàn)有排隊機(jī)、IVR、CTI設(shè)置一個XX部對外統(tǒng)一服務(wù)熱線，如1234，或?qū)F(xiàn)有XX號碼設(shè)置為統(tǒng)一服務(wù)熱線，對撥打用戶來說收聽相應(yīng)的IVR語言留言進(jìn)入不同的技能支持組，對外既是統(tǒng)一受理服務(wù)臺；虛擬服務(wù)臺由實體技能組來組成，各技能組權(quán)限獨立，即各技能組受理并記錄的工單，只有各幫助臺技能組察看和管理。如圖：附圖5. 服務(wù)臺模式方案三230。換句話說原XX服務(wù)臺職能變更為XX部對外統(tǒng)一受理服務(wù)臺230。 方案三230。XX服務(wù)臺將現(xiàn)有HP Openview摒棄，使用新的Remedy流程平臺處理事件，‘客戶端問題’從受理到處理各環(huán)節(jié)均在Remedy流程平臺上實現(xiàn)；‘其他系統(tǒng)問題’全部記錄在本期Remedy流程平臺系統(tǒng)上，但不依賴于平臺處理，分派處理等環(huán)節(jié)不在系統(tǒng)中實現(xiàn)，閉環(huán)于幫助臺，對申告用戶及外部部門來說是透明的。重新調(diào)整的具備多種應(yīng)用受理的XX熱線人員、客服系統(tǒng)支持人員構(gòu)成了信息化部統(tǒng)一服務(wù)臺。 缺點由于其他系統(tǒng)問題并不是頻發(fā)，建立初期服務(wù)臺受理量較低；并未改善客戶端支持及客服系統(tǒng)支持等日常支持的服務(wù)水平；如配備新人須具備基本的IT系統(tǒng)技能，否則在設(shè)立之初可能會用戶造成服務(wù)不夠?qū)I(yè)的印象178。 新建其他系統(tǒng)問題服務(wù)臺支持人員使用本期流程平臺系統(tǒng)終端支持、客服支持仍采用現(xiàn)有支持方式，在本期不做改變。 設(shè)置統(tǒng)一服務(wù)臺熱線，現(xiàn)有呼叫中心利舊利用現(xiàn)有排隊機(jī)、IVR、CTI設(shè)置一個XX部對外統(tǒng)一服務(wù)熱線，如1234，或?qū)F(xiàn)有XX號碼設(shè)置為統(tǒng)一服務(wù)熱線，對撥打用戶來說收聽相應(yīng)的IVR語言留言進(jìn)入不同的技能支持組，對外既是統(tǒng)一受理服務(wù)臺230。 運維服務(wù)管理平臺能夠接受來自于監(jiān)控管理平臺的配置信息，且當(dāng)運維服務(wù)管理平臺的配置信息發(fā)生變動后，能夠?qū)⒃撟儎有畔l(fā)送到監(jiān)控管理平臺中。這也是充分契合XX集團(tuán) “服務(wù)編織未來”的企業(yè)理念，是XX集團(tuán)對內(nèi)部及外部的運維支持趨近于統(tǒng)一的明智之選。但各IT組件負(fù)責(zé)人已經(jīng)意識到配置管理的重要性，在配置管理推廣上應(yīng)會起到正面的作用，但仍需加強(qiáng)運維人員的配置管理理念。 優(yōu)勢與主要問題：配置管理的工作在實際工作并未開展，各IT組件負(fù)責(zé)人掌握一部分配置信息，對部分關(guān)鍵IT組件有統(tǒng)一的命名規(guī)范和標(biāo)簽。但上述所有的管理工作主要依賴于系統(tǒng)負(fù)責(zé)人