变更管理的主要活动

  1. 变更的规划和控制
  2. 变更和发布的调度
  3. 沟通
  4. 变更决策和授权
  5. 确保有补救计划
  6. 度量和控制
  7. 管理报告
  8. 了解变更影响
  9. 持续改进
 变更管理流程图

 

 

变更管理流程各环节
创建和记录变更请求

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

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

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

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

变更请求审核

应过滤一下变更：

  • 不合理的变更请求
  • 过期、已接受、被拒绝或仍再审议中的被重复提交的变更请求
  • 提交不完整变更请求
这些变更请求应退回给发起者并连同拒绝理由及简单细节描述同时在日志中记录这一事项

变更评估

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

  • 谁提出的变更
  • 变更的原因
  • 变更的回报
  • 变更带来哪些风险
  • 变更所需要的资源
  • 谁来负责建立、测试和实施变更
  • 变更之间的关心
变更的风险

分配优先次序

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

1. 优先级的确定

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

  1. 低优先级: 些变更很值得，但是需要等待很长时间，
  2. 一般优先级: 没有很紧急或者重大的影响，但是变更不能被推迟。
  3. 高优先级: 影响许多用户的严重错误，或影响大量用户的困难错误，或与其他紧急事件有关的错误。这种变更将在CAB 的下一次会议上给予最高优先级。
  4. 最高优先级: 变更请求(RFC)关注严重影响用户使用潜在服务的问题，或者紧急IT 变更具有这种优先级的变更被划分为紧急变更。

2. 类别的确定

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

  1. 次要影响: 要求很低，且造成重大服务问题的风险也极低的变更。变更经理可以无须将它们提交给CAB，就批准这些变更。
  2. 实质影响: 需要做大量的工作，且对服务有切实的影响的变更。这些变更在CAB 会议上讨论以决定所需的工作和潜在的影响。在会议之前，相关的文档会在CAB 成员，可能包括专家以及开发人员之间传阅。
  3. 重大影响: 需要做很大量的工作，且会影响到组织的重要部分的变更。变更经理需要有IT 管理或IT 筹备指导委员会的优先级授权，在此之后，变更必须提交给CAB。

变更的规划和调度

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

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

变更的授权

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

  1. 预期业务风险
  2. 对财政影响
  3. 范围变化

协调变更执行

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

变更回顾、关闭

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

紧急变更

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

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

  • 已授权的变更会有相关技术组去建立，在时限内变更经理与技术经理协作确保足够的人力与资源来完成工作。
  • 紧急变更的测试有可能要进行，应避免那些完全未经测试的变更。
  • 变更的实施未能解决错误时可能需要有修补程序来迭代尝试。变更管理应确保业务是被优先考虑的。每次迭代都应在控制下并确保失败的变更被及时退出。

紧急变更文档

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

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

  1. 获准授权由ECAB而不是CAB
  2. 测试可以缩短，在极端情况下可以被完全放弃
  3. 更新记录和配置数据可以被推迟，可以在服务正常后进行。

其他相关文章

 

ITIL V3 服务转换篇 之 开发部署管理

ITIL V3 服务转换篇 之 资产和配置管理

ITIL V3 服务转换篇 之 变更管理 下篇

ITIL V3 服务转换篇 之 变更管理 中篇

ITIL V3 服务转换篇 之 变更管理 上

ITIL V3 服务转换篇 概述