1）关键角色与职责定义

表：关键角色与职责定义

变更管理流程角色	主要职责
变更流程负责人	对变更管理流程的最终结果负责。 负责对变更管理流程的原则、角色、职责和考核目标进行决策。 对变更管理流程的有效性和效率进行监控，在需要的时候发起改进。

续表

变更管理流程角色	主要职责
变更经理	变更流程的初始处理和验证变更请求。 根据变更模型，将变更分配给适当的团队进行评估和授权。 正式向受影响方传达变更授权方的决定 监视、评审、构建和测试变更团队的活动。发布变更计划并确保其在需要时可用。 进行定期和特别的服务评审分析；对变更模型和标准变更过程进行改进。 将组织在变更支持实践方法方面的专业知识进行记录总结。负责对变更管理流程中所有具体活动的管理和监控。 组织、主持紧急变更和重大变更的评审和审批。 负责协调相关的资源，保障所有变更按照预定流程顺利运作。确定变更类型，组织变更计划和排程。 对重大变更和紧急变更的执行结果进行回顾。
变更请求者	负责记录与提交变更请求（RFC）。提交初步的变更方案和计划。 初步评价变更的风险和影响，给变更请求设定适当的变更类型。
变更审批者	负责对变更进行评估，并确定是否批准； 可能以个人形式或团队会议的形式参与变更的风险评估和审批。
变更实施者	负责按照计划实施变更的内容（包括必要时的恢复步骤）。 负责按照实施计划在生产环境中实施具体的变更任务，并记录变更实施结果。
CAB	对变更的评估、优先顺序和时间安排提供专业建议。对过去一段时间的变更执行情况做回顾。 定期召开，如果没有需要CAB决策的变更可以不开。
ECAB	是变更顾问委员会的一部分，负责具有重大影响的紧急变更决策。 可以用电话等变通方式召开。

2）流程角色与岗位、人员映射

角色通常只有在某个流程中有效，但实际的组织中我们都是有具体的岗位、岗位上对应人员。因此，在项目中需要根据实际的业务情况将组织的对应岗位与流程角色进行映射，以便在每一个流程中都能在组织中找到对应的人员或岗位。

表：角色与岗位映射表

序号	流程角色	对应岗位/人员	备注
1	变更流程负责人
2	变更经理
3	变更请求者
4	变更审批者
5	变更实施者
6	CAB
7	ECAB

变更管理流程执行原则

1）总体原则

·所有在变更管理流程范围内发生的变更，均应遵循统一的变更管理流程，以规范各种变更请求的处理，从而有效控制变更引发的风险。

·所有变更请求及其处理过程均应被详尽记录并进行追踪。

·在变更管理流程中，应充分权衡“风险”与“效率”，通过在处理流程或审批路径上对不同类型的变更采取差异化处理，以实现高效目标。

·应定期生成变更管理报表，分析变更质量，并对失败的变更进行分析评估。

·每半年定期对流程进行回顾，以支持流程优化。回顾内容应包括关键衡量指标、流程执行效率和流程支持工具的有效性，以改进变更管理流程。

2）变更管理范围

本流程适用于生产环境内运行和维护相关系统的所有配置项，包括但不限于以下类型：

·应用系统变更（应用系统上线、版本升级、参数调整等）。

·系统软件变更（包括操作系统、数据库、中间件等版本升级、补丁、重要参数调整）。

·硬件变更（包括网络设备、主机、存储等补丁升级、参数调整、模块更换、扩容等）。·机房配套设施变更（空调、UPS调整或扩容等）。

·计划内系统重启。

·配置项信息的变更。·例行巡检引发的变更。

·故障测试引发的变更。

注：对于包含多种变更类型的复杂变更，应选择主要变更内容作为变更分类。

3）变更受理原则（变更前置条件）

·变更请求（RFC）必须符合IT运维管理中心管理制度。

·变更请求（除紧急变更外）在审批手续完备后，方可受理变更。

·涉及系统软件的变更，除须相关部门的审批手续外，还需附带《软件测试报告》。

4）变更责任人原则

责任人机制旨在确保变更过程中的任何阶段均有适宜人员负责，从而保障变更处理的及时性和有效性。

·变更发起人负责变更的正式提出。

·变更经理负责受理并跟踪变更的处理进展。

·变更经理负责组织召开CAB、组织变更审批、制定变更计划和任务排程。

5）CAB评估原则

·变更顾问委员会（CAB）是指对变更的评估、优先顺序和时间安排提供专业建议的虚拟组织。CAB通常由变更经理、工程师、部门主管、IT运维管理中心经理组成，必要时可邀请受变更影响的业务部门代表、相关部门领导、专家委成员、其他服务管理流程的主要代表和供应商代表。紧急变更顾问委员会（ECAB）是变更顾问委员会的一部分，负责具有重大影响的紧急变更决策。

·CAB评审应严格遵循以下原则：

·涉及跨部门协助沟通的发起CAB评审，是否需要CAB评审由发起部门部门主管确定。

·业务部门负责确认需求、提供技术方案及变更之后是否满足需求。

·工程师负责提供技术方案或验证业务部门提供的技术方案。

·外部服务商负责提供技术方案、测试报告和变更需求方确认书。

·技术专家负责对技术方案的审查和确认。

·CAB评审必须要有明确、一致的意见，只要参与CAB评审的一方代表不同意，则变更不能通过评审。

6）变更风险评估原则

变更的风险评估旨在识别变更对业务带来的负面影响，以及实施变更所需的资源和成本。变更风险评估应从以下方面考虑，并定期根据实际情况修正相关评估模型：

·业务影响（变更执行过程所造成的影响，包括影响范围、用户级别、应用系统的关键程度、持续时间）。

·对可用性、连续性的影响。

·对信息安全的影响。

·其他：

·技术难度等级（复杂度）。

·变更失败造成的影响以及变更失败的可能性。

·变更执行成本（工时、硬件、软件等）。

·执行回退的可能性以及所需要的时间和成本。

·所要求的测试条件以及现有具备的测试条件之间的差距。

·同类变更以前的执行情况（执行失败的记录或回退的次数）。

7）变更审批原则

除标准变更外所有变更请求（RFC）必须经过审批之后方可实施，但不同类型的变更采用不同的审批路径：

·变更审批分为四级，前一级别的审批人员若未完成审批，则不转给下一级。

·如审批未通过，则变更“逐级退回”。

变更审批路径参加以下示例：

表：变更审批路径示例

优先级	一级审批	二级审批	三级审批
紧急重大变更
紧急一般变更
重大变更
一般变更

8）变更窗口原则

变更窗口原则用于确定实施变更的日程，设置变更窗口的主要目的是减小变更对业务的影响，提高业务稳定性。

变更窗口的制定需要考虑下列因素：

·对业务的影响。

·个别业务的特定需求。·变更实施和回退的时间。

·原则上重大节假日或重大活动期间不执行变更。

·变更窗口定义为：由评审决定。

·若根据变更评估结果，变更实施时间需超过8小时的，可根据实际需要调整变更时间。变更窗口原则的相关规定参见以下示例：

表：变更窗口设计模板

变更类型	变更窗口	窗口
重大变更
	时间段	18：00-次日6：00
一般变更
	时间段	18：00-次日6：00
标准变更
	时间段	N/A
紧急变更
	时间段	N/A

9）变更目标时间原则

变更目标时间原则主要针对变更生命周期的关键步骤，目标时间由变更影响度等因素（如变更的复杂度、变更的数量）决定。目标时间政策规定了变更管理流程中几个关键步骤所应该完成的时间。以更为合理的权衡和安排对不同变更所投入的资源。目标时间应遵循以下原则：

·如果变更没有通过审批，变更退回的时间要求和审批时间相同。

·紧急变更虽然没有规定具体的审批和准备时间，但变更当前责任人应在第一时间处理变更，以确保变更可以快速完成。

·变更目标时间由服务台负责跟踪，一旦发现超时立即通知变更经理。变更目标时间原则的相关规定参见以下示例：

10）前导时间原则

表：前导时间设计原则

目标时间	变更实施前准备	变更实施前准备	变更实施确认	关闭变更
测量准则	[等待审批-已批准]*	[已批准-已就绪]*	[已实施-已确认]*	[已确认-已关闭]*
紧急变更	N/A	N/A	2工作日	3工作日
重大变更	2工作日	8工作日	10工作日	3工作日
一般变更	2工作日	3工作日	3工作日	3工作日
标准变更	N/A	N/A	3工作日	3工作日

前导时间是指从提交变更到召开CAB之前所需要进行评估、预审核等准备活动的最少时间。前导时间是基于变更类型制定的，同时结合了变更窗口及目标时间原则。

紧急变更不需满足前导时间要求。

变更前导时间原则的相关规定参见以下示例：

表：前导时间设计示例

变更优先级	变更前导时间
紧急变更	N/A
重大变更	10工作日
一般变更	5工作日
临时变更	2工作日
标准变更	N/A

11）变更回退原则

·当变更实施失败或者无法在规定的时间内完成，则需要进行回退。

·任何回退的变更将作为变更失败而关闭，在下一次实施前，变更请求者必须重新提交新的变更请求（RFC），以便重新进行审批。

12）变更关闭原则

在变更管理流程中，变更的关闭应严格遵循以下原则：

·当变更请求审批被退回至变更请求人时，变更请求人有权选择关闭变更。·变更实施结束后由变更经理负责关闭变更。

·其他人无权关闭变更。参考数字化IT运维管理体系建设指南等书籍资料

1）关键角色与职责定义

表：关键角色与职责定义

变更管理流程角色	主要职责
变更流程负责人	对变更管理流程的最终结果负责。 负责对变更管理流程的原则、角色、职责和考核目标进行决策。 对变更管理流程的有效性和效率进行监控，在需要的时候发起改进。

续表

变更管理流程角色	主要职责
变更经理	变更流程的初始处理和验证变更请求。 根据变更模型，将变更分配给适当的团队进行评估和授权。 正式向受影响方传达变更授权方的决定 监视、评审、构建和测试变更团队的活动。发布变更计划并确保其在需要时可用。 进行定期和特别的服务评审分析；对变更模型和标准变更过程进行改进。 将组织在变更支持实践方法方面的专业知识进行记录总结。负责对变更管理流程中所有具体活动的管理和监控。 组织、主持紧急变更和重大变更的评审和审批。 负责协调相关的资源，保障所有变更按照预定流程顺利运作。确定变更类型，组织变更计划和排程。 对重大变更和紧急变更的执行结果进行回顾。
变更请求者	负责记录与提交变更请求（RFC）。提交初步的变更方案和计划。 初步评价变更的风险和影响，给变更请求设定适当的变更类型。
变更审批者	负责对变更进行评估，并确定是否批准； 可能以个人形式或团队会议的形式参与变更的风险评估和审批。
变更实施者	负责按照计划实施变更的内容（包括必要时的恢复步骤）。 负责按照实施计划在生产环境中实施具体的变更任务，并记录变更实施结果。
CAB	对变更的评估、优先顺序和时间安排提供专业建议。对过去一段时间的变更执行情况做回顾。 定期召开，如果没有需要CAB决策的变更可以不开。
ECAB	是变更顾问委员会的一部分，负责具有重大影响的紧急变更决策。 可以用电话等变通方式召开。

2）流程角色与岗位、人员映射

角色通常只有在某个流程中有效，但实际的组织中我们都是有具体的岗位、岗位上对应人员。因此，在项目中需要根据实际的业务情况将组织的对应岗位与流程角色进行映射，以便在每一个流程中都能在组织中找到对应的人员或岗位。

表：角色与岗位映射表

序号	流程角色	对应岗位/人员	备注
1	变更流程负责人
2	变更经理
3	变更请求者
4	变更审批者
5	变更实施者
6	CAB
7	ECAB

变更管理流程执行原则

1）总体原则

·所有在变更管理流程范围内发生的变更，均应遵循统一的变更管理流程，以规范各种变更请求的处理，从而有效控制变更引发的风险。

·所有变更请求及其处理过程均应被详尽记录并进行追踪。

·在变更管理流程中，应充分权衡“风险”与“效率”，通过在处理流程或审批路径上对不同类型的变更采取差异化处理，以实现高效目标。

·应定期生成变更管理报表，分析变更质量，并对失败的变更进行分析评估。

·每半年定期对流程进行回顾，以支持流程优化。回顾内容应包括关键衡量指标、流程执行效率和流程支持工具的有效性，以改进变更管理流程。

2）变更管理范围

本流程适用于生产环境内运行和维护相关系统的所有配置项，包括但不限于以下类型：

·应用系统变更（应用系统上线、版本升级、参数调整等）。

·系统软件变更（包括操作系统、数据库、中间件等版本升级、补丁、重要参数调整）。

·硬件变更（包括网络设备、主机、存储等补丁升级、参数调整、模块更换、扩容等）。·机房配套设施变更（空调、UPS调整或扩容等）。

·计划内系统重启。

·配置项信息的变更。·例行巡检引发的变更。

·故障测试引发的变更。

注：对于包含多种变更类型的复杂变更，应选择主要变更内容作为变更分类。

3）变更受理原则（变更前置条件）

·变更请求（RFC）必须符合IT运维管理中心管理制度。

·变更请求（除紧急变更外）在审批手续完备后，方可受理变更。

·涉及系统软件的变更，除须相关部门的审批手续外，还需附带《软件测试报告》。

4）变更责任人原则

责任人机制旨在确保变更过程中的任何阶段均有适宜人员负责，从而保障变更处理的及时性和有效性。

·变更发起人负责变更的正式提出。

·变更经理负责受理并跟踪变更的处理进展。

·变更经理负责组织召开CAB、组织变更审批、制定变更计划和任务排程。

5）CAB评估原则

·变更顾问委员会（CAB）是指对变更的评估、优先顺序和时间安排提供专业建议的虚拟组织。CAB通常由变更经理、工程师、部门主管、IT运维管理中心经理组成，必要时可邀请受变更影响的业务部门代表、相关部门领导、专家委成员、其他服务管理流程的主要代表和供应商代表。紧急变更顾问委员会（ECAB）是变更顾问委员会的一部分，负责具有重大影响的紧急变更决策。

·CAB评审应严格遵循以下原则：

·涉及跨部门协助沟通的发起CAB评审，是否需要CAB评审由发起部门部门主管确定。

·业务部门负责确认需求、提供技术方案及变更之后是否满足需求。

·工程师负责提供技术方案或验证业务部门提供的技术方案。

·外部服务商负责提供技术方案、测试报告和变更需求方确认书。

·技术专家负责对技术方案的审查和确认。

·CAB评审必须要有明确、一致的意见，只要参与CAB评审的一方代表不同意，则变更不能通过评审。

6）变更风险评估原则

变更的风险评估旨在识别变更对业务带来的负面影响，以及实施变更所需的资源和成本。变更风险评估应从以下方面考虑，并定期根据实际情况修正相关评估模型：

·业务影响（变更执行过程所造成的影响，包括影响范围、用户级别、应用系统的关键程度、持续时间）。

·对可用性、连续性的影响。

·对信息安全的影响。

·其他：

·技术难度等级（复杂度）。

·变更失败造成的影响以及变更失败的可能性。

·变更执行成本（工时、硬件、软件等）。

·执行回退的可能性以及所需要的时间和成本。

·所要求的测试条件以及现有具备的测试条件之间的差距。

·同类变更以前的执行情况（执行失败的记录或回退的次数）。

7）变更审批原则

除标准变更外所有变更请求（RFC）必须经过审批之后方可实施，但不同类型的变更采用不同的审批路径：

·变更审批分为四级，前一级别的审批人员若未完成审批，则不转给下一级。

·如审批未通过，则变更“逐级退回”。

变更审批路径参加以下示例：

表：变更审批路径示例

优先级	一级审批	二级审批	三级审批
紧急重大变更
紧急一般变更
重大变更
一般变更

8）变更窗口原则

变更窗口原则用于确定实施变更的日程，设置变更窗口的主要目的是减小变更对业务的影响，提高业务稳定性。

变更窗口的制定需要考虑下列因素：

·对业务的影响。

·个别业务的特定需求。·变更实施和回退的时间。

·原则上重大节假日或重大活动期间不执行变更。

·变更窗口定义为：由评审决定。

·若根据变更评估结果，变更实施时间需超过8小时的，可根据实际需要调整变更时间。变更窗口原则的相关规定参见以下示例：

表：变更窗口设计模板

变更类型	变更窗口	窗口
重大变更
	时间段	18：00-次日6：00
一般变更
	时间段	18：00-次日6：00
标准变更
	时间段	N/A
紧急变更
	时间段	N/A

9）变更目标时间原则

变更目标时间原则主要针对变更生命周期的关键步骤，目标时间由变更影响度等因素（如变更的复杂度、变更的数量）决定。目标时间政策规定了变更管理流程中几个关键步骤所应该完成的时间。以更为合理的权衡和安排对不同变更所投入的资源。目标时间应遵循以下原则：

·如果变更没有通过审批，变更退回的时间要求和审批时间相同。

·紧急变更虽然没有规定具体的审批和准备时间，但变更当前责任人应在第一时间处理变更，以确保变更可以快速完成。

·变更目标时间由服务台负责跟踪，一旦发现超时立即通知变更经理。变更目标时间原则的相关规定参见以下示例：

10）前导时间原则

表：前导时间设计原则

目标时间	变更实施前准备	变更实施前准备	变更实施确认	关闭变更
测量准则	[等待审批-已批准]*	[已批准-已就绪]*	[已实施-已确认]*	[已确认-已关闭]*
紧急变更	N/A	N/A	2工作日	3工作日
重大变更	2工作日	8工作日	10工作日	3工作日
一般变更	2工作日	3工作日	3工作日	3工作日
标准变更	N/A	N/A	3工作日	3工作日

前导时间是指从提交变更到召开CAB之前所需要进行评估、预审核等准备活动的最少时间。前导时间是基于变更类型制定的，同时结合了变更窗口及目标时间原则。

紧急变更不需满足前导时间要求。

变更前导时间原则的相关规定参见以下示例：

表：前导时间设计示例

变更优先级	变更前导时间
紧急变更	N/A
重大变更	10工作日
一般变更	5工作日
临时变更	2工作日
标准变更	N/A

11）变更回退原则

·当变更实施失败或者无法在规定的时间内完成，则需要进行回退。

·任何回退的变更将作为变更失败而关闭，在下一次实施前，变更请求者必须重新提交新的变更请求（RFC），以便重新进行审批。

12）变更关闭原则

在变更管理流程中，变更的关闭应严格遵循以下原则：

·当变更请求审批被退回至变更请求人时，变更请求人有权选择关闭变更。·变更实施结束后由变更经理负责关闭变更。

·其他人无权关闭变更。参考数字化IT运维管理体系建设指南等书籍资料