由 superadmin 于 2024/10/29, 10:10 最后修改
Show last authors
1 = **1. 文档介绍** =
2
3 《服务台及事件管理流程设计》是在对IT维护管理流程进行现状评估后，结合实际情况， 共同制定的服务台建设及事件管理的流程设计文档。通过制定该设计文档，可以帮助信息中心通过建立一个综合的服务台和梯队式的IT服务架构，重新组织原有的IT运维管理工作，有效地解决IT环境的突发事件，提高IT系统和服务的质量，并为信息中心今后进一步完善事件管理提供指南。
4
5 == ==
6
7 == **1.1. 文档范围** ==
8
9 本文档描述了信息中心IT服务管理活动中服务台和事件管理流程的设计。
10
11 服务台的设计内容包括服务台的组织建设建议，担当职能以及相关流程定义，同时包括与事件管理活动集成的接口。
12
13 事件管理的流程设计部分，内容包括在信息中心实现事件管理控制的相关流程定义和部分平台实现时的代码设计。
14
15 == ==
16
17 == **1.2.文档用途** ==
18
19 本文档一方面作为本次ITSM项目的事件管理流程设计的交付物，另一方面也可作为进一步优化服务台，突发事件管理流程的蓝本，读者对象为与事件管理流程相关的所有技术与管理人员。
20
21 本文档所描述的流程在IT服务管理中有许多作用，例举如下：
22
23 1. 减小突发事件对业务的影响
24 1. 最优化支持资源，提高工作效率
25 1. 根据业务轻重缓急解决事件，保障有效IT运营
26 1. 加强有形监控和及时反馈
27 1. 提升用户满意度
28 1. 提供管理信息
29
30 == ==
31
32 == **1.3. 文档结构** ==
33
34 文档内容具体如下：
35
36 * 第一章 文档介绍
37
38 对文档目的和内容进行简单介绍，同时描述文档中用到的ITIL中的术语。
39
40 * 第二章 IT管理模式
41
42 讨论在华星光电IT信息中心现有基础上应该建立一个什么样的IT管理模式，以适应IT服务管理的要求。
43
44 * 第三章 服务台建设建议
45
46 分析管理模式中的核心工具－－服务台――的组建原则，人员、工具要求，角色职责以及衡量标准。
47
48 * 第四章 服务台用户交互管理流程设计
49
50 描述服务台用户交互流程设计内容，如：具体流程、流程代码等。
51
52 * 第五章 事件管理流程概述
53
54 简单描述事件流程，明确设计目的、范围、内容以及流程政策等。
55
56 * 第六章 事件管理流程设计
57
58 描述事件流程设计内容，如：具体流程、流程代码等。
59
60 * 第七章 事件管理流程设计
61
62 描述与服务台，突发事件流程相关的报表定义。
63
64
65 == **1.4. ITIL相关术语** ==
66
67 下面是ITIL中相关的术语：
68
69 * 帮助台：即Help Desk
70
71 在ITSM中， 帮助台从根本上来说是提供了用户和IT部门的唯一接口。帮助台是面向突发事件的支持机构，其根本目的是管理、协调并尽快解决突发事件。
72
73 * 服务台：即ServiceDesk
74
75 服务台是更广义上的IT服务管理支持工具，它不仅包含帮助台功能（支持事件管理流程），同时也提供与其它流程的接口。
76
77 * 事件管理：即 Incident Management
78
79 是负责处理所有导致IT服务中断或服务质量下降的事件和用户请求的运维流程。它的目的是尽快恢复被中断或受到影响的IT服务，而不在于查找根本原因。
80
81 * 问题管理：即Problem Management
82
83 是负责解决重大紧急事件或具有相同特征的一组事件的运维流程。它的目的是找出产生这些事件的根本原因，并通过永久性解决方案防止类似事件的再次发生，同时问题管理流程也通过主动式管理降低事件发生的数量。
84
85 * 配置管理：即Configuration Management
86
87 是负责描述、跟踪和汇报所有IT基础架构中的每一个设备或系统的信息的运维流程。这些设备和系统被称为配置元素(CI) 。每一个CI必须有效管理、跟踪和控制以支持IT服务和基础设施正常运行。
88
89 * 配置管理数据库（CMDB）：即Configuration Management Database
90
91 是配置管理流程中用于记录企业所有IT相关配置元素及其相互关系信息的数据库。
92
93 * 变更管理：即Change Management
94
95 是负责控制和管理IT相关的变更的运维流程。它的目的是使变更可能将对生产环境产生的影响和风险降到最小，从而提高IT环境的整体稳定性。
96
97 * ITIL：即IT Infrastructure Library
98
99 是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT服务管理标准，惠普的ITSM管理思想是以此为核心基础的。
100
101 服务流程的总体构架和互相之间的关系如下：
102
103 (% style="text-align:center" %)
104 [[image:1730091617324-254.png]]
105
106
107 = **2. IT管理模式（运维模式）** =
108
109
110 通过对信息中心业务和IT现状的调研和分析，我们发现，目前运维部门的运维工作主要集中在以下一些方面：
111
112 * 突发事件和请求
113 包括故障申告和各种客户申请活动，此类活动的特点是，随机产生，有发起者，对处理时间和信息反馈有要求，处理不当容易影响业务质量或客户满意度下降。
114 * 日常维护工作
115 定期或有计划的系统维护工作，如系统备份、磁盘空间维护、日志检查等，此类活动的特点是定期进行，无发起者，对业务质量或客户满意度无影响。
116 * 不定期的维护工作
117 包括各种维护规范、规划、策略的制定。此类活动的特点是，不定期进行，有发起者（通常是部门领导），活动周期较长，对业务质量或客户满意度无太大影响，但对运维管理工作产生一定的影响。
118
119 基于以上分析，我们建议华星光电IT信息中心采用以服务台为中心的IT管理组织模式，并且建立梯队式的技术支持与服务团队，在整合服务资源的同时，建立规范的管理流程和方法，以满足从传统的IT运维管理方式向IT服务管理方式转变的需要。
120
121
122 由于服务台与事件管理流程的关联最为紧密，服务台的建设将在本设计文档中与事件管理流程一起讨论。
123
124 = =
125
126 = =
127
128 = **3. 服务台建设建议** =
129
130 == **3.1. 什么是服务台** ==
131
132 服务台（Service Desk）在服务支持中扮演着一个极为重要的角色。完整意义上的服务台可以理解为其它IT部门和服务流程的“前台”，它可以在不需要联系特定技术人员的情况下处理大量的客户请求。对客户而言，服务台是他们与IT部门的唯一联络点，确保他们找到帮助其解决问题和请求的相关人员。
133
134 服务台有时也被称作“帮助台”（Help Desk），但这两个概念的意义并不完全一样。帮助台的主要任务是记录、解决和监控IT服务运作过程中产生的问题，主要和事故管理相关联。而服务台的概念则具有更广泛的内涵，它通过提供一个集中和专职的服务联络点促进了组织业务流程与服务管理基础架构的集成。
135
136 == ==
137
138 == **3.2. 服务台使命** ==
139
140 服务台只是一项服务管理职能，因此，与其他服务管理流程不同，它没有严格有序的日常运作流程，而只是针对用户的请求或根据服务级别协议的要求进行一些日常运作活动。这些日常运作活动包括响应用户呼叫、为用户发布信息、客户需求管理和客户关系管理、日常运维管理、基础架构监控等：
141
142 * 响应用户呼叫
143
144 即对于用户发出的故障申告、服务请求、变更请求等事件进行记录和处理。这是服务台最主要的工作。
145
146 * 为用户发布信息
147
148 服务台是为用户提供IT服务信息的主要来源，一般可以采用布告栏、电子邮件、屏幕消息等方式为用户提供有关故障信息、故障或新增服务等方面的信息；
149
150 * 客户需求管理和客户关系管理
151
152 服务台不仅仅是客户请求响应中心，同时也是客户关系管理中心。因此服务提供方应采取必要的措施和使用适当的技术对服务台进行有效的管理，从而使服务台可以准确迅速的了解客户需求，改善客户体验，提高客户满意度。这些措施和技术包括结构化询问技术、详细了解客户和跟踪客户、维护客户数据库和在客户中推广服务台等；
153
154 * 日常维护管理
155
156 服务台可承载日常运作管理任务，包括数据备份与恢复、磁盘空间管理、用户口令管理等；
157
158 * 基础架构监控
159
160 利用相关工具对IT基础架构的运作情况进行监控，一旦检测到故障已经发生或即将发生，就应该立即评估这种故障对关键设备可能产生的影响，并在必要时将检测到的故障报告事故管理流程。
161
162 作为事件管理的有效实现手段，服务台是一种基于日志管理来记录事件并为业务（内部或外部）提供日常支持的服务平台；同时，它通过对流程，文档和岗位责任制的管理协调，来达到尽快解决事件的目的。它专注于处理出现在信息系统中或由用户报告的事件来尽快恢复服务的可用性，并管理和维系最终用户和服务提供者之间的日常服务接口。
163
164 == ==
165
166 == **3.3. 服务台角色与职责** ==
167
168 === **3.3.1. 角色和职责** ===
169
170 服务台主要提供帮助台和一线职责，其职责可包括：
171
172 * 一线支持与客户协调
173 * 记录，跟踪服务事件
174 * 事件进展的沟通（内，外）
175 * 事件影响的评估
176 * 分派，协调，升级事件
177 * 管理服务请求
178 * 客户/用户信息发布
179 * 沟通变更计划
180 * 提供管理信息
181
182 根据信息中心实际情况并结合ITIL，定义如下角色：
183
184 * 服务台经理
185 * 服务台人员
186
187 ==== ====
188
189 ==== **3.3.1.1. 服务台经理** ====
190
191 职责：
192
193 * 确保服务台人员以良好专业知识和服务态度发挥服务台作用，提高用户的满意度。
194 * 负责管理服务台团队，监控和统计服务台的工作量和服务质量
195 * 协调和分配服务台人员日常工作，人员培训和能力建设
196 * 安排服务台值班人员
197 * 负责用户投诉的处理
198 * 配合事件，问题，变更，服务级别等流程经理的工作
199 * 制作管理报表
200
201 主要技能：
202
203 * 较强的口头表达能力和与客户沟通技巧
204 * 处理纠纷的能力
205 * 较强的领导能力
206 * 深刻了解服务台职能和其他IT服务管理流程
207 * 较强的组织和协调能力
208 * 具备一定企业管理知识
209
210 ==== ====
211
212 ==== **3.3.1.2. 服务台人员** ====
213
214 职责：
215
216 * 通过与用户联系来注册交互。
217 * 将用户交互与突发事件、问题、已知错误或知识文档相匹配。
218 * 解决和关闭交互。
219 * 请求时向用户提供状态更新。
220 * 根据用户交互注册突发事件并将其分配到正确的支持组。
221 * 验证支持组提供的解决方案。
222 * 向用户报告解决方案并对其进行验证。
223 * 监控所有注册突发事件的服务级别协议 (SLA) 目标，并在必要时升级至突发事件分析员。
224 * 向所有用户通报服务中断的消息。
225
226 主要技能：
227
228 * 了解技术平台和技术环境
229 * 熟悉事件处理流程和服务台的职责
230 * 熟悉事件分类和每类派发人员
231 * 快速诊断事件和分类事件的能力
232 * 较强的人际沟通能力
233 * 较强的提问和倾听能力
234 * 良好的电话使用技巧
235 * 较强的记录技巧
236
237 == ==
238
239 == **3.4. 服务台组建原则** ==
240
241 在组建服务台时，员工数量及类型决定于
242
243 * 服务的期望
244 * IT架构的复杂程度
245 * 客户的数量，电脑使用技能，以及客户的多样性
246 * 事件的数量和紧急程度
247 * 事件的时间分布形态
248 * 服务级别协议/承诺
249 * 已有的人员技能， 流程以及工具
250
251 服务台人员结构应在实际使用过程中动态调整，此原则同样适用于今后服务台发展过程中对人员结构的考察
252
253 == ==
254
255 == **3.5. 服务台衡量标准** ==
256
257 对于服务台服务工作的质量和绩效可以从以下指标考察：
258
259 * 电话接听率，接听电话的总量/ 用户拨入电话的总量 (需要其他设备记录拨入的电话数)
260 * 用户在线等待时间
261 * 问题解决率 ，热线支持工程师在线解决的问题/ 总共接听的问题
262
263 * 用户满意度
264
265 还可以包括的一些指标包括：
266
267 * 电话的记录比率(需要其他设备记录拨入的电话数)
268 * 分配给突发事件分析员的服务请求
269 * 服务台接到的服务请求总数
270 * 优先级为最高的服务请求数量
271 * 结束的服务请求 (按照关闭代码分类)
272 * 超过解决期限x天仍未解决的服务请求
273 * 按服务呼叫类别统计的呼叫总数
274 * 事件平均解决时间（按优先级分类）
275
276 == ==
277
278 == **3.6. 服务台工具的功能** ==
279
280 服务台的功能可能由一个或一组工具来实现，在使用工具实现服务台时应考虑以下方面的内容:
281
282 === ===
283
284 === **3.6.1. 呼叫管理** ===
285
286 在服务台电话呼叫量大，人员多的情况下（比如人均每月的电话量超过200个电话），可以考虑使用电话自动分配系统 (ACD) ， 以达到：平衡电话分配，提供电话性能报告（如电话放弃比例，电话时长等），提供呼叫队列 状态信息的目的。
287
288 === ===
289
290 === **3.6.2. 知识管理** ===
291
292 通过提供知识库，能够在服务台、突发事件分析员、系统管理员及最终用户间共享一些解决问题的关键信息，这些信息可以是一些临时的解决方案，脚本，补丁的参考信息，常见问题及答案等，并且能够按标题，现象等灵活查询。
293
294 === ===
295
296 === **3.6.3. 事件处理流程支持** ===
297
298 事件处理流程是服务台支持的流程，它承接呼叫管理流程，完成新的服务请求或突发事件的处理。事件处理的工具需提供接受，跟踪和控制事件的界面，这就需要工具具备整合的事件/服务请求管理，配置管理， 服务级别管理的能力，应能做到：
299
300 * 对授权的用户可以访问到相应权限范围内的事件；
301 * 可以记录事件的状态；
302 * 可以记录事件的结果；
303 * 可以提供一系列的事件状态报告， 如按照事件类别，状态等
304
305 === ===
306
307 === **3.6.4. 客户沟通管理** ===
308
309 与最终用户的沟通确认是一个很有价值的主动服务手段。它可以减少服务呼叫数量，降低服务台的工作量，节省人力。如果系统能自动为用户提供事件的状态，会大大改善服务台与用户之间的沟通。
310
311 === ===
312
313 === **3.6.5. 与监控管理工具集成 ** ===
314
315 服务台的事件管理工具提供与运营管理的监控工具集成的能力。
316
317 监控工具可以将告警事件自动输入到事件管理工具，并生成一个事件编号，自动的事件录入过程对事件管理工具有些隐含的要求：当服务台收到告警事件，需对其进行类别划分，优先级划分以及分派给合适的工作组，同时，要认定受影响的系统服务以及通过对配置管理数据库的搜索找出相关的配置项目；服务台坐席通过队列监控自动录入的事件管理系统；当事件被坐席关闭时， 最好能在监控系统中同时关闭事件。
318
319 由于网络监控工具日常发现的告警的数量较大， 为了保证服务台以及一线处理人员的工作效率， 需要 对监控工具转发到ITIL流程平台的告警进行精细的过滤。
320
321 = =
322
323 = =
324
325 = **4. 服务台用户交互流程设计** =
326
327 用户每次联系服务台都被记录为一次交互。用户交互管理是一个流程，用于处理用户与服务台的所有交互，这些交互通过邮件接收或直接通过服务台人员报告。交互类型可以包括用户报告的服务中断、服务请求、信息请求 (RFI) 或投诉。通过用户交互管理流程，可以轻松记录和解决简单的用户请求，并将其他请求升级为需要进一步操作的突发事件。
328
329 可以将多个用户交互链接到工具中的一个突发事件记录单。用户交互管理描述了注册新突发事件或变更时服务台需要执行的所有活动。服务台人员会执行必要的步骤并搜索相关知识记录、已知错误记录和现有突发事件或变更。
330
331 此流程简化了服务台活动，因此可以减少突发事件分析员的工作量。
332
333
334 == **4.1. 流程代码定义** ==
335
336 流程代码是服务台交互、事件管理流程不可或缺的一部分，是对服务台交互、事件管理流程关键环节的详细描述的必要准备。本章节将详细描述：信息项、分类、影响度、优先级、状态、关闭等代码，这些内容将在流程的具体描述中使用。
337
338 === ===
339
340 === **4.1.1. 信息项** ===
341
342 信息项定义的是交互、事件管理流程需要的所有信息项，主要如下
343
344 |**代码**|**描述**
345 |ID|工单号，自动生成
346 |联系人信息|本次事件报告人的联络信息，厂别
347 |受理人|自动设为登记该事件的操作员
348 |实际开始时间|在服务台生成事件记录的时间，系统自动记录
349 |实际结束时间|在服务台事件关闭的时间，系统自动记录
350 |最终期限|在事件开始处理前约定的最终解决时间
351 |描述|对于整个事件内容的详细描述
352 |状态|事件的状态
353 |类别|从事件所属性质的角度来确定其处理流程，是突发事件，还是服务请求
354 |领域|从事件所属的系统或架构来进行分类
355 |子领域|从事件从属的系统或技术架构的技术类型类型来进行分类，相对于区域
356 |服务名|发生问题所归属的服务
357 |配置项|故障对象的标识
358 |地点|事件发生地点
359 |影响范围|故障影响的范围
360 |紧急程度|故障需要处理的紧急程度
361 |优先级|事件优先级决定了事件的解决时限和处理次序
362 |分配对象|分配组和分配人员
363 |解决方案描述|事件解决方案的描述
364 |结束代码|根据事件结束的不同方式赋予不同的结束代码
365 |活动日志|反映事件处理过程中的事件处理信息，包括人员，时间等信息
366 |初步问题原因|关闭突发事件时已知的初步原因
367 |问题管理备选项|该事件作为问题管理的备选项
368
369 === ===
370
371 === **4.1.2. 类别代码** ===
372
373 根据的业务要求和管理要求，定义如下四种类型：
374
375 |**序号**|**代码**|**描述**
376 |1|突发事件|事件
377 |2|服务请求|服务请求,如:更改密码等
378 |3|投诉与建议|客户投诉
379 |4|变更请求|请求变更
380
381 === ===
382
383 === **4.1.3. 领域，子领域** ===
384
385 根据信息中心业务系统架构的事件，服务请求，投诉种类，故障比进一步划分为领域，子领域。领域和子领域的划分采用信息中心现有的分类：
386
387 CIM:
388
389 |**类型**|**领域**|**子领域**|**说明**
390 |(% rowspan="7" %)突发事件|(% rowspan="7" %)CIM|AUTO|含设备问题
391 |MES|
392 |Report|
393 |CFM|
394 |OEE|
395 |DEA|
396 |SPC|
397 |(% rowspan="7" %)服务请求|(% rowspan="7" %)CIM|AUTO|含设备问题
398 |MES|
399 |Report|
400 |CFM|
401 |OEE|
402 |DEA|
403 |SPC|
404 |(% rowspan="7" %)投诉与建议|(% rowspan="7" %)CIM|AUTO|含设备问题
405 |MES|
406 |Report|
407 |CFM|
408 |OEE|
409 |DEA|
410 |SPC|
411
412 Planning:
413
414 |**类型**|(% style="width:324px" %)**领域**|(% style="width:449px" %)**子领域**|**备注**
415 |(% rowspan="45" %)突发事件|(% rowspan="5" style="width:324px" %)VDI|(% style="width:449px" %)桌面系统问题|
416 |(% style="width:449px" %)应用程序问题|
417 |(% style="width:449px" %)客户端问题|
418 |(% style="width:449px" %)服务器端问题|
419 |(% style="width:449px" %)其它问题|
420 |(% rowspan="4" style="width:324px" %)OA|(% style="width:449px" %)访问问题|
421 |(% style="width:449px" %)流程创建审批查阅问题|
422 |(% style="width:449px" %)信息更新问题|
423 |(% style="width:449px" %)其它问题|
424 |(% rowspan="4" style="width:324px" %)Email|(% style="width:449px" %)outlook客户端问题|
425 |(% style="width:449px" %)exchange服务器端问题|
426 |(% style="width:449px" %)权限问题|
427 |(% style="width:449px" %)其它问题|
428 |(% rowspan="5" style="width:324px" %)网络|(% style="width:449px" %)外网问题|
429 |(% style="width:449px" %)内网问题|
430 |(% style="width:449px" %)权限问题|
431 |(% style="width:449px" %)物理设备问题|
432 |(% style="width:449px" %)其它问题|
433 |(% rowspan="4" style="width:324px" %)共享目录|(% style="width:449px" %)容量问题|
434 |(% style="width:449px" %)权限问题|
435 |(% style="width:449px" %)文件还原问题|
436 |(% style="width:449px" %)其它问题|
437 |(% rowspan="3" style="width:324px" %)电话系统|(% style="width:449px" %)号码开通删除问题|
438 |(% style="width:449px" %)电话相关物理设备问题|
439 |(% style="width:449px" %)其它问题|
440 |(% rowspan="3" style="width:324px" %)PC及NB|(% style="width:449px" %)系统问题|
441 |(% style="width:449px" %)应用程序问题|
442 |(% style="width:449px" %)硬件问题|
443 |(% rowspan="3" style="width:324px" %)外设|(% style="width:449px" %)服务器端问题|
444 |(% style="width:449px" %)设备|
445 |(% style="width:449px" %)网络|
446 |(% rowspan="3" style="width:324px" %)KVM|(% style="width:449px" %)转换流畅问题|
447 |(% style="width:449px" %)硬件问题|
448 |(% style="width:449px" %)其它问题|
449 |(% rowspan="3" style="width:324px" %)AD|(% style="width:449px" %)退域|
450 |(% style="width:449px" %)加域|
451 |(% style="width:449px" %)其它问题|
452 |(% rowspan="3" style="width:324px" %)病毒|(% style="width:449px" %)客户端问题|
453 |(% style="width:449px" %)服务器端问题|
454 |(% style="width:449px" %)其它问题|
455 |(% style="width:324px" %)SSO|(% style="width:449px" %)NA|值班员接触不到
456 |(% style="width:324px" %)Window Server|(% style="width:449px" %)NA|值班员接触不到
457 |(% style="width:324px" %)UNIX|(% style="width:449px" %)NA|值班员接触不到
458 |(% style="width:324px" %)数据库|(% style="width:449px" %)NA|值班员接触不到
459 |(% style="width:324px" %)Storage|(% style="width:449px" %)NA|值班员接触不到
460 |(% rowspan="45" %)服务请求|(% rowspan="5" style="width:324px" %)VDI|(% style="width:449px" %)桌面系统问题|
461 |(% style="width:449px" %)应用程序问题|
462 |(% style="width:449px" %)客户端问题|
463 |(% style="width:449px" %)服务器端问题|
464 |(% style="width:449px" %)其它问题|
465 |(% rowspan="4" style="width:324px" %)OA|(% style="width:449px" %)访问问题|
466 |(% style="width:449px" %)流程创建审批查阅问题|
467 |(% style="width:449px" %)信息更新问题|
468 |(% style="width:449px" %)其它问题|
469 |(% rowspan="4" style="width:324px" %)Email|(% style="width:449px" %)outlook客户端问题|
470 |(% style="width:449px" %)exchange服务器端问题|
471 |(% style="width:449px" %)权限问题|
472 |(% style="width:449px" %)其它问题|
473 |(% rowspan="5" style="width:324px" %)网络|(% style="width:449px" %)外网问题|
474 |(% style="width:449px" %)内网问题|
475 |(% style="width:449px" %)权限问题|
476 |(% style="width:449px" %)物理设备问题|
477 |(% style="width:449px" %)其它问题|
478 |(% rowspan="4" style="width:324px" %)共享目录|(% style="width:449px" %)容量问题|
479 |(% style="width:449px" %)权限问题|
480 |(% style="width:449px" %)文件还原问题|
481 |(% style="width:449px" %)其它问题|
482 |(% rowspan="3" style="width:324px" %)电话系统|(% style="width:449px" %)号码开通删除问题|
483 |(% style="width:449px" %)电话相关物理设备问题|
484 |(% style="width:449px" %)其它问题|
485 |(% rowspan="3" style="width:324px" %)PC及NB|(% style="width:449px" %)系统问题|
486 |(% style="width:449px" %)应用程序问题|
487 |(% style="width:449px" %)硬件问题|
488 |(% rowspan="3" style="width:324px" %)外设|(% style="width:449px" %)服务器端问题|
489 |(% style="width:449px" %)设备|
490 |(% style="width:449px" %)网络|
491 |(% rowspan="3" style="width:324px" %)KVM|(% style="width:449px" %)转换流畅问题|
492 |(% style="width:449px" %)硬件问题|
493 |(% style="width:449px" %)其它问题|
494 |(% rowspan="3" style="width:324px" %)AD|(% style="width:449px" %)退域|
495 |(% style="width:449px" %)加域|
496 |(% style="width:449px" %)其它问题|
497 |(% rowspan="3" style="width:324px" %)病毒|(% style="width:449px" %)客户端问题|
498 |(% style="width:449px" %)服务器端问题|
499 |(% style="width:449px" %)其它问题|
500 |(% style="width:324px" %)SSO|(% style="width:449px" %)NA|值班员接触不到
501 |(% style="width:324px" %)Window Server|(% style="width:449px" %)NA|值班员接触不到
502 |(% style="width:324px" %)UNIX|(% style="width:449px" %)NA|值班员接触不到
503 |(% style="width:324px" %)数据库|(% style="width:449px" %)NA|值班员接触不到
504 |(% style="width:324px" %)Storage|(% style="width:449px" %)NA|值班员接触不到
505 |(% rowspan="45" %)投诉与建议|(% rowspan="5" style="width:324px" %)VDI|(% style="width:449px" %)桌面系统问题|
506 |(% style="width:449px" %)应用程序问题|
507 |(% style="width:449px" %)客户端问题|
508 |(% style="width:449px" %)服务器端问题|
509 |(% style="width:449px" %)其它问题|
510 |(% rowspan="4" style="width:324px" %)OA|(% style="width:449px" %)访问问题|
511 |(% style="width:449px" %)流程创建审批查阅问题|
512 |(% style="width:449px" %)信息更新问题|
513 |(% style="width:449px" %)其它问题|
514 |(% rowspan="4" style="width:324px" %)Email|(% style="width:449px" %)outlook客户端问题|
515 |(% style="width:449px" %)exchange服务器端问题|
516 |(% style="width:449px" %)权限问题|
517 |(% style="width:449px" %)其它问题|
518 |(% rowspan="5" style="width:324px" %)网络|(% style="width:449px" %)外网问题|
519 |(% style="width:449px" %)内网问题|
520 |(% style="width:449px" %)权限问题|
521 |(% style="width:449px" %)物理设备问题|
522 |(% style="width:449px" %)其它问题|
523 |(% rowspan="4" style="width:324px" %)共享目录|(% style="width:449px" %)容量问题|
524 |(% style="width:449px" %)权限问题|
525 |(% style="width:449px" %)文件还原问题|
526 |(% style="width:449px" %)其它问题|
527 |(% rowspan="3" style="width:324px" %)电话系统|(% style="width:449px" %)号码开通删除问题|
528 |(% style="width:449px" %)电话相关物理设备问题|
529 |(% style="width:449px" %)其它问题|
530 |(% rowspan="3" style="width:324px" %)PC及NB|(% style="width:449px" %)系统问题|
531 |(% style="width:449px" %)应用程序问题|
532 |(% style="width:449px" %)硬件问题|
533 |(% rowspan="3" style="width:324px" %)外设|(% style="width:449px" %)服务器端问题|
534 |(% style="width:449px" %)设备|
535 |(% style="width:449px" %)网络|
536 |(% rowspan="3" style="width:324px" %)KVM|(% style="width:449px" %)转换流畅问题|
537 |(% style="width:449px" %)硬件问题|
538 |(% style="width:449px" %)其它问题|
539 |(% rowspan="3" style="width:324px" %)AD|(% style="width:449px" %)退域|
540 |(% style="width:449px" %)加域|
541 |(% style="width:449px" %)其它问题|
542 |(% rowspan="3" style="width:324px" %)病毒|(% style="width:449px" %)客户端问题|
543 |(% style="width:449px" %)服务器端问题|
544 |(% style="width:449px" %)其它问题|
545 |(% style="width:324px" %)SSO|(% style="width:449px" %)NA|值班员接触不到
546 |(% style="width:324px" %)Window Server|(% style="width:449px" %)NA|值班员接触不到
547 |(% style="width:324px" %)UNIX|(% style="width:449px" %)NA|值班员接触不到
548 |(% style="width:324px" %)数据库|(% style="width:449px" %)NA|值班员接触不到
549 |(% style="width:324px" %)Storage|(% style="width:449px" %)NA|值班员接触不到
550
551 === ===
552
553 === **4.1.4. 影响范围代码** ===
554
555 影响范围用于衡量事件所影响业务的范围。影响范围通常通过所影响的人数、关键系统数以及服务故障所造成的损失来设定。
556
557 定义事件影响度等级的因素有：
558
559 * 是否影响了关键应用
560 * 所影响的用户范围
561 * 服务失效的影响范围
562
563 下表是当前定义的影响度，后续可根据实际变化进行调整。
564
565 |序号|代码|描述
566 |1| 公司|影响范围为全公司
567 |2| 生产厂|影响范围为一个或多个厂
568 |3| 产线|影响范围为一条或多条生产线
569 |4| 个人|影响范围为一个或多个个人
570
571 === ===
572
573 === **4.1.5. 紧急程度代码** ===
574
575 紧急程度决定事件需要处理的急迫程度。
576
577 |序号|代码|描述
578 |1|十分紧急|需要马上处理
579 |2|紧急|需要2小时之内处理
580 |3|一般|需要24小时之内处理
581 |4|低|处理时间可以超过24小时
582
583 === ===
584
585 === **4.1.6. 优先级代码** ===
586
587 优先级(Priority)决定了处理次序和期限。 期限可以在运行的过程中适当的调整，并且主要目的是通过升级的机制，让高层领导及时的了解在IT运维过程中发生的问题。优先级根据事件的影响度和事件的紧急度代码计算决定。算法为：优先级=[(影响范围+紧急程度)/2]. “[]”表示取整。
588
589 |**序号**|**代码**|**描述**
590 |1|一级|重大故障处理的优先级，用于严重影响业务应用的事故处理
591 |2|二级|特殊服务事件的处理，用于紧急服务事件的处理
592 |3|三级|一般故障处理的优先级，用于中等业务影响度的服务
593 |4|四级|故障处理中最低的优先级，一般用于业务影响度低的服务，有时需要预约时间
594
595 === ===
596
597 === **4.1.7. 状态代码 ** ===
598
599 状态代码表明事件所处的处理状态。
600
601 缺省的状态如下：
602
603 |**流程/功能**|**状态**|**说明**
604 |(% rowspan="8" %)突发事件|已登记|突发事件登记后缺省状态
605 |已分配|事件分配给了处理人员
606 |已接受|被分配人接受了分配任务
607 |已拒绝|被分配人拒绝了分配任务.
608 |工作中|被分配人正在处理
609 |已挂起|挂起等待客户信息，变更，厂商支持等.
610 |已解决|已经解决，请求服务台与客户确认
611 |已关闭|客户确认后关闭.
612 |(% rowspan="4" %)服务台|已登记|交互单登记后的缺省状态
613 |已升级|升级给了突发事件分析员
614 |等待确认|等待客户确认解决方案
615 |关闭|客户确认后关闭.
616
617 注意：以上各个状态是对整个事件管理流程中可能的状态的总结，一个具体事件处理过程中，可能只是经过其中的几个状态。
618
619 === ===
620
621 === **4.1.8. 关闭代码** ===
622
623 关闭代码说明了事件是在何种情况下关闭的。
624
625 结合信息中心的实际，将采用如下关闭代码：
626
627 |**序号**|**代码**|**描述**
628 |1|超出范围|超出了信息中心支持范围
629 |2|不能解决|现有条件无法解决，与客户解释后关闭
630 |3|使用变通方法解决|通过临时措施解决
631 |4|通过变更解决|发现了根本原因，通过变更解决
632 |5|用户放弃|用户放弃
633 |6|无法重现|无法重现客户报告的故障，与客户解释后同意关闭
634
635 == ==
636
637 == **4.2. 服务台用户交互概要设计** ==
638
639 服务台用户交互概要流程是根据华星光电IT信息中心的具体情况，结合HP ITSM的最佳经验，并通过与IT信息中心人员的共同讨论最终确定的。服务台用户交互概要流程主要从整体上描述用户交互的处理过程，不会体现具体的细节和涵盖所有的人员，但能够体现当前可能的输入和输出。
640
641
642 === **4.2.1. 流程图例说明** ===
643
644 根据流程设计要求， 我们将服务台用户交互管理流程的设计标号以SO0开头，比如SO1.X.X。SO是Service Operation的缩写。
645
646 === ===
647
648 === **4.2.2. 概要流程描述** ===
649
650 IT信息中心服务台用户交互管理概要流程具体如下：
651
652 (% style="text-align:center" %)
653 [[image:1730166821053-186.png]]
654
655
656 描述如下：
657
658 |**序号**|(% style="width:126px" %)**步骤名称**|(% style="width:107px" %)**责任人**|(% style="width:1043px" %)**流程描述**
659 |SO1.1|(% style="width:126px" %)用户自助服务|(% style="width:107px" %)用户|(% style="width:1043px" %)用户通过使用Web 页面，注册交互或查询状态，。由于成熟度的关系，当前，自助服务可能对用户是一种比较困难的工作如选择类别等，需要在下期再实施
660 |SO1.2|(% style="width:126px" %) 处理用户交互|(% style="width:107px" %)服务台人员|(% style="width:1043px" %)服务台负责处理通过自助服务 Web 入口、电子邮件或电话收到的所有用户交互。服务台尝试在用户首次联系服务台时解决交互。用户交互处理包括交互的注册和增强，其中包括匹配打开的突发事件、问题、已知错误和知识库，以最大化一线解决率。如果服务台不能在首次联系时关闭交互，则会将其升级到突发事件管理、变更管理、请求执行过程。
661 |SO1.3|(% style="width:126px" %)关闭交互|(% style="width:107px" %)服务台人员|(% style="width:1043px" %)当交互在第一次联系服务台即被服务台解决或被已解决的相关突发事件、变更或请求解决时，即会发生交互关闭流程。根据用户的偏好，服务台通过电话、电子邮件或其他方式将此解决方案传达给用户。
662
663 (% class="wikigeneratedid" %)
664 == ==
665
666 == **4.3. 服务台用户交互详细设计** ==
667
668 服务台用户交互管理流程详细设计是在概要流程设计的基础上，逐个环节细化，同时结合服务台用户交互流程代码，把整个服务台用户交互流程具体处理过程详细描述。
669
670 === ===
671
672 === **4.3.1. （SO1.1）用户自助服务** ===
673
674 用户自助服务流程环节SO1.1的细化流程如下图所示：
675
676 (% style="text-align:center" %)
677 [[image:1730166890958-158.png]]
678
679 描述如下：
680
681 |**序号**|**步骤名称**|**责任人**|**流程描述**
682 |SO1.1.1|登录到自助服务|用户|要访问自助服务 Web 界面，用户必须使用其登录凭据进行登录。
683 |SO1.1.2|记录新交互？|用户|如果是，请继续 SO1.1.3。如果不是，请转至 SO1.1.9。
684 |SO1.1.3|服务请求？|用户|如果是，请转至请求执行流程。如果不是，先查询知识库。
685 |SO1.1.4|查询知识库|用户|要搜索知识文档，用户必须完成搜索。
686 |SO1.1.5|对找到的答案是否满意？|用户|如果是，请停止。如果不是，请转至 SO1.1.6。
687 |SO1.1.6|打开新交互|用户|用户通过web提交新的交互
688 |SO1.1.7|手动完成交互详细信息|用户|要注册新交互，用户必须提供请求的描述信息，然后选择紧急程度、受影响的服务以及首选联系方式等
689 |SO1.1.8|提交交互|用户|完成所有必填字段后，用户必须单击“提交”按钮向服务台发送请求。
690 |SO1.1.9|是否要验证已解决交互的解决方案？|用户|如果用户要验证先前报告的交互的解决方案，请转至 SO1.1.10。如果不是，请转至 SO1.1.13。
691 |SO1.1.10|验证解决方案|用户|搜索自己提交的交互，查看所有已解决的交互的概述。选择相应的交互并验证所提供的解决方案。
692 |SO1.1.11|交互是否已解决？|用户|如果是，请停止。如果不是，请转至 SO1.1.12。
693 |SO1.1.12|重新提交交互并提供更新|用户|如果用户不同意建议的解决方案，则可以重新提交交互并说明不同意的原因。
694 |SO1.1.13|是否检查历史记录和未决交互？|用户|如果用户要检查先前提交的交互的状态或历史记录，请转至 SO1.1.14。如果不是，请停止。
695 |SO1.1.14|检查交互状态|用户|搜索自己提交的交互，选择交互并查看状态和上次更新。
696 |SO1.1.15|是否提供更新？|用户|如果用户要向先前记录的交互中添加其他详细信息，并且这些信息对专业技术人员很有帮助，请转至 SO1.1.16。如果不是，请停止。
697 |SO1.1.16|更新交互|用户|要向先前记录的交互中添加信息，请使用描述字段并保存所作的变更。
698
699 === ===
700
701 === **4.3.2. （SO1.2）用户交互处理** ===
702
703 用户交互处理流程环节SO1.2的细化流程如下图所示：
704
705
706 (% style="text-align:center" %)
707 [[image:图片1.jpg]]
708
709
710 描述如下：
711
712 |**序号**|**步骤名称**|(% style="width:131px" %)**责任人**|(% style="width:889px" %)**流程描述**
713 |SO1.2.1|填写用户信息|(% style="width:131px" %)服务台人员|(% style="width:889px" %)填写呼叫方姓名等。
714 |SO1.2.2|确定受影响的服务|(% style="width:131px" %)服务台人员|(% style="width:889px" %)在“受影响的服务”字段中选择与用户请求匹配的服务。
715 |SO1.2.3|是否涉及先前已注册的交互？|(% style="width:131px" %)服务台人员|(% style="width:889px" %)如果用户联系服务台询问先前已注册的交互，请转至 SO1.2.13。如果不是，请转至 SO1.2.4。
716 |SO1.2.4|应用交互模板（在适用时）|(% style="width:131px" %)服务台人员|(% style="width:889px" %)如果提供了交互模板，请应用该模板快速定义交互。如果没有提供模板，则显示默认的交互设置。
717 |SO1.2.5|按照模板说明操作|(% style="width:131px" %)服务台人员|(% style="width:889px" %)此模板中的预定义字段已填写完成，检查确认
718 |SO1.2.6|手动填写交互详细信息|(% style="width:131px" %)服务台人员|(% style="width:889px" %)填写所需的交互详细信息，如整描述、交互类型以及分类。并且选择相应的影响和紧急程度。
719 |SO1.2.7|服务请求？|(% style="width:131px" %)服务台人员|(% style="width:889px" %)如果交互涉及“服务请求”，请转至“请求执行”过程。如果不是，请转至 SO1.2.8。
720 |SO1.2.8|变更请求？|(% style="width:131px" %)服务台人员|(% style="width:889px" %)如果交互涉及“变更请求”，请转至“变更”过程。如果不是，请转至 SO1.2.9。
721 |SO1.2.9|是否与打开的突发事件相匹配？|(% style="width:131px" %)服务台人员|(% style="width:889px" %)服务台人员会根据服务和分类执行搜索以查看任何打开的与用户交互匹配的突发事件。如果是，请转至 SO1.2.18。如果不是，请转至 SO1.2.10。
722 |SO1.2.10|是否与已打开的问题/已知错误匹配？|(% style="width:131px" %)服务台人员|(% style="width:889px" %)服务台人员会根据服务和分类执行搜索，以查找任何与用户交互匹配的已打开问题或已知错误。如果是，请转至 SO1.2.20。如果不是，请转至 SO1.2.11。
723 |SO1.2.11|是否在知识库中找到解决方案？|(% style="width:131px" %)服务台人员|(% style="width:889px" %)服务台人员会根据描述执行知识库搜索。如果是，请转至 SO1.2.21。如果不是，请转至 SO1.2.12。
724 |SO1.2.12|服务台人员是否能够解决？|(% style="width:131px" %)服务台人员|(% style="width:889px" %)如果服务台人员具备充足的工具和知识解决用户交互问题，请转至 SO1.2.22。如果不是，请转至创建突发事件过程。
725 |SO1.2.13|为用户提供更新并更新现有交互|(% style="width:131px" %)服务台人员|(% style="width:889px" %)通知用户相关的最新情况，并通过陈述用户请求了更新来更新该交互。
726 |SO1.2.14|是否需要重新打开突发事件？|(% style="width:131px" %)服务台人员|(% style="width:889px" %)如果用户对提供的解决方案不满意，必须重新打开突发事件，请转至 SO1.2.15。如果不是，请转至 SO1.2.16。
727 |SO1.2.15|是否允许重新打开？|(% style="width:131px" %)服务台人员|(% style="width:889px" %)如果由于用户在收到解决方案通知后的两周内发出了请求，从而允许重新打开突发事件，请转至 SO1.2.17。如果不是，请转至 SO1.2.6。
728 |SO1.2.16|取消最新创建的交互|(% style="width:131px" %)服务台人员|(% style="width:889px" %)由于不再需要此注册，取消最新创建的交互。
729 |SO1.2.17|重新打开突发事件|(% style="width:131px" %)服务台人员|(% style="width:889px" %)通过将状态更改为“打开”并提供更新以说明重新打开突发事件的原因，重新打开先前已注册且没有正确解决的突发事件。
730 |SO1.2.18|将交互与未决突发事件相关联|(% style="width:131px" %)服务台人员|(% style="width:889px" %)将交互与打开的突发事件相关联。
731 |SO1.2.19|保存交互|(% style="width:131px" %)服务台人员|(% style="width:889px" %)将交互保存在交互数据库中并向用户提供交互编号。
732 |SO1.2.20|将交互与问题/已知错误相关联|(% style="width:131px" %)服务台人员|(% style="width:889px" %)将交互与问题或已知错误相关联。
733 |SO1.2.21|将交互与知识记录相关联|(% style="width:131px" %)服务台人员|(% style="width:889px" %)在交互单中填写对应的知识记录号，将知识库中的解决方案拷贝到解决方案字段中。
734 |SO1.2.22|记录交互中的解决方案|(% style="width:131px" %)服务台人员|(% style="width:889px" %)在“解决方案”字段中描述解决方案。
735 |SO1.2.23|实施解决方案|(% style="width:131px" %)服务台人员|(% style="width:889px" %)(((
736 执行所需操作
737 )))
738
739 (% class="wikigeneratedid" %)
740 === ===
741
742 === **4.3.3. （SO1.3）关闭交互** ===
743
744 关闭交互流程环节SO1.3的细化流程如下图所示：
745
746
747 (% style="text-align:center" %)
748 [[image:图片2.jpg]]
749
750
751 描述如下：
752
753 |**序号**|**步骤名称**|(% style="width:130px" %)**责任人**|(% style="width:945px" %)**流程描述**
754 |SO1.3.1|检查解决方案的完整性|(% style="width:130px" %)服务台人员|(% style="width:945px" %)服务台人员检查交互的解决方案。
755 |SO1.3.2|服务台人员是否接受解决方案？|(% style="width:130px" %)服务台人员|(% style="width:945px" %)如果是，请转至 SO1.3.4。如果不是，请转至 SO1.3.3。
756 |SO1.3.3|重新打开突发事件|(% style="width:130px" %) |(% style="width:945px" %)服务台人员将重新打开突发事件记录以进行深入调查和诊断。
757 |SO1.3.4|是否向用户回电？|(% style="width:130px" %)服务台人员|(% style="width:945px" %)如果用户想要通过电话得到通知，请转至 SO1.3.6，否则请转至 SO1.3.5。
758 |SO1.3.5|向用户发送电子邮件通知|(% style="width:130px" %)服务台人员|(% style="width:945px" %)用户会自动接收到交互关闭的电子邮件,用户可以检查此解决方案，并可以在两周内拒绝此解决方案。
759 |SO1.3.6|通过用户验证解决方案|(% style="width:130px" %)服务台人员|(% style="width:945px" %)服务台人员会联系用户并传达解决方案。用户应当验证此解决方案并确认已解决突发事件、已对问题或投诉作出回答或已执行服务请求。
760 |SO1.3.7|用户是否接受解决方案？|(% style="width:130px" %)服务台人员|(% style="width:945px" %)如果是，请转至 SO1.3.9。如果不是，请转至 SO1.3.8。
761 |SO1.3.8|重新打开或重新创建突发事件|(% style="width:130px" %)服务台人员|(% style="width:945px" %)提供的解决方案可能无法解决所有用户的问题。如果解决方案无法解决所有用户的问题，服务台人员必须重新打开现有突发事件或创建新的突发事件，然后关联未解决的交互。
762 |SO1.3.9|关闭交互|(% style="width:130px" %)服务台人员|(% style="width:945px" %)服务台人员关闭交互。
763
764 = =
765
766 = =
767
768 = **5. 事件管理流程概述** =
769
770 == **5.1. 什么是事件管理流程** ==
771
772 事件管理流程是负责解决IT服务的突发事件、问题和用户请求等的运维流程。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。
773
774 事件管理流程受事件触发和驱动，所谓事件，是指发生了非常规的运作情况，包括系统崩溃、软件故障、任何影响用户业务操作和系统正常运作的故障、以及影响业务流程或违背服务水平协议的情况。事件也包括一个用户的请求，如，重设用户密码。不是所有的事件都由用户产生，监控管理平台产生的告警也可引发事件。
775
776 通常由服务台负责记录事件相关信息，向用户提供对已知问题的处理方法，报告事件和尽快恢复服务，目的是在事件管理阶段获得尽可能高的事件解决率。
777
778 事件基于相关配置元素的关键等级和影响度进行优先级分类。
779
780 事件管理的责任是记录、分类、调查/诊断、解决已知问题、监控跟踪事件、与用户和问题管理流程交流、最终解决事件。
781
782 == ** ** ==
783
784 == **5.2. 流程目的** ==
785
786 事件管理流程的主要功能是尽快解决出现的事件，保持业务系统的稳定性，本期建设目的包括：
787
788 * 针对本期项目范围内的IT系统，在IT信息中心建立统一的事件管理流程
789 * 在成本允许的范围内尽快恢复服务
790 ** 快速响应服务请求（电话，监控系统，..）
791 ** 沟通问题解决的状态
792 ** 确认事件的解决和用户满意度
793 * 进行事件控制
794 ** 按规范记录事件
795 ** 就事件的优先级，紧急性和严重性进行分类
796 ** 分析，诊断，必要时进行升级
797 ** 监视并结束事件
798 ** 进行定期服务回顾
799 * 提供一个日常接口
800 ** 从一个用户面对多个服务接口，转向统一服务接口面向多用户
801 ** 提供关于服务状态的受理、信息更新等日常工作
802 * 提供IT管理信息
803 ** 人力资源利用情况
804 ** 服务故障
805 ** 支持效率
806
807 == ** ** ==
808
809 == **5.3. 管理范围** ==
810
811 IT生产环境发生的所有IT事件，包括试运行期间的IT事件，用户报告的请求、询问、置疑、报障等，同时还包括由监控系统检测发现的IT事件。它们都将由事件管理流程进行处理。
812
813 本次事件管理的范围包括所有与IT基础架构和业务相关的如下事件：
814
815 * 突发事件
816
817 来源主要是用户电话告知、IT维护人员日常检查或监控系统发现的故障。
818
819 * 服务请求
820
821 具体如：软件安装、咨询、安全事件、功能需求、等。在整个流程中对于服务请求，主要是记录和跟踪，涉及到的审批（如：帐号申请）等，不在本流程范围之内。
822
823 不包括：
824
825 * 在开发和测试环境中的设备或系统产生的事件；
826 * 周期性、计划性的日常维护工作；
827
828 == ** ** ==
829
830 == **5.4. 主要内容** ==
831
832 事件管理流程不一定必须找到问题发生的根本原因，着重于在IT信息中心快速解决IT环境中的事件，恢复已经中断的IT服务，并降低其对业务的影响度。主要活动包括记录事件、分派事件、找出解决方案和结束事件等。其流程内容如下：
833
834 * 检测和记录
835
836 事件通过IT维护人员日常检查或系统监控软件检测出来，用户打电话进来通告或直接请求，所有事件记录进系统中。
837
838 * 判断并分派
839
840 服务台初步分析，确定是事件，还是服务请求。如果是服务请求，依照服务请求处理；如不是，进行事件的影响、收集信息等，并尝试解决。如果不能解决，升级到突发事件分析员。
841
842 * 调查和诊断
843
844 突发事件分析员支持人员利用自身技能和相关工具，力图在规定的时间内提出解决方案，尝试解决事件。必要时升级给厂商或集成商（统称为三线）
845
846 * 服务台确认
847
848 对事件的解决方案进行确认，如未解决，根据情况采取相应动作，如确认被否，需继续处理，转回原事件处理支持人员;如解决，则转至关闭记录。
849
850 * 结束
851
852 如果确认已解决，关闭记录，更新文档; 必要时进行回顾。
853
854 * 定期产生报表
855
856 事件支持人员将根据管理要求定期产生相关报表。
857
858 == ** ** ==
859
860 == **5.5. 业务价值** ==
861
862 事件管理流程将在多方面对IT信息中心的IT服务产生积极作用，具体表现在：
863
864 * 提高服务可用性
865
866 不管什么原因，当用户不能使用IT提供的IT服务的时候(如咨询如何使用，设备宕机，网络过载等)，服务都是被认为不可用的，它影响了用户的生产率。事件管理流程通过保证事件和请求等的快速处理来达到服务可用性的最大化。
867
868 * 提高客户满意度
869 * 集中化事件数据
870
871 通过事件管理流程和系统来统一收集事件数据，这些数据被其他流程所使用，如问题管理流程将分析这些数据以确定事件的根本原因，并确定纠正措施以消除再次发生的可能性。
872
873 == ** ** ==
874
875 == **5.6. 政策与建议** ==
876
877 IT信息中心认识到建立以ITIL为指导的IT服务管理流程对公司IT运维的重要性和必要性，并能够支持所必要的IT服务流程、角色职责和服务质量考核的变革工作。
878
879 IT信息中心在具体的事件管理流程执行过程中，应能够遵守如下的流程政策：
880
881 * 规定1：
882
883 服务台是信息中心向用户提供的单一联系点(通过电话或Email)，包括接受故障申告， 回答产品咨询和分享信息等。
884
885 * 规定2：
886
887 任何用户要解决的问题不能绕过服务台来解决，所有需解决的突发事件要通过服务台提交。
888
889 * 规定3：
890
891 服务台所接受到的所有事件或服务请求及其解决方案，都要记录在服务台的事件管理系统中。
892
893 * 规定4：
894
895 创立事件记录的服务台员工是该事件的责任人，必须确保事件、问题解决和质量管理得到有效跟踪与解决。根据事件管理流程，事件在传递以后，责任人就是当前的处理人员，但服务台员工需要负责跟踪此事件是否得到解决。
896
897 服务台将事件升级给二线后，被指派的人员同样有类似服务台的首问负责似的责任，即使事件以后被传递给三线或其他二线人员，首次被指派人员有责任跟踪该事件并与服务台沟通
898
899 在交接班时服务台人员如果没有处理完手中的工作，应该升级为突发事件，并分配给下一班值班长，由下一班值班长指定新的服务台人员跟踪处理
900
901 * 规定5：
902
903 在整个事件的解决过程中，应及时向提交问题的最终用户通报问题的处理情况，使用户可以知道事件的解决状态；通过主动式服务所处理问题的进度和情况也应由服务台员工与最终用户进行沟通。
904
905 * 规定6：
906
907 为了确保重要事件的及时解决，应严格执行重大事件升级流程。
908
909 * 规定7：
910
911 事件管理流程将就任何已知的或可能的事件的相关情况与受到影响的用户进行沟通。
912
913 * 规定8：
914
915 事件必须在得到确认后，才能关闭记录。
916
917 * 规定9：
918
919 服务台应全面了解到内部变更的情况，包括近期完成的变更及变更计划的安排。
920
921 * 规定10：
922
923 服务台有责任通知最终用户变更的计划及变更实施的详细情况。
924
925 * 规定11：
926
927 定义和明确服务台及突发事件分析员的角色和责任，使人员明确自己的角色和相关的责任，流程能够得到正确的执行，保证服务的质量。
928
929 * 规定12：
930
931 明确定义服务台和事件管理的流程并进行归档，有章可寻，有制度可依，有流程可遵循。
932
933 * 规定13：
934
935 对于已知或计划内的服务中断要及时准确的提前通知所有受影响的部门和用户。
936
937 * 规定14：
938
939 规范事件处理的描述和记录。
940
941 * 规定15：
942
943 建立定期的服务回顾和检查制度，定义潜在的流程改进计划。根据流程的不断完善和对服务质量的提高，对服务台支持人员应该进行必要的培训工作。
944
945 * 规定16：
946
947 服务台应具备识别已知问题的能力，及完善的与问题管理功能衔接的接口。
948
949 * 规定17：
950
951 当事件经理不在岗位时，有相应人员代理执行其职责。
952
953 == ** ** ==
954
955 == **5.7. 与其它流程的关系**​ ==
956
957 (% style="text-align:center" %)
958 [[image:图片3.jpg]]
959
960 * 和问题管理流程的关系
961
962 事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势。如果优先级为一二级的事件，在事件解决并恢复服务后，必须做为问题进行进一步的分析和处理。
963
964 * 和配置管理流程的关系
965
966 需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。
967
968 * 和变更管理流程的关系
969
970 服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。
971
972 * 和知识管理流程的关系
973
974 事件管理流程中成功解决事件的解决方案作为知识进入知识库， 供运维人员使用。
975
976 = =
977
978
979 = **6. 事件管理流程设计** =
980
981 == **6.1. 前提约定** ==
982
983 === **6.1.1. 概念约定** ===
984
985 为了方便后续内容的理解，对一些比较关键的概念解释如下：
986
987 * “用户”
988
989 指的是XXIT信息中心内部的所有服务提供者（运维支持人员）和外部的所有服务使用者。
990
991 * “客户”
992
993 指的是使用XXIT信息中心提供的各种服务的所有使用者。
994
995 * “IT维护人员”
996
997 指的是XXIT信息中心IT服务的提供者，具体来讲，就是运维部门的支持、运维人员；也包括第三方的支持人员。
998
999 * “角色”
1000
1001 角色是ITIL从实际工作中抽象出来的具体流程环节的执行者，具备一定的职能，被要求一定的能力，并设置相应的考核指标。
1002
1003 一个事件管理流程中可具备多种角色，如：用户、服务台（一线）、突发事件分析员（二线，三线）、事件经理等等，角色把流程要求的各个环节的工作合理的划分、细分，使得资源配置合理，进而流程执行起来更加流畅，并被有效的监督。
1004
1005 角色的划分使得工作责权明确，便于开展IT运维工作。
1006
1007 * “角色与具体IT维护人员关系”
1008
1009 角色的定义来源于具体的运维人员，但在流程设计和描述中与具体IT维护人员没有直接关系，即流程中描述的是每个角色的具体操作环节和角色之间的关系，在具体流程执行时，将会在具体IT运维人员与流程的角色之间做映射。
1010
1011 一般来说一个运维人员对应一个角色，根据实际的情况，一个具体IT运维人员也可以对应多个角色。如：一个IT运维人员负责日常检查，当发现问题的时候，作为“用户”需要马上电话通知“服务台”的人员记录和分配该突发事件，如果该IT运维人员负责问题发生的系统，那么又将以“一线”的角色开始处理问题。
1012
1013 * “流程设计”
1014
1015 基于ITIL的事件管理流程设计，是把XXIT信息中心实际情况作为输入，通过ITIL指导和加工处理，最终输出基于ITIL的符合XXIT信息中心实际情况的事件管理流程的过程。
1016
1017 一般来说，用户的输入是一个空白或已有的具体人员和流程混合在一起的实际流程。经过ITIL处理，把实际工作和人员抽象化，经过讨论和设计，变成与具体人员无关的角色和各种必需的操作环节结合体的流程；最终在流程执行时，把流程中的角色和具体的IT运维人员映射，具体IT运维人员再按照设计出来的流程执行。
1018
1019 整个输入、处理、输出的过程，是顾问和XXIT信息中心配合人员共同讨论完成的，这样有助于知识的转移和后续的流程自我优化。
1020
1021 * “变通方法”
1022
1023 “变通方法”是相对“根本解决方法”而言的，是指没有根本解决一个事件引起的故障，但恢复了事件影响的服务（或业务）的方法。“变通方法”定义本身也说明了：**事件管理流程的目的是在规定时间内恢复服务（或业务），而不完全是针对事件本身**。比如：用户不能够打印文档，只要提供一台备用打印机就可以恢复打印服务，用户原有的打印机还是故障状态。因此，**具体事件管理流程执行时，需要把握好尺度：规定时间内，在服务（或业务）恢复的前提下，再尽可能的去完善方法。**
1024
1025 === ** ** ===
1026
1027 === **6.1.2. 原则约定** ===
1028
1029 **(注：此处涉及的时间需要待服务级别流程确定后再更新，三天为示例)**
1030
1031 **事件关闭原则：**
1032
1033 ITIL中要求，事件的建立和关闭都要由服务台进行，这就是事件管理的闭环原则。
1034
1035 事件的关闭原则具体描述如下：
1036
1037 1. 事件必须有责任人，一般情况下事件的责任人由服务台人员担任。
1038 1. 事件必须由事件责任人关闭。
1039 1. 采用两段式关闭策略，事件处理人员解决事件后，将状态改为“已解决”，相关服务台人员联系用户确认关闭，确保事件处理的闭包（Closed-Loop)
1040 1. 对于确实因为条件不具备无法解决的事件或请求，用户坚持不同意的关闭的，升级给服务台经理和突发事件经理，服务台经理与事件经理协商后，联系用户解释后以关闭代码”无法解决”关闭。
1041
1042 结合IT信息中心的具体情况，定义了以下关闭事件的原则：
1043
1044 * 对于非重大事件，由服务台与用户确认并关闭问题。
1045 * 对于重大事件，如特殊事件，可由具体重大故障负责人与用户直接确认，服务台直接关闭该事件。
1046
1047 **为落实首问责任制中的事件跟踪、闭环规范，现给出事件闭环操作指导。**
1048
1049 * 已在电话或邮件中与用户确认解决的事件
1050
1051 **规范的操作：**关闭相应的交互单和突发事件单.   
1052
1053 * 给出了解决方案，但不确定一定解决，还未得到用户确认的事件
1054
1055 **规范的操作：**
1056
1057 （1）突发事件分析员将突发事件状态置为”已解决“。
1058
1059 （2）服务台在事件**”已解决”后的三个工作日内**电话或邮件联系用户，确认事件解决情况，用户确认解决后，将事件闭环。
1060
1061 * 服务台/突发事件分析员自己解决不了，传递给专家或者其他技术支持的事件
1062
1063 *
1064 ** 规范的操作：
1065
1066 （1）事件传递后要确定责任人已收到事件传递的通知（确定方式包括但不限于邮件和电话），保证事件及时处理，并将联系技术支持处理的过程记录到活动历史中；
1067
1068 （2）已收到”已解决“通知后，紧急或者影响大的事件（如：网络不通），要立即联系用户确认解决情况，确认解决后将事件闭环。其余事件必须在事件**Resolved后的三个工作日内**电话或邮件联系用户，确认事件解决情况，用户确认解决后，将事件闭环。
1069
1070 （3）如果下班时紧急或者影响大的事件还未解决（如：网络不通），需在下班后将事件号和事件的当前进展通过邮件发送给下一班次的值班人员，并与下一班次的值班人员进行当面交接。
1071
1072 * 跟踪、闭环要求：
1073
1074 （1）将每次跟踪的记录、用户确认解决的闭环信息必须写入活动历史中;
1075
1076 （2）传递给别人的事件闭环后事件单关闭
1077
1078 备注：不限制跟踪的次数，关注闭环结果，除了联系不上用户外，其他在三个工作日内未闭环的均不合格。
1079
1080 **重分配原则：**
1081
1082 事件的重分配规则具体描述如下：
1083
1084 1. 事件的及时、正确分配和接受处理是确保事件在解决时限内解决的关键因素。
1085 1. 一线和突发事件分析员可以根据重分配原则重新分配不属于自己运维范围的事件。
1086
1087 **升级原则：**
1088
1089 制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案
1090
1091 1. 服务台/一线支持应及时将不能解决的事件升级到其后一级的支持人员，若未及时升级，事件经理应及时介入，负责协调升级处理
1092 1. 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台应将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理
1093 1. 应遵从华星光电的事件升级通报规范
1094
1095 **重复事件原则**
1096
1097 重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件或一人、多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。
1098
1099 * 监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台
1100 * 如果服务台/一线支持判断到重复事件，则由服务台/一线支持需要将新建的交互单关联到已有的突发事件单
1101
1102 == ** ** ==
1103
1104 == **6.2. 事件通知与升级机制** ==
1105
1106 事件升级的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。
1107
1108 事件升级的分类：
1109
1110 技术升级，技术升级意味着会涉及更多的技术专家来帮助事件的解决， 这往往会涉及到不同的部门或小组，比如一个事件一开始分配给一线支持来解决，但一线支持的工程师在分析事件的过程中，发现需要突发事件分析员的网络专家来解决。
1111
1112 管理升级，管理升级意味着公司或IT部门的管理层的介入， 这很有可能是由于资源不足或重大事件引起的。对管理层升级不代表需要管理层直接操作事件处理。
1113
1114 事件升级的方式：电话、邮件和短信等多种方式结合。其中电话确认是必须的。
1115
1116 无论是技术升级还是管理升级，需要通过合适的途径让服务台知晓。
1117
1118 升级规定请参考<<WI-IT-CIM-00011 信息中心IT故障管理规范Ver.01>>
1119
1120 == ** ** ==
1121
1122 == **6.3. 事件管理流程角色和职责** ==
1123
1124 === **6.3.1. 角色和职责** ===
1125
1126 根据XXIT信息中心实际情况并结合ITIL，定义如下角色：
1127
1128 * 事件经理
1129 * 突发事件协调员
1130 * 突发事件分析员（二，三线人员）
1131 * 服务台经理， 请参见3.3.1.1
1132 * 服务台人员，请参见3.3.1.2
1133
1134 ==== ** ** ====
1135
1136 ==== **6.3.1.1. 事件经理** ====
1137
1138 职责：
1139
1140 * 确保有效协调资源，通过事件支持专家快速恢复正常服务。
1141 * 确保事件管理支持人员的适当技能水平和绩效表现。
1142 * 确保和问题经理及外部供应商等部门的有效合作。
1143 * 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题。
1144 * 通过服务台的作用及良好的服务态度来确保客户的满意。
1145 * 确保有关IT服务和客户支持的管理信息的可获得性。
1146 * 确保流程满足实际的需要，角色职责明确，流程各环节合理
1147 * 接收各方意见和建议，改进和提高事件管理流程的有效性和效率
1148 * 制定和解释事件流程的相关内容
1149 * 处理由突发事件协调员升级的突发事件
1150
1151 主要技能：
1152
1153 * 熟悉技术架构和技术环境
1154 * 较强的领导能力
1155 * 深刻了解事件管理流程
1156 * 熟悉各个业务系统的运维
1157 * 较强的流程规划和制定能力
1158 * 较强的组织和协调能力
1159 * 具备一定企业管理知识
1160
1161 ==== ** ** ====
1162
1163 ==== **6.3.1.2. 突发事件协调员** ====
1164
1165 职责：
1166
1167 * 审核并接受或拒绝分配给支持组的突发事件。
1168 * 处理由突发事件分析员升级的突发事件。
1169 * 监控支持组的操作级别协议 (OLA) 和支持合同 (UC) 目标。
1170
1171 主要技能：
1172
1173 * 熟悉技术架构和技术环境
1174 * 处理纠纷的能力
1175 * 较强的领导能力
1176 * 较强的组织和协调能力
1177 * 熟悉突发事件分析员能力水平和日常安排
1178 * 熟悉事件管理流程
1179
1180 ==== ** ** ====
1181
1182 ==== **6.3.1.3. 突发事件分析员** ====
1183
1184 职责：
1185
1186 * 在规定的时间内解决事件（突发事件，服务请求等）
1187 * 对利用“变通方法"解决的事件，在资源及时间允许时应找到问题根源或将之标记为”问题候选项”
1188 * 必要时升级到三线或突发事件协调员
1189 * 将事件的解决步骤文档化，并将解决方案录入服务台系统中
1190 * 根据解决方案进行服务恢复
1191 * 必要时现场支持
1192
1193 主要技能：
1194
1195 * 熟悉所负责的技术平台和技术环境.
1196 * 很强的技术能力
1197 * 较强的解决问题的能力
1198 * 较强的分析能力
1199
1200 == ** ** ==
1201
1202 == **6.4. 事件流程代码定义** ==
1203
1204 参见4.1， 事件流程与交互使用同样地代码定义有利于将交互直接升级成突发事件，保证两个模块直接信息的一致性。
1205
1206 == ** ** ==
1207
1208 == **6.5. 事件管理流程概要设计** ==
1209
1210 事件管理概要流程是根据IT信息中心的具体情况，结合HP ITSM的最佳经验，并通过与IT信息中心人员的共同讨论最终确定的。事件管理概要流程主要从整体上描述事件的处理过程，不会体现具体的细节和涵盖所有的人员，但能够体现当前可能的输入和输出。
1211
1212 === ** ** ===
1213
1214 === **6.5.1. 流程图例说明** ===
1215
1216 根据流程设计要求， 我们将事件管理流程的设计标号以SO2开头，比如SO2.X。
1217
1218 === ** ** ===
1219
1220 === **6.5.2. 概要流程描述** ===
1221
1222 IT信息中心事件管理概要流程具体如下：
1223
1224 突发事件管理
1225
1226 (% style="text-align:center" %)
1227 [[image:图片4.jpg]]
1228
1229
1230 描述如下：
1231
1232 |**序号**|(% style="width:121px" %)**步骤名称**|(% style="width:163px" %)**责任人**|(% style="width:994px" %)**流程描述**
1233 |SO2.1|(% style="width:121px" %)突发事件记录|(% style="width:163px" %)服务台人员|(% style="width:994px" %)突发事件将根据其来源和性质作为交互管理流程的一部分或事件管理流程的一部分启动和记录。如果突发事件是通过服务台人员记录的，则大多数突发事件详细信息都已在交互记录中提供。如果突发事件由操作员记录，并且通常使用系统管理工具，则操作员可以根据适用的突发事件模板记录突发事件。
1234 |SO2.2|(% style="width:121px" %)突发事件分配|(% style="width:163px" %)服务台人员/突发事件协调员|(% style="width:994px" %)突发事件协调员监控突发事件队列，审核处于打开状态的突发事件，并根据提供的信息确定是接受还是拒绝突发事件记录。接受突发事件记录后，会将其分配给突发事件分析员以进行进一步调查和诊断。
1235 |SO2.3|(% style="width:121px" %)突发事件调查和诊断 |(% style="width:163px" %)突发事件分析员|(% style="width:994px" %)突发事件分析员执行分析和诊断任务来找到事件的根本原因和解决方案。
1236 |SO2.4|(% style="width:121px" %)突发事件解决和恢复 |(% style="width:163px" %)突发事件分析员|(% style="width:994px" %)突发事件分析员需要在应用可能的解决方案前对其进行识别和评估，并根据需要升级突发事件。必要时，突发事件分析员会将突发事件（包括那些需要变更的突发事件）升级到突发事件协调员。如果突发事件分析员没有实施变更所需的权限级别，他/她需要将突发事件重新分配给其他可以实施解决方案的组。
1237 |SO2.5|(% style="width:121px" %)突发事件关闭 |(% style="width:163px" %)突发事件分析员|(% style="width:994px" %)关闭突发事件时，必须对其进行检查以确认初始突发事件分类是否正确。如果类别不正确，则必须使用正确的类别更新记录。如果突发事件记录中缺失信息，则必须将缺失的信息添加到记录中以确保突发事件记录的完整性。突发事件关闭过程的最后一步是确定突发事件重复发生的可能性，并相应地选择关闭类别。如果突发事件可能重复发生，将突发事件记录标记为“问题候选项”
1238 |SO2.6|(% style="width:121px" %)突发事件升级 |(% style="width:163px" %)突发事件协调员|(% style="width:994px" %)当突发事件调查和诊断流程或突发事件解决和恢复流程超出服务级别协议目标时或如果不能达到这些目标，将升级突发事件。
1239 |SO2.7|(% style="width:121px" %)监控服务级别协议 |(% style="width:163px" %)服务台人员|(% style="width:994px" %)服务级别协议 (SLA) 包含突发事件解决情况的标准。此过程对突发事件从初始化到解决的过程中要监控的所有与突发事件相关的交互的活动进行了描述。SLA 监控还可确定是否符合突发事件解决的时间目标，并根据关联的 SLA 指示是否需要升级以符合目标解决日期。
1240 |SO2.8|(% style="width:121px" %)OLA 和 UC 监控 |(% style="width:163px" %)突发事件协调员|(% style="width:994px" %)突发事件协调员会监控分配给支持组和相应供应商的所有突发事件。在没有按照指定的协议日期和时间解决或升级突发事件前，将会一直跟踪执行情况。OLA 和 UC 的目标日期通常取决于突发事件的优先级和类别。如果已超过或即将超过目标时间，突发事件协调员可以将突发事件升级给突发事件经理。
1241 |SO2.9|(% style="width:121px" %)投诉处理 |(% style="width:163px" %)服务台经理|(% style="width:994px" %)当服务台经理收到“突发事件”或“任务”队列中的已分配的投诉类型的突发事件时，他将接受该突发事件。并且通过评估相关信息以及与相关人员进行交流来调查投诉原因。他还将搜索答案或解决方案以满足投诉用户的要求，并使用协定过的详细信息更新突发事件记录，然后关闭突发事件记录。
1242
1243 == ==
1244
1245 == **6.6. 事件管理流程详细设计** ==
1246
1247 事件管理流程详细设计是在概要流程设计的基础上，逐个环节细化，同时结合事件流程代码，把整个事件流程具体处理过程详细描述。
1248
1249
1250 === **6.6.1.（SO2.1）突发事件记录** ===
1251
1252 突发事件记录流程环节SO2.1的细化流程如下图所示：
1253
1254 (% style="text-align:center" %)
1255 [[image:1730167336482-691.png]]
1256
1257 描述如下：
1258
1259 |**序号**|**步骤名称**|(% style="width:109px" %)**责任人**|(% style="width:888px" %)**流程描述**
1260 |SO2.1.1|升级交互为突发事件|(% style="width:109px" %)服务台人员|(% style="width:888px" %)用户交互无法在第一次联系即得以解决，将升级到突发事件管理流程。交互将会与新创建的突发事件自动关联。服务台人员根据交互创建突发事件。
1261 |SO2.1.2|是否分类为投诉？|(% style="width:109px" %)服务台人员|(% style="width:888px" %)此突发事件是否分类为服务台人员无法解决的投诉？如果是，请转至 SO2.1.5。如果不是，请转至 SO2.1.3。
1262 |SO2.1.3|将突发事件分配给组/人|(% style="width:109px" %)服务台人员|(% style="width:888px" %)突发事件会根据分类和受影响的服务分配到相应的支持组或人。CIM部门的突发事件同时要求电话确认分配人。
1263 |SO2.1.4|为用户提供交互编号|(% style="width:109px" %)服务台人员|(% style="width:888px" %)服务台人员为用户提供交互编号。用户需将此交互编号保存下来，以用作此突发事件的参考。
1264 |SO2.1.5|将投诉突发事件分配给服务台组|(% style="width:109px" %)服务台人员|(% style="width:888px" %)最初会将分类为投诉的突发事件分配给服务台组。
1265 |SO2.1.6|为用户提供交互编号和服务级别协议目标|(% style="width:109px" %)服务台人员|(% style="width:888px" %)服务台人员为用户提供交互编号。用户需将此交互编号保存下来，以用作此突发事件的参考。另外，服务台人员还将根据 SLA 提供目标解决日期。
1266 |SO2.1.7|将突发事件分配给服务台经理|(% style="width:109px" %)服务台人员|(% style="width:888px" %)突发事件保存后，将其分配给服务台经理（请参见 SO2.9 投诉管理）。
1267 |SO2.1.8|审核突发事件信息|(% style="width:109px" %)服务台人员|(% style="width:888px" %)突发事件可能会由于分配错误或信息不完整被分配组拒绝。在这种情况下，服务台人员需要审核记录的注释并更正信息或分配。
1268 |SO2.1.9|信息是否完整？|(% style="width:109px" %)服务台人员|(% style="width:888px" %)如果不是，请转至 SO2.1.10。如果是，请转至 SO2.1.3。
1269 |SO2.1.10|收集所需信息|(% style="width:109px" %)服务台人员|(% style="width:888px" %)收集丢失的必需信息，并使用这些信息更新突发事件。如果有必要，请与用户联系。
1270 |SO2.1.11|创建新的突发事件|(% style="width:109px" %)服务台人员|(% style="width:888px" %)从监控系统发现突发事件，根据实际情况，服务台手动登记突发事件记录或由监控系统集成自动打开突发事件记录。
1271 |SO2.1.12|选择合适的突发事件模板|(% style="width:109px" %)服务台人员|(% style="width:888px" %)服务台人员从列表中选择突发事件模板
1272 |SO2.1.13|按照模板说明操作|(% style="width:109px" %)服务台人员|(% style="width:888px" %)服务台人员将根据突发事件模板中的说明记录突发事件详细信息。
1273 |SO2.1.14|提供描述/配置项|(% style="width:109px" %)服务台人员|(% style="width:888px" %)为突发事件提供适当的描述。这可以是基于事件文本得出的。如果可能，应选择受影响的配置项。
1274 |SO2.1.15|选择类别和优先级|(% style="width:109px" %)服务台人员|(% style="width:888px" %)通过选择适用的影响级别和紧急程度选择适当的类别和优先级。
1275 |SO2.1.16|将突发事件分配给组|(% style="width:109px" %)服务台人员|(% style="width:888px" %)突发事件会根据分类和相关受影响的服务自动分配到相应的支持组。
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
1301 通过服务管理平台派发事件的方式，能够很好的记录日常处理的事件，但同时也会面临响应延迟的问题。响应延迟的问题主要体现在事件分配后，被分配人员因为某种原因，不能及时登录服务管理平台查询需要自己处理的事件，导致延迟处理事件。
1302
1303 响应延迟可能存在多种原因，如：正在处理一个事件；正在开会，不具备条件，不能够马上登陆服务管理平台察看并处理；正在休假；不能察看邮件等等。随着事件管理流程的执行，可能还会有其它的原因。但都不是流程能够解决的问题，需要制定管理制度，并有效执行才能解决。
1304
1305 当前为避免该问题发生的建议如下：
1306
1307 * 当前每次事件的分派前电话通知被分派人员，同时通过服务管理平台邮件；
1308 * 如果被分派人员未联系上，直接联系突发事件协调员，由突发事件协调员协调处理；
1309 * 及时更新各个系统具体负责的运维人员相关信息，并通知服务台人员。
1310
1311 后续随着事件管理流程的运转，通过服务台把各种情况记录下来，定期统计分析，发现响应延迟的根本原因，再进一步完善弥补响应延迟的措施。如果是管理制度不完善，如：休假制度、出差制度，则完善相应的制度；如果是资源配置不合理，如：工作量大但只有一个人负责，则合理增配运维人员。后续各个流程在分派响应问题上可参考此处描述，不再复述。
1312
1313 === ===
1314
1315 === **6.6.2. （SO2.2）突发事件分配/再分配** ===
1316
1317 突发事件分配流程环节SO2.2的细化流程如下图所示：
1318
1319
1320 (% style="text-align:center" %)
1321 [[image:1730167403847-523.png]]
1322
1323 描述如下：
1324
1325 |序号|步骤名称|(% style="width:129px" %)责任人|(% style="width:920px" %)流程描述
1326 |SO2.2.1|审核突发事件信息|(% style="width:129px" %)突发事件协调员|(% style="width:920px" %)突发事件协调员监控突发事件队列并审核所有传入的突发事件。
1327 |SO2.2.2|突发事件信息是否完整并分配到正确的组？|(% style="width:129px" %)突发事件协调员|(% style="width:920px" %)突发事件协调员验证突发事件记录中是否提供了足够的信息以诊断突发事件，并验证突发事件是否已分配给正确的支持组。如果是，请继续 SO2.2.3。如果不是，请转至 SO2.2.8。
1328 |SO2.2.3|将突发事件分配或再分配给突发事件分析员|(% style="width:129px" %)突发事件协调员|(% style="width:920px" %)突发事件协调员接受突发事件，并将其分配或再分配给突发事件协调员组中的某位突发事件分析员，以便进行进一步调查和诊断。
1329 |SO2.2.4|审核突发事件信息|(% style="width:129px" %)突发事件分析员|(% style="width:920px" %)突发事件分析员对分配给他/她自己的突发事件的队列进行监控，并审核传入的突发事件。
1330 |SO2.2.5|是否能解决突发事件？|(% style="width:129px" %)突发事件分析员|(% style="width:920px" %)突发事件分析员审核分配的突发事件以确定他/她是否能够解决该突发事件。如果是，请继续 SO2.2.6。如果不是，请转至 SO2.2.7。
1331 |SO2.2.6|接受突发事件|(% style="width:129px" %)突发事件分析员|(% style="width:920px" %)突发事件分析员通过将状态更改为“已接受”接受突发事件。
1332 |SO2.2.7|拒绝突发事件|(% style="width:129px" %)突发事件分析员|(% style="width:920px" %)突发事件分析员通过将“分配人”字段设置为突发事件协调员并提供一个更新来拒绝突发事件，拒绝原因在更新中陈述。然后，将突发事件返回到突发事件队列中，以待突发事件协调员重新进行分配。
1333 |SO2.2.8|拒绝突发事件|(% style="width:129px" %)突发事件协调员|(% style="width:920px" %)突发事件协调员拒绝突发事件，然后将其重新分配给服务台。
1334
1335 === ===
1336
1337 === **6.6.3. （SO2.3）突发事件调查和诊断** ===
1338
1339 突发事件调查和诊断流程环节SO2.3的细化流程如下图所示：
1340
1341
1342 (% style="text-align:center" %)
1343 [[image:1730167464291-929.png]]
1344
1345 描述如下：
1346
1347 |序号|步骤名称|(% style="width:136px" %)责任人|(% style="width:1000px" %)流程描述
1348 |SO2.3.1|审核突发事件|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员对分配给他/她自己的突发事件的队列进行监控，并审核传入的突发事件
1349 |SO2.3.2|是否请求信息？|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员评估突发事件以查看是否已将其分类为服务请求。如果是，请继续 SO2.3.11。如果不是，请转至 SO2.3.3。
1350 |SO2.3.3|调查和诊断|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员开始调查和诊断突发事件原因。突发事件的状态被设置为“正在处理”。
1351 |SO2.3.4|是否再现突发事件？|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员尝试是否可以重现突发事件。如果是，请继续 SO2.3.5。如果不是，请转至 SO2.3.8。
1352 |SO2.3.5|是否与未决问题/已知错误匹配？|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员搜索问题数据库中是否存在为此突发事件定义的问题或已知错误。如果是，请继续 SO2.3.9。如果不是，请转至 SO2.3.6。
1353 |SO2.3.6|突发事件是否由变更引起？|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员搜索变更知识库以查看是否由于最新变更而导致服务中断。如果列出了与此突发事件相关联的配置项，则突发事件分析员还可以查看最近根据此配置项执行的所有变更。此外，突发事件分析员还可以查看配置项树以确定突发事件是否由相关配置项引起。如果是，请继续 SO2.3.10。如果不是，请转至 SO2.3.7。
1354 |SO2.3.7|是否找到解决方案？|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员将检查已知错误/知识库来获得此突发事件的应对措施或解决方案，或尝试查找解决方案。如果是，请继续 SO2.3.8。如果不是，请返回至 SO2.3.3
1355 |SO2.3.8|记录解决方案/应对措施|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员将在突发事件记录中记录解决方案或应对措施。
1356 |SO2.3.9|将突发事件与问题/已知错误相关联|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)如果突发事件与未决问题/已知错误相匹配，则突发事件记录与此问题/已知错误记录相关联。在应对措施可以使用前，突发事件一直处于挂起状态。
1357 |SO2.3.10|将突发事件与变更相关联|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)如果突发事件由先前变更引起，则突发事件记录与此变更记录相关。但是，仍然需要找到一个解决方案来解决突发事件。
1358 |SO2.3.11|搜索/收集信息|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员将搜索相关信息，以为用户提供请求的信息。
1359
1360 注意：
1361
1362 在事件处理中要注意最后期限的要求，并按照事件通知和升级机制， 通知相关人员。在以下处理过程中不再重复描述。
1363
1364 === ===
1365
1366 === **6.6.4. （SO2.4）突发事件解决与恢复** ===
1367
1368 突发事件解决与恢复流程环节SO2.4的细化流程如下图所示：
1369
1370
1371 (% style="text-align:center" %)
1372 [[image:1730167509731-690.png]]
1373
1374 描述如下：
1375
1376 |序号|步骤名称|(% style="width:134px" %)责任人|(% style="width:892px" %)流程描述
1377 |SO2.4.1|审核突发事件|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)突发事件分析员会审核突发事件信息，以获得所提供的解决方案或应对措施。
1378 |SO2.4.2|是否需要变更来解决突发事件？|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)突发事件分析员确定提供的解决方案是否需要通过变更来实施。如果是，请转至 SO2.6。如果不是，请继续 SO2.4.3。
1379 |SO2.4.3|突发事件分析员是否有权实施解决方案？|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)突发事件分析员必须判断他/她是否有权实施解决方案。如果是，请继续 SO2.4.4。如果不是，请转至 SO2.4.7。
1380 |SO2.4.4|实施解决方案|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)突发事件分析员在生产环境中测试和实施解决方案。验证完成后将状态标记为”已完成。
1381 |SO2.4.5|是否出现错误？|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)如果在实施解决方案过程中出现错误，突发事件分析员将撤销解决方案，突发事件将返回到调查和诊断阶段。如果是，请转至 SO2.4.6。如果不是，请继续 SO2.5。
1382 |SO2.4.6|是否需要升级？|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)确定是否需要解决过程中的此位置升级到突发事件协调员。如果是，请转至突发事件升级过程。如果不是，请转至 SO2.3.3。
1383 |SO2.4.7|重新分配给其他组|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)当突发事件分析员没有被授予实施解决方案的权限时，突发事件分析员必须将突发事件重新分配到可以实施解决方案的支持组。
1384
1385
1386 === **6.6.5. （SO2.5）突发事件关闭** ===
1387
1388 突发事件关闭流程环节SO2.5的细化流程如下图所示：
1389
1390
1391 (% style="text-align:center" %)
1392 [[image:1730167543852-131.png]]
1393
1394 描述如下：
1395
1396 |序号|步骤名称|责任人|流程描述
1397 |SO2.5.1|监控状态为“已解决”突发事件队列|服务台人员|服务台人员通过队列定期检查标记为”已解决“状态的突发事件
1398 |SO2.5.2|验证并确认解决方案|服务台人员|服务台人员验证解决方案是否正确且完整，然后与用户联系确认是否已经解决。
1399 |SO2.5.3|用户确认已解决？|服务台人员|用户确认已解决？如果是，请继续 SO2.5.4。如果不是，请转至 SO2.5.7。
1400 |SO2.5.4|关闭突发事件|服务台人员|关闭突发事件并选择合适的关闭代码。
1401 |SO2.5.5|突发事件是否由监控系统触发？|服务台人员|突发事件是否由监控系统触发？如果是，则必须通过监控系统确认事件(Event)。如果不是，请转至 SO2.5.6。
1402 |SO2.5.6|突发事件是否通过交互引起？|服务台人员|突发事件是否由交互引起？如果是，请继续进行关闭交互过程。如果不是，请停止。
1403 |SO2.5.7|重新打开变更？|服务台人员|解决方案是否是通过变更实施的？如果是，请继续进行重新打开变更过程。如果不是，请转至 SO2.5.8。
1404 |SO2.5.8|重新打开服务请求？|服务台人员|解决方案是否是通过服务请求实施的？如果是，请继续进行重新打开变更过程。如果不是，请转至突发事件分配过程。
1405
1406 (% class="wikigeneratedid" %)
1407 === ===
1408
1409 === **6.6.6. （SO2.6）突发事件升级** ===
1410
1411 突发事件升级流程环节SO2.6的细化流程如下图所示：
1412
1413
1414 (% style="text-align:center" %)
1415 [[image:1730167571864-309.png]]
1416
1417 描述如下：
1418
1419 |序号|步骤名称|(% style="width:128px" %)责任人|(% style="width:949px" %)流程描述
1420 |SO2.6.1|确定如何解决突发事件|(% style="width:128px" %)突发事件协调员|(% style="width:949px" %)突发事件协调员从突发事件分析员处收集有关突发事件解决状态的信息，然后根据信息确定解决突发事件的最佳方式。
1421 |SO2.6.2|是否需要升级？|(% style="width:128px" %)突发事件协调员|(% style="width:949px" %)是否需要升级来解决突发事件？如果是，请继续 SO2.6.7。如果不是，请转至 SO2.6.3。
1422 |SO2.6.3|是否需要服务请求？|(% style="width:128px" %)突发事件协调员|(% style="width:949px" %)是否可以通过服务请求解决突发事件？如果是，请继续 SO2.6.5。如果不是，请转至 SO2.6.4。
1423 |SO2.6.4|让突发事件分析员解决突发事件|(% style="width:128px" %)突发事件协调员|(% style="width:949px" %)突发事件协调员可以让突发事件分析员只关注突发事件的解决，并为他们提供所有必要的方法，以加快解决速度。
1424 |SO2.6.5|请求服务请求|(% style="width:128px" %)突发事件协调员|(% style="width:949px" %)突发事件协调员通过请求执行流程完成服务请求以实施建议的解决方案
1425 |SO2.6.6|确定预期解决时间|(% style="width:128px" %)突发事件经理|(% style="width:949px" %)突发事件经理会验证预期解决时间是否符合服务级别协议 (SLA) 目标。
1426 |SO2.6.7|确定并执行升级操作|(% style="width:128px" %)突发事件经理|(% style="width:949px" %)突发事件经理确定要在目标时间内解决突发事件需要执行的操作，并指定发生升级时的升级联系人。这样可以包括确定是否需要服务台将信息公告发送给受影响的用户和利益相关者。
1427 |SO2.6.8|是否需要紧急变更？|(% style="width:128px" %)突发事件经理|(% style="width:949px" %)如果是，请转至 SO2.6.9。如果不是，请转至 SO2.6.10。
1428 |SO2.6.9|注册紧急变更|(% style="width:128px" %)突发事件协调员|(% style="width:949px" %)根据突发事件经理请求，突发事件协调员将注册紧急变更请求，与变更经理联系，将请求通知给他/她，然后启动紧急变更处理过程。
1429 |SO2.6.10|是否需要重新分配？|(% style="width:128px" %)突发事件经理|(% style="width:949px" %)是否需要将突发事件重新分配给经验更为丰富的支持组（即功能升级）？如果是，请继续 SO2.6.11。如果不是，请停止。
1430 |SO2.6.11|重新分配突发事件|(% style="width:128px" %)突发事件经理|(% style="width:949px" %)突发事件经理将突发事件重新分配给二线或三线支持组。
1431
1432 (% class="wikigeneratedid" %)
1433 === ===
1434
1435 === **6.6.7. （SO2.7）监控SLA** ===
1436
1437 (注：此处涉及到的与SLA/SLO相关的时间为示例，具体时间待服务级别管理流程确定后再更新)
1438
1439 监控SLA流程环节SO2.7的细化流程如下图所示：
1440
1441
1442 (% style="text-align:center" %)
1443 [[image:1730167600213-711.png]]
1444
1445
1446 描述如下：
1447
1448 |序号|步骤名称|责任人|流程描述
1449 |SO2.7.1|监控队列|服务台人员|通过查询或相关视图查询SLA监控队列
1450 |SO2.7.2|是否违反 SLA？|服务台人员|是否已超过此交互的 SLA 目标日期/时间？如果是，请启动突发事件升级过程 (SO2.6.7)。如果不是，请转至 SO2.7.3。
1451 |SO2.7.3|1 小时内发生 SLA 违约|服务台人员|是否需要在距 SLA 目标日期/时间还有 1 小时之前解决交互？如果是，请转至 SO2.7.4。如果不是，请转至 SO2.7.7。
1452 |SO2.7.4|与突发事件协调员协商能否按时解决|服务台人员|联系相关突发事件协调员。确定如果没有进一步的支持该组是否能够按时解决突发事件。
1453 |SO2.7.5|能否按时解决？|服务台人员|如果是，请转至 SO2.7.6。如果不是，请转至 SO2.6.7，立即升级突发事件。
1454 |SO2.7.6|通报受影响用户|服务台人员|识别受相关突发事件影响的用户或用户组。将突发事件状态和预期解决时间通报给所有受影响的用户。
1455 |SO2.7.7|4 小时内发生 SLA 违约？|服务台人员|是否需要在距 SLA 目标日期/时间还有 4 小时之前解决交互？如果是，请转至 SO2.7.9。如果不是，请转至 SO2.7.8。
1456 |SO2.7.8|1 天内发生 SLA 违约？|服务台人员|是否需要在距 SLA 目标日期/时间还有 1 天之前解决交互？如果是，请转至 SO2.7.9。如果不是，请转至 SO2.7.11。
1457 |SO2.7.9|了解事件处理进度|服务台人员|通过查看事件单中的工作日志或联系相关人员了解进度
1458 |SO2.7.10|能否按时解决|服务台人员|判断是否能够按时解决，如果是，转SO2.7.1,如果不是，转SO2.7.4
1459 |SO2.7.11|相关事件是否已关闭？|服务台人员|如果是，则不需要进一步执行任何操作。如果不是，请转至 SO2.7.1。
1460
1461 (% class="wikigeneratedid" %)
1462 === ===
1463
1464 === **6.6.8. （SO2.8）监控操作级别协议（OLA）和支持合同（UC）** ===
1465
1466 (注：此处涉及到的与SLA/SLO相关的时间为示例，具体时间待服务级别管理流程确定后再更新)
1467
1468 监控OLA和UC流程环节SO2.8的细化流程如下图所示：
1469
1470
1471
1472 (% style="text-align:center" %)
1473 [[image:1730167627857-667.png]]
1474
1475 描述如下：
1476
1477 |序号|步骤名称|责任人|流程描述
1478 |SO 2.8.1|检查突发事件的状态和进度|突发事件协调员|检查突发事件解决的状态和进度。验证是否将在适用的操作级别协议 (OLA) 和支持合同 (UC) 中指定的目标日期和时间之前解决突发事件。
1479 |SO 2.8.2|分配的突发事件分析员在工作？|突发事件协调员|外部环境（例如，工作班次结束、疾病或假期）可能导致找不到已分配的突发事件分析员。
1480 |SO 2.8.3|是否需要重新分配？|突发事件协调员|如果是，请转至 SO 2.2.3。如果不是，请转至 SO 2.8.4。
1481 |SO 2.8.4|是否违反OLA 或 UC？|突发事件协调员|如果是，请启动突发事件升级过程 (SO 2.6.7)。如果不是，请转至 SO 2.8.5。
1482 |SO 2.8.5|在 1 小时内发生 OLA/UC 违约？|突发事件协调员|如果是，请转至 SO 2.8.6。如果不是，请转至 SO 2.8.8。
1483 |SO 2.8.6|从事件分析员或供应商那里获取状态更新|突发事件协调员|与已分配的突发事件分析员联系，以接收突发事件的状态更新。如果已将突发事件报告给供应商，则联系供应商以获取状态更新。
1484 |SO 2.8.7|能否按时解决突发事件？|突发事件协调员|突发事件协调员估计是否仍然能够按时解决突发事件。如果是，请转至 SO 2.8.1。如果不是，请转至 SO 2.6.7 以立即升级突发事件。
1485 |SO 2.8.8|在 4 小时内发生 OLA/UC 违约？|突发事件协调员|是否需要在距 OLA/UC 目标日期/时间还有 4 小时之前解决突发事件？如果是，请转至 SO2.8.9。如果不是，请转至 SO2.8.11。
1486 |SO2.8.9|从事件分析员或供应商那里获取状态更新|突发事件协调员|与已分配的突发事件分析员联系，以接收突发事件的状态更新。如果已将突发事件报告给供应商，则联系供应商以获取状态更新。
1487 |SO2.8.10|如果需要，执行跟进操作|突发事件协调员|突发事件协调员根据 OLA/UC 确定是否需要执行跟进操作来解决突发事件。如果需要，突发事件协调员将执行所需操作。
1488 |SO2.8.11|在 1 天内发生 OLA/UC 违约？|突发事件协调员|如果是，请转至 SO2.8.9。如果不是，请转至 SO2.8.12。
1489 |SO2.8.12|突发事件是否已关闭？|突发事件协调员|如果是，则不需要进一步执行任何操作。如果不是，请转至 SO2.8.1。
1490
1491 (% class="wikigeneratedid" %)
1492 === ===
1493
1494 === **6.6.9. （SO2.9）投诉处理** ===
1495
1496 投诉处理流程环节SO2.9的细化流程如下图所示：
1497
1498
1499 (% style="text-align:center" %)
1500 [[image:1730167651416-536.png]]
1501
1502 描述如下：
1503
1504
1505 |序号|步骤名称|责任人|流程描述
1506 |SO2.9.1|审核投诉信息|服务台经理|服务台经理监控突发事件队列并审核已分配的突发事件。服务台经理检查投诉内容。
1507 |SO2.9.2|接受投诉|服务台经理|服务台经理接受突发事件记录，以调查投诉原因。
1508 |SO2.9.3|调查投诉原因|服务台经理|服务台经理通过查看相关信息并与相关人员进行交流来调查投诉原因。服务台经理还将寻找解决方案，让提交投诉的用户满意。
1509 |SO2.9.4|采取措施来与用户调解|服务台经理|服务台经理联系用户以解决用户的问题，并尝试达成协议。
1510 |SO2.9.5|更新和关闭投诉|服务台经理|服务台经理使用协定过的详细信息更新突发事件记录，然后关闭突发事件记录。
1511
1512
1513
1514 = **7. 报表** =
1515
1516 有了有效的、适合使用的流程，还要加强相应的管理才能获得最佳效果。对于服务台、事件流程的管理分析主要集中在：呼叫、事件的分布和处理情况、流程运行效率、各角色执行效率、人员分布及技能水平情况等方面。管理者（事件经理和运维主管）需要综合这些信息适时的对流程、人员组织的情况进行动态调整，以持续改善、提高事件管理流程的效率和能力。
1517
1518
1519 |报表名称|模块|描述
1520 |首次解绝率|服务台|在没有请求其他支持人员的情况下，首次联系即被服务台人员关闭的交互的百分比
1521 |用户满意度|服务台|客户满意度调查返回的平均结果
1522 |本人名下未关闭交互单|服务台|本人处理，由于升级到突发事件而未关闭的交互单
1523 |在 SLA 目标时间内关闭的突发事件的百分比|突发事件|在 SLA 目标时间内关闭的突发事件的数量（相对于在给定时间段内关闭的所有突发事件）
1524 |重新打开的突发事件的百分比|突发事件|由于解决方案不被客户接受而重新打开的已关闭突发事件的数量（相对于在给定时间段内关闭的所有突发事件的数量）。
1525 |月度故障解决率|突发事件|本月故障的服务台/二/三线解决率。
1526 |本月交互，故障分类统计|服务台，突发事件|本月各个分类出现的交互，突发事件次数统计。
1527 |各分类当前未解决事件统计|突发事件|反映当前正在处理中的事件分布情况
1528 |当前各个状态的事件统计|突发事件|当前各个状态的事件统计
1529 |当前所有未关闭事件列表|突发事件|用于服务台查看当前需要解决的事件的详细信息
1530 |当前分配给自己的未解决事件|突发事件|用于服务台以及支持人员查看需要自己解决事件。 此列表中包括分配给本组， 且未制定支持人员的事件。
1531 |高优先级突发事件列表|突发事件|需要优先解决的突发事件列表
1532 |超时的事件列表|突发事件|用于事件经理了解目前急需解决的事件。此列表可以包括即将超时的事件。
1533 |问题管理备选事件列表|突发事件|列出支持人员标注的问题管理备选事件， 在事件管理流程回顾时进行分析， 进入问题管理流程。
1534
1535
深圳市艾拓先锋企业管理咨询有限公司