From version < 45.1 >
edited by superadmin
on 2022/01/09, 10:52
To version < 47.1
edited by superadmin
on 2024/04/03, 16:50
<
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Content
... ... @@ -3,12 +3,14 @@
3 3  
4 4  [[阅读下一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E9%A9%B1%E5%8A%A8%E5%88%A9%E7%9B%8A%E7%9B%B8%E5%85%B3%E8%80%85%E4%BB%B7%E5%80%BC%E3%80%8BDSV/8.%20%E6%AD%A5%E9%AA%A46%EF%BC%9A%E4%BB%B7%E5%80%BC%E5%85%B1%E5%88%9B/]]  [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E9%A9%B1%E5%8A%A8%E5%88%A9%E7%9B%8A%E7%9B%B8%E5%85%B3%E8%80%85%E4%BB%B7%E5%80%BC%E3%80%8BDSV/6.%20%E6%AD%A5%E9%AA%A44%EF%BC%9A%E5%8D%8F%E8%AE%AE/]]
5 5  
6 -{{box cssClass="floatinginfobox" title="**Contents**"}}
6 +{{box cssClass="floatinginfobox" title="
7 +**Contents**"}}
7 7  {{toc/}}
8 8  {{/box}}
9 9  
10 -= 7. 步骤5:引入 =
11 += **7. 步骤5:引入** =
11 11  
13 +
12 12  [[image:1639123237595-418.png||height="64" width="627"]]
13 13  
14 14   计划引入
... ... @@ -112,8 +112,12 @@
112 112  [[image:1639123345078-830.png]]
113 113  
114 114  
117 +(% class="wikigeneratedid" %)
118 +== ==
119 +
115 115  == 7.1 规划引入 ==
116 116  
122 +
117 117  引入规划实际上是将一种或多种服务产品的引入方法适应于该引入计划的范围和背景的行为。引入计划应该考虑服务关系的当前状况、引入计划的范围、资源的当前配置以及相关的风险。
118 118  
119 119  
... ... @@ -132,8 +132,11 @@
132 132  * 谁负责引入行动?
133 133  * 如何控制引入并确保其成功?
134 134  
141 +
142 +
135 135  === 7.1.1 引入目标 ===
136 136  
145 +
137 137  服务提供者应该与利益相关者就引入目标定义、同意并构建认知。引入目标应在每个引入计划的背景中定义。引入目标的示例包括:
138 138  
139 139  * 确保服务消费者顺利迁移到协议服务
... ... @@ -158,8 +158,10 @@
158 158  在关键利益相关方接受引入目标之后,应通过详细的引入计划使引入方法适应计划的背景。计划由服务提供者驱动。但是,服务消费者代表将被告知、被咨询或对此负责,因为引入是一项联合行动,可能需要双方大量资源。
159 159  
160 160  
170 +
161 161  === 7.1.2 引入范围 ===
162 162  
173 +
163 163  要定义引入的范围,应考虑以下问题:
164 164  
165 165  * 需要引入的消费者资源是什么?
... ... @@ -228,6 +228,7 @@
228 228  
229 229  === 7.1.3 引入客户和用户:引入活动 ===
230 230  
242 +
231 231  在同意引入计划的范围之后,应规划引入活动。根据引入计划的范围和规模,以及组织的政策、规则和实践,用于计划的方法和工具可能会有所不同。表7.3提供了可能为服务管理四维模型资源计划的引入活动示例。
232 232  
233 233  
... ... @@ -300,8 +300,12 @@
300 300  * 服务请求管理
301 301  * 劳动力和人才管理。
302 302  
315 +
316 +
317 +
303 303  === 7.1.4 引入控制 ===
304 304  
320 +
305 305  当规划引入计划时,必须就控制和验证技术的方法达成一致,以确保计划成功。这种方法通常由引入计划的管理决定来主导。表7.5列出了根据情况可以组合的各种可用选项。
306 306  
307 307  
... ... @@ -343,8 +343,15 @@
343 343  [[image:1639123548518-524.png||height="52" width="40"]]**S**//olmaz:我们的第一批客户对引入给予了积极的反馈。新车共享客户在第一个月内致电服务台的电话,每个客户不超过两次。//
344 344  )))
345 345  
362 +(% class="wikigeneratedid" %)
363 +== ==
364 +
365 +(% class="wikigeneratedid" %)
366 +== ==
367 +
346 346  == 7.2 与用户相关并建立关系 ==
347 347  
370 +
348 348  由于服务提供者与服务消费者的技术和信息进行了更多的交互,因此某些服务不包括服务提供者与用户之间的广泛交互。机器对机器服务(例如IoT设备、技术微服务、信息系统维护和数据存储)是此类服务关系的示例。
349 349  
350 350  
... ... @@ -366,6 +366,7 @@
366 366  
367 367  === 7.2.1 建立与企业用户的关系 ===
368 368  
392 +
369 369  在大型组织环境中,用户引入通常是由组织所使用的服务的更改,用户组的更改(例如组织中的新成员)或人员角色和职位的更改触发的。
370 370  
371 371  
... ... @@ -398,8 +398,12 @@
398 398  * 用户参与的服务评审和改进
399 399  * 仪表板和报告让用户社区可以清楚地了解服务质量。
400 400  
425 +
426 +
427 +
401 401  === 7.2.2与个人消费者一起培育关系 ===
402 402  
430 +
403 403  当服务消费者是个人时,有很多因素会影响服务提供者在客户旅程期间如何管理服务关系。表7.6列出了其中一些因素。
404 404  
405 405  
... ... @@ -433,8 +433,18 @@
433 433  * 数据保护。
434 434  )))
435 435  
464 +(% class="wikigeneratedid" %)
465 +== ==
466 +
467 +(% class="wikigeneratedid" %)
468 +== ==
469 +
470 +(% class="wikigeneratedid" %)
471 +== ==
472 +
436 436  == 7.3 提供用户参与和交付渠道 ==
437 437  
475 +
438 438  重要的是要建立适当的用户参与和交付渠道,以提供良好的用户体验。
439 439  
440 440  
... ... @@ -463,8 +463,12 @@
463 463  
464 464  表7.7 服务提供者必须考虑的全渠道挑战示例
465 465  
466 -[[image:1641696535254-420.png]]
504 +[[image:1641696707897-409.png]]
467 467  
506 +[[image:1641696741463-574.png]]
507 +
508 +[[image:1641696754650-363.png]]
509 +
468 468  只有将这些方法编排为无缝的用户支持体验时,才能获得专注于用户的真正全渠道支持。这可以通过以下方式完成:
469 469  
470 470  * 跨所有渠道唯一地识别和辨识用户
... ... @@ -495,8 +495,15 @@
495 495  [[image:1639123701310-435.png||height="48" width="31"]]**S**//olmaz:我们可以使用社交媒体和在线实时视频流来使客户了解有关流动流量和事件的最新信息。//
496 496  )))
497 497  
540 +(% class="wikigeneratedid" %)
541 +== ==
542 +
543 +(% class="wikigeneratedid" %)
544 +== ==
545 +
498 498  == 7.4 使用户能够使用服务 ==
499 499  
548 +
500 500  某些服务需要特殊的用户技能。这些技能可能包括使用某些应用程序或设备,或者了解在使用服务的环境中安全操作的规则。例如,要被允许租用汽车,要求一个人具有有效的驾驶执照,该执照可证明根据特定国家/地区接受的交通法规来驾驶某种类型的汽车。
501 501  
502 502  要启用用户,服务提供者应考虑:
... ... @@ -569,22 +569,29 @@
569 569  [[image:1639123784450-617.png||height="42" width="37"]]//Mariana:我们还会为他们提供充电站和城市路线图、有关交通流量和拥堵的最新信息,以及有关如何使用汽车来帮助他们获得良好体验的常见问题和建议。//
570 570  )))
571 571  
621 +(% class="wikigeneratedid" %)
622 +== ==
623 +
624 +(% class="wikigeneratedid" %)
625 +== ==
626 +
572 572  == 7.5 提升彼此的能力 ==
573 573  
629 +
574 574  服务关系涉及所有利益相关者的价值共创。每次服务交互都是提升另一方能力的机会。表7.8解释了如何将每个ITIL指导原则用于一个小组,以提高另一组的能力。
575 575  
576 576  
577 577  表7.8 服务提供者和客户利用ITIL 指导原则提高用户能力的示例
578 578  
579 -(% style="width:714px" %)
580 -|(% style="width:130px" %)**指导原则**|(% style="width:582px" %)**优化用户能力的应用示例**
581 -|(% style="width:130px" %)聚焦价值|(% style="width:582px" %)用户应了解其工作目的和背景以及服务使用情况。 应鼓励他们提供可能有助于价值共创的服务改进。
582 -|(% style="width:130px" %)从当前开始|(% style="width:582px" %)用户体验的改善应基于当前的做法、习惯和期望。 用户体验中的根本性变化很少被视为改善,并且经常受到用户的抵制。
583 -|(% style="width:130px" %)基于反馈不断迭代|(% style="width:582px" %)对用户要求、服务交付和评估、服务使用过程以及用户体验的其他方面的所有更改,均应进行测试,并根据用户反馈进行持续审查。 应鼓励用户提供反馈,反馈的后续行动对用户社区应该是透明的。
584 -|(% style="width:130px" %)合作并提高知名度|(% style="width:582px" %)在需要联合运营的情况下,用户应了解协作的要求并相互帮助,服务提供商、合作伙伴和供应商以及其他相关方也同样如此。 如果服务无法按预期运行,或者用户不知道如何使用服务,则应安全,轻松并鼓励其寻求帮助或报告事件。
585 -|(% style="width:130px" %)全面思考和工作|(% style="width:582px" %)服务及其在价值共创中的作用应对所有相关方透明可见。 用户应了解其工作和依赖项的背景。
586 -|(% style="width:130px" %)保持简单实用|(% style="width:582px" %)用户界面和所有其他接触点应尽可能简单。 用户应具有提出改进界面的方法,并且应该认真透明地对待这些提议。
587 -|(% style="width:130px" %)优化和自动化|(% style="width:582px" %)用户体验的持续优化和自动化应该是用户和服务提供商之间所有接触点和服务交互的主题。
635 +(% style="width:414px" %)
636 +|(% style="width:85px" %)**指导原则**|(% style="width:327px" %)**优化用户能力的应用示例**
637 +|(% style="width:85px" %)聚焦价值|(% style="width:327px" %)用户应了解其工作目的和背景以及服务使用情况。 应鼓励他们提供可能有助于价值共创的服务改进。
638 +|(% style="width:85px" %)从当前开始|(% style="width:327px" %)用户体验的改善应基于当前的做法、习惯和期望。 用户体验中的根本性变化很少被视为改善,并且经常受到用户的抵制。
639 +|(% style="width:85px" %)基于反馈不断迭代|(% style="width:327px" %)对用户要求、服务交付和评估、服务使用过程以及用户体验的其他方面的所有更改,均应进行测试,并根据用户反馈进行持续审查。 应鼓励用户提供反馈,反馈的后续行动对用户社区应该是透明的。
640 +|(% style="width:85px" %)合作并提高知名度|(% style="width:327px" %)在需要联合运营的情况下,用户应了解协作的要求并相互帮助,服务提供商、合作伙伴和供应商以及其他相关方也同样如此。 如果服务无法按预期运行,或者用户不知道如何使用服务,则应安全,轻松并鼓励其寻求帮助或报告事件。
641 +|(% style="width:85px" %)全面思考和工作|(% style="width:327px" %)服务及其在价值共创中的作用应对所有相关方透明可见。 用户应了解其工作和依赖项的背景。
642 +|(% style="width:85px" %)保持简单实用|(% style="width:327px" %)用户界面和所有其他接触点应尽可能简单。 用户应具有提出改进界面的方法,并且应该认真透明地对待这些提议。
643 +|(% style="width:85px" %)优化和自动化|(% style="width:327px" %)用户体验的持续优化和自动化应该是用户和服务提供商之间所有接触点和服务交互的主题。
588 588  
589 589  为了帮助用户和客户变得更好,服务提供者可以考虑使用以下技术:
590 590  
... ... @@ -622,8 +622,15 @@
622 622  [[image:1639124353057-972.png||height="50" width="39"]]//Solmaz:这不仅使我们的客户受益,而且有助于我们确保每次预订后都对汽车进行清洁和充电。这为我们节省了一些维护成本,最重要的是,它支持出色的客户体验。//
623 623  )))
624 624  
681 +(% class="wikigeneratedid" %)
682 +== ==
683 +
684 +(% class="wikigeneratedid" %)
685 +== ==
686 +
625 625  == 7.6 撤销客户与用户 ==
626 626  
689 +
627 627  与引入类似,应将撤销的动作和职责预先定义为产品和服务设计的一部分,然后针对特定的引入/ 撤销计划进行调整。当两个服务都由同一服务提供者管理时,此方法有效。这类示例诸如,用户在组织中的位置发生了变化,这可能导致用户使用的服务范围的变化。
628 628  
629 629  
... ... @@ -641,6 +641,7 @@
641 641  
642 642  === 7.6.1 客户撤销 ===
643 643  
707 +
644 644  当服务协议期满或终止时,由服务提供者执行客户撤销。撤销动作通常包括:
645 645  
646 646  * 与所有相关的利益相关者,包括用户、客户、相关的合作伙伴/供应商和监管机构,就计划的服务终止进行沟通
... ... @@ -665,18 +665,19 @@
665 665  
666 666  表7.9 提供者切换操作示例
667 667  
668 -|**服务管理的维度**|**切换操作示例**
669 -|组织和人员|(((
732 +(% style="width:349px" %)
733 +|(% style="width:105px" %)**服务管理的维度**|(% style="width:240px" %)**切换操作示例**
734 +|(% style="width:105px" %)组织和人员|(% style="width:240px" %)(((
670 670  更改用户访问权限
671 671  
672 672  更改服务提供者的访问权限
673 673  )))
674 -|价值流和流程|(((
739 +|(% style="width:105px" %)价值流和流程|(% style="width:240px" %)(((
675 675  更改共同行动的责任
676 676  
677 677  更改程序和接口
678 678  )))
679 -|信息和技术|(((
744 +|(% style="width:105px" %)信息和技术|(% style="width:240px" %)(((
680 680  频道切换
681 681  
682 682  设备安装和卸载
... ... @@ -685,7 +685,7 @@
685 685  
686 686  记录存档
687 687  )))
688 -|合作伙伴和供应商|与服务提供者和服务消费者的供应商和合作伙伴终止、切换和建立合同
753 +|(% style="width:105px" %)合作伙伴和供应商|(% style="width:240px" %)与服务提供者和服务消费者的供应商和合作伙伴终止、切换和建立合同
689 689  
690 690  关于切换提供者的撤销动作类似于服务终止操作;它们应该涵盖表7.9中概述的所有服务管理四维模型。
691 691  
... ... @@ -706,6 +706,7 @@
706 706  
707 707  === 7.6.2 用户撤销 ===
708 708  
774 +
709 709  用户撤销可能是正在进行的服务关系的一部分,而没有服务或合同终止。常见的示例是用户从服务消费者组织辞职或在组织内的职位变化。这些场景应该在客户引入期间预先约定,并根据此方法进行处理(通常作为标准更改)。但是,在某些情况下,例如大规模撤销,可能需要额外的规划和协调。
710 710  
711 711  
... ... @@ -738,8 +738,15 @@
738 738  [[image:1639124450170-484.png||height="50" width="40"]]**S**//olmaz:撤销流程的一部分包括向我们的客户贷记所有剩余的会费。通过使流程自动化,我们不需要花费时间手动释放费用。//
739 739  )))
740 740  
807 +(% class="wikigeneratedid" %)
808 +== ==
809 +
810 +(% class="wikigeneratedid" %)
811 +== ==
812 +
741 741  == 7.7 总结 ==
742 742  
815 +
743 743  为了从协议发展到服务提供和消费,各方必须经历一种过渡,其中涉及服务提供者和服务消费者资源的整合或分离。应将此方法定义为服务设计的一部分,并且应该相应地计划、运行和控制引入或撤销活动。引入的主要活动包括建立用户关系、协调全渠道访问,使用户能够使用服务以及提升彼此的能力。
744 744  
745 745  
深圳市艾拓先锋企业管理咨询有限公司