由 superadmin 于 2024/04/03, 16:55 最后修改
从版本< 28.3 >
由superadmin编辑
在2024/03/07, 19:38上
到版本
由superadmin编辑
在2024/04/03, 16:55上
<
修改评论 该版本没有评论

Summary

Details

Icon Page properties
Content
... ... @@ -7,8 +7,9 @@
7 7  {{toc/}}
8 8  {{/box}}
9 9  
10 -= 5. 步骤3：供应 =
10 += **5. 步骤3：供应** =
11 11  
12 +
12 12  [[image:1639115614664-761.png]]
13 13  
14 14   管理需求和机会
... ... @@ -49,13 +49,18 @@
49 49  [[image:1639115675132-360.png||height="51" width="47"]]//Mariana：我们的eCampus汽车共享服务已受到大学学生和员工的欢迎。我们为普通汽车用户提供订阅会员资格，为间歇性用户提供不同的定价等级。我们的汽车是电动的，这使它们比传统的汽车更环保，因为它们排放的废气更少。另外，汽车共享会降低汽车拥有率，减少道路上的汽车行驶次数，并减少客户出行次数，因为客户会将差事合并为一次出行以最大程度地增加支出。我们为自己能提供一个干净、安全、可靠的往返于校园的其他交通选择而自豪。//
50 50  )))
51 51  
53 +== ==
54 +
52 52  == 5.1 管理需求和机会 ==
53 53  
57 +
54 54  就服务而言，需求和容量是相互关联的。服务无法存储供以后使用。当服务价值只有在服务提供者的供给满足服务使用者的需求时才能被共同创造。如果需求得不到满足，设施和资源就会浪费。同样，当需求高于容量时，也会丢失机会。为了优化服务机会，服务提供者应调整容量和影响需求。正确理解不同的客户群体和部门如何使用其服务至关重要。
55 55  
56 56  
61 +
57 57  === 5.1.1 业务活动模式 ===
58 58  
64 +
59 59  要了解如何使用服务，分析业务活动的模式很有用的。事实和图表是通过监控和日志记录生成的，反映了服务的使用情况。这些信息将有助于采取措施满足需求高峰。
60 60  
61 61  
... ... @@ -87,6 +87,7 @@
87 87  
88 88  === 5.1.2 优化容量 ===
89 89  
96 +
90 90  |(((
91 91  **容量和性能管理实践**
92 92  
... ... @@ -123,6 +123,7 @@
123 123  
124 124  === 5.1.3 成形或平滑需求 ===
125 125  
133 +
126 126  服务提供者经常受到服务需求的巨大差异和有限容量的挑战。如果不能形成与供应相匹配的需求，将导致容量投资的回报率很低。例如，服务台的训练有素的支持人员数量有限。因此，使需求与服务容量相匹配是一项重要的学科。
127 127  
128 128  
... ... @@ -137,6 +137,7 @@
137 137  
138 138  ==== 5.1.3.1 定价和计费机制 ====
139 139  
148 +
140 140  差异性收费和收益管理是使用定价和计费机制管理容量和需求的示例。这些机制可用于驱动服务使用者在服务的许多方面的行为。既然它是如此强大的工具，就应该有意识地使用它来驱动正确的行为。例如，如果云服务提供者希望其服务消费者在不需要时清除容量，则“按单位付费” 策略将正确地影响行为。
141 141  
142 142  
... ... @@ -156,8 +156,11 @@
156 156  [[image:1641543155649-541.png]]
157 157  
158 158  
168 +==== ====
169 +
159 159  ==== 5.1.3.2 服务改进点机会 ====
160 160  
172 +
161 161  服务质量取决于对改进点机会的管理。来自客户的冲突请求、糟糕的定价激励或缺乏专门的改进点预算可能是冲突的来源。因此，服务提供者必须专业地处理改进点机会。持续改进需要所有权、服务改进点预算和透明的流程，以确定如何识别、捕获、评估、优先级和处理改进点机会。
162 162  
163 163  
... ... @@ -181,8 +181,10 @@
181 181  持续改进实践指南和ITIL®4：指导计划和改进中介绍了有关如何完成结构化服务改进的详细指南。业务分析实践指南中介绍了执行业务分析的任务和技术。
182 182  
183 183  
196 +
184 184  === 5.1.4 构建客户商业案例 ===
185 185  
199 +
186 186  当需要和需求得到理解和解决时，可以起草通过新的或变更的产品和服务来满足需求的商业案例。
187 187  
188 188  
... ... @@ -261,8 +261,13 @@
261 261  * **时间不足** 如果没有足够的时间让用户参与进来，则可能导致他们的需求得不到满足。因此，该服务可能无法让用户更好地完成工作，并可能会导致负面的商业案例。
262 262  * **选择最便宜的提供者** 在这种情况下，价格和成本承受着巨大的压力，这可能会使服务提供者的利润空间很小，也可能会阻止服务提供者在不亏损的情况下保持灵活性。这可能会导致一种以牺牲价值为代价的紧张关系。
263 263  
278 +
279 +(% class="wikigeneratedid" %)
280 +=== ===
281 +
264 264  === 5.1.5 构建服务提供者商业案例 ===
265 265  
284 +
266 266  服务提供者需要构建和维护一个可盈利的、可行的商业案例。否则，服务提供者可能会赔钱，最终倒闭。在构建商业案例时，服务提供者应该考虑客户的商业案例。
267 267  
268 268  
... ... @@ -291,6 +291,8 @@
291 291  
292 292  |(((
293 293  (((
313 +
314 +
294 294  **ITIL的故事：管理需求和机遇**
295 295  
296 296  [[image:1639121261076-787.png||height="49" width="40"]]//Mariana：我们分析了我们服务的业务活动模式，发现需求在学期中期的几周内最高，而在假期期间最低。周末需求低于工作日需求。晚间曾经使用很受欢迎，但最近几个月有所下降。我们将此归功于当地政府针对学生开展的一项运动，该运动旨在告诉学生在酒精或毒品影响下开车的危险性。//
... ... @@ -305,8 +305,13 @@
305 305  )))
306 306  )))
307 307  
329 +== ==
330 +
331 +== ==
332 +
308 308  == 5.2 指定和管理客户要求 ==
309 309  
335 +
310 310  需求规范应该出现在可视化线中。理想情况下，客户应该让服务提供者参与到一个开放且透明的需求规范流程中。如果在流程中过早的密封了需求，则服务提供者可能无法形成最佳的服务并满足服务消费者需求。
311 311  
312 312  
... ... @@ -323,6 +323,8 @@
323 323  
324 324  |(((
325 325  (((
352 +
353 +
326 326  **ITIL故事：指定和管理客户要求**
327 327  
328 328  [[image:1639121261076-787.png||height="49" width="40"]]//Mariana：我们发现了新的客户需求：我们的许多客户在这一年中不得不搬家。当他们为此目的使用我们的汽车时，他们需要多次出行，并且比往常更频繁地为汽车充电。他们还将较低电荷的汽车退还，从而很难将汽车出租给下一个客户。此外，它还损害了我们提供环境可持续服务的愿景。//
... ... @@ -337,8 +337,14 @@
337 337  )))
338 338  )))
339 339  
368 +=== ===
369 +
370 +
371 +=== ===
372 +
340 340  === 5.2.1 角色和责任 ===
341 341  
375 +
342 342  明确的角色和职责是指定和管理需求的关键。权威人士必须得到识别，并说明如何捕获、表达和表示用户需求和期望。
343 343  
344 344  
... ... @@ -368,6 +368,7 @@
368 368  
369 369  === 5.2.2 管理需求 ===
370 370  
405 +
371 371  不仅应指定要求，还应在整个流程中对其进行管理和跟踪。需求所有者负责：
372 372  
373 373  * 确定利益相关方群体及其代表
... ... @@ -398,8 +398,10 @@
398 398  * 可度量性和可报告性
399 399  * 可扩展性。
400 400  
436 +
401 401  === 5.2.3 将问题与解决方案分开 ===
402 402  
439 +
403 403  我们已经说过，需求应该基于利益相关者需要。然而，指定一个解决方案，而不是将需要转换成需求可能会很有吸引力。在阐明需求时，必须将问题与解决方案分开，以考虑到解决方案无法解决潜在问题的事实。这也有助于将当前的解决方案与所有可能的未来解决方案区分开。表5.7概述了一种简单的技术来帮助完成此流程。
404 404  
405 405  
... ... @@ -424,8 +424,13 @@
424 424  图书管理员使用数据库查找图书并登记借出。
425 425  )))|(% style="width:252px" %)当我们识别问题的本质并探索解决问题的不同方法时，可以采用多种不同的解决方法，包括在线阅读，有声读物，相关文章以及内容摘要。
426 426  
464 +=== ===
465 +
466 +=== ===
467 +
427 427  === 5.2.4 最小化可行产品 ===
428 428  
470 +
429 429  在Eric Ries (Ries, 2011)所描述的精益创业方法中，关键的信息是制作一个好的商业案例的原型，并在真实的用户中进行测试，以获得反馈。对于原型设计，他依赖于最小可行产品的概念。
430 430  
431 431  
... ... @@ -446,8 +446,13 @@
446 446  [[image:1639121503640-486.png||height="50" width="38"]]**T**//omas：Mariana使用迭代的方法，Mariana发现顾客也需要手推车作为产品供应的一部分。这是她在试租拖车之前没有考虑过的事情。//
447 447  )))
448 448  
491 +=== ===
492 +
493 +=== ===
494 +
449 449  === 5.2.5  用户故事和故事映射 ===
450 450  
497 +
451 451  用户故事映射是表达服务需求的常用方法。用户故事是一种表示利益相关者所需功能领域的方式，这种方式可以在团队成员之间引起讨论和理解，帮助他们共同努力，将需求转变为有效的产品和服务。用户故事用于描述生产或服务的片段。该技术可以有不同的用途。
452 452  
453 453  
... ... @@ -484,6 +484,7 @@
484 484  
485 485  === ​​​​​​​5.2.6 MoSCoW方法 ===
486 486  
534 +
487 487  MoSCoW方法是一种用于管理需求的简单优先级排序技术。它可让利益相关者明确地就不同的优先级达成一致。
488 488  
489 489  
... ... @@ -497,8 +497,10 @@
497 497  * 可能 如果不影响“应该”或“必须”的需求，那么可以包括的需求。
498 498  * 不会 本次不包括但可能包含在未来版本的需求。
499 499  
548 +
500 500  === ​​​​​​​5.2.7 加权最短作业优先 ===
501 501  
551 +
502 502  有时需求具有匹配的优先级。在这些情况下，MoSCoW方法可以被更细粒度的技术（例如气泡排序）所取代或与之结合。然而，如果利益相关者的观点需要一致，这些方法可能不可行。
503 503  
504 504  
... ... @@ -510,8 +510,10 @@
510 510  图5.4 延迟成本除以适应服务管理条款的持续时间
511 511  
512 512  
563 +
513 513  == ​​​​​​​5.3 设计服务供应和用户体验 ==
514 514  
566 +
515 515  现代软件开发方法使新一代数字服务成为可能。这些方法有一个重要的共同点因素：它们在产品和服务的整个设计和的实现流程中都涉及到客户和用户。
516 516  
517 517  
... ... @@ -526,6 +526,7 @@
526 526  
527 527  === ​​​​​​​5.3.1 精益思维 ===
528 528  
581 +
529 529  精益思维可以被描述为一种流程改进哲学，它将流动效率置于资源效率之上。在精益中，流动是指工作在系统中进行的方式。工作单元可以定义为流经价值流的一件工作。一个好的流动意味着工作单元可以稳定且可预测地移动，而一个坏的流动则描述了一个包含大量队列的系统，其中工作单元将不得不停止并等待。
530 530  
531 531  
... ... @@ -550,6 +550,7 @@
550 550  
551 551  === ​​​​​​​5.3.2 敏捷生产和服务开发 ===
552 552  
606 +
553 553  软件开发的敏捷方法始于2001年的敏捷宣言，它鼓励人们优先考虑个人和交互，而不是工作流和工具，工作产品优先于综合文档，客户协作优先于合同，并对计划之后的变更做出响应。
554 554  
555 555  
... ... @@ -574,11 +574,13 @@
574 574  
575 575  === ​​​​​​​5.3.3 以用户为中心的设计 ===
576 576  
631 +
577 577  以用户为中心的设计是一个迭代的设计流程，它使用户置于整个项目流程中所有设计决策的中心。以用户为中心的设计确保生产和服务专注于用户需求和用户体验。
578 578  
579 579  
580 580  === ​​​​​​​5.3.4 服务设计思维 ===
581 581  
637 +
582 582  服务设计思维是解决问题的有效方法。由于该方法的核心是探索、原型，并收集来自真实用户的反馈，因此它是价值驱动、数据驱动和以用户为中心的服务设计的一个很好的例子。它鼓励用户定义价值，并且是一种不断收集有关什么有效和无效的反馈的方法。
583 583  
584 584  
... ... @@ -587,6 +587,7 @@
587 587  
588 588  === ​​​​​​​5.3.5 服务蓝图 ===
589 589  
646 +
590 590  蓝图是建筑设计的建筑图纸。这些蓝图描绘了建筑物的外观以及建造所需的所有规格。对于数字化服务，蓝图是可视化服务使用的图表，旨在优化用户体验。
591 591  
592 592  
... ... @@ -622,6 +622,7 @@
622 622  
623 623  === ​​​​​​​5.3.6 为引入设计 ===
624 624  
682 +
625 625  作为以用户为中心方法中的一部分，应该为每个产品、服务和服务供应定义引入方法，并作为设计的一部分，以平滑引入。
626 626  
627 627  
... ... @@ -675,8 +675,11 @@
675 675  [[image:1639121707255-977.png||height="54" width="39"]]//Henri：我们将做一个预告片自动预订流程的金丝雀版本，只有几个测试用户。然后，我们可以将其推广给客户，并随着我们的进展而开发功能。//
676 676  )))
677 677  
736 +== ==
737 +
678 678  == 5.4 销售并获得服务供应 ==
679 679  
740 +
680 680  设计产品、服务和服务供应之后，就需要进行销售。这可能发生在它们构建之前或之后，这取决于服务的性质和服务关系。内部和外部服务提供者都需要销售他们的服务。销售活动将根据客户是内部客户还是外部客户而有所不同。
681 681  
682 682  
... ... @@ -683,6 +683,7 @@
683 683  
684 684  === 5.4.1 定价 ===
685 685  
747 +
686 686  定价需要决定客户将被收取多少费用。可以使用许多定价选项为服务定价，如表5.12所示。要使一项服务可行，它必须产生足够的收入来支付投资和成本，并产生利润，除非服务提供者是非营利组织。
687 687  
688 688  
... ... @@ -712,8 +712,11 @@
712 712  在某些情况下，定价可以在短期内用于破坏竞争。
713 713  )))
714 714  
777 +=== ===
778 +
715 715  === ​​​​​​​5.4.2 内部销售 ===
716 716  
781 +
717 717  对内部客户而言，提高对可用服务的认知是销售的第一步。内部销售和促销，综合激励措施和定价机制，对于管理需求非常重要。
718 718  
719 719  
... ... @@ -746,6 +746,7 @@
746 746  
747 747  === ​​​​​​​5.4.3 对外销售 ===
748 748  
814 +
749 749  外部客户的销售更像是传统的销售技巧，例如广告和销售活动。销售流程取决于服务关系的类型、各方的性质和背景因素。其中包括：
750 750  
751 751  * 在高度监管的环境和公共部门，获取货品和服务可能会受到监管；某些服务提供者可能已被预授权销售其产品和服务。
... ... @@ -806,8 +806,14 @@
806 806  [[image:1639121791803-860.png||height="42" width="37"]]**M**//ariana：我们需要引入新的拖车租赁服务，这意味着将其添加到我们的服务目录中，向我们的支持人员介绍拖车的可用性，并管理拖车的需求。当学生最有可能搬家时，拖车租赁在每个学期的开始和结束时达到顶峰，但中期租赁确实会发生。//
807 807  )))
808 808  
875 +== ==
876 +
877 +== ==
878 +
809 809  == 5.5 总结 ==
810 810  
881 +​​​​​​​
882 +
811 811  为了确定利益相关者是否可以从相互的服务关系中受益，服务消费者和服务提供者需要构建商业案例，确定并匹配其需求和供应，并以需求和服务供应的形式阐明其需求和机会。只有真正了解服务消费者的需求，才能设计出产品和服务。
812 812  
813 813  
深圳市艾拓先锋企业管理咨询有限公司