ITIL事件管理流程设计

公众号回复：干货，领取价值58元/套IT管理体系文档

公众号回复：ITIL教材，领取最新ITIL4中文教材

正文

事件管理流程是ITIL主要流程之一，它的主要目标是尽快解决日常工作环境中出现的事件，保持IT服务的稳定性，监控事件的发展，并在事件得到解决之后将其关闭。

谈到事件流程我们需要了解一常见术语：

NO	术语	定义
1	事件	服务的意外中断或服务质量的下降。尚未影响服务的配置项失效也是事件，例如镜像组中一块磁盘的失效。
2	服务请求	用户对信息、建议、标准变更或服务访问的请求。例如重置密码、为新用户提供标准的服务。服务请求通常由服务台处理。
3	重大事件	对业务有重大影响的事件，重大事件将导致重要业务的中断。一般事件影响度或优先级为1级的事件默认定义为重大事件。
4	升级	在需要时获得额外资源，以达到服务级别目标或客户期望的活动。任何服务管理流程内部都可以升级，但是升级常常与事件管理、问题管理和有关客户投诉的管理有关联。主要有两种类型的升级：技术升级和管理升级。
5	管理升级	通知更多的高级管理人员或使他们参与解决疑难问题升级。
6	技术升级	将事件、问题或变更转给具有更高技术的小组，以便进行疑难问题升级。
7	响应时间	一种衡量完成运营或交易所需时间的指标，在性能管理中一般用于测量 IT 基础架构的性能，但在事件管理中主要用于测量接起电话或开始诊断的时间。
8	目标解决时间	为了更好的控制事件、变更等流程的整个处理过程，将处理过程被划分成几个阶段，并对每个阶段的完成时限设定了目标，即目标解决时间。
9	紧急度	测量事件、问题或变更多久会对业务产生重大的影响。例如，如果事件到年底才会影响业务，则影响大的事件可能紧急程度较低。指定优先级时要考虑到影响度和紧急度。
10	影响度	事件、问题或变更对业务流程影响的一种测量，影响度通常基于服务级别会如何受影响。指定优先级时要考虑到影响度和紧急度。
11	优先级	用于确定事件、问题或变更的相对重要性的类别。优先级的依据是影响度和紧急度，用它来确定采取行动所需的时间。例如 SLA 可以规定：优先级 2 的事件必须在 12 小时内解决。
12	挂起	事件、变更等流程可能因非技术原因而无法进行下去，此时可以暂停计算流程处理时间，挂起的目的在于更加公正的统计流程处理时间等与流程处理人员相关的指标。
13	临时措施	也称“变通方案”，在还没有完全的解决方法时，减少或消除事件或问题的影响。例如重新启动发生事件的配置项。
14	知识管理	负责收集、分析、保存和共享组织内部的知识和信息的流程。知识管理的主要目的是通过减少重新发现知识的需要，从而提高效率。
15	知识库	一个逻辑数据库，其中包含了服务知识管理系统使用的数据。

以下是事件流程设计图：

事件流程中的主要角色和职责的说明：

角色	职责描述	对应岗位
报障人	l 向服务台提交所发现的需要处理的事件。 l 与服务台确认事件处理结果。	所有可以发起事件的人
服务台	l 接听热线电话，响应用户报障需求，对用户进行初步相应的指导解决。 l 响应用户通过邮件、微信以及手机APP等方式的报障需求。 l 快速响应报障需求，为用户提供高效的远程服务。 l 及时联系现场工程师为用户提供服务。 l 及时联系二线支持人员为用户解决问题。 l 在ITSM平台中准确并及时录入事件信息。 l 对事件进行全程跟进，直到解决。 l 负责在事件解决后生成问题单或录入知识库（FAQ）。	客服
二线指派工程师	l 响应服务台派出的事件单，提供现场服务，包括备件更换安装服务。 l 在ITSM平台中准确并及时录入事件处理详细信息。 l 需要时发起服务请求单或变更单。 l 负责升级必要的事件到三线工程师或者供应商。 l 负责在事件解决后生成问题单或录入知识库。
三线指派工程师	l 响应二线工程师升级的工单，提供现场服务，包括备件更换安装服务，系统支持服务，工程服务等。 l 在ITSM平台中准确并及时录入事件处理详细信息。 l 需要时发起变更单。 l 负责在事件解决后生成问题单或录入知识库。
供应商	l 负责响应由二线或三线升级的事件单。 l 对事件单信息进行分析，并提供相应的解决方案。	外部设备供应商与服务提供商。
事件经理	l 设计和改进事件管理流程。 l 设定事件管理的绩效指标并考核指标完成程度。 l 跟踪、监控各事件流转状态，抽查事件记录。 l 收集汇总流程信息，编制管理报告，反映存在问题，提出改进建议，制定改进计划。
分管领导	l 接收事件经理升级的重大事件。 l 必要时与事件经理共同跟进重大事件，协调资源。 l 审批重大事件报告。

整体流程总共三大阶段：识别记录、调查诊断、解决关闭，各阶段详细说明如下：

一、事件识别与记录

	步骤名称	责任人	说明
1.1	提交事件	报障人	报障人通过电话、微信、邮件或手机APP来进行报障。
1.2	识别和记录	服务台	服务台在ITSM平台中进行事件信息的记录，包括用户联系方式、事件描述、事件分类分级等；若用户通过非电话的方式进行报障，服务台工程师可电话联系用户进行更多信息的确认和收集。
1.3	通知事件经理	服务台事件经理	若事件级别判断为一、二级事件，需要升级至事件经理需要跟进事件的处理过程；同时事件经理需要上报分管领导。

二、事件调查与诊断

	步骤名称	责任人	说明
2.1	初步处理	服务台	服务台对事件进行初步处理，进行远程调试或指导。
2.2	是否可以解决？	服务台	若可以解决，则直接处理解决，并进入3.2，与用户确认是否恢复；若无法解决，则进入2.3寻求二线支持。
2.3	二线支持团队调查诊断，寻找解决方案	二线工程师	二线支持团队接受服务台升级的事件，并判断是否需要进行内部转派，如需要则说明转派理由，并进行转派，如不需要则对事件进行分析和处理，处理过程需要及时更新到平台中；若需要执行变更，则触发变更管理。
2.4	是否找到解决方案？	二线工程师	若是，则进入2.5 是否需要发起服务请求管理；若否，则进入2.6寻求三线支持；若否，则进入2.8 寻求供应商支持。
2.5	是否需要发起服务请求管理	二线工程师	找到解决方案后，是否需要继续发起服务请求管理，寻求彻底解决：若需要执行服务请求，则发出服务请求管理若不需要，则进入3.1 事件解决。
2.6	三线支持团队调查诊断，寻找解决方案	三线工程师	三线支持团队接受二线升级的事件，对事件进行分析和处理，处理过程需要及时更新到平台中；若需要执行变更，则触发变更管理。
2.7	是否找到解决方案	三线工程师	若是，则进入3.1 事件解决；若否，则进入2.8寻求供应商支持。
2.8	供应商团队诊断调查，寻找解决方案	供应商	供应商接收来自二线和三线对的事件，并对事件进行分析诊断，给出最终解决方案。
2.9	提交解决方案	供应商	供应商将解决方案提交给相应的升级人员，由其去解决事件，并进入3.1 事件解决

三、事件解决与关闭

	步骤名称	责任人	说明
3.1	事件解决	二线工程师、三线工程师	将事件的解决结果及时更新至平台中，并标记解决，必要时发起问题工单进一步分析，或发起服务请求单完成临时解决后尚需进一步完善的遗留状态，或将事件总结生成知识库条目。
3.2	是否恢复？	服务台	服务台与用户确认事件的恢复结果。
3.3	填写用户反馈和满意度	服务台	将用户反馈和满意度调查情况更新至平台中，并关闭工单。

要落地实施好事件流程需要考虑的重要原则策略：

1. 所有已识别的事件都要被记录，所有事件都有整体责任人（服务台受理者），指派责任人（二线相关条线的主要负责人或受理人），以及当前执行人（具体负责该事件处理人），升级对象（三线或供应商）。

2. 事件首次响应的服务台（客服人员）负责在平台中记录此事件的详细信息，并进行初步支持，并作为此事件的最终负责人，负责跟踪事件处理的整个过程直至事件解决，以确保事件处理过程有专人及时跟进；

3. 原则上所有事件需要经过服务台。监控所发现的事件暂时不经过ITSM系统进行管理；

4. 若因情况紧急无法及时记录时，可进行事后补单，但补单时间不得超过12小时；

5. 原则上，所有事件首先指派给二线，如事件指派不准确或正好遇上交接班时间，该事件可在二线团队中做转派。如需要进一步支持，再由当前指派人升级给三线，二线三线都可以联系供应商解决，但只有三线可以进入ITSM系统操作（供应商不纳入ITSM使用者行列），当事件升级到三线后，二线的当前执行人仍为该事件的当前责任人。

6. 原则上，服务台、事件经理、指派工程师可根据实际情况对事件分类、分级等信息进行调整。

7. 服务台人员应在事件解决后2个工作日（48小时）内与报障人联系并关闭事件。如果报障人收到通知，且在2个工作日（48小时）内未对事件处理结果未提出异议，默认事件报告人接受结果，事件可关闭；

8. 导致事件发生的根本原因未知，或者事件重复发生，以及发生了重大事件，指派人都应提交问题管理流程查找根本原因，以期找到解决方案和预防措施；

10. 所有指派责任人都有义务根据事件处理情况更新相关知识库。

最后看看考核事件流程质量的一些关键绩效指标：

绩效指标	目标值	衡量方式	负责人
事件总数		事件总数/周期（年，月，周，日）	服务台、二线工程师、三线工程师
事件关闭的数量/比率		关闭事件数量 / 周期数量 / 事件总数 × 100 %	服务台、二线工程师、三线工程师
事件自动关闭的数量/比率		自动关闭事件数量 / 周期数量 / 事件关闭数量 × 100 %	服务台
重大事件数量/比率		优先级为一/二级事件数量 / 周期数量 / 事件总数 × 100 %	事件经理
事件成功关闭的数量/比率		成功解决事件并关闭数量 / 周期数量 / 事件关闭数量 × 100 %	服务台、二线工程师、三线工程师
临时解决事件的数量/比率		变通方法解决事件并关闭数量 / 周期数量 / 事件关闭数量 × 100 %	二线工程师
超过规定时间响应的事件数量/比率		一线响应超时事件 / 周期数量/事件总数 × 100 %	服务台
超过规定时间解决的事件数量/比率		超时解决事件 / 周期数量/事件总数 × 100 %	二线工程师，三线工程师，供应商
首次派单成功率		未派回服务台重派单事件 / 事件总数 × 100 %	服务台
平均响应时间		累计响应事件的时间 / 事件总数	服务台
平均解决时间		累加完成事件的时间 / 完成的事件数	二线工程师，三线工程师，供应商
一线解决率		一线解决事件数量 / 事件成功关闭总数 × 100 %	服务台
二线解决率		二线解决事件数量 / 事件成功关闭总数 × 100 %	二线工程师
用户满意度		事件记录中用户满意度分值总计 / 事件总数	服务台

需要原始事件管理流程设计WORD文档扫描下方二维码加入社群获取

福利

圈子构建、学习资料获取1000+份【ITIL/数字化转型/IT管理各类文档解决方案报告】，欢迎加入知识星球（扫下方二维码）~~~

更多推荐

ITIL配置管理实施常见问题总结

ITIL配置管理实施方案详解(二)

ITIL配置管理实施方案详解(一)

ITIL流程实施系列之变更管理

ITIL4基础认证培训教材之普通管理实践

免责声明：

本公众号部分分享的资料来自网络收集和整理，所有文字和图片版权归属于原作者所有，且仅代表作者个人观点，与ITIL之家无关，文章仅供读者学习交流使用，并请自行核实相关内容，如文章内容涉及侵权，请联系后台管理员删除。

ITIL事件管理流程设计相关推荐

ITIL: 事件管理流程问题管理流程
ITIL: 事件管理流程 & 问题管理流程前言概述事件管理流程图问题管理流程图前言上个项目上线一周了,因为前面的MA处理有点乱,学习下ITIL的管理流程,稍作修改适用于我们内部团队 ...
ITIL变更管理流程的设计
变更在企业运作中是必不可少的,实施变更面临风险,要首先取得高层的认可,让他们知道变更的范围和程度,事前通知用户或是发布流程都是执行变更时的措施,避免出现严重影响用户正常使用的问题发生,比如:邮件服务器 ...
itil 容量管理流程_探索ITIL和DevOps的边界
其实在今天的运维领域,ITIL和DevOps之间的冲突还是蛮明显的,有些是表现在产品上,有些是表现在思维/理念上.ITIL在产品上以流程为核心目标的设计,很难满足自动化的要求,DevOps极力推崇工具 ...
itil 容量管理流程_大项目定制，智能IT运营管理平台建设解决方案
大项目定制在传统的IT运营体系中,各个监控系统相对分散.对立,对IT系统竖井式管理,因此出现故障时无法准确定位:众多独立的监控系统形成结构复杂的监控群落,加大了运维管理难度:监控数据无法共享,系统隐 ...
itil 容量管理流程_（ITIL体系管理）可用性管理流程V1.1.doc
可用性管理流程目录 1 介绍1 1.1 目标1 1.2 适用范围1 2 流程详细说明2 2.1 输入2 2.2 输出:2 2.3 流程执行3 2.4 流程质量控制5 2.4.1 关键绩效指标KPI5 ...
ITIL 事件管理和问题管理的区别
在没有学ITIL的时候,很多人分不清事件管理和问题管理的区别, 在沟通了专家后,总结经验如下: 模化的企业都具备信息中心部门,信息中心的职责是服务于业务部门,保障企业网络的正常运转,那联结信息中心和业 ...
软件开发过程管理流程设计
根据当前公司的情况,分析整理设计了这个开发管理流程,希望能够解决项目开发中出现的管理问题.
itil 容量管理流程_（ITIL体系管理）容量管理流程V1.1.doc
容量管理流程版本记录版本号日期修改者说明文件名V1.02011-11-15孙小明初稿容量管理流程.docV1.12011-12-14范剑正式稿同上目录 1 介绍1 1.1 目标1 1. ...
员工寄件管理流程设计
员工寄快递管理方法? 员工寄快递需要收费吗? 员工寄快递的费用怎么做账? 员工寄快递让出纳直接付款...... 打开浏览器输入"员工寄快递",搜索框直接出现一堆"疑难杂症 ...
配置管理流程设计说明书
各位好,在各个企业的信息化建设中,为保证各个系统的运行稳定,提高IT内部规范化.标准化,提升效率,都会制定对应的配置管理流程,去指导内部管理平台的实施.以下是一个很好的范文: ------------ ...

ITIL事件管理流程设计

ITIL事件管理流程设计相关推荐

最新文章

热门文章