Changes for page 05. 步骤3:供应
Last modified by superadmin on 2024/04/03, 16:55
Summary
Details
- 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 管理需求和机会 ... ... @@ -25,25 +25,24 @@ 25 25 26 26 表5.1 形成需求和服务提供的目的 27 27 28 -(% style="width:6 00px" %)29 -|(% style="width: 115px" %)**供应**|(% style="width:230px" %)**对于服务消费者**|(% style="width:253px" %)**对于服务提供者**30 -|(% style="width: 115px" %)促进成果和体验|(% style="width:230px" %)确保客户清楚表达了服务消费者的需求和要求|(% style="width:253px" %)(((29 +(% style="width:464px" %) 30 +|(% style="width:83px" %)**供应**|(% style="width:163px" %)**对于服务消费者**|(% style="width:216px" %)**对于服务提供者** 31 +|(% style="width:83px" %)促进成果和体验|(% style="width:163px" %)确保客户清楚表达了服务消费者的需求和要求|(% style="width:216px" %)((( 31 31 了解如何为服务消费者和服务提供者创建价值,以及服务提供者如何支持该价值共创 32 32 33 33 使服务提供者能够平衡供应和需求 34 34 ))) 35 -|(% style="width: 115px" %)优化风险和合规性|(% style="width:230px" %)(((36 +|(% style="width:83px" %)优化风险和合规性|(% style="width:163px" %)((( 36 36 最小化购买服务而不满足实际需要的风险 37 37 38 38 减少供应商误解消费者需求的风险 39 -)))|(% style="width:2 53px" %)(((40 +)))|(% style="width:216px" %)((( 40 40 尽量减少无法履行承诺服务的风险 41 41 42 42 尽量减少客户不满意的风险 43 43 ))) 44 -|(% style="width: 115px" %)优化资源并最小化成本|(% style="width:230px" %)确保将资金投资于能够优化投资回报的领域|(% style="width:253px" %)确保在最佳区域使用时间和资源45 +|(% style="width:83px" %)优化资源并最小化成本|(% style="width:163px" %)确保将资金投资于能够优化投资回报的领域|(% style="width:216px" %)确保在最佳区域使用时间和资源 45 45 46 - 47 47 |((( 48 48 **ITIL故事:步骤3 – 供应** 49 49 ... ... @@ -50,15 +50,19 @@ 50 50 [[image:1639115675132-360.png||height="51" width="47"]]//Mariana:我们的eCampus汽车共享服务已受到大学学生和员工的欢迎。我们为普通汽车用户提供订阅会员资格,为间歇性用户提供不同的定价等级。我们的汽车是电动的,这使它们比传统的汽车更环保,因为它们排放的废气更少。另外,汽车共享会降低汽车拥有率,减少道路上的汽车行驶次数,并减少客户出行次数,因为客户会将差事合并为一次出行以最大程度地增加支出。我们为自己能提供一个干净、安全、可靠的往返于校园的其他交通选择而自豪。// 51 51 ))) 52 52 53 +(% class="wikigeneratedid" %) 54 +== == 53 53 54 - 55 55 == 5.1 管理需求和机会 == 56 56 58 + 57 57 就服务而言,需求和容量是相互关联的。服务无法存储供以后使用。当服务价值只有在服务提供者的供给满足服务使用者的需求时才能被共同创造。如果需求得不到满足,设施和资源就会浪费。同样,当需求高于容量时,也会丢失机会。为了优化服务机会,服务提供者应调整容量和影响需求。正确理解不同的客户群体和部门如何使用其服务至关重要。 58 58 59 59 62 + 60 60 === 5.1.1 业务活动模式 === 61 61 65 + 62 62 要了解如何使用服务,分析业务活动的模式很有用的。事实和图表是通过监控和日志记录生成的,反映了服务的使用情况。这些信息将有助于采取措施满足需求高峰。 63 63 64 64 ... ... @@ -73,11 +73,11 @@ 73 73 74 74 表5.2 会计处理的业务活动模式示例 75 75 76 -(% style="width:3 60px" %)77 -|(% style="width: 47px" %)**角色**|(% style="width:174px" %)**实现价值创建高峰工作量**|(% style="width:138px" %)**高峰时间**78 -|(% style="width: 47px" %)雇员|(% style="width:174px" %)所有员工填写工时表|(% style="width:138px" %)每周五午餐后79 -|(% style="width: 47px" %)会计|(% style="width:174px" %)获取或构建,报告和质量检查准备工资|(% style="width:138px" %)每月12日至15日80 -|(% style="width: 47px" %)会计|(% style="width:174px" %)年终结账|(% style="width:138px" %)每年十一月/十二月80 +(% style="width:333px" %) 81 +|(% style="width:55px" %)**角色**|(% style="width:150px" %)**实现价值创建高峰工作量**|(% style="width:125px" %)**高峰时间** 82 +|(% style="width:55px" %)雇员|(% style="width:150px" %)所有员工填写工时表|(% style="width:125px" %)每周五午餐后 83 +|(% style="width:55px" %)会计|(% style="width:150px" %)获取或构建,报告和质量检查准备工资|(% style="width:125px" %)每月12日至15日 84 +|(% style="width:55px" %)会计|(% style="width:150px" %)年终结账|(% style="width:125px" %)每年十一月/十二月 81 81 82 82 另一种可以识别的模式是通过分析来电。例如,结果可以表明,所有支助请求中平均有85%是在每个工作日的两个短期间提出的:10:00-11:00和15:00-16:00。服务台还可以看到所需的特定服务。有了这些信息,服务台可以通过在高峰时段提供额外人员或创建自助服务解决方案来管理需求。 83 83 ... ... @@ -90,6 +90,7 @@ 90 90 91 91 === 5.1.2 优化容量 === 92 92 97 + 93 93 |((( 94 94 **容量和性能管理实践** 95 95 ... ... @@ -126,6 +126,7 @@ 126 126 127 127 === 5.1.3 成形或平滑需求 === 128 128 134 + 129 129 服务提供者经常受到服务需求的巨大差异和有限容量的挑战。如果不能形成与供应相匹配的需求,将导致容量投资的回报率很低。例如,服务台的训练有素的支持人员数量有限。因此,使需求与服务容量相匹配是一项重要的学科。 130 130 131 131 ... ... @@ -140,6 +140,7 @@ 140 140 141 141 ==== 5.1.3.1 定价和计费机制 ==== 142 142 149 + 143 143 差异性收费和收益管理是使用定价和计费机制管理容量和需求的示例。这些机制可用于驱动服务使用者在服务的许多方面的行为。既然它是如此强大的工具,就应该有意识地使用它来驱动正确的行为。例如,如果云服务提供者希望其服务消费者在不需要时清除容量,则“按单位付费” 策略将正确地影响行为。 144 144 145 145 ... ... @@ -159,8 +159,12 @@ 159 159 [[image:1641543155649-541.png]] 160 160 161 161 169 +(% class="wikigeneratedid" %) 170 +==== ==== 171 + 162 162 ==== 5.1.3.2 服务改进点机会 ==== 163 163 174 + 164 164 服务质量取决于对改进点机会的管理。来自客户的冲突请求、糟糕的定价激励或缺乏专门的改进点预算可能是冲突的来源。因此,服务提供者必须专业地处理改进点机会。持续改进需要所有权、服务改进点预算和透明的流程,以确定如何识别、捕获、评估、优先级和处理改进点机会。 165 165 166 166 ... ... @@ -184,8 +184,10 @@ 184 184 持续改进实践指南和ITIL®4:指导计划和改进中介绍了有关如何完成结构化服务改进的详细指南。业务分析实践指南中介绍了执行业务分析的任务和技术。 185 185 186 186 198 + 187 187 === 5.1.4 构建客户商业案例 === 188 188 201 + 189 189 当需要和需求得到理解和解决时,可以起草通过新的或变更的产品和服务来满足需求的商业案例。 190 190 191 191 ... ... @@ -265,8 +265,10 @@ 265 265 * **选择最便宜的提供者** 在这种情况下,价格和成本承受着巨大的压力,这可能会使服务提供者的利润空间很小,也可能会阻止服务提供者在不亏损的情况下保持灵活性。这可能会导致一种以牺牲价值为代价的紧张关系。 266 266 267 267 281 + 268 268 === 5.1.5 构建服务提供者商业案例 === 269 269 284 + 270 270 服务提供者需要构建和维护一个可盈利的、可行的商业案例。否则,服务提供者可能会赔钱,最终倒闭。在构建商业案例时,服务提供者应该考虑客户的商业案例。 271 271 272 272 ... ... @@ -293,9 +293,10 @@ 293 293 * 服务连续性管理 294 294 * 服务财务管理。 295 295 296 - 297 297 |((( 298 298 ((( 313 + 314 + 299 299 **ITIL的故事:管理需求和机遇** 300 300 301 301 [[image:1639121261076-787.png||height="49" width="40"]]//Mariana:我们分析了我们服务的业务活动模式,发现需求在学期中期的几周内最高,而在假期期间最低。周末需求低于工作日需求。晚间曾经使用很受欢迎,但最近几个月有所下降。我们将此归功于当地政府针对学生开展的一项运动,该运动旨在告诉学生在酒精或毒品影响下开车的危险性。// ... ... @@ -310,8 +310,15 @@ 310 310 ))) 311 311 ))) 312 312 329 +(% class="wikigeneratedid" %) 330 +== == 331 + 332 +(% class="wikigeneratedid" %) 333 +== == 334 + 313 313 == 5.2 指定和管理客户要求 == 314 314 337 + 315 315 需求规范应该出现在可视化线中。理想情况下,客户应该让服务提供者参与到一个开放且透明的需求规范流程中。如果在流程中过早的密封了需求,则服务提供者可能无法形成最佳的服务并满足服务消费者需求。 316 316 317 317 ... ... @@ -326,9 +326,10 @@ 326 326 业务分析使组织能够以有意义的方式传达其需求,表达变更的基本原理,并设计和描述支持与组织目标相一致的价值创造的解决方案。 327 327 ))) 328 328 329 - 330 330 |((( 331 331 ((( 354 + 355 + 332 332 **ITIL故事:指定和管理客户要求** 333 333 334 334 [[image:1639121261076-787.png||height="49" width="40"]]//Mariana:我们发现了新的客户需求:我们的许多客户在这一年中不得不搬家。当他们为此目的使用我们的汽车时,他们需要多次出行,并且比往常更频繁地为汽车充电。他们还将较低电荷的汽车退还,从而很难将汽车出租给下一个客户。此外,它还损害了我们提供环境可持续服务的愿景。// ... ... @@ -343,8 +343,16 @@ 343 343 ))) 344 344 ))) 345 345 370 +(% class="wikigeneratedid" %) 371 +=== === 372 + 373 + 374 +(% class="wikigeneratedid" %) 375 +=== === 376 + 346 346 === 5.2.1 角色和责任 === 347 347 379 + 348 348 明确的角色和职责是指定和管理需求的关键。权威人士必须得到识别,并说明如何捕获、表达和表示用户需求和期望。 349 349 350 350 ... ... @@ -374,6 +374,7 @@ 374 374 375 375 === 5.2.2 管理需求 === 376 376 409 + 377 377 不仅应指定要求,还应在整个流程中对其进行管理和跟踪。需求所有者负责: 378 378 379 379 * 确定利益相关方群体及其代表 ... ... @@ -404,8 +404,11 @@ 404 404 * 可度量性和可报告性 405 405 * 可扩展性。 406 406 440 + 441 + 407 407 === 5.2.3 将问题与解决方案分开 === 408 408 444 + 409 409 我们已经说过,需求应该基于利益相关者需要。然而,指定一个解决方案,而不是将需要转换成需求可能会很有吸引力。在阐明需求时,必须将问题与解决方案分开,以考虑到解决方案无法解决潜在问题的事实。这也有助于将当前的解决方案与所有可能的未来解决方案区分开。表5.7概述了一种简单的技术来帮助完成此流程。 410 410 411 411 ... ... @@ -430,8 +430,15 @@ 430 430 图书管理员使用数据库查找图书并登记借出。 431 431 )))|(% style="width:252px" %)当我们识别问题的本质并探索解决问题的不同方法时,可以采用多种不同的解决方法,包括在线阅读,有声读物,相关文章以及内容摘要。 432 432 469 +(% class="wikigeneratedid" %) 470 +=== === 471 + 472 +(% class="wikigeneratedid" %) 473 +=== === 474 + 433 433 === 5.2.4 最小化可行产品 === 434 434 477 + 435 435 在Eric Ries (Ries, 2011)所描述的精益创业方法中,关键的信息是制作一个好的商业案例的原型,并在真实的用户中进行测试,以获得反馈。对于原型设计,他依赖于最小可行产品的概念。 436 436 437 437 ... ... @@ -452,8 +452,15 @@ 452 452 [[image:1639121503640-486.png||height="50" width="38"]]**T**//omas:Mariana使用迭代的方法,Mariana发现顾客也需要手推车作为产品供应的一部分。这是她在试租拖车之前没有考虑过的事情。// 453 453 ))) 454 454 498 +(% class="wikigeneratedid" %) 499 +=== === 500 + 501 +(% class="wikigeneratedid" %) 502 +=== === 503 + 455 455 === 5.2.5 用户故事和故事映射 === 456 456 506 + 457 457 用户故事映射是表达服务需求的常用方法。用户故事是一种表示利益相关者所需功能领域的方式,这种方式可以在团队成员之间引起讨论和理解,帮助他们共同努力,将需求转变为有效的产品和服务。用户故事用于描述生产或服务的片段。该技术可以有不同的用途。 458 458 459 459 ... ... @@ -483,37 +483,14 @@ 483 483 484 484 表5.9 使用史诗、功能、促成因素和故事来阐明需求 485 485 486 -(% style="width:578px" %) 487 -|(% style="width:113px" %)**类型**|(% style="width:243px" %)**描述**|(% style="width:219px" %)**示例** 488 -|(% style="width:113px" %)史诗|(% style="width:243px" %)((( 489 -史诗是向客户交付新产品、服务或客户旅程的一项举措。 536 +[[image:1641647603766-545.png]] 490 490 491 -史诗是大型故事或用户故事,它太大而无法在一个冲刺中涵盖。 492 - 493 -史诗包含大量特性。 494 -)))|(% style="width:219px" %)从租车到交车的整个用户体验。 495 -|(% style="width:113px" %)特性/促成因素|(% style="width:243px" %)((( 496 -特性是相关用户故事的集合,这些故事表示生产或服务负责人感兴趣的整个功能区域或能力。 497 - 498 -特性由许多用户故事实现。 499 - 500 -促进因素是支持探查,架构,基础结构或合规性的特性的技术先决条件。 501 -)))|(% style="width:219px" %)繁忙的经理可以在机场接车去开会。 502 -|(% style="width:113px" %)用户故事/ 促进因素故事|(% style="width:243px" %)((( 503 -一种功能的描述,可以在一个冲刺中开发。 504 - 505 -作为<用户>,我想要<需求>,所以<收益>。 506 -)))|(% style="width:219px" %)((( 507 -繁忙的经理可以在机场订购快速通道接送服务,以减轻压力。 508 - 509 -繁忙的经理可以在不支付停车费的情况下离开机场,以减少等待时间。 510 -))) 511 - 512 512 故事映射通常与敏捷服务设计方法(例如Scrum方法)结合使用。在Scrum方法中,产品负责人负责对每个冲刺中的用户故事进行优先级排序。在冲刺的末尾,生产团队将向实际用户演示这些功能并收集反馈。 513 513 514 514 515 515 === 5.2.6 MoSCoW方法 === 516 516 543 + 517 517 MoSCoW方法是一种用于管理需求的简单优先级排序技术。它可让利益相关者明确地就不同的优先级达成一致。 518 518 519 519 ... ... @@ -527,8 +527,11 @@ 527 527 * 可能 如果不影响“应该”或“必须”的需求,那么可以包括的需求。 528 528 * 不会 本次不包括但可能包含在未来版本的需求。 529 529 557 + 558 + 530 530 === 5.2.7 加权最短作业优先 === 531 531 561 + 532 532 有时需求具有匹配的优先级。在这些情况下,MoSCoW方法可以被更细粒度的技术(例如气泡排序)所取代或与之结合。然而,如果利益相关者的观点需要一致,这些方法可能不可行。 533 533 534 534 ... ... @@ -540,8 +540,10 @@ 540 540 图5.4 延迟成本除以适应服务管理条款的持续时间 541 541 542 542 573 + 543 543 == 5.3 设计服务供应和用户体验 == 544 544 576 + 545 545 现代软件开发方法使新一代数字服务成为可能。这些方法有一个重要的共同点因素:它们在产品和服务的整个设计和的实现流程中都涉及到客户和用户。 546 546 547 547 ... ... @@ -556,6 +556,7 @@ 556 556 557 557 === 5.3.1 精益思维 === 558 558 591 + 559 559 精益思维可以被描述为一种流程改进哲学,它将流动效率置于资源效率之上。在精益中,流动是指工作在系统中进行的方式。工作单元可以定义为流经价值流的一件工作。一个好的流动意味着工作单元可以稳定且可预测地移动,而一个坏的流动则描述了一个包含大量队列的系统,其中工作单元将不得不停止并等待。 560 560 561 561 ... ... @@ -580,6 +580,7 @@ 580 580 581 581 === 5.3.2 敏捷生产和服务开发 === 582 582 616 + 583 583 软件开发的敏捷方法始于2001年的敏捷宣言,它鼓励人们优先考虑个人和交互,而不是工作流和工具,工作产品优先于综合文档,客户协作优先于合同,并对计划之后的变更做出响应。 584 584 585 585 ... ... @@ -604,11 +604,13 @@ 604 604 605 605 === 5.3.3 以用户为中心的设计 === 606 606 641 + 607 607 以用户为中心的设计是一个迭代的设计流程,它使用户置于整个项目流程中所有设计决策的中心。以用户为中心的设计确保生产和服务专注于用户需求和用户体验。 608 608 609 609 610 610 === 5.3.4 服务设计思维 === 611 611 647 + 612 612 服务设计思维是解决问题的有效方法。由于该方法的核心是探索、原型,并收集来自真实用户的反馈,因此它是价值驱动、数据驱动和以用户为中心的服务设计的一个很好的例子。它鼓励用户定义价值,并且是一种不断收集有关什么有效和无效的反馈的方法。 613 613 614 614 ... ... @@ -617,6 +617,7 @@ 617 617 618 618 === 5.3.5 服务蓝图 === 619 619 656 + 620 620 蓝图是建筑设计的建筑图纸。这些蓝图描绘了建筑物的外观以及建造所需的所有规格。对于数字化服务,蓝图是可视化服务使用的图表,旨在优化用户体验。 621 621 622 622 ... ... @@ -652,6 +652,7 @@ 652 652 653 653 === 5.3.6 为引入设计 === 654 654 692 + 655 655 作为以用户为中心方法中的一部分,应该为每个产品、服务和服务供应定义引入方法,并作为设计的一部分,以平滑引入。 656 656 657 657 ... ... @@ -705,8 +705,12 @@ 705 705 [[image:1639121707255-977.png||height="54" width="39"]]//Henri:我们将做一个预告片自动预订流程的金丝雀版本,只有几个测试用户。然后,我们可以将其推广给客户,并随着我们的进展而开发功能。// 706 706 ))) 707 707 746 +(% class="wikigeneratedid" %) 747 +== == 748 + 708 708 == 5.4 销售并获得服务供应 == 709 709 751 + 710 710 设计产品、服务和服务供应之后,就需要进行销售。这可能发生在它们构建之前或之后,这取决于服务的性质和服务关系。内部和外部服务提供者都需要销售他们的服务。销售活动将根据客户是内部客户还是外部客户而有所不同。 711 711 712 712 ... ... @@ -713,6 +713,7 @@ 713 713 714 714 === 5.4.1 定价 === 715 715 758 + 716 716 定价需要决定客户将被收取多少费用。可以使用许多定价选项为服务定价,如表5.12所示。要使一项服务可行,它必须产生足够的收入来支付投资和成本,并产生利润,除非服务提供者是非营利组织。 717 717 718 718 ... ... @@ -742,8 +742,12 @@ 742 742 在某些情况下,定价可以在短期内用于破坏竞争。 743 743 ))) 744 744 788 +(% class="wikigeneratedid" %) 789 +=== === 790 + 745 745 === 5.4.2 内部销售 === 746 746 793 + 747 747 对内部客户而言,提高对可用服务的认知是销售的第一步。内部销售和促销,综合激励措施和定价机制,对于管理需求非常重要。 748 748 749 749 ... ... @@ -776,6 +776,7 @@ 776 776 777 777 === 5.4.3 对外销售 === 778 778 826 + 779 779 外部客户的销售更像是传统的销售技巧,例如广告和销售活动。销售流程取决于服务关系的类型、各方的性质和背景因素。其中包括: 780 780 781 781 * 在高度监管的环境和公共部门,获取货品和服务可能会受到监管;某些服务提供者可能已被预授权销售其产品和服务。 ... ... @@ -836,8 +836,16 @@ 836 836 [[image:1639121791803-860.png||height="42" width="37"]]**M**//ariana:我们需要引入新的拖车租赁服务,这意味着将其添加到我们的服务目录中,向我们的支持人员介绍拖车的可用性,并管理拖车的需求。当学生最有可能搬家时,拖车租赁在每个学期的开始和结束时达到顶峰,但中期租赁确实会发生。// 837 837 ))) 838 838 887 +(% class="wikigeneratedid" %) 888 +== == 889 + 890 +(% class="wikigeneratedid" %) 891 +== == 892 + 839 839 == 5.5 总结 == 840 840 895 + 896 + 841 841 为了确定利益相关者是否可以从相互的服务关系中受益,服务消费者和服务提供者需要构建商业案例,确定并匹配其需求和供应,并以需求和服务供应的形式阐明其需求和机会。只有真正了解服务消费者的需求,才能设计出产品和服务。 842 842 843 843
- 1641647603766-545.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.superadmin - Size
-
... ... @@ -1,0 +1,1 @@ 1 +66.6 KB - Content