Version 11.1 by superadmin on 2024/10/29, 18:56
Hide last authors
superadmin 3.2 1 = **1. 概述** =
2
3 == **1.1 目的** ==
4
5 编写事件管理程序的目的是为了规范XX移动网管中心IT服务管理体系的事件的管理，尽快解决IT环境中的突发事件、故障和服务请求，尽快恢复被中断或受到影响的IT服务，保持提供稳定的、高效的、高质量的IT服务。
6
7 具体目标体现在：
8
9 1）在成本允许的范围内尽快恢复IT服务
10
11 1. 快速响应服务请求（电话、邮件）
12 1. 快速处理故障申告（电话、邮件、自助平台、告警系统）
13 1. 用户在线获得帮助，提高用户工作效率
14 1. 沟通事件解决状态，提升客户满意度
15
16 2）进行事件的有效控制
17
18 1. 按规范记录事件
19 1. 对事件进行有效分类
20 1. 对事件优先级进行分级
21 1. 事件分析与诊断，必要时进行升级
22 1. 监视并结束事件
23 1. 进行定期服务流程回顾
24
25 3）提供有效的IT服务管理信息
26
27 1. 服务资源利用情况
28 1. 故障处理情况
29 1. 服务支持效率
30 1. 有效配置信息
31 1. 服务质量管理报告
32
33 == ==
34
35 == **1.2 适用范围** ==
36
37 事件管理的范围包括辽宁移动网管中心合同范围内客户的IT生产和运行环境中发生的故障、服务请求。如果用户通过事件管理流程提出新增服务，变更请求和服务投诉等事件，则它们会通过事件管理流程转入其他相应的管理流程进行处理，事件管理只负责故障申告和服务请求的处理。具体如下：
38
39 1）故障申告
40
41 1. 用户报告的故障事件
42 1. 监控系统的告警事件
43 1. IT服务人员监测、检测的故障事件
44 1. 其他人员转告的用户故障事件
45
46 2）服务请求
47
48 1. 业务支持
49 1. 信息咨询
50 1. 辅助配合
51 1. 文档需求
52
53
54 本事件管理范围不包括尚处于开发或测试环境系统引发的事件。
55
56
57
58 == **1.4 前提与假设** ==
59
60 阅读本文的读者应该了解IT服务管理国际最佳实践（ITIL）的基本知识，并具有流程的基本技能，了解XX移动网管中心系统运维的业务。
61
62 同时，假设网管中心的事件发起主要通过电话、邮件、自助平台、告警系统、短信。
63
64
65 == **1.5 文档结构** ==
66
67 本文有以下几个章节组成：
68
69 第一章，“概述”，描述了本文的目的、适用范围、引用文件、前提与假设等内容。
70
71 第二章，“术语”，描述了本文使用到的术语及其定义或说明。这些术语和说明是基于IT服务管理国际最佳实践（ITIL）和IT服务管理国际标准（ISO20000），同时结合网管中心实际进行的定义和说明。
72
73 第三章，“角色与职责”，描述了本管理程序相关的角色与角色应承担的职责。角色为逻辑角色，与网管中心现有人员的职能岗位无关，可以一人对应多个角色或多人对应一个角色。
74
75 第四章，“流程准则”，描述本管理程序应遵循的管理规范和要求。
76
77 第五章，“工作流程”，描述了本管理程序所遵循的管理流程及其流程说明。
78
79 第六章，“关键绩效指标”，描述了度量管理程序有效性的关键绩效指标。
80
81 第七章，“三四级文件”，描述了本管理程序配套的三四级文件名称。
82
83
84
85 = **2. 术语** =
86
87 |**术语**|**说明**
88 |事件|用户在信息系统使用过程中，在合同范围内的任何故障和服务请求。
89 |服务请求|服务请求是指用户希望从服务台/一线支持获得的业务支持、信息咨询、辅助配合或者文档方面的事件请求。
90 |故障申告|故障申告是指来自用户、IT维护人员、告警系统等不同对象关于桌面、系统、数据库、服务器、存储、网络等IT基础环境的事件请求。
91 |投诉建议|(((
92 客户对服务支持不满的诉讼请求，包括：支持质量，支持效率，支持态度等；
93
94 客户对服务支持过程中提出的意见和建议。
95 )))
96 |事件分类|事件分类通常是标明一个事件的类别属性，根据不同的类别属性，由具备不同技能的事件处理人员进行事件受理。
97 |事件优先级|事件优先级是根据事件的影响度和紧急度共同决定的事件处理的优先等级。
98 |主事件|主事件是由于相同原因导致的多个故障中，首先申告上来的故障。
99 |从事件|从事件是由于相同原因导致的多个故障中，在主事件后提出来的故障。
100
101
102
103 = **3. 角色与职责** =
104
105 流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合。在实际操作中，不同的人员将被赋予不同的角色，既可以一个人被赋予多个角色，也可以多个人被赋予一个角色。
106
107
108 事件管理流程主要有以下几类角色，其职责及技术技能如下。
109
110
111 |(% style="width:114px" %)角色|(% style="width:854px" %)职责|(% style="width:369px" %)技能要求
112 |(% style="width:114px" %)(((
113 事件管理
114
115 流程负责人
116 )))|(% style="width:854px" %)(((
117 事件管理流程负责人从宏观上监控流程，确保事件管理流程在网管中心被正确的执行。当流程不能适应网管中心的实际情况时，事件管理流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。
118
119 1. 确定事件管理流程的衡量指标。
120 1. 确保事件管理流程能够取得管理层的参与和支持。
121 1. 确保事件管理流程符合网管中心IT发展战略和实际状况。
122 1. 总体上管理和监控事件管理流程，建立事件管理流程的实施、评估和持续优化机制。
123 1. 确保事件管理流程实用、有效、正确地执行，当流程不能够适应网管中心的情况时，必须及时进行分析，找出缺陷，进行改进(例如增加或合并流程的角色)，从而实现可持续提高。
124 1. 保持与其他流程负责人的定期沟通。
125 )))|(% style="width:369px" %)(((
126 1. 深刻理解事件管理流程
127 1. 充分理解IT服务管理的其他流程，能够进行流程接口设计
128 1. 能够很好地理解业务对于事件管理的需求
129 1. 对质量控制与保障有很深入的了解
130 1. 有决策权，能够确保事件管理流程设计要求在实施项目中得到贯彻和执行
131 1. 具有很好的沟通技能，能够取得公司高层的支持，获得所需资源
132 )))
133 |(% style="width:114px" %)事件经理|(% style="width:854px" %)(((
134 事件经理负责事件解决过程中的协调和监控，对事件总负责。
135
136 1. 总体上负责事件的解决，协调资源，确保故障的最终排除。
137 1. 出现重大事件时，负责协调资源，启动紧急预案，并及时通知/上报有关机构与人员。
138 1. 事件处理即将超过规定的解决时限时，负责按照升级原则对事件进行处理，确保有效协调资源，督促支持人员快速恢复正常服务
139 1. 负责审批二线支持无法及时解决、需协调第三方/供应商支持的升级事件。
140 1. 负责接受重大事件的处理，判断重大事件的影响度与紧急度，组织或发起应急预案，及时通报相关机构与领导，协助做好善后处理工作。
141 1. 跟踪及监督超过规定解决时限的事件和客户满意度较低的事件的状况。
142 1. 确保和事件管理流程负责人的有效合作，改善事件管理流程。
143 1. 确保正确和广泛地收集和分析事件数据，形成事件管理报告，为问题管理、可用性管理、能力管理和服务级别管理提供依据。
144 1. 已解决的事件要转告服务台或一线支持，由服务台或一线支持关闭事件。
145 )))|(% style="width:369px" %)(((
146 1. 了解技术架构和技术环境
147 1. 较强的口头表达能力和与用户沟通技巧
148 1. 处理纠纷的能力
149 1. 深刻了解事件管理流程
150 1. 较强的领导能力
151 )))
152 |(% style="width:114px" %)服务台|(% style="width:854px" %)(((
153 负责[[受理来自电话、自助平台的服务请求事件和故障申告事件，并有效记录事件信息。根据事件分类分级负责事件的分派>>path:#_Hlk258312191]]，并负责处理部分服务请求事件。
154
155 1. 作为与用户进行事件沟通的联系入口。
156 1. 根据服务级别协议要求，受理来自电话、自助平台的事件申告。
157 1. 准确、完整地记录所有事件，包括服务请求、故障申告、客户需求、投诉与建议等事件。
158
159 1. 对事件进行正确分类分级，并分派到正确的角色（包括服务台、一线支持、现场工程师、二线支持、事件经理等）进行事件处理。
160 1. 负责部分服务请求类事件的处理，包括咨询服务、知识申请等。（需根据事件分类进行调整，明确服务台所处理的服务请求类事件）
161 1. 根据知识库负责对服务请求事件的及时处理。
162
163 1. 及时与用户直接沟通，向用户通报事件的处理状况。
164 1. 作为事件的受理者，要及时跟踪、监控事件的处理过程，确保在SLA规定的时间内解决事件，把事件的影响降到最低，确保尽快恢复正常。
165 1. 事件解决后，在关闭该事件之前要与用户确认事件处理效果及收集用户的满意度。
166 1. 事件解决后，在关闭该事件之前要更新相关信息，将事件的解决步骤、已知错误、解决方案/变通方法进行文档化，确保信息的完整性、准确性。
167 1. 事件解决后，在关闭该事件之前，将解决方案/变通方法申请纳入知识库中
168 )))|(% style="width:369px" %)(((
169 1. 熟悉事件管理流程和服务台的职责
170 1. 熟悉技术平台和技术环境
171 1. 快速诊断事件和解决事件的能力
172 1. 较强的沟通能力
173 1. 较强的倾听能力
174 )))
175 |(% style="width:114px" %)一线支持|(% style="width:854px" %)(((
176 负责受理来自自助平台、邮件、短信和告警系统的服务请求事件和故障申告事件，并有效记录事件信息。根据事件分类分级负责事件的分派，并负责处理部分服务请求事件和故障申告事件。
177
178 1. 作为与用户进行事件沟通的联络入口。
179 1. 根据服务级别协议要求，受理来自自助平台、邮件、短信和告警系统的事件申告。
180 1. 准确、完整地记录所申告的事件信息，包括服务请求、故障申告等。
181
182 1. 对事件进行正确分类分级，并分派到正确的角色（包括一线支持、现场工程师、二线支持、事件经理等）进行事件处理。
183 1. 负责部分服务请求事件和故障申告事件的处理，包括桌面故障、系统应用故障等。（需根据事件分类进行调整，明确一线支持所处理的事件类型）
184 1. 根据知识库负责对事件的及时处理。
185
186 1. 如果故障无法及时解决，需将故障升级二线支持。
187 1. 及时与用户直接的沟通，向用户通报事件的处理状况。
188 1. 作为事件的受理者，要及时跟踪、监控故障的处理过程，以确保在SLA规定的时间内处理事件，必要时进行事件升级，把事件的影响降到最低，确保尽快恢复正常。
189 1. 事件解决后，在关闭该事件之前要与用户确认事件处理效果及收集用户的满意度。
190 1. 事件解决后，在关闭该事件之前要更新相关信息，将事件的解决步骤、已知错误、解决方案/变通方法进行文档化，确保信息的完整性、准确性。
191 1. 事件解决后，在关闭该事件之前，需将解决方案/变通方法申请纳入知识库中。
192 1. 向现场工程师提供必要的支持和协助。
193 )))|(% style="width:369px" %)(((
194 1. 熟悉事件管理流程和一线支持的职责
195 1. 熟悉技术平台和技术环境
196 1. 快速诊断故障和解决故障的能力
197 1. 较强的沟通能力
198 1. 较强的倾听能力
199 )))
200 |(% style="width:114px" %)现场工程师|(% style="width:854px" %)(((
201 负责处理现场技术服务与支持，以及现场故障诊断与解决。
202
203 1. 负责现场技术服务与支持，包括系统软件安装、桌面工具安装等。（需根据事件分类进行调整，明确现场工程师所处理的事件类型）
204 1. 负责现场故障的处理，包括桌面系统故障、网络故障等。（需根据事件分类进行调整，明确现场工程师处理的事件类型）
205 1. 根据知识库及时对现场技术服务与故障进行处理。
206
207 1. 如果现场故障无法及时解决，可反馈一线支持升级二线支持。
208 1. 故障解决后，要更新相关信息，将故障的解决步骤、已知错误、解决方案/变通方法进行文档化，确保信息的完整性、准确性。
209 1. 事件解决后，要及时反馈结果给服务台/一线支持。
210 )))|(% style="width:369px" %)(((
211 1. 熟悉事件管理流程和现场工程师的职责
212 1. 熟悉现场技术平台和技术环境
213 1. 具备现场技术服务与支持的能力
214 1. 具备快速诊断现场故障和解决现场故障的能力
215 1. 较强的沟通能力
216 )))
217 |(% style="width:114px" %)二线支持|(% style="width:854px" %)(((
218 负责处理服务台或一线支持直接分派的事件，以及一线支持升级的故障类事件。
219
220 1. 接受与处理服务台或一线支持分派的事件申告。
221 1. 接受一线支持升级的故障类事件，并验证事件描述的准确性与完整性，进一步收集故障信息。
222 1. 在SLA规定的时间内解决故障申告。
223 1. 在故障无法及时解决时，应及时提出第三方/供应商支持，或利用其它资源参与，确保故障解决。
224
225 1. 根据知识库及时解决故障。
226
227 1. 对利用变通方法解决的事件，或无法解决的事件，应将事件升级为问题，提交问题管理流程查找事件的根本原因。
228 1. 向现场服务人员提供必要的技术支持。
229 1. 在事件处理过程中，解决方案涉及变更时，需向变更管理流程发起变更申请单（RFC），监督并确认变更结果。
230 1. 已解决的事件要反馈服务台/一线支持，由服务台/一线支持关闭事件。
231 1. 故障解决后，在反馈服务台/一线支持之前要更新相关信息，将事件的解决步骤、已知错误、解决方案/变通方法进行文档化，确保信息的完整性、准确性，并提交服务台/一线支持，申请将解决方案纳入知识库中。
232 1. 负责给用户和服务台/一线支持人员提供技术培训。
233 )))|(% style="width:369px" %)(((
234 1. 熟悉技术平台和技术环境.
235 1. 很强的技术能力
236 1. 较强的解决事件的能力
237 1. 较强的分析能力
238 )))
239 |(% style="width:114px" %)应急小组|(% style="width:854px" %)(((
240 负责重大事件的处理与善后工作。
241
242 1. 接受和处理重大事件，并将已解决的重大事件反馈服务台/一线支持，由服务台/一线支持关闭事件。
243 1. 根据事件类型，实施相关的应急预案。
244 1. 在重大事件处理过程中，根据事态启动服务持续性计划。
245 1. 对重大事件进行深入的研究与讨论，分析事件根本原因，并提出解决方案或紧急处理方案。
246 1. 在重大事件处理过程中，方案涉及变更时，需向变更管理流程发起紧急变更申请，监督并确认变更结果。
247 1. 在确保尽快提供解决方案的前提下，有权根据相关流程缩减工作步骤。
248 1. 完成重大事件的善后处理工作，向有关各方通报事件处理状况，收集整理事件解决方案，并将事件、问题解决步骤文档化，提交知识管理流程将其加入知识库中。
249 )))|(% style="width:369px" %)(((
250 1. 具备应急处理意识与经验
251 1. 熟悉相关技术平台和技术环境.
252 1. 很强的应急处理能力
253 1. 较强的分析判断能力
254 1. 较强的沟通协调能力
255 )))
256
257
258
259 = **4. 流程准则** =
260
261 == **4.1 执行准则** ==
262
263 === **4.1.1 常规原则** ===
264
265 1. 服务台/一线支持作为事件的总责任人，应监督事件的处理过程，负责事件的记录与最终关闭。
266 1. 服务台/一线支持应查看并监督用户申告事件相关表单等信息的完整性、准确性。
267 1. 在事件全生命周期管理中，服务台/一线支持从事件记录开始到事件关闭为止， 需要监督事件的影响及处理情况。
268 1. 所有事件都应该被记录，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案等相应的信息。同时，在事件关闭前应确保相关文档完整、全面、准确并归档。
269 1. 在建立知识库过程中，相关支持人员需要对其进行定期更新与维护，同时服务台及支持人员具有受限的访问权限。
270 1. 服务台及支持人员要按照服务级别协议规定的时限对事件进行处理。当事件处理发生冲突时，应优先处理重大紧急事件或优先级高的事件；如果优先级别相同，则优先处理相对简单事件。
271 1. 在事件处理过程中，服务台/一线支持应随时保持与用户的沟通，通知用户事件处理进展状况。若不能按照预期恢复，应提前告知用户，并采取相应措施，取得用户的认可。
272 1. 应定期（每月/半月/周）产生事件管理报告，应定期举行事件管理会议对重复发生的事件和通过变通方法解决的事件进行评估分析，为找出根本问题提供依据。
273 1. 应该定期（半年/季/月/周）对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以持续改进事件管理流程。
274 1. 事件主要来源于用户的电话、邮件、短信和自助平台，以及告警系统对事件的触发等几种情况。其中服务台主要受理来自用户电话、自助平台的事件申告；一线支持主要受理来自助平台、邮件、短信和告警系统的事件申告。
275 1. 用户发起的预授权变更走事件管理的服务请求事件流程；IT支持人员发起的变更都走变更管理流程。
276
277 === ===
278
279 === **4.1.2 分配原则** ===
280
281 事件的分配原则具体描述如下：
282
283 1. 服务台/一线支持不能解决事件，将事件分配给适合的二线支持工作组或二线支持人员。当不确定具体分配人时，可不填写支持人员。二线支持工作组的所有人员都能看到分派到本组的事件申请单，当二线支持人员接管事件的处理时，应将自己填入到分配人中。
284 1. 二线支持人员对不适合自己处理的事件，一定要先退回原分派的服务台/一线支持，由服务台/一线支持重新分配。
285 1. 通常情况，服务台/一线支持重新分配的次数建议不要超过4次。
286
287 === ===
288
289 === **4.1.3 通知原则** ===
290
291 通知原则的目的是提醒与事件相关的事件处理人、事件经理和管理层，以便及时地了解事件发展的状况，做出快速的应对，有效地监控事件流程的整体运行情况。
292
293 1. 如果事件没有在线解决，需要通过邮件、电话、短信等方式告知用户。
294 1. 事件被分配，有具体的分配人则通知到人，如只有分配工作组，则通知所有组内人员
295 1. 事件超过响应时限、即将超过和已经超过解决时限，要通知事件相关人员。（具体参见《事件响应、解决和通告时限规定文档》）
296 1. 出现重大事件时，事件经理要及时通知上级主管部门及人员。
297 1. 事件已经解决，但无法电话联系用户时，需通过邮件、短信等手段通知用户，用户24小时内没有异议则默认事件关闭。
298
299 === ===
300
301 === **4.1.4 升级原则** ===
302
303 制定升级原则的目的是确保事件在服务级别协议（SLA）规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，从而提供合适的资源，以快速找到解决事件的方案。
304
305 1. 服务台/一线支持应对事件的影响程度和影响范围，以及紧急程度进行初步评估，如果事件的影响范围广，影响程度深，时效性要求高的事件可以升级为重大事件，由事件经理直接负责。（可参考事件优先级划分文档及重大事件分类文档）
306 1. 服务台/一线支持对超出能力范围的事件应升级到二线支持处理，同时将事件相关信息转移给二线支持; 如果二线支持仍然无法及时解决，可申请第三方/供应商支持，事件经理根据UC或处理成本等评估进行审批，由二线支持和第三方/供应商共同解决。
307 1. 事件经理应将网管中心现有技术水平无法控制和解决的重大紧急事件升级第三方/供应商支持，以借助外部资源进口解决事件，确保业务尽快恢复正常；同时，根据网管中心要求上报有关领导与机构。
308 1. 对于升级的事件，处理人员应填写相关的申请表单或标注升级标记后，交由他人处理。
309
310
311 === **4.1.5 关闭原则** ===
312
313 用户申报的事件关闭必须由受理事件的服务台/一线支持完成。
314
315 1. 服务台/一线支持在事件关闭前，应与用户进行沟通，了解事件支持与处理的服务效率，服务质量和服务态度。
316 1. 服务台应定期与客户针对已关闭的事件进行回顾，了解客户的反馈。
317 1. 服务台/一线支持在关闭事件前，应将事件生命周期中所产生的所有表单信息进行归档。
318 1. 对于暂时恢复的事件，在事件关闭时，服务台/一线支持应将其升级为问题管理，并填写相应的问题申请单。
319 1. 已关闭的事件不允许重开。如果一个事件重复发生，则应创建一个新的事件申请单。
320 1. 如果事件存在相关联的问题或变更，应等待问题或变更关闭后才能关闭原事件。
321
322
323 == **4.2 流程关联原则** ==
324
325 事件管理与问题管理、变更管理、发布管理、配置管理、可用性管理和能力管理存在以下关联原则：
326
327 * 和问题管理的关联
328 ** 通过临时解决方法解决的事件在恢复客户IT服务后，都应该创建问题单，问题单需和事件申请单要建立关联。
329 ** 相关问题解决以后，需要将解决方案等信息反馈到事件管理流程中，从而避免故障的重复发生。
330 * 和变更管理的关联
331 ** 事件处理过程中，如果需要对系统进行变更，必须按照变更管理流程的规定，提交变更申请单（变更单和事件申请单要建立关联），变更完成后，再继续事件申请单的处理。
332 ** 当发生重大事件时，如果需要对系统进行变更，必须按照变更管理流程的规定，提出紧急变更请求。变更完成后，如果没有填写紧急变更单，必须补录紧急变更单，并要和重大事件申请单建立关联。
333 ** 对于错误或者不成功的变更所引起的事件，需要按照事件管理流程进行解决和改善。
334 * 和配置管理的关联
335 ** 事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件或变更，来帮助故障的定位。
336 ** 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件申请单与该配置项关联。
337 ** 对于配置项等信息的修改，需要及时反馈给事件经理，并走变更管理流程，以避免由此引发新的故障。
338 * 和发布管理的关联
339 ** 不成功的发布可能触发新事件的产生，其触发的事件按照事件管理流程进行解决和恢复。
340 ** 发布管理流程应向事件管理流程提供发布的相关信息，包括：年度发布计划，发布信息等，以确保事件管理的有效控制。
341 * 和可用性管理/能力管理的关联
342 ** 在日常系统检测中，当发现的IT基础设施问题或一些潜在故障时，应通过事件管理流程进行解决。
343 ** 当发生的事件需要调整相关的可用性指标和能力指标时，例如安全事件处理，则需要在通过可用性与能力的完善和修改后，反馈事件管理流程。
344 * 和知识管理的关联
345 ** 在事件处理过程中，会调用知识库中与事件相关的知识。
346 ** 事件处理完毕后，如果知识库没有处理相关事件的解决方案或变通方法。则可将该事件处理的解决方案/变通方法通告知识管理存入知识库中。
347
348
349 (% style="text-align:center" %)
350 [[image:1730193362660-174.png]]
351
352
353 == **4.3 入口原则** ==
354
355 合同范围内，事件管理流程运作过程中需要输入的信息包括：
356
357 1. 用户通过电话、邮件、自助平台等方式申告的事件
358 1. IT环境中监控系统的告警事件
359 1. 服务人员巡检过程中发现或其他人员转告的申告事件
360 1. 配置管理数据库(CMDB)提供的相关配置信息（CI）
361 1. 知识库提供的已知错误及解决方案信息
362 1. 供应商提供的其产品信息，包括产品技术细节和产品本身存在的已知错误
363 1. 服务目录和服务级别协议(SLA)
364
365
366 |名称|描述|模板|输入
367 |(((
368 故障申告
369
370 服务请求
371 )))|(((
372 1. 客户IT系统故障详细信息，包括：客户信息、故障描述，故障类型，影响及紧急程度等
373 1. 客户对IT环境及业务系统的应用服务需求
374 )))|事件申请单|(((
375 用户
376
377 可用性管理
378
379 能力管理
380 )))
381 |配置信息|(((
382 1. 与事件关联的配置项信息
383 )))|CMDB|配置管理
384 |(((
385 已知错误
386
387 解决方案
388 )))|(((
389 1. 与事件关联的已知错误信息及相关的解决方案
390 )))|知识库|知识库
391 |产品信息|(((
392 1. 供应商提供的与事件相关的产品信息，包括产品的缺陷、功能、应用范围等
393 )))|产品信息|供应商
394 |(((
395 服务目录
396
397 服务级别协议
398 )))|(((
399 1. 网管中心级的服务级别协议及服务目录
400 )))|(((
401 服务目录
402
403 服务级别协议
404 )))|服务级别管理
405
406
407 |序号|来源方式|说明
408 |1|电话|用户通过电话申告的事件，需要服务台/一线支持人员创建事件申请单。
409 |2|邮件|用户通过电子邮件向服务台/一线支持人员申报事件。
410 |3|自助平台|用户通过自助平台（网上）填写事件申请单申报事件。
411 |4|监控告警|通过后台监控软件/工具自动转发事件。
412
413
414 == **4.4 出口原则** ==
415
416 合同范围内，事件管理流程运作过程中需要输出的信息包括：
417
418 1. 向用户提供事件的处理措施或解决方案
419 1. 事件处理过程中，涉及变更时需向变更管理流程提出变更申请
420 1. 事件没有的得到根本解决，向问题管理流程提出问题解决申请
421 1. 事件处理过程中，涉及配置信息的变更，向配置管理流程提出配置申请
422 1. 根据事件管理情况，定期提供事件管理的相关分析报告
423
424
425 |名称|(% style="width:840px" %)描述|(% style="width:148px" %)模板|(% style="width:192px" %)输出
426 |(((
427 故障解决方案
428
429 服务请求处理信息
430 )))|(% style="width:840px" %)(((
431
432
433 * 根据用户提出的故障申告及服务请求申告，及时提供有关的解决方案及处理措施
434 )))|(% style="width:148px" %)事件申请单|(% style="width:192px" %)用户
435 |变更申请|(% style="width:840px" %)(((
436
437
438 * (% id="cke_bm_1143S" style="display:none" %) (% id="cke_bm_1091S" style="display:none" %) (%%)事件处理中涉及的变更申请，包括变更目标、内容、策略、联系人等(% id="cke_bm_1143E" style="display:none" %) (% id="cke_bm_1091E" style="display:none" %)
439 )))|(% style="width:148px" %)变更申请单|(% style="width:192px" %)变更管理
440 |配置更新|(% style="width:840px" %)(((
441
442
443 * (% id="cke_bm_1142S" style="display:none" %) (% id="cke_bm_1090S" style="display:none" %) (%%)事件处理中涉及配置信息的更新时，提出的配置更新，包括配置内容、时间等(% id="cke_bm_1142E" style="display:none" %) (% id="cke_bm_1090E" style="display:none" %)
444 )))|(% style="width:148px" %)配置申请表|(% style="width:192px" %)配置管理
445 |问题申请|(% style="width:840px" %)(((
446
447
448 * (% id="cke_bm_1141S" style="display:none" %) (% id="cke_bm_1089S" style="display:none" %) (%%)故障没有得到根本解决，需升级为问题时，向问题管理流程提供问题申请(% id="cke_bm_1141E" style="display:none" %) (% id="cke_bm_1089E" style="display:none" %)
449 )))|(% style="width:148px" %)问题申请表|(% style="width:192px" %)问题管理
450 |解决方案|(% style="width:840px" %)(((
451
452
453 * (% id="cke_bm_1140S" style="display:none" %) (% id="cke_bm_1088S" style="display:none" %) (%%)通过诊断分析，确定了处理事件的解决方案/变更方法，则可通告知识管理流程将解决方案/变更方法保存到知识库中。(% id="cke_bm_1140E" style="display:none" %) (% id="cke_bm_1088E" style="display:none" %)
454 )))|(% style="width:148px" %)(((
455 知识提交单
456
457 解决方案/
458
459 变通方法
460 )))|(% style="width:192px" %)知识管理
461 |服务报告|(% style="width:840px" %)(((
462
463
464 * (% id="cke_bm_1139S" style="display:none" %) (% id="cke_bm_1087S" style="display:none" %) (%%)定期对事件管理进行回顾，总结服务的质量，效率等信息(% id="cke_bm_1139E" style="display:none" %) (% id="cke_bm_1087E" style="display:none" %)
465 )))|(% style="width:148px" %)服务报告|(% style="width:192px" %)(((
466 能力管理
467
468 可用性管理
469
470 服务级别管理
471 )))
472
473
474
475 = **5. 工作流程** =
476
477 == **5.1 事件管理主流程** ==
478
479 === **5.1.1 流程描述** ===
480
481 此流程是事件管理的主流程，它涵盖了事件记录与分类分级（帮助台）、事件记录与分类分级（一线支持）、服务请求处理、重大事件处理、故障一线支持与处理、故障二线支持与处理、协调第三方支持和事件关闭等子流程。事件管理流程主要是为了帮助用户迅速解决事件，并确保事件对业务的不利影响最小化。流程始于事件的接收和申告，结束于经过用户确认的事件的解决。
482
483 === ===
484
485 === **5.1.2 流程图** ===
486
487 (% style="text-align:center" %)
488 [[image:图片9.jpg]]
489
490
491
492 === **5.1.3 流程说明** ===
493
494 |序号|活动/子流程|(% style="width:769px" %)描述|(% style="width:102px" %)输入|(% style="width:125px" %)输出|责任人
495 |1|开始|(% style="width:769px" %)流程的起始节点|(% style="width:102px" %) |(% style="width:125px" %) |
496 |2|(((
497 INC-01
498
499 事件记录与分类分级（服务台）
500 )))|(% style="width:769px" %)(((
501
502
503 * 服务台受理来自电话、自助平台的事件申告（包括服务请求、故障申告）。
504 * 服务台既承担着受理事件申告的职责，也承担着处理服务请求类事件的职责。
505 * 服务台根据用户的申告，创建事件记录，收集所需信息，确保记录信息的准确和完整。
506 * 服务台根据事件的分类与优先级，将事件直接分派给一线支持、现场工程师、二线支持和事件经理等不同的角色进行处理。
507 )))|(% style="width:102px" %)事件申请单|(% style="width:125px" %)事件申请单|服务台
508 |3|(((
509 INC-02
510
511 事件记录与分类分级（一线支持）
512 )))|(% style="width:769px" %)(((
513
514
515 * 一线支持受理来自自助平台、邮件、短信和告警系统的事件申告（包括服务请求、故障申告）。
516 * 一线支持既承担着受理事件申告的职责，也承担着处理服务请求类事件和故障类事件的职责。
517 * 一线支持根据用户的申告，创建事件记录，收集所需信息，确保记录信息的准确和完整。
518 * 一线支持根据事件的分类与优先级，将事件直接分派给、现场工程师、二线支持和事件经理等不同的角色进行处理。
519 )))|(% style="width:102px" %)事件申请单|(% style="width:125px" %)事件申请单|一线支持
520 |4|(((
521 INC-03
522
523 服务请求事件处理
524 )))|(% style="width:769px" %)(((
525
526
527 * 服务台/一线支持处理服务请求类事件。
528 * 服务台根据服务请求的类型，将事件分派给一线支持、现场工程师、二线支持等不同角色处理。
529 * 一线支持根据服务请求的类型，将事件分派给现场工程师、二线支持等不同角色处理。
530 * 如果一线支持受理的服务请求类的事件是服务台所负责的服务请求类事件，则由一线支持直接转派给服务台处理。
531 * 如果服务请求事件是关于客户需求、客户服务建议等信息，则由服务台记录基本信息后，关闭事件，并将信息转给相关流程。
532 )))|(% style="width:102px" %)事件申请单|(% style="width:125px" %)(((
533 事件申请单
534
535 投诉建议
536
537 客户需求
538 )))|(((
539 服务台/
540
541 现场工程师
542 )))
543 |5|(((
544 INC-04
545
546 重大事件处理
547 )))|(% style="width:769px" %)(((
548
549
550 * 接受对服务台/一线支持分派的重大故障处理。
551 * 事件经理组织启动相关的紧急预案，并上报相关机构与领导。
552 * 事件经理组织协调各方资源，支持应急小组分析诊断与解决重大故障。
553 * 应急小组尽快解决重大故障，并负责善后处理工作。
554 * 在解决重大故障的过程中，如果需要变更，需提出紧急变更请求，走变更管理流程。
555 )))|(% style="width:102px" %)事件申请单|(% style="width:125px" %)事件申请单|(((
556 事件经理
557
558 应急小组
559 )))
560 |6|(((
561 INC-05
562
563 故障一线支持与处理
564 )))|(% style="width:769px" %)(((
565
566
567 * 处理服务台分派或一线支持受理的故障类事件。
568 * 根据知识库处理常规故障。
569 * 通过故障分析与诊断，提出故障解决方案/变通方法。
570 * 在解决故障的过程中，如果需要发生变更，则需提出变更请求，走变更管理流程。
571 * 如果在时限内无法解决故障，则需将故障升级二线支持处理。
572 * 故障解决后，需对故障的解决方案或变通方法进行文档化。
573 * 故障处理后，需反馈故障处理结果给分派方（服务台）。
574 )))|(% style="width:102px" %)(((
575 事件申请单
576
577 已知错误
578
579 解决方案
580 )))|(% style="width:125px" %)事件申请单|一线支持
581 |7|(((
582 INC-06
583
584 故障二线支持与处理
585 )))|(% style="width:769px" %)(((
586
587
588 * 处理服务台分派的故障类事件。
589 * 接受与处理一线支持升级的故障类事件。
590 * 通过故障分析与诊断，提出故障解决方案/变通方法。
591 * 在解决故障的过程中，如果需要发生变更，则需提出变更请求，走变更管理流程。
592 * 在规定时限内无法解决的故障，需升级协调第三方支持。
593 * 故障处理后，对故障的解决方案或变通方法进行文档化。
594 * 故障处理后，需反馈故障处理结果给分派方（服务台或一线支持）。
595 )))|(% style="width:102px" %)(((
596 事件申请单
597
598 已知错误
599
600 解决方案
601 )))|(% style="width:125px" %)(((
602 事件申请单
603
604 变更申请单
605 )))|二线支持
606 |8|(((
607 INC-07
608
609 协调第三方支持
610 )))|(% style="width:769px" %)(((
611
612
613 * 二线支持无法在规定时限内解决的故障，升级第三方/供应商处理。
614 * 根据需要对故障处理的相关信息进行整理和归类。
615 * 将整理后的信息提供给第三方/供应商。
616 * 定期与第三方/供应商进行沟通，确保故障及时解决。
617 * 二线支持申请第三方/供应商提供支持时，必须通过事件经理审批。事件经理将从故障处理成本、服务级别协议指标等因素综合考虑。
618 )))|(% style="width:102px" %)(((
619 事件申请单
620
621 第三方申请单
622 )))|(% style="width:125px" %)事件申请单|事件经理
623 |9|(((
624 INC-08
625
626 事件关闭
627 )))|(% style="width:769px" %)(((
628
629
630 * 事件关闭之前，需要受理方（服务台或一线支持）及时通知用户，并沟通事件处理效果，得到认可后关闭事件。
631 * 回顾事件处理，如果故障是采用变通方法解决的，同时需要进一步找出故障的根本原因，则需要提起问题申请单，交问题管理流程。
632 * 根据故障处理结果，受理方（服务台或一线支持）需完善故障处理过程的相关文档
633 * 如果需要将已确定的解决方案/变通方法存入知识库中，则需提交知识申请单，走知识管理流程。
634 * 事件关闭遵循首问责任制，谁受理谁负责谁关闭的原则。
635 )))|(% style="width:102px" %)事件申请单|(% style="width:125px" %)(((
636 事件申请单
637
638 问题申请单
639
640 知识申请单
641 )))|(((
642 服务台/
643
644 一线支持
645 )))
646 |10|结束|(% style="width:769px" %)流程结束节点。|(% style="width:102px" %) |(% style="width:125px" %) |
647
648
649 == **5.2 子流程1：事件记录与分类分派（服务台）** ==
650
651 === **5.2.1 子流程描述** ===
652
653 该子流程是事件管理流程的起始点之一，是服务台受理来自电话、自助平台等渠道的服务请求类和故障类事件，并有效记录事件信息，以及根据事件分类分级进行事件分派的管理流程。服务台通过规范的流程不仅可确保事件信息记录的准确性与完整性，同时通过正确的事件分类分级和事件分派，还可达到提高事件处理质量与效率的目的。
654
655 === ===
656
657 === **5.2.2 流程图** ===
658
659 (% style="text-align:center" %)
660 [[image:图片10.jpg]]
superadmin 4.2 661
662
663 === **5.2.3 流程说明** ===
664
665 |序号|活动/子流程|描述|输入|输出|责任人
666 |1|开始|流程的起始节点 。|-|-|
667 |2|(((
668 L1.1
669
670 是否来自自助平台
671 )))|(((
672
673
674 * 判断用户申告的事件是来自自助平台，还是电话。
675 * 如果来自自助平台，事件信息自动导入。
676 * 如果来自电话，需要服务台进行事件记录。
677 * 自助平台发起的事件已有事件的信息记录；电话发起的事件需要服务台帮助记录。
678 )))|-|-|服务台
679 |3|(((
680 L1.2
681
682 事件记录
683 )))|(((
684
685
686 * (% id="cke_bm_11576S" style="display:none" %) (%%)服务台根据用户的申告，记录事件信息。
687 * 可通过工具对事件信息进行详细记录，包括事件症状，影响，申告人、联系方式等信息。
688 * 工具既可以是IT服务支持的平台工具，也可采用Excel，Word等工具。(% id="cke_bm_11576E" style="display:none" %)
689 )))|用户信息|事件信息|服务台
690 |4|(((
691 L1.3
692
693 判断服务范围
694 )))|(((
695
696
697 * (% id="cke_bm_11575S" style="display:none" %) (%%)服务台根据网管中心IT运维服务的服务目录和服务级别协议对受理的事件信息，判断是否在网管中心IT运维服务范围。
698 * 如果不在服务范围，则直接回复用户。
699 * 如果在服务范围，则受理服务请求，验证事件信息的完整性。(% id="cke_bm_11575E" style="display:none" %)
700 )))|-|-|
701 |5|(((
702 L1.4
703
704 回复/配合
705 )))|(((
706
707
708 * (% id="cke_bm_11841S" style="display:none" %) (%%)直接回复用户，解释其服务请求不在网管中心IT运维服务范围内。
709 * 如果是VIP客户，可适当配合，提供一定的协助咨询服务。
710 * 如果用户提供的信息是需求信息，可记录之后，转给相关部门或需求管理流程。(% id="cke_bm_11841E" style="display:none" %)
711 )))|事件信息|回复信息|服务台
712 |6|(((
713 L1.5
714
715 事件信息完整性
716
717 确认
718 )))|(((
719
720
721 * 服务台根据事件信息，生成事件申请单，正式受理用户事件申告。
722 * 如果发现事件信息不准确、不完整，需与用户进行沟通，完善事件申请单的信息。
723 )))|事件信息|事件申请单|服务台
724 |7|(((
725 L1.6
726
727 判断事件类别
728 )))|(((
729
730
731 * 根据事件分类规则，判断事件类型，可具体到事件分类三级。
732 * 如果是服务请求类事件，标注服务请求类。
733 * 如果是故障类事件，需进行故障等级判断。
734 )))|事件申请单|事件申请单|服务台
735 |8|(((
736 L1.7
737
738 转INC-03:服务请求处理流程
739 )))|(((
740
741
742 * 将事件申请单直接转服务请求处理流程，对事件进行处理。
743 )))|事件申请单|事件申请单|服务台
744 |9|(((
745 L1.8
746
747 判断故障优先级
748 )))|(((
749
750
751 * 根据故障的影响度和紧急度，判断故障的优先级。
752 * 事件的优先级可参考《事件分级》相关文件的定义。
753 )))|-|-|
754 |10|(((
755 L1.9
756
757 转INC-06:重大事件处理流程
758 )))|(((
759
760
761 * 服务台根据事件优先级的规则，判断事件等级是极高，则标记事件为重大事件，并提交重大事件处理流程。
762 * 一般事件的影响度和紧急度会有初始设定，服务台根据与用户的交流，可更新其影响度和紧急度，改变故障优先级。
763 )))|事件申请单|事件申请单|服务台
764 |11|(((
765 L1.10
766
767 判断重复故障
768 )))|(((
769
770
771 * 判断是否是重复性故障申告，如果是，则进行重复性故障处理。
772 )))|-|-|服务台
773 |12|(((
774 L1.11
775
776 重复故障处理
777 )))|(((
778
779
780 * 若用户提报的事件为重复故障，则服务台需要关联相对应的主事件，并按照主事件的解决方案进行处理。
781 )))|事件申请单|事件申请单|服务台
782 |13|(((
783 L1.12
784
785 故障派单
786 )))|(((
787
788
789 * 如果申告的故障等级非极高，则根据故障类型进行任务分配。
790 * 服务台“分派”的故障事件，最终事件处理完成后，需要反馈事件处理结果由服务台关闭此事件。
791 )))|-|-|服务台
792 |14|(((
793 L1.13
794
795 分派现场服务
796 )))|(((
797
798
799 * 如果需要现场故障处理，则派单现场工程师实施现场服务
800 )))|事件申请单|(((
801 现场工单
802
803 事件申请单
804 )))|服务台
805 |15|(((
806 L2.1
807
808 现场服务
809 )))|(((
810
811
812 * 现场工程师到用户现场进行故障处理。
813 )))|(((
814 现场工单
815
816 事件申请单
817 )))|事件申请单|(((
818 现场
819
820 工程师
821 )))
822 |16|(((
823 L2.2
824
825 反馈服务结果
826 )))|(((
827
828
829 * 现场服务完成后，需反馈现场故障处理情况，包括故障现象、解决方案、是否解决等
830 )))|事件申请单|事件申请单|(((
831 现场
832
833 工程师
834 )))
835 |17|(((
836 L1.14
837
838 分派一线支持
839 )))|(((
840
841
842 * 如果需要一线支持提供服务，则直接分派一线支持，并转一线支持与处理流程。
843 )))|事件申请单|事件申请单|服务台
844 |18|(((
845 L1.15
846
847 分派二线支持
848 )))|(((
849
850
851 * 如果需要二线支持提供服务，则直接分派二线支持，并转二线支持与处理流程。
852 )))|事件申请单|事件申请单|服务台
853 |19|结束|流程结束节点。| | |
854
855
856 == **5.3 子流程2：事件记录与分类分派（一线支持）** ==
857
858 === **5.3.1 子流程描述** ===
859
860 该子流程是事件管理流程的起始点之一，是一线支持受理来自自助平台、邮件、短信和告警系统等渠道的服务请求类和故障类事件，并有效记录事件信息，以及根据事件分类分级进行事件分派的管理流程。一线支持通过规范的流程不仅可确保事件信息记录的准确性与完整性，同时通过正确的事件分类分级和事件分派，可达到提高事件处理质量与效率的目的。
861
862 === ===
863
864 === **5.3.2 流程图** ===
865
866 (% style="text-align:center" %)
867 [[image:图片11.jpg]]
868
869
870 === **5.3.3 流程说明** ===
871
872 |序号|活动/子流程|描述|输入|输出|责任人
873 |1|开始|流程的起始节点 。|-|-|
874 |2|(((
875 L1.1
876
877 是否来自告警系统
878 )))|(((
879
880
881 * 判断用户申告的事件是来自告警系统，还是自助平台、邮件、短信。
882 * 如果是告警系统发起的事件，则直接确认事件信息的完整性。
883 * 如果事件来自自助平台、邮件、短信等渠道，需要一线支持进行服务范围的判断。
884 * 告警系统发起的事件都是故障类事件；自助平台、邮件、短信等渠道发起的事件包括服务请求类和故障类事件。
885 )))|-|-|一线支持
886 |3|(((
887 L1.2
888
889 判断服务范围
890 )))|(((
891
892
893 * 一线支持根据网管中心IT运维服务的服务目录和服务级别协议对受理的事件信息，判断是否在网管中心IT运维服务范围。
894 * 如果不在服务范围，则直接回复用户。
895 * 如果在服务范围，则受理服务请求，验证事件信息的完整性。
896 )))|-|-|
897 |4|(((
898 L1.3
899
900 回复/配合
901 )))|(((
902
903
904 * 直接回复用户，解释其服务请求不在网管中心IT运维服务范围内。
905 * 如果是VIP客户，可适当配合，提供一定的配合性服务。
906 * 如果用户提供的信息是需求信息，可记录之后，转给相关部门或需求管理流程。
907 )))|事件信息|回复信息|一线支持
908 |5|(((
909 L1.4
910
911 事件信息完整性
912
913 确认
914 )))|(((
915
916
917 * 一线支持根据事件信息，生成事件申请单，正式受理用户事件申告。
918 * 如果发现事件信息不准确、不完整，需与用户进行沟通，完善事件申请单的信息。
919 )))|事件信息|事件申请单|一线支持
920 |6|(((
921 L1.5
922
923 判断事件类别
924 )))|(((
925
926
927 * 根据事件分类规则，判断事件类型，可具体到事件分类三级。
928 * 如果是服务请求类事件，标注服务请求类。
929 * 如果是故障类事件，需进行故障等级判断。
930 )))|事件申请单|事件申请单|一线支持
931 |7|(((
932 L1.6
933
934 转INC-03:服务请求处理流程
935 )))|(((
936
937
938 * 将事件申请单直接转服务请求处理流程，对事件进行处理。
939 )))|事件申请单|事件申请单|一线支持
940 |8|(((
941 L1.7
942
943 判断故障优先级
944 )))|(((
945
946
947 * 根据故障的影响度和紧急度，判断故障的优先级。
948 * 事件的优先级可参考《事件分级》相关文件的定义。
949 )))|-|-|
950 |9|(((
951 L1.8
952
953 转INC-06:重大事件处理流程
954
955
956 )))|(((
957
958
959 * 根据事件优先级的规则，判断事件等级是极高，则标记事件为重大事件，并提交重大事件处理流程。
960 * 一般事件的影响度和紧急度会有初始设定，一线支持根据与用户的交流，可更新其影响度和紧急度，改变故障优先级。
961 )))|事件申请单|事件申请单|一线支持
962 |10|(((
963 L1.9
964
965 判断重复故障
966 )))|(((
967
968
969 * 判断是否是重复性故障申告，如果是，则进行重复性故障处理。
970 )))|-|-|服务台
971 |11|(((
972 L1.10
973
974 重复故障处理
975 )))|(((
976
977
978 * 若用户提报的事件为重复故障，则服务台需要关联相对应的主事件，并按照主事件的解决方案进行处理。
979 )))|事件申请单|事件申请单|服务台
980 |12|(((
981 L1.11
982
983 故障派单
984 )))|(((
985
986
987 * 如果申告的故障等级非极高，则根据故障类型进行任务分配。
988 * 一线支持“分派”的故障事件，最终事件处理完成后，需要反馈事件处理结果由一线支持关闭此事件。
989 )))|-|-|一线支持
990 |13|(((
991 L1.12
992
993 分派现场服务
994 )))|(((
995
996
997 * 如果需要现场故障处理，则派现场工单给现场工程师实施现场服务
998 )))|事件申请单|(((
999 现场工单
1000
1001 事件申请单
1002 )))|一线支持
1003 |14|(((
1004 L2.1
1005
1006 现场服务
1007 )))|(((
1008
1009
1010 * 现场工程师到用户现场进行故障处理。
1011 )))|(((
1012 现场工单
1013
1014 事件申请单
1015 )))|事件申请单|(((
1016 现场
1017
1018 工程师
1019 )))
1020 |15|(((
1021 L2.2
1022
1023 反馈服务结果
1024 )))|(((
1025
1026
1027 * 现场服务完成后，需向一线支持反馈现场故障处理情况，包括故障现象、解决方案、是否解决等。
1028 )))|事件申请单|事件申请单|(((
1029 现场
1030
1031 工程师
1032 )))
1033 |16|(((
1034 L1.13
1035
1036 分派二线支持
1037 )))|(((
1038
1039
1040 * 如果需要二线支持提供服务，则直接分派二线支持，并转二线支持与处理流程。
1041 )))|事件申请单|事件申请单|一线支持
1042 |17|结束|流程结束节点。| | |
1043
superadmin 11.1 1044
1045
1046 == **5.4 子流程3：服务请求事件处理** ==
1047
1048 === **5.4.1 子流程描述** ===
1049
1050 该子流程是服务台或一线支持针对服务请求类事件，按照不同角色的服务职责，科学合理地分（转）派事件，以及及时地处理服务请求类事件的管理流程。服务请求类事件采用谁受理，谁负责和谁关闭的原则，但是，如果一线支持受理的服务请求事件需要服务台处理，则是直接“转派”给服务台受理与处理，不再执行任务“分派”，也就是将事件直接转给服务台，由服务台对该事件受理、负责与关闭。
1051
1052
1053 === **5.4.2流程图** ===
1054
1055 (% style="text-align:center" %)
1056 [[image:1730198831968-776.png]]
1057
1058
1059 === **5.4.3 流程说明** ===
1060
1061 |序号|活动/子流程|(% style="width:876px" %)描述|(% style="width:94px" %)输入|(% style="width:112px" %)输出|责任人
1062 |1|开始|(% style="width:876px" %)流程开始流程的起始节点 。|(% style="width:94px" %) |(% style="width:112px" %) |
1063 |2|(((
1064 L1.1
1065
1066 明确服务请求需求
1067 )))|(% style="width:876px" %)(((
superadmin 4.2 1068
superadmin 11.1 1069
1070 * 服务台/一线支持与用户进一步沟通，明确用户的服务需求。
1071 )))|(% style="width:94px" %)事件申请单|(% style="width:112px" %)事件申请单|服务台/一线支持
1072 |3|(((
1073 L1.2
1074
1075 选择与分(转)派
1076
1077 服务支持
1078 )))|(% style="width:876px" %)(((
1079
1080
1081 * 根据服务请求事件的分类，分派不同角色。
1082 * 如果是服务台“分派”的事件，需要由服务台关闭此事件；如果是一线支持“分派”的事件需要由一线支持关闭此事件。
1083 * 如果一线支持受理的服务请求事件需要服务台处理，则直接“转派”给服务台受理与处理，不再执行任务“分派”。也就是将事件直接转给服务台，由服务台对该事件负责。
1084 )))|(% style="width:94px" %)事件申请单|(% style="width:112px" %)事件申请单|服务台/一线支持
1085 |4|(((
1086 L1.3
1087
1088 服务台解决
1089 )))|(% style="width:876px" %)(((
1090
1091
1092 * 服务台对所负责的服务请求事件进行处理。
1093 * 事件处理完，由服务台关闭此事件。
1094 )))|(% style="width:94px" %)事件申请单|(% style="width:112px" %)事件申请单|服务台
1095 |5|(((
1096 L2.1
1097
1098 一线支持与服务
1099 )))|(% style="width:876px" %)(((
1100
1101
1102 * 一线支持对所负责的服务请求事件进行处理。
1103 * 事件处理完，如果事件是服务台“分派”的事件，返回服务台服务结果，由服务台关闭此事件。
1104 * 事件处理完，如果事件是一线支持受理的事件，由一线支持关闭此事件。
1105 )))|(% style="width:94px" %)事件申请单|(% style="width:112px" %)事件申请单|一线支持
1106 |6|(((
1107 L3.1
1108
1109 现场服务
1110 )))|(% style="width:876px" %)(((
1111
1112
1113 * 现场工程师实现现场服务，并返回服务结果给“分派”方（服务台或一线支持）。
1114 * 事件处理完，如果事件是服务台“分派”的事件，返回服务台服务结果，由服务台关闭此事件。
1115 * 事件处理完，如果事件是一线支持“分派”的事件，返回一线支持服务结果，由一线支持关闭此事件。。
1116 )))|(% style="width:94px" %)事件申请单|(% style="width:112px" %)事件申请单|现场工程师
1117 |7|(((
1118 L4.1
1119
1120 二线支持与服务
1121 )))|(% style="width:876px" %)(((
1122
1123
1124 * 二线支持实现服务请求服务，并返回服务结果给“分派”方（服务台或一线支持）。
1125 * 事件处理完，如果事件是服务台“分派”的事件，返回服务台服务结果，由服务台关闭此事件。
1126 * 事件处理完，如果事件是一线支持“分派”的事件，返回一线支持服务结果，由一线支持关闭此事件。
1127 )))|(% style="width:94px" %)事件申请单|(% style="width:112px" %)事件申请单|二线支持
1128 |8|结束|(% style="width:876px" %)流程结束节点。|(% style="width:94px" %) |(% style="width:112px" %) |
1129
1130
1131
1132 == **5.5 子流程4：故障一线支持与处理** ==
1133
1134 === **5.5.1 子流程描述** ===
1135
1136 该子流程是处理服务台分派或一线支持受理的故障类事件的流程。一线支持基于记录与沟通的故障信息，根据自己的专业知识，借助知识库的支撑，诊断分析故障原因，提出适合的故障解决方案，达到对故障的及时处理。如果一线支持无法及时解决故障，需主动升级二线支持解决。在故障处理过程中，如果涉及变更，则需要提交变更申请单走变更管理流程；如果故障仅是通过变通方法解决而没有根本性解决，则需要创建问题申请单走问题管理流程。
1137
1138 === ===
1139
1140 === **5.5.2 流程图** ===
1141
1142
1143 (% style="text-align:center" %)
1144 [[image:图片12.jpg]]
1145
1146
1147 === **5.5.3 流程说明** ===
1148
1149 |序号|活动/子流程|(% style="width:922px" %)描述|(% style="width:98px" %)输入|(% style="width:93px" %)输出|(% style="width:92px" %)责任人
1150 |1|开始|(% style="width:922px" %)流程的起始节点 。|(% style="width:98px" %) |(% style="width:93px" %) |(% style="width:92px" %)
1151 |2|(((
1152 L1.1
1153
1154 明确支持需求
1155 )))|(% style="width:922px" %)(((
1156
1157
1158 * 一线支持受理或接受分派的事件请求后，如果需要与用户进一步沟通，可根据事件申请单信息联系用户，进行深层次了解事件情况，为评估诊断和提供解决方案奠定基础。
1159 )))|(% style="width:98px" %)事件申请单|(% style="width:93px" %)事件申请单|(% style="width:92px" %)一线支持
1160 |3|(((
1161 L1.2
1162
1163 故障诊断分析
1164
1165 及解决
1166 )))|(% style="width:922px" %)(((
1167
1168
1169 * 依据专业知识，借助已有的知识库对事件现象进行诊断分析，查明原因。
1170 * 查询配置数据库中受影响的配置项的属性和配置项间的关联关系，以定位故障。
1171 * 根据对故障的评估诊断，提供合理的解决方案或变通方法。
1172 * 如果是变通方法，在提供解决方案的同时，标注变通方法标记。
1173 * 如果故障处理过程中，涉及变更，需提交变更申请单，交变更管理流程。
1174 * 如果故障仅是通过变通方法解决而没有根本性解决，则需要创建问题申请单，走问题管理流程。
1175 )))|(% style="width:98px" %)(((
1176 事件申请单
1177
1178 已知错误
1179
1180 解决方案
1181
1182 配置信息
1183 )))|(% style="width:93px" %)事件申请单|(% style="width:92px" %)一线支持
1184 |4|(((
1185 L1.3
1186
1187 解决与恢复
1188 )))|(% style="width:922px" %)(((
1189
1190
1191 * 判断故障是否解决，如果在规定时限内无法解决，则可升级二线支持；如果已解决，则记录与整理解决方案。
1192 )))|(% style="width:98px" %)-|(% style="width:93px" %)-|(% style="width:92px" %)一线支持
1193 |5|(((
1194 L1.4
1195
1196 记录详细
1197
1198 解决方案
1199 )))|(% style="width:922px" %)(((
1200
1201
1202 * 如果故障得到解决，可将此故障的解决方案整理归档，存入知识库中，记录内容可包括详细的解决方案，诊断过程，处理人的信息等。
1203 * 如果是变通方法，需要标明。
1204 * 将处理结果反馈受理方（服务台或一线支持），交受理方关闭事件。
1205 )))|(% style="width:98px" %)(((
1206 解决方案
1207
1208 事件申请单
1209 )))|(% style="width:93px" %)事件申请单|(% style="width:92px" %)一线支持
1210 |6|(((
1211 L1.5
1212
1213 升级二线支持
1214 )))|(% style="width:922px" %)(((
1215
1216
1217 * 如果故障相对复杂，一线支持无法解决，或者故障影响范围和程度较大，则需提交二线支持进行故障评估与解决。
1218 * 标注事件状态，升级二线支持处理。
1219 )))|(% style="width:98px" %)事件申请单|(% style="width:93px" %)事件申请单|(% style="width:92px" %)一线支持
1220 |7|结束|(% style="width:922px" %)流程结束节点。|(% style="width:98px" %) |(% style="width:93px" %) |(% style="width:92px" %)
1221
1222
1223 == **5.6 子流程5：故障二线支持与处理** ==
1224
1225 === **5.6.1 子流程描述** ===
1226
1227 该子流程是处理服务台分派的，以及一线支持升级的故障类事件的流程。二线支持基于一线支持升级的故障信息及处理信息，根据自己的专业知识，借助知识库的支撑，诊断分析故障原因，提出适合的故障解决方案，达到对故障的及时处理。如果二线支持无法及时解决事件，将主动升级事件，与事件经理一起邀请第三方/供应商的支持。在故障的处理过程中，如果涉及变更，需要提交变更申请单，走变更管理流程。如果故障仅是通过变通方法解决而没有根本性解决，则需要创建问题申请单走问题管理流程。
1228
1229 === ===
1230
1231 === **5.6.2 流程图** ===
1232
1233 (% style="text-align:center" %)
1234 [[image:图片13.jpg]]
1235
1236
1237
1238 === **5.6.3 流程说明** ===
1239
1240 |序号|活动/子流程|(% style="width:883px" %)描述|(% style="width:117px" %)输入|(% style="width:111px" %)输出|(% style="width:105px" %)责任人
1241 |1|开始|(% style="width:883px" %)流程的起始节点|(% style="width:117px" %) |(% style="width:111px" %) |(% style="width:105px" %)
1242 |2|(((
1243 L1.1
1244
1245 事件受理及
1246
1247 需求明确
1248 )))|(% style="width:883px" %)(((
1249
1250
1251 * 二线支持在接到服务台分派或一线支持升级的事件后，如果需要与用户或一线支持人员进一步沟通，可根据事件申请单信息联系用户/一线支持人员进行深层次了解事件情况，为评估诊断和提供解决方案奠定基础。
1252 )))|(% style="width:117px" %)事件申请单|(% style="width:111px" %)事件申请单|(% style="width:105px" %)二线支持
1253 |3|(((
1254 L1.2
1255
1256 故障诊断分析
1257
1258 及解决
1259 )))|(% style="width:883px" %)(((
1260
1261
1262 * 二线支持依据专业知识，借助已有的知识库对事件现象进行诊断分析，查明原因。
1263 * 查询配置数据库中受影响的配置项的属性和配置项间的关联关系，以定位故障。
1264 * 根据对故障的评估诊断，提供合理的解决方案或变通方法。
1265 * 如果是变通方法，在提供解决方案的同时，标注变通方法标记。
1266 * 如果故障处理过程中，涉及变更，需提交变更申请单，交变更管理流程。
1267 * 如果故障仅是通过变通方法解决而没有根本性解决，则需要创建问题申请单，走问题管理流程。
1268 )))|(% style="width:117px" %)(((
1269 事件申请单
1270
1271 已知错误
1272
1273 解决方案
1274
1275 配置信息
1276 )))|(% style="width:111px" %)(((
1277 事件申请单
1278
1279 变更申请单
1280 )))|(% style="width:105px" %)二线支持
1281 |4|(((
1282 L1.3
1283
1284 解决与恢复
1285 )))|(% style="width:883px" %)(((
1286
1287
1288 * 判断故障是否解决，如果在规定时限内无法解决，则可升级第三方支持；如果已解决，则记录与整理解决方案。
1289 )))|(% style="width:117px" %)-|(% style="width:111px" %)-|(% style="width:105px" %)二线支持
1290 |5|(((
1291 L1.4
1292
1293 记录详细
1294
1295 解决方案
1296 )))|(% style="width:883px" %)(((
1297
1298
1299 * 如果故障得到解决，可将此故障的解决方案整理归档，存入知识库中，记录内容可包括详细的解决方案，诊断过程，处理人的信息等。
1300 * 如果是变通方法，需要标明。
1301 * 将处理结果反馈受理方（服务台或一线支持），交受理方关闭事件。
1302 )))|(% style="width:117px" %)(((
1303 解决方案
1304
1305 事件申请单
1306 )))|(% style="width:111px" %)事件申请单|(% style="width:105px" %)二线支持
1307 |6|(((
1308 L1.5
1309
1310 升级第三方支持
1311 )))|(% style="width:883px" %)(((
1312
1313
1314 * 如果故障相对复杂困难，二线支持能力范围之内无法解决，或者故障影响范围和程度较大，则需提交第三方/供应商的支持进行事件评估与解决。
1315 * 需要事件经理参与协调。
1316 )))|(% style="width:117px" %)事件申请单|(% style="width:111px" %)(((
1317 第三方申请单
1318
1319 事件申请单
1320 )))|(% style="width:105px" %)二线支持
1321 |7|结束|(% style="width:883px" %)流程结束节点。|(% style="width:117px" %) |(% style="width:111px" %) |(% style="width:105px" %)二线支持
1322
1323
1324 == **5.7 子流程6：重大事件处理** ==
1325
1326 === **5.7.1 子流程描述** ===
1327
1328 该子流程是针对具有影响程度高、影响范围广、紧急程度高等特点的重大故障类事件的处理流程。通常，这类事件需要整个网管中心的统一协调、管理上报、动员附加资源和加强沟通等内容。
1329
1330 === ===
1331
1332 === **5.7.2 流程图** ===
1333
1334 (% style="text-align:center" %)
1335 [[image:图片14.jpg]]
1336
1337
1338 === **5.7.3 流程说明** ===
1339
1340 |序号|活动/子流程|(% style="width:795px" %)描述|(% style="width:139px" %)输入|(% style="width:127px" %)输出|(% style="width:144px" %)责任人
1341 |1|开始|(% style="width:795px" %)流程开始流程的起始节点 。|(% style="width:139px" %) |(% style="width:127px" %) |(% style="width:144px" %)
1342 |2|(((
1343 L1.1
1344
1345 事件评估
1346 )))|(% style="width:795px" %)(((
1347
1348
1349 * 对重大事件的影响范围、影响程度和紧急程度进行评估，为协调资源提供依据。
1350 * 通知相关机构及部门领导
1351 )))|(% style="width:139px" %)事件申请单|(% style="width:127px" %)评估结果|(% style="width:144px" %)事件经理
1352 |3|(((
1353 L1.2
1354
1355 已有应急预案
1356 )))|(% style="width:795px" %)(((
1357
1358
1359 * 判断是否有对应事件的应急预案。
1360 * 如果有，直接交应急小组启动应急预案。
1361 * 如果没有，协调相关专家资源，启动应急小组参与。
1362 )))|(% style="width:139px" %)-|(% style="width:127px" %)-|(% style="width:144px" %)事件经理
1363 |4|(((
1364 L2.1
1365
1366 实施应急预案
1367 )))|(% style="width:795px" %)(((
1368
1369
1370 * 事件经理根据判断的紧急预案类型，上报主管领导，同时启动相应的紧急预案。
1371 )))|(% style="width:139px" %)-|(% style="width:127px" %)-|(% style="width:144px" %)应急小组
1372 |5|(((
1373 L1.3
1374
1375 协调资源
1376 )))|(% style="width:795px" %)(((
1377
1378
1379 * 根据事件评估结果组织有关的专家成员，并启动应急小组。
1380 * 协调相关设备资源，以应对重大事件。
1381 )))|(% style="width:139px" %)-|(% style="width:127px" %)-|(% style="width:144px" %)事件经理
1382 |6|(((
1383 L2.2
1384
1385 诊断分析及解决
1386 )))|(% style="width:795px" %)(((
1387
1388
1389 * 应急小组与相关技术专家对重大事件进行分析诊断，查找根本原因。
1390 * 如果需要，须与用户进一步沟通，为决策提供依据。
1391 * 根据分析诊断的结果，形成并提供适合的解决方案，包括临时紧急处理方案。
1392 * 如果在事件处理过程中，需要变更，则需提交紧急变更申请，走紧急变更流程。
1393 * 相关技术专家成员须参与。
1394 )))|(% style="width:139px" %)(((
1395 事件申请单
1396
1397 评估结果
1398 )))|(% style="width:127px" %)(((
1399 解决方案
1400
1401 临时处理方案
1402
1403 紧急变更申请单
1404 )))|(% style="width:144px" %)应急小组
1405 |7|(((
1406 L2.3
1407
1408 解决恢复
1409 )))|(% style="width:795px" %)(((
1410
1411
1412 * 判断重大事件是否得到解决。
1413 * 如果已解决，则走善后处理过程。
1414 * 如果未解决，则需调研外部资源，继续分析诊断与解决。
1415 )))|(% style="width:139px" %)-|(% style="width:127px" %)-|(% style="width:144px" %)应急小组
1416 |8|(((
1417 L2.4
1418
1419 协调外部
1420
1421 资源支持
1422 )))|(% style="width:795px" %)(((
1423
1424
1425 * 若故障相对复杂困难，应急小组及内部专家组成员无法解决，或者故障影响范围和影响程度很大，则应邀请相关的第三方或供应商参与解决。
1426 )))|(% style="width:139px" %)-|(% style="width:127px" %)-|(% style="width:144px" %)应急小组
1427 |9|(((
1428 L2.5
1429
1430 善后处理及通报
1431 )))|(% style="width:795px" %)(((
1432
1433
1434 * 重大事件解除后，应通知重大事件各方（申报方、受影响部门、主管机构及相关领导），并向主管机构及相关领导简要报告重大事件处理过程，解决方法，事件解除时间，业务恢复情况等。
1435 * 如果是临时处理方案，应创建一个新问题，将重大事件处理过程的详细信息记录到问题申请单中，提交问题管理流程。
1436 * 应对重大事件的处理过程进行详细记录，形成重大事件处理报告，包括事件、分析、诊断、解决等过程。
1437 * 将重大事件的解决方案或临时处理方案提交到知识管理流程，存入知识库中。
1438 )))|(% style="width:139px" %)事件申请单|(% style="width:127px" %)(((
1439
1440
1441 重大事件处理报告
1442
1443 事件申请单
1444
1445 问题申请单
1446 )))|(% style="width:144px" %)应急小组
1447 |10|结束|(% style="width:795px" %)流程结束节点。|(% style="width:139px" %) |(% style="width:127px" %) |(% style="width:144px" %)事件经理
1448
1449 == ==
1450
1451 == **5.8 子流程7：协调第三方支持** ==
1452
1453 === **5.8.1 子流程描述** ===
1454
1455 该子流程是在故障类事件的处理中，为有效发挥和利用第三方/供应商资源解决事件，对第三方/供应商资源应用进行的规范管理流程。
1456
1457 === ===
1458
1459 === **5.8.2**流程图 ===
1460
1461 (% style="text-align:center" %)
1462 [[image:1730199236176-847.png]]
1463
1464
1465 === **5.8.3 流程说明** ===
1466
1467 |序号|活动/子流程|描述|输入|输出|责任人
1468 |1|开始|流程的起始节点| | |
1469 |2|(((
1470 L1.1
1471
1472 信息收集
1473 )))|(((
1474 * 根据故障处理的实际情况，收集故障关联的所有相关信息。
1475 * 确保故障及故障处理描述要准确全面。
1476 )))|事件申请单|事件申请单|二线支持
1477 |3|(((
1478 L1.2
1479
1480 整理分类
1481 )))|(((
1482 * 对收集到的故障等进行整理，并按照其类别进行划分，以方便有效的识别和诊断。
1483 * 根据故障处理情况，提交第三方申请单，交事件经理审批。
1484 )))|事件申请单|(((
1485 事件申请单
1486
1487 第三方申请单
1488 )))|二线支持
1489 |4|(((
1490 L1.3
1491
1492 审批
1493 )))|(((
1494 * 事件经理根据故障的影响程度、紧急程度、投入成本、UC，以及提供信息的安全性等进行综合评估。
1495 * 如果未通过，则反馈二线支持和受理方，关闭事件。
1496 )))|(((
1497 第三方申请单
1498
1499 事件申请单
1500 )))|事件申请单|事件经理
1501 |5|(((
1502 L1.4
1503
1504 提供信息
1505 )))|(((
1506 * 二线支持将审批通过后的、故障相关信息提供给已协调的第三方/供应商。
1507 * 提供的方式可以多种，包括邮件、书面等方式或当面提供等。
1508 )))|事件申请单|事件申请单|二线支持
1509 |6|(((
1510 L1.5
1511
1512 沟通解决
1513 )))|(((
1514 * 二线支持负责跟踪第三方/供应商的故障处理状态，并不定期的保持沟通，以保证解决的效率和效果。
1515 * 如果在UC范围内，则按照协议规定，监督供应商的服务支持。
1516 * 记录第三方/供应商的解决方案，并反馈事件受理方（帮助台/一线支持）。
1517 )))|事件申请单|(((
1518 事件申请单
1519
1520 解决方案
1521 )))|事件经理
1522 |7|结束|流程结束节点。| | |
1523
1524
1525 == **5.9 子流程8：事件关闭** ==
1526
1527 === **5.9.1 子流程描述** ===
1528
1529 该子流程是事件管理流程的结束点，通过验证用户对事件处理的满意度，和事件信息的正确性与完整性，确保事件的最终关闭。同时，事件处理过程中的解决方案或变通方法应提交知识管理流程形成可复用、可共享的知识保存在知识库中。
1530
1531 === ===
1532
1533 === **5.9.2 **流程图 ===
1534
1535
1536 (% style="text-align:center" %)
1537 [[image:1730199296298-349.png]]
1538
1539
1540 === **5.9.3 流程说明** ===
1541
1542 |序号|活动/子流程|(% style="width:737px" %)描述|(% style="width:137px" %)输入|(% style="width:128px" %)输出|(% style="width:153px" %)责任人
1543 |1|开始|(% style="width:737px" %)流程的起始节点 。|(% style="width:137px" %) |(% style="width:128px" %) |(% style="width:153px" %)
1544 |2|(((
1545 L1.1
1546
1547 通知客户
1548 )))|(% style="width:737px" %)(((
1549
1550
1551 * 告知用户关闭事件。
1552 * 调查用户对故障处理的反馈，包括服务支持的质量，支持的效率和支持的态度等。
1553 )))|(% style="width:137px" %)事件申请单|(% style="width:128px" %)事件申请单|(% style="width:153px" %)(((
1554 服务台/
1555
1556 一线支持
1557 )))
1558 |3|(((
1559 L1.2
1560
1561 记录反馈信息
1562 )))|(% style="width:737px" %)(((
1563
1564
1565 * 将用户的反馈信息记录到相应的单据中。
1566 * 用户的反馈信息可采用短信平台收集。
1567 )))|(% style="width:137px" %)客户反馈信息|(% style="width:128px" %)客户反馈信息|(% style="width:153px" %)(((
1568 服务台/
1569
1570 一线支持
1571 )))
1572 |4|(((
1573 L1.3
1574
1575 查看过程文档
1576
1577 是否全面
1578 )))|(% style="width:737px" %)(((
1579
1580
1581 * 服务台/一线支持（事件受理者）应查看事件生命周期中所产生的文档是否完整全面。
1582 * 如果全面，标明事件状态为结束。
1583 )))|(% style="width:137px" %)事件申请单|(% style="width:128px" %)(((
1584 文档清单
1585
1586 事件申请单
1587 )))|(% style="width:153px" %)(((
1588 服务台/
1589
1590 一线支持
1591 )))
1592 |5|文档归档|(% style="width:737px" %)(((
1593
1594
1595 * 若在整个过程中文档不全面，则要求相关责任人完善。
1596 * 将产生的所有信息归档。
1597 * 如果解决事件时，采用了新的解决方案/变通方法，则申请将解决方案/变通方法加入到知识库中。
1598 * 标明事件状态为结束。
1599 )))|(% style="width:137px" %)文档清单|(% style="width:128px" %)(((
1600 事件申请单
1601
1602 知识申请单
1603 )))|(% style="width:153px" %)(((
1604 服务台/
1605
1606 一线支持
1607 )))
1608 |6|结束|(% style="width:737px" %)流程结束节点。|(% style="width:137px" %) |(% style="width:128px" %) |(% style="width:153px" %)
1609
1610
1611
1612
1613 = **6. 关键绩效指标（KPI）** =
1614
1615 为了较好地控制事件管理流程的质量，必须为流程设置衡量指标，通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。
1616
1617 以下为事件管理流程的关键衡量指标：（评价：角色指标、整体指标）
1618
1619
1620 |序号|绩效指标|公式|目标值|衡量方式|报告周期|责任人|备注
1621 |1|一次性正确解决率|一次正确解决事件数量/∑（事件数）|≥40％|统计|月\季度\年|事件经理|IT服务管理系统统计分析
1622 |2|服务台解决率|∑(一线解决事件数量)/∑（事件数）×100%|≥85%|统计|月\季度\年|事件经理|
1623 |3|一线支持解决率|∑(一线解决事件数量)/∑（事件数）×100%|≥85%|统计|月\季度\年|事件经理|
1624 |4|二线支持解决率|∑(二线解决事件数量)/∑（事件数）×100%|≥90%|统计|月\季度\年|事件经理|
1625 |5|(((
1626 事件超限率
1627
1628 （超过SLA）
1629 )))|(((
1630 ∑（超限事件数量）/∑（事件数）×100%
1631
1632 超限事件数量=用户事件未能在指定时间内解决
1633 )))|≤5%|统计|周\月\季度\年|事件经理|
1634 |6|客户满意度|∑（用户满意数量）/∑（调查用户数）×100%|≥95%|统计|季度\年|事件经理|电话回访或客户调查评定
1635
1636
1637
1638 = **7. 三、四级文件** =
1639
1640 |名称|说明
1641 |事件分类|
1642 |事件优先级|
1643 |事件申请单|
1644 |事件报告|月报，周报等
1645 |重大事件报告|
1646 |XX紧急预案|
1647
1648
1649
1650
深圳市艾拓先锋企业管理咨询有限公司