ITIL-事件管理流程设计说明书

1、目录目录 11 流程目的 32 流程主要内容 33 与其他流程的关系 44 关键角色、职责定义 4效劳台人员 5一线支持人员 5二线支持人员 6三线支持人员 7事件经理 7事件管理流程负责人 8实际岗位与方案角色的映射 85流程执行原那么 11常规原那么 11流程关联原那么 11所有权原那么 12再分派原那么 12重复事件原那么 12关闭原那么 12升级原那么 13人员岗位与角色落实原那么 13工单流转原那么 136 流程相关定义 13事件信息项 14事件性质 16事件来源非必填项 16事件所属系统类型 16事件分类 18事件优先级 19事件响应时限和解决时限 20事件影响度 21事件状态 2

2、2事件结束代码 26事件解决人角色 26处理是否超时 26故障厂商 26用户反应 277 流程概要设计 288 流程详细设计 30事件记录和分类 30初始支持 31一线尝试解决 32二线尝试解决 34紧急事件再确认 36三线尝试解决 37记录解决方案细节 39关闭事件 40事件处理的监控 4110 1紧急事件处理子流程 429 关键流程衡量指标 错误 !未定义书签。1 流程目的事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：在本钱允许的范围内尽快恢复 IT 效劳? 快速响应效劳请求 /Web/ 邮件等? 用户在线获得帮助? 沟通事件解决的状态? 和客户确认事件

3、的解决进行事件控制? 按标准记录事件? 就事件的优先级，影响度 进行分类? 分析，诊断，必要时进行升级? 监视并结束事件? 进行定期效劳流程回忆 提供 IT 管理信息? 人力资源利用情况? 故障处理情况? 支持效率2 流程主要内容事件 (Incidents) 是中断业务流程和降低 IT 效劳质量的错误。事件管理流程帮助迅速解决这些事件， 并最小化对于业务的不利影响。流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内 容：事件接收和记录这个环节是事件管理流程的起点。所有用户或系统报告的 IT 事件必须由此步骤开始。此步骤的目的是 在事件发生时快速准确地发现，以协助事件的诊断和解决并

4、通知相关人员。在此步骤中将会收集创立事件 记录所需的信息。该环节的关键是信息的准确性和完整性。分类和在线支持事件可以是一个申告 / 故障 /告警 /咨询，对于每个事件，需要确立优先级和分类。假设没有现成的解决 方案或临时解决措施，该事件将分配给适宜的支持人员对此进行调查。该环节的关键是必要的问题库支持和正确的事件分派。调查和诊断 假设支持人员无法解决事件，可运用问题库、诊断工具等进行更加深入的分析以找到恢复效劳的临时措施，必要时可调用多名支持人员以寻求解决措施。解决和恢复 支持人员实施事件的解决方案，并将解决完毕的事件转回效劳台，由效劳台通知用户解决的结果，并得到用户确实认。优先级为紧急的事件

5、紧急事件和事件升级 对于紧急事件，效劳台应立即提交给一线人员，由一线人员判断，上报给事件经理和相关的管理层，由事件经理决定紧急事件的处理方式，确保其得到最快速的解决。当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。结束事件 当用户确认事件解决后，此时可结束该事件，并在必要时更新问题库。3 与其他流程的关系和问题管理流程的关系 事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复效劳后做为问题进行进一步的分析和处理。 和配置管理流程的关系 需要从配置管理数据库中查询配置项的属性和配置

6、项间的关联关系来定位故障和帮助快速的恢复。 和变更管理流程的关系 效劳台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，涉及到需要对根底架构、应用系统及操作系统等进行变更的需要发起变更请求来解决事件。4 关键角色、职责定义流程的实现是通过不同的流程角色以及其被赋予的职责来实现的， 因此流程的每一个角色可以被定义为一系 列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的管理流程和角色的目的是为了在充分满足 流程所需角色的根底上，为具体的实现提供足够

7、的灵活性。事件管理流程主要分为以下几个职责 / 角色，分别简述如下：4.1 效劳台人员效劳台人员负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到适宜的一线支 持工程师。职责：在指定的响应时间内响应所有效劳台热线 、邮件、工单等事件报告； 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、 发生时间等；为事件进行适当的分类、为事件分配优先级等属性； 尝试使用知识库、初步诊断、分析相关信息等方式解决事件； 如果效劳台不能解决事件，应当将事件分配给最适宜的一线支持小组或来处理； 检查事件记录的处理进度，保持与用户的联系，适时通知事件处理进展； 在

8、事件处理过程中，催办事件处理进度与用户确认事件解决方案及用户满意度反应，关闭事件。技能要求：熟悉技术平台和技术环境较强的沟通能力对简单的故障要有快速诊断和解决的能力熟悉事件处理流程人员按排建议：建议总公司效劳台设置 3 人，分别负责受理桌面支持、核心业务系统类、非核心业务系统包括 其他应用系统、网络接入等三大类事件。各分公司效劳台设置 2-3 人受理各类事件。结合分公 司实际情况，假设事件单日常数量较多，效劳台人数可以进行增加。4.2 一线支持人员在 ITIL 体系中，一线支持人员负责对效劳台无法解决的事件进行快速有效的分析，提出解决方案以尽快恢复效劳，并在必要时提供现场支持。职责：决定需要采

9、取何种措施恢复效劳并实施有效的行动必要时提供现场支持根据优先级提供有效的解决方案更新事件解决信息，已解决的事件转回效劳台，由效劳台关闭事件如果一线不能解决这个事件，应当决定选择最适宜的二线支持小组 / 人员来处理技能要求：熟悉技术平台和技术环境较强的沟通能力快速诊断事件和解决事件的能力熟悉事件处理流程人员按排建议：建议将分公司 IT 部门日常维护包括硬件、软件、开发等人员纳入一线支持中，按日常所管系统类型或设备类型划分到相应维护支持组中分公司具有开发人员的，将开发人员纳入到应用系统支持组中如分公司技术力量较强，可将一线支持各组根据技术能力划分为初级组、高级组 对于地市技术力量薄弱的，将地市人员

10、按岗位技能纳入省级公司相应一线支持组中 对于地市技术力量较强的，可以考虑建立与省级公司平级的支持组4.3 二线支持人员二线支持人员是相关问题领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复效劳。职责:进行事件的深入调查研究根据经验和专业技能，决定需要采取何种措施恢复效劳并实施有效的行动必要时引入供应商的支持及时提供有效解决方案与其他二线小组合作，确定解决方案已解决的事件转回效劳台，由效劳台关闭事件技能要求：深厚的技术背景，对所维护范畴的技术深入掌握熟悉事件处理流程人员按排建议：主要由总公司各类业务系统及根底设施维护专家组成，技术力量较强的分公司的资深维护人

11、员组 成虚拟团队4.4 三线支持人员职责：从研发的角度进行事件的研究； 根据经验和专业技能，决定需要采取何种措施恢复效劳并实施有效的行动，如发布临时补丁等； 及时提供有效解决方案；已解决的事件转回效劳台，由效劳台关闭事件。技能要求：具备开发公司内各类应用系统的能力，对所维护范畴的技术深入掌握； 熟悉事件处理流程。人员按排建议： 由总公司开发人员及厂商代维人员组成，以及分公司开发力量较强人员组成虚拟团队4.5 事件经理事件经理负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。职责：负责对重大、紧急事件的解决协调资源，保证故障的最终排除；当事件优先级为紧急或者事件将超过规定的时限，负

12、责按照升级方法对事件进行处理确保有效协 调资源，促进各类角色小组如一线支持、二线支持快速恢复正常效劳； 确保和问题管理流程经理的有效合作；确保正确和广泛地收集和分析事件数据，发现 IT 和业务相关的问题。技能要求：了解技术架构和技术环境；较强的口头表达能力和与用户沟通技巧；处理纠纷的能力；深刻了解事件管理流程；较强的领导能力。人员按排建议：由分公司及总公司主管应用系统维护工作的领导担任4.6 事件管理流程负责人事件管理流程负责人从宏观上监控流程，确保事件流程在信息技术中心范围内被正确的执行。当流程不能够适应cl开展需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高

13、。职责：确定管理流程的衡量指标确保事件流程能够取得管理层的参与和支持确保事件流程符合 cl实际状况和公司IT开展战略总体上管理和监控流程，建立事件流程实施、评估和持续优化机制确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进假设增加或合并流程的角色，从而实现可持续提高技能要求：深刻理解事件管理流程；能够很好地理解业务对于事件管理的需求；有决策权，能够确保事件管理流程设计要求在实施工程中得到贯彻和执行；具有很好的沟通技能，获得所需资源。人员按排建议：由总公司IT部门领导担任4.7 实际岗位与方案角色的映射事件管理流程角色角色细分说明成员效

14、劳台总公司效劳台职责：负责受理办公管理、管理决策、核心运营、 销售客服、桌面支持五大类事件。建议总公司效劳台设置 3人分公司效劳台职责：负责受理各类事件。岗位建议：建议各分公司效劳台设置 2-3人，结 合分公司实际情况，假设事件单日常数量较多， 效劳台人数可以进行增加，建议对应岗位包括服 务支持管理岗、应用管理岗、数据管理岗一线支持总公司一线支持根底设施维护支持组职责：负责总公司小型机、PC效劳器、存储设备、 网络交换机、路由器、防火墙、网络链路等系统 硬件及操作系统、中间件、数据库等系统软件的 根底维护工作岗位建议：建议由总公司运行管理处、网络管理 处负责各根底设施领域维护工作的技术人员担

15、任应用系统支持组职责：负责总公司各类应用系统的维护支持工作 岗位建议：建议由负责各类应用系统维护工作的 技术人员担任桌面支持组职责：负责总公司桌面支持工作岗位建议：建议由代理效劳处负责桌面维护工作的技术人员担任分公司一线支持地市公司直接纳入分公司一线支持应用系统支持组职责：负责分公司自有应用系统的支持工作以及 对总公司应用系统的初始支持工作岗位建议：建议由分公司负责各类应用系统维护 工作的技术人员担任， 建议对应岗位包括 应用管 理岗、地市分公司应用管理岗、数据管理岗、应 用开发岗根底设施维护支持组职责：负责分公司小型机、PC效劳器、存储设备、 网络交换机、路由器、防火墙、网络链路等系统 硬件

16、及操作系统、中间件、数据库等系统软件的 根底维护工作岗位建议：建议由分公司信息技术部门各根底设 施领域维护工作的技术人员担任，建议对应岗位包括设备管理岗、系统管理岗、平安岗、网络管理岗、运行维护岗、地市分公司设备管理岗桌面支持组职责：负责分公司桌面维护支持工作岗位建议：由负责分公司桌面维护支持工作人员的担任，建议对应岗位包括效劳支持管理岗二线支持总公司二线支持应用系统运维专家组职责：负责总公司应用系统包括核心应用系统及 非核心应用系统的维护工作岗位建议：由负责总公司各类应用系统资深技术 人员担任，可以借调分公司相关人员，形成虚拟 团队根底设施维护专家组职责：负责分公司小型机、PC效劳器、存储设

17、备、 网络交换机、路由器、防火墙、网络链路等系统 硬件及操作系统、中间件、数据库等系统软件的 维护工作岗位建议：由总公司运行管理处、网络管理处负 责各领域维护工作的资深技术人员担任，可以借调分公司相关人员，形成虚拟团队三线支持总公司三线支持应用系统开发组职责：负责总公司应用系统包括核心应用系统及 非核心应用系统的开发、修改、优化工作岗位建议：由总公司核心运营开发处、销售客服 开发处、管理决策开发处、电子商务开发处开发 人员担任，可以借调分公司相关开发人员，形成 虚拟团队代维厂商组总公司的厂家支持，可以细分为IBM、HP等事件经理总公司/职责：负责督导与监控总公司事件处理过程的正 常运转，接收事

18、件的升级通知和处理超时通知等 岗位建议：建议在总公司设置事件经理 1人，由 总公司应用管理处处长或副处长担任分公司/职责：负责督导与监控分公司事件处理过程的正常运转，接收事件的升级通知和处理超时通知等 岗位建议：建议在各分公司设置事件经理1人，由分公司分管应用维护的领导担任事件管理流程负责人职责：负责确定管理流程的衡量指标，从宏观上 监控流程，当流程不能够适应cl开展需要时，流程负责人必须及时的对此进行分析、找岀缺 陷、进行改进，从而实现可持续提高岗位建议：建议在总公司设置事件管理流程负责 人1名，由总公司信息技术部相关领导担任说明：一、二、三线分组可进行扩充，各分公司可将现有分组提交到总公司

19、，由总公司统一协调配置5流程执行原那么5.1 常规原那么所有IT和信息技术中心事件管理范围内发生的事件，都应该记录在IT效劳管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件所有IT支持人员对优先级为紧急和高的事件所采取的效劳恢复行动，在比对其它行动的时候，将拥有 优先处理级别应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估应该半年对流程进行回忆，回忆内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性， 以改进事件管理流程5.2 流程关联原那么和问题管理的关联? 所有优先级为紧急的事件在恢复

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

21、将故障定位到某个配置项，那么必须将事件单与该配置项关联5.3 所有权原那么所有权原那么用来确保每个事件在任何时段都有适当的人员负责，效劳台是事件的负责人。由 IT 用户申报的事件单，效劳台职工是该事件的责任人，必须确保事件得到有效跟踪与解决，并负责 事件单的关闭5.4 再分派原那么事件的再分派原那么是确保事件在效劳目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再，再由组内分派的几率。事件单可以分配到个人，或者分配到组效劳台、一线支持、的支持人员处理。事件单的重分派次数不应该超过5 次。效劳台将事件单分配给一线支持一线支持可以将事件单重新分配给效劳台，其他一线支持组人员，二线支持组人员

22、二线支持可以将事件单重新分配给效劳台，人员一线支持组人员，其他二线支持组人员 ，三线支持组三线支持可以将事件单重新分配给效劳台，二线支持组人员，其他三线支持组人员5.5 重复事件原那么重复事件是指在一个较短时间段通常 30 分钟内至1 小时，由监控平台上报的同一个配置项上现象相同的事件或一人 / 多人申告的同一来源系统、应用现象相同的事件。当被报告的事件与某个已经创立且尚未解决的事件单相同，那么该事件被认为是重复的。由于此时已创立的事件尚未解决，还没有采取修正措施来 恢复效劳，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复 事件单获得解决。重复的事件信息必

23、须被标识，并且不计入事件流程的关键衡量指标如果效劳台可以判断到重复事件， 那么由效劳台对重复事件标识， 否那么由一线支持人员负责重复事件的处 理5.6 关闭原那么由 IT 用户申报的事件单，关闭必须由效劳台完成。事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复效劳时， 结束代码为 " 变通方法解决 " 。效劳台负责和 IT 用户再次确认事件的解决由 IT 用户认可获得关闭的事件单的结束代码为" 成功解决 " 关闭已解决的事件单如果没有得到 IT 用户的认可， 那么首先关闭该事件单， 结束代码修改为 "不成功 &

24、quot;，同时 创立一个新的事件单重新分配到原处理人员继续处理已关闭的事件单不允许重开。如果事件重复发生，那么创立一个新的事件单IT 和信息技术中心的维护人员一线、二线或三线自行创立的事件单，本着 " 谁开单，谁负责关闭 " 的原那么监控平台产生的事件发送到效劳台，由效劳台分派，处理人员解决并关单5.7 升级原那么 制定升级原那么的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重 视，提供适宜的资源，从而快速找到解决事件的方案。由一线支持再次确认， 如果确认了优先级为IT 效劳管理平台 ，由事件经理启动紧急优先级为紧急的事件， 效劳台应立即升级

25、到相应一线支持， 紧急，那么立即升级到事件经理，并通知相应的管理层通过 事件处理流程 各支持人员应及时响应和处理分配到本组或自己的事件单， 如果超出规定的响应时限和解决时限， 效劳 台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并催促事件能够及时被响应和处理 效劳台和一线支持应及时将不能解决的事件升级到下一级， 假设未及时升级， 事件经理应及时介入， 负 责协调升级处理5.8 人员岗位与角色落实原那么 分公司技术力量较强的一线各维护支持组根据实际情况可按能力划分初级维护支持组和高级维护支持 组，也可划分为一个组如分公司具有开发人员，可将开发人员纳入到一线应用维护组 地市支持力量薄弱

26、的，可将地市人员按岗位技能纳入省级公司相应支持组 地市支持力量较强的，可建立相对独立的支持维护组目前流程中的各角色的分组可以进行扩充， 由于此工程是全国性工程， 在收集各分公司反应后， 由总公 司进行统一协调配置5.9 工单流转原那么分公司事件管理流程负责处理分公司自有应用系统及根底设施产生的事件以及对总公司应用系统及基 础设施产生的事件进行尝试解决 总公司事件管理流程负责处理总公司应用系统及根底设施产生的事件分公司效劳台负责受理分公司效劳对象提交的所有请求，分公司效劳台首先对用户提交的请求进行尝试解决，不能解决的通过效劳目录自动提交到分公司一线相应支持组或人总公司效劳台负责受理总公司及成员公

27、司提交的所有请求，总公司效劳台首先对用户提交的请求进行尝试解决，不能解决的通过效劳目录自动提交到总公司一线相应支持组或人分公司一线负责处理分公司效劳台转派的工单，对于属于分公司自有应用系统及根底设施产生的事件在一线内部处理解决，不能解决的将工单提交到分公司事件经理，由分公司事件经理协调资源处理；对于属于总公司应用系统及根底设施产生的事件首先在分公司一线内部尝试解决，不能解决的提交到二线相应支持组总公司一线负责处理总公司效劳台转派的工单，首先在一线内部尝试解决，不能解决的提交到二线相应专家组二线负责处理分公司一线及总公司一线转派的工单，首先在二线内部尝试解决，不能解决的提交到三线相应支持组三线负

28、责处理二线转派的工单，首先在三线内部尝试解决，对于三线不能解决的将工单提交到总公司事 件经理，由总公司事件经理协调资源进行处理对于公司信息技术部内部人员创立的工单，根据效劳目录直接转派给本公司一线相应支持组组长，由组长视情况手工分派给本组人员进行处理对于公司信息技术部内容人员创立的工单，关闭原那么是谁创立工单，谁关闭工单6流程相关定义6.1 事件信息项事件单必须包含如下事件信息项:序 号信息项是否 必填说明事件记录和分类时填写：1请求人信息是事件申报人的信息，包括：登录名、分公司、部门、电子邮件、办公、手工填写2事件分类是参见事件分类定义3事件性质是参见事件性质定义4事件来源是参见事件来源定义

29、5事件所属系统类型是参见事件所属系统类型定义6事件发生时间是针对故障：指的是业务中断的实际时间可能早于登记时间，需要手工填写针对其他：缺省值等于登记时间事件发生时间必须小于或等于登记时间7事件发生单位是树形目录三级，总公司省公司地市序 号信息项是否 必填说明8事件发生地点否事件发生的地点手工填写描述性字段，不做为日后数据索引、统计，默认为事件发生单位9事件简要简述是事件的简要描述手工填写10事件详细描述是对于整个事件内容的详细描述手工填写11分配对象是被分配的技术支持组按效劳目录自动分派12事件优先级是参见事件优先级定义13事件影响度是参见事件影响度定义14重复事件标记否标记为重复事件手工填写

30、15关联配置项否记录岀现故障的配置项代码系统自动关联16附件否上传附件提交事件工单时，系统自动产生17事件ID是事件单流水号系统自动产生18建单人受理人是创立事件请求工单的记录人19登记时间是在效劳台生成事件记录的时间系统自动产生20事件状态是参见事件状态定义21事件完成期限是对应每一个事件优先级，系统根据流程相关定义中 事件解决时限自动设定最终的 完成期限系统自动产生同14关联配置项否记录岀现故障的配置项代码手工填写同15附件否上传附件一、二、三线尝试解决时填写：22业务恢复时间是针对故障的业务恢复实际时间手工填写23事件日志是反映事件信息项的变化历史， 如一个事件在处理过程中事件状态变化的

31、时间点等信 息系统自动产生24解决方案是事件解决方案的描述手工填写25故障厂商是记录故障厂商或集成商信息手工选择26重复事件标记否标记为重复事件手工选择一、二、三线尝试解决时，系统自动产生同19事件状态是参见事件状态定义序 号信息项是否 必填说明27实际开始时间是记录事件状态到 XX处理中的时间系统自动产生28事件解决人是事件的最终解决人系统填写29处理是否超时否参见 处理是否超时定义系统自动产生30实际完成时间是记录事件最后解决的时间系统自动产生31历时是“实际完成时间-“事件发生时间系统自动产生关闭工单时填写32用户反应是参见“用户反应定义33事件结束代码是参见事件结束代码定义34事件解决

32、人角色是参见 事件解决人角色定义35事件关闭时间是记录事件被关闭的事件6.2 事件性质根据cllT 支撑系统的业务要求和管理要求，定义如下四类事件:编号代码描述1故障指因IT支撑系统错误或反映支撑系统局部或全部功能不能正常使用的 报障；2申告与IT支撑系统相关的用户投诉，如信息技术部各处室等业务受理部门 转来的因支撑系统问题引发的投诉3告警监控平台自动产生的没有影响到系统正常使用的告警4咨询指对系统操作、业务流程等方面的求助和询问6.3 事件来源非必填项事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种:编号代码描述1用户报告用户或维护人员通过/邮件/ 报告的事件，效劳台人员手工创立

33、事件单2内部IT人员开单IT部门内部一线/二线人员提交的事件3监控系统6.4 事件所属系统类型根据目前信息技术中心支撑的应用系统和二级分类的划分定义事件所属系统类型，当事件发生时，应该 由效劳台初步定位是哪个系统及二级分类出现问题，由一线进行进一步的明确。业务系统分类子业务系统分类简称办公管理IT效劳管理系统ITSM综合办公系统电子邮件系统请填写简称电子商务网上招聘系统CORS管理决策团体年金报表子系统GARS财务电脑管理系统CLAF集团财务电脑管理系统GCLAFcl财务报表辅助系统EASY-REPORT大中城市业绩考核分析系统CSIS财务分析系统LIFA根底率分析系统EAS精算系统ATMS每

34、日业务快报系统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讲师管

35、理系统TMIS会员管理系统2005MMIS个人代理人营销支持系统E-MSS大客户支持系统anntsuport网络查询系统netquerycl呼叫中心系统CALL CENTERcl短信系统SMS其他其他系统类OTS说明：第一层为其它的话，分公司可以对其子类可以扩充并提交到总公司，由总公司统一协调配置6.5 事件分类分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。事件的分类层次设计不超过三层，第一级分类，称之为一级分类，第二级分类，称之为"二级分类，第三级分类，称之为三级分类。一级分类二级分类三级分类效劳器SR小型机EPSPC效劳器SPC存储设备RD磁盘阵列RAD磁带库

36、TAP其他存储设备OTR网络NW交换机SWT网络交换机SWT光纤交换机FST路由器RUT防火墙FRWVPN网关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应用系统模块A

37、PM其他应用APO6.6 事件优先级优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级紧急、高、中、低。编号优先级代码描述1紧急重要系统不可用因系统原因数据处理错误，导致大量用户投诉来自新闻媒体、消费者协会、国家行政机关工商、物价等的反映或申告 局部重要数据丧失，且无法全部恢复2高业务系统不可用，影响面为全北京市、某个分公司，或者多个非关键地区系统中的某一业务不可用，影响面为全北京市、某个分公司，或者多个非关键 地区3中一般性系统故障4低一般单个用户申告业务咨询当故障发生时，为了在判断优先级时增强实际可操作性，可以根据故障的影响范围和业务系统的关键程 度

38、在优先级映射表中定位优先级。故障的影响范围可以根据配置项中定义的“影响范围和用户报障描述来 确定。系统影响范围全北京市或 某一分公司至少包括一 个关键地区多个非关键地区一个非关键地区系统名称任一模功能点A紧急紧急高高功能点B高高系统一影.响范围全北京市或 某一分公司至少包括一 个关键地区多个非关键地区一个非关键地区块功能点C高高6.7 事件响应时限和解决时限在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制，一方面，需要各工程师协同合 作，在解决事件的时候应该有时间的概念，同时，也要求事件经理必须实时地催促事件的解决，对于影响度 为高或者紧急的事件，需要及时通告事件经理，同时，如果

39、该事件的响应或解决超过了时限，需要通告事件 经理，同时也要根据具体情况通告给其他相关管理人员。响应时限指的是事件状态从“已登记到“一线处理中经过的时间;24X7工作时间解决时限指的是事件状态从“已登记到“已解决经过的时间；事件优先级对应的事件响应时限和解决时限参考下表以下时间是编号优先级代码响应时限要求解决时限要求1紧急30分钟4小时2高1小时8小时3中4小时48小时4低8小时72小时事件发生时的通告定义通知人员列表的用途：当 IT效劳管理平台收到事件时，自动按照表中的人员列表发出邮件或短信通知。优先级别通知人员列表紧急部门主管，相应事件经理，一、二、三线支持人员高部门主管，相应事件经理，一、

40、二线支持人员中通知一、二线支持人员低通知一线支持人员超出响应时间的通告定义通知人员列表的用途：当 IT效劳管理平台判断到响应时限已经超出，那么自动按照表中的人员列表发出邮 件或短信通知。优先级别通知人员列表事件响应时限紧急部门主管，相应事件经理，一、二、三线支持人员30分钟高部门主管，相应事件经理，一、二线支持人员1小时中部门主管，相应事件经理，-、二线支持人员4小时低相应事件经理，效劳台/ -、二线支持人员8小时超出和即将超出解决时限的通告定义通知人员列表的用途：当IT效劳管理平台判断到解决时限已经或即将超出，那么自动按照表中的人员列表发出邮件或短信通知。优先级别通知时间通知人员列表事件解决

41、时限紧急3小时部门主管，相应事件经理，一、二、三线支持人员4小时4小时部门主管，相应事件经理，一、二线支持人员高7小时部门主管，相应事件经理，一、二线支持人员8小时8小时部门主管，相应事件经理，一、二线支持人员中47小时部门主管，相应事件经理，一、二线支持人员48小时48小时部门主管，相应事件经理，一、二线支持人员低71小时相应事件经理，一、二线支持人员72小时72小时相应事件经理，一、二线支持人员6.8 事件影响度事件影响度用于衡量事件所影响业务的严重程度。严重程度通常通过事件所影响的人数、关键系统数以及效劳故障所造成的损失来设定。定义事件影响度等级的因素有：是否影响了核心业务所影响的用户数

42、效劳失效的影响范围和时长事件影响度在事件的生命周期中是可以改变的，例如，初始等级为严重的故障会随着效劳失效的时间变成重大故障，所以事件的影响度应在事件得到解决效劳恢复后重新确认。事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。编号影响度 代码事件性质描述1重大故障全国半数以上地区或关键地区的业务系统中断超过6小时；全国半数以上地区或关键地区的营业、综合帐务、客服中任一业务 中断超过3小时；全国半数以上地区或关键地区的综合结算业务处理中断超过24小时；编号影响度 代码事件性质描述半数以下地区全业务中断超过 6小时；申告对人寿公司造成巨大损失产生严重后果和不良影响的；

43、来自新闻媒体、消费者协会、国家行政机关的反映或申告；2严重故障全国半数以上地区或关键地区的业务系统中断大于10分钟、小于6小时；全国半数以上地区或关键地区的营业、综合帐务、客服等业务中断 均大于10分钟、小于3小时；全国半数以上地区或关键地区的综合结算业务处理中断大于2小时、小于24小时；半数以下地区全业务中断大于10分钟、小于6小时。申告数据错误导致产生大量的错单；涉及到高额问题的申告； 用户在营业现场反映剧烈3一般故障系统内局部岀现问题，不影响整个系统运行，不影响业务处理的故 障申告不属于重大申告和严重申告的用户申述告警不影响系统的监控平台告警4无咨询一般数据查询或者使用指导6.9 事件状

44、态事件状态代码说明事件所处的处理状态，事件状态如下:编号代码描述1已登记新开事件记录或事件已创立2分配到效劳台事件已分配给效劳台人员3效劳台处理中效劳台人员已接手处理事件4分配到一线事件已分配到一线支持，一线还未响应5一线处理中一线支持人员已接手处理事件6分配到二线事件已分配到二线支持，二线还未响应7二线处理中二线支持人员已接手处理事件8分配到三线事件已分配到三线支持，三线还未响应9三线处理中三线支持人员已接手处理事件10已解决事件已解决，支持人员联系用户验证事件是否获得解决11关闭事件已关闭事件状态变迁图用来标明：当一个事件单处于某个状态时，它可以去到的下一个状态。当前状态为已登记状态时，可

45、迁移的状态状态合法描述已登记否 ：已登记为事件单初始状态分配到效劳台是用户提交事件请求，首先分派到效劳台效劳台处理中否分配到一线否一线处理中否分配到二线n否二线处理中否分配到三线否 丁三线处理中否已解决否已关闭否当前状态为分配到效劳台状态时，可迁移的状态状态合法描述已登记否分配到效劳台是效劳台的人员将分配给本人的事件单分配给效劳台或者效劳台的 其他人员效劳台处理中是效劳台人员开始尝试处理事件单分配到一线是效劳台组人员将事件单分配给一线支持组一线处理中否分配到二线否二线处理中否分配到三线否三线处理中否已解决否'已关闭是当事件处理范围不在信息技术中心或误报或可忽略时，可直接天 闭当前状态为

46、分配到一线状态时，可迁移的状态状态合法描述已登记否：分配到效劳台否效劳台处理中否分配到一线是一线支持人员将分配给本人的事件单分配给一线支持组或组内 的其他人一线处理中是一线支持人员，接受分配的事件单，并开始处理分配到二线否二线处理中否分配到三线 V否：三线处理中否已解决否已天闭否当前状态为“一线处理中状态时，可迁移的状态状态合法描述已登记否分配到效劳台否效劳台处理中否分配到一线是一线支持人员将分配给本人的事件单分配给一线支持组或组内 的其他人一线处理中否分配到二线是一线支持人员将事件单分配给二线支持组或二线支持组内的其 他人二线处理中否分配到三线1否三线处理中否已解决是一线支持找到解决方案或者

47、变通方法，解决了分配的事件单已天闭否当前状态为分配到二线状态时，可迁移的状态状态合法描述已登记否：分配到效劳台否效劳台处理中否分配到一线否一线处理中 否：分配到二线是二线支持人员将事件单分配给二线支持组或二线支持组内的其 他人二线处理中是二线支持人员，接受分配的事件单，并开始处理分配到三线否1三线处理中否已解决否已天闭否当前状态为二线处理中状态时，可迁移的状态状态合法描述已登记否分配到效劳台是效劳台处理中否分配到一线否一线处理中否分配到二线是二线支持人员无法处理该事件单，或者分配错误，将事件单重新分配给二线支持组或二线支持组内其他人员二线处理中否分配到三线是二线支持人员将事件单分配给三线支持组

48、或三线支持组内的其 他人三线处理中:否已解决是二线支持找到解决方案或者变通方法，解决了分配的事件单已关闭否当前状态为分配到三线状态时，可迁移的状态状态合法描述已登记否：分配到效劳台否效劳台处理中分配到一线否一线处理中 否分配到二线否二线处理中否分配到三线是三线支持人员将事件单分配给三线支持组或三线支持组内的其 他人三线处理中是三线支持人员，接受分配的事件单，并开始处理已解决否已关闭否当前状态为三线处理中状态时，可迁移的状态状态合法描述已登记否分配到效劳台否效劳台处理中否分配到一线否一线处理中 :否分配到二线是二线处理中否分配到三线是三线支持人员将事件单分配给三线支持组或三线支持组内的其 他人三

49、线处理中否已解决是三线支持找到解决方案或者变通方法，解决了分配的事件单已关闭否当前状态为已解决状态时，可迁移的状态状态合法描述已登记否分配到效劳台否效劳台处理中否分配到一线否一线处理中否分配到二线否二线处理中否分配到三线否三线处理中否已解决否已关闭是效劳台在关闭事件单的时候，需要填写客户反应和结束代码当前状态为已关闭状态时，可迁移的状态不迁移至任何状态。6.10 事件结束代码事件结束代码说明了事件是在何种情况下关闭的，结束代码如下:编号代码描述1成功解决事件获得成功解决2变通方法解决事件已通过变通方法或者临时措施获得解决， 步的根源分析但是需要进行更进一3不成功事件没有获得解决用户没有认可解决时使用4消失事件自行消失5误报不属于IT部门管理范围的事件6可忽略如通过其他系统接口或监控系统提交的信息，经确认属于无效信息6.11 事件解决人角色事件解决人角色用来标明该事件单最终解决的角色是效劳台还是