流程管理 业务变更管理流程文档格式.docx

流程管理 业务变更管理流程文档格式.docx

《流程管理 业务变更管理流程文档格式.docx》由会员分享，可在线阅读，更多相关《流程管理 业务变更管理流程文档格式.docx（28页珍藏版）》请在冰豆网上搜索。

是否批准变更；

如果批准，什么时间实施。

本公司建议：

初期CAB－个季度对已实施的变更回顾一次，正常运行后某客户再根据运行情况确定周期；

针对具体某一项变更回顾的报告结果可以用附件的方式附加在该变更单上进行保存；

CAB也负责变更实施后的回顾以确保：

变更是否成功？

是否产生其他副作用？

实际所用的资源和预期的是否一致，如果不是，调整评估流程。

批准后，变更将进入计划，测试/构建和实施阶段。

计划/构建阶段也包括开发一个恢复计划（FallbackPlan），用以在实施阶段出现问题或紧急状况时需要把变更回退回去。

变更管理流程也负责紧急变更，在此种情况下，变更的评估，计划，测试和实施阶段都将快速进行。

来自

2.2.目的

某客户IT变更管理流程将通过标准统一的方法和步骤管理和控制所有对IT生产环境有影响的变更，主要的目的包括：

IT部门可以管理和引导用户变更需求；

通过对所有变更的正确评估，可以维护IT环境的完整性；

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

减少或消除由于变更实施准备不当等原因出现的对IT环境的破坏作用；

提供了一致性的变更实施质量控制；

提高资源使用率（如，未得到正确控制和授权的变更需要更多的后续资源）；

确保实施的变更不会超出预定的系统利用限值；

确保紧急变更请求得到快速实施（由紧急变更委员会（CAB/EC）负责）。

2.3.范围

变更管理流程涵盖生产环境及CMDB中CI的所有变更，包括：

服务器；

业务系统（新系统上线，生产系统的变动）；

客户端；

网络设备；

存储设备；

机房环境；

在ServiceDesk中的CMDB数据项及其和CI之间的配置关系；

不包括：

尚处于开发阶段的IT元素的变更；

不需要某客户IT部门介入，并且不影响IT运维的由用户控制的行为动作；

2.4.主要内容

某客户IT变更管理流程将包括如下内容：

接受RFC（变更请求）

●所有变更请求，都需递交到变更经理，供评估和批准。

●评估变更分类、变更级别等，确定与变更相关的CAB人员，变更经理对常规变更进行实施；

变更请求分类和登录

通过分类，确定该RFC的批准人和领导／执行人，并确定是否是紧急变更，紧急变更适用同一流程但将得到快速批准和实施。

提交RFC到变更顾问委员会（CAB）进行评估，确定影响度

变更经理将根据特定的变更请求成立特定的CAB，成员包括对该变更的评估和批准提供应有附加价值的技术人员和管理人员。

评估工作包括技术可行性，对容量的影响，对现有服务的影响，资源需求等。

批准RFC

变更经理确定对该RFC有批准权的经理参加CAB，必要时参与评估。

评估后该经理根据判断决定是否批准RFC。

检查变更计划／测试结果，并批准实施

变更经理确定合适人员主管该变更并参与CAB，称为变更主管。

变更请求得到评估和批准后，变更主管安排相应资源进行变更的构建／开发，然后需要对将要实施到生产环境的变更进行测试，并制定实施计划，随后提交测试结果和计划给变更经理以获得实施。

变更经理必需要确保测试结果和计划都有文档记录和得到签署，并确认变更对生产环境没有影响或影响可以得到控制。

这一步骤为变更流程的关键质量检查点。

规划RFC

RFC一旦获得批准，它必须根据资源和其他情况进行规划，确定实施日期，分配相应资源，并通知请求人。

协调变更实施Coordinatingthechangeimplementation

一切就绪后，可以实施变更。

建议某客户计算机中心的运维组实施相应变更，变更经理监视实施过程，并在必要时进行协调。

更新变更状态

在整个变更过程中，变更的状态从登记，评估，回顾到最后关闭是不同的。

变更经理负责更新预先定义好的变更状态。

回顾和关闭

实施变更后，变更经理负责从技术和流程角度去回顾变更，该回顾在预先定义好的时间段针对变更单独进行，除确保RFC得到了预期效果外，也寻找流程的改进机会，如资源计划和实际使用的一致性。

确定是否满足了变更目的，有没有副面影响，否则需制定后续行动计划。

随后，变更经理负责利用预先定义好的结束状态关闭RFC。

总结汇报

向管理层提供流程报表，向客户提供变更的相关执行信息。

定期向相关小组／部门根据流程衡量标准汇报很重要，只有如此，才可以基于现有环境的最新信息，作出进一步的改进建议。

变更会议

变更经理负责定期或不定期召开变更会议，以在IT内部以及与客户就变更管理有一个好的沟通。

在会上，可以传递如，最近变更规划（ＦＳＣ），将要实施变更的信息，也包括对变更流程的反馈和建议等。

变更流程回顾

建议定期回顾变更管理流程以提高效率和效能，在实施变更流程不久之后，可以进行第一次回顾，以确保流程得到正确实施并起到预期目的，发现的问题必须追根溯源并尽快解决。

之后，可以定期举行正式的回顾——如每三个月。

2.5.业务价值

本流程将有助于实现某客户提高IT系统可用性的运维目标：

确保所有变更的实施都不会对业务产生负面影响；

确保所有变更的处理和实施都遵循规范的变更流程；

确保所有变更及实施都得到完整记录；

快速响应变更请求RFC；

确保变更得到跟踪直至解决；

确保和所有相关人员/部门能就变更状态有良好沟通；

变更请求能有从业务/客户角度定义的影响度；

变更的处理机遇所定的影响度分析；

变更管理流程主要的好处在于：

提高IT环境的稳定性；

面对客户需求和技术的快速变化，变更的管理和控制将使对生产环境的变更实施可能带来的风险最小化。

降低运行成本；

良好的变更记录有助于运维流程的持续性改进，并加快变更相关问题的解决。

3.变更管理的人员角色和职责

在变更管理流程中，ITSM对角色建议有４个，变更经理，变更顾问委员会（CAB），变更主管和变更实施人员。

在标准ITIL标准流程中采用CAB环节一般作为参考条件，但是考虑到某客户目前很多运维和变更工作需要各个组协同执行，所以推荐成立CAB。

各角色述职如下：

3.1.变更经理

根据ITSM最佳实践，结合某客户的实际情况，建议变更经理和配置经理的角色是一个人，这样可以使变更管理和配置管理结合得更加紧密，同时可以保障配置管理CMDB的准确性。

另外，还可以使相关流程更加简捷，确保ITSM管理流程的可推广性。

变更经理职责：

接受变更请求（RFC），并做初步筛选；

确保变更请求（RFC）得到评估,授权,控制和计划；

确保所有相关人员都尽可能地引入到变更请求的评估中；

确保管理层得到足够关于变更的数量，影响度的信息；

成立变更委员会，并领导变更委员会（CAB）和主持相关会议；

确保变更在符合组织风险和需求的情况下，并在适当的时间内实施，在变更单中确定选择实施时间（保证实施时间的有效性）；

分派相应资源；

协调变更的构建／测试和实施；

领导，支持和指导员工，确保变更管理人员足够的积极性和绩效表现；

确保变更管理流程，制定相关工作步骤及准则；

提供复杂变更请求（RFC）的项目管理指导；

生成有效的管理报表；

变更经理主要技能：

非常了解变更管理、问题管理、配置管理和事件管理流程及其他们之间的关系；

了解公司的IT架构和环境；

了解配置项之间的关系；

较强的沟通技巧；

较强的组织能力；

很强的团队领导能力；

变更经理主要考核指标：

变更请求（RFC）的有效管理和控制；

在变更回顾中，无效和负面变更的情况；

对其他管理流程的支持力度；

3.2.变更顾问委员会（CAB/EC）

变更顾问委员会（CABorCAB/EC）职责：

回顾所有提交重要的RFC，并确保它们的潜在影响和风险得到评估；

针对具体变更请求，评估并讨论相应资源的分派；

回顾所有已执行的变更，确保满足变更目的；

参加CAB会议和紧急CAB会议；

协作变更经理确定变更优先级及变更规划；

在某客户，变更经理可能对CAB成员（大部分是运维组成员）没有行政权，为了保证CAB成员都能够参加讨论，同石化相关人员确认建议，可以在CAB中加入运维组组长；

变更顾问委员会（CABorCAB/EC）的组成人员：

CAB的组成人员可以根据具体的变更种类指定不同的人参与；

固定成员：

变更经理、运维组组长、变更主管、项目组组长；

如果是重大的实施类变更，需要某客户计算机中心领导人参与，如，科长或主任等；

一般的实施类变更，CAB成员可以简化，如，变更主管可以和变更实施人员合并；

3.3.变更主管

变更主管属于不确定具体人员的角色，可以根据不同的变更种类，分派不同的人员作为变更主管。

对于普通的实施类变更，还可以将变更主管和变更实施人员合并在一起。

变更主管主要关注在测试计划、技术方案、实施计划等。

变更主管职责：

接受变更请求，并协调实施；

作为具体变更的项目经理，负责领导变更的构建／测试，实施和参与回顾；

制定变更项目计划和时间规划等；

更新项目记录，生成变更工单；

在整个变更中协调各工单，以维护变更项目的整体性；

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

在必要时，确保恢复计划（FallbackPlan）得以正确实施。

3.4.变更实施人员

变更实施人员主要关注在测试、具体现场实施等。

变更实施人员职责：

根据变更主管制定的变更计划实施变更；

执行分派的任务以推进变更项目；

向变更主管汇报工作进程（在系统中加入时间限定：

当变更没有在预定的时间内得到实施，系统将自动通知变更主管和变更经理）；

现场负责变更实施或恢复实施。

3.5.某客户人员角色定义

角色

人员安排

备份安排

变更管理委员会

变更经理

变更主管

XX、XX

变更实施人员

系统管理员、项目组人员

4.变更管理流程说明

4.1.变更管理总体流程

根据某客户IT的具体情况，同时结合ITIL的最佳经验，某公司给出下面的变更管理的逻辑流程：

注：

相关符号的说明：

=相关工具和人员

=流程

=决策

所有优先级为普通、中、高的变更都将完全按照如上流程执行，各步骤的描述如下：

序号

步骤名称

责任人

说明

300.1

提交变更请求

变更请求者

请求者找出变更求请需求，然后跟相关部门或客户确认后填写变更请求单并提交给变更经理，如果常规变更，则由变更经理直接执行并结束变更。

300.2

接受变更请求

接受变更请求，检查变更请求的完整性和正确性，确定相关变更顾问委员会CAB成员和变更主管。

常规类变更?

判断所提交的变更是否为常规类变更，如果是，直接至“结束”判断框，此时变更经理直接执行变更并结束变更；

如不是常规类变更，则继续。

紧急吗?

判断是否为紧急变更，如是，则转紧急变更流程，否则继续。

300.3

评估风险/影响

变更顾问委员会CAB

召开会议或指定人员对变更请求进行评估并得出评估结果。

授权吗?

决定是否对该变更请求授权，如果授权，则继续，否则拒绝变更请求并有变更经理与变更请求者进行沟通。

300.4

测试/实施计划

变更主管作为该变更项目经理，负责协调开发、测试和制定实施计划，并把测试结果和实施计划递交给变更经理以批准实施。

批准吗?

决定是否批准实施变更，必要时召集变更顾问委员会，如批准，则继续，否则把测试结果和实施计划退还给变更主管并要求重新提交。

300.5

计划和沟通

确定一个最合适的实施日期并和相关部门进行充分沟通。

300.6

实施

根据实施计划执行变更实施，在必要时启动恢复计划（FallbackPlan）。

300.7

回顾

变更经理召开变更顾问委员会对实施的变更进行回顾以确定变更目的是否已达到，如没有，要求变更主管制定一个后续行动计划并通过变更经理的审核。

300.8

结束

更新相关信息，关闭变更记录。

4.2.变更管理流程和其他管理流程的关系

4.3.变更管理详细流程

结合上面的逻辑流程和某客户的实际情况，某公司建议如下变更管理的物理流程。

（350）紧急变更逻辑流程

在日常运维过程中，紧急的变更和运维工作占了很大运维比率。

为了使紧急流程更能够符合某客户的实际情况，项目组在该问题上做了深入的讨论。

某客户对紧急流程处理的目标是：

1.实施流程尽量简化；

2.保证对流程的控制；

在ITSM/ITIL中确定了紧急流程的定义，但并没有详细做法。

结合某公司顾问的经验和某客户的实际情况，具体确定了以下策略来确保紧急变更流程的实施。

对于紧急变更，某公司顾问建议成立CAB紧急委员会，称为CAB/EC，对紧急变更请求进行评估和授权。

下面是紧急变更逻辑流程，其物理流程和正常变更的物理流程一致（具有相同的流程步骤名称，除了在每个名称前加上“快速”以作区别）。

CAB/EC成员可以是固定的，建议由某客户信息科技部安全运行处长、运维组组长和变更经理组成。

紧急变更的特殊之处是变更文档可以在变更实施完之后提交，但必须在可能的情况下通知变更经理并得到CAB/EC的口头批准。

流程详细描述如下：

350.1

紧急度确认

CAB紧急委员会（CAB/EC）

得到变更经理的紧急变更的口头或电子请求后，进行紧急度确认；

召开紧急会议或以Email+电话形式确定是否确属紧急变更请求，如不是，返回正常流程300.3，（建议参与CAB/EC者有信息科技部部长、安全运行处处长和变更经理，而且安全运行处处长必须参加并执行决定权，）如果是，继续；

350.2

快速评估

召开紧急会议，对紧急变更请求进行快速评估，包括影响度/风险和所需资源评估，并快速得出评估结果；

350.3

快速测试和制定计划

快速进行各种测试并制定必要的实施计划，并安排实施；

350.4

快速实施

根据实施计划，快速执行变更，必要时启动恢复计划（FallbackPlan）；

350.5

收集相关文档资料

紧急变更结束后，变更经理收集由变更实施人员递交的相关文档，包括测试结果和实施计划；

资料周期的搜集期限是2个工作日。

350.6

变更经理召开紧急变更顾问委员会CAB/EC，对实施的紧急变更进行回顾以确定变更目的是否已达到，资料收集是否完整，加以控制，需要对其进行实效控制（2个工作日）；

如没有，要求变更主管制定一个后续行动计划并通过变更经理的审核；

350.7

更新相关信息，关闭变更记录；

（300.1）提交变更请求

物理流程详细描述如下：

300.1.1

找出变更请求

基于技术需求和业务需求，找出变更机会；

300.1.2

收到变更请求

从其他IT成员或从客户部门得到变更请求；

300.1.3

确认变更请求

和部门负责人对变更请求进行确认，并得到批准；

300.1.4

填写变更请求

打开变更管理页面，填入相关变更信息；

300.1.5

把变更请求提交（分派）给变更经理，变更经理将获得相关通知；

（300.2）接受变更请求

物理流程描述

300.2.1

接受提交过来的变更请求；

300.2.2

根据变更的具体情况，确定变更顾问委员会成员和变更主管；

300.2.3

更新变更请求的相关信息；

紧急吗？

判断是否为紧急变更请求，如是，转紧急变更流程350，否则继续；

（300.3）评估风险/影响

评估风险/影响物理流程详细描述如下：

300.3.1

根据已确定的变更顾问委员会成员，确定会议议程,召开变更评估会议；

300.3.2

根据变更的具体情况，确定该变更的影响度及其影响度代码；

300.3.3

根据变更的具体情况，确定该变更的风险情况及其代码；

300.3.4

确定变更所需要的资源，包括所需时间等；

300.3.5

总结所有分析结果，得出最终决定；

决定是否给变更授权，如是转300.3.7，否则继续；

300.3.6

根据CAB决定，拒绝变更请求；

300.3.7

记录评估结果，并相应做初步规划；

300.3.8

跟变更请求者进行沟通，告知变更请求被拒绝原因；

300.3.9

更新工单状态，结束。

（300.4）测试/实施计划

测试/实施计划物理流程详细描述如下：

300.4.1

在需要的情况下做完必要的开发和功能测试后，制定变更项目实施的沟通计划，如在什么条件下谁该做什么，应该联系谁等；

300.4.2

根据具体要实施的变更，制定具体的任务列表；

300.4.3

制定从运维角度看如何满足运营要求的运维接受测试（OAT）计划；

300.4.4

根据先前风险评估得出的风险及其风险度，制定相应的风险管理计划；

300.4.5

根据风险情况，制定相应的恢复计划（FallbackPlan），以在需要时恢复变更

300.4.6

收集测试结果和制定的实施计划，提交给变更经理；

300.4.7

分析由变更主管提交的变更测试结果和实施计划，作出相应的决定；

批准？

根据分析，以确定是否批准实施，如是，转300.5.1，如否，退还变更主管重新测试和制定计划；

（300.5）计划&

沟通

计划&

沟通物理流程详细描述如下：

300.5.1

根据变更请求日期，测试结果和实施计划，确定实施日期；

300.5.2

根据确定的实施日期，找出与其相关的其他变更，并解决相互的关联关系，包括资源、人员等；

300.5.3

确定变更实施时间的冲突关系并协调解决；

300.5.4

判断确定的实施日期是否可行，如是，继续，否则返回300.5.1，重新确定日期；

300.5.5

根据确定的实施日期，与相关人员进行沟通，包括变更主管，变更实施人员等；

300.5.6

把变更相关信息通知相关用户，如可能的影响等；

（300.6）变更实施

变更实施流程详细描述如下：

300.6.1

变更实施人员

执行变更主管制定的运维接受测试（OAT）计划，以确认变更能符合运维的要求；

OK？

判断运维接受测试是否成功？

是则继续，否则重新进行OAT测试；

300.6.2

根据测试结果再次确认实施时间；

300.6.3

在确定的变更实施时间根据实施计划具体实施变更；

成功？

判断变更是否成功，是则继续，否则转300.6.5，执行恢复计划；

300.6.4

确认实施确已完成并符合预期质量要求；

300.6.5

执行变更主管制定的恢复计划（FallbackPlan），以恢复变更；

（300.7）回顾

回顾流程详细描述如下：

300.7.1

召开回顾会议（可以是各种形式，包括电话会议）；

实施了恢复计划？

判断是否实施了恢复计划，是则转300.7.2分析根本原因，否则转300.7.3开始技术回顾；

300.7.2

分析变更失败的根本原因；

300.7.3

从技术的角度回顾变更的实施过程；

300.7.4

从流程的角度回顾变更的实施；

变更目的达到？

综合起来判断变更目的是否达到，是则转300.7.7，记录回顾结果，否则转300.7.5，制定后续行动计划；

300.7.5

根据分析出的变更失败的根本原因制定后续行动计划，并将该后续行动计划进行测试和指定实施计划（300.4.1）；

300.7.6

记录和整理回顾的结果，包括成功的变更