Last modified by superadmin on 2024/04/03, 16:11
From version < 38.3 >
edited by roll tech
on 2022/08/05, 11:29
To version < 40.1
edited by superadmin
on 2024/04/03, 16:11
<
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.RollTech
1 +XWiki.superadmin
Content
... ... @@ -7,13 +7,14 @@
7 7  {{toc/}}
8 8  {{/box}}
9 9  
10 -= 4. 创建、交付和支持服务的价值流 =
10 += **4. 创建、交付和支持服务的价值流** =
11 11  
12 +
12 12  本章节提供了有关如何：
13 13  
14 14  * 记录一个价值流以理解工作流程如何贯穿该组织
15 15  * 了解创建一个新服务的原型价值流
16 -* 了解支持一个现场服务的原型价值流服务
17 +* 了解支持一个现场服务的原型价值流
17 17  
18 18  本章将帮助从业者理解：
19 19  
... ... @@ -20,14 +20,15 @@
20 20  * 价值流在 服务价值系统(SVS) 中的作用
21 21  * 价值流的分类
22 22  * 如何阐述一个价值流中存在的步骤
23 -* 如何将常见的数学模型理论应用于简化价值流
24 +* 如何将常见的数学建模理论应用于简化价值流
24 24  * 当设计一个价值流时需要考虑的内容
25 25  
26 -从业者必须要理解：价值流是简单易做的，但不一定是简化的工作表现形式 不同种类的工作遵循着不同的路线，因此也有着很多种不同的价值流它们既可以指代设计或理想的活动模式，也可以表达实际的、可观察的活动模式。相同的资源，如个人、工具、供应商、或流程，可以出现在价值流的不同部分；例如，一个运维专员可以是用户参与的一部分，支持调查，并部署修复程序以恢复服务
27 +实践者必须要理解：价值流是简单易做的，但不一定是简化的工作表现形式。 不同种类的工作遵循着不同的路线，因此也有着很多种不同的价值流它们既可以指代设计或理想的活动模式，也可以表达实际的、可观察的活动模式。相同的资源，如个人、工具、供应商、或流程，可以出现在价值流的不同部分；例如，一个运维专员可以是用户契动，支持调查，为恢复服务部署修复程序这些活动中的一部分。
27 27  
28 28  
29 29  == 4.1 ITIL服务价值流 ==
30 30  
32 +
31 31  ITIL价值链包括六种原型活动： 参与、计划、改进、设计和移交、契动和交付和支持。一种思考价值流的有用方法是：通过服务中的活动的旅程的可视化特定场景或需求类型的价值链。例如：
32 32  
33 33  * 不同类型的事件可能需要不同的价值流去描述每种情况下所需的工作，例如：
... ... @@ -39,6 +39,7 @@
39 39  ** 一个要求团队成员访问产品或服务的请求
40 40  ** 一个要求新的基础设施能力以保留产品或服务正常运行的请求。
41 41  
44 +
42 42  === 4.1.1 ITIL 服务价值流的结构 ===
43 43  
44 44  |(((
... ... @@ -91,6 +91,7 @@
91 91  
92 92  === 4.1.2 价值流和组织 ===
93 93  
97 +
94 94  ITIL 4 并不将组织等同于公司实体。组织可以是一个人（例如个体经营者程序员或顾问）、团队（例如开发或支持作为业务单位的团队）、企业，甚至企业协同工作的生态系统.
95 95  
96 96  价值流从根本上与组织有关。因此，每个颗粒度的层次都可能存在价值流，它们可以为单个人、一个团队、一个业务部门等。但是，重要的是要记住该价值流是被所建立的系统的环境定义的，而其目的是为组织、其客户和其他利益相关者创造价值。一个大型企业可以包括几个不同的拥有一定程度的自主权管理的组织，可以将它们中的每一个都视为具有自身价值的 服务价值系统(SVS)价值链和价值流。但是，其自给自足的可能性不大服务价值系统(SVS) 需要在团队级别建立。
... ... @@ -126,6 +126,7 @@
126 126  * 协作并提升跨组织和团队工作流程的可见性
127 127  * 通过了解更广泛的组织或生态系统如何运作和受益以及参与方所做的工作，整体思考和工作。
128 128  
133 +
129 129  === 4.1.3 价值流注意事项 ===
130 130  
131 131  
... ... @@ -139,8 +139,10 @@
139 139  * 更新价值流文档以反映实际的工作模式
140 140  * 通过减少转换时间来优化工作流程将需求转化为价值，并自动化可重复的工作。
141 141  
147 +
142 142  ==== 4.1.3.2 起点和终点 ====
143 143  
150 +
144 144  价值流始终以需求为开始，以为一个或多个利益干系人创建价值或实现价值而结束。因此，一种可取的方式是在记录价值流时，应保持一种由外而内的声音，例如，通过以下方式：
145 145  
146 146  * 能够反映业务计划的里程碑和时间表
... ... @@ -147,18 +147,25 @@
147 147  * 能够使用与观众相关的语言
148 148  * 从客户或用户的角度构建成果和价值。
149 149  
157 +==== ====
158 +
159 +==== ====
160 +
150 150  ==== 4.1.3.3 灵活性 ====
151 151  
163 +
152 152  根据执行工作的背景和环境，价值流重复使用价值链中的活动。价值流可以根据组织的需要而灵活定制。例如：组织可以在工作期间添加某一阶段，类似于瀑布方法，或者在价值链活动之间创建迭代循环。
153 153  
154 154  
155 155  ==== 4.1.3.4 颗粒度 ====
156 156  
169 +
157 157  价值流在一定程度上可以体现工作的颗粒度。例如：使用敏捷软件活动的价值流可以展示出多个工作迭代，从而反映出该方法所具备的探索性质。或者，价值流可以体现更高层次的视角，该视角允许工作表示为一个步骤。无论工作如何表示，在整个价值流中，颗粒度保持统一是至关重要的。
158 158  
159 159  
160 160  ==== 4.1.3.5 识别步骤 ====
161 161  
175 +
162 162  价值流应该使用哪些步骤，这些步骤应该包括什么活动，在决策时应该考虑以下几点：
163 163  
164 164  * 价值流的详细程度。组织需要决定应显示所有操作的详细信息，还是仅提供工作概述。
... ... @@ -165,6 +165,7 @@
165 165  * 个人或团队之间的工作交接会对价值流产生的影响。通常最好将不同团队执行的活动显示为不同的步骤。这有助于了解队列中哪些工作存在延迟。
166 166  * 对价值流产生影响的价值链中的多个活动。
167 167  
182 +
168 168  **包括多个价值链活动**
169 169  
170 170  如果一个步骤同时包含契动和计划两个活动，更合理的方式是将其分为两个单独的步骤。例如：步骤“确定客户需求”可以分为：
... ... @@ -182,25 +182,31 @@
182 182  
183 183  ==== 4.1.3.6 步骤顺序 ====
184 184  
200 +
185 185  尽管价值流通常以契动作为活动的开始，但其他活动也可以作为第一步。例如，如果工程师通过监控工具发现的事件（需求），则第一步活动可能是开始调查（交付和支持），这种情况不太可能去直接联系受影响的客户（契动）。
186 186  
187 187  
188 188  ==== 4.1.3.7 映射到服务价值链 ====
189 189  
206 +
190 190  价值流的步骤可以通过映射到价值链的活动中进行描述，其实价值链的活动也是通过基础性活动或任务的映射进行描述。例如：
191 191  
192 192  * 评估客户需求的步骤可以映射到价值链中的计划活动，但是也可以映射到价值链中契动活动的被称为 “与客户一起完善需求”的活动或任务。
193 193  * 从供应商网站下载补丁程序的步骤可以映射到价值链中的获取/构建活动，但是也可以映射到价值链中的改进活动的被称为“更新解决方法”的活动或任务。
194 194  
212 +
195 195  ==== 4.1.3.8 映射到实践 ====
196 196  
215 +
197 197  可以根据颗粒度级别，将价值流中的步骤、活动或任务映射到实践中的流程或过程。例如，开发部署代码的步骤可以映射到以下的活动和任务：
198 198  
199 199  * 执行自动化测试的程序
200 200  * 执行人工测试的流程
201 201  
221 +
202 202  === 4.1.4 设计服务价值流 ===
203 203  
224 +
204 204  鼓励从业人员使用以下方法或尝试其他方法，以确保满足组织需求。
205 205  
206 206  1、通过以下内容定义价值流的用例或场景：
... ... @@ -236,8 +236,10 @@
236 236  * 识别并管理瓶颈或约束，这可能需要围绕约束重新设计价值流
237 237  * 引入审查触发机制，必要时改进价值流。（审查可以是随机的”例如：可以在消费者反馈时“，也可以是定期进行。）
238 238  
260 +
239 239  === 4.1.5 描述价值流的步骤 ===
240 240  
263 +
241 241  在描述价值流中的步骤时，需要识别并记录以下内容：
242 242  
243 243  * **步骤名称 **定义步骤是什么。决定是否要使用非技术语言描述该步骤。避免使用首字母缩写词和行话，以便价值流评估人可以轻松地理解其目标是什么；例如：
... ... @@ -290,6 +290,7 @@
290 290  
291 291  === 4.1.6 价值流映射 ===
292 292  
316 +
293 293  价值流映射起源于精益制造技术。这是一种从需求机会到价值实现的可视化工作流，其工作流可有计划地持续改进。在精益中，核心思想是最大化客户价值，同时将浪费最小化。简而言之，精益涉及以更少的资源为服务消费者创造更多价值。精益组织了解服务对消费者的价值，并将其关键流程集中在增加价值上。
294 294  
295 295  我们的目标是通过不产生任何浪费的完美价值创造过程为服务消费者提供完美价值。为实现这个目标，精益思想通过将横跨技术、资产和部门的水平价值流，将管理的重点从优化单独的技术、资产和垂直部门转变为对消费者的产品和服务的流程进行优化。
... ... @@ -321,6 +321,7 @@
321 321  
322 322  === 4.1.7 分析价值流时的关键指标 ===
323 323  
348 +
324 324  可以为任何工作流程和活动定义以下几个重要的指标。这些在表4.3中概述，并在图4.2中显示。
325 325  
326 326  表格 4.3 工作流程指标
... ... @@ -373,7 +373,9 @@
373 373  * 根据粒度级别和工作性质，节点周期可以假定认为是固定的和可预测的。
374 374  * 为了创建更可预测的节点周期，可能有必要限制在制品数量。该技术是看板方法的一部分，在可预测吞吐量（工作量）的环境中效果很好。例如，一个团队可能一次将其在制品限制为三个请求，因此，如果在制品超过此限制，则延迟处理任何其他请求。
375 375  
376 -**ITIL 故事: ITIL 服务价值流**
401 +(% class="box" %)
402 +(((
403 +(% id="cke_bm_1975S" style="display:none" %)** **(%%)**ITIL 故事: ITIL 服务价值流**
377 377  
378 378  [[image:1640086134907-348.png||height="53" width="37"]]**亨利:**//艾克苏汽车租赁采用服务价值流来绘制整个组织的工作流程。价值流展示了组织如何利用信息、工具、流程和其他结构化的工作方式来创建产品和服务。它们有助于我们通过任何给定场景或利益相关者的价值链活动形象化过程；例如，当我们为用户创建新功能或为客户服务台更新脚本时。//
379 379  
... ... @@ -380,10 +380,12 @@
380 380  [[image:1640086144239-177.png||height="53" width="42"]]**索尔马兹: **//我们利用ITIL的服务价值流帮助我们的员工、合作伙伴和供应商了解如何为客户创造价值。我们定期审查我们的价值流，以确定改进运营的方法。//
381 381  
382 382  [[image:1640086152411-881.png||height="55" width="39"]]**雷尼: **//我们将利用从试点中吸取的经验教训，通过价值流的使用，规范我们如何应对常见问题。我们已经确定了两个需要优先考虑的场景：新功能的开发，以及当客户体验到服务降级时我们向他们提供的支持级别。在我们的待办事项中还有许多其他场景；例如，自行车归还时服务缓慢。//
410 +)))
383 383  
384 384  
385 385  == 4.2 价值流模型用于创建、交付和支持 ==
386 386  
415 +
387 387  本节探讨了几乎在所有组织中都可以找到的两种常见的价值流模型：
388 388  
389 389  * **新服务的开发  **组织经常发现有必要创建、修改或淘汰服务。这种价值流反映了创建新服务所需的常见工作模式，因此通常需要在整个组织中付出大量的努力和协调。
... ... @@ -400,13 +400,16 @@
400 400  * 合作伙伴和供应商  为组织等提供产品和服务的供应商。
401 401  * 价值流和流程  流程，过程，模板等
402 402  
432 +
403 403  === 4.2.1 开发新服务 ===
404 404  
435 +
405 405  这种价值流原型研究组织在创建新服务或修改现有服务时的常规活动。它与服务的性质无关，可以用来描述用于创建服务的价值流，这些服务可以提供给组织内部的客户，也可以提供给组织外部的客户。
406 406  
407 407  
408 408  ==== 4.2.1.1 设计考虑 ====
409 409  
441 +
410 410  设计此值流时，典型的注意事项包括：
411 411  
412 412  * 确定如何管理工作。使用顺序瀑布阶段应对较大的增量，或以快速反馈的方式在短时间内更改规格（例如敏捷方法）应对较小的增量，或者两者混合？根据工作的管理方式，可能有必要创建单独的价值流，并在每个价值流中描述不同的项目管理方法。
... ... @@ -416,8 +416,10 @@
416 416  * 确保组织对客户的预期目标和期望有清晰的了解，并从头到尾跟踪每个目标和期望，以确保服务支持所需的结果。在将客户需求转换为服务成果（功能性或非功能性）时，组织应避免引入冲突或不一致。
417 417  * 了解客户从需求到价值的过程，并从客户的角度定义需求，而不是仅仅依靠内部视角或团队成员的先前经验。
418 418  
451 +
419 419  ==== 4.2.1.2 从需求到价值的旅程 ====
420 420  
454 +
421 421  此价值流通过六个关键步骤描述了从需求出发的过程（如图4.5所示）：
422 422  
423 423  1. 确认并记录服务要求（契动）
... ... @@ -436,6 +436,7 @@
436 436  
437 437  ==== 4.2.1.3 需求和价值 ====
438 438  
473 +
439 439  此价值流是由创建新服务的需求触发的。它可能来自：
440 440  
441 441  * 服务消费者：赞助商、客户或用户。服务消费者可以在服务提供者外部，也可以是同一组织的成员，取决于具体环境。
... ... @@ -454,6 +454,7 @@
454 454  * 作为业务开发经理，我想跟踪我的销售流水线，以便专注于完成新交易。
455 455  * 作为基础架构工程师，我希望能够对报警通知进行分组，以便可以关联警报并消除重复项。
456 456  
492 +
457 457  ===== 步骤1：确认并记录服务需求 =====
458 458  
459 459  (% style="text-align:center" %)
... ... @@ -471,6 +471,7 @@
471 471  * **服务配置管理 **提供有关当前运行的服务和服务组件的信息，以便在描述需求时提供内容。
472 472  * **服务级别管理 **提供有关当前服务级别的信息，以在描述需求时提供内容。
473 473  
510 +
474 474  ===== 步骤2：决定是否投资新服务 =====
475 475  
476 476  (% style="text-align:center" %)
... ... @@ -479,6 +479,7 @@
479 479  
480 480  当请求细化并记录在业务案例中后，可能有必要澄清初始成本、收益和风险评估，以便服务组织可以计划工作。这将需要与各个内部团队进行更详细的讨论，并可能需要与客户和其他外部利益相关者进行持续的对话。完成后，管理团队可以评估业务案例，然后由管理团队决定是否授予批准。
481 481  
519 +
482 482  通常对此步骤有贡献的实践包括：
483 483  
484 484  * **业务分析 **提供与各种专家团队合作所需的技能、工具和其他资源，针对业务案例中记录的客户需求，收集补充信息并进行可行性分析。
... ... @@ -494,6 +494,7 @@
494 494  * **服务级别管理 **提供有关当前服务级别以及新功能可能带来变更的信息。
495 495  * **软件开发和管理 **提供有关设计和开发新服务的软件组件的补充评估，以及对运行的应用程序活动影响的补充评估。根据需要，为业务案例评估做出贡献。
496 496  
535 +
497 497  ===== 步骤3：设计和架构师新服务以满足客户需求 =====
498 498  
499 499  (% style="text-align:center" %)
... ... @@ -522,6 +522,7 @@
522 522  * **软件开发和管理  **提供所需的技能、工具和其他资源，以根据服务设计包中的规范，创建和提炼重要事情和用户故事列表。
523 523  * **供应商管理  **协助与合作伙伴和供应商进行互动，并选择新供应商采购服务组件。
524 524  
564 +
525 525  ===== 步骤4：构建、配置或购买服务组件 =====
526 526  
527 527  (% style="text-align:center" %)
... ... @@ -552,6 +552,7 @@
552 552  * **软件开发和管理**  提供所需的工程技能，工具和其他资源，用以创建新应用程序功能并将新系统和其他软件组件集成到现有服务。
553 553  * **供应商管理**  协助与合作伙伴和供应商进行互动，并选择新的供应商来采购服务组件。
554 554  
595 +
555 555  ===== 步骤5：部署服务组件以准备启动 =====
556 556  
557 557  (% style="text-align:center" %)
... ... @@ -582,6 +582,7 @@
582 582  * **服务台** 确保在新特性，已知缺陷和解决方法方面对所有面向客户的支持角色进行了充分的培训。
583 583  * **供应商管理** 在与合作伙伴及供应商的交互，以及选择提供服务组件的新供应商方面提供帮助。
584 584  
626 +
585 585  ===== 步骤6：为客户和用户提供发布新服务 =====
586 586  
587 587  (% style="text-align:center" %)
... ... @@ -615,13 +615,17 @@
615 615  * 与请求者互动，以识别新服务中的任何差距，或价值流活动中未发现的任何结果，成本和风险。
616 616  * 找出改进服务、价值流，以及积累实践的机会。
617 617  
660 +
661 +
618 618  === 4.2.2 恢复现有服务 ===
619 619  
664 +
620 620  此价值流模型检查组织为支持现有服务而进行的典型活动。此场景与服务的性质无关，可用于描述各类为组织内外部消费者提供支持服务的价值流。
621 621  
622 622  
623 623  ==== 4.2.2.1 设计考虑因素 ====
624 624  
670 +
625 625  设计此值流时，典型的注意事项包括：
626 626  
627 627  * 识别利益干系人，以及价值的创造或恢复对他们意味着什么，例如：
... ... @@ -633,8 +633,10 @@
633 633  * 强调合作伙伴和供应商执行的活动，这些活动可能会给成功创造或恢复价值引入风险或依赖关系。
634 634  * 了解应集成哪些（或如何集成）系统，并在多个活动中心之间共享数据。
635 635  
682 +
636 636  ==== 4.2.2.2 需求和价值 ====
637 637  
685 +
638 638  此价值流由无法使用现有产品或服务的用户触发。8由于服务消费者无法从次优产品或服务中获取最大价值，生产力的损失导致产出价值下降。
639 639  
640 640  当监视工具发出预警，提醒组织出现了或对用户产生影响的故障时，需求也可能源自服务提供者。在这种情况下，价值流可能会绕过步骤1或交换步骤1和2的顺序。换句话说，如果需要，服务提供者可以：
... ... @@ -644,8 +644,10 @@
644 644  * 事件解决后与用户联系。
645 645  * 恢复价值的需求推动了这一价值流。
646 646  
695 +
647 647  ==== 4.2.2.3 从需求到价值的旅程 ====
648 648  
698 +
649 649  此价值流描述了七个关键步骤（如图4.6所示）：
650 650  
651 651  (% style="text-align:center" %)
... ... @@ -681,6 +681,7 @@
681 681  * **服务目录管理 **提供优化登记查询所需的信息，技能，工具和其他资源。
682 682  * **服务台** 提供所需的技能，工具和其他资源，以允许客户或用户联系服务支持，并使客户支持专员能够与联系人产生共情，管理与客户或用户的沟通方式，获取及传递有关预期解决时间的信息
683 683  
734 +
684 684  ===== 步骤2：调查查询，将其重新分类为事件，然后尝试将其修复 =====
685 685  
686 686  (% style="text-align:center" %)
... ... @@ -707,6 +707,7 @@
707 707  * 网络中断的原因，是风暴影响了本地电缆或卫星连接。
708 708  * 流媒体服务中止服务的原因，是客户或用户的信用卡被银行拒付。
709 709  
761 +
710 710  ===== 步骤3：从专家团队处获取修复程序 =====
711 711  
712 712  (% style="text-align:center" %)
... ... @@ -733,6 +733,7 @@
733 733  * **软件开发和管理 **根据事件的性质，提供构建或配置故障软件的修复程序所需的技能，工具和其他资源。
734 734  * **供应商管理 **根据事件的性质，提供同协助构建修复程序的关键供应商进行交互所需的技能，工具和其他资源。
735 735  
788 +
736 736  ===== 步骤4：部署修复程序 =====
737 737  
738 738  (% style="text-align:center" %)
... ... @@ -757,6 +757,7 @@
757 757  * **软件开发和管理 **根据修复程序的性质，提供配置和打包用于部署的修复程序所需的技能，工具和其他资源。
758 758  * **供应商管理 **根据事件的性质，提供与能够协助配置和打包待部署的修复程序的关键供应商进行交互所需的技能，工具和其他资源。
759 759  
813 +
760 760  ===== 步骤5：验证事件是否已解决 =====
761 761  
762 762  (% style="text-align:center" %)
... ... @@ -794,6 +794,7 @@
794 794  * **服务台 **提供使支持专员能够产生共情并管理与客户或用户的沟通渠道所需的技能，工具和其他资源。
795 795  * **服务级别管理 **提供信息以评估恢复/已达到的服务水平，以及恢复的及时性。
796 796  
851 +
797 797  ===== 步骤6：征集用户反馈 =====
798 798  
799 799  (% style="text-align:center" %)
... ... @@ -817,6 +817,7 @@
817 817  * **软件开发和管理** 根据事件的性质和解决该事件所需的步骤，提供可用于识别改进机会的相关反馈所需的技能，工具和其他资源。
818 818  * **供应商管理** 根据事件的性质和解决事件所需的步骤，提供可用于识别改进机会的相关反馈所需的技能，工具和其他资源。
819 819  
875 +
820 820  ===== 步骤7:识别整体系统改进机会 =====
821 821  
822 822  (% style="text-align:center" %)
... ... @@ -849,6 +849,8 @@
849 849  * **软件开发和管理 **提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
850 850  * **供应商管理 **提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
851 851  
908 +(% class="box" %)
909 +(((
852 852  **ITIL 故事: 用于创建、交付和支持的模型价值流**
853 853  
854 854  [[image:1640086890026-742.png||height="53" width="41"]]**雷尼:**//有多种识别，创建和记录价值流的技术。//
... ... @@ -860,10 +860,13 @@
860 860  [[image:1640086939974-916.png||height="51" width="36"]]**弗朗西斯:**//在说明价值流时，我们结合了来自试点客户的反馈，并利用了艾克苏服务组合中的现有价值流。在创建用于实现新功能的价值流时，我们使用了ITIL模板。我们将不断调整我们的价值流，使它们与客户不断变化的需求保持一致。//
861 861  
862 862  [[image:1640086890026-742.png||height="53" width="41"]]**雷尼:**//在可视化价值流之后，我们能够识别我们需要投入新服务的额外资源。例如，我们发现迫切需要能够快速轻松地取回废弃或损坏的自行车，以帮助服务顺利运行。//
921 +)))
863 863  
864 864  
924 +
865 865  == 4.3 使用价值流来定义最小可行实践 ==
866 866  
927 +
867 867  前文描述的价值流设计和文档编制技术有助于服务提供商了解工作性质和从需求到价值的流动，以及组织资源和实践为实现这种流动所做的贡献。
868 868  
869 869  同样的技术也可以用于定义从对组织或利益干系人并允许学习和持续改进的实践中所需的最小贡献集。
... ... @@ -913,14 +913,20 @@
913 913  * 降低业务的总拥有成本（TCO）
914 914  * 增加服务配置管理的投资回报。
915 915  
916 -|(((
977 +(% class="box" %)
978 +(((
917 917  **ITIL 故事: 使用价值流来定义最小可行方法**
918 918  
919 919  [[image:1640087028260-207.png||height="52" width="42"]]**雷尼: **//定义34种ITIL做法所需的最小贡献集将很有用，它将对组织或利益干系人有利。例如，我们当前的支持服务旨在提供路边援助；但是，这并不延伸到我们的客户可能希望探索的山间小道。对于最初的城市自行车车队，我们可以采用当前的做法，但是如果我们将服务组合扩展到包括山地车租赁在内，那么我们还需要扩展支持能力。//
920 920  )))
921 921  
984 +== ==
985 +
986 +== ==
987 +
922 922  == 4.4 总结 ==
923 923  
990 +
924 924  价值流是服务价值链中的一段旅程的阐述方式，表达了工作如何在组织中创建，增强或支持与服务消费者共同创造价值的产品和服务时如何在组织中流动。价值流和流程是服务管理的维度之一，描述了从需求共同创造价值所需的步骤，动作和任务。
925 925  
926 926  价值流与其上下文环境紧密关联，体现了组织的控制范围和影响，以及场景或需求类型。价值流的粒度代表沟通工作流的需要。价值流可以是线性流动的或迭代循环的。模式的选择体现工作应该如何流动的愿望，也可以体现工作如何在整个组织中流动。
深圳市艾拓先锋企业管理咨询有限公司