由 superadmin 于 2024/12/25, 15:36 最后修改
Show last authors
1 {{box cssClass="floatinginfobox" title="**Contents**"}}
2 {{toc/}}
3 {{/box}}
4
5 (((
6 {{info}}
7
8 {{/info}}
9
10
11 **申明：**
12
13 本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注**微信公众号：ITILXF**，并回复“**持续改进**”即可。
14
15
16 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
17
18
19 翻译：严诚  审校：邓晓毅  审核：樊伟焯
20
21
22
23 ----
24
25 = **1  关于本文档** =
26
27 本文档提供持续改进实践实用指南，分为五个主要部分，涵盖：
28
29 * 有关实践的一般信息
30 * 本实践相关的流程和活动及其在服务价值链中的作用
31 * 参与本实践的组织和人员
32 * 支持本实践的信息和技术
33 * 对本实践的合作伙伴和供应商的考虑
34
35 == **1.1 ITIL 4资格认证计划** ==
36
37 本文档中的部分内容可作为以下教学大纲的一部分以供检查：
38
39 * ITIL专家创建,交付和支持
40 * ITIL专家指引,计划和优化
41
42 详情请参考各部分教学大纲。
43
44
45
46 ----
47
48 = **2 一般信息** =
49
50
51 == **2.1 ** **目的与描述** ==
52
53 * **关键信息**
54
55 持续改进实践的目的是通过持续的改进产品、服务、实践或管理产品和服务中涉及的任何元素，使组织的实践和服务与不断变化的业务需求保持一致。
56
57 当服务提供者采用实践作为其常规活动的一部分来规范，鼓励和管理改进时，它就开始了持续改进实践。
58
59 持续改进实践使服务提供者能够不断适应不断变化的业务需求，并维护和增加其服务价值系统（SVS）产生的价值。服务提供者应：
60
61 * 适应变化的环境（随机应变）。
62 * 提高他们有效交付和管理服务的整体能力。
63
64 如果不能适应和改进，将导致服务价值的减少。
65
66
67 == **2.2 术语和概念** ==
68
69 * **定义：改进**
70
71 有意引入的变更，为一个或多个干系人带来价值的增加。
72
73 组织中采取的几乎每个行动都可以被视为一种改进活动。改进意味着改变，如果不改变当前状态，将无法改变结果。
74
75
76 * **定义：愿景**
77
78 组织未来将成为什么的明确愿望。
79
80 愿景可能是对将来状态的简短描述，组织及其价值网络的所有部分都需要对此作出贡献。愿景专注于组织的抱负，但通常不详述实现这些抱负的方式。
81
82 所有改进计划都需要从组织愿景中展开。如果任何改进对实现愿景没有贡献，哪怕是很小的贡献都没有，那么这种改变可能就是不必要的或无效的。
83
84
85 * **定义：日程业务BAU**
86
87 通常可重复执行的常规任务，可以由具有适当技术或技能的人员执行，而不必作为项目进行管理。
88
89 日常业务（BAU）的一个示例是：需要在相对较短的时间范围内对现有产品进行修改或增强。在产品的整个生命周期中，通常会定期收到一长串这样的任务。可能有一支专门负责这项工作的团队。
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
122 ● 收到反馈后，就可以对其进行分析，以识别和验证改进的机会，风险或问题。
123
124
125 === **2.2.1 ** **涉及服务消费者** ===
126
127 在服务关系中，服务提供者和服务消费者可以共享价值流活动。因此：
128
129 ● 某些改进可能涉及服务使用的变化
130
131 ● 某些改进可能会直接影响服务消费者。
132
133 在获取改进机会和规划改进时，应考虑这两个因素。应鼓励服务消费者及其代表向改进登记表提交建议，并参与改进规划和风险评估。
134
135 服务消费者应该很自在地对服务提供者提出改进建议。服务提供者应该计划并为服务消费者及其代表提供反馈渠道。持续改进实践中开放的沟通和包容性将有助于构建成为有价值，有效的关系。
136
137 服务提供者应与服务消费者紧密合作，以确保快速的反馈循环，并验证改进的结果和效果。追求快速有效的持续改进的组织通常会尝试与他们的服务消费者达成密切的合作，从而消除沟通，协作和决策制定方面的正式官僚障碍。
138
139
140 == **2.3  范围** ==
141
142 持续改进实践的范围包括：
143
144 ● 建立和培育持续改进的文化
145
146 ● 在整个组织中规划和维护持续改进的方式和方法
147
148 ● 在其整个生命周期中规划和推动持续改进
149
150 ● 评估改进的效果，包括输出，结果，效率，风险和成本
151
152 ● 生成并合并有关改进的实施和结果的反馈。
153
154 尽管仍与持续改进密切相关，但其中有几个活动的职责并未包括在持续改进的范围内。表2.1中列出了这些内容，以及可以找到它们的对应实践的参考。重要的是要记住，ITIL实践只是价值流的环境中使用的工具的集合；根据情况，必要时应将它们组合在一起。
155
156
157 表2.1 其他实践指南中描述的与持续改进实践相关的活动
158
159 (% style="width:451px" %)
160 |(% style="width:255px" %)活动|(% style="width:194px" %)实践指南
161 |(% style="width:255px" %)实施改进|(% style="width:194px" %)(((
162 项目管理
163
164 软件开发和管理
165
166 基础设施和平台管理
167
168 变更支持
169
170 部署管理
171
172 发布管理
173
174 服务验证和测试
175 )))
176 |(% style="width:255px" %)愿景的定义和战略目标|(% style="width:194px" %)战略管理
177 |(% style="width:255px" %)价值流中的缺陷分析|(% style="width:194px" %)业务分析
178 |(% style="width:255px" %)变更授权|(% style="width:194px" %)变更支持
179 |(% style="width:255px" %)提供测量当前状态和影响改进的工具|(% style="width:194px" %)测量和报告管理
180 |(% style="width:255px" %)大型改进项目的投资决策|(% style="width:194px" %)组合管理
181 |(% style="width:255px" %)根据预期的改进结果评估风险|(% style="width:194px" %)风险管理
182 |(% style="width:255px" %)与合作伙伴和供应商协商并同意联合改进项目|(% style="width:194px" %)(((
183 供应商管理
184
185 关系管理
186 )))
187 |(% style="width:255px" %)与服务消费者通报并达成共识|(% style="width:194px" %)服务级别管理
188 |(% style="width:255px" %)在服务提供者和用户之间提供接口，以提供反馈和改进的想法|(% style="width:194px" %)服务台
189 |(% style="width:255px" %)管理大型改进项目的人为因素|(% style="width:194px" %)组织变革管理
190
191 == **2.4 实践成功因素** ==
192
193 * **定义：实践成功因素**
194
195 是实践实现其目标的必备的复杂功能的组成部分。
196
197 实践成功因素（PSF）不仅仅是一个任务或一个活动，它包括服务管理四个维度的全部组成部分。不同的实践，PSF的活动和资源属性可能不同，但是它们一起确保实践是有效的。
198
199 持续改进实践包括以下PSF：
200
201 * 建立并维护有效的持续改进方法
202 * 确保整个组织的改进高效和有效的进行
203
204 === **2.4.1 建立并维护有效的持续改进方法** ===
205
206
207 **2.4.1.1 持续改进模型**
208
209 ITIL 持续改进模型提供了支持改进计划的高级指导。使用此模型会增加改进倡议成功的可能性。模型专注于客户价值，并将改进工作与组织愿景链接在一起。
210
211 该模型促进了改进的迭代方法。工作被分为可管理的几部分，分别定义了可以逐步实现的目标。使用模型时，重要的是要使用逻辑和常识。这些步骤不必以线性方式执行，并且可能有必要在各个点重新评估并返回到先前的步骤。
212
213 图片2.1显示了ITIL 持续改进模型。
214
215 (% style="text-align:center" %)
216 [[image:1613728811426-586.png]]
217
218
219 图2.1 ITIL持续改进模型
220
221
222 **2.4.1.2 复杂环境中的持续改进**
223
224 复杂环境中的大规模改进通常会带来重大改变。使用项目管理实践而不是BAU（日常业务）来定义一个改进计划应该被交付的范围是很重要的。
225
226 尽管ITIL 持续改进模型倡导的方法是通用的，并且适用于任何的改进对象，但对于组织而言，使方法及其措施适应其特定的环境仍很重要。例如，在非常明显的挑战性的项目中考虑典型时间框架非常重要。
227
228 在复杂环境中运行的组织（例如，商业IT服务提供商）可能需要追求长期和短期改进目标。这样的服务提供者应该建立一个灵活的持续改进框架，允许管理人员根据环境的变化在战术之间进行切换。在许多可度量的改进战术中，复杂的组织可能同时采用两种战术：
229
230 * 丰田·卡塔（Toyota Kata）是迈克·罗瑟（Mike Rother）所写的书，它讨论并推广了用于迭代改进的科学思维和行为技术的原理。Rother推出了改进型Kata和教练型Kata：这些例程旨在培养和习惯读者的有益思维方式，以促进其在控制范围内的改进。Rother的改进型Kata例程可帮助从业人员避免基于偏见和过去的经验进行假设。取而代之的是，从业人员审慎而刻意地思考挑战和机遇，从而采取迭代，度量和有效的行动。
231
232 * OODA（观察，判断，决策，行动）循环是一种可操作的决策技术框架，源于军事作战方法。OODA循环旨在非常短期内，并且可以连续运行，直到一个紧急危险被消除为止。
233 这种方法展示了敏捷可以战胜力量。第二个O“判断”是该技术的核心。它提出了一个相互关联的知识领域（传统，遗产，过往经验，新信息，分析和综合）的系统，变革推动者可以迅速利用这些知识领域来得出结论。这些结论反过来又有助于决策。
234
235 组织的设计可以使复杂环境中的变更推动者具有自治性，并可以合理地选择采取哪种路径进行其特定的持续改进旅程。考虑无法改进的危险，是内在的还是需要长期的管理努力，这一点至关重要。
236
237
238 **2.4.1.3 嵌入组织**
239
240 持续改进的文化：
241
242 ● 鼓励干系人提出建议并支持改进
243
244 ● 鼓励干系人表达他们的需求，需要和关注点并承担风险
245
246 ● 认识到完美主义通常是自欺欺人的，并阻碍了及时的改进
247
248 ● 认为持续改进是日常工作的一个活动
249
250 ● 庆祝成功的改进
251
252 ● 鼓励快速反馈循环
253
254 ● 促进从失败中学习，而不是责备的文化。
255
256 为了在组织中嵌入这些价值并使持续改进实践成功，至关重要的是：高层管理者需要致力于发展一个持续改进的文化。
257
258
259 **2.4.1.4 促进持续学习**
260
261 应该始终使用ITIL 持续改进模型的第6步（是否已经达成？）来获取从改进项目中学到的经验教训。
262
263 成功的改进项目应该回顾已经取得的积极成果，包括计划和未预料到的结果。如果改进的预期结果没有实现，或者以一种不同于计划的方式实现了，那么应该审查计划，并告知干系人失败的原因。这就需要对改进计划进行彻底的分析，记录并交流所汲取的经验教训。该文档应说明根据经验收集到的在下一次迭代中哪些可以以不同的方式完成的描述。
264
265 在可能的情况下，应在整个计划实施过程中保留经验教训日志。然后应审查此日志，生成经验教训报告。经验教训报告应用于以后的类似改进项目。无论当前迭代的结果如何，透明度对于将来的工作都很重要。
266
267 如果跳过步骤6，则改进可能会保持孤立状态，随着时间的流逝，独立的计划和进度可能会丢失。要获得对将来的改进计划的支持并在组织的文化中嵌入持续改进可能也很困难。重要的是要记住，应该创建并维护一个无指责的环境，在这个环境中，失败是安全的，并且主要关注点不是在指责人，而是在吸取教训。
268
269
270 === **2.4.2 确保整个组织的改进高效和有效的进行** ===
271
272
273 **2.4.2.1 抓住机会**
274
275 持续改进实践支持所有其他实践，产品和服务的改进。它是SVS的核心组件，并且必须嵌入所有其他服务管理实践中。识别出的机会数量可以用作度量指标来评估持续改进实践在组织中的建立情况。
276
277
278 **2.4.2.2 优先次序**
279
280 优先级准则必须透明并且公正地应用于所有改进计划。当优先级被质疑或无法明确评估时，应将该改进计划升级给治理委员会以进行进一步讨论。
281
282 尽管所有商定的成果都将有助于达到期望的状态，但某些成果将比其他成果更为关键。为了达到这些结果，必须按一定顺序实施改进。有些成果将需要大量的投资，而另一些成果可能需要最少的成本和工作量即可实现。可以优先考虑低成本，低工作量的改进计划，以实现组织的价值的快速增加。
283
284
285 **2.4.2.3 所有权**
286
287 特定服务，产品或实践价值流的所有者负责管理相关的连续改进计划。这些人应以身作则，展示和重申改进活动的价值。
288
289 持续改进实践所有者负责管理持续改进实践。此人确保组织的其他成员具备识别，评估，资助，执行和评估持续改进活动的成果所需的知识、技能和工具。
290
291
292 **2.4.2.4 资源**
293
294 相互协作，带来成就的方式需要信息、理解和信任。工作成果应有目共睹。应该避免隐藏的议程。信息应尽可能共享。当人们意识到正在发生的事情以及原因时，他们将更愿意提供帮助。
295
296 当改进活动发生在只有一小部分人了解细节的情况下时，各种假设和谣言就会占据上风。当员工们开始猜测发生了什么变化以及它们可能如何变化时，对变化的抵制可能会增加。
297
298 通过短暂的迭代来快速，明显地交付价值，可以增强用户从已完成的工作中获得的价值，这反过来又对交付它的团队产生了激励和奖励。
299
300
301 **2.4.2.5 资助改进计划**
302
303 任一个业务案例应该阐明采取服务或流程改进计划的原因。应尽可能提供数据以及与开展改进计划的成本和预期收益相关的证据，注意是：
304
305 ● SVS重新设计的活动通常更复杂，因此比最初预期的成本更高。
306
307 ● 组织变更影响通常被低估了。
308
309 ● 改变的实践通常需要改变能力和工具，从而进一步增加成本。
310
311 在开发某一业务案例时，重点不应局限于投资的潜在回报率，还应关注于改进计划将带给组织及其客户（价值投资）的业务价值。这是因为仅衡量投资回报率无法体现服务改进的真实价值。如果一个组织选择只关注于投资的潜在回报率，则许多潜在的好处将不会被披露或审查。这可能会导致有价值的计划被拒绝，或者错误地认为某些计划失败了。
312
313 毫无疑问，大多数业务高管都希望获得投资回报。重要的是要认识到，对改进的投资及其收益可能会根据组织的客户基础，规模和成熟度而有所不同。收益将跨越现有的组织边界，只有用户/客户和服务提供者经理才能在协作中获得真正的收益。因此，重点应该是与干系人合作，开发特定于业务和服务-提供者的指标，这些指标将业务价值指标与服务提供者的贡献联系起来。换句话说，改进是如何为组织增加价值的？
314
315 业务价值度量的示例是：
316
317 ● 上市时间
318
319 ● 客户保留
320
321 ● 市场份额。
322
323 服务提供者的贡献可以通过以下方式获取：
324
325 ● 获得敏捷性
326
327 ● 管理知识
328
329 ● 增强知识
330
331 ● 降低成本
332
333 ● 减少风险。
334
335 服务提供者应该首先定义每个改进将贡献的业务价值的类型。
336
337 如果一项投资经过精心构思，可靠交付了成果，则可以随着时间的流逝节省成本。因此，选择正确的投资并确保其交付很重要。为某改进计划引入一项业务案例时，重要的是要帮助主管人员了解该计划的业务价值。当业务的变化带来最大收益时，大多数管理人员过分强调价值的技术和工具。重要的是要解决人和实践将如何从“现状”状态变为“将来”状态。
338
339 在业务案例开发中，考虑由于不进行改进活动而丢失价值的情况也很重要。在某些情况下，不采取行动将严重影响服务消费者和服务提供者；改进的价值可能是保留的价值，而不是增加价值。
340
341 可以帮助证明投资回报率的一种优秀实践是为一个试点项目申请资金，这是一个范围有限的短期项目，但它代表了一个大规模的计划，短期项目的结果将有助于证明大规模的计划是可行的。
342
343 开发业务案例时，重要的是要确保明确定义了成功的标准及其度量（包括时间表）。
344
345
346 **2.4.2.6 评价**
347
348 当一个改进机会被确认时，应评估当前状态，以便可以在“我们从哪里开始”的背景中度量和理解所做出的任何改进。
349
350 定量指标可用于度量服务和方法的实际效能。定性指标可用于衡量策略，项目组合以及与其他方面的关系。
351
352
353 == **2.5 关键指标** ==
354
355 应该在每个实践所贡献的价值流的背景内评估ITIL实践的效果和绩效。与任何其他绩效工具一样，实践的绩效只能在该项目的背景内评估。但是，工具在设计和质量上可能会有很大差异，这些差异定义了根据其用途使用工具的潜力或能力。度量和报告实践中可以找到关于度量、关键指标（KPI）和其他技术的进一步指导。
356
357 理想情况下，持续改进是根据改进活动对SVS产生的价值的影响来度量的。这可能很难量化，因为：
358
359 ● SVS中的价值是系统内部复杂交互的结果。
360
361 ● 许多改进可能同时发生。可能无法区分一个改进的影响与另一个改进的影响。
362
363 ● 改进的实施与价值的实现之间通常会存在很大的延迟。
364
365 如果持续改进实践采用敏捷方法，则度量价值会更容易，因为在这种情况下，干系人会在每个迭代边界处确认价值的创建。当将产品所有权分配给客户或服务提供者组织中最接近客户的人员时，这种影响更加明显。
366
367 有效的度量标准将识别组织的哪些领域正在交付持续改进项目。将持续改进实践本身包括在“持续改进项目管理”度量标准中非常重要。
368
369 其他度量标准与持续改进的组织成就有关，旨在识别尚未交付的改进或试图交付太大改进的服务，产品或实践。这些指标有助于确定哪些团队或干系人需要持续改进经理的额外关注。
370
371 持续改进实践的关键指标已映射到其PSF。它们可以用作价值流的背景中的KPI，以评估实践对这些价值流的效果和效率的贡献。表2.2中给出了一些关键指标的示例。
372
373
374 表2.2 实践成功因素的关键指标实例
375
376 (% style="width:589px" %)
377 |(% style="width:225px" %)实践成功因素|(% style="width:361px" %)关键指标
378 |(% style="width:225px" %)建立和维护有效的持续改进方法|(% style="width:361px" %)(((
379 * 干系人对从改进项目中获得价值的能力的满意度
380 * 全组织范围内对持续改进方法的认识和采用
381 * 在整个组织中采用持续改进的文化
382 )))
383 |(% style="width:225px" %)确保组织内有效且高效的改进|(% style="width:361px" %)(((
384 * 投资回报率和投资价值
385 * 改进计划的成功的百分比
386 * 按计划的时间表，成本实现改进的百分比
387 * 负结果和已发生的风险超过计划的积极结果的百分比
388 * 持续改进生产力指标
389 )))
390
391 表2.2 实践成功因素的关键指标实例
392
393
394
395 ----
396
397 = **3  价值流和流程** =
398
399
400 == **3.1 价值流贡献** ==
401
402 持续改进实践的独特之处在于，它为其他所有实践和价值流的每个组件的价值都有贡献。重要的是要记住，价值流永远不会由单个实践形成。持续改进实践与其他实践相结合，可以为服务消费者提供高质量服务。持续改进实践不应孤立看待：它是所有其他实践的关键组成部分。
403
404 图3.1中显示了持续改进实践对服务价值链的贡献
405
406 (% style="text-align:center" %)
407 [[image:1613728933318-559.png]]
408
409 图3.1持续改进实践对价值链活动贡献的热力图
410
411
412 == **3.2 流程** ==
413
414 每个实践可能包括实现其目的所必需的一个或多个流程和活动。
415
416 * **定义：流程**
417
418 将一组相互关联或相互作用的输入转换为输出的活动。流程接受一个或多个定义的输入，并将它们转换为输出。流程定义这些活动的顺序及其依赖关系。
419
420 持续改进实践活动形成了一个流程：
421
422 * 持续改进项目的管理
423
424 持续改进实践还包括一组将实践嵌入到组织的活动。
425
426
427 === **3.2.1 持续改进项目的管理** ===
428
429 此流程包括表3.1中列出的活动，并将输入转换为输出。
430
431
432 表3.1持续改进项目管理的输入、活动和组织规划流程的输出
433
434 [[image:1642344803777-641.png]]
435
436 图3.2显示了该流程的工作流程图
437
438 (% style="text-align:center" %)
439 [[image:1613729010836-627.png]]
440
441
442 图3.2持续改进项目管理流程的工作流程图
443
444
445 表3.2提供了流程活动的示例
446
447 [[image:1642344848246-190.png]]
448
449 [[image:1642344866726-446.png]]
450
451 表3.2持续改进项目管理流程的活动
452
453
454 //注：反馈是持续改进实践的基本要素。建立正式和非正式的多个反馈渠道非常重要。并非所有反馈都会触发对改进计划的更改，但是必须尊重和评审所有反馈。由于反馈而做出的决策应转发给反馈发起者。如果反馈被忽略或未被确认，将来将更难获得反馈。应当将提供更多改进机会的反馈添加到CIR并确定优先级。//
455
456
457 === **3.2.2 将持续改进实践嵌入组织** ===
458
459 这套活动的关键成果是确保持续改进实践是一种组织规范。这涉及采用各种敏捷行为，概念和技术。
460
461
462 该流程包括表3.3中列出的活动，并将输入转换为输出
463
464 [[image:1642344919050-445.png]]
465
466 表3.3持续改进实践嵌入组织的输入、活动和输出
467
468
469 表3.4提供了活动的示例
470
471 [[image:1642344959794-856.png]]
472
473 表3.4 将持续改进实践嵌入组织流程的活动
474
475
476 改进的项目可能来自各种途径。SVS内的几乎任何人都可以识别SVS的任何组件潜在的改进点。服务提供者有时会制定标准，以限制可能提出改进建议的人，但最好是尽可能鼓励做出贡献。
477
478 各种记录系统可能是改进建议的来源，通过自动的接口或者人工审查的方式提取数据。这些系统包括问题记录、风险登记、和流程绩效记录。
479
480 在定义了产品负责人角色的组织中，改进建议应首先提交给相关产品的产品负责人。然后，产品负责人可以过滤和调整建议，并将他们添加到CIR中。
481
482
483
484 ----
485
486 = **4  组织和人员** =
487
488
489 == **4.1  角色、能力和责任** ==
490
491 实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定的每个实践的专家角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。记住，角色并非职位头衔。一个人可担任多个角色，一个角色也可以分配给多个人员。
492
493 流程和活动的背景中描述了角色。每个角色都具有基于表4.1所示的模型的能力类型。
494
495 (% style="width:543px" %)
496 |(% style="width:87px" %)能力编码|(% style="width:453px" %)能力类型（活动和技能）
497 |(% style="width:87px" %)L|(% style="width:453px" %)**领导Leader**决策、授权、监督其他活动，提供激励和动力，并评估结果
498 |(% style="width:87px" %)А|(% style="width:453px" %)**管理员Administrator**分配任务并确定优先级，保存记录，持续报告，并启动基本改进
499 |(% style="width:87px" %)C|(% style="width:453px" %)**协调者/沟通者Coordnator/Communicator**协调多方，维护利益相关者之间的沟通，并开展宣传活动
500 |(% style="width:87px" %)М|(% style="width:453px" %)**方法和技术专家Methodsandtechniquesexpert**设计和实施工作技巧、文件化步骤、流程咨询、工作分析和持续改进
501 |(% style="width:87px" %)Т|(% style="width:453px" %)**技术专家Technical expert** 提供技术（IT）专业知识并执行基于专业知识的任务
502
503 表4.1能力类型及编码
504
505
506 表4.2列出了持续改进实践活动中可能涉及的角色示例，以及相关的能力类型和特定技能。
507
508 (% style="width:844px" %)
509 |(% style="width:83px" %)能力编码|(% style="width:759px" %)说明
510 |(% style="width:83px" %)L|(% style="width:759px" %)**领导Leader** 这个角色侧重于领导力技能和权威，与此角色相关的活动包括决策、授权、监督其他活动、激励和鼓励、以及对成果的评估。
511 |(% style="width:83px" %)A|(% style="width:759px" %)**管理员Administrator**这个角色侧重于行政管理技能，与此角色相关的活动包括任务分配和确定优先级，记录，持续的汇报和基本的改进计划。
512 |(% style="width:83px" %)C|(% style="width:759px" %)**协调者/沟通者Coordnator/Communicator**这个角色侧重于沟通和协调的能力。与此角色相关的活动包括多方协调、干系人之间的沟通以及展开宣传活动。
513 |(% style="width:83px" %)M|(% style="width:759px" %)**方法和技术专家Methodsandtechniquesexpert**这个角色侧重于咨询技能和工作技能的专业知识。与此角色相关的活动包括工作技术的设计和实施、程序文档化、过程咨询、工作分析和持续改进。
514 |(% style="width:83px" %)T|(% style="width:759px" %)**技术专家Technical expert**这个角色侧重于提供技术（IT）专业知识和基于专业知识的任务。
515
516 表4.2可能参与持续改进实践活动中的角色的例子，以及相关的能力类型和技能
517
518
519 [[image:1642345148994-403.png]]
520
521 [[image:1642345169446-309.png]]
522
523 表4.3续改进实践活动的角色示例
524
525
526 == **4.2  组织架构和团队** ==
527
528
529 === **4.2.1 持续改进团队** ===
530
531 服务提供者不太可能维护专门的致力于持续改进实践的团队。团队应负责改进他们自己，如何与其他内部团队互动，以及如何与外部供应商、合作伙伴和客户互动。
532
533 然而，服务提供者可以引入持续改进协调员或者变更记录（CIR）管理员角色。当实施持续改进框架时，服务提供者可能会将这个角色交给有领导技能的人。根据组织的规模和嵌入持续改进活动的策略，这可能是一个全职职位。随着整个组织团队的熟练程度的提高，服务提供者可能会淘汰角色或使其成为兼职人员。
534
535
536 === **4.2.2 持续改进团队的构建** ===
537
538 团队的一些属性或方面有助于增强改进的能力，包括多元性和能够安全失败的环境。
539
540
541 **4.2.2.1 多元性**
542
543 关于多元性对团队绩效的影响研究尚无定论。一些研究表明，社会上同质的团队与社会多元文化的团队之间存在显着差异。其他研究未能重现这些结果。一些研究表明，当经验丰富的专家与经验较少的成员组成的团队，将会带来好处。但是，很难说服其他成员为团队配备缺乏经验的成员。缺乏关于多元性变化对团队的影响的信息。
544
545 直接的经济利益只是影响团队人员配备的一个方面。其他因素包括：
546
547 ● 组织对社会的道德责任
548
549 ● 员工的专业性发展
550
551 ● 团队的长期稳定性和持久性
552
553 ● 避免群体思维和类似的组织偏见的价值。
554
555 根据人员的类别和类型进行思考可能会阻碍建立一个有凝聚力和表现良好的团队。没有选择“正确”人员的公式。相反，团队经理应该专注于培养信任和尊重并认可独特的个人贡献的技术。
556
557
558 **4.2.2.2可以安全的失败的环境**
559
560 增量的，迭代的改进技术依赖于团队进行实验的意愿。它们使改进经常会在小范围内失败，从而限制了大规模失败的可能性，减少了失败的潜在影响，并提高了团队从失败中恢复的难度。
561
562 团队应该将失败视为学习的机会：必须避免责备的文化。从小的失败中吸取教训，提高整体能力，比从不吸取教训要好。从成功的实验中获得好处，比从一开始就没有尝试过要好。
563
564 因此，团队需要无责备的环境，在该环境中即使失败也是安全的。这些环境促进了通常所说的“心理安全”，并且依赖团队成员和管理者之间的尊重和信任。
565
566
567
568 ----
569
570 = **5  信息和技术** =
571
572
573 == **5.1 信息交换** ==
574
575
576 === **5.1.1 信息对象和输入输出** ===
577
578 有关改进的建议通常含糊且无法衡量。例如，经理可能说服务必须更快地交付。这样的表述既无激励，也不能付诸行动。改进建议的结构应符合以下要求：
579
580 ● 了解应该解决什么问题
581
582 ● 了解改进的潜在价值
583
584 ● 知道工作的一般范围
585
586 ● 认识其他干系人
587
588 ● 了解关键约束条件
589
590 ● 可以衡量改进是否成功
591
592
593 === **5.1.2 持续改进登记表** ===
594
595 CIR是用于跟踪和管理持续改进的改进记录的完整列表。在敏捷方法中，CIR称为产品待办项。
596
597 CIR可以是服务管理系统的一个集成部分，也可以是改进记录的独立数据库。
598
599
600 === **5.1.3 改进记录** ===
601
602 每个改进记录中包含的细节程度取决于它捕获的需求规格说明的程度。
603
604
605 表3.4中显示了改进点记录的数据字段的示例，并且实际上CIR的结构也是如此。
606
607 (% style="width:489px" %)
608 |(% style="width:158px" %)字段|(% style="width:329px" %)描述
609 |(% style="width:158px" %)改进标识符|(% style="width:329px" %)在整个服务提供者组织中有效的唯一标识符
610 |(% style="width:158px" %)改进名称|(% style="width:329px" %)改进的简短描述性标题
611 |(% style="width:158px" %)改进请求者或来源|(% style="width:329px" %)这可以是任何干系人，包括外部客户或供应商
612 |(% style="width:158px" %)受影响的配置项|(% style="width:329px" %)服务、生产或实践有待改进
613 |(% style="width:158px" %)改进负责人|(% style="width:329px" %)负责改进和计划实施的人员，改进计划的责任不应在团队之间共享
614 |(% style="width:158px" %)紧急度|(% style="width:329px" %)说明改进的效果将在什么时间范围内产生开始被认识，可以用简单的高中低来表示紧急度
615 |(% style="width:158px" %)状态|(% style="width:329px" %)标识改进计划的当前位置的术语
616 |(% style="width:158px" %)成本|(% style="width:329px" %)可确定待办事项的优先级和比较计划的指示性值。尽管成本在登记和计划之后尚不明确，但应包含直接和间接的投入，时间和资源，可简单用高中低来表示。
617 |(% style="width:158px" %)价值或利益声明|(% style="width:329px" %)从服务提供者和使用者的角度定义最终输出
618 |(% style="width:158px" %)改进计划|(% style="width:329px" %)(((
619 对解决问题的方法的高级描述
620
621 采用敏捷工作方式的组织有时会为计划添加已定义作为验收标准
622
623 计划可以包括实施中涉及的团队和实践。
624 )))
625
626 表3.4 改进记录的示例数据字段
627
628
629 == **5.2 自动化与工具** ==
630
631 尽管人工智能取得了巨大的进步，但持续改进本质上是人类的手动实践。今天的持续改进实践中几乎没有可以自动化的，但是有很多工具可以支持持续改进的各个阶段。这些总结在表5.1中。
632
633 [[image:1642345264550-212.png]]
634
635 表5.1持续改进活动自动化解决方案
636
637
638
639 ----
640
641 = **6  合作伙伴和供应商** =
642
643 仅使用组织自己的资源提供的服务很少。大多数（如果不是全部）依赖于其他服务，这些服务通常由组织之外的第三方提供（请参阅ITIL®Foundation的2.4节：服务关系的ITIL 4版中的模型）。服务设计，架构管理和供应商管理的ITIL实践中介绍了由支持服务引入的关系和依赖性。
644
645 合作伙伴和供应商必须包含在持续改进计划中。应鼓励合作伙伴向CIR提交建议。同样，服务消费者组织应该能够提出对服务提供商的改进建议。开放的沟通和学习意愿有助于构建共同价值共创的关系。
646
647 在敏捷环境中，客户和供应商需要合作以实现最佳结果。组织的目标是快速，有效的持续改进。他们通常会试图与合作伙伴和供应商达成紧密的合作协议，消除沟通，协作和决策制定方面的正式官僚障碍（有关更多信息，请参见供应商管理实践指南）。
648
649
650 == **6.1  供应链中的持续改进** ==
651
652 所有改进陈述都包含要解决的问题的描述。但是，某些问题没有明显的解决方案。
653
654 例如，如果供应商提供低质量货品或服务，则客户有以下几种选择：
655
656 ● 接受货品或服务，并在该级别的质量上与他们合作
657
658 ● 变更供应商
659
660 ● 构建服务提供者的价值流，以检测和纠正或消除缺陷
661
662 ● 与货品的供应商合作，改进货品的质量或提供的服务进行协作，以及消费者如何使用它们。
663
664 接受较差的质量产品或服务会放弃持续改进的原则。更换供应商可能会提高质量，但这并不总是一种选择。货品的地理位置，价格或可用性和服务等许多因素会限制供应商的选择。在现有价值流中添加处理质量问题的步骤可能会导致价值服务更高，但是代价是敏捷性较低，交货时间更长且成本更高。
665
666 供应商和消费者可以通过以下方式合作改进供应链：
667
668 ● 识别不必要的且可以删除的消费者要求
669
670 ● 调整产品规格
671
672 ● 分离服务提供者的价值流，然后将某些活动重新分配给供应商（或消费者）
673
674 ● 调整交货节奏和批次大小
675
676
677 == **6.2  持续改进中合作伙伴和供应商的作用** ==
678
679 除了识别和实施改进项目，供应商和合作伙伴还可以提供支持持续改进实践的专业服务。表6.1给出了这些服务的示例。
680
681 (% style="width:461px" %)
682 |(% style="width:204px" %)ITIL 持续改进模型步骤|(% style="width:255px" %)服务
683 |(% style="width:204px" %)1.我们现在处于什么位置|(% style="width:255px" %)独立评估当前状态
684 |(% style="width:204px" %)2.我们要达到什么状态|(% style="width:255px" %)分析潜在的改进并提供有关最佳实践的建议
685 |(% style="width:204px" %)3.我们如何达成|(% style="width:255px" %)辅导和规划服务
686 |(% style="width:204px" %)4.采取行动|(% style="width:255px" %)承包专业技能
687 |(% style="width:204px" %)5.是否达成|(% style="width:255px" %)独立评估新状态
688 |(% style="width:204px" %)6.保持发展势头|(% style="width:255px" %)参与双方的定期讨论和规划的改进
689
690 表6.1 持续改进中供应商和合作伙伴的作用
691
692
693
694 ----
695
696 = **7  重要提醒** =
697
698 实践指南的大部分内容应视为组织在建立和培养自己的实践时可能考虑领域的建议。实践指南是组织可能考虑的事情目录，而不是答案列表。使用ITIL实践指南的内容时，组织应始终遵循ITIL指导原则：
699
700 * 聚焦价值
701 * 从你所处的地方开始
702 * 基于反馈迭代推进
703 * 协作和提升可视化程度
704 * 通盘思考和工作
705 * 保持简单实用
706 * 优化和自动化
707
708 关于指导原则及其应用的更多信息，请参见ITIL Foundation：ITIL 4出版物第4.3节。
709
710
711
712 ----
713
714 = **8  致谢** =
715
716 AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：
717
718
719 == **8.1  作者** ==
720
721 RomanJouravlev, Laura Little, Kirstie Magowan, Konstantin Naryzhny,.
722
723
724 == **8.2  审稿人** ==
725
726 Xavier Idrovo, Vernon Lloyd.
727
728
729 )))
深圳市艾拓先锋企业管理咨询有限公司