Last modified by superadmin on 2024/11/04, 09:47
Show last authors
1 = **1. 文档介绍** =
2
3 == **1.1. 文档简介** ==
4
5 本文档『突发事件管理流程设计报告』,是制定的突发事件管理流程的设计文档。通过该文档,可以帮助招行运行中心快速的解决IT环境的突发事件，为招行业务的快速发展提供更优质的IT服务。
6
7 本文档的内容是依据目前IT服务状况而制定的突发事件管理流程的说明，以后进一步的更新将由运行中心负责。
8
9 == ==
10
11 == **1.2. 文档用途** ==
12
13 本文档一方面作为本次ITIL项目的突发事件管理流程设计的交付物,也可作为进一步改进的蓝本,读者对象为与事件管理流程相关的所有技术与管理人员。
14
15
16 = =
17
18 = =
19
20 = **2. 突发事件管理流程介绍** =
21
22 == **2.1. 简介** ==
23
24 突发事件管理流程是负责解决IT服务的突发事件、问题的运维流程。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。
25
26 (% style="text-align:center" %)
27 [[image:图片1.jpg]]
28
29 == ==
30
31 == **2.2. 目的** ==
32
33 事件管理流程的主要功能是尽快解决环境中出现的事件，保持IT服务的稳定性，其目的包括：
34
35 * 在成本允许的范围内尽快恢复服务
36 ** 快速响应服务请求（事件/服务请求/咨询等）
37 ** 用户在线获得帮助
38 ** 沟通故障解决的状态
39 ** 和客户确认事件的解决
40
41
42 * 进行事件控制
43 ** 按规范记录事件
44 ** 就事件的优先级，紧急性和严重性进行分类
45 ** 分析，诊断，处理，必要时进行升级
46 ** 监视并结束事件
47 ** 进行定期服务流程回顾
48
49
50 * 提供IT管理信息
51 ** 人力资源利用情况
52 ** 故障处理情况
53 ** 支持效率
54
55
56 == **2.3. 范围** ==
57
58 突发事件管理的范围主要可以从下面几个角度来看：
59
60 从突发事件管理涉及突发事件类别来看：
61
62 * 客户突发事件：客户主动联系服务台申报的突发事件，如：PC机故障、使用应用系统时遇到问题等等。
63 * 后台突发事件：通过综合告警平台发现的系统中的异常突发事件或运行中心运维人员发现的异常突发事件。
64
65
66 从突发事件管理涉及的组织范围来看：
67
68 * 系统运行室
69 * 系统管理室
70 * 网络室
71 * 系统支持室
72 * 南京灾备中心
73 * 安全室
74 * 信用卡室
75
76
77 从突发事件管理的上报渠道来看
78
79 * 电话
80 * 一事通
81 * 监控软件
82 * 电子邮件
83 * RTX
84 * 运维人员提交
85
86 == ==
87
88 == **2.4. 主要内容** ==
89
90 突发事件管理流程着重于在快速解决IT环境中的突发事件，并降低其对业务的影响度。主要活动包括记录突发事件、分派突发事件、找出解决方案和结束突发事件等，其流程内容如下：
91
92 * **检测和记录**  突发事件通过系统管理软件检测出来或用户打电话进来产生的，所有突发事件记录进系统中。
93
94
95 * **判断并分派**  确定是服务请求、突发事件、咨询还是投诉。如果是突发事件，进行突发事件的影响、收集信息等，尝试解决问题。
96
97
98 * **判断是否已解决**  确定问题是否已解决，如解决，转5由服务台确认；如未解决，继续诊断，必要时转4由二线支持，三线（厂商和集成商、服务商等）进行支持解决等。
99
100
101 * **调查和诊断**  二线支持和三线（厂商和集成商、服务商等）支持人员利用自身技能和相关工具，力图在规定的时间内提出解决方案，尝试解决突发事件。转3
102
103
104 * **服务台确认**  对突发事件的解决方案进行确认，如未解决，根据情况采取相应动作，如转3继续，如解决，转6。
105
106
107 * **结束**   如果确认已解决，关闭记录，更新文档; 必要时进行回顾。
108
109
110 * **定期产生报表**   突发事件支持人员将根据管理要求定期产生相关报表。
111
112
113
114 == **2.5. 业务价值** ==
115
116 突发事件管理流程将在多方面对IT服务产生积极作用，具体表现在：
117
118 **提高服务可用性 **– 不管什么原因，当用户不能使用IT提供的IT服务的时候(如咨询如何使用，设备宕机，网络过载等)，服务都是被认为不可用的，它影响了用户的生产率。突发事件管理流程通过保证突发事件、问题和请求等的快速处理来达到服务可用性的最大化。** **
119
120 **提高客户满意度 **– 突发事件管理流程通过记录和管理突发事件的集成系统来提供有效服务以及一个集中的知识库。同时，也提供了服务供应者和使用者的沟通渠道，加强了信息中心和用户之间的双向认同。
121
122 **集中化突发事件数据** – 通过突发事件管理流程和系统来统一收集突发事件数据，这些数据被其他流程所使用，如问题管理流程将分析这些数据以确定突发事件的根本原因，并确定纠正措施以消除再次发生的可能性。
123
124
125 = =
126
127 = =
128
129 = **3. 事件管理流程设计** =
130
131 == **3.1. 流程指导原则** ==
132
133 咨询顾问和XX在事件管理流程咨询的设计阶段，一起共同设计事件管理流程遵循的原则。流程的原则是双方对流程的认识达成共识，是流程设计的基础和关键因素。下面是一些标准的事件管理流程遵循的原则：
134
135 * 指导原则 1：
136
137 突发事件管理流程中的服务台是运行中心向其他部门用户提供服务的单一联系点，服务台通过电话或Web对外提供服务，同时接受用户的查询请求；
138
139 * 指导原则2：
140
141 任何运行中心以外的部门要解决的突发事件不能绕过服务台来解决，所有需解决的突发事件要通过服务台向运行中心提交；
142
143 * 指导原则3：
144
145 任何突发事件，主单只是一个请求，必须创建任务子单，所有的处理过程在任务子单中完成；
146
147 * 指导原则4：
148
149 来自“一事通”的突发事件，由服务台热线在“一事通”中完成分单操作，并对主申请单进行跟踪、处理；
150
151 运行中心内部员工提交的突发事件，如果提交人知道如何分单，则将主申请单处理人指定为自己，并指定任务单的处理人，由系统根据指定的任务单处理人自动生成任务子单；如果提交人不知道如何分单，则由提交人转发突发事件单给服务台，由服务台来分单；
152
153 * 指导原则5：
154
155 对突发事件进行分单的员工是该事件的责任人，必须确保将突发事件正确的拆分成一个或者多个任务子单；确保将这些任务子单正确的分派给相应的处理人；对突发事件的解决进度和质量进行有效跟踪与协调；
156
157 * 指导原则6：
158
159 在整个突发事件的解决过程中，分单的员工应及时向用户通报突发事件的处理情况，使用户可以知道突发事件的解决状态；服务台员工也应该及时了解掌握突发事件处理的进度和情况，以方便跟用户进行沟通，或者接受用户查询；
160
161 * 指导原则7：
162
163 突发事件必须在得到用户的确认后，才能关闭记录。结合招行目前运维状况，一期目标是由系统将突发事件处理结果通过邮件发送给用户，用户如果在5个工作日内未反馈，则认为用户已经确认。
164
165 * 指导原则8：
166
167 突发事件的主申请单由分单人跟踪处理并关闭，任务子单由处理人直接关闭。
168
169 == ==
170
171 == **3.2. 一事通接口** ==
172
173 结合本次项目的需求和运行中心对一事通中请求处理的实际情况，HP建议本期项目一事通接口采用以下方案：
174
175 从来源上看，可将目前一事通中的所有的请求分为以下两种类型来处理：
176
177
178 * **运行中心内部的突发事件/服务请求，跟其他任何部门都没有关系，流程始终在运行部内部流转。**
179
180
181 此类请求将不再使用一事通平台，而是直接由发起人在新的HPSM平台中按照新的流程提交，并由系统自动转发给相关的处理人，中间不再经由服务台进行分派工单、审批等。
182
183
184
185 * **需要其他部门参与的突发事件/服务请求，甚至其他项目管理等等事情**
186
187 这其中又细分为以下两种情形：
188
189
190 a.运行中心发起中间需要其他部门参与的
191
192 这种请求运行部人员在一事通提交请求，全部审批（包括运行部人员的审批）完成后，服务台在一事通中完成分单操作后，系统通过接口将请求主单和子单信息一起转入新的HPSM平台按照新的流程处理。
193
194 b.其他部门发起需要运行部审批或者处理的
195
196 这种请求运行部人员在一事通提交请求，全部审批（包括运行部人员的审批）完成后，服务台在一事通中完成分单操作后，系统通过接口将请求主单和子单信息一起转入新的HPSM平台按照新的流程处理。
197
198
199 **以上a,b两种情况，最后具体落实处理的部门可能是运行中心，也可能不是运行中心。**
200
201 == ==
202
203 == **3.3. 分派机制** ==
204
205 针对上一个章节设计的两种来源的服务请求和突发事件，分别有以下的分派机制：
206
207 * **运行中心内部的突发事件/服务请求，跟其他任何部门都没有关系，流程始终在运行部内部流转。**
208
209
210 运行中心内部的服务请求和突发事件，包括服务台通过电话或者EMAIL或者RTX接受到的服务请求或者突发事件。
211
212 系统会根据服务目录的定义，自动分配给一线或者二线，如果在服务目录中没有清晰的定义，则由请求或者突发事件的提交人将请求分派给一线处理，如果一线人员无法处理则升级分派到二线。
213
214
215 * **需要其他部门参与的突发事件/服务请求，甚至其他项目管理等等事情**
216
217
218 申请人在一事通中提交服务请求和突发事件，由服务台在一事通中完成分派操作，所有的服务请求和突发事件首先分派给一线中负责相关业务的人员，如果一线人员无法处理则升级分派到二线。
219
220 == ==
221
222 == **3.4. 技术平台相关代码定义** ==
223
224 === **3.4.1. 信息项** ===
225
226 * **各个流程的通用属性：**
227
228 |(% colspan="4" %)**所有流程共有属性**
229 |**编号**|**属性**|**类型**|**说明**
230 |1|ID|TEXT|(((
231 突发事件IM/服务请求SQ/问题PM/变更CH/服务台SD
232
233 能否使用日期来区分，例如：IM090224000001
234 )))
235 |2|状态|CODE|
236 |3|类别|TEXT|室
237 |4|子类别|TEXT|应用系统
238 |5|类型|TEXT|突发事件/服务请求/问题/变更
239 |6|子类型|TEXT|具体的事件、问题或者变更类型
240 |7|影响范围|CODE|
241 |8|紧急程度|CODE|
242 |9|优先级|CODE|由影响范围和紧急程度计算得来
243 |10|简要描述|TEXT|
244 |11|详细描述|TEXT|
245 |12|活动记录|TEXT|处理步骤的活动记录，包括类型、人员、日期、更新内容
246 |13|登记人|RELATION|创建此单的人，默认当前登录人
247 |14|申请人|RELATION|事件等流程请求人，默认当前登录人
248 |15|分派组|RELATION|此单当前处理人所属的组别，建议按照目前运维组别来分
249 |16|分派人|RELATION|此单当前处理人
250 |17|解决方案|TEXT|
251 |18|关闭代码|RELATION|例如：根本解决、替代方法、误报、用户取消。。。
252 |19|打开时间|DATE|创建时间
253 |20|更新时间|DATE|最后更新的时间
254 |21|计划响应时间|DATE|由“优先级”决定，仅用于突发事件和服务请求流程
255 |22|实际响应时间|DATE|
256 |23|是否按时响应|TEXT|由“计划响应时间”“实际响应时间”比较的结果决定
257 |24|计划完成时间|DATE|由“优先级”决定，适用所有流程
258 |25|实际完成时间|DATE|填写“解决方案”和“结束代码”的时间
259 |26|是否按时完成|TEXT|由“计划完成时间”“实际完成时间”比较的结果决定
260 |27|处理时长（分钟）|TEXT|手工填写
261 |28|中断时长（分钟）|TEXT|手工填写，是指“子类别”的中断时长
262 |29|附件|RELATION|相关附件
263 |30|配置项|RELATION|相关配置项
264 |31|相关|RELATION|突发事件、服务请求、问题、变更之间的关联
265 |32|所属室|TEXT|该突发事件的由哪个室处理完成
266 |33|所属组|TEXT|该突发事件的由哪个组处理完成
267 |34|事件来源|TEXT|参见事件来源定义
268
269
270 * **突发事件特有属性：**
271
272 |(% colspan="4" %)**服务请求特有属性**
273 |**编号**|**属性**|**类型**|**说明**
274 |1|服务台满意度|CODE|服务台服务态度的满意度
275 |2|技术支持满意度|CODE|技术支持的满意度
276 |3|客户意见|TEXT|反馈意见
277 |4|服务级别|RELATION|缺省为5×8服务
278 |5|到达服务台时间|DATE|服务请求分派给服务台的时间
279 |6|来源ID|TEXT|通过接口进入HPSM的事件，其来源ID
280 | | | |
281
282
283 === **3.4.2. 突发事件分类** ===
284
285 对突发事件的进行分类，主要目的在于方便各个突发事件处理组之间的信息沟通，为突发事件的诊断和处理提供信息，并产生相关的管理信息报表，从而达到优化提高IT服务质量，提高突发事件处理效率的目标。
286
287 具体分类原则、标准和方法是：
288
289 各个流程，包括事件、问题、变更等分类统一规划，遵循统一的原则和标准，分类的层次为4级：
290
291 第一个层次： 类别
292
293 第二个层次： 子类别
294
295 第三个层次： 流程模块
296
297 第四个层次： 操作类型
298
299 例如：
300
301 |**类别**|**子类别**|**流程**|**操作类型**
302 |(% rowspan="22" %)**信用卡**|(% rowspan="15" %)**信用卡微机系统 - 370020**|(% rowspan="3" %)**服务请求**|**路由开通**
303 |**增加用户**
304 |**…….**
305 |(% rowspan="3" %)**突发事件**|**用户user1系统无法登录**
306 |**系统打开很慢**
307 |**……**
308 |(% rowspan="3" %)**问题**|**用户管理**
309 |** **
310 |**……**
311 |(% rowspan="3" %)**变更**|**系统版本升级**
312 |**增加一个菜单**
313 |**…….**
314 |(% rowspan="3" %)**知识库**|**系统安装**
315 |**用户管理**
316 |**…….**
317 |(% rowspan="5" %)**信用卡数据库 - 370030**|**服务请求**|** **
318 |**突发事件**|** **
319 |**问题**|** **
320 |**变更**|** **
321 |**知识库**|** **
322 |**信用卡主机系统 - 370010**|** **|** **
323 |**信用卡主机系统 - 370010**|** **|** **
324
325
326 详情参见《流程分类表》
327
328 === ===
329
330 === **3.4.3. 影响度、紧急度和优先级** ===
331
332 突发事件在提交到运行中心以后，因为数量很多，HP建议使用“影响范围”和“影响程度”两个纬度来计算每个突发事件的“优先级”，这个优先级跟《招商银行信息系统紧急突发事件管理办法》规定的P1-P5相对应，突发事件处理人员将根据此优先级的高低来决定处理的先后顺序。
333
334 * **优先级**
335
336 |**编号**|**代码**|**解释**
337 |1|P1|灾难事件
338 |2|P2|严重事件
339 |3|P3|重大事件
340 |4|P4|一般事件
341 |5|P5|隐患
342
343
344 * **影响范围**
345
346 |**编号**|**影响范围**|**影响范围代码**|**描述**
347 |1|全行所有业务系统|S1|
348 |2|全行一个或者多个重要业务系统|S2|
349 |3|一个或者多个分行所有业务系统|S3|
350 |4|一个或者多个分行某个重要业务系统|S4|
351 |5|总行或者分行的一个或者多个非重要业务系统|S5|
352 |6|对业务有影响的一个或者多个办公系统|S6|
353 | | | |
354
355
356 影响范围定义中的业务系统列表，参见附录一。
357
358
359 * **影响程度**
360
361 |**编号**|**影响度**|**影响度代码**|**描述**
362 |1|不可用|I1|系统完全不可用
363 |2|可用性受影响|I2|系统可用性受到影响
364 |3|可用性受威胁|I3|系统可用，但是可用性受到威胁
365
366
367 优先级用来指导运维人员确定突发事件处理的先后次序，优先级高的请求先处理，优先级低的后处理。为了能够客观的评价一个突发事件的优先级，可以使用“影响范围”和“影响度”两个维度来综合计算优先级。
368
369
370 |(% colspan="2" rowspan="2" %)(((
371 **~ 影响度**
372
373 **~ 影响范围**
374 )))|**不可用**|(((
375 **可用性**
376
377 **受影响**
378 )))|(((
379 **可用性**
380
381 **受威胁**
382 )))
383 |**I1**|**I2**|**I3**
384 |**全行所有业务系统**|**S1**|P1|P2|P3
385 |**全行一个或者多个重要业务系统**|**S2**|P2|P3|P5
386 |**一个或者多个分行所有业务系统**|**S3**|P2|P3|P5
387 |**一个或者多个分行某个重要业务系统**|**S4**|P3|P3|P5
388 |**总行或者分行的一个或者多个非重要业务系统**|**S5**|P4|P4|P5
389 |**对业务有影响的一个或者多个办公系统**|**S6**|P4|P5|P5
390 | | | | |
391
392
393 === **3.4.4. 优先级和解决时限** ===
394
395 与优先级相对应，我们定义一个事件处理的时限要求（deadline）和响应时限要求。下表列出了通常与各优先级对应的时限：
396
397 |**编号**|**优先级代码**|**解决时限（工作时间）**|**响应时限**
398 |1|P1|1个小时|5分钟
399 |2|P2|4个小时|15分钟
400 |3|P3|8个小时|1小时
401 |4|P4|16个小时|2小时
402 |5|P5|32个小时|4小时
403
404 注：以上时限设置，仅供参考，项目上线后，可做为参数灵活配置
405
406
407 解决时限的定义：事件单的实际完成时间（状态为已解决） － 事件单的分派时间（状态为处理中）
408
409 响应时限的定义：事件单的响应时间（状态处理中）－ 事件单的创建时间（状态为待处理）
410
411 === ===
412
413 === **3.4.5. 升级通告路径的定义** ===
414
415 当事件创建以后，需要相关工程师对事件进行响应和处理，为了保证事件能够及时被分派并且被处理，在事件管理流程中需要对不同级别的事件设定不同的响应时限，如果，违背了响应时限，系统将根据事件的优先级自动向相关事件处理人和事件经理发起通告，由事件经理负责协调资源，并督促事件能够及时被响应和处理。
416
417 在不同优先级别/影响程度的事件有不同的升级通知路径，在通告的每个过程中，相关人员都需要执行相应的动作来报障事件能够在规定的时间限制内解决：
418
419 |**优先级**|**响应通告**|**解决通告**
420 |P1|超时5分钟à 当前处理工程师、事件经理、行政经理|(((
421 * 通告事件经理；
422 * 最终期限前0.5小时à事件受理人、当前处理工程师、组长、事件经理；
423 * 已超时à事件受理人、当前处理工程师、组长、事件经理、行政经理
424 )))
425 |P2|超时15分钟à当前处理工程师、事件经理、行政经理|(((
426 * 创建时通知事件经理
427 * 最终期限前2小时à事件受理人、当前处理工程师、组长；
428 * 已超时à事件受理人、当前处理工程师、组长、事件经理、行政经理；
429 )))
430 |P3|超时1小时à当前处理工程师、事件经理、行政组长|(((
431 * 最终期限前4小时à当前处理工程师、行政组长；
432 * 已超时à事件受理人、当前处理工程师、行政组长、事件经理；
433 )))
434 |P4|超时2小时à 当前处理工程师、事件经理|(((
435 * 最终期限前8小时à当前处理工程师、组长；
436 * 已超时à事件受理人、当前处理工程师、组长、事件经理；
437 )))
438 |P5|超时4小时à当前处理工程师、事件经理|(((
439 * 最终期限前16小时à当前处理工程师、组长；
440 * 已超时à事件受理人、当前处理工程师、组长、事件经理；
441 )))
442
443 注：以上时限设置，仅供参考，项目上线后，可做为参数灵活配置
444
445 === ===
446
447 === **3.4.6. 事件状态** ===
448
449 |**编号**|**代码**|**描述**
450 |1|已登记|新开事件记录或事件已创建
451 |2|待处理|突发事件已经分配给一线或者二线，等待处理人处理
452 |3|处理中|二线支持人员已接手处理事件
453 |4|已解决|事件已解决，支持人员联系用户验证事件是否获得解决
454 |5|关闭|事件已关闭
455
456
457 === **3.4.7. 事件结束代码** ===
458
459 |**编号**|(% colspan="2" %)**代码**|**描述**
460 |1.|服务台解决|服务台解决|由服务台维护解决
461 |(% rowspan="2" %)2.|(% rowspan="2" %)一线解决|根本解决|找到事件的根本原因
462 |替代方法|使用替代方法解决
463 |(% rowspan="2" %)3.|(% rowspan="2" %)二线解决|根本解决|找到事件的根本原因
464 |替代方法|使用替代方法解决
465 |(% rowspan="2" %)4|(% rowspan="2" %)三线解决|内部解决|由开发中心开发人员解决
466 |厂商解决|外部厂商解决
467 |(% rowspan="2" %)5.|(% rowspan="2" %)未解决|上升到问题|提交到问题管理系统
468 |无法解决|无法解决
469 |6.|(% colspan="2" %)自动恢复|系统自动恢复，事件无法再现
470 |7.|(% colspan="2" %)误报|属于误报事件
471 |8．|(% colspan="2" %)拒绝|服务请求被拒绝
472
473
474 === **3.4.8. 事件来源** ===
475
476 |**编号**|**代码**|**备注**
477 |1.|电话|服务台、一线或者二线人员根据客户电话创建的
478 |2.|一事通|来自一事通
479 |3.|RTX|来自RTX
480 |4.|监控系统|监控系统通过接口自动创建的
481 |5.|运行中心|运行中心内部人员提交的
482 |6.|EMAIL|服务台、一线或者二线人员根据客户EMAIL创建的
483
484
485 === **3.4.9. 服务台满意度 ** ===
486
487 |**编号**|**代码**|**备注**
488 |1|非常好|
489 |2|正常|
490 |3|需要提高|
491
492
493 === **3.4.10. 技术支持满意度   ** ===
494
495 |**编号**|**代码**|**备注**
496 |1|非常好|
497 |3|正常|
498 |4|需要提高|
499
500
501 === **3.4.11. 工作子单状态代码** ===
502
503 当工程师在处理突发事件单时，有时需要其它工程师协调处理，或者需要征得其它同事的同意或认可，则可以在当前的突发事件单上发起工作子单并分派给相关的人员，所以，工作子单也有生命周期，即对应的各种状态：
504
505
506 |**序号**|**代码**|**描述**
507 |1.|待处理|等待处理；
508 |2.|处理中|处理中；
509 |3.|已完成|工作子单已实施；
510
511
512 === **3.4.12. 工作子单分类** ===
513
514 其它的流程如问题、配置、变更都会产生相应的工作单，所以最终工作单的分类应该综合各个流程产生的需求。
515
516 |**序号**|**代码**|**描述**
517 |1.|协助处理|事件处理过程的协助
518 |2.|会议|会议记录的工作单
519 |3.|。。。|
520
521 == ==
522
523 == **3.5. 事件管理的人员角色和职责** ==
524
525 结合ITSM最佳实践，在事件管理流程中推荐的主要角色有：事件经理、服务台主管、服务台热线支持、服务台一线支持、服务台现场支持以及二线和三线支持等。
526
527 === ===
528
529 === **3.5.1. 事件经理** ===
530
531 **事件经理职责:**
532
533 * 确保有效协调资源,通过事件支持专家快速恢复正常服务。
534 * 确保事件管理支持人员的适当技能水平和绩效表现。
535 * 确保和问题管理流程经理及外部供应商等部门的有效合作。
536 * 确保正确和广泛地收集和分析事件数据,发现IT和业务相关的问题。
537 * 通过服务台的作用及良好的服务态度来确保客户的满意。
538 * 确保有关IT服务和客户支持的管理信息的可获得性。
539 * 改进和提高事件管理流程的有效性和效率。
540
541
542 **事件经理技能:**
543
544 * 深刻了解事件管理流程
545 * 较强的领导能力
546 * 了解技术架构和技术环境
547 * 较强的口头表达能力和与客户沟通技巧
548 * 处理纠纷的能力
549
550 === ===
551
552 === **3.5.2. 二线支持** ===
553
554 **二线支持职责：**
555
556 * 接受一线支持升级的事件或服务请求，验证事件的描述，进一步收集相关信息
557 * 在规定的时间内解决事件和服务请求
558 * 对利用“替代方案"解决的事件，在资源及时间允许时应找到问题根源
559 * 在需要时及时利用其它资源(开发中心,开发商, 厂家) 参与事件解决
560 * 将事件的解决步骤文档化，并将解决方案录入服务台系统中
561
562 * 根据解决方案进行IT服务恢复
563 * 向现场服务人员提供必要的技术支持和协助
564 * 需要时根据解决方案发起变更请求RFC，监控变更请求过程并对解决结果进行确认
565 * 负责跟开发中心、集成商和供应商之间的接口
566 * 为VIP用户提供在线或现场支持
567
568 **二线支持技能：**
569
570 * 熟悉技术平台和技术环境.
571 * 很强的技术能力
572 * 较强的解决事件的能力
573 * 较强的分析能力
574
575
576 === **3.5.3. 三线支持** ===
577
578 对于运行中心来说，三线支持主要是指开发中心和厂商，在事件处理流程中二线支持专家，来协调三线人员来帮助处理突发事件或者服务请求。处理的结果由二线人员录入系统，并通过结束代码注明由三线解决。
579
580 **三线支持厂商人员职责：**
581
582 * 接受二线支持升级的事件或服务请求，验证事件的描述，进一步收集相关信息
583 * 在规定的时间内解决事件和服务请求
584 * 负责协调厂商、开发商内部资源
585
586
587 **三线支持开发人员职责：**
588
589 * 接受二线支持升级的事件或服务请求，验证事件的描述，进一步收集相关信息
590 * 在规定的时间内解决事件和服务请求
591 * 负责协调开发中心内部资源
592
593 **三线支持技能：**
594
595 * 很强的资源协调能力
596 * 熟悉技术平台和技术环境.
597 * 较强的分析能力
598
599
600 === **3.5.4. VIP支持** ===
601
602 **VIP支持职责：**
603
604 * 当接收到VIP客户的服务要求时，及时准确地为VIP客户提供服务；
605 * 随时关注VIP客户的满意度，积极调动资源为VIP客户提供服务；
606 * 二线支持工程师的所有职责。
607
608
609 **VIP支持技能要求：**
610
611 * 较强的沟通能力；
612 * 较强的倾听能力；
613 * 熟悉事件处理流程和服务台的职责；
614 * 较强的协调能力，能够迅速协调相关的二线团队为VIP提供服务；
615 * 二线支持的所有技能
616
617
618
619 == **3.6. 流程角色和人员对应** ==
620
621 |(% colspan="2" %)**角色**|**工作组**|**成员**
622 |事件经理| |事件经理|
623 |服务台主管| |服务台主管|
624 |服务台热线支持| |服务台-热线支持|
625 |服务台现场支持| |服务台-现场支持|
626 |(% rowspan="7" %)服务台一线支持|系统运行室|一线-系统运行|
627 |系统管理室| |
628 |网络室| |
629 |系统支持室| |
630 |南京灾备中心| |
631 |安全室| |
632 |信用卡| |
633 |(% rowspan="7" %)二线支持|系统运行室|二线-系统运行|
634 |系统管理室| |
635 |网络室| |
636 |系统支持室| |
637 |南京灾备中心| |
638 |安全室| |
639 |信用卡| |
640 |小组组长| | |
641 |室经理| | |
642 |总经理室成员| | |
643 |VIP支持| | |
644
645
646 == **3.7. 事件处理逻辑流程** ==
647
648 根据流程设计要求, 我们将事件管理流程的设计标号以100开头, 比如100.X.
649
650 流程图相关符号说明：
651
652 (% style="text-align:center" %)
653 [[image:1730684027930-584.png]]
654
655 === ===
656
657 === **3.7.1. 一事通请求处理逻辑流程** ===
658
659 根据具体情况, 同时结合ITSM的最佳经验, 建议在本次项目中，对目前一事通中的请求（这些请求包括服务请求、突发事件和变更），由服务台进行初步审核确认并组织审批，然后通过接口进入本次项目引进的HPSM系统，按照新的服务请求、突发事件和变更流程来处理。
660
661 具体来看，一事通中请求处理的逻辑流程如下图：
662
663 (% style="text-align:center" %)
664 [[image:图片2.jpg]]
665
666
667 === **3.7.2. 突发事件管理逻辑流程** ===
668
669 (% style="text-align:center" %)
670 [[image:图片3.jpg]]
671
672
673 == **3.8. 事件处理物理流程** ==
674
675 在上面的章节中描述了突发事件管理的逻辑流程，在下面两个章节会结合逻辑流程中的主要环节进行展开描述，我们称之为物理流程。
676
677 == ==
678
679 == **3.9. 一事通请求管理物理流程** ==
680
681 在3.7节中描述了突发事件管理的逻辑流程，在本节会结合突发事件的逻辑流程，针对“一事通”中的请求展开对流程的详细描述，我们称之为物理流程。
682
683 === ===
684
685 === **3.9.1. 产生请求单100.1** ===
686
687 此流程在“一事通”中实现。
688
689 === ===
690
691 === **3.9.2. 审核请求 100.2** ===
692
693 此流程在“一事通”中实现。
694
695 === ===
696
697 === **3.9.3. 审批请求 100.3** ===
698
699 此流程在“一事通”中实现。
700
701 === **3.9.4. 分单 100.4** ===
702
703 此流程在“一事通”中实现。
704
705 === ===
706
707 === **3.9.5. 创建突发事件 100.5** ===
708
709 (% style="text-align:center" %)
710 [[image:1730684204735-163.png]]
711
712 具体描述如下：
713
714
715 |**序号**|**责任人**|**物理流程描述**
716 |100.5.1|服务台热线人员|在一事通中选择分派组。
717 |100.5.2|服务台热线人员|在一事通中选择分派人。
718 |100.5.3|服务台热线人员|在一事通中选择创建突发事件并保存。
719 |100.5.4|系统|一事通和HPSM接口自动根据一事通信息，在HPSM中生成突发事件
720
721 === ===
722
723 === **3.9.6. 创建变更 100.6** ===
724
725
726 (% style="text-align:center" %)
727 [[image:1730684226176-364.png]]
728
729 具体描述如下：
730
731
732 |**序号**|**责任人**|**物理流程描述**
733 |100.6.1|服务台热线人员|在一事通中选择分派组。
734 |100.6.2|服务台热线人员|在一事通中选择分派人。
735 |100.6.3|服务台热线人员|在一事通中选择创建变更并保存。
736 |100.6.4|系统|一事通和HPSM接口自动根据一事通信息，在HPSM中生成变更
737
738
739 === **3.9.7. 创建服务请求 100.7** ===
740
741 具体描述如下：
742
743 |**序号**|**责任人**|**物理流程描述**
744 |100.7.1|服务台热线人员|在一事通中选择分派组。
745 |100.7.2|服务台热线人员|在一事通中选择分派人。
746 |100.7.3|服务台热线人员|在一事通中选择创建服务请求并保存。
747 |100.7.4|系统|一事通和HPSM接口自动根据一事通信息，在HPSM中生成服务请求
748
749
750 == **3.10. 突发事件管理物理流程** ==
751
752 在3.7节中描述了事件管理的逻辑流程，在本节会结合逻辑流程中的主要环节进行展开描述，我们称之为物理流程。
753
754 === ===
755
756 === **3.10.1. 产生记录 102.1** ===
757
758
759 (% style="text-align:center" %)
760 [[image:1730684276216-425.png]]
761
762
763 具体描述如下：
764
765 |**序号**|**责任人**|**物理流程描述**
766 |102.1.1|服务台、一线、二线|打开“突发事件”的输入界面。
767 |102.1.2|服务台、一线、二线|选择事件请求人。可以使用请求人的账号或者姓名作为索引定位HPSM数据库中的人员数据。
768 |102.1.3|服务台、一线、二线|注明事件类别信息、标题，并输入详细情况描述。
769 |100.1.4|服务台、一线、二线|如果可以确定到配置项，则选择跟此事件相关的配置项。
770 |100.1.5|服务台、一线、二线|根据用户的描述，填写初步判断的紧急程度和影响范围
771
772
773 === **3.10.2. 收集信息 102.2** ===
774
775
776 (% style="text-align:center" %)
777 [[image:1730684308633-426.png]]
778
779 具体描述如下：
780
781 |**序号**|**责任人**|**物理流程描述**
782 |102.2.1|服务台、一线、二线|从用户处了解更多有关此事件的相关信息。
783 |102.2.6|服务台、一线、二线|(((
784 根据//附件一：重大事件定义和应急预案//和//4.1.5优先级代码//的定义判断该事件优先级是否为P1、P2或者P3？
785
786 1. 如果是，需要走重大事件处理子流程同时在系统中创建重大事件记录；
787 1. 否则进行下一步，转102.3.1
788 )))
789
790
791 === **3.10.3. 分派任务子单 102.3** ===
792
793
794 (% style="text-align:center" %)
795 [[image:1730684333376-646.png]]
796
797 具体描述如下：
798
799 |**序号**|**责任人**|**物理流程描述**
800 |102.3.1|服务台、一线、二线|根据事件的信息描述，判断需要拆分成几个任务子单。
801 |102.3.2|服务台、一线、二线|创建任务子单，补充或者填写子单信息，设置分派组和分派人信息。
802 |102.3.3|服务台、一线、二线|保存子单信息。
803 |102.3.4|服务台、一线、二线|(((
804 判断该是否需要继续添加子单，
805
806 如果是转102.3.1继续创建任务子单；
807
808 否则转102.3.5；
809 )))
810 |102.3.5|服务台、一线、二线|保存主单信息。
811
812 === ===
813
814 === **3.10.4. 服务台尝试解决 102.4** ===
815
816 (% style="text-align:center" %)
817 [[image:1730684355138-392.png]]
818
819
820 具体描述如下：
821
822 |**序号**|**责任人**|**物理流程描述**
823 |102.4.1|服务台|根据事件的信息描述，分析事件的原因，并尝试找出解决方案。
824 |102.4.2|服务台|(((
825 判断任务是否得到解决，
826
827 是则转102.4.3
828
829 否则转102.5.1派单到一线。
830 )))
831 |102.4.3|服务台|将成功的解决方案和结束代码记录在系统中，并更改任务单状态为“已解决”。
832
833
834 === **3.10.5. 升级转单至一线 102.5** ===
835
836 (% style="text-align:center" %)
837 [[image:1730684373845-963.png]]
838
839
840 具体描述如下：
841
842 |**序号**|**责任人**|**物理流程描述**
843 |102.5.1|服务台|根据任务单具体类别，确定并设置相应的一线支持工作组。
844 |102.5.2|服务台|根据工作组分配机制，确定并设置相应的一线支持人员。
845 |102.5.3|服务台|保存分派信息
846
847
848
849 === **3.10.6. 一线响应 102.6** ===
850
851
852 (% style="text-align:center" %)
853 [[image:1730684395067-200.png]]
854
855 具体描述如下：
856
857
858 |**序号**|**责任人**|**物理流程描述**
859 |102.6.1|一线支持|(((
860 一线支持收到通知（Email/短信/电话），查看本工作组的任务队列，找到需要处理的事件单。
861
862 注：组长应时刻观察本组的任务单，对于没有及时响应的及时介入，协调人员
863 )))
864 |102.6.2|一线支持|(((
865 判断该事件单是否是本组的工作范围？
866
867 如果不是，则转102.6.3
868
869 如果是，则开始处理；
870 )))
871 |102.6.3|一线支持|填写转发的理由和建议，转发此请求给相应的工作组。
872 |102.6.4|一线支持|处理过程中，收集事件信息，检查事件的分类、影响度和优先级是否需要更正。
873 |102.6.5|一线支持|响应并保存任务单，然后在系统外具体处理任务。
874
875
876 === **3.10.7. 一线尝试解决 102.7** ===
877
878 (% style="text-align:center" %)
879 [[image:1730684417032-955.png]]
880
881
882 具体描述如下：
883
884
885 |**序号**|**责任人**|**物理流程描述**
886 |102.7.1|一线支持|根据事件的信息描述，分析事件的原因，并尝试找出解决方案。
887 |102.7.2|一线支持|判断解决方案是否涉及变更，是则转102.7.3，否则转102.7.4。
888 |102.7.3|一线支持|提交一个变更请求单（RFC），然后监控变更过程。
889 |102.7.4|一线支持|判断事件是否得到解决，是则转102.7.5，否则转102.8.1。
890 |102.7.5|一线支持|将成功的解决方案记录在系统中，并更改事件状态为“已解决”。
891 |102.11|一线支持|填写检查事件单的信息完整性，并修正，填写解决方案，结束代码关闭流程
892
893
894 === **3.10.8. 升级转单至二线 102.8** ===
895
896 (% style="text-align:center" %)
897 [[image:1730684441238-928.png]]
898
899 具体描述如下：
900
901 |**序号**|**责任人**|**物理流程描述**
902 |102.8.1|一线支持|根据事件具体类别，确定相应的二线支持工作组和二线支持人员。
903 |102.8.2|一线支持|在HPSM系统中，填写相应的二线支持工作组和二线支持人员。
904 |102.8.3|一线支持|保存分派信息
905
906 === ===
907
908 === **3.10.9. 二线响应 102.9** ===
909
910 (% style="text-align:center" %)
911 [[image:1730684461238-651.png]]
912
913
914 具体描述如下：
915
916
917 |**序号**|**责任人**|**物理流程描述**
918 |102.9.1|二线支持|(((
919 二线支持收到通知（Email/短信/电话），查看本工作组的任务队列，找到需要处理的事件单。
920
921 注：组长应时刻观察本组的任务单，对于没有及时响应的及时介入，协调人员
922 )))
923 |102.9.2|二线支持|(((
924 判断该事件单是否是本组的工作范围？
925
926 如果不是，则转102.9.3
927
928 如果是，则开始处理；
929 )))
930 |102.9.3|二线支持|填写转发的理由和建议，转发此请求给相应的工作组。
931 |102.9.4|二线支持|处理过程中，收集事件信息，检查事件的分类、影响度和优先级是否需要更正。
932 |102.9.5|二线支持|响应并保存任务单，然后在系统外具体处理任务。
933
934
935
936 === **3.10.10. 二线尝试解决 102.10** ===
937
938 (% style="text-align:center" %)
939 [[image:1730684481655-300.png]]
940
941 具体描述如下：
942
943
944 |**序号**|**责任人**|**物理流程描述**
945 |102.10.1|二线支持|根据事件的信息描述，分析事件的原因，并尝试找出解决方案。
946 |102.10.2|二线支持|判断解决方案是否涉及变更，是则转102.10.3，否则转102.10.4。
947 |102.10.3|二线支持|提交一个变更请求单（RFC），然后监控变更过程。
948 |102.10.4|二线支持|判断事件是否得到解决，是则转102.10.6，否则转102.10.5。
949 |102.10.5|二线支持|判断是否已超出解决时限？如果是，则将该事件升级至事件经理和管理层；如果否，则转102.11.1联系三线支持。
950 |102.10.6|二线支持|将成功的解决方案记录在系统中，并更改事件状态为“已解决”。
951 |102.12|二线支持|填写检查任务子单的信息完整性，并修正，填写解决方案，结束代码关闭任务子单
952
953
954 === **3.10.11. 联系三线解决 102.11** ===
955
956
957 (% style="text-align:center" %)
958 [[image:1730684498020-994.png]]
959
960 具体描述如下：
961
962
963 |**序号**|**责任人**|**物理流程描述**
964 |102.11.1|二线支持|确认并联系第三方的支持，需要联系开发中心或厂商时，需要电话或EMAIL通知事件经理和管理层
965 |102.11.2|二线支持|三线支持（开发中心/厂商等）根据事件的实际情况，提供解决方案，二线支持作为接口负责人，共同参与事件的解决。
966 |102.10|二线支持|及时将三线的处理进展信息记录在任务单中
967
968
969
970 === **3.10.12. 关闭任务子单 102.12** ===
971
972
973 (% style="text-align:center" %)
974 [[image:1730684518388-644.png]]
975
976 具体描述如下：
977
978
979 |**序号**|**责任人**|**物理流程描述**
980 |102.12.1|服务台、一线、二线|更新任务单，包括解决方案，确认情况，用户反馈等。确保信息的完整性。
981 |102.12.2|服务台、一线、二线|根据具体情况选择相应任务结束代码。
982 |102.12.3|服务台、一线、二线|任务单关闭后，系统自动发送通知给主单处理人，告知任务单处理情况。
983 |102.12.4|服务台、一线、二线|(((
984 判断事件主单分单的人是不是自己，
985
986 如果是，则转到下一个判断102.12.5；
987
988 否则转到102.12.7等待用户确认
989 )))
990 |102.12.5|服务台、一线、二线|(((
991 如果事件主单的分单人是自己，则要查看所有的子单是否都已经完成，
992
993 如果是，则转到102.13，关闭事件
994
995 如果否，则转到102.12.6等待其他任务完成
996 )))
997 |102.12.6|服务台、一线、二线|如果事件主单的分单人是自己，任何一个子单完成时系统都会发一个EMAIL通知自己，收到EMAIL后，转到102.12.5检查是否所有的子任务都完成了。
998 |102.12.7|服务台、一线、二线|如果用户确认此任务未完成，则 分单人会重新分配此任务。
999
1000
1001 === **3.10.13. 关闭事件 102.13** ===
1002
1003
1004 (% style="text-align:center" %)
1005 [[image:1730684547320-178.png]]
1006
1007 具体描述如下：
1008
1009
1010 |**序号**|**责任人**|**物理流程描述**
1011 |102.13.1|服务台、一线、二线|更新事件记录，包括解决方案，确认情况，用户反馈等。确保信息的完整性。
1012 |102.13.2|服务台、一线、二线|根据具体情况选择相应事件结束代码并保存事件，系统会自动将解决方案通过EMAIL发送给用户。
1013 |102.13.3|服务台、一线、二线|事件解决后（处于“已解决”状态），分单人通过电话、EMAIL等跟用户进行确认是否解决。
1014 |102.13.4|服务台、一线、二线|用户如果在5个工作日内没有反馈，则分单人关闭此事件。
1015 |102.14|用户|用户在收到已解决的EMAIL后，可以进行满意度反馈。
1016
1017 === ===
1018
1019 === **3.10.14. 用户确认 102.14** ===
1020
1021
1022 (% style="text-align:center" %)
1023 [[image:1730684577707-646.png]]
1024
1025 具体描述如下：
1026
1027 |**序号**|**责任人**|**物理流程描述**
1028 |102.14.1|用户|收到EMAIL发送的解决方案。
1029 |102.14.2|用户|查看确认解决方案是否有效。
1030 |102.14.3|用户|向用户确认是否解决了事件，如果是，则进入102.14.4进行满意度反馈，如果否，则进入102.14.5。
1031 |102.14.4|用户|通过EMAIl或者电话进行满意度和解决情况反馈。
1032 |102.14.5|用户|判断解决方案是否由一线支持提供，如果是，则进入102.7.1；如果否则转向102.14.6做进一步判断。
1033 |102.14.6|用户|判断解决方案是否由二线支持提供，如果是，则进入102.10.1，如果否则转向102.7.1找一线支持重新分析和尝试解决。
1034 |102.13|服务台、一线、二线|关闭事件
1035
1036
1037
1038
1039 = **4. 事件流程与其他流程的关系** =
1040
1041
1042 (% style="text-align:center" %)
1043 [[image:图片4.jpg]]
1044
1045
1046 == **4.1. 和问题管理流程的关系** ==
1047
1048 事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势。问题管理流程中的问题经理可以主动的对事件管理流程中记录和处理的重复发生或者重大而未彻底解决的事件进行分析，并从中创建一些问题工单纳入问题管理流程做深入分析和研究。
1049
1050 另外，事件管理流程中的服务台经理和二线支持专家可以主动的将一些潜在的问题通报给问题经理，结合招行的实际情况，惠普建议如下的操作方式：
1051
1052 1. 服务台组长和事件经理将那些在一段时间内频繁发生的重复事件标志为“潜在问题”
1053 1. 二线支持专家将那些未在规定期限中找到根本解决方案的事件标志为“潜在问题”
1054
1055 服务平台将自动将这些标识事件的相关信息以邮件的形式通知问题经理，以便其在问题管理流程中对这些事件进行着重关注和诊断，必要时升级为一个问题。
1056
1057 == ==
1058
1059 == **4.2. 和配置管理流程的关系** ==
1060
1061 一般而言，服务台和事件管理流程需要从配置管理数据库中查询配置项的属性和配置项间的关联关系，以帮助事件的分析与诊断。
1062
1063 == ==
1064
1065 == **4.3. 和变更管理流程的关系** ==
1066
1067 服务台和二线支持专家在处理服务请求和事件的过程中如果涉及变更，可以依据解决方案发起一个变更请求（RFC），该请求一旦发出将进入变更管理流程进行一系列运作，最终满足客户的请求或恢复中断的服务。服务台和二线支持专家有义务监控整个变更的过程，以保证最终达到方案预定的效果。
1068
1069 = =
1070
1071 = =
1072
1073 = **5. 附录一：重要业务系统** =
1074
1075 重要业务系统是指：
1076
1077 |**系统使用范围**|**系统列表**
1078 |总行|(((
1079 AS/400核心业务系统、
1080
1081 ATM系统、
1082
1083 银联系统、
1084
1085 信用卡系统、
1086
1087 网上银行系统、
1088
1089 证券/基金/第三方存管系统、
1090
1091 电话银行系统、
1092
1093 对公业务系统和现代化支付系统
1094 )))
1095 |分行|(((
1096 柜台交易的SNA系统、
1097
1098 ATM系统、
1099
1100 银联系统（如果没有集中到总行）、
1101
1102 现代化支付系统
1103 )))
1104
1105 = =
1106
1107
1108 = **6. 附录二：重大事件处理子流程** =
1109
1110 **其中黄色部分是需要进一步明确的。**
1111
1112
1113 == **6.1. 优先级P1事件处理流程** ==
1114
1115 === **6.1.1. 外部环境导致** ===
1116
1117 (% style="text-align:center" %)
1118 [[image:图片5.jpg]]
1119
1120
1121 === **6.1.2. 信息系统缺陷导致** ===
1122
1123 (% style="text-align:center" %)
1124 [[image:图片6.jpg]]
1125
1126
1127 == **6.2. 优先级P2事件处理流程** ==
1128
1129 === **6.2.1. 全行范围重要业务系统不可用** ===
1130
1131 (% style="text-align:center" %)
1132 [[image:图片7.jpg]]
1133
1134
1135 === **6.2.2. 分行范围所有业务系统不可用** ===
1136
1137 (% style="text-align:center" %)
1138 [[image:图片8.jpg]]
1139
1140
1141 == **6.3. 优先级P3事件处理流程** ==
1142
1143 === **6.3.1. 总行重大隐患** ===
1144
1145 (% style="text-align:center" %)
1146 [[image:图片9.jpg]]
1147
1148
1149 === **6.3.2. 分行范围内重要业务系统不可用** ===
1150
1151 (% style="text-align:center" %)
1152 [[image:图片10.jpg]]
1153
1154
1155 = =
1156
1157 = =
1158
1159 = **7. 附录三：重大事件通知联络表** =
1160
1161 |(% colspan="2" rowspan="2" %)**角色**|(% colspan="2" %)**主联系人**|(% colspan="2" %)**备用联系人**|(% rowspan="2" %)**备注**
1162 |**姓名**|**联系方式**|**姓名**|**联系方式**
1163 |(% rowspan="4" %)总行|领导小组| | | | |
1164 |协调小组| | | | |
1165 |执行小组| | | | |
1166 |保障小组| | | | |
1167 |(% rowspan="4" %)~*~*分行|领导小组| | | | |
1168 |协调小组| | | | |
1169 |执行小组| | | | |
1170 |保障小组| | | | |
1171 |(% rowspan="4" %)~*~*分行|领导小组| | | | |
1172 |协调小组| | | | |
1173 |执行小组| | | | |
1174 |保障小组| | | | |
1175 | | | | | | |
1176
1177
1178
深圳市艾拓先锋企业管理咨询有限公司