Version 3.1 by superadmin on 2024/06/06, 13:04
Show last authors
1 [[返回本章节索引>>url:https://itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/]]  阅读下一篇
2
3
4 = **某网络工程公司ITIL信息技术服务管理体系—事件流程管理办法** =
5
6
7 === **1 概述** ===
8
9
10 ===== **1.1 目标** =====
11
12 事件管理流程的主要功能是减少或消除存在或可能存在于信息技术服务中的干扰因素给信息技术服务带来的干扰，以确保用户可以尽快恢复自己的正常工作。事件管理流程的目标包括：
13
14 在成本允许的范围内尽快恢复IT服务，在给用户和公司正常业务活动带来最小影响的情况下，尽快恢复到SLA中定义的正常服务级别。
15
16 1. 快速响应服务请求（电话/Web/邮件等）；
17 1. 用户在线获得帮助；
18 1. 沟通事件解决的状态；
19 1. 进行事件控制；
20 1. 按规范记录事件；
21 1. 监视、分析和诊断事件，必要时进行事件升级；
22 1. 为其他流程提供合适的信息以改进相关处理流程；
23
24
25 ===== **1.2 范围** =====
26
27
28
29 **1.2.1 流程适用范围**
30
31 本流程适用于XX网络工程有限公司（以下简称“公司”）各相关部门。
32
33
34
35
36 **1.2.2流程管理范围**
37
38 事件管理流程涉及财务（资金）管理、营销管理、安全研发管理、协同办公、人力资源管理、物资管理、项目管理和综合管理及其与之相关的网络平台、防火墙、数据库等IT研发环境中产生的常规、非常规事件，以及客户环境中桌面硬件、计算机辅助设备的服务和故障请求，解答用户围绕这些生产环境提出的问题以及咨询。
39
40 事件管理流程不涉及尚处于开发或测试中的系统和应用。
41
42
43 === **2 角色和职责** ===
44
45 事件管理流程涉及的角色包括：事件管理流程负责人、事件经理、一线支持、二线支持、服务专员等。事件管理流程负责人和事件经理可以由同一人担任。各角色职责如下：
46
47
48 ===== **2.1 事件管理流程负责人** =====
49
50 事件管理流程负责人从宏观上对流程运行情况进行监控，确保事件管理流程在各部门间被正确的执行。当流程不能够适应公司实际情况时，流程负责人必须启动分析研究，找到解决方案并进行改进，实现流程的稳定运行和可持续提高。具体职责包括：
51
52
53 1. 确定管理流程的衡量指标；
54 1. 确保事件流程能够取得管理层的参与和支持；
55 1. 确保事件流程符合公司实际状况和公司 IT发展战略；
56 1. 总体上管理和监控流程，建立事件流程实施、评估和持续优化机制；
57 1. 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进（假如增加或合并流程的角色），从而实现可持续提高；
58 1. 保持与其他流程负责人的定期沟通。
59
60
61 ===== **2.2 事件经理** =====
62
63 1. 负责对事件的解决协调资源，保证故障的最终排除；
64 1. 当事件优先级为紧急或者事件将超过规定的时限，负责按照升级方法对事件进行处理确保有效协调资源，促进支持工程师快速恢复正常服务；
65 1. 确保和问题管理流程经理的有效合作；
66 1. 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题。
67 1. 负责流程运行质量的监控管理，向公司负责，
68
69
70 ===== **2.3 一线支持** =====
71
72 1. 在指定的响应时间内响应所有服务热线电话、邮件、传真等事件报告；
73 1. 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等；
74 1. 为事件进行适当的分类、为事件分配优先级等属性；
75 1. 将紧急事件分派给合适的二线支持人员；
76 1. 对非紧急事件，首先尝试使用工具、初步诊断、分析相关信息等方式解决问题；
77 1. 如果不能解决这个事件，应当将事件分配给最合适的二线支持小组/人员来处理；
78 1. 检查事件记录的处理进度，保持与事件报告人的联系，适时通知事件处理进展；
79 1. 与用户确认事件解决方案，关闭事件；
80 1. 负责24×7的值班。
81
82
83 ===== **2.4 二线支持** =====
84
85 1. 接收派单（事件处理请求），解决相关事件。
86 1. 按照标准要求填写处理过程。
87 1. 负责联络专家。
88
89
90 ===== **2.5 服务专员** =====
91
92 接受客户服务请求，初步处理客户提交的事件，并反馈结果给用户，关闭工单。
93
94
95 === **3 输入** ===
96
97 |**编号**|**输入项**|**来源**|**周期**
98 |(((
99 1
100 )))|通过纸质文件、邮件、电话和传真等提出的事件。|用户|日常运维
101 |(((
102 2
103 )))|通过日常维护提出的事件。|运维支持人员|日常运维
104 |(((
105 3
106 )))|问题管理给出解决方案和应急措施|问题管理流程|日常运维
107 |(((
108 4
109 )))|变更管理给出的变更通知|变更管理流程|日常运维
110
111
112 === **4 输出** ===
113
114 |**编号**|**输出项**|**去向**|**周期**
115 |(((
116 1
117 )))|问题|问题管理流程|日常运维
118 |(((
119 2
120 )))|事件和事件处理过程及结果的记录（报表）|事件经理|日常运维
121
122
123 === **5 相关定义和说明** ===
124
125
126 ===== **5.1 事件的分类** =====
127
128 为便于事件的合理分配以及有效汇总、统计和分析事件记录，并为问题、变更管理打好分类基础，事件应得到合理分类。其中一级分类为办公系统终端、基础设施、网络、主机、安全系统、基础应用、业务应用。
129
130 当影响范围为全体或紧急程度为特急时，此类事件可认为是重大事件，需按照紧急事件流程进行处理。
131
132
133 ===== **5.2 事件的优先级定义** =====
134
135 公司事件管理流程中，事件影响范围用于衡量事件所影响业务及用户范围，分为8个等级。事件紧急程度用于衡量事件需要及时解决响应的程度，分为4个等级，根据事件管理流程按照事件影响范围和紧急程度，按照事件优先级的特定计算公式，事件被分为四个优先级：一般(1)、中(2)、高(3)、特高(4)。
136
137
138 ===== **5.3 技术升级时间表** =====
139
140 |(((
141 **[[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml11140\wps4.png]] 支持**
142
143 **团队**
144
145 **升级**
146
147 **[[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml11140\wps5.png]]时限**
148
149 **事件**
150
151 **级别**
152 )))|(((
153 **一线支持（服务专员）升级到**
154
155 **二线支持**
156 )))|(((
157 **二线支持**
158
159 **升级到**
160
161 **专家支持 **
162 )))|(((
163 **升级到**
164
165 **问题流程 **
166 )))
167 |**紧急（5级）**|无|无|无
168 |**高（4级）**|2个小时|3个小时|
169 |**中（3级）**|8个小时|12个小时|
170 |**较低（2级）**|24个小时|最终期限前8个小时|
171 |**低（1级）**|48小时|最终期限前8个小时|超过最终时间
172
173
174 ===== **5.4 行政升级时间表** =====
175
176 |(% rowspan="2" %)**紧急（5级）**|升级阀值| | | |(% rowspan="6" %)/
177 |报告范围| | |
178 |(% rowspan="2" %)**高（4级）**|升级阀值|2个小时|3个小时|超过最终时间
179 |报告范围|服务专员/一线，被分派工单的二线|被分派工单的服务台/一线/二线，事件经理|事件经理及管理层
180 |(% rowspan="2" %)(((
181 **中（3级）**
182
183
184 )))|升级阀值|8个小时|12个小时|超过最终时间
185 |报告范围|服务专员/一线，被分派工单的二线|被分派工单的一线/二线，事件经理|事件经理及管理层
186 |(% rowspan="2" %)**较低（2级）**|升级阀值|24个小时|最终期限前8个小时|最终期限前2小时|超过最终时间
187 |报告范围|服务专员/一线，被分派工单的二线|被分派工单的一线/二线|被分派工单的一线/二线，事件经理|事件经理及管理层
188 |(% rowspan="2" %)**低（1级）**|升级阀值|48小时|最终期限前8个小时|最终期限前2小时|超过最终时间
189 |报告范围|服务专员/一线，被分派工单的二线|被分派工单的一线/二线|被分派工单的一线/二线，事件经理|事件经理及管理层
190
191
192 ===== **5.5 事件的状态** =====
193
194 事件处理流程中事件的相关状态定义见下表。
195
196 |**事件的状态 **|**定义**
197 |已登记|已由服务专员登记
198 |分派|事件已由一线发出，未被接受
199 |返回|事件分配不当，返回服务专员
200 |一线处理中|已分派到一线处理中
201 |二线处理中|已分派到二线并接受
202 |RFC|已通过RFC提交解决方案
203 |完成|一线/二线已解决事件
204 |结束|事件已关闭（服务专员）
205
206
207 === **6 事件管理流程描述** ===
208
209
210 ===== **6.1 普通事件流程** =====
211
212
213 |**序号**|(((
214 **步骤**
215
216 **名称**
217 )))|**责任人**|**说明**
218 |1|事件接受与记录|服务专员|(((
219 1. 服务专员对来自用户和系统自动产生的事件进行详细记录，其中包括故障/告警/服务请求
220 )))
221 |2|分类与支持，调度分派|服务专员|(((
222 1. 在接收到事件后进行分类记录
223 1. 尝试直接解决用户提出的请求
224 1. 无法解决则进行调度分派
225 )))
226 |3|分析处理|一线人员|(((
227 1. 技术部一线支持人员接受事件，进行调查诊断，尝试解决
228 1. 事件解决后，记录事件解决方案
229 )))
230 |4|二线调查诊断|二线人员|(((
231 1. 二线支持人员接受事件，进行调查诊断，尝试解决
232 1. 事件解决后，记录事件解决方案
233 1. 如果二线支持认为需要三线进行处理，即升级为问题
234 1. 二线支持人员接受到来自服务专员的紧急事件后，根据事件优先级别标准再次确认事件是否为紧急事件
235 1. 如果优先级确实紧急，则通知相应的管理层，并立即升级到事件经理，紧急事件处理子流程
236 )))
237 |6|解决和恢复|(((
238 一线支持
239
240 二线支持
241 )))|(((
242 1. 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息
243 )))
244 |7|反馈客户/关闭|(((
245 一线支持
246
247 二线支持
248 )))|(((
249 1. 服务专员与用户确认事件是否已得到解决，如果解决，事件以成功解决或变通方法解决而关闭；否则，事件以不成功关闭，重新开事件记录，并与原记录作关联，分派到原处理人员继续处理
250 1. 服务专员在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确
251 1. 其它由一线或二线人员自行创建的事件单，则由开单人负责关闭
252 )))
253 |8|审核并提交进入知识库|事件经理|(((
254 1. 对已关闭的工单进行审核并挑选加入知识库
255 )))
256 |9|紧急事件处理流程|事件经理|(((
257 1. 事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程
258 )))
259
260
261 ===== **6.2 紧急事件流程** =====
262
263
264 |**序号**|**步骤名称**|**说明**
265 |1|召集应急小组，协调应急会议|(((
266 ~1. 事件经理主持应急会议，并组织讨论、协调各方资源，分析紧急事件处理方案；
267
268 2. 与此同时，事件经理还需将紧急事件上报上级公司信息部门。
269 )))
270 |2|判断是否属于应急预案中的事件？|(((
271 1. 应急小组和相关厂商根据紧急事件现象和影响程度，判断是否需要启动相应系统的应急预案；
272 1. 如果没有应急预案，则进入4组织相关专家共同分析紧急事件，制定处理方案并处理；
273 1. 如果有应急预案，则进入3按照应急预案处理。
274 )))
275 |3|按照应急预案处理|(((
276 1. 根据各系统制定的应急预案中的实施步骤，处理紧急事件。
277 )))
278 |4|组织相关厂商共同分析，制定处理方案并处理|(((
279 1. 应急小组负责组织相关厂商共同分析紧急事件，制定相应的处理方案；
280 1. 处理方案在实施前应得到应急小组和相关领导的认可；
281 1. 事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求。
282 )))
283 |5|紧急事件解除确认？|(((
284 1. 在紧急事件处理方案实施后，应急小组、相关专家和相关部门对紧急事件是否解除进行确认；
285 1. 紧急事件如果没有解除，则重新进入4组织相关专家共同分析紧急事件，制定处理方案并处理；
286 1. 如果解除，则进入6紧急事件善后处理和总结分析。
287 )))
288 |6|善后处理和通报|(((
289 1. 紧急事件解除后，应向申告方、公司相关领导简要报告紧急事件处理过程，解决方法，事件解除时间，业务恢复情况；
290 1. 对于影响度为高的紧急事件，必须提交《重大事件报告》；
291 1. 紧急事件的处理人需要创建一个新问题，将紧急事件处理过程的详细信息记录到问题单中，提交到问题经理，由问题经理组织相关专家进行问题根源的分析。
292 )))
293
294
295 === **7 表单和模板** ===
296
297
298 |**名称**|**版本**|**负责人**|**说明**
299 |事件记录|V1.0|沈立峰|
300 |事件管理报告|V1.0|沈立峰|对流程运行情况的报告
301
302
303 === **8 关键绩效指标（KPI）** ===
304
305 事件管理的可选指标包括：
306
307 |**绩效指标**|**目标值**|**衡量方式**|**频度**|**负责人**
308 |事件总数| |统计| |
309 |事件的平均解决时间|4小时|统计|每日|
310 |按优先级计算的平均解决时间| |统计|每日|
311 |一线解决率|50%|统计|每日|
312 |超时未解决的事件数量| |统计|每日|
313 |超时事件解决率|10%|统计|每日|
314 |事件一次解决率|80%|统计|每日|
315 |事件成功关闭数量比率|98%|统计|每日|
316 |正确转交的事件数量比率|95%|统计|每日|
317
318
319 === **9 流程质量控制** ===
320
321 **[[image:图片3.png]]**
322
323 [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml11140\wps6.png]]
324
325 |**步骤**|**输入**|**步骤描述**|**输出**|**负责人**
326 |(((
327 1 现有流程评估
328 )))|KPI、报告、流程执行过程中发现的问题|(((
329 1. 通过对KPI的完成程度，事件历史记录等数据进行差距、趋势分析，定期对事件管理流程的实施有效性、服务质量和用户满意度进行回顾；
330 1. 生成差距分析评估报告、趋势分析报告。
331 )))|差距分析评估报告、趋势分析报告|事件经理
332 |(((
333 2 制定改进计划
334 )))|差距分析评估报告、趋势分析报告|(((
335 1. 根据差距分析评估报告、趋势分析报告总结待改进项，制定改进计划，改进计划中包括：
336 1*. 流程的待改进项和改进机会；
337 1*. 改进收益；
338 1*. 执行改进计划可能带来的影响和风险；
339 1*. 所需资源；
340 1*. 测试和培训计划；
341 1*. 实施计划；
342
343 *
344 ** 相关的支持文档等内容。
345 )))|改进计划|事件经理
346 |(((
347 3 审批改进计划
348 )))|改进计划|(((
349 1. 事件经理协调改进涉及到的相关人等对改进计划进行评估审批；
350 1. 提交RFC。
351 )))|审批后的改进计划|事件经理
352 |(((
353 4 执行改进计划
354 )))|被批准的改进计划|调动资源，组织相关人员执行被批准的改进计划。|实施后的改进计划、改进效果|事件经理
355 |(((
356 5 回顾
357 )))|实施后的改进计划、改进结果|(((
358 1. 对改进后的结果进行回顾，评估改进计划是否成功，存在哪些待改进项；
359 1. 依据PDCA方法论再次执行步骤1对现有流程进行评估，对流程进行持续改进，起到对流程质量控制的作用。
360 )))|回顾结果|事件经理
361
362
363 === **10 与其它流程的接口** ===
364
365 **[[image:图片4.png]]**
366
367 [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml11140\wps7.jpg]]
368
369 * **配置管理**
370
371 需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。
372
373 * **问题管理**
374
375 事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为高的事件解决并恢复服务后作为问题进行进一步的分析和处理。
376
377 * **变更管理**
378
379 服务专员应了解变更管理流程中目前正在进行的变更信息，监测因变更引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。
380
381 * **服务级别管理**
382
383 服务级别管理流程对SLA协议完成情况进行持续监控，事件流程相关人员必须全面了解SLA协议内容，以便在与用户进行沟通的时候可用到这些信息。有关事件记录的报告可用来判断是否真正地提供的规定级别的服务。
384
385 * **可用性管理**
386
387 为了评估服务的可用性，可用性管理流程需要使用配置管理流程提供的事件记录和状态监控信息，例如事件处理期间导致的某项服务的“不可用”状态。
388
389 * **能力管理**
390
391 能力管理流程关注由于能力（Capability）不足导致的事件，例如系统处理能力不足导致的处理响应时间过长。
392
393
394 === **11 术语定义** ===
395
396
397 |**术语**|**定义**
398 |事件（Incident）|在某一服务中不属于标准操作（standard operation）并且有可能导致IT服务中断或服务质量下降的任何事情(event)。
399 |事件状态|事件状态代码表明事件所处的处理状态
400 |事件分类|有故障和服务请求
401 |事件影响度|事件影响度用于衡量事件所影响业务的严重程度
402 |事件优先级|事件优先级定义了事件优先获得资源并得到处理的优先顺序
403 |事件结束代码|事件结束代码说明了事件是在何种情况下关闭的
404 |事件超时代码|事件超时代码用于标明事件的处理是否超过规定的时限
405
406
407 === 12 附则 ===
408
409 本管理办法由技术部负责组织制定、解释和修改，各部门可根据本规定制定相应的实施细则。
410
411 本管理办法自印发之日起实行。
412
413 相关文件：
414
415 《信息技术服务管理手册》
416
417 《信息技术服务管理策略》
418
419 《服务报告流程管理办法》
420
421 《记录控制管理规定》
422
423 相关时间要求：
424
425 管理办法中规定的“每月”为每月10号前；
426
427 管理办法中规定的“每季度”为每季度第一个月10号前；
428
429 管理办法中规定的“每半年”为每半年度第一个月15号前；
430
431 管理办法中规定的“每年”为每自然年度第一个月20号前；
432
433 如遇节假日可顺延。
434
435
436
深圳市艾拓先锋企业管理咨询有限公司