文档更改第5章 持续改进
由 superadmin 于 2024/04/03, 17:34 最后修改
修改评论
上传新附件1639215795722-566.png
Summary
Details
- Page properties
-
- 标题
-
... ... @@ -1,1 +1,0 @@ 1 -第5章 持续改进 - 父
-
... ... @@ -1,1 +1,0 @@ 1 -ITIL 4《指导、计划和改进》DPI.WebHome - Content
-
... ... @@ -1,367 +1,0 @@ 1 -= 第5章 持续改进 = 2 - 3 - 4 -== 5.1 创建持续改进文化 == 5 - 6 -任何改进都是变更,必须仔细管理变更。重要的是要考虑变更如何影响组织的文化。 7 - 8 -与将承诺持续改进嵌入组织的文化中一样,实施不同改进不会具有相同的影响。在几乎每种情况下,具有强大的持续改进文化的组织也将具有强大的治理能力,从而可以分配资源并提供管理和成功改进倡议所需的领导能力。计划和交付改进的方式也应遵守持续改进。 9 - 10 -成功的持续改进文化是平衡的。必须保持动力,但重要的是不要同时采取更多的主动行动。稳定工作而不会使组织进行多次大规模改进,可以保持兴趣和兴奋,而不会造成不必要的压力或反弹。 11 - 12 -大多数员工都认为正式的改进倡议超出了他们的常规职责范围。专门雇用员工来促进持续改进可以为其他团队提供支持,使他们更容易参与并受到尊重。反过来,这将增强持续改进的重要性,并有助于将其嵌入文化。 13 - 14 -(% style="text-align:center" %) 15 -[[image:1639215024707-577.png]] 16 - 17 - 18 -== 5.2 服务价值链和实践的持续改进 == 19 - 20 -服务价值链可以看作是一组构建块,可以按任何顺序组合以创建价值流。改进服务价值链可能需要对构建基块进行一些小的改进,从而将其价值增加到一个或多个价值流。但是,重要的是要考虑改进对整个价值链和关联的价值流的影响。价值流图对于理解所涉及的相互依赖性很有用。 21 - 22 -了解如何使用改进的实践涉及了解它们如何对服务价值链做出的贡献。如果不能始终如一地实现实践的目的,或者如果实践不是有效的或有用的,则其贡献的价值链活动可能会受到影响。 23 - 24 - 25 -(% style="text-align:center" %) 26 -[[image:1639215103257-893.png]] 27 - 28 - 29 -== 5.3 组织中的持续改进 == 30 - 31 -组织不是静态实体。遇到一个目的时,重要的是为改进和计划寻找另一种到达那里的机会。在整个组织中都是如此:与运行的实践一样,改善领导实践的机会也很多。 32 - 33 -持续改进是每个人的责任。以任何方式为提供服务做出贡献的每个人都必须不断寻找改进的机会,因为改进的范围是整个SVS。 34 - 35 - 36 -|((( 37 -**关键信息** 38 - 39 -**持续改进实践**通过持续的产品、服务、实践改进与产品和服务的管理,使组织的实践和服务与不断变化的业务需求保持一致。 40 -))) 41 - 42 -从个人到团队甚至整个组织都可以在任何级别上进行改进。例如,服务台操作员可能会看到机会改进用来收集来自客户和用户信息的脚本。在这种情况下,操作员应与他们的经理一起使用改进和服务台实践。但是,参与改进活动的个人和团队必须了解将取得什么样的成功,并帮助定义并同意要实现成果所必须达到的目标。 43 - 44 - 45 -(% style="text-align:center" %) 46 -[[image:1639215144770-786.png]] 47 - 48 - 49 - 50 -== 5.4 持续改进模型 == 51 - 52 -在ITIL Foundation中引入并在图片5.1中显示的ITIL 持续改进模型是支持改进倡议的高级指南。使用此模型时,改进倡议更可能成功。模型专注于服务消费者价值,将改进的工作与组织愿景联系起来,并促进了改进的迭代方法。 53 - 54 -每个组织应该使持续改进模型适应其自己的文化和目标。模型设计灵活、简单,可以在敏捷环境和传统瀑布中正常工作文化。它可以作为任何改进的辅助工具,但最好应用于特定的改进计划;它不是为整个组织定义一个改进策略而设计的。 55 - 56 -(% style="text-align:center" %) 57 -[[image:1639215190117-306.png]] 58 - 59 -图片5.1 ITIL 持续改进模型 60 - 61 - 62 -由于改进旅程本质上不一定是线性的,因此持续改进模型并非一定要严格。它是指导那些从事持续改进的人员并帮助他们避免浪费性错误的框架。变更推动者并不总是先完成一个步骤,然后再进行下一个步骤,因此他们可以并且应该在必要时重新访问模型的较早步骤。 63 - 64 - 65 -=== 5.4.1 步骤1:愿景是什么 === 66 - 67 -在此步骤中,将各个改进倡议与组织的目标对齐,这些目标是从其愿景和使命派生而来的,并且为改进计划本身定义了一个愿景。 68 - 69 -定期重新评估计划的进度并将其与组织的愿景和策略进行比较非常重要。一项似乎支持愿景处于初期阶段的计划可能已经转变为不再有效或不合适的计划。 70 - 71 - 72 -|((( 73 -**关键信息** 74 - 75 -在步骤1结束时,变更推动者应: 76 - 77 -* 了解组织的愿景、使命和目标如何转换为特定的业务单元、部门、团队和/或充当变更推动者的个人 78 -* 对计划中的改进或改进区域具有高级愿景,包括: 79 -** 改进工作的公认高层指导 80 -** 变更推动者的控制范围的背景和改进愿景中对计划的改进计划的描述 81 -** 对相关利益相关者以及他们如何参与计划有清晰的了解 82 -** 计划的改进预期价值 83 -* 同意下一步的步骤以验证范围和计划改进倡议的详细信息。 84 -))) 85 - 86 - 87 -==== 5.4.1.1 计划改进的愿景 ==== 88 - 89 -当规划改进倡议时,变更推动者通常会考虑潜在的改进,否则,他们希望针对他们知道存在改进机会的广阔领域。他们的想法可能来自持续改进登记册、会议记录、管理指令、开发日志、问题管理记录或其他来源。 90 - 91 -如果变更推动者从目标改进开始,那么将其与组织的愿景对齐以确认该计划的有效性就非常重要。但是,如果他们希望瞄准广阔的区域,则变更推动者应为他们的控制下的区域设想一个与组织愿景一致的未来状态的改进,并确定为实现该未来状态而必须进行的变更。 92 - 93 -共同愿景是任何成功的改进计划中最重要的部分。在没有从组织的相关级别输入信息的情况下决定的愿景不太可能激发所需的支持,以推动将其变为现实的必要更改。 94 - 95 -尽管不是每个人都可以控制组织愿景,但是任何人都可以为其控制范围中的区域定义愿景,只要它与组织愿景保持一致即可。某些人可能会觉得他们无法驾驭变更来帮助其朝组织愿景的方向发展,但这很少是真的。改进创意可以来自组织的任何部分,并且运行级别的员工经常拥有最好的创意。 96 - 97 -所有改进倡议都应有明确的目标,以传达改进的意图、预期的价值和建议的方向。负责变更的任何人都应该能够描述期望的将来状态和成功准则。目标应简明扼要、面向未来、可实现、清晰和鼓舞人心。明确符合组织愿景并已定义迭代计划的计划更有可能得到利益相关者的支持。 98 - 99 - 100 -(% style="text-align:center" %) 101 -[[image:1639215264724-198.png]] 102 - 103 - 104 -=== 5.4.2 步骤2:我们现在在哪里? === 105 - 106 -[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml\wps6066.tmp.png]]如果不了解当前状态,则几乎不可能定义要执行什么需求才能转换到未来状态。记录当前状态涉及建立当前状态指标度量,以便可以客观地证明向新状态的进度。 107 - 108 - 109 -|((( 110 -**关键信息** 111 - 112 -在步骤2结束时,变更推动者应具有: 113 - 114 -* 清楚了解改进焦点区域的当前状态 115 -* 基线当前状态的测量和指标度量,将用于以后的比较。 116 -))) 117 - 118 - 119 -(% style="text-align:center" %) 120 -[[image:1639215318282-759.png]] 121 - 122 - 123 -==== 5.4.2.1 评估 ==== 124 - 125 -评估用于测量、分析和理解实践、流程、服务、技术和人员的行为和性能或绩效。一个好的评估不仅可以发现差距和问题,还可以做更多的事情。它将识别出做得好的方面,并展示如何利用成功。对所有服务管理四维模型进行评估至关重要。组织中的任何人都可以评估其控制范围中某个区域的当前状态。 126 - 127 -所有利益相关者都需要对评估的目标达成共识,否则很难获得符合需求的可用结果。评估的重点和工作深度应以改进的大小为准,但是由于即使一个看似很小的计划也可能拥有更广泛的影响,所以评估的这一步绝不可忽略。 128 - 129 -变更推动者必须根据每个评估的目标和对每种方法约束的理解,为它们选择适当的方法。在许多情况下,在改进旅途中使用多种评估方法将是适当的。选择评估方法时,重要的是要考虑必须收集哪些信息,从谁那里收集信息以及所需的准确性和详细程度。选择的方法应与那些要求相吻合。 130 - 131 - 132 -=== 5.4.3 步骤3:我们想去哪里? === 133 - 134 -当前状态是改进旅程的起点。下一步是展望未来,并确定下一步的发展方向。此步骤不是要定义绝对的、完美的最终状态。改进不是有限的旅程。此步骤是关于定义下一个状态,即持续改进旅程中的下一个逻辑阶段。明智的做法是采取小的迭代步骤。如果改进的目标距离太远或似乎无法实现,则实现变更会变得更加困难。 135 - 136 - 137 -|((( 138 -**关键信息** 139 - 140 -在步骤3结束时,变更推动者应具有: 141 - 142 -* 期望的未来状态的描述 143 -* 差距分析的结果,证明了当前的缺陷 144 -* 尽可能列出具有相关SMART原则目标和平衡KPI的改进优先级 145 -* 创建详细的性能或绩效计划的工具 146 -* 清楚地了解影响力可以改进的约束 147 -* 改进计划的商业论证 148 -* 改进上将要使用的高级协议 149 -* 利益相关者提出的协议,以提出建议的改进和任何相关的优先级。 150 -))) 151 - 152 - 153 -==== 5.4.3.1 确定成果的优先级和范围 ==== 154 - 155 -在评估了当前状态并定义了所需的结果之后,需要对结果进行优先级划分和确定范围。确定的结果都应有助于实现所需的状态,但是某些结果将比其他结果更为关键,并且按特定顺序实施更改可能会促进某些成果。有些成果需要采用不同的方法来实现,有些成果则需要大量投资,而另一些成果只需花费很少的精力就可以实现。需要用可衡量的术语定义所需的结果。 156 - 157 -改进的成果可以在很多方面带来积极的效果,包括通过降低成本或风险、通过法规改进合规性来实现。在确定这些结果的优先级时,请考虑它们可能对使组织更接近实现其愿景的影响。在背景中具有更大积极影响的结果应优先于其他结果。 158 - 159 - 160 -==== 5.4.3.2 制作商业论证并到达协议 ==== 161 - 162 -进行改进可能不仅需要变更推动者,而且还需要负责授权所需预算和时间分配的人员使用协议。可能有必要制作一个简单的商业论证来概述提案并获得批准。 163 - 164 -(% style="text-align:center" %) 165 -[[image:1639215430903-598.png]] 166 - 167 - 168 -=== 5.4.4 步骤4:我们如何到达那里? === 169 - 170 -一旦定义了当前状态和所需状态,下一步就是创建一个性能或绩效计划。有效的性能或绩效计划应该回答几个问题,包括: 171 - 172 -● 是否完成任何变更都需要按照特定顺序? 173 - 174 -● 有没有可以快速交付客户价值的速赢法? 175 - 176 -● 是否有任何资源约束影响了变更流程? 177 - 178 -如果在计划和改进上披露了可能对影响利益相关者的期望或支持的新信息,则变更推动者可能需要返回到步骤3,然后与利益相关者重新进行契动。 179 - 180 - 181 -|((( 182 -**关键信息** 183 - 184 -在步骤4结束后,变更推动者应具有: 185 - 186 -* 经过批准的改进计划,符合利益相关者对治理的需求 187 -* 了解改进的性质以及用于达到预期结果的最有效方法。 188 -))) 189 - 190 - 191 -==== 5.4.4.1 创建改进计划 ==== 192 - 193 -根据改进的大小,组织中既定的方法或要求可能会决定规划的执行方式和改进的交付方式。变更推动者应确保已建立的策略得到遵守,并应利用现有的制品(例如工具和模板)(如果存在)。计划的设计应高效且轻巧,同时确保利益相关者具有可视化和控制的要求级别,并确保考虑到任何法规要求。 194 - 195 -无论使用哪种工作方法,改进计划都应考虑到以前的持续改进工作模型的步骤。相关的愿景、评估结果、期望的目标、商业论证的内容以及预期的结果都是对改进计划有价值的输入的示例。 196 - 197 - 198 -**工作迭代** 199 - 200 -管理改进计划并不一定意味着从复杂的甘特图或载有详细信息的项目计划开始。在可行的情况下,最好进行小幅改进的持续交付。即使需要持续努力的计划,也可以在较短的迭代中更好地实现,以突出进度,从而可以利用自然检查点来审核反馈,并在需要时修改方法。 201 - 202 -在复杂的环境中,组织通常无法定义一个特定的计划来达到目标状态。相反,可以针对测试假设计划一系列安全的失败实验,然后选择正确的选项。 203 - 204 -对于使用这种工作方式体验较少的组织,人们可能需要适应敏捷的迭代工作方式。通过速赢交付价值是将敏捷方法引入组织的一种好方法。 205 - 206 - 207 -**整合反馈和指标度量** 208 - 209 -在整个改进计划中纳入反馈机制和活动将确保征求和评估反馈。作为正在进行的利益干系人管理的一部分,重要的是定义每个阶段需要利益相关者提供的反馈类型,以及如何收集、处理和报告该反馈。 210 - 211 -通过在改进计划中包括一个简单实用的指标度量方案,利用步骤3中完成的工作也很重要。如果组织的标准项目管理方法包括必需的指标度量,则必须容纳这些指标度量。但是对于改进的成功更重要的是,可以定义明确的指标度量,这些指标度量可以用作项目的目标,也可以用作改进实施后的成功测量。 212 - 213 - 214 -==== 5.4.4.2 沟通并同意计划 ==== 215 - 216 -一旦设计了计划,就可以将其呈现给利益相关者,这有助于设定期望。根据改进的性质,可能决定在变更推动者的控制范围中进行处理。但是,如果需要批准,则在计划获批后,即可开始改进的工作。利益干系人沟通计划可以帮助设计并跟踪成功准备和交付演示文稿所需的沟通活动。与仅需要一般认知的利益相关者相比,那些有权批准计划的利益相关者可能需要不同的详细程度。 217 - 218 - 219 -(% style="text-align:center" %) 220 -[[image:1639215520586-581.png]] 221 - 222 - 223 -=== 5.4.5 步骤5:采取行动 === 224 - 225 -在此步骤中,计划变得栩栩如生,并且会完成工作;但是,如果性能或绩效无法产生期望的结果,则可能需要修改计划。还必须定期验证计划所基于的假设,并积极管理已识别的风险和利益相关者。 226 - 227 -如果在步骤4中选择了安全的失败实验方法,则会进行实验以为进一步的规划提供反馈。在某些情况下,这可能不仅导致对计划进行审查,而且对目标状态进行审查。 228 - 229 - 230 -|((( 231 -**关键信息** 232 - 233 -在步骤5结束时,变更推动者应利用先前传达并批准的性能或绩效计划,完成改进的动作。 234 -))) 235 - 236 - 237 -重要的是要记住,可能会并行发生多个单独的改进迭代。使用的治理方法应适应许多类型变更的有效管理。 238 - 239 -(% style="text-align:center" %) 240 -[[image:1639215570387-297.png]] 241 - 242 - 243 -=== 5.4.6 步骤6:我们到达了吗 === 244 - 245 - 246 -**关键信息** 247 - 248 -在步骤6结束时,变更推动者应具有: 249 - 250 -* 改进计划和目标验证的结果 251 -* 记录在案的改进评审。 252 - 253 -第6步的目的是使用真实证据并利用数据分析来确认是否已达到所需的将来状态,并通过变更确认新的状况和价值。经常会假定已实现一项计划的预期收益,并且组织转到下一个计划。准确了解已实现和尚未实现的内容对于将来的规划至关重要。 254 - 255 - 256 -==== 5.4.6.1 进行改进评审 ==== 257 - 258 -对于改进计划的每个迭代,都需要检查并确认进度和交付的价值。这是通过改进评审(有时称为利益实现评审)完成的。 259 - 260 - 261 -**定义:改进评审** 262 - 263 -使用指标度量和其他证据来评价改进是否已达到其期望的结果,如果没有,则需要执行什么以完成工作。 264 - 265 - 266 -关于进度和价值的问题只能通过使用指标度量来验证成功或确认是否缺少什么来回答。需要检查商定的成功因素和KPI,并确认价值的交付。除了指标度量外,还可以考虑使用更主观的证据,例如利益干系人报告或意见调查。如果尚未实现预期的收益,则需要重新审查改进计划,并且需要在下一次迭代之前进行更改。 267 - 268 -对于复杂的改进项目,改进评审可能是正式的、高度结构化的活动,但即使是短期的简单改进也应进行审查。 269 - 270 -如果改进计划为监控包含了足够的活动并验证了进度,并且允许进行定期修订,则改进评审不应发现重大的意外。但是,在改进评审期间发现教训可以使将来的改进更加有效,这种情况并不罕见。这些是改进评审的活动附带的,但不是其主要的输出。经验教训分析更适合作为步骤7的一部分。 271 - 272 - 273 -(% style="text-align:center" %) 274 -[[image:1639215688476-711.png]] 275 - 276 - 277 -=== 5.4.7 步骤7:我们如何保持势头? === 278 - 279 -改进必须保持连续性,以与组织的需求保持同步,并确保用于创建和交付它们的服务和SVS继续提供价值。目的应该是创建一个文化,其中持续改进是正常工作的一部分。当持续改进嵌入组织中时,各个级别的人们都会不断地寻求改进,以帮助其朝着愿景的方向发展,而且未来需要进行大规模转型的风险也得到了缓解。 280 - 281 -如果改进交付了预期的价值,则该计划的重点应转移到成功营销和加强引入的任何新方法上。这确保了进度不会丢失,并为下一次改进提供了支持和动力。 282 - 283 - 284 - 285 -**关键信息** 286 - 287 -在步骤7结束时,变更推动者应具有: 288 - 289 -* 确认改进已牢固的实施 290 -* 有关其他改进倡议或迭代的建议列表 291 -* 记录下来的经验教训分析,记录了有关如何在将来更好地实施改进的想法。 292 - 293 - 294 -==== 5.4.7.1 识别额外的改进机会 ==== 295 - 296 -即使实现了所有改进计划的目标,也总是有更多范围可以解决改进问题。变更推动者将在进行的改进计划中仔细管理范围,以保持关注焦点和改进成功的可能性。这通常意味着在步骤5中出现的改进想法无法集成到变更的该迭代中。这些想法应记录在案,并考虑在将来的性能或绩效中使用。此外,通常在持续改进登记册中,应记录在步骤1、2和3中产生的想法,以备将来可能使用的性能或绩效。 297 - 298 -在这最后一步中,变更推动者和其他利益相关者应就有关下一步和改进优先级的问题汇编其建议。他们对当前计划的参与将为他们提供宝贵的观点,使他们了解未来的改进构想将构建在当前应用上,以及可以很容易地在新的当前状态下实施。 299 - 300 - 301 -==== 5.4.7.2 确认和评估经验教训 ==== 302 - 303 -与其他所有实践一样,必须对持续改进实践进行检查并接受持续改进的约束。通过分析变更计划的成功或失效,可以看到可以改进的部分以及特别成功的部分。教训的结果可应用于将来的改进活动。 304 - 305 - 306 -**定义:经验教训分析** 307 - 308 -改进计划或迭代的评价,目的是了解在什么情况下进展顺利或不顺利以及以后在类似情况下应以不同的方式进行。 309 - 310 - 311 -在改进计划期间的任何时候都可以学习经验教训。当犯了错误时,应予以纠正,但那时所汲取的教训也应记录在案。 312 - 313 - 314 -(% style="text-align:center" %) 315 -[[image:1639215795722-566.png]] 316 - 317 - 318 -== 5.5 在持续改进中使用测量和报告 == 319 - 320 -测量和报告为持续改进的各个方面做出了贡献。表5.1给出了实践在持续改进模型上做出的突出贡献的示例。 321 - 322 - 323 -表5.1 持续改进模型中的测量和报告贡献 324 - 325 -|**持续改进**|**测量和报告模型步骤的贡献** 326 -|什么是愿景?|((( 327 -提供有关组织的竞争力和针对竞争对手的性能或绩效的数据的报告可能会为有关愿景以及个人和团队如何受到影响的讨论提供参考。 328 - 329 -在选择更特定的改进区域时,对于改进性能或绩效建议的高级区域中的过去性能或绩效的数据可能会有所帮助。 330 -))) 331 -|我们现在在哪?|收集有关目标改进区域的数据和其他证据,并将其处理为指标度量和信息,以提供当前状态的评估的基础。 332 -|我们想去哪里?|((( 333 -分析当前和历史测量值以识别特定的改进机会。 334 - 335 -开发了支持商业论证的指标度量。 336 - 337 -定义了每个改进的SMART原则目标,包括可用来验证改进进度的可衡量目标。 338 -))) 339 -|我们怎么去那里?|((( 340 -改进计划中包含用于度量和管理改进主动性的方法。 341 - 342 -同意在每个阶段都需要实现的出口准则。 343 -))) 344 -|采取行动|((( 345 -随着改进努力的进行,将对工作进行衡量并报告给相关的利益相关者。 346 - 347 -如果测量结果显示实施问题,则进行更改并进行新的测量。 348 -))) 349 -|我们到了那里吗?|((( 350 -将目标改进区域在新状态下的实际性能或绩效与先前状态进行比较,以验证改进。 351 - 352 -产生了有关评审和关闭实施的报告。 353 -))) 354 -|我们如何保持发展势头?|((( 355 -改进成就的衡量标准用于向组织和利益相关者推销市场成功。 356 - 357 -监视并报告新行为,以确保改进不会随着时间的流逝而减弱。 358 -))) 359 - 360 - 361 -== 5.6 总结 == 362 - 363 -通过在整个组织和SVS的每个元素中嵌入持续改进的承诺,组织可以更好地对更改做出响应,并增强与利益相关者共同创建价值的能力。 364 - 365 -无论组织的成熟度如何,持续改进都应成为每个SVS的重要组成部分。所有服务管理四维模型都受持续改进的约束。技术在不断变化,提供服务的方式需求可以跟上这些变化。强大的持续改进实践(自身会不断改进)是维护和增加价值的关键,而服务供应商为其服务消费者和其他利益相关者做出了贡献。 366 - 367 -