业务变更管理流程
版本记录
目录
1.文档介绍 (1)
1.1.文档简介 (1)
1.2.文档用途 (1)
2.变更管理流程简介 (2)
2.1.变更管理流程描述 (2)
2.2.目的 (3)
2.3.围 (3)
2.4.主要容 (3)
2.5.业务价值 (5)
3.变更管理的人员角色和职责 (7)
3.1.变更经理 (7)
3.2.变更顾问委员会（CAB/EC） (8)
3.3.变更主管 (8)
3.4.变更实施人员 (9)
3.5.某客户人员角色定义 (9)
4.变更管理流程说明 (10)
4.1.变更管理总体流程 (10)
4.2.变更管理流程和其他管理流程的关系 (12)
4.3.变更管理详细流程 (12)
4.3.1.（350）紧急变更逻辑流程 (12)
4.3.2.（300.1）提交变更请求 (15)
4.3.3.（300.2）接受变更请求 (15)
4.3.4.（300.3）评估风险/影响 (16)
4.3.5.（300.4）测试/实施计划 (17)
4.3.6.（300.5）计划&沟通 (18)
4.3.7.（300.6）变更实施 (18)
4.3.8.（300.7）回顾 (19)
4.3.9.（300.8）结束 (20)
4.4.SD相关代码定义 (20)
4.4.1.请求者优先级别 (21)
4.4.2.影响度 (21)
4.4.3.风险 (21)
4.4.4.状态 (22)
4.4.5.变更工单实施状态 (22)
4.4.6.结束代码 (22)
4.4.7.类别（Category） (22)
4.4.8.类型（Type） (23)
5.变更管理流程控制 (24)
5.1.变更管理流程政策/建议 (24)
5.1.1.政策 (24)
5.1.2.建议 (25)
5.2.管理报表 (25)
5.3.工作报表 (26)
6.附件 (27)
1.文档介绍
1.1.文档简介
本文档是某客户变更流程设计说明及分析报告，是中国某公司和某客户信息科技部安全运行处（以下简称某客户）一起制定的变更管理的流程说明文档，通过制定该流程，可以帮助所有实施IT变更的人员有一套规的分步流程去更新或升级生产环境中的IT系统。
从而保证由于变更而引起的对IT环境的影响降到最小，提高IT系统和服务的质量，为业务的快速发展提供更优质的IT服务，并且可以有效地实施其他相关ITSM管理流程，如配置管理。
本文档描述的是依据目前某客户的IT服务状况而制定的变更管理流程说明，以后进一步的更新和优化将由某客户负责。
文档用途来自
1.2.
本文档一方面作为本次ITSM项目的变更管理流程说明的交付物，也可为进一步设计变更管理流程的蓝本，读者对象为与变更管理流程相关的所有技术和管理人员。
本文档所描述的流程在IT服务管理中有许多作用，它提供一个统一的一致的生产系统的实施和变更流程以确保：
a) 所有需要的递交物已完成；
b) 所有的系统已测试；
c) 已完成彻底的实施计划。
变更管理流程确保在打软件补丁，实施事件解决方案或引入新系统时有能够遵循的流程。
它详细描述在某客户的IT环境中如何实施一个变更，如，上线一个新系统。
并包括定义在变更流程中涉及的文档资料。
2.变更管理流程简介
2.1.变更管理流程描述
变更管理理想来看应该是一个单一的职能流程来控制和管理整个IT运行环境中的一切变更，并和配置管理建立接口。
变更管理应该由管理工具来支持，管理的围可包括软件，硬件，通讯设备和文档等的变更。
变更经理应该对整个变更流程负责，但这并不意味着自己要做每件事情，而是要确保有人在做应该做的事情。
ITIL建议成立一个变更顾问委员会(CAB)来帮助和支持变更经理，CAB的成员根据变更的实质可以包括客户代表，运维支持，应用开发和供应商等跟变更有关的人员。
CAB通过开会等手段来考虑和评估变更请求(RFC)的：
➢潜在风险和影响；
➢实施变更需要的资源；
➢是否批准变更；
➢如果批准，什么时间实施。
本公司建议：初期CAB－个季度对已实施的变更回顾一次，正常运行后某客户再根据运行情况确定周期；针对具体某一项变更回顾的报告结果可以用附件的方式附加在该变更单上进行保存；
CAB也负责变更实施后的回顾以确保：
➢变更是否成功？
➢是否产生其他副作用？
➢实际所用的资源和预期的是否一致，如果不是，调整评估流程。
批准后，变更将进入计划，测试/构建和实施阶段。
计划/构建阶段也包括开发一个恢复计划(Fallback Plan)，用以在实施阶段出现问题或紧急状况时需要把变更回退回去。
变更管理流程也负责紧急变更，在此种情况下，变更的评估，计划，测试和实施阶段都将快速进行。
来自
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一旦获得批准，它必须根据资源和其他情况进行规划，确定实施日期，分配相应资源，并通知请求人。
➢协调变更实施Coordinating the change implementation
一切就绪后，可以实施变更。
建议某客户计算机中心的运维组实施相应变更，变更经理监视实施过程，并在必要时进行协调。
➢更新变更状态
在整个变更过程中，变更的状态从登记，评估，回顾到最后关闭是不同的。
变更经理负责更新预先定义好的变更状态。
➢回顾和关闭
实施变更后，变更经理负责从技术和流程角度去回顾变更，该回顾在预先定义好的时间段针对变更单独进行，除确保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）
变更顾问委员会（CAB or CAB/EC）职责：
➢回顾所有提交重要的RFC，并确保它们的潜在影响和风险得到评估；
➢针对具体变更请求，评估并讨论相应资源的分派；
➢回顾所有已执行的变更，确保满足变更目的；
➢参加CAB会议和紧急CAB会议；
➢协作变更经理确定变更优先级及变更规划；
➢在某客户，变更经理可能对CAB成员（大部分是运维组成员）没有行政权，为了保证CAB成员都能够参加讨论，同石化相关人员确认建议，可以在CAB中加入运维组组长；
变更顾问委员会（CAB or CAB/EC）的组成人员：
➢CAB的组成人员可以根据具体的变更种类指定不同的人参与；
➢固定成员：变更经理、运维组组长、变更主管、项目组组长；
➢如果是重大的实施类变更，需要某客户计算机中心领导人参与，如，科长或主任等；
➢一般的实施类变更，CAB成员可以简化，如，变更主管可以和变更实施人员合并；
3.3.变更主管
变更主管属于不确定具体人员的角色，可以根据不同的变更种类，分派不同的人员作为变更主管。
对于普通的实施类变更，还可以将变更主管和变更实施人员合并在一起。
变更主管主要关注在测试计划、技术方案、实施计划等。
变更主管职责：
➢接受变更请求，并协调实施；
➢作为具体变更的项目经理，负责领导变更的构建／测试，实施和参与回顾；
➢制定变更项目计划和时间规划等；
➢更新项目记录，生成变更工单；
➢在整个变更中协调各工单，以维护变更项目的整体性；
➢确保变更在预定的时间，资源和成本完成；
➢在必要时，确保恢复计划（Fallback Plan）得以正确实施。
3.4.变更实施人员
变更实施人员主要关注在测试、具体现场实施等。
变更实施人员职责：
➢根据变更主管制定的变更计划实施变更；
➢执行分派的任务以推进变更项目；
➢向变更主管汇报工作进程（在系统中加入时间限定：当变更没有在预定的时间得到实施，系统将自动通知变更主管和变更经理）；
➢现场负责变更实施或恢复实施。
3.5.某客户人员角色定义
4. 变更管理流程说明
4.1. 变更管理总体流程
根据某客户IT 的具体情况，同时结合ITIL 的最佳经验，某公司给出下面的变更管理的逻辑流程：
注：相关符号的说明：
= 相关工具和人员 = 流程
= 决策
所有优先级为普通、中、高的变更都将完全按照如上流程执行，各步骤的描述如下：
4.2.变更管理流程和其他管理流程的关系
4.3.变更管理详细流程
结合上面的逻辑流程和某客户的实际情况，某公司建议如下变更管理的物理流程。
4.3.1.（350）紧急变更逻辑流程
在日常运维过程中，紧急的变更和运维工作占了很大运维比率。
为了使紧急流程更能够符合某客户的实际情况，项目组在该问题上做了深入的讨论。
某客户对紧急流程处理的目标是：
1. 实施流程尽量简化；
2. 保证对流程的控制；
来自
在ITSM/ITIL中确定了紧急流程的定义，但并没有详细做法。
结合某公司顾问的经验和某客户的实际情况，具体确定了以下策略来确保紧急变更流程的实施。
对于紧急变更，某公司顾问建议成立CAB紧急委员会，称为CAB/EC，对紧急变更请求进行评估和授权。
下面是紧急变更逻辑流程，其物理流程和正常变更的物理流程一致（具有相同的流程步骤名称，除了在每个名称前加上“快速”以作区别）。
CAB/EC成员可以是固定的，建议由某客户信息科技部安全运行处长、运维组组长和变更经理组成。
紧急变更的特殊之处是变更文档可以在变更实施完之后提交，但必须在可能的情况下通知变更经理并得到CAB/EC的口头批准。
流程详细描述如下：
4.3.2.（300.1）提交变更请求
物理流程详细描述如下：
4.3.3.（300.2）接受变更请求
物理流程详细描述如下：
4.3.4.（300.3）评估风险/影响
评估风险/影响物理流程详细描述如下：
4.3.
5.（300.4）测试/实施计划
测试/实施计划物理流程详细描述如下：
4.3.6.（300.5）计划&沟通
计划&沟通物理流程详细描述如下：
4.3.7.（300.6）变更实施
变更实施流程详细描述如下：
4.3.8.（300.7）回顾
回顾流程详细描述如下：
4.3.9.（300.8）结束
在某客户IT运维管理流程中，建议变更经理和配置经理是同一个人，这样一方面避免了某客户需要分别为变更管理和配置管理设立两个岗位角色；另一方面，也增加了对CMDB 维护过程的简易性。
结束流程详细描述如下：
4.4.SD相关代码定义
某客户的变更管理流程将采用Open View Service Desk来实施作为管理平台，相关定义如下：
4.4.1.请求者优先级别
4.4.2.影响度
（在回顾时作为条件和依据，同时，实施时可以作为警告提醒）
4.4.3.风险
（在回顾时作为条件和依据，同时，实施时可以作为警告提醒）
4.4.4.状态
4.4.
5.变更工单实施状态
4.4.6.结束代码
4.4.7.类别（Category）
4.4.8.类型（Type）
5.变更管理流程控制
为了更好地保证变更管理流程在某客户的执行，某公司设计如下几方面的控制手段；
5.1.变更管理流程政策/建议
按照KPI计量，变更管理流程可以设定如下几个方面的衡量标准：
5.1.1.政策
规定 1：
所有对IT基础架构（如，服务器、系统、客户端、网络环境等）环境的变更
都必须经过本变更管理流程；
规定 2：
所有预先定义的常规变更可由变更经理直接审批，可以不经过CAB评估和授
权；
规定 3：
所有变更请求(除常规变更请求和紧急变更外)，都必须在希望实施日期的5个
工作日前提交（明确此政策的意义，具体时间由某客户自己确定）；
规定 4：
紧急变更应遵循紧急变更流程以获得及时实施；
规定 5：
实施类变更和紧急变更都必须经过充分测试，并制定相应恢复计划(Back-out
Plan)；
规定 6：
变更实施前,变更经理必须跟所有受变更影响的相关部门或人员进行充分沟
通；(中、高、最高影响度的变更，在实施前必须通过书面或网上系统通知所
有受影响单位)；
规定 7：
整个变更过程中必须保持CMDB的正确性和完整性；
规定 8：
所有的变更都必须进行回顾（通过报表），常规变更可执行特殊/简易回顾流
程。
规定 9：
所有的变更请求都应该被记录，并在OVSD系统中进行跟踪
规定 10：
变更流程和指南必须被文档化，并在执行过程中被严格遵守
规定 11：
变更管理计划要考虑和解决执行变更时有可能产生的时间冲突，主要是要考虑
到变更动作所影响到的CI的变化和直接的环境相互依赖关系
5.1.2.建议
建议1：
对于变更管理流程的执行，建议能够有来自某客户IT服务领导层从上而下的
支持，变更经理的角色应该位高权重。
建议2：
所有外部供应商都应遵循某客户IT变更管理流程
5.2.管理报表
报表意义：制度完善、人员培养、组织建设、管理流程优化、发现IT基础建设的不足；
使用人员：信息中心领导、计算中心领导、运维组长；
5.3.工作报表
报表意义：与变更相关的工作人员能够及时掌握变更运作情况，能够及时调整人力资源、工作时间任务安排等；
使用人员：运维组组长、硬件组长；
6.附件。
