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