Version 12.1 by superadmin on 2024/10/25, 21:46
Show last authors
1 = **第1章前言** =
2
3 为了提升XX电信企信部运维服务质量，保障对所支持系统和业务的及时响应，改善事件的处理效率，参考ITIL最佳实践并结合XX电信企信部目前的运维现状，对事件处理的过程进行梳理，并形成管理规范和操作指导。
4
5 == ==
6
7 == **1.1.本文适用对象** ==
8
9 本文作为XX电信事件管理流程的参考，供XX电信参与到事件管理流程中的人员和相关的管理层使用。
10
11 == ==
12
13 == **1.2.前提与假设** ==
14
15 读者应该了解ITIL，并对流程具有基本的技能
16
17 在本文中“客户”是指报告事件，或是受到事件影响的人员或部门，与ITIL中的客户（Customer）的定义略有不同
18
19
20 == **1.3.名词定义** ==
21
22 为了推进事件管理流程在XX电信的有效应用，在事件流程设计开始统一相应的设计语言，方便各级人员对事件管理流程的理解。
23
24
25
26 |**名词**|**解释**
27 |ITIL( IT Infrastructure Library)|是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT管理标准。
28 |事件管理流程|ITIL流程之一，事件管理负责处理IT事件和用户请求。它的目的是尽快恢复被中断或受到影响的IT服务，是以解决表征现象为目的，而不在于查找根本原因。
29 |服务|XX电信企信部运维团队提供给内部和外部用户的支持内容
30 |事件|是指XX电信企信部维护范围内的所有与IT基础架构和应用相关的故障、咨询和业务处理。
31 |危机|对于优先级为“紧急”并且严重性等级为最高的重大突发事件我们称之为“危机”
32 |事件任务|是指在进行复杂事件处理时，由支持人员创建的需要其他支持人员辅助处理的任务
33 |事件单|系统中存在的在事件管理流程中运行的以数据形式存在的工单
34 |客户|指目前XX电信企信部提供服务的业务部门
35 |服务台|服务台从根本上来说是提供了用户和企信部的唯一接口。此项功能常通过集中方式提供服务。帮助台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。
36 |支持人员|进行事件处理的支持人员，通常对应于XX电信一线二线支持人员
37 |事件经理|负责协调事件管理的日常操作步骤，并管理工作的时间安排
38
39
40 == **1.4.阅读指南** ==
41
42 本文所有工作流程均使用Line of Visibility Engineering Methodology (LoVEM)描述。LoVEM 可提供工作流程的图形化表述。流程中涉及的角色（Roles）定义于左列，还包括用户等其他内容；右侧是流程的每个步骤或环节。
43
44 流程的各个步骤分布于各角色相对应的行，各步骤从左到右排列，箭头连接各步骤并表明信息和数据的流向。
45
46 每个流程步骤均以图形化表示，并以图表显示步骤的流程、执行相应步骤的角色和各项步骤的内容
47
48 (% style="text-align:center" %)
49 [[image:1729859978220-355.png]]
50
51
52
53 = **第2章概述** =
54
55
56 == **2.1.流程目的** ==
57
58 事件管理的主要目标是争取在最短的时间内解决、恢复，尽量避免或减少事件对用户造成影响。事件管理需要保留事件的有效记录，给其他的服务管理流程提供相关的信息，以及正确报告进展情况。
59
60
61 == **2.2.流程范围** ==
62
63 事件管理的范围主要是针对XX电信企信部所管理和维护的应用系统及IT相关基础架构设施所发生的业务问题、系统故障、信息咨询和客户投诉。
64
65
66
67
68 = **第3章角色与职责** =
69
70
71 == **3.1.领导小组** ==
72
73 **担任者：**
74
75 领导小组由IT运行保障部领导组成
76
77 **职责：**
78
79 负责对重大事件实施应急处理的决策和应急资源统一指挥调配，及时向上级机关汇报情况，执行上级领导的命令。
80
81 == ==
82
83 == **3.2.事件管理流程负责人** ==
84
85
86 **担任者：**
87
88 事件管理流程负责人由服务台经理担任，
89
90 **职责：**
91
92 作为事件管理流程的责任人，对于整个流程执行的结果负责，并有一定的权力管理流程。
93
94
95 |**事件管理流程负责人的职责：**
96 |(((
97 * 全面负责流程的效率和成果
98 * 建立流程考核和目标，以提升流程的有效性和效率
99 * 为保障流程的有效性，需争取高级管理层承诺投入足够的资源
100 * 鉴别和管理关键的流程成功要素
101 * 控制和带领流程的改进
102 * 批准和拒绝偏离流程的请求
103 * 定义事件管理的角色、责任和应负的责任
104 * 定义目标、流程、工作流、业务规则和规则，并与相关人员进行沟通
105 * 强制事件管理流程的执行
106 * 确保对客户进行流程满意度调查
107 * 确保对流程的使用者提供适当的教育
108 * 对其他流程负责人和管理层汇报流程的状况和进度
109 * 对事件管理流程的有效性和效率进行监控，在需要的时候作出改进
110 * 召开和主持对事件管理流程改进的季度会议
111 * 审计事件管理流程的执行
112 * 对事件管理流程的成本和投资负责
113 * 作为事件管理流程对外的代表
114 * 在适当的情况下，事件管理流程负责人可以把部分责任委任给其他人员执行。
115 )))
116
117 == **3.3.事件经理 ** ==
118
119
120 **担任者：**
121
122 事件经理由服务台经理担任A岗，必要时服务质监岗和服务分析岗可以兼任事件经理B岗
123
124 **职责：**
125
126 负责协调事件管理的日常操作步骤，并管理工作的时间安排。
127
128
129 |**事件经理的职责：**
130 |(((
131 * 协调事件管理的日常操作
132 * 确定和执行流程本身的变更
133 * 鉴别流程执行过程中的例外和异常情况, 并进行管理
134 * 传达流程的新业务规则和更新的业务规则
135 * 确保流程标准和步骤得到遵循
136 * 作出资源的承诺和分配
137 * 鉴别和实施流程的改进建议
138 * 产生和分派流程管理的报表
139 * 对事件管理流程的负责人提出改进的建议
140 * 作为流程的集中联络点，负责与客户、服务供应商、管理层之间的沟通
141 * 对于不遵守流程的情形进行处理
142 * 在需要的时候，按照升级业务规则中所定义的途径进行升级
143 * 对不遵从事件管理流程的参与者作出通告
144 * 执行日常的流程管理
145 * 出席会议并传达和协调有关事件和问题
146 * 确保日常操作中所采集信息的完整性
147 * 管理所有事件管理的模板和报表
148 * 准备和分析报表
149 * 从事件管理流程的开始到结束进行跟踪
150 * 解决问题（Issue）
151 )))
152
153
154 == **3.4.服务台** ==
155
156 **担任者：**
157
158 服务台人员由IT运行保障部服务台担任，主要操作人员包括：省客服接口岗、监控操作岗、服务受理岗、服务质监岗和服务分析岗
159
160 === ===
161
162 === **3.4.1.省客服接口岗** ===
163
164 承接省客服工作要求、进行分解和分派、对分派工作进行跟踪管理（五个一工程、全业务服务达标、“天翼腾飞”劳动竞赛等）
165
166 === ===
167
168 === **3.4.2.监控操作岗** ===
169
170
171 对IT系统和业务平台的运行情况进行监控和巡检，主动发现问题并进行分类、派发、跟踪、确认和考核；配合客户服务质监和分析工作。
172
173
174 |监控操作岗的职责包括：
175 |(((
176 * 负责监视监控各生产系统的IT平台运行状况，发现问题及时告警、派发事件单；
177 * 负责IT机房动力环境的监视监控，并做好记录；
178 * 负责每日定时通报各生产系统巡视情况；
179 * 负责重大问题的逐级上报；
180 * 机房出入管理
181 )))
182
183 === **3.4.3.服务受理岗** ===
184
185 服务受理岗承接内部和外部客户投诉故障申报，对投诉故障分类和分派，工单跟踪管理，确保投诉处理工作按时、按质完成。
186
187 |服务受理岗的职责包括：
188 |(((
189 * 接受客户的联系
190 * 收集基本的联系信息
191 * 收集客户的请求信息
192 * 分析请求信息
193 * 创建或者更新事件单
194 * 验证客户的基本信息，如有需要，更新客户的资料
195 * 鉴别请求的种类 (例如：信息查询，故障等等)
196 * 对不同的请求，收集适当的信息
197 * 初步评估请求的优先级
198 * 确定适当的分派
199 * 基于知识库，解决咨询类请求
200 * 对于不能解决的请求，分派给合适的支持人员
201 * 若客户要求了解事件状态，则将事件的当前状况通知客户
202 * 与客户确认事件的状况和解决方案
203 * 了解客户对处理结果的满意程度
204 * 更新和关闭事件单
205 )))
206
207 === **3.4.4.服务质监岗** ===
208
209 服务质监岗主要负责重点事件的质量跟踪和监管以及服务台内部质量管理工作，对服务质量指标监控、督促和考核；升级与紧急事件督办；投诉与重要问题回复；配合客户服务分析工作。
210
211 |服务质监岗的职责包括：
212 |(((
213 * 重点投诉故障的分析处理及管控考核
214 * 投诉工单进行质监管理
215 * 服务台内部质量管理（班务安排、服务质量）
216 * 必要时负担服务受理岗工作
217 * 必要时承担服务分析岗工作
218 )))
219
220 === **3.4.5.服务分析岗** ===
221
222 服务分析岗主要负责重大问题的逐级上报和编写对外通知；服务处理报告编写和分析；服务质量回顾分析；故障回顾分析和规律发现；配合质监岗工作。
223
224 |服务分析岗的职责包括：
225 |(((
226 * 每周故障处理及IT运营分析
227 * 投诉障碍流程优化
228 * 本地网服务工作考核
229 * 二线支撑管控考核
230 * 必要时负担服务受理岗工作
231 * 必要时负担服务质监岗工作
232 )))
233
234
235 == **3.5.支持人员** ==
236
237 **担任者：**
238
239 支持人员由计费结算部、应用开发维护部、IT运行保障部所有技术支持人员组成
240
241
242 |支持人员的职责包括：
243 |(((
244 * 故障和潜在故障发现
245 * 第一时间响应事件，进行故障诊断和处理
246 * 协同其他小组工作
247 * 在必要时进行问题和维护性需求单的提交和追踪
248 * 记录变通方法/解决方案
249 * 厂商管理
250 )))
251
252 企信部各部门按照各自负责的技术领域进行技术支持分工，具体如下：
253
254 ==== ====
255
256 ==== **3.5.1.1.计费账务组** ====
257
258 受理因计费账务出错导致的前台业务类故障和投诉
259
260 ==== ====
261
262
263 ==== **3.5.1.2.计费应用组** ====
264
265 负责处理计费域应用系统故障，范围包括：计费系统（HB）、OCS、ABM和联机采集系统，以及计费域（除CRM系统外）的中间件平台
266
267 ==== ====
268
269
270 ==== **3.5.1.3.结算组** ====
271
272 负责处理结算域业务故障和应用系统故障，范围包括：应用系统的范围：综合结算、代理商系统和智能交换平台
273
274 === ===
275
276
277 === **3.5.2.应用开发维护部** ===
278
279
280 ==== **3.5.2.1.CRM组** ====
281
282 负责维护CRM域业务故障和应用系统故障，应用系统的范围：CRM系统、SPS系统和TSAP系统
283
284 ==== ====
285
286
287 ==== **3.5.2.2.非CRM组** ====
288
289 负责维护电子渠道、MSS域和OSS域应用系统，发现和处理故障
290
291
292
293 === **3.5.3.IT运行保障部** ===
294
295 ==== **3.5.3.1.运行组** ====
296
297 统一受理所有IT运行保障部职责范围内的事件单，主要指基础架构环境相关的系统故障等，组内岗责划分如下：
298
299 |岗位|职责范围
300 |BSS系统运行岗|负责维护BSS域系统下相关的主机和数据库等基础架构，发现和处理故障
301 |M&O系统运行岗|(((
302 负责维护MSS、OSS域系统下相关的主机和数据库等基础架构，发现和处理故障
303
304 负责维护内部网络、VPN、DNS、视频监控等IT运行基础设施，发现和处理故障
305 )))
306 |终端维护岗|负责维护本部门办公网和省公司大楼终端，发现和处理故障
307 |数据备份岗|负责存储和备份系统，发现和处理故障
308
309 (% class="wikigeneratedid" %)
310 ==== ====
311
312 ==== **3.5.3.2.支持组** ====
313
314 1. 支持组正常情况下不参与处理故障，以下情况支持组将参与对事件的处理：
315
316 * 运行组无法处理的故障
317 * 重大故障
318 * 升级并引起关注的故障
319
320 支持组组内岗责划分如下：
321
322
323 |岗位|职责范围
324 |主机和存储支持岗|负责主机和存储系统技术支持
325 |数据库支持岗|负责数据和中间件技术支持
326 |网络支持岗|负责网络系统技术支持
327 |信息安全岗|企信部范围内系统的信息安全管理
328
329 = **第4章事件管理流程说明** =
330
331 == ==
332
333 == **4.1.事件出入口** ==
334
335 |(% style="width:95px" %) |(% style="width:90px" %)**名称**|**说明**
336 |(% rowspan="5" style="width:95px" %)事件入口|(% style="width:90px" %)监控系统告警|监控系统产生的有效告警、将建立事件单处理
337 |(% style="width:90px" %)服务台建单|服务台在必要时自行建立事件单并协调处理
338 |(% style="width:90px" %)支持人员建单|支持人员在日常工作中发现的故障或潜在故障，需建立事件单记录并协调处理
339 |(% style="width:90px" %)本地网上报事件|本地网上报至企信部服务台的事件单
340 |(% style="width:90px" %)转派事件|省NOC、省客服、10000号、本地网服务台转派事件
341 |(% rowspan="3" style="width:95px" %)事件出口|(% style="width:90px" %)维护性需求单|(((
342 故障在处理过程中分析发现为既定的服务功能出现错误或未能实现，需要经维护性需求处理，则基于此事件单创建维护性需求单，同时事件进入等待状态，等待需求处理完成并返回结果
343
344 （二线确认故障为维护性需求时，需要发送协查请求到规建部，由规建部与用户进行需求确认，待确认完成后才创建维护性需求单）
345
346 （维护性需求单属于短流程，建议直接进入需求处理阶段）
347 )))
348 |(% style="width:90px" %)变更单|故障在处理过程中分析发现为需要进行变更处理，则基于此事件单创建变更申请单，同时事件进入等待状态，等待变更处理完成并返回结果
349 |(% style="width:90px" %)问题单|故障在处理过程中分析并未找到很好的故障解决办法，或者只能通过变通手段对故障进行临时性的解决，则需要基于此事件单创建问题单留待后续做根源性的分析和解决，同时关闭事件单
350 |(% style="width:95px" %)事件协同|(% style="width:90px" %)任务管理|事件在处理过程中发现需要其他小组人员帮助一起协查或处理，则可以基于此事件单创建多张任务单分派至不同小组
351
352
353 == **4.2.事件管理流程概述** ==
354
355 下图从总体上描述了事件管理流程、执行步骤和各步骤执行的顺序。
356
357 (% style="text-align:center" %)
358 [[image:1729862087672-227.png]]
359
360
361
362 在事件管理流程中所提及的事件，是指湖南电信企信部维护范围内的所有与IT基础架构和应用相关的故障、咨询和投诉。
363
364 事件管理流程必须对事件要速度响应和和尽快恢复业务运作。
365
366 事件管理流程主要包括五个主要环节：
367
368 |**环节**|**环节名称**|**环节说明**
369 |**1.**|**事件检测与记录**|事件生命周期的起点，产生事件记录。
370 |**2.**|**事件分类与初步支持**|对事件进行初步判断，分类，优先级判定等，在此步骤中事件可以得到初步解决或转派到相应的支持人员。
371 |**3.**|**事件调查与诊断**|支持人员(支持人员)接受分派的事件，并进行事件分析和处理的过程
372 |**4.**|**事件解决与恢复**|事件在此环节得到解决，或得到临时解决方案，服务得以恢复。
373 |**5.**|**事件关闭**|事件生命周期的终点，事件单被关闭
374
375 1. 同时，为了事件管理流程得到持续改进和优化，在事件管理流程中还要包括两个环节：
376
377 * 事件管理计划及实施
378
379 事件管理的建设和设计，并成为事件管理流程建设和改造的蓝本。
380
381 * 事件管理回顾
382
383 对事件管理流程的运行结果进行回顾，提出相应的改进计划。
384
385
386 == **4.3.流程步骤细节描述** ==
387
388
389 === **4.3.1.事件检测与记录** ===
390
391
392 ==== **4.3.1.1 描述:** ====
393
394 该步骤要快速、准确地探测和捕捉所有在IT生产环境中发生的错误现象，同时，及时将信息通知到相关的部门。在本步骤中，需要收集创建一个事件单所需要的信息。在收集信息中要准确、完整地记录必要的信息。
395
396
397 (% style="text-align:center" %)
398 [[image:1729862145549-260.png]]
399
400
401
402 ==== **4.3.1.2该流程主要内容:** ====
403
404
405 根据事件请求和服务请求，实施发起请求、识别并验证请求来源、更新相应工单、记录请求、信息是否充分、创建公告、通知用户等措施；输出创建的事件工单或关闭事件
406
407
408 ==== **4.3.1.3 具体步骤:** ====
409
410 |**1.1发起请求**|**执行者：客户**
411
412 1.根据数据来源所提出的相关事件。
413
414
415 |**1.2识别并验证请求来源**|**执行者：服务台 **
416
417 1． 接受客户的服务请求
418
419 2.根据唯一的客户信息识别并验证客户信息，需要尽量多地获取客户基本信息：
420
421 * [[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps3.png]]客户姓名（必填）
422 * 客户标识（普通员工、主管、经理等）
423 * [[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps4.png]]电话号码（手机）（二者必填一项）
424 * 分机号码
425 * 员工当前所在地点
426 * 邮件地址
427 * 所属部门
428
429 提示：
430
431 * 建议预先记录客户的信息以保障服务目标信息准确
432 * 可使用员工电话号码等作为客户的唯一识别
433 * 及时更新客户信息十分必要，可用帮助支持人员及时找到事件报告人
434
435 3.检查该客户是否属于服务对象的范围
436
437 4.如有必要，帮助客户更新客户资料，如联系方式
438
439
440 |**1.3 更新相应工单**|**执行者：服务台 **
441
442 1.对于原有的事件单，根据客户所提供的事件请求进一步的描述信息，对之前由该事件请求所产生的事件单进行进一步补充
443
444 2.补充后的工单仍按原有工单流程进行处理。
445
446
447 |**1.4记录事件请求**|**执行者：服务台 **
448
449 1.创建事件请求，生成事件工单，进入后续流程。
450
451 2.在事件单中至少需要录入以下事件信息，以下信息需要详细而准确：
452
453 * 事件的概要描述
454 * 事件的详细信息，包括事件可能造成的服务影响，影响部门等。
455 * 可能的描述事件现象的附件
456 * 事件发生的时间
457 * 事件来源:与咨询相关的事件
458 * 事件报告人信息
459
460 3.针对不同事件来源，需要填写不同的事件来源信息：
461
462 4.事件单如果是来自客户的服务请求，则需要填写客户信息，至少包含以下内容：
463
464 * 客户姓名
465 * 客户标识（普通员工、主管、经理）
466 * 联系电话/手机
467 * 所属部门
468
469 5.如果是系统自动触发的，事件告警信息是通过系统接口自动载入，至少包含以下内容：
470
471 * 事件告警严重等级
472 * 事件告警编号
473 * 事件告警信息
474 * 是否是自动触发还是手工触发，如是手工触发，则还需要记录触发人员的帐号。
475
476 6.如果该事件单是由运维人员主动发起，运维人员作为事件提交者其相关信息由系统自动填写，至少包含以下内容：
477
478 * 运维人员帐号及姓名
479 * 运维人员联系电话
480
481 7.根据客户提交请求，进行配置信息判断，关联对该事件造成影响的配置项
482
483 8.如果该事件是由于变更实施失败导致，需要在创建新事件的同时关联引发失败的变更单。
484
485 9.创建事件单后需要判断是否为服务范围，如果信息不足则进入“1.5 等待进一步信息”
486
487 10.如果是服务范围则进入“事件分类与初步支持”，如果需要的话在“1.6 创建公告”
488
489 11.如果不是服务范围，则在“1.7通知用户”，通知用户关闭事件单
490
491
492 |**1.5 等待进一步信息**|**执行者：服务台 **
493
494 1. 通知并等待用户提供进一步信息
495
496 |**1.6 创建公告**|**执行者：服务台 **
497
498 1.如果事件影响较小，不会造成大范围的影响，则不需要创建公告。
499
500 2.需要创建公告的事件可以包括以下情况：
501
502 * 事件范围大，一个部门以上的用户使用收到影响需要通知的
503 * 信息类，需要向一个以上部门发出通知或者解释说明的
504
505
506 |**1.7 通知用户**|**执行者：服务台 **
507
508 1.通知用户并关闭事件
509
510 2.通知用户的手段包括：
511
512 * 邮件通知
513 * 电话通知
514 * 短信通知
515
516
517 === **4.3.2.事件分类与初步支持 ** ===
518
519
520 ==== **4.3.2.1 描述：** ====
521
522 该步骤要对每个事件进行正确的分类，在现存的解决方案中查询与该事件相匹配的方案。若没有找到合适的解决方案或变通方法，该事件需要分配给一个具有合适技术技能的支持人员。
523
524 (% style="text-align:center" %)
525 [[image:图片2.jpg]]
526
527
528 **图‎2-3. 分类与初始支持**
529
530
531 ==== **4.3.2.2流程主要内容:** ====
532
533 根据“事件检测与记录”的事件单、处理过程中回退和处理完成后重新打开的请求，实施判断请求类型、判断事件严重性优先等级与分类、关联到主事件、更新主事件信息、查找可能的解决方案、尝试解决、实施解决方案、事件分派、进行事件分析、执行升级、直接转派等措施，输出已分派的事件工单、已解决的事件工单和提交关闭
534
535 ==== ====
536
537 ==== **4.3.2.3 具体步骤:** ====
538
539 |**2.1 判断请求类型**|** 执行者：服务台**
540
541 1.判断请求类型，如果是信息咨询类，则提供信息后进入“事件关闭”
542
543 2.根据客户提供的信息，判断该事件是否会对CI（配置项）造成影响
544
545 3.进入环节“2.3 判断事件严重性、优先等级、分类”
546
547
548 |**2.2判断事件严重性、优先等级、分类**|** 执行者：服务台**
549
550 1.[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps5.png]]查询事件的表现症状，所需要的信息如下：
551
552 * 事件简要描述
553 * 可能影响了什么服务
554 * 必要时提供软件和硬件配置信息
555
556 备注：
557
558 * 事件信息的准确记录十分关键
559 * 对事件进行准确分类 是事件能够得到快速解决的前提
560 * 具体分类规则参见5.1.5 事件分类
561
562
563 2.记录事件的表现症状根据事件描述状况进行事件分类
564
565 3.如果是客户报告的事件请求，了解该事件对服务可能产生的影响
566
567 4.如果是运维人员报告的事件请求，运维人员在提交事件请求时根据5.6“优先级”定义设定事件的优先级
568
569 5.[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps6.png]]如果是监控系统产生的告警事件，根据5.6“优先级”定义设定事件的优先级（注，目前湖南电信尚没有监控系统，此处为为未来系统接口做的扩展考虑）
570
571 6.依据预定义的事件优先级业务规则，在事件单中记录优先级（事件的优先级表应根据实际情况实时修改）
572
573 7.事件基本特征判断完成，根据客户提供事件描述信息查找是否存在的症状类似的事件工单。
574
575 * 如果存在类似的事件单，转入环节“2.3 关联到主事件”。
576 * 如果不存在类似的事件单，进入“2.5 查找可能的解决方案”。
577
578 提示：
579
580 * 类似事件通常表现为由于某个原因导致的多个客户出现的同一症状的服务不可用
581
582
583 |**2.3关联到主事件 & 2.4 更新主事件单**|**执行者：服务台**
584
585 1.如事件单为重复或类似的未解决的事件，将新的事件单关联到原有事件单，原有事件单进行更新。
586
587 * 原有事件单被标识为“主事件单”
588 * 原有事件单关联事件单数加一
589 * 新建事件单出现在原有事件单重复工单列表中
590
591 2.新事件单状态将随原有事件单状态的更新而更新，不单独进行处理
592
593
594 |**2.5 查找可能的解决方案**|**执行者：服务台**
595
596 1.查找可能的解决方案将提供两种途径：
597
598 * 在原有事件工单中查找可能的解决方案或临时变通方法
599 * 在关联的知识库中查找可能的解决方案或临时变通方法
600
601 2.根据查询结果，判断是否存在可能的解决方案或变通方法；
602
603 * 如果存在解决方案/变通方法，转至“2.7 实施解决方案”
604 * 如果没有找到解决方案/变通方法，转至环节“2.6 尝试解决”；
605
606 |**2.6 尝试解决**|**执行者： 服务台**
607
608 1.服务台人员根据自身所拥有的技能尝试确定“解决方案或变通方法”，进行事件解决；
609
610 * 如果可以解决，转至转至“2.7 实施解决方案”
611 * 如果不能解决，转至环节“2.8 事件分派”；
612
613 |**2.7 实施解决方案**|**执行者： 服务台**
614
615 1.在系统中实施临时措施或解决方案，使服务得到恢复。
616
617 2.服务恢复之后，进入步骤“事件关闭”
618
619 3.此环节通常是在流程系统外完成，将实施完成的结果登记到流程系统中
620
621
622 |**2.8 分派事件**|**执行者：服务台**
623
624 1.[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps7.png]]根据事件分类不同，进行事件分派；
625
626 * 不同的事件工单会有不同的事件类别和所属地点属性；
627 * 根据事件类别和地点属性不同，事件工单会被直接分派到相应的技能组/支持人员，转至环节2.9“进行事件分析”；
628
629 2.服务台在执行“事件关闭”操作时发现某些事件在得到支持人员事件解决的反馈后，由服务台与客户沟通后发现客户未认可事件得到解决，则该事件重新进入“分派事件”环节。
630
631
632 **提示：**
633
634 * 根据XX电信目前事件分配状况，按事件工单分类不同分派到不同的技能组
635
636 |**2.9 进行事件分析**|**执行者： 支持人员**
637
638 1.得到事件工单分派的通知，进行事件检查，并确认是否接受分派的事件工单
639
640 2.支持人员查看事件，判断是否具备执行事件诊断和分析的技能
641
642 * 如果具备，接受这个事件并转至步骤4.3.3“调查和诊断”,环节3.1 “进行事件分析与评估”.
643 * 如果不具备，需要升级，转至环节“2.10 执行升级”
644 * 如果不具备，无需升级，转至环节“2.11直接转派”
645
646 |**2.10 执行升级**|**执行者： 支持人员**
647
648 1.执行升级的情况如下：
649
650 * 事件的处理非常复杂，耗时较多
651 * 派单次数超过3次，升级至相关事件经理及相应直属领导
652 * 事件经理或客户对事件处理过程不满意，要求支持人员重新处理事件，需要升级至相关事件经理及相应直属领导
653
654 |**2.11 直接转派**|**执行者： 支持人员**
655
656 1.对于支持人员之间的转派，可以直接实现，组内转派到人，组间转派到组
657
658 2.工单转派后，进入环节“2.9 进行事件分析”，支持人员接到工单后进行事件分析
659
660 3.转派的原因如下：
661
662 * 支持人员不具备解决该事件单的技能或时间，直接将事件单转派给其他支持人员
663 * 支持人员认为该事件单出现分类选择错误，导致处理人员选择错误，可以在修改该事件单的分类后，将事件单转派给其他支持人员
664 * 在事件单处理过程中，支持人员难以找到解决方法，可以直接将事件单转派给其他技能较强的支持人员
665 * 在事件的解决时，发现解决方案需要改进，而自身能力有限，支持人员可以转派工单给其他支持人员，改进解决方案
666 * 事件经理对事件处理过程不满意，事件单功能升级后，工单派至相应分析员重新进行补充处理
667 * 用户对事件处理结果不满意，事件单进行功能升级后，事件记录员退回工单至相应的处理人员，重新进行处理
668
669
670 === **4.3.3.事件调查和诊断** ===
671
672
673 ==== **4.3.3.1.描述: ** ====
674
675 这个步骤阶段要进行深入调查，对事件进行诊断，以解决事件。支持人员要根据步骤找到合适的解决方案或变通方法。
676
677
678 (% style="text-align:center" %)
679 [[image:1729862828843-152.png]]
680
681
682 ==== **4.3.3.2.流程主要内容:** ====
683
684 根据初步分类的事件单、分析员主动发现的事件、未成功解决的事件单、知识库现有知识、事件数据库中的现有解决方案，实施事件分析和评估、收集分析相关信息、再次确认严重等级及分类、进行关联、诊断、试图解决事件的措施，得出“解决和恢复”工单、需要升级的工单或事件关闭的工单
685
686 ==== ====
687
688 ==== **4.3.3.3 具体步骤:** ====
689
690 |**3.1事件分析和评估**|**执行者：支持人员**
691
692 1.来源于用户的事件，将在本环节对事件进行分析和评估
693
694 2.来源于支持人员的事件报告，创建工单后，直接进入该环节，对事件进行分析和评估
695
696 3.在事件的调查和诊断中，需要对关键信息进行补充搜集，进入环节“3.2收集分析相关信息”
697
698
699 |**3.2收集分析相关信息 **|**执行者：支持人员**
700
701 1.支持人员查找事件处理的有用信息，获得信息后，记录到事件工单中
702
703 2.需要用户提供进一步信息时，可以主动联系用户收集信息
704
705 3.完成信息的收集和分析后，进入环节“3.3再次确认严重等级及分类”
706
707
708 |**3.3再次确认严重等级及分类**|**执行者：支持人员**
709
710 1.根据对事件的分析和评估，再次确认事件的分类
711
712 2.从专家角度再次确认事件的严重等级，并对错误等级进行调整
713
714 3.如果有相关事件，进入环节“3.4进行关联”；否则，进入环节“3.5 诊断”
715
716
717 |**3.4进行关联**|**执行者：支持人员**
718
719 1.如果该事件单有关联事件单，进行事件单关联
720
721 2.如果该事件单为现有事件的主事件
722
723 * 原有事件单被标识为“子事件单”
724 * 原有事件单出现在现有事件单的子工单列表中
725 * 事件单进入环节“3.5诊断”
726
727 3.如果该事件单为现有事件的子事件
728
729 * 原有事件单被标识为“主事件单”
730 * 新建事件单出现在原有事件单的子工单列表中
731 * 原子事件数量加1
732
733 4.子事件单状态将随主事件单状态的更新而更新，不需要单独进行处理子事件单，如果主事件单进入“已解决”状态，子事件单随之更新为“已解决”状态
734
735
736 |**3.5诊断**|**执行者：支持人员**
737
738 1.支持人员利用已有信息，对事件进行诊断，确认事件的详细情况
739
740 2.完成诊断后，转入环节“3.6试图解决事件”
741
742
743 |**3.6试图解决事件**|**执行者：支持人员**
744
745 1.根据对事件的诊断，着手处理事件，通过专业知识尝试进行解决，寻找可能的解决方案或变通方法
746
747 2.如果寻找到解决方案或变通方法，进入步骤“4解决与恢复”，如果没有寻找到解决方案或变通方法，进入步骤“4.3.2 分类与初步支持”
748
749
750 === **4.3.4.解决和恢复** ===
751
752 ==== ====
753
754 ==== **4.3.4.1.描述:** ====
755
756 这个步骤要使用解决方案和变通方法来解决事件。对于某些事件，需要创建变更单或者需求单解决事件。
757
758
759 (% style="text-align:center" %)
760 [[image:1729862863138-519.png]]
761
762 ==== ====
763
764 ==== **4.3.4.2.流程主要内容:** ====
765
766 根据“调查与诊断”事件工单、解决方案/变通方法，实施沟通决绝方案/变通方法、创建变更请求、创建需求请求、任务分解并分派、采取恢复操作、验证解决结果，输出沟通后部实施解决方案/变通方法的事件进入“分类与初步支持”、解决失败的事件进入“调查与诊断”已经恢复的事件进入“事件关闭”、需要通过变更解决的事件/流转至变更管理流程/发起变更申请。
767
768 ==== ====
769
770 ==== **4.3.4.3.具体步骤** ====
771
772
773 |**4.1沟通解决方案或变通方法**|**执行者：支持人员**
774
775 1.与用户沟通即将实施的解决方案/变通方法
776
777 2.如果用户不同意实施解决方案/变通方法，进入步骤“2分类与初步支持”
778
779 3.如果用户同意实施解决方案/变通方法，分析是否需要进行变更，如果需要变更，进入环节“4.2创建变更请求”；如果不需要变更，则：
780
781 * 是否需要创建需求，进入环节“4.3 创建需求请求”
782 * 是否需要配合完成，进入环节“4.4 任务分解并分派”
783 * 如果不需要，进入环节“4.5 采取恢复操作”
784
785 |**4.2创建变更请求**|**执行者：支持人员**
786
787 1.创建变更请求单，进入变更管理流程
788
789 2.变更实施完成后，进入步骤“5事件关闭”
790
791
792 |**4.3创建需求请求**|**执行者：支持人员**
793
794 1.创建需求请求单，进入需求管理流程
795
796 2.需求单创建后，直接关闭事件工单
797
798
799 |**4.4任务分解并分派**|**执行者：支持人员**
800
801 1.对事件单进行分解并分派到其它支持人员
802
803 2.任务单处理完成后，处理任务单的支持人员进行相关反馈
804
805 3.任务单完成前，事件单不可以转入“已解决”状态
806
807 4.所有任务处理完成，收到反馈后，进入环节“4.6验证解决结果”
808
809
810 |**4.5采取恢复操作 **|**执行者：支持人员**
811
812 1.与客户就解决方案/变通方法达成一致意见后，进入实施
813
814 2.处理完成后，进入环节“4.6验证解决结果”
815
816
817 |**4.6验证解决结果**|**执行者：支持人员**
818
819 1.对解决结果进行验证
820
821 2.如果服务恢复，进入步骤“5事件关闭”
822
823 3.如果服务没有恢复，进入步骤“3调查与诊断”
824
825
826
827 === **4.3.5.事件关闭** ===
828
829 ==== ====
830
831 ==== **4.3.5.1.描述:** ====
832
833 这个步骤要确保客户对事件的处理情况感到满意。保证事件单的信息是正确、完整的，以便于以后生成报表。处理过程中的经验要得到记录以形成可重用的知识。
834
835
836 (% style="text-align:center" %)
837 [[image:1729863014449-857.png]]
838
839
840 ==== **4.3.5.2.流程主要内容:** ====
841
842 根据“1检测与记录”“2分类与初步支持”“3调查与诊断”“4解决与恢复”的事件、已经完成的变更、用户对解决情况的反馈，实施验证并检查记录、更新工单记录、与用户沟通、关闭相应公告、关闭工单等措施，输出已关闭的事件单、经过检查没有解决的事件单以及用户不满意的事件单
843
844 ==== ====
845
846 ==== **4.3.5.3.具体步骤** ====
847
848
849 |**5.1验证并检查记录**|**执行者：事件记录员**
850
851 1.告警消除的来自监控系统的事件，事件记录员对结果进行验证，并确认事件单的完整性
852
853 2.对于来自于用户的事件，对事件单内容的完整性的进行确认
854
855 3.如果记录不完整，进入环节“5.2更新工单记录”
856
857 4.如果工单记录完整，判断工单关闭是否需要用户确认，如果需要用户确认，进入环节“5.3与用户沟通”；如果不需要用户确认事件解决结果，直接进入“5.4关闭相应公告”
858
859
860 |**5.2更新工单记录**|**执行者：支持人员**
861
862 1.支持人员接到服务台需要更新事件记录的通知后，对事件单进行完善，补充事件记录
863
864 2.事件单补充完成后，事件记录员判断工单关闭是否需要用户确认，如果需要用户确认，进入环节“5.3与用户沟通”；如果不需要用户确认事件解决结果，直接进入“5.4关闭相应公告”
865
866
867 |**5.3与用户沟通**|**执行者：事件记录员**
868
869 1.联系用户，征询对事件处理结果是否满意，记录用户意见
870
871 2.如果用户对事件的解决不满意，则转入步骤“2分类与初步支持”
872
873 3.如果用户满意解决结果，进入“5.4关闭相应公告”
874
875
876 |**5.4关闭相应公告**|**执行者：事件记录员**
877
878 1.如果有相应公告，进行关闭
879
880 2.进入环节“5.5关闭事件单”
881
882
883 |**5.5关闭事件单**|**执行者：支持人员/事件记录员**
884
885 1.来自于支持人员提出的事件，处理完成后，直接关闭事件单
886
887 2.用户提出的事件，由事件记录员关闭事件单
888
889
890 === **4.3.6.跟踪回顾** ===
891
892 ==== ====
893
894 ==== **4.3.6.1.描述:** ====
895
896 在进行事件处理过程中，为了保证XX电信企信部提供业务支持的服务质量，保证对事件的及时响应和快速解决，事件经理要对事件的整个处理过程进行实时监控，处理升级的事件。
897
898
899 (% style="text-align:center" %)
900 [[image:1729863056927-116.png]]
901
902
903
904 ==== **4.3.6.2.流程主要内容:** ====
905
906 根据未解决的事件、客户提出的查询请求和升级的事件单，实施选择事件、跟踪/回归过程、要求更新工单、更新信息、交流事件状态，得出更新记录的事件单和进一步升级的事件单
907
908 ==== ====
909
910 ==== **4.3.6.3.具体步骤** ====
911
912
913 |**6.1选择事件**|**执行者：事件经理**
914
915 1.进入事件管理流程系统，查询执行过程中的事件工单
916
917 2.选择要跟踪回顾的对象
918
919
920 |**6.2跟踪/回顾过程**|**执行者：事件经理**
921
922 1.浏览跟踪回顾的事件工单，主要包括：
923
924 * 事件处理日志
925 * 事件解决方案或变通方法
926 * 事件处理耗时
927
928 2.必要时，要求事件处理人员更新事件单信息，进入环节“6.3要求更新记录”
929
930 3.如果对事件处理过程不满意，则升级事件，进入环节“4.3.2分类与初步支持”
931
932 4.如果还需要进一步联系用户，进入环节“6.5交流事件状态”
933
934 5.如果对处理过程满意，且不需要进一步联系用户，则跟踪回顾结束
935
936
937 |**6.3要求更新工单**|**执行者：事件经理**
938
939 1.如果事件单信息不完整，要求事件处理人员更新事件单信息
940
941
942 |**6.4更新信息**|**执行者：事件记录员\支持人员**
943
944 1. 事件处理人员对事件单内容进行更新
945
946 2.事件更新结果反馈回事件经理，事件经理进行下一步操作
947
948
949 |**6.5交流事件状态**|**执行者：事件经理**
950
951 1.如果需要与用户交流事件的处理状况和情况，联系用户进行沟通，并补充到事件工单中
952
953 2.交流结束后，跟踪回顾结束
954
955 === ===
956
957 === **4.3.7.重大（危机）事件** ===
958
959 重大故障由服务人员在处理过程中主观发现和定义，判断依据如下：
960
961 * CRM系统、计费、结算系统等核心应用系统业务瘫痪或中断；
962 * 省级生产网络瘫痪或中断；
963 * 事件管理中“紧急程度”和“影响程度”均为最高的故障；
964
965 以上故障可称为重大故障。
966
967 重大故障的组织和协调机制，参见《湖南电信重大故障管理办法》
968
969 = =
970
971 = =
972
973 = **第5章业务规则** =
974
975 注：所有在本章节所提及的日期和时间是指“经过的（elapsed）”的日期和时间。
976
977 == ==
978
979 == **5.1.总体业务规则** ==
980
981 1.XX电信所支持的系统和网络环境中，所有对操作特性和服务提供有影响的事件都会通过事件管理流程处理；事件将通过流程中定义的标准、业务规则和指导进行管理。
982
983 2.所有报告和处理事件的部门将会参与统一的事件管理流程，不应该有任何例外。
984
985 3.所有IT支持人员对优先级（极高）和（高）的事件所采取的恢复服务的行动，相比其他任务具有优先权。
986
987 4.对于省客服、省NOC、10000号等外部转派的事件单并带有解决时间要求的，应遵照其解决时间的要求进行处理。
988
989 5.应由服务台定期产生和回顾事件管理报表。对没有解决的问题，应生成问题进行跟踪和处理，服务台对此有考评职责。
990
991 6.应由服务台定期对流程进行回顾，以改进事件管理流程。
992
993
994 === **5.1.1.责任人业务规则** ===
995
996 事件管理需要定义一个责任人业务规则，以确保每个事件在任何时段都有适当的人员负责。
997
998 事件管理：
999
1000 1.当一个事件被创建后，服务台负责这个事件单
1001
1002 2.当事件单被分派后，支持人员负责此事件单；在故障现象描述和对应正确时，被分派方遵循首问责任制，被分派的支持人员有权拒绝故障现象不属于本组职责范围内的事件单。
1003
1004 3.如果需要向客户通知处理情况，由事件单的当前责任人负责
1005
1006
1007 === **5.1.2.分类规则** ===
1008
1009 1.分类分为两个，“故障现象分类”和“故障根源分类”
1010
1011 2.服务台派单时填写故障现象，以故障现象为准分派支持人员
1012
1013 3.支持人员转派事件和解决事件时以填写故障根源，故障根源为准
1014
1015
1016 |**分类**|**原则**|**上级分类**
1017 |**类别（Category）**|**分类原则以能够准确定位事件所在系统、设备或者功能单元为准，且需要兼顾服务台人员的判断能力，如OCS系统**|
1018 |**子类（Type）**|**分类原则以能够指导事件分派到相应处理组为准，且需要兼顾服务台人员的判断能力，如应用、主机、数据库**|**类别**
1019 |**现象分类（superficies）**|**分类原则以能够描述故障现象为准，如计费出错**|**子类**
1020 |**根源分类（causation）**|**分类原则以能够描述故障根源为准，如数据错误**|**子类**
1021
1022 具体分类参见《事件管理设计信息表》
1023
1024
1025 === **5.1.3.分派业务规则** ===
1026
1027 1．分派业务规则主要决定由服务台创建事件后的分派原则。
1028
1029 |分派规范|描述
1030 |规范一|基于目前管理状况，建议服务台分派事件到组而非到人
1031 |规范二|服务台依据事件（故障）现象在三级分类中指定二线处理路径
1032 |规范三|可分派的二线人员组列表将根据事件分类和事件地点信息进行筛选
1033 |规范四|二线处理遵循首问制的原则，可将不属于本组处理的事件单转派其他小组。转派前必须明确事件（故障）根源
1034 |规范五|对于事件（故障）现象填写出错并由此造成的分派错误，二线处理小组有权将事件单退回服务台，退回时必须说明理由
1035 |规范六|发生三次以上分派、转派和回退的事件将自动通知事件经理，由事件经理协调处理
1036
1037 === **5.1.4.代办业务规则** ===
1038
1039 考虑到XX电信在人员组织方面的实际情况，可以允许在事件处理过程中实现代办功能，代办原则如下：
1040
1041 * 服务台和支持人员，由于某些原因（例如出差，休假，培训等）离开本岗位时，必须确保将未处理完毕的事件单重新分派到本岗位其他事件处理人员；如果
1042 * 本岗位只有自己一人，则通过指定代办人的方式，确保在代办期间，由代办人处理该岗位的各项工作；
1043
1044 === **5.1.5.优先级** ===
1045
1046 1. 事件的优先级表明了支持人员对事件工单处理的优先程度。它是评定事件处理优先等级的一个重要指标。
1047 1. 所有事件都将分配到四个优先级中的一个。优先级从 1 (极高) 到 4 (低) 。
1048 1. 优先级在事件的生命周期中是可以改变的。关于更改事件单优先级的原因和行为应该在事件单中记录。
1049 1. 事件的优先级通常由两方面的指标共同决定：事件影响度及事件紧急程度。
1050
1051 ==== ====
1052
1053 ==== **5.1.5.1.事件影响程度** ====
1054
1055 * 事件影响度规则
1056 ** 规则一：事件影响程度由服务台或支持人员建单和受理时判断定义
1057 ** 规则二：事件影响程度定义如下表所示
1058 * 我们可以根据一个表格来制定湖南电信事件的影响程度，在下表中对事件的影响程度按照四个等级进行划分，每个等级中对事件的表象进行了描述，服务台可以根据影响程度的定义对事件进行影响度的划分：
1059
1060 [[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps8.jpg]]
1061
1062 ==== **5.1.5.2.事件紧急程度** ====
1063
1064 1. 事件紧急程度规则
1065
1066 * 规则一：事件的紧急程度划分为三级 ~-~-~-~- 高、中、低
1067 * 规则二：事件紧急程度由用户或服务台按照“用户类型”和“分类”交叉运算得出
1068 * 规则三：没有明确用户类型的事件紧急程度默认为“中”
1069 * 规则四：投诉类事件和升级事件紧急度默认为“高”
1070
1071 示例表：
1072
1073 [[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml368584\wps9.jpg]]
1074
1075 具体参见《事件管理设计信息表》
1076
1077
1078
1079 ==== **5.1.5.3.事件优先级的计算方法** ====
1080
1081 1. 计算方法：按照“影响范围”和“紧急程度”交叉运算得出优先级
1082 1. 规则：事件的严重等级由系统根据紧急程度和影响程度自动运算得出
1083
1084 计算规则如下表所示：
1085
1086 (% style="text-align:center" %)
1087 [[image:1729863415035-613.png]]
1088
1089
1090
1091 优先级业务规则将用于服务台，支持人员在进行事件优先级判断时参考使用。具体参见《事件管理设计信息表》
1092
1093
1094 === **5.1.6.目标解决时间业务规则** ===
1095
1096 1. 在事件处理的每个环节中，按照严重等级不同有不同的处理时间限制，超过时间将执行升级上报。
1097 1. 事件得到响应：指服务台在接到故障申报到分派处理的时间
1098 1. 事件单接受：指从服务台分派事件单到支持人员开始，到支持人员接受分派的时间
1099 1. 服务得到恢复：指支持人员从接受分派到解决事件的时间
1100 1. 工单得到关闭：指支持人员解决事件后，到确认结果并关闭事件的时间
1101 1. 事件管理的目标时间如下表所示：
1102
1103 | |事件得到响应|事件单接受|服务得到恢复|工单得到关闭
1104 |**严重等级1**|10分钟|20分钟|8H|1D
1105 |**严重等级2**|20分钟|30分钟|1D|1D
1106 |**严重等级3**|40分钟|1H|2D|2D
1107 |**严重等级4**|1H|2H|3D|3D
1108
1109 **表 3-4. 事件目标时间业务规则**
1110
1111 === ===
1112
1113 === **5.1.7.等待规则** ===
1114
1115 1. 事件可能会超过目标时间上限，但这些原因有一些是客观的，无法预期的，当事件由于这些原因进入等待状态时，等待中的时间将不计入目标时间计算中。
1116 1. 等待需要遵循以下规则：
1117
1118 |等待规范|描述
1119 |规范一|事件记录员、支持人员和事件经理可将事件置为等待状态
1120 |规范二|事件创建维护性需求时，事件自动进入等待状态
1121 |规范三|事件创建变更时，事件自动进入等待状态
1122 |规范四|事件进入等待状态必须填写等待代码，自动进入等待的事件单由系统自动填写等待代码
1123 |规范五|等待中的事件单不计入目标时间考核
1124
1125 === **5.1.8.通知业务与升级业务规则** ===
1126
1127 1. 规范一：根据湖南电信管理现状，事件升级将执行事件上报通知，以及将紧急程度置为“高”
1128 1. 规范二：事件升级触发条件包括：转派3次升级、解决驳回2次升级和超时升级
1129 1. 规范三：事件上报通知对象必须包括事件经理。在必要时，除事件经理外还可包括相关部门领导
1130 1. 事件通知触发条件和通知对象：
1131
1132 **图例: **U：相关用户；C：事件记录员；E：支持人员；M：事件经理
1133
1134
1135 |严重等级
1136 触发条件|严重等级一|严重等级二|严重等级三|严重等级四
1137 |分派/转派事件|EM|E|E|E
1138 |事件解决|UCM|UCM|UC|UC
1139 |事件关闭|C|C|C|C
1140 |升级通知|CEM|CEM|CEM|CEM
1141
1142 **表 3-6. 通知业务规则**
1143
1144 === ===
1145
1146 === **5.1.9.标准的通知内容** ===
1147
1148 1. 通过通知业务规则进行沟通的事件信息可以通过电话、系统消息、电子邮件或者短信等方式发送，并将遵循标准的格式。下列的几个通知内容项应当以容易理解的方式进行描述：
1149
1150 * 事件的简要描述
1151 * 受到影响的服务
1152 * 预计恢复服务的时间（要尽可能准确）
1153 * 联系服务台咨询更多信息的方法
1154 * 通知方式可以考虑通过短信或邮件方式自动进行。
1155
1156 === ===
1157
1158 === **5.1.10.重复业务规则** ===
1159
1160 1. 对于重复事件，将采用“主+从”关系绑定的方式处理，“从事件单”状态和受理人与“主事件单”相同。如果被报告的事件与某个已经创建且尚未解决的事件单症状相同，则该事件被认为是重复的。
1161
1162 |重复事件|描述
1163 |(% rowspan="2" %)定义|如果被报告的事件与某个已经创建且尚未解决的事件单症状相同，则该事件被认为是重复事件
1164 |如果被报告的事件可以确定是由于某个已经创建且尚未解决的事件所引起的，则该事件被认为是重复事件
1165 |(% rowspan="3" %)处理方法|服务台或者二线人员在第一张事件单受理时即判断出此事件必将带来后续重复，那么将事件置为主事件，后续事件为从事件
1166 |服务台或者二线人员在处理了多张事件单之后才发现真正的根源性事件，将根源性事件置为主单，与之前已处理的相关事件建立关联（非主从，不绑定状态），后续再出现的事件作为从单
1167 |对已关闭的事件单发现重复事件，做事件关联，不做主从
1168 |(% rowspan="2" %)配套措施|系统需要建立重复事件判断条件的配置功能，维护多个判断重复事件的条件，当满足条件时系统会弹出窗口提示操作者有哪些事件单可能是重复事件。可以选择是否关联或者主从
1169 |重复事件的主从关系允许拆解
1170
1171 === **5.1.11.复发业务规则 ** ===
1172
1173 1. 如果报告的事件与已经关闭的事件相同（查询范围含时间），该事件被认为是“复发”的事件单。这意味着为了解决事件而采取的解决措施失败了。此时应当创建一个新的事件单，复制原始事件单的内容，并说明这是复发的事件。
1174
1175 === ===
1176
1177 === **5.1.12.事件单关闭业务规则** ===
1178
1179 1. 服务台和用户进行确认并关闭工单
1180 1. 事件关闭有以下业务规则：
1181
1182 |关闭规范|描述
1183 |规范一|事件单应由事件创建者关闭,本地网发起的事件并由省企二线处理的，直接回本地网关闭
1184 |规范二|关闭事件单之前，必须确认处理结果并填写解决方案记录
1185 |规范三|事件创建需求单后，事件将自动关闭
1186 |规范四|关闭代码为解决失败或变通解决的事件单，在关闭前必须创建问题单
1187 |规范五|状态为已解决的事件单30天后系统自动关闭
1188 |规范六|事件单在关闭前，必须填写关闭代码，自动关闭的事件单由系统自动填写关闭代码。
1189 |规范七|已关闭的事件单不允许重新打开
1190
1191
1192 = **第6章质监合规与分析考核** =
1193
1194
1195 == **6.1质监合规** ==
1196
1197 服务台质监需要注意两个方面
1198
1199 第一，是日常的流程执行质量和合规要求的质监，通过系统和人工手段对每张工单进行实时质监，由服务台服务受理岗和质监岗对质监出现问题的工单及时介入进行督促协调或者请求领导支持。
1200
1201 第二，是收集和整理质监数据，分析流程的执行效率和存在的瓶颈及问题。此项工作可以按月度或者季度进行，由服务台质监岗牵头，事件经理负责。
1202
1203 如下表：
1204
1205 |工作类型|工作方式|工作内容|说明
1206 |(% rowspan="6" %)日常质监|半自动|分类质监|对工单分类的填写正确性进行质监，包括分派时和关单时
1207 |半自动|工单填写合规质监|对工单内容的填写按照合规要求进行质监，包括未填写和填写不规范，表述不清，信息不全等
1208 |半自动|严重等级质监|对严重等级相关的紧急度、影响度填写进行质监
1209 |自动|升级质监|监控工单的执行，对达到升级要求的工单进行升级上报
1210 |半自动|关单质监|在工单处理完成时进行一次质监，主要查看工单内容填写情况，如关闭代码是否填写，解决方案是否填写。
1211 |人工|督促协调|对质监出现问题的工单及时进行协调处理和督促处理，并在必要时请求领导介入支持
1212 |(% rowspan="2" %)流程分析|半自动|规范修正|对流程管理规范（分类、严重等级等）进行评估，对需要修正的规范提交领导审阅
1213 |半自动|流程效率分析|对流程执行效率（如工单总量和超时率）进行评估分析，找出流程本身可以进一步优化的地方
1214
1215 工作方式：“自动”为系统可以帮助完成；“半自动”为系统可以帮助完成一部分信息收集工作，只能起到辅助作用，最终还是需要人工判断；“人工”指的是系统无法提供帮助，属于人工完成的工作。
1216
1217
1218 == **6.2考核分析** ==
1219
1220 考核的方面包括：
1221
1222 * 对本地网服务台的考核
1223 * 对二线处理的考核，对厂商的考核要求将归并到对二线人员的考核中；
1224 * 对企信部服务台自身绩效考核。
1225
1226 |考核对象|考核内容|说明|KPI
1227 |(% rowspan="2" %)本地网服务台|预处理率|本地网服务台事件单预处理比例|（本地处理工单数/本地工单总数）>85%
1228 |上报正确率|本地网服务台上报企信部服务台事件单被驳回比例|（退回服务台工单数/本地工单数）<1%
1229 |(% rowspan="6" %)企信部服务台|派单准确率|服务台派单被二线驳回比例|（退回服务台工单数/省工单总数）<1%
1230 |派单及时率|服务台派单超时比例|（分派超时工单数/省工单总数）<99%
1231 |投诉率|专指对工单处理的投诉比例|（遭投诉工单总数/省工单总数）< 1%
1232 |告警工单生成率|监控组将有效告警转成告警事件单比例|（告警类工单总数/有效告警数）> 95%
1233 |维护作业完成率|监控组对维护作业计划的执行率|（已完成巡检单/计划巡检单）= 100%
1234 |客户满意度|客户满意度需要相关调研手段的配合，如问卷方式| 不满意客户/全部客户 <10%
1235 |(% rowspan="5" %)二线处理小组|受理及时率和处理完成及时率|受理超时和处理超时比例，按各个二线小组统计|（及时处理工单总数/承接工单总数）> 95%
1236 |关单确认率|解决完成事件被用户核实并关单的比例，按各个二线小组统计|（关单驳回数/本组工单总数）<1%
1237 |问题单覆盖率|未成功解决工单中转问题单的比例|（故障转问题数/不成功工单总数）> 90%
1238 |处理完成率|事件处理正常解决的比例，按各个二线小组统计|（成功解决数/本组工单总数）>80%
1239 |重发故障率|被正常解决并关单的事件，事后重新发生并被确认为重发故障。占所有正常解决事件的比例，按各个二线小组统计|（重发故障工单次数/成功解决工单总数）< 5%
1240
1241 具体考核指标内容可参见《XX电信企信部指标体系》
1242
1243 == ==
1244
1245 == **6.3故障分析** ==
1246
1247 故障分析主要是两个维度的工作，为服务质量的提升找到数据上的依据和切入点：
1248
1249 * 第一，故障规律分析；
1250 * 第二，闭环管理相关分析；
1251
1252 故障分析由服务台故障分析岗和事件经理完成，一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础完成分析，召开例会，总结经验教训并修正不合适的分析指标。
1253
1254 分析例会应根据需要选择以月例会、季度例会的方式进行
1255
1256 分析内容如下：
1257
1258 (% style="text-align:center" %)
1259 [[image:1729863581118-960.png]]
1260
1261
1262
1263
1264 = **第7章流程维护机制** =
1265
1266
1267 流程本身是需要不断完善和优化的，在日常工作、流程回顾、故障分析时都会产生对流程本身进行优化调整的需求，很多企业优化工作陷入停滞，最主要的原因就是缺少一套行之有效的维护机制。
1268
1269 对此，在管理上需要执行一套简单易行的维护机制，简述如下：
1270
1271 |**维护项**|**描述**|**执行工序**|**审批人**|**执行周期**
1272 |日常维护|人员账户和人员组增删改，权限配置，错误工单修正等日常的维护操作|(((
1273 * 服务台发起
1274 * 服务台自行操作
1275 )))|无需审批|日常
1276 |配置信息维护|分类（故障现象、故障根源）、分类和人员组映射配置、等待代码、关闭代码、邮件模板更新等信息配置类操作|(((
1277 * 服务台发起
1278 * 服务台/事件经理审批
1279 * 服务台自行操作或提交系统管理员操作
1280 )))|服务台/事件经理|每周
1281 |规则信息维护|流程流转步骤和判断条件修正、优先级计算规则修正、目标时间和升级规则修正、自动派单及重复事件判断条件修正等对流程相关规则的修改和优化操作|(((
1282 * 服务台发起
1283 * 服务台/事件经理审批
1284 * 系统管理员操作
1285 )))|服务台/事件经理|每月
1286 |系统维护|系统性能优化、故障处理等功能类维护|(((
1287 * 系统管理员负责
1288 )))|无需审批|日常
1289
1290 执行周期是对操作时间窗口间隔的限制，过于频繁的规则和配置修正会影响流程的有效推广
1291
1292 其他（如二线）人员需要对流程的配置信息和规则进行修改，需要将建议提交服务台，由服务台发起
1293
1294
1295
1296
1297 = **附录一:**日常工作管理要求 =
1298
1299
1300 == **1.1日常管理** ==
1301
1302
1303 === **1.1.1轮班制度** ===
1304
1305 信息中心，尤其是服务台小组应当制定一个轮班制度和步骤，并明确由何人负责修改该制度、步骤，由谁授权这些修改，如何发布新的修改，并制定修改的规则，以保障操作员的利益。
1306
1307
1308 === **1.1.2休假，培训，病假和其他事假** ===
1309
1310 应当记录并维护所有的缺席状态，确保核心系统总是技术人员能够支持。应当制定审批休假的授权标准，确定授权人，确保现场有足够的人员工作。另外，应当制定备份方案，以防关键人员病假或者其他原因不能到场支持。
1311
1312
1313 === **1.1.3电话值班** ===
1314
1315 对于核心业务系统，每天应当确定在正常工作时间之外的主责支持人员和后备人员，称为“电话值班人员”，当天的支持人员应当确保手机等联络工具通畅。特别对于一些不太稳定的系统，工作时间之外可能更需要频繁的现场支持。值班人员应当清楚了解每个支持人员的联系方式，以防主责人员联系不到时可以联系后备人员。
1316
1317 应当建立内部的服务水平，如：对于紧急电话的响应时间、到现场时间、解决问题的时间等，加强对于紧急事件处理的责任感和效率。
1318
1319 如果支持人员未能响应，或者未能及时到场，可以采用事件升级的步骤。
1320
1321
1322 == **1.2检查清单（备忘录）** ==
1323
1324
1325 === **1.2.1换班交接检查清单 ** ===
1326
1327 可以为所有参与操作值班的员工制定一份检查清单，避免员工在交接班的时候遗漏任何应当转交的内容。
1328
1329
1330 === **1.2.2其他交接清单（如：服务台与操作小组之间的交接）** ===
1331
1332 同样，也可以为服务台（在工作时间接受事件报告）与操作组（在非工作时段接受事件报告）交接时制定交接清单。该清单应包括所在值班时段发生的重大事件，以及一些需要下一班注意的事项。
1333
1334
1335 === **1.2.3监控检查清单** ===
1336
1337 所有的维护组员工应当制定每日维护工作的检查清单，包括每日应当监控和检查的项目（如：必须人工检查的内容，设备指示灯、屏幕、以及运行一些检查脚本程序的结果等），以及其他每日例行的工作。检查清单可以细分为日检查清单、周检查清单、月检查清单、年检查清单。这些清单应当由小组长签字，确保所列项目都已执行。
1338
1339 如果某个员工遗漏了某些检查项目，必须有正当的理由。
1340
1341
1342 === **1.2.4值班日记（包括注意事项、意外情况、经验教训等） ** ===
1343
1344 很多IT部门的操作部门都会维护一份值班日记，纪录值班期间发生的意外情况、注意事项、经验教训等。值班日记也成为交接内容的一个重要部分。
1345
1346
1347 == **1.3公告管理** ==
1348
1349 “公告”指信息中心对其所服务对象（各业务部门）的信息公示手段，可采用的手段包括系统公告，邮件群发，张贴纸质通告等手段，目的就是将信息最有效的通知到目标人群。
1350
1351 公告建议由服务台人员统一管理。
1352
1353 非服务台人员在具备发出公告条件时，需通知服务台人员，由服务台人员负责发出公告，通知方式不限。
1354
1355
1356 === **1.3.1触发条件和通知对象** ===
1357
1358 |**种类**|**触发条件**|**通知对象**|**公示期限**
1359 |文档发放|文档需要发放，如调查表等|文档所针对业务部门|文档有效期内
1360 |信息公示|政策，规范等需要公示|信息所针对业务部门|信息有效期内
1361 |操作指导|应用系统操作指导|所有用户|操作方式改变后
1362 |故障通告|系统故障，对用户造成较大影响时，比如影响程度为1的事件|受影响用户|故障解决后
1363 |停机通告|影响为1和2的变更在执行前，需要发出停机通告|受影响用户|变更完成后
1364
1365 === **1.3.2公告用语** ===
1366
1367 公告包括“标题”“正文”“落款”三个组成部分。
1368
1369
1370 |**种类**|文档发放
1371 |**内容要求**|需说明发放部门，接收部门，文档用途，如果需要填写并回收的，需说明负责人、填写方法、回收方式及期限。
1372 |**范例**|(((
1373 OA系统使用情况调查表发放通知
1374
1375
1376 为配合OA项目组更好的进行系统测试的工作，现下发OA系统使用情况调查表，希望各相关部门予以配合。
1377
1378 各部门每位OA使用者均需要填写，下载附件调查表并按表内提示填写完成后，交与各部门汇总，由管理员统一发送至企信部~*~**部门。
1379
1380 截止日期为~*~*~*~*。
1381
1382 联系人电话：~*~*~*~*，邮箱：~*~*~*~*
1383
1384 谢谢配合！
1385
1386
1387 附件：OA系统使用情况调查表.doc
1388
1389 ~*~*~*~*~*~*
1390
1391 ~*~*~*~*-*-~*~*
1392 )))
1393
1394 |**种类**|信息公示
1395 |**内容要求**|需说明信息内容，信息所针对范围，信息生效和失效时间。
1396 |**范例**|(((
1397 公司OA系统使用规范v1.0
1398
1399
1400 为配合OA系统的正式启用，现在发布《公司OA系统使用规范》v1.0版，主要是对公司内OA用户进行使用上的指导和规范，以及一些重要功能的操作指导和约束。请各OA用户认真下载阅读。
1401
1402 本规范从发布之日起生效。
1403
1404 谢谢配合！
1405
1406
1407 附件：公司OA系统使用规范 v1.0.doc
1408
1409 企信部
1410
1411 ~*~*~*~*-~*~*-~*~*
1412 )))
1413
1414 |**种类**|操作指导
1415 |**内容要求**|需要说明系统名称，发布操作指导的原因和使用场景。
1416 |**范例**|(((
1417 访问公司主页系统乱码处理办法
1418
1419
1420 近日很多用户向中心反映，在访问公司主页系统时会在新闻栏看到乱码，为此经过相关技术人员的研究，发现这是用户浏览器终端配置的问题，现将解决办法予以公示，当用户再次遇到类似问题时，可以按照提示自行解决，也可以选择拨打~*~*~*~*请心服务台人员帮助解决。
1421
1422 谢谢配合！
1423
1424
1425 附件：公司主页系统乱码处理办法.doc
1426
1427 企信部
1428
1429 ~*~*~*~*-~*~*-~*~*
1430 )))
1431
1432 |**种类**|故障通告
1433 |**内容要求**|需要说明故障原因，影响范围，预期解决时间，当然还要表示歉意
1434 |**范例**|(((
1435 6月20日OA系统故障通告
1436
1437
1438 由于数据库系统故障，导致本日10:00开始OA系统停止服务，全公司OA用户均无法登陆OA系统，现在技术人员正在全力解决故障，预计本日15：30之前可以恢复服务。
1439
1440 因此给您带来的不便我们表示万分抱歉！并谢谢您的配合和谅解！
1441
1442
1443 企信部
1444
1445 ~*~*~*~*-~*~*-~*~*
1446 )))
1447
1448 |**种类**|停机通告
1449 |**内容要求**|需要说明停机原因，影响范围，预期恢复时间，当然还要表示歉意
1450 |**范例**|(((
1451 6月22日OA系统停机通告
1452
1453
1454 为了使OA系统可以更加稳定和高效的运行，经过OA项目组研究决定，计划在6月22日19:00到23:00进行OA系统数据库升级，期间OA系统将停止服务，请各部门用户届时提前结束OA系统上的工作，并在此期间不要尝试登录OA系统。
1455
1456 因此给您带来的不便我们表示万分抱歉！并谢谢您的配合和谅解！
1457
1458
1459 企信部
1460
1461 ~*~*~*~*-~*~*-~*~*
1462 )))
1463
1464
1465 = **附录二:服务台运行管理要求** =
1466
1467
1468 == **1.1服务受理规范** ==
1469
1470
1471 === **1.1.1客户信息记录准确** ===
1472
1473 受理Case时首先要询问员工编号，没有员工编号的可以记录临时邮件账号或联系电话，以便进行Case问题的跟踪及进行信息反馈。
1474
1475
1476 === **1.1.2问题信息记录准确** ===
1477
1478 详细记录客户描述的问题现象，当可以解决问题时需记录问题原因及解决方法，以便放到知识库中使资源共享。未能解决的问题可以分发给现场或进行初步处理，进行初步处理的Case要对问题进行跟踪，直到问题解决。
1479
1480
1481 === **1.1.3处理客户投诉遵循的原则** ===
1482
1483
1484 === **1.1.4状态跟踪机制** ===
1485
1486 我们遇到投诉或者是投诉升级的时候经常会发现，好像每个处理的人都做了合理的事情，但是投诉还是产生和升级了。其实这就是由于没有一个事件跟踪的流程导致的，很多部门配合的时候更容易出现这样的情况，因此说这种事件状态跟踪机制是必需的，而且不仅仅是在投诉的处理上面。事情的处理一定是闭环的，有头有尾的。
1487
1488 服务台人员必须首先对自己接手处理的事件负责，有责任和义务跟踪自己处理事件的当前状态并在需要时反馈给用户。
1489
1490 服务台经理对整个服务台的事件处理情况负责。
1491
1492 === ===
1493
1494 === **1.1.5投诉升级机制** ===
1495
1496 有了状态跟踪机制其实并不能保证事情得到及时的处理，这需要另外一个机制来控制——投诉处理升级机制。如果一件事情在相应规定的时间没有解决掉，相关的管理者会逐级得到信息——该投诉未能及时处理完成以及当前的状态。这样相应的管理人员就逐渐参与到投诉的处理当中，加快事件的处理。而一般的投诉专人负责的岗位就已经可以处理了，管理者只需要按时得到每周的报告就可以了。
1497
1498 事件超时时会自动升级至事件经理，事件经理通常是服务台经理兼任，事件经理有责任和权利协调资源优先处理升级事件，包括与二线团队协调资源。
1499
1500 === ===
1501
1502 === **1.1.6报告机制** ===
1503
1504 已经有跟踪、升级处理等机制，但如果想把用户投诉的问题转化为服务提升的动力，那详细的分析报告将是非常重要和必需的。一个简单扼要、眼光敏锐、总结分析到位的报告对管理者提升服务来说是很有帮助的。
1505
1506 服务台建议设置周报和月报制度，每周和每月定时将报告汇总给服务台经理。
1507
1508 === ===
1509
1510 === **1.1.7回访处理** ===
1511
1512 投诉处理结束了，我们还有事情要做，就是对曾经投诉我们服务的用户进行回访，投诉过你的用户今后可能还是你的用户，请他谈谈对改进后的服务的看法，听听用户对整体服务的意见和建议。
1513
1514
1515 == **1.2处理投诉的基本方法** ==
1516
1517 以下为对于服务台人员在处理投诉时的基本方法建议，实际上这些建议对于非投诉类Case的处理一样适用。
1518
1519 === ===
1520
1521 === **1.2.1用心聆听** ===
1522
1523 聆听是一门艺术，从中你可以发现客户的真正需求，从而获得处理投诉的重要信息。
1524
1525 === ===
1526
1527 === **1.2.2表示道歉** ===
1528
1529 如果你没有出错，就没有理由惊慌，如你真的出错，就得勇于面对。请记住客户之所以动气是因遇上问题，你漠不关心或据理力争。找借口或拒绝，只会使对方火上加油，适时的表示歉意会起到意想不到的效果。
1530
1531 === ===
1532
1533 === **1.2.3仔细询问** ===
1534
1535 引导用户说出问题重点，有的放矢。表示同情如果对方知道你的确关心他的问题，也了解他的心情，怒气便会消减一半。找出双方一起同意的观点，表明你是理解他的。
1536
1537 === ===
1538
1539 === **1.2.4记录问题** ===
1540
1541 对于投诉类的问题，必须忠实详尽的记录投诉者、投诉的原因、被投诉者、内容、处理过程、解决情况等信息。
1542
1543 === ===
1544
1545 === **1.2.5解决问题** ===
1546
1547 探询客户希望解决的办法，一旦你找出方法，征求客户的同意。如果客户不接受你的办法，请问他有什么提议或希望解决的方法，不论你是否有权决定，让客户随时清楚地了解你的进程。如果你无法解决，可推荐其他合适的人，但要主动地代为联络。礼貌地结束。当你将这件不愉快的事情解决了之后，必须问：请问您觉得这样处理可以了吗？您还有别的问题吗？……。如果没有，就多谢对方提出的问题。
1548
1549
1550 == **1.3培训制度** ==
1551
1552 培训是服务台服务的重要成功因素。若没有适当的初期和持续培训，服务台将不能提供最佳的客户服务。持续培训可以使服务台人员掌握所需技能。它也可以提高生产力，改善客户服务，此外还能增加服务台人员的工作满意程度，自信心。
1553
1554 |**种类**|**机制**|**内容**|**培训者**
1555 |上岗培训|上岗前培训，每名服务台人员必须接受至少一次上岗培训|(((
1556 ITIL基础理论
1557
1558 服务台的概况和职能
1559
1560 运行管理规范
1561
1562 ITSM系统软件使用
1563
1564 一周观摩学习
1565 )))|(((
1566 服务台经理
1567
1568 服务台资深员工
1569
1570 专业培训人员
1571 )))
1572 |进阶培训|进阶培训的主要目的是提高服务台人员的工作效率和工作热情，内容主要是工作经验的分享和技巧的传授，不定期开展。|(((
1573 工作总结
1574
1575 经验教训总结
1576
1577 典型案例分享
1578
1579 新技巧传授
1580 )))|(((
1581 服务台经理
1582
1583 服务台资深员工
1584 )))
1585 |专业技能培训|由服务台经理协调二线支持团队不定期进行专业技能的培训。目的为提高服务台人员的工作能力，并提高一线解决率。|(((
1586 终端维护技能
1587
1588 ITSM系统软件使用
1589
1590 各系统常见故障处理等
1591 )))|二线支持团队
1592 |日常培训|即为传统意义上的“传帮带”|服务台日常工作熟练|服务台资深员工
1593
1594
深圳市艾拓先锋企业管理咨询有限公司