Wiki源代码06 变更支持（已发布）

Version 13.1 by superadmin on 2021/02/07, 00:50

version	line-number	content
10.1	1	{{box cssClass="floatinginfobox" title="Contents"}}
	2	{{toc/}}
	3	{{/box}}
1.1	4
	5
4.1	6	需要下载 ITIL 4变更支持实践【中文】pdf版全文，请关注微信公众号itilxf ，并回复“变更支持”即可。
1.1	7
12.1	8	[[image:微信截图_20210206234644.png]]
1.1	9
	10
4.1	11	申明：
	12
5.1	13	本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
4.1	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	== ==
	35
	36	[[编辑>>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]]
	37
	38	== 1.1 ITIL 4资格认证计划 ==
	39
	40	[[编辑>>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]]
	41
	42	本文档中的部分内容可作为以下教学大纲的一部分以供检查：
	43
	44	* ITIL专家创建、交付和支持
	45	* ITIL专家交付利益干系人价值
	46
	47	详情请参考各部分教学大纲。
	48
	49
	50
	51	----
	52
	53	= 2 一般信息 =
	54
	55	[[编辑>>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]]
	56
	57	== 2.1目的和描述 ==
	58
	59	[[编辑>>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]]
	60
	61	* 关键信息
	62
	63	本次变更支持实践的目的是通过确保有效的风险评估、变更执行的授权和变更计划的管理最大化的保障服务和产品变更的成功。
	64
	65	该实践指导旨在确保对服务及其组件的变更在可控的范围内，并确保它们能够满足组织变更的相关需求。授权的变更即要能保证满足预期，同时还要满足组织关于变更效率的管理（变更的数量和变更实现的速度）和风险管理的要求。因为灵活性和敏捷性是现代组织的核心要素，所以它们会一直贯穿在本次实践指导中。
	66
	67	成功实现变更包含三个前提：
	68
	69	* 在价值流中规划及实现变更。将实践融入到价值流中，并确保其有效，安全且及时，来满足利益相关者的期望。
	70	* 实践的目的并不是将组织中所有变更计划和行动统一为一种模式：在数字化环境中，可能同时发生数百个更改，这种要求既不现实也不是必需的。
	71	* 对于所有在定义范围内的变更，实践应该集中精力放在效率，合规性和风险控制上。
	72
	73	== ==
	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=3]]
	76
	77	== 2.2术语和概念 ==
	78
	79	[[编辑>>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]]
	80
	81	变更
	82
	83	任何可能对服务产生直接或间接影响的添加，修改或删除行为。
	84
	85	变更支持实践要确保每个变更都能达到预期的结果。这与'聚焦价值'的指导性原则是相互统一的。与变更的技术细节相比，利益相关者更关心变更带来的价值。有时候，虽然准确的实施了变更，但是未必能实现预期的结果，达到预期的目标。此外，变更可能会产生意想不到的结果，包括对用户的负面影响，服务停机，服务级别降低和不稳定。所以，对于这些结果的控制很重要。变更包括使用各种方式和方法，每种方式和方法都代表不同级别的业务风险。软件变更通常是通过频繁且定期地部署新功能和修改内容来进行的。这些变更可以通过持续集成/ 持续交付（CI / CD）的方式来完。如DevOps和其他形式的迭代/敏捷交付（有关CI / CD的更多信息，请参见ITIL专家：创建，交付和支持）。物理基础架构的变化可能较慢，需要分阶段的“瀑布式”方法。可以使用相关的项目控制管理技术将这种类型的变更作为项目进行管理。但是，在实践中，很少有组织完全处于单一的阶段内。在大多数的变更中，组织经常包含了多个价值流阶段。其中，变更实践必须是自适应的，才能满足各种开发方法的需求。
	86
	87
	88	=== 2.2.1 基于复杂性的变更方法 ===
	89
	90	变更支持实践应该确保在变更效率，变更数量和风险控制之间达到有效的平衡。这意味着在计划授权和流程控制上要进行更为谨慎的选择。
	91
	92	从常规型的业务到灾难型的业务都可能发生变更（请参阅图片2.1）的情况。组织应该能够在该范围内的任何情况下都能做出改变。
	93
8.1	94	(% style="text-align:center" %)
7.1	95	[[image:http://itil4hub.cn/bin/download/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/1600754487294-144.png?rev=1.1\|\|alt="1600754487294-144.png"]]
	96
	97	图2.1在所有的业务阶段下都需要进行变更
	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	变更授权
	129
	130	负责授权变更的个人或团体。
	131
	132	可以通过创建（手动或自动）变更请求来触发一般变更。然而，具有CI/CD自动化流程的组织通常会利用自动化执行大多数变更过程。某些步骤（如服务请求注册）实际上可能变得不可见。
	133
	134	变更模型为处理一般变更提供了指导。组织通常会根据评估，授权和持续控制的类型来定义变更模型。
	135
	136	变更模型
	137
	138	对特定类型的变更可重复管理的方法。
	139
	140	可以基于以下因素定义变更模型：
	141
	142	* 变更的系统/技术
	143	* 变更的规模
	144	* 地点/地区
	145	* 客户
	146	* 影响变更的法规要求
	147
	148	如表2.1所示，在服务管理中的四种关键因素可以定义一个变更模型
	149
13.1	150
7.1	151	表2.1 服务管理模型中可确定变更模型的四种关键因素
	152
	153	\|价值流和流程\|组织和人员\|信息和技术\|合作伙伴和供应商
	154	\|(((
	155	变更流程的程序，包括形式化级别、变更授权的级别和形式
	156
	157	客户或用户体验过程
	158	)))\|(((
	159	所需能力
	160
	161	组织解决方案（例如变更咨询委员会或同行评审）
	162
	163	问责制度
	164
	165	责任委托制度
	166	)))\|(((
	167	信息要求
	168
	169	工具自动化
	170	)))\|(((
	171	第三方的参与情况和实施规划的情况
	172
	173	合作伙伴和供应商的沟通情况
1.1	174	)))
7.1	175
	176	此外，组织需要考虑变更的风险级别。例如，组织可以通过迭代的方式来控制变更的风险。变更的每个迭代都在可控的风险阈值以下，较小的变更也会降低变更的成本，并且更易于控制。基于这些注意事项，许多组织限制了单个更改的大小，尤其是软件和其他数字化资源的大小。
	177
	178	在管理不确定的复杂情况下，变更模型可能会有更大的帮助。例如，在变更模型的流程中可能包括了实施某些解决方案的失败性测试。这可能对定位那些无法带来明确的变更内容的事件或灾难带来极大的帮助。尽管这种方法在不稳定情况下更常见，但也适用于常见的业务型变更。
	179
	180	变更实践应该确保在紧急情况下，能够有效、安全且及时地实施变更。有助于解决紧急情况的变更通常称为紧急变更。
	181
	182	紧急变更
	183
	184	必须尽快处理的变更。
	185
	186	尽管有一些紧急的场景可以提前预知并提供标准解决方案（包括所需的标准变更），但是许多情况下尚没有现成的解决方案或没有时间进行失败测试。用于紧急变更的变更模型通常包含了那些有时间延迟的流程，例如注册请求或变更计划的更新。紧急变更可以通过特殊的部署拥有更高的授权。目的是在保证可接受的风险下，加快变更。
	187
	188	关于紧急变更的两个重要的注意事项：
	189
	190	* “紧急情况”并不意味着“没有规则或约束”。紧急变更可以在可控的情况下，通过标准化和自动化得到加速。紧急情况并不总是意味着完全不可预测。
	191	* 一些紧急变更确实可以应对不可预测的未知情况。这些情况包括，他们可能需要快速实施最佳解决方案，而没有足够的信息或时间进行测试。且这些情况的延迟变更和失败变更的风险在同一个等级上。
	192
	193	关键信息
	194
	195	变更支持实践应该包括针对可预见性和不可预见性不同情况的方法。这些方法可能包括：
	196
	197	* 标准的变更
	198	* 根据专家分析和计划的可控变更
	199	* 基于多个安全的失败测试的变更
	200	* 在没有足够的评估和规划的情况下实施的紧急变更。
	201
	202	前三种方法适用于从日常型业务到灾难业务的所有情况。最后一种方法适用于延迟成本高于失败成本的特殊情况。
	203
	204	标准化和自动化功能对于实践是非常有益的，因为它们可以在大大加速变更的同时保留足够的流程控制。对于数字化资源，产品和服务，这是实践变更的推荐方法。
	205
	206	减小变更的大小可以增加实践的效率，同时降低风险的级别。对于组织的变更模型，大小应该是重要的考量因素。
	207
	208
	209	=== 2.2.2 变更定义和范围 ===
	210
	211	变更实践支持所有价值流，并且可以与任何其他实践一起使用，因为它们都可以启动对产品和服务的更改。但是，组织通常根据要变更的内容和发生变更的[[[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]] 背景，将变更实践的应用程序限制为有限的变更类型。
	212
	213	通常，变更实践用于更改组织的产品信息和服务技术，同时其他的实践也会在服务管理的另外三个方面发挥极大的作用。尽管有些更改包含了部分变更内容，但变更实践的范围中可能不完全包括它（有关变更的示例，请参见表2.2）。组织定义了在变更支持实践中，处于哪一类的变更和哪个级别的变更要得到优先处理。基于这几个注意事项，通常包括：
	214
	215	* 风险等级考虑引入变更后所带来的风险是否可控
	216	* 成本和损失评估变更带来的成本和造成的损失是否可控
	217	* 配置范围和资产管理变更实践能够为注册的配置项目和资产提供修改方法
	218	* 内部和外部规则要求组织必须严格遵守变更的相关要求。
	219	* 可视化变更所带来的影响在组件是动态互连的环境中，变更影响的可视化需求是非常重要的
	220
13.1	221
7.1	222	表2.2 服务管理模型中的四个核心要素变更示例
	223
	224	\|服务管理的要素\|涉及变更的内容\|注意事项
	225	\|信息和技术\|(((
	226	硬件和软件的服务架构
	227
	228	服务设计
	229
	230	用户技术手册
	231	)))\|通常由变更实践和项目管理，服务设计和架构管理实践一起解决
	232	\|组织和人员\|(((
	233	组织架构
	234
	235	人员职责
	236
	237	工作行为规范
	238	)))\|通常由组织管理和项目管理实践解决
	239	\| \|个人能力\|通常由员工和人才管理机构解决
	240	\|价值流和流程\|(((
	241	价值流架构
	242
	243	工作流程和程序
	244
	245	流程文档
	246	)))\|可以通过变更实践或其他实践来解决
	247	\|合作伙伴和供应商\|(((
	248	在体系结构上对第三方的依赖
	249
	250	与第三方的合同安排（新供应商，责任变更等）
	251
	252	合同和其他文档（版本的变更，延期等）
	253	)))\|变更支持实践，供应商管理或其他实践可能会解决
	254
	255	根据这些以及其他注意事项，组织决定是否将对产品和服务的修改视为变更，如果是，再将其进行轻度，中等或重度的划分。变更支持实践通常针对不同程度的变更有不同的方法，通常在变更划分中对此进行了详细说明。
	256
	257
	258	=== 2.2.3 变更支持实践的自动化作用和可视化作用 ===
	259
	260	当对软件和其他数字化资源进行变更时，为了使变更的内容（包括变更计划，完整性控制，版本控制，兼容性控制等）能够成功自动执行。自动化变更大大提高了变更效率，同时保证了变更的风险在一个可接受的水平。尤其是处理单个且体量较小的变更时（请参阅第5节软件开发管理，发布管理和部署管理指南）。
	261
	262	当变更实践高度自动化时，会因为受控环境的高度复杂性，造成难以对整个组织计划和正在进行的变更进行完整的范围监督，同时，也很难确定变更是在哪里产生的。
	263
	264	组织应该拥有在较高的不确定性和复杂性中，保证变更风险在可控范围内的能力。
	265
	266	能够降低变更风险的主要方法是减小自动化变更的规模，同时对变更进行标准化的定义。
	267
	268
	269	== 2.3 范围 ==
	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=5]]
	272
	273	变更支持实践的范围包括：
	274
	275	* 规划组织中受控环境的变更
	276	* 规划变更模型和变更标准化
	277	* 规划变更工作流，活动和控制点
	278	* 计划和协调所有正在进行的变更
	279	* 控制从启动到完成的变更进度
	280	* 与利益相关者沟通变更计划和进度
	281	* 评估变更的成功，包括输出，结果，效率，风险和成本
	282
	283	变更支持实践中不包含以下几个活动和职责范围，尽管它们与变更密切相关。表2.3中列出了这些内容，需要着重注意的是，ITIL实践只是价值流中使用工具的集合；根据情况，应将它们组合在一起。
	284
13.1	285
7.1	286	表2.3 与变更支持实践相关的其他实践活动
	287
	288	\|(% colspan="3" %)实践指南
	289	\|(% colspan="2" %)变更启动\|所有其他实践
	290	\|(% colspan="2" %)变更的实现\|(((
	291	架构管理
	292
	293	部署管理
	294
	295	基础设施和平台管理
	296
	297	IT资产管理
	298
	299	发布管理
	300
	301	服务目录管理
	302
	303	服务配置管理
	304
	305	服务设计
	306
	307	服务级别管理
	308
	309	软件开发和管理
	310
	311	供应商管理
	312
	313	劳动力和人才管理
1.1	314	)))
7.1	315	\|(% colspan="1" %)变更风险评估与控制\|(% colspan="2" %)风险管理
	316	\|(% colspan="1" %)成本控制，变更财务评估\|(% colspan="2" %)服务财务管理
	317	\|(% colspan="1" %)管理项目\|(% colspan="2" %)项目管理
	318	\|(% colspan="1" %)管理的组织变更\|(% colspan="2" %)组织变更管理
	319	\|(% colspan="1" %)测试\|(% colspan="2" %)服务验证和测试
1.1	320
7.1	321	== ==
	322
	323	[[编辑>>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]]
	324
	325	== 2.4实践成功因素 ==
	326
	327	[[编辑>>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]]
	328
	329	* 定义：实践成功因素
	330
	331	实践成功因素是满足实践所需复杂的功能组成部分的目标。
	332
	333	实践的成功因素（PSF）不仅仅是一项任务或活动；它包括所有服务管理模型的四个要素。虽然活动的性质和实践中PSF的资源可能有所不同，但它们都保证了实践的有效性。
	334
	335	变更支持实践包含以下PSF：
	336
	337	* 确保及时有效地实现变更
	338	* 最小化变更的负面影响
	339	* 确保利益干系人对变更的满意度
	340	* 满足与变更相关合规性的要求
	341
	342	=== ===
	343
	344	=== 2.4.1 确保及时有效的实现变更 ===
	345
	346	变更支持实践的重点是效果和变更的及时性。
	347
	348	变更效果可以通过变更的结果和产出进行度量。在变更产出的结果中，有效的变更可描述为“将资源从初始状态成功转换为预定义目标状态的变更”。但是，目标状态很少是变更的目标。目标状态产出的成果才是变更的目标。在成果级别上，有效的变更可描述为“成功实现所需预定义结果的变更”。
	349
	350	众所周知，对正在发生的变更进行控制和评估是非常重要的。针对特定的变更，我们可以进行重新定义和评估。通常通过多次的变更和其他措施来实现结果。对于正在进行变更的团队而言，这种差异对于管理和控制极为重要。这些团队应了解变更的价值和具体的变更内容。团队的绩效应根据其在职责范围内对目标做出的贡献来评估。
	351
	352	有效性包括在变更范围内定义的资源和服务的各种质量特性。这些可能包括安全性、性能、法规遵从性和可用性。
	353
	354	变更的及时性是变更满足启动期望和要求的另一种度量要素。可以根据授权的变更数量来衡量变更的及时性，但主要关注的是变更是否满足启动的需求。在计划，控制和评估变更时，这应该是重要的考量要素。
	355
	356	有时，如果不能满足变更的及时性将会使变更变得失效，无用或有害。
	357
	358	变更的有效性和及时性可以通过以下方法改进：
	359
	360	* 减少单个变更的大小
	361	* 标准化和自动化变更
	362	* 在变更，规划和实现的每个迭代中都包含一个反馈环
	363	* 关注结果，同时针对变更的过程及时沟通
	364	* 针对价值流内容的变更采用多种有效的ITIL实践。
	365
	366	=== ===
	367
	368	=== 2.4.2 最小化变更的负面影响 ===
	369
	370	变更是中断和风险的来源。变更支持实践有望将风险保持在可接受的水平。在简单，变化缓慢的环境中，可以通过在变更的每个步骤上施加控制，在授权步骤中引入更多的利益相关者并在每种情况下创建应急计划来实现。但是，这些控制将导致变更的实现效率低下和延迟，这在复杂的环境中是无法接受的。
	371
	372	为了平衡变更的及时性，有效性和风险级别，组织定义了将手动和自动控制结合起来的变更模型，以使变更标准化，不断减小变更规模，并监控和评估变更对基础设施、服务和利益相关者的影响。通过减少每个单独变更的影响、在变更失败时快速自动返回到以前的稳定状态以及自动化配置管理，可以实现风险最小化。
	373
	374
	375	=== 2.4.3 确保利益干系人满意度 ===
	376
	377	许多利益相关者都对变更感兴趣，包括：
	378
	379	* 服务提供者团队
	380	* 使用者
	381	* 消费者
	382	* 服务提供的赞助商
	383	* 服务消费的赞助商
	384	* 供应商和合作伙伴
	385
	386	变更支持实践确保利益相关者的期望能够得到考虑和满足。这将与关系管理、风险管理和业务分析实践等一起完成。变更支持实践主要集中在变更实现期间和变更完成后，对利益相关者参与度和满意度的持续监控。持续沟通、状态更新和反馈收集是管理满意度的重要组成部分。
	387
	388
	389	=== 2.4.4 满足变更相关的管理和合规性要求 ===
	390
	391	许多与变更相关的管理和合规性要求都会影响变更支持实践以及个别变更。重要的是，组织必须找到它们，理解它们并确保它们得到满足。变更支持实践通过以下方式支持此需求：
	392
	393	* 包括变更模型，流程和程序中所需的控制点
	394	* 提供所需的信息
	395	* 通过持续改进来防止非合规性情况发生
	396
	397	== ==
	398
	399	[[编辑>>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]]
	400
	401	== 2.5 关键指标 ==
	402
	403	[[编辑>>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]]
	404
	405	变更实践的有效性和绩效应在每种实践贡献的价值流的背景下进行评估。与任何工具的绩效一样，该实践的绩效只能在其应用范围内进行评估。但是，工具的设计和质量可能会有很大差异，这些差异定义了根据用途使用工具的潜力或能力。有关度量，关键绩效指标（KPI）以及其他可以帮助实现此目标的技术的进一步指南，可以在衡量和报告实践指南中找到。
	406
	407	变更支持实践的关键指标已映射到其PSF。它们可以用作价值流环境中的KPI，以评估实践对这些价值流的有效性和效率的贡献。表2.4中给出了一些关键指标的示例。
	408
13.1	409
7.1	410	表2.4 实践成功因素的关键指标示例
	411
	412	\|实践成功要素\|关键指标
	413	\|确保及时有效地实现变更\|(((
	414	整个时间段内汇总的及时性处理（TPI）
	415
	416	每个变更模型成功实现的平均时间
	417
	418	变更启动的满意度和变更的结果
	419
	420	变更的时效性
	421
	422	变更成功率/接受率
	423
	424	特定变更的TPI
1.1	425	)))
7.1	426	\|最小化负面影响\|(((
	427	受到变更影响的相关业务事件
	428
	429	变更所带来的问题以及影响相关事件的数量和持续时间
1.1	430	)))
7.1	431
	432	\|确保变更相关利益干系人的满意度\|(((
	433	利益干系人对变更支持实践的程序和沟通的满意度
	434
	435	利益干系人对实现特定变更的满意度
	436	)))
	437	\|满足变更相关管理和合规性要求\|(((
	438	根据审计报告，具有明确的合规性规定
	439
	440	与变更相关且不合规性事件的数量和影响
	441
	442	与变更相关的合规性事件的数量和影响
	443	)))
	444
	445	将关键的指标汇总到复杂的实践中，更易于价值流的管理，且对于变更实践的定期评估和持续改进也有着极大的帮助。变更支持实践中，没有单一的最佳解决方案，所以度量标准是基于组织的优先级和价值流的首要目标来进行考虑的。
	446
	447
	448
	449	----
	450
	451	= 3 价值流和流程 =
	452
	453	[[编辑>>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]]
	454
	455	== 3.1 价值流的作用 ==
	456
	457	[[编辑>>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]]
	458
	459	像任何其他ITIL 实践一样，变更支持实践也有助于多个价值流。重要的是要记住，价值流永远不会由单个实践形成。变更支持实践与其他实践相结合，可以为消费者提供高质量服务。价值流的主要活动形式是：
	460
	461	* 获取和构建
	462	* 设计和转换
	463	* 交付和支持
	464	* 改进
	465
13.1	466
7.1	467	图3.1 中显示了变更支持实践对服务价值流的作用。
	468
8.1	469	(% style="text-align:center" %)
7.1	470	[[image:http://itil4hub.cn/bin/download/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/1600755273276-287.png?rev=1.1\|\|alt="1600755273276-287.png"]]
	471
	472	图3.1 变更支持实践对价值流活动的热力图
	473
	474
	475	== 3.2 流程 ==
	476
	477	[[编辑>>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]]
	478
	479	每个实践都可能包含流程和活动，它们对于实现实践目的是必不可少的。
	480
	481	* 定义：流程
	482
	483	一组相互关联或交互的活动，可将输入转换为输出。流程就是将一个或多个定义好的输入，转换为定义好的输出。流程定义了活动的顺序及其依赖关系。
	484
	485	变更支持实践包括两个流程：
	486
	487	* 变更生命周期管理
	488	* 变更优化
	489
13.1	490
7.1	491	=== 3.2.1 变更生命周期管理 ===
	492
	493	变更生命周期管理流程包括表3.1中列出的活动，并将输入转换为输出。
	494
13.1	495
7.1	496	表3.1 变更生命周期管理流程的输入活动和输出活动
	497
	498	\|关键输入\|活动\|关键输出
	499	\|(((
	500	变更请求
	501
	502	变更模型和标准变更程序
	503
	504	政策法规要求
	505
	506	配置信息
	507
	508	IT资产信息服务目录
	509
	510	与消费者和供应商/合作伙伴
	511
	512	服务级别协议（SLA）
	513
	514	财务约束准则
	515
	516	风险信息
	517
	518	容量和性能信息
	519
	520	连续性政策和计划
	521
	522	信息安全政策和计划
	523	)))\|(((
	524	变更登记
	525
	526	变更评估
	527
	528	变更授权
	529
	530	变更规划
	531
	532	变更实现控制
	533
	534	变更评审和关闭
	535	)))\|(((
	536	变更记录
	537
	538	变更流程
	539
	540	变更评审报告
	541
	542	变更资源和服务
	543	)))
	544
13.1	545
7.1	546	图3.2 显示了变更生命周期管理的工作流程图
	547
8.1	548	(% style="text-align:center" %)
7.1	549	[[image:http://itil4hub.cn/bin/download/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/1600755315634-648.png?rev=1.1\|\|alt="1600755315634-648.png"]]
	550
	551	图3.2 变更生命周期管理流程的工作流程
	552
	553
	554	流程可能会因变更模型而异。
	555
	556
	557	表3.2 提供了两个变更模型中的活动的示例。
	558
13.1	559
7.1	560	表3.2 中的变更模型示例只是说明众多变更模型中的两个。组织应根据自身管理的体系结构来确保服务的灵活性并满足利益干系人的期望。
	561
	562	\|(% colspan="2" %)活动\|(% colspan="3" %)人工变更\|自动化变更
	563	\|(% colspan="2" %)变更登记\|(% colspan="3" %)(((
	564	从变更发起者收到变更请求，根据变更请求，服务所有者，资源所有者，变更管理者或变更协调者将创建变更记录。
	565
	566	变更发起方收到变更请求接受的确认。
	567	)))\|变更请求累积在生产或服务待办项中。生产开发团队决定将哪些请求纳入开发。
	568	\|(% colspan="2" %)变更评估\|(% colspan="3" %)服务负责人，资源所有者，变更经理或变更协调员执行变更影响的评估，相关风险和所需资源。如果需要，可能会涉及其他领域的专家。评估信息被添加到变更记录。\|生产开发团队决定执行变更的最佳方法。
	569	\|(% colspan="2" %)变更授权\|(% colspan="3" %)根据变更模型分配的授权，授权机构检查变更记录并提供授权。如果变更未经授权，则将其发送以供审查或关闭。由于会需要进行其他评估，因此将变更记录连同评估理由一起返回评估。\|(((
	570	不需要变更授权：
	571
	572	因为标准的更改很可能是预先授权的对于该类型的变更，通过开发过程对待办任务列表的评估完成变更授权。
	573	)))
	574	\|(% colspan="2" %)变更规划\|(% colspan="3" %)根据变更模型，将有相关专业知识和权限的角色安排到规划中。规划中可能需要其他授权，具体取决于变更模型。该变更规划由变更协调员或变更经理来进行安排。\|规划阶段被最小化：较小的工作量允许将规划委派给开发团队，并减少了为此需要时间。
	575	\| \|(% colspan="2" %)变更实现控制\|(((
	576	资源的计划变更由内部和外部专家团队执行。其中可能包括：
	577
	578	* 软件开发人员
	579	* 基础架构工程师
	580	* 合同/ 供应商管理员
	581	* 测试人员
	582	* 用户支持专家
	583
	584	手动和自动控制操作由变更经理或其他约定的角色执行。变更经理定期进行检测并纠正。
	585	)))\|(% colspan="2" %)(((
	586	资源的计划变更由内部和外部专家团队执行。
	587
	588	变更的实现控制几乎是全自动的，包括：
	589
	590	* 验证和测试
	591	* 配置控制和验证
	592	* 资产控制
	593	* 版本控制
	594	* 备份和还原
	595	)))
	596	\| \|(% colspan="2" %)变更评审和关闭\|(((
	597	变更完成后，或变更如果未能及时完成，需由公认的机构审查变更。其中，可能涉及以下一个或多个角色：变更经理，服务负责人，变更发起者，资源所有者。
	598
	599	在评审前还是评审后正式关闭变更，取决于具体的变更模型。
	600	)))\|(% colspan="2" %)除非变更实现不成功，否则不会对单个更改执行变更评审。在确认变更成功后，变更将自动关闭。
	601
	602	表3.2 变更生命周期管理流程的活动对比
	603
	604
	605	=== 3.2.2 变更优化 ===
	606
	607	该流程专注于变更支持实践，变更模型和标准变更过程的持续改进。它由变更评审触发，目的是找到低效率和其他需要改进的流程，或者根据现有模型和程序定期执行。
	608
	609	该流程包括表3.3 中列出的活动，并将输入转换为输出。
	610
	611
	612	表3.3 变更优化流程的输入，活动和输出
	613
	614	\|关键输入\|活动\|关键输出
	615	\|(((
	616	变更记录
	617
	618	当前的变更模型和标准变更程序
	619
	620	政策法规要求
	621
	622	配置信息IT资产信息服务目录
	623
	624	与消费者和供应商/合作伙伴的SLA
	625
	626	财务准则和约束
	627
	628	风险信息
	629
	630	容量和性能或绩效信息
	631
	632	连续性政策和计划
	633	)))\|(((
	634	变更评审分析
	635
	636	变更模型改进点启动
	637
	638	变更模型更新的沟通
	639	)))\|(((
	640	变更评审分析报告
	641
	642	改进启动
	643
	644	变更请求
	645
	646	更新的变更模型
	647
	648	更新的标准变更程序
	649	)))
	650
	651	图3.3 展示了变更的工作流程图。
	652
	653
	654	表3.4 提供了变更活动的示例。
	655
	656	\|实践活动\|示例
	657	\|变更评审分析\|变更经理与资源所有者和其他相关的利益相关者一起，在此期间对选定的（通常是不成功的）变更执行评审。他们确定变更模型和标准变更程序优化的流程，包括新变更类型的标准化。
	658	\|变更模型改进启动\|变更经理或变更协调员要在变更实践中持续改进措施和发起变更请求（如果变更模型和过程包含在变更支持实践的范围内）。
	659	\|变更模型更新沟通\|如果变更模型成功更新，则将其传达给相关的利益相关者。这通常由变更经理或资源所有者完成。
	660
	661	表3.4 变更优化的活动流程
	662
	663
	664	变更支持实践由服务提供者执行，如表3.2和3.4所述。他们可能涉及客户，供应商和合作伙伴。这些实践依赖工具和技术的支持（有时甚至完全或很大程度上依赖自动化）。下图是对工作流程的优化展示。
	665
8.1	666	(% style="text-align:center" %)
7.1	667	[[image:http://itil4hub.cn/bin/download/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/1600755414932-477.png?rev=1.1\|\|alt="1600755414932-477.png"]]
	668
	669	图3.3 变更工作流程优化
	670
	671
	672
	673	----
	674
	675	= 4 组织和人员 =
	676
	677	[[编辑>>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]]
	678
	679	== 4.1 角色、能力和责任 ==
	680
	681	[[编辑>>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]]
	682
	683	实践指南虽然没有描述实践管理的角色，例如实践所有者，实践领导，或实践教练。因为每个角色的结构和命名都在不同的组织上有所区别，因此ITIL中定义的任何角色都不应被视为强制性的。
	684
	685	请记住，角色不是职务。一个人可以担任多个角色，一个角色可以分配给多个人。
	686
	687	在活动中我们描述了角色的背景。根据表4.1所示的模型，每个角色都有一个能力简介。
	688
	689	\|能力代号\|能力简介（活动和技能）
	690	\|L\|领导者决策，委派，监督其他活动，提供激励和动机以及评估结果
	691	\|А\|管理员分配任务并确定优先级，保存记录，持续报告，并发起基本改进
	692	\|C\|协调员/沟通者协调多方，维护利益相关者之间的沟通，并开展宣贯活动
	693	\|М\|方法和技术专家设计和实施工作技术，文档程序，流程咨询，工作分析和持续改进
	694	\|Т\|技术专家提供技术（IT）专业知识并执行基于专业知识的任务
	695
	696	表4.1 能力代号和简介
	697
	698
	699	在组织中可能会发现三个实践特定角色：变更经理，变更协调员和变更授权者。这些角色通常在手动处理大量变更的组织中被引入。
	700
	701
	702	=== 4.1.1 变更经理和变更协调员角色 ===
	703
	704	变更经理通常负责：
	705
	706	* 变更流程的初始处理和验证变更请求
	707	* 根据变更模型，将变更分配给适当的团队进行评估和授权
	708	* 正式向受影响方传达变更授权方的决定
	709	* 监视、评审、构建和测试变更团队的活动
	710	* 发布变更计划并确保其在需要时可用
	711	* 进行定期和特别的服务评审分析；对变更模型和标准变更程序进行改进
	712	* 将组织在变更支持实践方法方面的专业知识进行记录总结
	713
	714	在某些情况下，组织会引入变更协调员的角色，它具有相似的职责，但职责范围比较有限（特定类型的变更、或管区，或组织的一部分）。
	715
	716	这些角色的能力配置文件是MTCLA，尽管这些能力的重要性因变更而异。表4.2 中列出了变更支持实践中可能涉及的角色以及相关的能力概况和所需技能。
	717
	718
	719	=== 4.1.2 变更授权角色 ===
	720
	721	变更需要资源，并且会带来风险。这有时会导致组织建立复杂的、通常是形式化的变更授权系统，且该系统有正式的委员会定期开会，来审查和授权在此期间累积的变更。这些被称为变更顾问委员会（CAB），它们通常成为组织价值流的瓶颈。它们导致了延迟并影响了变更支持实践的效率。
	722
	723	基于资源、成本和优先级考虑对变更进行授权是很重要的。这通常不需要一个形式化的程序。变更模型应定义授权的要求和程序，将变更权限的角色委派给适当的级别的角色，如开发团队、技术专家或服务和产品所有者。
	724
	725	变更授权者在其生命周期（从发起到完成）期间负责评估和变更的授权。根据变更模型，评估和授权，可以手动，自动完成，也可以针对特定类型的变更跳过授权。
	726
	727
	728	=== 4.1.3 变更支持活动中涉及的其他角色 ===
	729
	730	表4.2 中列出了变更支持活动中涉及的其他角色的示例。
	731
	732	\|(% colspan="3" %)活动\|(% colspan="3" %)负责角色\|胜任力\|(% colspan="3" %)具体技能简介
	733	\|(% colspan="10" %)变更生命周期管理流程
	734	\|(% colspan="4" %)变更登记\|(((
	735	变更协调员
	736
	737	变更经理
	738
	739	产品负责人
	740
	741	生产开发团队
	742
	743	资源服务负责人
	744	)))\|(% colspan="3" %)TA\|(% colspan="2" %)了解变更模型和登记程序
	745	\|(% colspan="4" %)变更评估\|(((
	746	变更协调员
	747
	748	生产开发团队
	749
	750	产品负责人
	751
	752	服务负责人
	753
	754	技术专家
	755	)))\|(% colspan="3" %)TC\|(% colspan="2" %)(((
	756	良好的产品知识
	757
	758	包括其架构和配置
	759
	760	业务影响分析风险分析
	761	)))
	762	\|(% colspan="4" %)变更认证\|(((
	763	变更协调员
	764
	765	变更经理
	766
	767	客户代表
	768
	769	生产开发团队
	770
	771	产品负责人
	772
	773	资源负责人
	774
	775	风险和合规性专家
	776
	777	服务负责人
	778
	779	技术专家
	780	)))\|(% colspan="3" %)CTM\|(% colspan="2" %)(((
	781	良好的产品知识，内容包括其架构和配置
	782
	783	了解变更模型，业务影响分析
	784	)))
	785	\|(% colspan="4" %)变更计划\|(((
	786	变更协调员
	787
	788	变更经理
	789
	790	生产开发团队
	791
	792	产品负责人
	793
	794	资源负责人
	795
	796	服务负责人
	797	)))\|(% colspan="3" %)TAC\|(% colspan="2" %)(((
	798	良好的产品知识，内容包括其架构和配置
	799
	800	了解变更模型
	801	)))
	802	\|(% colspan="4" %)变更实施控制\|(((
	803	变更协调员
	804
	805	变更经理
	806
	807	生产开发团队
	808
	809	产品负责人
	810
	811	资源负责人
	812
	813	服务负责人
	814	)))\|(% colspan="3" %)ATC\|(% colspan="2" %)(((
	815	良好的产品知识，内容包括其架构和配置
	816
	817	了解变更模型
	818	)))
	819	\|(% colspan="4" %)变更审核和关闭\|(((
	820	变更协调员
	821
	822	变更经理
	823
	824	客户代表
	825
	826	生产开发团队
	827
	828	产品负责人
	829
	830	资源负责人
	831
	832	服务负责人
	833	)))\|(% colspan="3" %)TCA\|(% colspan="2" %)(((
	834	良好的产品知识，内容包括其架构和配置
	835
	836	业务影响分析
	837	)))
	838	\| \|(% colspan="9" %)变更优化流程
	839	\| \|变更评审分析\|(% colspan="4" %)(((
	840	变更协调员
	841
	842	变更经理
	843
	844	生产开发团队
	845
	846	产品负责人
	847
	848	资源负责人
	849
	850	风险和合规性专家
	851
	852	服务负责人
	853	)))\|(% colspan="3" %)TC\|(((
	854	良好的产品知识，内容包括其基础架构和配置
	855
	856	了解变更模型
	857
	858	业务影响分析
	859
	860	风险分析
	861	)))
	862	\| \|(((
	863	变更模型
	864
	865	改进举措
	866	)))\|(% colspan="4" %)(((
	867	变更经理
	868
	869	生产开发团队
	870
	871	产品负责人
	872
	873	风险和合规性专家
	874
	875	服务负责人
	876	)))\|(% colspan="3" %)TMA\|(((
	877	良好的产品知识，内容包括其基础架构和配置
	878
	879	了解变更模型
	880
	881	业务影响分析
	882
	883	风险分析
	884	)))
	885	\| \|(((
	886	变更模型
	887
	888	更新通讯
	889	)))\|(% colspan="4" %)(((
	890	变更经理
	891
	892	产品负责人
	893
	894	服务负责人
	895	)))\|(% colspan="3" %)CT\|(((
	896	了解变更模型
	897
	898	沟通技巧
	899	)))
	900	\| \| \| \| \| \| \| \| \| \|
	901
	902	表4.2 负责变更支持活动的角色示例
	903
	904
	905	== 4.2 组织结构和团队 ==
	906
	907	[[编辑>>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]]
	908
	909	尽管变更经理角色可能与正式职位相关联，但很少看到单独的组织结构来支持变更实践。这样的结构更容易在具有复杂的政府机构的组织中找到，并且许多变更都是手工处理的。在以产品为中心的组织中，工作头衔和工作角色通常不用于此实践，因为它与产品开发团队的日常活动集成在一起，并且在任何可能的地方都是自动化的。正式团队在实践中可能包括变更授权团队(例如变更委员会)和为特定变更指定的临时团队，特别是当变更被视为一个项目时(有关项目团队的详细信息，请参阅项目管理实践指南)。
	910
	911
	912
	913	----
	914
	915	= 5 信息和技术 =
	916
	917	[[编辑>>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]]
	918
	919	== 5.1 信息交流 ==
	920
	921	[[编辑>>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]]
	922
	923	变更支持实践的有效性是基于所有使用信息的质量。这包括但不限于以下信息：
	924
	925	* 客户和用户
	926	* 服务及其体系架构和设计
	927	* 合作伙伴和供应商，包括有关它们提供的服务的合同和SLA信息
	928	* 规范服务提供的政策和要求
	929	* 提出变更
	930	* 消费者和组织的预期收益
	931	* 用户故事
	932	* 变更实施的预估时间和成本的实现
	933	* 影响变更的规定
	934	* 从过去的类似变更中学到的教训
	935	* 过去和正在进行的变化
	936	* 利益干系人满意度和实践
	937
	938	该信息可以采用各种形式。变更支持实践的关键输入和输出在第3节中列出。
	939
	940
	941	== 5.2 自动化和工具 ==
	942
	943	[[编辑>>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]]
	944
	945	大多数情况下，变更支持实践的自动化将工作变得可行且有效。表5.1中将概述自动化的解决方案。
	946
	947
	948	表5.1 变更支持实践的自动化解决方案
	949
	950	\|(% colspan="2" %)实践流程\|自动化方法\|(% colspan="2" %)关键功能\|影响效果
	951	\|(% colspan="6" %)//变更生命周期管理流程//
	952	\|变更登记\|(% colspan="2" %)工单和工作流程系统，代办项管理工具，以及看板\|启用和控制变更工作流程；\|(% colspan="2" %)很高，特别是对于大量的变更
	953	\| \|(% colspan="2" %) \|待办项优先级和工作流程管理；\|(% colspan="2" %)
	954	\| \|(% colspan="2" %) \|工作流程可视化\|(% colspan="2" %)
	955	\|变更评估\|(% colspan="2" %)工单和工作流系统，协作工具和资源规划工具\|评估的形式化和结构化，可提供更准确，更可靠的数据授权\|(% colspan="2" %)中到高，特别是对于手动处理复杂的变更
	956	\|变更授权\|(% colspan="2" %)工单和工作流系统以及协作工具\|快速且可追溯的远程批准变更\|(% colspan="2" %)高，特别是对于高速变更的授权。
	957	\|变更计划\|(% colspan="2" %)变更调度程序，项目管理工具，看板和编排系统\|可视化对所有利益相关者共享的计划和正在进行的变更；自动化标准变更的规划\|(% colspan="2" %)很高，特别是在并行实现许多变更时
	958	\|变更实施控制\|(% colspan="2" %)工作流程管理工具，协作和报告工具，看板以及编排系统\|可视化和报告对正在进行的变更的最新视图\|(% colspan="2" %)很高
	959	\|变更评审和关闭\|(% colspan="2" %)协作工具以及工单和工作流系统\|远程评审和讨论；可追溯的正式关闭变更\|(% colspan="2" %)中等到高，特别是在法规要求可追溯记录的情况下
	960	\|(% colspan="6" %)变更优化流程
	961	\|变更评审分析\|(% colspan="2" %)协作系统、分析和报告系统\|远程协作;变更数据分析\|(% colspan="2" %)(((
	962	中到高，
	963
	964	特别是对于大量变更
	965	)))
	966	\|(((
	967	变更模型
	968
	969	改进启动
	970	)))\|(% colspan="2" %)工单和工作流系统以及待办项工具\|主动改进的正式注册登记\|(% colspan="2" %)中低
	971	\|变更模型更新沟通 \|(% colspan="2" %)(((
	972	沟通系统和
	973
	974	协作系统
	975	)))\|向受影响的团队同步最新情况\|(% colspan="2" %)中等到高，特别是当组织很大并且变更的数量很多的时候
	976
13.1	977
	978
7.1	979	----
	980
	981	= 6 合作伙伴和供应商 =
	982
	983	[[编辑>>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]]
	984
	985	组织完全使用自己资源提供服务的这种情况很少。大多数（不是全部）依赖于其他服务。这些通常是由第三方提供的（请参阅ITIL 4版ITIL^^® ^^Foundation的2.4节：服务关系的模型）。在实践指南中，针对服务设计，架构管理和供应商管理引入了支持服务的依赖关系。第三方服务依赖信息用于支持变更实践中生命周期管理过程的所有步骤，并且也适用于变更优化的过程。
	986
	987	变更模型应定义第三方如何参与变更的实现以及组织如何确保变更的流程。这取决于产品的架构和设计解决方案,服务和价值来源。然而，支持这些解决方案的变更模型的优化涉及变更支持实践。通常，在选择了正确的变更模型之后，在变更，评估，规划，授权，实现控制和评审期间，还要有第三方依赖的考量。与客户和供应商签订合同时可能会对变更施加限制，将标准变更包括在内，通常情况下，将变更模型包括在合同中，并对有异议的变更提供明确的定义和批准程序。
	988
	989	组织的目标是确保快速有效的执行变更流，他们通常试图同意与合作伙伴和供应商密切合作，消除沟通、协作和决策中的障碍。此类关系中的各方应以相互透明可见为目标，知晓可能影响各方的变更内容(有关更多信息，请参阅供应商管理实践指南)。
	990
	991
	992
	993	----
	994
	995	= 7 重要提醒 =
	996
	997	[[编辑>>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]]
	998
	999	实践指南的大部分内容都可以为组织在建立和培养自己的实践时提供可参考的建议。实践指南为组织提供了解决问题的框架，而不是答案本身。使用实践指南时，组织应始终遵循ITIL 指导原则：
	1000
	1001	* 聚焦价值
	1002	* 从你所处的地方开始
	1003	* 基于反馈迭代推进
	1004	* 协作和提升可视化程度
	1005	* 通盘思考和工作
	1006	* 保持简单实用
	1007	* 优化和自动化
	1008
	1009	有关指导原则及其应用程序的更多信息，请参见ITIL 4 基础版中的第4.3节
	1010
	1011
	1012
	1013	----
	1014
	1015	= 8 致谢 =
	1016
	1017	[[编辑>>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]]
	1018
	1019	AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：
	1020
	1021	== ==
	1022
	1023	[[编辑>>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]]
	1024
	1025	== 8.1 作者 ==
	1026
	1027	[[编辑>>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]]
	1028
	1029	罗曼·朱拉夫列夫（Roman Jouravlev），格雷格·桑克（Greg Sanker）。
	1030
	1031	== ==
	1032
	1033	[[编辑>>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]]
	1034
	1035	== 8.2审阅者 ==
	1036
	1037	[[编辑>>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]]
	1038
	1039	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号

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

Wiki源代码06 变更支持 （已发布）

Wiki源代码06 变更支持（已发布）