变更管理

变更管理

开放分类：产品创新数字化(PLM)，PDM/PLM

变更管理泛指在项目进行过程中，对变动、更改的部分进行有效预见、应对、管理的过程。由变更管理对象的不同可以分为：

变更管理(工程)，是系统工程方面的一种过程，系统工程方面的变更管理过程是指就某一系统的变更提出请求，确定可行性以及开展计划、实施和评估的过程。

变更管理(人员)，是个人、团队、组织机构以及社会变更的一种结构化方法

变更管理(信息技术服务管理)，是一个信息技术服务管理学科。

变更管理的目的与目标

“变更管理”这项SMF 的目标就是提供严格有序的流程，以确保在尽量避免正常操作运转所受干扰的前提下，将所需变更调整引入IT 环境。为实现这个总体目标，变更管理过程应提出以下要求：

• 通过提交变更请求（RFC）正式启动变更程序。

• 在确定轻重缓急和对基础架构或最终用户影响程度的基础上，为变更事项指定优先级和类别。所做指定将对变更请求受理速度及其所循授权途径产生影响。

• 建立快捷高效的申报程序，将RFC 交由变更管理人员和变更顾问委员会(CAB) 核准或否决。

• 制定变更部署计划，变更部署范围可能大相径庭，并需要在较为关键的过渡性里程碑处进行回顾评审。

• 与“发布管理”这项SMF 密切配合。后者通常嵌套在变更管理过程当中，负责将变更事项发布并部署到生产环境。如需进一步了解“发布管理”这项SMF ，请参阅

/technet/itsolutions/cits/mo/smf/default.mspx 。

• 在将变更付诸实现后执行一个回顾评审程序，判断变更调整活动是否达到既定目标，并决定是否保留变更成果或将其恢复原状。

变更管理的重要定义

CAB 应急委员会(CAB/EC)。只负责处理紧急变更事项的CAB 专设机构。组建这个委员会的目的在于，针对具有特殊优先级的紧急变更事项做出授权或予以否决。

变更。刻意导入IT 环境的一切新增IT 组件，要么对IT 服务级别产生影响，要么对整个IT 环境或它的某一部分产生影响。

变更顾问委员会(CAB)。CAB 是一个跨职能部门，负责评价针对业务需求的变更请求、优先级别、成本/效益指标以及对其他系统或过程的潜在影响。CAB 通常针对变更

请求提出付诸实施、深入分析、暂缓实施或彻底否决等建议。

变更类别。变更部署对IT 和业务产生所影响的衡量指标。为确定变更类型，有关方面将对变更复杂程度和所需资源（包括人员、资金及时间）加以衡量。此外，部署风险（包括可能发生的服务中断）也是一个影响因素。

变更发起人。最初提起变更请求的人员；这个人可能是业务代表或IT 部门成员。

变更管理人员。IT 机构中对变更管理过程负有全面管理责任的角色。

变更拥有者。负责在IT 环境下计划并实施变更事项的角色。变更拥有者角色由变更管理人员针对特定变更事项指派给有关人员，担当这个角色的人员将在收到已经核准的RFC 的时刻起承担相关职责。变更拥有者必须遵循业经核准的变更时间安排。

变更优先级。决定变更请求核准与部署速度的变更分类机制。解决方案需求的紧迫性和不予实施变更的业务风险是赖以确定优先级的主要标准。

配置项目(CI)。受配置管理职能控制的IT 组件。每个CI 都可能由其他的CI 组成。大到整个系统（包括全部硬件、软件和文档），小到单个软件模块或次要硬件组件，不同CI 的复杂程度、大小和类型可能存在天壤之别。

发布。由一或多项变更组成的集合，其中包括已通过测试并被引入生产环境的新增和/或变更配置项目。

变更请求(RFC)。这里指正规变更请求，包括针对变更的描述、受到影响的组件、业务需求、成本估算、风险评估、资源需求及核准状态等信息。

流程摘要

在以变更管理为中心的语境中，变更可被定义为包括硬件、软件、系统组件、服务、文件或程序在内的一切对象——有条不紊地将变更引入IT 环境，并对IT 服务级别协议(SLA)、IT 环境或IT 环境某一组成部分施加影响。变更可以是永久或暂时的。变更既可能是以新创或修订版本组件全面取代当前版本组件，又可能是安装完全不同的组件或剔除过时组件。

不论是永久或暂时、新创或修订，符合上述定义的所有变更事项必须置于变更管理过程的掌控之下。变更管理应对IT 环境下的所有变更实施管理。这一点非常重要，因为变更有可能：

• 对多个用户构成影响。

• 有可能导致关键任务或关键业务伺服中断。

• 涉及硬件(如服务器或网络设备) 或软件调整。

• 影响基于IT 系统存储的数据资料。(这主要取决于数据类型——例如，电子商务网站报价单更新操作应由变更管理程序控制，但在公司数据库中更新客户信息的操作将无法以此方式控制。)

• 涉及影响多个用户的运转和程序调整。

我们还可对这张高阶图表做进一步编排，以提供详尽的端到端程序说明，进而描绘出全面完整的变更管理程序蓝图。这份“变更管理SMF”指南的其余部分还提供了详细阐述这些变更管理程序的图表。

变更请求

一般来说，身处业务环境的任何人均可提供变更请求，并因此成为变更发起人。由于可能成为变更发起人的人员基础较为广泛，而这些人员对变更申请程序的熟悉程度各不相同，因此，需要由一个程序确保变更请求的同质性和完整性，并将无关请求剔除。虽然变更请求可由企业中的任何人提出，但却通常由“MOF 团队模型”角色群体中的某种角色发起并提交。一般来说，每个角色群体都会提交与职责范围相关的变更请求。无论变更请求是为了改善或摒弃现有服务，还是为了新建服务项目，都将促使变更管理程序做出相应调整。在受控变更管理程序中，这些需求都将导致变更请求(RFC)的形成。RFC 是记录变更提议全部相关信息的标准文档，内容涵盖从基本事项(例如，修改数据库系统字段名) 到详细信息（例如，变更产生的广泛影响——与已修改字段名相关的交互或服务系统）。

RFC 必须解答与变更提议相关的一系列问题，诸如“什么”、“为什么”、“谁”、“何时”、“哪里”及“如何”等。RFC 必须对变更本身、实现变更所需开展的工作、变更执行主体、变更实现手段和变更涉及的配置项目加以说明。RFC 还应披露变更目的支持信息、变更对组织机构的影响、在失败情况下的复原计划、变更成本、预算核准签名（如有必要）以及变更提议的轻重缓急。RFC 应为变更管理人员提供充足的信息资料，帮助他们在初始审查阶段准确快捷地评估变更事项，并在正式审核阶段决定受理或驳回。

RFC 应使用标准格式编制，以确保变更发起人为变更管理人员提供充足的信息资料，进而间接帮助CAB 做出变更实施决策。使用标准格式还可促使变更发起人对变更请求的范围、含意、风险以及在部署失败情况下的复原计划进行分辨并记录在案。在许多情况下，变更发起人将不会得知或完全了解变更事项内含。为此，所有MOF 团队模型角色群体均应对RFC 加以考虑，进而判断变更事项可能对IT 操作运转产生的影响。 RFC 将成为变更所涉及全部活动的参考重点。Microsoft Word 模板、Microsoft OutlookR 邮件表格、Microsoft InfoPath? 表单或Web 窗体等标准格式的运用将允许各有关方面随时随地轻松调用所需信息，因而颇具裨益。

为协助开展变更管理程序，RFC 表单可包含有效性验证、强制及可选字段，以确保尽快录入必要信息，并避免发生在提交审核前将RFC 退还发起人补足所需信息的情况。提出变更请求