Changes for page 34 某银行ITIL项目突发事件管理流程设计报告

Last modified by superadmin on 2024/11/04, 09:47

From version < 28.1

edited by superadmin
on 2024/11/04, 09:47

To version < 27.1 >

edited by superadmin
on 2024/11/04, 09:47

Change comment: 上传新附件图片10.jpg

Raw
Rendered

Summary

Page properties (3 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,1 +1,0 @@
1		-34 某银行ITIL项目突发事件管理流程设计报告

Parent

...	...	@@ -1,1 +1,0 @@
1		-G 参考资料.ITIL实施项目资料.ITIL实施项目流程设计方案集.事件管理.WebHome

Content

@@ -1,1178
          +1,0 @@
--= **1. 文档介绍** =
--
--== **1.1. 文档简介** ==
--
--本文档『突发事件管理流程设计报告』,是制定的突发事件管理流程的设计文档。通过该文档,可以帮助招行运行中心快速的解决IT环境的突发事件，为招行业务的快速发展提供更优质的IT服务。
--
--本文档的内容是依据目前IT服务状况而制定的突发事件管理流程的说明，以后进一步的更新将由运行中心负责。
--
--==   ==
--
--== **1.2. 文档用途** ==
--
--    本文档一方面作为本次ITIL项目的突发事件管理流程设计的交付物,也可作为进一步改进的蓝本,读者对象为与事件管理流程相关的所有技术与管理人员。
--
--
--=   =
--
--=   =
--
--= **2. 突发事件管理流程介绍** =
--
--== **2.1. 简介** ==
--
--突发事件管理流程是负责解决IT服务的突发事件、问题的运维流程。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。
--
--(% style="text-align:center" %)
--[[image:图片1.jpg]]
--
--==   ==
--
--== **2.2. 目的** ==
--
--事件管理流程的主要功能是尽快解决环境中出现的事件，保持IT服务的稳定性，其目的包括：
--
--* 在成本允许的范围内尽快恢复服务
--** 快速响应服务请求（事件/服务请求/咨询等）
--** 用户在线获得帮助
--** 沟通故障解决的状态
--** 和客户确认事件的解决
--
--
--* 进行事件控制
--** 按规范记录事件
--** 就事件的优先级，紧急性和严重性进行分类
--** 分析，诊断，处理，必要时进行升级
--** 监视并结束事件
--** 进行定期服务流程回顾
--
--
--* 提供IT管理信息
--** 人力资源利用情况
--** 故障处理情况
--** 支持效率
--
--
--== **2.3. 范围** ==
--
--突发事件管理的范围主要可以从下面几个角度来看：
--
--从突发事件管理涉及突发事件类别来看：
--
--* 客户突发事件：客户主动联系服务台申报的突发事件，如：PC机故障、使用应用系统时遇到问题等等。
--* 后台突发事件：通过综合告警平台发现的系统中的异常突发事件或运行中心运维人员发现的异常突发事件。
--
--
--从突发事件管理涉及的组织范围来看：
--
--* 系统运行室
--* 系统管理室
--* 网络室
--* 系统支持室
--* 南京灾备中心
--* 安全室
--* 信用卡室
--
--
--从突发事件管理的上报渠道来看
--
--* 电话
--* 一事通
--* 监控软件
--* 电子邮件
--* RTX
--* 运维人员提交
--
--==   ==
--
--== **2.4. 主要内容** ==
--
--突发事件管理流程着重于在快速解决IT环境中的突发事件，并降低其对业务的影响度。主要活动包括记录突发事件、分派突发事件、找出解决方案和结束突发事件等，其流程内容如下：
--
--* **检测和记录**  突发事件通过系统管理软件检测出来或用户打电话进来产生的，所有突发事件记录进系统中。
--
--
--* **判断并分派**  确定是服务请求、突发事件、咨询还是投诉。如果是突发事件，进行突发事件的影响、收集信息等，尝试解决问题。
--
--
--* **判断是否已解决**  确定问题是否已解决，如解决，转5由服务台确认；如未解决，继续诊断，必要时转4由二线支持，三线（厂商和集成商、服务商等）进行支持解决等。
--
--
--* **调查和诊断**  二线支持和三线（厂商和集成商、服务商等）支持人员利用自身技能和相关工具，力图在规定的时间内提出解决方案，尝试解决突发事件。转3
--
--
--* **服务台确认**  对突发事件的解决方案进行确认，如未解决，根据情况采取相应动作，如转3继续，如解决，转6。
--
--
--* **结束**   如果确认已解决，关闭记录，更新文档; 必要时进行回顾。
--
--
--* **定期产生报表**   突发事件支持人员将根据管理要求定期产生相关报表。
--
--
--
--== **2.5. 业务价值** ==
--
--突发事件管理流程将在多方面对IT服务产生积极作用，具体表现在：
--
--**提高服务可用性 **–  不管什么原因，当用户不能使用IT提供的IT服务的时候(如咨询如何使用，设备宕机，网络过载等)，服务都是被认为不可用的，它影响了用户的生产率。突发事件管理流程通过保证突发事件、问题和请求等的快速处理来达到服务可用性的最大化。** **
--
--**提高客户满意度 **– 突发事件管理流程通过记录和管理突发事件的集成系统来提供有效服务以及一个集中的知识库。同时，也提供了服务供应者和使用者的沟通渠道，加强了信息中心和用户之间的双向认同。
--
--**集中化突发事件数据** – 通过突发事件管理流程和系统来统一收集突发事件数据，这些数据被其他流程所使用，如问题管理流程将分析这些数据以确定突发事件的根本原因，并确定纠正措施以消除再次发生的可能性。
--
--
--=   =
--
--=   =
--
--= **3. 事件管理流程设计** =
--
--== **3.1. 流程指导原则** ==
--
--咨询顾问和XX在事件管理流程咨询的设计阶段，一起共同设计事件管理流程遵循的原则。流程的原则是双方对流程的认识达成共识，是流程设计的基础和关键因素。下面是一些标准的事件管理流程遵循的原则：
--
--* 指导原则 1：
--
--突发事件管理流程中的服务台是运行中心向其他部门用户提供服务的单一联系点，服务台通过电话或Web对外提供服务，同时接受用户的查询请求；
--
--* 指导原则2：
--
--任何运行中心以外的部门要解决的突发事件不能绕过服务台来解决，所有需解决的突发事件要通过服务台向运行中心提交；
--
--* 指导原则3：
--
--任何突发事件，主单只是一个请求，必须创建任务子单，所有的处理过程在任务子单中完成；
--
--* 指导原则4：
--
--来自“一事通”的突发事件，由服务台热线在“一事通”中完成分单操作，并对主申请单进行跟踪、处理；
--
--运行中心内部员工提交的突发事件，如果提交人知道如何分单，则将主申请单处理人指定为自己，并指定任务单的处理人，由系统根据指定的任务单处理人自动生成任务子单；如果提交人不知道如何分单，则由提交人转发突发事件单给服务台，由服务台来分单；
--
--* 指导原则5：
--
--对突发事件进行分单的员工是该事件的责任人，必须确保将突发事件正确的拆分成一个或者多个任务子单；确保将这些任务子单正确的分派给相应的处理人；对突发事件的解决进度和质量进行有效跟踪与协调；
--
--* 指导原则6：
--
--在整个突发事件的解决过程中，分单的员工应及时向用户通报突发事件的处理情况，使用户可以知道突发事件的解决状态；服务台员工也应该及时了解掌握突发事件处理的进度和情况，以方便跟用户进行沟通，或者接受用户查询；
--
--* 指导原则7：
--
--突发事件必须在得到用户的确认后，才能关闭记录。结合招行目前运维状况，一期目标是由系统将突发事件处理结果通过邮件发送给用户，用户如果在5个工作日内未反馈，则认为用户已经确认。
--
--* 指导原则8：
--
--突发事件的主申请单由分单人跟踪处理并关闭，任务子单由处理人直接关闭。
--
--==   ==
--
--== **3.2. 一事通接口** ==
--
--结合本次项目的需求和运行中心对一事通中请求处理的实际情况，HP建议本期项目一事通接口采用以下方案：
--
--从来源上看，可将目前一事通中的所有的请求分为以下两种类型来处理：
--
--
--* **运行中心内部的突发事件/服务请求，跟其他任何部门都没有关系，流程始终在运行部内部流转。**
--
--
--此类请求将不再使用一事通平台，而是直接由发起人在新的HPSM平台中按照新的流程提交，并由系统自动转发给相关的处理人，中间不再经由服务台进行分派工单、审批等。
--
--
--
--* **需要其他部门参与的突发事件/服务请求，甚至其他项目管理等等事情**
--
--这其中又细分为以下两种情形：
--
--
--    a.运行中心发起中间需要其他部门参与的
--
--这种请求运行部人员在一事通提交请求，全部审批（包括运行部人员的审批）完成后，服务台在一事通中完成分单操作后，系统通过接口将请求主单和子单信息一起转入新的HPSM平台按照新的流程处理。
--
--    b.其他部门发起需要运行部审批或者处理的
--
--这种请求运行部人员在一事通提交请求，全部审批（包括运行部人员的审批）完成后，服务台在一事通中完成分单操作后，系统通过接口将请求主单和子单信息一起转入新的HPSM平台按照新的流程处理。
--
--
--**以上a,b两种情况，最后具体落实处理的部门可能是运行中心，也可能不是运行中心。**
--
--==   ==
--
--== **3.3. 分派机制** ==
--
--针对上一个章节设计的两种来源的服务请求和突发事件，分别有以下的分派机制：
--
--* **运行中心内部的突发事件/服务请求，跟其他任何部门都没有关系，流程始终在运行部内部流转。**
--
--
--运行中心内部的服务请求和突发事件，包括服务台通过电话或者EMAIL或者RTX接受到的服务请求或者突发事件。
--
--系统会根据服务目录的定义，自动分配给一线或者二线，如果在服务目录中没有清晰的定义，则由请求或者突发事件的提交人将请求分派给一线处理，如果一线人员无法处理则升级分派到二线。
--
--
--* **需要其他部门参与的突发事件/服务请求，甚至其他项目管理等等事情**
--
--
--申请人在一事通中提交服务请求和突发事件，由服务台在一事通中完成分派操作，所有的服务请求和突发事件首先分派给一线中负责相关业务的人员，如果一线人员无法处理则升级分派到二线。
--
--==   ==
--
--== **3.4. 技术平台相关代码定义** ==
--
--=== **3.4.1. 信息项** ===
--
--* **各个流程的通用属性：**
--
--|(% colspan="4" %)**所有流程共有属性**
--|**编号**|**属性**|**类型**|**说明**
--|1|ID|TEXT|(((
--突发事件IM/服务请求SQ/问题PM/变更CH/服务台SD
--
--能否使用日期来区分，例如：IM090224000001
--)))
--|2|状态|CODE|
--|3|类别|TEXT|室
--|4|子类别|TEXT|应用系统
--|5|类型|TEXT|突发事件/服务请求/问题/变更
--|6|子类型|TEXT|具体的事件、问题或者变更类型
--|7|影响范围|CODE|
--|8|紧急程度|CODE|
--|9|优先级|CODE|由影响范围和紧急程度计算得来
--|10|简要描述|TEXT|
--|11|详细描述|TEXT|
--|12|活动记录|TEXT|处理步骤的活动记录，包括类型、人员、日期、更新内容
--|13|登记人|RELATION|创建此单的人，默认当前登录人
--|14|申请人|RELATION|事件等流程请求人，默认当前登录人
--|15|分派组|RELATION|此单当前处理人所属的组别，建议按照目前运维组别来分
--|16|分派人|RELATION|此单当前处理人
--|17|解决方案|TEXT|
--|18|关闭代码|RELATION|例如：根本解决、替代方法、误报、用户取消。。。
--|19|打开时间|DATE|创建时间
--|20|更新时间|DATE|最后更新的时间
--|21|计划响应时间|DATE|由“优先级”决定，仅用于突发事件和服务请求流程
--|22|实际响应时间|DATE|
--|23|是否按时响应|TEXT|由“计划响应时间”“实际响应时间”比较的结果决定
--|24|计划完成时间|DATE|由“优先级”决定，适用所有流程
--|25|实际完成时间|DATE|填写“解决方案”和“结束代码”的时间
--|26|是否按时完成|TEXT|由“计划完成时间”“实际完成时间”比较的结果决定
--|27|处理时长（分钟）|TEXT|手工填写
--|28|中断时长（分钟）|TEXT|手工填写，是指“子类别”的中断时长
--|29|附件|RELATION|相关附件
--|30|配置项|RELATION|相关配置项
--|31|相关|RELATION|突发事件、服务请求、问题、变更之间的关联
--|32|所属室|TEXT|该突发事件的由哪个室处理完成
--|33|所属组|TEXT|该突发事件的由哪个组处理完成
--|34|事件来源|TEXT|参见事件来源定义
--
--
--* **突发事件特有属性：**
--
--|(% colspan="4" %)**服务请求特有属性**
--|**编号**|**属性**|**类型**|**说明**
--|1|服务台满意度|CODE|服务台服务态度的满意度
--|2|技术支持满意度|CODE|技术支持的满意度
--|3|客户意见|TEXT|反馈意见
--|4|服务级别|RELATION|缺省为5×8服务
--|5|到达服务台时间|DATE|服务请求分派给服务台的时间
--|6|来源ID|TEXT|通过接口进入HPSM的事件，其来源ID
--| | | |
--
--
--=== **3.4.2. 突发事件分类** ===
--
--对突发事件的进行分类，主要目的在于方便各个突发事件处理组之间的信息沟通，为突发事件的诊断和处理提供信息，并产生相关的管理信息报表，从而达到优化提高IT服务质量，提高突发事件处理效率的目标。
--
--具体分类原则、标准和方法是：
--
--各个流程，包括事件、问题、变更等分类统一规划，遵循统一的原则和标准，分类的层次为4级：
--
--第一个层次： 类别
--
--第二个层次： 子类别
--
--第三个层次： 流程模块
--
--第四个层次： 操作类型
--
--例如：
--
--|**类别**|**子类别**|**流程**|**操作类型**
--|(% rowspan="22" %)**信用卡**|(% rowspan="15" %)**信用卡微机系统 - 370020**|(% rowspan="3" %)**服务请求**|**路由开通**
--|**增加用户**
--|**…….**
--|(% rowspan="3" %)**突发事件**|**用户user1系统无法登录**
--|**系统打开很慢**
--|**……**
--|(% rowspan="3" %)**问题**|**用户管理**
--|** **
--|**……**
--|(% rowspan="3" %)**变更**|**系统版本升级**
--|**增加一个菜单**
--|**…….**
--|(% rowspan="3" %)**知识库**|**系统安装**
--|**用户管理**
--|**…….**
--|(% rowspan="5" %)**信用卡数据库 - 370030**|**服务请求**|** **
--|**突发事件**|** **
--|**问题**|** **
--|**变更**|** **
--|**知识库**|** **
--|**信用卡主机系统 - 370010**|** **|** **
--|**信用卡主机系统 - 370010**|** **|** **
--
--
--详情参见《流程分类表》
--
--===   ===
--
--=== **3.4.3. 影响度、紧急度和优先级** ===
--
--突发事件在提交到运行中心以后，因为数量很多，HP建议使用“影响范围”和“影响程度”两个纬度来计算每个突发事件的“优先级”，这个优先级跟《招商银行信息系统紧急突发事件管理办法》规定的P1-P5相对应，突发事件处理人员将根据此优先级的高低来决定处理的先后顺序。
--
--* **优先级**
--
--|**编号**|**代码**|**解释**
--|1|P1|灾难事件
--|2|P2|严重事件
--|3|P3|重大事件
--|4|P4|一般事件
--|5|P5|隐患
--
--
--* **影响范围**
--
--|**编号**|**影响范围**|**影响范围代码**|**描述**
--|1|全行所有业务系统|S1|
--|2|全行一个或者多个重要业务系统|S2|
--|3|一个或者多个分行所有业务系统|S3|
--|4|一个或者多个分行某个重要业务系统|S4|
--|5|总行或者分行的一个或者多个非重要业务系统|S5|
--|6|对业务有影响的一个或者多个办公系统|S6|
--| | | |
--
--
--影响范围定义中的业务系统列表，参见附录一。
--
--
--* **影响程度**
--
--|**编号**|**影响度**|**影响度代码**|**描述**
--|1|不可用|I1|系统完全不可用
--|2|可用性受影响|I2|系统可用性受到影响
--|3|可用性受威胁|I3|系统可用，但是可用性受到威胁
--
--
--优先级用来指导运维人员确定突发事件处理的先后次序，优先级高的请求先处理，优先级低的后处理。为了能够客观的评价一个突发事件的优先级，可以使用“影响范围”和“影响度”两个维度来综合计算优先级。
--
--
--|(% colspan="2" rowspan="2" %)(((
--**~                              影响度**
--
--**~    影响范围**
--)))|**不可用**|(((
--**可用性**
--
--**受影响**
--)))|(((
--**可用性**
--
--**受威胁**
--)))
--|**I1**|**I2**|**I3**
--|**全行所有业务系统**|**S1**|P1|P2|P3
--|**全行一个或者多个重要业务系统**|**S2**|P2|P3|P5
--|**一个或者多个分行所有业务系统**|**S3**|P2|P3|P5
--|**一个或者多个分行某个重要业务系统**|**S4**|P3|P3|P5
--|**总行或者分行的一个或者多个非重要业务系统**|**S5**|P4|P4|P5
--|**对业务有影响的一个或者多个办公系统**|**S6**|P4|P5|P5
--| | | | |
--
--
--=== **3.4.4. 优先级和解决时限** ===
--
--与优先级相对应，我们定义一个事件处理的时限要求（deadline）和响应时限要求。下表列出了通常与各优先级对应的时限：
--
--|**编号**|**优先级代码**|**解决时限（工作时间）**|**响应时限**
--|1|P1|1个小时|5分钟
--|2|P2|4个小时|15分钟
--|3|P3|8个小时|1小时
--|4|P4|16个小时|2小时
--|5|P5|32个小时|4小时
--
--注：以上时限设置，仅供参考，项目上线后，可做为参数灵活配置
--
--
--解决时限的定义：事件单的实际完成时间（状态为已解决） － 事件单的分派时间（状态为处理中）
--
--响应时限的定义：事件单的响应时间（状态处理中）－ 事件单的创建时间（状态为待处理）
--
--===   ===
--
--=== **3.4.5. 升级通告路径的定义** ===
--
--当事件创建以后，需要相关工程师对事件进行响应和处理，为了保证事件能够及时被分派并且被处理，在事件管理流程中需要对不同级别的事件设定不同的响应时限，如果，违背了响应时限，系统将根据事件的优先级自动向相关事件处理人和事件经理发起通告，由事件经理负责协调资源，并督促事件能够及时被响应和处理。
--
--在不同优先级别/影响程度的事件有不同的升级通知路径，在通告的每个过程中，相关人员都需要执行相应的动作来报障事件能够在规定的时间限制内解决：
--
--|**优先级**|**响应通告**|**解决通告**
--|P1|超时5分钟à 当前处理工程师、事件经理、行政经理|(((
--* 通告事件经理；
--* 最终期限前0.5小时à事件受理人、当前处理工程师、组长、事件经理；
--* 已超时à事件受理人、当前处理工程师、组长、事件经理、行政经理
--)))
--|P2|超时15分钟à当前处理工程师、事件经理、行政经理|(((
--* 创建时通知事件经理
--* 最终期限前2小时à事件受理人、当前处理工程师、组长；
--* 已超时à事件受理人、当前处理工程师、组长、事件经理、行政经理；
--)))
--|P3|超时1小时à当前处理工程师、事件经理、行政组长|(((
--* 最终期限前4小时à当前处理工程师、行政组长；
--* 已超时à事件受理人、当前处理工程师、行政组长、事件经理；
--)))
--|P4|超时2小时à 当前处理工程师、事件经理|(((
--* 最终期限前8小时à当前处理工程师、组长；
--* 已超时à事件受理人、当前处理工程师、组长、事件经理；
--)))
--|P5|超时4小时à当前处理工程师、事件经理|(((
--* 最终期限前16小时à当前处理工程师、组长；
--* 已超时à事件受理人、当前处理工程师、组长、事件经理；
--)))
--
--注：以上时限设置，仅供参考，项目上线后，可做为参数灵活配置
--
--===   ===
--
--=== **3.4.6. 事件状态** ===
--
--|**编号**|**代码**|**描述**
--|1|已登记|新开事件记录或事件已创建
--|2|待处理|突发事件已经分配给一线或者二线，等待处理人处理
--|3|处理中|二线支持人员已接手处理事件
--|4|已解决|事件已解决，支持人员联系用户验证事件是否获得解决
--|5|关闭|事件已关闭
--
--
--=== **3.4.7. 事件结束代码** ===
--
--|**编号**|(% colspan="2" %)**代码**|**描述**
--|1.|服务台解决|服务台解决|由服务台维护解决
--|(% rowspan="2" %)2.|(% rowspan="2" %)一线解决|根本解决|找到事件的根本原因
--|替代方法|使用替代方法解决
--|(% rowspan="2" %)3.|(% rowspan="2" %)二线解决|根本解决|找到事件的根本原因
--|替代方法|使用替代方法解决
--|(% rowspan="2" %)4|(% rowspan="2" %)三线解决|内部解决|由开发中心开发人员解决
--|厂商解决|外部厂商解决
--|(% rowspan="2" %)5.|(% rowspan="2" %)未解决|上升到问题|提交到问题管理系统
--|无法解决|无法解决
--|6.|(% colspan="2" %)自动恢复|系统自动恢复，事件无法再现
--|7.|(% colspan="2" %)误报|属于误报事件
--|8．|(% colspan="2" %)拒绝|服务请求被拒绝
--
--
--=== **3.4.8. 事件来源** ===
--
--|**编号**|**代码**|**备注**
--|1.|电话|服务台、一线或者二线人员根据客户电话创建的
--|2.|一事通|来自一事通
--|3.|RTX|来自RTX
--|4.|监控系统|监控系统通过接口自动创建的
--|5.|运行中心|运行中心内部人员提交的
--|6.|EMAIL|服务台、一线或者二线人员根据客户EMAIL创建的
--
--
--=== **3.4.9. 服务台满意度 ** ===
--
--|**编号**|**代码**|**备注**
--|1|非常好|
--|2|正常|
--|3|需要提高|
--
--
--=== **3.4.10. 技术支持满意度   ** ===
--
--|**编号**|**代码**|**备注**
--|1|非常好|
--|3|正常|
--|4|需要提高|
--
--
--=== **3.4.11. 工作子单状态代码** ===
--
--当工程师在处理突发事件单时，有时需要其它工程师协调处理，或者需要征得其它同事的同意或认可，则可以在当前的突发事件单上发起工作子单并分派给相关的人员，所以，工作子单也有生命周期，即对应的各种状态：
--
--
--|**序号**|**代码**|**描述**
--|1.|待处理|等待处理；
--|2.|处理中|处理中；
--|3.|已完成|工作子单已实施；
--
--
--=== **3.4.12. 工作子单分类** ===
--
--其它的流程如问题、配置、变更都会产生相应的工作单，所以最终工作单的分类应该综合各个流程产生的需求。
--
--|**序号**|**代码**|**描述**
--|1.|协助处理|事件处理过程的协助
--|2.|会议|会议记录的工作单
--|3.|。。。|
--
--==   ==
--
--== **3.5. 事件管理的人员角色和职责** ==
--
--结合ITSM最佳实践，在事件管理流程中推荐的主要角色有：事件经理、服务台主管、服务台热线支持、服务台一线支持、服务台现场支持以及二线和三线支持等。
--
--===   ===
--
--=== **3.5.1. 事件经理** ===
--
--**事件经理职责:**
--
--* 确保有效协调资源,通过事件支持专家快速恢复正常服务。
--* 确保事件管理支持人员的适当技能水平和绩效表现。
--* 确保和问题管理流程经理及外部供应商等部门的有效合作。
--* 确保正确和广泛地收集和分析事件数据,发现IT和业务相关的问题。
--* 通过服务台的作用及良好的服务态度来确保客户的满意。
--* 确保有关IT服务和客户支持的管理信息的可获得性。
--* 改进和提高事件管理流程的有效性和效率。
--
--
--**事件经理技能:**
--
--* 深刻了解事件管理流程
--* 较强的领导能力
--* 了解技术架构和技术环境
--* 较强的口头表达能力和与客户沟通技巧
--* 处理纠纷的能力
--
--===   ===
--
--=== **3.5.2. 二线支持** ===
--
--**二线支持职责：**
--
--* 接受一线支持升级的事件或服务请求，验证事件的描述，进一步收集相关信息
--* 在规定的时间内解决事件和服务请求
--* 对利用“替代方案"解决的事件，在资源及时间允许时应找到问题根源
--* 在需要时及时利用其它资源(开发中心,开发商, 厂家) 参与事件解决
--* 将事件的解决步骤文档化，并将解决方案录入服务台系统中
--
--* 根据解决方案进行IT服务恢复
--* 向现场服务人员提供必要的技术支持和协助
--* 需要时根据解决方案发起变更请求RFC，监控变更请求过程并对解决结果进行确认
--* 负责跟开发中心、集成商和供应商之间的接口
--* 为VIP用户提供在线或现场支持
--
--**二线支持技能：**
--
--* 熟悉技术平台和技术环境.
--* 很强的技术能力
--* 较强的解决事件的能力
--* 较强的分析能力
--
--
--=== **3.5.3. 三线支持** ===
--
--对于运行中心来说，三线支持主要是指开发中心和厂商，在事件处理流程中二线支持专家，来协调三线人员来帮助处理突发事件或者服务请求。处理的结果由二线人员录入系统，并通过结束代码注明由三线解决。
--
--**三线支持厂商人员职责：**
--
--* 接受二线支持升级的事件或服务请求，验证事件的描述，进一步收集相关信息
--* 在规定的时间内解决事件和服务请求
--* 负责协调厂商、开发商内部资源
--
--
--**三线支持开发人员职责：**
--
--* 接受二线支持升级的事件或服务请求，验证事件的描述，进一步收集相关信息
--* 在规定的时间内解决事件和服务请求
--* 负责协调开发中心内部资源
--
--**三线支持技能：**
--
--* 很强的资源协调能力
--* 熟悉技术平台和技术环境.
--* 较强的分析能力
--
--
--=== **3.5.4. VIP支持** ===
--
--**VIP支持职责：**
--
--* 当接收到VIP客户的服务要求时，及时准确地为VIP客户提供服务；
--* 随时关注VIP客户的满意度，积极调动资源为VIP客户提供服务；
--* 二线支持工程师的所有职责。
--
--
--**VIP支持技能要求：**
--
--* 较强的沟通能力；
--* 较强的倾听能力；
--* 熟悉事件处理流程和服务台的职责；
--* 较强的协调能力，能够迅速协调相关的二线团队为VIP提供服务；
--* 二线支持的所有技能
--
--
--
--== **3.6. 流程角色和人员对应** ==
--
--|(% colspan="2" %)**角色**|**工作组**|**成员**
--|事件经理| |事件经理|
--|服务台主管| |服务台主管|
--|服务台热线支持| |服务台-热线支持|
--|服务台现场支持| |服务台-现场支持|
--|(% rowspan="7" %)服务台一线支持|系统运行室|一线-系统运行|
--|系统管理室| |
--|网络室| |
--|系统支持室| |
--|南京灾备中心| |
--|安全室| |
--|信用卡| |
--|(% rowspan="7" %)二线支持|系统运行室|二线-系统运行|
--|系统管理室| |
--|网络室| |
--|系统支持室| |
--|南京灾备中心| |
--|安全室| |
--|信用卡| |
--|小组组长| | |
--|室经理| | |
--|总经理室成员| | |
--|VIP支持| | |
--
--
--== **3.7. 事件处理逻辑流程** ==
--
--根据流程设计要求, 我们将事件管理流程的设计标号以100开头,  比如100.X.
--
--流程图相关符号说明：
--
--(% style="text-align:center" %)
--[[image:1730684027930-584.png]]
--
--===   ===
--
--=== **3.7.1. 一事通请求处理逻辑流程** ===
--
--根据具体情况, 同时结合ITSM的最佳经验, 建议在本次项目中，对目前一事通中的请求（这些请求包括服务请求、突发事件和变更），由服务台进行初步审核确认并组织审批，然后通过接口进入本次项目引进的HPSM系统，按照新的服务请求、突发事件和变更流程来处理。
--
--具体来看，一事通中请求处理的逻辑流程如下图：
--
--(% style="text-align:center" %)
--[[image:图片2.jpg]]
--
--
--=== **3.7.2. 突发事件管理逻辑流程** ===
--
--(% style="text-align:center" %)
--[[image:图片3.jpg]]
--
--
--== **3.8. 事件处理物理流程** ==
--
--在上面的章节中描述了突发事件管理的逻辑流程，在下面两个章节会结合逻辑流程中的主要环节进行展开描述，我们称之为物理流程。
--
--==   ==
--
--== **3.9. 一事通请求管理物理流程** ==
--
--在3.7节中描述了突发事件管理的逻辑流程，在本节会结合突发事件的逻辑流程，针对“一事通”中的请求展开对流程的详细描述，我们称之为物理流程。
--
--===   ===
--
--=== **3.9.1. 产生请求单100.1** ===
--
--此流程在“一事通”中实现。
--
--===   ===
--
--=== **3.9.2. 审核请求 100.2** ===
--
--此流程在“一事通”中实现。
--
--===   ===
--
--=== **3.9.3. 审批请求 100.3** ===
--
--此流程在“一事通”中实现。
--
--=== **3.9.4. 分单 100.4** ===
--
--此流程在“一事通”中实现。
--
--===   ===
--
--=== **3.9.5. 创建突发事件 100.5** ===
--
--(% style="text-align:center" %)
--[[image:1730684204735-163.png]]
--
--具体描述如下：
--
--
--|**序号**|**责任人**|**物理流程描述**
--|100.5.1|服务台热线人员|在一事通中选择分派组。
--|100.5.2|服务台热线人员|在一事通中选择分派人。
--|100.5.3|服务台热线人员|在一事通中选择创建突发事件并保存。
--|100.5.4|系统|一事通和HPSM接口自动根据一事通信息，在HPSM中生成突发事件
--
--===   ===
--
--=== **3.9.6. 创建变更 100.6** ===
--
--
--(% style="text-align:center" %)
--[[image:1730684226176-364.png]]
--
--具体描述如下：
--
--
--|**序号**|**责任人**|**物理流程描述**
--|100.6.1|服务台热线人员|在一事通中选择分派组。
--|100.6.2|服务台热线人员|在一事通中选择分派人。
--|100.6.3|服务台热线人员|在一事通中选择创建变更并保存。
--|100.6.4|系统|一事通和HPSM接口自动根据一事通信息，在HPSM中生成变更
--
--
--=== **3.9.7. 创建服务请求 100.7** ===
--
--具体描述如下：
--
--|**序号**|**责任人**|**物理流程描述**
--|100.7.1|服务台热线人员|在一事通中选择分派组。
--|100.7.2|服务台热线人员|在一事通中选择分派人。
--|100.7.3|服务台热线人员|在一事通中选择创建服务请求并保存。
--|100.7.4|系统|一事通和HPSM接口自动根据一事通信息，在HPSM中生成服务请求
--
--
--== **3.10. 突发事件管理物理流程** ==
--
--在3.7节中描述了事件管理的逻辑流程，在本节会结合逻辑流程中的主要环节进行展开描述，我们称之为物理流程。
--
--===   ===
--
--=== **3.10.1. 产生记录 102.1** ===
--
--
--(% style="text-align:center" %)
--[[image:1730684276216-425.png]]
--
--
--具体描述如下：
--
--|**序号**|**责任人**|**物理流程描述**
--|102.1.1|服务台、一线、二线|打开“突发事件”的输入界面。
--|102.1.2|服务台、一线、二线|选择事件请求人。可以使用请求人的账号或者姓名作为索引定位HPSM数据库中的人员数据。
--|102.1.3|服务台、一线、二线|注明事件类别信息、标题，并输入详细情况描述。
--|100.1.4|服务台、一线、二线|如果可以确定到配置项，则选择跟此事件相关的配置项。
--|100.1.5|服务台、一线、二线|根据用户的描述，填写初步判断的紧急程度和影响范围
--
--
--=== **3.10.2. 收集信息 102.2** ===
--
--
--(% style="text-align:center" %)
--[[image:1730684308633-426.png]]
--
--具体描述如下：
--
--|**序号**|**责任人**|**物理流程描述**
--|102.2.1|服务台、一线、二线|从用户处了解更多有关此事件的相关信息。
--|102.2.6|服务台、一线、二线|(((
--根据//附件一：重大事件定义和应急预案//和//4.1.5优先级代码//的定义判断该事件优先级是否为P1、P2或者P3？
--
--1. 如果是，需要走重大事件处理子流程同时在系统中创建重大事件记录；
--1. 否则进行下一步，转102.3.1
--)))
--
--
--=== **3.10.3. 分派任务子单 102.3** ===
--
--
--(% style="text-align:center" %)
--[[image:1730684333376-646.png]]
--
--具体描述如下：
--
--|**序号**|**责任人**|**物理流程描述**
--|102.3.1|服务台、一线、二线|根据事件的信息描述，判断需要拆分成几个任务子单。
--|102.3.2|服务台、一线、二线|创建任务子单，补充或者填写子单信息，设置分派组和分派人信息。
--|102.3.3|服务台、一线、二线|保存子单信息。
--|102.3.4|服务台、一线、二线|(((
--判断该是否需要继续添加子单，
--
--如果是转102.3.1继续创建任务子单；
--
--否则转102.3.5；
--)))
--|102.3.5|服务台、一线、二线|保存主单信息。
--
--===   ===
--
--=== **3.10.4. 服务台尝试解决 102.4** ===
--
--(% style="text-align:center" %)
--[[image:1730684355138-392.png]]
--
--
--具体描述如下：
--
--|**序号**|**责任人**|**物理流程描述**
--|102.4.1|服务台|根据事件的信息描述，分析事件的原因，并尝试找出解决方案。
--|102.4.2|服务台|(((
--判断任务是否得到解决，
--
--是则转102.4.3
--
--否则转102.5.1派单到一线。
--)))
--|102.4.3|服务台|将成功的解决方案和结束代码记录在系统中，并更改任务单状态为“已解决”。
--
--
--=== **3.10.5. 升级转单至一线 102.5** ===
--
--(% style="text-align:center" %)
--[[image:1730684373845-963.png]]
--
--
--具体描述如下：
--
--|**序号**|**责任人**|**物理流程描述**
--|102.5.1|服务台|根据任务单具体类别，确定并设置相应的一线支持工作组。
--|102.5.2|服务台|根据工作组分配机制，确定并设置相应的一线支持人员。
--|102.5.3|服务台|保存分派信息
--
--
--
--=== **3.10.6. 一线响应 102.6** ===
--
--
--(% style="text-align:center" %)
--[[image:1730684395067-200.png]]
--
--具体描述如下：
--
--
--|**序号**|**责任人**|**物理流程描述**
--|102.6.1|一线支持|(((
--一线支持收到通知（Email/短信/电话），查看本工作组的任务队列，找到需要处理的事件单。
--
--注：组长应时刻观察本组的任务单，对于没有及时响应的及时介入，协调人员
--)))
--|102.6.2|一线支持|(((
--判断该事件单是否是本组的工作范围？
--
--如果不是，则转102.6.3
--
--如果是，则开始处理；
--)))
--|102.6.3|一线支持|填写转发的理由和建议，转发此请求给相应的工作组。
--|102.6.4|一线支持|处理过程中，收集事件信息，检查事件的分类、影响度和优先级是否需要更正。
--|102.6.5|一线支持|响应并保存任务单，然后在系统外具体处理任务。
--
--
--=== **3.10.7. 一线尝试解决 102.7** ===
--
--(% style="text-align:center" %)
--[[image:1730684417032-955.png]]
--
--
--具体描述如下：
--
--
--|**序号**|**责任人**|**物理流程描述**
--|102.7.1|一线支持|根据事件的信息描述，分析事件的原因，并尝试找出解决方案。
--|102.7.2|一线支持|判断解决方案是否涉及变更，是则转102.7.3，否则转102.7.4。
--|102.7.3|一线支持|提交一个变更请求单（RFC），然后监控变更过程。
--|102.7.4|一线支持|判断事件是否得到解决，是则转102.7.5，否则转102.8.1。
--|102.7.5|一线支持|将成功的解决方案记录在系统中，并更改事件状态为“已解决”。
--|102.11|一线支持|填写检查事件单的信息完整性，并修正，填写解决方案，结束代码关闭流程
--
--
--=== **3.10.8. 升级转单至二线 102.8** ===
--
--(% style="text-align:center" %)
--[[image:1730684441238-928.png]]
--
--具体描述如下：
--
--|**序号**|**责任人**|**物理流程描述**
--|102.8.1|一线支持|根据事件具体类别，确定相应的二线支持工作组和二线支持人员。
--|102.8.2|一线支持|在HPSM系统中，填写相应的二线支持工作组和二线支持人员。
--|102.8.3|一线支持|保存分派信息
--
--===   ===
--
--=== **3.10.9. 二线响应 102.9** ===
--
--(% style="text-align:center" %)
--[[image:1730684461238-651.png]]
--
--
--具体描述如下：
--
--
--|**序号**|**责任人**|**物理流程描述**
--|102.9.1|二线支持|(((
--二线支持收到通知（Email/短信/电话），查看本工作组的任务队列，找到需要处理的事件单。
--
--注：组长应时刻观察本组的任务单，对于没有及时响应的及时介入，协调人员
--)))
--|102.9.2|二线支持|(((
--判断该事件单是否是本组的工作范围？
--
--如果不是，则转102.9.3
--
--如果是，则开始处理；
--)))
--|102.9.3|二线支持|填写转发的理由和建议，转发此请求给相应的工作组。
--|102.9.4|二线支持|处理过程中，收集事件信息，检查事件的分类、影响度和优先级是否需要更正。
--|102.9.5|二线支持|响应并保存任务单，然后在系统外具体处理任务。
--
--
--
--=== **3.10.10. 二线尝试解决 102.10** ===
--
--(% style="text-align:center" %)
--[[image:1730684481655-300.png]]
--
--具体描述如下：
--
--
--|**序号**|**责任人**|**物理流程描述**
--|102.10.1|二线支持|根据事件的信息描述，分析事件的原因，并尝试找出解决方案。
--|102.10.2|二线支持|判断解决方案是否涉及变更，是则转102.10.3，否则转102.10.4。
--|102.10.3|二线支持|提交一个变更请求单（RFC），然后监控变更过程。
--|102.10.4|二线支持|判断事件是否得到解决，是则转102.10.6，否则转102.10.5。
--|102.10.5|二线支持|判断是否已超出解决时限？如果是，则将该事件升级至事件经理和管理层；如果否，则转102.11.1联系三线支持。
--|102.10.6|二线支持|将成功的解决方案记录在系统中，并更改事件状态为“已解决”。
--|102.12|二线支持|填写检查任务子单的信息完整性，并修正，填写解决方案，结束代码关闭任务子单
--
--
--=== **3.10.11. 联系三线解决 102.11** ===
--
--
--(% style="text-align:center" %)
--[[image:1730684498020-994.png]]
--
--具体描述如下：
--
--
--|**序号**|**责任人**|**物理流程描述**
--|102.11.1|二线支持|确认并联系第三方的支持，需要联系开发中心或厂商时，需要电话或EMAIL通知事件经理和管理层
--|102.11.2|二线支持|三线支持（开发中心/厂商等）根据事件的实际情况，提供解决方案，二线支持作为接口负责人，共同参与事件的解决。
--|102.10|二线支持|及时将三线的处理进展信息记录在任务单中
--
--
--
--=== **3.10.12. 关闭任务子单 102.12** ===
--
--
--(% style="text-align:center" %)
--[[image:1730684518388-644.png]]
--
--具体描述如下：
--
--
--|**序号**|**责任人**|**物理流程描述**
--|102.12.1|服务台、一线、二线|更新任务单，包括解决方案，确认情况，用户反馈等。确保信息的完整性。
--|102.12.2|服务台、一线、二线|根据具体情况选择相应任务结束代码。
--|102.12.3|服务台、一线、二线|任务单关闭后，系统自动发送通知给主单处理人，告知任务单处理情况。
--|102.12.4|服务台、一线、二线|(((
--判断事件主单分单的人是不是自己，
--
--如果是，则转到下一个判断102.12.5；
--
--否则转到102.12.7等待用户确认
--)))
--|102.12.5|服务台、一线、二线|(((
--如果事件主单的分单人是自己，则要查看所有的子单是否都已经完成，
--
--如果是，则转到102.13，关闭事件
--
--如果否，则转到102.12.6等待其他任务完成
--)))
--|102.12.6|服务台、一线、二线|如果事件主单的分单人是自己，任何一个子单完成时系统都会发一个EMAIL通知自己，收到EMAIL后，转到102.12.5检查是否所有的子任务都完成了。
--|102.12.7|服务台、一线、二线|如果用户确认此任务未完成，则 分单人会重新分配此任务。
--
--
--=== **3.10.13. 关闭事件 102.13** ===
--
--
--(% style="text-align:center" %)
--[[image:1730684547320-178.png]]
--
--具体描述如下：
--
--
--|**序号**|**责任人**|**物理流程描述**
--|102.13.1|服务台、一线、二线|更新事件记录，包括解决方案，确认情况，用户反馈等。确保信息的完整性。
--|102.13.2|服务台、一线、二线|根据具体情况选择相应事件结束代码并保存事件，系统会自动将解决方案通过EMAIL发送给用户。
--|102.13.3|服务台、一线、二线|事件解决后（处于“已解决”状态），分单人通过电话、EMAIL等跟用户进行确认是否解决。
--|102.13.4|服务台、一线、二线|用户如果在5个工作日内没有反馈，则分单人关闭此事件。
--|102.14|用户|用户在收到已解决的EMAIL后，可以进行满意度反馈。
--
--===   ===
--
--=== **3.10.14. 用户确认 102.14** ===
--
--
--(% style="text-align:center" %)
--[[image:1730684577707-646.png]]
--
--具体描述如下：
--
--|**序号**|**责任人**|**物理流程描述**
--|102.14.1|用户|收到EMAIL发送的解决方案。
--|102.14.2|用户|查看确认解决方案是否有效。
--|102.14.3|用户|向用户确认是否解决了事件，如果是，则进入102.14.4进行满意度反馈，如果否，则进入102.14.5。
--|102.14.4|用户|通过EMAIl或者电话进行满意度和解决情况反馈。
--|102.14.5|用户|判断解决方案是否由一线支持提供，如果是，则进入102.7.1；如果否则转向102.14.6做进一步判断。
--|102.14.6|用户|判断解决方案是否由二线支持提供，如果是，则进入102.10.1，如果否则转向102.7.1找一线支持重新分析和尝试解决。
--|102.13|服务台、一线、二线|关闭事件
--
--
--
--
--= **4. 事件流程与其他流程的关系** =
--
--
--(% style="text-align:center" %)
--[[image:图片4.jpg]]
--
--
--== **4.1. 和问题管理流程的关系** ==
--
--事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势。问题管理流程中的问题经理可以主动的对事件管理流程中记录和处理的重复发生或者重大而未彻底解决的事件进行分析，并从中创建一些问题工单纳入问题管理流程做深入分析和研究。
--
--另外，事件管理流程中的服务台经理和二线支持专家可以主动的将一些潜在的问题通报给问题经理，结合招行的实际情况，惠普建议如下的操作方式：
--
--1. 服务台组长和事件经理将那些在一段时间内频繁发生的重复事件标志为“潜在问题”
--1. 二线支持专家将那些未在规定期限中找到根本解决方案的事件标志为“潜在问题”
--
--服务平台将自动将这些标识事件的相关信息以邮件的形式通知问题经理，以便其在问题管理流程中对这些事件进行着重关注和诊断，必要时升级为一个问题。
--
--==   ==
--
--== **4.2. 和配置管理流程的关系** ==
--
--一般而言，服务台和事件管理流程需要从配置管理数据库中查询配置项的属性和配置项间的关联关系，以帮助事件的分析与诊断。
--
--==   ==
--
--== **4.3. 和变更管理流程的关系** ==
--
--服务台和二线支持专家在处理服务请求和事件的过程中如果涉及变更，可以依据解决方案发起一个变更请求（RFC），该请求一旦发出将进入变更管理流程进行一系列运作，最终满足客户的请求或恢复中断的服务。服务台和二线支持专家有义务监控整个变更的过程，以保证最终达到方案预定的效果。
--
--=   =
--
--=   =
--
--= **5. 附录一：重要业务系统** =
--
--重要业务系统是指：
--
--|**系统使用范围**|**系统列表**
--|总行|(((
--AS/400核心业务系统、
--
--ATM系统、
--
--银联系统、
--
--信用卡系统、
--
--网上银行系统、
--
--证券/基金/第三方存管系统、
--
--电话银行系统、
--
--对公业务系统和现代化支付系统
--)))
--|分行|(((
--柜台交易的SNA系统、
--
--ATM系统、
--
--银联系统（如果没有集中到总行）、
--
--现代化支付系统
--)))
--
--=   =
--
--
--= **6. 附录二：重大事件处理子流程** =
--
--**其中黄色部分是需要进一步明确的。**
--
--
--== **6.1. 优先级P1事件处理流程** ==
--
--=== **6.1.1. 外部环境导致** ===
--
--(% style="text-align:center" %)
--[[image:图片5.jpg]]
--
--
--=== **6.1.2. 信息系统缺陷导致** ===
--
--(% style="text-align:center" %)
--[[image:图片6.jpg]]
--
--
--== **6.2. 优先级P2事件处理流程** ==
--
--=== **6.2.1. 全行范围重要业务系统不可用** ===
--
--(% style="text-align:center" %)
--[[image:图片7.jpg]]
--
--
--=== **6.2.2. 分行范围所有业务系统不可用** ===
--
--(% style="text-align:center" %)
--[[image:图片8.jpg]]
--
--
--== **6.3. 优先级P3事件处理流程** ==
--
--=== **6.3.1. 总行重大隐患** ===
--
--(% style="text-align:center" %)
--[[image:图片9.jpg]]
--
--
--=== **6.3.2. 分行范围内重要业务系统不可用** ===
--
--(% style="text-align:center" %)
--[[image:图片10.jpg]]
--
--
--=   =
--
--=   =
--
--= **7. 附录三：重大事件通知联络表** =
--
--|(% colspan="2" rowspan="2" %)**角色**|(% colspan="2" %)**主联系人**|(% colspan="2" %)**备用联系人**|(% rowspan="2" %)**备注**
--|**姓名**|**联系方式**|**姓名**|**联系方式**
--|(% rowspan="4" %)总行|领导小组| | | | |
--|协调小组| | | | |
--|执行小组| | | | |
--|保障小组| | | | |
--|(% rowspan="4" %)~*~*分行|领导小组| | | | |
--|协调小组| | | | |
--|执行小组| | | | |
--|保障小组| | | | |
--|(% rowspan="4" %)~*~*分行|领导小组| | | | |
--|协调小组| | | | |
--|执行小组| | | | |
--|保障小组| | | | |
--| | | | | | |
--
--
--

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司