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

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

从版本< 11.1 >

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

到版本

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

< >

修改评论该版本没有评论

Raw
已渲染

Summary

Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

@@ -2,13
          +2,13 @@
  为了提升XX电信企信部运维服务质量，保障对所支持系统和业务的及时响应，改善事件的处理效率，参考ITIL最佳实践并结合XX电信企信部目前的运维现状，对事件处理的过程进行梳理，并形成管理规范和操作指导。
--==   ==
++==  ==
  == **1.1.本文适用对象** ==
  本文作为XX电信事件管理流程的参考，供XX电信参与到事件管理流程中的人员和相关的管理层使用。
--==   ==
++==  ==
  == **1.2.前提与假设** ==
@@ -37,7
          +37,6 @@
  |事件经理|负责协调事件管理的日常操作步骤，并管理工作的时间安排
--
  == **1.4.阅读指南** ==
  本文所有工作流程均使用Line of Visibility Engineering Methodology (LoVEM)描述。LoVEM 可提供工作流程的图形化表述。流程中涉及的角色（Roles）定义于左列，还包括用户等其他内容；右侧是流程的每个步骤或环节。
@@ -79,7
          +79,7 @@
  负责对重大事件实施应急处理的决策和应急资源统一指挥调配，及时向上级机关汇报情况，执行上级领导的命令。
--==   ==
++==  ==
  == **3.2.事件管理流程负责人** ==
@@ -115,7
          +115,6 @@
  * 在适当的情况下，事件管理流程负责人可以把部分责任委任给其他人员执行。
  )))
--
  == **3.3.事件经理 ** ==
@@ -153,7
          +153,6 @@
  )))
--
  == **3.4.服务台** ==
  **担任者：**
@@ -160,13
          +160,13 @@
  服务台人员由IT运行保障部服务台担任，主要操作人员包括：省客服接口岗、监控操作岗、服务受理岗、服务质监岗和服务分析岗
--===   ===
++===  ===
  === **3.4.1.省客服接口岗** ===
  承接省客服工作要求、进行分解和分派、对分派工作进行跟踪管理（五个一工程、全业务服务达标、“天翼腾飞”劳动竞赛等）
--===   ===
++===  ===
  === **3.4.2.监控操作岗** ===
@@ -183,7
          +183,6 @@
  * 机房出入管理
  )))
--
  === **3.4.3.服务受理岗** ===
  服务受理岗承接内部和外部客户投诉故障申报，对投诉故障分类和分派，工单跟踪管理，确保投诉处理工作按时、按质完成。
@@ -208,7
          +208,6 @@
  * 更新和关闭事件单
  )))
--
  === **3.4.4.服务质监岗** ===
  服务质监岗主要负责重点事件的质量跟踪和监管以及服务台内部质量管理工作，对服务质量指标监控、督促和考核；升级与紧急事件督办；投诉与重要问题回复；配合客户服务分析工作。
@@ -222,7
          +222,6 @@
  * 必要时承担服务分析岗工作
  )))
--
  === **3.4.5.服务分析岗** ===
  服务分析岗主要负责重大问题的逐级上报和编写对外通知；服务处理报告编写和分析；服务质量回顾分析；故障回顾分析和规律发现；配合质监岗工作。
@@ -238,7
          +238,6 @@
  )))
--
  == **3.5.支持人员** ==
  **担任者：**
@@ -256,48
          +256,49 @@
  * 厂商管理
  )))
--
  企信部各部门按照各自负责的技术领域进行技术支持分工，具体如下：
--====   ====
++====  ====
  ==== **3.5.1.1.计费账务组** ====
  受理因计费账务出错导致的前台业务类故障和投诉
--====   ====
++====  ====
++
  ==== **3.5.1.2.计费应用组** ====
  负责处理计费域应用系统故障，范围包括：计费系统（HB）、OCS、ABM和联机采集系统，以及计费域（除CRM系统外）的中间件平台
--====   ====
++====  ====
++
  ==== **3.5.1.3.结算组** ====
  负责处理结算域业务故障和应用系统故障，范围包括：应用系统的范围：综合结算、代理商系统和智能交换平台
--===   ===
++===  ===
++
  === **3.5.2.应用开发维护部** ===
--====   ====
  ==== **3.5.2.1.CRM组** ====
  负责维护CRM域业务故障和应用系统故障，应用系统的范围：CRM系统、SPS系统和TSAP系统
--====   ====
++====  ====
++
  ==== **3.5.2.2.非CRM组** ====
  负责维护电子渠道、MSS域和OSS域应用系统，发现和处理故障
++
  === **3.5.3.IT运行保障部** ===
--====   ====
--
  ==== **3.5.3.1.运行组** ====
  统一受理所有IT运行保障部职责范围内的事件单，主要指基础架构环境相关的系统故障等，组内岗责划分如下：
@@ -312,6
          +312,8 @@
  |终端维护岗|负责维护本部门办公网和省公司大楼终端，发现和处理故障
  |数据备份岗|负责存储和备份系统，发现和处理故障
++(% class="wikigeneratedid" %)
++====  ====
  ==== **3.5.3.2.支持组** ====
@@ -321,7
          +321,6 @@
  * 重大故障
  * 升级并引起关注的故障
--
  支持组组内岗责划分如下：
@@ -331,11
          +331,9 @@
  |网络支持岗|负责网络系统技术支持
  |信息安全岗|企信部范围内系统的信息安全管理
--
--
  = **第4章事件管理流程说明** =
--==   ==
++==  ==
  == **4.1.事件出入口** ==
@@ -357,7
          +357,6 @@
  |(% style="width:95px" %)事件协同|(% style="width:90px" %)任务管理|事件在处理过程中发现需要其他小组人员帮助一起协查或处理，则可以基于此事件单创建多张任务单分派至不同小组
--
  == **4.2.事件管理流程概述** ==
  下图从总体上描述了事件管理流程、执行步骤和各步骤执行的顺序。
@@ -501,7
          +501,6 @@
 .  通知并等待用户提供进一步信息
--
  |**1.6 创建公告**|**执行者：服务台 **
 .如果事件影响较小，不会造成大范围的影响，则不需要创建公告。
@@ -512,7
          +512,6 @@
  * 信息类，需要向一个以上部门发出通知或者解释说明的
--
  |**1.7 通知用户**|**执行者：服务台 **
 .通知用户并关闭事件
@@ -524,7
          +524,6 @@
  * 短信通知
--
  === **4.3.2.事件分类与初步支持 ** ===
@@ -543,7
          +543,7 @@
  根据“事件检测与记录”的事件单、处理过程中回退和处理完成后重新打开的请求，实施判断请求类型、判断事件严重性优先等级与分类、关联到主事件、更新主事件信息、查找可能的解决方案、尝试解决、实施解决方案、事件分派、进行事件分析、执行升级、直接转派等措施，输出已分派的事件工单、已解决的事件工单和提交关闭
--====   ====
++====  ====
  ==== **4.3.2.3 具体步骤:** ====
@@ -564,7
          +564,6 @@
  * 可能影响了什么服务
  * 必要时提供软件和硬件配置信息
--
  备注：
  * 事件信息的准确记录十分关键
@@ -572,7
          +572,6 @@
  * 具体分类规则参见5.1.5 事件分类
--
 .记录事件的表现症状根据事件描述状况进行事件分类
 .如果是客户报告的事件请求，了解该事件对服务可能产生的影响
@@ -588,13
          +588,11 @@
  * 如果存在类似的事件单，转入环节“2.3 关联到主事件”。
  * 如果不存在类似的事件单，进入“2.5 查找可能的解决方案”。
--
  提示：
  * 类似事件通常表现为由于某个原因导致的多个客户出现的同一症状的服务不可用
--
  |**2.3关联到主事件 & 2.4 更新主事件单**|**执行者：服务台**
 .如事件单为重复或类似的未解决的事件，将新的事件单关联到原有事件单，原有事件单进行更新。
@@ -618,7
          +618,6 @@
  * 如果存在解决方案/变通方法，转至“2.7 实施解决方案”
  * 如果没有找到解决方案/变通方法，转至环节“2.6 尝试解决”；
--
  |**2.6 尝试解决**|**执行者： 服务台**
 .服务台人员根据自身所拥有的技能尝试确定“解决方案或变通方法”，进行事件解决；
@@ -626,7
          +626,6 @@
  * 如果可以解决，转至转至“2.7 实施解决方案”
  * 如果不能解决，转至环节“2.8 事件分派”；
--
  |**2.7 实施解决方案**|**执行者： 服务台**
 .在系统中实施临时措施或解决方案，使服务得到恢复。
@@ -650,7
          +650,6 @@
  * 根据XX电信目前事件分配状况，按事件工单分类不同分派到不同的技能组
--
  |**2.9 进行事件分析**|**执行者： 支持人员**
 .得到事件工单分派的通知，进行事件检查，并确认是否接受分派的事件工单
@@ -661,7
          +661,6 @@
  * 如果不具备，需要升级，转至环节“2.10 执行升级”
  * 如果不具备，无需升级，转至环节“2.11直接转派”
--
  |**2.10 执行升级**|**执行者： 支持人员**
 .执行升级的情况如下：
@@ -670,7
          +670,6 @@
  * 派单次数超过3次，升级至相关事件经理及相应直属领导
  * 事件经理或客户对事件处理过程不满意，要求支持人员重新处理事件，需要升级至相关事件经理及相应直属领导
--
  |**2.11 直接转派**|**执行者： 支持人员**
 .对于支持人员之间的转派，可以直接实现，组内转派到人，组间转派到组
@@ -687,7
          +687,6 @@
  * 用户对事件处理结果不满意，事件单进行功能升级后，事件记录员退回工单至相应的处理人员，重新进行处理
--
  === **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.具体步骤** ====
@@ -803,7
          +803,6 @@
  * 是否需要配合完成，进入环节“4.4 任务分解并分派”
  * 如果不需要，进入环节“4.5 采取恢复操作”
--
  |**4.2创建变更请求**|**执行者：支持人员**
 .创建变更请求单，进入变更管理流程
@@ -848,7
          +848,7 @@
  === **4.3.5.事件关闭** ===
--====   ====
++====  ====
  ==== **4.3.5.1.描述:** ====
@@ -863,7
          +863,7 @@
  根据“1检测与记录”“2分类与初步支持”“3调查与诊断”“4解决与恢复”的事件、已经完成的变更、用户对解决情况的反馈，实施验证并检查记录、更新工单记录、与用户沟通、关闭相应公告、关闭工单等措施，输出已关闭的事件单、经过检查没有解决的事件单以及用户不满意的事件单
--====   ====
++====  ====
  ==== **4.3.5.3.具体步骤** ====
@@ -911,7
          +911,7 @@
  === **4.3.6.跟踪回顾** ===
--====   ====
++====  ====
  ==== **4.3.6.1.描述:** ====
@@ -927,7
          +927,7 @@
  根据未解决的事件、客户提出的查询请求和升级的事件单，实施选择事件、跟踪/回归过程、要求更新工单、更新信息、交流事件状态，得出更新记录的事件单和进一步升级的事件单
--====   ====
++====  ====
  ==== **4.3.6.3.具体步骤** ====
@@ -974,7
          +974,7 @@
 .交流结束后，跟踪回顾结束
--===   ===
++===  ===
  === **4.3.7.重大（危机）事件** ===
@@ -988,15
          +988,15 @@
  重大故障的组织和协调机制，参见《湖南电信重大故障管理办法》
--=   =
++=  =
--=   =
++=  =
  = **第5章业务规则** =
  注：所有在本章节所提及的日期和时间是指“经过的（elapsed）”的日期和时间。
--==   ==
++==  ==
  == **5.1.总体业务规则** ==
@@ -1056,7
          +1056,6 @@
  |规范五|对于事件（故障）现象填写出错并由此造成的分派错误，二线处理小组有权将事件单退回服务台，退回时必须说明理由
  |规范六|发生三次以上分派、转派和回退的事件将自动通知事件经理，由事件经理协调处理
--
  === **5.1.4.代办业务规则** ===
  考虑到XX电信在人员组织方面的实际情况，可以允许在事件处理过程中实现代办功能，代办原则如下：
@@ -1064,7
          +1064,6 @@
  * 服务台和支持人员，由于某些原因（例如出差，休假，培训等）离开本岗位时，必须确保将未处理完毕的事件单重新分派到本岗位其他事件处理人员；如果
  * 本岗位只有自己一人，则通过指定代办人的方式，确保在代办期间，由代办人处理该岗位的各项工作；
--
  === **5.1.5.优先级** ===
 . 事件的优先级表明了支持人员对事件工单处理的优先程度。它是评定事件处理优先等级的一个重要指标。
@@ -1072,7
          +1072,7 @@
 . 优先级在事件的生命周期中是可以改变的。关于更改事件单优先级的原因和行为应该在事件单中记录。
 . 事件的优先级通常由两方面的指标共同决定：事件影响度及事件紧急程度。
--====   ====
++====  ====
  ==== **5.1.5.1.事件影响程度** ====
@@ -1132,7
          +1132,7 @@
  **表 3-4. 事件目标时间业务规则**
--===   ===
++===  ===
  === **5.1.7.等待规则** ===
@@ -1139,7
          +1139,6 @@
 . 事件可能会超过目标时间上限，但这些原因有一些是客观的，无法预期的，当事件由于这些原因进入等待状态时，等待中的时间将不计入目标时间计算中。
 . 等待需要遵循以下规则：
--
  |等待规范|描述
  |规范一|事件记录员、支持人员和事件经理可将事件置为等待状态
  |规范二|事件创建维护性需求时，事件自动进入等待状态
@@ -1147,7
          +1147,6 @@
  |规范四|事件进入等待状态必须填写等待代码，自动进入等待的事件单由系统自动填写等待代码
  |规范五|等待中的事件单不计入目标时间考核
--
  === **5.1.8.通知业务与升级业务规则** ===
 . 规范一：根据湖南电信管理现状，事件升级将执行事件上报通知，以及将紧急程度置为“高”
@@ -1167,7
          +1167,7 @@
  **表 3-6. 通知业务规则**
--===   ===
++===  ===
  === **5.1.9.标准的通知内容** ===
@@ -1179,7
          +1179,7 @@
  * 联系服务台咨询更多信息的方法
  * 通知方式可以考虑通过短信或邮件方式自动进行。
--===   ===
++===  ===
  === **5.1.10.重复业务规则** ===
@@ -1194,12
          +1194,11 @@
  |(% rowspan="2" %)配套措施|系统需要建立重复事件判断条件的配置功能，维护多个判断重复事件的条件，当满足条件时系统会弹出窗口提示操作者有哪些事件单可能是重复事件。可以选择是否关联或者主从
  |重复事件的主从关系允许拆解
--
  === **5.1.11.复发业务规则 ** ===
 . 如果报告的事件与已经关闭的事件相同（查询范围含时间），该事件被认为是“复发”的事件单。这意味着为了解决事件而采取的解决措施失败了。此时应当创建一个新的事件单，复制原始事件单的内容，并说明这是复发的事件。
--===   ===
++===  ===
  === **5.1.12.事件单关闭业务规则** ===
@@ -1216,7
          +1216,6 @@
  |规范七|已关闭的事件单不允许重新打开
--
  = **第6章质监合规与分析考核** =
@@ -1268,7
          +1268,7 @@
  具体考核指标内容可参见《XX电信企信部指标体系》
--==   ==
++==  ==
  == **6.3故障分析** ==
@@ -1390,7
          +1390,6 @@
  |故障通告|系统故障，对用户造成较大影响时，比如影响程度为1的事件|受影响用户|故障解决后
  |停机通告|影响为1和2的变更在执行前，需要发出停机通告|受影响用户|变更完成后
--
  === **1.3.2公告用语** ===
  公告包括“标题”“正文”“落款”三个组成部分。
@@ -1420,7
          +1420,6 @@
                                                           ~*~*~*~*-*-~*~*
  )))
--
  |**种类**|信息公示
  |**内容要求**|需说明信息内容，信息所针对范围，信息生效和失效时间。
  |**范例**|(((
@@ -1441,7
          +1441,6 @@
                                                         ~*~*~*~*-~*~*-~*~*
  )))
--
  |**种类**|操作指导
  |**内容要求**|需要说明系统名称，发布操作指导的原因和使用场景。
  |**范例**|(((
@@ -1460,7
          +1460,6 @@
                                                         ~*~*~*~*-~*~*-~*~*
  )))
--
  |**种类**|故障通告
  |**内容要求**|需要说明故障原因，影响范围，预期解决时间，当然还要表示歉意
  |**范例**|(((
@@ -1477,7
          +1477,6 @@
                                                            ~*~*~*~*-~*~*-~*~*
  )))
--
  |**种类**|停机通告
  |**内容要求**|需要说明停机原因，影响范围，预期恢复时间，当然还要表示歉意
  |**范例**|(((
@@ -1495,7
          +1495,6 @@
  )))
--
  = **附录二:服务台运行管理要求** =
@@ -1523,7
          +1523,7 @@
  服务台经理对整个服务台的事件处理情况负责。
--===   ===
++===  ===
  === **1.1.5投诉升级机制** ===
@@ -1531,7
          +1531,7 @@
  事件超时时会自动升级至事件经理，事件经理通常是服务台经理兼任，事件经理有责任和权利协调资源优先处理升级事件，包括与二线团队协调资源。
--===   ===
++===  ===
  === **1.1.6报告机制** ===
@@ -1539,7
          +1539,7 @@
  服务台建议设置周报和月报制度，每周和每月定时将报告汇总给服务台经理。
--===   ===
++===  ===
  === **1.1.7回访处理** ===
@@ -1550,31
          +1550,31 @@
  以下为对于服务台人员在处理投诉时的基本方法建议，实际上这些建议对于非投诉类Case的处理一样适用。
--===   ===
++===  ===
  === **1.2.1用心聆听** ===
  聆听是一门艺术，从中你可以发现客户的真正需求，从而获得处理投诉的重要信息。
--===   ===
++===  ===
  === **1.2.2表示道歉** ===
  如果你没有出错，就没有理由惊慌，如你真的出错，就得勇于面对。请记住客户之所以动气是因遇上问题，你漠不关心或据理力争。找借口或拒绝，只会使对方火上加油，适时的表示歉意会起到意想不到的效果。
--===   ===
++===  ===
  === **1.2.3仔细询问** ===
  引导用户说出问题重点，有的放矢。表示同情如果对方知道你的确关心他的问题，也了解他的心情，怒气便会消减一半。找出双方一起同意的观点，表明你是理解他的。
--===   ===
++===  ===
  === **1.2.4记录问题** ===
  对于投诉类的问题，必须忠实详尽的记录投诉者、投诉的原因、被投诉者、内容、处理过程、解决情况等信息。
--===   ===
++===  ===
  === **1.2.5解决问题** ===
@@ -1625,5
          +1625,4 @@
  )))|二线支持团队
  |日常培训|即为传统意义上的“传帮带”|服务台日常工作熟练|服务台资深员工
--

粤ICP备17056641号

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