Version 16.1 by superadmin on 2024/10/29, 16:51
Show last authors
1 ​
2
3 = **1. 流程目的** =
4
5 事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：
6
7 * **在成本允许的范围内尽快恢复IT服务**
8 ** 快速响应服务请求（电话/Web/邮件等）
9 ** 用户在线获得帮助
10 ** 沟通事件解决的状态
11 ** 和客户确认事件的解决
12 * **进行事件控制**
13 ** 按规范记录事件
14 ** 就事件的优先级，影响度 进行分类
15 ** 分析，诊断，必要时进行升级
16 ** 监视并结束事件
17 ** 进行定期服务流程回顾
18 * **提供IT管理信息**
19 ** 人力资源利用情况
20 ** 故障处理情况
21 ** 支持效率
22
23 = ** ** =
24
25 = ** ** =
26
27 = **2. 流程主要内容** =
28
29 事件(Incidents)是中断业务流程和降低IT服务质量的错误。事件管理流程帮助迅速解决这些事件，并最小化对于业务的不利影响。流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容：
30
31 * **事件接收和记录**
32
33 这个环节是事件管理流程的起点。所有用户或系统报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。
34
35 该环节的关键是信息的准确性和完整性。
36
37 * **分类和在线支持**
38
39 事件可以是一个申告/故障/告警/咨询，对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。
40
41 该环节的关键是必要的问题库支持和正确的事件分派。
42
43 * **调查和诊断**
44
45 若支持人员无法解决事件，可运用问题库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。
46
47 * **解决和恢复**
48
49 支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认。
50
51 * **优先级为紧急的事件（紧急事件）和事件升级**
52
53 对于紧急事件，服务台应立即提交给一线人员，由一线人员判断，上报给事件经理和相关的管理层，由事件经理决定紧急事件的处理方式，确保其得到最快速的解决。
54
55 当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。
56
57 * **结束事件**
58
59 当用户确认事件解决后，此时可结束该事件，并在必要时更新问题库。
60
61 = ** ** =
62
63 = ** ** =
64
65 = **3. 与其他流程的关系** =
66
67 * **和问题管理流程的关系**
68
69 事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。
70
71 * **和配置管理流程的关系**
72
73 需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。
74
75 * **和变更管理流程的关系**
76
77 服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，涉及到需要对基础架构、应用系统及操作系统等进行变更的需要发起变更请求来解决事件。
78
79 = ** ** =
80
81 = ** ** =
82
83 = **4.  关键角色、职责定义** =
84
85 == ** ** ==
86
87 == **4.1 服务台人员** ==
88
89 流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的管理流程和角色的目的是为了在充分满足流程所需角色的基础上，为具体的实现提供足够的灵活性。
90
91 事件管理流程主要分为以下几个职责/角色，分别简述如下：
92
93 服务台人员负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到合适的一线支持工程师。
94
95 **职责：**
96
97 1. 在指定的响应时间内响应所有服务台热线电话、邮件、工单等事件报告；
98 1. 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等；
99 1. 为事件进行适当的分类、为事件分配优先级等属性；
100 1. 尝试使用知识库、初步诊断、分析相关信息等方式解决事件；
101 1. 如果服务台不能解决事件，应当将事件分配给最合适的一线支持小组或来处理；
102 1. 检查事件记录的处理进度，保持与用户的联系，适时通知事件处理进展；
103 1. 在事件处理过程中，催办事件处理进度
104 1. 与用户确认事件解决方案及用户满意度反馈，关闭事件。
105
106 **技能要求：**
107
108 1. 熟悉技术平台和技术环境
109 1. 较强的沟通能力
110 1. 对简单的故障要有快速诊断和解决的能力
111 1. 熟悉事件处理流程
112
113 **人员按排建议：**
114
115 * 建议总公司服务台设置3人，分别负责受理桌面支持、核心业务系统类、非核心业务系统（包括其他应用系统、网络接入等）三大类事件。各分公司服务台设置2-3人受理各类事件。结合分公司实际情况，若事件单日常数量较多，服务台人数可以进行增加。
116
117 == ** ** ==
118
119 == **4.2 一线支持人员** ==
120
121 在ITIL体系中，一线支持人员负责对服务台无法解决的事件进行快速有效的分析，提出解决方案以尽快恢复服务，并在必要时提供现场支持。
122
123 **职责：**
124
125 1. 决定需要采取何种措施恢复服务并实施有效的行动
126 1. 必要时提供现场支持
127 1. 根据优先级提供有效的解决方案
128 1. 更新事件解决信息，已解决的事件转回服务台，由服务台关闭事件
129 1. 如果一线不能解决这个事件，应当决定选择最合适的二线支持小组/人员来处理
130
131 **技能要求：**
132
133 1. 熟悉技术平台和技术环境
134 1. 较强的沟通能力
135 1. 快速诊断事件和解决事件的能力
136 1. 熟悉事件处理流程
137
138 **人员按排建议：**
139
140 1. 建议将分公司IT部门日常维护（包括硬件、软件、开发等）人员纳入一线支持中，按日常所管系统类型或设备类型划分到相应维护支持组中
141 1. 分公司具有开发人员的，将开发人员纳入到应用系统支持组中
142 1. 如分公司技术力量较强，可将一线支持各组根据技术能力划分为初级组、高级组
143 1. 对于地市技术力量薄弱的，将地市人员按岗位技能纳入省级公司相应一线支持组中
144 1. 对于地市技术力量较强的，可以考虑建立与省级公司平级的支持组
145
146 == ** ** ==
147
148 == **4.3 二线支持人员** ==
149
150 二线支持人员是相关问题领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。
151
152 **职责:**
153
154 1. 进行事件的深入调查研究
155 1. 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动
156 1. 必要时引入供应商的支持
157 1. 及时提供有效解决方案
158 1. 与其他二线小组合作，确定解决方案
159 1. 已解决的事件转回服务台，由服务台关闭事件
160
161 **技能要求：**
162
163 1. 深厚的技术背景，对所维护范畴的技术深入掌握
164 1. 熟悉事件处理流程
165
166 **人员按排建议：**
167
168 * 主要由总公司各类业务系统及基础设施维护专家组成，技术力量较强的分公司的资深维护人员组成虚拟团队
169
170 == ** ** ==
171
172 == **4.4 三线支持人员** ==
173
174 **职责：**
175
176 1. 从研发的角度进行事件的研究；
177 1. 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动，如发布临时补丁等；
178 1. 及时提供有效解决方案；
179 1. 已解决的事件转回服务台，由服务台关闭事件。
180
181 **技能要求：**
182
183 1. 具备开发公司内各类应用系统的能力，对所维护范畴的技术深入掌握；
184 1. 熟悉事件处理流程。
185
186 **人员按排建议：**
187
188 * 由总公司开发人员及厂商代维人员组成，以及分公司开发力量较强人员组成虚拟团队
189
190 == ** ** ==
191
192 == **4.5 事件经理** ==
193
194 事件经理负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。
195
196 **职责：**
197
198 1. 负责对重大、紧急事件的解决协调资源，保证故障的最终排除；
199 1. 当事件优先级为紧急或者事件将超过规定的时限，负责按照升级方法对事件进行处理确保有效协调资源，促进各类角色小组（如一线支持、二线支持）快速恢复正常服务；
200 1. 确保和问题管理流程经理的有效合作；
201 1. 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题。
202
203 **技能要求：**
204
205 1. 了解技术架构和技术环境；
206 1. 较强的口头表达能力和与用户沟通技巧；
207 1. 处理纠纷的能力；
208 1. 深刻了解事件管理流程；
209 1. 较强的领导能力。
210
211 **人员按排建议：**
212
213 * 由分公司及总公司主管应用系统维护工作的领导担任
214
215 == ** ** ==
216
217 == **4.6 事件管理流程负责人** ==
218
219 事件管理流程负责人从宏观上监控流程，确保事件流程在信息技术中心范围内被正确的执行。当流程不能够适应cl发展需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。
220
221 **职责：**
222
223 1. 确定管理流程的衡量指标
224 1. 确保事件流程能够取得管理层的参与和支持
225 1. 确保事件流程符合cl实际状况和公司 IT发展战略
226 1. 总体上管理和监控流程，建立事件流程实施、评估和持续优化机制
227 1. 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进(假如增加或合并流程的角色)，从而实现可持续提高
228
229 **技能要求：**
230
231 1. 深刻理解事件管理流程；
232 1. 能够很好地理解业务对于事件管理的需求；
233 1. 有决策权，能够确保事件管理流程设计要求在实施项目中得到贯彻和执行；
234 1. 具有很好的沟通技能，获得所需资源。
235
236 **人员按排建议：**
237
238 * 由总公司IT部门领导担任
239
240 == ** ** ==
241
242 == **4.7 实际岗位与方案角色的映射** ==
243
244 |(% colspan="5" %)**事件管理流程**
245 |**角色**|(% colspan="2" %)**角色细分**|**说明**|**成员**
246 |(% rowspan="2" %)服务台|总公司服务台| |(((
247 职责：负责受理办公管理、管理决策、核心运营、销售客服、桌面支持五大类事件。
248
249 建议总公司服务台设置3人
250 )))|
251 |分公司服务台| |(((
252 职责：负责受理各类事件。
253
254 岗位建议：建议各分公司服务台设置2-3人，结合分公司实际情况，若事件单日常数量较多，服务台人数可以进行增加，建议对应岗位包括服务支持管理岗、应用管理岗、数据管理岗
255 )))|
256 |(% rowspan="6" %)一线支持|(% rowspan="3" %)总公司一线支持|基础设施维护支持组|(((
257 职责：负责总公司小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件的基础维护工作
258
259 岗位建议：建议由总公司运行管理处、网络管理处负责各基础设施领域维护工作的技术人员担任
260 )))|
261 |应用系统支持组|(((
262 职责：负责总公司各类应用系统的维护支持工作
263
264 岗位建议：建议由负责各类应用系统维护工作的技术人员担任
265 )))|
266 |桌面支持组|(((
267 职责：负责总公司桌面支持工作
268
269 岗位建议：建议由代理服务处负责桌面维护工作的技术人员担任
270 )))|
271 |(% rowspan="3" %)(((
272 分公司一线支持
273
274 （地市公司直接纳入分公司一线支持）
275 )))|应用系统支持组|(((
276 职责：负责分公司自有应用系统的支持工作以及对总公司应用系统的初始支持工作
277
278 岗位建议：建议由分公司负责各类应用系统维护工作的技术人员担任，建议对应岗位包括应用管理岗、地市分公司应用管理岗、数据管理岗、应用开发岗
279 )))|
280 |基础设施维护支持组|(((
281 职责：负责分公司小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件的基础维护工作
282
283 岗位建议：建议由分公司信息技术部门各基础设施领域维护工作的技术人员担任，建议对应岗位包括设备管理岗、系统管理岗、安全岗、网络管理岗、运行维护岗、地市分公司设备管理岗
284 )))|
285 |桌面支持组|(((
286 职责：负责分公司桌面维护支持工作
287
288 岗位建议：由负责分公司桌面维护支持工作人员的担任，建议对应岗位包括服务支持管理岗
289 )))|
290 |(% rowspan="2" %)二线支持|(% rowspan="2" %)总公司二线支持|应用系统运维专家组|(((
291 职责：负责总公司应用系统包括核心应用系统及非核心应用系统的维护工作
292
293 岗位建议：由负责总公司各类应用系统资深技术人员担任，可以借调分公司相关人员，形成虚拟团队
294 )))|
295 |基础设施维护专家组|(((
296 职责：负责分公司小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件的维护工作
297
298 岗位建议：由总公司运行管理处、网络管理处负责各领域维护工作的资深技术人员担任，可以借调分公司相关人员，形成虚拟团队
299 )))|
300 |(% rowspan="2" %)三线支持|(% rowspan="2" %)总公司三线支持|应用系统开发组|(((
301 职责：负责总公司应用系统包括核心应用系统及非核心应用系统的开发、修改、优化工作
302
303 岗位建议：由总公司核心运营开发处、销售客服开发处、管理决策开发处、电子商务开发处开发人员担任，可以借调分公司相关开发人员，形成虚拟团队
304 )))|
305 |代维厂商组|总公司的厂家支持，可以细分为IBM、HP等|
306 |(% rowspan="2" %)事件经理|总公司| |(((
307 职责：负责督导与监控总公司事件处理过程的正常运转，接收事件的升级通知和处理超时通知等
308
309 岗位建议：建议在总公司设置事件经理1人，由总公司应用管理处处长或副处长担任
310 )))|
311 |分公司| |(((
312 职责：负责督导与监控分公司事件处理过程的正常运转，接收事件的升级通知和处理超时通知等
313
314 岗位建议：建议在各分公司设置事件经理1人，由分公司分管应用维护的领导担任
315 )))|
316 |事件管理流程负责人|(% colspan="2" %) |(((
317 职责：负责确定管理流程的衡量指标，从宏观上监控流程，当流程不能够适应cl发展需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高
318
319 岗位建议：建议在总公司设置事件管理流程负责人1名，由总公司信息技术部相关领导担任
320 )))|
321
322 **说明：**一、二、三线分组可进行扩充，各分公司可将现有分组提交到总公司，由总公司统一协调配置
323
324 = =
325
326 = =
327
328 = **5. 流程执行原则** =
329
330 == **5.1 常规原则** ==
331
332 1. 所有IT和信息技术中心事件管理范围内发生的事件，都应该记录在IT服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件
333 1. 所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别
334 1. 应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估
335 1. 应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程
336
337 == ** ** ==
338
339 == **5.2流程关联原则** ==
340
341 * 和问题管理的关联
342 ** 所有优先级为紧急的事件在恢复服务后，都应该创建问题单（问题单必须和事件单建立关联）
343 ** 支持人员在解决事件的过程中，可以通过问题记录查找相应的解决方案
344 * 和变更管理的关联
345 ** 事件处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和事件单建立关联），变更完成后，继续事件单的处理
346 ** 紧急事件（优先级为紧急的事件，下同）的处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和紧急事件单建立关联
347 * 和配置管理的关联
348 ** 事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位
349 ** 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联
350
351 == ** ** ==
352
353 == **5.3 所有权原则** ==
354
355 所有权原则用来确保每个事件在任何时段都有适当的人员负责，服务台是事件的负责人。
356
357 * 由IT用户申报的事件单，服务台员工是该事件的责任人，必须确保事件得到有效跟踪与解决，并负责事件单的关闭
358
359 == ** ** ==
360
361 == **5.4 再分派原则** ==
362
363 事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分配到个人，或者分配到组（服务台、一线支持、二线支持、三线支持），再由组内的支持人员处理。事件单的重分派次数不应该超过5次。
364
365 * 服务台将事件单分配给一线支持
366 * 一线支持可以将事件单重新分配给服务台，其他一线支持组（人员），二线支持组（人员）
367 * 二线支持可以将事件单重新分配给服务台，一线支持组（人员），其他二线支持组（人员），三线支持组（人员）
368 * 三线支持可以将事件单重新分配给服务台，二线支持组（人员），其他三线支持组（人员）
369
370 == ** ** ==
371
372 == **5.5 重复事件原则** ==
373
374 重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。
375
376 * 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标
377 * 如果服务台可以判断到重复事件，则由服务台对重复事件标识，否则由一线支持人员负责重复事件的处理
378
379 == ** ** ==
380
381 == **5.6 关闭原则** ==
382
383 由IT用户申报的事件单，关闭必须由服务台完成。
384
385 * 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时，结束代码为"变通方法解决"。服务台负责和IT用户再次确认事件的解决
386 * 由IT用户认可获得关闭的事件单的结束代码为"成功解决"关闭
387 * 已解决的事件单如果没有得到IT用户的认可，则首先关闭该事件单，结束代码修改为"不成功"，同时创建一个新的事件单重新分配到原处理人员继续处理
388 * 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单
389 * IT和信息技术中心的维护人员（一线、二线或三线）自行创建的事件单，本着"谁开单，谁负责关闭"的原则
390 * 监控平台产生的事件发送到服务台，由服务台分派，处理人员解决并关单
391
392 == ** ** ==
393
394 == **5.7 升级原则** ==
395
396 制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。
397
398 * 优先级为紧急的事件，服务台应立即升级到相应一线支持，由一线支持再次确认，如果确认了优先级为紧急，则立即升级到事件经理，并通知相应的管理层（通过IT服务管理平台），由事件经理启动紧急事件处理流程
399 * 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理
400 * 服务台和一线支持应及时将不能解决的事件升级到下一级，若未及时升级，事件经理应及时介入，负责协调升级处理
401
402 == ** ** ==
403
404 == **5.8 人员岗位与角色落实原则** ==
405
406 * 分公司技术力量较强的一线各维护支持组根据实际情况可按能力划分初级维护支持组和高级维护支持组，也可划分为一个组
407 * 如分公司具有开发人员，可将开发人员纳入到一线应用维护组
408 * 地市支持力量薄弱的，可将地市人员按岗位技能纳入省级公司相应支持组
409 * 地市支持力量较强的，可建立相对独立的支持维护组
410 * 目前流程中的各角色的分组可以进行扩充，由于此项目是全国性项目，在收集各分公司反馈后，由总公司进行统一协调配置
411
412 == ** ** ==
413
414 == **5.9 工单流转原则** ==
415
416 * 分公司事件管理流程负责处理分公司自有应用系统及基础设施产生的事件以及对总公司应用系统及基础设施产生的事件进行尝试解决
417 * 总公司事件管理流程负责处理总公司应用系统及基础设施产生的事件
418 * 分公司服务台负责受理分公司服务对象提交的所有请求，分公司服务台首先对用户提交的请求进行尝试解决，不能解决的通过服务目录自动提交到分公司一线相应支持组或人
419 * 总公司服务台负责受理总公司及成员公司提交的所有请求，总公司服务台首先对用户提交的请求进行尝试解决，不能解决的通过服务目录自动提交到总公司一线相应支持组或人
420 * 分公司一线负责处理分公司服务台转派的工单，对于属于分公司自有应用系统及基础设施产生的事件在一线内部处理解决，不能解决的将工单提交到分公司事件经理，由分公司事件经理协调资源处理；对于属于总公司应用系统及基础设施产生的事件首先在分公司一线内部尝试解决，不能解决的提交到二线相应支持组
421 * 总公司一线负责处理总公司服务台转派的工单，首先在一线内部尝试解决，不能解决的提交到二线相应专家组
422 * 二线负责处理分公司一线及总公司一线转派的工单，首先在二线内部尝试解决，不能解决的提交到三线相应支持组
423 * 三线负责处理二线转派的工单，首先在三线内部尝试解决，对于三线不能解决的将工单提交到总公司事件经理，由总公司事件经理协调资源进行处理
424 * 对于公司信息技术部内部人员创建的工单，根据服务目录直接转派给本公司一线相应支持组组长，由组长视情况手工分派给本组人员进行处理
425 * 对于公司信息技术部内容人员创建的工单，关闭原则是‘谁创建工单，谁关闭工单’
426
427 = ** ** =
428
429 = ** ** =
430
431 = **6. 流程相关定义** =
432
433 == **6.1 事件信息项** ==
434
435 事件单必须包含如下事件信息项：
436
437 |**序号**|**信息项**|**是否必填**|**说明**
438 |(% colspan="4" %)事件记录和分类时填写：
439 |1|请求人信息|是|事件申报人的信息，包括：登录名、姓名、分公司、部门、电子邮件、办公电话、手机（手工填写）
440 |2|事件分类|是|参见“事件分类”定义
441 |3|事件性质|是|参见“事件性质”定义
442 |4|事件来源|是|参见“事件来源”定义
443 |5|事件所属系统类型|是|参见“事件所属系统类型”定义
444 |6|事件发生时间|是|(((
445 针对故障：指的是业务中断的实际时间 （可能早于登记时间，需要手工填写）
446
447 针对其他：缺省值等于登记时间
448
449 事件发生时间必须小于或等于登记时间
450 )))
451 |7|事件发生单位|是|树形目录（三级，总公司－省公司－地市）
452 |8|事件发生地点|否|事件发生的地点 （手工填写）描述性字段，不做为日后数据索引、统计，默认为事件发生单位
453 |9|事件简要简述|是|事件的简要描述（手工填写）
454 |10|事件详细描述|是|对于整个事件内容的详细描述（手工填写）
455 |11|分配对象|是|被分配的技术支持组（按服务目录自动分派）
456 |12|事件优先级|是|参见“事件优先级”定义
457 |13|事件影响度|是|参见“事件影响度”定义
458 |14|重复事件标记|否|标记为重复事件（手工填写）
459 |15|关联配置项|否|记录出现故障的配置项代码（系统自动关联）
460 |16|附件|否|上传附件
461 |(% colspan="4" %)提交事件工单时，系统自动产生
462 |17|事件ID|是|事件单流水号（系统自动产生）
463 |18|建单人（受理人）|是|创建事件请求工单的记录人
464 |19|登记时间|是|在服务台生成事件记录的时间（系统自动产生）
465 |20|事件状态|是|参见“事件状态”定义
466 |21|事件完成期限|是|对应每一个事件优先级，系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限 （系统自动产生）
467 |同14|关联配置项|否|记录出现故障的配置项代码（手工填写）
468 |同15|附件|否|上传附件
469 |(% colspan="4" %)一、二、三线尝试解决时填写：
470 |22|业务恢复时间|是|针对故障的业务恢复实际时间（手工填写）
471 |23|事件日志|是|反映事件信息项的变化历史，如一个事件在处理过程中事件状态变化的时间点等信息（系统自动产生）
472 |24|解决方案|是|事件解决方案的描述（手工填写）
473 |25|故障厂商|是|记录故障厂商或集成商信息（手工选择）
474 |26|重复事件标记|否|标记为重复事件（手工选择）
475 |(% colspan="4" %)一、二、三线尝试解决时，系统自动产生
476 |同19|事件状态|是|参见“事件状态”定义
477 |27|实际开始时间|是|记录事件状态到XX处理中的时间（系统自动产生）
478 |28|事件解决人|是|事件的最终解决人（系统填写）
479 |29|处理是否超时|否|参见“处理是否超时”定义（系统自动产生）
480 |30|实际完成时间|是|记录事件最后解决的时间（系统自动产生）
481 |31|历时|是|“实际完成时间”-“事件发生时间”（系统自动产生）
482 |(% colspan="4" %)关闭工单时填写
483 |32|用户反馈|是|参见“用户反馈”定义
484 |33|事件结束代码|是|参见“事件结束代码”定义
485 |34|事件解决人角色|是|参见“事件解决人角色”定义
486 |35|事件关闭时间|是|记录事件被关闭的事件
487
488 == ** ** ==
489
490 == **6.2 事件性质** ==
491
492 根据clIT支撑系统的业务要求和管理要求，定义如下四类事件：
493
494 |**编号**|**代码**|**描述**
495 |1|故障|指因IT支撑系统错误或反映支撑系统部分或全部功能不能正常使用的报障；
496 |2|申告|与IT支撑系统相关的用户投诉，如信息技术部各处室等业务受理部门转来的因支撑系统问题引发的投诉
497 |3|告警|监控平台自动产生的没有影响到系统正常使用的告警
498 |4|咨询|指对系统操作、业务流程等方面的求助和询问
499
500 == ** ** ==
501
502 == **6.3 事件来源（非必填项）** ==
503
504 事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种：
505
506 |**编号**|**代码**|**描述**
507 |1|用户报告|用户或维护人员通过电话/邮件/传真报告的事件，服务台人员手工创建事件单
508 |2|内部IT人员开单|IT部门内部（一线/二线人员）提交的事件
509 |3|监控系统|
510
511 == ** ** ==
512
513 == **6.4 事件所属系统类型** ==
514
515 根据目前信息技术中心支撑的应用系统和二级分类的划分定义事件所属系统类型，当事件发生时，应该由服务台初步定位是哪个系统及二级分类出现问题，由一线进行进一步的明确。
516
517 |**业务系统分类**|**子业务系统分类**|**简称**
518 |(% rowspan="3" %)办公管理|IT服务管理系统|ITSM
519 |综合办公系统|
520 |电子邮件系统|请填写简称
521 |电子商务|网上招聘系统|CORS
522 |(% rowspan="11" %)管理决策|团体年金报表子系统|GARS
523 |财务计算机管理系统|CLAF
524 |集团财务计算机管理系统|GCLAF
525 |cl财务报表辅助系统|EASY-REPORT
526 |大中城市业绩考核分析系统|CSIS
527 |财务分析系统|LIFA
528 |基础率分析系统|EAS
529 |精算系统|ATMS
530 |每日业务快报系统|ZHCX
531 |统计信息系统|TJXX
532 |审计系统|AMS
533 |(% rowspan="16" %)核心运营|综合业务处理系统7版|CBPS7
534 |集团综合业务处理系统7版|NBPS
535 |老业务处理系统|OBPS
536 |综合业务处理系统8版|CBPS8
537 |出单管理系统(七版)|Printpro
538 |档案影像管理系统|CIMS
539 |单证管理系统|CVMS
540 |打印管理系统|CPMS
541 |数据清理系统|CLEANER
542 |投连万能处理系统|UBPS
543 |团体年金核心业务处理系统|GAPS
544 |中介业务处理系统|ABPS
545 |统括业务处理系统|UNITE
546 |再保险系统|RBPS
547 |健康意外险系统|HDPS
548 |互联网销售系统|ISS
549 |(% rowspan="11" %)销售客服|团体年金大客户支持子系统|GACS
550 |团体年金报价子系统|GAPS
551 |团体年金销售支持系统|GA3S
552 |个人代理人管理信息系统|AMIS
553 |讲师管理系统|TMIS
554 |会员管理系统2005   |MMIS
555 |个人代理人营销支持系统|E-MSS
556 |大客户支持系统|anntsuport
557 |网络查询系统|netquery
558 |cl呼叫中心系统|CALL CENTER
559 |cl短信系统|SMS
560 |其他|其他系统类|OTS
561
562 **说明**：第一层为”其它”的话，分公司可以对其子类可以扩充并提交到总公司，由总公司统一协调配置
563
564 == ** ** ==
565
566 == **6.5 事件分类** ==
567
568 分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。
569
570 事件的分类层次设计不超过三层，第一级分类，称之为"一级分类"，第二级分类，称之为"二级分类"，第三级分类，称之为"三级分类"。
571
572 |**一级分类**|**二级分类**|**三级分类**
573 |(% rowspan="2" %)服务器SR|小型机（EPS）|
574 |PC 服务器（SPC）|
575 |(% rowspan="3" %)存储设备 RD|磁盘阵列（RAD）|
576 |磁带库（TAP）|
577 |其他存储设备（OTR）|
578 |(% rowspan="8" %)网络NW|(% rowspan="2" %)交换机（SWT）|网络交换机（SWT）
579 |光纤交换机（FST）
580 |路由器（RUT）|
581 |防火墙（FRW）|
582 |VPN网关（VPG）|
583 |安全网关（SEG）|
584 |链路（LNK）|
585 |其他网络设备（OTN）|
586 |(% rowspan="4" %)终端TR|台式机（COM）|
587 |笔记本（NTB）|
588 |字符终端（CTR）|
589 |图形终端（GTR）|
590 |(% rowspan="7" %)外设及其他PR|(% rowspan="4" %)外设（DDV）|打印机（PRT）
591 |扫描仪（SCN）
592 |绘图仪（DRW）
593 |其他（SSO）
594 |(% rowspan="2" %)机房（DCE）|监控系统（）
595 |消防系统
596 |其他（OTR）|
597 |(% rowspan="7" %)软件SW|(% rowspan="3" %)应用软件APP|自主开发（SDV）
598 |外包开发（ODV）
599 |商业软件（FRD）
600 |(% rowspan="4" %)系统软件SYS|数据库（SDB）
601 |操作系统（OPS）
602 |中间件（SMD）
603 |其他（SYO）
604 |(% rowspan="6" %)文档DC|管理文档（ADC）|
605 |技术文档（TDC）|
606 |维护文档（ODC）|
607 |工程文档（PDC）|
608 |(% rowspan="2" %)合同CRT|产品购买合同（PUS）
609 |维护合同（MAN）
610 |(% rowspan="3" %)应用系统AP|应用系统名称（API）|
611 |应用系统模块（APM）|
612 |其他应用（APO）|
613
614 == ** ** ==
615
616 == **6.6 事件优先级** ==
617
618 优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级（紧急、高、中、低）。
619
620 |**编号**|**优先级代码**|**描述**
621 |1|紧急|(((
622 1. 重要系统不可用
623 1. 因系统原因数据处理错误，导致大量用户投诉
624 1. 来自新闻媒体、消费者协会、国家行政机关（工商、物价等）的反映或申告
625 1. 部分重要数据丢失，且无法全部恢复
626 )))
627 |2|高|(((
628 1. 业务系统不可用，影响面为全北京市、某个分公司，或者多个非关键地区
629 1. 系统中的某一业务不可用，影响面为全北京市、某个分公司，或者多个非关键地区
630 )))
631 |3|中|(((
632 1. 一般性系统故障
633 )))
634 |4|低|(((
635 1. 一般单个用户申告
636 1. 业务咨询
637 )))
638
639 当故障发生时，为了在判断优先级时增强实际可操作性，可以根据故障的影响范围和业务系统的关键程度在优先级映射表中定位优先级。故障的影响范围可以根据配置项中定义的“影响范围”和用户报障描述来确定。
640
641 |(% colspan="2" %)**系统 影响范围**|**全北京市或某一分公司**|**至少包括一个关键地区**|**多个非关键地区**|**一个非关键地区**
642 |(% rowspan="3" %)系统名称（任一模块）|功能点A|紧急|紧急|高|高
643 |功能点B|高|高| |
644 |功能点C|高|高| |
645
646 == ** ** ==
647
648 == **6.7 事件响应时限和解决时限** ==
649
650 在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制，一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念，同时，也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理，同时，如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。
651
652 响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间；
653
654 解决时限指的是事件状态从“已登记”到“已解决”经过的时间；
655
656 **事件优先级对应的事件响应时限和解决时限参考下表（以下时间是24×7工作时间）：**
657
658 |**编号**|**优先级代码**|**响应时限要求**|**解决时限要求**
659 |1|紧急|30分钟|4小时
660 |2|高|1小时|8小时
661 |3|中|4小时|48小时
662 |4|低|8小时|72小时
663
664 **事件发生时的通告定义**
665
666 通知人员列表的用途：当IT服务管理平台收到事件时，自动按照表中的人员列表发出邮件或短信通知。
667
668 |**优先级别**|**通知人员列表**
669 |紧急|部门主管，相应事件经理，一、二、三线支持人员
670 |高|部门主管，相应事件经理，一、二线支持人员
671 |中|通知一、二线支持人员
672 |低|通知一线支持人员
673
674 **超出响应时间的通告定义**
675
676 通知人员列表的用途：当IT服务管理平台判断到响应时限已经超出，则自动按照表中的人员列表发出邮件或短信通知。
677
678 |**优先级别**|**通知人员列表**|**事件响应时限**
679 |紧急|部门主管，相应事件经理，一、二、三线支持人员|30分钟
680 |高|部门主管，相应事件经理，一、二线支持人员|1小时
681 |中|部门主管，相应事件经理，一、二线支持人员|4小时
682 |低|相应事件经理，服务台/一、二线支持人员|8小时
683
684 **超出和即将超出解决时限的通告定义**
685
686 通知人员列表的用途：当IT服务管理平台判断到解决时限已经或即将超出，则自动按照表中的人员列表发出邮件或短信通知。
687
688 |**优先级别**|**通知时间**|**通知人员列表**|**事件解决时限**
689 |(% rowspan="2" %)紧急|3小时|部门主管，相应事件经理，一、二、三线支持人员|(% rowspan="2" %)4小时
690 |4小时|部门主管，相应事件经理，一、二线支持人员
691 |(% rowspan="2" %)高|7小时|部门主管，相应事件经理，一、二线支持人员|(% rowspan="2" %)8小时
692 |8小时|部门主管，相应事件经理，一、二线支持人员
693 |(% rowspan="2" %)中|47小时|部门主管，相应事件经理，一、二线支持人员|(% rowspan="2" %)48小时
694 |48小时|部门主管，相应事件经理，一、二线支持人员
695 |(% rowspan="2" %)低|71小时|相应事件经理，一、二线支持人员|(% rowspan="2" %)72小时
696 |72小时|相应事件经理，一、二线支持人员
697
698 == ** ** ==
699
700 == **6.8 事件影响度** ==
701
702 事件影响度用于衡量事件所影响业务的严重程度。严重程度通常通过事件所影响的人数、关键系统数以及服务故障所造成的损失来设定。
703
704 定义事件影响度等级的因素有：
705
706 * 是否影响了核心业务
707 * 所影响的用户数
708 * 服务失效的影响范围和时长
709
710 事件影响度在事件的生命周期中是可以改变的，例如，初始等级为严重的故障会随着服务失效的时间变成重大故障，所以事件的影响度应在事件得到解决（服务恢复）后重新确认。
711
712 事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。
713
714 |**编号**|**影响度代码**|**事件性质**|**描述**
715 |(% rowspan="2" %)1|(% rowspan="2" %)重大|故障|(((
716 * 全国半数以上地区或关键地区的业务系统中断超过6小时；
717 * 全国半数以上地区或关键地区的营业、综合帐务、客服中任一业务中断超过3小时；
718 * 全国半数以上地区或关键地区的综合结算业务处理中断超过24小时；
719 * 半数以下地区全业务中断超过6小时；
720 )))
721 |申告|(((
722 * 对人寿公司造成巨大损失产生严重后果和不良影响的；
723 * 来自新闻媒体、消费者协会、国家行政机关的反映或申告；
724 )))
725 |(% rowspan="2" %)2|(% rowspan="2" %)严重|故障|(((
726 * 全国半数以上地区或关键地区的业务系统中断大于10分钟、小于6小时；
727 * 全国半数以上地区或关键地区的营业、综合帐务、客服等业务中断均大于10分钟、小于3小时；
728 * 全国半数以上地区或关键地区的综合结算业务处理中断大于2小时、小于24小时；
729 * 半数以下地区全业务中断大于10分钟、小于6小时。
730 )))
731 |申告|(((
732 * 数据错误导致产生大量的错单；
733 * 涉及到高额问题的申告；
734 * 用户在营业现场反映激烈
735 )))
736 |(% rowspan="3" %)3|(% rowspan="3" %)一般|故障|(((
737 * 系统内局部出现问题，不影响整个系统运行，不影响业务处理的故障
738 )))
739 |申告|(((
740 * 不属于重大申告和严重申告的用户申述
741 )))
742 |告警|(((
743 * 不影响系统的监控平台告警
744 )))
745 |4|无|咨询|(((
746 * 一般数据查询或者使用指导
747 )))
748
749 == ** ** ==
750
751 == **6.9 事件状态** ==
752
753 事件状态代码表明事件所处的处理状态，事件状态如下：
754
755 |**编号**|**代码**|**描述**
756 |1|已登记|新开事件记录或事件已创建
757 |2|分配到服务台|事件已分配给服务台人员
758 |3|服务台处理中|服务台人员已接手处理事件
759 |4|分配到一线|事件已分配到一线支持，一线还未响应
760 |5|一线处理中|一线支持人员已接手处理事件
761 |6|分配到二线|事件已分配到二线支持，二线还未响应
762 |7|二线处理中|二线支持人员已接手处理事件
763 |8|分配到三线|事件已分配到三线支持，三线还未响应
764 |9|三线处理中|三线支持人员已接手处理事件
765 |10|已解决|事件已解决，支持人员联系用户验证事件是否获得解决
766 |11|关闭|事件已关闭
767
768 事件状态变迁图用来标明：当一个事件单处于某个状态时，它可以去到的下一个状态。
769
770 ​
771
772 (% style="text-align:center" %)
773 [[image:1730190194331-786.png]]
774
775
776 * 当前状态为‘已登记’状态时，可迁移的状态
777
778 |**状态**|**合法**|**描述**
779 |已登记|否|已登记为事件单初始状态
780 |分配到服务台|是|用户提交事件请求，首先分派到服务台
781 |服务台处理中|否|
782 |分配到一线|否|
783 |一线处理中|否|
784 |分配到二线|否|
785 |二线处理中|否|
786 |分配到三线|否|
787 |三线处理中|否|
788 |已解决|否|
789 |已关闭|否|
790
791 * 当前状态为‘分配到服务台’状态时，可迁移的状态
792
793 |**状态**|**合法**|**描述**
794 |已登记|否|
795 |分配到服务台|是|服务台的人员将分配给本人的事件单分配给服务台或者服务台的其他人员
796 |服务台处理中|是|服务台人员开始尝试处理事件单
797 |分配到一线|是|服务台组人员将事件单分配给一线支持组
798 |一线处理中|否|
799 |分配到二线|否|
800 |二线处理中|否|
801 |分配到三线|否|
802 |三线处理中|否|
803 |已解决|否|
804 |已关闭|是|当事件处理范围不在信息技术中心或误报或可忽略时，可直接关闭
805
806 * 当前状态为‘分配到一线’状态时，可迁移的状态
807
808 |**状态**|**合法**|**描述**
809 |已登记|否|
810 |分配到服务台|否|
811 |服务台处理中|否|
812 |分配到一线|是|一线支持人员将分配给本人的事件单分配给一线支持组或组内的其他人
813 |一线处理中|是|一线支持人员，接受分配的事件单，并开始处理
814 |分配到二线|否|
815 |二线处理中|否|
816 |分配到三线|否|
817 |三线处理中|否|
818 |已解决|否|
819 |已关闭|否|
820
821 * 当前状态为“一线处理中”状态时，可迁移的状态
822
823 |**状态**|**合法**|**描述**
824 |已登记|否|
825 |分配到服务台|否|
826 |服务台处理中|否|
827 |分配到一线|是|一线支持人员将分配给本人的事件单分配给一线支持组或组内的其他人
828 |一线处理中|否|
829 |分配到二线|是|一线支持人员将事件单分配给二线支持组或二线支持组内的其他人
830 |二线处理中|否|
831 |分配到三线|否|
832 |三线处理中|否|
833 |已解决|是|一线支持找到解决方案或者变通方法，解决了分配的事件单
834 |已关闭|否|
835
836 * 当前状态为‘分配到二线’状态时，可迁移的状态
837
838 |**状态**|**合法**|**描述**
839 |已登记|否|
840 |分配到服务台|否|
841 |服务台处理中|否|
842 |分配到一线|否|
843 |一线处理中|否|
844 |分配到二线|是|二线支持人员将事件单分配给二线支持组或二线支持组内的其他人
845 |二线处理中|是|二线支持人员，接受分配的事件单，并开始处理
846 |分配到三线|否|
847 |三线处理中|否|
848 |已解决|否|
849 |已关闭|否|
850
851 * 当前状态为‘二线处理中’状态时，可迁移的状态
852
853 |**状态**|**合法**|**描述**
854 |已登记|否|
855 |分配到服务台|是|
856 |服务台处理中|否|
857 |分配到一线|否|
858 |一线处理中|否|
859 |分配到二线|是|二线支持人员无法处理该事件单，或者分配错误，将事件单重新分配给二线支持组或二线支持组内其他人员
860 |二线处理中|否|
861 |分配到三线|是|二线支持人员将事件单分配给三线支持组或三线支持组内的其他人
862 |三线处理中|否|
863 |已解决|是|二线支持找到解决方案或者变通方法，解决了分配的事件单
864 |已关闭|否|
865
866 * 当前状态为‘分配到三线’状态时，可迁移的状态
867
868 |**状态**|**合法**|**描述**
869 |已登记|否|
870 |分配到服务台|否|
871 |服务台处理中|否|
872 |分配到一线|否|
873 |一线处理中|否|
874 |分配到二线|否|
875 |二线处理中|否|
876 |分配到三线|是|三线支持人员将事件单分配给三线支持组或三线支持组内的其他人
877 |三线处理中|是|三线支持人员，接受分配的事件单，并开始处理
878 |已解决|否|
879 |已关闭|否|
880
881 * 当前状态为‘三线处理中’状态时，可迁移的状态
882
883 |**状态**|**合法**|**描述**
884 |已登记|否|
885 |分配到服务台|否|
886 |服务台处理中|否|
887 |分配到一线|否|
888 |一线处理中|否|
889 |分配到二线|是|
890 |二线处理中|否|
891 |分配到三线|是|三线支持人员将事件单分配给三线支持组或三线支持组内的其他人
892 |三线处理中|否|
893 |已解决|是|三线支持找到解决方案或者变通方法，解决了分配的事件单
894 |已关闭|否|
895
896 * 当前状态为‘已解决’状态时，可迁移的状态
897
898 |**状态**|**合法**|**描述**
899 |已登记|否|
900 |分配到服务台|否|
901 |服务台处理中|否|
902 |分配到一线|否|
903 |一线处理中|否|
904 |分配到二线|否|
905 |二线处理中|否|
906 |分配到三线|否|
907 |三线处理中|否|
908 |已解决|否|
909 |已关闭|是|服务台在关闭事件单的时候，需要填写客户反馈和结束代码
910
911 * 当前状态为‘已关闭’状态时，可迁移的状态
912
913 不迁移至任何状态。
914
915 == ** ** ==
916
917 == **6.10 事件结束代码** ==
918
919 事件结束代码说明了事件是在何种情况下关闭的，结束代码如下：
920
921 |**编号**|**代码**|**描述**
922 |1|成功解决|事件获得成功解决
923 |2|变通方法解决|事件已通过变通方法或者临时措施获得解决，但是需要进行更进一步的根源分析
924 |3|不成功|事件没有获得解决（用户没有认可解决时使用）
925 |4|消失|事件自行消失
926 |5|误报|不属于IT部门管理范围的事件
927 |6|可忽略|如通过其他系统接口或监控系统提交的信息，经确认属于无效信息
928
929 == ** ** ==
930
931 == **6.11 事件解决人角色** ==
932
933 事件解决人角色用来标明该事件单最终解决的角色是服务台还是一线、二线、三线。
934
935 |**编号**|**代码**|**描述**
936 |1|服务台|服务台最终解决事件
937 |2|一线|一线支持最终解决事件
938 |3|二线|二线支持最终解决事件
939 |４|三线|三线支持最终解决事件
940 |５|其他|自动消失的事件等
941
942 == ** ** ==
943
944 == **6.12 处理是否超时** ==
945
946 每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超过了解决期限。
947
948 |**编号**|**代码**|**描述**
949 |1|未超时|未超时
950 |2|超时|事件已超出规定的解决时限
951
952 == ** ** ==
953
954 == **6.13 故障厂商** ==
955
956 用来在事件单中记录是哪个厂商的设备或系统发生故障。
957
958 |**编号**|**厂商名称**
959 |1|3COM
960 |2|AVAYA
961 |3|BEA
962 |4|BMC
963 |5|Borland
964 |6|CA
965 |7|Cisco
966 |8|EMC
967 |9|HDS
968 |10|HP
969 |11|IBM
970 |12|McDATA
971 |13|Microsoft
972 |14|NCR
973 |15|NETAPP
974 |16|Oracle
975 |17|Quantum ATL
976 |18|STK
977 |19|SUN
978 |20|Sybase
979 |21|TERADATA
980 |22|北电
981 |23|东方通
982 |24|中兴
983 |25|华为
984 |26|SYMANTEC
985 |27|QUEST
986 |28|REDHAT
987 |29|BROCADE
988 |30|锐捷
989 |31|迈普
990 |32|联想
991 |33|网神
992 |34|天融信
993
994 == ** ** ==
995
996 == **6.14 用户反馈** ==
997
998 用来在事件单中记录用户对事件处理的满意程度。
999
1000 |**编号**|**代码**|**描述**
1001 |1|满意|用户对事件处理结果表示满意
1002 |2|一般|用户对事件处理结果既非满意也非不满意，处于中间感受
1003 |3|不满意|用户对事件处理结果表示不满意
1004
1005 = ** ** =
1006
1007 = ** ** =
1008
1009 = **7. 流程概要设计** =
1010
1011 事件管理概要设计流程图如下：
1012
1013 (% style="text-align:center" %)
1014 [[image:图片5.jpg]]
1015
1016 流程描述如下：
1017
1018 |**序号**|(% style="width:134px" %)**步骤名称**|(% style="width:123px" %)**责任人**|(% style="width:1027px" %)**说明**
1019 |100.1|(% style="width:134px" %)事件记录和分类|(% style="width:123px" %)服务台|(% style="width:1027px" %)(((
1020 1. 服务台对来自本部门服务范围内的用户和系统自动产生的事件进行详细记录，其中包括申告/咨询/告警/故障
1021 1. 服务台负责在接收到事件后进行分类转发
1022 1. 对于初步判断为紧急的事件马上升级到本公司一线人员处理
1023 )))
1024 |100.2|(% style="width:134px" %)初始支持|(% style="width:123px" %)服务台|(% style="width:1027px" %)(((
1025 1. 属于服务台技能范围内可以处理的事件，服务台应尝试解决，如果无法解决需及时升级到本部门一线支持
1026 1. 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案
1027 1. 不属于服务台职责范围的事件，立即分派到相应的本部门一线支持
1028 )))
1029 |100.3|(% style="width:134px" %)一线尝试解决|(% style="width:123px" %)一线支持|(% style="width:1027px" %)(((
1030 1. 一线支持人员在接受到由本公司服务台派发的事件后，进行调查诊断，尝试解决
1031 1. 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案
1032 1. 对于需要通过问题解决的事件提出问题申请，通过问题流程实施解决方案
1033 1. 事件解决后，在事件管理平台记录事件解决方案并更新事件状态
1034 1. 不能解决的事件，转100.4二线尝试解决
1035 )))
1036 |100.4|(% style="width:134px" %)二线尝试解决|(% style="width:123px" %)二线支持|(% style="width:1027px" %)(((
1037 1. 二线支持人员接受到来自总公司或各分公司一线支持的事件后，进行调查诊断，尝试解决方案，在必要时根据服务协议联系厂商帮助解决并负责核查
1038 1. 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案
1039 1. 对于需要通过问题解决的事件提出问题申请，通过问题流程实施解决方案
1040 1. 事件解决后，在事件管理平台记录事件解决方案并更新事件状态
1041
1042 1. 不能解决的事件，转100.6三线尝试解决
1043 )))
1044 |100.5|(% style="width:134px" %)紧急事件再确认|(% style="width:123px" %)一线支持|(% style="width:1027px" %)(((
1045 1. 一线支持人员接受到来自本部门服务台的紧急事件后，根据事件优先级别标准再次确认事件是否为紧急事件
1046 1. 如果优先级确实紧急，则通知相应的管理层，并立即升级到事件经理，转101紧急事件处理子流程
1047 1. 如不是，转100.3一线尝试解决，开始正常事件解决流程
1048 )))
1049 |100.6|(% style="width:134px" %)三线尝试解决|(% style="width:123px" %)三线支持|(% style="width:1027px" %)(((
1050 1. 三线支持人员接受来自总公司二线支持派发的事件后，根据实际情况，尝试找出并实施解决方案，在必要时根据服务协议联系厂商帮助解决并负责核查
1051 1. 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案
1052 1. 对于需要通过问题解决的事件提出问题申请，通过问题流程实施解决方案
1053 1. 事件解决后，在事件管理平台记录事件解决方案并更新事件状态
1054 1. 指定时限内未能解决的事件，通告事件经理，由事件经理负责协调资源
1055 )))
1056 |100.7|(% style="width:134px" %)记录解决方案细节|(% style="width:123px" %)(((
1057 服务台
1058
1059 一、二、三线支持
1060 )))|(% style="width:1027px" %)(((
1061 1. 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息
1062 1. 针对故障，一、二、三线支持必须记录业务恢复时间
1063 )))
1064 |100.8|(% style="width:134px" %)关闭事件|(% style="width:123px" %)服务台|(% style="width:1027px" %)(((
1065 1. 服务台与申报用户确认事件是否已得到解决，如果解决，事件以成功解决或变通方法解决而关闭；否则，事件以不成功关闭，重新开事件记录，并与原记录做关联，分派到原处理人员继续处理
1066 1. 服务台在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确
1067 )))
1068 |100.9|(% style="width:134px" %)事件处理的监控|(% style="width:123px" %)事件经理|(% style="width:1027px" %)(((
1069 1. 负责监控所有未关闭的事件的处理状况，对接收到的超时告警应及时关注，并负责协调资源，保证事件的最终解决
1070 1. 当事件优先级为紧急时，应按照紧急事件处理流程处理紧急事件
1071 )))
1072 |101|(% style="width:134px" %)紧急事件处理流程|(% style="width:123px" %)事件经理|(% style="width:1027px" %)(((
1073 1. 事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程
1074 )))
1075
1076
1077
1078 = **8. 流程详细设计** =
1079
1080 == **8.1 （100.1）事件记录和分类** ==
1081
1082
1083 (% style="text-align:center" %)
1084 [[image:1730190304376-384.png]]
1085
1086 流程描述如下：
1087
1088 |**序号**|**步骤名称**|(% style="width:110px" %)**责任人**|(% style="width:106px" %)**输入**|(% style="width:148px" %)**输出**|**说明**
1089 |100.1.1|从任务队列中接受事件|(% style="width:110px" %)服务台|(% style="width:106px" %)事件队列|(% style="width:148px" %)需要处理的事件|(((
1090 事件任务队列的来源：
1091
1092 1. 监控系统自动发送的告警
1093 1. 业务部门通过其他接口转发的事件单
1094 1. IT用户通过服务台自助系统提交的事件单
1095
1096 服务台负责检查事件任务队列中的新事件单，开始处理
1097 )))
1098 | |是否为本部门职责范围？|(% style="width:110px" %)服务台|(% style="width:106px" %)事件单|(% style="width:148px" %) |(((
1099 服务台判断是否属于本部门职责范围：
1100
1101 1. 是，进行事件分类的处理；
1102 1. 否，转100.1.3回复和关闭
1103 )))
1104 |100.1.2|新建事件|(% style="width:110px" %)服务台|(% style="width:106px" %)电话/OA/传真|(% style="width:148px" %)新建的事件记录|(((
1105 属于本中心（科室）职责范围，服务台负责创建新的事件单，填写详细情况描述，不属于本部门处理的，直接电话回复。
1106
1107 事件单填写的详细内容如下：
1108
1109 1. 报告人姓名、联系电话、邮件、分公司、部门
1110 1. 事件标题和描述
1111 1. 必要的附件
1112 1. 事件发生时间和地点
1113 1. 事件来源和事件性质
1114 1. 进行事件分类
1115 1. 设定事件状态为“新建”
1116 )))
1117 |100.1.3|回复和关闭|(% style="width:110px" %)服务台|(% style="width:106px" %)误报的事件单|(% style="width:148px" %)关闭的事件单|联系申报用户，说明情况，将该事件单状态置为“关闭”，结束代码为“误报”，保存关闭
1118 | |是否为重复事件？|(% style="width:110px" %)服务台|(% style="width:106px" %)事件记录|(% style="width:148px" %)相应的处理流程|(((
1119 服务台根据重复事件原则，判断该事件单是否属于重复事件：
1120
1121 1. 是，转100.1.4重复事件处理；
1122 1. 否，事件分类的判断
1123 )))
1124 |100.1.4|重复事件处理|(% style="width:110px" %)服务台|(% style="width:106px" %)重复事件|(% style="width:148px" %) |在重复事件单的“重复事件标记”中记录正在处理的事件单的流水号，状态置为“XX处理中”，保存退出。
1125 | |事件性质区分？|(% style="width:110px" %)服务台|(% style="width:106px" %)事件性质|(% style="width:148px" %)相应的处理流程|(((
1126 根据事件性质区分不同的处理流程：
1127
1128 告警/申告/咨询/故障，走100.1.5事件影响度、优先级设定
1129 )))
1130 |100.1.5|事件影响度、优先级设定|(% style="width:110px" %)服务台|(% style="width:106px" %)事件记录|(% style="width:148px" %)确定了影响度和优先级的事件|根据上报的事件描述，判断对业务的影响程度，并对照优先级代码表，确定事件的优先级，以及初始确定的影响度
1131 | |优先级为紧急吗？|(% style="width:110px" %)服务台|(% style="width:106px" %)事件优先级|(% style="width:148px" %)相应的处理流程|(((
1132 服务台根据业务的影响程度和事件优先级判定的条件，初步判断优先级别：
1133
1134 1. 优先级为紧急，转100.5紧急事件再确认；
1135 1. 其他优先级否，转100.2初始支持
1136 )))
1137
1138 == ==
1139
1140 == **8.2 （100.2）初始支持** ==
1141
1142 (% style="text-align:center" %)
1143 [[image:1730190352635-874.png]]
1144
1145
1146 流程描述如下：
1147
1148 |**序号**|**步骤名称**|(% style="width:96px" %)**责任人**|(% style="width:87px" %)**输入**|(% style="width:134px" %)**输出**|(% style="width:787px" %)**说明**
1149 | |服务台技能可以处理吗？|(% style="width:96px" %)服务台|(% style="width:87px" %)事件记录|(% style="width:134px" %)处理方式|(% style="width:787px" %)(((
1150 服务台根据事件分类和事件描述，判断处理职责是否在服务台： 
1151
1152 1. 是，转100.2.1尝试处理；
1153 1. 否，转100.2.2分配到一线支持
1154 )))
1155 |100.2.1|尝试处理|(% style="width:96px" %)服务台|(% style="width:87px" %)事件记录|(% style="width:134px" %) |(% style="width:787px" %)服务台运用知识库和自身技能在规定的时限内尝试解决，将事件状态置为“分配到服务台”，如果不能处理应及时将事件单分配到一线支持
1156 |100.2.2|分配到一线支持|(% style="width:96px" %)服务台|(% style="width:87px" %)事件记录|(% style="width:134px" %)分配到一线的事件单|(% style="width:787px" %)选择本部门相关的一线处理组和处理人员分派，并将事件状态置为“分配到一线”
1157 | |解决了吗？|(% style="width:96px" %)服务台|(% style="width:87px" %) |(% style="width:134px" %) |(% style="width:787px" %)(((
1158 将解决方案和用户沟通，判断是否可以解决；
1159
1160 1. 可以解决，转100.7记录解决方案细节
1161 1. 无法解决，转100.2.2分配到一线支持
1162 )))
1163 | |发起变更吗？|(% style="width:96px" %)服务台|(% style="width:87px" %)解决方案|(% style="width:134px" %)N/A|(% style="width:787px" %)(((
1164 服务台根据解决方案的内容和变更管理流程对变更范围的定义，判断是否需要发起变更？
1165
1166 1. 需要发起变更，创建变更请求，提交到变更管理流程，解决方案的实施由变更管理完成
1167 1. 不需要发起变更，转100.7
1168 )))
1169
1170 == ==
1171
1172 == **8.3 （100.3）一线尝试解决** ==
1173
1174 (% style="text-align:center" %)
1175 [[image:1730190390900-163.png]]
1176
1177
1178 流程描述如下：
1179
1180 (% style="text-align:center" %)
1181 [[image:1730190622591-389.png]]
1182
1183 (% style="text-align:center" %)
1184 [[image:1730190639294-778.png]]
1185
1186
1187 (% style="text-align:center" %)
1188 [[image:1730190655622-126.png]]
1189
1190
1191
1192 == **8.4 （100.4）二线尝试解决** ==
1193
1194 (% style="text-align:center" %)
1195 [[image:1730190688154-623.png]]
1196
1197
深圳市艾拓先锋企业管理咨询有限公司