Changes for page 28 某电信企信部ITIL信息技术服务管理体系管理办法——事件管理分册

Last modified by superadmin on 2024/06/24, 13:01

From version < 12.1 >

edited by superadmin
on 2024/06/24, 12:54

To version < 9.1 >

edited by superadmin
on 2024/06/24, 12:37

< >

Change comment: 上传新附件图片3.png

Raw
Rendered

Summary

Page properties (3 modified, 0 added, 0 removed)
Attachments (0 modified, 0 added, 2 removed)
- 图片4.png
- 图片5.png

Details

Page properties

Title

...	...	@@ -1,1 +1,0 @@
1		-28 某电信企信部ITIL信息技术服务管理体系管理办法——事件管理分册

Parent

...	...	@@ -1,1 +1,0 @@
1		-G 参考资料.ITIL实施项目资料.ITIL实施项目流程设计方案集.管理规范.WebHome

Content

@@ -1,1556
          +1,0 @@
--[[返回本章节索引>>url:https://itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/]]    阅读下一篇
--
--
--= **某电信企信部ITIL信息技术服务管理体系管理办法——事件管理分册** =
--
--
--=== **第一章 前言** ===
--
--
--为了提升XX电信企信部运维服务质量，保障对所支持系统和业务的及时响应，改善事件的处理效率，参考ITIL最佳实践并结合湖南电信企信部目前的运维现状，对事件处理的过程进行梳理，并形成管理规范和操作指导。
--
--
--
--===== **1.1 本文适用对象** =====
--
--本文作为湖南电信事件管理流程的参考，供湖南电信参与到事件管理流程中的人员和相关的管理层使用。
--
--
--
--===== **1.2 前提与假设** =====
--
--读者应该了解ITIL，并对流程具有基本的技能
--
--在本文中“客户”是指报告事件，或是受到事件影响的人员或部门，与ITIL中的客户（Customer）的定义略有不同
--
--
--===== **1.3 名词定义** =====
--
--
--为了推进事件管理流程在湖南电信的有效应用，在事件流程设计开始统一相应的设计语言，方便各级人员对事件管理流程的理解。
--
--|**名词**|**解释**
--|ITIL( IT Infrastructure Library)|是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT管理标准。
--|事件管理流程|ITIL流程之一，事件管理负责处理IT事件和用户请求。它的目的是尽快恢复被中断或受到影响的IT服务，是以解决表征现象为目的，而不在于查找根本原因。
--|服务|湖南电信企信部运维团队提供给内部和外部用户的支持内容
--|事件|是指湖南电信企信部维护范围内的所有与IT基础架构和应用相关的故障、咨询和业务处理。
--|危机|对于优先级为“紧急”并且严重性等级为最高的重大突发事件我们称之为“危机”
--|事件任务|是指在进行复杂事件处理时，由支持人员创建的需要其他支持人员辅助处理的任务
--|事件单|系统中存在的在事件管理流程中运行的以数据形式存在的工单
--|客户|指目前湖南电信企信部提供服务的业务部门
--|服务台|服务台从根本上来说是提供了用户和企信部的唯一接口。此项功能常通过集中方式提供服务。帮助台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。
--|支持人员|进行事件处理的支持人员，通常对应于湖南电信一线二线支持人员
--|事件经理|负责协调事件管理的日常操作步骤，并管理工作的时间安排
--
--
--
--===== **1.4 阅读指南** =====
--
--本文所有工作流程均使用Line of Visibility Engineering Methodology (LoVEM)描述。LoVEM 可提供工作流程的图形化表述。流程中涉及的角色（Roles）定义于左列，还包括用户等其他内容；右侧是流程的每个步骤或环节。
--
--流程的各个步骤分布于各角色相对应的行，各步骤从左到右排列，箭头连接各步骤并表明信息和数据的流向。
--
--每个流程步骤均以图形化表示，并以图表显示步骤的流程、执行相应步骤的角色和各项步骤的内容
--
--
--[[image:图片1.png]]
--
--
--
--=== **第2章 概述** ===
--
--
--===== **2.1 流程目的** =====
--
--事件管理的主要目标是争取在最短的时间内解决、恢复，尽量避免或减少事件对用户造成影响。事件管理需要保留事件的有效记录，给其他的服务管理流程提供相关的信息，以及正确报告进展情况。
--
--
--===== 2.2 **流程范围** =====
--
--事件管理的范围主要是针对湖南电信企信部所管理和维护的应用系统及IT相关基础架构设施所发生的业务问题、系统故障、信息咨询和客户投诉。
--
--
--=== **第3章 角色与职责** ===
--
--
--===== **3.1 领导小组** =====
--
--**担任者：**
--
--领导小组由IT运行保障部领导组成
--
--**职责：**
--
--负责对重大事件实施应急处理的决策和应急资源统一指挥调配，及时向上级机关汇报情况，执行上级领导的命令。
--
--
--
--===== **3.2 事件管理流程负责人** =====
--
--**担任者：**
--
--事件管理流程负责人由服务台经理担任，
--
--**职责：**
--
--作为事件管理流程的责任人，对于整个流程执行的结果负责，并有一定的权力管理流程。
--
--|**事件管理流程负责人的职责：**
--|(((
--* 全面负责流程的效率和成果
--* 建立流程考核和目标，以提升流程的有效性和效率
--* 为保障流程的有效性，需争取高级管理层承诺投入足够的资源
--* 鉴别和管理关键的流程成功要素
--* 控制和带领流程的改进
--* 批准和拒绝偏离流程的请求
--* 定义事件管理的角色、责任和应负的责任
--* 定义目标、流程、工作流、业务规则和规则，并与相关人员进行沟通
--* 强制事件管理流程的执行
--* 确保对客户进行流程满意度调查
--* 确保对流程的使用者提供适当的教育
--* 对其他流程负责人和管理层汇报流程的状况和进度
--* 对事件管理流程的有效性和效率进行监控，在需要的时候作出改进
--* 召开和主持对事件管理流程改进的季度会议
--* 审计事件管理流程的执行
--* 对事件管理流程的成本和投资负责
--* 作为事件管理流程对外的代表
--* 在适当的情况下，事件管理流程负责人可以把部分责任委任给其他人员执行。
--)))
--
--
--===== **3.3 事件经理 ** =====
--
--**担任者：**
--
--事件经理由服务台经理担任A岗，必要时服务质监岗和服务分析岗可以兼任事件经理B岗
--
--**职责：**
--
--负责协调事件管理的日常操作步骤，并管理工作的时间安排。
--
--|**事件经理的职责：**
--|(((
--* 协调事件管理的日常操作
--* 确定和执行流程本身的变更
--* 鉴别流程执行过程中的例外和异常情况, 并进行管理
--* 传达流程的新业务规则和更新的业务规则
--* 确保流程标准和步骤得到遵循
--* 作出资源的承诺和分配
--* 鉴别和实施流程的改进建议
--* 产生和分派流程管理的报表
--* 对事件管理流程的负责人提出改进的建议
--* 作为流程的集中联络点，负责与客户、服务供应商、管理层之间的沟通
--* 对于不遵守流程的情形进行处理
--* 在需要的时候，按照升级业务规则中所定义的途径进行升级
--* 对不遵从事件管理流程的参与者作出通告
--* 执行日常的流程管理
--* 出席会议并传达和协调有关事件和问题
--* 确保日常操作中所采集信息的完整性
--* 管理所有事件管理的模板和报表
--* 准备和分析报表
--* 从事件管理流程的开始到结束进行跟踪
--* 解决问题（Issue）
--)))
--
--
--
--===== **3.4 服务台** =====
--
--**担任者：**
--
--服务台人员由IT运行保障部服务台担任，主要操作人员包括：省客服接口岗、监控操作岗、服务受理岗、服务质监岗和服务分析岗
--
--====== **3.4.1 省客服接口岗** ======
--
--承接省客服工作要求、进行分解和分派、对分派工作进行跟踪管理（五个一工程、全业务服务达标、“天翼腾飞”劳动竞赛等）
--
--====== **3.4.2 监控操作岗** ======
--
--对IT系统和业务平台的运行情况进行监控和巡检，主动发现问题并进行分类、派发、跟踪、确认和考核；配合客户服务质监和分析工作。
--
--
--
--|监控操作岗的职责包括：
--|(((
--* 负责监视监控各生产系统的IT平台运行状况，发现问题及时告警、派发事件单；
--* 负责IT机房动力环境的监视监控，并做好记录；
--* 负责每日定时通报各生产系统巡视情况；
--* 负责重大问题的逐级上报；
--* 机房出入管理
--)))
--
--
--
--
--====== **3.4.3 服务受理岗** ======
--
--服务受理岗承接内部和外部客户投诉故障申报，对投诉故障分类和分派，工单跟踪管理，确保投诉处理工作按时、按质完成。
--
--|服务受理岗的职责包括：
--|(((
--* 接受客户的联系
--* 收集基本的联系信息
--* 收集客户的请求信息
--* 分析请求信息
--* 创建或者更新事件单
--* 验证客户的基本信息，如有需要，更新客户的资料
--* 鉴别请求的种类 (例如：信息查询，故障等等)
--* 对不同的请求，收集适当的信息
--* 初步评估请求的优先级
--* 确定适当的分派
--* 基于知识库，解决咨询类请求
--* 对于不能解决的请求，分派给合适的支持人员
--* 若客户要求了解事件状态，则将事件的当前状况通知客户
--* 与客户确认事件的状况和解决方案
--* 了解客户对处理结果的满意程度
--* 更新和关闭事件单
--)))
--
--
--
--
--====== **3.4.4 服务质监岗** ======
--
--服务质监岗主要负责重点事件的质量跟踪和监管以及服务台内部质量管理工作，对服务质量指标监控、督促和考核；升级与紧急事件督办；投诉与重要问题回复；配合客户服务分析工作。
--
--|服务质监岗的职责包括：
--|(((
--* 重点投诉故障的分析处理及管控考核
--* 投诉工单进行质监管理
--* 服务台内部质量管理（班务安排、服务质量）
--* 必要时负担服务受理岗工作
--* 必要时承担服务分析岗工作
--)))
--
--
--====== **3.4.5 服务分析岗** ======
--
--服务分析岗主要负责重大问题的逐级上报和编写对外通知；服务处理报告编写和分析；服务质量回顾分析；故障回顾分析和规律发现；配合质监岗工作。
--
--|服务分析岗的职责包括：
--|(((
--* 每周故障处理及IT运营分析
--* 投诉障碍流程优化
--* 本地网服务工作考核
--* 二线支撑管控考核
--* 必要时负担服务受理岗工作
--* 必要时负担服务质监岗工作
--)))
--
--
--
--===== **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运行保障部职责范围内的事件单，主要指基础架构环境相关的系统故障等，组内岗责划分如下：
--
--|岗位|职责范围
--|BSS系统运行岗|负责维护BSS域系统下相关的主机和数据库等基础架构，发现和处理故障
--|M&O系统运行岗|(((
--负责维护MSS、OSS域系统下相关的主机和数据库等基础架构，发现和处理故障
--
--负责维护内部网络、VPN、DNS、视频监控等IT运行基础设施，发现和处理故障
--)))
--|终端维护岗|负责维护本部门办公网和省公司大楼终端，发现和处理故障
--|数据备份岗|负责存储和备份系统，发现和处理故障
--
--
--
--
--
--**3.5.3.2 支持组**
--
--支持组正常情况下不参与处理故障，以下情况支持组将参与对事件的处理：
--
--* 运行组无法处理的故障
--* 重大故障
--* 升级并引起关注的故障
--
--支持组组内岗责划分如下：
--
--
--|岗位|职责范围
--|主机和存储支持岗|负责主机和存储系统技术支持
--|数据库支持岗|负责数据和中间件技术支持
--|网络支持岗|负责网络系统技术支持
--|信息安全岗|企信部范围内系统的信息安全管理
--
--
--=== **第4章 事件管理流程说明** ===
--
--
--===== **4.1 事件出入口** =====
--
--| |**名称**|**说明**
--|(% rowspan="5" %)事件入口|监控系统告警|监控系统产生的有效告警、将建立事件单处理
--|服务台建单|服务台在必要时自行建立事件单并协调处理
--|支持人员建单|支持人员在日常工作中发现的故障或潜在故障，需建立事件单记录并协调处理
--|本地网上报事件|本地网上报至企信部服务台的事件单
--|转派事件|省NOC、省客服、10000号、本地网服务台转派事件
--|(% rowspan="3" %)事件出口|维护性需求单|(((
--故障在处理过程中分析发现为既定的服务功能出现错误或未能实现，需要经维护性需求处理，则基于此事件单创建维护性需求单，同时事件进入等待状态，等待需求处理完成并返回结果
--
--（二线确认故障为维护性需求时，需要发送协查请求到规建部，由规建部与用户进行需求确认，待确认完成后才创建维护性需求单）
--
--（维护性需求单属于短流程，建议直接进入需求处理阶段）
--)))
--|变更单|故障在处理过程中分析发现为需要进行变更处理，则基于此事件单创建变更申请单，同时事件进入等待状态，等待变更处理完成并返回结果
--|问题单|故障在处理过程中分析并未找到很好的故障解决办法，或者只能通过变通手段对故障进行临时性的解决，则需要基于此事件单创建问题单留待后续做根源性的分析和解决，同时关闭事件单
--|事件协同|任务管理|事件在处理过程中发现需要其他小组人员帮助一起协查或处理，则可以基于此事件单创建多张任务单分派至不同小组
--
--
--
--===== **4.2 事件管理流程概述** =====
--
--下图从总体上描述了事件管理流程、执行步骤和各步骤执行的顺序。
--
--
--
--[[image:微信图片_20240624113918.png]]
--
--
--**图‎2 1. 流程概述**
--
--
--在事件管理流程中所提及的事件，是指湖南电信企信部维护范围内的所有与IT基础架构和应用相关的故障、咨询和投诉。
--
--事件管理流程必须对事件要速度响应和和尽快恢复业务运作。
--
--事件管理流程主要包括五个主要环节：
--
--|**环节**|**环节名称**|**环节说明**
--|**1.**|**事件检测与记录**|事件生命周期的起点，产生事件记录。
--|**2.**|**事件分类与初步支持**|对事件进行初步判断，分类，优先级判定等，在此步骤中事件可以得到初步解决或转派到相应的支持人员。
--|**3.**|**事件调查与诊断**|支持人员(支持人员)接受分派的事件，并进行事件分析和处理的过程
--|**4.**|**事件解决与恢复**|事件在此环节得到解决，或得到临时解决方案，服务得以恢复。
--|**5.**|**事件关闭**|事件生命周期的终点，事件单被关闭
--
--1. 同时，为了事件管理流程得到持续改进和优化，在事件管理流程中还要包括两个环节：
--
--* 事件管理计划及实施
--
--事件管理的建设和设计，并成为事件管理流程建设和改造的蓝本。
--
--* 事件管理回顾
--
--对事件管理流程的运行结果进行回顾，提出相应的改进计划。
--
--
--
--===== **4.3 流程步骤细节描述** =====
--
--====== **4.3.1 事件检测与记录** ======
--
--**4.3.1.1 描述:**
--
--该步骤要快速、准确地探测和捕捉所有在IT生产环境中发生的错误现象，同时，及时将信息通知到相关的部门。在本步骤中，需要收集创建一个事件单所需要的信息。在收集信息中要准确、完整地记录必要的信息。
--
--
--[[image:微信图片_20240624114046.png]]
--
--
--**图‎2 2. 事件检测与记录**
--
--
--
--
--
--**4.3.1.2 该流程主要内容:**
--
--根据事件请求和服务请求，实施发起请求、识别并验证请求来源、更新相应工单、记录请求、信息是否充分、创建公告、通知用户等措施；输出创建的事件工单或关闭事件
--
--
--**4.3.1.3 具体步骤:**
--
--|**1.1发起请求**|**执行者：客户**
--
-- 1 根据数据来源所提出的相关事件。
--
--
--|**1.2识别并验证请求来源**|**执行者：服务台 **
--
-- 1 接受客户的服务请求
--
-- 2 根据唯一的客户信息识别并验证客户信息，需要尽量多地获取客户基本信息：
--
--* [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml3216\wps1.png]]客户姓名（必填）
--* 客户标识（普通员工、主管、经理等）
--* [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml3216\wps2.png]]电话号码（手机）（二者必填一项）
--* 分机号码
--* 员工当前所在地点
--* 邮件地址
--* 所属部门
--
-- 3 检查该客户是否属于服务对象的范围
--
-- 4 如有必要，帮助客户更新客户资料，如联系方式
--
--
--|**1.3 更新相应工单**|**执行者：服务台 **
--
--1. 对于原有的事件单，根据客户所提供的事件请求进一步的描述信息，对之前由该事件请求所产生的事件单进行进一步补充
--1. 补充后的工单仍按原有工单流程进行处理。
--
--
--|**1.4记录事件请求**|**执行者：服务台 **
--
-- 1 创建事件请求，生成事件工单，进入后续流程。
--
-- 2 在事件单中至少需要录入以下事件信息，以下信息需要详细而准确：
--
--* 事件的概要描述
--* 事件的详细信息，包括事件可能造成的服务影响，影响部门等。
--* 可能的描述事件现象的附件
--* 事件发生的时间
--* 事件来源:与咨询相关的事件
--* 事件报告人信息
--
-- 3 针对不同事件来源，需要填写不同的事件来源信息：
--
-- 4 事件单如果是来自客户的服务请求，则需要填写客户信息，至少包含以下内容：
--
--* 客户姓名
--* 客户标识（普通员工、主管、经理）
--* 联系电话/手机
--* 所属部门
--
-- 5 如果是系统自动触发的，事件告警信息是通过系统接口自动载入，至少包含以下内容：
--
--* 事件告警严重等级
--* 事件告警编号
--* 事件告警信息
--* 是否是自动触发还是手工触发，如是手工触发，则还需要记录触发人员的帐号。
--
-- 6 如果该事件单是由运维人员主动发起，运维人员作为事件提交者其相关信息由系统自动填写，至少包含以下内容：
--
--* 运维人员帐号及姓名
--* 运维人员联系电话
--
-- 7 根据客户提交请求，进行配置信息判断，关联对该事件造成影响的配置项
--
-- 8 如果该事件是由于变更实施失败导致，需要在创建新事件的同时关联引发失败的变更单。
--
-- 9 创建事件单后需要判断是否为服务范围，如果信息不足则进入“1.5 等待进一步信息”
--
-- 10 如果是服务范围则进入“事件分类与初步支持”，如果需要的话在“1.6 创建公告”
--
-- 11 如果不是服务范围，则在“1.7通知用户”，通知用户关闭事件单
--
--
--|**1.5 等待进一步信息**|**执行者：服务台 **
--
-- 1  通知并等待用户提供进一步信息
--
--
--|**1.6 创建公告**|**执行者：服务台 **
--
--1. 如果事件影响较小，不会造成大范围的影响，则不需要创建公告。
--1. 需要创建公告的事件可以包括以下情况：
--
--* 事件范围大，一个部门以上的用户使用收到影响需要通知的
--* 信息类，需要向一个以上部门发出通知或者解释说明的
--
--
--|**1.7 通知用户**|**执行者：服务台 **
--
--1. 通知用户并关闭事件
--1. 通知用户的手段包括：
--
--* 邮件通知
--* 电话通知
--* 短信通知
--
--
--
--======   ======
--
--======   ======
--
--====== **4.3.2 事件分类与初步支持 ** ======
--
--**4.3.2.1 描述：**
--
--该步骤要对每个事件进行正确的分类，在现存的解决方案中查询与该事件相匹配的方案。若没有找到合适的解决方案或变通方法，该事件需要分配给一个具有合适技术技能的支持人员。
--
--
--[[image:微信图片_20240624114554.png]]
--
--
--**图‎2 3. 分类与初始支持**
--
--
--
--
--
--**4.3.2.2 流程主要内容:**
--
--根据“事件检测与记录”的事件单、处理过程中回退和处理完成后重新打开的请求，实施判断请求类型、判断事件严重性优先等级与分类、关联到主事件、更新主事件信息、查找可能的解决方案、尝试解决、实施解决方案、事件分派、进行事件分析、执行升级、直接转派等措施，输出已分派的事件工单、已解决的事件工单和提交关闭
--
--**4.3.2.3 具体步骤:**
--
--|**2.1 判断请求类型**|**     执行者：服务台**
--
--1. 判断请求类型，如果是信息咨询类，则提供信息后进入“事件关闭”
--1. 根据客户提供的信息，判断该事件是否会对CI（配置项）造成影响
--1. 进入环节“2.3 判断事件严重性、优先等级、分类”
--
--
--|**2.2判断事件严重性、优先等级、分类**|**     执行者：服务台**
--
-- 1 [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml3216\wps3.png]]查询事件的表现症状，所需要的信息如下：
--
--* 事件简要描述
--* 可能影响了什么服务
--* 必要时提供软件和硬件配置信息
--
-- 2 记录事件的表现症状根据事件描述状况进行事件分类
--
-- 3 如果是客户报告的事件请求，了解该事件对服务可能产生的影响
--
-- 4 如果是运维人员报告的事件请求，运维人员在提交事件请求时根据5.6“优先级”定义设定事件的优先级
--
--[[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml3216\wps4.png]] 5 如果是监控系统产生的告警事件，根据5.6“优先级”定义设定事件的优先级（注，目前湖南电信尚没有监控系统，此处为为未来系统接口做的扩展考虑）
--
-- 6 依据预定义的事件优先级业务规则，在事件单中记录优先级（事件的优先级表应根据实际情况实时修改）
--
-- 7 事件基本特征判断完成，根据客户提供事件描述信息查找是否存在的症状类似的事件工单。
--
--* 如果存在类似的事件单，转入环节“2.3 关联到主事件”。
--* 如果不存在类似的事件单，进入“2.5 查找可能的解决方案”。
--
--
--|**2.3关联到主事件 & 2.4 更新主事件单**|**执行者：服务台**
--
-- 1 如事件单为重复或类似的未解决的事件，将新的事件单关联到原有事件单，原有事件单进行更新。
--
--* 原有事件单被标识为“主事件单”
--* 原有事件单关联事件单数加一
--* 新建事件单出现在原有事件单重复工单列表中
--
-- 2 新事件单状态将随原有事件单状态的更新而更新，不单独进行处理
--
--
--|**2.5 查找可能的解决方案**|**执行者：服务台**
--
-- 1 查找可能的解决方案将提供两种途径：
--
--* 在原有事件工单中查找可能的解决方案或临时变通方法
--* 在关联的知识库中查找可能的解决方案或临时变通方法
--
-- 2 根据查询结果，判断是否存在可能的解决方案或变通方法；
--
--* 如果存在解决方案/变通方法，转至“2.7 实施解决方案”
--* 如果没有找到解决方案/变通方法，转至环节“2.6 尝试解决”；
--
--
--|**2.6 尝试解决**|**执行者： 服务台**
--
--1. 服务台人员根据自身所拥有的技能尝试确定“解决方案或变通方法”，进行事件解决；
--
--* 如果可以解决，转至转至“2.7 实施解决方案”
--* 如果不能解决，转至环节“2.8 事件分派”；
--
--
--|**2.7 实施解决方案**|**执行者： 服务台**
--
--1. 在系统中实施临时措施或解决方案，使服务得到恢复。
--1. 服务恢复之后，进入步骤“事件关闭”
--1. 此环节通常是在流程系统外完成，将实施完成的结果登记到流程系统中
--
--
--|**2.8 分派事件**|**执行者：服务台**
--
--1. [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml3216\wps5.png]]根据事件分类不同，进行事件分派；
--
--* 不同的事件工单会有不同的事件类别和所属地点属性；
--* 根据事件类别和地点属性不同，事件工单会被直接分派到相应的技能组/支持人员，转至环节2.9“进行事件分析”；
--
--1. 服务台在执行“事件关闭”操作时发现某些事件在得到支持人员事件解决的反馈后，由服务台与客户沟通后发现客户未认可事件得到解决，则该事件重新进入“分派事件”环节。
--
--
--|**2.9 进行事件分析**|**执行者： 支持人员**
--
--1. 得到事件工单分派的通知，进行事件检查，并确认是否接受分派的事件工单
--1. 支持人员查看事件，判断是否具备执行事件诊断和分析的技能
--
--* 如果具备，接受这个事件并转至步骤4.3.3“调查和诊断”,环节3.1 “进行事件分析与评估”.
--* 如果不具备，需要升级，转至环节“2.10 执行升级”
--* 如果不具备，无需升级，转至环节“2.11直接转派”
--
--
--|**2.10 执行升级**|**执行者： 支持人员**
--
--1. 执行升级的情况如下：
--
--* 事件的处理非常复杂，耗时较多
--* 派单次数超过3次，升级至相关事件经理及相应直属领导
--* 事件经理或客户对事件处理过程不满意，要求支持人员重新处理事件，需要升级至相关事件经理及相应直属领导
--
--
--|**2.11 直接转派**|**执行者： 支持人员**
--
--1. 对于支持人员之间的转派，可以直接实现，组内转派到人，组间转派到组
--1. 工单转派后，进入环节“2.9 进行事件分析”，支持人员接到工单后进行事件分析
--1. 转派的原因如下：
--
--* 支持人员不具备解决该事件单的技能或时间，直接将事件单转派给其他支持人员
--* 支持人员认为该事件单出现分类选择错误，导致处理人员选择错误，可以在修改该事件单的分类后，将事件单转派给其他支持人员
--* 在事件单处理过程中，支持人员难以找到解决方法，可以直接将事件单转派给其他技能较强的支持人员
--* 在事件的解决时，发现解决方案需要改进，而自身能力有限，支持人员可以转派工单给其他支持人员，改进解决方案
--* 事件经理对事件处理过程不满意，事件单功能升级后，工单派至相应分析员重新进行补充处理
--* 用户对事件处理结果不满意，事件单进行功能升级后，事件记录员退回工单至相应的处理人员，重新进行处理
--
--
--
--
--
--====== **4.3.3 事件调查和诊断** ======
--
--**4.3.3.1 描述: **
--
--    这个步骤阶段要进行深入调查，对事件进行诊断，以解决事件。支持人员要根据步骤找到合适的解决方案或变通方法。
--
--
--[[image:微信图片_20240624120655.png]]
--
--
--**图‎2 4. 事件调查和诊断**
--
--
--
--**4.3.3.2 流程主要内容:**
--
--根据初步分类的事件单、分析员主动发现的事件、未成功解决的事件单、知识库现有知识、事件数据库中的现有解决方案，实施事件分析和评估、收集分析相关信息、再次确认严重等级及分类、进行关联、诊断、试图解决事件的措施，得出“解决和恢复”工单、需要升级的工单或事件关闭的工单
--
--**4.3.3.3 具体步骤:**
--
--|**3.1事件分析和评估**|**执行者：支持人员**
--
--1. 来源于用户的事件，将在本环节对事件进行分析和评估
--1. 来源于支持人员的事件报告，创建工单后，直接进入该环节，对事件进行分析和评估
--1. 在事件的调查和诊断中，需要对关键信息进行补充搜集，进入环节“3.2收集分析相关信息”
--
--
--|**3.2收集分析相关信息 **|**执行者：支持人员**
--
--1. 支持人员查找事件处理的有用信息，获得信息后，记录到事件工单中
--1. 需要用户提供进一步信息时，可以主动联系用户收集信息
--1. 完成信息的收集和分析后，进入环节“3.3再次确认严重等级及分类”
--
--
--|**3.3再次确认严重等级及分类**|**执行者：支持人员**
--
--1. 根据对事件的分析和评估，再次确认事件的分类
--1. 从专家角度再次确认事件的严重等级，并对错误等级进行调整
--1. 如果有相关事件，进入环节“3.4进行关联”；否则，进入环节“3.5 诊断”
--
--
--|**3.4进行关联**|**执行者：支持人员**
--
-- 1 如果该事件单有关联事件单，进行事件单关联
--
-- 2 如果该事件单为现有事件的主事件
--
--* 原有事件单被标识为“子事件单”
--* 原有事件单出现在现有事件单的子工单列表中
--* 事件单进入环节“3.5诊断”
--
-- 3 如果该事件单为现有事件的子事件
--
--* 原有事件单被标识为“主事件单”
--* 新建事件单出现在原有事件单的子工单列表中
--* 原子事件数量加1
--
-- 4 子事件单状态将随主事件单状态的更新而更新，不需要单独进行处理子事件单，如果主事件单进入“已解决”状态，子事件单随之更新为“已解决”状态
--
--
--|**3.5诊断**|**执行者：支持人员**
--
--1. 支持人员利用已有信息，对事件进行诊断，确认事件的详细情况
--1. 完成诊断后，转入环节“3.6试图解决事件”
--
--
--|**3.6试图解决事件**|**执行者：支持人员**
--
--1. 根据对事件的诊断，着手处理事件，通过专业知识尝试进行解决，寻找可能的解决方案或变通方法
--1. 如果寻找到解决方案或变通方法，进入步骤“4解决与恢复”，如果没有寻找到解决方案或变通方法，进入步骤“4.3.2 分类与初步支持”
--
--
--
--
--
--====== **4.3.4 解决和恢复** ======
--
--**4.3.4.1 描述:**
--
--这个步骤要使用解决方案和变通方法来解决事件。对于某些事件，需要创建变更单或者需求单解决事件。
--
--
--[[image:微信图片_20240624121220.png]]
--
--
--**图‎2 5. 解决与恢复**
--
--
--
--
--
--**4.3.4.2 流程主要内容:**
--
--根据“调查与诊断”事件工单、解决方案/变通方法，实施沟通决绝方案/变通方法、创建变更请求、创建需求请求、任务分解并分派、采取恢复操作、验证解决结果，输出沟通后部实施解决方案/变通方法的事件进入“分类与初步支持”、解决失败的事件进入“调查与诊断”已经恢复的事件进入“事件关闭”、需要通过变更解决的事件/流转至变更管理流程/发起变更申请。
--
--
--**4.3.4.3具体步骤**
--
--
--|**4.1沟通解决方案或变通方法**|**执行者：支持人员**
--
--1. 与用户沟通即将实施的解决方案/变通方法
--1. 如果用户不同意实施解决方案/变通方法，进入步骤“2分类与初步支持”
--1. 如果用户同意实施解决方案/变通方法，分析是否需要进行变更，如果需要变更，进入环节“4.2创建变更请求”；如果不需要变更，则：
--
--* 是否需要创建需求，进入环节“4.3 创建需求请求”
--* 是否需要配合完成，进入环节“4.4 任务分解并分派”
--* 如果不需要，进入环节“4.5 采取恢复操作”
--
--
--|**4.2创建变更请求**|**执行者：支持人员**
--
--1. 创建变更请求单，进入变更管理流程
--1. 变更实施完成后，进入步骤“5事件关闭”
--
--
--|**4.3创建需求请求**|**执行者：支持人员**
--
--1. 创建需求请求单，进入需求管理流程
--1. 需求单创建后，直接关闭事件工单
--
--
--|**4.4任务分解并分派**|**执行者：支持人员**
--
--1. 对事件单进行分解并分派到其它支持人员
--1. 任务单处理完成后，处理任务单的支持人员进行相关反馈
--1. 任务单完成前，事件单不可以转入“已解决”状态
--1. 所有任务处理完成，收到反馈后，进入环节“4.6验证解决结果”
--
--
--|**4.5采取恢复操作 **|**执行者：支持人员**
--
--1. 与客户就解决方案/变通方法达成一致意见后，进入实施
--1. 处理完成后，进入环节“4.6验证解决结果”
--
--
--|**4.6验证解决结果**|**执行者：支持人员**
--
--1. 对解决结果进行验证
--1. 如果服务恢复，进入步骤“5事件关闭”
--1. 如果服务没有恢复，进入步骤“3调查与诊断”
--
--
--
--
--
--====== **4.3.5 事件关闭** ======
--
--**4.3.5.1 描述:**
--
--    这个步骤要确保客户对事件的处理情况感到满意。保证事件单的信息是正确、完整的，以便于以后生成报表。处理过程中的经验要得到记录以形成可重用的知识。
--
--[[image:微信图片_20240624122051.png]]
--
--
--
--**图‎2 6. 事件关闭**
--
--**4.3.5.2 流程主要内容:**
--
--根据“1检测与记录”“2分类与初步支持”“3调查与诊断”“4解决与恢复”的事件、已经完成的变更、用户对解决情况的反馈，实施验证并检查记录、更新工单记录、与用户沟通、关闭相应公告、关闭工单等措施，输出已关闭的事件单、经过检查没有解决的事件单以及用户不满意的事件单
--
--**4.3.5.3 具体步骤**
--
--
--|**5.1验证并检查记录**|**执行者：事件记录员**
--
--1. 告警消除的来自监控系统的事件，事件记录员对结果进行验证，并确认事件单的完整性
--1. 对于来自于用户的事件，对事件单内容的完整性的进行确认
--1. 如果记录不完整，进入环节“5.2更新工单记录”
--1. 如果工单记录完整，判断工单关闭是否需要用户确认，如果需要用户确认，进入环节“5.3与用户沟通”；如果不需要用户确认事件解决结果，直接进入“5.4关闭相应公告”
--
--
--|**5.2更新工单记录**|**执行者：支持人员**
--
--1. 支持人员接到服务台需要更新事件记录的通知后，对事件单进行完善，补充事件记录
--1. 事件单补充完成后，事件记录员判断工单关闭是否需要用户确认，如果需要用户确认，进入环节“5.3与用户沟通”；如果不需要用户确认事件解决结果，直接进入“5.4关闭相应公告”
--
--
--|**5.3与用户沟通**|**执行者：事件记录员**
--
--1. 联系用户，征询对事件处理结果是否满意，记录用户意见
--1. 如果用户对事件的解决不满意，则转入步骤“2分类与初步支持”
--1. 如果用户满意解决结果，进入“5.4关闭相应公告”
--
--
--|**5.4关闭相应公告**|**执行者：事件记录员**
--
--1. 如果有相应公告，进行关闭
--1. 进入环节“5.5关闭事件单”
--
--
--|**5.5关闭事件单**|**执行者：支持人员/事件记录员**
--
--1. 来自于支持人员提出的事件，处理完成后，直接关闭事件单
--1. 用户提出的事件，由事件记录员关闭事件单
--
--
--
--
--====== **4.3.6 跟踪回顾** ======
--
--**4.3.6.1 描述:**
--
--在进行事件处理过程中，为了保证湖南电信企信部提供业务支持的服务质量，保证对事件的及时响应和快速解决，事件经理要对事件的整个处理过程进行实时监控，处理升级的事件。
--
--[[image:微信图片_20240624122931.png]]
--
--
--**图‎2 6. 事件监控**
--
--
--**4.3.6.2 流程主要内容:**
--
--根据未解决的事件、客户提出的查询请求和升级的事件单，实施选择事件、跟踪/回归过程、要求更新工单、更新信息、交流事件状态，得出更新记录的事件单和进一步升级的事件单
--
--**4.3.6.3 具体步骤**
--
--
--|**6.1选择事件**|**执行者：事件经理**
--
--1. 进入事件管理流程系统，查询执行过程中的事件工单
--1. 选择要跟踪回顾的对象
--
--
--|**6.2跟踪/回顾过程**|**执行者：事件经理**
--
-- 1 浏览跟踪回顾的事件工单，主要包括：
--
--* 事件处理日志
--* 事件解决方案或变通方法
--* 事件处理耗时
--
-- 2 必要时，要求事件处理人员更新事件单信息，进入环节“6.3要求更新记录”
--
-- 3 如果对事件处理过程不满意，则升级事件，进入环节“4.3.2分类与初步支持”
--
-- 4 如果还需要进一步联系用户，进入环节“6.5交流事件状态”
--
-- 5 如果对处理过程满意，且不需要进一步联系用户，则跟踪回顾结束
--
--
--|**6.3要求更新工单**|**执行者：事件经理**
--
-- 1 如果事件单信息不完整，要求事件处理人员更新事件单信息
--
--
--|**6.4更新信息**|**执行者：事件记录员\支持人员**
--
--  1 事件处理人员对事件单内容进行更新
--
--  2 事件更新结果反馈回事件经理，事件经理进行下一步操作
--
--
--|**6.5交流事件状态**|**执行者：事件经理**
--
-- 1 如果需要与用户交流事件的处理状况和情况，联系用户进行沟通，并补充到事件工单中
--
-- 2 交流结束后，跟踪回顾结束
--
--
--
--===== **4.3.7 重大（危机）事件** =====
--
--重大故障由服务人员在处理过程中主观发现和定义，判断依据如下：
--
--* CRM系统、计费、结算系统等核心应用系统业务瘫痪或中断；
--* 省级生产网络瘫痪或中断；
--* 事件管理中“紧急程度”和“影响程度”均为最高的故障；
--
--以上故障可称为重大故障。
--
--重大故障的组织和协调机制，参见《湖南电信重大故障管理办法》
--
--
--=== **第5章 业务规则** ===
--
--
--注：所有在本章节所提及的日期和时间是指“经过的（elapsed）”的日期和时间。
--
--
--
--===== **5.1 总体业务规则** =====
--
--1. XX电信所支持的系统和网络环境中，所有对操作特性和服务提供有影响的事件都会通过事件管理流程处理；事件将通过流程中定义的标准、业务规则和指导进行管理。
--1. 所有报告和处理事件的部门将会参与统一的事件管理流程，不应该有任何例外。
--1. 所有IT支持人员对优先级（极高）和（高）的事件所采取的恢复服务的行动，相比其他任务具有优先权。
--1. 对于省客服、省NOC、10000号等外部转派的事件单并带有解决时间要求的，应遵照其解决时间的要求进行处理。
--1. 应由服务台定期产生和回顾事件管理报表。对没有解决的问题，应生成问题进行跟踪和处理，服务台对此有考评职责。
--1. 应由服务台定期对流程进行回顾，以改进事件管理流程。
--
--
--====== **5.1.1 责任人业务规则** ======
--
--事件管理需要定义一个责任人业务规则，以确保每个事件在任何时段都有适当的人员负责。
--
--事件管理：
--
--1. 当一个事件被创建后，服务台负责这个事件单
--1. 当事件单被分派后，支持人员负责此事件单；在故障现象描述和对应正确时，被分派方遵循首问责任制，被分派的支持人员有权拒绝故障现象不属于本组职责范围内的事件单。
--1. 如果需要向客户通知处理情况，由事件单的当前责任人负责
--
--
--**5.1.2 分类规则**
--
--
--
--1. 分类分为两个，“故障现象分类”和“故障根源分类”
--1. 服务台派单时填写故障现象，以故障现象为准分派支持人员
--1. 支持人员转派事件和解决事件时以填写故障根源，故障根源为准
--
--|**分类**|**原则**|**上级分类**
--|**类别（Category）**|**分类原则以能够准确定位事件所在系统、设备或者功能单元为准，且需要兼顾服务台人员的判断能力，如OCS系统**|
--|**子类（Type）**|**分类原则以能够指导事件分派到相应处理组为准，且需要兼顾服务台人员的判断能力，如应用、主机、数据库**|**类别**
--|**现象分类（superficies）**|**分类原则以能够描述故障现象为准，如计费出错**|**子类**
--|**根源分类（causation）**|**分类原则以能够描述故障根源为准，如数据错误**|**子类**
--
--具体分类参见《事件管理设计信息表》
--
--
--====== **5.1.3 分派业务规则** ======
--
--1．分派业务规则主要决定由服务台创建事件后的分派原则。
--
--|分派规范|描述
--|规范一|基于目前管理状况，建议服务台分派事件到组而非到人
--|规范二|服务台依据事件（故障）现象在三级分类中指定二线处理路径
--|规范三|可分派的二线人员组列表将根据事件分类和事件地点信息进行筛选
--|规范四|二线处理遵循首问制的原则，可将不属于本组处理的事件单转派其他小组。转派前必须明确事件（故障）根源
--|规范五|对于事件（故障）现象填写出错并由此造成的分派错误，二线处理小组有权将事件单退回服务台，退回时必须说明理由
--|规范六|发生三次以上分派、转派和回退的事件将自动通知事件经理，由事件经理协调处理
--
--
--====== **5.1.4 代办业务规则** ======
--
--考虑到湖南电信在人员组织方面的实际情况，可以允许在事件处理过程中实现代办功能，代办原则如下：
--
--1 服务台和支持人员，由于某些原因（例如出差，休假，培训等）离开本岗位时，必须确保将未处理完毕的事件单重新分派到本岗位其他事件处理人员；如果
--
--2 本岗位只有自己一人，则通过指定代办人的方式，确保在代办期间，由代办人处理该岗位的各项工作；
--
--
--====== **5.1.5 优先级** ======
--
--1. 事件的优先级表明了支持人员对事件工单处理的优先程度。它是评定事件处理优先等级的一个重要指标。
--1. 所有事件都将分配到四个优先级中的一个。优先级从 1 (极高) 到 4 (低) 。
--1. 优先级在事件的生命周期中是可以改变的。关于更改事件单优先级的原因和行为应该在事件单中记录。
--1. 事件的优先级通常由两方面的指标共同决定：事件影响度及事件紧急程度。
--
--
--
--**5.1.5.1 事件影响程度**
--
--1 事件影响度规则
--
--* 规则一：事件影响程度由服务台或支持人员建单和受理时判断定义
--* 规则二：事件影响程度定义如下表所示
--
--2 我们可以根据一个表格来制定湖南电信事件的影响程度，在下表中对事件的影响程度按照四个等级进行划分，每个等级中对事件的表象进行了描述，服务台可以根据影响程度的定义对事件进行影响度的划分：
--
--[[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml3216\wps6.jpg]]
--
--
--
--
--**5.1.5.2 事件紧急程度**
--
--1. 事件紧急程度规则
--
--* 规则一：事件的紧急程度划分为三级 ~-~-~-~- 高、中、低
--* 规则二：事件紧急程度由用户或服务台按照“用户类型”和“分类”交叉运算得出
--* 规则三：没有明确用户类型的事件紧急程度默认为“中”
--* 规则四：投诉类事件和升级事件紧急度默认为“高”
--
--示例表：
--
--[[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml3216\wps7.jpg]][[image:图片3.png]]
--
--具体参见《事件管理设计信息表》
--
--
--====== **5.1.5.3 事件优先级的计算方法** ======
--
--
--
--
--1. 计算方法：按照“影响范围”和“紧急程度”交叉运算得出优先级
--1. 规则：事件的严重等级由系统根据紧急程度和影响程度自动运算得出
--
--计算规则如下表所示：
--
--[[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml3216\wps8.jpg]][[image:图片4.png]]
--
--**表 3-3.优先级**
--
--
--优先级业务规则将用于服务台，支持人员在进行事件优先级判断时参考使用。具体参见《事件管理设计信息表》
--
--
--====== **5.1.6 目标解决时间业务规则** ======
--
--1. 在事件处理的每个环节中，按照严重等级不同有不同的处理时间限制，超过时间将执行升级上报。
--1. 事件得到响应：指服务台在接到故障申报到分派处理的时间
--1. 事件单接受：指从服务台分派事件单到支持人员开始，到支持人员接受分派的时间
--1. 服务得到恢复：指支持人员从接受分派到解决事件的时间
--1. 工单得到关闭：指支持人员解决事件后，到确认结果并关闭事件的时间
--1. 事件管理的目标时间如下表所示：
--
--| |事件得到响应|事件单接受|服务得到恢复|工单得到关闭
--|**严重等级1**|10分钟|20分钟|8H|1D
--|**严重等级2**|20分钟|30分钟|1D|1D
--|**严重等级3**|40分钟|1H|2D|2D
--|**严重等级4**|1H|2H|3D|3D
--
--**表 3-4. 事件目标时间业务规则**
--
--
--====== **5.1.7 等待规则** ======
--
--1. 事件可能会超过目标时间上限，但这些原因有一些是客观的，无法预期的，当事件由于这些原因进入等待状态时，等待中的时间将不计入目标时间计算中。
--1. 等待需要遵循以下规则：
--
--
--|等待规范|描述
--|规范一|事件记录员、支持人员和事件经理可将事件置为等待状态
--|规范二|事件创建维护性需求时，事件自动进入等待状态
--|规范三|事件创建变更时，事件自动进入等待状态
--|规范四|事件进入等待状态必须填写等待代码，自动进入等待的事件单由系统自动填写等待代码
--|规范五|等待中的事件单不计入目标时间考核
--
--
--====== **5.1.8通知业务与升级业务规则** ======
--
--1. 规范一：根据湖南电信管理现状，事件升级将执行事件上报通知，以及将紧急程度置为“高”
--1. 规范二：事件升级触发条件包括：转派3次升级、解决驳回2次升级和超时升级
--1. 规范三：事件上报通知对象必须包括事件经理。在必要时，除事件经理外还可包括相关部门领导
--1. 事件通知触发条件和通知对象：
--
--**图例:  **U：相关用户；C：事件记录员；E：支持人员；M：事件经理
--
--
--|严重等级
--触发条件|严重等级一|严重等级二|严重等级三|严重等级四
--|分派/转派事件|EM|E|E|E
--|事件解决|UCM|UCM|UC|UC
--|事件关闭|C|C|C|C
--|升级通知|CEM|CEM|CEM|CEM
--
--**表 3-6. 通知业务规则**
--
--
--**5.1.9 标准的通知内容**
--
--1. 通过通知业务规则进行沟通的事件信息可以通过电话、系统消息、电子邮件或者短信等方式发送，并将遵循标准的格式。下列的几个通知内容项应当以容易理解的方式进行描述：
--
--* 事件的简要描述
--* 受到影响的服务
--* 预计恢复服务的时间（要尽可能准确）
--* 联系服务台咨询更多信息的方法
--* 通知方式可以考虑通过短信或邮件方式自动进行。
--
--
--====== **5.1.10 重复业务规则** ======
--
--1. 对于重复事件，将采用“主+从”关系绑定的方式处理，“从事件单”状态和受理人与“主事件单”相同。如果被报告的事件与某个已经创建且尚未解决的事件单症状相同，则该事件被认为是重复的。
--
--
--|重复事件|描述
--|(% rowspan="2" %)定义|如果被报告的事件与某个已经创建且尚未解决的事件单症状相同，则该事件被认为是重复事件
--|如果被报告的事件可以确定是由于某个已经创建且尚未解决的事件所引起的，则该事件被认为是重复事件
--|(% rowspan="3" %)处理方法|服务台或者二线人员在第一张事件单受理时即判断出此事件必将带来后续重复，那么将事件置为主事件，后续事件为从事件
--|服务台或者二线人员在处理了多张事件单之后才发现真正的根源性事件，将根源性事件置为主单，与之前已处理的相关事件建立关联（非主从，不绑定状态），后续再出现的事件作为从单
--|对已关闭的事件单发现重复事件，做事件关联，不做主从
--|(% rowspan="2" %)配套措施|系统需要建立重复事件判断条件的配置功能，维护多个判断重复事件的条件，当满足条件时系统会弹出窗口提示操作者有哪些事件单可能是重复事件。可以选择是否关联或者主从
--|重复事件的主从关系允许拆解
--
--
--
--====== **5.1.11 复发业务规则 ** ======
--
--1. 如果报告的事件与已经关闭的事件相同（查询范围含时间），该事件被认为是“复发”的事件单。这意味着为了解决事件而采取的解决措施失败了。此时应当创建一个新的事件单，复制原始事件单的内容，并说明这是复发的事件。
--
--====== **5.1.12 事件单关闭业务规则** ======
--
--1. 服务台和用户进行确认并关闭工单
--1. 事件关闭有以下业务规则：
--
--|关闭规范|描述
--|规范一|事件单应由事件创建者关闭,本地网发起的事件并由省企二线处理的，直接回本地网关闭
--|规范二|关闭事件单之前，必须确认处理结果并填写解决方案记录
--|规范三|事件创建需求单后，事件将自动关闭
--|规范四|关闭代码为解决失败或变通解决的事件单，在关闭前必须创建问题单
--|规范五|状态为已解决的事件单30天后系统自动关闭
--|规范六|事件单在关闭前，必须填写关闭代码，自动关闭的事件单由系统自动填写关闭代码。
--|规范七|已关闭的事件单不允许重新打开
--
--
--
--=== **第6章 质监合规与分析考核** ===
--
--
--===== **6.1 质监合规** =====
--
--服务台质监需要注意两个方面
--
--第一，是日常的流程执行质量和合规要求的质监，通过系统和人工手段对每张工单进行实时质监，由服务台服务受理岗和质监岗对质监出现问题的工单及时介入进行督促协调或者请求领导支持。
--
--第二，是收集和整理质监数据，分析流程的执行效率和存在的瓶颈及问题。此项工作可以按月度或者季度进行，由服务台质监岗牵头，事件经理负责。
--
--如下表：
--
--|工作类型|工作方式|工作内容|说明
--|(% rowspan="6" %)日常质监|半自动|分类质监|对工单分类的填写正确性进行质监，包括分派时和关单时
--|半自动|工单填写合规质监|对工单内容的填写按照合规要求进行质监，包括未填写和填写不规范，表述不清，信息不全等
--|半自动|严重等级质监|对严重等级相关的紧急度、影响度填写进行质监
--|自动|升级质监|监控工单的执行，对达到升级要求的工单进行升级上报
--|半自动|关单质监|在工单处理完成时进行一次质监，主要查看工单内容填写情况，如关闭代码是否填写，解决方案是否填写。
--|人工|督促协调|对质监出现问题的工单及时进行协调处理和督促处理，并在必要时请求领导介入支持
--|(% rowspan="2" %)流程分析|半自动|规范修正|对流程管理规范（分类、严重等级等）进行评估，对需要修正的规范提交领导审阅
--|半自动|流程效率分析|对流程执行效率（如工单总量和超时率）进行评估分析，找出流程本身可以进一步优化的地方
--
--工作方式：“自动”为系统可以帮助完成；“半自动”为系统可以帮助完成一部分信息收集工作，只能起到辅助作用，最终还是需要人工判断；“人工”指的是系统无法提供帮助，属于人工完成的工作。
--
--
--
--
--===== **6.2 考核分析** =====
--
--考核的方面包括：
--
--* 对本地网服务台的考核
--* 对二线处理的考核，对厂商的考核要求将归并到对二线人员的考核中；
--* 对企信部服务台自身绩效考核。
--
--|考核对象|考核内容|说明|KPI
--|(% rowspan="2" %)本地网服务台|预处理率|本地网服务台事件单预处理比例|（本地处理工单数/本地工单总数）>85%
--|上报正确率|本地网服务台上报企信部服务台事件单被驳回比例|（退回服务台工单数/本地工单数）<1%
--|(% rowspan="6" %)企信部服务台|派单准确率|服务台派单被二线驳回比例|（退回服务台工单数/省工单总数）<1%
--|派单及时率|服务台派单超时比例|（分派超时工单数/省工单总数）<99%
--|投诉率|专指对工单处理的投诉比例|（遭投诉工单总数/省工单总数）< 1%
--|告警工单生成率|监控组将有效告警转成告警事件单比例|（告警类工单总数/有效告警数）> 95%
--|维护作业完成率|监控组对维护作业计划的执行率|（已完成巡检单/计划巡检单）= 100%
--|客户满意度|客户满意度需要相关调研手段的配合，如问卷方式| 不满意客户/全部客户 <10%
--|(% rowspan="5" %)二线处理小组|受理及时率和处理完成及时率|受理超时和处理超时比例，按各个二线小组统计|（及时处理工单总数/承接工单总数）> 95%
--|关单确认率|解决完成事件被用户核实并关单的比例，按各个二线小组统计|（关单驳回数/本组工单总数）<1%
--|问题单覆盖率|未成功解决工单中转问题单的比例|（故障转问题数/不成功工单总数）> 90%
--|处理完成率|事件处理正常解决的比例，按各个二线小组统计|（成功解决数/本组工单总数）>80%
--|重发故障率|被正常解决并关单的事件，事后重新发生并被确认为重发故障。占所有正常解决事件的比例，按各个二线小组统计|（重发故障工单次数/成功解决工单总数）< 5%
--
--具体考核指标内容可参见《湖南电信企信部指标体系》
--
--
--
--=====   =====
--
--===== **6.3 故障分析** =====
--
--故障分析主要是两个维度的工作，为服务质量的提升找到数据上的依据和切入点：
--
--* 第一，故障规律分析；
--* 第二，闭环管理相关分析；
--
--故障分析由服务台故障分析岗和事件经理完成，一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础完成分析，召开例会，总结经验教训并修正不合适的分析指标。
--
--分析例会应根据需要选择以月例会、季度例会的方式进行
--
--
--分析内容如下：
--
--[[image:图片5.png]]
--
--
--具体分析内容可参见《服务分析报告》
--
--
--
--=== **第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的事件|受影响用户|故障解决后
--|停机通告|影响为1和2的变更在执行前，需要发出停机通告|受影响用户|变更完成后
--
--
--====== **1.3.2 公告用语** ======
--
--公告包括“标题”“正文”“落款”三个组成部分。
--
--
--|**种类**|文档发放
--|**内容要求**|需说明发放部门，接收部门，文档用途，如果需要填写并回收的，需说明负责人、填写方法、回收方式及期限。
--|**范例**|(((
--OA系统使用情况调查表发放通知
--
--
--为配合OA项目组更好的进行系统测试的工作，现下发OA系统使用情况调查表，希望各相关部门予以配合。
--
--各部门每位OA使用者均需要填写，下载附件调查表并按表内提示填写完成后，交与各部门汇总，由管理员统一发送至企信部~*~**部门。
--
--截止日期为~*~*~*~*。
--
--联系人电话：~*~*~*~*，邮箱：~*~*~*~*
--
--谢谢配合！
--
--
--附件：OA系统使用情况调查表.doc
--
--                                                         ~*~*~*~*~*~*
--
--                                                         ~*~*~*~*-*-~*~*
--)))
--
--
--|**种类**|信息公示
--|**内容要求**|需说明信息内容，信息所针对范围，信息生效和失效时间。
--|**范例**|(((
--公司OA系统使用规范v1.0
--
--
--为配合OA系统的正式启用，现在发布《公司OA系统使用规范》v1.0版，主要是对公司内OA用户进行使用上的指导和规范，以及一些重要功能的操作指导和约束。请各OA用户认真下载阅读。
--
--本规范从发布之日起生效。
--
--谢谢配合！
--
--
--附件：公司OA系统使用规范 v1.0.doc
--
--                                                        企信部
--
--                                                       ~*~*~*~*-~*~*-~*~*
--)))
--
--
--|**种类**|操作指导
--|**内容要求**|需要说明系统名称，发布操作指导的原因和使用场景。
--|**范例**|(((
--访问公司主页系统乱码处理办法
--
--
--近日很多用户向中心反映，在访问公司主页系统时会在新闻栏看到乱码，为此经过相关技术人员的研究，发现这是用户浏览器终端配置的问题，现将解决办法予以公示，当用户再次遇到类似问题时，可以按照提示自行解决，也可以选择拨打~*~*~*~*请心服务台人员帮助解决。
--
--谢谢配合！
--
--
--附件：公司主页系统乱码处理办法.doc
--
--                                                     企信部
--
--                                                       ~*~*~*~*-~*~*-~*~*
--)))
--
--
--|**种类**|故障通告
--|**内容要求**|需要说明故障原因，影响范围，预期解决时间，当然还要表示歉意
--|**范例**|(((
--X月X日OA系统故障通告
--
--
--由于数据库系统故障，导致本日10:00开始OA系统停止服务，全公司OA用户均无法登陆OA系统，现在技术人员正在全力解决故障，预计本日15：30之前可以恢复服务。
--
--因此给您带来的不便我们表示万分抱歉！并谢谢您的配合和谅解！
--
--
--                                                        企信部
--
--                                                          ~*~*~*~*-~*~*-~*~*
--)))
--
--
--|**种类**|停机通告
--|**内容要求**|需要说明停机原因，影响范围，预期恢复时间，当然还要表示歉意
--|**范例**|(((
--X月X日OA系统停机通告
--
--
--为了使OA系统可以更加稳定和高效的运行，经过OA项目组研究决定，计划在X月X日19:00到23:00进行OA系统数据库升级，期间OA系统将停止服务，请各部门用户届时提前结束OA系统上的工作，并在此期间不要尝试登录OA系统。
--
--因此给您带来的不便我们表示万分抱歉！并谢谢您的配合和谅解！
--
--
--                                                     企信部
--
--                                                       ~*~*~*~*-~*~*-~*~*
--)))
--
--
--
--
--= **附录二:服务台运行管理要求** =
--
--
--=====   =====
--
--===== **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 培训制度** =====
--
--培训是服务台服务的重要成功因素。若没有适当的初期和持续培训，服务台将不能提供最佳的客户服务。持续培训可以使服务台人员掌握所需技能。它也可以提高生产力，改善客户服务，此外还能增加服务台人员的工作满意程度，自信心。
--
--|**种类**|**机制**|**内容**|**培训者**
--|上岗培训|上岗前培训，每名服务台人员必须接受至少一次上岗培训|(((
--ITIL基础理论
--
--服务台的概况和职能
--
--运行管理规范
--
--ITSM系统软件使用
--
--一周观摩学习
--)))|(((
--服务台经理
--
--服务台资深员工
--
--专业培训人员
--)))
--|进阶培训|进阶培训的主要目的是提高服务台人员的工作效率和工作热情，内容主要是工作经验的分享和技巧的传授，不定期开展。|(((
--工作总结
--
--经验教训总结
--
--典型案例分享
--
--新技巧传授
--)))|(((
--服务台经理
--
--服务台资深员工
--)))
--|专业技能培训|由服务台经理协调二线支持团队不定期进行专业技能的培训。目的为提高服务台人员的工作能力，并提高一线解决率。|(((
--终端维护技能
--
--ITSM系统软件使用
--
--各系统常见故障处理等
--)))|二线支持团队
--|日常培训|即为传统意义上的“传帮带”|服务台日常工作熟练|服务台资深员工
--
--
--
--

图片4.png

Author

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

Size

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

Content

图片5.png

Author

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

Size

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

Content

粤ICP备17056641号

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