文档更改09 某省电信企信部管理办法ITIL事件管理分册

由 superadmin 于 2024/10/25, 21:50 最后修改

从版本< 15.1

由superadmin编辑
在2024/10/25, 21:50上

到版本

由superadmin编辑
在2024/10/25, 21:49上

修改评论上传新附件1729864146488-525.png

Raw
已渲染

Summary

Page properties (1 modified, 0 added, 0 removed)
Attachments (0 modified, 0 added, 1 removed)
- 1729864165904-928.png

Details

Page properties

Content

@@ -2,13
          +2,13 @@
  为了提升XX电信企信部运维服务质量，保障对所支持系统和业务的及时响应，改善事件的处理效率，参考ITIL最佳实践并结合XX电信企信部目前的运维现状，对事件处理的过程进行梳理，并形成管理规范和操作指导。
--==   ==
++==  ==
  == **1.1.本文适用对象** ==
  本文作为XX电信事件管理流程的参考，供XX电信参与到事件管理流程中的人员和相关的管理层使用。
--==   ==
++==  ==
  == **1.2.前提与假设** ==
@@ -36,6
          +36,7 @@
  |支持人员|进行事件处理的支持人员，通常对应于XX电信一线二线支持人员
  |事件经理|负责协调事件管理的日常操作步骤，并管理工作的时间安排
++
  == **1.4.阅读指南** ==
  本文所有工作流程均使用Line of Visibility Engineering Methodology (LoVEM)描述。LoVEM 可提供工作流程的图形化表述。流程中涉及的角色（Roles）定义于左列，还包括用户等其他内容；右侧是流程的每个步骤或环节。
@@ -51,6
          +51,7 @@
  = **第2章概述** =
++
  == **2.1.流程目的** ==
  事件管理的主要目标是争取在最短的时间内解决、恢复，尽量避免或减少事件对用户造成影响。事件管理需要保留事件的有效记录，给其他的服务管理流程提供相关的信息，以及正确报告进展情况。
@@ -65,6
          +65,7 @@
  = **第3章角色与职责** =
++
  == **3.1.领导小组** ==
  **担任者：**
@@ -75,7
          +75,7 @@
  负责对重大事件实施应急处理的决策和应急资源统一指挥调配，及时向上级机关汇报情况，执行上级领导的命令。
--==   ==
++==  ==
  == **3.2.事件管理流程负责人** ==
@@ -111,9
          +111,6 @@
  * 在适当的情况下，事件管理流程负责人可以把部分责任委任给其他人员执行。
  )))
--(% class="wikigeneratedid" %)
--==   ==
--
  == **3.3.事件经理 ** ==
@@ -150,8
          +150,6 @@
  * 解决问题（Issue）
  )))
--(% class="wikigeneratedid" %)
--==   ==
  == **3.4.服务台** ==
@@ -159,13
          +159,13 @@
  服务台人员由IT运行保障部服务台担任，主要操作人员包括：省客服接口岗、监控操作岗、服务受理岗、服务质监岗和服务分析岗
--===   ===
++===  ===
  === **3.4.1.省客服接口岗** ===
  承接省客服工作要求、进行分解和分派、对分派工作进行跟踪管理（五个一工程、全业务服务达标、“天翼腾飞”劳动竞赛等）
--===   ===
++===  ===
  === **3.4.2.监控操作岗** ===
@@ -182,9
          +182,6 @@
  * 机房出入管理
  )))
--(% class="wikigeneratedid" %)
--===   ===
--
  === **3.4.3.服务受理岗** ===
  服务受理岗承接内部和外部客户投诉故障申报，对投诉故障分类和分派，工单跟踪管理，确保投诉处理工作按时、按质完成。
@@ -209,9
          +209,6 @@
  * 更新和关闭事件单
  )))
--(% class="wikigeneratedid" %)
--===   ===
--
  === **3.4.4.服务质监岗** ===
  服务质监岗主要负责重点事件的质量跟踪和监管以及服务台内部质量管理工作，对服务质量指标监控、督促和考核；升级与紧急事件督办；投诉与重要问题回复；配合客户服务分析工作。
@@ -225,9
          +225,6 @@
  * 必要时承担服务分析岗工作
  )))
--(% class="wikigeneratedid" %)
--===   ===
--
  === **3.4.5.服务分析岗** ===
  服务分析岗主要负责重大问题的逐级上报和编写对外通知；服务处理报告编写和分析；服务质量回顾分析；故障回顾分析和规律发现；配合质监岗工作。
@@ -242,8
          +242,6 @@
  * 必要时负担服务质监岗工作
  )))
--(% class="wikigeneratedid" %)
--==   ==
  == **3.5.支持人员** ==
@@ -264,13
          +264,13 @@
  企信部各部门按照各自负责的技术领域进行技术支持分工，具体如下：
--====   ====
++====  ====
  ==== **3.5.1.1.计费账务组** ====
  受理因计费账务出错导致的前台业务类故障和投诉
--====   ====
++====  ====
  ==== **3.5.1.2.计费应用组** ====
@@ -277,7
          +277,7 @@
  负责处理计费域应用系统故障，范围包括：计费系统（HB）、OCS、ABM和联机采集系统，以及计费域（除CRM系统外）的中间件平台
--====   ====
++====  ====
  ==== **3.5.1.3.结算组** ====
@@ -284,7
          +284,7 @@
  负责处理结算域业务故障和应用系统故障，范围包括：应用系统的范围：综合结算、代理商系统和智能交换平台
--===   ===
++===  ===
  === **3.5.2.应用开发维护部** ===
@@ -294,7
          +294,7 @@
  负责维护CRM域业务故障和应用系统故障，应用系统的范围：CRM系统、SPS系统和TSAP系统
--====   ====
++====  ====
  ==== **3.5.2.2.非CRM组** ====
@@ -319,7
          +319,8 @@
  |终端维护岗|负责维护本部门办公网和省公司大楼终端，发现和处理故障
  |数据备份岗|负责存储和备份系统，发现和处理故障
--====   ====
++(% class="wikigeneratedid" %)
++====  ====
  ==== **3.5.3.2.支持组** ====
@@ -338,15
          +338,9 @@
  |网络支持岗|负责网络系统技术支持
  |信息安全岗|企信部范围内系统的信息安全管理
--(% class="wikigeneratedid" %)
--=   =
--
--(% class="wikigeneratedid" %)
--=   =
--
  = **第4章事件管理流程说明** =
--==   ==
++==  ==
  == **4.1.事件出入口** ==
@@ -367,8
          +367,6 @@
  |(% style="width:90px" %)问题单|故障在处理过程中分析并未找到很好的故障解决办法，或者只能通过变通手段对故障进行临时性的解决，则需要基于此事件单创建问题单留待后续做根源性的分析和解决，同时关闭事件单
  |(% style="width:95px" %)事件协同|(% style="width:90px" %)任务管理|事件在处理过程中发现需要其他小组人员帮助一起协查或处理，则可以基于此事件单创建多张任务单分派至不同小组
--(% class="wikigeneratedid" %)
--==   ==
  == **4.2.事件管理流程概述** ==
@@ -438,9
          +438,9 @@
 .根据唯一的客户信息识别并验证客户信息，需要尽量多地获取客户基本信息：
--* 客户姓名（必填）
++* [[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps3.png]]客户姓名（必填）
  * 客户标识（普通员工、主管、经理等）
--* 电话号码（手机）（二者必填一项）
++* [[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps4.png]]电话号码（手机）（二者必填一项）
  * 分机号码
  * 员工当前所在地点
  * 邮件地址
@@ -522,6
          +522,7 @@
  * 事件范围大，一个部门以上的用户使用收到影响需要通知的
  * 信息类，需要向一个以上部门发出通知或者解释说明的
++
  |**1.7 通知用户**|**执行者：服务台 **
 .通知用户并关闭事件
@@ -532,8
          +532,6 @@
  * 电话通知
  * 短信通知
--(% class="wikigeneratedid" %)
--===   ===
  === **4.3.2.事件分类与初步支持 ** ===
@@ -553,7
          +553,7 @@
  根据“事件检测与记录”的事件单、处理过程中回退和处理完成后重新打开的请求，实施判断请求类型、判断事件严重性优先等级与分类、关联到主事件、更新主事件信息、查找可能的解决方案、尝试解决、实施解决方案、事件分派、进行事件分析、执行升级、直接转派等措施，输出已分派的事件工单、已解决的事件工单和提交关闭
--====   ====
++====  ====
  ==== **4.3.2.3 具体步骤:** ====
@@ -568,7
          +568,7 @@
  |**2.2判断事件严重性、优先等级、分类**|**     执行者：服务台**
--1.查询事件的表现症状，所需要的信息如下：
++1.[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps5.png]]查询事件的表现症状，所需要的信息如下：
  * 事件简要描述
  * 可能影响了什么服务
@@ -580,6
          +580,7 @@
  * 对事件进行准确分类 是事件能够得到快速解决的前提
  * 具体分类规则参见5.1.5 事件分类
++
 .记录事件的表现症状根据事件描述状况进行事件分类
 .如果是客户报告的事件请求，了解该事件对服务可能产生的影响
@@ -586,7
          +586,7 @@
 .如果是运维人员报告的事件请求，运维人员在提交事件请求时根据5.6“优先级”定义设定事件的优先级
--5.如果是监控系统产生的告警事件，根据5.6“优先级”定义设定事件的优先级（注，目前湖南电信尚没有监控系统，此处为为未来系统接口做的扩展考虑）
++5.[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps6.png]]如果是监控系统产生的告警事件，根据5.6“优先级”定义设定事件的优先级（注，目前湖南电信尚没有监控系统，此处为为未来系统接口做的扩展考虑）
 .依据预定义的事件优先级业务规则，在事件单中记录优先级（事件的优先级表应根据实际情况实时修改）
@@ -599,6
          +599,7 @@
  * 类似事件通常表现为由于某个原因导致的多个客户出现的同一症状的服务不可用
++
  |**2.3关联到主事件 & 2.4 更新主事件单**|**执行者：服务台**
 .如事件单为重复或类似的未解决的事件，将新的事件单关联到原有事件单，原有事件单进行更新。
@@ -640,7
          +640,7 @@
  |**2.8 分派事件**|**执行者：服务台**
--1.根据事件分类不同，进行事件分派；
++1.[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps7.png]]根据事件分类不同，进行事件分派；
  * 不同的事件工单会有不同的事件类别和所属地点属性；
  * 根据事件类别和地点属性不同，事件工单会被直接分派到相应的技能组/支持人员，转至环节2.9“进行事件分析”；
@@ -685,8
          +685,6 @@
  * 事件经理对事件处理过程不满意，事件单功能升级后，工单派至相应分析员重新进行补充处理
  * 用户对事件处理结果不满意，事件单进行功能升级后，事件记录员退回工单至相应的处理人员，重新进行处理
--(% class="wikigeneratedid" %)
--===   ===
  === **4.3.3.事件调查和诊断** ===
@@ -704,7
          +704,7 @@
  根据初步分类的事件单、分析员主动发现的事件、未成功解决的事件单、知识库现有知识、事件数据库中的现有解决方案，实施事件分析和评估、收集分析相关信息、再次确认严重等级及分类、进行关联、诊断、试图解决事件的措施，得出“解决和恢复”工单、需要升级的工单或事件关闭的工单
--====   ====
++====  ====
  ==== **4.3.3.3 具体步骤:** ====
@@ -770,7
          +770,7 @@
  === **4.3.4.解决和恢复** ===
--====   ====
++====  ====
  ==== **4.3.4.1.描述:** ====
@@ -780,13
          +780,13 @@
  (% style="text-align:center" %)
  [[image:1729862863138-519.png]]
--====   ====
++====  ====
  ==== **4.3.4.2.流程主要内容:** ====
  根据“调查与诊断”事件工单、解决方案/变通方法，实施沟通决绝方案/变通方法、创建变更请求、创建需求请求、任务分解并分派、采取恢复操作、验证解决结果，输出沟通后部实施解决方案/变通方法的事件进入“分类与初步支持”、解决失败的事件进入“调查与诊断”已经恢复的事件进入“事件关闭”、需要通过变更解决的事件/流转至变更管理流程/发起变更申请。
--====   ====
++====  ====
  ==== **4.3.4.3.具体步骤** ====
@@ -847,7
          +847,7 @@
  === **4.3.5.事件关闭** ===
--====   ====
++====  ====
  ==== **4.3.5.1.描述:** ====
@@ -862,7
          +862,7 @@
  根据“1检测与记录”“2分类与初步支持”“3调查与诊断”“4解决与恢复”的事件、已经完成的变更、用户对解决情况的反馈，实施验证并检查记录、更新工单记录、与用户沟通、关闭相应公告、关闭工单等措施，输出已关闭的事件单、经过检查没有解决的事件单以及用户不满意的事件单
--====   ====
++====  ====
  ==== **4.3.5.3.具体步骤** ====
@@ -910,7
          +910,7 @@
  === **4.3.6.跟踪回顾** ===
--====   ====
++====  ====
  ==== **4.3.6.1.描述:** ====
@@ -926,7
          +926,7 @@
  根据未解决的事件、客户提出的查询请求和升级的事件单，实施选择事件、跟踪/回归过程、要求更新工单、更新信息、交流事件状态，得出更新记录的事件单和进一步升级的事件单
--====   ====
++====  ====
  ==== **4.3.6.3.具体步骤** ====
@@ -973,7
          +973,7 @@
 .交流结束后，跟踪回顾结束
--===   ===
++===  ===
  === **4.3.7.重大（危机）事件** ===
@@ -987,15
          +987,15 @@
  重大故障的组织和协调机制，参见《湖南电信重大故障管理办法》
--=   =
++=  =
--=   =
++=  =
  = **第5章业务规则** =
  注：所有在本章节所提及的日期和时间是指“经过的（elapsed）”的日期和时间。
--==   ==
++==  ==
  == **5.1.总体业务规则** ==
@@ -1055,9
          +1055,6 @@
  |规范五|对于事件（故障）现象填写出错并由此造成的分派错误，二线处理小组有权将事件单退回服务台，退回时必须说明理由
  |规范六|发生三次以上分派、转派和回退的事件将自动通知事件经理，由事件经理协调处理
--(% class="wikigeneratedid" %)
--===   ===
--
  === **5.1.4.代办业务规则** ===
  考虑到XX电信在人员组织方面的实际情况，可以允许在事件处理过程中实现代办功能，代办原则如下：
@@ -1065,9
          +1065,6 @@
  * 服务台和支持人员，由于某些原因（例如出差，休假，培训等）离开本岗位时，必须确保将未处理完毕的事件单重新分派到本岗位其他事件处理人员；如果
  * 本岗位只有自己一人，则通过指定代办人的方式，确保在代办期间，由代办人处理该岗位的各项工作；
--(% class="wikigeneratedid" %)
--===   ===
--
  === **5.1.5.优先级** ===
 . 事件的优先级表明了支持人员对事件工单处理的优先程度。它是评定事件处理优先等级的一个重要指标。
@@ -1075,7
          +1075,7 @@
 . 优先级在事件的生命周期中是可以改变的。关于更改事件单优先级的原因和行为应该在事件单中记录。
 . 事件的优先级通常由两方面的指标共同决定：事件影响度及事件紧急程度。
--====   ====
++====  ====
  ==== **5.1.5.1.事件影响程度** ====
@@ -1084,13
          +1084,8 @@
  ** 规则二：事件影响程度定义如下表所示
  * 我们可以根据一个表格来制定湖南电信事件的影响程度，在下表中对事件的影响程度按照四个等级进行划分，每个等级中对事件的表象进行了描述，服务台可以根据影响程度的定义对事件进行影响度的划分：
++[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps8.jpg]]
--(% style="text-align:center" %)
--[[image:1729864146488-525.png]]
--
--(% class="wikigeneratedid" %)
--====   ====
--
  ==== **5.1.5.2.事件紧急程度** ====
 . 事件紧急程度规则
@@ -1102,8
          +1102,7 @@
  示例表：
--(% style="text-align:center" %)
--[[image:1729864165904-928.png]]
++[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps9.jpg]]
  具体参见《事件管理设计信息表》
@@ -1141,7
          +1141,7 @@
  **表 3-4. 事件目标时间业务规则**
--===   ===
++===  ===
  === **5.1.7.等待规则** ===
@@ -1155,9
          +1155,6 @@
  |规范四|事件进入等待状态必须填写等待代码，自动进入等待的事件单由系统自动填写等待代码
  |规范五|等待中的事件单不计入目标时间考核
--(% class="wikigeneratedid" %)
--===   ===
--
  === **5.1.8.通知业务与升级业务规则** ===
 . 规范一：根据湖南电信管理现状，事件升级将执行事件上报通知，以及将紧急程度置为“高”
@@ -1165,7
          +1165,7 @@
 . 规范三：事件上报通知对象必须包括事件经理。在必要时，除事件经理外还可包括相关部门领导
 . 事件通知触发条件和通知对象：
--**图例:  **U：相关用户；C：事件记录员；E：支持人员；M：事件经理
++**图例:  **U：相关用户；C：事件记录员；E：支持人员；M：事件经理
  |严重等级
@@ -1177,7
          +1177,7 @@
  **表 3-6. 通知业务规则**
--===   ===
++===  ===
  === **5.1.9.标准的通知内容** ===
@@ -1189,7
          +1189,7 @@
  * 联系服务台咨询更多信息的方法
  * 通知方式可以考虑通过短信或邮件方式自动进行。
--===   ===
++===  ===
  === **5.1.10.重复业务规则** ===
@@ -1204,14
          +1204,11 @@
  |(% rowspan="2" %)配套措施|系统需要建立重复事件判断条件的配置功能，维护多个判断重复事件的条件，当满足条件时系统会弹出窗口提示操作者有哪些事件单可能是重复事件。可以选择是否关联或者主从
  |重复事件的主从关系允许拆解
--(% class="wikigeneratedid" %)
--===   ===
--
  === **5.1.11.复发业务规则 ** ===
 . 如果报告的事件与已经关闭的事件相同（查询范围含时间），该事件被认为是“复发”的事件单。这意味着为了解决事件而采取的解决措施失败了。此时应当创建一个新的事件单，复制原始事件单的内容，并说明这是复发的事件。
--===   ===
++===  ===
  === **5.1.12.事件单关闭业务规则** ===
@@ -1227,8
          +1227,6 @@
  |规范六|事件单在关闭前，必须填写关闭代码，自动关闭的事件单由系统自动填写关闭代码。
  |规范七|已关闭的事件单不允许重新打开
--(% class="wikigeneratedid" %)
--=   =
  = **第6章质监合规与分析考核** =
@@ -1281,7
          +1281,7 @@
  具体考核指标内容可参见《XX电信企信部指标体系》
--==   ==
++==  ==
  == **6.3故障分析** ==
@@ -1403,9
          +1403,6 @@
  |故障通告|系统故障，对用户造成较大影响时，比如影响程度为1的事件|受影响用户|故障解决后
  |停机通告|影响为1和2的变更在执行前，需要发出停机通告|受影响用户|变更完成后
--(% class="wikigeneratedid" %)
--===   ===
--
  === **1.3.2公告用语** ===
  公告包括“标题”“正文”“落款”三个组成部分。
@@ -1505,8
          +1505,6 @@
                                                         ~*~*~*~*-~*~*-~*~*
  )))
--(% class="wikigeneratedid" %)
--=   =
  = **附录二:服务台运行管理要求** =
@@ -1535,7
          +1535,7 @@
  服务台经理对整个服务台的事件处理情况负责。
--===   ===
++===  ===
  === **1.1.5投诉升级机制** ===
@@ -1543,7
          +1543,7 @@
  事件超时时会自动升级至事件经理，事件经理通常是服务台经理兼任，事件经理有责任和权利协调资源优先处理升级事件，包括与二线团队协调资源。
--===   ===
++===  ===
  === **1.1.6报告机制** ===
@@ -1551,7
          +1551,7 @@
  服务台建议设置周报和月报制度，每周和每月定时将报告汇总给服务台经理。
--===   ===
++===  ===
  === **1.1.7回访处理** ===
@@ -1562,31
          +1562,31 @@
  以下为对于服务台人员在处理投诉时的基本方法建议，实际上这些建议对于非投诉类Case的处理一样适用。
--===   ===
++===  ===
  === **1.2.1用心聆听** ===
  聆听是一门艺术，从中你可以发现客户的真正需求，从而获得处理投诉的重要信息。
--===   ===
++===  ===
  === **1.2.2表示道歉** ===
  如果你没有出错，就没有理由惊慌，如你真的出错，就得勇于面对。请记住客户之所以动气是因遇上问题，你漠不关心或据理力争。找借口或拒绝，只会使对方火上加油，适时的表示歉意会起到意想不到的效果。
--===   ===
++===  ===
  === **1.2.3仔细询问** ===
  引导用户说出问题重点，有的放矢。表示同情如果对方知道你的确关心他的问题，也了解他的心情，怒气便会消减一半。找出双方一起同意的观点，表明你是理解他的。
--===   ===
++===  ===
  === **1.2.4记录问题** ===
  对于投诉类的问题，必须忠实详尽的记录投诉者、投诉的原因、被投诉者、内容、处理过程、解决情况等信息。
--===   ===
++===  ===
  === **1.2.5解决问题** ===

1729864165904-928.png

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.superadmin

Size

...	...	@@ -1,1 +1,0 @@
1		-48.9 KB

Content

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司