《IT服务管理项目事件管理流程设计手册[1].docx》由会员分享，可在线阅读，更多相关《IT服务管理项目事件管理流程设计手册[1].docx（38页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、事件管理流程手册 事件管理流程设计手册 文档信息工程名称：工程编号：工程经理：工程阶段：文档名称：文档编号：文档起草人：起草日期：当前版本编号：版本日期：相关文档：分发名单来自 From日 期 / /Email给 To行 动*截止日期 / /Email*：行动类别：批准，复审，通知，存档，修改，其它请指明版本记录版本号版本日期修改者说 明文件名目 录1.文档介绍5文档简介5文档用途5文档结构5术语62.事件管理流程简介7流程根本概念7流程目的8流程范围9流程主要内容9流程业务价值103.事件管理流程设计10流程执行原那么103.1.1.流程常规原那么103.1.2.责任制原那么113.1.3.
2、事件分派原那么113.1.4.事件重分派原那么123.1.5.重复/复发事件原那么123.1.6.事件关闭原那么123.1.7.事件通报原那么133.1.8.事件升级原那么143.1.9.流程关联原那么14流程相关定义153.2.1.事件信息项153.2.2.事件来源183.2.3.事件性质193.2.4.事件分类193.2.5.事件优先级203.2.6.事件时限213.2.7.事件状态223.2.8.事件结束代码22流程角色和职责定义233.3.1.事件流程负责人233.3.2.事件流程经理243.3.3.效劳台支持人员含1线、线253.3.4.二线支持人员263.3.5.三线支持人员263
3、.3.6.四线支持人员26流程概要设计27流程详细设计293.5.1.事件检测与记录293.5.2.事件分类和初步支持303.5.3.事件调查和诊断323.5.4.事件解决和恢复333.5.5.事件关闭34与其他流程的关系36流程衡量指标及报表374.附录38事件管理流程相关表格38图目录图 31 XXX事件管理流程概览3图 32 事件检测和记录3图 33 事件分类和初步支持3图 34 事件调查和诊断3图 35 事件解决和恢复3图 36 事件关闭3图 37 XXX效劳管理流程关系图3表目录表 31 事件升级机制3表 32 事件信息项3表 33 事件来源3表 34 事件性质3表 35 事件分类3
4、表 36 事件紧急程度3表 37 事件优先级矩阵3表 38 事件时限3表 39 事件状态3表 310 事件结束代码3表 311 事件管理KPI列表3381. 文档介绍1.1 文档简介本文档XXX事件管理流程设计手册,是XXX信息技术总部以下简称XXX团队制定的事件管理流程文档。通过制定该流程，可以帮助XXX信息技术总部团队对主动监控发现以及用户上报的故障和效劳请求进行快速响应和快速处理, 尽快恢复中断或受影响的用户业务。通过该流程的标准，可进一步改良XXXIT效劳向用户提供的效劳水平和效劳质量,确保用户对效劳价值的认同和肯定。本文档是依据目前XXX的IT效劳状况而制定的事件管理流程,进一步的流
5、程更新将移交由XXX效劳团队负责。1.2 文档用途本文档既是本次IT效劳管理工程事件管理流程的交付物,也可作为XXX效劳团队进一步改良事件管理流程的蓝本,读者对象为与事件管理流程相关的所有管理与技术人员.本文档所描述的流程在IT效劳管理中有许多作用,列举如下:q 减小突发事件对业务的影响；q 最优化支持资源，提高工作效率；q 屏蔽错误事件和效劳请求；q 根据影响业务轻重缓急安排资源解决事件，保障有效IT运营；q 加强有形监控和及时反应；q 提升用户对效劳的认知度和满意度；q 提供管理信息；1.3 文档结构本文档作为XXX事件管理流程设计手册，主要包含针对XXX效劳运营中对用户故障及用户请求处理
6、等相关人员及活动的定义和描述。各章节中内容概要如下：q 文档介绍主要对文档的目的、用途及结构进行简要描述，并就文档当中出现的术语进行了说明。q 事件管理流程简介主要对事件管理流程的根本概念、目的和范围进行了介绍。同时简单梳理了事件管理流程中包含的主要活动内容，最后对事件管理流程对组织及用户的业务价值进行了相关阐述。q 事件管理流程设计该局部为本文档的重点章节。在该章节中，首先对事件管理流程的相关执行原那么和代码进行了描述；其次，对事件流程相关角色的职责和技能要求进行了说明；基于流程原那么和角色定义，进而对事件管理的概要设计流程及详细设计流程进行了充分定义，并给出了事件管理流程的关键衡量指标，以
7、保证对流程运行的监控、管理和改良。q 附录与事件管理流程相关的附属内容，都将在附录中进行补充说明。1.4 术语q 效劳台在ITIL中， 效劳台从根本上来说提供了用户和IT部门的唯一接口。此项功能常常通过集中的效劳台进行表达。效劳台的根本目的是提供一线支持，并通过变通方法、解决方案或升级到二线支持等手段帮助用户恢复到正常工作状态。q 事件管理ITIL流程，是负责解决所有的IT事件、问题和用户请求等的管理流程。它的目的是尽快恢复被中断或受到影响的IT效劳，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。q 问题管理ITIL流程，是负责对事件进行深入分析，找出根本原因并提供解决方案的管
8、理流程。它的目的是主动防御，找出根本原因并对其铲除，所以它与事件管理流程有显著的不同，以“治本为最终目标。q 变更管理ITIL流程，是负责对生产环境中支持IT效劳的各种根底架构设备和应用系统的变更操作进行记录、分类、评估、方案和协调的流程。它的目的是在权衡“风险和“效率的前提下，对变更操作进行有效的控制，以保证任何变更对IT环境和其所支撑的IT效劳的影响最小。q 发布管理ITIL流程，是负责对应用系统上线过程的全局管理和控制。管理范围涉及测试环境、预发布环境和生产环境等，旨在通过对发布单元的生命周期各个阶段的控制保证其平安稳妥的进入生产环境，而不引入新的缺陷或故障。q 配置管理ITIL流程，配
9、置管理负责描述，跟踪和汇报所有IT根底架构中的每一个设备或系统的管理流程。这些设备和系统被称为配置元素CI。每一个CI必须有效管理，跟踪和控制以支持IT效劳和根底设施成功运行。q 配置管理数据库CMDB是在配置管理流程中用于记录企业所有IT相关配置元素信息及其相互关系而建立的数据库。q ITIL IT Infrastructure Library，是英国政府在1987年制定的有关IT效劳管理的方法论，现已成为事实上的IT管理标准。2. 事件管理流程简介2.1 流程根本概念事件管理流程通过提供效劳台作为日常IT支持接口，由IT支持人员根据流程定义，快速响应和解决IT用户的效劳请求、突发事件、投诉
10、反应等，最大化地减少突发事件对用户业务活动的影响，最终确保SLA目标的实现。事件管理流程相关的几个关键词汇解释如下：“日常支持接口：即效劳台，该接口将采用集中效劳方式，向所有IT用户提供唯一效劳窗口，按照业务需求，提供相应级别的支持效劳。“IT用户：指的是指XXX效劳的使用者，他们使用XXX提供的IT效劳来支持相关日常业务。“IT支持人员：指的是XXX 效劳团队中IT运维和支持人员的统称，包括一线人员和二线人员等，可能涉及XXX体系中的相关的开发、支持和运维等团队。 “一线支持：指效劳台的通用座席，向IT用户提供一线支持效劳，以下提到的效劳台人员即一线支持人员。“线支持：指机房值班人员交易系统
11、故障时和桌面维护人员桌面故障时)，在桌面类和机房交易系统相关事件处理过程中实施IT支持效劳； “二线支持：主要由各职能小组运维工程师组成，协助效劳台一线人员参与事件处理，相对一线支持人员，二线支持具有更高更专业的技能。“三线支持：指各职能小组组长，在复杂度较高事件或二线支持无法解决事件时负责协调小组内部人员进行事件处理，三线支持更多的强调管理协调职能。“四线支持：指XXX开发团队和供给商等。“事件：指XXX在用户IT环境中发现的所有非正常事件，对现有的效劳造成影响或中断。例如：效劳器宕机、网络中断、应用不可用等。从来源上来分，主要包括由信息技术总部内部人员发起的事件以及有用户报告的事件等。 “
12、效劳请求：指用户提出的关于标准效劳、培训、文档、信息等方面的请求，以及针对IT效劳使用的咨询等，通常并没有发生IT组件方面的故障。例如：请求培训、寻求咨询等。效劳请求是一种特殊类型的事件。 “投诉反应：指由用户提出的对于IT效劳质量或效劳方式的抱怨或改良建议，通过效劳台统一接受，并进行相应处理。2.2 流程目的事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括： q 在本钱允许的范围内尽快恢复IT效劳- 快速响应故障及效劳请求- 用户在线获得帮助- 沟通事件解决的状态 - 和用户确认事件的解决q 进行事件控制- 按标准记录事件- 就事件的优先级，影响度 进行分类-
13、 分析，诊断，必要时进行升级- 监视并结束事件- 进行定期效劳流程回忆q 提供IT管理信息- 人力资源利用情况- 故障处理情况- 支持效率2.3 流程范围XXX事件流程管理范围包括所有用户与XXX信息技术总部内部的事件、效劳请求和投诉反应等。其中：q 不包括现有应用系统新增功能需求q 不包括用户对于信息类设备和应用系统的新需求q 不包括新系统开发需求2.4 流程主要内容事件管理流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容：q 事件接收和记录 这个环节是事件管理流程的起点。所有监控系统或用户报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事
14、件的诊断和解决并通知相关人员。在此步骤中将会收集创立事件记录所需的信息。该环节的关键是信息的准确性和完整性。q 分类和初步支持对于每个事件，需要确立优先级和分类。假设没有现成的解决方案Solution或变通方法Workaround，该事件将分配给适宜的支持人员对此进行调查。q 调查和诊断 假设支持人员无法利用现成方案解决事件，可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复效劳的临时措施，必要时可调用多名支持人员以寻求解决措施。q 解决和恢复支持人员实施事件的解决方案，并将解决完毕的事件转回效劳台，由效劳台通知用户解决的结果，并得到用户确实认。q 事件升级对于高优先级的事件，效劳
15、台应立即上报给事件经理和相关的管理层，由事件经理决定事件的处理方式，确保其得到最快速的解决。当事件处理超过预期解决时限，应通知相关处理人员和管理层，以引起处理人员和管理人员的重视和参与。q 结束事件当用户确认事件解决后，可结束该事件。2.5 流程业务价值XXX事件管理流程将在多个方面对“XXX效劳业务产生积极作用，具体表现在以下几个方面：单一联系点 通过在团队内部建立效劳台，作为与用户沟通联系的单一联系点。对用户方发生的故障及用户上报的效劳请求进行快速响应和统一管理，对内部效劳支持资源进行合理协调和调配。同时，效劳台作为IT效劳窗口，也进一步维护和加强了与用户的关系，为提高用户体验和满意度起到
16、了重要作用。用户业务尽快恢复 通过合理调配资源，使用知识库等相关支持工具，对不同级别事件选择各自的解决时限，对用户被中断或受影响的业务进行快速响应和恢复。内部团队协作加强 为效劳支持团队成员分配角色，并清晰界定职责。通过事件管理流程将团队成员进行有效的连接，加强内部团队协作和沟通的有效性和工作效率。效劳质量控制和改良 通过定期提交流程相关指标和报表至管理层，以实现对流程的监控和管理，同时为效劳质量的改良奠定根底。3. 事件管理流程设计3.1 流程执行原那么3.1.1. 流程常规原那么q 所有在流程范围内发生的事件，都应该被完整准确的记录下来，记录的信息应足够详细，包括事件处理交互过程，详细的解
17、决方案和相关的附件等。q 事件处理过程中，在需要寻求第三方的情况下，遵循下述原那么：- 根据事件实际处理情况，各二线或三线支持寻找相应供给商- 在供给商参与解决事件的过程中，事件当前处理责任仍保存在二线或三线人员处q XXX效劳支持体系是由信息技术总部全体人员共同组成的，事件的处理过程中必须加强一线和二线的沟通，沟通的方式优先使用工具效劳管理平台，在需要的时候必须辅助 、短信、邮件等手段。q 所有支持人员优先处理优先级较高的事件。q 对于来自于效劳台转入的事件包括故障/效劳请求/咨询/投诉建议，首次接听 并进行支持的效劳台人员负责在系统中进行登记，并由该员工成为该事件在XXX范围内的责任人，确
18、保事件在在XXX内部得到有效跟踪、解决，并将解决结果反应给效劳台。q 每月定期产生事件管理报表，分析效劳质量，对重大事件、重复发生的事件或者利用变通方法解决的事件，应提交问题管理流程进行问题定义分析和解决，并定期对这些事件进行评估跟踪。q 建议每三个月对流程进行回忆，包括流程执行效率和流程支持工具的有效性，以改良和优化事件管理流程。3.1.2. 责任制原那么责任制原那么用来确保每个事件在任何时段都有适当的人员负责。q 由监控系统上报的事件，对故障进行识别并在系统中记录的效劳台人员是该事件的责任人，确保事件得到有效跟踪与解决，并负责事件单的关闭q 由用户 上报的事件，首次接听 并进行支持的效劳台
19、人员负责在系统中进行登记，并由该员工成为该事件的责任人，确保事件得到有效跟踪与解决，并负责事件单的关闭q 效劳台员工换班时，由效劳台值班经理进行事件重新分派，事件责任人也由此转移q 事件被效劳台人员转至二线人员或第三方后，二线人员/第三方成为该事件的当前责任人，但效劳台人员仍然是事件的整体负责人，有义务对事件处理状态按相应策略进行监控，并及时反应给用户，保证事件的处理过程对用户充分透明。3.1.3. 事件分派原那么事件分派原那么是确保事件在效劳目标时段内处理和解决的重要因素。q 效劳台一线支持人员在规定的一线处理时限内，可按情况选择转给其他在值效劳台一线支持人员进行处理q 效劳台一线支持人员在
20、规定的一线处理时限内不能解决事件时，原那么上根据事件分类分派到相应二线支持人员。q 在特定情况下，比方二线支持人员的非工作时间内，效劳台一线支持人员在派单后利用 方式通知二线人员相关事宜。q 桌面类故障导致事件直接由线桌面运维小组进行处理q 开市期间交易系统故障，直接由线机房座席接听处理。q 效劳台一线支持人员在判断事件为交易系统故障后，应第一时间按策略通报机房处理，不能明确界定是否是交易系统故障，亦应交机房处理。3.1.4. 事件重分派原那么q 二线支持接受效劳台分派事件后，如果该事件不属于本人支持范围或者自身能力无法处理，二线人员需首先注明原因，然后将事件返回到效劳台，由效劳台重新分配。q
21、 为提高事件解决效率，应当尽量减少事件单重分派的几率。事件单的重分派次数不应该超过2次。q 同组的事件单再分派不被监控；q 任何跨组的事件单再分派将会报告给事件经理；q 事件再分派超过2次，事件单将升级给事件经理；3.1.5. 重复/复发事件原那么重复事件 如果被报告的事件与某个已经创立且尚未解决的事件单病症相同，那么该事件被认为是重复的。将会为此重复的事创立新的事件单，并标注此单为“重复并与原始事件单相关联。原始事件将被标注为“主事件复发事件3天内同一用户，同一件事如果报告的事件与已经关闭的事件相同，该事件被认为是“复发的事件单。这意味着为了解决事件而采取的解决措施失败了或失败或误再报。此时
22、，应当创立一个新的事件单，复制原始事件单的内容，并说明这是复发的事件。3.1.6. 事件关闭原那么q 事件单的关闭必须由效劳台对应线支持人员完成，但是事件经理可以超越此规那么。其他人无权关闭事件单。二线支持人员确定解决方案并解决事件后，必须把事件返回到效劳台。q 事件单的用户可以要求关闭此事件单，例如：误报、错报事件。关闭事件单由事件单对应一线支持人员负责。q 效劳台人员关闭事件前，需获得客户对解决方案确实认和反应。q 关闭事件时，根据实际解决情况填写事件的结束代码。q 已关闭的事件单不允许重开。如果事件重复发生，那么创立一个新的事件单，并标识为复发事件。q 对于以“变通方法解决或 “不能重现
23、结束代码关闭的事件，需通知问题经理对此类事件进行分析并在必要时生成问题，通过问题流程对问题进行根源分析并提供解决方案。 q 所有优先级为最高的事件在关闭后，需通知问题经理对此类事件进行分析并在必要时生成问题，通过问题流程对问题进行根源分析并提供解决方案。q 对于未及时取得用户反应的已解决事件，系统将对其保存3日。3日内效劳台人员应至少每天主动与用户联系1次。假设3日后仍未得到用户有效反应，系统将自动关闭事件，并标识结束代码为“自动关闭字样。3.1.7. 事件通报原那么对于监控系统自动发现的告警信息，效劳台人员有责任对其进行识别。如确认为一条事件，那么应首先在第一时间通报相应用户和事件经理，然后
24、在效劳管理平台中进行记录。通报策略具体如下：通报方式q 用户工作时间内采用正式的通知方式进行通报q 用户非工作时间采用邮件方式进行通报q 与用户通报相关的其他方式参考与用户签订的SLA中的具体定义q 采用邮件的方式通知事件经理； q 如果由于用户原因第一时间无法完成通报，应首先在效劳管理平台中登记一条事件，并置于“挂起状态，相关效劳台人员有责任在开单后每隔5分钟主动尝试联系用户3次。假设3次后仍无法取得联系，那么应在事件工作日志中注明“无法联系到用户的字样，并进行后续处理；假设3次内取得联系，那么在与用户确认故障后，取消事件“挂起状态并进行后续处理。通报对象q 依照事件分类表中定义，向用户部门
25、相关人员通报q 最后通报事件经理通报内容q 事件简要描述q 可能受到影响的用户方业务或范围q 确认是否为用户方运维操作导致q 可能导致事件的原因q 预计解决事件的时间点3.1.8. 事件升级原那么制定升级原那么的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和管理人员，引起足够的重视，协助提供适宜的资源，从而快速找到解决事件的方案。q 优先级为最高的事件，需要立即事件升级，同时，事件继续按事件管理流程进行快速处理q 超出规定的响应或者解决时限之后，需要立即升级事件，同时，事件继续按流程进行快速处理q 事件重复派单超过三次直接升级给事件经理具体事件升级机制如下表所示：表 31 事件升级
26、机制事件升级机制小组技术经理事件经理运维经理技术总部领导公司领导优先级15分钟5分钟10分钟10分钟15分钟优先级21小时1小时1小时小时优先级32小时2小时优先级44小时4小时3.1.9. 流程关联原那么q 和问题管理的关联- 一线支持在解决事件的过程中，可以通过问题记录查找相应的解决方案- 通过分析事件记录，形成问题，并使该问题与相关事件建立关联- 通过事件单和问题单的关联，效劳台人员对问题的解决状况进行跟踪并和用户保持沟通- 对高优先级事件或者“变通方法解决或“无法重现关闭的事件，由问题管理流程生成问题进行进一步分析，直到确定根本原因，得到根本解决。事件单和问题应建立关联。q 和变更发布
27、管理的关联- 事件处理过程中，如果需要对相关IT组件进行变更不在标准变更清单内的变更，必须按照变更管理的定义，提交变更请求变更单必须和事件单建立关联，变更完成后，继续事件的处理。- 高优先级事件的处理过程中，如果需要对相关IT组件进行变更，必须按照变更管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和事件单建立关联。q 和配置管理的关联- 事件处理过程中，可以通过配置管理查询相关的配置项信息尤其是关系信息以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位- 事件处理过程中，如果可以将故障定位到某个配置项，那么必须将事件单与该配置项关联3.2 流程相关定义3.2.1. 事件信
28、息项事件单必须包含如下事件信息项，XXX效劳团队可以在此根底上进行扩充：表 32 事件信息项序号信息项说明1事件ID事件单流水号系统自动产生2事件请求人事件申报人的信息，包括：姓名、公司、部门、电子邮件、办公 、 3事件登记时间在效劳台生成事件记录的时间系统自动产生4事件登记人事件开单人的信息，包括员工姓名、员工ID、联系方式等系统自动产生5事件发生时间针对故障：指的是业务中断的实际时间 可能早于登记时间，自动设置或者手工填写；针对用户请求：缺省值等于登记时间。事件发生时间必须早于或等于登记时间。6事件发生地点事件发生的位置信息7事件来源参见“事件来源定义8事件标题事件的简要描述9事件描述对于
29、整个事件内容的详细描述10事件性质参见“事件性质定义11事件分类参见“事件分类定义12事件状态参见“事件状态定义13事件影响范围参见“事件影响范围定义14事件紧急程度参见“事件紧急程度定义15事件优先级参见“事件优先级定义16事件完成期限对应每一个事件优先级，系统根据流程相关定义中“事件解决时限自动设定最终的完成期限 系统自动产生17事件分配工作组被分配的支持小组18事件分配人员被分配的支持小组内成员19事件工作日志反映事件处理过程的信息 20解决方案/变通方法事件解决方案/变通方法的描述21事件解决人事件的最终解决人22事件解决人角色参见“事件解决人角色定义23事件解决时间记录事件状态为“已
30、解决的时间系统自动产生24处理是否超时参见“处理是否超时定义系统自动产生25涉及第三方支持XXX和第三方集成商名称26关联配置项记录出现故障的线路编号或者CPE设备编号27关联的问题单号记录由事件引发问题时，关联的问题单号28关联的变更单号记录由事件引发变更时，关联的变更单号29事件结束代码参见“事件结束代码定义30事件关闭时间记录事件状态为“结束的时间系统自动产生31重复事件标记标记为重复事件32对应告警ID事件如来自于监控系统告警，那么填写对应告警的ID；假设为用户自动上报，此处为空不填33 用户满意度用户对事件处理的满意程度。分值从5分至1分，分别对应非常满意、比拟满意、一般，不太满意及
31、很不满意34用户反应信息用户对事件处理过程及结果的意见或建议35附件信息事件相关附件信息IT运维事件单含事件、信息咨询、效劳请求事件单编号： 例如：200708220001受理事件根本信息 受理时间2007年 月 日 时 分受理人用户所属部门申报人申报人 申报人EMAIL申报方式 邮件 工作台 现场 其他受理人根据事件形成事件信息效劳分类故障 问题 改良 咨询 业务需求 投拆 其他 事件分类桌面终端类：PC机故障 局域网故障 软件故障 外设故障根底设施类：硬件故障 操作系统/DB/系统软件故障 网络故障 机房环境故障(空调、UPS等)应用系统类：可用性 响应速度 功能性 易用性 应用系统列表选
32、择影响度：人员分类报障人员分类VIP1 VIP2 普通影响度：受影响人员分类单内部客户 单部门 2个部门以上影响度：单外部客户 单营业部 24个营业部 4个营业部以上影响度：关键设备关键设备(列表选择) 非关键设备 未知影响度：典型事件分类典型事件列表选择 无对应典型事件事件描述事件影响度事件紧急度1-危急(5分钟) 2-紧急(高,30分钟3-紧急(中,2小时) 4-紧急(低,4小时) 5-普通(4小时以上)事件处理优先级事件完成方案时间受派人员处理人员记录响应时间 月 日 时 分处理人员效劳方式 Email 现场 远程终端 送修 其它原因及故障分析：解决方法：是否需要发起技术问题处理 是 否
33、 (去除？完成时间 日 时 分用户反应用户填写处理结果全部解决 局部解决 未解决满意度评价非常满意 较满意 满意 不满意用户意见(可选)事件优先级升级记录事件结束方式自动结束 客户确认结束 转为其它 事件经理结束事件对应其它流程编号(转为其它时填写转为同工具其它流程对应编号 转为NOTES其它流程流程名称(列表)对应编号最终事件分类效劳台填报故障类型问题类型咨询类型需求类型投拆其他知识库评价有对应完善知识库 知识库需完善 无对应知识库 3.2.2. 事件来源事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种：表 33 事件来源事例来源 描 述 电子邮件 效劳台通过电子邮件收到一个请求
34、。 效劳台通过 收到一个请求。 效劳台工具Help Desk 效劳台通过Web系统流程管理平台收到一个请求。 来访用户直接到电脑部工作间找相关工程师报障主动监控效劳台通过系统网络管理工具主动监控得到的请求。 3.2.3. 事件性质事件性质用来说明事件的概要类型，具体可以包含以下几种：表 34 事件性质请求类型 描 述 事件 出现对效劳造成影响的不正常现象 信息咨询 对与业务或IT相关杂项信息联系人、 号码，状态查询等的请求 效劳请求 对外宣布的效劳不含新业务需求 3.2.4. 事件分类事件分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。当事件发生时，应该由效劳台初步分析和定位
35、事件的分类，一方面便于与历史事件/问题或者知识库的匹配，另一方面也便于选择适宜的二线或者第三方进行分配。事件最终分类可由后续支持人员作进一步确实认，并在事件关闭前进行调整。事件的分类层次设计不超过三层，第一级分类，称之为“类别，第二级分类，称之为“子类，第三级分类，称之为“条目。XXX事件分类表分为三大类：桌面类、网络类、系统类表 35 事件分类流 程系统/类别模块/子类模块/子类说明使用部门典型事件二线责任人三线责任人四线责任人备 注各应用系统名称应用系统的模块名称模块业务功能说明使用该模块的业务部门填写根本原那么：客户化语言描诉处理该事件的工程师或职能小组3.2.5. 事件优先级优先级是事
36、件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源。在XXX效劳中，事件优先级可分为四级：P1最高、P2高、P3中、P4低。为方便效劳支持对于事件优先级的判断，XXX建议从事件影响程度和事件紧急程度两维来进行优先级定位。事件的影响程度主要是对事件发生的关键程度以及事件发生后的影响范围综合考虑得出。在XXX业务中，要考虑以下几个方面：q 用户身份q 受影响用户数量和范围q 受影响设备q 受影响系统具体影响程度判定可直参考附件中的影响度判读资料。事件的紧急程度主要由事件本身是否涉及关键业务系统来进行判定，如事件涉及关键业务系统，那么认为紧急程度较高，需要尽快恢复；如事件不涉及关键业务系统，
37、那么认为紧急程度较低，可优先处理紧急程度较高的事件。在XXX业务中，事件紧急程度定义具体如下：表 36 事件紧急程度紧急度紧急度时间标准备注1-危急30分钟2-紧急高2小时3-紧急中4小时4-紧急低8小时5-普通8小时以上结合事件发生时的影响程度和紧急程度，可以通过下表确定事件的优先级：表 37 事件优先级矩阵事件优先级影响度高中低紧急度1-危急1232-紧急高2333-紧急中3444-紧急低3445-普通444注：对于用户上报的效劳请求，一般建议按优先级为P4低进行处理。3.2.6. 事件时限在事件处理过程中，对于事件应有响应时间限制、分派时间限制和解决时间限制，以保证事件处理过程的高效执行
38、。如果该事件的响应、一线分派、解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。响应时限指的是事件发生到在系统中登记所经过的时间；一线分派时限指事件登记时间到转给二线/第三方所经过的时间；解决时限指的是事件登记时间到事件状态变为“已解决所经过的时间。在XXX业务中，不同的事件优先级对应了不同的响应时限、一线分派时限及解决时限，具体如下：表 38 事件时限事件目标时间一线响应时间事件被分派并得到接受事件得到解决的时间备注优先级13分钟5分钟30分钟优先级25分钟10分钟2小时优先级310分钟20分钟4小时优先级410分钟30分钟8小时3.2.7. 事件状态事件状态代码
39、说明事件所处的处理状态，事件状态如下：表 39 事件状态状态代码 描述 待处理一个事件被记录或创立已分派一个事件已被分派给一线支持人员、二线支持人员或事件经理； 受理中-1线受理中线受理中-2线受理中-3线受理中-4线任何一个效劳台线支持人员或第三方供给商、开发部接受了事件并开始处理事件挂起事件信息不完整，或在某些情况下阻止事件受理员对事件进行处理，等待的原因为： 需要客户提供更详细的信息 优先级为1、2必须由事件经理挂起 不能联系到用户人员 升级到供给商处理 采购定单的批准 不可抗拒力原因 已解决为一个事件找到解决方案或变通方法已关闭事件经用户确认已关闭 3.2.8. 事件结束代码事件结束代
40、码说明了事件是在何种情况下关闭的，结束代码如下：表 310 事件结束代码事件关闭代码 描 述 成功事件被正常解决成功但有问题事件已通过变通方法解决掉，但是需要进行更进一步的根源分析。不能重现没有找到错误或不能重现故障操作错误用户错误如操作错误、理解存在误差等失败的错误、变通方法或已实施的变更失败，不能解决这个事件或问题3.3 流程角色和职责定义3.3.1. 事件流程负责人事件管理流程负责人从宏观上监控流程，确保事件流程XXX效劳团队范围内被正确的执行。随着业务需求和IT环境的改变，流程负责人必须定期或不定期进行流程分析、找出缺陷、进行改良，从而实现效劳能力的可持续提升。职责定义:q 确定管理流
41、程的衡量指标q 确保事件流程能够取得管理层的参与和支持q 确保事件流程符合业务实际状况和业务开展战略q 总体上管理和监控流程，建立事件流程运行机制q 确保事件流程实用、有效、正确地执行q 保持与其他流程负责人的定期沟通专业技能：q 理解内部和外部业务环境q 理解业务规划及开展战略q 理解用户需求q 充分理解业务相关IT政策、操作过程和标准q 流程的评估和设计能力q 良好的分析和规划能力q 理解事件管理流程q 理解效劳水平承诺处事技能：q 良好的矛盾管理技巧q 确定问题和趋势发现的能力q 良好的口头和书面表达能力q 工作主动性和领导能力q 决策能力 3.3.2. 事件流程经理事件流程经理负责事件解决过程中的协调和监控，以及事件升级的判断以及升级过程中的具体执行或协调。职责定义：q 监控事件流程运行状况q 负责对事件解决过程的资源协调，跟踪事件的解决进展q 当事件超时升级或重大事件升级时，负责或参与资源协调，解决事件q 确保和问题管理流程的有效合作q 基于事件处理状况，发现IT或业务相关的问题专业技能：q 充分理解业务相关IT政策、操作过程和标准q 根本了解业务系统环境q 具有流程的知识q 了解用户需求q 分析技能 q 理