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

导航

需要帮助？

如果您需要有关XWiki的帮助，可以联系：

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