由 superadmin 于 2024/04/03, 17:34 最后修改
从版本< 16.5 >
由superadmin编辑
在2024/03/07, 19:39上
到版本
由superadmin编辑
在2024/04/03, 17:34上
<
修改评论 该版本没有评论

Summary

Details

Icon Page properties
Content
... ... @@ -3,15 +3,18 @@
3 3  
4 4  [[阅读下一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E6%8C%87%E5%AF%BC%E3%80%81%E8%AE%A1%E5%88%92%E5%92%8C%E6%94%B9%E8%BF%9B%E3%80%8BDPI/%E7%AC%AC6%E7%AB%A0%20%E6%B2%9F%E9%80%9A%E5%92%8C%E7%BB%84%E7%BB%87%E5%8F%98%E9%9D%A9%E7%AE%A1%E7%90%86/]]  [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E6%8C%87%E5%AF%BC%E3%80%81%E8%AE%A1%E5%88%92%E5%92%8C%E6%94%B9%E8%BF%9B%E3%80%8BDPI/%E7%AC%AC4%E7%AB%A0%20%E6%B5%8B%E9%87%8F%E5%92%8C%E6%8A%A5%E5%91%8A/]]
5 5  
6 -{{box cssClass="floatinginfobox" title="**Contents**"}}
6 +{{box cssClass="floatinginfobox" title="
7 +
8 +**Contents**"}}
7 7  {{toc/}}
8 8  {{/box}}
9 9  
10 -= 第5章 持续改进 =
12 += **第5章 持续改进** =
11 11  
12 12  
13 13  == 5.1 创建持续改进文化 ==
14 14  
17 +
15 15  任何改进都是变更，必须仔细管理变更。重要的是要考虑变更如何影响组织的文化。
16 16  
17 17  与将承诺持续改进嵌入组织的文化中一样，实施不同改进不会具有相同的影响。在几乎每种情况下，具有强大的持续改进文化的组织也将具有强大的治理能力，从而可以分配资源并提供管理和成功改进倡议所需的领导能力。计划和交付改进的方式也应遵守持续改进。
... ... @@ -24,19 +24,28 @@
24 24  [[image:1639215024707-577.png]]
25 25  
26 26  
30 +(% class="wikigeneratedid" %)
31 +== ==
32 +
27 27  == 5.2 服务价值链和实践的持续改进 ==
28 28  
35 +
29 29  服务价值链可以看作是一组构建块，可以按任何顺序组合以创建价值流。改进服务价值链可能需要对构建基块进行一些小的改进，从而将其价值增加到一个或多个价值流。但是，重要的是要考虑改进对整个价值链和关联的价值流的影响。价值流图对于理解所涉及的相互依赖性很有用。
30 30  
31 31  了解如何使用改进的实践涉及了解它们如何对服务价值链做出的贡献。如果不能始终如一地实现实践的目的，或者如果实践不是有效的或有用的，则其贡献的价值链活动可能会受到影响。
32 32  
33 33  
41 +
34 34  (% style="text-align:center" %)
35 35  [[image:1639215103257-893.png]]
36 36  
37 37  
46 +(% class="wikigeneratedid" %)
47 +== ==
48 +
38 38  == 5.3 组织中的持续改进 ==
39 39  
51 +
40 40  组织不是静态实体。遇到一个目的时，重要的是为改进和计划寻找另一种到达那里的机会。在整个组织中都是如此：与运行的实践一样，改善领导实践的机会也很多。
41 41  
42 42  持续改进是每个人的责任。以任何方式为提供服务做出贡献的每个人都必须不断寻找改进的机会，因为改进的范围是整个SVS。
... ... @@ -56,8 +56,12 @@
56 56  
57 57  
58 58  
71 +(% class="wikigeneratedid" %)
72 +== ==
73 +
59 59  == 5.4 持续改进模型 ==
60 60  
76 +
61 61  在ITIL Foundation中引入并在图片5.1中显示的ITIL 持续改进模型是支持改进倡议的高级指南。使用此模型时，改进倡议更可能成功。模型专注于服务消费者价值，将改进的工作与组织愿景联系起来，并促进了改进的迭代方法。
62 62  
63 63  每个组织应该使持续改进模型适应其自己的文化和目标。模型设计灵活、简单，可以在敏捷环境和传统瀑布中正常工作文化。它可以作为任何改进的辅助工具，但最好应用于特定的改进计划；它不是为整个组织定义一个改进策略而设计的。
... ... @@ -71,8 +71,12 @@
71 71  由于改进旅程本质上不一定是线性的，因此持续改进模型并非一定要严格。它是指导那些从事持续改进的人员并帮助他们避免浪费性错误的框架。变更推动者并不总是先完成一个步骤，然后再进行下一个步骤，因此他们可以并且应该在必要时重新访问模型的较早步骤。
72 72  
73 73  
90 +(% class="wikigeneratedid" %)
91 +=== ===
92 +
74 74  === 5.4.1 步骤1：愿景是什么 ===
75 75  
95 +
76 76  在此步骤中，将各个改进倡议与组织的目标对齐，这些目标是从其愿景和使命派生而来的，并且为改进计划本身定义了一个愿景。
77 77  
78 78  定期重新评估计划的进度并将其与组织的愿景和策略进行比较非常重要。一项似乎支持愿景处于初期阶段的计划可能已经转变为不再有效或不合适的计划。
... ... @@ -92,8 +92,12 @@
92 92  * 同意下一步的步骤以验证范围和计划改进倡议的详细信息。
93 93  )))
94 94  
115 +(% class="wikigeneratedid" %)
116 +==== ====
117 +
95 95  ==== 5.4.1.1 计划改进的愿景 ====
96 96  
120 +
97 97  当规划改进倡议时，变更推动者通常会考虑潜在的改进，否则，他们希望针对他们知道存在改进机会的广阔领域。他们的想法可能来自持续改进登记册、会议记录、管理指令、开发日志、问题管理记录或其他来源。
98 98  
99 99  如果变更推动者从目标改进开始，那么将其与组织的愿景对齐以确认该计划的有效性就非常重要。但是，如果他们希望瞄准广阔的区域，则变更推动者应为他们的控制下的区域设想一个与组织愿景一致的未来状态的改进，并确定为实现该未来状态而必须进行的变更。
... ... @@ -109,8 +109,12 @@
109 109  [[image:1639215264724-198.png]]
110 110  
111 111  
136 +(% class="wikigeneratedid" %)
137 +=== ===
138 +
112 112  === 5.4.2 步骤2：我们现在在哪里？ ===
113 113  
141 +
114 114  如果不了解当前状态，则几乎不可能定义要执行什么需求才能转换到未来状态。记录当前状态涉及建立当前状态指标度量，以便可以客观地证明向新状态的进度。
115 115  
116 116  
... ... @@ -127,8 +127,12 @@
127 127  [[image:1639215318282-759.png]]
128 128  
129 129  
158 +(% class="wikigeneratedid" %)
159 +==== ====
160 +
130 130  ==== 5.4.2.1 评估 ====
131 131  
163 +
132 132  评估用于测量、分析和理解实践、流程、服务、技术和人员的行为和性能或绩效。一个好的评估不仅可以发现差距和问题，还可以做更多的事情。它将识别出做得好的方面，并展示如何利用成功。对所有服务管理四维模型进行评估至关重要。组织中的任何人都可以评估其控制范围中某个区域的当前状态。
133 133  
134 134  所有利益相关者都需要对评估的目标达成共识，否则很难获得符合需求的可用结果。评估的重点和工作深度应以改进的大小为准，但是由于即使一个看似很小的计划也可能拥有更广泛的影响，所以评估的这一步绝不可忽略。
... ... @@ -136,8 +136,12 @@
136 136  变更推动者必须根据每个评估的目标和对每种方法约束的理解，为它们选择适当的方法。在许多情况下，在改进旅途中使用多种评估方法将是适当的。选择评估方法时，重要的是要考虑必须收集哪些信息，从谁那里收集信息以及所需的准确性和详细程度。选择的方法应与那些要求相吻合。
137 137  
138 138  
171 +(% class="wikigeneratedid" %)
172 +=== ===
173 +
139 139  === 5.4.3 步骤3：我们想去哪里？ ===
140 140  
176 +
141 141  当前状态是改进旅程的起点。下一步是展望未来，并确定下一步的发展方向。此步骤不是要定义绝对的、完美的最终状态。改进不是有限的旅程。此步骤是关于定义下一个状态，即持续改进旅程中的下一个逻辑阶段。明智的做法是采取小的迭代步骤。如果改进的目标距离太远或似乎无法实现，则实现变更会变得更加困难。
142 142  
143 143  
... ... @@ -156,15 +156,23 @@
156 156  * 利益相关者提出的协议，以提出建议的改进和任何相关的优先级。
157 157  )))
158 158  
195 +(% class="wikigeneratedid" %)
196 +==== ====
197 +
159 159  ==== 5.4.3.1 确定成果的优先级和范围 ====
160 160  
200 +
161 161  在评估了当前状态并定义了所需的结果之后，需要对结果进行优先级划分和确定范围。确定的结果都应有助于实现所需的状态，但是某些结果将比其他结果更为关键，并且按特定顺序实施更改可能会促进某些成果。有些成果需要采用不同的方法来实现，有些成果则需要大量投资，而另一些成果只需花费很少的精力就可以实现。需要用可衡量的术语定义所需的结果。
162 162  
163 163  改进的成果可以在很多方面带来积极的效果，包括通过降低成本或风险、通过法规改进合规性来实现。在确定这些结果的优先级时，请考虑它们可能对使组织更接近实现其愿景的影响。在背景中具有更大积极影响的结果应优先于其他结果。
164 164  
165 165  
206 +(% class="wikigeneratedid" %)
207 +==== ====
208 +
166 166  ==== 5.4.3.2 制作商业论证并到达协议 ====
167 167  
211 +
168 168  进行改进可能不仅需要变更推动者，而且还需要负责授权所需预算和时间分配的人员使用协议。可能有必要制作一个简单的商业论证来概述提案并获得批准。
169 169  
170 170  (% style="text-align:center" %)
... ... @@ -171,8 +171,12 @@
171 171  [[image:1639215430903-598.png]]
172 172  
173 173  
218 +(% class="wikigeneratedid" %)
219 +=== ===
220 +
174 174  === 5.4.4 步骤4：我们如何到达那里？ ===
175 175  
223 +
176 176  一旦定义了当前状态和所需状态，下一步就是创建一个性能或绩效计划。有效的性能或绩效计划应该回答几个问题，包括：
177 177  
178 178  ● 是否完成任何变更都需要按照特定顺序？
... ... @@ -193,8 +193,12 @@
193 193  * 了解改进的性质以及用于达到预期结果的最有效方法。
194 194  )))
195 195  
244 +(% class="wikigeneratedid" %)
245 +==== ====
246 +
196 196  ==== 5.4.4.1 创建改进计划 ====
197 197  
249 +
198 198  根据改进的大小，组织中既定的方法或要求可能会决定规划的执行方式和改进的交付方式。变更推动者应确保已建立的策略得到遵守，并应利用现有的制品（例如工具和模板）（如果存在）。计划的设计应高效且轻巧，同时确保利益相关者具有可视化和控制的要求级别，并确保考虑到任何法规要求。
199 199  
200 200  无论使用哪种工作方法，改进计划都应考虑到以前的持续改进工作模型的步骤。相关的愿景、评估结果、期望的目标、商业论证的内容以及预期的结果都是对改进计划有价值的输入的示例。
... ... @@ -216,8 +216,12 @@
216 216  通过在改进计划中包括一个简单实用的指标度量方案，利用步骤3中完成的工作也很重要。如果组织的标准项目管理方法包括必需的指标度量，则必须容纳这些指标度量。但是对于改进的成功更重要的是，可以定义明确的指标度量，这些指标度量可以用作项目的目标，也可以用作改进实施后的成功测量。
217 217  
218 218  
271 +(% class="wikigeneratedid" %)
272 +==== ====
273 +
219 219  ==== 5.4.4.2 沟通并同意计划 ====
220 220  
276 +
221 221  一旦设计了计划，就可以将其呈现给利益相关者，这有助于设定期望。根据改进的性质，可能决定在变更推动者的控制范围中进行处理。但是，如果需要批准，则在计划获批后，即可开始改进的工作。利益干系人沟通计划可以帮助设计并跟踪成功准备和交付演示文稿所需的沟通活动。与仅需要一般认知的利益相关者相比，那些有权批准计划的利益相关者可能需要不同的详细程度。
222 222  
223 223  
... ... @@ -225,8 +225,12 @@
225 225  [[image:1639215520586-581.png]]
226 226  
227 227  
284 +(% class="wikigeneratedid" %)
285 +=== ===
286 +
228 228  === 5.4.5 步骤5：采取行动 ===
229 229  
289 +
230 230  在此步骤中，计划变得栩栩如生，并且会完成工作；但是，如果性能或绩效无法产生期望的结果，则可能需要修改计划。还必须定期验证计划所基于的假设，并积极管理已识别的风险和利益相关者。
231 231  
232 232  如果在步骤4中选择了安全的失败实验方法，则会进行实验以为进一步的规划提供反馈。在某些情况下，这可能不仅导致对计划进行审查，而且对目标状态进行审查。
... ... @@ -244,6 +244,9 @@
244 244  [[image:1639215570387-297.png]]
245 245  
246 246  
307 +(% class="wikigeneratedid" %)
308 +=== ===
309 +
247 247  === 5.4.6 步骤6：我们到达了吗 ===
248 248  
249 249  
... ... @@ -257,8 +257,10 @@
257 257  第6步的目的是使用真实证据并利用数据分析来确认是否已达到所需的将来状态，并通过变更确认新的状况和价值。经常会假定已实现一项计划的预期收益，并且组织转到下一个计划。准确了解已实现和尚未实现的内容对于将来的规划至关重要。
258 258  
259 259  
323 +
260 260  ==== 5.4.6.1 进行改进评审 ====
261 261  
326 +
262 262  对于改进计划的每个迭代，都需要检查并确认进度和交付的价值。这是通过改进评审（有时称为利益实现评审）完成的。
263 263  
264 264  
... ... @@ -278,8 +278,12 @@
278 278  [[image:1639215688476-711.png]]
279 279  
280 280  
346 +(% class="wikigeneratedid" %)
347 +=== ===
348 +
281 281  === 5.4.7 步骤7：我们如何保持势头？ ===
282 282  
351 +
283 283  改进必须保持连续性，以与组织的需求保持同步，并确保用于创建和交付它们的服务和SVS继续提供价值。目的应该是创建一个文化，其中持续改进是正常工作的一部分。当持续改进嵌入组织中时，各个级别的人们都会不断地寻求改进，以帮助其朝着愿景的方向发展，而且未来需要进行大规模转型的风险也得到了缓解。
284 284  
285 285  如果改进交付了预期的价值，则该计划的重点应转移到成功营销和加强引入的任何新方法上。这确保了进度不会丢失，并为下一次改进提供了支持和动力。
... ... @@ -294,15 +294,20 @@
294 294  * 有关其他改进倡议或迭代的建议列表
295 295  * 记录下来的经验教训分析，记录了有关如何在将来更好地实施改进的想法。
296 296  
366 +
367 +
297 297  ==== 5.4.7.1 识别额外的改进机会 ====
298 298  
370 +
299 299  即使实现了所有改进计划的目标，也总是有更多范围可以解决改进问题。变更推动者将在进行的改进计划中仔细管理范围，以保持关注焦点和改进成功的可能性。这通常意味着在步骤5中出现的改进想法无法集成到变更的该迭代中。这些想法应记录在案，并考虑在将来的性能或绩效中使用。此外，通常在持续改进登记册中，应记录在步骤1、2和3中产生的想法，以备将来可能使用的性能或绩效。
300 300  
301 301  在这最后一步中，变更推动者和其他利益相关者应就有关下一步和改进优先级的问题汇编其建议。他们对当前计划的参与将为他们提供宝贵的观点，使他们了解未来的改进构想将构建在当前应用上，以及可以很容易地在新的当前状态下实施。
302 302  
303 303  
376 +
304 304  ==== 5.4.7.2 确认和评估经验教训 ====
305 305  
379 +
306 306  与其他所有实践一样，必须对持续改进实践进行检查并接受持续改进的约束。通过分析变更计划的成功或失效，可以看到可以改进的部分以及特别成功的部分。教训的结果可应用于将来的改进活动。
307 307  
308 308  
... ... @@ -317,8 +317,18 @@
317 317  (% style="text-align:center" %)
318 318  [[image:1639215795722-566.png]]
319 319  
394 +(% class="wikigeneratedid" %)
395 +== ==
396 +
397 +(% class="wikigeneratedid" %)
398 +== ==
399 +
400 +(% class="wikigeneratedid" %)
401 +== ==
402 +
320 320  == 5.5 在持续改进中使用测量和报告 ==
321 321  
405 +
322 322  测量和报告为持续改进的各个方面做出了贡献。表5.1给出了实践在持续改进模型上做出的突出贡献的示例。
323 323  
324 324  
... ... @@ -359,8 +359,18 @@
359 359  监视并报告新行为，以确保改进不会随着时间的流逝而减弱。
360 360  )))
361 361  
446 +(% class="wikigeneratedid" %)
447 +== ==
448 +
449 +(% class="wikigeneratedid" %)
450 +== ==
451 +
452 +(% class="wikigeneratedid" %)
453 +== ==
454 +
362 362  == 5.6 总结 ==
363 363  
457 +
364 364  通过在整个组织和SVS的每个元素中嵌入持续改进的承诺，组织可以更好地对更改做出响应，并增强与利益相关者共同创建价值的能力。
365 365  
366 366  无论组织的成熟度如何，持续改进都应成为每个SVS的重要组成部分。所有服务管理四维模型都受持续改进的约束。技术在不断变化，提供服务的方式需求可以跟上这些变化。强大的持续改进实践（自身会不断改进）是维护和增加价值的关键，而服务供应商为其服务消费者和其他利益相关者做出了贡献。
深圳市艾拓先锋企业管理咨询有限公司