Wiki源代码服务管理实践 - 06 变更支持

Version 40.1 by superadmin on 2024/03/08, 09:47

version	line-number	content
39.1	1	{{box cssClass="floatinginfobox" title="Contents"}}
	2	{{toc/}}
	3	{{/box}}
1.1	4
	5
39.1	6	需要下载 ITIL 4变更支持实践【中文】pdf版全文，请关注微信公众号itilxf ，并回复“变更支持”即可。
1.1	7
39.1	8	[[image:微信截图_20210206234644.png]]
1.1	9
	10
39.1	11	申明：
4.1	12
39.1	13	本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
	14
5.1	15	请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
4.1	16
12.1	17	翻译：马军审校：康羿审核：戚依军
4.1	18
7.1	19
13.1	20	----
	21
7.1	22	= 1 关于本文档 =
	23
	24	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=1]]
	25
	26	本文档提供变更支持实践实用指南，分为五个主要部分，涵盖：
	27
	28	* 本实践的一般信息
	29	* 本实践相关的流程和活动及其在服务价值链中的作用
	30	* 参与本实践的组织和人员
	31	* 支持本实践的信息和技术
	32	* 对本实践的合作伙伴和供应商的考虑
	33
	34	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=2]]
	35
	36	== 1.1 ITIL 4资格认证计划 ==
	37
	38	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=3]]
	39
	40	本文档中的部分内容可作为以下教学大纲的一部分以供检查：
	41
	42	* ITIL专家创建、交付和支持
	43	* ITIL专家交付利益干系人价值
	44
	45	详情请参考各部分教学大纲。
	46
	47
	48
	49	----
	50
	51	= 2 一般信息 =
	52
	53	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=1]]
	54
	55	== 2.1目的和描述 ==
	56
	57	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=2]]
	58
	59	* 关键信息
	60
	61	本次变更支持实践的目的是通过确保有效的风险评估、变更执行的授权和变更计划的管理最大化的保障服务和产品变更的成功。
	62
	63	该实践指导旨在确保对服务及其组件的变更在可控的范围内，并确保它们能够满足组织变更的相关需求。授权的变更即要能保证满足预期，同时还要满足组织关于变更效率的管理（变更的数量和变更实现的速度）和风险管理的要求。因为灵活性和敏捷性是现代组织的核心要素，所以它们会一直贯穿在本次实践指导中。
	64
	65	成功实现变更包含三个前提：
	66
	67	* 在价值流中规划及实现变更。将实践融入到价值流中，并确保其有效，安全且及时，来满足利益相关者的期望。
	68	* 实践的目的并不是将组织中所有变更计划和行动统一为一种模式：在数字化环境中，可能同时发生数百个更改，这种要求既不现实也不是必需的。
	69	* 对于所有在定义范围内的变更，实践应该集中精力放在效率，合规性和风险控制上。
	70
	71	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=3]]
	72
	73	== 2.2术语和概念 ==
	74
	75	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=4]]
	76
	77	变更
	78
	79	任何可能对服务产生直接或间接影响的添加，修改或删除行为。
	80
	81	变更支持实践要确保每个变更都能达到预期的结果。这与'聚焦价值'的指导性原则是相互统一的。与变更的技术细节相比，利益相关者更关心变更带来的价值。有时候，虽然准确的实施了变更，但是未必能实现预期的结果，达到预期的目标。此外，变更可能会产生意想不到的结果，包括对用户的负面影响，服务停机，服务级别降低和不稳定。所以，对于这些结果的控制很重要。变更包括使用各种方式和方法，每种方式和方法都代表不同级别的业务风险。软件变更通常是通过频繁且定期地部署新功能和修改内容来进行的。这些变更可以通过持续集成/ 持续交付（CI / CD）的方式来完。如DevOps和其他形式的迭代/敏捷交付（有关CI / CD的更多信息，请参见ITIL专家：创建，交付和支持）。物理基础架构的变化可能较慢，需要分阶段的“瀑布式”方法。可以使用相关的项目控制管理技术将这种类型的变更作为项目进行管理。但是，在实践中，很少有组织完全处于单一的阶段内。在大多数的变更中，组织经常包含了多个价值流阶段。其中，变更实践必须是自适应的，才能满足各种开发方法的需求。
	82
	83
	84	=== 2.2.1 基于复杂性的变更方法 ===
	85
	86	变更支持实践应该确保在变更效率，变更数量和风险控制之间达到有效的平衡。这意味着在计划授权和流程控制上要进行更为谨慎的选择。
	87
	88	从常规型的业务到灾难型的业务都可能发生变更（请参阅图片2.1）的情况。组织应该能够在该范围内的任何情况下都能做出改变。
	89
37.1	90	(% style="text-align:center" %)
	91	[[image:1642580164161-760.png]]
7.1	92
	93	图2.1在所有的业务阶段下都需要进行变更
	94
	95
	96	虽然，常规型业务相对可预测，不确定性较低，灾难情况相比有很高的不确定性，但是，任何情况下的变化都具有不同程度的复杂性和不可预测性。
	97
	98	在不确定性较低的情况下，可以对变更进行标准化和自动化，这有助于降低成本并提升变更效率。在这些情况下，可以使用检查清单，模板和标准化的工作方式。这会定义在标准变更的内容中。
	99
	100	标准变更
	101
	102	一种低风险、预先授权的变更，它能得到完全理解和记录，并且可以在不需要额外授权的情况下实施。
	103
	104	标准变更的示例包括：
	105
	106	* 服务请求的实现
	107	* 基础架构的维护
	108	* 日常应急检测
	109	* 日常软件更新
	110
	111	当创建或修改标准变更的程序时，应授权该程序并对其进行全面的风险评估。这种风险评估不需要每次都重复，只有在程序本身进行了一次修改时才需要进行。
	112
	113	尽管标准的变更通常与正常情况下的业务有关，但在不确定性较高的情况下，存在多个标准化示例。这些包括：
	114
	115	* 标准的事件解决
	116	* 标准的灾难响应
	117
	118	通过预定义和预先测试的方式，可以帮助组织减少极端情况下产生的不确定性。
	119
	120	然而，标准解决方案可能不能完美执行。这些情况需要一种不同的方法来实现变更。
	121
	122	当有些变更没有标准化的方法时，组织通常会制定计划、授权和控制变更。他们实施的措施包括集中专家评估，授权和控制过程等。该流程由一组专家或权威人士共同来执行完成。针对风险较低的“一般变更”，通常可以使用自动化来提升变更效率。当变更为高风险时，变更授权可能是管理委员会或类似的机构。
	123
	124	变更授权
	125
	126	负责授权变更的个人或团体。
	127
	128	可以通过创建（手动或自动）变更请求来触发一般变更。然而，具有CI/CD自动化流程的组织通常会利用自动化执行大多数变更过程。某些步骤（如服务请求注册）实际上可能变得不可见。
	129
	130	变更模型为处理一般变更提供了指导。组织通常会根据评估，授权和持续控制的类型来定义变更模型。
	131
	132	变更模型
	133
	134	对特定类型的变更可重复管理的方法。
	135
	136	可以基于以下因素定义变更模型：
	137
	138	* 变更的系统/技术
	139	* 变更的规模
	140	* 地点/地区
	141	* 客户
	142	* 影响变更的法规要求
	143
	144	如表2.1所示，在服务管理中的四种关键因素可以定义一个变更模型
	145
13.1	146
7.1	147	表2.1 服务管理模型中可确定变更模型的四种关键因素
	148
29.1	149	[[image:1642238796608-454.png]]
7.1	150
	151	此外，组织需要考虑变更的风险级别。例如，组织可以通过迭代的方式来控制变更的风险。变更的每个迭代都在可控的风险阈值以下，较小的变更也会降低变更的成本，并且更易于控制。基于这些注意事项，许多组织限制了单个更改的大小，尤其是软件和其他数字化资源的大小。
	152
	153	在管理不确定的复杂情况下，变更模型可能会有更大的帮助。例如，在变更模型的流程中可能包括了实施某些解决方案的失败性测试。这可能对定位那些无法带来明确的变更内容的事件或灾难带来极大的帮助。尽管这种方法在不稳定情况下更常见，但也适用于常见的业务型变更。
	154
	155	变更实践应该确保在紧急情况下，能够有效、安全且及时地实施变更。有助于解决紧急情况的变更通常称为紧急变更。
	156
	157	紧急变更
	158
	159	必须尽快处理的变更。
	160
	161	尽管有一些紧急的场景可以提前预知并提供标准解决方案（包括所需的标准变更），但是许多情况下尚没有现成的解决方案或没有时间进行失败测试。用于紧急变更的变更模型通常包含了那些有时间延迟的流程，例如注册请求或变更计划的更新。紧急变更可以通过特殊的部署拥有更高的授权。目的是在保证可接受的风险下，加快变更。
	162
	163	关于紧急变更的两个重要的注意事项：
	164
	165	* “紧急情况”并不意味着“没有规则或约束”。紧急变更可以在可控的情况下，通过标准化和自动化得到加速。紧急情况并不总是意味着完全不可预测。
	166	* 一些紧急变更确实可以应对不可预测的未知情况。这些情况包括，他们可能需要快速实施最佳解决方案，而没有足够的信息或时间进行测试。且这些情况的延迟变更和失败变更的风险在同一个等级上。
	167
	168	关键信息
	169
	170	变更支持实践应该包括针对可预见性和不可预见性不同情况的方法。这些方法可能包括：
	171
	172	* 标准的变更
	173	* 根据专家分析和计划的可控变更
	174	* 基于多个安全的失败测试的变更
	175	* 在没有足够的评估和规划的情况下实施的紧急变更。
	176
	177	前三种方法适用于从日常型业务到灾难业务的所有情况。最后一种方法适用于延迟成本高于失败成本的特殊情况。
	178
	179	标准化和自动化功能对于实践是非常有益的，因为它们可以在大大加速变更的同时保留足够的流程控制。对于数字化资源，产品和服务，这是实践变更的推荐方法。
	180
	181	减小变更的大小可以增加实践的效率，同时降低风险的级别。对于组织的变更模型，大小应该是重要的考量因素。
	182
	183
	184	=== 2.2.2 变更定义和范围 ===
	185
	186	变更实践支持所有价值流，并且可以与任何其他实践一起使用，因为它们都可以启动对产品和服务的更改。但是，组织通常根据要变更的内容和发生变更的[[[Q3]>>url:http://itil4hub.cn/bin/view/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/#_msocom_3]] 背景，将变更实践的应用程序限制为有限的变更类型。
	187
	188	通常，变更实践用于更改组织的产品信息和服务技术，同时其他的实践也会在服务管理的另外三个方面发挥极大的作用。尽管有些更改包含了部分变更内容，但变更实践的范围中可能不完全包括它（有关变更的示例，请参见表2.2）。组织定义了在变更支持实践中，处于哪一类的变更和哪个级别的变更要得到优先处理。基于这几个注意事项，通常包括：
	189
	190	* 风险等级考虑引入变更后所带来的风险是否可控
	191	* 成本和损失评估变更带来的成本和造成的损失是否可控
	192	* 配置范围和资产管理变更实践能够为注册的配置项目和资产提供修改方法
	193	* 内部和外部规则要求组织必须严格遵守变更的相关要求。
	194	* 可视化变更所带来的影响在组件是动态互连的环境中，变更影响的可视化需求是非常重要的
	195
	196	表2.2 服务管理模型中的四个核心要素变更示例
	197
32.1	198	(% style="width:578px" %)
	199	\|(% style="width:134px" %)服务管理的要素\|(% style="width:178px" %)涉及变更的内容\|(% style="width:264px" %)注意事项
29.1	200	\|(% style="width:134px" %)信息和技术\|(% style="width:178px" %)(((
7.1	201	硬件和软件的服务架构
	202
	203	服务设计
	204
	205	用户技术手册
32.1	206	)))\|(% style="width:264px" %)通常由变更实践和项目管理，服务设计和架构管理实践一起解决
29.1	207	\|(% style="width:134px" %)组织和人员\|(% style="width:178px" %)(((
7.1	208	组织架构
	209
	210	人员职责
	211
	212	工作行为规范
32.1	213	)))\|(% style="width:264px" %)通常由组织管理和项目管理实践解决
	214	\|(% style="width:134px" %) \|(% style="width:178px" %)个人能力\|(% style="width:264px" %)通常由员工和人才管理机构解决
29.1	215	\|(% style="width:134px" %)价值流和流程\|(% style="width:178px" %)(((
7.1	216	价值流架构
	217
	218	工作流程和程序
	219
	220	流程文档
32.1	221	)))\|(% style="width:264px" %)可以通过变更实践或其他实践来解决
29.1	222	\|(% style="width:134px" %)合作伙伴和供应商\|(% style="width:178px" %)(((
7.1	223	在体系结构上对第三方的依赖
	224
	225	与第三方的合同安排（新供应商，责任变更等）
	226
	227	合同和其他文档（版本的变更，延期等）
32.1	228	)))\|(% style="width:264px" %)变更支持实践，供应商管理或其他实践可能会解决
7.1	229
	230	根据这些以及其他注意事项，组织决定是否将对产品和服务的修改视为变更，如果是，再将其进行轻度，中等或重度的划分。变更支持实践通常针对不同程度的变更有不同的方法，通常在变更划分中对此进行了详细说明。
	231
	232
	233	=== 2.2.3 变更支持实践的自动化作用和可视化作用 ===
	234
	235	当对软件和其他数字化资源进行变更时，为了使变更的内容（包括变更计划，完整性控制，版本控制，兼容性控制等）能够成功自动执行。自动化变更大大提高了变更效率，同时保证了变更的风险在一个可接受的水平。尤其是处理单个且体量较小的变更时（请参阅第5节软件开发管理，发布管理和部署管理指南）。
	236
	237	当变更实践高度自动化时，会因为受控环境的高度复杂性，造成难以对整个组织计划和正在进行的变更进行完整的范围监督，同时，也很难确定变更是在哪里产生的。
	238
	239	组织应该拥有在较高的不确定性和复杂性中，保证变更风险在可控范围内的能力。
	240
	241	能够降低变更风险的主要方法是减小自动化变更的规模，同时对变更进行标准化的定义。
	242
	243
	244	== 2.3 范围 ==
	245
	246	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=5]]
	247
	248	变更支持实践的范围包括：
	249
	250	* 规划组织中受控环境的变更
	251	* 规划变更模型和变更标准化
	252	* 规划变更工作流，活动和控制点
	253	* 计划和协调所有正在进行的变更
	254	* 控制从启动到完成的变更进度
	255	* 与利益相关者沟通变更计划和进度
	256	* 评估变更的成功，包括输出，结果，效率，风险和成本
	257
	258	变更支持实践中不包含以下几个活动和职责范围，尽管它们与变更密切相关。表2.3中列出了这些内容，需要着重注意的是，ITIL实践只是价值流中使用工具的集合；根据情况，应将它们组合在一起。
	259
13.1	260
7.1	261	表2.3 与变更支持实践相关的其他实践活动
	262
32.1	263	[[image:1642239632641-909.png]]
7.1	264
32.1	265	[[image:1642239644197-746.png]]
7.1	266
	267	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=6]]
	268
	269	== 2.4实践成功因素 ==
	270
	271	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=7]]
	272
	273	* 定义：实践成功因素
	274
	275	实践成功因素是满足实践所需复杂的功能组成部分的目标。
	276
	277	实践的成功因素（PSF）不仅仅是一项任务或活动；它包括所有服务管理模型的四个要素。虽然活动的性质和实践中PSF的资源可能有所不同，但它们都保证了实践的有效性。
	278
	279	变更支持实践包含以下PSF：
	280
	281	* 确保及时有效地实现变更
	282	* 最小化变更的负面影响
	283	* 确保利益干系人对变更的满意度
	284	* 满足与变更相关合规性的要求
	285
	286	=== 2.4.1 确保及时有效的实现变更 ===
	287
	288	变更支持实践的重点是效果和变更的及时性。
	289
	290	变更效果可以通过变更的结果和产出进行度量。在变更产出的结果中，有效的变更可描述为“将资源从初始状态成功转换为预定义目标状态的变更”。但是，目标状态很少是变更的目标。目标状态产出的成果才是变更的目标。在成果级别上，有效的变更可描述为“成功实现所需预定义结果的变更”。
	291
	292	众所周知，对正在发生的变更进行控制和评估是非常重要的。针对特定的变更，我们可以进行重新定义和评估。通常通过多次的变更和其他措施来实现结果。对于正在进行变更的团队而言，这种差异对于管理和控制极为重要。这些团队应了解变更的价值和具体的变更内容。团队的绩效应根据其在职责范围内对目标做出的贡献来评估。
	293
	294	有效性包括在变更范围内定义的资源和服务的各种质量特性。这些可能包括安全性、性能、法规遵从性和可用性。
	295
	296	变更的及时性是变更满足启动期望和要求的另一种度量要素。可以根据授权的变更数量来衡量变更的及时性，但主要关注的是变更是否满足启动的需求。在计划，控制和评估变更时，这应该是重要的考量要素。
	297
	298	有时，如果不能满足变更的及时性将会使变更变得失效，无用或有害。
	299
	300	变更的有效性和及时性可以通过以下方法改进：
	301
	302	* 减少单个变更的大小
	303	* 标准化和自动化变更
	304	* 在变更，规划和实现的每个迭代中都包含一个反馈环
	305	* 关注结果，同时针对变更的过程及时沟通
	306	* 针对价值流内容的变更采用多种有效的ITIL实践。
	307
39.1	308
7.1	309	=== 2.4.2 最小化变更的负面影响 ===
	310
	311	变更是中断和风险的来源。变更支持实践有望将风险保持在可接受的水平。在简单，变化缓慢的环境中，可以通过在变更的每个步骤上施加控制，在授权步骤中引入更多的利益相关者并在每种情况下创建应急计划来实现。但是，这些控制将导致变更的实现效率低下和延迟，这在复杂的环境中是无法接受的。
	312
	313	为了平衡变更的及时性，有效性和风险级别，组织定义了将手动和自动控制结合起来的变更模型，以使变更标准化，不断减小变更规模，并监控和评估变更对基础设施、服务和利益相关者的影响。通过减少每个单独变更的影响、在变更失败时快速自动返回到以前的稳定状态以及自动化配置管理，可以实现风险最小化。
	314
	315
	316	=== 2.4.3 确保利益干系人满意度 ===
	317
	318	许多利益相关者都对变更感兴趣，包括：
	319
	320	* 服务提供者团队
	321	* 使用者
	322	* 消费者
	323	* 服务提供的赞助商
	324	* 服务消费的赞助商
	325	* 供应商和合作伙伴
	326
	327	变更支持实践确保利益相关者的期望能够得到考虑和满足。这将与关系管理、风险管理和业务分析实践等一起完成。变更支持实践主要集中在变更实现期间和变更完成后，对利益相关者参与度和满意度的持续监控。持续沟通、状态更新和反馈收集是管理满意度的重要组成部分。
	328
	329
	330	=== 2.4.4 满足变更相关的管理和合规性要求 ===
	331
	332	许多与变更相关的管理和合规性要求都会影响变更支持实践以及个别变更。重要的是，组织必须找到它们，理解它们并确保它们得到满足。变更支持实践通过以下方式支持此需求：
	333
	334	* 包括变更模型，流程和程序中所需的控制点
	335	* 提供所需的信息
	336	* 通过持续改进来防止非合规性情况发生
	337
	338	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=8]]
	339
	340	== 2.5 关键指标 ==
	341
	342	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=9]]
	343
	344	变更实践的有效性和绩效应在每种实践贡献的价值流的背景下进行评估。与任何工具的绩效一样，该实践的绩效只能在其应用范围内进行评估。但是，工具的设计和质量可能会有很大差异，这些差异定义了根据用途使用工具的潜力或能力。有关度量，关键绩效指标（KPI）以及其他可以帮助实现此目标的技术的进一步指南，可以在衡量和报告实践指南中找到。
	345
	346	变更支持实践的关键指标已映射到其PSF。它们可以用作价值流环境中的KPI，以评估实践对这些价值流的有效性和效率的贡献。表2.4中给出了一些关键指标的示例。
	347
13.1	348
7.1	349	表2.4 实践成功因素的关键指标示例
	350
29.1	351	(% style="width:380px" %)
	352	\|(% style="width:134px" %)实践成功要素\|(% style="width:243px" %)关键指标
	353	\|(% style="width:134px" %)确保及时有效地实现变更\|(% style="width:243px" %)(((
7.1	354	整个时间段内汇总的及时性处理（TPI）
	355
	356	每个变更模型成功实现的平均时间
	357
	358	变更启动的满意度和变更的结果
	359
	360	变更的时效性
	361
	362	变更成功率/接受率
	363
	364	特定变更的TPI
1.1	365	)))
29.1	366	\|(% style="width:134px" %)最小化负面影响\|(% style="width:243px" %)(((
7.1	367	受到变更影响的相关业务事件
	368
	369	变更所带来的问题以及影响相关事件的数量和持续时间
1.1	370	)))
7.1	371
29.1	372	(% style="width:416px" %)
	373	\|(% style="width:135px" %)确保变更相关利益干系人的满意度\|(% style="width:278px" %)(((
7.1	374	利益干系人对变更支持实践的程序和沟通的满意度
	375
	376	利益干系人对实现特定变更的满意度
	377	)))
29.1	378	\|(% style="width:135px" %)满足变更相关管理和合规性要求\|(% style="width:278px" %)(((
7.1	379	根据审计报告，具有明确的合规性规定
	380
	381	与变更相关且不合规性事件的数量和影响
	382
	383	与变更相关的合规性事件的数量和影响
	384	)))
	385
	386	将关键的指标汇总到复杂的实践中，更易于价值流的管理，且对于变更实践的定期评估和持续改进也有着极大的帮助。变更支持实践中，没有单一的最佳解决方案，所以度量标准是基于组织的优先级和价值流的首要目标来进行考虑的。
	387
	388
	389
	390	----
	391
	392	= 3 价值流和流程 =
	393
	394	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=1]]
	395
	396	== 3.1 价值流的作用 ==
	397
	398	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=2]]
	399
	400	像任何其他ITIL 实践一样，变更支持实践也有助于多个价值流。重要的是要记住，价值流永远不会由单个实践形成。变更支持实践与其他实践相结合，可以为消费者提供高质量服务。价值流的主要活动形式是：
	401
	402	* 获取和构建
	403	* 设计和转换
	404	* 交付和支持
	405	* 改进
	406
	407	图3.1 中显示了变更支持实践对服务价值流的作用。
	408
37.1	409	(% style="text-align:center" %)
	410	[[image:1642580200864-749.png]]
7.1	411
	412	图3.1 变更支持实践对价值流活动的热力图
	413
	414
	415	== 3.2 流程 ==
	416
	417	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=3]]
	418
	419	每个实践都可能包含流程和活动，它们对于实现实践目的是必不可少的。
	420
	421	* 定义：流程
	422
	423	一组相互关联或交互的活动，可将输入转换为输出。流程就是将一个或多个定义好的输入，转换为定义好的输出。流程定义了活动的顺序及其依赖关系。
	424
	425	变更支持实践包括两个流程：
	426
	427	* 变更生命周期管理
	428	* 变更优化
	429
	430	=== 3.2.1 变更生命周期管理 ===
	431
	432	变更生命周期管理流程包括表3.1中列出的活动，并将输入转换为输出。
	433
13.1	434
7.1	435	表3.1 变更生命周期管理流程的输入活动和输出活动
	436
29.1	437	(% style="width:468px" %)
	438	\|(% style="width:220px" %)关键输入\|(% style="width:118px" %)活动\|(% style="width:127px" %)关键输出
	439	\|(% style="width:220px" %)(((
7.1	440	变更请求
	441
	442	变更模型和标准变更程序
	443
	444	政策法规要求
	445
	446	配置信息
	447
	448	IT资产信息服务目录
	449
	450	与消费者和供应商/合作伙伴
	451
	452	服务级别协议（SLA）
	453
	454	财务约束准则
	455
	456	风险信息
	457
	458	容量和性能信息
	459
	460	连续性政策和计划
	461
	462	信息安全政策和计划
29.1	463	)))\|(% style="width:118px" %)(((
7.1	464	变更登记
	465
	466	变更评估
	467
	468	变更授权
	469
	470	变更规划
	471
	472	变更实现控制
	473
	474	变更评审和关闭
29.1	475	)))\|(% style="width:127px" %)(((
7.1	476	变更记录
	477
	478	变更流程
	479
	480	变更评审报告
	481
	482	变更资源和服务
	483	)))
	484
	485	图3.2 显示了变更生命周期管理的工作流程图
	486
37.1	487	(% style="text-align:center" %)
	488	[[image:1642580221097-469.png]]
7.1	489
	490	图3.2 变更生命周期管理流程的工作流程
	491
	492
	493	流程可能会因变更模型而异。
	494
	495
	496	表3.2 提供了两个变更模型中的活动的示例。
	497
13.1	498
7.1	499	表3.2 中的变更模型示例只是说明众多变更模型中的两个。组织应根据自身管理的体系结构来确保服务的灵活性并满足利益干系人的期望。
	500
29.1	501	[[image:1642239008124-714.png]]
7.1	502
29.1	503	[[image:1642239054927-965.png]]
7.1	504
	505
	506	表3.2 变更生命周期管理流程的活动对比
	507
	508
	509	=== 3.2.2 变更优化 ===
	510
	511	该流程专注于变更支持实践，变更模型和标准变更过程的持续改进。它由变更评审触发，目的是找到低效率和其他需要改进的流程，或者根据现有模型和程序定期执行。
	512
	513	该流程包括表3.3 中列出的活动，并将输入转换为输出。
	514
	515
	516	表3.3 变更优化流程的输入，活动和输出
	517
29.1	518	[[image:1642239105896-279.png]]
7.1	519
	520	图3.3 展示了变更的工作流程图。
	521
	522
	523	表3.4 提供了变更活动的示例。
	524
29.1	525	(% style="width:652px" %)
	526	\|(% style="width:113px" %)实践活动\|(% style="width:536px" %)示例
	527	\|(% style="width:113px" %)变更评审分析\|(% style="width:536px" %)变更经理与资源所有者和其他相关的利益相关者一起，在此期间对选定的（通常是不成功的）变更执行评审。他们确定变更模型和标准变更程序优化的流程，包括新变更类型的标准化。
	528	\|(% style="width:113px" %)变更模型改进启动\|(% style="width:536px" %)变更经理或变更协调员要在变更实践中持续改进措施和发起变更请求（如果变更模型和过程包含在变更支持实践的范围内）。
	529	\|(% style="width:113px" %)变更模型更新沟通\|(% style="width:536px" %)如果变更模型成功更新，则将其传达给相关的利益相关者。这通常由变更经理或资源所有者完成。
7.1	530
	531	表3.4 变更优化的活动流程
	532
	533
	534	变更支持实践由服务提供者执行，如表3.2和3.4所述。他们可能涉及客户，供应商和合作伙伴。这些实践依赖工具和技术的支持（有时甚至完全或很大程度上依赖自动化）。下图是对工作流程的优化展示。
	535
37.1	536	(% style="text-align:center" %)
	537	[[image:1642580281388-786.png]]
7.1	538
	539	图3.3 变更工作流程优化
	540
	541
	542
	543	----
	544
	545	= 4 组织和人员 =
	546
	547	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=1]]
	548
	549	== 4.1 角色、能力和责任 ==
	550
	551	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=2]]
	552
	553	实践指南虽然没有描述实践管理的角色，例如实践所有者，实践领导，或实践教练。因为每个角色的结构和命名都在不同的组织上有所区别，因此ITIL中定义的任何角色都不应被视为强制性的。
	554
	555	请记住，角色不是职务。一个人可以担任多个角色，一个角色可以分配给多个人。
	556
	557	在活动中我们描述了角色的背景。根据表4.1所示的模型，每个角色都有一个能力简介。
	558
29.1	559	(% style="width:559px" %)
	560	\|(% style="width:87px" %)能力代号\|(% style="width:470px" %)能力简介（活动和技能）
	561	\|(% style="width:87px" %)L\|(% style="width:470px" %)领导者决策，委派，监督其他活动，提供激励和动机以及评估结果
	562	\|(% style="width:87px" %)А\|(% style="width:470px" %)管理员分配任务并确定优先级，保存记录，持续报告，并发起基本改进
	563	\|(% style="width:87px" %)C\|(% style="width:470px" %)协调员/沟通者协调多方，维护利益相关者之间的沟通，并开展宣贯活动
	564	\|(% style="width:87px" %)М\|(% style="width:470px" %)方法和技术专家设计和实施工作技术，文档程序，流程咨询，工作分析和持续改进
	565	\|(% style="width:87px" %)Т\|(% style="width:470px" %)技术专家提供技术（IT）专业知识并执行基于专业知识的任务
7.1	566
	567	表4.1 能力代号和简介
	568
	569
	570	在组织中可能会发现三个实践特定角色：变更经理，变更协调员和变更授权者。这些角色通常在手动处理大量变更的组织中被引入。
	571
	572
	573	=== 4.1.1 变更经理和变更协调员角色 ===
	574
	575	变更经理通常负责：
	576
	577	* 变更流程的初始处理和验证变更请求
	578	* 根据变更模型，将变更分配给适当的团队进行评估和授权
	579	* 正式向受影响方传达变更授权方的决定
	580	* 监视、评审、构建和测试变更团队的活动
	581	* 发布变更计划并确保其在需要时可用
	582	* 进行定期和特别的服务评审分析；对变更模型和标准变更程序进行改进
	583	* 将组织在变更支持实践方法方面的专业知识进行记录总结
	584
	585	在某些情况下，组织会引入变更协调员的角色，它具有相似的职责，但职责范围比较有限（特定类型的变更、或管区，或组织的一部分）。
	586
	587	这些角色的能力配置文件是MTCLA，尽管这些能力的重要性因变更而异。表4.2 中列出了变更支持实践中可能涉及的角色以及相关的能力概况和所需技能。
	588
	589
	590	=== 4.1.2 变更授权角色 ===
	591
	592	变更需要资源，并且会带来风险。这有时会导致组织建立复杂的、通常是形式化的变更授权系统，且该系统有正式的委员会定期开会，来审查和授权在此期间累积的变更。这些被称为变更顾问委员会（CAB），它们通常成为组织价值流的瓶颈。它们导致了延迟并影响了变更支持实践的效率。
	593
	594	基于资源、成本和优先级考虑对变更进行授权是很重要的。这通常不需要一个形式化的程序。变更模型应定义授权的要求和程序，将变更权限的角色委派给适当的级别的角色，如开发团队、技术专家或服务和产品所有者。
	595
	596	变更授权者在其生命周期（从发起到完成）期间负责评估和变更的授权。根据变更模型，评估和授权，可以手动，自动完成，也可以针对特定类型的变更跳过授权。
	597
	598
	599	=== 4.1.3 变更支持活动中涉及的其他角色 ===
	600
	601	表4.2 中列出了变更支持活动中涉及的其他角色的示例。
	602
29.1	603	[[image:1642239213795-240.png]]
7.1	604
29.1	605	[[image:1642239298248-268.png]]
7.1	606
29.1	607	[[image:1642239334488-589.png]]
7.1	608
29.1	609	[[image:1642239439588-858.png]]
7.1	610
29.1	611	[[image:1642239455339-462.png]]
7.1	612
	613	表4.2 负责变更支持活动的角色示例
	614
	615
	616	== 4.2 组织结构和团队 ==
	617
	618	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=3]]
	619
	620	尽管变更经理角色可能与正式职位相关联，但很少看到单独的组织结构来支持变更实践。这样的结构更容易在具有复杂的政府机构的组织中找到，并且许多变更都是手工处理的。在以产品为中心的组织中，工作头衔和工作角色通常不用于此实践，因为它与产品开发团队的日常活动集成在一起，并且在任何可能的地方都是自动化的。正式团队在实践中可能包括变更授权团队(例如变更委员会)和为特定变更指定的临时团队，特别是当变更被视为一个项目时(有关项目团队的详细信息，请参阅项目管理实践指南)。
	621
	622
	623
	624	----
	625
	626	= 5 信息和技术 =
	627
	628	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=1]]
	629
	630	== 5.1 信息交流 ==
	631
	632	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=2]]
	633
	634	变更支持实践的有效性是基于所有使用信息的质量。这包括但不限于以下信息：
	635
	636	* 客户和用户
	637	* 服务及其体系架构和设计
	638	* 合作伙伴和供应商，包括有关它们提供的服务的合同和SLA信息
	639	* 规范服务提供的政策和要求
	640	* 提出变更
	641	* 消费者和组织的预期收益
	642	* 用户故事
	643	* 变更实施的预估时间和成本的实现
	644	* 影响变更的规定
	645	* 从过去的类似变更中学到的教训
	646	* 过去和正在进行的变化
	647	* 利益干系人满意度和实践
	648
	649	该信息可以采用各种形式。变更支持实践的关键输入和输出在第3节中列出。
	650
	651
	652	== 5.2 自动化和工具 ==
	653
	654	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=3]]
	655
	656	大多数情况下，变更支持实践的自动化将工作变得可行且有效。表5.1中将概述自动化的解决方案。
	657
	658
	659	表5.1 变更支持实践的自动化解决方案
	660
29.1	661	[[image:1642239505774-551.png]]
7.1	662
29.1	663	[[image:1642239521102-602.png]]
7.1	664
	665
	666
	667	----
	668
29.1	669	(% style="color:#2d2d2d; font-size:29px" %)6 合作伙伴和供应商(%%)
7.1	670	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/6%20%E5%90%88%E4%BD%9C%E4%BC%99%E4%BC%B4%E5%92%8C%E4%BE%9B%E5%BA%94%E5%95%86/WebHome?section=1]]
	671
	672	组织完全使用自己资源提供服务的这种情况很少。大多数（不是全部）依赖于其他服务。这些通常是由第三方提供的（请参阅ITIL 4版ITIL^^® ^^Foundation的2.4节：服务关系的模型）。在实践指南中，针对服务设计，架构管理和供应商管理引入了支持服务的依赖关系。第三方服务依赖信息用于支持变更实践中生命周期管理过程的所有步骤，并且也适用于变更优化的过程。
	673
	674	变更模型应定义第三方如何参与变更的实现以及组织如何确保变更的流程。这取决于产品的架构和设计解决方案,服务和价值来源。然而，支持这些解决方案的变更模型的优化涉及变更支持实践。通常，在选择了正确的变更模型之后，在变更，评估，规划，授权，实现控制和评审期间，还要有第三方依赖的考量。与客户和供应商签订合同时可能会对变更施加限制，将标准变更包括在内，通常情况下，将变更模型包括在合同中，并对有异议的变更提供明确的定义和批准程序。
	675
	676	组织的目标是确保快速有效的执行变更流，他们通常试图同意与合作伙伴和供应商密切合作，消除沟通、协作和决策中的障碍。此类关系中的各方应以相互透明可见为目标，知晓可能影响各方的变更内容(有关更多信息，请参阅供应商管理实践指南)。
	677
	678
	679
	680	----
	681
	682	= 7 重要提醒 =
	683
	684	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/7%20%E9%87%8D%E8%A6%81%E6%8F%90%E9%86%92/WebHome?section=1]]
	685
	686	实践指南的大部分内容都可以为组织在建立和培养自己的实践时提供可参考的建议。实践指南为组织提供了解决问题的框架，而不是答案本身。使用实践指南时，组织应始终遵循ITIL 指导原则：
	687
	688	* 聚焦价值
	689	* 从你所处的地方开始
	690	* 基于反馈迭代推进
	691	* 协作和提升可视化程度
	692	* 通盘思考和工作
	693	* 保持简单实用
	694	* 优化和自动化
	695
	696	有关指导原则及其应用程序的更多信息，请参见ITIL 4 基础版中的第4.3节
	697
	698
	699
	700	----
	701
	702	= 8 致谢 =
	703
	704	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/8%20%E8%87%B4%E8%B0%A2/WebHome?section=1]]
	705
	706	AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：
	707
	708
14.1	709
7.1	710	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/8%20%E8%87%B4%E8%B0%A2/WebHome?section=2]]
	711
	712	== 8.1 作者 ==
	713
	714	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/8%20%E8%87%B4%E8%B0%A2/WebHome?section=3]]
	715
	716	罗曼·朱拉夫列夫（Roman Jouravlev），格雷格·桑克（Greg Sanker）。
	717
	718
	719	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/8%20%E8%87%B4%E8%B0%A2/WebHome?section=4]]
	720
	721	== 8.2审阅者 ==
	722
	723	[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/8%20%E8%87%B4%E8%B0%A2/WebHome?section=5]]
	724
	725	Akshay Anand，Roy Atkinson，Sofi Fahlberg，Cheryl Grimes，Piia Karvonen，Henny KerkvlietTerpstra，Antonina Klentsova，Anton Lykov，PaulaMäättänen，David Moskowitz，Christian F.Nissen，Mark O'Loughlin，Tatiana Orlova，Eina Pirjtutu Skrynnik，Mark Smalley。

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司