ERP运维管理之变更管理流程设计说明书.docx

ERP运维管理之变更管理流程设计说明书.docx

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

ERP运维管理之变更管理流程设计说明书

华新ERP运维管理之变更管理流程设计说明书

慧眼工程

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

版本V1.0

2010/05/31

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

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

作者

作者

联系方式

李春雷

▪电子邮件:

chunlei.li@

▪电话:

修订

日期

文档版本

修订描述

文档作者

2010/05/31

1.0

初始版本

姓名:

李春雷

审批

审批日期

审批版本

审批人角色

审批人

2010/06/01

1.0

凯捷项目经理

姓名Name:

蔡玮

2010/06/01

1.0

华新项目经理

姓名Name:

张林

1流程目的

变更管理流程将通过标准统一的方法和步骤来管理和控制所有对ERP生产环境有影响的变更。

主要目的包括：

❑ERP部门可以管理和引导用户变更需求

❑通过对所有变更的正确评估，可以维护ERP生产环境的完整性

❑变更和变更实施得到正确记录，并提供审核依计

❑减少或消除由于变更实施准备不当等对ERP环境的破坏作用

2流程主要内容

变更管理流程始于变更的接收，结束于变更的实施和回顾。

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

❑提出变更请求、评估、分类

变更申请人提出变更请求，由变更主管负责检查和完善其内容，通过查询配置管理数据库，进行风险等级的初步评估；并尽量提出可能与业务发生的关联的影响，以供决策参考。

变更主管对变更进行分类；如为紧急变更，则按照紧急变更子流程执行；如为简单变更，直接制定变更计划，并安排实施。

❑变更主管负责组织制定变更计划、测试

变更主管安排并协调相应资源制定变更计划，包括实施计划、测试计划、回退计划、配置项更新计划等。

应安排对实施计划进行测试，随后将测试结果、实施计划、测试计划、回退计划、配置项更新计划等提交给变更经理审核。

❑变更经理评估、审批

变更经理接受变更请求，如果确定是紧急变更，则快速完成评估、审批。

对标准变更，确定变更风险等级，审阅变更实施计划、测试计划、回退计划和配置项更新计划，批准或驳回变更申请，如需要更高级别的审批，则根据不同风险级别报批。

❑变更委员会/紧急变更委员会评估、审批

变更经理将根据特定的变更请求成立特定的变更委员会，成员包括对该变更的评估和批准提供应有附加价值的技术人员和业务管理人员，审阅工作包括变更的风险、对现有服务的影响、实施计划、测试计划、回退计划和配置项更新计划等，并做出批准与否的决定。

如为紧急变更，则快速完成以上评估、审批。

❑公司审批

对于风险等级为“重大”的变更，在变更委员会审批通过后，必须再由变更经理报请至公司管理层审批。

❑协调变更实施

变更主管负责协调资源，准备实施前相关工作，组织人员按计划实施变更，变更主管监控实施过程和结果，并在必要时进行协调或做出决定。

在这阶段可能需要变更经理和变更委员会成员的帮助。

❑回顾和关闭

实施变更后，变更主管确保配置项及时得到更新，并协同变更经理负责从技术、管理、业务角度去回顾变更，确保变更请求达到了预期效果，如未达到预期效果则寻找改进机会，确定后续行动计划。

在回顾过程中可能会需要得到变更委员会中相关领域技术人员和业务管理人员的帮助，随后更新变更记录并关闭变更请求。

3与其他流程的关系

变更管理流程可以从其他的服务管理流程接收到变更请求。

❑和配置管理流程的关系

变更管理涉及到的配置改变应当在配置管理数据库中得到体现，改变的数据可能包括配置项、配置项间的关系或配置项的某些属性；

变更的评估需要从配置管理数据库中获取相关的信息进行分析。

❑和事件管理流程的关系

事件的解决涉及到需要对基础架构、应用系统及操作系统等进行变更的，需要触发变更管理流程来实现，变更成功实施后应当通知事件管理流程。

❑和问题管理流程的关系   

问题管理流程中对于错误的修正涉及到需要对基础架构、应用系统及操作系统等进行变更的，需要触发变更管理流程，变更成功实施后应当通知问题管理流程。

4关键角色、职责定义

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

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

4.1变更请求者

根据工作的需要，发起变更请求的ERP维护人员。

职责：

❑必要时提出变更申请，创建变更请求单，并提交给相关业务或技术领域的变更主管

❑在变更处理过程中提供必要的信息。

对于由用户提出的有效变更请求，应要求用户提交相关审批文档，并作为附件录入变更请求单。

技能要求：

❑具备一定的业务、技术背景

❑熟悉变更管理流程

人员配置：

❑ERP维护人员

4.2变更主管

变更主管通常由与变更请求内容相关的具体业务或技术领域的负责人担任。

可以根据不同的变更种类，分派不同的人员作为变更主管。

对于某些重要变更，还可以将变更主管和变更实施人员合并在一起；变更主管主要关注实施方案、详细实施计划等方面。

职责：

❑检查由变更请求者提交的每一个变更请求，检查变更的正确性和必要性，必要时拒绝无关、无法实施或没有必要的变更请求，若为有效的变更请求，应检查列入变更请求单附件的审批文档

❑初步判断及评估变更请求的分类、变更时间要求、风险等级等

❑制定变更实施计划、测试计划、回退计划、配置项更新计划等

❑作为具体的变更项目负责人，负责领导该变更项目的开发、测试、实施和参与回顾

❑针对具体变更请求，评估并分派相应资源

❑确保变更在预定的时间、资源和成本内完成

❑在必要时，确保回退计划得以正确实施

❑负责收集与该变更有关的部门或小组的意见，综合评价变更对于业务运行的影响

技能要求：

❑较强的业务、技术背景，

❑较强的项目管理技能

❑较强的分析能力

❑以用户为导向、良好的沟通能力

❑熟悉变更管理流程

人员配置：

❑由各业务模块及开发组的经理担任

4.3变更经理

变更经理全面负责变更管理流程中的所有具体活动执行，保障所有变更依照预定流程顺利执行。

职责：

❑帮助变更主管协调必要的变更时间、人员等方面的工作

❑审批变更请求，确保只有授权和必要的变更才被实行，并使该种变更影响最小化

❑成立变更委员会，并主持变更委员会、紧急变更委员会会议

❑定期召开变更回顾会议

❑参与流程评估，对流程改进提出建议

技能要求：

❑在ERP项目部拥有足够的权威且受到尊重

❑深厚的业务、技术背景

❑较强的决策力和判断力

❑优秀的项目管理技能

❑有效的会议组织与管理能力

❑以用户为导向、良好的沟通能力

❑深刻理解变更管理流程

人员配置：

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

4.4变更委员会、紧急变更委员会

变更委员会、紧急变更委员会是对变更进行评估和决策、批准或者拒绝某个变更请求的虚拟组织。

职责：

❑参加变更委员会会议、紧急变更委员会会议

❑针对具体变更请求，评估潜在影响和风险，必要时协调所需资源

❑协助变更经理对变更做出审批、决策

❑回顾失败变更，以确保今后不再发生类似情形

❑回顾已执行的重大变更，确保满足变更的目的

❑对流程改进提出建议

技能要求：

❑在各自的业务、技术领域拥有足够的权威

❑深厚的业务、技术背景

❑较强的决策力和判断力

❑准确理解业务需求的能力

❑以用户为导向、良好的沟通能力

人员配置：

❑变更委员会主要由ERP项目部的部门领导、变更经理、发布经理、各变更主管组成，必要时应邀请公司相关业务主管部门的负责人、第三方厂商等参加会议。

紧急变更委员会由ERP项目部经理、变更经理及相应业务或专业领域的变更主管组成，履行紧急变更委员会的职责。

4.5变更实施人员

变更实施人员负责变更在生产环境中的实施，必要时第三方厂商也可参与变更实施过程

职责：

❑协助变更主管制定变更实施方案

❑记录变更实施相关的信息，确保文档的完整性

❑负责实施和测试

❑变更完成后，进行监控，并记录监控结果

❑与变更主管沟通，通报变更实施的进度和结果

技能要求：

❑较强的业务、技术背景

❑较强的沟通、协调能力

❑较强的分析能力

人员配置：

❑ERP维护人员

4.6变更管理流程负责人

变更管理流程负责人从总体上对问题管理流程的设计、实施、执行及优化负责。

。

职责：

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

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

❑确保变更流程符合公司实际状况和公司ERP发展战略

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

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

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

技能要求：

❑深刻理解变更管理流程

❑能够很好地理解业务对于变更管理的需求

❑对质量控制与保障有很深入的了解

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

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

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

人员配置：

❑由ERP项目部经理担任

5执行原则

5.1常规原则

❑所有影响生产环境配置项的变更都必须严格遵循变更管理流程

❑所有的变更请求记录都应被记录和追踪

❑所有变更实施过程都应记录在ERP运维管理平台

❑每月出具变更管理报表，对失败的变更和风险等级重大的变更进行回顾和检查，以更好地管理变更流程

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

5.2流程关联原则

❑和配置管理的关联

Ø在制定变更计划时通过查询配置管理数据库，评估变更可能影响的系统，制定变更计划时需制定配置项更新计划，变更实施完成后需确保配置项信息及时更新，只有配置项更新完成后，才能关闭变更请求单

Ø配置项信息的变更需要通过变更管理流程控制

❑和事件管理的关联

Ø解决事件的过程中涉及到需要对应用系统等进行变更的，需要触发变更管理流程，如果变更管理流程是由事件管理流程触发，则事件记录必须与变更记录相关联

❑和问题管理的关联

Ø解决问题的过程中涉及到需要对应用系统等进行变更的，需要触发变更管理流程，如果变更管理流程是由问题管理流程触发，则问题记录必须与变更记录相关联

5.3变更实施记录原则

❑所有变更实施过程都必须记录在ERP运维管理平台，以体现出变更实施中的主要执行环节和执行情况，比如各关键步骤的起始时间、结束时间、执行人、执行结果、异常情况等。

具体记录方式可采用在该变更请求单上增加填写信息项，或新增任务单等其他方式，记录的信息项参见变更实施单信息项定义

5.4变更分类执行原则

❑简单变更采用预授权的方式，由变更主管直接安排实施，并通告变更经理

❑标准变更由变更经理总体负责，通过与各相关方面协同，采取多种方式，严格管理其计划、评估、审批、测试、实施

❑紧急变更提供变更快速实施处理的机制

5.5分级审批原则

❑风险等级为低的变更，由变更主管负责审批

❑风险等级为中的变更，由变更经理负责审批

❑风险等级为高的变更，由变更委员会审批，必要时邀请ERP项目部主管副总裁（总裁助理）

❑风险等级为重大的变更，由变更委员会预审批，然后提交公司管理层（ERP项目指导委员会）审批

5.6所有权原则

❑变更主管负责审核变更请求的有效性和正确性，制定相应的变更计划，并处理各种变更执行时的日程安排和协调，必要时可以得到变更经理的帮助

❑变更经理负责关闭紧急变更，变更主管负责关闭其他变更

❑对于不在变更经理审批权限内的变更，由变更经理负责提交至变更委员会审批

❑对风险等级为重大的变更，在变更委员会审批完成后，由变更经理负责提交至公司审批

5.7变更通知原则

❑对现有业务系统产生影响的变更，例如因实施变更而需要停机或者中止业务，均需在变更执行前提前通知有关人员做好业务调整，减少对业务的影响，待实施完成后再次通告

5.8紧急变更处理原则

❑紧急变更必须通过E-MAIL等书面方式申请，但可以口头获得紧急变更委员会审批，事后必须在ERP运维管理平台补变更申请单及相关测试和审批文档，其中变更申请单信息项中必须填写变更实施记录、变更测试记录和变更观察记录，这三项内容即为紧急变更操作日志

❑紧急变更实施前应尽量进行必要的测试，如由于紧急变更而无法完成的测试应在实施后安排补测

❑尽量控制紧急变更的次数，以免变更失败影响业务运行

5.9变更测试原则

❑对生产系统进行变更时，需根据变更的性质、影响程度等情况在变更请求单中选择是否需要在测试环境进行测试。

如果需要，则按照测试计划进行测试，测试后需由相关测试人员确认并提供测试报告

5.10变更文档控制原则

❑变更计划通常包括实施计划、测试计划、回退计划、配置项更新计划等

❑对应用系统上线类的变更，除变更计划外，还需包括变更功能说明文档、变更技术说明文档及测试报告

❑对数据迁移类的变更，除变更计划外，还需包括转换方案，该方案一般包含数据转换策略、数据转换测试、数据备份及恢复方案、数据转换结果核对等方面的内容

❑对要求上报公司管理层审批的变更，提交的文档具体内容说明如下:

Ø变更总体方案（包括变更原因、变更前后系统拓扑、配置或功能对比、变更总体计划、具体方案、进度安排、人员分工、测试标准、风险评估等）

Ø测试报告（提供系统在变更前的测试范围、测试步骤、测试项目、测试情况等）

Ø变更回退/应急方案

6流程相关定义

6.1变更申请单信息项

变更申请单必须包含如下变更信息项：

序号

信息项

是否必填

说明

变更发起时填写－变更发起人

1

实际请求人信息

是

记录实际变更请求人的信息，包括：

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

2

关联的事件单号

否

如果变更来源是事件，则关联到相应的事件单

3

关联的问题单号

否

如果变更来源是问题，则关联到相应的问题单

4

变更来源

是

参见“变更来源”定义

5

变更简要描述

是

简单描述变更请求

6

变更详细描述

是

详细描述变更的内容

7

变更所属系统类型

是

参见“变更所属系统类型”定义

8

变更分类

是

参见“变更分类”定义

9

变更需求单位

是

10

关联配置项

否

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

11

附件

否

上传附件

12

分配对象

是

将问题分配到各组变更主管

变更发起时，系统自动填写

13

变更ID

是

为每个变更请求分配一个唯一的序列号

14

建单人

是

变更请求的记录人

15

登记时间

是

变更请求创建的时间

16

变更状态

是

参见“变更状态”定义

检查、测试和计划阶段填写－变更主管

17

风险等级

是

参见“风险等级”定义

18

变更类型

是

参见“变更类型”定义

19

所影响的应用系统

否

实施该变更将对哪些应用系统产生影响，用于评估变更

20

变更是否中断业务

是

参见“变更是否中断业务“定义

21

变更是否需要测试

是

参见“变更是否需要测试“定义

22

需通知部门

否

需要通知的部门名称

23

变更计划

否

使用附件形式。

变更计划通常包括变更的实施计划、测试计划、回退计划、配置项更新计划等

24

计划开始时间

是

变更计划开始时间YYYY-MM-DDHH:

MM

25

计划完成时间

是

变更计划完成时间YYYY-MM-DDHH:

MM

26

中断关键业务1名称

否

描述该变更所中断的关键业务系统1的名称，填写内容参见“变更所属系统类型”中的子类定义

27

关键业务1中断时长

否

描述该变更所中断的关键业务系统1的时长，按分钟计算

28

中断关键业务2名称

否

描述该变更所中断的关键业务系统2的名称，填写内容参见“变更所属系统类型”中的子类定义

29

关键业务2中断时长

否

描述该变更所中断的关键业务系统2的时长，按分钟计算

30

中断关键业务3名称

否

描述该变更所中断的关键业务系统3的名称，填写内容参见“变更所属系统类型”中的子类定义

31

关键业务3中断时长

否

描述该变更所中断的关键业务系统3的时长，按分钟计算

32

中断关键业务

否

描述该变更所中断的所有关键业务系统名称

33

关键业务中断总时长

否

描述该变更中断的所有关键业务系统的时长，按分钟计算

34

变更测试记录

是

描述测试的情况、测试结果

35

关联配置项

否

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

36

附件

否

上传附件

37

变更主管

是

变更主管姓名

38

变更实施单位

是

39

变更主管接受变更时间

是

变更主管接受变更请求的时间

需求审批阶段填写－变更经理

40

变更审批记录

是

记录变更审批的历史记录，包括如下信息：

审批人姓名、审批结果、原因、时间等

41

分派对象

是

将变更分派到各变更主管

需求审批阶段填写－变更委员会

42

变更审批记录

是

记录变更审批的历史记录，包括如下信息：

审核人姓名、审批结果、原因、时间等

实施阶段填写－变更实施人

43

分派变更任务

否

分派变更任务给变更实施人员

44

变更实施记录

是

用于描述实施时的现场情况

45

实际开始时间

是

变更实际开始时间YYYY-MM-DDHH:

MM

46

实际完成时间

是

变更实际完成时间YYYY-MM-DDHH:

MM

回顾阶段填写－变更主管

47

变更观察记录

否

描述变更结束后，观察期间的情况

48

回顾意见

否

变更委员会对变更进行回顾后得出的意见

49

回顾代码

否

参见“回顾代码”定义

关闭时填写－变更主管

50

变更结束代码

是

参见“变更结束代码”定义

51

关闭人

是

关闭人的姓名

52

关闭时间

是

变更关闭的时间YYYY-MM-DDHH:

MM

其他

6.2变更来源

变更来源用于区分触发变更的其他流程或需求，以便进行有效地关联。

编号

代码

描述

1

事件

变更来源于事件

2

问题

变更来源于问题

3

配置

变更来源于配置项信息的调整

6.3变更类型

变更类型用于区分变更，提高变更处理的效率。

编号

代码

描述

1

简单变更

指频繁发生、影响范围较小、紧急程度较低、实施风险较小（不会带来重大后果）、实施较简单的变更，如用户权限管理、系统组织架构的变更等。

2

标准变更

指涉及影响范围较大（影响客户、业务部门或者社会影响较大）、实施风险较大、实施较复杂的变更。

这些变更可以进行充分的计划和测试。

如涉及程序开发或修改的变更、涉及流程或业务规则变动的变更、数据迁移、应用系统升级等

3

紧急变更

指如果不进行变更，会立即或正在严重影响业务运行、导致严重影响服务水平或者带来重大影响的变更，应当得到尽可能快速的处理，减少流程的复杂性，但是又要有良好的控制。

如紧急事件引发的紧急变更，参见事件管理流程中的紧急事件定义。

6.4变更是否中断业务

变更可能会引起业务中断，需要在变更评估时加以说明。

编号

代码

描述

1

是

变更会引起业务中断

2

否

变更不会引起业务中断

6.5变更是否需要测试

变更实施前是否需进行必要的测试。

编号

代码

描述

1

是

变更需要测试

2

否

变更不需要测试

6.6风险等级

除简单变更外，变更主管、变更经理、变更委员会/紧急变更委员会对标准变更和紧急变更根据下表所列的衡量因素来量化评估实施变更可能带来的风险，该评估结果用于决定是否批准变更，是否需要更高级别的审批，以及实施完成后的观察期。

该评估由变更主管进行初步评定，再由变更经理或变更委员会进行最终确定。

风险等级量化评估表如下：

衡量因素

条件

得分

业务运行受影响程度

非常严重

4

严重

3

较轻

2

无

1

变更成功的可能性

无法测试，变更失败可能性很高

4

能实现部分测试，变更失败可能性较高

3

有成熟的变更方案，变更失败可能性低

2

有成熟的变更方案，变更失败可能性非常低

1

准备/实施必需的资源

4个或更多支持小组

4

3个支持小组

3

2个支持小组

2

1个支持小组

1

变更实施时间（变更审批通过开始实施至上线）

60天以上

4

6-60天

3

1-5天

2

小于1天

1

根据上表对每个变更进行评估，最终得出风险等级。

风险分为四个等级：

重大、高、中、低。

不同的风险等级分别有对应的审批级别和实施完成后的观察期，具体定义如下表：

总得分

对应风险等级

对应审批级别

实施完后的观察周期

15–16

重大

变更委员会、公司管理层

5-7天

12–14

高

变更委员会

4-5天

8–11

中

变更经理

2-3天

4-7

低

变更主管

1天

6.7变更所属系统类型

定义变更所属的业务系统。

业务分类

业务系统分类

ERP业务

ERPR3系统

RMX专家系统

OA系统

运维服务管理系统

BI系统

BCS合并系统

PCS平台系统

称重系统

TIS接口系统

EPM系统

CRM系统

SCM系统

电子商务系统

其他

IT业务

略

6.8变更分类

分类代码用于标识变更的具体业务类型，由变更申请人填写，变更主管在处理过程再行确认或更新。

变更分类

销售管理

生产管理

质量管理

维修管理

采购与库房管理

人力资源管理

财务管理

行政办公管理

企业绩效管理

开发管理

用户及权限管理　

ERP运维服务管理

6.9变更状态

变更从提出到最后被关闭，会历经各个阶段。

变更处于不同的处理阶段具有不同的状态，需要不同的角色参与。

以下是变更请求从提出、实施到结束的整个生命周期中的不同状态：

编号

代码

描述

1

已登记

变更请求已登记入系统，变更主管还未受理

2

接收需求

变更主管接收变更申请人的变更请求

3

需求审批

变更经理对变更请求进行需求审批

4

计划中

变更主管对变更进行规划，检验变更单的分类和信息是否正确，提交必要的变更文档

5

等待审批

变更请求提交给变更经理或变更委员会、或公司等待审批

6

已批准

变更单得到批