ERP运维管理之事件管理流程设计说明书.docx

资源描述

ERP运维管理之事件管理流程设计说明书.docx

《ERP运维管理之事件管理流程设计说明书.docx》由会员分享，可在线阅读，更多相关《ERP运维管理之事件管理流程设计说明书.docx（65页珍藏版）》请在冰豆网上搜索。

ERP运维管理之事件管理流程设计说明书.docx

ERP运维管理之事件管理流程设计说明书

华新ERP运维管理之事件管理流程设计说明书

慧眼工程

华新ERP运维管理体系设计项目

版本V1.0

2010/05/31

本文档版权由华新水泥股份有限公司所有。

未经华新水泥股份有限公司书面许可，任何单位和个人不得以任何形式摘抄、复制本文档的部分或全部，并以任何形式传播。

作者

联系方式

李春雷

▪电子邮件:

chunlei.li@

▪电话:

修订

日期

文档版本

修订描述

文档作者

2010/05/28

1.0

初始版本

姓名:

李春雷

审批

审批日期

审批版本

审批人角色

审批人

2010/06/01

1.0

凯捷项目经理

姓名Name:

蔡玮

2010/06/01

1.0

华新项目经理

姓名Name:

张林

1流程目的

事件管理流程的主要功能是尽快解决出现的事件，保持业务系统的稳定性，其目的包括：

❑在成本允许的范围内尽快恢复ERP服务

Ø快速响应服务请求（电话/邮件/运维平台等）

Ø用户获得服务支持

Ø沟通事件解决的状态

Ø和客户确认事件的解决

❑进行事件控制

Ø按规范记录事件

Ø就事件的优先级，影响度进行分类

Ø分析，诊断，必要时进行升级

Ø监视并结束事件

Ø进行定期服务流程回顾

❑提供ERP管理信息

Ø人力资源利用情况

Ø故障处理情况

Ø服务支持效率

2流程主要内容

事件是中断业务流程和降低ERP服务质量的错误。

事件管理流程帮助迅速解决这些事件，并最小化对于业务的不利影响。

流程始于事件的接收和报告，结束于事件的解决。

该流程包含下述主要内容：

❑事件接收和记录

这个环节是事件管理流程的起点。

所有用户或系统报告的ERP应用系统事件必须由此步骤开始。

此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。

在此步骤中将会收集创建事件记录所需的信息。

该环节的关键是信息的准确性和完整性。

❑分类和在线支持

事件可以是一个申告/故障/告警/咨询，对于每个事件，需要确立优先级和分类。

若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。

该环节的关键是必要的知识库支持和正确的事件分派。

❑调查和诊断

若支持人员无法解决事件，可运用知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。

❑解决和恢复

支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认。

❑优先级为紧急的事件（紧急事件）和事件升级

对于紧急事件，服务台应立即提交给一线人员，由一线人员判断，上报给事件经理和相关的管理层，由事件经理决定紧急事件的处理方式，确保其得到最快速的解决。

当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。

❑结束事件

当用户确认事件解决后，此时可结束该事件，并在必要时更新知识库。

3与其他流程的关系

❑和问题管理流程的关系

事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。

❑和配置管理流程的关系

需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。

❑和变更管理流程的关系

服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。

在事件的解决过程中，涉及到需要对基础架构、应用系统及操作系统等进行变更的需要发起变更请求来解决事件。

4关键角色、职责定义

流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的管理流程和角色的目的是为了在充分满足流程所需角色的基础上，为具体的实现提供足够的灵活性。

事件管理流程主要分为以下几个职责/角色，分别简述如下：

4.1服务台人员

服务台人员负责对所有事件的接收与关闭，并参与事件的处理，具体包括以下职责：

❑在指定的响应时间内响应所有服务台热线电话、邮件、工单等事件报告；

❑完整记录所有接收的事件信息，包括：

记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等；

❑为事件进行适当的分类、为事件分配优先级等属性；

❑尝试使用知识库、初步诊断、分析相关信息等方式解决事件；

❑如果服务台不能解决事件，应当将事件分配给最合适的一线支持小组或来处理；

❑检查事件记录的处理进度，保持与用户的联系，适时通知事件处理进展；

❑在事件处理过程中，催办事件处理进度

❑与用户确认事件解决方案及用户满意度反馈，关闭事件。

技能要求：

❑熟悉技术平台和技术环境

❑较强的沟通能力

❑对简单的故障要有快速诊断和解决的能力

❑熟悉事件处理流程

人员配置：

❑设立专职服务台人员，人员数量根据公司相关规定执行。

4.2一线支持人员

在服务管理体系中，一线支持人员负责对服务台无法解决的事件进行快速有效的分析，提出解决方案以尽快恢复服务，并在必要时提供现场支持。

职责：

❑决定需要采取何种措施恢复服务并实施有效的行动

❑必要时提供现场支持

❑根据优先级提供有效的解决方案

❑与其他一线小组合作，确定解决方案

❑更新事件解决信息，已解决的事件转回服务台，由服务台关闭事件

❑如果一线不能解决这个事件，应当升级到二线支持来处理

技能要求：

❑较强的业务、技术背景

❑较强的沟通能力

❑快速诊断事件和解决事件的能力

❑熟悉事件处理流程

人员配置：

❑由业务模块的成员组成，人员数量根据公司相关规定执行。

4.3二线支持人员

二线支持人员是相关业务或技术领域的专家。

负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。

职责:

❑进行事件的深入调查研究

❑根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动

❑必要时引入供应商的支持

❑及时提供有效解决方案

❑与其他二线小组合作，确定解决方案

❑更新事件解决信息，已解决的事件转回服务台，由服务台关闭事件

❑如果二线不能解决这个事件，应当升级到三线支持来处理

技能要求：

❑深厚的业务、技术背景

❑较强的沟通能力

❑快速诊断复杂事件并解决的能力

❑熟悉事件处理流程

人员配置：

❑由业务模块的经理及开发组人员担任。

4.4三线支持人员

职责：

❑从研发的角度进行事件的研究；

❑根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动，如发布临时补丁等；

❑及时提供有效解决方案；

❑已解决的事件转回服务台，由服务台关闭事件。

技能要求：

❑具备开发公司内各类应用系统的能力，对所维护范畴的技术深入掌握；

❑熟悉事件处理流程。

人员配置：

❑由外维厂商代维人员组成

4.5事件经理

事件经理负责事件解决过程中的协调和监控，以及事件升级的判断。

职责：

❑负责对重大、紧急事件的解决协调资源，保证故障的最终排除；

❑当事件优先级为紧急或者事件将超过规定的时限，负责按照升级方法对事件进行处理,确保有效协调资源，促进各类角色小组（如一线支持、二线支持）快速恢复正常服务；

❑当事件被二线支持人员升级到三线支持时，由事件经理负责监控事件，并通过及时与第三方供应商进行联系，协调各方资源来处理升级事件，并负责在事件管理平台记录第三方供应商反馈的事件解决方案；

❑确保和问题管理流程经理的有效合作；

❑确保正确和广泛地收集和分析事件数据，发现ERP应用系统和业务相关的问题。

技能要求：

❑深厚的业务、技术背景；

❑较强的表达能力和与用户沟通技巧；

❑处理纠纷的能力；

❑深刻理解事件管理流程；

❑较强的组织、领导能力。

人员配置：

❑由ERP项目部经理任命1名内部人员担任

4.6事件管理流程负责人

事件管理流程负责人从总体对事件管理流程的设计、实施、执行及优化负责。

职责：

❑确定管理流程的衡量指标

❑确保事件管理流程能够取得管理层的参与和支持

❑确保事件管理流程符合公司实际状况和公司ERP发展战略

❑总体上管理和监控流程，建立事件管理流程实施、评估和持续优化机制

❑确保事件管理流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高

❑保持与其他流程负责人的定期沟通

❑具有较强的计划、组织、领导和控制才能，能够综合各方意见，按时制订和定期优化事件管理流程

技能要求：

❑深刻理解事件管理流程；

❑能够很好地理解业务对于事件管理的需求；

❑有决策权，能够确保事件管理流程设计的要求在实际工作中得到贯彻和执行；

❑具有很好的沟通技能，获得所需资源。

人员配置：

❑由ERP项目部经理担任

5流程执行原则

5.1常规原则

❑所有ERP事件管理范围内发生的事件，都应该记录在ERP运维服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件

❑所有ERP支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别

❑每月出具事件管理报表，并对重复发生的事件和变通方法解决的事件进行评估

❑每年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程

5.2流程关联原则

❑和问题管理的关联

Ø所有优先级为紧急的事件在恢复服务后，都应该创建问题单（问题单必须和事件单建立关联）

Ø支持小组在解决事件的过程中，可以通过问题记录查找相应的解决方案

❑和变更管理的关联

Ø事件处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和事件单建立关联），变更完成后，继续事件单的处理

Ø紧急事件（优先级为紧急的事件，下同）的处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和紧急事件单建立关联

❑和配置管理的关联

Ø事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位

Ø事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联

5.3所有权原则

所有权原则用来确保每个事件在任何时段都有适当的人员负责，服务台是事件的负责人。

❑由ERP用户申报的事件单，服务台员工是该事件的责任人，必须确保事件得到有效跟踪与解决，并负责事件单的关闭

5.4再分派原则

事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。

因此，应当尽量减少事件单再分派的几率。

事件单可以分配到个人，或者分配到组（服务台、一线支持、二线支持、三线支持），再由组内的支持人员处理。

❑服务台将事件单分配给一线支持

❑一线支持可以将事件单重新分配给服务台，其他一线支持小组，二线支持小组

❑二线支持可以将事件单重新分配给服务台，一线支持小组，其他二线支持小组，三线支持小组（事件经理负责组织协调）

❑三线支持不可以将事件单重新分配,若不能解决的,交由事件经理协调资源进行处理

5.5重复事件原则

重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源（系统、应用）现象相同的事件。

当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。

由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。

在原有事件单获得解决时，所有的重复事件单获得解决。

❑重复的事件信息必须被标识，并且不计入事件管理流程的关键衡量指标

❑如果服务台可以判断出重复事件，则由服务台对重复事件标识，否则由其他支持小组负责重复事件的处理

5.6关闭原则

由ERP用户申报的事件单，关闭必须由服务台完成。

❑事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时，结束代码为"变通方法解决"。

服务台负责和ERP用户再次确认事件的解决

❑由ERP用户认可获得关闭的事件单的结束代码为"成功解决"关闭

❑已解决的事件单如果没有得到ERP用户的认可，则首先关闭该事件单，结束代码修改为"不成功"，同时创建一个新的事件单重新分配到原处理人员继续处理

❑已关闭的事件单不允许重开。

如果事件重复发生，则创建一个新的事件单

❑监控平台产生的事件发送到服务台，由服务台分派，处理人员解决并关单

5.7升级原则

制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。

❑优先级为紧急的事件，服务台应立即升级到相应一线支持，由一线支持再次确认，如果确认了优先级为紧急，则立即升级到事件经理，并通知相应的管理层（通过ERP运维服务管理平台），由事件经理启动紧急事件处理流程

❑各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理

❑服务台和一线支持应及时将不能解决的事件升级到下一级，若未及时升级，事件经理应及时介入，负责协调升级处理

5.8工单流转原则

❑事件管理流程负责处理公司应用系统及基础设施产生的事件

❑服务台负责受理所有请求，首先进行尝试解决，不能解决的分派到一线支持小组或人员，不能明确待分派对象的，分派给事件经理

❑一线负责处理服务台转派的工单，对于属于应用系统产生的事件首先在一线内部尝试解决，不能解决的提交到二线支持小组或人员

❑二线负责处理一线转派的工单，首先在二线内部尝试解决，不能解决的提交到三线支持小组

❑三线负责处理二线转派的工单，若不能解决,交由事件经理协调资源进行处理

6流程相关定义

6.1事件信息项

事件单必须包含如下事件信息项：

序号

信息项

是否必填

说明

事件记录和分类时填写：

请求人信息

是

事件申报人的信息，包括：

姓名、部门、电子邮件、办公电话、手机

事件分类

是

参见“事件分类”定义

事件性质

是

参见“事件性质”定义

事件来源

是

参见“事件来源”定义

事件所属系统类型

是

参见“事件所属系统类型”定义

事件发生时间

是

针对故障：

指的是业务中断的实际时间（可能早于登记时间）

针对其他：

缺省值等于登记时间

事件发生时间必须早于或等于登记时间

事件发生单位

是

公司名称

事件简要描述

是

事件的简要描述

事件详细描述

是

对于整个事件内容的详细描述

分配对象

是

被分配的技术支持组

事件优先级

是

参见“事件优先级”定义

重复事件标记

否

标记为重复事件

关联变更

否

用相关变更单号就行关联

关联配置项

否

记录出现故障的配置项代码

附件

否

上传附件

提交事件工单时，系统自动产生

事件ID

是

事件单流水号

建单人（受理人）

是

创建事件请求工单的记录人

登记时间

是

在服务台生成事件记录的时间

事件状态

是

参见“事件状态”定义

事件完成期限

是

对应每一个事件优先级，系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限

一、二、三线尝试解决时填写：

业务恢复时间

是

针对故障的业务恢复实际时间

事件日志

是

反映事件信息项的变化历史，如一个事件在处理过程中、事件状态变化的时间点等信息

解决方案

是

事件解决方案的描述

故障厂商

否

记录故障厂商信息

重复事件标记

否

标记为重复事件

一、二、三线尝试解决时，系统自动产生

事件状态

是

参见“事件状态”定义

实际开始时间

是

记录事件状态到XX处理中的时间

事件解决人

是

事件的最终解决人

处理是否超时

否

参见“处理是否超时”定义

实际完成时间

是

记录事件最后解决的时间

历时

是

“实际完成时间”-“事件发生时间”

关闭工单时填写

用户反馈

是

参见“用户反馈”定义

事件结束代码

是

参见“事件结束代码”定义

事件解决人角色

是

参见“事件解决人角色”定义

事件关闭时间

是

记录事件被关闭的时间

6.2事件性质

根据ERP系统的业务要求和管理要求，定义如下四类事件：

编号

代码

描述

故障

指因EPR系统错误或反映EPR系统部分或全部功能不能正常使用的报障；

申告

与EPR系统相关的用户投诉，如业务受理部门转来的因ERP系统问题引发的投诉

告警

监控平台自动产生的没有影响到系统正常使用的告警

咨询

指对系统操作、业务流程等方面的求助和询问

6.3事件来源

事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种：

编号

代码

描述

用户报告

用户或维护人员通过电话/邮件/运维平台报告的事件，服务台人员手工创建或修改事件单

ERP项目部人员报告

ERP项目部内部（一线/二线支持人员）提交的事件

监控系统报告

6.4事件所属系统类型

根据EPR应用系统的划分，定义事件所属系统类型。

当事件发生时，应该由服务台初步确定是哪个系统出现问题，再由一线作最终确认。

业务分类

业务系统分类

ERP业务

ERPR3系统

RMX专家系统

OA系统

运维服务管理系统

BI系统

BCS合并系统

PCS平台系统

称重系统

TIS接口系统

EPM系统

CRM系统

SCM系统

电子商务系统

其他

IT业务

略

6.5事件分类

分类代码用于标识故障或申告的具体业务类型，由服务台人员填写或修改，支持人员在处理过程再行确认或更新。

事件分类

销售管理

生产管理

质量管理

维修管理

采购与库房管理

人力资源管理

财务管理

行政办公管理

企业绩效管理

开发管理

用户及权限管理　

ERP运维服务管理

6.6事件优先级

优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级（紧急、高、中、低）。

编号

优先级代码

描述

紧急

事件需尽快解决，否则影响严重，包括但不局限于以下类别：

●影响生产经营的重要ERP应用系统完全不可用,例如SAP、RMX专家系统、OA

●严重影响重要业务，例如销售发货、产品生产、月结

●影响两家及以上工厂ERP应用系统的业务应用

●应用系统数据丢失

●影响公司管理层ERP应用系统的业务应用

高

●事件需尽快解决，否则影响较严重，包括但不局限于以下类别：

●影响生产经营的重要应用系统局部不可用,例如SAP、RMX专家系统、OA部分功能不可用

●影响生产经营的其他应用系统完全不可用，例如PCS、EPM、SCM、CRM、电子商务系统

●影响单家工厂ERP应用系统的业务应用

●影响业务主管部门、各事业部及区域管理层ERP应用系统的业务应用

中

事件解决的时间性要求不高，对业务操作影响不大：

●一般性系统故障

●用户申告

●影响工厂管理层ERP应用系统的业务应用

低

●业务咨询

●ERP应用功能增强

6.7事件响应时限和解决时限

在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制，一方面，需要各支持组或人员协同合作，在解决事件的时候应该有时间的概念，同时，也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理，同时，如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。

响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间；

解决时限指的是事件状态从“已登记”到“已解决”经过的时间；

事件优先级对应的事件响应时限和解决时限如下表：

编号

优先级代码

响应时限要求

解决时限要求

工作时间说明

紧急

10分钟

4小时

7×24小时

高

20分钟

8小时

7×24小时

中

30分钟

3个工作日

5×8小时

低

60分钟

4个工作日

5×8小时

事件发生时的通告定义

通知人员列表的用途：

当ERP运维服务管理平台收到事件时，按照表中的人员列表发出邮件或短信通知。

优先级别

通知人员列表

紧急

部门经理、事件经理、一、二线支持人员

高

事件经理，一、二线支持人员

中

通知一、二线支持人员

低

通知一线支持人员

超出响应时间的通告定义

通知人员列表的用途：

当ERP运维服务管理平台判断到响应时限已经超出，则按照表中的人员列表发出邮件或短信通知。

优先级别

通知人员列表

事件响应时限

紧急

部门经理、事件经理，一、二线支持人员

10分钟

高

事件经理、一、二线支持人员

20分钟

中

事件经理、一、二线支持人员

30分钟

低

事件经理、服务台、一、二线支持人员

60分钟

超出解决时限的通告定义

通知人员列表的用途：

当ERP运维服务管理平台判断到解决时限已经或即将超出，则按照表中的人员列表发出邮件或短信通知。

优先级别

通知时间

通知人员列表

事件解决时限

紧急

3小时

部门经理、事件经理、一、二线支持人员

4小时

高

7小时

部门经理、事件经理、一、二线支持人员

8小时

部门主管，相应事件经理，一、二线支持人员

中

71小时

事件经理、一、二线支持人员

72小时

部门主管，相应事件经理，一、二线支持人员

低

95小时

一线支持人员

96小时

相应事件经理，一、二线支持人员

6.8事件状态

事件状态代码表明事件所处的处理状态，事件状态如下：

编号

代码

描述

已创建

用户自行创建事件单并提交

已登记

服务台人员对已创建事件单更新或自行创建事件单

分配到服务台

事件已分配给服务台人员

服务台处理中

服务台人员已接手处理事件

分配到一线

事件已分配到一线支持，一线还未响应

一线处理中

一线支持人员已接手处理事件

分配到二线

事件已分配到二线支持，二线还未响应

二线处理中

二线支持人员已接手处理事件

分配到三线

事件已分配到三线支持，三线还未响应

三线处理中

三线支持人员已接手处理事件

已解决

事件已解决，支持人员联系用户验证事件是否获得解决

关闭

事件已关闭

6.9事件结束代码

展开阅读全文