# 15 ITIL项目实施之事件管理流程设计说明书

由 superadmin 于 2024/10/29, 16:57 最后修改
导出
Office格式
以PDF格式导出 以ODT格式导出 以RTF格式导出
其他格式

选择要导出的页面：

选择所有/ 无

Legend:
  Created Page
  Modified Extension Page
  Clean Extension Page

以HTML格式导出

​

# 1. 流程目的

事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：

- 在成本允许的范围内尽快恢复IT服务
  - 快速响应服务请求（电话/Web/邮件等）
  - 用户在线获得帮助
  - 沟通事件解决的状态
  - 和客户确认事件的解决
- 进行事件控制
  - 按规范记录事件
  - 就事件的优先级，影响度 进行分类
  - 分析，诊断，必要时进行升级
  - 监视并结束事件
  - 进行定期服务流程回顾
- 提供IT管理信息
  - 人力资源利用情况
  - 故障处理情况
  - 支持效率

#

#

# 2. 流程主要内容

事件(Incidents)是中断业务流程和降低IT服务质量的错误。事件管理流程帮助迅速解决这些事件，并最小化对于业务的不利影响。流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容：

- 事件接收和记录

这个环节是事件管理流程的起点。所有用户或系统报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。

该环节的关键是信息的准确性和完整性。

- 分类和在线支持

事件可以是一个申告/故障/告警/咨询，对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。

该环节的关键是必要的问题库支持和正确的事件分派。

- 调查和诊断

若支持人员无法解决事件，可运用问题库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。

- 解决和恢复

支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认。

- 优先级为紧急的事件（紧急事件）和事件升级

对于紧急事件，服务台应立即提交给一线人员，由一线人员判断，上报给事件经理和相关的管理层，由事件经理决定紧急事件的处理方式，确保其得到最快速的解决。

当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。

- 结束事件

当用户确认事件解决后，此时可结束该事件，并在必要时更新问题库。

#

#

# 3. 与其他流程的关系

- 和问题管理流程的关系

事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。

- 和配置管理流程的关系

需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。

- 和变更管理流程的关系

服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，涉及到需要对基础架构、应用系统及操作系统等进行变更的需要发起变更请求来解决事件。

#

#

# 4. 关键角色、职责定义

##

## 4.1 服务台人员

流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的管理流程和角色的目的是为了在充分满足流程所需角色的基础上，为具体的实现提供足够的灵活性。

事件管理流程主要分为以下几个职责/角色，分别简述如下：

服务台人员负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到合适的一线支持工程师。

职责：

1. 在指定的响应时间内响应所有服务台热线电话、邮件、工单等事件报告；
2. 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等；
3. 为事件进行适当的分类、为事件分配优先级等属性；
4. 尝试使用知识库、初步诊断、分析相关信息等方式解决事件；
5. 如果服务台不能解决事件，应当将事件分配给最合适的一线支持小组或来处理；
6. 检查事件记录的处理进度，保持与用户的联系，适时通知事件处理进展；
7. 在事件处理过程中，催办事件处理进度
8. 与用户确认事件解决方案及用户满意度反馈，关闭事件。

技能要求：

1. 熟悉技术平台和技术环境
2. 较强的沟通能力
3. 对简单的故障要有快速诊断和解决的能力
4. 熟悉事件处理流程

人员按排建议：

- 建议总公司服务台设置3人，分别负责受理桌面支持、核心业务系统类、非核心业务系统（包括其他应用系统、网络接入等）三大类事件。各分公司服务台设置2-3人受理各类事件。结合分公司实际情况，若事件单日常数量较多，服务台人数可以进行增加。

##

## 4.2 一线支持人员

在ITIL体系中，一线支持人员负责对服务台无法解决的事件进行快速有效的分析，提出解决方案以尽快恢复服务，并在必要时提供现场支持。

职责：

1. 决定需要采取何种措施恢复服务并实施有效的行动
2. 必要时提供现场支持
3. 根据优先级提供有效的解决方案
4. 更新事件解决信息，已解决的事件转回服务台，由服务台关闭事件
5. 如果一线不能解决这个事件，应当决定选择最合适的二线支持小组/人员来处理

技能要求：

1. 熟悉技术平台和技术环境
2. 较强的沟通能力
3. 快速诊断事件和解决事件的能力
4. 熟悉事件处理流程

人员按排建议：

1. 建议将分公司IT部门日常维护（包括硬件、软件、开发等）人员纳入一线支持中，按日常所管系统类型或设备类型划分到相应维护支持组中
2. 分公司具有开发人员的，将开发人员纳入到应用系统支持组中
3. 如分公司技术力量较强，可将一线支持各组根据技术能力划分为初级组、高级组
4. 对于地市技术力量薄弱的，将地市人员按岗位技能纳入省级公司相应一线支持组中
5. 对于地市技术力量较强的，可以考虑建立与省级公司平级的支持组

##

## 4.3 二线支持人员

二线支持人员是相关问题领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。

职责:

1. 进行事件的深入调查研究
2. 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动
3. 必要时引入供应商的支持
4. 及时提供有效解决方案
5. 与其他二线小组合作，确定解决方案
6. 已解决的事件转回服务台，由服务台关闭事件

技能要求：

1. 深厚的技术背景，对所维护范畴的技术深入掌握
2. 熟悉事件处理流程

人员按排建议：

- 主要由总公司各类业务系统及基础设施维护专家组成，技术力量较强的分公司的资深维护人员组成虚拟团队

##

## 4.4 三线支持人员

职责：

1. 从研发的角度进行事件的研究；
2. 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动，如发布临时补丁等；
3. 及时提供有效解决方案；
4. 已解决的事件转回服务台，由服务台关闭事件。

技能要求：

1. 具备开发公司内各类应用系统的能力，对所维护范畴的技术深入掌握；
2. 熟悉事件处理流程。

人员按排建议：

- 由总公司开发人员及厂商代维人员组成，以及分公司开发力量较强人员组成虚拟团队

##

## 4.5 事件经理

事件经理负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。

职责：

1. 负责对重大、紧急事件的解决协调资源，保证故障的最终排除；
2. 当事件优先级为紧急或者事件将超过规定的时限，负责按照升级方法对事件进行处理确保有效协调资源，促进各类角色小组（如一线支持、二线支持）快速恢复正常服务；
3. 确保和问题管理流程经理的有效合作；
4. 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题。

技能要求：

1. 了解技术架构和技术环境；
2. 较强的口头表达能力和与用户沟通技巧；
3. 处理纠纷的能力；
4. 深刻了解事件管理流程；
5. 较强的领导能力。

人员按排建议：

- 由分公司及总公司主管应用系统维护工作的领导担任

##

## 4.6 事件管理流程负责人

事件管理流程负责人从宏观上监控流程，确保事件流程在信息技术中心范围内被正确的执行。当流程不能够适应cl发展需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。

职责：

1. 确定管理流程的衡量指标
2. 确保事件流程能够取得管理层的参与和支持
3. 确保事件流程符合cl实际状况和公司 IT发展战略
4. 总体上管理和监控流程，建立事件流程实施、评估和持续优化机制
5. 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进(假如增加或合并流程的角色)，从而实现可持续提高

技能要求：

1. 深刻理解事件管理流程；
2. 能够很好地理解业务对于事件管理的需求；
3. 有决策权，能够确保事件管理流程设计要求在实施项目中得到贯彻和执行；
4. 具有很好的沟通技能，获得所需资源。

人员按排建议：

- 由总公司IT部门领导担任

##

## 4.7 实际岗位与方案角色的映射

事件管理流程
角色 | 角色细分 | 说明 | 成员
服务台 | 总公司服务台 |  | 职责：负责受理办公管理、管理决策、核心运营、销售客服、桌面支持五大类事件。 建议总公司服务台设置3人 |
分公司服务台 |  | 职责：负责受理各类事件。 岗位建议：建议各分公司服务台设置2-3人，结合分公司实际情况，若事件单日常数量较多，服务台人数可以进行增加，建议对应岗位包括服务支持管理岗、应用管理岗、数据管理岗 |
一线支持 | 总公司一线支持 | 基础设施维护支持组 | 职责：负责总公司小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件的基础维护工作 岗位建议：建议由总公司运行管理处、网络管理处负责各基础设施领域维护工作的技术人员担任 |
应用系统支持组 | 职责：负责总公司各类应用系统的维护支持工作 岗位建议：建议由负责各类应用系统维护工作的技术人员担任 |
桌面支持组 | 职责：负责总公司桌面支持工作 岗位建议：建议由代理服务处负责桌面维护工作的技术人员担任 |
分公司一线支持 （地市公司直接纳入分公司一线支持） | 应用系统支持组 | 职责：负责分公司自有应用系统的支持工作以及对总公司应用系统的初始支持工作 岗位建议：建议由分公司负责各类应用系统维护工作的技术人员担任，建议对应岗位包括应用管理岗、地市分公司应用管理岗、数据管理岗、应用开发岗 |
基础设施维护支持组 | 职责：负责分公司小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件的基础维护工作 岗位建议：建议由分公司信息技术部门各基础设施领域维护工作的技术人员担任，建议对应岗位包括设备管理岗、系统管理岗、安全岗、网络管理岗、运行维护岗、地市分公司设备管理岗 |
桌面支持组 | 职责：负责分公司桌面维护支持工作 岗位建议：由负责分公司桌面维护支持工作人员的担任，建议对应岗位包括服务支持管理岗 |
二线支持 | 总公司二线支持 | 应用系统运维专家组 | 职责：负责总公司应用系统包括核心应用系统及非核心应用系统的维护工作 岗位建议：由负责总公司各类应用系统资深技术人员担任，可以借调分公司相关人员，形成虚拟团队 |
基础设施维护专家组 | 职责：负责分公司小型机、PC服务器、存储设备、网络交换机、路由器、防火墙、网络链路等系统硬件及操作系统、中间件、数据库等系统软件的维护工作 岗位建议：由总公司运行管理处、网络管理处负责各领域维护工作的资深技术人员担任，可以借调分公司相关人员，形成虚拟团队 |
三线支持 | 总公司三线支持 | 应用系统开发组 | 职责：负责总公司应用系统包括核心应用系统及非核心应用系统的开发、修改、优化工作 岗位建议：由总公司核心运营开发处、销售客服开发处、管理决策开发处、电子商务开发处开发人员担任，可以借调分公司相关开发人员，形成虚拟团队 |
代维厂商组 | 总公司的厂家支持，可以细分为IBM、HP等 |
事件经理 | 总公司 |  | 职责：负责督导与监控总公司事件处理过程的正常运转，接收事件的升级通知和处理超时通知等 岗位建议：建议在总公司设置事件经理1人，由总公司应用管理处处长或副处长担任 |
分公司 |  | 职责：负责督导与监控分公司事件处理过程的正常运转，接收事件的升级通知和处理超时通知等 岗位建议：建议在各分公司设置事件经理1人，由分公司分管应用维护的领导担任 |
事件管理流程负责人 |  | 职责：负责确定管理流程的衡量指标，从宏观上监控流程，当流程不能够适应cl发展需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高 岗位建议：建议在总公司设置事件管理流程负责人1名，由总公司信息技术部相关领导担任 |

说明：一、二、三线分组可进行扩充，各分公司可将现有分组提交到总公司，由总公司统一协调配置

#

#

# 5. 流程执行原则

## 5.1 常规原则

1. 所有IT和信息技术中心事件管理范围内发生的事件，都应该记录在IT服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件
2. 所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别
3. 应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估
4. 应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程

##

## 5.2流程关联原则

- 和问题管理的关联
  - 所有优先级为紧急的事件在恢复服务后，都应该创建问题单（问题单必须和事件单建立关联）
  - 支持人员在解决事件的过程中，可以通过问题记录查找相应的解决方案
- 和变更管理的关联
  - 事件处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和事件单建立关联），变更完成后，继续事件单的处理
  - 紧急事件（优先级为紧急的事件，下同）的处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和紧急事件单建立关联
- 和配置管理的关联
  - 事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位
  - 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联

##

## 5.3 所有权原则

所有权原则用来确保每个事件在任何时段都有适当的人员负责，服务台是事件的负责人。

- 由IT用户申报的事件单，服务台员工是该事件的责任人，必须确保事件得到有效跟踪与解决，并负责事件单的关闭

##

## 5.4 再分派原则

事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分配到个人，或者分配到组（服务台、一线支持、二线支持、三线支持），再由组内的支持人员处理。事件单的重分派次数不应该超过5次。

- 服务台将事件单分配给一线支持
- 一线支持可以将事件单重新分配给服务台，其他一线支持组（人员），二线支持组（人员）
- 二线支持可以将事件单重新分配给服务台，一线支持组（人员），其他二线支持组（人员），三线支持组（人员）
- 三线支持可以将事件单重新分配给服务台，二线支持组（人员），其他三线支持组（人员）

##

## 5.5 重复事件原则

重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。

- 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标
- 如果服务台可以判断到重复事件，则由服务台对重复事件标识，否则由一线支持人员负责重复事件的处理

##

## 5.6 关闭原则

由IT用户申报的事件单，关闭必须由服务台完成。

- 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时，结束代码为"变通方法解决"。服务台负责和IT用户再次确认事件的解决
- 由IT用户认可获得关闭的事件单的结束代码为"成功解决"关闭
- 已解决的事件单如果没有得到IT用户的认可，则首先关闭该事件单，结束代码修改为"不成功"，同时创建一个新的事件单重新分配到原处理人员继续处理
- 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单
- IT和信息技术中心的维护人员（一线、二线或三线）自行创建的事件单，本着"谁开单，谁负责关闭"的原则
- 监控平台产生的事件发送到服务台，由服务台分派，处理人员解决并关单

##

## 5.7 升级原则

制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。

- 优先级为紧急的事件，服务台应立即升级到相应一线支持，由一线支持再次确认，如果确认了优先级为紧急，则立即升级到事件经理，并通知相应的管理层（通过IT服务管理平台），由事件经理启动紧急事件处理流程
- 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理
- 服务台和一线支持应及时将不能解决的事件升级到下一级，若未及时升级，事件经理应及时介入，负责协调升级处理

##

## 5.8 人员岗位与角色落实原则

- 分公司技术力量较强的一线各维护支持组根据实际情况可按能力划分初级维护支持组和高级维护支持组，也可划分为一个组
- 如分公司具有开发人员，可将开发人员纳入到一线应用维护组
- 地市支持力量薄弱的，可将地市人员按岗位技能纳入省级公司相应支持组
- 地市支持力量较强的，可建立相对独立的支持维护组
- 目前流程中的各角色的分组可以进行扩充，由于此项目是全国性项目，在收集各分公司反馈后，由总公司进行统一协调配置

##

## 5.9 工单流转原则

- 分公司事件管理流程负责处理分公司自有应用系统及基础设施产生的事件以及对总公司应用系统及基础设施产生的事件进行尝试解决
- 总公司事件管理流程负责处理总公司应用系统及基础设施产生的事件
- 分公司服务台负责受理分公司服务对象提交的所有请求，分公司服务台首先对用户提交的请求进行尝试解决，不能解决的通过服务目录自动提交到分公司一线相应支持组或人
- 总公司服务台负责受理总公司及成员公司提交的所有请求，总公司服务台首先对用户提交的请求进行尝试解决，不能解决的通过服务目录自动提交到总公司一线相应支持组或人
- 分公司一线负责处理分公司服务台转派的工单，对于属于分公司自有应用系统及基础设施产生的事件在一线内部处理解决，不能解决的将工单提交到分公司事件经理，由分公司事件经理协调资源处理；对于属于总公司应用系统及基础设施产生的事件首先在分公司一线内部尝试解决，不能解决的提交到二线相应支持组
- 总公司一线负责处理总公司服务台转派的工单，首先在一线内部尝试解决，不能解决的提交到二线相应专家组
- 二线负责处理分公司一线及总公司一线转派的工单，首先在二线内部尝试解决，不能解决的提交到三线相应支持组
- 三线负责处理二线转派的工单，首先在三线内部尝试解决，对于三线不能解决的将工单提交到总公司事件经理，由总公司事件经理协调资源进行处理
- 对于公司信息技术部内部人员创建的工单，根据服务目录直接转派给本公司一线相应支持组组长，由组长视情况手工分派给本组人员进行处理
- 对于公司信息技术部内容人员创建的工单，关闭原则是‘谁创建工单，谁关闭工单’

#

#

# 6. 流程相关定义

## 6.1 事件信息项

事件单必须包含如下事件信息项：

序号 | 信息项 | 是否必填 | 说明
事件记录和分类时填写：
1 | 请求人信息 | 是 | 事件申报人的信息，包括：登录名、姓名、分公司、部门、电子邮件、办公电话、手机（手工填写）
2 | 事件分类 | 是 | 参见“事件分类”定义
3 | 事件性质 | 是 | 参见“事件性质”定义
4 | 事件来源 | 是 | 参见“事件来源”定义
5 | 事件所属系统类型 | 是 | 参见“事件所属系统类型”定义
6 | 事件发生时间 | 是 | 针对故障：指的是业务中断的实际时间 （可能早于登记时间，需要手工填写） 针对其他：缺省值等于登记时间 事件发生时间必须小于或等于登记时间
7 | 事件发生单位 | 是 | 树形目录（三级，总公司－省公司－地市）
8 | 事件发生地点 | 否 | 事件发生的地点 （手工填写）描述性字段，不做为日后数据索引、统计，默认为事件发生单位
9 | 事件简要简述 | 是 | 事件的简要描述（手工填写）
10 | 事件详细描述 | 是 | 对于整个事件内容的详细描述（手工填写）
11 | 分配对象 | 是 | 被分配的技术支持组（按服务目录自动分派）
12 | 事件优先级 | 是 | 参见“事件优先级”定义
13 | 事件影响度 | 是 | 参见“事件影响度”定义
14 | 重复事件标记 | 否 | 标记为重复事件（手工填写）
15 | 关联配置项 | 否 | 记录出现故障的配置项代码（系统自动关联）
16 | 附件 | 否 | 上传附件
提交事件工单时，系统自动产生
17 | 事件ID | 是 | 事件单流水号（系统自动产生）
18 | 建单人（受理人） | 是 | 创建事件请求工单的记录人
19 | 登记时间 | 是 | 在服务台生成事件记录的时间（系统自动产生）
20 | 事件状态 | 是 | 参见“事件状态”定义
21 | 事件完成期限 | 是 | 对应每一个事件优先级，系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限 （系统自动产生）
同14 | 关联配置项 | 否 | 记录出现故障的配置项代码（手工填写）
同15 | 附件 | 否 | 上传附件
一、二、三线尝试解决时填写：
22 | 业务恢复时间 | 是 | 针对故障的业务恢复实际时间（手工填写）
23 | 事件日志 | 是 | 反映事件信息项的变化历史，如一个事件在处理过程中事件状态变化的时间点等信息（系统自动产生）
24 | 解决方案 | 是 | 事件解决方案的描述（手工填写）
25 | 故障厂商 | 是 | 记录故障厂商或集成商信息（手工选择）
26 | 重复事件标记 | 否 | 标记为重复事件（手工选择）
一、二、三线尝试解决时，系统自动产生
同19 | 事件状态 | 是 | 参见“事件状态”定义
27 | 实际开始时间 | 是 | 记录事件状态到XX处理中的时间（系统自动产生）
28 | 事件解决人 | 是 | 事件的最终解决人（系统填写）
29 | 处理是否超时 | 否 | 参见“处理是否超时”定义（系统自动产生）
30 | 实际完成时间 | 是 | 记录事件最后解决的时间（系统自动产生）
31 | 历时 | 是 | “实际完成时间”-“事件发生时间”（系统自动产生）
关闭工单时填写
32 | 用户反馈 | 是 | 参见“用户反馈”定义
33 | 事件结束代码 | 是 | 参见“事件结束代码”定义
34 | 事件解决人角色 | 是 | 参见“事件解决人角色”定义
35 | 事件关闭时间 | 是 | 记录事件被关闭的事件

##

## 6.2 事件性质

根据clIT支撑系统的业务要求和管理要求，定义如下四类事件：

编号 | 代码 | 描述
1 | 故障 | 指因IT支撑系统错误或反映支撑系统部分或全部功能不能正常使用的报障；
2 | 申告 | 与IT支撑系统相关的用户投诉，如信息技术部各处室等业务受理部门转来的因支撑系统问题引发的投诉
3 | 告警 | 监控平台自动产生的没有影响到系统正常使用的告警
4 | 咨询 | 指对系统操作、业务流程等方面的求助和询问

##

## 6.3 事件来源（非必填项）

事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种：

编号 | 代码 | 描述
1 | 用户报告 | 用户或维护人员通过电话/邮件/传真报告的事件，服务台人员手工创建事件单
2 | 内部IT人员开单 | IT部门内部（一线/二线人员）提交的事件
3 | 监控系统 |

##

## 6.4 事件所属系统类型

根据目前信息技术中心支撑的应用系统和二级分类的划分定义事件所属系统类型，当事件发生时，应该由服务台初步定位是哪个系统及二级分类出现问题，由一线进行进一步的明确。

业务系统分类 | 子业务系统分类 | 简称
办公管理 | IT服务管理系统 | ITSM
综合办公系统 |
电子邮件系统 | 请填写简称
电子商务 | 网上招聘系统 | CORS
管理决策 | 团体年金报表子系统 | GARS
财务计算机管理系统 | CLAF
集团财务计算机管理系统 | GCLAF
cl财务报表辅助系统 | EASY-REPORT
大中城市业绩考核分析系统 | CSIS
财务分析系统 | LIFA
基础率分析系统 | EAS
精算系统 | ATMS
每日业务快报系统 | ZHCX
统计信息系统 | TJXX
审计系统 | AMS
核心运营 | 综合业务处理系统7版 | CBPS7
集团综合业务处理系统7版 | NBPS
老业务处理系统 | OBPS
综合业务处理系统8版 | CBPS8
出单管理系统(七版) | Printpro
档案影像管理系统 | CIMS
单证管理系统 | CVMS
打印管理系统 | CPMS
数据清理系统 | CLEANER
投连万能处理系统 | UBPS
团体年金核心业务处理系统 | GAPS
中介业务处理系统 | ABPS
统括业务处理系统 | UNITE
再保险系统 | RBPS
健康意外险系统 | HDPS
互联网销售系统 | ISS
销售客服 | 团体年金大客户支持子系统 | GACS
团体年金报价子系统 | GAPS
团体年金销售支持系统 | GA3S
个人代理人管理信息系统 | AMIS
讲师管理系统 | TMIS
会员管理系统2005 | MMIS
个人代理人营销支持系统 | E-MSS
大客户支持系统 | anntsuport
网络查询系统 | netquery
cl呼叫中心系统 | CALL CENTER
cl短信系统 | SMS
其他 | 其他系统类 | OTS

说明：第一层为”其它”的话，分公司可以对其子类可以扩充并提交到总公司，由总公司统一协调配置

##

## 6.5 事件分类

分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。

事件的分类层次设计不超过三层，第一级分类，称之为"一级分类"，第二级分类，称之为"二级分类"，第三级分类，称之为"三级分类"。

一级分类 | 二级分类 | 三级分类
服务器SR | 小型机（EPS） |
PC 服务器（SPC） |
存储设备 RD | 磁盘阵列（RAD） |
磁带库（TAP） |
其他存储设备（OTR） |
网络NW | 交换机（SWT） | 网络交换机（SWT）
光纤交换机（FST）
路由器（RUT） |
防火墙（FRW） |
VPN网关（VPG） |
安全网关（SEG） |
链路（LNK） |
其他网络设备（OTN） |
终端TR | 台式机（COM） |
笔记本（NTB） |
字符终端（CTR） |
图形终端（GTR） |
外设及其他PR | 外设（DDV） | 打印机（PRT）
扫描仪（SCN）
绘图仪（DRW）
其他（SSO）
机房（DCE） | 监控系统（）
消防系统
其他（OTR） |
软件SW | 应用软件APP | 自主开发（SDV）
外包开发（ODV）
商业软件（FRD）
系统软件SYS | 数据库（SDB）
操作系统（OPS）
中间件（SMD）
其他（SYO）
文档DC | 管理文档（ADC） |
技术文档（TDC） |
维护文档（ODC） |
工程文档（PDC） |
合同CRT | 产品购买合同（PUS）
维护合同（MAN）
应用系统AP | 应用系统名称（API） |
应用系统模块（APM） |
其他应用（APO） |

##

## 6.6 事件优先级

优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级（紧急、高、中、低）。

编号 | 优先级代码 | 描述
1 | 紧急 | 重要系统不可用 因系统原因数据处理错误，导致大量用户投诉 来自新闻媒体、消费者协会、国家行政机关（工商、物价等）的反映或申告 部分重要数据丢失，且无法全部恢复
2 | 高 | 业务系统不可用，影响面为全北京市、某个分公司，或者多个非关键地区 系统中的某一业务不可用，影响面为全北京市、某个分公司，或者多个非关键地区
3 | 中 | 一般性系统故障
4 | 低 | 一般单个用户申告 业务咨询

当故障发生时，为了在判断优先级时增强实际可操作性，可以根据故障的影响范围和业务系统的关键程度在优先级映射表中定位优先级。故障的影响范围可以根据配置项中定义的“影响范围”和用户报障描述来确定。

系统 影响范围 | 全北京市或某一分公司 | 至少包括一个关键地区 | 多个非关键地区 | 一个非关键地区
系统名称（任一模块） | 功能点A | 紧急 | 紧急 | 高 | 高
功能点B | 高 | 高 |  |
功能点C | 高 | 高 |  |

##

## 6.7 事件响应时限和解决时限

在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制，一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念，同时，也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理，同时，如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。

响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间；

解决时限指的是事件状态从“已登记”到“已解决”经过的时间；

事件优先级对应的事件响应时限和解决时限参考下表（以下时间是24×7工作时间）：

编号 | 优先级代码 | 响应时限要求 | 解决时限要求
1 | 紧急 | 30分钟 | 4小时
2 | 高 | 1小时 | 8小时
3 | 中 | 4小时 | 48小时
4 | 低 | 8小时 | 72小时

事件发生时的通告定义

通知人员列表的用途：当IT服务管理平台收到事件时，自动按照表中的人员列表发出邮件或短信通知。

优先级别 | 通知人员列表
紧急 | 部门主管，相应事件经理，一、二、三线支持人员
高 | 部门主管，相应事件经理，一、二线支持人员
中 | 通知一、二线支持人员
低 | 通知一线支持人员

超出响应时间的通告定义

通知人员列表的用途：当IT服务管理平台判断到响应时限已经超出，则自动按照表中的人员列表发出邮件或短信通知。

优先级别 | 通知人员列表 | 事件响应时限
紧急 | 部门主管，相应事件经理，一、二、三线支持人员 | 30分钟
高 | 部门主管，相应事件经理，一、二线支持人员 | 1小时
中 | 部门主管，相应事件经理，一、二线支持人员 | 4小时
低 | 相应事件经理，服务台/一、二线支持人员 | 8小时

超出和即将超出解决时限的通告定义

通知人员列表的用途：当IT服务管理平台判断到解决时限已经或即将超出，则自动按照表中的人员列表发出邮件或短信通知。

优先级别 | 通知时间 | 通知人员列表 | 事件解决时限
紧急 | 3小时 | 部门主管，相应事件经理，一、二、三线支持人员 | 4小时
4小时 | 部门主管，相应事件经理，一、二线支持人员
高 | 7小时 | 部门主管，相应事件经理，一、二线支持人员 | 8小时
8小时 | 部门主管，相应事件经理，一、二线支持人员
中 | 47小时 | 部门主管，相应事件经理，一、二线支持人员 | 48小时
48小时 | 部门主管，相应事件经理，一、二线支持人员
低 | 71小时 | 相应事件经理，一、二线支持人员 | 72小时
72小时 | 相应事件经理，一、二线支持人员

##

## 6.8 事件影响度

事件影响度用于衡量事件所影响业务的严重程度。严重程度通常通过事件所影响的人数、关键系统数以及服务故障所造成的损失来设定。

定义事件影响度等级的因素有：

- 是否影响了核心业务
- 所影响的用户数
- 服务失效的影响范围和时长

事件影响度在事件的生命周期中是可以改变的，例如，初始等级为严重的故障会随着服务失效的时间变成重大故障，所以事件的影响度应在事件得到解决（服务恢复）后重新确认。

事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。

编号 | 影响度代码 | 事件性质 | 描述
1 | 重大 | 故障 | 全国半数以上地区或关键地区的业务系统中断超过6小时； 全国半数以上地区或关键地区的营业、综合帐务、客服中任一业务中断超过3小时； 全国半数以上地区或关键地区的综合结算业务处理中断超过24小时； 半数以下地区全业务中断超过6小时；
申告 | 对人寿公司造成巨大损失产生严重后果和不良影响的； 来自新闻媒体、消费者协会、国家行政机关的反映或申告；
2 | 严重 | 故障 | 全国半数以上地区或关键地区的业务系统中断大于10分钟、小于6小时； 全国半数以上地区或关键地区的营业、综合帐务、客服等业务中断均大于10分钟、小于3小时； 全国半数以上地区或关键地区的综合结算业务处理中断大于2小时、小于24小时； 半数以下地区全业务中断大于10分钟、小于6小时。
申告 | 数据错误导致产生大量的错单； 涉及到高额问题的申告； 用户在营业现场反映激烈
3 | 一般 | 故障 | 系统内局部出现问题，不影响整个系统运行，不影响业务处理的故障
申告 | 不属于重大申告和严重申告的用户申述
告警 | 不影响系统的监控平台告警
4 | 无 | 咨询 | 一般数据查询或者使用指导

##

## 6.9 事件状态

事件状态代码表明事件所处的处理状态，事件状态如下：

编号 | 代码 | 描述
1 | 已登记 | 新开事件记录或事件已创建
2 | 分配到服务台 | 事件已分配给服务台人员
3 | 服务台处理中 | 服务台人员已接手处理事件
4 | 分配到一线 | 事件已分配到一线支持，一线还未响应
5 | 一线处理中 | 一线支持人员已接手处理事件
6 | 分配到二线 | 事件已分配到二线支持，二线还未响应
7 | 二线处理中 | 二线支持人员已接手处理事件
8 | 分配到三线 | 事件已分配到三线支持，三线还未响应
9 | 三线处理中 | 三线支持人员已接手处理事件
10 | 已解决 | 事件已解决，支持人员联系用户验证事件是否获得解决
11 | 关闭 | 事件已关闭

事件状态变迁图用来标明：当一个事件单处于某个状态时，它可以去到的下一个状态。

​

- 当前状态为‘已登记’状态时，可迁移的状态

状态 | 合法 | 描述
已登记 | 否 | 已登记为事件单初始状态
分配到服务台 | 是 | 用户提交事件请求，首先分派到服务台
服务台处理中 | 否 |
分配到一线 | 否 |
一线处理中 | 否 |
分配到二线 | 否 |
二线处理中 | 否 |
分配到三线 | 否 |
三线处理中 | 否 |
已解决 | 否 |
已关闭 | 否 |

- 当前状态为‘分配到服务台’状态时，可迁移的状态

状态 | 合法 | 描述
已登记 | 否 |
分配到服务台 | 是 | 服务台的人员将分配给本人的事件单分配给服务台或者服务台的其他人员
服务台处理中 | 是 | 服务台人员开始尝试处理事件单
分配到一线 | 是 | 服务台组人员将事件单分配给一线支持组
一线处理中 | 否 |
分配到二线 | 否 |
二线处理中 | 否 |
分配到三线 | 否 |
三线处理中 | 否 |
已解决 | 否 |
已关闭 | 是 | 当事件处理范围不在信息技术中心或误报或可忽略时，可直接关闭

- 当前状态为‘分配到一线’状态时，可迁移的状态

状态 | 合法 | 描述
已登记 | 否 |
分配到服务台 | 否 |
服务台处理中 | 否 |
分配到一线 | 是 | 一线支持人员将分配给本人的事件单分配给一线支持组或组内的其他人
一线处理中 | 是 | 一线支持人员，接受分配的事件单，并开始处理
分配到二线 | 否 |
二线处理中 | 否 |
分配到三线 | 否 |
三线处理中 | 否 |
已解决 | 否 |
已关闭 | 否 |

- 当前状态为“一线处理中”状态时，可迁移的状态

状态 | 合法 | 描述
已登记 | 否 |
分配到服务台 | 否 |
服务台处理中 | 否 |
分配到一线 | 是 | 一线支持人员将分配给本人的事件单分配给一线支持组或组内的其他人
一线处理中 | 否 |
分配到二线 | 是 | 一线支持人员将事件单分配给二线支持组或二线支持组内的其他人
二线处理中 | 否 |
分配到三线 | 否 |
三线处理中 | 否 |
已解决 | 是 | 一线支持找到解决方案或者变通方法，解决了分配的事件单
已关闭 | 否 |

- 当前状态为‘分配到二线’状态时，可迁移的状态

状态 | 合法 | 描述
已登记 | 否 |
分配到服务台 | 否 |
服务台处理中 | 否 |
分配到一线 | 否 |
一线处理中 | 否 |
分配到二线 | 是 | 二线支持人员将事件单分配给二线支持组或二线支持组内的其他人
二线处理中 | 是 | 二线支持人员，接受分配的事件单，并开始处理
分配到三线 | 否 |
三线处理中 | 否 |
已解决 | 否 |
已关闭 | 否 |

- 当前状态为‘二线处理中’状态时，可迁移的状态

状态 | 合法 | 描述
已登记 | 否 |
分配到服务台 | 是 |
服务台处理中 | 否 |
分配到一线 | 否 |
一线处理中 | 否 |
分配到二线 | 是 | 二线支持人员无法处理该事件单，或者分配错误，将事件单重新分配给二线支持组或二线支持组内其他人员
二线处理中 | 否 |
分配到三线 | 是 | 二线支持人员将事件单分配给三线支持组或三线支持组内的其他人
三线处理中 | 否 |
已解决 | 是 | 二线支持找到解决方案或者变通方法，解决了分配的事件单
已关闭 | 否 |

- 当前状态为‘分配到三线’状态时，可迁移的状态

状态 | 合法 | 描述
已登记 | 否 |
分配到服务台 | 否 |
服务台处理中 | 否 |
分配到一线 | 否 |
一线处理中 | 否 |
分配到二线 | 否 |
二线处理中 | 否 |
分配到三线 | 是 | 三线支持人员将事件单分配给三线支持组或三线支持组内的其他人
三线处理中 | 是 | 三线支持人员，接受分配的事件单，并开始处理
已解决 | 否 |
已关闭 | 否 |

- 当前状态为‘三线处理中’状态时，可迁移的状态

状态 | 合法 | 描述
已登记 | 否 |
分配到服务台 | 否 |
服务台处理中 | 否 |
分配到一线 | 否 |
一线处理中 | 否 |
分配到二线 | 是 |
二线处理中 | 否 |
分配到三线 | 是 | 三线支持人员将事件单分配给三线支持组或三线支持组内的其他人
三线处理中 | 否 |
已解决 | 是 | 三线支持找到解决方案或者变通方法，解决了分配的事件单
已关闭 | 否 |

- 当前状态为‘已解决’状态时，可迁移的状态

状态 | 合法 | 描述
已登记 | 否 |
分配到服务台 | 否 |
服务台处理中 | 否 |
分配到一线 | 否 |
一线处理中 | 否 |
分配到二线 | 否 |
二线处理中 | 否 |
分配到三线 | 否 |
三线处理中 | 否 |
已解决 | 否 |
已关闭 | 是 | 服务台在关闭事件单的时候，需要填写客户反馈和结束代码

- 当前状态为‘已关闭’状态时，可迁移的状态

不迁移至任何状态。

##

## 6.10 事件结束代码

事件结束代码说明了事件是在何种情况下关闭的，结束代码如下：

编号 | 代码 | 描述
1 | 成功解决 | 事件获得成功解决
2 | 变通方法解决 | 事件已通过变通方法或者临时措施获得解决，但是需要进行更进一步的根源分析
3 | 不成功 | 事件没有获得解决（用户没有认可解决时使用）
4 | 消失 | 事件自行消失
5 | 误报 | 不属于IT部门管理范围的事件
6 | 可忽略 | 如通过其他系统接口或监控系统提交的信息，经确认属于无效信息

##

## 6.11 事件解决人角色

事件解决人角色用来标明该事件单最终解决的角色是服务台还是一线、二线、三线。

编号 | 代码 | 描述
1 | 服务台 | 服务台最终解决事件
2 | 一线 | 一线支持最终解决事件
3 | 二线 | 二线支持最终解决事件
４ | 三线 | 三线支持最终解决事件
５ | 其他 | 自动消失的事件等

##

## 6.12 处理是否超时

每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超过了解决期限。

编号 | 代码 | 描述
1 | 未超时 | 未超时
2 | 超时 | 事件已超出规定的解决时限

##

## 6.13 故障厂商

用来在事件单中记录是哪个厂商的设备或系统发生故障。

编号 | 厂商名称
1 | 3COM
2 | AVAYA
3 | BEA
4 | BMC
5 | Borland
6 | CA
7 | Cisco
8 | EMC
9 | HDS
10 | HP
11 | IBM
12 | McDATA
13 | Microsoft
14 | NCR
15 | NETAPP
16 | Oracle
17 | Quantum ATL
18 | STK
19 | SUN
20 | Sybase
21 | TERADATA
22 | 北电
23 | 东方通
24 | 中兴
25 | 华为
26 | SYMANTEC
27 | QUEST
28 | REDHAT
29 | BROCADE
30 | 锐捷
31 | 迈普
32 | 联想
33 | 网神
34 | 天融信

##

## 6.14 用户反馈

用来在事件单中记录用户对事件处理的满意程度。

编号 | 代码 | 描述
1 | 满意 | 用户对事件处理结果表示满意
2 | 一般 | 用户对事件处理结果既非满意也非不满意，处于中间感受
3 | 不满意 | 用户对事件处理结果表示不满意

#

#

# 7. 流程概要设计

事件管理概要设计流程图如下：

流程描述如下：

序号 | 步骤名称 | 责任人 | 说明
100.1 | 事件记录和分类 | 服务台 | 服务台对来自本部门服务范围内的用户和系统自动产生的事件进行详细记录，其中包括申告/咨询/告警/故障 服务台负责在接收到事件后进行分类转发 对于初步判断为紧急的事件马上升级到本公司一线人员处理
100.2 | 初始支持 | 服务台 | 属于服务台技能范围内可以处理的事件，服务台应尝试解决，如果无法解决需及时升级到本部门一线支持 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案 不属于服务台职责范围的事件，立即分派到相应的本部门一线支持
100.3 | 一线尝试解决 | 一线支持 | 一线支持人员在接受到由本公司服务台派发的事件后，进行调查诊断，尝试解决 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案 对于需要通过问题解决的事件提出问题申请，通过问题流程实施解决方案 事件解决后，在事件管理平台记录事件解决方案并更新事件状态 不能解决的事件，转100.4二线尝试解决
100.4 | 二线尝试解决 | 二线支持 | 二线支持人员接受到来自总公司或各分公司一线支持的事件后，进行调查诊断，尝试解决方案，在必要时根据服务协议联系厂商帮助解决并负责核查 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案 对于需要通过问题解决的事件提出问题申请，通过问题流程实施解决方案 事件解决后，在事件管理平台记录事件解决方案并更新事件状态 不能解决的事件，转100.6三线尝试解决
100.5 | 紧急事件再确认 | 一线支持 | 一线支持人员接受到来自本部门服务台的紧急事件后，根据事件优先级别标准再次确认事件是否为紧急事件 如果优先级确实紧急，则通知相应的管理层，并立即升级到事件经理，转101紧急事件处理子流程 如不是，转100.3一线尝试解决，开始正常事件解决流程
100.6 | 三线尝试解决 | 三线支持 | 三线支持人员接受来自总公司二线支持派发的事件后，根据实际情况，尝试找出并实施解决方案，在必要时根据服务协议联系厂商帮助解决并负责核查 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案 对于需要通过问题解决的事件提出问题申请，通过问题流程实施解决方案 事件解决后，在事件管理平台记录事件解决方案并更新事件状态 指定时限内未能解决的事件，通告事件经理，由事件经理负责协调资源
100.7 | 记录解决方案细节 | 服务台 一、二、三线支持 | 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息 针对故障，一、二、三线支持必须记录业务恢复时间
100.8 | 关闭事件 | 服务台 | 服务台与申报用户确认事件是否已得到解决，如果解决，事件以成功解决或变通方法解决而关闭；否则，事件以不成功关闭，重新开事件记录，并与原记录做关联，分派到原处理人员继续处理 服务台在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确
100.9 | 事件处理的监控 | 事件经理 | 负责监控所有未关闭的事件的处理状况，对接收到的超时告警应及时关注，并负责协调资源，保证事件的最终解决 当事件优先级为紧急时，应按照紧急事件处理流程处理紧急事件
101 | 紧急事件处理流程 | 事件经理 | 事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程

# 8. 流程详细设计

## 8.1 （100.1）事件记录和分类

流程描述如下：

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
100.1.1 | 从任务队列中接受事件 | 服务台 | 事件队列 | 需要处理的事件 | 事件任务队列的来源： 监控系统自动发送的告警 业务部门通过其他接口转发的事件单 IT用户通过服务台自助系统提交的事件单 服务台负责检查事件任务队列中的新事件单，开始处理
| 是否为本部门职责范围？ | 服务台 | 事件单 |  | 服务台判断是否属于本部门职责范围： 是，进行事件分类的处理； 否，转100.1.3回复和关闭
100.1.2 | 新建事件 | 服务台 | 电话/OA/传真 | 新建的事件记录 | 属于本中心（科室）职责范围，服务台负责创建新的事件单，填写详细情况描述，不属于本部门处理的，直接电话回复。 事件单填写的详细内容如下： 报告人姓名、联系电话、邮件、分公司、部门 事件标题和描述 必要的附件 事件发生时间和地点 事件来源和事件性质 进行事件分类 设定事件状态为“新建”
100.1.3 | 回复和关闭 | 服务台 | 误报的事件单 | 关闭的事件单 | 联系申报用户，说明情况，将该事件单状态置为“关闭”，结束代码为“误报”，保存关闭
| 是否为重复事件？ | 服务台 | 事件记录 | 相应的处理流程 | 服务台根据重复事件原则，判断该事件单是否属于重复事件： 是，转100.1.4重复事件处理； 否，事件分类的判断
100.1.4 | 重复事件处理 | 服务台 | 重复事件 |  | 在重复事件单的“重复事件标记”中记录正在处理的事件单的流水号，状态置为“XX处理中”，保存退出。
| 事件性质区分？ | 服务台 | 事件性质 | 相应的处理流程 | 根据事件性质区分不同的处理流程： 告警/申告/咨询/故障，走100.1.5事件影响度、优先级设定
100.1.5 | 事件影响度、优先级设定 | 服务台 | 事件记录 | 确定了影响度和优先级的事件 | 根据上报的事件描述，判断对业务的影响程度，并对照优先级代码表，确定事件的优先级，以及初始确定的影响度
| 优先级为紧急吗？ | 服务台 | 事件优先级 | 相应的处理流程 | 服务台根据业务的影响程度和事件优先级判定的条件，初步判断优先级别： 优先级为紧急，转100.5紧急事件再确认； 其他优先级否，转100.2初始支持

##

## 8.2 （100.2）初始支持

流程描述如下：

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
| 服务台技能可以处理吗？ | 服务台 | 事件记录 | 处理方式 | 服务台根据事件分类和事件描述，判断处理职责是否在服务台： 是，转100.2.1尝试处理； 否，转100.2.2分配到一线支持
100.2.1 | 尝试处理 | 服务台 | 事件记录 |  | 服务台运用知识库和自身技能在规定的时限内尝试解决，将事件状态置为“分配到服务台”，如果不能处理应及时将事件单分配到一线支持
100.2.2 | 分配到一线支持 | 服务台 | 事件记录 | 分配到一线的事件单 | 选择本部门相关的一线处理组和处理人员分派，并将事件状态置为“分配到一线”
| 解决了吗？ | 服务台 |  |  | 将解决方案和用户沟通，判断是否可以解决； 可以解决，转100.7记录解决方案细节 无法解决，转100.2.2分配到一线支持
| 发起变更吗？ | 服务台 | 解决方案 | N/A | 服务台根据解决方案的内容和变更管理流程对变更范围的定义，判断是否需要发起变更？ 需要发起变更，创建变更请求，提交到变更管理流程，解决方案的实施由变更管理完成 不需要发起变更，转100.7

##

## 8.3 （100.3）一线尝试解决

流程描述如下：

## 8.4 （100.4）二线尝试解决

流程描述如下：

## 8.5（100.5）紧急事件再确认

流程描述如下：

## 8.6 （100.6）三线尝试解决

流程描述如下：

## 8.7（100.7）记录解决方案细节

流程描述如下：

## 8.8（100.8）关闭事件

##

流程描述如下：

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
| 监控系统自动告警？ | 服务台 | 事件记录 | 事件记录 | 服务台判断是否是监控系统自动产生的告警； 是，转100.8.1更新事件状态 否，转100.8.2与用户处确认事件解决
100.8.1 | 更新事件状态及结束代码，关闭事件 | 服务台 | 已解决的事件记录 | 关闭的事件 | 更新事件记录，状态为“已关闭”，结束代码根据实际处理结果或用户反馈填写； 如果该事件单有相关联的重复事件，应该将重复事件单一起关闭，重复事件的结束代码和该事件保持一致
100.8.2 | 与用户处确认事件解决 | 服务台 | 用户反馈 | 反馈结果 | 从事件请求人处确认所提供的解决方案是否有效
| 是否解决？ | 服务台 |  |  | 判断是否解决方案是否有效？ 是，转100.8.1 否，转100.8.3重开单处理
100.8.3 | 重开单处理 | 服务台 | 未解决的事件记录 | 新的事件记录 | 服务台将该事件单的的结束代码置为“不成功”，关闭保存； 创建一个新的事件单，事件信息可以复制，分配到原处理人员处理，新事件单状态“分配到一线” 注：服务台应该和原处理人员沟通事件的确认结果和后续的处理方式,并通过将事件单关联到新的事件单中
| 是服务台分派吗？ | 一、二、三线支持 |  |  | 如果是服务台分派的事件单，需要返回到服务台，否则直接到100.8.4
100.8.4 | 更新事件状态及结束代码，关闭事件 | 一、二、三线支持 | 已解决的事件记录 | 关闭的事件 | 更新事件记录，状态为“已关闭”，结束代码根据实际处理结果填写； 如果该事件单有相关联的重复事件，应该将重复事件单一起关闭，重复事件的结束代码和该事件保持一致

##

## 8.9（100.9）事件处理的监控

流程描述如下：

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
100.9.1 | 事件队列的监控 | 事件经理 | 当前打开的事件单服务台的超时告警 |  | 事件经理可以从以下途径获取事件处理的信息 服务台系统自动发送的告警通知 查询服务台系统的当前处理中的事件列表
| 需要介入吗？ | 事件经理 |  |  | 事件经理根据处理时限和该事件对业务的影响程度，判断是否需要及时介入，帮助协调资源解决 需要介入，转100.9.2 不需要，则继续监控
100.9.2 | 召集资源协商解决 | 事件经理 | 告警事件 支持人员的电话通知 | 解决方案 | 由于处理不及时而可能导致用户满意度下降的事件或疑难事件，事件经理负责召集相应二线专家，共同商讨并制定解决方案，并实施解决方案
| 可以解决吗？ | 事件经理 |  |  | 如果解决，转100.8关闭事件 无法解决，转100.9.3升级到管理层解决
100.9.3 | 升级到管理层解决 | 事件经理 | 升级的事件记录 | 解决方案 | 事件经理负责将升级事件通报到管理层，通过高层寻求更多的资源介入，共同商讨和制定解决方案

##

## 8.10（１０１）紧急事件处理子流程

制定各系统应急处理预案

为了确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障，各系统应该建立相应的应急处理预案，建议预案中的内容至少应涵盖以下方面：

1. 应急预案启动条件
2. 应急处理小组负责人和成员联系名单和联系方式
3. 应急处理步骤
4. 应急信息通报
5. 应急善后处理
6. 应急保障措施（人员、培训、演习、场地等）

紧急事件处理子流程说明如下：

序号 | 步骤名称 | 说明
101.1 | 召集应急小组，协调应急会议 | 事件经理主持应急会议，并组织讨论、协调各方资源，分析紧急事件处理方案，并将紧急事件情况通报分公司人寿IT信息中心相关领导或总公司
101.2 | 判断是否属于应急预案中的事件？ | 应急小组和相关厂商根据紧急事件现象和影响程度，判断是否需要启动相应系统的应急预案？ 如果没有应急预案，则进入101.4组织相关厂商共同分析紧急事件，制定处理方案并处理； 如果有应急预案，则进入101.3按照应急预案处理
101.3 | 按照应急预案处理 | 根据各系统制定的应急预案中的实施步骤，处理紧急事件
101.4 | 组织相关厂商共同分析，制定处理方案并处理 | 应急小组负责组织相关厂商共同分析紧急事件，制定相应的处理方案，如果需要总公司介入处理，则向总公司申请介入； 处理方案在实施前应得到应急小组和相关领导的认可； 事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求
101.5 | 紧急事件解除确认？ | 在紧急事件处理方案实施后，应急小组、相关厂商和相关部门对紧急事件是否解除进行确认 紧急事件如果没有解除，则重新进入101.4组织相关厂商共同分析紧急事件，制定处理方案并处理； 如果解除，则进入101.6紧急事件善后处理和总结分析
101.6 | 善后处理和通报客户方 | 紧急事件解除后，应急小组向申告方、公司相关领导简要报告紧急事件处理过程，解决方法，事件解除时间，业务恢复情况，并将该信息汇报到总公司 对于影响度为重大的紧急事件，必须通过服务台提交《重大事件报告》 紧急事件的处理人需要创建一个新问题，将紧急事件处理过程的详细信息记录到问题单中，提交到问题经理，由问题经理组织相关专家进行问题根源的分析

#

#

# 9. 流程样例

## 9.1 总公司内部

总部人员财务部门小王，财务分析系统在总部内部执行，财务小王电话总公司服务台人员财务分析系统无法使用，服务台人员记录事件信息，与小王沟通后确认是“管理决策－财务分析系统－报送问题”的问题，首先根据服务目录查询知识库，如果有匹配的解决方案，则按照解决方案处理，如果需要发起变更，则由服务台人员根据解决方案创建变更工单。如果未在知识库中查询到匹配的解决方案，则进行重复事件判断，如是重复事件，则关联重复事件工单号，并置事件状态“XX处理中”，保存退出，同时服务台人员告知小王可以查询XX工单号可以了解决事件处理进度。如果不是重复事件，则判断事件性质、优先级、影响度等，如果此事件为紧急事件则转派给一线支持进行再确认，如果不是紧急事件则进行尝试解决，并更新事件状态为“服务台处理中”，如果服务台人员解决了此事件，则更新工单信息，并与小王确认解决方案及满意度。如果经尝试未能解决则转派一线支持，系统自动将事件状态置为“分派到一线”
通过系统对服务目录判断将此工单分派给一线应用支持组中的财务支持小组组长，此时财务支持小组有四人，分别为A，B，C，D，财务支持小组组长根据实际情况手工将此工单派发给B，B接到服务台派发的关于财务分析系统的事件工单后，经判断属于本人处理范围之内，将事件状态置为“一线处理中”，对于服务台人员派发的事件进行优先级确认，此工单非紧急事件，根据服务目录查询知识库，未查到匹配的解决方案，且不是重复事件，B通过借助工具或运用自己技能尝试找出解决方案，如果未找到解决方案则点击按钮，系统会根据服务目录自动转派给二线支持人员。
通过系统对服务目录判断将此工单分派给二线应用支持组中的财务支持小组组长，此时财务支持小组有三人，分别为E,F,G，财务支持小组组长根据实际情况将此工单派发给G，G进行分析后手工选择分派对象为F将此工单派发给F，F对此工单做进一步分析，经分析后属于防火墙设置问题，将此工单分派给二线基础设施组中的防火墙小组。系统根据F填写的服务目录查找到二线基础设施组中的防火墙小组，目前此小组有三人，为H,I,J，防火墙小组组长根据实际情况将此工单派发给J，J进行分析确认，确是防火墙设置问题，需要修改防火墙设置，须走变更，J根据需要修改的防火墙设置创建变更工单，并关联此事件单，J将事件状态置为“已解决”并将工单转派给服务台人员，由服务台人员告知小王，此事件单正在变更流程中处理。

##

## 9.2 分公司内部

杭州市分公司柜面操作员小李，反映查询系统有问题，电话告知浙江省分公司服务台人员，分公司服务台人员记录事件信息，与小李沟通后确认是“分公司自有系统－浙江省－查询系统”的问题，首先根据服务目录查询知识库，如果有匹配的解决方案，则按照解决方案处理，如果需要发起变更，则由分公司服务台人员根据解决方案创建变更工单。如果未在知识库中查询到匹配的解决方案，则进行重复事件判断，如是重复事件，则关联重复事件工单号，并置事件状态“XX处理中”，保存退出，同时分公司服务台人员告知小李可以查询XX工单号可以了解决事件处理进度。如果不是重复事件，则判断事件性质、优先级、影响度等，如果此事件为紧急事件则转派给一线支持进行再确认，如果不是紧急事件则进行尝试解决，并更新事件状态为“服务台处理中”，如果服务台人员解决了此事件，则更新工单信息，并与小李确认解决方案及满意度。如果经尝试未能解决则转派一线支持，系统自动将事件状态置为“分派到一线”

通过系统对服务目录判断将此工单分派给分公司一线应用支持组中的查询支持小组组长，查询支持小组有两人，分别为A`，B`，查询支持小组组长根据实际情况将此工单派发给B`，B`经分析为数据库问题，填写分析过程后，将工单通过服务目录转派给分公司一线基础设施支持组中的数据库小组组长，此小组有三人，为C`,D`,E`，数据库小组组长根据实际情况将此工单派发给D`，D`进行分析判断后通过借助工具或运用自己技能尝试找出解决方案，D`将事件状态置为“已解决”并将工单转派给服务台人员，由分公司服务台人员与小李确认解决方案及满意度，并更新事件状态及事件结束代码。

##

## 9.3 紧急事件

山东省分公司信息技术部小张反映CBPS8版系统不可用，小张直接创建事件工单，根据经验技能判断现象分类为“核心运营－CBPS8版系统－宕库”，并确认此事件为紧急事件，通过服务目录自动将此工单分派给分公司一线应用支持组中的CBPS8版支持小组组长，小组有成员3人分别为F1,F2,F3，CBPS8版支持小组组长根据实际情况手工选择将此工单派发给F2，经F2再次确认此事件确实为紧急事件，同时系统通过邮件或短信方式自动通知分公司事件经理，经分析F2无法独立处理，由F2联系分公司事件经理G1，G1通过其他方式联系总公司负责业务应用的事件经理W3，同时F2点击按钮，系统通过服务目录将此工单转派给总公司二线应用系统专家组中的CBPS8版系统小组组长（不派发给小组成员）L1，由W3召集应急小组进行应急会议，根据之前制定的应急预案进行处理，同时W3与G1对事件处理过程进行沟通并确认紧急事件是否解决，L1发起对该紧急事件的问题请求。如果没有应用预案或已有应急预案无法解决此紧急事件，则由W3组织相关人员及厂商共同分析，制定解决方案并进行处理。事件处理结束后，将工单返回给山东省分公司信息技术部小张，由小张确认并关闭

##

## 9.4 分公司与总公司

贵阳市分公司业务处理人员小赵反映万能系统保全功能操作报错，联系贵州省分公司服务台人员，服务台人员记录事件信息并与小赵沟通确认是“核心运营－万能系统－保全模块”的问题，首先根据服务目录查询知识库，如果有匹配的解决方案，则按照解决方案处理，如果需要发起变更，则由服务台人员根据解决方案创建变更工单。如果未在知识库中查询到匹配的解决方案，则进行重复事件判断，如是重复事件，则关联重复事件工单号，并置事件状态“XX处理中”，保存退出，同时服务台人员告知小赵通过查询XX工单号可以了解决事件处理进度。如果不是重复事件，则判断事件性质、优先级、影响度等，如果此事件为紧急事件则转派给一线支持进行再确认，如果不是紧急事件则进行尝试解决，并更新事件状态为“服务台处理中”，如果服务台人员解决了此事件，则更新工单信息，并与小赵确认解决方案及满意度。如果经尝试未能解决则转派一线支持，系统自动将事件状态置为“分派到一线”

通过系统对服务目录判断将此工单分派给分公司一线应用支持组中的万能支持小组组长，此时万能支持小组有两人，分别为A，B，万能支持小组组长根据实际情况手工将此工单派发给B，经B分析分公司一线内部无法解决，需转派给总公司二线

通过系统对服务目录判断将此工单分派给总公司二线应用支持组中的万能支持小组组长，此时万能支持小组有三人，分别为C,D,E，万能支持小组组长根据实际情况手工将此工单派发给E，经E分析无法准确定位原因，需转派给总公司三线

通过系统对服务目录判断将此工单分派给总公司三线开发支持组中的万能支持小组，此时万能支持小组有五人，分别为F,G,H,I,J，其中F为本组中的组长，系统将此工单派发给F，经F分析了解此事件，H是最适合的人选，由F通过手工选择组内人员的方式将此工单派发给H，经H分析确认，此事件是由系统BUG引起，H填写临时解决方案，并将事件状态设置为“已解决”，同时由H发起一个针对此事件的问题工单，并与此事件工单进行关联，系统自动将事件工单转派给贵州省分公司服务台，由服务台人员告知小赵针对此事件已经创建一问题工单。小赵可以通过此事件工单关联的问题工单查看问题处理进度。

#

# 10. 关键流程衡量指标

为了控制流程的质量，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。

序号 | 衡量指标 | 指标计算说明
1 | 事件总数 | 数量：在事件单中根据以下条件过滤 【重复事件标记】为空 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’ 【事件发生时间】在统计周期内
2 | 服务台解决率 | 数量：在事件总数中过滤所有【事件解决人角色】＝‘服务台’ 比率：数量 / 事件总数 × 100 %
3 | 服务台平台响应时间 | 响应时间：（【实际开始时间】－【登记时间】） 总响应时间：在事件总数中统计各（【实际开始时间】－【登记时间】） 平均响应时间：总响应时间/事件总数
4 | 一线解决率 | 数量：在事件总数中过滤所有【事件解决人角色】＝‘一线’ 比率：数量 / 事件总数 × 100 %

标签：
由 superadmin 在 2024/10/29, 16:23 创建

- 评论 （0）
- 注释 （0）
- 附件 （23）
- 历史记录
- 信息

粤ICP备17056641号
深圳市艾拓先锋企业管理咨询有限公司