Changes for page 第3章 评估和计划

Last modified by superadmin on 2024/04/03, 17:29
From version < 17.1
edited by superadmin
on 2024/04/03, 17:29
To version < 16.4 >
edited by superadmin
on 2024/03/07, 19:39
<
Change comment: Updated parent field.

Summary

Details

Icon Page properties
Parent
... ... @@ -1,1 +1,1 @@
1 -ITIL 4《指导、计划和改进》DPI.WebHome
1 +xwiki:ITIL 4《指导、计划和改进》DPI.WebHome
Content
... ... @@ -3,15 +3,12 @@
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%AC4%E7%AB%A0%20%E6%B5%8B%E9%87%8F%E5%92%8C%E6%8A%A5%E5%91%8A/]]  [[返回上一章>>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%AC2%E7%AB%A0%20%E6%88%98%E7%95%A5%E4%B8%8E%E6%8C%87%E5%AF%BC/]]
5 5  
6 -{{box cssClass="floatinginfobox" title="
7 -
8 -**Contents**"}}
6 +{{box cssClass="floatinginfobox" title="**Contents**"}}
9 9  {{toc/}}
10 10  {{/box}}
11 11  
12 -= **第3章 评估和计划** =
10 += 第3章 评估和计划 =
13 13  
14 -
15 15  当规划改进或其他倡议时，了解当前状态至关重要。这使组织能够：
16 16  
17 17  ● 比较当前状态与期望的未来状态；
... ... @@ -21,10 +21,8 @@
21 21  ● 开发符合逻辑的计划以弥补这些差距。
22 22  
23 23  
24 -
25 25  == 3.1 评估的基础 ==
26 26  
27 -
28 28  评估用于测量、分析和理解行为和性能或绩效。他们应该通过准确反映当前状态来理解改进。在服务管理的背景中，评估通常以SVS的元素为目标，例如服务、实践或价值流。在评估期间，应考虑服务管理四维模型。
29 29  
30 30  存在许多类型的评估，不仅是是作为正式计划的一部分，而且还包括在日常管理活动中。例如，服务供应商组织可能希望整体上改进其提供服务的性能或绩效，这个改进依赖于对每项服务绩效的持续监控和管理。诸如服务台性能或绩效、技术或服务的可用性、重大事件审查以及与变更相关的事件之类的定期报告都是评估的典范。这些可以并且应该用来了解当前状态和计划的改进。
... ... @@ -35,16 +35,13 @@
35 35  
36 36  === 3.1.1 有效评估 ===
37 37  
38 -
39 39  目标评估包括进行测量、将其处理为指标度量、将其与期望值进行比较。然后，所有信息都应记录在报告中，该文件应支持评估的发现和做出的决定。应保留以此方式创建的报告，并将其用作与将来评估的比较点。
40 40  
41 41  全面的评估不仅可以确定差距和关注的领域，还可以突出表现良好的生产领域以及可以进一步发展的领域。找出不良做法并要求变更可以促进改进，但是突出积极之处和鼓励良好做法往往更为有效。
42 42  
43 43  
44 -
45 45  ==== 3.1.1.1 评估类型 ====
46 46  
47 -
48 48  在选择评估方法和技术时，重要的是要了解每个人将产生结果的性质。可以采用一种以上的评估方法，即从不同的角度看待SVS的不同方面，或者看相同的方面。表3.1列出了三种主要的评估类型。
49 49  
50 50  表3.1 评估类型
... ... @@ -54,15 +54,8 @@
54 54  |(% style="width:66px" %)定量|(% style="width:368px" %)定量评估以证据为导向，因此更多。这些评估依赖于准确、完整的数据。正式审核通常是定量。
55 55  |(% style="width:66px" %)混合法|(% style="width:368px" %)定性和定量，混合法评估相结合，涉及专家分析证据并提出意见的过程。当采用混合法方法时，用于识别和实施改进的评估通常最有效。
56 56  
57 -(% class="wikigeneratedid" %)
58 -==== ====
59 -
60 -(% class="wikigeneratedid" %)
61 -==== ====
62 -
63 63  ==== 3.1.1.2 评估目标 ====
64 64  
65 -
66 66  评估可以设计为一次性使用，也可以作为常规方案的一部分，以跟踪组织功能的发展。它们应该在改进倡议开始之前、整个过程以及结论中发生。在开始之前，了解评估的目标很重要。评估目标的一些示例是：
67 67  
68 68  ● 了解某件事的表现如何；
... ... @@ -78,11 +78,8 @@
78 78  评估目标应该被定义并记录下来。利益相关者了解评估的目标和结果也很重要。如果没有这种共识，将很难制造出符合组织的需求的评估。
79 79  
80 80  
81 -
82 -
83 83  === 3.1.2 收集当前状态数据或其他证据 ===
84 84  
85 -
86 86  评估依赖于数据或其他证据。原始数据一旦收集，就应处理成指标度量。指标度量的价值取决于数据的准确性和完整性。其他证据（例如从调查中收集的证据）依赖良好的沟通来传达预期的含义，因此需要进行解释。表3.2概述了五种常见的证据收集方法。
87 87  
88 88  表3.2取证方法
... ... @@ -94,15 +94,8 @@
94 94  |圆桌会议|互动小组会议收集的反馈
95 95  |观察|从直接检查以及行为和性能或绩效的测量得出的报告
96 96  
97 -(% class="wikigeneratedid" %)
98 -==== ====
99 -
100 -(% class="wikigeneratedid" %)
101 -==== ====
102 -
103 103  ==== 3.1.2.1 指标度量/数据挖掘 ====
104 104  
105 -
106 106  此方法涉及收集相关指标度量或未处理的数据并将其处理为新指标度量。评估能被有效测量的区域使评估更具目的。但是，必须解释指标度量的含义，这会带来主观性。
107 107  
108 108  仅当所基于的数据相关、准确且完整时，这些指标度量才有价值。无法反映现实数据会得出错误的结论。如果所分析的数据没有反映足够的细节，则可能会怀疑所涉及的准确性和完整性。当测量、指标度量和报告源于可靠的数据时，指标度量分析可以产生可信赖的信息，这些信息可以在改进的整个过程中使用。表3.3概述了指标度量/数据挖掘的优缺点。
... ... @@ -122,15 +122,8 @@
122 122  有时，直到原始数据的质量改进后，指标度量才可靠。
123 123  )))
124 124  
125 -(% class="wikigeneratedid" %)
126 -==== ====
127 -
128 -(% class="wikigeneratedid" %)
129 -==== ====
130 -
131 131  ==== 3.1.2.2 调查 ====
132 132  
133 -
134 134  如果使用得当，调查会非常有效。时间非常重要：事态之后立即进行的调查与事态捕获了几周后再进行调查的结果截然不同。适当的调查时间也各不相同：太短，可能无法收集足够的有意义的信息；时间过长，完成率和回应率就会降低。
135 135  
136 136  有效调查的提示包括：
... ... @@ -168,15 +168,8 @@
168 168  对于性能或绩效，数字响应可能很困难。书面答复可能过于密集而难以解释。
169 169  )))
170 170  
171 -(% class="wikigeneratedid" %)
172 -==== ====
173 -
174 -(% class="wikigeneratedid" %)
175 -==== ====
176 -
177 177  ==== 3.1.2.3 访谈 ====
178 178  
179 -
180 180  访谈与调查相似，但访谈的性质使访谈者对于提取信息并与受访者建立关系，获得了更大的自由。
181 181  
182 182  许多有效调查的技巧也适用于访谈。具体的访谈技巧包括：
... ... @@ -210,15 +210,8 @@
210 210  单独的访谈通常不能收集足够的数据。
211 211  )))
212 212  
213 -(% class="wikigeneratedid" %)
214 -==== ====
215 -
216 -(% class="wikigeneratedid" %)
217 -==== ====
218 -
219 219  ==== 3.1.2.4 圆桌会议 ====
220 220  
221 -
222 222  圆桌会议与访谈类似，但是具有更多的自发性交互的机会。他们参加小组会议讨论一个主题。组织者精心计划以及主持人引导会议进程，形成了问题、参与者、位置、议程和期望的输出。
223 223  
224 224  小组讨论的性质意味着，参与者可能会遵循与访谈中不同的思维方式。一个参与者的评论将激发另一个想法，对话将朝着新的方向发展。
... ... @@ -262,15 +262,8 @@
262 262  将会存在偏差。
263 263  )))
264 264  
265 -(% class="wikigeneratedid" %)
266 -==== ====
267 -
268 -(% class="wikigeneratedid" %)
269 -==== ====
270 -
271 271  ==== 3.1.2.5 观察 ====
272 272  
273 -
274 274  从源头进行观察意味着要去观察组织中价值创造活动的地方。
275 275  
276 276  观察者应该提出问题。如果他们对实现价值不了解，可能会有所帮助，因为他们没有先入为主的观念。如果观察者熟悉实现价值，则他们可能会做出无效的假设或无法提出基本问题。
... ... @@ -297,18 +297,8 @@
297 297  观察属于时间消耗型。
298 298  )))
299 299  
300 -(% class="wikigeneratedid" %)
301 -=== ===
302 -
303 -(% class="wikigeneratedid" %)
304 -=== ===
305 -
306 -(% class="wikigeneratedid" %)
307 -=== ===
308 -
309 309  === 3.1.3 选择评估方法 ===
310 310  
311 -
312 312  收集有关当前状态的信息后，必须对其进行严格分析以评估其含义并准确理解当前的状态。
313 313  
314 314  选择的评估方法将取决于评估的目标和应当的输出。在评估和流程中进行批判性和客观的思考非常重要，以增加其结论有效的可能性。
... ... @@ -329,12 +329,8 @@
329 329  组织通常会重新使用评估方法，但重要的是，基于当前情况的探索新的备选方案。
330 330  
331 331  
332 -(% class="wikigeneratedid" %)
333 -==== ====
334 -
335 335  ==== 3.1.3.1 差距分析 ====
336 336  
337 -
338 338  差距分析用于将当前状态与期望状态进行比较。该分析的输出突出显示了两种状态之间差距的性质和范围，并且为计划提供基础使得组织更加接近实现目标。
339 339  
340 340  《AgileSHIFT™指南》（AXELOS，2018年）将此差距称为“增量”。可以通过考虑以下因素来理解增量：
... ... @@ -380,12 +380,8 @@
380 380  图片3.1 SWOT分析
381 381  
382 382  
383 -(% class="wikigeneratedid" %)
384 -==== ====
385 -
386 386  ==== 3.1.3.2 SWOT分析 ====
387 387  
388 -
389 389  SWOT分析可以识别优势、劣势、机遇和威胁。它是确定组织的内部和外部威胁并显示其与竞争对手有何不同的最古老的方法之一。
390 390  
391 391  优势和劣势是影响组织朝着目标前进的能力的内部因素。威胁和机遇是控制之外的外部因素，但是规划进行更改和改进时必须考虑这些因素。
... ... @@ -415,15 +415,8 @@
415 415  SWOT分析是主观的。
416 416  )))
417 417  
418 -(% class="wikigeneratedid" %)
419 -==== ====
420 -
421 -(% class="wikigeneratedid" %)
422 -==== ====
423 -
424 424  ==== 3.1.3.3 变更准备评估 ====
425 425  
426 -
427 427  变更准备评估对组织准备过渡到一种新工作方式的评估。有许多影响因素会影响组织、部门或团队成功适应变化的能力。在启动变更举措之前，评估这些因素突出显示了其可能成为阻碍其成功的因素。
428 428  
429 429  一个善于接受这种变更并过渡到新的工作方式的组织，是最有可能实现持续改进的潜力组织。如果每个变更都遇到阻力，变更的驱动力会动摇，并可能最终失败。变更准备评估将提供信息，这将有助于指导可能影响变更举措成功的活动。
... ... @@ -457,15 +457,8 @@
457 457  确定成功变更的障碍并不意味着组织可以或将解决这些障碍。
458 458  )))
459 459  
460 -(% class="wikigeneratedid" %)
461 -==== ====
462 -
463 -(% class="wikigeneratedid" %)
464 -==== ====
465 -
466 466  ==== 3.1.3.4 客户/用户满意度分析 ====
467 467  
468 -
469 469  对于大多数改进而言，了解客户和用户的满意度水平是有价值的输入。当计划迭代更改时，重要的是要考虑它们将对客户和用户产生的影响。完变更之后，确定满意度的水平是否已按预期提高就很重要。
470 470  
471 471  根据服务的类型，用户和客户的角色可以由不同的人员或组合完成。在后一种情况下，客户旅程、客户体验和客户满意度可能与用户的不同。因此，他们可能需要对评估和分析使用不同的方法。
... ... @@ -489,15 +489,8 @@
489 489  请求客户和用户的时间可能会严重影响响应。
490 490  )))
491 491  
492 -(% class="wikigeneratedid" %)
493 -==== ====
494 -
495 -(% class="wikigeneratedid" %)
496 -==== ====
497 -
498 498  ==== 3.1.3.5 SLA绩效分析 ====
499 499  
500 -
501 501  |(((
502 502  定义：服务级别协议（SLA）
503 503  
... ... @@ -527,15 +527,8 @@
527 527  与SLA达成相关问题的根本原因可能很难发现且难以解决。
528 528  )))
529 529  
530 -(% class="wikigeneratedid" %)
531 -==== ====
532 -
533 -(% class="wikigeneratedid" %)
534 -==== ====
535 -
536 536  ==== 3.1.3.6 基准测试 ====
537 537  
538 -
539 539  基准测试是将组织的产品、服务或实践的性能或绩效与类似的组织的产品、服务或实践进行度量的行为。将一个组织与一个表现更好的组织进行比较，可能会突出能够产生切实改进的变更措施。基准测试应该作为持续改进实践的一部分定期进行，以使组织达到或超过竞争对手的性能。它在组织可以成为其他组织对其进行衡量的标准的前提下，也是激励文化变更的宝贵工具。
540 540  
541 541  尽管基准测试通常是在组织级别完成的，但比较高性能组织的特定领域可能更有价值。例如，一个问题经理可能想了解另一个具有较低重大事件发生率的组织在其问题管理实践中的不同之处。与扮演类似角色的对手交谈可以提供有价值的洞察力，这可能会带来有价值的改进倡议。
... ... @@ -563,15 +563,8 @@
563 563  旨在确定行业领导者，从而导致标准化但不一定理想的行为。
564 564  )))
565 565  
566 -(% class="wikigeneratedid" %)
567 -==== ====
568 -
569 -(% class="wikigeneratedid" %)
570 -==== ====
571 -
572 572  ==== 3.1.3.7 成熟度评估 ====
573 573  
574 -
575 575  成熟度评估是对能力进行评估（通常是流程或组织），用于与成熟度的框架、模型或等级相比较，用于评估的参考模型通常包括多个级别，每个级别描述特定的实践或整个组织的特性。
576 576  
577 577  成熟度评估结果作为成熟度评级与支持证据的详细描述一起出现。组织必须决定评估的成熟度是否可接受；如果不是，则应寻求改进。
... ... @@ -595,18 +595,8 @@
595 595  风险是目标在于提高成熟度的水平，而不是改进组织或流程。
596 596  )))
597 597  
598 -(% class="wikigeneratedid" %)
599 -=== ===
600 -
601 -(% class="wikigeneratedid" %)
602 -=== ===
603 -
604 -(% class="wikigeneratedid" %)
605 -=== ===
606 -
607 607  === 3.1.4 定义评估目标和准则 ===
608 608  
609 -
610 610  了解任何评估的目标都是至关重要的。如果要使用多种类型的评估方法，则必须明确定义每个评估的角色。如果其目标过于广泛，则评估可能会很昂贵且耗时。但是，狭窄的范围不太可能传递足够的信息。
611 611  
612 612  提出并回答某些问题将有助于定义每个评估的关键元素，并确保它们与改进的高级愿景保持一致。特别是，每个评估目的必须经过同意并明确定义。否则以下问题将无法获得有意义的回答。
... ... @@ -647,15 +647,8 @@
647 647  当将评估用作正在进行的管理工具时，至少应每年重新评估一次此信息，以确保所使用的方法仍然有效。
648 648  
649 649  
650 -(% class="wikigeneratedid" %)
651 -=== ===
652 -
653 -(% class="wikigeneratedid" %)
654 -=== ===
655 -
656 656  === 3.1.5 进行评估并产生输出 ===
657 657  
658 -
659 659  评估通常是与第三方执行的，但是变更推动者本身必须定义每个评估的目标和范围。一种常见的方法是使用独立的评估程序，因为它们是组织的新手，因此他们常常注意到变更推动者错过的改进机会。
660 660  
661 661  必须仔细考虑使用第三方进行评估是否合适。不这样做可能会节省资金，但可能不会产生所需的结果。在决定是否使用第三方时，请考虑以下几点：
... ... @@ -681,18 +681,8 @@
681 681  
682 682  
683 683  
684 -(% class="wikigeneratedid" %)
685 -== ==
686 -
687 -(% class="wikigeneratedid" %)
688 -== ==
689 -
690 -(% class="wikigeneratedid" %)
691 -== ==
692 -
693 693  == 3.2 计划的基础 ==
694 694  
695 -
696 696  在任何组织或团队中，计划可以更好地理解实现目标所需的资源。计划在不知道需要什么新资源或更改资源的情况下更改工作方式将导致不良后果。
697 697  
698 698  计划必须先于性能或绩效，但不应过高到“分析瘫痪”的地步，在该分析中，计划花了太多时间，并制定了策略，使性能或绩效从未启动。敏捷的工作方式鼓励人们着眼于在完美结果之前创建最小可行产品（MVP），特别是避免这种计划的危害。
... ... @@ -702,12 +702,8 @@
702 702  在工作流程的计划阶段，重要的是要问：“此计划如何与我们的总体战略保持一致？”无论计划看起来多么小或看起来似乎无关紧要，它都应该有助于实现组织的战略目标。计划如果没有这样运行，则可能不值得。
703 703  
704 704  
705 -(% class="wikigeneratedid" %)
706 -=== ===
707 -
708 708  === 3.2.1 利用计划中的不同工作方式 ===
709 709  
710 -
711 711  计划可以采用多种形式，可以利用多种工作方式。计划可以采用的最为熟悉和结构化的形式是项目计划，它可以涵盖多年的工作，其子项目计划和相互依赖的阶段需要数十个人的参与。但是，计划也可以像个人的待办事项清单一样简单。
712 712  
713 713  项目计划可以包括不同的工作方式，具体取决于计划的类型、计划的目标和限制以及相关人员的经验。本部分将介绍探索的三种著名的工作方式：瀑布法、敏捷法和混合法。尽管这些工作方式最初是为在IT 开发项目中使用而创建的，但它们的关键特性也适用于许多其他内容和范围。
... ... @@ -727,12 +727,8 @@
727 727  |很多方面依赖其他SVS的系统、服务或元素|项目的主题区域或者独立，或者少有依赖|有一些依赖关系，但它们是易于理解和管理
728 728  |团队成员是只担任一个角色|团队成员灵活且能够担任多个角色|团队成员有专长，但也能够跨角色和在小团体
729 729  
730 -(% class="wikigeneratedid" %)
731 -==== ====
732 -
733 733  ==== 3.2.1.1 瀑布 ====
734 734  
735 -
736 736  使用传统瀑布式方法的计划分为不同的阶段。在每个阶段都完成并且产品处于最终状态之前，项目或计划的输出无法交付。在每个阶段结束时，都会进行一次评审，以评估项目的状态，并确定下一阶段是否可以开始。这些检查点有时被称为项目里程碑。
737 737  
738 738  基于瀑布的工作流旨在项目结束时能够提供近乎完美的解决方案。瀑布式方法有许多优点，在某些特定情况下，它是一种最佳的工作方式。例如，瀑布式开发技术很可能用于系统不完整或有故障会导致严重后果的情况。但是，这种工作方式的主要缺点与技术变更的快速发展有关。用这种方法管理的项目通常需要很长时间才能完成，这意味着该技术可能会在最终使用之前超过最终的输出。
... ... @@ -746,12 +746,8 @@
746 746  ● 阶段一次完成，没有重叠，允许检查点验证进度。
747 747  
748 748  
749 -(% class="wikigeneratedid" %)
750 -==== ====
751 -
752 752  ==== 3.2.1.2 敏捷 ====
753 753  
754 -
755 755  敏捷的工作方式将项目组织成小的独立单元，称为迭代或冲刺。每个冲刺通常会持续一到三周，并将重点放在该时间段内可以完成和交付的工作上。敏捷规划专注于确定每个冲刺可以完成什么，构建可重复的流程，并帮助团队了解他们在短期内可以实现多少。
756 756  
757 757  以敏捷的工作方式，团队不会立即尝试计划或交付大型生产。他们用计划交付体积更小、功能更强大的产品，这些产品将用较短的时限范围满足客户的需求。
... ... @@ -767,12 +767,8 @@
767 767  ● **更高的客户满意度**： 敏捷团队与客户紧密合作，可以提供快速的反馈和更改，以适应他们不断发展的需求。
768 768  
769 769  
770 -(% class="wikigeneratedid" %)
771 -==== ====
772 -
773 773  ==== 3.2.1.3 混合法 ====
774 774  
775 -
776 776  有几种将瀑布式和敏捷方法混合为一种方法的方法。通用方法使用类似于瀑布项目的整体分阶段结构，将需求收集在单个阶段中，然后是高级设计。但是，开发工作是在冲刺中进行的迭代，使用反馈来验证成功并相应地调整即将到来的冲刺。但是，与真正的敏捷项目不同，最终的输出都是在项目的末尾一次性发布的，而不是在每个冲刺的末尾发布的。
777 777  
778 778  混合法工作方式的好处包括：
... ... @@ -784,15 +784,8 @@
784 784  ● 对于习惯瀑布式但想学习如何敏捷工作的团队来说，它可以是一种中间方法。
785 785  
786 786  
787 -(% class="wikigeneratedid" %)
788 -=== ===
789 -
790 -(% class="wikigeneratedid" %)
791 -=== ===
792 -
793 793  === 3.2.2 监控计划的进展 ===
794 794  
795 -
796 796  不管使用哪种方法，都要定期测量针对计划需求的进度。必须监视和调整计划，即便是瀑布计划和混合法型计划，以确保不需要外部因素进行更改。例如，计划中面向客户的服务可能需要快速修改，以应对竞争对手利用的新技术。如果无法调整计划，则其输出将在交付之前被淘汰。
797 797  
798 798  敏捷的基本前提是，它可以快速地向变更定向，而不会失去动力。在敏捷项目的生命周期内，监控的外部影响和内部压力至关重要。在交付计划的每个迭代时，相关利益相关者提供的监控反馈将指示所需方向的任何变化。
... ... @@ -810,18 +810,8 @@
810 810  //PRINCE2 Agile//® (AXELOS, 2015) 为组织提供了适当的结构和治理模型，使团队能够以敏捷的方式工作。
811 811  )))
812 812  
813 -(% class="wikigeneratedid" %)
814 -== ==
815 -
816 -(% class="wikigeneratedid" %)
817 -== ==
818 -
819 -(% class="wikigeneratedid" %)
820 -== ==
821 -
822 822  == 3.3 价值流图简介 ==
823 823  
824 -
825 825  价值流图是一种将从需求或机会流动到价值可视化的方法，然后在可视化如何规划中改进流动。该方法起源于精益制造技术，但同样适用于产品和服务的创建和交付，如ITIL®4：创建、交付和支持中所述。提供产品和服务时有许多价值流。可以在价值流图中定义用于快速恢复服务，以约定的可用性级别交付服务或管理服务变更的实现价值流程。对于利益相关者，组织所做的一切都应直接或间接映射到价值。
826 826  
827 827  价值流图用于深入了解组织工作流。它可以帮助识别价值流中的添加价值的活动和不添加价值的活动，同时突出显示优化和自动化的机会。价值流图包括评估（记录了从需求到价值的工作流的当前状态）和规划（规划，将对改进对该工作流进行哪些更改）。然而，价值流图最重要的作用是确定必须实施哪些改进行动才能达到预期的未来状态。
... ... @@ -831,12 +831,8 @@
831 831  价值流通常跨越许多合作伙伴，供应商和服务消费者组织。但是，对于价值流图来说，新的组织可能需要简单地开始，重点放在组织本身内的价值流的那些方面。随着时间的推移，它可以扩展其价值流图的范围，从而找到更多的优化机会。
832 832  
833 833  
834 -(% class="wikigeneratedid" %)
835 -=== ===
836 -
837 837  === 3.3.1 精益 ===
838 838  
839 -
840 840  精益和价值流图密切相关。精益的核心思想是最大化客户价值，同时最大程度地减少浪费。简而言之，精益意味着用更少的资源为服务使用者创建更多的价值。
841 841  
842 842  应当充分利用各种类型的资源，尤其是人力资源。任何浪费的东西都应该消除，技术应该被最大程度地利用。人为干预只能在确实有助于价值的地方进行。
... ... @@ -844,12 +844,8 @@
844 844  精益旨在通过零浪费的完美价值创造流程提供完美的价值。精益思想鼓励管理层关注的不是孤立的技术、资产和部门，而是通过整个价值流优化产品和服务的流动，这些价值流水平地跨技术、资产和部门流向服务消费者。
845 845  
846 846  
847 -(% class="wikigeneratedid" %)
848 -=== ===
849 -
850 850  === 3.3.2 避免局部优化 ===
851 851  
852 -
853 853  在许多组织中，专注于单个流程可以优化小型控制范围中的流程中的步骤，例如针对单个团队或部门，同时忽略更改对整个价值流的影响。局部优化会导致在价值流的更下方创建瓶颈，并使整个性能或绩效变差，而不是变好。
854 854  
855 855  消除整个价值流中的浪费，而不是孤立地消除浪费，创造了需要更少人力、空间、资本和时间的流程，从而以更低的成本和更少的缺陷制造产品和服务。
... ... @@ -857,12 +857,8 @@
857 857  价值流图是优化整个价值链的出色工具。较大的视图与“通盘思考和工作”的导向原则完美对齐。
858 858  
859 859  
860 -(% class="wikigeneratedid" %)
861 -=== ===
862 -
863 863  === 3.3.3 价值流图的价值 ===
864 864  
865 -
866 866  价值流图很有价值，因为它能够：
867 867  
868 868  ● 帮助组织可视化超过生产中的单个流程级别
... ... @@ -876,12 +876,8 @@
876 876  ● 帮助计划和文档改进。
877 877  
878 878  
879 -(% class="wikigeneratedid" %)
880 -=== ===
881 -
882 882  === 3.3.4 开发价值流图 ===
883 883  
884 -
885 885  |(((
886 886  定义：价值流图
887 887  
... ... @@ -923,12 +923,8 @@
923 923  随着计划改进的实施，将来的状态价值流图变为当前的状态价值流图。价值流图是迭代的，应将价值流重新映射为工作方式和其他因素变更。
924 924  
925 925  
926 -(% class="wikigeneratedid" %)
927 -==== ====
928 -
929 929  ==== 3.3.4.1 增加价值流图中的细节 ====
930 930  
931 -
932 932  通过详细介绍流动的步骤来映射价值流。最初，添加了基本信息，以便需求对其进行研究的任何人都可以理解价值流图。这包括概述价值流的输入和输出。
933 933  
934 934  但是，仅提供高级信息还不够。价值流图需要更加具体，以便进行详细分析。当在映射中定义逻辑和可衡量的步骤时，量化工作流程和识别浪费将变得更加容易。
... ... @@ -945,12 +945,8 @@
945 945  图片3.2 价值流图符号
946 946  
947 947  
948 -(% class="wikigeneratedid" %)
949 -=== ===
950 -
951 951  === 3.3.5 价值流图中的典型错误 ===
952 952  
953 -
954 954  表3.19概述了与价值流图相关的典型错误。
955 955  
956 956  表3.19 价值流图中的典型错误
... ... @@ -970,15 +970,8 @@
970 970  [[image:1639210933547-115.png]]
971 971  
972 972  
973 -(% class="wikigeneratedid" %)
974 -== ==
975 -
976 -(% class="wikigeneratedid" %)
977 -== ==
978 -
979 979  == 3.4 总结 ==
980 980  
981 -
982 982  评估是任何持续改进历程的关键部分：定义评估的目标，适当地设定范围以及了解如何从当前状态过渡到未来状态至关重要。如果您在改进的每个迭代之后都使用另一个评估来验证您的结果，那么当规划计划的下一阶段时，这将有所帮助。
983 983  
984 984  
深圳市艾拓先锋企业管理咨询有限公司