详细描述事件管理中的ITSS主要活动
20150827 淡然
续上
3.2 流程输入及输出
3.2.1 流程触发条件
l 客户上报的事件 ITSS考试
l 巡检发现事件
l 监控系统上报告警事件
3.2.2 输入
l 来自于客服的事件请求
l 通过巡检发现的事件
l 监控系统上报的告警事件
l 配置项(CI)的信息
l 来自于知识库的解决方案/变通方法
3.2.3 输出
l 已关闭的事件单
l 知识库的候选解决方案
3.2.4 流程关闭条件
l 所有事件均通过解决方案或变通方法恢复
3.3 流程描述
3.3.1 流程综述
事件管理流程在执行过程中需要遵循以下要求:
l 所有接收的事件要保证完整、准确、详细的记录
l 事件需进行优先级划分和分类
l 应有一线解决方案和事件转交说明
l 事件需进行追踪和生命周期管理
l 事件需验证和关闭
l 事件需存在升级机制
l 所有的事件均应可以追溯和分析相关信息
l 应同事件影响对象及时沟通事件解决的过程,要在事件记录中记录所采取的全部措施
l 应为处理人员提供更新的知识库
l 只有事件确认已经解决并且服务得到恢复的情况下,事件才能被认为可以关闭
3.3.2 作业流程图

3.3.3 流程活动说明
1)主要活动说明
编码 | 活动 | 责任人 | 说明 |
IM.1 | 事件识别 和记录 | 事件记录员 (1线) | l 验证与识别事件信息 l 记录事件表现症状 |
IM.2 | 事件初步支持 | 事件记录员 (1线) | l 利用知识库,对事件解决进行初步支持 l 对于无法解决的事件分配给2线,以获得进一步的分析解决 |
IM.3 | 事件调查 和诊断 | 事件受理员(2/3/n线工程师) | l 开展事件调查与诊断,查找解决方案或变通方法,尝试解决 l 对于无法找到解决方案或者变通方法的事件,二线人员可进行转派或转回服务台请求重新分派 |
IM.4 | 事件解决 和恢复 | 事件受理员(2/3/n线工程师) | l 执行变通方法(需要的话使用变更管理流程) l 若成功,验证变通方法结果 |
IM.5 | 事件关闭 | 事件受理员(2/3/n线工程师) | l 当前是手动关闭方式,待有工具之后可考虑自动关闭 l 目前集中由事件记录员(1线经理)统一关闭,事件经理可以超越此权限,则其他人无权关闭事件 l 根据知识库决定是否需要进行后续操作 l 关闭事件,设定适当的关闭代码 |
2)分活动说明
编码 | 活动 | 责任人 | 说明 |
IM 1.1 | 识别和验证客户基本信息 | 事件记录员(1线) | l 接受来自客服与系统监控上报的事件请求(包括故障与服务请求) l 根据唯一的客户识别号识别客户 l 检查该客户是否属于服务对象的范围 |
IM 1.2 | 事件记录 | 事件记录员(1线) | l 如果是用户通过电话报告的事件,事件记录员需要了解用户信息是否准确并与客户沟通事件信息,了解必要的故障请求情况并作初步的受理和支持。 l 如果是用户通过邮件或其他方式提交事件单,一线支持人员首先需要检查用户提交的事件请求单是否完整、正确;如果不正确,与用户进行沟通,对用户信息不一致的情况进行调查,并修改相应记录;并关联相关CI、对用户提交的事件单中的类别、紧急度和影响度进行设置。 ITSS认证 |
IM 2.1 | 初步支持 | 事件记录员(1线) | l 事件记录员调用知识库对用户的事件进行初步的支持与解决 l 如知识库无法匹配解决办法,事件记录员(1线)负责查找其他资源,包括根据资深知识经验和自己查找信息,或咨询资深人员看能否找到其他解决办法。 l 如果找到相应的解决办法,则进行相应的处理和实施工作; l 如果找不到,则转入下一步 |
IM 2.2 | 判断是否能解决 | 事件记录员(1线) | l 事件记录员作为一线支持人员,判断该事件是否被解决。 l 如果解决,转入任务IM4.3“接受关闭请求?”,与用户进行沟通,是否可以关闭事件。 l 如果没有解决,转入任务IM2.3“派单”。 |
IM 2.3 | 派单 | 事件记录员(1线) | l 将事件单首先分派给2线接口人(项目经理),再由项目经理将事件分派给合适的事件受理员(2/3/n线),具体按分派机制或事件处理流程操作规定来执行; l 如果派单两次仍未成功,则升级给事件经理派单 |
IM 2.4 | 确定是否接受派单 | 事件受理员(2/3/n线) | l 事件受理员(2/3/n线)查看事件记录描述,决定是否接受派单。如果接受,转入任务IM3.1 “调查和诊断”。否则,转入任务IM2.5 “注明拒绝原因” |
IM 2.5 | 注明拒绝原因 | 事件受理员(2/3/n线) | l 事件受理员(2/3/n线)如不接受事件单,应在事件单上注明原因(比如事件分类不正确或自身任务排的很满),并提供下次分派的建议,将事件记录退回一线支持人员进行重新分派,进入任务2.3“重派单” |
IM 3.1 | 调查和诊断 | 事件受理员(2/3/n线) | l 事件受理员(2/3/n线)对事件进行分析诊断,可借助知识管理信息进行辅助 l 事件受理员(2/3/n线)在必要时对事件信息作进一步的收集,比如向用户询问或者现场了解事件信息。 l 事件受理员(2/3/n线)诊断事件,并寻求解决方案或变通方法 |
IM3.2 | 找到解决方案/变通方法? | 事件受理员(2/3/n线) | l 事件受理员(2/3/n线)判断是否找到了解决方案或者变通方法 l 如果找到,则转入IM3.5“记录解决方案/变通方法”,在事件单上记录解决方案或变通方法 l 如果未找到,事件受理员(2/3/n线)判断是否需要寻求进一步的支持,则转入IM3.4“升级到更高层” |
IM3.3 | 需要更多支持? | 事件受理员(2/3/n线) | l 当事件受理员无法解决事件时,转向IM3.4“升级到更高层”,将事件升级. |
IM3.4 | 升级到更高层 | 事件受理员(2/3/n线) | l 如果事件受理员(2/3/n线)在规定时限内仍找不到解决方案,应将事件的处理提交给更高层专家来处理。 |
IM3.5 | 记录解决方案和/变通方法 | 事件受理员(2/3/n线) | l 事件受理员(2/3/n线)找到解决方案或变通方法后,在事件单上应详细记录解决方案或变通方法信息。 |
IM4.1 | 是否需要变更 | 事件受理员(2/3/n线) | l 事件受理员(2/3/n线)对解决方案进行判断,如果需要变更,则提交变更请求,进入变更管理流程。变更管理流程进行实施后评审并通过之后,将实施结果返回到事件管理流程,进入IM4.3 “记录处理结果” l 如果不需要变更,则直接实施,转入IM4.2 “实施解决方案/变通方法” |
IM4.2 | 实施解决方案/变通方法 | 事件受理员(2/3/n线) | l 事件受理员(2/3/n线)根据事件的解决方案或变通方法进行实施,并确保实施成功和解决故障、满足客户请求或达到客户期望。 l 必要时可授权事件记录员(1线)来实施解决方案/变通方法 |
IM4.3 | 记录处理结果 | 事件受理员(2/3/n线) | l 事件受理员(2/3/n线)在实施解决方案或变通方法后,在事件单上应详细记录解决方案或变通方法实施结果信息。 l 实施和记录实施结果之后,联系用户以请求关闭事件。 |
IM5.1 | 与用户确认是否可以关闭 | 事件记录员(1线) | l 一线或事件受理员解决事件后,需要通过事件记录员与用户进行联系,确认相关处理方案是否成功,是否达到用户需求,然后将事件单关闭。 |
IM5.2 | 是否接受关闭请求 | 用户 | l 用户检查自己提出的请求或者报障是否得到完全解决,根据实施结果和满足程度判断是否接受关闭请求 l 如果接受关闭请求,则通知服务台可以关闭事件单,转入任务IM5.3 “是否需要更新到知识库” l 如果不接受,则需要重新调查和诊断,转入任务 |
IM5.3 | 是否需要更新到知识库 | 事件记录员或事件受理员 | l 事件受理工程师判断该解决方案或变通方法是否需要更新到知识库中,对于一些有价值的方案信息可以提交候选知识库解决方案,进入知识管理流程; l 不需要的话,则直接进入IM5.5“关闭事件” l 转入IM5.4“创建候选知识条目”,将该事件的解决信息更新到知识库 |
IM5.4 | 创建候选知识条目 | 事件受理员(1/2/3/n) | l 事件受理员在事件关闭后,将事件的根本原因和解决方案写入知识条目,转入IM5.5“关闭事件”。 |
IM5.5 | 关闭事件 | 事件记录员或事件受理员 | l 一线支持人员(一线值班经理)负责填写结束代码后关闭事件 |
3.4 流程衡量指标及报表
为了控制流程的质量,提高用户服务体验,建议为事件流程设置衡量指标。通过对指标的分析,可以有效地对流程的运行情况进行监控和改进。基于对IT运维服务部的IT服务认识和了解,事件管理流程KPI指标设置如下:
序号 | 衡量指标 | 指标计算说明 |
1 | 事件总数 | 数量:在事件单中根据以下条件过滤 1. 【重复事件标记】为空 2. 【事件发生时间】在统计周期内 |
2 | 事件关闭的数量/比率 | 数量:在事件总数中过滤【事件状态】=‘关闭’ 比率:数量 / 事件总数 × 100 % |
3 | 事件成功关闭的数量/比率 | 数量:在事件总数中过滤【事件结束代码】=‘成功’ 比率:数量 / 事件总数 × 100 % |
4 | 升级到问题的数量/比例 | 数量:在事件总数中过滤【事件结束代码】=‘成功但有问题’ 比率:数量 / 事件总数 × 100 % |
5 | 规定时间内解决的事件数量/比率 | 数量:在事件总数中过滤【事件解决是否超时】=‘未超时’and 【事件结束代码】=‘成功’ 比率:数量/事件总数 × 100 % |
6 | 规定时间内响应的事件数量/比率 | 数量:在事件总数中过滤【事件响应是否超时】=‘未超时’ 比率:数量/事件总数 × 100 % |
7 | 平均响应时间 | 平均响应时间:累计响应事件的时间(【事件登记时间】- 【事件发生时间】)/ 事件总数 |
8 | 平均解决时间 | 完成的事件数量:在事件总数中过滤所有【事件状态】=‘已解决’or ‘关闭’,同时【事件解决人角色】=‘一线’or‘二线’的事件 平均解决时间:累加完成事件的(【事件解决时间】-【事件登记时间】)/ 完成的事件数量 |
9 | 第三方平均解决时间 | 完成的事件:在事件总数中过滤所有【事件状态】=‘已解决’or ‘关闭’,同时【事件解决人角色】=‘3/n’的事件 平均解决时间:累加完成事件的(【事件解决时间】-【转至第三方时间】)/ 完成的事件数量 |
10 | 一线解决率 | 数量:在事件总数中过滤所有【事件解决人】=‘一线’ 比率:数量 / 事件总数 × 100 % |
11 | 二线解决率 | 数量:在事件总数中过滤所有【事件解决人】=‘二线’ 比率:数量 / 事件总数 × 100 % |
12 | 重大事件数量/比率 | 数量 :在事件总数中过滤【事件优先级】=‘1’或‘2’ 比率:数量 / 事件总数 × 100 % |
13 | 员工月度发起事件数量 | 数量:每月事件总数按【事件登记人】=%员工名称% 进行分类统计 |
14 | 员工月度处理事件数量 | 数量:每月事件总数按【事件工作日志】包含%员工名称%进行分类统计 |
15 | 知识库利用率 | 数量:解决问题,获取知识库的数量; 比率:数量/时间总数×100% |
16 | 员工月度发起事件比率 | 数量:每月事件总数按【事件登记人】=%员工名称% 进行分类统计 比率:数量/服务组事件总量×100% |
17 | 员工月度解决事件比率 | 数量:在事件总数中过滤所有【事件解决人角色】=%员工名称% 比率:数量/服务组事件总量×100% |
事件流程管理相关报表建议如下,IT运维服务部运维服务团队可在此基础上自行补充:
序号 | 报表名称 | 报表类型 | 包含指标 |
1 | 事件数量按用户及优先级统计 | 月报/季报 | 事件总数 |
2 | 事件数量按用户及设备统计 | 月报/季报 | 事件总数 |
3 | 事件数量按用户及事件分类统计 | 月报/季报 | 事件总数 |
4 | 超时响应事件数量按用户及优先级统计 | 月报/季报 | 超时响应数量 |
5 | 超时解决事件数量按用户及优先级统计 | 月报/季报 | 超时解决数量 |
6 | 平均响应/解决时间按优先级统计 | 月报/季报 | 平均响应时间 平均解决时间 |
7 | 一线/二线解决率按事件分类统计 | 月报/季报 | 一线解决率 二线解决率 |
8 | 事件登记/解决数量按服务支持人员统计 | 月报/季报 | 事件总数 ITSS培训 |
4. 参考4.1 相关流程
l 问题管理
l 变更与发布管理
l 服务级别管理
l 业务关系管理
l 供应商管理
4.2 相关表单
l 事件单/事件记录
l 运维事件月报/周报
l 经验手册/FAQ
4.3 事件分类表本帖关键字:ITSS