ISO20000服务事件管理程序
变更管理程序(ISO20000-1:2018)

变更管理程序
1目的
变更管理的目的是保证变更在受控方式下正确评估,批准和实施。
减少和杜绝非授权变更,降低变更风险和对业务的影响。
2过程定义
事件从服务热线到事件管理再到问题管理是一个解决力度逐步加强的过程,但也是一个治标未治本的过程。
要真正做到防范于未然或者减少事件影响,必须实施一定的变更以消除事件产生的根本原因。
有变更必然会有风险,因此,加强对变更过程的控制,以防变更过程中的疏忽、资源短缺、准备不足等等原因造成变更失败或产生新的事件已经成为IT服务提供者必须重视和认识考虑的问题。
2.1范围
变更管理流程涵盖IT服务环节的所有变更。
一般不包括:
1)尚处于开发和测试阶段的系统和应用的变更
2)不需要其他介入的或由用户自身发起的变更行为
2.2过程负责人
变更管理负责人
2.3主要输入
2.4主要输出
2.5职责权限
1)变更管理负责人。
ISO20000IT服务管理系统控制程序

ISO20000IT服务管理系统控制程序ISO/IEC 20000-1:2018 IT服务管理系统控制程序本文档旨在详细阐述ISO/IEC 20000-1:2018标准下IT服务管理系统的控制程序,确保组织提供一致、可靠的IT服务,同时满足内外部客户的需求。
1. 引言1.1 目的本文档旨在为组织提供一个框架,通过实施ISO/IEC 20000-1:2018标准,确保IT服务管理系统(ITSMS)的有效运行,从而提供高质量的服务。
1.2 范围本文档适用于组织的内部和外部客户,涵盖IT服务管理的所有方面,包括服务战略、设计、过渡和运营。
2. 职责和角色2.1 角色和职责- 服务管理负责人:负责制定和维护ITSMS,确保其符合ISO/IEC 20000-1:2018标准要求。
- 服务提供者:负责提供服务的实际执行,确保服务满足既定的目标和指标。
- 客户:负责提出服务需求,参与服务改进,并对所接收的服务进行评价。
- 工作人员:负责执行具体的服务管理流程和任务。
3. 服务管理流程3.1 服务战略- 服务需求分析:确定内部和外部客户的需求,评估服务的可行性和效益。
- 服务级别目标(SLA)制定:基于需求分析,制定服务级别目标,确保服务满足客户期望。
- 财务管理:确保服务的财务可行性,包括成本效益分析和预算管理。
3.2 服务设计- 服务设计框架:制定服务设计框架,包括服务组件、服务架构和能力需求。
- 服务模型和框架:开发和维护服务模型,包括服务组件、服务架构和能力需求。
- 服务生命周期管理:确保在整个服务生命周期内,服务质量得到维护和提升。
3.3 服务过渡- 变更管理:确保变更经过适当评估和控制,以降低对服务的影响。
- 服务部署:确保新服务和变更按照既定计划和程序进行部署。
- 服务连续性和可用性管理:制定和实施服务连续性和可用性计划,以应对潜在的威胁和中断。
3.4 服务运营- 服务操作管理:确保服务操作按照既定流程执行,以提供稳定的服务。
ISO20000:2018事件管理

事件管理《事件管理流程》旨在介绍和描述事件管理流程,并将作为信息日常IT维护所涉及的事件管理流程的参考。
本文介绍了如何在事件发生、诊断、关闭的整个生命周期中实施事件管理,并定义支持、运作事件管理流程相关的人员职责以及事件的升级策略。
一、流程概述研发部接线员作为事件记录员,根据用户提出的服务请求,将事件转到研发部,研发部组员根据日常监控过程中发现的事件,创建事件单,搜索知识库,通过常规恢复操作尝试进行事件的初步分析、解决、跟踪和关闭,对于知识库中缺乏或者较为复杂的事件向研发部经理汇报并提交组长处理。
研发部经理根据知识库判断该组员是否能够处理该事件,能够处理的组员进行处理。
在事件管理流程中,研发部接线员为事件经理对整个事件的处理负责,受理事件并创建事件单的研发部组员对整个事件流程进行跟踪,并及时答复用户事件处理情况。
(1)事件检测与记录事件检测与记录步骤是事件管理流程的起点。
该步骤的目的是快速、准确地探测和捕捉所有在IT生产环境中发生的错误,并在将来的问题管理流程中帮助确定问题和解决问题。
在本步骤中,将收集创建一个事件单所需要的信息,重点是准确、完整地记录必要的信息。
(一)事件的检测研发部接线员在受理事件后检查是否已存在该事件单,若存在则将事件转由当前的受理人处理。
否则,创建新事件单。
(二)事件的记录事件的记录遵循《决策管理系统工单编制规范》进行填写。
(2)事件分类与初步支持该步骤包括:为了对用户的请求进行分析而进一步收集信息。
该步骤的目的是对每个事件进行正确的分类(依据《决策管理系统分类规范》进行),随即在现存的知识库中查询与该事件相匹配的条目。
若没有找到合适的解决方案或变通方法,则该事件需要转派研发部经理解决在处理过程中,研发部组员需要根据处理的情况详细记录整个处理过程和结果,记录信息应与实际情况一致。
若根据当前已有知识库条目能够解决事件,则在解决完事件后,在事件单中记录和填写故障根源和解决方案。
ISO20000-1:2018体系文件-事件管理程序

事件管理程序信息技术有限责任公司变更履历目录1 简介 (4)1.1目的 (4)1.2适用范围 (4)1.3术语表 (4)1.4引用文件 (6)2 职责 (6)2.1服务台 (6)2.2一线/二线支持组 (7)2.3外部资源 (7)2.4服务部经理................................................................................. 错误!未定义书签。
3 流程图 (8)4 具体内容 (9)4.1接受/记录事件 (9)4.2分级/分类和初步支持 (9)4.3调查和分析 (10)4.4解决和恢复 (10)4.5事件关闭 (11)4.6过程的跟踪监控 (11)5 事件升级过程 (11)5.1事件严重程度定义 (11)5.2事件升级步骤 (11)6 事件管理过程与其他流程的关系 (12)6.1事件管理过程与其他关系 (12)7 事件管理过程的KPI (13)7.1KPI定义 (13)8输出的文件和记录 (14)1简介1.1目的事件管理过程提供日程支持服务的接口,以降低因IT事件带来的影响。
该过程关注尽可能快的恢复服务以满足预定服务等级协议(SLA)的要求。
1.2适用范围事件管理过程适用于记录、处理、关闭事件并监督整个过程的管理活动,事件管理过程包括服务台和相应的支持组。
1.3术语表●事件:指服务的任何异常,并将导致或可能导致服务的中断或服务质量下降的事态。
●服务请求:来自客户对IT服务的信息、建议、标准变更或访问请求。
例如要求增加内存、安装某个软件、账号申请、变更请求等。
变更通常不认为是一个事件,而是一个变更请求(RFC)。
但两者的处理方式相近,因此在事件处理过程中也包括对服务请求的处理,即事件包含服务请求。
●事件关闭:接到事件请求后,服务台不能当时解决问题,则将需要把事件分配给相应的支持组。
为尽可能快地恢复业务,可利用解决方案(永久性的)或临时措施。
iso20000管理体系审核

iso20000管理体系审核摘要:1.ISO20000 管理体系简介2.ISO20000 审核的目的和意义3.ISO20000 审核的过程4.ISO20000 审核的具体内容5.审核结果及后续改进措施正文:ISO20000 管理体系是一个面向机构的IT 服务管理标准,旨在提供建立、实施、运作、监控、评审、维护和改进IT 服务管理体系(ITSM) 的模型。
越来越多的组织,特别是金融机构、电信、高科技产业等,已经认识到建立IT 服务管理体系(ITSM) 对于管理运营风险的重要性。
ISO20000 审核是确保组织IT 服务管理体系是否符合ISO20000 标准要求的过程。
其目的在于识别并解决不符合项,从而提升组织的服务质量、效率和客户满意度。
通过ISO20000 审核,组织可以更好地满足客户和利益相关者的需求和期望,实现持续改进。
ISO20000 审核的过程通常包括以下几个阶段:1.审核申请:组织向认证机构提交审核申请,并提供相关材料,如组织结构、业务流程、服务管理计划等。
2.审核计划:认证机构根据组织提供的信息,制定审核计划,包括审核时间、地点、审核员等。
3.审核实施:审核员对组织的IT 服务管理体系进行现场审核,收集证据,与相关人员沟通交流。
4.审核报告:审核员根据审核发现,编写审核报告,包括不符合项、推荐改进措施等。
5.审核结论:认证机构根据审核报告,做出审核结论,如通过审核、未通过审核等。
ISO20000 审核的具体内容包括:1.服务管理计划:包括服务战略、服务设计、服务过渡、服务运营、持续服务改进等方面的内容。
2.文件和记录:审核员将对组织的文件和记录进行审查,确认其是否符合ISO20000 标准要求。
3.服务运营:包括服务请求处理、事件管理、问题管理、配置管理、变更管理、发布管理等方面。
4.持续服务改进:审核员将关注组织是否建立了持续服务改进机制,如内部审核、管理评审等。
在审核过程中,如果审核员发现不符合项,组织需要采取相应的改进措施,并在规定时间内完成整改。
ISO20000-12服务连续性管理程序

密级:敏感文档编号:HTPC-ITSM-B-12服务连续性管理程序版本号:V1.0服务连续性管理程序***********信息技术有限公司---------------------------------------------------------------------------- ***********信息技术有限公司对本文件资料享受著作权及其它专属权利,未经书面许可,不得将该等文件资料(其全部或任何部分)披露予任何第三方,或进行修改后使用。
修订履历目录1 目的 (4)2 范围 (4)3 职责 (4)3.1 持续性管理负责人 (4)3.2 持续性负责人 (4)3.3 部门经理 (4)4 相关文件 (4)5 程序 (5)5.1 持续性需求识别和分析 (5)5.2 定义持续性实施范围 (5)5.3 业务影响分析 (6)5.4 风险评估 (6)5.5 制定持续性计划 (6)5.6 持续性计划测试 (7)5.7 沟通和培训 (7)5.8 组织和实施计划 (7)5.9 持续性计划维护变更 (8)6 记录 (8)1 目的本程序的目的是确保在所有情况下都可以实现向客户承诺的服务持续性,帮助客户服务在发生灾难之后尽快恢复客户服务和确保业务的持续运营。
确保业务运作所需的客户基础架构和客户服务在灾难发生后的限定时间内能够得到恢复,从而对组织的总体业务持续性管理提供支持。
2 范围本程序适用于客户服务所覆盖的所有部门。
持续性发生的条件包括火灾、战争、大规模断电、硬件瘫痪、自然灾害、失窃、暴力破坏、人力资源危机等意外事件,可能中断客户服务并且影响组织的正常业务运营,最终导致业务损失。
实施持续性计划的范围包括:1)重点关注支持关键业务流程的客户服务项目。
2)对具体的客户技术和服务需求提供支持。
3 职责3.1 持续性管理负责人1)实施和维护客户服务持续性管理流程。
2)维护和改进《持续性计划》。
3.2 持续性负责人负责《风险评估报告》、《持续性计划》和《持续性测试报告》的编制。
ITSMS-B-14问题管理程序(ISO20000)

1.目的本程序的目的是消除或减少系统开发和IT服务过程中事件发生的数量和严重程度,防止相同事件的再次发生,从而为企业建立一个稳定的IT环境,提高IT服务的可用性。
问题管理包括主动性问题管理和被动问题管理两类活动。
前者的目标是通过找出基础设施中的薄弱环节来阻止事件再次发生,以及提出消除这些薄弱环节的建议;后者的目标是找出导致以前发生事件的根本原因,以及提出解决措施或纠正建议。
2.范围本程序适用于ITSMS覆盖的所有部门。
本程序调查基础设施的配置信息、可用信息、能力信息,来确定引起事件发生的真正潜在原因以及提供的服务中可能存在的故障。
问题管理的归口管理部门是体系中心。
3.术语一.问题:引发一个或多个事件的未知因素。
问题通常具有如下特征:•一组具有一定关系的已结束的事件•一个重大事件问题的根本原因找出后即成为已知错误;许多事件往往是有一个问题引起的。
问题管理流程的输出有:•变更请求•变通方法•预防性措施二.已知错误:查明事件原因并且已有临时、应急处理措施的问题。
三.主动问题管理:•通过改进基础设施以及提出变更请求来阻止可避免事件的发生。
•通过找出基础设施中的薄弱环节来阻止事件的再次发生,以及提出消除这些薄弱环节的建议。
•分析基础设施的运行趋势并找出那些潜在事件以防止其发生。
4.角色与职责信息管理部经理a)根据服务台提供的信息找出问题,与开发部部长组织技术工程师一起探讨发现IT系统基础平台中存在的技术问题。
b)确定并协调必要资源来处理所有(潜在)影响服务级别的所有类型问题,最小化问题的负面影响。
c)领导信息管理部,制定清晰有效的工作流程和准则,确保员工的积极性、技能水平和绩效表现。
d)发现造成问题的可能原因,将问题分派给有能力将其解决的IT职能部门。
e)跟踪问题解决的过程,必要时进行升级以及问题升级后的协调工作。
f)将关键问题的解决状态及时地通报给事业部管理层。
g)提出变更请求来消除事件和问题的根本原因。
iso20000信息技术服务管理措施

ISO20000信息技术服务管理措施1.引言随着信息技术的快速发展和广泛应用,各行各业对于信息系统和技术服务的需求越来越高。
为了保证信息技术服务的质量和可持续发展,国际标准化组织(IS O)制定了I SO/I EC20000标准,旨在帮助组织建立和实施有效的信息技术服务管理体系(IT SM S)。
本文将介绍I SO/I EC20000标准所要求的信息技术服务管理措施,旨在帮助组织提升信息技术服务的质量和效率。
2.建立ITS MS2.1确定服务管理的范围和目标在建立I TS MS之前,组织需要明确自己的服务管理范围和目标。
这包括确定服务的类型、覆盖的业务范围以及希望达到的服务质量水平等。
通过明确范围和目标,组织可以有针对性地制定管理措施。
2.2建立服务流程和流程指南根据服务管理的范围和目标,组织需要建立适合的服务管理流程和相应的流程指南。
服务流程应包括服务请求管理、变更管理、问题管理、事件管理等。
流程指南则详细描述了每个服务流程的操作步骤和要求,以保证流程的执行一致性和高效性。
2.3建立服务级别协议(S L A)服务级别协议是组织与客户之间就服务提供的各方面约定所达成的协议。
建立服务级别协议可以明确双方的责任和权益,同时也是组织向客户承诺提供优质服务的重要方式。
S LA应包括服务的可用性、响应时间、故障处理时间等关键指标。
3.实施ITS MS3.1风险管理在实施I TS MS过程中,风险管理是不可忽视的一环。
组织需要评估和识别可能对服务管理造成影响的风险,并制定相应的风险应对策略。
例如,组织可以建立备份和恢复机制来保证信息系统的可靠性和可用性。
3.2人员培训和意识提升为了保证IT SM S的有效实施,组织需要进行人员培训和意识提升工作。
培训内容应涵盖I SO/I EC20000标准的要求、服务流程和操作规范等。
通过提高人员的专业技能和服务意识,组织可以提升信息技术服务的质量和客户满意度。
3.3性能和度量评估为了监控和评估I TSM S的绩效,组织需要建立相应的性能和度量评估机制。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
服务事件管理1目的事件管理流程的目的是尽快解决IT环境中的突发事件,保障IT系统的稳定性,提高服务质量,为业务的发展提供更优质的IT服务,并且可以有效实施其他相关ITSM 管理流程,如问题管理流程。
通过本文档的定义,建立一个完整的事件管理系统,从而实现:1)减小突发事件对业务的影响●在成本允许的范围内尽快恢复IT服务●快速响应服务请求(电话/Web/邮件等)2)提高用户工作效率3)提升客户满意度4)进行事件有效控制●按规范记录事件,避免事件丢失●就事件的优先级,影响度进行分类●分析,诊断,必要时进行升级●监视并结束事件●进行定期服务流程回顾5)提供IT管理信息●人力资源利用情况,从而更好使用人力●支持效率●IT系统故障处理情况●给准确信息至配置管理数据库(CMDB)●服务报告2适用范围事件管理的范围包括ABC软件股份有限公司合同范围内的客户的IT生产和运行环境中发生的故障事件、用户的服务请求,具体如下:1)故障申告●用户报告的故障事件●监控系统的报警事件●IT服务人员监测、检测的故障事件●其他人员转告的用户故障事件2)服务请求●信息咨询,主要包括:客户在IT信息系统建设,运维管理,IT产品,系统使用等方面提出的咨询请求●业务支持请求,主要包括:会议支持请求,庭审支持请求,远程提讯支持请求,系统培训支持请求●辅助配合,主要包括:领导交办任务及第三方配合的服务请求事件管理的范围不包括客户提出的、合同范围之外的相关请求,以及投诉事件和ABC软件股份有限公司内其他部门的工作任务。
3术语定义3.1事件用户在信息系统使用过程中,在合同范围内可能导致这个服务的中断或服务质量下降的任何事件,包括故障申告,服务请求等。
3.2事件管理降低或消除正常提供IT服务时产生的干扰因素,通过一些变通方案,降低影响,尽快恢复客户业务应用,保障用户能够尽快重新工作。
3.3服务请求服务请求类事件是指客户希望从服务台得到的业务支持、信息咨询、辅助配合或者文档方面的请求。
3.4事件升级当某一事件不能在规定时间内解决,那么就需要更多经验、更高权限人员和资源参与解决,从而确保事件得到解决。
3.5同一事件同一事件是指在单一客户申告的统一来源(IT系统、应用系统)同一个配置项上相同事件现象的已创建且尚未解决的事件。
4岗位与职责4.1事件经理●通过服务台来确保客户满意;●确保事件快速解决;●出现紧急、重大事件时,负责协调外部资源尽快解决;●当事件优先级为紧急或者事件将超过规定的时限,负责按照升级方法对事件进行处理确保有效协调资源,促进各类角色小组(如一线支持、二线支持)快速恢复正常服务;●确保正确和广泛地收集和分析事件数据,发现IT和业务相关的问题;●确保与问题管理、外部供应商等部门的有效合作。
4.2一线工程师●作为客户事件沟通的唯一联系点;●在指定的响应时间内响应所有服务台热线电话、邮件、工单等事件报告;●正确、完整记录所有接收的事件信息,包括:记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等;●为事件进行适当的分类、为事件分配优先级等属性;● 进行初步支持;● 检查事件记录的处理进度,保持与用户的联系,适时通知事件处理进展; ● 在事件处理过程中,催办事件处理进度;● 与用户确认事件解决方案及用户满意度反馈,关闭事件; ● 结束事件,更新信息;● 把事件的影响降低到最小,并确保快速回复到正常服务水平; ● 尝试使用知识库、初步诊断、分析相关信息等方式解决事件; ● 根据解决方案进行IT 服务的解决与恢复;● 如事件无法解决,将事件进行升级,并寻求事件经理的支持;4.3 二线工程师● 接收和处理升级事件;● 把事件的影响降低到最小,并确保快速回复到正常服务水平; ● 及时提供有效解决方案;● 与其他二线小组合作,确定解决方案;● 如果事件无法解决,将事件升级,寻求事件经理的支持; ● 已解决的事件转回服务台,由服务台关闭事件;● 进行问题的深入调查研究,找到问题根本原因,并提出解决方案;● 收集有关事件解决方案,并将事件、问题解决步骤文档化,并录入知识库系统。
5 程序准则5.1 执行准则5.1.1 常规原则● 服务台作为事件总负责人,监督事件的处理,负责事件的提起与关闭;进行事件的深入调查研究;确定事件的分类、分级和关联配置项;● 根据经验和专业技能,决定需要采取何种措施恢复服务并实施有效的行动; ● 必要时引入供应商的支持;● 根据解决方案进行IT 服务恢复;●从事件记录时起至事件关闭时结束,事件全生命周期监控事件的影响及处理情况;●所有事件都应该被记录在紫光华宇业务系统中,记录的信息应足够详细,包括事件处理交互过程,详细的解决方案和相应的信息;●所有IT支持人员按照服务级别协议规定时限对事件进行处理,当事件冲突时,对优先级为重大紧急的事件所采取的服务恢复行动,在比对其它行动的时候,将拥有优先处理级别,如果优先级别相同,则优先处理相对简单事件;●安全事件发生时,严格遵循服务安全管理程序的原则,通过事件管理流程进行事件管理;●事件处理过程中,应持续保持与客户的沟通,通知客户事件处理进展;●应该每月产生事件管理报表,对重复发生的事件和变通方法解决的事件,应该举行定期的事件管理会议对这些事件进行评估;●应该半年对流程进行回顾,回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性,以改进事件管理流程。
5.1.2升级原则制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导,引起更多的重视,提供合适的资源,从而快速找到解决事件的方案。
●优先级为紧急的事件,由一线工程师确认,如果确认了优先级为重大、紧急,则立即升级到事件经理,并通知相应的管理层(通过IT服务管理平台),由事件经理启动紧急事件处理流程●各支持人员应及时响应和处理分配到本组或自己的事件单,如果超出规定的解决时限,服务台应将事件信息升级至二线工程师进行支持,如果二线工程师超过解决时限,则通报事件经理,事件经理负责协调资源,并督促事件能够及时被响应和处理●服务台应及时将不能解决的事件升级到下一级,若未及时升级,事件经理应及时介入,负责协调升级处理5.1.3关闭原则由IT用户申报的事件单,关闭必须由服务台完成。
●已关闭的事件单不允许重开,如果事件重复发生,则创建一个新的事件单。
●事件处理人员在解决完成事件时,根据实际解决情况填写事件的结束代码,采用临时措施恢复服务时,结束代码为"变通关闭";由IT用户认可获得关闭的事件单的结束代码为"成功关闭";●监控平台产生的事件发送到服务台,由服务台分派处理人员解决并关单。
5.1.4流程关联原则事件管理与问题管理、变更管理、发布管理、配置管理存在以下关联原则:●和问题管理的关联通过临时解决方法解决的事件在恢复客户IT服务后,都应该创建问题单,问题单需和事件单建立关联。
●和变更管理的关联事件处理过程中,如果需要对系统进行变更,必须按照变更管理的定义,提交变更请求单(变更单必须和事件单建立关联),变更完成后,继续事件单的处理。
紧急事件(优先级为紧急的事件,下同)的处理过程中,如果需要对系统进行变更,必须按照变更管理的定义,提出紧急变更请求,变更完成后,补录紧急变更单,并和紧急事件单建立关联。
●和配置管理的关联事件处理过程中,可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件或变更,来帮助故障的定位。
事件处理过程中,如果可以将故障定位到某个配置项,则必须将事件单与该配置项关联。
和发布管理的关联发布工作结束后,可能触发新事件的产生。
发布管理应向事件管理提供发布相关信息,包括:年度发布计划,发布信息等。
5.2输入及入口准则5.2.1入口准则ABC软件股份有限公司合同范围内,用户通过电话、邮件、传真、企业cocall协作系统等方式进行的事件请求、IT环境中监控系统告警、服务人员巡检过程中发现或其他人员转告的事件请求。
5.2.2输入5.3输出及出口准则5.3.1出口准则由客户提出的事件,关闭时必须通知IT客户。
5.3.2输出此为事件管理主流程。
事件管理流程帮助迅速解决用户事件,并最小化事件对于业务的不利影响。
流程始于事件的接收和报告,结束于经过用户确认的事件解决。
1)服务台(一线工程师)接收用户事件请求并记录事件信息,根据事件信息对事件进行分类,标识事件的紧急度、影响度和优先级;2)服务台(一线工程师)查看知识库对事件进行匹配,对事件进行调查与分析,尝试解决,并根据实际情况决定是否要升级为问题;3)当超过时限内无法解决则分配给二线工程师进行处理,二线工程师引用知识库,调查并诊断事件,并根据实际情况决定是否要升级为问题;4)事件解决完成后,记录详细的分析、诊断过程和解决方案;5)通告用户问题解决,关闭事件并选择性更新知识库和提起新问题;6)服务台(一线工程师)判定事件的紧急度、影响度和优先级高,提交至事件经理协调相关资源进行处理;7)服务台(一线工程师)判定事件为服务请求类事件,进行服务请求的支持活动8)服务台(一线工程师)判定事件为变更请求类事件,提交变更流程进行管理;9)服务台(一线工程师)判定事件为客户投诉,合同外的新增请求,安全事件,其他部门任务等事件,转交其他流程进行管理;10)事件全生命周期监控对整个事件处理过程进行监控。
6工作程序6.1事件管理流程6.1.1流程描述6.1.2错误!未指定书签。
流程图6.1.3流程说明6.1.4裁剪说明6.2子流程1:事件记录与分类6.2.1流程图6.2.2流程说明6.2.3裁剪说明6.3子流程2:一线尝试解决6.3.1流程图6.3.2流程说明6.3.3裁剪说明6.4子流程3:二线尝试解决6.4.1流程图6.4.2流程说明6.4.3裁剪说明6.5子流程4:记录详细解决方案6.5.1流程图6.5.2流程说明6.5.3裁剪说明6.6子流程5:服务请求管理6.6.1流程图6.6.2流程说明6.6.3裁剪说明6.7子流程6:紧急、重大事件管理6.7.1流程图6.7.2流程说明6.7.3裁剪说明6.8子流程7:事件关闭6.8.1流程图6.8.2流程说明6.8.3裁剪说明7相关二级文件Q2-CS-02《服务问题管理》Q2-CS-03《服务配置管理》Q2-CS-04《服务变更管理》Q2-CS-05《服务发布管理》8三级文件8.1质量记录模板8.2文档模板Q3-CS-01-01《服务事件单》Q3-CS-01-02《服务工作记录》Q3-CS-01-03《服务事件故障报告》Q3-CS-01-04《服务事件统计分析报表》8.3规则、惯例和约定Q3-CS-01-11《事件分类规则》Q3-CS-01-12《事件分级规则》Q3-CS-01-21《服务行为规范》Q3-CS-01-22《生产系统操作规范》Q3-CS-01-23《ABC应急预案》8.4检查单。