成功的变更管理就是：优化风险；减少影响和破坏程度；一次性成功

变更管理目的：

1.标准化的方法和程序用于有效快速处理变更

2.所有的服务资产变更及它们的配置都被记录在配置管理系统中

3.优化整体商业风险

变更管理目标：

确保变更被记录然后被评估、授权、决定优先级、计划、测试、实施、记录和审核的一些列控制措施

变更管理的范围

范围：服务资产基线及其在整个服务生命周期的配置项

变更的种类

1、标准变更

标准变更：由变更管理预先批准的对服务和基础设施的变更。其具有一个既定的流程来提供变更请求服务。

由这个标准变更授权来批准每一个标准变更的发生。

标准变更关键在于：

变更请求的发起是由一个已定义的触发来发起的。

任何变更时已知的，被记录和被证明的。

管理权限事先给予的

低风险且易于了解

预算审批通常是事先决定或者由变更请求者控制的

一旦标准变更管理方式被通过，标准变更流程和相关变更工作流程都应该被订制和被传达。

标准变更流程应在建立变更管理流程初期就被订制。

所有变更包括标准变更将有详细的变更记录。配置项目的标准变更在资产或配置项目生命周期中北跟踪。

如果有一个健全的CMS系统可以对当前状态，相关配置项及有关CI状态作出变更报告。在这类情况下，变更和配置管理报告被整合。变更管理可以监督所有变更过的服务CIS项和发布CIS项。

一些标准变更会被服务请求流程触发并由服务台直接记录和执行。

2、紧急变更

紧急变更是被预留给那些旨在修复那些严重影响到业务的紧迫程序高的IT服务故障。

一个紧急变更的授权级别和权力下放程度应清楚的被记录和了解。在紧急情况下，由ECAB批准。

紧急变更的建立、测试、实施

已授权的变更会有相关技术组去建立，在时限内变更经理与技术经理协作确保足够的人力与资源来完成工作。

紧急变更的测试有可能要进行，应避免那些完全未经测试的变更。

变更的实施未能解决错误时可能需要有修补程序来迭代尝试。变更管理应确保业务是被优先考虑的。每次迭代都应在控制下并确保失败的变更被及时退出。

变更管理的原则

建立组织变更管理文化

变更管理流程与企业项目管理、利益相关者的变更管理流程要一致

职责分离

建立单一节点，减少冲突和潜在问题

防止生产环境中的未授权变更

和其他服务管理进程一致从而可以追踪变更、发现未授权变更

变更窗口—实施、授权

评估影响服务能力的变更的风险和性能

流程的绩效评估

在设计和规划变更流程时应考虑一下几个问题

变更流程应和发布、配置管理一起被设计。有助于评价当前和计划中的服务和发布造成的影响

变更管理流程的需求和设计包括：变更文件标识符；变更文件类型、变更文档模板和内容；影响、紧急程度、优先级。

组织结构作用和责任

利益相关者

分组及相关变更

程序

其他服务管理接口

处理变更、发布、配置管理与问题事故管理流程的接口来确认、减少事故变化

配置管理接口

变更管理的主要活动

变更的规划和控制

变更和发布的调度

沟通

变更决策和授权

确保有补救计划

度量和控制

管理报告

了解变更影响

持续改进

变更管理流程图

变更管理流程各环节

创建和记录变更请求

变更是由发起者通过一个请求发起的。对于一个能给组织或财政带来重大影响的重大变更，变更提议需要被完整说明，并连同从业务和财政角度来说明。

变更记录，记录了变更的所有历史痕迹，从变更请求和随后已设定的参数记录中获得信息。如优先和授权，执行和检查信息。

变更记录的定义应在流程规划和设计时完成。

变更文档的各类属性药尽量标准化。变更文档，相关记录和相关配置项都由CMS系统来更新。所以预算，实际资源，成本和结果都被管理报告记录。

变更请求审核

应过滤一下变更：

1.不合理的变更请求

2.过期、已接受、被拒绝或仍再审议中的被重复提交的变更请求

3.提交不完整变更请求

这些变更请求应退回给发起者并连同拒绝理由及简单细节描述同时在日志中记录这一事项

变更评估

失败的变更引发的潜在影响和对于服务资产和配置的影响需要被考虑。对于变更一下7个问题能对变更进行评估

谁提出的变更

变更的原因

变更的回报

变更带来哪些风险

变更所需要的资源

谁来负责建立、测试和实施变更

变更之间的关心

变更的风险

分配优先次序

用来确定变更顺序的。每一个变更都包括发起人对影响的评估和变更的紧迫性。变更优先是来自于影响性和紧迫性。最初的影响性和紧急度是由发起人提供的，但在变更授权流程中优先次序可能会被修改所以风险评估在这一阶段就很重要。变更顾问组织为了评估实施或者不实施变更所引发的风险时需要业务影响信息。影响是基于有利于业务的变更或由于错误变更造成损失和成本。影响无法用绝对数值表示，但可以取决于某些事情或某些情况的可能性。

1. 优先级的确定

以下是一个优先级编码系统的例子：

低优先级: 些变更很值得，但是需要等待很长时间，

一般优先级: 没有很紧急或者重大的影响，但是变更不能被推迟。

高优先级: 影响许多用户的严重错误，或影响大量用户的困难错误，或与其他紧急事件有关的错误。这种变更将在CAB 的下一次会议上给予最高优先级。

最高优先级: 变更请求(RFC)关注严重影响用户使用潜在服务的问题，或者紧急IT 变更具有这种优先级的变更被划分为紧急变更。

2. 类别的确定

类别由变更管理决定，在与CAB 的磋商中很有必要，它显示了变更的影响和IT 组织的需求。以下是类别的一些例子：

次要影响: 要求很低，且造成重大服务问题的风险也极低的变更。变更经理可以无须将它们提交给CAB，就批准这些变更。

实质影响: 需要做大量的工作，且对服务有切实的影响的变更。这些变更在CAB 会议上讨论以决定所需的工作和潜在的影响。在会议之前，相关的文档会在CAB 成员，可能包括专家以及开发人员之间传阅。

重大影响: 需要做很大量的工作，且会影响到组织的重要部分的变更。变更经理需要有IT 管理或IT 筹备指导委员会的优先级授权，在此之后，变更必须提交给CAB。

变更的规划和调度

仔细的规划变更确保变更管理流程中每一个任务都是明确的；其他流程所包含的任务；给那些变更和发布的供应商或项目提供多少流程接口。许多变更可能是属于一个发布里的，有可能是设计、测试和发布。也有许多独立的变更组成一个发布，这可能造成复杂的依赖关系难以管理。建议变更管理中，调度变更时优先考虑业务而不是IT的需求。

事先商定和已确定的变更和发布窗口能帮助组织改善计划和整个变更发布。只要有可能，变更管理应安排授权，进行发布目标变更或部署软件包和分配相应资源。变更管理协调产品和变更日程的分配和预计服务中断。变更日程包括所有授权实施变更及实施日期的详细信息。预计服务中断包含SLA协议和可用性中的变更细节。

变更的授权

特定类型变更的授权等级取决于变更种类、规模或风险。权力下放的程度可能存在于一个授权程度。

预期业务风险

对财政影响

范围变化

协调变更执行

已授权的变更会被提交给执行变更的相关技术组，建议使用正规的方式来实现，便于对其追踪。变更管理应确保变更如期完成，管理主要起到协调作用，具体实施由其他人员负责。每个变更都应提前准备修复程序并将其文档化。因为实施期间或实施后发生错误时这些程序能以对业务最小影响下进行快速恢复。变更管理有监督的作用，确保变更是经过测试的。对于没有经全面测试的变更需要在执行时特别关注。

变更回顾、关闭

变更完成后变更管理者应对结果进行评估。评估还要包括由变更引起的任何事件。变更回顾应确认变更是否达到目标，应吸取的经验对今后的变更进行改进。变更若没有实现目标，变更管理应决定后续的行动，如果达到目标应关闭变更。

紧急变更

紧急变更是被预留给那些旨在修复那些严重影响到业务的紧迫程序高的IT服务故障。一个紧急变更的授权级别和权力下放程度应清楚的被记录和了解。在紧急情况下，由ECAB批准。

紧急变更的建立、测试、实施

1.已授权的变更会有相关技术组去建立，在时限内变更经理与技术经理协作确保足够的人力与资源来完成工作。

2.紧急变更的测试有可能要进行，应避免那些完全未经测试的变更。

3.变更的实施未能解决错误时可能需要有修补程序来迭代尝试。变更管理应确保业务是被优先考虑的。每次迭代都应在控制下并确保失败的变更被及时退出。

紧急变更文档

它有可能无法在紧急行动时对所有变更管理记录进行更新。但重要的是能尽早对这一阶段进行记录和对所有记录进行回顾。为了避免一些事故可以在未经事先授权情况下向事故管理员、计算机和网络管理员下放权力。但这些下放的权利应限于不改变服务资产规范和不尝试修复软件错误。要解决软件造成的事故首选方式是回退到以前的状态或者受信版本，而不是试图进行一个无计划或者有潜在危险的变更。

紧急变更程序将遵循除正常变更外的一下规则

1.获准授权由ECAB而不是CAB

2.测试可以缩短，在极端情况下可以被完全放弃

3.更新记录和配置数据可以被推迟，可以在服务正常后进行。

变更触发、输入、输出

变更可以由以下情况被触发

1.战略变更：服务战略变更需求在最小成本和风险下完成特定的目标。战略计划都存在风险和成本。

2.对一个或多个服务进行变更

3.运营变更

变更管理的输入

由变更请求提交的变更往往会关联一个变更建议，提供一个关于如何发生变更的细节。这个建议会依据变更模式并会提供发生详细的建议。

包括

1.变更和发布的政策和战略

2.变更请求

3.变更建议

4.计划-（变更、转换、发布等）

5.当前变更时间表和预计服务中断

6.当前资产和配置项

7.规划配置基线

8.测试的报告、结果、评估报告

变更管理的输出

流程的输出包括

1.被拒绝的变更请求

2.被批准的变更请求

3.通过变更请求对服务、服务或基础设施的变更

4.新的、变更的、出售资产或配置项

5.变更日程

6.被修订的预计服务中断

7.已授权的变更计划

8.变更决定和行动

9.变更文档和报告

10.变更管理报告

变更管理的接口

为了明确界限，依赖关系和规则，变更、发布管理应结合组织项目、供应商流程、程序的使用过程，变更管理与其他相关程序必须有适当的接口。

1.业务变更流程的整合

2.适当情况下变更管理应参与业务项目和业务管理。

3.程序和项目管理

服务管理接口

服务管理流程可能需要变更和改进。影响评估和服务变更执行回涉及到：

1.资产和配置管理：配置管理系统提供可靠的快速的以获取的准确的配置信息，其能使相关人员对拟定的变更的影响和跟踪变更工作流程进行评估。还能使CMS可以鉴别受变更影响的CI项和资产。（见附图）

2.问题管理：问题管理是另一个重要的变更过程，是变更请求的重要来源

3.业务连续性关系：业务连续性很多程序是需要通过变更管理来更新的，以确保是最新的准确的且被相关者知晓的。

4.安全管理：每个重大变更是评估其对安全计划潜在的影响。

5.能力和需求管理

附图为变更管理与配置管理的工作流程图

关键绩效指标和衡量标准

1.满足客户的变更实施的数量

2.变更所带来的利益与变更成本的比较

3.服务中断数量、因为错误规则导致的缺陷或返工、不完整或缺乏评估这类现象的减少

4.减少未经授权的变更数量

5.减少积压的变更请求数量

6.减少无计划变更和紧急修复的数量和百分比

7.变更成功率

8.减少变更失败的数量

9.减少变更回退的数量

10.变更预估的精确性

11.变更的事故原因

12.落实确定变更紧迫性/优先/类型的平均时间