事件管理流程設(shè)計樣例

信息中心事件管理流程業(yè)務需求文檔日期:2021-11-26文檔版本:V0.1目錄事件管理流程業(yè)務需求文檔 1介紹文檔簡介本文介紹XXXX信息中心事件管理流程和對工具的業(yè)務需求，供參與信息中心IT運維管理系統(tǒng)事件管理流程模塊的開發(fā)和測試人員使用。文檔目的為了保證即將建立的“IT運維管理系統(tǒng)〞符合XXXX信息中心建立全省一體化協(xié)同運維體系的要求，本文對“IT運維管理系統(tǒng)〞中的事件管理模塊的業(yè)務需求進展細化。事件管理流程以確保在故障發(fā)生后盡快地恢復效勞，減小對業(yè)務的影響。事件管理流程關(guān)注快速地解決故障現(xiàn)象而非查找故障背后的根本原因。前提與假設(shè)讀者應該了解ITIL，并對事件管理流程具有根本的技能。文檔構(gòu)造本文由以下幾個章節(jié)組成：第一章，“介紹〞，描述了本文的適用對象、組織，以及相關(guān)術(shù)語。第二章，介紹“事件管理流程〞的業(yè)務邏輯，定義了總體流程，詳細流程，流程步驟、角色及職責、業(yè)務規(guī)則、事件單代碼、流程衡量指標。第三章，介紹“事件管理流程〞的工具功能需求以實現(xiàn)其業(yè)務邏輯，從工具用戶特點、工單流程、與其他流程關(guān)系和流程評估和改良四個方面闡述。第四章，介紹效勞臺構(gòu)造，省市效勞臺邏輯及聯(lián)動模式，及為實現(xiàn)該種模式效勞臺業(yè)務邏輯的工具功能需求。術(shù)語為方便相關(guān)人員對事件管理流程的理解，下表對事件管理流程中涉及的術(shù)語進展解釋。名詞解釋ITIL(ITInfrastructureLibrary)是英國政府在1987年制定的有關(guān)IT效勞管理的最正確實踐，現(xiàn)已成為事實上的IT管理標準。事件管理流程ITIL流程之一，事件管理負責處理IT事件和用戶請求。它的目的是盡快恢復被中斷或受到影響的IT效勞，是以快速解決故障現(xiàn)象為目的，而不在于查找根本原因。IT效勞XXXX省局信息中心和地市信息科提供給全省稅務系統(tǒng)業(yè)務部門的IT支持效勞內(nèi)容。事件不包含在標準效勞操作之內(nèi)，導致或可能導致效勞中斷或效勞質(zhì)量降低的事件。范圍包括XXXX信息中心維護范圍內(nèi)的所有與IT根底架構(gòu)和應用系統(tǒng)相關(guān)的故障、咨詢和效勞請求。事件單事件在流程管理系統(tǒng)中的數(shù)據(jù)記錄。解決方案是指針對某一個或某一類已找到根本原因的問題，提出的解決問題的最終方案。變通方法〔也稱臨時措施〕是指解決事件的臨時修復方法或技術(shù)，目的是使用替代措施暫時恢復SLA約定的效勞，防止事件繼續(xù)對客戶的業(yè)務產(chǎn)生影響，該事件的永久解決措施有賴于對該事件潛在問題的最終解決。IT用戶XXXX省局信息中心和地市信息科的效勞對象。監(jiān)控效勞臺監(jiān)控效勞臺是信息中心為用戶提供效勞的唯一接口，是全省一體化協(xié)同運維體系中的重要組成局部。監(jiān)控效勞臺的主要工作內(nèi)容是記錄和受理事件內(nèi)容，通過知識庫提供初始支持，或通過功能型升級到對應的運維組幫助用戶恢復到正常工作狀態(tài)。事件分析員進展事件處理的支持人員，通常對應信息中心的二線或三線支持人員。事件經(jīng)理負責協(xié)調(diào)和管理事件管理流程的各項活動。運維辦事件經(jīng)理流程所有者，負責對流程的審計和評估，持續(xù)改良該流程。CIConfigurationitem配置項RFCRequestforchange變更請求單CMDB配置管理數(shù)據(jù)庫

事件管理流程流程概述XXXX事件管理流程包括地市事件處理和省局信息中心事件處理兩個局部。整個流程、執(zhí)行步驟和各步驟執(zhí)行的順序參見流程概覽圖。這個流程旨在確保全省所有與省級集中信息系統(tǒng)相關(guān)的事件得到有效記錄和跟蹤，使事件能在最短的時間內(nèi)得到解決，并為問題管理等其它效勞管理流程提供相關(guān)信息。要到達這個目標的重點在于：各地市信息科首先對事件進展有效記錄和過濾，如果本級不能處理，則確保升級至省局的事件單信息完整和準確；地市和省局信息中心效勞臺準確分類分級事件；準確的將故障單分派給后臺技術(shù)支持組或人員；確保用戶對于事件的解決方案是滿意的。事件管理流程由事件驅(qū)動，關(guān)注事件的響應速度以盡快恢復業(yè)務運營。流程步驟描述事件記錄〔地市〕描述:事件的記錄是事件管理流程的起點。所有用戶報告或系統(tǒng)產(chǎn)生的IT事件都必須從這個步驟開場。該步驟的目的是快速、準確地探測和捕捉到在IT生產(chǎn)環(huán)境中發(fā)生的錯誤。除此以外，該活動也是其它用戶相關(guān)請求的入口，諸如信息咨詢、效勞請求。本步驟的重點是準確、完整地采集創(chuàng)立一個事件單所需的必要信息。流程主要內(nèi)容:輸入：任務：輸出：事件驅(qū)動輸入：來自于用戶的請求〔提交方式：、郵件、Web〕運維人員主動發(fā)起的事件0.11發(fā)起請求0.12識別并驗證用戶信息0.13信息充分性判斷0.14進一步提供信息0.15新事件判斷0.16更新相關(guān)事件單0.17記錄新事件單已創(chuàng)立的事件單已更新的事件單過程環(huán)節(jié):0.11發(fā)起請求執(zhí)行者：用戶用戶向所在地市信息科效勞臺提交事件請求。用戶提交事件請求的方式可以有多種：通過向效勞臺提交請求；通過web網(wǎng)頁形式向運行部提交請求；通過電子郵件提交請求；0.12識別并驗證用戶信息執(zhí)行者：地市效勞臺承受用戶的事件報告。提示：建議通過統(tǒng)一工作平臺用戶管理，建立客戶信息庫以提高識別和驗證效率；提示：建議通過統(tǒng)一工作平臺用戶管理，建立客戶信息庫以提高識別和驗證效率；可使用號碼等作為用戶的唯一識別；在發(fā)現(xiàn)現(xiàn)有客戶信息庫不完整時，效勞臺需要及時更新；用戶姓名〔必填〕用戶標識〔是否為VIP用戶〕號碼〔手機〕〔二者必填一項〕分機號碼員工當前所在地點所屬部門/所屬辦稅效勞廳地址檢查該用戶是否屬于效勞對象的范圍。如有必要，更新用戶資料，如聯(lián)系方式。0.13信息充分性判斷執(zhí)行者：地市效勞臺對于事件請求，效勞臺需要判斷用戶提供的信息是否足夠用于后續(xù)提供支持，快速恢復效勞。如果足夠，則進入環(huán)節(jié)“0.15新事件判斷〞如果不夠充分，則進入環(huán)節(jié)“0.14進一步提供信息〞0.14進一步提供信息執(zhí)行者：用戶用戶按照效勞臺要求補充相關(guān)信息；0.15新事件判斷執(zhí)行者：地市效勞臺根據(jù)用戶提供的事件描述信息，判斷請求是否為新的事件。新的事件，進入環(huán)節(jié)“0.17記錄新事件單〞原有的事件，進入環(huán)節(jié)“0.16更新相關(guān)事件單〞0.16更新相關(guān)事件單執(zhí)行者：地市效勞臺對于原有的請求，根據(jù)用戶所提供的描述信息，對之前由該效勞請求所產(chǎn)生的工單進展進一步補充。補充后的工單仍按原有工單流程進展處理。0.17記錄新事件單執(zhí)行者：地市效勞臺創(chuàng)立事件請求，生成事件單，進入后續(xù)流程。在事件單中至少需要錄入以下事件信息，以下信息需要詳細而準確：事件單號〔系統(tǒng)自動產(chǎn)生〕事件的標題事件的詳細信息，包括事件可能造成的效勞影響，影響部門等?？赡艿拿枋鍪录F(xiàn)象的附件事件發(fā)生的時間事件單創(chuàng)立時間〔系統(tǒng)自動產(chǎn)生〕事件來源事件報告人信息事件單如果是來自用戶，則需要填寫用戶信息，至少包含以下內(nèi)容：用戶姓名用戶標識〔是否為VIP用戶〕聯(lián)系/手機所屬部門/所屬辦稅效勞廳如果該事件單是由運維人員主動發(fā)起，運維人員作為事件提交者其相關(guān)信息由系統(tǒng)自動填寫，至少包含以下內(nèi)容：運維人員帳號或姓名運維人員聯(lián)系事件分類分級與初步支持〔地市〕描述：該步驟的目的是判斷事件級別和分類，隨即在現(xiàn)存的解決方案中查詢與該事件相匹配的方案，或根據(jù)個人經(jīng)歷嘗試在線對事件進展處理。假設(shè)沒有找到適宜的解決方案或變通方法或需要離線對事件進展處理，該事件需要分配給二線具有適宜技術(shù)技能的事件分析員。該步驟的重點是正確地分配事件，以防止后面對時間的浪費。流程主要內(nèi)容:輸入：任務：輸出：來自于步驟事件單0.21分類分級0.22初步支持0.23能否解決問題0.24效勞臺分派事件單3.25判斷是否承受事件單3.26受理事件單已分派的事件單表格STYLEREF1\s3SEQ表格\*ARABIC\s14受理與初步分析內(nèi)容過程環(huán)節(jié):0.21分類分級執(zhí)行者：地市效勞臺確定事件等級；〔具體請參見2.4.7〕根據(jù)事件影響度和緊急度，確定優(yōu)先級?！簿唧w請參見2.4.8“優(yōu)先級規(guī)則〞〕。確定CTI分類〔具體請參見2.“事件分類〞〕。如果是省級集中信息系統(tǒng)類事件單，則需標注。0.22初步支持執(zhí)行者：地市效勞臺在事件管理中查詢已經(jīng)存在的解決方案/變通方法，或進展知識庫有效知識的匹配進展在線事件解決；根據(jù)事件記錄人員所擁有的技能嘗試確定“解決方案或變通方法〞，進展在線事件解決；如果可以解決，轉(zhuǎn)至步驟IM-05“事件單關(guān)閉〞中的步驟。如果不能解決，轉(zhuǎn)至步驟0.24“分派事件〞。執(zhí)行者：地市效勞臺根據(jù)事件分類不同，把事件分派給適宜的事件分析員；假設(shè)地市二線技術(shù)人員認為事件單派轉(zhuǎn)不合理，則事件重新進入“分派事件〞環(huán)節(jié)。0.25二線受理事件單判斷執(zhí)行者：地市二線地市二線事件分析員接到事件后，判斷事件是否分派正確，即是否本人的工作職責和技能范圍。如果是，則轉(zhuǎn)步驟0.26。如果不是，說明理由，并須考慮是否需要對事件“分派事件〞。受理事件單執(zhí)行者：地市二線如果被分派的事件分析員確認該事件單分派正確，則承受該事件單，進入步驟0.31“故障分析〞。二線受理與診斷〔地市〕描述:這個步驟的目標是對事件進展分析以便提出解決方案，不同技術(shù)領(lǐng)域的事件分析員將會參與到該步驟中以尋求一個事件解決方案，在有必要時會升級至省局信息中心以便快速解決恢復事件影響。流程主要內(nèi)容:輸入：任務：輸出：來自于步驟“受理事件單〞收集相關(guān)信息0.33關(guān)聯(lián)至主事件單進展事件分析解決方案針對該事件的解決方案升級至省局信息中心的事件單過程環(huán)節(jié):收集相關(guān)信息執(zhí)行者：地市二線二線對事件進展處理，并查找可能對事件處理有效的相關(guān)信息。該處理過程一線往往脫離開流程系統(tǒng)進展，在得到相關(guān)信息后，重新登錄到流程系統(tǒng)，并將相關(guān)信息記錄在事件單中。是否重復事件執(zhí)行者：地市二線尋找有相似病癥(即由同一原因造成)的事件:如找到類似的事件，即進入“關(guān)聯(lián)事件到主事件〞，如果在事件診斷過程中發(fā)現(xiàn)匹配錯誤，可以取消此關(guān)聯(lián)。如果沒有找到，進入“事件單分析〞關(guān)聯(lián)到主事件單執(zhí)行者：地市二線判斷當前事件單所描述的現(xiàn)象與之前未解決的事件是否有相似：如果確認是重復工單或主事件驅(qū)開工單，將新的事件單關(guān)聯(lián)到原主事件單原有事件單被標識為“主事件單〞原有事件單關(guān)聯(lián)事件單數(shù)加一新建事件單出現(xiàn)在原有事件單重復工單列表中新事件單狀態(tài)將隨原有事件單狀態(tài)的更新而更新，不單獨進展處理。0.34事件單分析執(zhí)行者：地市二線檢索知識庫查詢可能的解決方案，查找的途徑包括但不限于：通過對已記錄激活和未激活知識記錄進展查詢通過以往已關(guān)閉事件單中的解決方案或處理過程進展查詢通過其它公共的資料信息進展查詢根據(jù)專業(yè)技術(shù)經(jīng)歷尋找解決方案或者變更方法。經(jīng)分析如發(fā)現(xiàn)解決方案，轉(zhuǎn)到步驟“〞如未發(fā)現(xiàn)解決方案，在轉(zhuǎn)到步驟“〞。如果在事件恢復和解決階段未能恢復業(yè)務，或者在事件關(guān)閉階段用戶不滿意解決方案，則需返回“0.34事件單分析〞，由同一名事件分析員繼續(xù)進展處理。升級至省局信息中心執(zhí)行者：地市二線如果當前地市事件分析員由于某些原因不能解決該事件，需要將事件升級至省局信息中心監(jiān)控效勞臺?！仓幌抻谑〖壖行畔⑾到y(tǒng)類事件單〕解決和恢復〔地市〕描述:該步驟嘗試使用解決方案和變通方法來解決事件。某些情況下，需引入變更管理來批準評估實施步驟。對于某些事件，即使得到了解決，仍然需要創(chuàng)立問題單以進一步尋找其根源。流程主要內(nèi)容:輸入：任務：輸出：來自于步驟“〞采取恢復操作驗證解決方案效勞是否恢復是否進展根源問題分析創(chuàng)立新的問題并與事件關(guān)聯(lián)恢復受影響的效勞創(chuàng)立根本解決該事件單的問題單過程環(huán)節(jié):采取恢復操作執(zhí)行者：地市二線 由二線工程師負責實施以確定的解決方案，以恢復受影響的效勞。驗證解決方案&效勞是否恢復執(zhí)行者：地市二線 驗證解決方案的實施是否有效：對于方案無效的情況，轉(zhuǎn)到子流程“分析〞。對于方案有效的情況，轉(zhuǎn)到子流程“事件關(guān)閉〞以及活動“是否進展根源問題分析〞是否進展根源問題分析&創(chuàng)立新的問題并與事件關(guān)聯(lián)執(zhí)行者：一線判斷是需要對以解決的事件進展根源問題分析：對于需要分析的情況，轉(zhuǎn)到活動“創(chuàng)立新的問題并與事件關(guān)聯(lián)〞，針對該事件單新建一個問題單或關(guān)聯(lián)到已有的問題單上。對于不需要分析的情況，轉(zhuǎn)到步驟“事件關(guān)閉〞事件關(guān)閉〔地市〕描述:這個步驟確保用戶對事件的處理情況感到滿意。事件單的信息是正確、完整的，以便于以后生成報表。流程主要內(nèi)容:輸入：任務：輸出：來自于步驟“恢復〞1檢查事件記錄是否需要與用戶確認與用戶溝通提供反應信息用戶確認事件是否解決關(guān)閉事件單已關(guān)閉的事件單過程環(huán)節(jié):檢查事件記錄執(zhí)行者：地市效勞臺對于用戶報告的事件單，效勞臺檢查系統(tǒng)中事件單記錄的完整性，對于不完整的記錄進展補充。是否需要與客戶確認&與客戶溝通執(zhí)行者：地市效勞臺效勞臺根據(jù)事件性質(zhì)，判斷是否需要與用戶溝通事件的處理結(jié)果，以便確認事件的真正解決。如確認需要告知用戶事件處理結(jié)果的情況，轉(zhuǎn)入活動“與用戶溝通〞，溝通形式包括但不限于：系統(tǒng)通告，短信告知，郵件通知，通知等方式。如確認不需要告知用戶事件處理結(jié)果，轉(zhuǎn)入活動“關(guān)閉事件單〞提供反應信息執(zhí)行者：用戶用戶在承受效勞臺通知后，向效勞臺提供著呢對事件處理結(jié)果的反應信息。戶確認事件是否解決執(zhí)行者：地市效勞臺效勞臺根據(jù)用戶反應確定事件是否被成功解決：如確認事件未解決的情況，轉(zhuǎn)入子流程“〞，重新查找事件原因。如確認事件已解決的情況，轉(zhuǎn)入活動“關(guān)閉事件單〞關(guān)閉事件單執(zhí)行者：地市效勞臺按照關(guān)單原則對事件單進展關(guān)閉。事件受理和記錄描述:這個步驟是XXXX省局信息中心事件管理流程的起點。所有地市升級至省局信息中心、IT工程師主動報告或監(jiān)控平臺產(chǎn)生的IT事件都必須從這個步驟開場。該步驟的目的是快速、準確地探測和捕捉到在IT生產(chǎn)環(huán)境中發(fā)生的錯誤。本步驟的重點是準確、完整地采集創(chuàng)立一個事件單所需的必要信息。流程主要內(nèi)容:輸入：任務：輸出：事件驅(qū)動輸入：來自于地市信息科升級的事件單工程師主動發(fā)起的事件通過監(jiān)控平臺發(fā)現(xiàn)的告警事件其他信息來源來自失敗的變更實施1.1識別并驗證事件單信息1.2信息充分性判斷1.3進一步提供信息1.4新事件判斷1.5更新相關(guān)事件單1.6監(jiān)控告警1.7記錄新事件單已創(chuàng)立的事件單已更新的事件單表格STYLEREF1\s3SEQ表格\*ARABIC\s12記錄事件環(huán)節(jié)的內(nèi)容過程環(huán)節(jié):1.1識別并驗證事件單信息&事件單信息充分性判斷執(zhí)行者：省局監(jiān)控效勞臺對地市升級的事件單信息進展識別和驗證，重點關(guān)注如下幾點：用戶根本信息是否完備；事件描述是否清晰，是否提供截圖；事件分類分級是否合理；是否有對應“內(nèi)部呈批表或加蓋公章〞；要求維護參數(shù)表代碼表，確認是否有提供EXCEL格式的內(nèi)容。監(jiān)控效勞臺需要判斷地市升級的事件單信息是否足夠用于后續(xù)提供支持，快速恢復效勞。如果足夠，則進入環(huán)節(jié)“1.4新事件判斷〞如果不夠充分，則進入環(huán)節(jié)“1.3進一步提供信息〞1.3進一步提供信息執(zhí)行者：用戶用戶按照效勞臺要求補充相關(guān)信息；1.4新事件判斷執(zhí)行者：監(jiān)控效勞臺根據(jù)地市升級的事件單描述信息，判斷請求是否為新的事件。新的事件，進入環(huán)節(jié)“新事件單〞原有的請求，進入環(huán)節(jié)“1.5更新相關(guān)事件單〞1.5更新相關(guān)事件單執(zhí)行者：監(jiān)控效勞臺將該事件單關(guān)聯(lián)到原有事件單?？蓪χ魇录芜M展進一步補充相關(guān)信息。關(guān)聯(lián)后的工單仍按原有工單流程進展處理。1.6監(jiān)控告警執(zhí)行者：監(jiān)控工具/工程師監(jiān)控平臺自動觸發(fā)的，事件告警信息是通過系統(tǒng)接口自動載入的事件。由工程師主動發(fā)起，并在系統(tǒng)上自助填寫事件單，并轉(zhuǎn)監(jiān)控效勞臺受理。1.7受理或記錄記錄新事件單執(zhí)行者：監(jiān)控效勞臺受理或記錄新事件單請求，進入后續(xù)流程。初步支持描述：該步驟的目的是監(jiān)控效勞臺在現(xiàn)存的解決方案中查詢與該事件相匹配的方案，或根據(jù)個人經(jīng)歷嘗試在線對事件進展處理。假設(shè)沒有找到適宜的解決方案或變通方法，將事件分配給一個具有適宜技術(shù)技能的運維組。該步驟的重點是正確地分配事件，以防止后面對時間的浪費。流程主要內(nèi)容:輸入：任務：輸出：來自于步驟“受理或者記錄新事件單〞2.1確定事件分類分級2.3提供初步支持2.4能否解決事件單2.5分派事件單2.6承受事件單分派判斷2.7說明理由，返回效勞臺重新分派事件單已分派的事件單管理升級的信息表格STYLEREF1\s3SEQ表格\*ARABIC\s14受理與初步分析內(nèi)容過程環(huán)節(jié):2.1確定事件分類分級&2.2重大事件判斷執(zhí)行者：監(jiān)控效勞臺確定事件等級是否正確〔具體請參見2.4.7“事件等級〞〕，如果是重大事件則進展〔管理升級〕確定事件分類是否正確〔具體請參見2.“事件分類〞〕。根據(jù)事件等級和緊急度，確定優(yōu)先級?！簿唧w請參見2.4.8“優(yōu)先級規(guī)則〞〕。如果不是重大事件則進入步驟“〞。2.3提供初步支持&2.4能否解決事件單執(zhí)行者：監(jiān)控效勞臺在事件管理中查詢已經(jīng)存在的解決方案/變通方法，或進展知識庫有效知識的匹配進展在線事件解決；根據(jù)監(jiān)控效勞臺人員所擁有的技能嘗試確定“解決方案或變通方法〞，進展事件解決；如果可以解決，轉(zhuǎn)至步驟IM-06“事件單關(guān)閉〞中的步驟6.1。如果不能解決，轉(zhuǎn)至步驟2.5“分派事件〞。2.5分派事件單執(zhí)行者：監(jiān)控效勞臺提示：在此環(huán)節(jié)，如果是分派到組，則該運維工程組必須制定負責人，由負責人負責對事件單的組內(nèi)分派。組員也可主動認領(lǐng)未組內(nèi)分派的事件單。提示：在此環(huán)節(jié)，如果是分派到組，則該運維工程組必須制定負責人，由負責人負責對事件單的組內(nèi)分派。組員也可主動認領(lǐng)未組內(nèi)分派的事件單。2.6是否執(zhí)行者：運維工程組運維工程組/人接到事件后，判斷事件是否分派正確，即是否本組/人的工作職責和技能范圍。如果不是，則須在事件單上解釋理由，將事件單返回效勞臺進展重新分派。如果承受，則轉(zhuǎn)步驟2.5“分派事件〞。執(zhí)行者：監(jiān)控效勞臺如果事件是重大事件，則立刻向信息中心管理層報告事件。信息中心管理層需要考慮和決策是否需要啟動重大應急流程或災備流程。管理升級描述：該步驟的重點是明確默認的管理升級機制及事件處理過程中正確的進展事件信息通知。流程主要內(nèi)容:輸入：任務：輸出：來自于步驟“IM-2.受理與初步分析〞中確定為對事件單級別的判斷來自于步驟“IM-5.事件分析〞中確定為對事件處理時間的預估3.1開場管理升級3.2/3.5/3.8/3.11重要性判斷3.3/3.6/3.9是否升級3.4/3.7/3.10/3.12持續(xù)關(guān)注3.13事件進展通報3.14是否啟動緊急狀態(tài)判斷中心領(lǐng)導層宣布緊急狀態(tài)管理層對事件處理指導與批示管理層對事件處理持續(xù)關(guān)注過程環(huán)節(jié):3.1開場管理升級執(zhí)行者：運維工程師運維工程師根據(jù)事件等級和性質(zhì)對事件信息進展恰當?shù)纳?。默認的升級規(guī)則見圖中管理升級中默認升級機制根據(jù)預定義的通知規(guī)則進展升級通知，通知的形式可能包括諸如：通過系統(tǒng)傳遞信息；，郵件或者短信；升級之后進入環(huán)節(jié)“3.2重要性判斷〞，判斷是否有必要繼續(xù)升級。&持續(xù)關(guān)注執(zhí)行者：各升級環(huán)節(jié)的負責人提示：事件管理升級應首先按照等級自動升級；在事件重要性發(fā)生變化時，可由適當級別的負責人進展人工升級根據(jù)下級人員提供的事件描述信息，判斷是否應將事件單信息向上級提示：事件管理升級應首先按照等級自動升級；在事件重要性發(fā)生變化時，可由適當級別的負責人進展人工升級如果確定事件單應繼續(xù)升級，轉(zhuǎn)入下一升級環(huán)節(jié)。如果不需繼續(xù)升級，轉(zhuǎn)入“持續(xù)關(guān)注〞環(huán)節(jié)。在“持續(xù)關(guān)注〞環(huán)節(jié)中，本環(huán)節(jié)負責人應及時收聽或查看與事件處理相關(guān)的報告或匯報，確保對事件進展的持續(xù)關(guān)注。3.13實時進展匯報執(zhí)行者：運維工程師由事件的處理工程師向各級領(lǐng)導實施匯報事件的處理進展與當前的影響范圍。3.14是否啟動緊急狀態(tài)執(zhí)行者：中心領(lǐng)導層由中心領(lǐng)導層對事件的影響度及處置情況進展綜合評估，判斷是否將當前事件升級為重大緊急狀態(tài)：如果確定是緊急狀態(tài)，轉(zhuǎn)至“IM-7重大緊急事件〞子流程如果認為暫不構(gòu)成緊急狀態(tài)，轉(zhuǎn)至“持續(xù)關(guān)注〞環(huán)節(jié)密切關(guān)注事件的進展和處置情況。故障分析描述:這個步驟的目標是對事件進展分析以便提出解決方案，不同技術(shù)領(lǐng)域的事件分析員將會參與到該步驟中以尋求一個事件解決方案，在有必要時會升級至三線或者原廠開發(fā)商以便快速解決恢復事件影響。流程主要內(nèi)容:輸入：任務：輸出：來自于步驟“2.6受理事件單〞4.1收集相關(guān)信息4.2是否重復事件4.3關(guān)聯(lián)至主事件單4.4進展事件分析4.5預估解決時間所需時間找到解決方案轉(zhuǎn)派事件單〔技術(shù)升級〕判斷是否受理事件單說明拒絕原因提出解決方案針對該事件的解決方案管理升級信息過程環(huán)節(jié):4.1收集相關(guān)信息執(zhí)行者：二線二線對事件進展處理，并查找可能對事件處理有效的相關(guān)信息。該處理過程一線往往脫離開流程系統(tǒng)進展，在得到相關(guān)信息后，重新登錄到流程系統(tǒng)，并將相關(guān)信息記錄在事件單中。4.2是否重復事件執(zhí)行者：二線尋找有相似病癥(即由同一原因造成)的事件:如找到類似的事件，即進入步驟4.3“關(guān)聯(lián)事件到主事件〞，如果在事件診斷過程中發(fā)現(xiàn)匹配錯誤，可以取消此關(guān)聯(lián)。如果沒有找到，進入步驟4.4“事件單分析〞4.3關(guān)聯(lián)到主事件單執(zhí)行者：二線判斷當前事件單所描述的現(xiàn)象與之前未解決的事件是否有相似：如果確認是重復工單或主事件驅(qū)開工單，將新的事件單關(guān)聯(lián)到原主事件單原有事件單被標識為“主事件單〞原有事件單關(guān)聯(lián)事件單數(shù)加一新建事件單出現(xiàn)在原有事件單重復工單列表中事件單狀態(tài)將隨原有事件單狀態(tài)的更新而更新，不單獨進展處理。4.4事件單分析執(zhí)行者：二線檢索知識庫查詢可能的解決方案，查找的途徑包括但不限于：通過對已記錄激活和未激活知識記錄進展查詢通過以往已關(guān)閉事件單中的解決方案或處理過程進展查詢通過其它公共的資料信息進展查詢根據(jù)專業(yè)技術(shù)經(jīng)歷尋找解決方案或者變更方法。預估解決時間所需時間執(zhí)行者：二線二線對事件處理所需的資源和時間進展預判，并將結(jié)果通過“IM-3管理升級〞向管理層及時通報。執(zhí)行者：二線經(jīng)分析如發(fā)現(xiàn)解決方案，轉(zhuǎn)到步驟“解決和恢復〞如未發(fā)現(xiàn)解決方案，或者需要其他系統(tǒng)運維工程組配合解決，則轉(zhuǎn)到步驟“轉(zhuǎn)派事件單〔技術(shù)升級〕〞。4.7轉(zhuǎn)派事件單〔技術(shù)升級〕執(zhí)行者：二線如果當前事件分析員由于某些原因不能解決該事件，需要將事件轉(zhuǎn)派給其他系統(tǒng)運維工程組?！笆欠癯惺苁录?。判斷是否受理事件單&說明拒絕原因執(zhí)行者：二線、三線運維工程組/人接到轉(zhuǎn)派的事件后，判斷事件是否分派正確，即是否本組/人的工作職責和技能范圍。如果不是，則須解釋理由，將事件單返回原事件處理人員。如果承受，則“分派事件〞。轉(zhuǎn)派超過3次，則事件單自動到事件經(jīng)理進展協(xié)調(diào)。提出解決方案執(zhí)行者：二線、三線二、三線工程師根據(jù)事件描述狀況以及所掌握的相關(guān)信息，對事件著手進展處理，并嘗試找到解決方案或者應急方案。找到方案后，轉(zhuǎn)IM5.1“事件解決和恢復〞解決與恢復描述：這個步驟嘗試使用解決方案和變通方法來解決事件。對于某些事件，即使得到了解決，仍然需要創(chuàng)立問題單以進一步尋找其根源。另外，處理過程中的經(jīng)歷能夠得到記錄以形成可重用的知識圖STYLEREF1\s38解決與恢復流程主要內(nèi)容:輸入：任務：輸出：來自于步驟4.5&4.10“找到解決方案〞5.1是否需要變更5.2采取恢復操作5.3驗證解決方案5.4效勞是否恢復5.5是否進展根源問題分析5.6創(chuàng)立新的問題并與事件關(guān)聯(lián)恢復受影響的效勞針對該事件的需要根源解決的問題單過程環(huán)節(jié):5.1判斷是否需要變更執(zhí)行者：二線、三線 首先判斷解決方案/變通方法是否需要啟動變更管理流程如果需要，則“創(chuàng)立變更單〞，通過變更流程實施；如果不需要，則可以直接執(zhí)行，進入步驟5.2“采取恢復操作〞5.2采取恢復操作執(zhí)行者：二線、三線 實施已確定的解決方案，以恢復受影響的效勞。5.3驗證解決方案&5.4效勞是否恢復執(zhí)行者：二線、三線 驗證解決方案的實施是否有效：對于方案無效的情況，轉(zhuǎn)到“故障分析〞。對于方案有效的情況，同步轉(zhuǎn)到“事件關(guān)閉〞以及步驟“是否進展根源問題分析〞5.5是否進展根源問題分析&5.6創(chuàng)立新的問題并與事件關(guān)聯(lián)執(zhí)行者：二線、三線判斷是需要對已解決的事件進展根源問題分析：對于需要分析的情況，轉(zhuǎn)到活動“5.6創(chuàng)立新的問題并與事件關(guān)聯(lián)〞，針對該事件單新建一個問題單或關(guān)聯(lián)到已有的問題單上。對于不需要分析的情況，轉(zhuǎn)到子流程6.1“事件關(guān)閉〞事件關(guān)閉描述：這個步驟確保用戶對事件的處理情況感到滿意。事件單的信息是正確、完整的，以便于以后生成報表。流程主要內(nèi)容:輸入：任務：輸出：來自于步驟“IM-5.4業(yè)務已恢復〞已解決的事件單6.1檢查事件記錄6.2是否需要與用戶確認6.3與用戶溝通6.4提供反應信息6.5用戶確認事件是否解決6.6關(guān)閉事件單已關(guān)閉的事件單過程環(huán)節(jié):6.1檢查事件記錄執(zhí)行者：監(jiān)控效勞臺對于用戶報告的事件單，效勞臺檢查系統(tǒng)中事件單記錄的完整性，對于不完整的記錄進展補充。6.2是否需要與用戶確認&6.3與用戶溝通執(zhí)行者：監(jiān)控效勞臺效勞臺根據(jù)事件性質(zhì)，判斷是否需要與用戶溝通事件的處理結(jié)果，以便確認事件的真正解決。如確認需要告知用戶事件處理結(jié)果的情況，轉(zhuǎn)入活動“6.3與用戶溝通〞，溝通形式包括但不限于：系統(tǒng)通告，短信告知，郵件通知，通知等方式。如確認不需要告知用戶事件處理結(jié)果，轉(zhuǎn)入活動“6.6關(guān)閉事件單〞6.4提供反應信息執(zhí)行者：用戶用戶在承受效勞臺通知后，向效勞臺提供著呢對事件處理結(jié)果的反應信息。6.5用戶確認事件是否解決執(zhí)行者：監(jiān)控效勞臺效勞臺根據(jù)用戶反應確定事件是否被成功解決：如確認事件未解決的情況，轉(zhuǎn)入子流程“IM-5故障分析〞，重新查找事件原因。如確認事件已解決的情況，轉(zhuǎn)入活動“6.6關(guān)閉事件單〞6.6關(guān)閉事件單執(zhí)行者：監(jiān)控效勞臺按照關(guān)單原則對事件單進展關(guān)閉。緊急狀態(tài)描述：這個步驟是針對重大緊急事件的子流程，該流程的啟用必須通過管理升級決定。流程主要內(nèi)容:輸入：任務：輸出：來自于步驟“IM-3管理升級〞中確定是緊急狀態(tài)的事件7.1指定緊急應對小組的負責人7.2成立緊急應對小組7.3收集相關(guān)信息進展事件分析7.4初步分析結(jié)果匯報7.5是否協(xié)調(diào)更多資源7.6是否有應急處置預案7.7提出緊急恢復方案7.8提交ECAB審批7.9實施方案7.10方案是否有效緊急恢復受影響的效勞過程環(huán)節(jié):7.1指定緊急應對小組的負責人執(zhí)行者：中心領(lǐng)導通過管理升級確定為重大緊急事件后，由信息中心領(lǐng)導制定一名負責人作為緊急應對小組的負責人，對緊急情況進展指揮和處理。如果啟動緊急應急狀態(tài)，則事件單轉(zhuǎn)到該負責人，由該負責人對事件單進展分派。7.2成立緊急應對小組執(zhí)行者：緊急應對小組由緊急應對小組的負責人，選取適當?shù)募夹g(shù)和業(yè)務人員成立緊急應對小組，對緊急事件進展處理。7.3收集相關(guān)信息進展事件分析執(zhí)行者：緊急應對小組由緊急應對小組對事件的現(xiàn)象、相關(guān)CI、影響范圍、技術(shù)相關(guān)領(lǐng)域的信息進展收集，以供分析診斷。7.4初步分析結(jié)果匯報&7.5是否協(xié)調(diào)更多資源執(zhí)行者：緊急應對小組根據(jù)上一步驟收集的信息對重大緊急事件作出初步分析判斷，并及時提交報告至中心領(lǐng)導審批，由中心領(lǐng)導決定是否需要向緊急應對小組提供更多資源以便加快處理流程。如需要協(xié)調(diào)資源，轉(zhuǎn)入活動“7.3收集相關(guān)信息進展事件分析〞。如確認不要協(xié)調(diào)資源，轉(zhuǎn)入活動“7.6是否有應急處置預案〞7.6是否有應急處置預案&7.7提出緊急恢復方案執(zhí)行者：緊急應對小組 緊急應對小組查詢已有資源，包括但不限于：可持續(xù)性方案、事件記錄、知識庫等，確定是否有可以應用于本領(lǐng)件的應急預案：如有應急預案，轉(zhuǎn)入活動“7.8提交審批〞。如確認沒有應急預案，轉(zhuǎn)入活動“7.7提出緊急恢復方案〞，由緊急應對小組審計編寫應急方案，之后轉(zhuǎn)入活動“7.8提交審批〞。7.8提交審批執(zhí)行者：ECAB 應急負責人組織中心領(lǐng)導和對緊急應對小組提交的解決方案進展審批：如審批通過，轉(zhuǎn)入活動“7.9實施方案〞。如確審批未通過，轉(zhuǎn)入活動“7.7提出緊急恢復方案〞，由緊急應對小組審計重新編寫應急方案。7.9實施方案執(zhí)行者：緊急應對小組 緊急應對小組實施以審批的解決方案。如果解決方案需要啟動變更管理流程，則需在事件恢復后補錄緊急變更單。7.10方案是否有效執(zhí)行者：緊急應對小組 緊急應對小組檢測事件解決方案的實施效果：如效勞已恢復，轉(zhuǎn)入子流程“事件關(guān)閉〞。如效勞未恢復，轉(zhuǎn)入活動“7.7提出緊急恢復方案〞，由緊急應對小組審計重新編寫應急方案。角色與職責本章節(jié)描述省局信息中心有關(guān)人員在參與執(zhí)行和管理事件管理方案時的角色和責任。市局參與事件管理的角色可以參照省局對應角色進展設(shè)置。一個角色不等于對應一個人員，一個人員可以擔任多個角色。例如，可以由同一個人員擔任事件管理和問題管理負責人的角色。以下為事件管理流程中必須具有的角色：事件管理流程負責人事件管理流程負責人作為事件管理流程的責任人，對于整個流程執(zhí)行的結(jié)果負責，并有一定的權(quán)力管理流程。事件管理流程負責人的職責包括：全面負責流程的效率和成果建立考核和目標，以提升流程的有效性和效率為保障流程的有效性，需爭取高級管理層承諾投入足夠的資源鑒別和管理關(guān)鍵的流程成功要素控制和帶著流程的改良批準和拒絕偏離流程的請求定義事件管理的角色、責任和應負的責任定義目標、流程、工作流、政策和規(guī)則，并與相關(guān)人員進展溝通強制事件管理流程的執(zhí)行確保對流程的使用者提供適當?shù)慕逃龑ζ渌鞒特撠熑撕凸芾韺訁R報流程的狀況和進度對事件管理流程的有效性和效率進展監(jiān)控，在需要的時候作出改良召開和主持對事件管理流程改良的季度會議審計事件管理流程的執(zhí)行作為事件管理流程對外的代表事件經(jīng)理事件經(jīng)理負責協(xié)調(diào)事件管理的日常操作步驟，并管理工作的時間安排。事件經(jīng)理的責任包括：協(xié)調(diào)事件管理的日常操作確定和執(zhí)行流程本身的變更鑒別流程執(zhí)行過程中的例外和異常情況，并進展管理傳達流程的新政策和更新的政策確保流程標準和步驟得到遵循作出資源的承諾和分配鑒別和實施流程的改良建議產(chǎn)生和分派流程管理的報表對事件管理流程的負責人提出改良的建議作為流程的集中聯(lián)絡點，負責與用戶、效勞供給商、管理層之間的溝通組織解決需要跨越職能部門或工程組的問題，如有需要，應升級匯報對于不遵守流程的情形進展處理在需要的時候，按照升級政策中所定義的途徑進展升級對不遵從事件管理流程的參與者作出通告執(zhí)行日常的流程管理出席會議并傳達和協(xié)調(diào)有關(guān)事件和問題準備和分析報表從事件管理流程的開場到完畢進展跟蹤事件分析員事件分析員，主要是省局信息中心作為二線、三線的專業(yè)支持人員，具有某個領(lǐng)域的技術(shù)技能。負責提供良好的事件分析和/或者是提供一個方案，來快速恢復受到干擾的效勞。省局信息中心的事件分析員按技能或者系統(tǒng)劃分為運維工程組，例如應用運維工程組，大集中征管系統(tǒng)維保工程組等。事件分析員的責任包括：分析事件信息關(guān)聯(lián)受事件影響的CI〔配置項〕確認事件的優(yōu)先級查找一樣的病癥的事件，并進展關(guān)聯(lián)決定恢復效勞所需要的必要條件，并啟動適當?shù)男袆痈鶕?jù)事件的優(yōu)先級提供有效的解決方案/應急預案如有需要，與廠家和其他小組人員協(xié)同合作確定恰當?shù)姆峙?例如轉(zhuǎn)派到組內(nèi)其他事件分析員或者其他組事件分析員)根據(jù)事件等級進展恰當管理升級識別解決方案或者變通方法是否需要提交變更申請記錄解決方案/應急預案鑒別成為問題的事件，如需要找出問題的根源，創(chuàng)立問題單〔待問題管理實施后需履行此職責〕向效勞臺提供事件單處理進度有權(quán)限訪問相關(guān)錯誤、問題解決方法和配置管理數(shù)據(jù)庫(CMDB)監(jiān)控效勞臺監(jiān)控效勞臺作為省局信息中心的一線的支持人員，是用戶、各地市信息科和省局信息中心的主要聯(lián)系人。作為是事件的負責人，負責受理或創(chuàng)立事件單、跟蹤、協(xié)調(diào)事件的解決。監(jiān)控效勞臺的責任包括：承受用戶或者地市信息科的事件報告或者事件升級請求驗證用戶的根本信息，如有需要，更新用戶的資料創(chuàng)立或者更新事件單收集與事件處理相關(guān)信息，并確保信息的完整〔尤其是相關(guān)審批表〕分析故障報告信息初步評估事件的優(yōu)先級確定適當?shù)姆峙苫谥R庫，初步解決事件對于不能解決的事件，分派給適宜的事件分析組或人員假設(shè)用戶要求了解事件狀態(tài)，則將事件的當前狀況通知用戶與用戶確認事件的狀況和解決方案更新和關(guān)閉事件單角色映射角色省局信息中心崗位映射監(jiān)控效勞臺監(jiān)控效勞臺崗事件分析員〔二線〕應用運維工程組、系統(tǒng)平臺運維工程組、平安及網(wǎng)絡運維工程組事件分析員〔三線〕各信息系統(tǒng)運維工程組，例如：大集中征管系統(tǒng)維保工程組、發(fā)票在線系統(tǒng)工程組、納服整合平臺工程組等事件經(jīng)理監(jiān)控效勞臺臺長事件流程負責人運維辦事件經(jīng)理業(yè)務規(guī)則總體業(yè)務規(guī)則XXXX信息部門〔包括省局信息中心和各地市信息科〕支持的信息系統(tǒng)和網(wǎng)絡環(huán)境中，所有對效勞的正常提供有影響的事件都會通過事件管理流程處理；將通過流程中定義的標準、政策和指導進展管理。所有報告事件的部門將會參與統(tǒng)一的事件管理流程，不應該有任何例外。確保各地市效勞臺作為各地市信息科事件的統(tǒng)一入口，省局監(jiān)控效勞臺作為省局信息中心事件的統(tǒng)一入口，從而保證所有的事件都能夠記錄和跟蹤。故障處理人員如果因為時間緊迫沒有對所有發(fā)現(xiàn)的故障進展記錄，直接解決故障的話，應事后補單。〔補單情況應通過管理來盡量防止〕需要定期抽查事件單填寫的質(zhì)量，確保內(nèi)容足夠明確、詳細。應該定期產(chǎn)生和回憶事件管理報表。對沒有解決的問題，應該舉行定期的事件管理會議對這些事件進展評估。應該定期對流程進展回憶，以改良事件管理流程。責任人業(yè)務規(guī)則有效的管理事件的重要因素是定義一個責任人業(yè)務規(guī)則，以確保每個事件在任何時段都有適當?shù)娜藛T負責。當一個事件由地市效勞臺創(chuàng)立后且未升級至省局信息中心，地市效勞臺作為事件單的責任人，在事件單的全部生命周期內(nèi)負責推進事件的處理進度。如果事件單升級至省局信息中心，則事件單的負責人是省局監(jiān)控效勞臺，但是地市效勞臺繼續(xù)跟蹤該事件單的進度。如果事件單是由省局監(jiān)控效勞臺或者工程師創(chuàng)立，則省局監(jiān)控效勞臺是事件責任人，在事件單的全部生命周期內(nèi)負責推進事件的處理進度。當事件單被分派后，承受事件單的事件分析員是此事件單的當前負責人；但是分派方〔作出分派的效勞臺或是作出轉(zhuǎn)派的事件分析員〕有責任通知被分派的事件分析員并要求他承受或是拒絕此事件單。如果需要向用戶通知處理情況，由事件單的當前責任人或效勞臺負責。分派和受理業(yè)務規(guī)則監(jiān)控效勞臺可以直接分派事件到運維工程組或人。各運維工程組可以指定組長對分派到該組的事件單進展轉(zhuǎn)派。在運維工程組組長未及時進展轉(zhuǎn)派的情況下，組內(nèi)任何成員均可主動受理此工單。事件處理人員在收到工單指派通知后應盡快做出響應。注:每個運維工程組都需設(shè)定一名組長角色。轉(zhuǎn)派業(yè)務規(guī)則轉(zhuǎn)派指監(jiān)控效勞臺或者運維工程組組長分派后，被分派對象將事件單轉(zhuǎn)給組內(nèi)或者其他組的事件分析員〔效勞臺分派事件不屬于事件轉(zhuǎn)派〕。轉(zhuǎn)派業(yè)務規(guī)則確保事件單不被過于頻繁的相互轉(zhuǎn)派，以至于無法在規(guī)定時間內(nèi)得到解決。事件單可以由事件分析員轉(zhuǎn)派給本組或其他組的事件分析員。事件轉(zhuǎn)派超過3次〔含3次〕，事件單將升級給事件經(jīng)理。效勞臺和事件分析員，由于某些原因〔例如出差，休假，培訓等〕離開本崗位時，必須確保將未處理完畢的事件單轉(zhuǎn)派到本崗位其他事件分析員。效勞臺或者工具管理員可以手工干預對其單進展組內(nèi)轉(zhuǎn)派〔不會影響一次分派成功率〕組內(nèi)轉(zhuǎn)派不影響KPI“首次分派成功率〞的計算，有兩種情況：效勞臺下單后分派到效勞臺組，此種分派不算作第一次分派，不影響一次分派成功率的計算，及后假設(shè)繼續(xù)在效勞臺組內(nèi)轉(zhuǎn)派，同樣不影響一次分派成功率的計算。效勞臺派單到后臺各個分析員組后，事件分析員在其組內(nèi)轉(zhuǎn)派，也不影響首次分派成功率的計算，假設(shè)其須轉(zhuǎn)派到其它組，則需先退回到效勞臺，再由效勞臺作轉(zhuǎn)派。此時則算作首次分派不成功，對一次分派成功率的計算有影響。事件單轉(zhuǎn)派時，按第一次狀態(tài)變?yōu)椤疤幚碇楔暤臅r刻為“承受所分派事件〞的時刻。從第一次“已分派〞狀態(tài)到第一次“處理中〞狀態(tài)之間的時間，作為響應時間。如果事件單被屢次轉(zhuǎn)派，則在KPI指標計算時，只計算大環(huán)節(jié)的“響應時間〞和“解決時間〞。即計算第一次“已分派〞狀態(tài)到第一次“處理中〞狀態(tài)為響應時間，第一次“處理中〞狀態(tài)到最后一次“已解決〞狀態(tài)為解決時間。關(guān)于中間的轉(zhuǎn)派環(huán)節(jié)，需要翻開具體的單來看，不必在報表中表達。不在崗業(yè)務規(guī)則如果事件分析員由于某些原因〔例如出差，休假，培訓等〕離開本崗位時，而無法處理事件單，必須在離開前在ITSM工具上把自己的狀態(tài)設(shè)置為“不在崗〞，并通過適宜的方式通知效勞臺，以確保效勞臺和其他事件分析員不會派單給該事件分析員。重復事件業(yè)務規(guī)則重復事件：如果被報告的事件與某個已經(jīng)創(chuàng)立且尚未解決的事件單病癥一樣，則該事件被認為是重復的。將會為此重復的事創(chuàng)立新的事件單，并標注此單為“重復〞并與原始事件單相關(guān)聯(lián)。原始事件將被標注為“主事件〞。主事件解決時，從事件自動解決〔自動變?yōu)椤耙呀鉀Q〞狀態(tài)〕。事件等級事件的等級說明了對事件單處理的優(yōu)先程度。它是評定事件處理優(yōu)先等級的一個重要指標。所有事件都將分配到四個等級中的一個。事件等級從一級到四級。本表針對省級集中系統(tǒng)的事件進展劃分，地市自行開發(fā)業(yè)務系統(tǒng)的事件等級可參照設(shè)定。事件等級在事件的生命周期中是可以改變的。關(guān)于更改事件單等級的原因和行為應該在事件單中記錄。在故障處理過程中，隨著事件影響范圍擴大，故障等級應按擴大后的范圍重新劃定在下表中對事件的影響程度按照四個等級進展劃分，每個等級中對事件的表象進展了描述，效勞臺可以根據(jù)影響程度的定義對事件進展等級的劃分：一級二級三級四級級別描述導致兩個〔含〕以上地市全部或局部重要業(yè)務系統(tǒng)稅期中斷效勞的故障。導致單個地市的一個〔含〕以上系統(tǒng)全面中斷或者重要業(yè)務系統(tǒng)稅期重大效勞的故障。導致單個地市單個系統(tǒng)全面或局部功能中斷效勞的故障。不屬于上述故障的其他故障。主要負責人由信息中心分管主任或主任負責由運維工程組所在科室科長負責。由具體運維工程組負責人負責由具體事件分析員負責優(yōu)先級規(guī)則優(yōu)先級決定處理事件的順序及所需的資源。事件優(yōu)先級可分為四級：最高、高、中、低。由事件重要程度和緊急程度兩個維度共同決定。事件的緊急程度主要是以用戶能容忍的故障解決時間來進展判定，詳見下表：緊急程度用戶能容忍故障解決時間11H22H34H46H結(jié)合事件等級和緊急程度，可以通過下表確定事件的優(yōu)先級：事件優(yōu)先級事件等級一級二級三級四級緊急度1最高最高最高高2最高高高中3最高高中低4最高高低低目標解決時間業(yè)務規(guī)則為了更好的控制事件的解決，整個流程被分解成幾個組成局部。每個流程的階段都設(shè)定了目標時間。事件管理的目標時間如下表所示：〔時間的起點是事件單創(chuàng)立完成或者事件單升級至省局信息中心〕。升級至省局信息中心的事件單的時間起點從提交至監(jiān)控效勞臺的時間點算起。目標時間事件等級一級二級三級四級事件分派、承受與響應5min10min15min30min解決&關(guān)閉事件2H4H6H8HTotal2H4H6H8H每個步驟的目標時間到達后，仍未響應，自動郵件通知相關(guān)人員，其中二級以上事件自動通知事件經(jīng)理和所在科室科長。所有超出目標時間的事件單將表達在每周、每月的統(tǒng)計報表中。同時，事件經(jīng)理將得到通知。催辦業(yè)務規(guī)則為了保證效勞盡快恢復，事件在沒有在規(guī)定時間內(nèi)響應或解決時，效勞臺人員需要對事件的處理過程進展干預，催促事件盡快處理。該功能需要結(jié)合事件的等級進展設(shè)定，不同等級的事件其響應時間和解決時間不同，催辦的時間也不盡一樣。一級二級三級四級第一次催辦1H2H4H6H第二次催辦2H4H6H8H注：催辦時間從事件單產(chǎn)生或者提交至省局監(jiān)控效勞臺的時間點開場計算。通知規(guī)則在效勞不可用或恢復時，需要將受影響效勞的可用性信息及時通知關(guān)鍵的IT部門和業(yè)務部門。業(yè)務部門的通知規(guī)則詳見運維公告規(guī)定，IT部門的通知規(guī)則如下表：事件級別運維組負責人所在科室科長分管主任中心主任一級√√√√二級√√三級√四級管理升級內(nèi)容通知內(nèi)容應當以容易理解的方式進展描述并至少包含下述內(nèi)容：事件的簡要描述；受到影響的效勞；正在采取的措施預計恢復效勞的時間〔盡可能準確〕；事件的最新進展等。技術(shù)升級規(guī)則對于不同優(yōu)先級的事件，升級業(yè)務規(guī)則的目的是確保分配到適宜的資源在規(guī)定的時間內(nèi)恢復效勞。為了到達這個目的，在此定義了事件升級的業(yè)務規(guī)則時間框架。當?shù)竭_以下時間要求如果事件還未解決，將觸發(fā)升級業(yè)務規(guī)則。事件等級一線二線三線一級立即立即立即二級立即立即立即三級2H4H四級1H4H6H事件單關(guān)閉業(yè)務規(guī)則事件關(guān)閉有以下業(yè)務規(guī)則：由效勞臺分派的事件單應由效勞臺人員關(guān)閉。通過監(jiān)控發(fā)現(xiàn)的事件單可以由一線主動關(guān)閉此事件單。自動關(guān)閉事件單規(guī)則：對超過5個工作日的已解決的事件自動關(guān)閉。事件單代碼事件類型事件類型是對用戶請求的分類。事件類型能夠用來進展制作報表和查詢。預定義的事件類型如下：事件類型描述咨詢應用或業(yè)務的使用咨詢效勞請求來自用戶的對信息、標準變更的請求。例如數(shù)據(jù)查詢和修改、創(chuàng)立用戶、變更系統(tǒng)權(quán)限或密碼等。此類事件多因由業(yè)務規(guī)則或政策改變導致。操作錯誤用戶因不熟悉系統(tǒng)或者業(yè)務規(guī)則，對應用系統(tǒng)操作不當而導致的事件。此類事件因用戶操作不當引起的后臺數(shù)據(jù)修改故障因系統(tǒng)數(shù)據(jù)本來存在的缺陷、異常數(shù)據(jù)或其他原因，即非用戶操作不當導致，也非業(yè)務規(guī)則改變導致系統(tǒng)正常的操作事件單狀態(tài)代碼在事件的不同處理階段擁有不同的狀態(tài)，各階段狀態(tài)代碼建議定義如下〔需在產(chǎn)品的客戶化設(shè)計中進展最終確定〕：狀態(tài)代碼描述新建事件被記錄或創(chuàng)立已分派事件已被分派給效勞臺、事件分析員〔二、三線支持〕或事件經(jīng)理；處理中事件分析員〔二、三線支持〕承受了分派給他/她的事件單；等待事件信息不完整，或在某些情況下阻止效勞臺或事件分析員對事件進展處理，等待的原因可能為：等待用戶進一步的信息等待RFC變更流程處理等待問題管理〔僅對事件單有效〕等待其他廠商/供給商處理等待業(yè)務部門領(lǐng)導批復已解決為一個事件找到解決方案或變通方法已關(guān)閉事件已經(jīng)關(guān)閉事件來源當一個事件被登記后，效勞臺必須指定事件單的來源。這個信息能夠幫助確定多數(shù)用戶請求來自哪里，這對優(yōu)化用戶能夠帶來最大潛在好處的接口時非常重要。事件來源描述E-Mail效勞臺通過電子郵件收到一個請求。效勞臺通過收到一個請求。Web通過工具的網(wǎng)上自助效勞提出的事件。內(nèi)部報告由運維人員主動發(fā)現(xiàn)的故障告警事件由告警管理自動/手工產(chǎn)生的事件事件分類事件分類通常是標明一個事件的類別屬性，根據(jù)不同的類別屬性，由具備不同技能的事件分析員進展事件受理。事件類型也是用來統(tǒng)計事件單和制作報表時常用的一種匯報依據(jù)?？傮w來看，事件分類是用來判斷：誰來負責解決事件〔如，缺省的分派組〕創(chuàng)立事件單需要那些信息可以用于配置事件的缺省優(yōu)先級采用三種分類方式按歸屬層次地市級系統(tǒng)故障省級大集中系統(tǒng)故障按影響范圍影響全?。挥绊懢植康厥?；影響一個地市。按事件發(fā)生的歸屬系統(tǒng)分類，使用不超過三級分類：類別〔Category〕類別是CTI分類方法的最高層。它將被用作對事件進展分組的第一層。例如：應用系統(tǒng)、系統(tǒng)平臺、網(wǎng)絡、桌面系統(tǒng)等。子類〔Type〕子類用來區(qū)分每個“系統(tǒng)〞的根本組成模塊。它將被用作對事件進展分組的第二層。例如：對類別“應用系統(tǒng)〞來說，可以分為核心征管系統(tǒng)、發(fā)票在線系統(tǒng)等“子類〞。對于類別“系統(tǒng)平臺〞來說，可以分為主機、數(shù)據(jù)庫、中間件等“子類〞。工程〔Item〕這個層次體系中第三層是工程。這一層是指在這個體系中特定的模塊。工程這一層能夠獲得更詳細的信息和更準確的搜索。關(guān)閉代碼每個事件單在關(guān)閉時，都需要填寫關(guān)閉代碼以標識該事件單被處理的最終結(jié)果。因為每個事件單的處理結(jié)果不一定都有最終解決方案，因此為了更有效標識事件的解決結(jié)果，我們建議定義事件關(guān)閉代碼如下〔需在產(chǎn)品的客戶化設(shè)計中進展最終確定〕：關(guān)閉代碼描述成功關(guān)閉事件被正常解決變通方法事件已通過變通方法解決掉，但是需要進展更進一步的根源分析。未能解決的錯誤、變通方法或已實施的變更失敗，在現(xiàn)有條件下不能解決這個事件不能重現(xiàn)事件自行消失或者監(jiān)控系統(tǒng)告警自行消除自動關(guān)閉系統(tǒng)自動關(guān)閉用戶撤銷用戶撤銷事件單人員信息為了滿足對流程有效運作及流程角色的績效統(tǒng)計，暫定人員屬性信息如下〔需在產(chǎn)品的客戶化設(shè)計中進展最終確定〕：數(shù)據(jù)對象數(shù)據(jù)源備注登錄名內(nèi)部信息姓名內(nèi)部信息內(nèi)部信息Email內(nèi)部信息所屬科室/公司內(nèi)部信息所在地市/省局信息中心內(nèi)部信息所在工程組內(nèi)部信息一線、二線、三線內(nèi)部信息單項選擇運維工程組組長內(nèi)部信息是否事件信息事件單包含的屬性字段建議如下〔需在產(chǎn)品的客戶化設(shè)計中進展最終確定〕：數(shù)據(jù)對象數(shù)據(jù)源備注事件單號系統(tǒng)自動生成事件描述必填，簡短描述事件詳細信息事件發(fā)生時間事件影響范圍事件優(yōu)先級事件類別事件子類以類別為依據(jù)事件條目以類別、子類為依據(jù)相關(guān)配置項相關(guān)配置項ID請求人姓名請求人聯(lián)系事件分派組事件分派人工作日志記錄不同狀態(tài)下，人員的工作內(nèi)容解決方案/變通方法用戶反應意見信息附件附件的主要目的是協(xié)助問題流程衡量指標序號指標名稱指標類型指標說明1全省事件單總數(shù)日常統(tǒng)計指標用途：當前事件的總數(shù)，用于了解系統(tǒng)中記錄的事件數(shù)量。數(shù)量：在事件單中根據(jù)以下條件過濾【關(guān)聯(lián)主事件】標示為空【事件創(chuàng)立時間】在統(tǒng)計周期內(nèi)【事件創(chuàng)立時間】在統(tǒng)計周期之前，但在統(tǒng)計周期的起始時間還未關(guān)閉的事件單2事件關(guān)閉的數(shù)量/比率日常統(tǒng)計指標用途：當前事件處于“關(guān)閉〞狀態(tài)的數(shù)量以及占總事件數(shù)的比例，用于了解事件處理完畢的情況。數(shù)量：在事件總數(shù)中過濾【事件狀態(tài)】＝‘關(guān)閉’比率：數(shù)量/事件總數(shù)×100%3各種關(guān)閉類型的事件數(shù)量/比率日常統(tǒng)計指標用途：了解事件單關(guān)閉情況分布數(shù)量：在事件總數(shù)中過濾【事件完畢代碼】＝成功關(guān)閉、變通方法、未能解決、不能重現(xiàn)、自動關(guān)閉、用戶撤銷。比率：數(shù)量/事件關(guān)閉數(shù)量×100%4重大事件數(shù)量/比率日常統(tǒng)計指標用途：事件等級為一級的數(shù)量及占事件總數(shù)的比例，用于了解重大事件的發(fā)生率。數(shù)量：在事件總數(shù)中過濾【事件等級】＝‘一級’比率：數(shù)量/事件總數(shù)×100%5各類型事件單比例日常統(tǒng)計指標用途：各事件類型事件數(shù)量及占事件總數(shù)的比例，用于了解重大事件的發(fā)生率。數(shù)量：在事件總數(shù)中過濾不同【事件類型】比率：數(shù)量/事件總數(shù)×100%6各等級事件單比例日常統(tǒng)計指標用途：各等級事件數(shù)量及占事件總數(shù)的比例，用于了解重大事件的發(fā)生率。數(shù)量：在事件總數(shù)中過濾不同【事件等級】比率：數(shù)量/事件總數(shù)×100%7超過規(guī)定時間轉(zhuǎn)出的事件數(shù)量/比率績效衡量指標用途：超過預定一線轉(zhuǎn)出時限的事件數(shù)量及占事件總數(shù)的比例，用于衡量效勞臺處理事件的效率。數(shù)量：在事件總數(shù)中過濾〔【事件轉(zhuǎn)出時間】－【事件登記時間】〕<優(yōu)先級對應的轉(zhuǎn)出時限比率：數(shù)量/事件總數(shù)×100%8首次派單成功率績效衡量指標用途：未出現(xiàn)重分派情況的事件記錄數(shù)量，用于衡量效勞臺對事件分類和對應支持資源的判斷和協(xié)調(diào)能力。數(shù)量：在事件總數(shù)中過濾【事件重分派次數(shù)】=1；比率：數(shù)量/事件總數(shù)×100%9未超過規(guī)定時間解決的事件數(shù)量/比率績效衡量指標用途：超過SLA指定解決時限的事件數(shù)量及占事件總數(shù)的比例，用于衡量事件流程對事件的處理能力。數(shù)量：在事件總數(shù)中過濾【處理是否超時】＝‘未超時’and【事件關(guān)閉代碼】＝‘成功解決’or‘變通方法解決’比率：數(shù)量/事件總數(shù)×100%10平均響應時間績效衡量指標用途：響應事件的平均時間，用于衡量效勞臺、二線、三線的響應效率。效勞臺響應時間：累計響應事件的時間〔【事件分派時間】-【事件登記事件】〕/事件總數(shù)。省局信息中心的事件登記時間為地市提交至省局的時間。二線、三線平均響應時間：累計響應事件的時間〔【事件受理時間】-【事件分派時間】〕/事件總數(shù)11平均解決時間績效衡量指標用途：效勞臺/二線/三線解決事件的平均時間，用于衡量效勞團隊對事件的處理能力。完成的事件數(shù)量：在事件總數(shù)中過濾所有【事件狀態(tài)】＝‘已解決’or‘關(guān)閉’，同時【事件解決人角色】=‘效勞臺熱線’or‘二線’or‘三線’的事件平均解決時間：累加完成事件的〔【事件解決時間】－【事件登記時間】〕/完成的事件數(shù)量12一線解決率績效衡量指標用途：效勞臺解決事件的比例，用于衡量效勞臺對事件的處理能力。數(shù)量：在事件總數(shù)中過濾所有【事件解決人角色】＝‘效勞臺’比率：數(shù)量/事件成功關(guān)閉總數(shù)×100%13二線解決率績效衡量指標用途：二線解決事件的比例，用于衡量二線人員對事件的處理能力。數(shù)量：在事件總數(shù)中過濾所有【事件解決人角色】＝‘二線’比率：數(shù)量/事件成功關(guān)閉總數(shù)×100%14三線解決率績效衡量指標用途：三線解決事件的比例，用于衡量三線人員對事件的處理能力。數(shù)量：在事件總數(shù)中過濾所有【事件解決人角色】＝‘三線’比率：數(shù)量/事件成功關(guān)閉總數(shù)×100%功能需求 在一致性流程處理的大的根本原則下，需要考慮不同地市流程處理要求的特殊性。例如，事件管理流程角色設(shè)置在不同地市存在差異。系統(tǒng)平臺軟件需要針對具體差異進展靈活的流程定制，并提供相應的統(tǒng)計分析功能；用戶的特點本流程模塊的用戶特點如下表地市信息科用戶情況21個地市〔廣州市、珠海市、中山市、惠州市、順德區(qū)、東莞市、湛江市、肇慶市、茂名市、河源市、汕尾市、揭陽市、清遠市、汕頭市、潮州市、陽江市、韶關(guān)市、云浮市、梅州市、江門市〕，平均每個地市6個用戶，其中廣州、佛山、中山預估還需增加24。總共21*6+30=150人。角色情況其中每個地市信息科配置一個效勞臺角色，屬于地市一線、一個事件經(jīng)理、其余為事件分析員，屬于地市二線。使用頻率效勞臺角色工作時間在線，工程師接到事件單登陸系統(tǒng)處理。平均每個地市每天事件單數(shù)量約15個，