由 superadmin 于 2024/04/03, 17:29 最后修改
从版本< 15.1 >
由superadmin编辑
在2022/01/06, 13:18上
到版本
由superadmin编辑
在2024/04/03, 17:29上
<
修改评论 该版本没有评论

Summary

Details

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