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

Summary

Details

Icon Page properties
父
... ... @@ -1,1 +1,1 @@
1 -xwiki:ITIL 4《指导、计划和改进》DPI.WebHome
1 +ITIL 4《指导、计划和改进》DPI.WebHome
Content
... ... @@ -3,12 +3,15 @@
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="**Contents**"}}
6 +{{box cssClass="floatinginfobox" title="
7 +
8 +**Contents**"}}
7 7  {{toc/}}
8 8  {{/box}}
9 9  
10 -= 第3章 评估和计划 =
12 += **第3章 评估和计划** =
11 11  
14 +
12 12  当规划改进或其他倡议时，了解当前状态至关重要。这使组织能够：
13 13  
14 14  ● 比较当前状态与期望的未来状态；
... ... @@ -18,8 +18,10 @@
18 18  ● 开发符合逻辑的计划以弥补这些差距。
19 19  
20 20  
24 +
21 21  == 3.1 评估的基础 ==
22 22  
27 +
23 23  评估用于测量、分析和理解行为和性能或绩效。他们应该通过准确反映当前状态来理解改进。在服务管理的背景中，评估通常以SVS的元素为目标，例如服务、实践或价值流。在评估期间，应考虑服务管理四维模型。
24 24  
25 25  存在许多类型的评估，不仅是是作为正式计划的一部分，而且还包括在日常管理活动中。例如，服务供应商组织可能希望整体上改进其提供服务的性能或绩效，这个改进依赖于对每项服务绩效的持续监控和管理。诸如服务台性能或绩效、技术或服务的可用性、重大事件审查以及与变更相关的事件之类的定期报告都是评估的典范。这些可以并且应该用来了解当前状态和计划的改进。
... ... @@ -30,13 +30,16 @@
30 30  
31 31  === 3.1.1 有效评估 ===
32 32  
38 +
33 33  目标评估包括进行测量、将其处理为指标度量、将其与期望值进行比较。然后，所有信息都应记录在报告中，该文件应支持评估的发现和做出的决定。应保留以此方式创建的报告，并将其用作与将来评估的比较点。
34 34  
35 35  全面的评估不仅可以确定差距和关注的领域，还可以突出表现良好的生产领域以及可以进一步发展的领域。找出不良做法并要求变更可以促进改进，但是突出积极之处和鼓励良好做法往往更为有效。
36 36  
37 37  
44 +
38 38  ==== 3.1.1.1 评估类型 ====
39 39  
47 +
40 40  在选择评估方法和技术时，重要的是要了解每个人将产生结果的性质。可以采用一种以上的评估方法，即从不同的角度看待SVS的不同方面，或者看相同的方面。表3.1列出了三种主要的评估类型。
41 41  
42 42  表3.1 评估类型
... ... @@ -46,8 +46,15 @@
46 46  |(% style="width:66px" %)定量|(% style="width:368px" %)定量评估以证据为导向，因此更多。这些评估依赖于准确、完整的数据。正式审核通常是定量。
47 47  |(% style="width:66px" %)混合法|(% style="width:368px" %)定性和定量，混合法评估相结合，涉及专家分析证据并提出意见的过程。当采用混合法方法时，用于识别和实施改进的评估通常最有效。
48 48  
57 +(% class="wikigeneratedid" %)
58 +==== ====
59 +
60 +(% class="wikigeneratedid" %)
61 +==== ====
62 +
49 49  ==== 3.1.1.2 评估目标 ====
50 50  
65 +
51 51  评估可以设计为一次性使用，也可以作为常规方案的一部分，以跟踪组织功能的发展。它们应该在改进倡议开始之前、整个过程以及结论中发生。在开始之前，了解评估的目标很重要。评估目标的一些示例是：
52 52  
53 53  ● 了解某件事的表现如何；
... ... @@ -63,8 +63,11 @@
63 63  评估目标应该被定义并记录下来。利益相关者了解评估的目标和结果也很重要。如果没有这种共识，将很难制造出符合组织的需求的评估。
64 64  
65 65  
81 +
82 +
66 66  === 3.1.2 收集当前状态数据或其他证据 ===
67 67  
85 +
68 68  评估依赖于数据或其他证据。原始数据一旦收集，就应处理成指标度量。指标度量的价值取决于数据的准确性和完整性。其他证据（例如从调查中收集的证据）依赖良好的沟通来传达预期的含义，因此需要进行解释。表3.2概述了五种常见的证据收集方法。
69 69  
70 70  表3.2取证方法
... ... @@ -76,8 +76,15 @@
76 76  |圆桌会议|互动小组会议收集的反馈
77 77  |观察|从直接检查以及行为和性能或绩效的测量得出的报告
78 78  
97 +(% class="wikigeneratedid" %)
98 +==== ====
99 +
100 +(% class="wikigeneratedid" %)
101 +==== ====
102 +
79 79  ==== 3.1.2.1 指标度量/数据挖掘 ====
80 80  
105 +
81 81  此方法涉及收集相关指标度量或未处理的数据并将其处理为新指标度量。评估能被有效测量的区域使评估更具目的。但是，必须解释指标度量的含义，这会带来主观性。
82 82  
83 83  仅当所基于的数据相关、准确且完整时，这些指标度量才有价值。无法反映现实数据会得出错误的结论。如果所分析的数据没有反映足够的细节，则可能会怀疑所涉及的准确性和完整性。当测量、指标度量和报告源于可靠的数据时，指标度量分析可以产生可信赖的信息，这些信息可以在改进的整个过程中使用。表3.3概述了指标度量/数据挖掘的优缺点。
... ... @@ -97,8 +97,15 @@
97 97  有时，直到原始数据的质量改进后，指标度量才可靠。
98 98  )))
99 99  
125 +(% class="wikigeneratedid" %)
126 +==== ====
127 +
128 +(% class="wikigeneratedid" %)
129 +==== ====
130 +
100 100  ==== 3.1.2.2 调查 ====
101 101  
133 +
102 102  如果使用得当，调查会非常有效。时间非常重要：事态之后立即进行的调查与事态捕获了几周后再进行调查的结果截然不同。适当的调查时间也各不相同：太短，可能无法收集足够的有意义的信息；时间过长，完成率和回应率就会降低。
103 103  
104 104  有效调查的提示包括：
... ... @@ -136,8 +136,15 @@
136 136  对于性能或绩效，数字响应可能很困难。书面答复可能过于密集而难以解释。
137 137  )))
138 138  
171 +(% class="wikigeneratedid" %)
172 +==== ====
173 +
174 +(% class="wikigeneratedid" %)
175 +==== ====
176 +
139 139  ==== 3.1.2.3 访谈 ====
140 140  
179 +
141 141  访谈与调查相似，但访谈的性质使访谈者对于提取信息并与受访者建立关系，获得了更大的自由。
142 142  
143 143  许多有效调查的技巧也适用于访谈。具体的访谈技巧包括：
... ... @@ -171,8 +171,15 @@
171 171  单独的访谈通常不能收集足够的数据。
172 172  )))
173 173  
213 +(% class="wikigeneratedid" %)
214 +==== ====
215 +
216 +(% class="wikigeneratedid" %)
217 +==== ====
218 +
174 174  ==== 3.1.2.4 圆桌会议 ====
175 175  
221 +
176 176  圆桌会议与访谈类似，但是具有更多的自发性交互的机会。他们参加小组会议讨论一个主题。组织者精心计划以及主持人引导会议进程，形成了问题、参与者、位置、议程和期望的输出。
177 177  
178 178  小组讨论的性质意味着，参与者可能会遵循与访谈中不同的思维方式。一个参与者的评论将激发另一个想法，对话将朝着新的方向发展。
... ... @@ -216,8 +216,15 @@
216 216  将会存在偏差。
217 217  )))
218 218  
265 +(% class="wikigeneratedid" %)
266 +==== ====
267 +
268 +(% class="wikigeneratedid" %)
269 +==== ====
270 +
219 219  ==== 3.1.2.5 观察 ====
220 220  
273 +
221 221  从源头进行观察意味着要去观察组织中价值创造活动的地方。
222 222  
223 223  观察者应该提出问题。如果他们对实现价值不了解，可能会有所帮助，因为他们没有先入为主的观念。如果观察者熟悉实现价值，则他们可能会做出无效的假设或无法提出基本问题。
... ... @@ -244,8 +244,18 @@
244 244  观察属于时间消耗型。
245 245  )))
246 246  
300 +(% class="wikigeneratedid" %)
301 +=== ===
302 +
303 +(% class="wikigeneratedid" %)
304 +=== ===
305 +
306 +(% class="wikigeneratedid" %)
307 +=== ===
308 +
247 247  === 3.1.3 选择评估方法 ===
248 248  
311 +
249 249  收集有关当前状态的信息后，必须对其进行严格分析以评估其含义并准确理解当前的状态。
250 250  
251 251  选择的评估方法将取决于评估的目标和应当的输出。在评估和流程中进行批判性和客观的思考非常重要，以增加其结论有效的可能性。
... ... @@ -266,8 +266,12 @@
266 266  组织通常会重新使用评估方法，但重要的是，基于当前情况的探索新的备选方案。
267 267  
268 268  
332 +(% class="wikigeneratedid" %)
333 +==== ====
334 +
269 269  ==== 3.1.3.1 差距分析 ====
270 270  
337 +
271 271  差距分析用于将当前状态与期望状态进行比较。该分析的输出突出显示了两种状态之间差距的性质和范围，并且为计划提供基础使得组织更加接近实现目标。
272 272  
273 273  《AgileSHIFT™指南》（AXELOS，2018年）将此差距称为“增量”。可以通过考虑以下因素来理解增量：
... ... @@ -313,8 +313,12 @@
313 313  图片3.1 SWOT分析
314 314  
315 315  
383 +(% class="wikigeneratedid" %)
384 +==== ====
385 +
316 316  ==== 3.1.3.2 SWOT分析 ====
317 317  
388 +
318 318  SWOT分析可以识别优势、劣势、机遇和威胁。它是确定组织的内部和外部威胁并显示其与竞争对手有何不同的最古老的方法之一。
319 319  
320 320  优势和劣势是影响组织朝着目标前进的能力的内部因素。威胁和机遇是控制之外的外部因素，但是规划进行更改和改进时必须考虑这些因素。
... ... @@ -344,8 +344,15 @@
344 344  SWOT分析是主观的。
345 345  )))
346 346  
418 +(% class="wikigeneratedid" %)
419 +==== ====
420 +
421 +(% class="wikigeneratedid" %)
422 +==== ====
423 +
347 347  ==== 3.1.3.3 变更准备评估 ====
348 348  
426 +
349 349  变更准备评估对组织准备过渡到一种新工作方式的评估。有许多影响因素会影响组织、部门或团队成功适应变化的能力。在启动变更举措之前，评估这些因素突出显示了其可能成为阻碍其成功的因素。
350 350  
351 351  一个善于接受这种变更并过渡到新的工作方式的组织，是最有可能实现持续改进的潜力组织。如果每个变更都遇到阻力，变更的驱动力会动摇，并可能最终失败。变更准备评估将提供信息，这将有助于指导可能影响变更举措成功的活动。
... ... @@ -379,8 +379,15 @@
379 379  确定成功变更的障碍并不意味着组织可以或将解决这些障碍。
380 380  )))
381 381  
460 +(% class="wikigeneratedid" %)
461 +==== ====
462 +
463 +(% class="wikigeneratedid" %)
464 +==== ====
465 +
382 382  ==== 3.1.3.4 客户/用户满意度分析 ====
383 383  
468 +
384 384  对于大多数改进而言，了解客户和用户的满意度水平是有价值的输入。当计划迭代更改时，重要的是要考虑它们将对客户和用户产生的影响。完变更之后，确定满意度的水平是否已按预期提高就很重要。
385 385  
386 386  根据服务的类型，用户和客户的角色可以由不同的人员或组合完成。在后一种情况下，客户旅程、客户体验和客户满意度可能与用户的不同。因此，他们可能需要对评估和分析使用不同的方法。
... ... @@ -404,8 +404,15 @@
404 404  请求客户和用户的时间可能会严重影响响应。
405 405  )))
406 406  
492 +(% class="wikigeneratedid" %)
493 +==== ====
494 +
495 +(% class="wikigeneratedid" %)
496 +==== ====
497 +
407 407  ==== 3.1.3.5 SLA绩效分析 ====
408 408  
500 +
409 409  |(((
410 410  定义：服务级别协议（SLA）
411 411  
... ... @@ -435,8 +435,15 @@
435 435  与SLA达成相关问题的根本原因可能很难发现且难以解决。
436 436  )))
437 437  
530 +(% class="wikigeneratedid" %)
531 +==== ====
532 +
533 +(% class="wikigeneratedid" %)
534 +==== ====
535 +
438 438  ==== 3.1.3.6 基准测试 ====
439 439  
538 +
440 440  基准测试是将组织的产品、服务或实践的性能或绩效与类似的组织的产品、服务或实践进行度量的行为。将一个组织与一个表现更好的组织进行比较，可能会突出能够产生切实改进的变更措施。基准测试应该作为持续改进实践的一部分定期进行，以使组织达到或超过竞争对手的性能。它在组织可以成为其他组织对其进行衡量的标准的前提下，也是激励文化变更的宝贵工具。
441 441  
442 442  尽管基准测试通常是在组织级别完成的，但比较高性能组织的特定领域可能更有价值。例如，一个问题经理可能想了解另一个具有较低重大事件发生率的组织在其问题管理实践中的不同之处。与扮演类似角色的对手交谈可以提供有价值的洞察力，这可能会带来有价值的改进倡议。
... ... @@ -464,8 +464,15 @@
464 464  旨在确定行业领导者，从而导致标准化但不一定理想的行为。
465 465  )))
466 466  
566 +(% class="wikigeneratedid" %)
567 +==== ====
568 +
569 +(% class="wikigeneratedid" %)
570 +==== ====
571 +
467 467  ==== 3.1.3.7 成熟度评估 ====
468 468  
574 +
469 469  成熟度评估是对能力进行评估（通常是流程或组织），用于与成熟度的框架、模型或等级相比较，用于评估的参考模型通常包括多个级别，每个级别描述特定的实践或整个组织的特性。
470 470  
471 471  成熟度评估结果作为成熟度评级与支持证据的详细描述一起出现。组织必须决定评估的成熟度是否可接受；如果不是，则应寻求改进。
... ... @@ -489,8 +489,18 @@
489 489  风险是目标在于提高成熟度的水平，而不是改进组织或流程。
490 490  )))
491 491  
598 +(% class="wikigeneratedid" %)
599 +=== ===
600 +
601 +(% class="wikigeneratedid" %)
602 +=== ===
603 +
604 +(% class="wikigeneratedid" %)
605 +=== ===
606 +
492 492  === 3.1.4 定义评估目标和准则 ===
493 493  
609 +
494 494  了解任何评估的目标都是至关重要的。如果要使用多种类型的评估方法，则必须明确定义每个评估的角色。如果其目标过于广泛，则评估可能会很昂贵且耗时。但是，狭窄的范围不太可能传递足够的信息。
495 495  
496 496  提出并回答某些问题将有助于定义每个评估的关键元素，并确保它们与改进的高级愿景保持一致。特别是，每个评估目的必须经过同意并明确定义。否则以下问题将无法获得有意义的回答。
... ... @@ -531,8 +531,15 @@
531 531  当将评估用作正在进行的管理工具时，至少应每年重新评估一次此信息，以确保所使用的方法仍然有效。
532 532  
533 533  
650 +(% class="wikigeneratedid" %)
651 +=== ===
652 +
653 +(% class="wikigeneratedid" %)
654 +=== ===
655 +
534 534  === 3.1.5 进行评估并产生输出 ===
535 535  
658 +
536 536  评估通常是与第三方执行的，但是变更推动者本身必须定义每个评估的目标和范围。一种常见的方法是使用独立的评估程序，因为它们是组织的新手，因此他们常常注意到变更推动者错过的改进机会。
537 537  
538 538  必须仔细考虑使用第三方进行评估是否合适。不这样做可能会节省资金，但可能不会产生所需的结果。在决定是否使用第三方时，请考虑以下几点：
... ... @@ -558,8 +558,18 @@
558 558  
559 559  
560 560  
684 +(% class="wikigeneratedid" %)
685 +== ==
686 +
687 +(% class="wikigeneratedid" %)
688 +== ==
689 +
690 +(% class="wikigeneratedid" %)
691 +== ==
692 +
561 561  == 3.2 计划的基础 ==
562 562  
695 +
563 563  在任何组织或团队中，计划可以更好地理解实现目标所需的资源。计划在不知道需要什么新资源或更改资源的情况下更改工作方式将导致不良后果。
564 564  
565 565  计划必须先于性能或绩效，但不应过高到“分析瘫痪”的地步，在该分析中，计划花了太多时间，并制定了策略，使性能或绩效从未启动。敏捷的工作方式鼓励人们着眼于在完美结果之前创建最小可行产品（MVP），特别是避免这种计划的危害。
... ... @@ -569,8 +569,12 @@
569 569  在工作流程的计划阶段，重要的是要问：“此计划如何与我们的总体战略保持一致？”无论计划看起来多么小或看起来似乎无关紧要，它都应该有助于实现组织的战略目标。计划如果没有这样运行，则可能不值得。
570 570  
571 571  
705 +(% class="wikigeneratedid" %)
706 +=== ===
707 +
572 572  === 3.2.1 利用计划中的不同工作方式 ===
573 573  
710 +
574 574  计划可以采用多种形式，可以利用多种工作方式。计划可以采用的最为熟悉和结构化的形式是项目计划，它可以涵盖多年的工作，其子项目计划和相互依赖的阶段需要数十个人的参与。但是，计划也可以像个人的待办事项清单一样简单。
575 575  
576 576  项目计划可以包括不同的工作方式，具体取决于计划的类型、计划的目标和限制以及相关人员的经验。本部分将介绍探索的三种著名的工作方式：瀑布法、敏捷法和混合法。尽管这些工作方式最初是为在IT 开发项目中使用而创建的，但它们的关键特性也适用于许多其他内容和范围。
... ... @@ -590,8 +590,12 @@
590 590  |很多方面依赖其他SVS的系统、服务或元素|项目的主题区域或者独立，或者少有依赖|有一些依赖关系，但它们是易于理解和管理
591 591  |团队成员是只担任一个角色|团队成员灵活且能够担任多个角色|团队成员有专长，但也能够跨角色和在小团体
592 592  
730 +(% class="wikigeneratedid" %)
731 +==== ====
732 +
593 593  ==== 3.2.1.1 瀑布 ====
594 594  
735 +
595 595  使用传统瀑布式方法的计划分为不同的阶段。在每个阶段都完成并且产品处于最终状态之前，项目或计划的输出无法交付。在每个阶段结束时，都会进行一次评审，以评估项目的状态，并确定下一阶段是否可以开始。这些检查点有时被称为项目里程碑。
596 596  
597 597  基于瀑布的工作流旨在项目结束时能够提供近乎完美的解决方案。瀑布式方法有许多优点，在某些特定情况下，它是一种最佳的工作方式。例如，瀑布式开发技术很可能用于系统不完整或有故障会导致严重后果的情况。但是，这种工作方式的主要缺点与技术变更的快速发展有关。用这种方法管理的项目通常需要很长时间才能完成，这意味着该技术可能会在最终使用之前超过最终的输出。
... ... @@ -605,8 +605,12 @@
605 605  ● 阶段一次完成，没有重叠，允许检查点验证进度。
606 606  
607 607  
749 +(% class="wikigeneratedid" %)
750 +==== ====
751 +
608 608  ==== 3.2.1.2 敏捷 ====
609 609  
754 +
610 610  敏捷的工作方式将项目组织成小的独立单元，称为迭代或冲刺。每个冲刺通常会持续一到三周，并将重点放在该时间段内可以完成和交付的工作上。敏捷规划专注于确定每个冲刺可以完成什么，构建可重复的流程，并帮助团队了解他们在短期内可以实现多少。
611 611  
612 612  以敏捷的工作方式，团队不会立即尝试计划或交付大型生产。他们用计划交付体积更小、功能更强大的产品，这些产品将用较短的时限范围满足客户的需求。
... ... @@ -622,8 +622,12 @@
622 622  ● **更高的客户满意度**： 敏捷团队与客户紧密合作，可以提供快速的反馈和更改，以适应他们不断发展的需求。
623 623  
624 624  
770 +(% class="wikigeneratedid" %)
771 +==== ====
772 +
625 625  ==== 3.2.1.3 混合法 ====
626 626  
775 +
627 627  有几种将瀑布式和敏捷方法混合为一种方法的方法。通用方法使用类似于瀑布项目的整体分阶段结构，将需求收集在单个阶段中，然后是高级设计。但是，开发工作是在冲刺中进行的迭代，使用反馈来验证成功并相应地调整即将到来的冲刺。但是，与真正的敏捷项目不同，最终的输出都是在项目的末尾一次性发布的，而不是在每个冲刺的末尾发布的。
628 628  
629 629  混合法工作方式的好处包括：
... ... @@ -635,8 +635,15 @@
635 635  ● 对于习惯瀑布式但想学习如何敏捷工作的团队来说，它可以是一种中间方法。
636 636  
637 637  
787 +(% class="wikigeneratedid" %)
788 +=== ===
789 +
790 +(% class="wikigeneratedid" %)
791 +=== ===
792 +
638 638  === 3.2.2 监控计划的进展 ===
639 639  
795 +
640 640  不管使用哪种方法，都要定期测量针对计划需求的进度。必须监视和调整计划，即便是瀑布计划和混合法型计划，以确保不需要外部因素进行更改。例如，计划中面向客户的服务可能需要快速修改，以应对竞争对手利用的新技术。如果无法调整计划，则其输出将在交付之前被淘汰。
641 641  
642 642  敏捷的基本前提是，它可以快速地向变更定向，而不会失去动力。在敏捷项目的生命周期内，监控的外部影响和内部压力至关重要。在交付计划的每个迭代时，相关利益相关者提供的监控反馈将指示所需方向的任何变化。
... ... @@ -654,8 +654,18 @@
654 654  //PRINCE2 Agile//® (AXELOS, 2015) 为组织提供了适当的结构和治理模型，使团队能够以敏捷的方式工作。
655 655  )))
656 656  
813 +(% class="wikigeneratedid" %)
814 +== ==
815 +
816 +(% class="wikigeneratedid" %)
817 +== ==
818 +
819 +(% class="wikigeneratedid" %)
820 +== ==
821 +
657 657  == 3.3 价值流图简介 ==
658 658  
824 +
659 659  价值流图是一种将从需求或机会流动到价值可视化的方法，然后在可视化如何规划中改进流动。该方法起源于精益制造技术，但同样适用于产品和服务的创建和交付，如ITIL®4：创建、交付和支持中所述。提供产品和服务时有许多价值流。可以在价值流图中定义用于快速恢复服务，以约定的可用性级别交付服务或管理服务变更的实现价值流程。对于利益相关者，组织所做的一切都应直接或间接映射到价值。
660 660  
661 661  价值流图用于深入了解组织工作流。它可以帮助识别价值流中的添加价值的活动和不添加价值的活动，同时突出显示优化和自动化的机会。价值流图包括评估（记录了从需求到价值的工作流的当前状态）和规划（规划，将对改进对该工作流进行哪些更改）。然而，价值流图最重要的作用是确定必须实施哪些改进行动才能达到预期的未来状态。
... ... @@ -665,8 +665,12 @@
665 665  价值流通常跨越许多合作伙伴，供应商和服务消费者组织。但是，对于价值流图来说，新的组织可能需要简单地开始，重点放在组织本身内的价值流的那些方面。随着时间的推移，它可以扩展其价值流图的范围，从而找到更多的优化机会。
666 666  
667 667  
834 +(% class="wikigeneratedid" %)
835 +=== ===
836 +
668 668  === 3.3.1 精益 ===
669 669  
839 +
670 670  精益和价值流图密切相关。精益的核心思想是最大化客户价值，同时最大程度地减少浪费。简而言之，精益意味着用更少的资源为服务使用者创建更多的价值。
671 671  
672 672  应当充分利用各种类型的资源，尤其是人力资源。任何浪费的东西都应该消除，技术应该被最大程度地利用。人为干预只能在确实有助于价值的地方进行。
... ... @@ -674,8 +674,12 @@
674 674  精益旨在通过零浪费的完美价值创造流程提供完美的价值。精益思想鼓励管理层关注的不是孤立的技术、资产和部门，而是通过整个价值流优化产品和服务的流动，这些价值流水平地跨技术、资产和部门流向服务消费者。
675 675  
676 676  
847 +(% class="wikigeneratedid" %)
848 +=== ===
849 +
677 677  === 3.3.2 避免局部优化 ===
678 678  
852 +
679 679  在许多组织中，专注于单个流程可以优化小型控制范围中的流程中的步骤，例如针对单个团队或部门，同时忽略更改对整个价值流的影响。局部优化会导致在价值流的更下方创建瓶颈，并使整个性能或绩效变差，而不是变好。
680 680  
681 681  消除整个价值流中的浪费，而不是孤立地消除浪费，创造了需要更少人力、空间、资本和时间的流程，从而以更低的成本和更少的缺陷制造产品和服务。
... ... @@ -683,8 +683,12 @@
683 683  价值流图是优化整个价值链的出色工具。较大的视图与“通盘思考和工作”的导向原则完美对齐。
684 684  
685 685  
860 +(% class="wikigeneratedid" %)
861 +=== ===
862 +
686 686  === 3.3.3 价值流图的价值 ===
687 687  
865 +
688 688  价值流图很有价值，因为它能够：
689 689  
690 690  ● 帮助组织可视化超过生产中的单个流程级别
... ... @@ -698,8 +698,12 @@
698 698  ● 帮助计划和文档改进。
699 699  
700 700  
879 +(% class="wikigeneratedid" %)
880 +=== ===
881 +
701 701  === 3.3.4 开发价值流图 ===
702 702  
884 +
703 703  |(((
704 704  定义：价值流图
705 705  
... ... @@ -741,8 +741,12 @@
741 741  随着计划改进的实施，将来的状态价值流图变为当前的状态价值流图。价值流图是迭代的，应将价值流重新映射为工作方式和其他因素变更。
742 742  
743 743  
926 +(% class="wikigeneratedid" %)
927 +==== ====
928 +
744 744  ==== 3.3.4.1 增加价值流图中的细节 ====
745 745  
931 +
746 746  通过详细介绍流动的步骤来映射价值流。最初，添加了基本信息，以便需求对其进行研究的任何人都可以理解价值流图。这包括概述价值流的输入和输出。
747 747  
748 748  但是，仅提供高级信息还不够。价值流图需要更加具体，以便进行详细分析。当在映射中定义逻辑和可衡量的步骤时，量化工作流程和识别浪费将变得更加容易。
... ... @@ -759,8 +759,12 @@
759 759  图片3.2 价值流图符号
760 760  
761 761  
948 +(% class="wikigeneratedid" %)
949 +=== ===
950 +
762 762  === 3.3.5 价值流图中的典型错误 ===
763 763  
953 +
764 764  表3.19概述了与价值流图相关的典型错误。
765 765  
766 766  表3.19 价值流图中的典型错误
... ... @@ -780,8 +780,15 @@
780 780  [[image:1639210933547-115.png]]
781 781  
782 782  
973 +(% class="wikigeneratedid" %)
974 +== ==
975 +
976 +(% class="wikigeneratedid" %)
977 +== ==
978 +
783 783  == 3.4 总结 ==
784 784  
981 +
785 785  评估是任何持续改进历程的关键部分：定义评估的目标，适当地设定范围以及了解如何从当前状态过渡到未来状态至关重要。如果您在改进的每个迭代之后都使用另一个评估来验证您的结果，那么当规划计划的下一阶段时，这将有所帮助。
786 786  
787 787  
深圳市艾拓先锋企业管理咨询有限公司