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