事件管理流程设计样例Word文件下载.doc
《事件管理流程设计样例Word文件下载.doc》由会员分享，可在线阅读，更多相关《事件管理流程设计样例Word文件下载.doc（55页珍藏版）》请在冰豆网上搜索。
第二章，介绍“事件管理流程”的业务逻辑，定义了总体流程，详细流程，流程步骤、角色及职责、业务规则、事件单代码、流程衡量指标。
第三章，介绍“事件管理流程”的工具功能需求以实现其业务逻辑，从工具用户特点、工单流程、与其他流程关系和流程评估和改进四个方面阐述。
第四章，介绍服务台结构，省市服务台逻辑及联动模式，及为实现该种模式服务台业务逻辑的工具功能需求。
1.5.术语
为方便相关人员对事件管理流程的理解，下表对事件管理流程中涉及的术语进行解释。
名词
解释
ITIL（ITInfrastructureLibrary）
是英国政府在1987年制定的有关IT服务管理的最佳实践，现已成为事实上的IT管理标准。
事件管理流程
ITIL流程之一，事件管理负责处理IT事件和用户请求。
它的目的是尽快恢复被中断或受到影响的IT服务，是以快速解决故障现象为目的，而不在于查找根本原因。
IT服务
XXXX省局信息中心和地市信息科提供给全省税务系统业务部门的IT支持服务内容。
事件
不包含在标准服务操作之内，导致或可能导致服务中断或服务质量降低的事件。
范围包括XXXX信息中心维护范围内的所有与IT基础架构和应用系统相关的故障、咨询和服务请求。
事件单
事件在流程管理系统中的数据记录。
解决方案
是指针对某一个或某一类已找到根本原因的问题，提出的解决问题的最终方案。
变通方法（也称临时措施）
是指解决事件的临时修复方法或技术，目的是使用替代措施暂时恢复SLA约定的服务，避免事件继续对客户的业务产生影响，该事件的永久解决措施有赖于对该事件潜在问题的最终解决。
IT用户
XXXX省局信息中心和地市信息科的服务对象。
监控服务台
监控服务台是信息中心为用户提供服务的唯一接口，是全省一体化协同运维体系中的重要组成部分。
监控服务台的主要工作内容是记录和受理事件内容，通过知识库提供初始支持，或通过功能型升级到对应的运维组帮助用户恢复到正常工作状态。
事件分析员
进行事件处理的支持人员，通常对应信息中心的二线或三线支持人员。
事件经理
负责协调和管理事件管理流程的各项活动。
运维办事件经理
流程所有者，负责对流程的审计和评估，持续改进该流程。
CI
Configurationitem配置项
RFC
Requestforchange变更请求单
CMDB
配置管理数据库
2.事件管理流程
2.1.流程概述
XXXX事件管理流程包括地市事件处理和省局信息中心事件处理两个部分。
整个流程、执行步骤和各步骤执行的顺序参见流程概览图。
这个流程旨在确保全省所有与省级集中信息系统相关的事件得到有效记录和跟踪，使事件能在最短的时间内得到解决，并为问题管理等其它服务管理流程提供相关信息。
要达到这个目标的重点在于：
l各地市信息科首先对事件进行有效记录和过滤，如果本级不能处理，则确保升级至省局的事件单信息完整和准确；
l地市和省局信息中心服务台准确分类分级事件；
l准确的将故障单分派给后台技术支持组或人员；
l确保用户对于事件的解决方案是满意的。
事件管理流程由事件驱动，关注事件的响应速度以尽快恢复业务运营。
2.2.流程步骤描述
2.2.1.事件记录（地市）
2.2.1.1.描述:
事件的记录是事件管理流程的起点。
所有用户报告或系统产生的IT事件都必须从这个步骤开始。
该步骤的目的是快速、准确地探测和捕捉到在IT生产环境中发生的错误。
除此以外，该活动也是其它用户相关请求的入口，诸如信息咨询、服务请求。
本步骤的重点是准确、完整地采集创建一个事件单所需的必要信息。
2.2.1.2.流程主要内容:
输入：
任务：
输出：
·
事件驱动输入：
–来自于用户的请求（提交方式：
电话、邮件、Web）
–运维人员主动发起的事件
0.11发起请求
0.12识别并验证用户信息
0.13信息充分性判断
0.14进一步提供信息
0.15新事件判断
0.16更新相关事件单
0.17记录新事件单
已创建的事件单
已更新的事件单
2.2.1.3.过程环节:
执行者：
用户
用户向所在地市信息科服务台提交事件请求。
用户提交事件请求的方式可以有多种：
-通过电话向服务台提交请求；
-通过web网页形式向运行部提交请求；
-通过电子邮件提交请求；
地市服务台
接受用户的事件报告。
提示：
建议通过统一工作平台用户管理，建立客户信息库以提高识别和验证效率；
可使用电话号码等作为用户的唯一识别；
在发现现有客户信息库不完整时，服务台需要及时更新；
对用户信息进行识别和验证，服务台需要尽量多地获取用户基本信息，诸如：
-用户姓名（必填）
-用户标识（是否为VIP用户）
-电话号码（手机）（二者必填一项）
-分机号码
-员工当前所在地点
-所属部门/所属办税服务厅
-地址
检查该用户是否属于服务对象的范围。
如有必要，更新用户资料，如联系方式。
对于事件请求，服务台需要判断用户提供的信息是否足够用于后续提供支持，快速恢复服务。
-如果足够，则进入环节“0.15新事件判断”
如果不够充分，则进入环节“0.14进一步提供信息”
用户按照服务台要求补充相关信息；
根据用户提供的事件描述信息，判断请求是否为新的事件。
-新的事件，进入环节“0.17记录新事件单”
-原有的事件，进入环节“0.16更新相关事件单”
对于原有的请求，根据用户所提供的描述信息，对之前由该服务请求所产生的工单进行进一步补充。
补充后的工单仍按原有工单流程进行处理。
创建事件请求，生成事件单，进入后续流程。
在事件单中至少需要录入以下事件信息，以下信息需要详细而准确：
-事件单号（系统自动产生）
-事件的标题
-事件的详细信息，包括事件可能造成的服务影响，影响部门等。
-可能的描述事件现象的附件
-事件发生的时间
-事件单创建时间（系统自动产生）
-事件来源
-事件报告人信息
事件单如果是来自用户，则需要填写用户信息，至少包含以下内容：
-用户姓名
-联系电话/手机
如果该事件单是由运维人员主动发起，运维人员作为事件提交者其相关信息由系统自动填写，至少包含以下内容：
-运维人员帐号或姓名
-运维人员联系电话
2.2.2.事件分类分级与初步支持（地市）
2.2.2.1.描述：
该步骤的目的是判断事件级别和分类，随即在现存的解决方案中查询与该事件相匹配的方案，或根据个人经验尝试在线对事件进行处理。
若没有找到合适的解决方案或变通方法或需要离线对事件进行处理，该事件需要分配给二线具有合适技术技能的事件分析员。
该步骤的重点是正确地分配事件，以避免后面对时间的浪费。
2.2.2.2.流程主要内容:
来自于步骤0.17新记录的事件单
0.21分类分级
0.22初步支持
0.23能否解决问题
0.24服务台分派事件单
3.25判断是否接受事件单
3.26受理事件单
已分派的事件单
表格2 1受理与初步分析内容
2.2.2.3.过程环节:
0.21分类分级
地市服务台
确定事件等级；
（具体请参见2.4.7）
根据事件影响度和紧急度，确定优先级。
（具体请参见2.4.8“优先级规则”）。
确定CTI分类（具体请参见2.5.4“事件分类”）。
如果是省级集中信息系统类事件单，则需标注。
在事件管理中查询已经存在的解决方案/变通方法，或进行知识库有效知识的匹配进行在线事件解决；
根据事件记录人员所拥有的技能尝试确定“解决方案或变通方法”，进行在线事件解决；
如果可以解决，转至步骤IM-05“事件单关闭”中的步骤0.51。
如果不能解决，转至步骤0.24“分派事件”。
0.24分派事件单
根据事件分类不同，把事件分派给合适的事件分析员；
若地市二线技术人员认为事件单派转不合理，则事件重新进入“分派事件”环节。
0.25二线受理事件单判断
执行者：
地市二线
地市二线事件分析员接到事件后，判断事件是否分派正确，即是否本人的工作职责和技能范围。
如果是，则转步骤0.26。
如果不是，说明理由，并须考虑是否需要对事件进行重新分类，以帮助服务台在下一次分派时更准确派单。
流程返回步骤0.24“分派事件”。
3.7受理事件单
如果被分派的事件分析员确认该事件单分派正确，则接受该事件单，进入步骤0.31“故障分析”。
2.2.3.二线受理与诊断（地市）
2.2.3.1.描述:
这个步骤的目标是对事件进行分析以便提出解决方案，不同技术领域的事件分析员将会参与到该步骤中以寻求一个事件解决方案，在有必要时会升级至省局信息中心以便快速解决恢复事件影响。
2.2.3.2.流程主要内容:
来自于步骤“0.26受理事件单”
0.31收集相关信息
0.32是否重复事件
0.33关联至主事件单
0.34进行事件分析
0.35找到解决方案
0.36升级至省局信息中心
针对该事件的解决方案
升级至省局信息中心的事件单
2.2.3.3.过程环节:
二线对事件进行处理，并查找可能对事件处理有效的相关信息。
该处理过程一线往往脱离开流程系统进行，在得到相关信息后，重新登录到流程系统，并将相关信息记录在事件单中。
寻找有相似症状（即由同一原因造成）的事件:
-如找到类似的事件，即进入步骤0.33“关联事件到主事件”，如果在事件诊断过程中发现匹配错误，可以取消此关联。
-如果没有找到，进入步骤0.34“事件单分析”
0.33关联到主事件单
判断当前事件单所描述的现象与之前未解决的事件是否有相似：
-如果确认是重复工单或主事件驱动工单，将新的事件单关联到原主事件单
-原有事件单被
升级会员 