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