ITSM-02-IM-01 事件和服务请求管理流程手册 v1.0.doc

XXX有限公司 ISO20000体系文件 事件和服务请求管理流程手册 文档信息 文档编号：ITSM-02-IM-01 文档名称： 事件和服务请求管理流程手册 起草人： 审核人： 批准人： 生效日期： 发布范围：内部使用 版本记录 版本号 版本日期 修改 修改章节 修改记录 目 录 1. 目的与范围 4 1.1 编写目的 4 1.2 适用范围 4 2. 制定依据 5 3. 术语定义 5 4. 流程角色及职责 5 5. 具体条款 5 5.1 流程执行策略 5 5.1.1 总体策略 5 5.1.2 优先级策略 6 5.1.3 目标解决时间策略 6 5.1.4 升级策略 6 5.1.5 重大事件策略 7 5.1.6 关闭策略 7 5.2 流程相关定义 7 5.2.1 事件和服务请求信息项 7 5.2.2 事件和服务请求服务方式 7 5.2.3 事件和服务请求性质 7 5.2.4 事件和服务请求分类 8 5.2.5 事件和服务请求状态 8 5.2.6 事件和服务请求关闭代码 8 5.3 事件管理流程输入及输出 8 5.3.1 流程触发条件 8 5.3.2 输入 8 5.3.3 输出 9 5.3.4 流程关闭条件 9 5.4 事件管理流程设计 10 5.4.1 作业流程图 10 5.4.2 流程活动说明 12 5.5 服务请求管理流程输入及输出 14 5.5.1 流程触发条件 14 5.5.2 输入 14 5.5.3 输出 14 5.5.4 流程关闭条件 14 5.6 服务请求管理流程设计 15 5.6.1 作业流程图 15 5.6.2 流程活动说明 17 5.7 KPI指标参考 18 6. 相关文件与记录 18 1. 目的与范围 1.1 编写目的 本文档编写的目的是有效地解决XXX有限公司技术中心的运维及IT服务部（以下简称“运维及IT服务部”）IT环境下所发生的事件和服务请求，并且可以有效地帮助实施其他相关服务管理流程。本文档所规定的IT服务是指运维及IT服务部为公司研发部门所提供的IT服务。针对研发部门在IT环境下所发生的事件和服务请求，提高IT服务的质量，为其业务提供更为优质的IT服务，并且可以有效地帮助实施其他相关服务管理流程，如问题管理、变更管理等流程。 通过本文档的定义，将建立一个完整的事件和服务请求管理系统，从而实现： q 快速恢复服务； q 为用户请求和接受标准服务提供一个渠道，针对这些服务制定预定义的审批和资格流程； q 确保每个事件和服务请求都得到有效处理； q 减小事件对业务的影响； q 最优化支持资源，提高工作效率； q 根据业务轻重缓急解决事件和服务请求，保障有效IT运营； q 加强有效监控和及时反馈； q 提升客户满意度； q 提供管理信息。 1.2 适用范围 本文档适用于XXX有限公司技术中心的运维及IT服务部（以下简称“运维及IT服务部”），本文档所规定的IT服务是指运维及IT服务部为公司研发部门所提供的IT服务。 管理范围指的是为研发部门提供应用系统运行维护服务（含计算机应用、系统、网络、机房、监控、操作等）相关的信息技术服务，包括客户IT环境中产生的事件和服务请求。具体说明如下： q 事件 Ø IT人员监测或通过检查发现的事件 Ø 用户申报的事件 q 服务请求 Ø 服务咨询 Ø 标准服务申请 Ø 标准变更 2. 制定依据 ISO/IEC 20000-1:2011。 3. 术语定义 本文档采用《ITSM标准术语表》中的定义。 4. 流程角色及职责 具体流程角色与运维及IT服务部相关岗位/人员的对应关系请参见三级文件《事件和服务请求管理策略》。 5. 具体条款 5.1 流程执行策略 5.1.1 总体策略 事件和服务请求管理流程应该遵循如下总体策略： q 所有事件和服务请求都应该被完整准确的记录，并保证记录的信息尽可能详细； q 所有对用户业务环境可能造成影响的事件和服务请求都应通过事件和服务请求管理流程处理，并遵守流程定义的相关标准和策略； q 所有支持人员应按照事件和服务请求的优先级进行处理，优先处理级别较高的事件和服务请求； q 应该定期（每周）产生和回顾事件和服务请求管理报表。对没有解决的事件或服务请求，应该举行定期的回顾会议，并对这些事件或服务请求进行评估； q 应该定期（每年）对流程进行回顾，以改进事件和服务请求管理流程。事件和服务请求管理流程的回顾与改进由流程负责人负责。 5.1.2 优先级策略 事件或服务请求的优先级表明了该事件对客户的业务影响和紧急程度。它是评定事件或服务请求处理优先顺序、解决时限的一个重要指标。所有事件或服务请求都划分到不同的优先级中，其中划分为3级的代表优先级为最高。优先级的定义主要由事件或服务请求的“影响度”和“紧急度”共同决定。 影响度是指受影响业务系统的关键程度，通常根据受影响的客户数量、设备或系统的关键/重要程度、所服务客户/人员的关键程度（如：是否为VIP人员）、可能造成的业务损失程度等方面来决定。 紧急度是指受影响事件或服务请求在解决时所需要的速度，即客户可忍受的最长可耽搁时间。需要指出的是：一个高影响度的事件并不一定非常紧急，反之亦然。 运维及IT服务部的事件和服务请求优先级定义具体请参见三级文件《事件和服务请求管理策略》。 5.1.3 目标解决时间策略 为了更好的控制事件和服务请求的解决，每个流程定义了目标解决时间，包括响应时间要求，解决时限要求。事件或服务请求管理的目标时间可参见三级文件《事件和服务请求管理策略》。 所有超出目标解决时间的事件和服务请求单将体现在每月的统计报表中。同时，事件和服务请求经理将得到通知。 5.1.4 升级策略 升级策略的目的是，对于不同优先级的事件和服务请求，确保分配到合适的资源来解决。为了达到这个目的，定义了升级策略的时间框架。当达到下列时间时，如果事件和服务请求还未解决，将触发升级策略。运维及IT服务部的事件和服务请求升级主要包括技术升级和管理升级。 具体的升级策略可参见三级文件《事件和服务请求管理策略》。 5.1.5 重大事件策略 定义重大事件为优先级为“3”，同时非终端故障的事件。并定义重大事件的报告机制，由服务台或现场服务人员直接报告服务台经理，服务台经理需协调资源进行解决。 重大事件处理完毕后，由事件处理人员提交对重大事件处理情况的报告，经事件流程经理审核后，上报运维及IT服务部管理层。 5.1.6 关闭策略 事件和服务请求单在得以成功解决后，需要进行关闭。事件和服务请求单的关闭必须由服务台完成，工具应可以支持事件和服务请求单的自动关闭。 5.2 流程相关定义 5.2.1 事件和服务请求信息项 事件和服务请求单信息项用于记录事件或服务请求的必要的信息，以满足事件或服务请求处理、跟踪、统计、分析等需要。详情请参见三级文件《事件和服务请求管理策略》。 5.2.2 事件和服务请求服务方式 事件和服务请求服务方式请参见三级文件《事件和服务请求管理策略》。 5.2.3 事件和服务请求性质 事件和服务请求性质用来表明事件的概要类型，详情请参见三级文件《事件和服务请求管理策略》。 5.2.4 事件和服务请求分类 事件和服务请求分类代码用于标识故障或服务请求种类，由服务台进行填写。当提交事件或服务请求单后，应该由服务台工程师分析和定位。事件或服务请求最终分类可由后续支持人员作进一步的确认，并可在事件或服务请求关闭前进行调整。 事件和服务请求的分类层次一般不超过三层，第一级分类，称之为“分类”，第二级分类，称之为“子分类”，第三级分类，称之为“条目”。 有关研发部门事件分类表，请参见三级文件《事件和服务请求管理策略》。 5.2.5 事件和服务请求状态 事件和服务请求状态代码表明事件或服务请求所处的处理状态，事件或服务请求状态示例请参见三级文件《事件和服务请求管理策略》。 5.2.6 事件和服务请求关闭代码 事件和服务请求关闭代码说明了事件或服务请求是在何种情况下关闭的，结束代码请参见三级文件《事件和服务请求管理策略》。 5.3 事件管理流程输入及输出 5.3.1 流程触发条件 q 用户申告的事件 q 巡检或监控发现的事件 5.3.2 输入 q 用户申告的事件 q 通过巡检或监控发现的事件 q 配置项（CI）的信息 q 变更信息 q 来自于知识库的解决方案/变通方法 5.3.3 输出 q 已关闭的事件单 q 知识库的候选解决方案 5.3.4 流程关闭条件 q 事件处理完毕并得到用户确认 5.4 事件管理流程设计 5.4.1 作业流程图 5.4.2 流程活动说明 编 码 活 动 责任人 说 明 参考 01 需求部门上报事件 用户 l 发生IT服务事件时，需求部门人员（用户）通过邮件或电话等渠道告知技术中心服务台工程师 02 服务台工程师在IT服务平台记录事件信息（联系人、时间、现象、分类、分级等） 服务台工程师 l 服务台工程师获取IT服务事件信息后，在IT服务台创建《事件单》，填写事件基本信息，包括：IT事件联系人、提交方式、提交时间、现象描述、事件分类、影响度分级等 03 是否重大事件 服务台工程师 l 服务台工程师根据需求部门人员的描述，按照上报事件的影响度来判断事件是否重大：事件影响度按照事件影响用户的程度（包括使用的系统及受影响的人数等）及公司运营是否收到影响来判断。 l 对于重大事件，服务台经理分配具备相关处置经验和技术的技术专家进行解决。对于非重大事件，则优先由服务台工程师尝试解决。 l 重大事件策略 04 服务台工程师通过电话或在线解决并更新IT服务平台信息 服务台工程师 l 对于非重大的上报事件，服务台工程师通过电话或远程在线为需求人员解决，解决后服务台工程师更新《事件单》的信息 05 是否解决 服务台工程师 l 服务台工程师是否有效的解决，如事件无法解决，则转步骤13 06 服务台工程师与用户沟通，确认事件解决 服务台工程师 l 《事件单》解决后，服务台工程师与事件提报人通过邮件、电话或即时通讯工具等方式沟通，确认事件已得到有效解决。如解决过程中出现新的问题，则由服务台工程师在IT服务台上创建新的《事件单》。 07 用户确认事件解决 用户 l 提报人员确认事件已解决 08 是否仅为桌面或终端事件 服务台工程师 l 服务台工程师解决事件后，查看《事件单》的事件分类是否为桌面或终端事件，如为桌面或终端事件则关闭IT服务台《事件单》，如分类非桌面或终端事件，则转步骤10，由服务台经理回顾《事件单》的记录。 09 服务台工程师关闭IT服务平台的事件记录 服务台工程师 l 对已解决的事件，服务台工程师关闭《事件单》。 10 服务台经理回顾事件记录 服务台经理 l 对涉及非桌面或终端事件的相关事件，服务台经理回顾IT服务台上《事件单》的记录信息（包括：事件解决方法、描述、解决时间、《事件单》状态等），核实记录的准确性和完整性。 11 是否找到事件根原因 服务台经理 l 对于事件解决方法的描述中未找到跟原因的事件进行判定，以确定是否需要启动问题管理流程。 12 服务台经理沟通服务台工程师并分派技术专家工程师，全程跟踪事件进展，协助技术专家记录工作日志，保持与用户沟通 服务台经理 l 对重大的上报事件，服务台经理与服务台工程师沟通，包括事件发生时间、现象及影响范围等，依据沟通确认结果分配具备相关处置经验和技术的技术专家。 l 服务台经理对技术专家处理的事件全过程进行跟踪，并协助技术专家记录工作日志，包括解决日期、解决方法、根原因信息等，服务台经理保持与需求提报人沟通事件处理的状态。 13 服务台工程师分派给合适的技术专家工程师 服务台经理 l 对于非重大但服务台工程师无法解决的《事件单》，服务台工程师依据用户的提报信息及处理过程中获取的信息，与技术专家进行沟通，将待处理事件交由适当的技术专家处理，服务台工程师在IT服务台的《事件单》更新技术员信息。 14 专家工程师处理事件并更新IT服务平台信息 专家工程师 l 专家工程师处理事件，事件处理后更新《事件单》的信息。 15 是否需要重新分配 专家工程师 l 专家工程师依据事件处理是否顺利，决定是否需要对解决问题人员进行重新分配。如需要重新分配，则专家工程师在IT服务台为《事件单》重新分配技术员，由合适的技术专家继续跟进处理事件。 16 是否解决 专家工程师 l 已由专家工程师解决的事件，专家工程师及时通过各种沟通渠道通知服务台工程师。服务台工程师及时告知到事件提报人。如事件尚未解决，专家工程师依据情况在IT服务台上为《事件单》重新分配技术员。 17 是否启动紧急响应预案 服务台经理 l 如经过专家工程师处理跟进后尚无法解决事件，服务无法得到恢复，则服务台经理根据服务影响大小决定是否需要启动应急响应流程。 l 并非所有服务都有应急响应流程。 5.5 服务请求管理流程输入及输出 5.5.1 流程触发条件 q 用户申告的服务请求 5.5.2 输入 q 用户申告的的服务请求 q 变更信息 5.5.3 输出 q 已关闭的服务请求单 5.5.4 流程关闭条件 q 服务请求处理完毕并得到用户确认 5.6 服务请求管理流程设计 5.6.1 作业流程图 5.6.2 流程活动说明 编 码 活 动 责任人 说 明 参考 01 需求部门提报服务请求 用户 l 需求部门的用户对IT资源有服务需求时，需求部门人员（用户）通过邮件或电话等渠道告知技术中心服务台工程师 02 服务台工程师在IT服务平台上创建请求，生成工单 服务台工程师 l 服务台工程师获取IT服务请求信息后，在IT服务台创建《服务请求单》，填写请求的基本信息，包括：IT服务请求联系人、提交方式、提交时间、需求等 03 IT服务台判断请求的审批类型 服务台工程师 l 服务台根据用户提报的服务请求判断该服务请求所对应的审批类型，为后续判断审批是否有效提供依据 l 审批类型 04 服务请求类型是审批人模式或接口人模式 服务台工程师 l 根据服务请求对应的审批类型确认相对应的审批类型，做审批结果合法性做确认。 l 审批类型 05 已获得审批人审批 审批人 l 确认在审批人模式下的服务请求是否已经获得了有效审批人的审批，如审批有效，则进入服务请求处理步骤，如果否，则驳回请求。 06 是否是接口人提报的服务请求 审批人 l 确认在接口人模式下的服务请求是否是由接口人提报的（提报人是否在接口人名单中），如果是则进入服务请求处理步骤，如果否，则驳回请求。 l 接口人名单 07 IT服务台在系统平台中完善工单内容(分类、分级等)并执行服务请求操作 服务台工程师 l 服务台工程师在确认服务请求的合法性后，在处理前需要进一步在IT服务平台中完善服务请求的信息，在《服务请求单》中填写分类、分级、等信息，然后进行跟进处理。 08 通知需求部门请求人或接口人服务请求已完成，请其确认 服务台工程师 l 在处理完服务请求后，服务台工程师通过各个沟通渠道联系到请求人，让其确认一下服务请求的完成结果。 09 用户确认服务请求已完成 服务台工程师 l 用户跟进服务台工程师反馈的信息对需求进行验证，并将结果再次反馈到服务台工程师。 10 关闭工单 服务台工程师 l 在用户服务请求已完成后，在IT服务平台上关闭《服务请求单》。 5.7 KPI指标参考 为了控制流程的质量，提高用户体验，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。基于对运维及IT服务部的IT服务认识和了解，设置事件和服务请求管理流程KPI指标供参考，详情请见三级文件《事件和服务请求管理策略》。 6. 相关文件与记录 q 《事件和服务请求管理策略》 q 《重大事件报告》 18