文档更改04 某汽车金融公司ITIL事件管理流程说明书

由 superadmin 于 2024/06/05, 11:02 最后修改

从版本< 2.1 >

由superadmin编辑
在2024/04/16, 16:57上

到版本

由superadmin编辑
在2024/04/16, 17:06上

< >

修改评论该版本没有评论

Raw
已渲染

Summary

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

Details

Page properties

标题

...	...	@@ -1,0 +1,1 @@
	1	+某汽车金融公司ITIL事件管理流程说明书

父

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

Content

@@ -1,0
          +1,570 @@
++=== **某汽车金融公司ITIL事件管理流程说明书** ===
++
++
++==== **1 .1 流程目的** ====
++
++
++本文档是针对IT桌面支持及IT运维项目范围内基于Agile-ITSM平台的相关事件进行处理的详细说明。
++
++事件管理流程的主要功能是尽快解决出现的事件，保持业务系统的稳定性，其目的包括：
++
++
++**◆在成本允许的范围内尽快恢复IT服务**
++
++* 快速响应服务请求（电话/Web/邮件/短信等）
++* 用户在线获得帮助
++* 沟通事件解决的状态
++* 和客户确认事件的解决
++* 启动应急预案
++
++
++**◆进行事件控制**
++
++* 按规范记录事件
++* 就事件的优先级，影响度进行分类
++* 分析，诊断，必要时进行升级
++* 监视并结束事件
++* 进行定期服务流程回顾
++
++
++**◆提供IT管理信息**
++
++* 人力资源利用情况
++* 故障处理情况
++* 支持效率
++
++
++
++===== **1.2 流程主要内容** =====
++
++
++事件管理流程始于事件的登记和报告，结束于事件的解决。该流程包含下述主要内容：
++
++
++**◆事件检测和记录**
++
++这个环节是事件管理流程的起点。所有用户或系统报告的IT事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。
++
++该环节的关键是信息的准确性和完整性。
++
++
++**◆分类和初步支持**
++
++对于每个事件，需要确立事件所属的领域、子领域和优先级。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。
++
++
++**◆调查和诊断 **
++
++若支持人员无法解决事件，可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。
++
++
++**◆解决和恢复**
++
++支持人员实施事件的解决方案，并将解决完毕的事件转回用户或通知用户解决的结果，并得到用户的确认。
++
++
++**◆优先级为一级的事件（紧急事件）和事件升级**
++
++用户报告经运维一线判定事件优先级为一级事件，将立刻转交给应急小组并上报管理层；在经应急小组确认事件优先级后，立即启动紧急事件流程。
++
++
++**◆结束事件**
++
++当用户确认事件解决后，此时可结束该事件。
++
++
++**◆事件例外**
++
++当发生如地震、洪水和战争等不可抗力的因素时，由此导致的故障将不作为事件管理流程记录范围。
++
++
++
++==== **1.3 与其他流程的关系** ====
++
++
++**◆和问题管理流程的关系**
++
++事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来进行事件趋势分析和问题定位；在优先级为一级的事件解决并恢复服务后做为问题进行进一步的分析和处理。
++
++
++**◆和配置与资产管理流程的关系**
++
++需要从配置与资产管理清单中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。
++
++
++**◆和变更管理流程的关系**
++
++变更实施人员和监控人员应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。
++
++
++
++==== **1.4 流程范围** ====
++
++
++在此次项目中事件管理流程的范围包括涉及用户端的软硬件、机房内的基础架构和应用系统
++
++不包括：
++
++◆尚处于开发或测试环境的系统和应用引发的事件
++
++
++
++==== **1.5 流程执行原则** ====
++
++
++===== **1.5.1 常规原则** =====
++
++* 所有IT事件管理范围内发生的事件，都应该记录在Agile-ITSM平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件
++* 所有IT支持人员对优先级为一级和二级的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别
++* 应该每月产生事件管理报表，包含对考核指标的统计，以及相应的报表。并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估
++* 应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程
++
++
++
++
++===== **1.5.2 所有权原则** =====
++
++所有权原则用来确保每个事件在任何时段都有适当的人员负责，服务台是事件的负责人。下表是事件管理中各角色在各环节中承担不同责任的RACI模型。
++
++
++|(% rowspan="3" %) |用户|事件经理|一线支持|二线支持
++| | | |
++|(所有公司员工)|(职能经理)|(员工)|(厂商)
++|检测和记录(detection and recording)|A|I|R|
++|分类和支持(classification & initial support)|C|C|A|
++|分析和诊断(investigation and diagnosis)| | |A|R
++|解决和恢复(resolution and recovery)| |C/I|A|R
++|事件关闭(Incident closure)|A|A/I|R|
++|监控和沟通(ownership, monitoring, tracking & communication)|I|R/C/I|A/I|I
++|(% colspan="5" %)RACI模型说明       A: 负全责; R: 有义务; C: 提建议; I: 需知会
++
++表2-1 事件管理RACI模型
++
++
++===== **1.5.3 再分派原则** =====
++
++事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分配到个人，或者分配到组，由组内的支持人员处理。
++
++* 一线技术人员可以将事件单分配给其他一线技术人员。
++* 一线支持人员可以将事件单重新再分配给其他一线支持人员或升级厂商。
++* 一线支持人员将事件升级至厂商后，由于一线支持人员代表厂商完成工单流转。
++
++
++===== **1.5.4 重复事件原则** =====
++
++重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件，或者一人/多人申告的同一来源（系统、应用）现象相同的事件。
++
++
++当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。
++
++* 重复的事件必须被关联，并且不计入事件流程的关键衡量指标。
++* 如果一线技术人员可以判断到重复事件，则由一线支持人员关联重复事件，否则由事件经理进行关联。
++
++
++===== **1.5.5 关闭原则** =====
++
++事件工单关闭环节的基本原则：谁开单，谁负责关闭。
++
++◆ 用户通过系统登记事件工单或IT人员通过电话、邮件等方式受理的事件工单，由一线支持人员与用户确认解决后进行关闭。
++
++◆ 一线支持人员自行创建的事件单，由创建人关闭。
++
++◆ 监控平台产生的告警，由一线支持人员根据监控平台的反馈确认后关闭。
++
++◆ 优先级为一级的事件工单由事件经理进行关闭。
++
++◆ 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码并转用户关闭：
++
++* 用户确认问题已解决，则关闭工单。
++* 工单处理人员在转用户确认后，要与用户持续保持沟通，了解用户对工单处理的满意程度；如果用户不满意，则需要进一步处理直至满足用户需求。
++
++◆已关闭的事件单不允许重开。如果事件再次发生，则创建一个新的事件单，并与已关闭的工单进行关联。
++
++
++===== **1.5.6 升级原则** =====
++
++制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。
++
++* 对所有事件，一线支持人员应立即接受事件单并着手解决。
++* 优先级为一级的事件，由应急小组再次确认，如果确认了优先级为一级，则通过线下通知的方式升级到事件经理，启动紧急事件处理流程。
++* 优先级为二级的事件，一线人员处理4小时后，如不能解决，则要求立即升级到二线人员进行处理。
++* 优先级为三、四、五级的事件，处理时间超过80%时，由事件经理对处理人进行督促，要求将规定时间内不能解决的事件升级。（一线升级到厂商）。
++* 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定解决时限，运维管理系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理。
++* 各支持人员处理优先级为三、四、五级的事件时，应及时将不能解决的事件升级；事件经理对未及时升级的事件及时介入，负责协调升级处理。事件经理通过对事件的抽查和对超时解决的事件统计情况对各支持人员的主动性进行监督。
++
++
++==== **1.6 流程相关定义** ====
++
++
++===== **1.6.1 事件信息项** =====
++
++
++事件单包含如下事件信息项：
++
++|序号|信息项|说明
++|1|工单号|事件单流水号（系统自动产生）
++|2|派单人|事件申报人的信息（系统自动产生）
++|3|登记时间|在服务台生成事件记录的时间（系统自动产生）
++|4|地点|事件发生的地点 （手工填写）
++|5|发生时间|系统自动产生
++|6|业务恢复时间|针对故障的业务恢复实际时间（手工填写）
++|7|事件来源|“用户填写”，“BA开单”，“内部开单”，“其他”
++|8|影响范围|“所有用户”，“1个以上用户”，“1个用户或无明显影响”
++|9|优先级|参见“ 事件优先级判定标准”
++|10|服务类别|参见“服务类别、服务子类”
++|11|服务子类|参见“服务类别、服务子类”
++|12|事件类型|“突发事件”，“服务请求”，“咨询”，“建议”
++|13|描述|对于整个事件内容的详细描述（手工填写）
++|14|状态|系统自动产生
++|15|解决方案|事件解决方案的描述（手工填写）
++|16|结束代码|“通过变更解决”，“正常解决”，“超出范围”，“用户取消”，“使用变通方法解决”
++|17|关闭时间|手动填写
++|18|问题初步原因|手动填写
++|19|厂商|参见“故障厂商列表”
++|20|关联事件|标记为重复事件（手工选择）
++|21|关联配置项|记录出现故障的配置项代码（手工选择）
++|22|关联的问题单号|记录由事件引发问题时，关联的问题单号（手工选择）
++|23|关联的变更单号|记录由事件引发变更时，关联的变更单号（手工选择）
++|24|用户|系统内查询并选择
++|25|用户工号|根据用户选择自动产生
++|26|用户电话|根据用户选择自动产生
++|27|用户邮件|根据用户选择自动产生
++|28|用户部门|根据用户选择自动产生
++|29|升级厂商时间|升级厂商的时间
++|30|厂商工单ID|厂商提供的保修单ID
++|31|厂商电话响应时间|厂商电话响应的时间
++|32|厂商现场响应时间|厂商现场响应的时间
++
++
++===== **1.6.2 事件优先级判定标准** =====
++
++用户/BA在登记事件单时根据系统所属的领域、子领域的选择和影响范围两者加权来定义事件优先级。
++
++|(% colspan="2" rowspan="2" %)事件优先级判定说明|(% colspan="3" %)影响范围
++|所有用户|1个以上用户|1个用户或无明显影响
++|(% colspan="2" %)业务关键性|关键（2）|重要（1）|一般（0）
++|关键业务|关键（2）|一级|二级|四级
++|重要业务|重要（1）|二级|三级|四级
++|一般业务|一般（0）|三级|四级|五级
++
++表5-2事件优先级
++
++
++===== **1.6.3 服务类别、服务子类 ** =====
++
++|服务类别|服务子类|业务定义|对应一线
++|业务系统|WHS|关键业务|BA
++| |RTL|关键业务|
++| |SAP|关键业务|
++| |ODS|重要业务|
++| |SMS|一般业务|
++| |IMG|一般业务|
++| |个人征信|一般业务|
++| |企业征信|一般业务|
++| |其他|一般业务|
++|(% colspan="4" %)
++|办公应用|AD|关键业务|基础架构
++| |邮件系统|关键业务|
++| |文件共享服务|关键业务|
++| |内网门户|重要业务|
++| |VoIP|关键业务|
++| |防病毒系统|一般业务|
++| |其他|一般业务|
++|(% colspan="4" %)
++|IT管理平台|监控平台|一般业务|基础架构
++| |IT服务管理|一般业务|
++|(% colspan="3" %) |
++|桌面服务|电脑|重要业务|桌面服务
++| |打印|一般业务|
++| |电话|重要业务|
++| |病毒|一般业务|
++| |网络|一般业务|
++| |软件|一般业务|
++| |其他|一般业务|
++|(% colspan="4" %)
++|基础架构|网络设备|关键业务|基础架构
++| |安全设备|关键业务|
++| |服务器|关键业务|
++| |虚拟化|关键业务|
++| |存储设备|关键业务|
++| |存储网络|关键业务|
++| |备份设备|一般业务|
++| |备份系统|一般业务|
++| |UPS|一般业务|
++| |空调|重要业务|
++| |其他|一般业务|
++|(% colspan="4" %)
++|服务请求|资产申请|一般业务|桌面服务
++| |帐号与权限|一般业务|
++| |软件安装|一般业务|
++| |其他|一般业务|
++|(% colspan="4" %)
++|应用运维|数据库|关键业务|应用运维
++| |中间件|关键业务|
++| |Web|重要业务|
++| |应用程序|关键业务|
++
++表5-3服务类别、服务子类域、业务关键程度和对应一线映射表
++
++
++===== **1.6.4 事件响应时限和解决时限** =====
++
++在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制。一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念；也要求事件经理必须实时地督促事件的解决，对于优先级别高的事件，需要及时通告事件经理；如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。
++
++响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间；
++
++解决时限指的是事件状态从“已登记”到“已解决”经过的时间；
++
++事件优先级对应的事件响应时限和解决时限参考下表（以下时间是9×5工作时间）：
++
++|事件级别|响应时限|解决时限|1线 to 2线升级时限|备注
++|一级事件|立刻|8小时|N/A|事件直接交由应急小组处理
++|二级事件|5分钟|12小时|4小时|未与厂商合同约定解决时限，目前只做内部参考
++|三级事件|10分钟|24小时|8小时|未与厂商合同约定解决时限，目前只做内部参考
++|四级事件|15分钟|48小时|18小时|未与厂商合同约定解决时限，目前只做内部参考
++|五级事件|30分钟|96小时|40小时|未与厂商合同约定解决时限，目前只做内部参考
++|九级事件|30分钟|96小时|48小时|服务请求主要是IT办公资源申请/调整和信息咨询，通常可能不存在升级，但不排除
++
++ 表5-4事件响应·解决·升级时限
++
++
++**超出和即将超出解决时限的通告定义：**
++
++通知人员列表的用途：当Agile-ITSM平台判断到解决时限已经或即将超出，则自动按照表中的人员列表发出邮件通知。
++
++
++===== **1.6.5 通知与提醒** =====
++
++在事件流程开始和处理过程中，发送满足以下条件的通知或提醒，推进事件工单的及时执行：
++
++* 当事件工单分（转）派时，发送通知给接收人。
++* 当一级事件确认后，通知应急小组。
++* 对二、三、四、五和九级优先级的事件，在处理时间过去50%时，发送提醒给事件处理人和事件经理。
++* 对二、三、四、五、九级优先级的事件，超过解决时间时，发送提醒给事件处理人和事件经理。
++
++
++|优先级别|通知时间|通知人员列表
++|1级|立刻|应急小组
++|2级|6小时|事件经理、事件处理人
++| |12小时|事件经理、事件处理人
++|3级|12小时|事件经理、事件处理人
++| |24小时|事件经理、事件处理人
++|4级|24小时|事件经理、事件处理人
++| |48小时|事件经理、事件处理人
++|5级|48小时|事件经理、事件处理人
++| |96小时|事件经理、事件处理人
++|9级|48小时|事件经理、事件处理人
++| |96小时|事件经理、事件处理人
++
++ 表5-4通知时间和对应人员列表
++
++
++===== **1.6.6 故障厂商列表** =====
++
++用来在事件单中记录是哪个厂商的设备/系统或者哪个集成商的应用软件发生故障。
++
++
++|厂商
++|HP硬件
++|HP服务
++|Oracle
++|SAP
++|Netsol
++|PCCW
++|剑阁
++|H3C
++|F5
++|万国数据
++|万申
++|联想
++|华为
++|其他
++
++表5-5故障厂商列表
++
++
++==== **1.7 流程设计** ====
++
++为了更清晰地描述事件管理流程，我们将通过事件管理流程和紧急事件管理流程来详述：
++
++
++===== **1.7.1 事件管理流程** =====
++
++**[[image:图片1.png]]**
++
++
++事件管理流程文字说明：
++
++
++|序号|步骤名称|责任人|说明
++|104|一级事件处理模型|事件经理|一级事件即紧急事件必须由事件经理提出。
++|104.1|二次确认|应急小组|应急小组需要对一级事件再次确认。
++|104.2|参见一级事件流程| |一级事件是运维过程中出现的极其特殊、重大的事件，因此有单独工作流程供参见。
++|100.1|事件记录-用户|用户|用户工作中遇见任何非业务系统类的IT故障或IT服务请求时，他们可以自行开单，工单将自动转派给一线（桌面支持小组）。
++|100.2|桌面支持尝试尝试解决|桌面支持小组|桌面支持二次判断事件类型，若确认事件属于桌面服务/服务请求，则着手解决或升级厂商；若不是上述服务类别则转派其他一线小组，具体参见一线互相转派子流程。
++|100.3|二线尝试解决|厂商|厂商通过线下方式接到一线升级的事件，着手解决并提供解决方案。
++|101.1|事件记录-IT|基础架构小组|当故障或潜在故障涉及办公应用/IT管理平台/基础架构时，由基础架构小组开单，工单将自动转派给一线（基础架构支持小组）。
++|101.2|基础架构支持尝试解决|基础架构支持小组|基础架构支持小组尝试解决故障或潜在故障；若判断无法解决，则向二线厂商升级，并进入线下协调工作模式至问题解决。
++|101.3|二线尝试解决|厂商|厂商通过线下方式接到一线升级的事件，着手解决并提供解决方案。
++|102.1|事件记录-BA|BA支持小组|用户工作中遇见任何业务系统故障时，他们需要联系BA并告知故障现象，由BA开单，工单将自动转派给一线（BA支持小组）。
++|102.2|BA尝试解决|BA支持小组|BA支持小组二次判断事件类型，若确认事件属于业务系统，则着手解决或升级厂商；若不是上述服务类别则转派其他一线小组，具体参见一线互相转派子流程。
++|102.3|二线尝试解决|厂商|厂商通过线下方式接到一线升级的事件，着手解决并提供解决方案。
++|103.1|事件记录-APP支持|APP支持小组|当APP支持小组发现业务系统对应的中间件或数据库出现故障或潜在故障时，由APP支持小组开单，工单将自动转派给一线（APP支持小组）。
++|103.2|APP支持尝试解决|APP支持小组|APP支持小组尝试解决故障或潜在故障；若判断无法解决，则向二线厂商升级，并进入线下协调工作模式至问题解决。
++|103.3|二线尝试解决|厂商|厂商通过线下方式接到一线升级的事件，着手解决并提供解决方案。
++|105|事件处理的监控|事件经理/开单人|事件经理可以全程关注事件流转过程，而事件每流转一次，则系统会发邮件告知开单人（事件上报人）。
++|106|记录解决方案细节|一线|无论由一线还是二线厂商提出最终的解决方案，均由一线完成记录并填入工单。
++|107|关闭事件|用户/BA/IT|由开单人确认并关闭事件；若出现helpdesk替用户开单的状况，则helpdesk需要得到用户邮件确认方可关单。
++
++ 一线互相转派子流程文字说明：
++
++
++|序号|步骤名称|子流程说明|执行原则
++|100.2|桌面支持尝试解决|桌面支持小组接受由用户开单的事件后，需要检查该事件的服务类别是否正确，若事件类别不合适，则需要修改服务类别并在一线内转派。|参见“服务类别、服务子类域、业务关键程度和对应一线映射表”
++|101.2|基础架构支持尝试解决|基础架构支持小组可以分析事件，若是本组职能范围内的事件，则根据主流程尝试解决；若非职能范围内的事件，则需要修改服务类别并在一线内转派。|参见“服务类别、服务子类域、业务关键程度和对应一线映射表”
++|102.2|BA尝试解决|BA小组在接到用户报告业务故障后判断故障非业务本身导致，但无法进一步判断是何原因导致，则可以转派给基础架构支持小组；若可以确定是哪个环节故障，则直接转派相应的一线。|参见“服务类别、服务子类域、业务关键程度和对应一线映射表”
++|103.2|APP支持尝试解决|APP支持小组通常是接受一线内转派的事件工单；若由其自己开单则一般都确认事件属于其职能范围内，则直接解决。|参见“服务类别、服务子类域、业务关键程度和对应一线映射表”
++
++
++==== **1.7 一级（紧急）事件管理流程** ====
++
++
++
++[[image:图片2.png]]
++
++
++图5-2 一级（紧急）事件管理流程
++
++
++制定一级（紧急）事件管理流程的目标：
++
++◆当（一级）紧急事件发生时，尽可能采取措施减少对于业务带来的影响。
++
++◆确保对紧急情况的有效管理：
++
++* 加快一级（紧急）事件的响应和处理速度。
++* 对紧急情况中的人员及采取的行动加强管理。
++* 加强处理人员与用户之间的沟通和反馈。
++* 对紧急情况妥善处理。
++
++
++一级（紧急）事件处理的特殊性包括各系统应急处理预案的制定和使用，及时上报等。
++
++应急处理预案是事先制定的针对某种特定故障的处理措施，可以确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障。预案中的内容至少应涵盖应急预案启动条件、应急处理小组负责人和成员联系名单和联系方式、应急处理步骤、应急信息通报、应急善后处理、应急保障措施（人员、培训、演习、场地）等。
++
++
++由于一级（紧急）事件通常对企业造成非常严重的影响，从实际工作出发此时在进行电子化工单的流转不合适宜，因此当事件经理对一级（紧急）事件进行确认后，应急小组直接介入处理，待一级（紧急事件）解除后，由事件主要相关一线进行补单。
++
++一级（紧急）事件管理流程文字说明：
++
++
++|序号|步骤名称|责任人|说明
++|104.1|召集应急小组,协调应急会议|事件经理|当事件经理确认一级（紧急）事件后，立即召集应急小组和上报CIO并召开应急会议；会议上，应急小组对一级（紧急）事件再次确认。
++|104.2|应急小组分析、制定处理方案并处理|应急小组|应急小组（包含CIO、事件经理、所有相关技术人员和厂商）确认一级（紧急）事件是否已有应急预案，若有则执行应急预案；若无适合应急预案，则制定处理方案再处理。
++|104.3|紧急事件解除确认？|应急小组|应急小组处理过事件后，由应急小组再次判断一级（紧急）事件是否解除；若未解除，则再次执行104.2流程节点；若解除，流程继续往下走。
++|104.4|善后处理和通报|应急小组|在解除一级（紧急）事件后，应急小组需要安抚受影响的用户并将事件原因和处理结果等信息上报CIO，再由事件主要相关一线事后补单。
++|104.5|关闭事件|应急小组|主要相关一线完成补单后，直接关单。
++
++
++==== **1.8 关键角色、职责定义** ====
++
++
++事件管理流程主要分为以下角色：
++
++
++===== **1.8.1 事件管理流程负责人** =====
++
++事件管理流程负责人从宏观上监控流程，确保事件流程在业务支持中心范围内被正确的执行。当流程不能够适应业务支持中心的情况时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。
++
++**职责：**
++
++1. 确定管理流程的衡量指标
++1. 确保事件流程能够取得管理层的参与和支持
++1. 确保事件流程符合公司实际状况和公司 IT发展战略
++1. 总体上管理和监控流程，建立事件流程实施、评估和持续优化机制
++1. 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进(假如增加或合并流程的角色)，从而实现可持续提高
++1. 保持与其他流程负责人的定期沟通
++
++
++===== **1.8.2 事件经理** =====
++
++事件经理负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。
++
++**职责**
++
++1. 负责对事件的解决协调资源，保证故障的最终排除
++1. 确保和问题管理流程经理的有效合作
++1. 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题
++1. 监督优先级为紧急、高的事件的处理情况
++1. 监督一线是否及时将事件工单升级。
++
++
++===== **1.8.3 一线支持人员** =====
++
++一线支持人员根据预定义进行不同类型的事件开单和接受事件，对事件进行快速有效的分析，提出解决方案以尽快恢复服务。在解决事件过程中，一线支持人员可以再分类和转派事件至其他一线支持小组；另外，一线支持人员可以将事件升级至厂商寻求技术支持。
++
++**职责：**
++
++1. 按照系统进行划分，对事件进行快速有效的分析，提出解决方案以尽快恢复服务；
++1. 验证事件的描述和信息，进一步收集相关信息；
++1. 进行深入调查研究或协调二线支持，提供/获取有效的解决方案；
++1. 实施事件解决方案；
++1. 更新事件解决信息，已解决的事件转用户确认。
++
++
++===== **1.8.4 二线支持人员** =====
++
++包括现场支持和远程支持设备厂商。
++
++**职责:**
++
++1. 必要时提供现场支持和深入调查研究，提供有效的解决方案
++1. 参与解决方案的实施
++1. 将解决方案和实施结果反馈给一线人员，由一线人员进行解决方案的记录。
++
++
++===== **1.8.5 流程角色和人员对应表** =====
++
++|(% colspan="2" %)角色|成员|默认接单人
++|(% colspan="2" %)事件管理流程负责人| |N/A
++|(% colspan="2" %)事件经理| |N/A
++|一线支持|桌面服务| |
++| |BA| |
++| |应用运维| |
++| |基础架构| |
++
++ 表5-6流程角色和人员对应表
++
++
++===== **1.8.6 关键流程衡量指标** =====
++
++为了控制流程的质量，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。
++
++|序号|衡量指标|指标计算说明
++|1|事件总数|事件总数量
++| | |【发生时间】在统计周期内
++|2|在一定周期内每一类事件的数量/百分比|数量：【事件类型】="突发事件" or"服务请求" or "咨询" or "建议"
++| | |比率：数量/事件总数 × 100%
++| | |【发生时间】在统计周期内
++|3|在一定周期内每一类事件的前top3的服务子类数量/百分比|各类事件数量：【事件类型】="突发事件" or"服务请求" or "咨询" or "建议"
++| | |数量：在各类事件数量中获取每一个【服务子类】的数量并倒序排列，获取前三个数量
++| | |比率：数量/各类事件数量 × 100 %
++|4|规定时间内一线响应的事件数量/百分比|数量：在事件总数中获取符合SLA的事件 and 状态~!="已登记"
++| | |比率：数量/事件总数 × 100 %
++| | |【发生时间】在统计周期内
++|5|已关闭事件数量|数量：状态="已关闭"
++| | |【关闭时间】在统计周期内
++|6|事件成功关闭的数量/百分比|数量：【事件结束代码】＝"正常解决"or"使用变通方法解决"or"通过变更解决" and 状态="已关闭"
++| | |比率：数量 / 已关闭事件数量  × 100 %
++| | |【关闭时间】在统计周期内
++|7|规定时间内解决的事件数量/百分比|数量：在事件总数中获取符合SLA的事件 and 【事件结束代码】＝‘正常解决’or‘使用变通方法解决’or‘通过变更解决’ and 状态="已关闭"
++| | |比率：数量/已关闭事件数量 × 100 %
++| | |【关闭时间】在统计周期内
++|8|一线解决数量/百分比|数量：在事件总数中获取未升级厂商的事件单  and 状态="已关闭"
++| | |比率：数量 / 已关闭事件数量 × 100 %
++| | |【关闭时间】在统计周期内
++|9|超时未解决的事件数量/百分比|数量：在事件总数中获取SLA超时 and 【事件状态】！＝‘已关闭’
++| | |比率：数量 / 事件总数 × 100 %
++| | |【关闭时间】在统计周期内
++
++表5-7流程角色和人员对应表

粤ICP备17056641号

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