第1章前言

为了提升XX电信企信部运维服务质量，保障对所支持系统和业务的及时响应，改善事件的处理效率，参考ITIL最佳实践并结合XX电信企信部目前的运维现状，对事件处理的过程进行梳理，并形成管理规范和操作指导。

1.1.本文适用对象

本文作为XX电信事件管理流程的参考，供XX电信参与到事件管理流程中的人员和相关的管理层使用。

1.2.前提与假设

读者应该了解ITIL，并对流程具有基本的技能

在本文中“客户”是指报告事件，或是受到事件影响的人员或部门，与ITIL中的客户（Customer）的定义略有不同

1.3.名词定义

为了推进事件管理流程在XX电信的有效应用，在事件流程设计开始统一相应的设计语言，方便各级人员对事件管理流程的理解。

1.4.阅读指南

本文所有工作流程均使用Line of Visibility Engineering Methodology (LoVEM)描述。LoVEM 可提供工作流程的图形化表述。流程中涉及的角色（Roles）定义于左列，还包括用户等其他内容；右侧是流程的每个步骤或环节。

流程的各个步骤分布于各角色相对应的行，各步骤从左到右排列，箭头连接各步骤并表明信息和数据的流向。

每个流程步骤均以图形化表示，并以图表显示步骤的流程、执行相应步骤的角色和各项步骤的内容

第2章概述

2.1.流程目的

事件管理的主要目标是争取在最短的时间内解决、恢复，尽量避免或减少事件对用户造成影响。事件管理需要保留事件的有效记录，给其他的服务管理流程提供相关的信息，以及正确报告进展情况。

2.2.流程范围

事件管理的范围主要是针对XX电信企信部所管理和维护的应用系统及IT相关基础架构设施所发生的业务问题、系统故障、信息咨询和客户投诉。

第3章角色与职责

3.1.领导小组

担任者：

领导小组由IT运行保障部领导组成

职责：

负责对重大事件实施应急处理的决策和应急资源统一指挥调配，及时向上级机关汇报情况，执行上级领导的命令。

3.2.事件管理流程负责人

担任者：

事件管理流程负责人由服务台经理担任，

职责：

作为事件管理流程的责任人，对于整个流程执行的结果负责，并有一定的权力管理流程。

3.3.事件经理 

担任者：

事件经理由服务台经理担任A岗，必要时服务质监岗和服务分析岗可以兼任事件经理B岗

职责：

负责协调事件管理的日常操作步骤，并管理工作的时间安排。

3.4.服务台

担任者：

服务台人员由IT运行保障部服务台担任，主要操作人员包括：省客服接口岗、监控操作岗、服务受理岗、服务质监岗和服务分析岗

3.4.1.省客服接口岗

承接省客服工作要求、进行分解和分派、对分派工作进行跟踪管理（五个一工程、全业务服务达标、“天翼腾飞”劳动竞赛等）

3.4.2.监控操作岗

对IT系统和业务平台的运行情况进行监控和巡检，主动发现问题并进行分类、派发、跟踪、确认和考核；配合客户服务质监和分析工作。

3.4.3.服务受理岗

服务受理岗承接内部和外部客户投诉故障申报，对投诉故障分类和分派，工单跟踪管理，确保投诉处理工作按时、按质完成。

3.4.4.服务质监岗

服务质监岗主要负责重点事件的质量跟踪和监管以及服务台内部质量管理工作，对服务质量指标监控、督促和考核；升级与紧急事件督办；投诉与重要问题回复；配合客户服务分析工作。

3.4.5.服务分析岗

服务分析岗主要负责重大问题的逐级上报和编写对外通知；服务处理报告编写和分析；服务质量回顾分析；故障回顾分析和规律发现；配合质监岗工作。

3.5.支持人员

担任者：

支持人员由计费结算部、应用开发维护部、IT运行保障部所有技术支持人员组成

企信部各部门按照各自负责的技术领域进行技术支持分工，具体如下：

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运行保障部职责范围内的事件单，主要指基础架构环境相关的系统故障等，组内岗责划分如下：

3.5.3.2.支持组

1. 支持组正常情况下不参与处理故障，以下情况支持组将参与对事件的处理：

• 运行组无法处理的故障
• 重大故障
• 升级并引起关注的故障

支持组组内岗责划分如下：

第4章事件管理流程说明

4.1.事件出入口

4.2.事件管理流程概述

下图从总体上描述了事件管理流程、执行步骤和各步骤执行的顺序。

在事件管理流程中所提及的事件，是指湖南电信企信部维护范围内的所有与IT基础架构和应用相关的故障、咨询和投诉。

事件管理流程必须对事件要速度响应和和尽快恢复业务运作。

事件管理流程主要包括五个主要环节：

1. 同时，为了事件管理流程得到持续改进和优化，在事件管理流程中还要包括两个环节：

• 事件管理计划及实施

事件管理的建设和设计，并成为事件管理流程建设和改造的蓝本。

• 事件管理回顾

对事件管理流程的运行结果进行回顾，提出相应的改进计划。

4.3.流程步骤细节描述

4.3.1.事件检测与记录

4.3.1.1 描述:

该步骤要快速、准确地探测和捕捉所有在IT生产环境中发生的错误现象，同时，及时将信息通知到相关的部门。在本步骤中，需要收集创建一个事件单所需要的信息。在收集信息中要准确、完整地记录必要的信息。

4.3.1.2该流程主要内容:

根据事件请求和服务请求，实施发起请求、识别并验证请求来源、更新相应工单、记录请求、信息是否充分、创建公告、通知用户等措施；输出创建的事件工单或关闭事件

4.3.1.3 具体步骤:

1.根据数据来源所提出的相关事件。

1． 接受客户的服务请求

2.根据唯一的客户信息识别并验证客户信息，需要尽量多地获取客户基本信息：

• 客户姓名（必填）
• 客户标识（普通员工、主管、经理等）
• 电话号码（手机）（二者必填一项）
• 分机号码
• 员工当前所在地点
• 邮件地址
• 所属部门

提示：

• 建议预先记录客户的信息以保障服务目标信息准确
• 可使用员工电话号码等作为客户的唯一识别
• 及时更新客户信息十分必要，可用帮助支持人员及时找到事件报告人

3.检查该客户是否属于服务对象的范围

4.如有必要，帮助客户更新客户资料，如联系方式

1.对于原有的事件单，根据客户所提供的事件请求进一步的描述信息，对之前由该事件请求所产生的事件单进行进一步补充

2.补充后的工单仍按原有工单流程进行处理。

1.创建事件请求，生成事件工单，进入后续流程。

2.在事件单中至少需要录入以下事件信息，以下信息需要详细而准确： 

• 事件的概要描述
• 事件的详细信息，包括事件可能造成的服务影响，影响部门等。
• 可能的描述事件现象的附件
• 事件发生的时间
• 事件来源:与咨询相关的事件
• 事件报告人信息

3.针对不同事件来源，需要填写不同的事件来源信息：

4.事件单如果是来自客户的服务请求，则需要填写客户信息，至少包含以下内容：

• 客户姓名 
• 客户标识（普通员工、主管、经理）
• 联系电话/手机
• 所属部门

5.如果是系统自动触发的，事件告警信息是通过系统接口自动载入，至少包含以下内容：

• 事件告警严重等级
• 事件告警编号
• 事件告警信息
• 是否是自动触发还是手工触发，如是手工触发，则还需要记录触发人员的帐号。

6.如果该事件单是由运维人员主动发起，运维人员作为事件提交者其相关信息由系统自动填写，至少包含以下内容：

• 运维人员帐号及姓名
• 运维人员联系电话

7.根据客户提交请求，进行配置信息判断，关联对该事件造成影响的配置项

8.如果该事件是由于变更实施失败导致，需要在创建新事件的同时关联引发失败的变更单。

9.创建事件单后需要判断是否为服务范围，如果信息不足则进入“1.5 等待进一步信息”

10.如果是服务范围则进入“事件分类与初步支持”，如果需要的话在“1.6 创建公告”

11.如果不是服务范围，则在“1.7通知用户”，通知用户关闭事件单

1.  通知并等待用户提供进一步信息

1.如果事件影响较小，不会造成大范围的影响，则不需要创建公告。

2.需要创建公告的事件可以包括以下情况：

• 事件范围大，一个部门以上的用户使用收到影响需要通知的
• 信息类，需要向一个以上部门发出通知或者解释说明的

1.通知用户并关闭事件

2.通知用户的手段包括： 

• 邮件通知
• 电话通知
• 短信通知

4.3.2.事件分类与初步支持 

4.3.2.1 描述：

该步骤要对每个事件进行正确的分类，在现存的解决方案中查询与该事件相匹配的方案。若没有找到合适的解决方案或变通方法，该事件需要分配给一个具有合适技术技能的支持人员。

图‎2-3. 分类与初始支持

4.3.2.2流程主要内容:

根据“事件检测与记录”的事件单、处理过程中回退和处理完成后重新打开的请求，实施判断请求类型、判断事件严重性优先等级与分类、关联到主事件、更新主事件信息、查找可能的解决方案、尝试解决、实施解决方案、事件分派、进行事件分析、执行升级、直接转派等措施，输出已分派的事件工单、已解决的事件工单和提交关闭

4.3.2.3 具体步骤:

1.判断请求类型，如果是信息咨询类，则提供信息后进入“事件关闭”

2.根据客户提供的信息，判断该事件是否会对CI（配置项）造成影响

3.进入环节“2.3 判断事件严重性、优先等级、分类”

1.查询事件的表现症状，所需要的信息如下：

• 事件简要描述
• 可能影响了什么服务
• 必要时提供软件和硬件配置信息

备注：

• 事件信息的准确记录十分关键
• 对事件进行准确分类 是事件能够得到快速解决的前提
• 具体分类规则参见5.1.5 事件分类

2.记录事件的表现症状根据事件描述状况进行事件分类

3.如果是客户报告的事件请求，了解该事件对服务可能产生的影响

4.如果是运维人员报告的事件请求，运维人员在提交事件请求时根据5.6“优先级”定义设定事件的优先级

5.如果是监控系统产生的告警事件，根据5.6“优先级”定义设定事件的优先级（注，目前湖南电信尚没有监控系统，此处为为未来系统接口做的扩展考虑）

6.依据预定义的事件优先级业务规则，在事件单中记录优先级（事件的优先级表应根据实际情况实时修改）

7.事件基本特征判断完成，根据客户提供事件描述信息查找是否存在的症状类似的事件工单。

• 如果存在类似的事件单，转入环节“2.3 关联到主事件”。 
• 如果不存在类似的事件单，进入“2.5 查找可能的解决方案”。

提示：

• 类似事件通常表现为由于某个原因导致的多个客户出现的同一症状的服务不可用

1.如事件单为重复或类似的未解决的事件，将新的事件单关联到原有事件单，原有事件单进行更新。

• 原有事件单被标识为“主事件单”
• 原有事件单关联事件单数加一
• 新建事件单出现在原有事件单重复工单列表中

2.新事件单状态将随原有事件单状态的更新而更新，不单独进行处理

1.查找可能的解决方案将提供两种途径：

• 在原有事件工单中查找可能的解决方案或临时变通方法
• 在关联的知识库中查找可能的解决方案或临时变通方法

2.根据查询结果，判断是否存在可能的解决方案或变通方法；

• 如果存在解决方案/变通方法，转至“2.7 实施解决方案”
• 如果没有找到解决方案/变通方法，转至环节“2.6 尝试解决”；

1.服务台人员根据自身所拥有的技能尝试确定“解决方案或变通方法”，进行事件解决；

• 如果可以解决，转至转至“2.7 实施解决方案”
• 如果不能解决，转至环节“2.8 事件分派”；

1.在系统中实施临时措施或解决方案，使服务得到恢复。

2.服务恢复之后，进入步骤“事件关闭”

3.此环节通常是在流程系统外完成，将实施完成的结果登记到流程系统中

1.根据事件分类不同，进行事件分派；

• 不同的事件工单会有不同的事件类别和所属地点属性；
• 根据事件类别和地点属性不同，事件工单会被直接分派到相应的技能组/支持人员，转至环节2.9“进行事件分析”；

2.服务台在执行“事件关闭”操作时发现某些事件在得到支持人员事件解决的反馈后，由服务台与客户沟通后发现客户未认可事件得到解决，则该事件重新进入“分派事件”环节。

提示：

• 根据XX电信目前事件分配状况，按事件工单分类不同分派到不同的技能组

1.得到事件工单分派的通知，进行事件检查，并确认是否接受分派的事件工单

2.支持人员查看事件，判断是否具备执行事件诊断和分析的技能

• 如果具备，接受这个事件并转至步骤4.3.3“调查和诊断”,环节3.1 “进行事件分析与评估”.
• 如果不具备，需要升级，转至环节“2.10 执行升级”
• 如果不具备，无需升级，转至环节“2.11直接转派”

1.执行升级的情况如下：

• 事件的处理非常复杂，耗时较多
• 派单次数超过3次，升级至相关事件经理及相应直属领导
• 事件经理或客户对事件处理过程不满意，要求支持人员重新处理事件，需要升级至相关事件经理及相应直属领导

1.对于支持人员之间的转派，可以直接实现，组内转派到人，组间转派到组

2.工单转派后，进入环节“2.9 进行事件分析”，支持人员接到工单后进行事件分析

3.转派的原因如下：

• 支持人员不具备解决该事件单的技能或时间，直接将事件单转派给其他支持人员
• 支持人员认为该事件单出现分类选择错误，导致处理人员选择错误，可以在修改该事件单的分类后，将事件单转派给其他支持人员
• 在事件单处理过程中，支持人员难以找到解决方法，可以直接将事件单转派给其他技能较强的支持人员
• 在事件的解决时，发现解决方案需要改进，而自身能力有限，支持人员可以转派工单给其他支持人员，改进解决方案
• 事件经理对事件处理过程不满意，事件单功能升级后，工单派至相应分析员重新进行补充处理
• 用户对事件处理结果不满意，事件单进行功能升级后，事件记录员退回工单至相应的处理人员，重新进行处理

4.3.3.事件调查和诊断

4.3.3.1.描述: 

    这个步骤阶段要进行深入调查，对事件进行诊断，以解决事件。支持人员要根据步骤找到合适的解决方案或变通方法。

4.3.3.2.流程主要内容:

根据初步分类的事件单、分析员主动发现的事件、未成功解决的事件单、知识库现有知识、事件数据库中的现有解决方案，实施事件分析和评估、收集分析相关信息、再次确认严重等级及分类、进行关联、诊断、试图解决事件的措施，得出“解决和恢复”工单、需要升级的工单或事件关闭的工单

4.3.3.3 具体步骤:

1.来源于用户的事件，将在本环节对事件进行分析和评估

2.来源于支持人员的事件报告，创建工单后，直接进入该环节，对事件进行分析和评估

3.在事件的调查和诊断中，需要对关键信息进行补充搜集，进入环节“3.2收集分析相关信息”

1.支持人员查找事件处理的有用信息，获得信息后，记录到事件工单中

2.需要用户提供进一步信息时，可以主动联系用户收集信息

3.完成信息的收集和分析后，进入环节“3.3再次确认严重等级及分类”

1.根据对事件的分析和评估，再次确认事件的分类

2.从专家角度再次确认事件的严重等级，并对错误等级进行调整

3.如果有相关事件，进入环节“3.4进行关联”；否则，进入环节“3.5 诊断”

1.如果该事件单有关联事件单，进行事件单关联

2.如果该事件单为现有事件的主事件

• 原有事件单被标识为“子事件单”
• 原有事件单出现在现有事件单的子工单列表中
• 事件单进入环节“3.5诊断”

3.如果该事件单为现有事件的子事件

• 原有事件单被标识为“主事件单”
• 新建事件单出现在原有事件单的子工单列表中
• 原子事件数量加1

4.子事件单状态将随主事件单状态的更新而更新，不需要单独进行处理子事件单，如果主事件单进入“已解决”状态，子事件单随之更新为“已解决”状态

1.支持人员利用已有信息，对事件进行诊断，确认事件的详细情况

2.完成诊断后，转入环节“3.6试图解决事件”

1.根据对事件的诊断，着手处理事件，通过专业知识尝试进行解决，寻找可能的解决方案或变通方法

2.如果寻找到解决方案或变通方法，进入步骤“4解决与恢复”，如果没有寻找到解决方案或变通方法，进入步骤“4.3.2 分类与初步支持”

4.3.4.解决和恢复

4.3.4.1.描述:

这个步骤要使用解决方案和变通方法来解决事件。对于某些事件，需要创建变更单或者需求单解决事件。

4.3.4.2.流程主要内容:

根据“调查与诊断”事件工单、解决方案/变通方法，实施沟通决绝方案/变通方法、创建变更请求、创建需求请求、任务分解并分派、采取恢复操作、验证解决结果，输出沟通后部实施解决方案/变通方法的事件进入“分类与初步支持”、解决失败的事件进入“调查与诊断”已经恢复的事件进入“事件关闭”、需要通过变更解决的事件/流转至变更管理流程/发起变更申请。

4.3.4.3.具体步骤

1.与用户沟通即将实施的解决方案/变通方法

2.如果用户不同意实施解决方案/变通方法，进入步骤“2分类与初步支持”

3.如果用户同意实施解决方案/变通方法，分析是否需要进行变更，如果需要变更，进入环节“4.2创建变更请求”；如果不需要变更，则：

• 是否需要创建需求，进入环节“4.3 创建需求请求”
• 是否需要配合完成，进入环节“4.4 任务分解并分派”
• 如果不需要，进入环节“4.5 采取恢复操作”

1.创建变更请求单，进入变更管理流程

2.变更实施完成后，进入步骤“5事件关闭”

1.创建需求请求单，进入需求管理流程

2.需求单创建后，直接关闭事件工单

1.对事件单进行分解并分派到其它支持人员

2.任务单处理完成后，处理任务单的支持人员进行相关反馈

3.任务单完成前，事件单不可以转入“已解决”状态

4.所有任务处理完成，收到反馈后，进入环节“4.6验证解决结果”

1.与客户就解决方案/变通方法达成一致意见后，进入实施

2.处理完成后，进入环节“4.6验证解决结果”

1.对解决结果进行验证

2.如果服务恢复，进入步骤“5事件关闭”

3.如果服务没有恢复，进入步骤“3调查与诊断”

4.3.5.事件关闭

4.3.5.1.描述:

    这个步骤要确保客户对事件的处理情况感到满意。保证事件单的信息是正确、完整的，以便于以后生成报表。处理过程中的经验要得到记录以形成可重用的知识。

4.3.5.2.流程主要内容:

根据“1检测与记录”“2分类与初步支持”“3调查与诊断”“4解决与恢复”的事件、已经完成的变更、用户对解决情况的反馈，实施验证并检查记录、更新工单记录、与用户沟通、关闭相应公告、关闭工单等措施，输出已关闭的事件单、经过检查没有解决的事件单以及用户不满意的事件单

4.3.5.3.具体步骤

1.告警消除的来自监控系统的事件，事件记录员对结果进行验证，并确认事件单的完整性

2.对于来自于用户的事件，对事件单内容的完整性的进行确认

3.如果记录不完整，进入环节“5.2更新工单记录”

4.如果工单记录完整，判断工单关闭是否需要用户确认，如果需要用户确认，进入环节“5.3与用户沟通”；如果不需要用户确认事件解决结果，直接进入“5.4关闭相应公告”

1.支持人员接到服务台需要更新事件记录的通知后，对事件单进行完善，补充事件记录

2.事件单补充完成后，事件记录员判断工单关闭是否需要用户确认，如果需要用户确认，进入环节“5.3与用户沟通”；如果不需要用户确认事件解决结果，直接进入“5.4关闭相应公告”

1.联系用户，征询对事件处理结果是否满意，记录用户意见

2.如果用户对事件的解决不满意，则转入步骤“2分类与初步支持”

3.如果用户满意解决结果，进入“5.4关闭相应公告”

1.如果有相应公告，进行关闭

2.进入环节“5.5关闭事件单”

1.来自于支持人员提出的事件，处理完成后，直接关闭事件单

2.用户提出的事件，由事件记录员关闭事件单

4.3.6.跟踪回顾

4.3.6.1.描述:

在进行事件处理过程中，为了保证XX电信企信部提供业务支持的服务质量，保证对事件的及时响应和快速解决，事件经理要对事件的整个处理过程进行实时监控，处理升级的事件。

4.3.6.2.流程主要内容:

根据未解决的事件、客户提出的查询请求和升级的事件单，实施选择事件、跟踪/回归过程、要求更新工单、更新信息、交流事件状态，得出更新记录的事件单和进一步升级的事件单

4.3.6.3.具体步骤

1.进入事件管理流程系统，查询执行过程中的事件工单

2.选择要跟踪回顾的对象

1.浏览跟踪回顾的事件工单，主要包括：

• 事件处理日志
• 事件解决方案或变通方法
• 事件处理耗时

2.必要时，要求事件处理人员更新事件单信息，进入环节“6.3要求更新记录”

3.如果对事件处理过程不满意，则升级事件，进入环节“4.3.2分类与初步支持”

4.如果还需要进一步联系用户，进入环节“6.5交流事件状态”

5.如果对处理过程满意，且不需要进一步联系用户，则跟踪回顾结束

1.如果事件单信息不完整，要求事件处理人员更新事件单信息

1. 事件处理人员对事件单内容进行更新

2.事件更新结果反馈回事件经理，事件经理进行下一步操作

1.如果需要与用户交流事件的处理状况和情况，联系用户进行沟通，并补充到事件工单中

2.交流结束后，跟踪回顾结束

4.3.7.重大（危机）事件

重大故障由服务人员在处理过程中主观发现和定义，判断依据如下：

• CRM系统、计费、结算系统等核心应用系统业务瘫痪或中断；
• 省级生产网络瘫痪或中断；
• 事件管理中“紧急程度”和“影响程度”均为最高的故障；

以上故障可称为重大故障。

重大故障的组织和协调机制，参见《湖南电信重大故障管理办法》

第5章业务规则

注：所有在本章节所提及的日期和时间是指“经过的（elapsed）”的日期和时间。

5.1.总体业务规则

1.XX电信所支持的系统和网络环境中，所有对操作特性和服务提供有影响的事件都会通过事件管理流程处理；事件将通过流程中定义的标准、业务规则和指导进行管理。

2.所有报告和处理事件的部门将会参与统一的事件管理流程，不应该有任何例外。

3.所有IT支持人员对优先级（极高）和（高）的事件所采取的恢复服务的行动，相比其他任务具有优先权。

4.对于省客服、省NOC、10000号等外部转派的事件单并带有解决时间要求的，应遵照其解决时间的要求进行处理。

5.应由服务台定期产生和回顾事件管理报表。对没有解决的问题，应生成问题进行跟踪和处理，服务台对此有考评职责。

6.应由服务台定期对流程进行回顾，以改进事件管理流程。

5.1.1.责任人业务规则

事件管理需要定义一个责任人业务规则，以确保每个事件在任何时段都有适当的人员负责。

事件管理：

1.当一个事件被创建后，服务台负责这个事件单

2.当事件单被分派后，支持人员负责此事件单；在故障现象描述和对应正确时，被分派方遵循首问责任制，被分派的支持人员有权拒绝故障现象不属于本组职责范围内的事件单。

3.如果需要向客户通知处理情况，由事件单的当前责任人负责

5.1.2.分类规则

1.分类分为两个，“故障现象分类”和“故障根源分类”

2.服务台派单时填写故障现象，以故障现象为准分派支持人员

3.支持人员转派事件和解决事件时以填写故障根源，故障根源为准

具体分类参见《事件管理设计信息表》

5.1.3.分派业务规则

1．分派业务规则主要决定由服务台创建事件后的分派原则。

5.1.4.代办业务规则

考虑到XX电信在人员组织方面的实际情况，可以允许在事件处理过程中实现代办功能，代办原则如下：

• 服务台和支持人员，由于某些原因（例如出差，休假，培训等）离开本岗位时，必须确保将未处理完毕的事件单重新分派到本岗位其他事件处理人员；如果
• 本岗位只有自己一人，则通过指定代办人的方式，确保在代办期间，由代办人处理该岗位的各项工作；

5.1.5.优先级

1. 事件的优先级表明了支持人员对事件工单处理的优先程度。它是评定事件处理优先等级的一个重要指标。
2. 所有事件都将分配到四个优先级中的一个。优先级从 1 (极高) 到 4 (低) 。
3. 优先级在事件的生命周期中是可以改变的。关于更改事件单优先级的原因和行为应该在事件单中记录。
4. 事件的优先级通常由两方面的指标共同决定：事件影响度及事件紧急程度。

5.1.5.1.事件影响程度

• 事件影响度规则
  • 规则一：事件影响程度由服务台或支持人员建单和受理时判断定义
  • 规则二：事件影响程度定义如下表所示
• 我们可以根据一个表格来制定湖南电信事件的影响程度，在下表中对事件的影响程度按照四个等级进行划分，每个等级中对事件的表象进行了描述，服务台可以根据影响程度的定义对事件进行影响度的划分：

5.1.5.2.事件紧急程度

1. 事件紧急程度规则

• 规则一：事件的紧急程度划分为三级 ---- 高、中、低
• 规则二：事件紧急程度由用户或服务台按照“用户类型”和“分类”交叉运算得出
• 规则三：没有明确用户类型的事件紧急程度默认为“中”
• 规则四：投诉类事件和升级事件紧急度默认为“高”

示例表：

具体参见《事件管理设计信息表》

5.1.5.3.事件优先级的计算方法

1. 计算方法：按照“影响范围”和“紧急程度”交叉运算得出优先级
2. 规则：事件的严重等级由系统根据紧急程度和影响程度自动运算得出

计算规则如下表所示：

优先级业务规则将用于服务台，支持人员在进行事件优先级判断时参考使用。具体参见《事件管理设计信息表》

5.1.6.目标解决时间业务规则

1. 在事件处理的每个环节中，按照严重等级不同有不同的处理时间限制，超过时间将执行升级上报。
2. 事件得到响应：指服务台在接到故障申报到分派处理的时间
3. 事件单接受：指从服务台分派事件单到支持人员开始，到支持人员接受分派的时间
4. 服务得到恢复：指支持人员从接受分派到解决事件的时间
5. 工单得到关闭：指支持人员解决事件后，到确认结果并关闭事件的时间
6. 事件管理的目标时间如下表所示： 

表 3-4. 事件目标时间业务规则

5.1.7.等待规则

1. 事件可能会超过目标时间上限，但这些原因有一些是客观的，无法预期的，当事件由于这些原因进入等待状态时，等待中的时间将不计入目标时间计算中。
2. 等待需要遵循以下规则：

5.1.8.通知业务与升级业务规则

1. 规范一：根据湖南电信管理现状，事件升级将执行事件上报通知，以及将紧急程度置为“高”
2. 规范二：事件升级触发条件包括：转派3次升级、解决驳回2次升级和超时升级
3. 规范三：事件上报通知对象必须包括事件经理。在必要时，除事件经理外还可包括相关部门领导
4. 事件通知触发条件和通知对象：

图例:  U：相关用户；C：事件记录员；E：支持人员；M：事件经理

表 3-6. 通知业务规则

5.1.9.标准的通知内容

1. 通过通知业务规则进行沟通的事件信息可以通过电话、系统消息、电子邮件或者短信等方式发送，并将遵循标准的格式。下列的几个通知内容项应当以容易理解的方式进行描述：

• 事件的简要描述
• 受到影响的服务
• 预计恢复服务的时间（要尽可能准确） 
• 联系服务台咨询更多信息的方法
• 通知方式可以考虑通过短信或邮件方式自动进行。

5.1.10.重复业务规则

1. 对于重复事件，将采用“主+从”关系绑定的方式处理，“从事件单”状态和受理人与“主事件单”相同。如果被报告的事件与某个已经创建且尚未解决的事件单症状相同，则该事件被认为是重复的。

5.1.11.复发业务规则 

1. 如果报告的事件与已经关闭的事件相同（查询范围含时间），该事件被认为是“复发”的事件单。这意味着为了解决事件而采取的解决措施失败了。此时应当创建一个新的事件单，复制原始事件单的内容，并说明这是复发的事件。

5.1.12.事件单关闭业务规则

1. 服务台和用户进行确认并关闭工单
2. 事件关闭有以下业务规则：

第6章质监合规与分析考核

6.1质监合规

服务台质监需要注意两个方面

第一，是日常的流程执行质量和合规要求的质监，通过系统和人工手段对每张工单进行实时质监，由服务台服务受理岗和质监岗对质监出现问题的工单及时介入进行督促协调或者请求领导支持。

第二，是收集和整理质监数据，分析流程的执行效率和存在的瓶颈及问题。此项工作可以按月度或者季度进行，由服务台质监岗牵头，事件经理负责。

如下表：

工作方式：“自动”为系统可以帮助完成；“半自动”为系统可以帮助完成一部分信息收集工作，只能起到辅助作用，最终还是需要人工判断；“人工”指的是系统无法提供帮助，属于人工完成的工作。

6.2考核分析

考核的方面包括：

• 对本地网服务台的考核
• 对二线处理的考核，对厂商的考核要求将归并到对二线人员的考核中；
• 对企信部服务台自身绩效考核。

具体考核指标内容可参见《XX电信企信部指标体系》

6.3故障分析

故障分析主要是两个维度的工作，为服务质量的提升找到数据上的依据和切入点：

• 第一，故障规律分析；
• 第二，闭环管理相关分析；

故障分析由服务台故障分析岗和事件经理完成，一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础完成分析，召开例会，总结经验教训并修正不合适的分析指标。

分析例会应根据需要选择以月例会、季度例会的方式进行

分析内容如下：

第7章流程维护机制

流程本身是需要不断完善和优化的，在日常工作、流程回顾、故障分析时都会产生对流程本身进行优化调整的需求，很多企业优化工作陷入停滞，最主要的原因就是缺少一套行之有效的维护机制。

对此，在管理上需要执行一套简单易行的维护机制，简述如下：

执行周期是对操作时间窗口间隔的限制，过于频繁的规则和配置修正会影响流程的有效推广

其他（如二线）人员需要对流程的配置信息和规则进行修改，需要将建议提交服务台，由服务台发起

附录一:日常工作管理要求

1.1日常管理

1.1.1轮班制度

信息中心，尤其是服务台小组应当制定一个轮班制度和步骤，并明确由何人负责修改该制度、步骤，由谁授权这些修改，如何发布新的修改，并制定修改的规则，以保障操作员的利益。

1.1.2休假，培训，病假和其他事假

应当记录并维护所有的缺席状态，确保核心系统总是技术人员能够支持。应当制定审批休假的授权标准，确定授权人，确保现场有足够的人员工作。另外，应当制定备份方案，以防关键人员病假或者其他原因不能到场支持。

1.1.3电话值班

对于核心业务系统，每天应当确定在正常工作时间之外的主责支持人员和后备人员，称为“电话值班人员”，当天的支持人员应当确保手机等联络工具通畅。特别对于一些不太稳定的系统，工作时间之外可能更需要频繁的现场支持。值班人员应当清楚了解每个支持人员的联系方式，以防主责人员联系不到时可以联系后备人员。

应当建立内部的服务水平，如：对于紧急电话的响应时间、到现场时间、解决问题的时间等，加强对于紧急事件处理的责任感和效率。

如果支持人员未能响应，或者未能及时到场，可以采用事件升级的步骤。

1.2检查清单（备忘录）

1.2.1换班交接检查清单 

可以为所有参与操作值班的员工制定一份检查清单，避免员工在交接班的时候遗漏任何应当转交的内容。

1.2.2其他交接清单（如：服务台与操作小组之间的交接）

同样，也可以为服务台（在工作时间接受事件报告）与操作组（在非工作时段接受事件报告）交接时制定交接清单。该清单应包括所在值班时段发生的重大事件，以及一些需要下一班注意的事项。

1.2.3监控检查清单

所有的维护组员工应当制定每日维护工作的检查清单，包括每日应当监控和检查的项目（如：必须人工检查的内容，设备指示灯、屏幕、以及运行一些检查脚本程序的结果等），以及其他每日例行的工作。检查清单可以细分为日检查清单、周检查清单、月检查清单、年检查清单。这些清单应当由小组长签字，确保所列项目都已执行。

如果某个员工遗漏了某些检查项目，必须有正当的理由。

1.2.4值班日记（包括注意事项、意外情况、经验教训等） 

很多IT部门的操作部门都会维护一份值班日记，纪录值班期间发生的意外情况、注意事项、经验教训等。值班日记也成为交接内容的一个重要部分。

1.3公告管理

“公告”指信息中心对其所服务对象（各业务部门）的信息公示手段，可采用的手段包括系统公告，邮件群发，张贴纸质通告等手段，目的就是将信息最有效的通知到目标人群。

公告建议由服务台人员统一管理。

非服务台人员在具备发出公告条件时，需通知服务台人员，由服务台人员负责发出公告，通知方式不限。

1.3.1触发条件和通知对象

1.3.2公告用语

公告包括“标题”“正文”“落款”三个组成部分。

附录二:服务台运行管理要求

1.1服务受理规范

1.1.1客户信息记录准确

受理Case时首先要询问员工编号，没有员工编号的可以记录临时邮件账号或联系电话，以便进行Case问题的跟踪及进行信息反馈。

1.1.2问题信息记录准确

详细记录客户描述的问题现象，当可以解决问题时需记录问题原因及解决方法，以便放到知识库中使资源共享。未能解决的问题可以分发给现场或进行初步处理，进行初步处理的Case要对问题进行跟踪，直到问题解决。

1.1.3处理客户投诉遵循的原则

1.1.4状态跟踪机制

我们遇到投诉或者是投诉升级的时候经常会发现，好像每个处理的人都做了合理的事情，但是投诉还是产生和升级了。其实这就是由于没有一个事件跟踪的流程导致的，很多部门配合的时候更容易出现这样的情况，因此说这种事件状态跟踪机制是必需的，而且不仅仅是在投诉的处理上面。事情的处理一定是闭环的，有头有尾的。

服务台人员必须首先对自己接手处理的事件负责，有责任和义务跟踪自己处理事件的当前状态并在需要时反馈给用户。

服务台经理对整个服务台的事件处理情况负责。

1.1.5投诉升级机制

有了状态跟踪机制其实并不能保证事情得到及时的处理，这需要另外一个机制来控制——投诉处理升级机制。如果一件事情在相应规定的时间没有解决掉，相关的管理者会逐级得到信息——该投诉未能及时处理完成以及当前的状态。这样相应的管理人员就逐渐参与到投诉的处理当中，加快事件的处理。而一般的投诉专人负责的岗位就已经可以处理了，管理者只需要按时得到每周的报告就可以了。

事件超时时会自动升级至事件经理，事件经理通常是服务台经理兼任，事件经理有责任和权利协调资源优先处理升级事件，包括与二线团队协调资源。

1.1.6报告机制

已经有跟踪、升级处理等机制，但如果想把用户投诉的问题转化为服务提升的动力，那详细的分析报告将是非常重要和必需的。一个简单扼要、眼光敏锐、总结分析到位的报告对管理者提升服务来说是很有帮助的。

服务台建议设置周报和月报制度，每周和每月定时将报告汇总给服务台经理。

1.1.7回访处理

投诉处理结束了，我们还有事情要做，就是对曾经投诉我们服务的用户进行回访，投诉过你的用户今后可能还是你的用户，请他谈谈对改进后的服务的看法，听听用户对整体服务的意见和建议。

1.2处理投诉的基本方法

以下为对于服务台人员在处理投诉时的基本方法建议，实际上这些建议对于非投诉类Case的处理一样适用。

1.2.1用心聆听

聆听是一门艺术，从中你可以发现客户的真正需求，从而获得处理投诉的重要信息。

1.2.2表示道歉

如果你没有出错，就没有理由惊慌，如你真的出错，就得勇于面对。请记住客户之所以动气是因遇上问题，你漠不关心或据理力争。找借口或拒绝，只会使对方火上加油，适时的表示歉意会起到意想不到的效果。

1.2.3仔细询问

引导用户说出问题重点，有的放矢。表示同情如果对方知道你的确关心他的问题，也了解他的心情，怒气便会消减一半。找出双方一起同意的观点，表明你是理解他的。

1.2.4记录问题

对于投诉类的问题，必须忠实详尽的记录投诉者、投诉的原因、被投诉者、内容、处理过程、解决情况等信息。

1.2.5解决问题

探询客户希望解决的办法，一旦你找出方法，征求客户的同意。如果客户不接受你的办法，请问他有什么提议或希望解决的方法，不论你是否有权决定，让客户随时清楚地了解你的进程。如果你无法解决，可推荐其他合适的人，但要主动地代为联络。礼貌地结束。当你将这件不愉快的事情解决了之后，必须问：请问您觉得这样处理可以了吗？您还有别的问题吗？……。如果没有，就多谢对方提出的问题。

1.3培训制度

培训是服务台服务的重要成功因素。若没有适当的初期和持续培训，服务台将不能提供最佳的客户服务。持续培训可以使服务台人员掌握所需技能。它也可以提高生产力，改善客户服务，此外还能增加服务台人员的工作满意程度，自信心。