Changes for page ITIL4核心著作 - ③ 《驱动利益相关者价值》DSV

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -264,7 +264,7 @@
264	264	治理是指挥和控制组织的手段。角色和治理在ITIL SVS中的位置将根据在组织中使用SVS的方式而有所不同。
265	265
266	266
267		-== ==
	267	+== ==
268	268
269	269	== 持续改进 ==
270	270
...	...	@@ -294,4379 +294,17 @@
294	294
295	295	----
296	296
297		-= 4. 步骤2：契动 =
	297	+= =
298	298
299		-[[image:1639038146748-255.png]]
	299	+----
300	300
301		- 交流与协作
302		-
303		- 理解服务关系类型
304		-
305		- 建立服务关系
306		-
307		- 管理供应商和合作伙伴
308		-
309		-
310		-契动步骤的目的是构建透明度，持续的契动、以及利益相关者之间的信任，以确保对每个利益相关者的偏好和体验有良好的相互理解。对于任何服务而言，关系和信任是成功实现价值的重要因素。当存在高度信任时，每一方都相信另一方致力于共同成功，当这种关系导致相互依赖的成功时，可能会积累更多的信任。
311		-
312		-
313		-当所有利益相关者能够培养和维持一个合作和信任的环境时，它们都是成功的，因为：
314		-
315		-* 凭借高度信任，客户会倾向于增加需求，可以有效促进价值共创。
316		-* 表现出色的服务提供者会获得资源为服务消费者创建和交付高质量的产品或服务，有助于增强竞争优势。
317		-
318		-在低度信任的关系中，所有内容都趋于固定、文档和规范。在高度信任的关系中，它更加灵活，接触点和服务交互性的数量可能会增加。因此，协作变得更容易。
319		-
320		-
321		-表4.1总结了为什么服务提供者、客户和其他利益相关者应该投资于促进服务关系。
322		-
323		-
324		-在大多数情况下，服务不足以满足利益相关者对结果的实际需求。利益相关者也需要相信服务提供者将随着时间的推移继续提供一定水平的服务和改进。各方不仅在结果方面，而且在体验和偏好中都必须对期望有共同的理解。图4.1中对此进行了突出显示。
325		-
326		-
327		-优秀的服务关系可以培养并揭示对利益相关者，体验和偏好对结果的期望。由于偏见和错误的假设是共同努力取得成功的主要威胁，因此对于契动始终是一个好主意，以便开始阐明和传达相互的假设和期望。
328		-
329		-
330		-表4.1契动和培养关系的目的
331		-
332		-|**契动**|(% style="width:554px" %)**对于服务消费者**|(% style="width:528px" %)**对于服务提供者**
333		-|**促进成果和体验**|(% style="width:554px" %)(((
334		-从服务中获得更高（潜在）的价值
335		-
336		-为了更好的客户体验
337		-
338		-由于增加了服务提供者认同而增加了服务设计的效果和效率
339		-
340		-由于与服务提供者进行了有效的沟通，为了更清晰地共享对期望的理解，需求和偏好
341		-)))|(% style="width:528px" %)(((
342		-通过培育和保留现有客户来增加服务提供
343		-
344		-增强竞争优势，以寻找和吸引新客户
345		-
346		-从更好的客户认同获得改进点机会
347		-
348		-获得更好的决策信息
349		-
350		-推进共同愿景如何实现双赢
351		-)))
352		-|**优化风险和合规性**|(% style="width:554px" %)(((
353		-降低复杂度
354		-
355	355
356		-)))|(% style="width:528px" %)(((
357		-降低复杂度
358	358
359		-增加长期成功的可能性降低服务的成本
360		-)))
361		-|**优化资源与最小化成本**|(% style="width:554px" %)(((
362		-减少服务支出
	303	+= =
363	363
364		-减少谈判支出
365	365
366		-减少控制活动的时间和精力
367		-)))|(% style="width:528px" %)(((
368		-减少谈判支出
369		-
370		-减少行销的成本和客户
371		-)))
372		-
373		-(% style="text-align:center" %)
374		-[[image:1639038280007-636.png]]
375		-
376		- 图片4.1 服务的各个方面价值
377		-
378		-
379		-|(((
380		-**ITIL故事：第2步– 契动**
381		-
382		-[[image:1639038342932-765.png||height="55" width="52"]]//Mariana：与传统的汽车租赁不同，汽车共享是服务，它要求服务提供者和客户之间高度信任。例如，我们相信客户可以收集和归还车辆，而无需员工检查车辆是否损坏。我们要求客户记录他们收车时发现的任何损坏，并告知我们在旅途中汽车是否损坏。//
383		-
384		-[[image:1639038356665-888.png||height="60" width="48"]]//Radhika：我们的客户信任eCampus Car Share在需要时提供清洁，安全，可行驶的车辆。他们相信服务能够通过使用绿色清洁产品和校园内可靠的计费站来达到愿景环保可持续性的要求。他们还信任公司保护自己的私人信息，并诚实，适当地管理其帐户。//
385		-)))
386		-
387		-== 4.1 沟通与协作 ==
388		-
389		-沟通是建立关系和信任的基础。沟通不畅会破坏良好的意愿，并导致损失、延误、不必要的纠纷和糟糕的服务交付。在契动步骤中，有效的沟通尤为重要，因为这是形成最初预期的时候。沟通的效果取决于沟通双方的关系类型。
390		-
391		-
392		-合作是与他人一起工作实现自己的目标。这些目标可能是共同目标的一部分。但是，有一个风险，涉及合作的个人/团队将在竖井中工作。结果，个人/团队的目标实现了，但是组织的目标却没有实现。
393		-
394		-
395		-协作是一人或多人与他人共事产生某种东西的流程。从业务的角度来看，协作是一种实践，人们可以一起工作以实现一个共同目标。协作允许信息共享，从而实现反馈并带来更高的服务质量和更有创造性的改进。
396		-
397		-
398		-对于团队合作和服务关系而言，合作和协作都是有效且有价值的方法。在复杂的环境中，合作具有更大的创造性和创业工作潜力。合作可以是一种有效的标准化工作模式，明确划分职责，尤其是当来自多个组织的人员需要一起工作时。在服务关系中，协作对于伙伴关系是困难的；合作在基本的合作关系中是很常见的。
399		-
400		-
401		-为了有效地进行沟通和协作，个人应该了解文化差异、语言障碍和时区。
402		-
403		-
404		-表4.2 三种倾听模式在不同服务管理情况下的应用
405		-
406		-|(% style="width:89px" %)**倾听模式**|(% style="width:483px" %)**描述**|(% style="width:511px" %)**何时使用**|(% style="width:211px" %)**柯维的层次**
407		-|(% style="width:89px" %)**内部倾听**|(% style="width:483px" %)重点是内在的。大部分的注意力集中在主题如何影响听者，它唤起了什么情感，以及它如何与个人成见的比较。|(% style="width:511px" %)当以用户身份参与培训、审查工作结果报告、学习新的说明、接受辅导或指导、审查文档等时，这种倾听方式非常有用。|(% style="width:211px" %)(((
408		-听而不闻
409		-
410		-假装在听
411		-
412		-选择性倾听
413		-)))
414		-|(% style="width:89px" %)**专注倾听**|(% style="width:483px" %)(((
415		-关注的是对方，而不是外部世界。
416		-
417		-专注倾听是同理心、澄清和协作的水平。听众在整个对话过程中会注意到语气、肢体语言和持续的反应。
418		-)))|(% style="width:511px" %)在讨论服务需求（例如，协商SLA）、参加决策会议、规划变更等，可使用这种倾听类型。|(% style="width:211px" %)专注倾听
419		-|(% style="width:89px" %)**360度倾听**|(% style="width:483px" %)(((
420		-360度倾听或环境倾听，包括所有感官所能观察到的一切。
421		-
422		-好的执行者通常都有很强的360度倾听技巧。
423		-
424		-经验丰富的演员、培训师、教师和领导者可能已经能够立即评估一种气氛，并监控其气氛如何随他们的行动而变化。这些人擅长根据自己的影响调整自己的行为。
425		-)))|(% style="width:511px" %)(((
426		-解决问题时、设计产品和服务时、在教学中、进行审计时、在协调团队合作时、在销售情况下都可以使用这种倾听类型。
427		-
428		-服务提供者通过调查，社交媒体，客户评论，电子邮件，反馈表，服务使用情况分析等与服务消费者进行沟通。
429		-)))|(% style="width:211px" %)同理心的倾听
430		-
431		-=== 4.1.1 倾听模式 ===
432		-
433		-倾听是有效沟通的关键，可以通过实践和训练来提高。糟糕的倾听会导致错误、误解和合作失败。
434		-
435		-
436		-不同的倾听模式可以用于不同的情况，以改善沟通。斯蒂芬·柯维(Stephen Covey)在《高效能人士的七个习惯》(The 7 Habits of Highly Effective People, Covey, 1989)一书中提出了一个常见的倾听层次。这包括以下内容：
437		-
438		-* 听而不闻 不努力倾听。
439		-* 假装在听 表现出你在倾听的样子。
440		-* 选择性倾听 仅倾听你感兴趣的部分对话。
441		-* 专注倾听 集中注意力听说话者所说的话。
442		-* 同理心的倾听 倾听并回应理解说话者的言语、意图和感受。
443		-
444		-该层次可以进一步简化为三种基本的倾听模式。表4.2中描述了三种倾听模式及其在不同服务管理情况下的应用方式。
445		-
446		-
447		-=== 4.1.2 多元化 ===
448		-
449		-当今世界非常多样化。因此，在服务关系的合作中，应考虑许多因素，包括：
450		-
451		-* 文化差异和语言
452		-* 时区和位置
453		-* 季节因素（例如，暑假）
454		-* 组织文化。
455		-
456		-始终重要的是：
457		-
458		-* 培养尊重的态度
459		-* 使用正确的语言
460		-* 创建一个可以安全表达所有观点的环境
461		-* 最后得出可执行的结论
462		-* 不断地与工作程序保持一致。
463		-
464		-|(((
465		-**ITIL的故事：沟通与协作**
466		-
467		-[[image:1639038517459-380.png||height="59" width="53"]]//Mariana：我们使用艾克苏的预订系统开始了eCampus Car Share，但是我们需要应用程序中添加额外的功能来自助报告损坏和维护问题。通过自动化此流程，我们能够确保服务的最小延迟和中断。//
468		-
469		-[[image:1639038531211-275.png||height="68" width="47"]]**S**//olmaz：我们正在利用艾克苏的服务台进行事件报告。作为eCampus Car Share 培训和意识的一部分，本地服务台成员已被派往西雅图，以协作方式为我们的圣保罗客户提供支持。//
470		-)))
471		-
472		-== 4.2 理解服务关系类型 ==
473		-
474		-与服务消费者的契动包括但不限于建立和维持关系、理解需求以及评估相互准备和成熟程度 。然而，这些活动因客户追求的目标、服务的类型、服务提供者的类型可能有所不同。这些依赖关系如表4.3所示。
475		-
476		-关系越亲密、越成熟、越透明、非正式沟通（更多），风险分担和回报就越多。然而，由于市场和安全的原因，并非所有客户都希望这种亲密关系。同样，从经济角度来看，服务提供者可能也不希望使用这种类型的关系
477		-
478		-
479		-表4.3 不同环境中的契动和培养关系
480		-
481		-(% style="text-align:center" %)
482		-[[image:1639038587049-177.png]]
483		-
484		-|(% style="width:123px" %) |(% style="width:302px" %)**基础关系**|(% style="width:441px" %)**合作关系**|(% style="width:427px" %)**伙伴关系**
485		-|(% style="width:123px" %)**关键属性**|(% style="width:302px" %)(((
486		-提供者充当临时接单者
487		-
488		-需求的优先级是基于薄弱或主观的数据
489		-
490		-频繁的误解会造成不信任
491		-
492		-服务提供者是被动的，不质疑客户的请求
493		-
494		-缺少质量数据来支持成本或价值分析
495		-
496		-“先入先出”
497		-
498		-成本通常是透明的，但价值可能是隐藏的
499		-)))|(% style="width:441px" %)(((
500		-提供者充当可信赖的顾问
501		-
502		-对需求和供应有相互理解和赞赏
503		-
504		-服务组合适用于服务消费者需求
505		-
506		-服务提供者在契动早期与通常在客户决策周期中，对于产品和服务的价值有着共同的理解
507		-
508		-“ 例行公事是例行公事”，但创新是挑战
509		-
510		-关系建立在相互尊重和理解的基础上
511		-)))|(% style="width:427px" %)(((
512		-提供者充当战略合作伙伴
513		-
514		-服务提供者和服务消费者共享聚焦于价值实现的共同目标
515		-
516		-在产品和服务的投资和支持价值分析的质量数据方面，有明确的实现价值的责任
517		-
518		-最大化价值的共同目标，以及共同的风险和回报
519		-)))
520		-|(% style="width:123px" %)**构造关系的方法**|(% style="width:302px" %)(((
521		-最小化信息共享
522		-
523		-建立一个沟通渠道
524		-
525		-建立价格驱动的工作方式
526		-
527		-减少退出关系的障碍（或提供替代方法）
528		-)))|(% style="width:441px" %)(((
529		-积极寻找添加价值的机会
530		-
531		-提供多个联系点和渠道
532		-
533		-独立而不是联合进行预测
534		-
535		-限制信息共享
536		-
537		-投资关系管理
538		-)))|(% style="width:427px" %)(((
539		-建立深厚的信任感和合作关系
540		-
541		-双方都承认彼此的重要性
542		-
543		-共同投资精简流程
544		-
545		-共同开展各种活动
546		-
547		-自由交换敏感信息
548		-
549		-为退出关系制造障碍
550		-)))
551		-
552		- BRM研究所（2014）。
553		-
554		-
555		-|(((
556		-你知道吗？
557		-
558		-人们普遍认为，信任越多越好。然而，在服务关系中过度投资以建立信任是有可能的，但这种投资不会为相关方增加价值。
559		-)))
560		-
561		-=== ​​​​​​​4.2.1 基础关系 ===
562		-
563		-当以服务运营效率为基石时，基础关系通常适用于标准产品和服务。在这样的关系中的服务提供者对弹性且重复的操作感兴趣，这些操作能够以最小的努力和偏差实现特定的服务水平。商业服务提供者的主要目的是续约，它通常避免与服务消费者建立关系，因为产品或服务可能无利可图。在这种关系中，客户通常对服务提供者的服务有良好的控制，在达到服务水平，但往往难以评估服务价值。
564		-
565		-
566		-表4.4讨论了基本关系的优缺点。
567		-
568		-
569		-表4.4中讨论了基础关系的优缺点。
570		-
571		-(% style="width:885px" %)
572		-| |(% style="width:370px" %)**优点**|(% style="width:313px" %)**缺点**
573		-|**服务消费者**|(% style="width:370px" %)(((
574		-容易退出
575		-
576		-容易控制
577		-)))|(% style="width:313px" %)(((
578		-重点放在效率和交易上
579		-
580		-难以开发更深的关系
581		-
582		-难以评估服务价值
583		-)))
584		-|**服务提供者**|(% style="width:370px" %)(((
585		-单一渠道交流
586		-
587		-易于测量和报告
588		-
589		-在服务管理实践中建立规模和运行的效率
590		-
591		-标准客户管理方法
592		-)))|(% style="width:313px" %)(((
593		-重点放在效率和交易上
594		-
595		-难于开发可信赖的关系
596		-
597		-几乎没有信息共享
598		-
599		-客户容易退出
600		-
601		-客户受价格驱动
602		-
603		-很少有机会提供差异化客户体验
604		-)))
605		-
606		-=== ​​​​​​​4.2.2 合作关系 ===
607		-
608		-在合作的服务关系中，服务提供者通常根据服务消费者需求来定制产品和服务。客户期望服务提供者会考虑服务成果和体验，而不仅仅是服务水平。由于服务提供者需要寻找新的机会来为服务消费者创造额外的价值，因此相关各方之间应该轻松交换信息。对于商业服务提供者，在成为一个值得信赖的供应商和提供高价值的服务而得不到投资回报的过程中，存在花费太多时间和资源的风险。
609		-
610		-
611		-表4.5列出了合作关系的优缺点。
612		-
613		-
614		-表4.5列出了合作关系的优缺点。
615		-
616		-| |**优点**|**缺点**
617		-|**服务消费者**|(((
618		-服务提供者根据特定的服务消费者需求定制服务
619		-
620		-与服务提供者开展更多业务的新机会
621		-)))|(((
622		-相互的活动可能感觉不协调
623		-
624		-昂贵且资源密集
625		-)))
626		-|**服务提供者**|(((
627		-更高的服务消费者依赖于服务提供者
628		-
629		-从客户收到更多信息；有机会更有效地帮助推动有价值的解决方案
630		-)))|(((
631		-相互之间的活动可能会感觉不协调昂贵且耗费大量资源
632		-
633		-错误分配资源的更高风险新的运行的复杂性出现了
634		-
635		-客户给服务提供者带来内部问题
636		-
637		-相比客户减少了效率和控制
638		-)))
639		-
640		-=== ​​​​​​​4.2.3 伙伴关系 ===
641		-
642		-在合作伙伴中，服务提供者和服务消费者可以充当跨各种职能和流程的一种组织协调活动。随着相互依赖程度和集成的增长，双方可能会通过共同设定目标和优先级来在战略层面上保持一致。
643		-
644		-
645		-实现高水平的透明度可能会付出高昂的代价，但它为发现缺陷和找到最佳解决方案提供了机会。双方将更耐心地等待结果，因为他们将通过长期的眼光来看待关系。
646		-
647		-
648		-表4.6列出了合伙企业的优缺点。
649		-
650		-
651		-表4.6列出了伙伴关系的优缺点
652		-
653		-(% style="width:923px" %)
654		-| |(% style="width:446px" %)**优点**|(% style="width:307px" %)**缺点**
655		-|服务消费者|(% style="width:446px" %)(((
656		-透明度允许双方识别
657		-
658		-效率低下并共同解决这些问题，从而导致成本相互减少
659		-
660		-长期规划开辟新的市场机会
661		-)))|(% style="width:307px" %)(((
662		-锁定可能会阻止客户增加要求或退出
663		-
664		-分离既痛苦又费时
665		-)))
666		-|服务提供者|(% style="width:446px" %)(((
667		-透明度允许双方识别
668		-
669		-效率低下并共同解决这些问题，从而导致成本相互减少
670		-
671		-长期规划开辟新的市场机会
672		-
673		-吸引更大，更具战略性客户的机会
674		-)))|(% style="width:307px" %)分离既痛苦又费时
675		-
676		-|(((
677		-**ITIL故事：了解服务关系类型**
678		-
679		-[[image:1639038881228-610.png||height="55" width="44"]]//Mariana：我们与大学有合作的关系，它为校园内的停车位和充电站提供名义上的费用。反过来，我们为大学提供服务的折扣，它可以将供应提供给新生。//
680		-
681		-[[image:1639038890493-937.png||height="56" width="37"]]**S**//olmaz：我们的基本服务关系包括我们从中采购汽车零件和发动机油的供应商。//
682		-
683		-[[image:1639038900744-862.png||height="51" width="38"]]**H**//enri：艾克苏的合作关系和eCampus Car Share共享利润，资源和策略。艾克苏提供了资金，专业知识，基础架构和技术来设置和维护服务。当我们将服务的汽车份额扩展到其他地区时，Mariana的体验将对规划和设计中的汽车具有不可估量的价值。//
684		-)))
685		-
686		-== 4.3 建立服务关系 ==
687		-
688		-关系管理可以是角色、职能、和/或组织的能力或实践。在本出版物中，关系管理主要被视为一种实践，其详细描述可以在关系管理实践指南中找到。
689		-
690		-
691		-关系管理实践通过服务关系阶梯应用于客户旅程，该阶梯覆盖关系的初始阶段。客户旅程的其他步骤在培养和塑造服务关系方面发挥作用。关系阶梯包括图片4.2中所示的步骤，并在表4.7中进行了详细说明。
692		-
693		-
694		-服务关系阶梯可以应用于不同的服务关系，但必须适应于特定的系统。
695		-
696		-
697		-业务关系管理研究所（BRM研究所）定义了三种与该方法一致的关系管理比喻。根据专业指南（BRM研究所，2014），关系管理的作用是：
698		-
699		-* 连接器，促进生产性连接，形成需求/供应并影响利益相关者
700		-* 协调器，协调角色、资源和能力，并协调和汇总需求和供应
701		-* 导航器，促进利益相关者之间的融合，促进规划并指导相关角色。
702		-
703		-(% style="text-align:center" %)
704		-[[image:1639038943791-508.png]]
705		-
706		-
707		-图片4.2 服务关系阶梯
708		-
709		-
710		-表4.7 服务关系阶梯的步骤
711		-
712		-|(% style="width:294px" %)**步骤**|(% style="width:690px" %)**描述**|(% style="width:311px" %)**ITIL 管理实践和工具**
713		-|(% style="width:294px" %)创建允许出现关系模式的环境|(% style="width:690px" %)(((
714		-在开始任何通信和协作之前，服务提供者和客户需要进行相遇。
715		-
716		-服务提供者应该建立或利用现有的聚会场所，以使客户与契动足够接近，并使相互努力成为可能。
717		-
718		-
719		-)))|(% style="width:311px" %)(((
720		-关系管理
721		-
722		-* 管理沟通渠道
723		-* 提供联系点
724		-* 营销活动
725		-* 服务目录管理
726		-* 使用服务目录邀请客户开始对话
727		-)))
728		-|(% style="width:294px" %)(((
729		-建立和维持信任与关系
730		-)))|(% style="width:690px" %)在客户表现出兴趣之后，建立信任和将关系作为进一步价值共创的基础变得至关重要。|(% style="width:311px" %)关系管理（所有活动和工具）
731		-|(% style="width:294px" %)了解服务提供者功能（与步骤4：同意同时执行）|(% style="width:690px" %)当客户选择服务提供者时，客户需要确保服务提供者具有一组适当的可用功能，以充分利用提供者的功能。|(% style="width:311px" %)
732		-|(% style="width:294px" %)了解客户需求（与步骤3：供应同时执行）|(% style="width:690px" %)(((
733		-服务关系主要专注于满足服务消费者需求。
734		-
735		-服务提供者应该利用关系来发现和理解客户需要创建的价值。
736		-)))|(% style="width:311px" %)(((
737		-关系管理
738		-
739		-●了解客户需求实现价值
740		-
741		-●业务分析
742		-)))
743		-|(% style="width:294px" %)评估相互准备和成熟度|(% style="width:690px" %)(((
744		-了解需求后，可以回答双方最后的参与问题。
745		-
746		-服务提供者：我们有能力与客户一起创建价值吗？我们的资源和实践是否与客户需求相匹配？
747		-
748		-客户：我们是否足够成熟，并准备好使用服务提供者适应契动，并记住所有必要的限制以及实现价值，服务，价值所需的活动？
749		-)))|(% style="width:311px" %)(((
750		-●业务提供者成熟度模型^^a^^
751		-
752		-●成熟度评估和审核
753		-)))
754		-
755		-a: BRM研究所，2014年。
756		-
757		-
758		-表4.8 契动的初始活动
759		-
760		-(% style="width:1103px" %)
761		-|**步骤**|(% style="width:309px" %)**客户状态**|(% style="width:402px" %)**客户活动**|(% style="width:285px" %)**服务提供者活动**
762		-|**认知**|(% style="width:309px" %)客户应该知道这项服务/ 服务提供者|(% style="width:402px" %)市场调查|(% style="width:285px" %)(((
763		-营销活动
764		-
765		-促进有效的联系
766		-)))
767		-|**动机**|(% style="width:309px" %)客户应该主动与服务提供者建立服务关系|(% style="width:402px" %)没有|(% style="width:285px" %)(((
768		-营销活动
769		-
770		-了解替代方案
771		-
772		-刺激需求
773		-)))
774		-|**联系**|(% style="width:309px" %)(((
775		-客户启动服务关系应该很容易：
776		-
777		-1. 去哪里，单一联系点
778		-1. 提供什么
779		-)))|(% style="width:402px" %)(((
780		-联系服务提供者
781		-
782		-浏览服务目录
783		-)))|(% style="width:285px" %)(((
784		-提供单一联系点
785		-
786		-管理服务目录
787		-)))
788		-|**塑造期望**|(% style="width:309px" %)服务提供者应使客户期望得到好的体验|(% style="width:402px" %)(((
789		-检查服务提供者过去的性能和/或公众评级（如果有）
790		-
791		-尽职调查
792		-)))|(% style="width:285px" %)(((
793		-聚集并成形需求
794		-
795		-确保适当的容量和服务提供的功能
796		-)))
797		-
798		-=== 4.3.1  创建容许契动关系模式的环境 ===
799		-
800		-为了成功使用服务消费者进行契动，服务提供者可以指导客户进行表4.8中所示的步骤。
801		-
802		-
803		-==== 4.3.1.1 初始契动工具 ====
804		-
805		-服务目录支持服务提供者在与服务使用者初次接触时的活动，是确保：
806		-
807		-* 客户的认知
808		-* 开始对话的初始邀请
809		-* 支持与标准和非标准服务供应有关的讨论。
810		-
811		-服务目录可以采用多种形式（例如文档，在线门户或工具）来使当前服务列表能够传达给受众。这些表单对于不同的受众有不同的视图（例如，发起人、客户、用户、IT到IT-客户视图）（ITIL Foundation，第5.2.10.1节）。客户视图可以提供服务绩效和财务数据。然而，服务目录可能不包括客户为了做出明智的决定而需要的关于风险和约束的完整信息。服务提供者应该与客户合作，以提供有关选择的明确信息，并概述客户愿意接受的风险。只有客户可以决定服务消费者愿意接受哪些风险，但服务提供者有责任澄清风险的性质和范围，并根据客户的偏好进行处理。
812		-
813		-
814		-服务提供者使用的另一个功能强大的工具集是CRM系统，该系统存储有关当前和潜在客户的数据，以及历史和当前关系状态的数据。客户可以直接访问有关相关服务供应、服务级别和条件的信息，以及获得的产品和服务的概述（Bordoloi等，2018）。
815		-
816		-
817		-==== 4.3.1.2 维持允许出现关系模式的环境 ====
818		-
819		-服务提供者应该创建允许开发关系模式的舒适环境。为此，应考虑以下几点：
820		-
821		-* 如果没有定期的沟通，就有可能造成和扩大双方之间的距离。即使在没有必要沟通的情况下，也应安排交流并遵守计划。
822		-* 如果服务提供者提供了联系点但没有及时响应，则可能对组织产生负面影响。
823		-* 服务事件可能导致客户归咎于服务提供者的情况。在这些情况下，应该管理冲突。
824		-* 服务提供者组织、客户组织或市场上总会有一些干扰。风险管理实践可以指出哪些风险对合作环境的威胁最大。
825		-
826		-|(((
827		-**ITIL故事：建立服务关系**
828		-
829		-[[image:1639039151460-470.png||height="48" width="46"]]//Mariana：我们这学年快结束了，很多学生都要毕业离校了。虽然我们已经在现有的学生中获得了良好的声誉，但在两个月后新学生到来之前，我们面临着失去许多忠实客户的风险。我们每年都需要和这些新生建立服务关系。对于那些不打算离开的学生，我们必须与他们建立并保持牢固的关系，这样才能增加我们在未来几年留住他们作为忠实客户的机会。//
830		-
831		-[[image:1639039161376-906.png||height="48" width="43"]]//Tomas：有些学生在大学里待的时间更长，要么继续深造，要么在大学里工作。//
832		-
833		-[[image:1639039151460-470.png||height="48" width="46"]]//Mariana：我们可以为在大学待较长时间的学生提供特别服务，以激励他们使用我们的服务，并与他们建立更牢固的关系。//
834		-
835		-[[image:1639039172592-758.png||height="50" width="39"]]//Radhika：有些学生仅参加短期课程，我们也应提x供能反映其需求的产品。//
836		-
837		-[[image:1639039151460-470.png||height="48" width="46"]]//Mariana：对于这些学生，我们可以提供无义务的、短期的、现收现付的服务。这是根据这个群体的情况和需要量身定制的，将有助于与他们建立关系。。//
838		-)))
839		-
840		-=== ​​​​​​​4.3.2 建立和维持信任与关系 ===
841		-
842		-由于服务提供商和客户必须共同创造价值，他们需要建立和管理一种透明的关系，这种关系支持相互信任，注重在优化成本和风险的同时实现服务成果。为了有效地做到这一点，这些操作通常被称为科目：业务关系管理（对于内部服务提供者）和CRM（对于商业服务提供者）。在ITIL中，关系管理实践指南涵盖了这两个学科。
843		-
844		-
845		-信任可能以多种方式出现（Hacker等，1999），包括：
846		-
847		-* **基于知识** 随着时间的推移，对另一组人的认识可以提高信任度。
848		-* **基于核算** 在服务关系中，信任可以快速建立。在这种情况下，这两个组都可以权衡潜在的机会与风险。
849		-
850		-==== 4.3.2.1 信任和关系因素 ====
851		-
852		-可信赖的特征分为三个维度（Hacker等，1999）：
853		-
854		-* **能力 **产生结果的能力
855		-* **承诺** 关心共同目标以及他人的成功和福利
856		-* **一致性** 以同样的方式完成预期任务的能力。
857		-
858		-图4.3显示了模型中的这些维度。这些维度提供了个人、团队或组织的信任关系的基础（Hacker等，1999）。
859		-
860		-
861		-为了值得信赖，服务提供者和客户都应致力于体现三个Cs 模型。表4.9显示了该模型如何应用于服务关系。
862		-
863		-(% style="text-align:center" %)
864		-[[image:1639039414823-634.png]]
865		-
866		-
867		-图4.3 三Cs 可信度模型
868		-
869		-
870		-表4.9 适用于服务关系的三个Cs 模型
871		-
872		-|**信任因素**|**服务提供者**|**客户**
873		-|**能力**|(((
874		-足够的知识和技能
875		-
876		-足够的需求能力
877		-
878		-展示敏捷性/适应性
879		-)))|展示敏捷性/适应性
880		-|**承诺**|(((
881		-关注客户的成功或分享共同的/相互的目标
882		-
883		-诚实、尊重和合作
884		-
885		-解释影响客户的行动
886		-
887		-熟悉服务消费者及其需求
888		-
889		-鼓励/促进开放的双向沟通
890		-)))|(((
891		-关注服务提供者的成功或分享共同的/相互的目标
892		-
893		-诚实、尊重和合作
894		-
895		-解释影响服务提供者的变更
896		-
897		-鼓励/促进开放的双向沟通
898		-)))
899		-|**一致性**|(((
900		-先寻求理解，再寻求被理解
901		-
902		-在一段时间内完成预期的表现
903		-
904		-及时响应
905		-)))|(((
906		-先寻求理解，再寻求被理解
907		-
908		-披露足够数量的信息
909		-)))
910		-
911		-==== 4.3.2.2 建立信任和关系活动 ====
912		-
913		-表4.10中列出了客户和服务提供者为建立信任而执行的不同方法和活动的描述。这些活动同样适用于内部和外部关系。
914		-
915		-
916		-表4.10 关系管理活动
917		-
918		-|**关系类型**|(% style="width:536px" %)**建立信任和关系方法**|(% style="width:341px" %)**客户**|**服务提供者**
919		-|(((
920		-**基本关系**
921		-
922		-[[image:1639039486627-293.png]]**[[image:file:///C:/Users/19805/AppData/Local/Temp/msohtmlclip1/01/clip_image001.png]]**
923		-)))|(% style="width:536px" %)信任和关系主要是通过遵循正式的规程和控制来建立的|(% style="width:341px" %)(((
924		-与服务提供者共享需求
925		-
926		-检查服务提供者过去的绩效
927		-
928		-查看过去和现在客户的公开评级和反馈
929		-
930		-尽职调查/检查符合行业标准和/或认证的证据
931		-
932		-检查SLA
933		-)))|(((
934		-管理服务目录和服务请求目录
935		-
936		-不要质疑来自客户的请求
937		-
938		-满足需求/限制服务目录范围内的协作
939		-
940		-提供报告
941		-
942		-注重产出
943		-)))
944		-|(((
945		-**合作关系**
946		-
947		-[[image:1639039493704-758.png]]**[[image:file:///C:/Users/19805/AppData/Local/Temp/msohtmlclip1/01/clip_image002.png]]**
948		-)))|(% style="width:536px" %)(((
949		-信任和关系主要是通过各方的广泛沟通和努力建立起来的，以取得成果
950		-
951		-一致的结果、反馈、半正式控制
952		-)))|(% style="width:341px" %)(((
953		-共享需求
954		-
955		-接受服务提供者的建议
956		-
957		-执行审计或成熟度评估交叉引用
958		-)))|(((
959		-根据客户需求的变化，管理和开发服务组合
960		-
961		-为可能的服务解决方案提供建议
962		-
963		-由成果驱动，而不是输出驱动
964		-)))
965		-|(((
966		-**伙伴关系**
967		-
968		-[[image:1639039500519-639.png]]**[[image:file:///C:/Users/19805/AppData/Local/Temp/msohtmlclip1/01/clip_image003.png]]**
969		-)))|(% style="width:536px" %)信任和关系的建立主要是通过分享风险和回报，关注共同的目标和共同创造的价值|(% style="width:341px" %)(((
970		-建立与服务提供者协作的开放平台
971		-
972		-分享目标、风险和回报
973		-
974		-联合战略/计划/项目规划
975		-
976		-展示出对不断变化环境的敏捷性和适应性
977		-)))|(((
978		-建立与客户协作的开放平台
979		-
980		-展示促进客户发展和创新的能力
981		-
982		-关注变化环境中的价值实现，而不是固定的成果
983		-)))
984		-
985		-==== 4.3.2.3 持续建立信任和关系 ====
986		-
987		-许多因素威胁着信任和关系，包括：
988		-
989		-* 分离双方的自然趋势；例如，来自服务消费者的服务提供者
990		-* 服务提供者的资源和实践不断变化
991		-* 服务消费者的风险状况和容忍度随时间变化
992		-* 任何一方的新员工改变了服务关系的性质（确保与与新员工及时接触很重要）
993		-* 不可避免的客户投诉（正式的客户投诉和升级流程可以缓解这一因素）。
994		-
995		-|(((
996		-**ITIL的故事：建立和维持信任与关系**
997		-
998		-[[image:1639039544729-234.png||height="48" width="41"]]//Mariana：我们希望新生们在进入大学时，能够了解到我们的服务。我们计划通过提供有吸引力的价格来积极地针对这些学生，以便他们注册我们的服务。我们将要求大学在其欢迎信息中包含指向我们网站的链接，以方便潜在客户与我们联系。//
999		-
1000		-[[image:1639039554566-680.png||height="45" width="32"]]**R**//adhika：在新的学年开始之初，我们可能需要在服务台上配备更多人员，以管理注册数量的增加。//
1001		-)))
1002		-
1003		-=== ​​​​​​​4.3.3 理解服务提供者能力 ===
1004		-
1005		-理解和评估服务提供者能力的最流行方法是通过审计和成熟度评估。
1006		-
1007		-
1008		-有些信息可能是公开可用的，也可能是通过与提供者当前和过去的客户进行沟通而收集的（例如，参考评论）。然而，能力评估通常关注流程和规程，例如文档和记录。表4.11提供了一个理解服务提供者能力的清单。
1009		-
1010		-
1011		-表4.11 理解服务提供者能力清单
1012		-
1013		-|**组织和人员**|**信息和技术**
1014		-|(((
1015		-理解组织目标并检查组织的结构是否能够最佳地满足这些目标。
1016		-
1017		-要评估的项目/属性：
1018		-
1019		-●重复（活动、组织职能等）
1020		-
1021		-●沟通效果（渠道、频率、反馈等）
1022		-
1023		-●工作模式和决策结构（集中式与分散式，基于流程的与分层式的）
1024		-
1025		-●信任和透明度，控制级别
1026		-
1027		-●知识和学习文化
1028		-
1029		-●技能和能力
1030		-)))|(((
1031		-评估用于决策的信息质量，以及技术是否以最佳方式支持目标和决策流程。
1032		-
1033		-要评估的项目/属性：
1034		-
1035		-●当前的技术项目
1036		-
1037		-●集成
1038		-
1039		-●技术债务
1040		-
1041		-●技术趋势（技术发展如何改变工作方式）
1042		-
1043		-●数据和信息的可靠性
1044		-
1045		-●技术性能
1046		-)))
1047		-|**合作伙伴与供应商**|**价值流和流程**
1048		-|(((
1049		-服务提供者如何有效地管理其合作伙伴和供应商？
1050		-
1051		-服务提供者是否依赖战略供应商？
1052		-
1053		-关键供应商关闭时，对服务运营可能产生的影响是什么？
1054		-
1055		-它们是否无缝集成在价值链中？
1056		-)))|(((
1057		-有哪些流程，以及它们如何运作的？
1058		-
1059		-流程绩效如何？
1060		-
1061		-价值流的管理效率如何？
1062		-)))
1063		-
1064		-|(((
1065		-**ITIL故事：了解服务提供者功能**
1066		-
1067		-
1068		-[[image:1639039664566-243.png||height="53" width="47"]]//Mariana：为了与新的汽车清洁合作伙伴契动，我们进行了一次审计，以确保它们在财务上是可行的。我们检查了其他乘客对其服务的评论。我们还确保他们有能力提供绿色清洁产品。//
1069		-)))
1070		-
1071		-=== ​​​​​​​4.3.4 了解客户需求 ===
1072		-
1073		-重要的是要记住，客户不购买服务；他们购买的是特定需求的实现。他们有工作要做（克里斯滕森等，2016），服务提供者必须理解这些工作，才能识别服务消费者的需求、偏好以及期望的成果和体验。
1074		-
1075		-
1076		-==== 4.3.4.1 价值驱动 ====
1077		-
1078		-第1章介绍的服务价值驱动框架可用于分析和理解服务消费者的需求和期望的成果如何与服务提供者的服务供应链接。图4.4中再次显示了该框架。
1079		-
1080		-
1081		-业务关系管理：BRM Professional（BRMP）定义了两种将结果与产品和服务联系起来的方法（BRM Institute，2014，5.6.3），包括：
1082		-
1083		-* **基于价值的方法（自上而下）** 服务提供者讨论客户最紧迫的问题或目标，然后分析计划（如何解决或实现它们）、促成因素（实施计划需要什么功能或资源）和技术（生产或服务如何交付这些能力和促成因素）。
1084		-* **基于解决方案的方法（自下而上） **服务提供者讨论其产品和服务，并试图将与紧迫的消费者问题或目的连接起来，以相反的顺序回答与基于价值的方法相同的问题。
1085		-
1086		-客户需求通常是由具体问题引起的。研究这些问题可以提供通过产品和服务实现需求的最佳方法。需要考虑的问题有：
1087		-
1088		-* 主要问题是什么？
1089		-* 这些问题的原因是什么？
1090		-* 这些问题如何影响服务消费者的目的、目标和绩效?
1091		-* 当前的服务消费者背景是什么，包括影响或受这些问题影响的战略、架构和组织结构？
1092		-
1093		-不要将客户需要与客户需求混淆。了解需要后，服务提供者仍然需要理解需求。然后，各方就可将服务消费者的需要作为具体的需求表达出来。这些活动将在第5章中进一步介绍。
1094		-
1095		-(% style="text-align:center" %)
1096		-[[image:1639039745940-752.png]]
1097		-
1098		-图4.4 价值驱动框架的示例
1099		-
1100		-
1101		-==== 4.3.4.2 风险与成本 ====
1102		-
1103		-理解产品和服务的受影响成果以及风险和成本，应该是发现客户需求和构建服务关系的一部分。
1104		-
1105		-
1106		-表4.12显示了自助服务门户引入后的预期结果、消除的风险和成本，潜在损失以及风险和成本的示例。
1107		-
1108		-
1109		-表4.12 自助服务门户的积极和消极影响
1110		-
1111		-| |(% colspan="2" %)**客户体验**
1112		-| |**积极**|**消极**
1113		-|**成果**|(((
1114		-支持的成果，包括增强经验和满足偏好:
1115		-
1116		-●更快的沟通
1117		-
1118		-●所有用户请求的单点联系人
1119		-
1120		-●工单跟踪
1121		-
1122		-●用户对IT维护计划的了解
1123		-)))|(((
1124		-受影响的结果:
1125		-
1126		-●用户与IT之间的直接沟通较少
1127		-)))
1128		-|**风险**|(((
1129		-风险消除:
1130		-
1131		-●降低响应时间
1132		-
1133		-●降低服务请求分类中的错误数量
1134		-)))|(((
1135		-引入的风险：
1136		-
1137		-●单点故障
1138		-
1139		-●对用户能力的依赖度更高
1140		-
1141		-●外部人员可获取敏感事件数据
1142		-)))
1143		-|**成本**|(((
1144		-成本消除：
1145		-
1146		-●减少服务台人员
1147		-)))|(((
1148		-引入的成本
1149		-
1150		-●自助式管理和维护（在让用户参与管理门户的情况下）
1151		-)))
1152		-
1153		-==== 4.3.4.3 体验和偏好 ====
1154		-
1155		-偏好影响服务消费者的服务体验，尤其是对于服务消费者是个人的大众市场服务。表4.13显示了服务消费者体验的关键生产和服务因素。
1156		-
1157		-
1158		-一旦确定了成果、体验和偏好，则利益相关者就可以检查实现服务消费者的需求和所做出的决策。
1159		-
1160		-
1161		-|(((
1162		-**ITIL故事：了解客户需求**
1163		-
1164		-[[image:1639039862455-516.png||height="57" width="44"]]//Mariana：为了实现我们对环境可持续性的愿景，我们研究的一个方案是在我们的一些电动汽车上安装自行车架。然而，当我们调查我们的客户时，我们发现很少有人用汽车来运输自行车。如果没有这种需求，自行车架就不会为我们的客户带来任何价值，所以我们没有采取这种做法。//
1165		-)))
1166		-
1167		-表4.13 服务客户体验的关键生产和服务因素
1168		-
1169		-(% style="width:857px" %)
1170		-|**因素**|(% style="width:558px" %)**描述**
1171		-|**服务质量方面**|(% style="width:558px" %)(((
1172		-功能性
1173		-
1174		-数据和信息可用性
1175		-
1176		-可用性
1177		-
1178		-绩效和容量
1179		-
1180		-信息安全
1181		-
1182		-持续性
1183		-
1184		-可访问性
1185		-
1186		-可用性
1187		-)))
1188		-|**风险与合规性**|(% style="width:558px" %)服务符合相关规定
1189		-|**价格与成本**|(% style="width:558px" %)(((
1190		-服务符合消费者的风险承受水平
1191		-
1192		-顾客感知的成本效益比
1193		-)))
1194		-|**设计和便利性**|(% style="width:558px" %)(((
1195		-服务价格与替代品的比较，例如竞争对手的服务
1196		-
1197		-用户体验
1198		-)))
1199		-|**兼容性和接口**|(% style="width:558px" %)(((
1200		-服务简化了一个耗时的过程
1201		-
1202		-架构
1203		-
1204		-与客户已经使用的其他服务的兼容性，跨各种渠道或设备的可用性
1205		-)))
1206		-|**信息，透明度和公平性**|(% style="width:558px" %)(((
1207		-所有关于服务定价、实际使用等方面的数据都可以很容易地提供给客户
1208		-
1209		-用户可以方便地检查数据的准确性
1210		-)))
1211		-|**控制能力**|(% style="width:558px" %)客户保持对服务消费的控制，并拥有管理服务选项、定价(如果有定价选项)等工具。
1212		-|**社会责任感**|(% style="width:558px" %)客户确保服务供应商符合适用的社会责任规范，如污染、奴役和公平贸易。
1213		-
1214		-=== ​​​​​​​4.3.5 评估相互准备和成熟度 ===
1215		-
1216		-相互准备是指双方完成适当的检查（即过往的绩效检查）和尽职调查（即审计），建立了初步信任，并准备形成工作关系，以便共同创建价值。
1217		-
1218		-
1219		-相互准备和成熟度评估可能会根据关系类型而有所不同：
1220		-
1221		-* 在基础关系中，客户可以检查服务提供者以往的绩效，避免投资于额外的保证措施，例如审计或准备评估。
1222		-* 在合作关系中，客户可以使用审计和成熟度评估工具评估服务提供者成熟度。与基础关系相比，协作和沟通机制的准备也变得非常重要。在所有利益相关者之间明确协调成果并就反馈程序达成一致是至关重要的。
1223		-* 在伙伴关系中，开放和信任是相互成功的关键因素。因此，尽管可能会进行正式的能力成熟度和以往的绩效检查，但是协作的准备是至关重要的。
1224		-
1225		-表4.14 显示了不同类型的评估与不同类型的关系的相关性。
1226		-
1227		-
1228		-表4.14 契动步骤的评估类型
1229		-
1230		-(% style="width:725px" %)
1231		-|(% style="width:336px" %)**评估的属性**|(% style="width:157px" %)**基础关系**|(% style="width:109px" %)**合作关系**|(% style="width:121px" %)**伙伴关系**
1232		-|(% style="width:336px" %)能力成熟度和以往的绩效（服务提供者）|(% style="width:157px" %)关键|(% style="width:109px" %)中度|(% style="width:121px" %)轻度
1233		-|(% style="width:336px" %)准备合作（双方）|(% style="width:157px" %)N/A|(% style="width:109px" %)中度|(% style="width:121px" %)关键
1234		-|(% style="width:336px" %)为变更做好准备（客户）|(% style="width:157px" %)N/A|(% style="width:109px" %)中度|(% style="width:121px" %)关键
1235		-
1236		-==== 4.3.5.1 关系成熟度 ====
1237		-
1238		-在执行评估之前，最好理解关系成熟度的水平。根据业务提供者成熟度模型（BRM研究所，2014），成熟度级别（例如基础型，合作型和伙伴关系）可以由一组需求和供应特性确定，如表4.15所示。
1239		-
1240		-
1241		-表4.15 业务提供者成熟度模型
1242		-
1243		-(% style="width:939px" %)
1244		-| |(% style="width:363px" %)**需求**|(% style="width:448px" %)**供应**
1245		-|基础关系|(% style="width:363px" %)(((
1246		-交易自动化
1247		-
1248		-来自业务竖井的请求
1249		-
1250		-专注于职能绩效
1251		-)))|(% style="width:448px" %)(((
1252		-交易处理以及基本服务
1253		-
1254		-为业务竖井定制/修改产品
1255		-
1256		-专注于稳定性
1257		-)))
1258		-|合作关系|(% style="width:363px" %)(((
1259		-端到端流程自动化/ 业务
1260		-
1261		-集成
1262		-
1263		-事务性数据管理信息（决策信息）
1264		-)))|(% style="width:448px" %)(((
1265		-企业系统
1266		-
1267		-业务流程改进点/重新设计开放式网络和网关
1268		-
1269		-大多数IT服务的优化/通用基础架构
1270		-
1271		-外包商品服务技术驱动的业务功能是推动市场差异化的IT催化剂
1272		-)))
1273		-|(((
1274		-(% class="wikigeneratedid" id="H4F194F3451737CFB" %)
1275		-伙伴关系
1276		-)))|(% style="width:363px" %)(((
1277		-创新与成长
1278		-
1279		-业务和市场情报
1280		-
1281		-可重新配置的功能组合（HR，IT，资产等）
1282		-)))|(% style="width:448px" %)标准接口
1283		-
1284		-在这个模型中，关系成熟度级别是累积的:成熟度级别构建在较低的成熟度级别之上，并包括较低的成熟度级别。
1285		-
1286		-
1287		-这个模型中的需求和供给是相互依存的；服务提供者在基本的关系中仅满足需求，但在合作关系中刺激需求。随着关系的成熟，服务消费者开始学习开发产品和服务，从而导致复杂的业务问题。但是，服务提供者将学会提供更有效的服务并塑造需求。
1288		-
1289		-
1290		-==== 4.3.5.2 成熟度评估和基准测试 ====
1291		-
1292		-其中一个利益干系人比另一个更成熟的服务关系通常会失败，因为变化会导致不兼容。因此，评估服务提供者和服务消费者的成熟度是有帮助的。
1293		-
1294		-
1295		-表4.16中的问题可用作评估的清单。
1296		-
1297		-
1298		-表4.16 基于服务管理四维模型的服务提供者和服务消费者成熟度评估
1299		-
1300		-|(% style="width:108px" %)**服务消费者/服务供应者**|(% style="width:260px" %)**组织和人员**|(% style="width:306px" %)**价值流和流程**|(% style="width:354px" %)**信息和技术**|**合作伙伴与供应商**
1301		-|(% style="width:108px" %)组织和人员|(% style="width:260px" %)(((
1302		-用户准备好与服务提供者代理商的沟通？
1303		-
1304		-服务提供者的代理可以理解用户吗？
1305		-)))|(% style="width:306px" %)(((
1306		-服务提供者的规程是否进行了修改，以便让用户参与进来？
1307		-
1308		-用户可以按照规程操作吗?
1309		-
1310		-我们能确保用户遵守规程吗?
1311		-)))|(% style="width:354px" %)(((
1312		-服务提供者的产品和服务是否配置为向用户提供正确的访问级别？
1313		-
1314		-是否对用户进行了正确使用技术和流程数据的培训？
1315		-)))|服务提供者的供应商代理是否准备好与用户沟通？
1316		-|(% style="width:108px" %)价值流和流程|(% style="width:260px" %)(((
1317		-服务提供者的代理商可以遵循消费者的规程吗？
1318		-
1319		-我们可以确保代理商遵循规程吗？
1320		-)))|(% style="width:306px" %)(((
1321		-哪些服务消费者规程为服务提供者的规程提供输入，反之亦然？
1322		-
1323		-服务消费者和服务提供者需要更改哪些规程？
1324		-)))|(% style="width:354px" %)(((
1325		-服务提供者的产品是否正确地自动执行服务消费者规程？
1326		-
1327		-是否需要变更？服务提供者是否知道服务消费者的职能型要求？
1328		-)))|服务提供者的供应商是否准备好遵循服务消费者的规程？
1329		-|(% style="width:108px" %)信息和技术|(% style="width:260px" %)服务提供者的代理商是否具有支持消费者技术所需的技能和能力？|(% style="width:306px" %)服务提供者的规程是否涵盖了服务提供者需要管理的技术和信息系统（例如变更启用、服务配置管理、审计）？|(% style="width:354px" %)(((
1330		-需要集成哪些信息系统？
1331		-
1332		-集成信息系统的最有效与最高效的方式是什么？
1333		-
1334		-双方都需要在信息系统方面做出哪些改变？
1335		-)))|(((
1336		-服务提供者的供应商是否具备支持服务消费者技术所需的技能和能力？
1337		-
1338		-
1339		-)))
1340		-|(% style="width:108px" %)合作伙伴与供应商|(% style="width:260px" %)(((
1341		-服务提供者与服务消费者的供应商之间的沟通渠道是否已经建立？
1342		-
1343		-服务提供商的代理是否准备好与服务消费者的供应商沟通？
1344		-)))|(% style="width:306px" %)(((
1345		-服务提供者的规程是否适用于服务消费者的供应商（如服务集成和管理、变更管理、审计）？
1346		-
1347		-服务消费者的供应商是否准备好遵循服务供应商的规程（如果相关）？
1348		-
1349		-我们怎样才能保证？
1350		-)))|(% style="width:354px" %)服务提供者的产品是否配置为向服务消费者的供应商提供正确的访问权限？|(((
1351		-服务提供者的供应商和服务消费者的供应商之间是否建立了沟通渠道？
1352		-
1353		-服务提供者是否确保所有各方遵守所有协议以及法律和法规要求？
1354		-)))
1355		-
1356		-==== 4.3.5.3 评估协作的准备情况 ====
1357		-
1358		-利益相关者之所以对协作感兴趣，是因为与其他利益相关者的持续合作更容易实现目标。为了评估协作的准备情况，必须考虑表4.17中概述的信息。
1359		-
1360		-
1361		-表4.17 准备评估检查表
1362		-
1363		-(% style="width:875px" %)
1364		-|(% style="width:438px" %)**合作准备因素**|(% style="width:434px" %)**清单和参考**
1365		-|(% style="width:438px" %)是否建立起最初的信任？|(% style="width:434px" %)三个Cs 模型
1366		-|(% style="width:438px" %)我们是否与相关的利益相关者契动？管理**层**是否支持合作活动？|(% style="width:434px" %)(((
1367		-利益干系人分析
1368		-
1369		-利益干系人地图（影响力/兴趣网格）
1370		-)))
1371		-|(% style="width:438px" %)我们是否为密切合作创建了组织基础？|(% style="width:434px" %)(((
1372		-确保原则和运营活动保持一致
1373		-
1374		-检查信息系统与其他资源之间的集成和接口
1375		-
1376		-沟通风险承受能力和约束条件(风险登记册)
1377		-
1378		-建立沟通渠道，尤其是投诉渠道（利益干系人沟通计划）
1379		-
1380		-跨协作组织分配资源（主要是人员，技术和信息）
1381		-)))
1382		-
1383		-==== 4.3.5.4 评估组织变革准备情况 ====
1384		-
1385		-在某些情况下，成功交付服务可能需要转换组织惯例和例程，以便从服务获得价值。这需要组织变革管理。ITIL Foundation定义了以下有效组织变革管理实践的属性：
1386		-
1387		-* 明确而相关的目标
1388		-* 坚强而坚定的领导
1389		-* 愿意和有准备的参与者
1390		-* 持续的改进点。
1391		-
1392		-为了评估组织变革的准备情况，可以使用表4.18中所示的检查表。
1393		-
1394		-
1395		-表4.18 组织变革准备情况评估清单
1396		-
1397		-(% style="width:884px" %)
1398		-|(% style="width:184px" %)**组织变革准备就绪因素**|(% style="width:697px" %)**检查清单**
1399		-|(% style="width:184px" %)**明确而相关的目标**|(% style="width:697px" %)(((
1400		-服务关系是否有清晰的愿景？
1401		-
1402		-是否有效传达了变更的原因？
1403		-)))
1404		-|(% style="width:184px" %)**坚强而坚定的领导**|(% style="width:697px" %)(((
1405		-赞助商是否因成功的业绩而备受尊敬？
1406		-
1407		-利益相关者是否信任管理层考虑他们的利益？
1408		-
1409		-是否有横向领导者？
1410		-)))
1411		-|(% style="width:184px" %)**愿意和有准备的参与者**|(% style="width:697px" %)(((
1412		-是否有奖励贡献者的计划？
1413		-
1414		-组织中是否有足够水平的系统知识？利益相关者是否理解变更的全貌，而不仅仅是他们自己的一部分？
1415		-)))
1416		-|(% style="width:184px" %)**持续的改进点**|(% style="width:697px" %)(((
1417		-组织中有多少变更阻力？
1418		-
1419		-过去的改进是否成功？
1420		-
1421		-当前有多少变更？
1422		-
1423		-公事公办与创新之间是否有良好的平衡？如果组织过分强调持续运营的责任，创新就会受到影响。如果创新是唯一的焦点，那么对当前经营活动的责任就被忽略了。因此，成功的组织应该找到正确的平衡点。
1424		-)))
1425		-
1426		-读者应参阅组织变革管理实践指南以获取详细指导。
1427		-
1428		-
1429		-== 4.4  管理供应商和合作伙伴 ==
1430		-
1431		-在某种程度上，每个组织都依赖于其他组织提供的服务（ITIL Foundation，第3.3节）。因此，对于服务提供者和服务消费者，与供应商和合作伙伴的关系同样重要。这包括与主要供应商建立更紧密、更协作的关系，以发现和实现价值新的价值，并减少失效的风险（ITIL Foundation ，第5.1.13节）。
1432		-
1433		-
1434		-由于服务提供者在其供应商的关系中充当服务消费者，因此服务提供者的旅程包括与客户旅程相同的步骤：
1435		-
1436		-* **探索** 理解确定的潜在供应商的需求和价值
1437		-* **契动** 与供应商建立关系
1438		-* **供应** 形成需求和需求规范
1439		-* **协议 **就供应商提供的产品和服务的条款和条件进行谈判并达成一致
1440		-* **引入** 决定是否应从供应商处获得产品和服务，并执行转换活动
1441		-* **价值共创** 创建消费服务并与供应商进行服务交互
1442		-* **实现价值 ** 持续跟踪、评估和评价价值实现，并改进整个过程。
1443		-
1444		-服务消费者和提供者具有不同的视角和关注领域。通常不同的方面是服务集成和编排。服务集成负责协调或编排参与产品或服务的采购和提供的所有供应商。它侧重于端到端的提供服务，确保控制供应商的所有接口和结果，并促进了供应商之间的协作（ITIL Foundation ，第5.1.13节）。
1445		-
1446		-
1447		-越来越多的服务提供者被其客户视为服务中心，并期望为了客户的利益协调其供应商和合作伙伴。其他人则被视为“黑匣子”；他们的客户不想知道他们的服务提供者与之合作的供应商和合作伙伴的依赖关系。服务消费者的这些期望极大地影响了服务提供者管理其与供应商和合作伙伴之间关系的方式。
1448		-
1449		-
1450		-服务集成有四个主要类型，每个组织都应该考虑最适合它的模型，以便转换到更协调的服务供应商环境。这些模型是：
1451		-
1452		-* **作为服务集成和管理的保留组织 **保留的组织管理所有供应商并自行协调服务集成和管理职能
1453		-* **单一供应商 **其中供应商提供所有服务以及服务集成和管理职能
1454		-* **服务守护者 **供应商除了管理其他供应商外，还提供服务集成和管理职能以及一个或多个交付职能
1455		-* **独立的服务集成商 **即使供应商不向组织提供任何服务，也可以由供应商提供服务集成和管理职能并管理所有其他供应商。
1456		-
1457		-如果服务提供者充当服务集成商，则通常代表客户建立关系和协作。在某种程度上，现在每个服务提供商都是服务集成商。
1458		-
1459		-
1460		-表4.19 列出了当服务提供者充当服务集成商时服务提供者活动的契动步骤。
1461		-
1462		-
1463		-表4.19 关系管理服务集成商活动
1464		-
1465		-(% style="width:891px" %)
1466		-|(% style="width:278px" %)**步骤**|(% style="width:610px" %)**服务集成商活动**
1467		-|(% style="width:278px" %)**创建容许契动关系模式的环境**|(% style="width:610px" %)(((
1468		-审视消费者环境，以寻找新的供应商和合作伙伴，以实现消费者战略和目标
1469		-
1470		-与可能的供应商进行联系和谈判
1471		-
1472		-检查供应商过去的业绩和/或公众评级，并管理尽职调查(如果相关的话)
1473		-)))
1474		-|(% style="width:278px" %)**建立和维持信任与关系**|(% style="width:610px" %)与正常服务关系相同
1475		-|(% style="width:278px" %)**了解服务提供者能力**|(% style="width:610px" %)(((
1476		-根据关系类型、依赖程度和风险定义管理供应商的标准
1477		-
1478		-根据标准识别和分类现有供应商，并关注最重要的供应商
1479		-
1480		-根据客户的需求评估供应商的能力
1481		-)))
1482		-|(% style="width:278px" %)**了解服务消费者需求**|(% style="width:610px" %)与正常服务关系相同
1483		-|(% style="width:278px" %)**评估相互准备和成熟度**|(% style="width:610px" %)(((
1484		-跟踪供应商的绩效和合规性
1485		-
1486		-评估供应商的成熟度
1487		-
1488		-评估更大的供应链，管理与供应商及其分包商有关的风险，以影响供应商提供服务的能力
1489		-)))
1490		-
1491		-供应商管理实践可用于为参与服务交付的所有供应商创建一个单一的可视点，以确保一致性并实现价值。这有助于回答以下问题：
1492		-
1493		-* 服务提供者在管理其合作伙伴和供应商时是否有效？
1494		-* 服务提供者是否依赖战略供应商？
1495		-* 关键供应商停工对服务运营可能导致的影响是什么？
1496		-* 供应商是否与服务提供者的价值链无缝集成？
1497		-
1498		-此实践还确保与供应商的协议与预期的服务结果和客户需求相一致，并监督其绩效，以确保条款、条件和目标得到满足。
1499		-
1500		-
1501		-|(((
1502		-**ITIL的故事：管理供应商和合作伙伴**
1503		-
1504		-[[image:1639040403078-235.png||height="47" width="45"]]//Mariana：我们面临的一个问题是，校园充电站经常出现故障，无法将车充满电。尽管eCampus Car Share不管理站点，但当汽车未充满电时，端到端的客户体验会受到负面影响。客户认为这些站点的功能是我们的责任。//
1505		-
1506		-[[image:1639040414134-638.png||height="47" width="39"]]**S**//olmaz：充电站归大学所在的地方议会所有，并由该议会的供应商安装。//
1507		-
1508		-[[image:1639040403078-235.png||height="47" width="45"]]//Mariana：这种情况并不少见，在这种情况下，为了提供我们的服务，我们对其他提供商的依赖很多。//
1509		-
1510		-[[image:1639040433389-601.png||height="46" width="43"]]//K//atrina//：我刚和朋友们从计划了三个小时的旅行回来，去看一个当地的乐队。不幸的是，这辆车没有充满电。当我们试图给它充电时，校园里的充电站坏了。充电站不属于eCampus Car Share或大学：完全是一个不同的组体。艾克苏服务台能够帮我找到另一辆车，但在使用之前，我不得不等待它退回。//
1511		-
1512		-[[image:1639040403078-235.png||height="47" width="45"]]//Mariana：尽管eCampus Car Share对充电站不负直接责任，但我们的客户仍会受到其他原因造成的故障和缺陷的影响。这是一个很好的例子，说明了所有服务交互和接触点是如何帮助客户感知我们的服务和价值的。//
1513		-
1514		-[[image:1639040414134-638.png||height="47" width="39"]]**S**//olmaz：我们正在寻求与充电运营商更紧密的合作，以减少我们的汽车无法正确充电的机会。//
1515		-)))
1516		-
1517		-== 4.5 总结 ==
1518		-
1519		-良好的关系是管理合作关系、伙伴关系和基础关系所必须的。培养良好的关系包括创建能够契动的关系模式，建立信任并理解相互需求和价值的环境。
1520		-
1521		-
1522		-供应商关系等同于其他服务关系，应进行相应的管理。多个供应商的集成和协调是供应商关系中的一个特例。
1523		-
1524		-
1525		-
1526	1526	----
1527	1527
1528		-= 5. 步骤3：供应 =
1529		-
1530		-[[image:1639040503323-766.png]]
1531		-
1532		- 管理需求和机会
1533		-
1534		- 指定和管理客户需求
1535		-
1536		- 设计服务供应和用户体验
1537		-
1538		- 销售并获得服务产品
1539		-
1540		-
1541		-客户和服务提供者之间的服务关系越密切，就越能进一步形成客户需求和服务供应。供应步骤有助于客户阐明其需求和要求，并帮助服务提供者设计匹配的服务供应。本章描述了基于价值驱动、数据驱动和以用户为中心的服务设计来确定、设计、销售和获得产品和服务所需的服务交互和接触点。无论服务来自内部还是外部服务提供者，本指南均适用。表5.1概述了形成需求和服务提供的目的。
1542		-
1543		-
1544		-表5.1 形成需求和服务提供的目的
1545		-
1546		-(% style="width:1180px" %)
1547		-|**供应**|**对于服务消费者**|(% style="width:583px" %)**对于服务提供者**
1548		-|促进成果和体验|确保客户清楚表达了服务消费者的需求和要求|(% style="width:583px" %)(((
1549		-了解如何为服务消费者和服务提供者创建价值，以及服务提供者如何支持该价值共创
1550		-
1551		-使服务提供者能够平衡供应和需求
1552		-)))
1553		-|优化风险和合规性|(((
1554		-最小化购买服务而不满足实际需要的风险
1555		-
1556		-减少供应商误解消费者需求的风险
1557		-)))|(% style="width:583px" %)(((
1558		-尽量减少无法履行承诺服务的风险
1559		-
1560		-尽量减少客户不满意的风险
1561		-)))
1562		-|优化资源并最小化成本|确保将资金投资于能够优化投资回报的领域|(% style="width:583px" %)确保在最佳区域使用时间和资源
1563		-
1564		-|(((
1565		-**ITIL故事：步骤3 – 供应**
1566		-
1567		-[[image:1639040709737-670.png||height="50" width="44"]]//Mariana：我们的eCampus汽车共享服务已受到大学学生和员工的欢迎。我们为普通汽车用户提供订阅会员资格，为间歇性用户提供不同的定价等级。我们的汽车是电动的，这使它们比传统的汽车更环保，因为它们排放的废气更少。另外，汽车共享会降低汽车拥有率，减少道路上的汽车行驶次数，并减少客户出行次数，因为客户会将差事合并为一次出行以最大程度地增加支出。我们为自己能提供一个干净、安全、可靠的往返于校园的其他交通选择而自豪。//
1568		-)))
1569		-
1570		-== 5.1 管理需求和机会 ==
1571		-
1572		-就服务而言，需求和容量是相互关联的。服务无法存储供以后使用。当服务价值只有在服务提供者的供给满足服务使用者的需求时才能被共同创造。如果需求得不到满足，设施和资源就会浪费。同样，当需求高于容量时，也会丢失机会。为了优化服务机会，服务提供者应调整容量和影响需求。正确理解不同的客户群体和部门如何使用其服务至关重要。
1573		-
1574		-
1575		-=== 5.1.1 业务活动模式 ===
1576		-
1577		-要了解如何使用服务，分析业务活动的模式很有用的。事实和图表是通过监控和日志记录生成的，反映了服务的使用情况。这些信息将有助于采取措施满足需求高峰。
1578		-
1579		-
1580		-|(((
1581		-**定义：业务活动模式（PBA）**
1582		-
1583		-一个或多个业务活动的工作负载描述。PBA用于帮助服务提供者理解和支持不同级别的服务消费者活动。
1584		-)))
1585		-
1586		-表5.2描述了一个会计流程的PBA。
1587		-
1588		-
1589		-表5.2 会计处理的业务活动模式示例
1590		-
1591		-(% style="width:689px" %)
1592		-|**角色**|(% style="width:350px" %)**实现价值创建高峰工作量**|(% style="width:200px" %)**高峰时间**
1593		-|雇员|(% style="width:350px" %)所有员工填写工时表|(% style="width:200px" %)每周五午餐后
1594		-|会计|(% style="width:350px" %)获取或构建，报告和质量检查准备工资|(% style="width:200px" %)每月12日至15日
1595		-|会计|(% style="width:350px" %)年终结账|(% style="width:200px" %)每年十一月/十二月
1596		-
1597		-另一种可以识别的模式是通过分析来电。例如，结果可以表明，所有支助请求中平均有85%是在每个工作日的两个短期间提出的:10:00-11:00和15:00-16:00。服务台还可以看到所需的特定服务。有了这些信息，服务台可以通过在高峰时段提供额外人员或创建自助服务解决方案来管理需求。
1598		-
1599		-
1600		-业务活动模式非常有用，因为它们允许组织做出基于事实的决策。检测到的模式可以反映不同的趋势。有些模式是重复的，例如表5.2中的示例；其他模式显示增长或下降。一些服务业经历了快速增长，这将对容量产生影响。需要进一步的业务分析来理解总体情况并做出正确的决策。
1601		-
1602		-
1603		-一旦确定了模式，就可以使用不同的选择来调整和管理容量以形成需求。
1604		-
1605		-
1606		-=== 5.1.2 优化容量 ===
1607		-
1608		-|(((
1609		-**容量和性能管理实践**
1610		-
1611		-
1612		-容量和性能管理实践为容量管理提供了三个视角：
1613		-
1614		-* **业务容量管理 **由客户触发的容量需求计划。
1615		-* **生产和服务容量管理 **管理特定生产或服务的端到端容量。
1616		-* **组件容量管理 **监视并调整生产或服务组件的容量。如果其中一个组件没用更多的容量，则整个服务将受到影响。在IT中，大多数组件都可以通过监视和调优进行设置，以避免容量问题。
1617		-
1618		-读者应参阅容量和性能管理实践指南以了解更多详细信息。
1619		-)))
1620		-
1621		-由于容量和需求是相互交织的，为了更好地利用稀缺资源，必须同时考虑两者。管理需求的目的是了解不同的用户概况并影响其行为。容量和性能管理代表等式的另一侧。如图5.1所示，这是关于根据实际需求确定容量大小的问题。
1622		-
1623		-
1624		-有多种方法可以调整和管理容量。一些措施包括：
1625		-
1626		-* 在高峰期增加容量
1627		-* 避免在高峰时段运行其他繁重的工作量
1628		-* 不允许在变更生产或服务时引入冻结期。
1629		-
1630		-需求可以是固定的，也可以是可变的。如果需求是可变的，最好的做法可能是将其与可变容量相匹配，以帮助服务消费者将固定成本转换为可变成本。这就是云计算通常的工作方式。客户(例如开发团队)使用灵活的自服务机制，在需要的时候添加额外的基础设施容量，在完成工作时释放它，从而使容量可供其他用户使用。
1631		-
1632		-
1633		-优化资源容量的另一种方法是将工作量转移到服务消费者。在为数字化转型设计技术服务时，这是相关的。数字化服务允许服务消费者管理自己的银行账户，在线订购机票以及预订自己的航班和酒店，以减轻服务提供者的需求负担，并增加服务消费者对服务的控制。
1634		-
1635		-(% style="text-align:center" %)
1636		-[[image:1639040866308-122.png]]
1637		-
1638		-图片5.1容量和供应之间的关系
1639		-
1640		-
1641		-=== 5.1.3 成形或平滑需求 ===
1642		-
1643		-服务提供者经常受到服务需求的巨大差异和有限容量的挑战。如果不能形成与供应相匹配的需求，将导致容量投资的回报率很低。例如，服务台的训练有素的支持人员数量有限。因此，使需求与服务容量相匹配是一项重要的学科。
1644		-
1645		-
1646		-允许服务消费者提前预订时间的预订服务有助于平滑需求。为了最大程度地减少损失，监控错过预约的比率并以类似比率补偿超额预订是很常见的。服务提供者通常通过延迟承诺时间、增加取消费用、或发送提醒以确保消费者提前一天确认预订来防止风险出现。
1647		-
1648		-
1649		-服务提供者通常供应价格激励来影响消费者的行为。差别收费是根据使用时间对同一服务收取不同的价格。例如，电力公司可能会在一天的不同时间收取不同的价格。给电动汽车充电最便宜的时间可能是在晚上。这样，运营者可以影响白天的服务容量，同时在非高峰时段实现更好的利用率。
1650		-
1651		-
1652		-收益管理是一种对利用价格激励来优化容量的技术。这是一个高度自动化的流程，使用历史和实时数据估算未来的需求，并相应地调整价格。例如，当在互联网浏览即将到来的旅行时，如果提前几个月搜索，则价格可能相对较低。然而，随着旅行日期的临近，同一次旅行的价格将大幅上涨。
1653		-
1654		-
1655		-==== 5.1.3.1 定价和计费机制 ====
1656		-
1657		-差异性收费和收益管理是使用定价和计费机制管理容量和需求的示例。这些机制可用于驱动服务使用者在服务的许多方面的行为。既然它是如此强大的工具，就应该有意识地使用它来驱动正确的行为。例如，如果云服务提供者希望其服务消费者在不需要时清除容量，则“按单位付费” 策略将正确地影响行为。
1658		-
1659		-
1660		-计费作为一种需求管理机制存在不利的副作用。这些副作用的一些示例如表5.3所示。应进行适当的评估和测试，以确保定价机制驱动预期行为。这是由思考和整体工作的指导原则和迭代的反馈进展所支持的。
1661		-
1662		-
1663		-在服务关系中，定价和计费机制应经常进行评估和评价，以确保它们按预期工作。这些机制通常在合同协商阶段就已达成共识，但对它们如何影响行为和价值创造却知之甚少。
1664		-
1665		-一些重要的问题是：
1666		-
1667		-* 驱动行为的机制是否以一种对双方都有最大价值的方式存在？
1668		-* 这些机制是否能够实现资源的双赢和最佳利用？
1669		-* 双方是否有激励措施来推动服务的改进？
1670		-
1671		-表5.3 计费机制的不良负作用示例
1672		-
1673		-|**案例**|**定价机制**|**不受欢迎的行为**|**问题**|**解决方案**
1674		-|由内部服务提供者提供的业务关键信息系统|为了弥补成本，服务提供者为每个用户定义了一个昂贵的许可证成本。|由于高昂的许可证成本，业务单元只购买了一到两个人的许可证，并让他们“服务”单位的其余部分。|服务提供者无法覆盖成本，并且需要提高许可证价格。|当检测到这种模式时，管理层决定在业务部门之间平均分担成本，使所有员工都能够使用服务。
1675		-|复印和打印|没有定价机制。|因为是免费的，所以做了很多不必要的彩印。|没有“打印前思考”的动机，也没有意识到彩印的成本。|通过引入收费和宣传活动，打印量减少了50%，用户切换到黑白默认设置。
1676		-
1677		-==== 5.1.3.2 服务改进点机会 ====
1678		-
1679		-服务质量取决于对改进点机会的管理。来自客户的冲突请求、糟糕的定价激励或缺乏专门的改进点预算可能是冲突的来源。因此，服务提供者必须专业地处理改进点机会。持续改进需要所有权、服务改进点预算和透明的流程，以确定如何识别、捕获、评估、优先级和处理改进点机会。
1680		-
1681		-
1682		-服务改进点的机会来源广泛。一些示例包括：
1683		-
1684		-* 服务使用情况分析
1685		-* 事件、投诉和问题分析
1686		-* 服务请求模式分析
1687		-* 自助服务模式分析和知识文章的使用
1688		-* 变更请求和改进点请求
1689		-* 用户反馈
1690		-* 客户反馈和客户满意度调查
1691		-* 服务需求增加
1692		-* 新技术和创新
1693		-* 市场变化
1694		-* 来自服务提供者团队的反馈。
1695		-
1696		-目的旨在收集有关服务如何促进利益相关者价值的事实。这是价值驱动和数据驱动洞察力的一个方面。业务分析人员可以协助分析数据、识别需要、阐明需求并推荐解决方案。分析应基于定期且频繁捕获的真实数据。为了加深理解并做出正确的决定，需要进行深入的业务分析。
1697		-
1698		-
1699		-持续改进实践指南和ITIL®4：指导计划和改进中介绍了有关如何完成结构化服务改进的详细指南。业务分析实践指南中介绍了执行业务分析的任务和技术。
1700		-
1701		-
1702		-=== 5.1.4 构建客户商业案例 ===
1703		-
1704		-当需要和需求得到理解和解决时，可以起草通过新的或变更的产品和服务来满足需求的商业案例。
1705		-
1706		-
1707		-|(((
1708		-**定义：商业案例**
1709		-
1710		-组织资源支出的理由，提供有关成本、收益、选择、风险和问题的信息。
1711		-)))
1712		-
1713		-商业案例的核心是财务分析，用于评估收益率和风险的支出。此分析应同时考虑定性和定量方面。商业案例为正表示预期收益超过支出和风险。
1714		-
1715		-
1716		-服务商业案例理想地应覆盖完整的服务的所有区域，从服务消费者用途到产品和资源，如图片1.11所示。它应包括所有相关的收益，成本和风险。
1717		-
1718		-
1719		-商业案例涉及的主要问题包括：
1720		-
1721		-* 目的是什么？
1722		-* 这种新的或变更的服务如何支持组织的战略目标？
1723		-* 需要解决的问题是什么？
1724		-* 期望的成果是什么？
1725		-* 谁是利益相关者，它将如何影响他们？
1726		-* 预期的收益和损害是什么？
1727		-* 需要哪些资源和投资？
1728		-* 预算和预期成本是什么？
1729		-* 有什么风险？
1730		-* 流程的时间表是什么？
1731		-* 我们什么时候需要资源和投资？
1732		-* 总体拥有成本（TCO）是多少？
1733		-* 预期的投资回报率（ROI）或净现值（NPV）是多少？
1734		-* 为了创造价值和实现收益，需要进行哪些组织上的变革？
1735		-
1736		-商业案例的目的是为明智的决策奠定基础，但它是基于假设的。这些假设存在不确定性，并且常常与需求和利益冲突。不同的视角会影响业务分析人员对用户需求进行优先排序的能力。表5.4突出显示了冲突和不确定性的典型领域。
1737		-
1738		-
1739		-表5.4 典型冲突和不确定性领域的示例
1740		-
1741		-|(% style="width:161px" %)**调查范围**|(% style="width:1133px" %)**组织中冲突区域的典型示例**
1742		-|(% style="width:161px" %)(((
1743		-**价值**
1744		-
1745		-**理解真实的需求**
1746		-)))|(% style="width:1133px" %)(((
1747		-谁是关键利益相关者？如何优先考虑他们的需求？
1748		-
1749		-服务的用户可能具有与客户/发起人不同的需求和优先级（请参见表5.5）。其他利益相关者组也可能具有相互冲突的需求。
1750		-)))
1751		-|(% style="width:161px" %)(((
1752		-**成果**
1753		-
1754		-**理解收益**
1755		-)))|(% style="width:1133px" %)可能只考虑短期利益而牺牲长期利益，这很诱人。另一方面，长期收益通常会面临更多的不确定性和风险。
1756		-|(% style="width:161px" %)(((
1757		-**成本**
1758		-
1759		-**理解资本和运营支出**
1760		-)))|(% style="width:1133px" %)我们的生产或服务需要什么样的投资？实施的成本是多少？维护和支持成本是多少？使用成本是多少？需要多少培训？需要什么样的组织变革？
1761		-|(% style="width:161px" %)(((
1762		-**风险**
1763		-
1764		-**理解不确定性和影响**
1765		-)))|(% style="width:1133px" %)很难事先知道服务提供者是否愿意并且能够满足服务消费者的需求。重要的是要从一开始就建立良好的关系，不仅要与销售人员建立联系，而且还要与将成为服务提供关键资源的人员建立联系。在协议和合同中包含建立关系的激励措施和双赢文化是很好的。
1766		-
1767		-表5.5中描述了优先级与需求冲突的一些传统领域。
1768		-
1769		-
1770		-表5.5 客户和用户优先级与需求
1771		-
1772		-|**客户**|**用户**|**冲突**|**考虑**
1773		-|(((
1774		-**成本**
1775		-
1776		-成本效益高吗？是否与其他提供者的类似服务进行比较？可以削减任何东西以使其更便宜吗？
1777		-)))|(((
1778		-**性能**
1779		-
1780		-有多快？响应时间有多快？当我需要它时，它会在那里吗？使用起来有多方便？它触发什么情绪？
1781		-)))|性能越好，服务就越贵。|(((
1782		-决定使用成本更低的服务应平衡如下代价：
1783		-
1784		-●性能下降
1785		-
1786		-●负面的用户体验。
1787		-)))
1788		-|(((
1789		-**收益率/价值**
1790		-
1791		-该服务会带来投资回报吗？它会帮助我们实现业务的目标吗？
1792		-)))|(((
1793		-**易用性**
1794		-
1795		-用户界面有多直观？我需要通过多少屏幕才能完成交易？它会使我的工作更轻松吗？
1796		-)))|易用性可能需要额外的投资。|随着时间的推移，易用性将提高收益率。这将使用户能够实现组织目标，并尽量减少培训和支持的需要。
1797		-|(((
1798		-**服务影响**
1799		-
1800		-该服务的实际目的是什么？它会提高生产效率吗？它能改善服务吗？这个组织将来会在哪里？
1801		-)))|(((
1802		-**质量**
1803		-
1804		-该服务实际上是如何工作的？它会做它需要所做的一切吗？是否提供培训？它能解决问题吗？
1805		-)))|顾客并不关心服务质量，只要它能以合理的价格完成工作。|(((
1806		-如果用户难以获得高质量，将对业务产生负面影响：
1807		-
1808		-●性能下降
1809		-
1810		-●用户犯的错误更多
1811		-
1812		-●错误和更正
1813		-)))
1814		-|(((
1815		-**创新**
1816		-
1817		-这项服务是否能够识别机会并有助于业务增长？它会开辟新市场吗？它能实现交付扩展吗？
1818		-)))|(((
1819		-**一致性**
1820		-
1821		-这项服务在使用期间是否可用？
1822		-)))|客户可能有用户不感兴趣的战略问题。|借助IT服务，许多例行公事任务可以实现自动化，使员工能够更加专注于创新。
1823		-
1824		-对时间和成本的短期关注可能会在以后造成大量成本：
1825		-
1826		-* **时间不足** 如果没有足够的时间让用户参与进来，则可能导致他们的需求得不到满足。因此，该服务可能无法让用户更好地完成工作，并可能会导致负面的商业案例。
1827		-* **选择最便宜的提供者** 在这种情况下，价格和成本承受着巨大的压力，这可能会使服务提供者的利润空间很小，也可能会阻止服务提供者在不亏损的情况下保持灵活性。这可能会导致一种以牺牲价值为代价的紧张关系。
1828		-
1829		-=== 5.1.5 构建服务提供者商业案例 ===
1830		-
1831		-服务提供者需要构建和维护一个可盈利的、可行的商业案例。否则，服务提供者可能会赔钱，最终倒闭。在构建商业案例时，服务提供者应该考虑客户的商业案例。
1832		-
1833		-
1834		-在为服务准备商业案例时，确定服务如何适合于现有的和未来的服务组合是非常重要的。组合管理和财务管理实践是这项工作的关键资源。
1835		-
1836		-
1837		-服务是一种通过促进客户希望实现（想要达到）的结果，而无需客户管理特定成本和风险，从而实现价值共创的一种手段。风险作为服务的一部分转移到服务提供者。
1838		-
1839		-
1840		-为了建立商业案例，服务提供者需求理解提供服务的成本。要做到这一点，它需要有一个考虑所有所需资源的成本模型。分析所有服务管理四维模型中的成本因素可能会有所帮助。这可以包括以下内容：
1841		-
1842		-* 服务所依赖的技术和基础架构的投资和管理
1843		-* 需要价值流和流程才能操作服务并便利所需的成果（运营服务和促进预期结果所需的价值流和流程）
1844		-* 合作伙伴和供应商，它将成为服务提供的一部分
1845		-* 组织方面，例如资源数量以及员工的技能和能力。
1846		-
1847		-许多ITIL 管理实践都可以为客户、组织和服务提供者的新的服务或变更的服务提供输入。这些包括：
1848		-
1849		-* 可用性管理
1850		-* 容量和性能管理
1851		-* 信息安全管理
1852		-* 组合管理
1853		-* 关系管理
1854		-* 服务连续性管理
1855		-* 服务财务管理。
1856		-
1857		-|(((
1858		-**ITIL的故事：管理需求和机遇**
1859		-
1860		-[[image:1639041341602-194.png||height="51" width="46"]]//Mariana：我们分析了我们服务的业务活动模式，发现需求在学期中期的几周内最高，而在假期期间最低。周末需求低于工作日需求。晚间曾经使用很受欢迎，但最近几个月有所下降。我们将此归功于当地政府针对学生开展的一项运动，该运动旨在告诉学生在酒精或毒品影响下开车的危险性。//
1861		-
1862		-**-**[[image:1639041350610-448.png||height="56" width="45"]]**S**//olmaz：我们对我们所提供的服务有影响力并能创造需求。例如，我们在非高峰期提供租车折扣，这样我们就可以将一些需求转移到那段时间。这有助于我们在繁忙时期进行容量规划。//
1863		-
1864		-[[image:1639041359021-160.png||height="51" width="41"]]**R**//adhika：我们已经确定了服务台的两个繁忙时期：学年开始时，客户注册每月订阅；年末，他们会要求退还每月会员费的剩余费用。在此期间，我们增加了服务台的资源。//
1865		-)))
1866		-
1867		-== 5.2 指定和管理客户要求 ==
1868		-
1869		-需求规范应该出现在可视化线中。理想情况下，客户应该让服务提供者参与到一个开放且透明的需求规范流程中。如果在流程中过早的密封了需求，则服务提供者可能无法形成最佳的服务并满足服务消费者需求。
1870		-
1871		-
1872		-许多组织利用业务分析人员与与利益相关者进行契动，以引出和分析代表服务提供者或服务消费者需求。业务分析人员将使用本节中描述的许多技术。业务分析实践指南提供了有关此主题的指南。
1873		-
1874		-
1875		-|(((
1876		-**定义：业务分析**
1877		-
1878		-分析业务或业务的某些元素，定义其需求并推荐解决方案以满足这些需求和/或解决业务问题，并为利益相关者创建价值的实践。
1879		-
1880		-
1881		-业务分析使组织能够以有意义的方式传达其需求，表达变更的基本原理，并设计和描述支持与组织目标相一致的价值创造的解决方案。
1882		-)))
1883		-
1884		-|(((
1885		-**ITIL故事：指定和管理客户要求**
1886		-
1887		-[[image:1639041459049-896.png||height="42" width="43"]]//Mariana：我们发现了新的客户需求：我们的许多客户在这一年中不得不搬家。当他们为此目的使用我们的汽车时，他们需要多次出行，并且比往常更频繁地为汽车充电。他们还将较低电荷的汽车退还，从而很难将汽车出租给下一个客户。此外，它还损害了我们提供环境可持续服务的愿景。//
1888		-
1889		-[[image:1639041467084-729.png||height="53" width="44"]]//Tomas：我鼓励Mariana与艾克苏汽车租赁公司合作，向客户提供拖车，这样他们就可以最大程度地减少出行次数。//
1890		-
1891		-[[image:1639041475311-111.png||height="44" width="45"]]//Katrina：我的室友们已经离开大学回到欧洲的家中，这是我两个月来第二次不得不搬家！eCampus Car Share公司发现，客户偶尔需要拖车来帮助他们搬家，这真是太棒了。现在，我不必寻找其他选择。//
1892		-)))
1893		-
1894		-=== ​​​​​​​5.2.1 角色和责任 ===
1895		-
1896		-明确的角色和职责是指定和管理需求的关键。权威人士必须得到识别，并说明如何捕获、表达和表示用户需求和期望。
1897		-
1898		-
1899		-在大型组织中，客户和用户有时是分开的。结果，期望和要求可能无法协调和统一，如图5.2所示。
1900		-
1901		-(% style="text-align:center" %)
1902		-[[image:1639041500798-489.png]]
1903		-
1904		-图5.2 服务交付三角形：将需求转换为需求所涉及的角色
1905		-
1906		-
1907		-服务提供者和客户之间需要协商并达成协议的事实可能是一个挑战。为了管理感知到的服务质量，必须对期望和需求进行管理。
1908		-
1909		-
1910		-因此，服务提供者可能成为客户和用户之间的中介。为防止这种情况发生，服务消费者需要采取有效的沟通和协调措施。
1911		-
1912		-
1913		-表5.6说明了服务需求规范中涉及的角色和职责编排的一些场景。
1914		-
1915		-
1916		-表5.6 服务消费者角色和需求规范场景的示例
1917		-
1918		-|**场景**|**参与角色**
1919		-|客户从服务提供者订购了预定义的标准服务/产品，例如笔记本电脑，智能手机或应用程序。|(((
1920		-客户根据需求规范从服务提供者中选择标准服务。作为需求规范的一部分，会咨询有代表性的用户。
1921		-
1922		-根据用户的个人需求，用户可以在预定义的备选方案中进行选择。
1923		-)))
1924		-|客户从提供者处获得现成的服务，以便在服务消费者组织内部进行配置、实现和管理。|(((
1925		-客户会预先进行适当的评价，以确保服务符合服务消费者的需求。客户评价它是否为符合目的与用途。即使它是现成的服务，仍然可能有许多配置选项。因此，服务的代表用户参与了需求规范及其实现。
1926		-
1927		-其他利益相关者，例如内部IT部门，对架构的适合性和与现有基础设施的集成提出了非功能性需求。
1928		-)))
1929		-|服务提供者为客户或代表客户开发新的和创新服务。|(((
1930		-为了成功开发复杂的新服务，考虑了一种针对需求规范的敏捷方法，以便：
1931		-
1932		-●迭代分解复杂性
1933		-
1934		-●构建技术要求，如安全性，从一开始
1935		-
1936		-●让客户参与进来，确保频繁的反馈循环。
1937		-
1938		-这种方法要求客户在整个生产开发过程中积极参与。为了取得成功，重要的是客户（例如产品负责人）有权代表服务消费者做出有关需求和优先级的决策。用户可能会被咨询，甚至参与启动、演示等。
1939		-)))
1940		-|服务提供者为大众市场设计一种新的商品服务。|需求由服务提供者拥有和管理，在将需求转换为需求的过程中，服务提供者可能涉及服务消费者，也可能不涉及服务消费者。
1941		-
1942		-业务分析人员可以帮助阐明和确定需求的优先级，并将其转换为服务提供者可以理解的语言和格式。这可以用作设计和构建服务的基础。
1943		-
1944		-
1945		-=== ​​​​​​​5.2.2 管理需求 ===
1946		-
1947		-不仅应指定要求，还应在整个流程中对其进行管理和跟踪。需求所有者负责：
1948		-
1949		-* 确定利益相关方群体及其代表
1950		-* 教育代表代表他们的利益相关者群体清楚地表达需求
1951		-* 收集、记录、管理、跟踪和沟通需求
1952		-* 持续确保以正确的方式解释和理解需求
1953		-* 验证产品和服务符合要求。
1954		-
1955		-客户的需求不是一成不变的；随着新的知识和经验的获得，客户的需求也会发生变化。因此，确保将需求集中在客户需求上，以使需求的定义与生产或服务的测试之间的时间尽可能短。
1956		-
1957		-
1958		-需求必须是可测试的。因此，定义如何测试是否满足要求是很重要的。在测试驱动的开发中，需求甚至是由它们必须通过的测试来定义的，以便被认为是满足的。
1959		-
1960		-
1961		-功用需求确保新的或变更的生产或服务是符合目的。功用需求涵盖了数据、信息和功能要求。
1962		-
1963		-
1964		-非功能性需求确保新的或变更的生产或服务在限制范围内使用。非功能性需求的类别包括但不限于：
1965		-
1966		-* 可用性
1967		-* 可用性和可靠性
1968		-* 容量和性能
1969		-* 信息安全
1970		-* 合规性
1971		-* 连续性
1972		-* 可维护性
1973		-* 可操作性
1974		-* 可度量性和可报告性
1975		-* 可扩展性。
1976		-
1977		-=== ​​​​​​​5.2.3 将问题与解决方案分开 ===
1978		-
1979		-我们已经说过，需求应该基于利益相关者需要。然而，指定一个解决方案，而不是将需要转换成需求可能会很有吸引力。在阐明需求时，必须将问题与解决方案分开，以考虑到解决方案无法解决潜在问题的事实。这也有助于将当前的解决方案与所有可能的未来解决方案区分开。表5.7概述了一种简单的技术来帮助完成此流程。
1980		-
1981		-
1982		-表5.8显示了此技术用于服务库的示例。此外，提炼，模型和演示之类的技术还可以帮助利益相关者确保他们真正解决了潜在的问题。
1983		-
1984		-
1985		-表5.7 问题规范技术
1986		-
1987		-(% style="width:708px" %)
1988		-| |(% style="width:279px" %)**当前**|(% style="width:259px" %)**未来**
1989		-|什么？|(% style="width:279px" %)当前问题的本质和需要做的事情的本质|(% style="width:259px" %)真正的需要什么？什么是“本质”？
1990		-|怎么样？|(% style="width:279px" %)当前执行所需工作的方式|(% style="width:259px" %)将来有什么可能的方法来解决问题？
1991		-
1992		-表5.8 问题规范技术的使用示例
1993		-
1994		-| |**当前**|**未来**
1995		-|什么？|一个人需要阅读一本特定的书。|一个人需要可以了解一个特定的主题。
1996		-|怎么样？|(((
1997		-去图书馆询问图书管理员。
1998		-
1999		-图书管理员使用数据库查找图书并登记借出。
2000		-)))|当我们识别问题的本质并探索解决问题的不同方法时，可以采用多种不同的解决方法，包括在线阅读，有声读物，相关文章以及内容摘要。
2001		-
2002		-=== ​​​​​​​5.2.4 最小化可行产品 ===
2003		-
2004		-在Eric Ries (Ries, 2011)所描述的精益创业方法中，关键的信息是制作一个好的商业案例的原型，并在真实的用户中进行测试，以获得反馈。对于原型设计，他依赖于最小可行产品的概念。
2005		-
2006		-
2007		-最小化可行产品是具有足够功能，来满足早期客户的需求并为将来的生产开发提供反馈的产品。该概念已在敏捷开发中广泛使用：服务提供者根据特定的需求设计最小化可行产品，并相应地指定了需求，然后开发产品并将其交付给用户以收集反馈。反馈用于阐明未来的需求，并且通过迭代的方法，产品将根据需求和优先级进行开发。
2008		-
2009		-
2010		-|(((
2011		-**关键信息**
2012		-
2013		-如云计算、大数据、自动化、机器人、物联网和人工智能等新兴技术，需要新兴产品和服务。最小化可行产品和敏捷开发等概念使新兴的数字产品和服务成为可能。
2014		-)))
2015		-
2016		-|(((
2017		-**ITIL故事：最小可行产品**
2018		-
2019		-[[image:1639041656324-582.png||height="46" width="40"]]//Mariana：对于我们的拖车租赁，最小化可行产品将不包括任何自动化，例如跟踪或在线预订。当我们测试和证明我们的观念时，客户需要手动预订拖车。//
2020		-
2021		-[[image:1639041663609-946.png||height="49" width="44"]]**T**//omas：Mariana使用迭代的方法，Mariana发现顾客也需要手推车作为产品供应的一部分。这是她在试租拖车之前没有考虑过的事情。//
2022		-)))
2023		-
2024		-=== ​​​​​​​5.2.5  用户故事和故事映射 ===
2025		-
2026		-用户故事映射是表达服务需求的常用方法。用户故事是一种表示利益相关者所需功能领域的方式，这种方式可以在团队成员之间引起讨论和理解，帮助他们共同努力，将需求转变为有效的产品和服务。用户故事用于描述生产或服务的片段。该技术可以有不同的用途。
2027		-
2028		-
2029		-基于人物角色，设计人员可以收集有关客户旅程和需求的数据，并在小而明确的用户故事中清晰的阐明相应的需求。用户故事具有非常具体和简单的形式：用户可能需要某种东西来实现某种利益。例如，一个人可能需要大汽车才能带家人去度假；其他人可能需要在机场用特快专车来接他们去开会。用户故事易于编写、理解、确定优先级和检查。改进和演示可以帮助您以很少的投资来解决问题。
2030		-
2031		-
2032		-故事映射在不同环境中的处理方式有所不同。映射生产或服务需求的一种常见方法是将生产或服务描述为史诗，然后将史诗分解为特性，然后进一步细分为用户故事。此方法如图5.3所示，并在表5.9中进一步说明。
2033		-
2034		-
2035		-第一个冲刺提供了最小化可行产品（MVP），该产品发布给用户，用于共同创建价值并收集反馈，然后再将更多的故事添加到生产或服务中。
2036		-
2037		-
2038		-INVEST首字母缩略词提供了一个有用的提示，即用户故事应为：
2039		-
2040		-* 独立的
2041		-* 可讨论的
2042		-* 有价值的
2043		-* 可估计的
2044		-* 小的
2045		-* 可测试的
2046		-
2047		-(% style="text-align:center" %)
2048		-[[image:1639041699377-385.png]]
2049		-
2050		-
2051		-图片5.3 故事映射的示例
2052		-
2053		-
2054		-表5.9 使用史诗、功能、促成因素和故事来阐明需求
2055		-
2056		-|**类型**|**描述**|**示例**
2057		-|史诗|(((
2058		-史诗是向客户交付新产品、服务或客户旅程的一项举措。
2059		-
2060		-史诗是大型故事或用户故事，它太大而无法在一个冲刺中涵盖。
2061		-
2062		-史诗包含大量特性。
2063		-)))|从租车到交车的整个用户体验。
2064		-|特性/促成因素|(((
2065		-特性是相关用户故事的集合，这些故事表示生产或服务负责人感兴趣的整个功能区域或能力。
2066		-
2067		-特性由许多用户故事实现。
2068		-
2069		-促进因素是支持探查，架构，基础结构或合规性的特性的技术先决条件。
2070		-)))|繁忙的经理可以在机场接车去开会。
2071		-|用户故事/ 促进因素故事|(((
2072		-一种功能的描述，可以在一个冲刺中开发。
2073		-
2074		-作为<用户>，我想要<需求>，所以<收益>。
2075		-)))|(((
2076		-繁忙的经理可以在机场订购快速通道接送服务，以减轻压力。
2077		-
2078		-繁忙的经理可以在不支付停车费的情况下离开机场，以减少等待时间。
2079		-)))
2080		-
2081		-故事映射通常与敏捷服务设计方法（例如Scrum方法）结合使用。在Scrum方法中，产品负责人负责对每个冲刺中的用户故事进行优先级排序。在冲刺的末尾，生产团队将向实际用户演示这些功能并收集反馈。
2082		-
2083		-
2084		-=== ​​​​​​​5.2.6 MoSCoW方法 ===
2085		-
2086		-MoSCoW方法是一种用于管理需求的简单优先级排序技术。它可让利益相关者明确地就不同的优先级达成一致。
2087		-
2088		-
2089		-该方法还涵盖了无法交付的需求。这很有用，因为列表通常会被不必要的需求填满，例如没人需要的报告。这些需求增加了成本却没有增加价值。
2090		-
2091		-
2092		-MoSCoW的缩写代表：
2093		-
2094		-* 必须 涵盖最重要需要的强制性需求。
2095		-* 应该 在可能的情况下应包括的需求。
2096		-* 可能 如果不影响“应该”或“必须”的需求，那么可以包括的需求。
2097		-* 不会 本次不包括但可能包含在未来版本的需求。
2098		-
2099		-=== ​​​​​​​5.2.7 加权最短作业优先 ===
2100		-
2101		-有时需求具有匹配的优先级。在这些情况下，MoSCoW方法可以被更细粒度的技术（例如气泡排序）所取代或与之结合。然而，如果利益相关者的观点需要一致，这些方法可能不可行。
2102		-
2103		-
2104		-另一种替代方法是使用加权最短作业优先（WSJF）方法（Reinertsen，2009），该方法采用计算机操作系统中使用的调度算法。在这种方法中，作业的权重除以持续时间或规模。特别推荐用于生产或服务开发的权量是延迟成本。延迟成本是一种衡量价值实现程度的指标，以损失的结果和保留的不确定性来度量。在传统的服务管理术语中，延迟成本可视为延迟对服务影响（服务成果），紧急度（时间临界）和风险（不确定性）的结果。对每个作业或需求进行评分，然后根据延迟成本除以持续时间（CD3）对其进行优先级排序。该方法如图5.4所示。
2105		-
2106		-(% style="text-align:center" %)
2107		-[[image:1639041756120-116.png]]
2108		-
2109		-图5.4 延迟成本除以适应服务管理条款的持续时间
2110		-
2111		-
2112		-== ​​​​​​​5.3 设计服务供应和用户体验 ==
2113		-
2114		-现代软件开发方法使新一代数字服务成为可能。这些方法有一个重要的共同点因素：它们在产品和服务的整个设计和的实现流程中都涉及到客户和用户。
2115		-
2116		-
2117		-价值驱动和数据驱动的服务设计意味着一种基于频繁反馈、持续试验和学习的迭代方法，以确保在设计过程的每个步骤中共同创造价值。这需要服务提供者和服务消费者在不同角色之间进行契动、参与和交互。
2118		-
2119		-
2120		-服务提供者将提供其在开发方法上的专业知识，但其成功与否将取决于客户契动。客户应该准备好为流程提供最适合的资源，并确保他们有权代表组织做出决策。
2121		-
2122		-
2123		-重要的是要注意，协议或合同可能会限制敏捷和灵活交付模型的可能性。解决复杂问题时，允许敏捷和灵活的模型的协议是提供者和客户能够在建设性的合作关系中工作的先决条件。
2124		-
2125		-
2126		-=== ​​​​​​​5.3.1 精益思维 ===
2127		-
2128		-精益思维可以被描述为一种流程改进哲学，它将流动效率置于资源效率之上。在精益中，流动是指工作在系统中进行的方式。工作单元可以定义为流经价值流的一件工作。一个好的流动意味着工作单元可以稳定且可预测地移动，而一个坏的流动则描述了一个包含大量队列的系统，其中工作单元将不得不停止并等待。
2129		-
2130		-
2131		-精益定义了五项基本原则，在表5.10中概述。关于利益相关者价值，这些原则集中于支持设计产品和服务的高效且连续的流动。
2132		-
2133		-
2134		-表5.10 精益的五项原则
2135		-
2136		-|(% style="width:102px" %)**精益原则**|(% style="width:1192px" %)**说明**
2137		-|(% style="width:102px" %)识别客户价值|(% style="width:1192px" %)首先是要了解客户及需要。是什么为客户创建价值？所需的成果是什么？为什么需要它？何时何地需要它？多少？多久一次？
2138		-|(% style="width:102px" %)映射价值流|(% style="width:1192px" %)接下来是了解和映射价值流。从服务提供者接收到来自客户的新的或变更的生产或服务的请求起，就需要设计、构建、转换和交付所需的活动。关键是定义工作单元（请求、生产、服务）并映射它如何流过价值链。每个流代表一个价值流。
2139		-|(% style="width:102px" %)创建流动|(% style="width:1192px" %)工作单元在价值流中可能会遇到几个瓶颈。从工作单元的角度来看，这是浪费。通过消除浪费改进流。
2140		-|(% style="width:102px" %)建立拉动|(% style="width:1192px" %)创建流后，下一步就是将优化转换为价值流。该“拉式” 原则确保不会将工作推向下游。它允许限制批量大小和在制品，以便及时完成工作单元。
2141		-|(% style="width:102px" %)寻求完美|(% style="width:1192px" %)该原则反映了持续改进。
2142		-
2143		-价值流映射是一种用于说明和分析价值流逻辑的精益技术：一种将从需求/机会到价值的流动可视化的方法，然后计划如何改进该流动。价值流图以图形的方式概述了物料和信息的流动，并指出了需要改进的地方。这是理解活动如何联系和创造价值的良好基础。
2144		-
2145		-
2146		-关于精益思维如何应用于服务管理的更详细说明请参见ITIL®4：高速IT。
2147		-
2148		-
2149		-=== ​​​​​​​5.3.2 敏捷生产和服务开发 ===
2150		-
2151		-软件开发的敏捷方法始于2001年的敏捷宣言，它鼓励人们优先考虑个人和交互，而不是工作流和工具，工作产品优先于综合文档，客户协作优先于合同，并对计划之后的变更做出响应。
2152		-
2153		-
2154		-敏捷理念的一个方面是应用精益思维。敏捷开发流程中的工作单元是特性（这是职能有限的一部分），还是促进因素（这是职能的技术前提）。
2155		-
2156		-
2157		-另一个方面是迭代开发。在Scrum方法中，需求被捕获在待办项中，该需求由产品负责人连续为下一个冲刺分配优先级。开发团队将在冲刺的末尾进行演示，以在冲刺中进行最大程度的开发，以捕获来自实际用户的反馈。在每个冲刺末尾的评审会议上，将评估方法和团队合作精神。
2158		-
2159		-
2160		-这种方法有助于服务提供者和服务消费者共同成长。他们可以先定义一个最小可行产品，该最小可行产品从合作关系的开始就可以工作并实现价值，然后随着双方的共同成熟，可以在服务功用，功效和体验上进行扩展。
2161		-
2162		-
2163		-持续部署是敏捷理念的另一方面。这意味着特性和促进因素将被不断集成、测试和部署，以便客户准备就绪后就可以发布它们。这方面需要服务提供者和客户之间紧密的协作，这意味着客户和发布必须连续提供客户。持续部署使用的一些方法包括：
2164		-
2165		-* **特征开关（特征标记特性中已编程的“开/关”按钮）**。客户准备就绪时，就可以打开特征开关。如果有问题，该功能可以再次关闭。
2166		-* **暗发布** 新功能已启动，但是在该功能足够成熟之前，新功能的链接是不可见的。
2167		-* **金丝雀发布** 一个暗发布，邀请一些测试用户测试新功能。
2168		-* **蓝绿部署** 用来测试两种可选方案中哪一种方案是最好的一种技术。它可以是另一种图形设计或功能。消费者被随机分为两组，测试相同功能的两个不同版本。
2169		-
2170		-这些技术使快速开发发布和新功能成为可能和安全。
2171		-
2172		-
2173		-=== ​​​​​​​5.3.3 以用户为中心的设计 ===
2174		-
2175		-以用户为中心的设计是一个迭代的设计流程，它使用户置于整个项目流程中所有设计决策的中心。以用户为中心的设计确保生产和服务专注于用户需求和用户体验。
2176		-
2177		-
2178		-=== ​​​​​​​5.3.4 服务设计思维 ===
2179		-
2180		-服务设计思维是解决问题的有效方法。由于该方法的核心是探索、原型，并收集来自真实用户的反馈，因此它是价值驱动、数据驱动和以用户为中心的服务设计的一个很好的例子。它鼓励用户定义价值，并且是一种不断收集有关什么有效和无效的反馈的方法。
2181		-
2182		-
2183		-服务设计思维流程的最终目标是为最初的挑战确定可取的、可行的和可实行的解决方案。
2184		-
2185		-
2186		-=== ​​​​​​​5.3.5 服务蓝图 ===
2187		-
2188		-蓝图是建筑设计的建筑图纸。这些蓝图描绘了建筑物的外观以及建造所需的所有规格。对于数字化服务，蓝图是可视化服务使用的图表，旨在优化用户体验。
2189		-
2190		-
2191		-在服务蓝图中，关键元素由三条水平线隔开：
2192		-
2193		-* **交互线** 这条线确定了客户/ 用户和服务提供者之间的直接服务交互。
2194		-* **可视化线 **这条线客户和用户可见的服务活动与不可见的活动分开。可见的活动显示在此线上方，不可见的活动显示在此线下方。
2195		-* **内部交互线** 这条线将联系的员工与不直接支持与客户和用户进行交互的员工区分开来。
2196		-
2197		-对于一个服务，如果有多个不同的场景，则可能会有多个蓝图。在绘制蓝图时，，从最上面一行开始，然后沿着模板向下，这一点很重要。
2198		-
2199		-
2200		-图5.5 显示了服务蓝图的示例。
2201		-
2202		-(% style="text-align:center" %)
2203		-[[image:1639041944866-674.png]]
2204		-
2205		-图片5.5 服务蓝图的示例
2206		-
2207		-
2208		-服务蓝图可用于以下目的：
2209		-
2210		-* 将客户旅程与生产和服务联系过来
2211		-* 突显用户接触点和服务交互
2212		-* 发现弱点并确定优化机会
2213		-* 努力搭建跨部门的桥梁，避免双重工作量。
2214		-
2215		-总之，服务蓝图帮助组织了解服务提供者如何实现服务，以及客户和用户如何使用服务。服务蓝图确定了面向员工的流程和面向客户/用户的流程之间的依赖关系。它还可以帮助服务提供者识别痛点，优化复杂的相互，并了解改进服务设计和客户旅程以及降低成本的可能性。
2216		-
2217		-
2218		-关于如何制作服务蓝图的模板和更多信息可以在业务分析实践指南中找到。
2219		-
2220		-
2221		-=== ​​​​​​​5.3.6 为引入设计 ===
2222		-
2223		-作为以用户为中心方法中的一部分，应该为每个产品、服务和服务供应定义引入方法，并作为设计的一部分，以平滑引入。
2224		-
2225		-
2226		-文档化的引入方法用于规划引入计划。引入方法包括范围、行动、利益相关者、时间表和其它引入方面。它们可能会根据服务供应的结构，消费者资源、规模、法律和法规要求、风险等等，而有所不同。
2227		-
2228		-
2229		-一个极端是狭窄的可视化线，而另一个极端（例如广泛的可视化线）可以是综合的转换方案（包括员工和基础设施的转移），实现相关组织之间的集成实施，建立共同的治理结构，和退运旧产品和服务。在服务期间，应仔细计划和测试引入方法。
2230		-
2231		-
2232		-在定义引入方法和规划引入计划时，组织应考虑服务管理四维模型。它也应该受到外部因素的影响（ITIL Foundation，第3.5节）。
2233		-
2234		-
2235		-构造引入方法的一种方法是遵循持续改进模型的步骤，如表5.11所示。
2236		-
2237		-
2238		-表5.11 持续改进模型和引入方法
2239		-
2240		-(% style="width:819px" %)
2241		-|**持续改进步骤**|(% style="width:472px" %)**引入方法**
2242		-|**愿景是什么？**|(% style="width:472px" %)定义引入的预期结果。
2243		-|**我们现在在哪里？**|(% style="width:472px" %)建立基线并确定引入的范围，包括所需的资源。
2244		-|**我们想去哪里?**|(% style="width:472px" %)定义引入目标，包括资源的理想组合和交互。
2245		-|**我们如何实现目标？**|(% style="width:472px" %)计划引入的行动和责任
2246		-|**采取行动**|(% style="width:472px" %)根据计划运行引入行动
2247		-|**我们做到了吗?**|(% style="width:472px" %)控制和引入并确保其成功：与基线和目标相比较的控制和度量
2248		-|**我们如何保持动力?**|(% style="width:472px" %)评审和改进
2249		-
2250		-当引入方法被设计为产品、服务或服务供应的一部分时，主要活动包括：
2251		-
2252		-* 识别将与消费者的资源进行交互的提供者的资源
2253		-* 识别将与提供者的资源进行交互的消费者的资源
2254		-* 确定引入每对资源的需求
2255		-* 探索优化和自动化引入的机会
2256		-* 创建需要手动或人工控制引入的规程
2257		-* 测试规程并根据测试结果进行更新（根据需要重复）
2258		-* 文档化并与有关各方进行沟通。
2259		-
2260		-以下ITIL实践支持产品和服务的设计，以实现平稳有效的用户引入：
2261		-
2262		-* 架构管理
2263		-* 服务设计
2264		-* 服务级别管理
2265		-* 服务验证和测试
2266		-* 软件开发和管理。
2267		-
2268		-|(((
2269		-**ITIL的故事：设计服务产品和用户体验**
2270		-
2271		-[[image:1639042090327-629.png||height="50" width="46"]]//Mariana：我们的拖车租赁在客户中很成功。我们的下一步是迭代构建将拖车的自动预订流程构建到艾克苏’s 的预订应用程序中。在我们的手动迭代中，我们发现包含不同拖车类型的图片是很有用的，以便客户可以确定哪种拖车适合其需求。//
2272		-
2273		-[[image:1639042099419-158.png||height="52" width="46"]]//Henri：我们将做一个预告片自动预订流程的金丝雀版本，只有几个测试用户。然后，我们可以将其推广给客户，并随着我们的进展而开发功能。//
2274		-)))
2275		-
2276		-== 5.4 销售并获得服务供应 ==
2277		-
2278		-设计产品、服务和服务供应之后，就需要进行销售。这可能发生在它们构建之前或之后，这取决于服务的性质和服务关系。内部和外部服务提供者都需要销售他们的服务。销售活动将根据客户是内部客户还是外部客户而有所不同。
2279		-
2280		-
2281		-=== ​​​​​​​5.4.1 定价 ===
2282		-
2283		-定价需要决定客户将被收取多少费用。可以使用许多定价选项为服务定价，如表5.12所示。要使一项服务可行，它必须产生足够的收入来支付投资和成本，并产生利润，除非服务提供者是非营利组织。
2284		-
2285		-
2286		-对于商业服务提供者，计费与成本的关系较少，而与感知服务的价值和竞争对手提供的类似服务的相对成本的关系较大。在这些情况下，成本模型将显示影响盈利能力之前的最低收费水平。商业服务提供者也可以根据首选定价模型或服务销售的预期价值以及一年中的消费趋势来做出决定。
2287		-
2288		-
2289		-表5.12 定价选项
2290		-
2291		-|(% style="width:124px" %)**定价选项**|(% style="width:556px" %)**描述**|(% style="width:615px" %)**可适用时**
2292		-|(% style="width:124px" %)**成本**|(% style="width:556px" %)此选项基于盈亏平衡点或成本回收模型。收费项目的定价应可能接近成本单元的实际成本。|(% style="width:615px" %)适用于内部服务提供者或非营利组织。
2293		-|(% style="width:124px" %)**成本加成**|(% style="width:556px" %)加价（％）可以由服务提供者设置以匹配其他投资的回报，也可以由服务提供者设置以满足战略业务需要。|(% style="width:615px" %)加价可以鼓励使用新产品和服务，同时不鼓励使用旧产品和服务。
2294		-|(% style="width:124px" %)**市场价格/行情**|(% style="width:556px" %)价格与市场上类似的服务供应相当。|(% style="width:615px" %)(((
2295		-商品和开箱即用服务。
2296		-
2297		-重要的是要记住，从外部寻找服务可以抵消一些从客户到服务供应商的商业风险。
2298		-)))
2299		-|(% style="width:124px" %)**固定价格**|(% style="width:556px" %)服务提供者根据与客户的协商确定价格，该价格涵盖固定的时间段和预计的消费。|(% style="width:615px" %)使双方能够锁定价格，而不受成本波动的影响，例如，如果客户有固定的预算。
2300		-|(% style="width:124px" %)**差异性收费**|(% style="width:556px" %)就相同或类似服务在不同时间的不同用途设定不同收费。。|(% style="width:615px" %)使组织能够奖励某些使用模式，而不是其他使用模式，例如，在高峰时段不鼓励使用服务。
2301		-
2302		-|(((
2303		-**关键信息**
2304		-
2305		-在决定一项服务的价格时，应考虑以下几个因素：
2306		-
2307		-* 服务提供者在传递服务的价值方面有多好？
2308		-* 客户愿意支付多少？
2309		-* 市场上有类似的服务吗？
2310		-* 同类服务的定价如何？
2311		-* 扩展服务容易？
2312		-* 引入新客户容易吗？
2313		-* 这项服务是否可以用来弥补亏损？
2314		-* 服务提供者有多成熟？
2315		-* 三重底线方法会影响定价吗？
2316		-
2317		-在某些情况下，定价可以在短期内用于破坏竞争。
2318		-)))
2319		-
2320		-=== ​​​​​​​5.4.2 内部销售 ===
2321		-
2322		-对内部客户而言，提高对可用服务的认知是销售的第一步。内部销售和促销，综合激励措施和定价机制，对于管理需求非常重要。
2323		-
2324		-
2325		-向对内部客户销售的一些好处是：
2326		-
2327		-* 提高现有服务的利用率
2328		-* 更好的控制服务需求
2329		-* 改进与客户和用户的沟通
2330		-* 关于服务如何满足需求的反馈。
2331		-
2332		-内部销售有助于内部服务提供者的整体客户感知。
2333		-
2334		-
2335		-内部销售流程中最重要的工具之一是服务目录：一种促进服务的沟通工具。对于服务提供者，它有助于定义并使产品和服务可见。服务目录对于关系管理，促进现有服务以及发现新服务的需求至关重要。在定义服务级别时，它也是服务级别管理的关键工具。
2336		-
2337		-
2338		-对于服务消费者，最重要的是正在使用的服务。服务台在这方面发挥着关键作用，通常会为用户提供订购表和自助服务系统，并提供有关如何使用产品和服务的必要指导和帮助。因此，服务台将始终是内部销售流程和用户体验的关键贡献者。
2339		-
2340		-
2341		-有关更多信息，请参考以下ITIL实践：
2342		-
2343		-* 关系管理
2344		-* 服务目录管理
2345		-* 服务台
2346		-* 服务级别管理
2347		-* 服务请求管理。
2348		-
2349		-此外，服务提供者也可以应用大多数用于外部销售的传统技术。
2350		-
2351		-
2352		-=== ​​​​​​​5.4.3 对外销售 ===
2353		-
2354		-外部客户的销售更像是传统的销售技巧，例如广告和销售活动。销售流程取决于服务关系的类型、各方的性质和背景因素。其中包括：
2355		-
2356		-* 在高度监管的环境和公共部门，获取货品和服务可能会受到监管；某些服务提供者可能已被预授权销售其产品和服务。
2357		-* 一些服务消费者要求由采购团队完成采购。
2358		-* 其他人可能已经定义了正式的采购流程，其中包括正式的请求方法，例如信息请求、报价请求、提议请求、概念验证、演示等。
2359		-
2360		-表5.13显示了请求产品和服务的不同方法
2361		-
2362		-
2363		-表5.13 请求产品和服务的不同方法
2364		-
2365		-|**信息请求**|**报价邀请函**|**需求建议书**
2366		-|(((
2367		-收集信息以识别潜在供应商
2368		-
2369		-当你在寻找信息的时候
2370		-
2371		-提出一般性问题
2372		-
2373		-随意的
2374		-
2375		-快速
2376		-)))|(((
2377		-针对特定产品或服务的定价请求
2378		-
2379		-当你知道你需要什么的时候
2380		-
2381		-询问有关需求的问题
2382		-
2383		-结构化的
2384		-
2385		-关注价格
2386		-)))|(((
2387		-战略性密集建议流程
2388		-
2389		-当您要比较建议时
2390		-
2391		-提出特定问题
2392		-
2393		-正式的
2394		-
2395		-供应商比较
2396		-)))
2397		-
2398		-成功的销售流程取决于良好的沟通、信任和公平。服务提供者应避免为服务创造高于客户价值的价格。服务消费者应避免压低价格，以免服务提供者难以交付。
2399		-
2400		-
2401		-一个典型的错误是通过促销多种产品和服务来开始销售。相反，服务提供者应该提出问题并倾听。这样，服务提供者在尝试实现客户的需求之前就会了解客户的需求。
2402		-
2403		-
2404		-重要的是，服务消费者在与潜在的服务提供者进行交谈之前，不要根据过时产品的经验来准备需求清单。相反，他们应该根据实际的需要描述需求，然后听取服务提供者的意见。服务提供者可以根据他们的产品和服务组合以及与其他客户的以往经验，提供新的更好的方式来满足特定的需求。
2405		-
2406		-
2407		-|(((
2408		-**ITIL的故事：销售并获得服务产品**
2409		-
2410		-[[image:1639042297905-281.png||height="46" width="43"]]**M**//ariana：我们需要引入新的拖车租赁服务，这意味着将其添加到我们的服务目录中，向我们的支持人员介绍拖车的可用性，并管理拖车的需求。当学生最有可能搬家时，拖车租赁在每个学期的开始和结束时达到顶峰，但中期租赁确实会发生。//
2411		-)))
2412		-
2413		-== 5.5 总结 ==
2414		-
2415		-为了确定利益相关者是否可以从相互的服务关系中受益，服务消费者和服务提供者需要构建商业案例，确定并匹配其需求和供应，并以需求和服务供应的形式阐明其需求和机会。只有真正了解服务消费者的需求，才能设计出产品和服务。
2416		-
2417		-
2418		-
2419		-----
2420		-
2421		-= 6. 步骤4：协议 =
2422		-
2423		-[[image:1639042354726-214.png]]
2424		-
2425		- 约定和规划价值共创
2426		-
2427		- 谈判和约定服务
2428		-
2429		-
2430		-协议步骤的目的是在服务提供者和服务消费者之间统一期望，并建立对目标服务范围和质量的共享视图。
2431		-
2432		-
2433		-在某些情况下，协议可以包括签定合同，这可能需要法律顾问或合同经理等专家的参与。
2434		-
2435		-
2436		-表6.1总结了服务提供者、服务消费者和其他利益相关者为何应在统一期望和约定服务方面进行投资。
2437		-
2438		-
2439		-表6.1 统一期望和约定服务的目的
2440		-
2441		-(% style="width:1157px" %)
2442		-|**协议**|**对于服务消费者**|(% style="width:493px" %)**对于服务提供者**
2443		-|促进成果和经验|(((
2444		-确保提供的服务满足客户和用户的要求和期望
2445		-
2446		-通过服务和服务关系增加潜在价值
2447		-
2448		-确保所有利益相关者对服务质量达成共识
2449		-
2450		-确保对利益相关者的责任有共同的理解
2451		-)))|(% style="width:493px" %)(((
2452		-确保所有相关利益相关者对服务质量达成共识
2453		-
2454		-确保对利益相关者的责任有共同的了解
2455		-
2456		-确保对服务和服务关系的现实期望
2457		-
2458		-通过服务交付和服务关系增加潜在价值
2459		-)))
2460		-|优化风险和合规性|(((
2461		-确保对服务质量的充分控制和服务状态的透明度
2462		-
2463		-消除有关当事方之间的误解和错位
2464		-
2465		-降低违规风险
2466		-
2467		-确保对服务相关风险达成共识
2468		-
2469		-为无法通过协议共享或转移的风险安排补偿性控制
2470		-)))|(% style="width:493px" %)(((
2471		-消除有关当事方之间的误解和错位
2472		-
2473		-降低违规风险
2474		-
2475		-确保对服务相关风险达成共识
2476		-
2477		-确保对服务价格和相关付款有共同的了解，并减少付款纠纷或延误的风险
2478		-)))
2479		-|优化资源并最小化成本|(((
2480		-确保对服务消费成本和相关付款有共同的了解
2481		-
2482		-优化服务消费成本
2483		-
2484		-优化谈判和协议成本以及整体资源利用
2485		-)))|(% style="width:493px" %)(((
2486		-确保对服务提供成本有共同的了解
2487		-
2488		-优化服务提供成本
2489		-
2490		-确保对服务价格和相关付款有共同了解
2491		-
2492		-优化谈判和协议成本以及整体资源利用
2493		-)))
2494		-
2495		-服务的目标范围和质量应得到各方的同意；在服务关系的其余步骤中，它们将被称为“约定的服务范围和质量”。遗憾的是，约定的目标不可能总能实现，因此应定期将已实现的服务范围和质量与目标进行比较，以评估协议的履行情况。目标也可能随时间的推移而变化。因此，在旅程中协议步骤可能会被多次重新审视。
2496		-
2497		-
2498		-在用户旅程的背景中，其目的非常相似：与服务提供者建立目标服务范围和质量的共享视图。但是，根据用户和客户角色之间的关系，这可能会有所不同。在某些情况下，范围和质量受限于客户和服务提供者之间的协议，因此对于用户，“同意”可能仅限于未经（或非常有限）协商的接受。但是，这仍然是用户旅程中的重要一步：了解可用服务及其约定的质量对于用户有效工作非常重要。
2499		-
2500		-
2501		-|(((
2502		-**ITIL故事：步骤4 –协议**
2503		-
2504		-[[image:1639048000162-709.png||height="44" width="39"]]//Mariana：当我们的客户加入我们的汽车共享俱乐部时，他们同意我们在会员资格中规定的条款和条件。每次预订均受使用条款和条件的约束。例如，我们与艾克苏达成的有关汽车故障的协议是，当汽车发生故障或发生事故时，可以提供道路救援。 但是它不适用于常规维护（如爆胎）。//
2505		-
2506		-[[image:1639048009299-382.png||height="54" width="39"]]**S**//olmaz：客户在实际租车时也会与我们达成协议，以遵守租车的条款和条件。//
2507		-)))
2508		-
2509		-== 6.1 约定和规划价值共创 ==
2510		-
2511		-应该就如何以及何时共同创造、跟踪、评估和评价价值达成共识。 这类规划的一种方法是，首先就驱动价值的因素达成一致，并概述预期的服务成果和经验，然后计划如何以及何时衡量、评估、报告和评价价值共创。 该规划应包括风险管理、合规和成本以及资源管理。
2512		-
2513		-
2514		-=== ​​​​​​​6.1.1 服务价值驱动类型 ===
2515		-
2516		-在服务价值系统（SVS）中，通过实现服务消费者目标可以实现服务消费者目的。实现服务消费者目标的动力来自于消费者的绩效和相关体验。服务消费者的绩效取决于服务绩效，并被视为功用和功效。最终，服务绩效由组合的和单独的资源、实践和产品的绩效决定。图1.11说明了这些关系。
2517		-
2518		-服务产品通常包括三种形式的服务绩效驱动：
2519		-
2520		-* 商品从服务提供者转移到服务消费者
2521		-* 服务消费者访问服务提供者的资源
2522		-* 由服务提供者、服务消费者或二者共同实施的服务动作
2523		-
2524		-大多数服务产品都结合了几种形式。基于技术的服务通常包括对服务提供者资源的访问，有时还包括对服务动作的访问。表6.2提供了一些价值驱动的示例。
2525		-
2526		-
2527		-表6.2适用于不同类型服务产品的价值驱动示例
2528		-
2529		-|(% style="width:198px" %)**服务示例**|(% style="width:184px" %)**商品转移**|(% style="width:428px" %)**访问资源**|(% style="width:485px" %)**服务动作**
2530		-|(% style="width:198px" %)企业会计|(% style="width:184px" %)N/A|(% style="width:428px" %)财务部门的员工可以访问：具有约定功能的会计应用程序；约定质量的财务和其他数据；以及服务台和其他支持接口|(% style="width:485px" %)(((
2531		-用户动作：通过应用程序在会计系统中进行的任何交易或查询
2532		-
2533		-服务提供者的动作：
2534		-
2535		-定期更新来自不同业务部门的合并数据
2536		-
2537		-联合动作：服务台代理登记用户报告的事件
2538		-)))
2539		-|(% style="width:198px" %)面向个人消费者的宽带互联网服务|(% style="width:184px" %)将具有所有权的Wi-Fi路由器和用户手册出售给用户|(% style="width:428px" %)(((
2540		-客户授权的所有用户都可以以约定的速度访问局域网和广域网
2541		-
2542		-向客户提供用于支付、报告和服务管理的用户接口访问权限
2543		-)))|(% style="width:485px" %)(((
2544		-用户动作：查看帐户状态；变更订阅；管理用户帐户
2545		-
2546		-服务提供者的动作：向客户发送发票
2547		-
2548		-联合行动：当客户搬到新地方时，更改服务提供的地址
2549		-)))
2550		-|(% style="width:198px" %)一家小型咖啡店的刷卡支付处理|(% style="width:184px" %)读卡器设备所有权转让给客户|(% style="width:428px" %)(((
2551		-访问与客户的收银机和银行帐户集成的支付处理服务
2552		-
2553		-访问用于接收和管理支付的移动应用
2554		-
2555		-访问支持热线
2556		-)))|(% style="width:485px" %)(((
2557		-用户动作：接收卡或设备支付；取消支付；重置设备； 与智能手机配对
2558		-
2559		-服务提供者的动作：通知客户有关应用程序更新和其他重要事件
2560		-
2561		-联合动作：更换有故障的读卡器设备
2562		-)))
2563		-|(% style="width:198px" %)内部IT基础架构团队为产品开发团队提供的基础架构平台服务|(% style="width:184px" %)N/A|(% style="width:428px" %)平台即服务的访问|(% style="width:485px" %)(((
2564		-用户动作：安装和更新应用程序； 通过标准化接口配置资源并安装、调试、启动、停止和停用平台组件
2565		-
2566		-服务提供者的动作：监控和报告服务水平；组件打补丁； 开票给客户
2567		-
2568		-联合行动：对平台进行重大更新； 解决共同的问题
2569		-)))
2570		-
2571		-在表6.2中，第一个和第三个示例主要是在服务动作的上下文中被客户和用户感知。 这对于旨在使业务活动自动化的服务来说是典型的。第二个和第四个示例主要是通过服务提供者提供的资源质量来感知。不同点通常反映在服务协议的格式中，因为它们更加关注所提供的资源质量或服务动作的执行情况。
2572		-
2573		-
2574		-对于服务提供者而言，识别、约定和衡量提供给服务消费者的资源的特征非常容易。 在许多情况下，这些都是可衡量且明确的技术特征。 定义对服务消费者重要的服务动作则比较困难。
2575		-
2576		-
2577		-=== ​​​​​​​6.1.2 服务交互方法 ===
2578		-
2579		-服务交互方法有助于基于用户和服务提供者在服务消费期间执行的关键服务交互的绩效来描述和评估服务结果。 它可以帮助各方进行价值共创的规划。
2580		-
2581		-
2582		-**服务交互方法示例**
2583		-
2584		-银行有向其客户提供个人贷款的价值流。该价值流包括一系列活动，其中大多数活动由IT服务实现的。在对价值流进行映射和分析后，确定了以下服务交互，如下所示。
2585		-
2586		-(% style="width:751px" %)
2587		-|(% style="width:389px" %)**服务交互**|(% style="width:204px" %)**需求**|(% style="width:156px" %)**约束条件**
2588		-|(% style="width:389px" %)贷款申请的处理|(% style="width:204px" %) |(% style="width:156px" %)
2589		-|(% style="width:389px" %)1.当前不良信用检查|(% style="width:204px" %) |(% style="width:156px" %)
2590		-|(% style="width:389px" %)2.负担能力计算|(% style="width:204px" %) |(% style="width:156px" %)
2591		-|(% style="width:389px" %)3.信用等级评估|(% style="width:204px" %) |(% style="width:156px" %)
2592		-|(% style="width:389px" %)4. 申请评分|(% style="width:204px" %) |(% style="width:156px" %)
2593		-|(% style="width:389px" %)5.基于风险的利息计算|(% style="width:204px" %) |(% style="width:156px" %)
2594		-|(% style="width:389px" %)6.报价的确认或更新|(% style="width:204px" %) |(% style="width:156px" %)
2595		-|(% style="width:389px" %)…|(% style="width:204px" %) |(% style="width:156px" %)
2596		-|(% style="width:389px" %)贷款协议的签署与转帐|(% style="width:204px" %) |(% style="width:156px" %)
2597		-|(% style="width:389px" %)8.贷款协议和相关协议的自动登记|(% style="width:204px" %) |(% style="width:156px" %)
2598		-|(% style="width:389px" %)9.开户并创建付款时间表|(% style="width:204px" %) |(% style="width:156px" %)
2599		-|(% style="width:389px" %)10.设置直接付款指令|(% style="width:204px" %) |(% style="width:156px" %)
2600		-|(% style="width:389px" %)…|(% style="width:204px" %) |(% style="width:156px" %)
2601		-|(% style="width:389px" %)贷款协议持续管理|(% style="width:204px" %) |(% style="width:156px" %)
2602		-|(% style="width:389px" %)14.利息计算和帐户信息更新|(% style="width:204px" %) |(% style="width:156px" %)
2603		-|(% style="width:389px" %)…|(% style="width:204px" %) |(% style="width:156px" %)
2604		-|(% style="width:389px" %)付款处理|(% style="width:204px" %) |(% style="width:156px" %)
2605		-|(% style="width:389px" %)28.如果客户请求全额偿还贷款，计算应付款项|(% style="width:204px" %) |(% style="width:156px" %)
2606		-|(% style="width:389px" %)…|(% style="width:204px" %) |(% style="width:156px" %)
2607		-
2608		-根据此列表，服务提供者和客户就下表中列出的某些服务交互的服务级别要求和度量标准达成一致
2609		-
2610		-(% style="width:1004px" %)
2611		-|(% colspan="3" style="width:1001px" %)**约定的服务级别要求和指标**
2612		-|(% style="width:453px" %)服务级别特征|(% style="width:222px" %)客户需求|(% style="width:326px" %)服务级别指标
2613		-|(% style="width:453px" %)自动贷款申请处理时间|(% style="width:222px" %)少于60秒|(% style="width:326px" %)及时处理贷款申请的百分比
2614		-|(% style="width:453px" %)银行分行中使用的所有贷款相关系统的服务中断的最大持续时间|(% style="width:222px" %)少于10分钟|(% style="width:326px" %)单次中断最长持续时间
2615		-|(% style="width:453px" %)一个工作日内总不可用时间|(% style="width:222px" %)少于15分钟|(% style="width:326px" %)一段时间内未满足需求的天数和百分比
2616		-
2617		-此方法包括以下阶段：
2618		-
2619		-* 识别服务交互，包括服务提供者动作、服务消费者动作和联合动作
2620		-* 将已识别的服务交互与服务提供者的服务目录进行匹配
2621		-* 协定服务交互目标绩效
2622		-* 与客户和服务提供者团队就服务的度量和测量标准达成一致。
2623		-
2624		-识别服务交互的最佳方法是映射服务提供者和服务消费者价值流。对于组织而言，拥有价值流和流程的最新地图非常有帮助。根据这些信息，服务提供者和服务消费者可以得出服务、相关的服务交互以及绩效需求所支持的动作列表。
2625		-
2626		-
2627		-但是，在组织中通常找不到价值流和流程的正确且最新的地图。在没有这些图的情况下，可以利用组织的文档和标准来识别服务交互。由此产生的列表将更加通用，但对于规划价值共创而言可能就足够了。客户和服务提供者对服务交互绩效的要求，可以从组织的相关内部程序和标准中得出。
2628		-
2629		-
2630		-这项工作应该由一个团队来完成，其中可能包括：
2631		-
2632		-* 服务和/或产品所有者
2633		-* 客户
2634		-* 服务/系统架构师
2635		-* 服务设计师
2636		-* 业务分析师
2637		-* 服务目录管理员
2638		-
2639		-
2640		-=== ​​​​​​​6.1.3 服务的固有和指定特征 ===
2641		-
2642		-
2643		-|(((
2644		-**定义**
2645		-
2646		-* **服**务质量，与服务满足既定和隐含需求的能力相关的服务特征的整体。
2647		-* **服**务级别，一个或多个用于定义预期或已实现的服务质量的度量标准。
2648		-)))
2649		-
2650		-组织通常会同意一种定义服务质量的方法。这些协议包括基于资源或服务运营的服务规范和度量的首选方法。
2651		-
2652		-
2653		-服务的固有特征可能包括：
2654		-
2655		-* 功能和性能
2656		-* 架构
2657		-* 接口和兼容性
2658		-* 费用
2659		-
2660		-服务的指定特征可能包括：
2661		-
2662		-* 价格
2663		-* 风险与合规
2664		-* 服务交付的透明度
2665		-* 监控
2666		-* 报告
2667		-* 灵活性
2668		-* 社会责任
2669		-
2670		-固有特征基于相应产品的资源。指定特征大多定义为服务和服务提供设计的一部分。它们描述了服务的交付、支持和改进方式，并且可以在不对相关产品进行重大变更的情况下进行修改。
2671		-
2672		-这种区别虽然对服务管理有所帮助，但并不是确定的。某些特征，例如兼容性或安全性，可以是固有的（集成接口是产品设计的一部分），也可以是指定的（集成是引入和持续支持的一部分）。服务提供者决定哪些特征应包括在服务质量规范中，哪些应留给服务交付情况、条款和条件的讨论。
2673		-
2674		-(% style="text-align:center" %)
2675		-[[image:1639048305942-643.png]]
2676		-
2677		-
2678		-(% style="text-align:center" %)
2679		-[[image:1639048338706-431.png]]
2680		-
2681		-
2682		-== 6.2 协商并同意服务 ==
2683		-
2684		-根据服务关系模型，协商和同意服务的方法可能会有很大不同。但大多数情况下，范围包括：
2685		-
2686		-* 提供和使用的服务
2687		-* 服务的固有质量特性，例如功用、功效和体验
2688		-* 服务的指定特征，例如价格、地区和提供期限
2689		-* 服务范围和质量的共同控制和改进的方法
2690		-
2691		-=== ​​​​​​​6.2.1 协议表格 ===
2692		-
2693		-有几种方法可以确定服务关系中的服务范围和质量。 这些关系可以是：
2694		-
2695		-* 基于义务
2696		-* 基于协议
2697		-* 基于承诺
2698		-* 根据社会规则和期望
2699		-
2700		-这些方式具有不同级别的形式、协商流程以及控制和改进的方法。
2701		-
2702		-
2703		-==== 6.2.1.1 基于义务的服务关系 ====
2704		-
2705		-基于义务的服务关系是通过对组织的强制性要求定义的，通常是法律或其他法规规定的。法律可能要求提供最低级别的服务；有时它也要求服务消费。示例包括：
2706		-
2707		-* 社会服务，例如医疗服务和教育
2708		-* 基础设施服务，例如运输或设施安全
2709		-* 社会责任服务，例如司机或旅行者的强制性保险。
2710		-
2711		-尽管这些服务大多数可以由商业服务提供商提供，但服务消费者的最低服务级别和价格通常由国家规定。这意味着，无论服务协议的形式如何，它都必须包括某些服务质量特性，并保证最低服务级别。如果仅提供了最低的强制性服务级别，则没有协商和协议的空间。
2712		-
2713		-
2714		-在某些情况下，各方从强制性服务级别开始，但同意对其进行扩展，并相应地设置服务级别的目标。在这种情况下，他们根据自己的义务建立自己的协议，并扩展为基于协议的关系。
2715		-
2716		-
2717		-|(((
2718		-**ITIL故事：基于义务的服务协议**
2719		-
2720		-[[image:1639048447665-961.png||height="58" width="43"]]**S**//olmaz：为了开展国际业务，艾克苏租车必须尊重国家之间存在的双边和区域贸易协定。这些是基于义务的协议，这些协议支配着我们如何开展业务，如何在当地雇用员工以及如何投资以获得回报。//
2721		-)))
2722		-
2723		-==== 6.2.1.2 基于协议的服务关系 ====
2724		-
2725		-基于协议的服务关系，意味着服务关系所涉及的各方就服务的范围和质量进行协商并达成一致。他们可能会以电子或书面方式记录该协议，并利用它来监视和管理服务的实际质量。在大多数情况下，该协议称为服务级别协议（SLA）。根据关系不同，它可以采用谅解备忘录的形式，或更常见的是法律合同的形式。
2726		-
2727		-
2728		-|(((
2729		-**定义：服务级别协议（SLA）**
2730		-
2731		-服务提供者和客户之间的书面协议，标识了所需的服务和服务的预期级别。
2732		-)))
2733		-
2734		-SLA是双方之间正确讨论的结果，这一点很重要。即使服务提供者不灵活，也没有提供太多的谈判空间，也应在知情同意的情况下向客户提供SLA中定义的服务。认知和同意是基于协议的关系的最低要求。
2735		-
2736		-
2737		-SLA可能具有不同的形式级别。形式化的水平可能反映了服务提供者和服务消费者之间的信任程度。如果信任度较低，则组织将试图在协议中包含尽可能多的细节。如果信任度很高，并且是通过关系的正面体验获得的，则各方倾向于将重点放在最重要和特定的服务特性上，这意味着协议中未提及的内容将根据既定的惯例和期望进行交付和消费，这些含义可以描述为承诺。
2738		-
2739		-在高度信任的服务关系中，或者如果服务特性较简单，则可以口头或通过简短的电子邮件或文本消息来达成协议。
2740		-
2741		-
2742		-==== 6.2.1.3 基于承诺的服务关系 ====
2743		-
2744		-基于承诺的服务关系最初由Mark Burgess（Burgess，2004）在2004年提出的承诺理论描述。它适用于以下情况：服务提供者和服务消费者的意图没有被记录，而是由以前的经验、社会规范或共同认可的迹象所暗示。
2745		-
2746		-(% style="text-align:center" %)
2747		-[[image:1639048543615-528.png]]
2748		-
2749		-
2750		-
2751		-==== 6.2.1.4 基于社会规则和期望的关系 ====
2752		-
2753		-在已建立的长期服务关系中，非正式的承诺和强加很常见。根据以前的经验，服务的隐含特性在初始阶段就向服务消费者公开。此外，服务提供者期望参与方（例如客户、用户、赞助者和服务消费者资源）将按照既定的标准和约定的规则行事。
2754		-
2755		-
2756		-有许多描述社会契约的哲学和社会学理论。本质上，社会契约是对社会及其政府施加的规则的接受。特别是，在具有合法影响力的地区生活、工作和互动的个人和组织都接受它。接受可以是显式或隐式的。
2757		-
2758		-
2759		-这个概念可能会影响服务关系，因为政府的标准和要求经常会影响组织的期望，并且对服务的范围和质量特性施加了约束。在某些情况下，正式服务协议会包含有关合规性的声明。
2760		-
2761		-
2762		-法律、当地传统、社区规则和其他要求，通常是由社会契约施加。这是明确接受合同的一个示例，当其中一个组织不熟悉这些要求时可能会有用；例如，建立国际服务关系时。
2763		-
2764		-
2765		-|(((
2766		-示例
2767		-
2768		-当组织决定将内部服务职能转变为单独的公司时，他们通常希望根据多年的以往经验，来获得他们习惯了的服务范围和质量。但是，这几乎是不可能的，尤其是在新服务公司有望在商业上取得成功的情况下。
2769		-
2770		-
2771		-不管新的正式签署的服务级别协议如何，都期望可能继续基于先前建立的规范。有效地管理此类组织变更很重要，这样才能保持所需的服务质量、成本和用户满意度。
2772		-)))
2773		-
2774		-在实践层面上，服务关系始终由服务提供者和服务消费者之间的显式或隐式协议来支持。重要的是要平衡正式记录的服务隐含特性和协议本身。还应记住，隐含协议基于共同的假设和共同的价值。在应用非明示协议时，尤其是在与新的消费者或提供者建立服务关系时，组织应考虑文化、背景、以前的经验和法规。对默示协议的误解和曲解可能会导致紧张和冲突。
2775		-
2776		-
2777		-=== ​​​​​​​6.2.2 基于成果的协议 ===
2778		-
2779		-在合作关系和伙伴关系中，组织倾向于从价值和结果角度讨论服务质量。指定功用和功效级别很有用，因为它使服务的监控和管理保持一致。当讨论服务消费者的价值时，讨论可能集中在预期的结果上，或涵盖服务减少或引入的风险和成本。
2780		-
2781		-
2782		-价值的书面定义成为规划价值共创和价值实现的联合跟踪、评估和评价的基础，这将在第9章中进一步讨论。价值的定义对于组织而言通常比遵守服务级别要求更为重要，尽管期望两者都应满足。如果信任级别足够高，则即使已经达到约定的服务级别，也可以允许服务提供者调整服务级别并启动服务改进。组织可以在同意步骤中就服务改进和价值实现的方法达成协议，并在其合作关系协议中记录此方法。
2783		-
2784		-
2785		-基于价值和基于成果的服务级别管理方法同样适用于内部和外部关系。需求包括共同的目标、相互信任和组织敏捷性。
2786		-
2787		-
2788		-|(((
2789		-**ITIL的故事：基于成果的协议**
2790		-
2791		-[[image:1639048688182-294.png||height="53" width="41"]]//Solmaz：我们与汽车清洁公司的协议基于成果。对于此协议，我们不按资源或清洁时间付费；取而代之的是，我们根据干净状态下退还给我们的车辆数量付款，那些影响客户的体验。//
2792		-)))
2793		-
2794		-=== ​​​​​​​6.2.3 从服务消费者需求到协议 ===
2795		-
2796		-根据服务关系和模型，服务提供者和服务消费者组织之间对服务质量的协商存在很大差异。影响谈判的一些因素是：
2797		-
2798		-* 内部或外部关系
2799		-* 个人（一个人组织）或公司服务消费者
2800		-* 基本服务或战略合作关系
2801		-* 量身定制的或开箱即用服务
2802		-
2803		-所有这些因素都会影响旅程的所有步骤。表6.3列出了这种影响的一些示例。
2804		-
2805		-
2806		-表6.3  不同情况下服务关系旅程差异的示例。
2807		-
2808		-(% style="width:802px" %)
2809		-|**影响因素**|(% style="width:569px" %)**因素影响的例子**
2810		-|内部服务关系|(% style="width:569px" %)(((
2811		-服务提供和服务消费可能具有相同的发起人
2812		-
2813		-服务提供者和服务消费者可能具有相同的战略目标
2814		-
2815		-可能没有合法的服务合同
2816		-
2817		-关系可能基于命令和控制，而不是合作关系
2818		-)))
2819		-|个人服务消费者|(% style="width:569px" %)(((
2820		-发起人或赞助人（隶属于服务消费）、客户和用户可能是同一个人，并且有利益冲突
2821		-
2822		-客户数量可能非常大；个人谈判方法不可行
2823		-
2824		-关系可能是规范且正式的，而不是基于个人需求和类似合作关系的关系
2825		-
2826		-简单且通常为自动化的协议规程
2827		-)))
2828		-|基本服务|(% style="width:569px" %)(((
2829		-高度标准化的服务产品和服务要求
2830		-
2831		-简单且通常为自动化的协议规程
2832		-
2833		-协议不太可能专注于结果或价值
2834		-)))
2835		-|量身定制的服务|(% style="width:569px" %)(((
2836		-协商、交付和评估服务的个性化方法
2837		-
2838		-量身定制的协议（格式、服务级别目标、评估和报告）
2839		-)))
2840		-
2841		-服务消费者和服务提供者应意识到的一个重要共性是，协商旨在缩小服务质量特性的范围。图6.1中对此进行了说明。
2842		-
2843		-
2844		-参与谈判的所有各方均应了解，约定的服务级别（尤其是以合法的合同的形式）仅包含可以高度保证且明确衡量的特性和目标。包含此内容的另一个原因是，在流程期间可能会丢失信息，包括从建立需求和期望到明确陈述的需求，再到协议。
2845		-
2846		-此外，对于开箱即用服务，客户需求不会直接转换为服务特性；它们必须与预定义和已发布的服务描述进行比较和匹配，而这些描述可能是在没有客户参与的情况下设计的。这意味着仅关注履行正式协议不足以管理服务的质量。监视和讨论用户和客户的满意度，以及服务消费的结果和价值非常重要。
2847		-
2848		-尽管SLA不足以用于服务度量、评估、评价和改进，但它们仍然有用。协议有多种形式。
2849		-
2850		-(% style="text-align:center" %)
2851		-[[image:1639048741852-426.png]]
2852		-
2853		-图片6.1协议限制：从服务消费者需求到协议
2854		-
2855		-
2856		-|(((
2857		-**SLA的内容和结构**
2858		-
2859		-SLA的基本结构由名称表示：
2860		-
2861		-* **Service 服**务定义协议的范围
2862		-* **Level 级**别定义服务的特性以及每个特性的商定指标和目标
2863		-* **Agreement 协**议涵盖了服务提供和使用的条款和条件。
2864		-
2865		-如果协议涵盖多种服务或反映了消费者组织的复杂结构，则该结构可能会变得更加复杂。例如，“级别”和“协议”部分可能包含适用于每种服务或客户的段落，以及特定于服务或客户的段落。
2866		-
2867		-与外部组织的协议（SLA是法律合同的一种或一部分）中，协议部分通常会变得更加复杂。在订购协议中，它可能包含特定条款，例如订购期限、取消的规则和费用以及收取定期付款的方法。无论哪种结构对组织更有效，遵循此指导原则都是很重要的：使其简单实用。在不可避免的复杂情况下，建议（或法规要求）以简洁明了的语言提供简短的解释。这对于敏感服务（例如贷款）尤其重要。
2868		-)))
2869		-
2870		-|(((
2871		-**ITIL的故事：从服务消费者需求到协议**
2872		-
2873		-[[image:1639048791347-982.png||height="51" width="36"]]//Solmaz：根据我们向汽车清洁公司提出的初始价格，该公司回应说不再使用环保产品。环保可持续性在艾克苏汽车租赁公司中，对我们的愿景至关重要，因此我们不得不重新协商互利的成果。//
2874		-)))
2875		-
2876		-
2877		-=== ​​​​​​​6.2.4 协商并协定服务功用、功效和体验 ===
2878		-
2879		-SLA的“级别”部分通常包括针对服务功用和功效的议定服务级别目标。
2880		-
2881		-
2882		-|(((
2883		-**定义**
2884		-
2885		-* **功用，**产品或服务提供的可满足特定需求的功能。功用可以概括为“ 服务的用途”，并且可以用来确定服务是否“ 符合目的”。要具有功用，服务必须支持消费者的性能或绩效，或消除消费者的约束。许多服务都可以做到。
2886		-* **功**效，确保产品或服务将满足约定的要求。功效可以概括为“ 服务的执行方式”，并且可以用来确定服务是否“适合使用”。功效通常涉及与服务消费者的需求相符的服务水平。这可以基于正式的协议，也可能是市场营销信息或品牌图像。功效通常涉及诸如服务的可用性、其容量、安全级别和连续性等领域。如果满足所有定义和约定的条件，则可以说服务提供了可接受的保证或“功效”。
2887		-)))
2888		-
2889		-
2890		-服务质量和服务级别的管理应该着重于价值，并且应该管理服务的所有相关特性。这包括相关的指标、体验领域和反馈。从需求的规范到已实现的质量的评价，分离服务的功能和非功能特性的方法来自于开发和运营团队的分离。这些特性和团队的分离通常导致对服务质量的零碎理解。
2891		-
2892		-
2893		-==== 6.2.4.1 功用 ====
2894		-
2895		-服务的功用特性通常被描述为由服务提供者的人员和其他资源执行的功能，或服务动作（由服务提供者执行，可供用户使用或共同执行）。表6.4提供了服务功用描述和指标的一些示例。
2896		-
2897		-
2898		-表6.4显示功用特性通常是二进制的（它起作用或不起作用）。关联的指标通常基于重要功能或性能不可用或性能太低而无法接受的事件。但是，服务功用的整体评估可以基于多个特性和相关指标的集成。例如，如果系统的某些功能不可用或执行时出错很多，则可以将它们评估为约定的功用的百分比，而不是二进制指标。有关服务指标和度量的更多信息，请参见第9章和服务级别管理实践指南。
2899		-
2900		-
2901		-表6.4 服务功用说明和指标的示例
2902		-
2903		-|**服务**|**功能示例**|**指标和目标示例**
2904		-|移动网络|(((
2905		-连接到全球互联网
2906		-
2907		-用于语音和视频通话的IP电话、SMS
2908		-)))|(((
2909		-无法访问互联网资源发生的事件数（每月<2）
2910		-
2911		-平均连接速度（> 10 Mbps）
2912		-
2913		-连接中断的呼叫百分比（<5％）
2914		-
2915		-音频或视频质量被用户评估为5星中的3星，或更少（<10％）
2916		-
2917		-无法建立呼叫或应用程序连接（<5％）
2918		-
2919		-交付时间超过一分钟的SMS的百分比（<5％）
2920		-)))
2921		-|商务旅行机票搜索与预订|(((
2922		-按日期、航空公司和票价搜索航班
2923		-
2924		-选择和预订航班
2925		-
2926		-飞行常客卡的识别和申请
2927		-
2928		-政策符合性检查
2929		-
2930		-将差旅费用分配给正在进行的代码和项目预算代码
2931		-)))|(((
2932		-无法完成搜索的事件数（<1％）
2933		-
2934		-服务未提供通过其他搜索引擎提供更好票价或航班的已报告事件的数量（每月少于5个）
2935		-
2936		-未正确分配给预算代码的预订数量和百分比（每月<5或<2％）
2937		-
2938		-由于技术问题而无法完成航班搜索，预订或付款的事件的数量和百分比（每月<2或<1％）
2939		-
2940		-搜索、预订或付款交易超时（每月<5或<2％）的事件数量和百分比
2941		-)))
2942		-
2943		-==== 6.2.4.2 功效 ====
2944		-
2945		-服务功效描述了在约定的条件下提供约定的功用的保证级别。条件可能包括：
2946		-
2947		-* 服务提供的地区和期限
2948		-* 需求/工作量
2949		-* 威胁和相关风险
2950		-* 用户的准备情况
2951		-* 适用法律
2952		-
2953		-“保证级别”是指在约定的条件下，提供了某些级别的可用性、性能、容量、连续性、安全、可用性、合规性和其他服务质量特性。表6.5给出了移动互联网服务的一些示例。
2954		-
2955		-
2956		-表6.5 功效需求和相关指标的示例
2957		-
2958		-(% style="width:1097px" %)
2959		-|**功效需求**|(% style="width:469px" %)**指标和目标**|(% style="width:529px" %)**条件**
2960		-|可用性|(% style="width:469px" %)(((
2961		-可用性超过一个月的百分比（> 99％）
2962		-
2963		-中断次数（每月<3）
2964		-
2965		-最长中断时间（<15分钟）
2966		-
2967		-中断之间的最小正常运行时间（> 3小时）
2968		-)))|(% style="width:529px" %)(((
2969		-在约定的服务提供时间和范围内，
2970		-
2971		-包括本地区和漫游目的地
2972		-)))
2973		-|性能|(% style="width:469px" %)(((
2974		-最低下载速度（> 5 Mbps）
2975		-
2976		-一段时间内的平均下载速度（> 10 Mbps）
2977		-
2978		-最低上传速度（> 3 Mbps）
2979		-
2980		-下载一小时视频的平均时间（少于5分钟）
2981		-
2982		-视讯通话或视频流中断或延迟的事件数（每月<3）
2983		-)))|(% style="width:529px" %)(((
2984		-同时下载进程的最大数量为3
2985		-
2986		-有关官方视频托管和通信服务的商定列表
2987		-
2988		-在商定的服务提供区域内，仅家庭网络
2989		-)))
2990		-|容量|(% style="width:469px" %)(((
2991		-最大并发流量的应用程序数量，例如视频流/下载和视频通话（5）
2992		-
2993		-覆盖范围（建筑物的所有房间）
2994		-
2995		-每月流量（无限制）
2996		-)))|(% style="width:529px" %)(((
2997		-官方认可的应用
2998		-
2999		-在家庭网络和选定的漫游目的地内
3000		-)))
3001		-|信息安全|(% style="width:469px" %)每月来自互联网的恶意软件引起的安全事件数（0）|(% style="width:529px" %)只要用户不更改安全设置和防病毒软件设置，并且所有用户都遵循信息安全准则
3002		-|合规性|(% style="width:469px" %)服务提供和服务符合有关个人数据保护、版权保护和内容控制的国家法规|(% style="width:529px" %)只要用户不更改内容控制设置，并且用户遵循信息处理准则
3003		-|连续性|(% style="width:469px" %)(((
3004		-发生重大网络中断时的最长服务恢复时间（<12小时）
3005		-
3006		-发生重大网络事件时切换到备份解决方案的最长时间（<3小时）
3007		-)))|(% style="width:529px" %)(((
3008		-如果国家电网可用
3009		-
3010		-如果至少有一个移动运营商合作伙伴的网络可用
3011		-)))
3012		-|辅助功能|(% style="width:469px" %)所有界面清晰可见，易于使用|(% style="width:529px" %)只要用户没有视力障碍，并且可以阅读和说英语、德语、法语或西班牙语
3013		-
3014		-==== 6.2.4.3 体验 ====
3015		-
3016		-如前所述，组织越来越多地在协议中包含用户体验目标。许多体验指标与服务接口性能相关；其他的可能表示用户对界面或服务的总体满意度。其中的度量可以集成到数字化服务中。体验指标的示例包括：
3017		-
3018		-* 用户错误
3019		-* 返回上一级（后退按钮用法）
3020		-* 帮助（F1）呼叫
3021		-* 丢弃（未完成）服务操作
3022		-* 在广告休息期间切换到其他频道的用户
3023		-* 试用期过后取消订阅的用户
3024		-* 确认用户同意条款但不阅读条款和条件的用户。
3025		-
3026		-表6.6 提供了一些商务旅行机票搜索和预订服务的体验特性和指标的示例。
3027		-
3028		-
3029		-表6.6 体验特性和指标示例
3030		-
3031		-(% style="width:875px" %)
3032		-|**体检特性**|(% style="width:553px" %)**指标和目标**
3033		-|不间断地完成用户操作|(% style="width:553px" %)每月未完成的预订数量和百分比（<50或<5％）
3034		-|用户对服务的满意度|(% style="width:553px" %)用户在一段时间内对服务给予的平均和最低评分（> 4分，共5分；> 2.9分）
3035		-|界面清晰便捷|(% style="width:553px" %)(((
3036		-每月用户使用界面帮助的交易数量和百分比（<10或<5％）
3037		-
3038		-用户在一段时间内对服务界面给予的平均和最低评分（> 4，共5；> 3.5）
3039		-)))
3040		-
3041		-其背后的想法是直接测量用户体验，而不仅仅是询问用户。术语体验级别协议或XLA™由Marco Gianotten（Gianotten，2017年）提出。基于体验的服务定义和度量方法适用于服务动作是服务的重要组成部分的服务。有很多服务没有用户交互，也很少交互。例如基础设施即服务（IaaS）或平台作为服务（PaaS）。
3042		-
3043		-
3044		-(% style="text-align:center" %)
3045		-[[image:1639049066141-786.png]]
3046		-
3047		-
3048		-
3049		-=== ​​​​​​​6.2.5 协商并同意其他条款和条件 ===
3050		-
3051		-服务提供者与客户之间的协议通常包括功用、功效或体验所未涵盖的条款和条件。这些条款和条件可能包括：
3052		-
3053		-* 服务提供的地区和期限/时间表
3054		-* 服务提供的前提条件（用户培训、保险、基础设施和软件兼容性）
3055		-* 引入和撤销的规则和条件
3056		-* 更改协议的规则和条件
3057		-* 更改涵盖产品和服务、执行测试等的规则和条件。
3058		-* 服务协议终止和延期的规则和条件
3059		-* 角色和责任
3060		-* 协议中利益相关者的组织
3061		-* 沟通与沟通渠道
3062		-* 协议的治理
3063		-* 服务提供的资金来源
3064		-* 价格、价格计算规则以及付款方式和付款期限
3065		-* 执法方法（例如，奖励措施、处罚措施、积分的赚取/扣除、信任分数、反馈会议、合同合规性的发布、法律步骤和媒体使用）
3066		-* 纠纷
3067		-* 服务提供者和服务消费者保证并遵守相关标准和其他要求
3068		-* 权利以及进行第三方审核和审查、请求独立的审计报告等的访问权限
3069		-
3070		-其中大多数都属于SLA结构的协议部分。它们描述了为满足条件的功用提供同意的保证级别或功效的条件。
3071		-
3072		-
3073		-此服务协议的详细程度和形式取决于服务关系类型和SLA结构。与企业内部的非商业服务提供相比，向外部服务消费者提供商业服务需要记录更多的手续。
3074		-
3075		-
3076		-|(((
3077		-**关键信息**
3078		-
3079		-即使非正式协议也应包括服务评估和改进的规则和程序。重要的是要确保所有相关的利益相关者都意识到这一点，并愿意参加相关的活动，例如反馈调查、服务评审会议和改进计划。
3080		-)))
3081		-
3082		-=== ​​​​​​​6.2.6 标准化和自动化协议 ===
3083		-
3084		-如同客户旅程的所有其他步骤一样，此步骤在很大程度上可以标准化和自动化，尤其是在与各个消费者建立服务关系时。表6.7说明了它可能有多简单和快速。
3085		-
3086		-
3087		-这些步骤之后，会自动形成正式的协议，并应由各方（通常以电子方式）签署。之后，服务消费者和服务提供者进入引入，将在第7章中进行讨论。
3088		-
3089		-
3090		-为了实现这一点，服务提供者需要仔细地设计和测试其服务、服务目录和支持工具。重要的是要确保其服务符合所选关系模型的目的。预定义的自动协商方法和协议不能解决所有服务关系。许多服务关系是基于自定义的单独方法构建的，无法自动执行。
3091		-
3092		-
3093		-表6.7 针对向许多个人消费者提供服务的典型协议操作示例
3094		-
3095		-(% style="width:1146px" %)
3096		-|**同意的要素**|(% style="width:1008px" %)**谈判和协议动作**
3097		-|范围|(% style="width:1008px" %)(((
3098		-可用的服务由服务提供者预先定义。客户从可用目录中进行选择，无论是否咨询服务提供者。
3099		-
3100		-通过自动界面进行选择。
3101		-)))
3102		-|固有的质量特性|(% style="width:1008px" %)对于选定的服务，可以使用一些预定义的选项。 这些选项可以自定义或预先包装在服务级别软件包中。 客户选择最能满足他们需求和要求的选项。
3103		-|指定的质量特性|(% style="width:1008px" %)对于选定的服务和质量，可以使用一些预定义的交付选项，例如付款方式和时间表、服务提供期限，服务提供范围等。客户选择最能满足其需求和要求的选项。
3104		-|控制和改进方法|(% style="width:1008px" %)服务提供者预先定义了控制的方法、报告和反馈。客户被告知并被迫接受这些条件以继续执行协议。
3105		-
3106		-=== ​​​​​​​6.2.7应用实践 ===
3107		-
3108		-为了成功达到有关服务关系和服务质量的协议，组织应采用以下ITIL 管理实践：
3109		-
3110		-* 业务分析
3111		-* 关系管理
3112		-* 服务目录管理
3113		-* 服务财务管理
3114		-* 服务级别管理
3115		-* 供应商管理。
3116		-
3117		-读者应参阅相应的ITIL 实践指南以了解详细信息。
3118		-
3119		-
3120		-|(((
3121		-**ITIL的故事：标准化和自动化协议**
3122		-
3123		-[[image:1639049191757-274.png||height="43" width="42"]]//Mariana：我们用于预订汽车的服务可通过艾克苏预订应用程序在线自动进行。eCampus Car Share与客户之间不会进行协商。但是，在接受预订后，我们要求客户明确同意您租车的条款和条件。他们同意后，便与我们签订了协议。他们无需在每次预订汽车时签署冗长的法律文件。//
3124		-)))
3125		-
3126		-== 6.3 总结 ==
3127		-
3128		-要驱动和跟踪利益干系人的价值，必须调整期望，映射和计划价值共创，并且就服务范围和质量达成共识。
3129		-
3130		-
3131		-该方法取决于关系的类型以及产品和服务的性质，但是服务关系始终由服务提供者和服务消费者之间的显式或隐式协议来支持。
3132		-
3133		-
3134		-
3135		-----
3136		-
3137		-= 7. 步骤5：引入 =
3138		-
3139		-[[image:1639049245149-501.png]]
3140		-
3141		-
3142		- 计划引入
3143		-
3144		- 与用户相关并建立关系
3145		-
3146		- 提供用户参与和交付渠道
3147		-
3148		- 使用户能够使用服务
3149		-
3150		- 提升彼此的能力和撤销客户与用户
3151		-
3152		-
3153		-引入包括服务消费者开始使用服务和服务提供者准备交付服务所需的所有活动。这些范围包括从打开并可供使用的服务（例如，连接到网络的移动电话）到合同协议、用户感知、培训和资源共享（例如，外包桌面设备）。
3154		-
3155		-
3156		-有效的引入支持服务的提供和使用，提高服务的使用效率，改善用户体验，确保满意度，并增进服务提供者和服务消费者之间的关系。
3157		-
3158		-
3159		-表7.1总结了服务提供者、服务消费者和其他利益相关方为何应投资有效的引入和撤销。
3160		-
3161		-
3162		-引入在协议达成或更改之后，但在服务消费启动之前发生。引入为用户创造了第一个服务印象，这可能会严重影响发起人和客户就服务关系做出的任何进一步决定。 因此，应根据商定的计划仔细计划和管理每个引入计划。
3163		-
3164		-
3165		-表7.1 引入和撤销的目的
3166		-
3167		-(% style="width:1025px" %)
3168		-|**引入和撤销**|(% style="width:389px" %)**对于服务消费者**|(% style="width:391px" %)**对于服务提供者**
3169		-|促进成果和体验|(% style="width:389px" %)(((
3170		-通过有效使用服务来确保更好的投资回报
3171		-
3172		-改善用户体验
3173		-
3174		-通过有效使用服务来提高业务运营的效果和效率
3175		-
3176		-通过与新的服务提供者合作来最大化价值
3177		-)))|(% style="width:391px" %)(((
3178		-通过与新的服务消费者/客户/用户的合作来最大化价值
3179		-
3180		-提高对新的服务和服务提供者的总体了解
3181		-
3182		-提高客户和用户的忠诚度和参与度
3183		-)))
3184		-|优化风险和合规性|(% style="width:389px" %)(((
3185		-降低与新服务和用户有关的用户事件及问题的可能性
3186		-
3187		-缩短过渡到新服务/提供者的时间
3188		-)))|(% style="width:391px" %)(((
3189		-降低服务质量中事件和相关违规的可能性
3190		-
3191		-防止/减少用户对新服务和/或服务提供者的抵制
3192		-)))
3193		-|优化资源并最小化成本|(% style="width:389px" %)(((
3194		-减少过渡到新服务/提供者相关的成本和损失
3195		-
3196		-优化用户培训成本
3197		-
3198		-优化用户支持成本
3199		-)))|(% style="width:391px" %)(((
3200		-减少过渡成本
3201		-
3202		-减少用户支持成本
3203		-
3204		-优化入门成本和整体资源利用率
3205		-)))
3206		-
3207		-引入包括：
3208		-
3209		-* 在利益相关者中构建有关新服务消费者（或与现有消费者的服务关系的新范围）的认知
3210		-* 确保为服务提供准备好服务范围内的所有资源
3211		-* 确保客户和用户已准备好使用服务消费。
3212		-
3213		-引入通常被认为是服务提供者的活动，而服务消费者参与却很少。但是，成功的引入涉及服务提供者和服务消费者。如果服务消费者的参与需要大量资源，组织通常会同意，并提前与客户达成引入的方法。重要的是要确保其他合作伙伴和供应商知道并接受引入方法和计划（如果它们将参与其实现）。当将引入详细定义为产品、服务和服务产品设计的一部分时，用于特定计划的规划则更容易、更安全、更快捷。因此，在第5章中将引入方法定义为产品、服务和服务提供设计的一部分。在本章中，引入方法适用于特定引入计划的计划。
3214		-
3215		-从服务提供者角度来看，成功的引入依赖于以下ITIL 管理实践：
3216		-
3217		-* 部署管理
3218		-* 组织变革管理
3219		-* 发布管理
3220		-* 服务配置管理
3221		-* 服务设计
3222		-* 服务台
3223		-* 服务级别管理。
3224		-
3225		-规划和执行引入计划中可能还涉及其他实践。例如，有时将引入作为项目进行管理，需要项目管理实践。
3226		-
3227		-
3228		-|(((
3229		-**ITIL故事：第5步– 引入**
3230		-
3231		-[[image:1639049400385-584.png||height="51" width="42"]]//Mariana：汽车共享与传统汽车租赁不同。我们希望与客户保持持续的关系，并且客户必须对法律以及他们对汽车共享俱乐部中其他驾驶员的义务负责。//
3232		-
3233		-[[image:1639049408203-780.png||height="54" width="39"]]**S**//olmaz：我们已经为客户建立了会员等级。他们中的一些人将成为常规用户，而某些人将不再需要汽车。普通客户将支付月租费和较低的预订费，而很少使用的客户将支付较高的预订费以避免月租费。我们所有的客户都需要完成相同的引入流程。//
3234		-
3235		-[[image:1639049400385-584.png||height="51" width="42"]]//Mariana：在我们的引入过程中，我们请客户同意他们将遵守所有驾驶法规。这包括关于遵守交通信号灯和标志，不在酒精或毒品影响下驾驶的法律以及停车法。我们还要求所有客户在使用我们的汽车时携带驾驶执照和其他身份证明。//
3236		-)))
3237		-
3238		-[[image:1639049435845-855.png]]
3239		-
3240		-
3241		-== 7.1 规划引入 ==
3242		-
3243		-引入规划实际上是将一种或多种服务产品的引入方法适应于该引入计划的范围和背景的行为。引入计划应该考虑服务关系的当前状况、引入计划的范围、资源的当前配置以及相关的风险。
3244		-
3245		-
3246		-规划引入计划是客户和服务提供者之间的协作。客户参与：
3247		-
3248		-* 定义引入目标和相关指标
3249		-* 确定引入所覆盖的服务提供者和服务消费者资源（（访问和集成）
3250		-* 规划引入行动，包括时间表和职责
3251		-* 审核并接受引入计划。
3252		-
3253		-引入计划应该回答以下问题：
3254		-
3255		-* 引入目标是什么？
3256		-* 引入范围是什么？
3257		-* 引入行动是什么？
3258		-* 谁负责引入行动？
3259		-* 如何控制引入并确保其成功？
3260		-
3261		-=== 7.1.1 引入目标 ===
3262		-
3263		-服务提供者应该与利益相关者就引入目标定义、同意并构建认知。引入目标应在每个引入计划的背景中定义。引入目标的示例包括：
3264		-
3265		-* 确保服务消费者顺利迁移到协议服务
3266		-* 确保服务消费者从内部技术平台平稳迁移到云
3267		-* 支持所选服务的用户数量的临时增加
3268		-* 支持服务消费者从一个（第三方）供应商切换到另一个。
3269		-
3270		-应该根据议定的目标（成果）来评估引入的成功，而不是仅仅检查计划的引入行动（输出）的进度和完成情况。
3271		-
3272		-
3273		-负责与服务消费者之间的关系以及范围内产品和服务管理的团队，应设定引入目标。 这些人可能扮演以下角色：
3274		-
3275		-* 产品负责人
3276		-* 服务负责人
3277		-* 客户经理
3278		-* 关系经理
3279		-* 业务合作伙伴。
3280		-
3281		-在服务消费者方面，客户有责任同意引入的目标，并将其传达给组织内的相关利益相关方，以及组织的合作伙伴和供应商（如果它们是引入的一部分或受其影响）。
3282		-
3283		-
3284		-在关键利益相关方接受引入目标之后，应通过详细的引入计划使引入方法适应计划的背景。计划由服务提供者驱动。但是，服务消费者代表将被告知、被咨询或对此负责，因为引入是一项联合行动，可能需要双方大量资源。
3285		-
3286		-
3287		-== 7.1.2 引入范围 ==
3288		-
3289		-要定义引入的范围，应考虑以下问题：
3290		-
3291		-* 需要引入的消费者资源是什么？
3292		-* 引入需要哪些提供者资源？
3293		-* 引入什么时候开始和结束？
3294		-
3295		-引入方法有望回答所有这些问题，但是每个引入计划都需要根据该计划的范围，对引入方法进行审查和调整。
3296		-
3297		-
3298		-表7.2概述了与服务管理四维模型有关的消费者资源引入的可能范围。
3299		-
3300		-
3301		-表7.2 引入的消费者资源示例
3302		-
3303		-|(% style="width:129px" %)**服务管理维度**|(% style="width:417px" %)**资源实例**|(% style="width:749px" %)**需要引入的示例**
3304		-|(% style="width:129px" %)组织和人员|(% style="width:417px" %)用户（消费者组织的雇员）|(% style="width:749px" %)为了有效利用服务，用户需要接受有关服务使用和支持设置方面的培训
3305		-|(% style="width:129px" %)价值流和流程|(% style="width:417px" %)消费者组织程序、动作和工作流程|(% style="width:749px" %)应调整程序以整合服务、技术和服务提供商人员
3306		-|(% style="width:129px" %)信息和技术|(% style="width:417px" %)消费者组织的技术、数据和IT服务|(% style="width:749px" %)应该授予服务提供商代表访问消费者组织的IT资源的权限； IT资源应与服务提供商的IT资源整合在一起； 数据和信息应迁移和/或转换
3307		-|(% style="width:129px" %)合作伙伴和供应商|(% style="width:417px" %)用户（消费者组织的供应商和合作伙伴的雇员充当新服务用户）|(% style="width:749px" %)用户（代表消费者组织的供应商和合作伙伴）需要使用服务和支持程序方面的培训
3308		-
3309		-引入方法将影响一个或多个资源。当为引入方案创建引入计划时，服务提供者应基于引入方法识别需要引入的特定资源和所需的操作。
3310		-
3311		-
3312		-对于客户旅程，引入暗示以下或类似的场景之一：
3313		-
3314		-* 引入新的服务消费者组织开始使用一系列服务
3315		-* 在现有服务消费者组织内加入新客户
3316		-* 引入现有客户开始使用一系列新服务
3317		-* 从其它服务提供者迁移服务消费者
3318		-* 从其它服务提供者迁移服务和/或生产。
3319		-
3320		-这些场景旨在连接服务提供者资源和服务消费者，服务消费者可能涉及多个服务、用户、位置和供应商。最复杂的引入计划可以作为项目或项目群来运行。在设计产品和服务时，服务提供者旨在最大程度地减少引入的成本，并使服务消费的启动变得无缝和便捷。
3321		-
3322		-对于用户旅程，引入意味着以下或类似的场景之一：
3323		-
3324		-* 引入新的用户开始使用一项或多项服务
3325		-* 引入现有的用户以开始使用一项或多项服务
3326		-* 引入现有用户切换到一个或多个服务的较新版本
3327		-* 将现有的用户从当前的服务迁移到另一个服务。
3328		-
3329		-这些场景意味着服务提供者和服务消费者的资源已在客户引入期间集成，并且用户引入仅需要针对用户的较少操作。但是，涉及大量用户的用户引入计划可能非常复杂，需要项目管理。
3330		-
3331		-
3332		-为了确定引入计划开始和结束时间，应考虑以下因素：
3333		-
3334		-* 全新或现有的服务消费者
3335		-* 全新或现有的客户
3336		-* 全新或现有的用户
3337		-* 全新或现有的生产/ 服务/ 服务供应
3338		-* 由服务提供者资助的商业服务提供，或由服务消费者组织资助的非商业性服务。
3339		-
3340		-基于上述考虑，引入可能在以下选项期间启动：
3341		-
3342		-* 当各方达成有关服务提供协议时
3343		-* 服务合同正式签订后
3344		-* 服务已部署并准备发布时
3345		-* 服务正在部署时
3346		-* 当用户正式受雇于服务消费者时
3347		-* 用户临时同意的工作时间
3348		-
3349		-引入计划的结束也可能会有所不同。例如，当第一个用户能够使用服务时，或者在所有用户成功通过测试以确认他们熟悉服务之后，某些引入计划可能被视为已完成。新的服务、客户或用户的引入可能包括旧的撤销。有时，这是完成引入所必需的。
3350		-
3351		-
3352		-
3353		-=== 7.1.3 引入客户和用户：引入活动 ===
3354		-
3355		-在同意引入计划的范围之后，应规划引入活动。根据引入计划的范围和规模，以及组织的政策、规则和实践，用于计划的方法和工具可能会有所不同。表7.3提供了可能为服务管理四维模型资源计划的引入活动示例。
3356		-
3357		-
3358		-表7.3中的示例描述了服务提供者、服务消费者和服务消费者的合作伙伴/供应商如何参与引入计划。可以根据应该与服务消费者进行交互的资源类型来定义更具体的操作。例如，向服务消费者介绍服务提供者的应用程序可能需要进行在线培训，但是在研讨会上向他们介绍服务提供者员工会更好。
3359		-
3360		-
3361		-用户引入是用户体验的重要组成部分。当向个人消费者提供服务时，客户和用户引入通常会合并在一起，并且引入操作涵盖了这两个方面。当向大型组织提供服务，并且客户和用户的角色可能会分开时，客户和服务提供者将一起计划用户引入活动。这可能会导致从消费者组织的角度描述引入方法。
3362		-
3363		-
3364		-在许多情况下，尤其是为个人消费者提供服务时，服务提供商会标准化引入并使之自动化。这通常是通过使用高度标准化和兼容的IT解决方案来实现，例如通用平台、标准库和协议、微服务等。无缝引入通常由以下因素维护：
3365		-
3366		-* 多语言界面
3367		-* 高度直观的界面
3368		-* 高可用性支持，包括自助服务和同行支持
3369		-* 自动化软件安装和更新
3370		-* 跨平台可用性。
3371		-
3372		-表7.3 服务提供者、服务消费者和供应商/合作伙伴引入活动的示例
3373		-
3374		-|(% style="width:176px" %)**服务消费者资源即将启用**|(% style="width:354px" %)**服务提供者执行的引入活动**|(% style="width:348px" %)**服务消费者执行的引入活动**|(% style="width:417px" %)**服务消费者的合作伙伴/ 供应商执行的引入活动**
3375		-|(% style="width:176px" %)服务消费者的组织和人员|(% style="width:354px" %)(((
3376		-提供培训和培训材料
3377		-
3378		-介绍了联系和支持界面
3379		-
3380		-授予用户访问服务的权限
3381		-
3382		-传达了必要的警告（安全和责任）以及条款和条件
3383		-
3384		-成立治理组织
3385		-)))|(% style="width:348px" %)(((
3386		-用户学习培训材料（阅读、参加培训、学习教程等）
3387		-
3388		-组织同意并分配了使用新服务的责任
3389		-
3390		-角色和/或团队已更改以优化服务消费
3391		-
3392		-组织变革管理
3393		-)))|(% style="width:417px" %)(((
3394		-如果供应商服务受引入影响，则提供培训和培训材料
3395		-
3396		-对服务的访问权限进行审查并在需要时进行更改
3397		-)))
3398		-|(% style="width:176px" %)服务消费者的信息和技术|(% style="width:354px" %)(((
3399		-信息系统集成
3400		-
3401		-数据迁移和/或转换，建立数据交换
3402		-
3403		-进行必要的配置和自定义
3404		-
3405		-部署了监视工具和其他操作工具
3406		-
3407		-建立了数据交换协议、集成和工具
3408		-)))|(% style="width:348px" %)(((
3409		-服务提供者的专家可以访问信息资源
3410		-
3411		-信息系统与服务提供者的系统集成在一起
3412		-
3413		-冗余信息系统已停用
3414		-
3415		-建立了数据交换协议、集成和工具
3416		-)))|(% style="width:417px" %)(((
3417		-受引入影响的服务变更（基础架构支持）
3418		-
3419		-服务消费者委托合作伙伴/供应商执行的任何操作
3420		-)))
3421		-|(% style="width:176px" %)服务消费者的价值流和流程|(% style="width:354px" %)(((
3422		-同意服务提供商参与服务消费者的流程； 角色、职责得到同意、分配和测试
3423		-
3424		-在需要的地方提供流程改进咨询
3425		-)))|(% style="width:348px" %)(((
3426		-为服务消费更改/优化组织流程
3427		-
3428		-价值流得到优化，以最大化服务价值
3429		-
3430		-冗余程序（由服务替换或自动化）被删除或更新
3431		-)))|(% style="width:417px" %)(((
3432		-审核合作伙伴/供应商对服务消费者流程的参与；在需要时就角色、职责进行约定、、分配和测试
3433		-
3434		-在需要的地方提供流程改进咨询
3435		-)))
3436		-|(% style="width:176px" %)服务消费者的合作伙伴和供应商|(% style="width:354px" %)(((
3437		-服务消费者的合作伙伴/供应商的授权代表可以使用服务
3438		-
3439		-在需要时提供退役/迁移协助
3440		-)))|(% style="width:348px" %)(((
3441		-与合作伙伴/供应商的合同已更新，以适应新的流程和价值流
3442		-
3443		-冗余（替换）服务的合同被取消或更改
3444		-
3445		-传达服务的新/变更要求
3446		-)))|(% style="width:417px" %)(((
3447		-必要时对合同进行审查和更新
3448		-
3449		-作为用户的供应商代表应学习所需的材料（通过阅读、参加培训、学习教程等）
3450		-)))
3451		-
3452		-但是，在许多引入计划中，用户需要引起极大关注，并且必须将其引入新服务，包括所有四个维度的资源。这种类型的用户引入通常与客户引入相吻合，在客户引入中，向大量用户提供了一项或多项新服务。表7.4概述了用户引入活动类型的示例。
3453		-
3454		-
3455		-表7.4 用户引入活动的示例
3456		-
3457		-(% style="width:923px" %)
3458		-|**服务**|(% style="width:524px" %)**动作**
3459		-|技术（应用和设备）|(% style="width:524px" %)(((
3460		-在线教程、正式培训、模拟器、自定进度的培训，以及各种形式的手册
3461		-
3462		-指导安装和设置
3463		-
3464		-培训超级用户以领导同行
3465		-)))
3466		-|流程（活动和过程）|(% style="width:524px" %)(((
3467		-海报、手册和培训
3468		-
3469		-演练和指导
3470		-
3471		-根据用户的动机来激发正确的行为
3472		-
3473		-阻止访问旧的工作方式
3474		-)))
3475		-|提供者的人员（操作和支持）|(% style="width:524px" %)(((
3476		-面对面或虚拟介绍，联合研讨会和培训
3477		-
3478		-通讯录和明确的角色描述
3479		-
3480		-团队建设
3481		-)))
3482		-|第三方人员（操作和支持）|(% style="width:524px" %)(((
3483		-面对面或虚拟介绍，联合研讨会以及培训，
3484		-
3485		-通讯录和明确的角色描述
3486		-
3487		-团队建设
3488		-)))
3489		-
3490		-这些引入活动受多种ITIL惯例的支持，包括：
3491		-
3492		-* 变更使能
3493		-* 部署管理
3494		-* 组织变革管理
3495		-* 项目管理
3496		-* 发布管理
3497		-* 服务台
3498		-* 服务请求管理
3499		-* 劳动力和人才管理。
3500		-
3501		-=== 7.1.4 引入控制 ===
3502		-
3503		-当规划引入计划时，必须就控制和验证技术的方法达成一致，以确保计划成功。这种方法通常由引入计划的管理决定来主导。表7.5列出了根据情况可以组合的各种可用选项。
3504		-
3505		-
3506		-保持简单实用的指导性原则适用于引入控制。在许多情况下，最好将引入的控制定义为引入方法的一部分。但是，与引入方法的其他组件一样，应在规划期间对其进行检查和调整。
3507		-
3508		-
3509		-对已完成的引入计划的正式评审可能是有价值的练习。根据引入控制的一般方法，评审可能包括以下内容：
3510		-
3511		-* 正式确认所有计划的引入活动均已完成
3512		-* 评审用户、客户和其他利益相关者的满意度和体验
3513		-* 评审未决的操作和错误
3514		-* 风险评估
3515		-* 持续改进实践的改进登记
3516		-
3517		-表7.5 引入控制方法示例
3518		-
3519		-|**引入计划的管理方式**|**如何控制和验证引入进度和成功**|**ITIL实践支持方法**|**适用性**
3520		-|项目集|项目集和项目计划、工作包、评审和KPI|组织变革管理、项目管理|大型客户和用户引入计划需要对各种资源进行复杂的更改
3521		-|项目|项目计划、工作包、评审和KPI|组织变革管理、项目管理|企业服务的大多数服务消费者引入计划
3522		-|一般变更|自定义清单|变更使能、部署管理、组织变革管理、发布管理、服务验证和测试|较小的服务消费者引入计划，主要是向现有消费者引入新服务的地方
3523		-|标准变更|预定义清单|变更使能、部署管理，组织变革管理、发布管理以及服务验证和测试|企业服务的大多数用户引入计划
3524		-|自动化部署和发布（例如，即插即用）|预装的自动化测试和控制|部署管理、基础架构和平台管理、监控和事态管理，发布管理以及软件开发和管理|提供给个人服务消费者的大多数数字服务引入计划，以及企业服务的许多用户引入计划
3525		-|审计与保证|第三方审核、审计意见、保证书、现场检查等|信息安全管理、度量和报告、风险管理和供应商管理|正式服务关系或高度管制环境中的关系
3526		-
3527		-引入评审可能会导致下述各种改进：
3528		-
3529		-* 产品、服务和服务提供设计
3530		-* 用户接口和程序
3531		-* 服务组合
3532		-* 服务目录
3533		-* 与合作伙伴和供应商的关系
3534		-* 服务提供者的管理实践
3535		-* 正在进行的引入计划和举措
3536		-
3537		-|(((
3538		-**ITIL故事：规划引入**
3539		-
3540		-[[image:1639049867583-763.png||height="47" width="45"]]//Mariana：引入的目标是确保客户对使用电动车的各个方面感到满意。他们还需要知道如何预订车辆，并且必须同意在我们的道路上以合法和负责任的方式行事。//
3541		-
3542		-[[image:1639049876815-154.png||height="49" width="37"]]**R**//adhika：在我们能够将其发布给我们的第一批客户之前，指导视频经过了一些规划。艾克苏没有专门的电动汽车教育视频，而汽车共享是该公司的一项新服务。客户需要事先做出一些决定，例如他们首选的会员等级。//
3543		-
3544		-[[image:1639049867583-763.png||height="47" width="45"]]//Mariana：我们还希望能够参考视频中的巴西法律法规。艾克苏提供了预算，将视频制作外包给一个小的本地团队，其中包括一名作家、导演和两个演员。我们拍摄了汽车收藏、汽车充电和事件报告。我们还介绍了如何联系道路救援，以及如何计划可能包括公共充电站的旅程。此外，我们希望确保视频中有多种语言的字幕，因为该大学拥有大量的国际学生和教职员工。//
3545		-
3546		-[[image:1639049903595-695.png||height="60" width="43"]]**S**//olmaz：我们的第一批客户对引入给予了积极的反馈。新车共享客户在第一个月内致电服务台的电话，每个客户不超过两次。//
3547		-)))
3548		-
3549		-
3550		-
3551		-== 7.2 与用户相关并建立关系 ==
3552		-
3553		-由于服务提供者与服务消费者的技术和信息进行了更多的交互，因此某些服务不包括服务提供者与用户之间的广泛交互。机器对机器服务（例如IoT设备、技术微服务、信息系统维护和数据存储）是此类服务关系的示例。
3554		-
3555		-
3556		-但是，大量的服务包括活动的、频繁的和重要的接触点以及与服务用户的交互。服务提供者代表、过程和技术（例如用户应用程序和可穿戴/嵌入式技术）是交互式的。
3557		-
3558		-
3559		-当用户与服务提供者交互时，用户体验成为服务成功的关键因素。糟糕的用户体验导致生产效率下降，并给服务和服务提供者带来负面印象。这意味着服务提供者和客户在客户旅程的所有步骤中都应注意用户体验。对于任何包含直接用户交互作用的服务，积极的用户体验应该是最重要的要求之一。
3560		-
3561		-
3562		-如果客户对用户体验的关注不足或对用户体验的要求不明确，那么创建积极的用户体验仍然很重要。服务提供者应该与用户一起培育关系，即使客户并不直接要求它也是如此。
3563		-
3564		-
3565		-用户体验应该被视为产品和服务的设计、开发、测试，过渡到运行环境，持续交付以及定期评估和评审的一部分。它也应该是持续改进的主题。
3566		-
3567		-
3568		-用户引入会影响用户对服务和服务提供者的态度。对于成功的服务消费而言，这很重要，因为它可以实现价值的价值共创，并有助于与用户和消费者组织建立和维护可持续的关系。
3569		-
3570		-
3571		-=== 7.2.1 建立与企业用户的关系 ===
3572		-
3573		-在大型组织环境中，用户引入通常是由组织所使用的服务的更改，用户组的更改（例如组织中的新成员）或人员角色和职位的更改触发的。
3574		-
3575		-
3576		-当服务消费者组织大于几个人时，用户和客户角色之间的区别变得明显且重要。客户成为组织的代表，并就新的和更改的服务与服务提供者进行沟通。这可能会导致首次用户交互出现在引入期间。在某些情况下，用户不愿接受新的服务或更改的服务，也拒绝引入。这种抵制可能会影响服务的整体生产效率和价值。
3577		-
3578		-
3579		-为了防止抵制新服务并建立良好的关系，服务消费者和服务提供者组织应该在客户旅程的每个步骤中共同努力。这可以通过以下方式完成：
3580		-
3581		-* 考虑客户体验在客户旅程的每个步骤中如何受到影响
3582		-* 规划用户引入作为每个新服务实施的一部分
3583		-* 实行组织变革管理
3584		-* 让用户参与需求表达
3585		-* 让用户参与测试服务和引入活动
3586		-* 设计用户友好的界面
3587		-* 理解和利用人们作为私人用户的体验及其相关期望
3588		-* 提供有用、方便且相关的服务目录，包括服务请求目录
3589		-* 持续监控用户满意度以改进服务体验
3590		-* 让用户参与服务测试、评估和审查
3591		-* 让有影响力的用户参与服务推广和对等同行支持计划
3592		-* 培育用户社区并积极支持其成员
3593		-* 对画像执行服务使用情况分析，并主动使用实时终端用户计算数据。
3594		-
3595		-当组织的用户社区的变化触发引入时，IT服务引入可能会成为更广泛的引入计划的一部分。这包括人力资源、法律、财务和其他团队。在这些情况下，重要的是要确保与包括内部和外部服务提供程序在内的多方进行有效的集成和交互。这会影响用户对组织的看法。为了成功引入新用户，需要特别关注所涉及服务提供者之间的集成和一致性。使单个团队或角色负责用户/员工引入可能会很有用；这可以是人力资源团队/ 角色，也可以是专注于用户参与和福利的团队/ 角色。
3596		-
3597		-
3598		-当企业用户参与进来时，保持联系和参与很重要。用于此目的的工具和技术包括：
3599		-
3600		-* 服务提供者积极支持的具有用户组和对等同行支持的企业社交网络
3601		-* 使用便捷的渠道，可提供有效且高度可用的服务台
3602		-* 用户参与的服务评审和改进
3603		-* 仪表板和报告让用户社区可以清楚地了解服务质量。
3604		-
3605		-
3606		-=== 7.2.2与个人消费者一起培育关系 ===
3607		-
3608		-当服务消费者是个人时，有很多因素会影响服务提供者在客户旅程期间如何管理服务关系。表7.6列出了其中一些因素。
3609		-
3610		-
3611		-表7.6 与个人服务消费者的关系管理
3612		-
3613		-(% style="width:1171px" %)
3614		-|(% style="width:93px" %)**步骤**|(% style="width:468px" %)**挑战性**|(% style="width:606px" %)**服务提供商应用的示例解决方案**
3615		-|(% style="width:93px" %)探索|(% style="width:468px" %)(((
3616		-服务消费者未明确表达其需求和期望
3617		-
3618		-有时服务消费者没有意识到他们的需求和机会
3619		-
3620		-个人意见不一定代表更大的消费群体的需求
3621		-)))|(% style="width:606px" %)(((
3622		-市场营销和社会学调查
3623		-
3624		-有代表性的小组进行的安全失效实验
3625		-
3626		-旨在提高认识和创造需求的营销活动
3627		-)))
3628		-|(% style="width:93px" %)契动|(% style="width:468px" %)(((
3629		-由于用户数量众多且服务提供者的能力有限，因此个人面对面的联系通常是不可能或效率低下的
3630		-
3631		-售前和售后受到严格监管，以保护消费者权益
3632		-
3633		-社区、影响者和同行的意见对于最初的契动决定很重要
3634		-)))|(% style="width:606px" %)(((
3635		-使用相关渠道和媒体公开广告
3636		-
3637		-广泛使用社交媒体、影响者和用户群体
3638		-
3639		-使用直接营销和对等的代理商
3640		-
3641		-基于对用户互联网活动的监视、搜索引擎优化以及其他针对目标受众的工具的情境广告
3642		-
3643		-优化基于互联网的服务目录（网站、登录页面、社交媒体帐户等）
3644		-
3645		-在相关和合理的情况下，销售和支持办公室网络
3646		-)))
3647		-|(% style="width:93px" %)供应|(% style="width:468px" %)(((
3648		-大量的服务消费者
3649		-
3650		-需要简单快捷的签约程序和界面
3651		-)))|(% style="width:606px" %)(((
3652		-标准服务目录、合同和协议
3653		-
3654		-目录和协议中的用户友好的简单语言描述
3655		-
3656		-广泛使用移动平台和应用程序
3657		-)))
3658		-|(% style="width:93px" %)同意|(% style="width:468px" %)(((
3659		-高水平的国际、国家和行业法规
3660		-
3661		-需要简单明确的语言
3662		-)))|(% style="width:606px" %)(((
3663		-高度自动化的签约，广泛使用数字文档和签名
3664		-
3665		-与电子支付系统（卡、PayPal等）集成
3666		-
3667		-自动尽职调查检查（如果适用）
3668		-)))
3669		-|(% style="width:93px" %)引入|(% style="width:468px" %)(((
3670		-大量具有不同技能和背景的服务消费者
3671		-
3672		-需要简单快速的引入
3673		-
3674		-不同的技术背景
3675		-)))|(% style="width:606px" %)(((
3676		-自动化的介绍和初步培训
3677		-
3678		-经过严格测试的引入说明和规程
3679		-
3680		-有关用户支持资源的专门章节，以帮助引入
3681		-
3682		-自动化资格和兼容性检查
3683		-)))
3684		-|(% style="width:93px" %)价值共创|(% style="width:468px" %)(((
3685		-大量具有不同技能和背景的服务消费者
3686		-
3687		-不同的技术背景
3688		-
3689		-不同的语言和沟通技巧
3690		-
3691		-通过社交媒体高度暴露用户体验和意见
3692		-)))|(% style="width:606px" %)(((
3693		-可用、方便且最新的在线状态支持常规业务
3694		-
3695		-为具有技能、背景和能力的用户优化的界面
3696		-
3697		-便捷的支持和沟通渠道（电话、支持办公室、社交媒体帐户、直接消息传递）
3698		-
3699		-社交媒体监控，并在投诉和其他问题时提供积极支持
3700		-
3701		-促进用户社区成为服务提供商及对等同行支持的渠道
3702		-
3703		-主动沟通（尤其是在重大事件时）、透明度和高可用性
3704		-
3705		-利用媒体和营销手段进行损害控制和被动式声明
3706		-
3707		-监视和事态管理以主动纠正服务质量偏差，或联系服务使用者
3708		-)))
3709		-|(% style="width:93px" %)(((
3710		-实现价值
3711		-)))|(% style="width:468px" %)(((
3712		-大量服务消费者
3713		-
3714		-个人经验对服务质量和满意度统计的影响很小
3715		-
3716		-对每个服务消费者进行直接服务评估的效率低下或不可能
3717		-
3718		-服务支持的不同期望和需求
3719		-)))|(% style="width:606px" %)(((
3720		-用于服务质量监控和报告的自动化接口，
3721		-
3722		-持续监控社交媒体反馈
3723		-
3724		-对用户满意度和态度的独立调查
3725		-
3726		-使用用户忠诚度指标（例如，净推荐值）
3727		-
3728		-使用自动体验指标
3729		-
3730		-服务消费者要求的服务评估专用支持渠道
3731		-)))
3732		-
3733		-服务提供者可以控制有关这些因素的决策。但是，与个人服务消费者的关系可能要遵守组织必须遵守的规定。例如，预期或法律上要求服务提供者要特别考虑残疾用户。
3734		-
3735		-
3736		-为了使服务取得成功，用户（个人和公司）可以通过有效的渠道和接口访问用于选择、引入、使用、支持和评审的服务尤为重要。
3737		-
3738		-
3739		-|(((
3740		-**示例**
3741		-
3742		-英国监管机构要求移动通信提供商制定并遵循政策和规范，以确保公平、恰当地对待弱势消费者，他们或因年龄、身体或学习障碍、身体或精神疾病、识字率低、沟通困难而脆弱，或因情势变化而脆弱，例如丧亲。
3743		-
3744		-这些政策和做法应解决：
3745		-
3746		-* 关键功能的可访问界面
3747		-* 通过高度可访问的界面访问重要信息
3748		-* 获得紧急服务
3749		-* 优先故障修复
3750		-* 第三方账单管理
3751		-* 无障碍格式的票据和合同
3752		-* 数据保护。
3753		-)))
3754		-
3755		-== 7.3 提供用户参与和交付渠道 ==
3756		-
3757		-重要的是要建立适当的用户参与和交付渠道，以提供良好的用户体验。
3758		-
3759		-
3760		-用户使用社交媒体、聊天、热线和电子邮件等渠道与服务提供者进行互动。他们还可以在每个用户旅程中使用多个渠道。例如，用户可以通过自助门户网站报告事件，通过电子邮件为该事件中提供更多的信息，通过电话询问状况，并通过在线聊天回复服务提供者的问题。 跨所有渠道、接触点和服务交互来管理用户体验称为全渠道管理。 全渠道管理的目的是为用户提供无缝的用户旅程。 这些原理如图7.1所示。
3761		-
3762		-(% style="text-align:center" %)
3763		-[[image:1639050104902-799.png]]
3764		-
3765		-图7.1 通过全渠道管理实现无缝的用户旅程
3766		-
3767		-
3768		-随着技术的发展，服务提供者会对其进行测试，并将其用于服务交付，并在适用的情况下为用户提供支持以及客户和用户旅程的其他步骤。影响选择和设计的趋势包括：
3769		-
3770		-* 许多服务提供者尝试将左移法应用于服务支持。这可能包括将一些支持任务从服务提供者转移到用户，以及扩大自助服务选项的范围。说明，视频教程和逐步向导可以支持此方法。
3771		-* 许多服务提供商将社交媒体用于对等和服务提供者支持。该方法被广泛用于提供给可能是社交网络中活跃用户的个人用户的服务，并且通常由多个渠道来启用。
3772		-* 用户期望公司和个人服务提供他们习惯的体验，并且是基于他们日常的智能手机、个人计算机、可穿戴设备和常用应用程序的使用。为了满足此需求，服务提供商使用或模拟熟悉的接口来为其服务提供交付和支持。他们还更新了这些接口，以与操作系统、移动设备、流行的应用程序和社交网络的发展保持一致。
3773		-* 一个普遍的趋势是使用机器学习功能来自动化用户支持。聊天机器人是这种方法的一个示例。这可能包括人工认知支持、自然语言理解及处理和翻译、自动语音识别以及在与服务提供者联系之前和期间预测用户行为。
3774		-* 机器学习还可以用于基于用户画像和服务消费模式的优化支持和交付渠道。这可能包括高级路径，以找到针对用户的最佳支持代理或资源，包括基于技能、基于语言、基于国家/地区、基于产品、基于客户和基于技术的路径。
3775		-* 对自动界面不满意时，许多用户珍视与人工支持代理进行交谈的机会，尤其是在发生事件的情况下。为了满足这种需求，一些服务提供者通过电话、电子邮件、聊天或社交媒体引入，重新引入或改进人工支持。使用这种方法时，确保高可用性和快速响应尤其重要。在某些情况下，物理上的存在（例如在现场中心中）仍然是联系服务提供者的最理想方式。
3776		-* 为基于技术的服务提供远程用户支持时，通常的做法是使用带有视频功能的移动设备，以允许支持代理查看用户正在疲于应付的设备和应用程序。这可能是支持缺乏技术技能的用户的有效方法。
3777		-* 监控和事态管理技术帮助服务提供者远程主动地监视、管理和修复服务组件，从而使用户在请求支持时无需执行诊断操作。
3778		-
3779		-这些方法与服务提供者必须考虑的挑战有关。表7.7说明了其中一些挑战。
3780		-
3781		-
3782		-表7.7 服务提供者必须考虑的全渠道挑战示例
3783		-
3784		-|**方法**|**挑战示例**|**解决方案示例**
3785		-|左移，增加自助服务|(((
3786		-用户没有足够的技术技能和/或动力来使用自助服务工具
3787		-
3788		-用户在访问服务的级别上只能完成有限的任务
3789		-
3790		-用户在自助服务期间犯的错误可能导致更多事件
3791		-
3792		-基于知识的导航可能很困难
3793		-)))|(((
3794		-实施自助服务之前，评估用户技能和可用的支持行动范围
3795		-
3796		-与具有代表性的用户组全面测试所有自助服务说明和工具
3797		-
3798		-确保自助服务工具和操作安全且易于使用
3799		-
3800		-改善信息质量和导航工具
3801		-)))
3802		-|社交媒体支持|(((
3803		-情绪化且难以控制的沟通方式
3804		-
3805		-病毒效应、容易出错和发生冲突
3806		-
3807		-非结构化信息
3808		-
3809		-多个渠道进行监控和回复
3810		-
3811		-处理个人和合同信息方面的限制
3812		-
3813		-没有集成的诊断工具
3814		-
3815		-没有正式记录系统在服务提供者的控制之下
3816		-)))|(((
3817		-培训社交媒体传播中的支持人员
3818		-
3819		-使用标签和服务/服务提供商的其他提及来自动监视用户证据
3820		-
3821		-将社交媒体渠道与专门的支持系统集成。 保留记录并处理这些系统中的敏感信息
3822		-
3823		-确保用户对社交媒体的所有支持请求都得到迅速响应并处理得令其满意
3824		-)))
3825		-|熟悉的界面|(((
3826		-服务提供者使用的旧版系统可能会限制兼容性和接口设计
3827		-
3828		-常用的应用程序和操作系统不断发展，通常多个平台和版本共存
3829		-
3830		-一些服务需要专门的设备和接口
3831		-)))|(((
3832		-设计产品和服务以实现持续发展和灵活性，最大程度地减少使用大一统的和旧的产品
3833		-
3834		-考虑提供适合不同平台用户的界面
3835		-
3836		-提供自定义接口时，进行可用性设计，并在可能的情况下遵循常用服务和接口的使用模式
3837		-)))
3838		-|机器学习：聊天机器人|(((
3839		-适用范围有限
3840		-
3841		-机器学习的数据不足和不恰当
3842		-
3843		-多语言支持的困难
3844		-)))|(((
3845		-在成功程度足够高之前，请勿使用基于机器学习的人机界面来代替； 提供人工备份
3846		-
3847		-迭代地扩展基于机器学习的服务交互的范围，包括多个反馈循环
3848		-
3849		-不断提高用于与用户进行服务交互的所有语言的数据质量
3850		-
3851		-跟踪和利用机器学习方面的发展
3852		-)))
3853		-|机器学习：优化的交付渠道|(((
3854		-适用范围有限
3855		-
3856		-机器学习的数据不足和不恰当
3857		-
3858		-用户行为和支持组织的改变
3859		-
3860		-资源有限，无法支持多个渠道
3861		-)))|(((
3862		-关注最重要和最受欢迎的支持方式
3863		-
3864		-确保高质量的支持历史记录数据
3865		-
3866		-优化，然后自动化
3867		-
3868		-与经验丰富的支持代理商一起将新技术解决方案付诸实施
3869		-)))
3870		-|终端支持人员|(((
3871		-扩展性有限
3872		-
3873		-错误的可能性
3874		-
3875		-情绪态度
3876		-
3877		-高成本
3878		-)))|(((
3879		-支持人员的动力、忠诚度和专业发展
3880		-
3881		-将人工支持限制在需要和合理的情况下
3882		-
3883		-考虑点对点同行支持以增加可伸缩性并优化成本
3884		-)))
3885		-|视频诊断|(((
3886		-用户设备的使用可能会受到技术、法律和法规监管的限制
3887		-
3888		-隐私问题
3889		-
3890		-使用视频数据可能会给用户带来额外的费用
3891		-)))|(((
3892		-警告用户可能的风险和成本
3893		-
3894		-确保符合适用法规
3895		-
3896		-实施控制措施以防止滥用技术
3897		-)))
3898		-|增强监控|技术和隐私限制，尤其是在使用服务消费者的基础架构提供服务时|(((
3899		-与客户讨论收益、风险和成本，考虑与用户讨论
3900		-
3901		-确保符合适用法规
3902		-
3903		-实施控制措施以防止滥用技术
3904		-)))
3905		-
3906		-只有将这些方法编排为无缝的用户支持体验时，才能获得专注于用户的真正全渠道支持。这可以通过以下方式完成：
3907		-
3908		-* 跨所有渠道唯一地识别和辨识用户
3909		-* 系统地收集和分析用户数据
3910		-* 利用所有遇到的用户数据
3911		-* 监控并管理所有用户旅程中的绩效。
3912		-
3913		-在公司环境中提供服务时，通常很容易同意与用户进行交互的渠道。但是，人们希望他们在工作场所的体验与在家一样顺畅舒适。。服务提供者必须响应此需求，并提供更广泛的渠道和接口。这可能包括在没有加强数据保护的情况下，通过个人设备或公司设备提供业务服务。服务提供者和服务消费者在讨论并协定服务时应考虑收益、风险和成本。
3914		-
3915		-如表7.7所示，有可能克服这些挑战。但是，表7.7中列出的解决方案只能在财务、技术或组织方面有足够的资源才能应用。所需资源的示例包括：
3916		-
3917		-* 服务提供者团队和用户的技能和能力
3918		-* 用于支持的数据质量
3919		-* 接口的效率和可用性
3920		-* 与参与支持互动的供应商和合作伙伴整合
3921		-* 确保符合安全以及法律和法规要求
3922		-* 远程支持的连接性，包括用户端的支持
3923		-
3924		-选择和设计服务渠道时要考虑的一个重要因素是用户准备使用服务以及相关的风险和机遇。
3925		-
3926		-
3927		-|(((
3928		-**ITIL的故事：提供用户参与和交付渠道**
3929		-
3930		-[[image:1639050210407-577.png||height="47" width="42"]]//Mariana：eCampus Car Share是一款新的服务，我们尚未完全了解客户的业务活动模式。随着服务的成熟，我们将学习他们的定期通勤和旅程。然后，我们将能够使用推送通知来提醒他们即将发生的事件，例如周末节日或工作日封路。。//
3931		-
3932		-[[image:1639050219865-483.png||height="52" width="38"]]**S**//olmaz：我们可以使用社交媒体和在线实时视频流来使客户了解有关流动流量和事件的最新信息。//
3933		-)))
3934		-
3935		-== 7.4 使用户能够使用服务 ==
3936		-
3937		-某些服务需要特殊的用户技能。这些技能可能包括使用某些应用程序或设备，或者了解在使用服务的环境中安全操作的规则。例如，要被允许租用汽车，要求一个人具有有效的驾驶执照，该执照可证明根据特定国家/地区接受的交通法规来驾驶某种类型的汽车。
3938		-
3939		-要启用用户，服务提供者应考虑：
3940		-
3941		-* 向相关利益相关者收集需求
3942		-* 根据要求采取措施
3943		-* 控制实施并不断检查需求的相关性。
3944		-
3945		-对于许多服务，都有某些要求。为了使用户能够正确、安全和有效地使用这些服务，应在用户开始使用该服务之前满足这些要求。某些要求是由监管机构定义的；一些则是由服务消费者和服务提供者组织推出的。
3946		-
3947		-
3948		-同样重要的是，确保用户在使用服务目录或请求支持时，只能看到他们有权使用的服务以及可以使用的级别。适当的访问级别，再加上正确清晰地显示可用选项，有助于改进用户体验，防止混乱并降低信息安全风险。
3949		-
3950		-
3951		-这些要求可能需要：
3952		-
3953		-* 尽职调查，只有具有一定访问权限的人员才可以访问服务中提供的信息和技术。
3954		-* 用户培训和认证，只有具有公认的知识和技能的人才能使用某些服务。
3955		-* 安全培训和认证，只有具有安全规程知识的人才能使用某些服务。
3956		-* 年龄控制和身份检查，只有经过验证身份的用户才能访问某些服务或服务级别。
3957		-* 有效管理对服务、服务目录和支持接口的访问。
3958		-* 有效的服务目录展示，包括服务请求目录。
3959		-* 其他措施，以确保用户有权使用服务。
3960		-
3961		-这些措施中的许多都可以作为引入计划的一部分。有些可能需要定期确认，以作为持续消费的一部分。服务消费者和服务提供者组织应在提议和协定步骤上就措施达成一致。
3962		-
3963		-
3964		-业务分析、部署管理、信息安全管理、服务目录管理、服务设计、服务台和服务级别管理实践用于确保捕获用户需求，提供给相关方，满足并定期进行审查。
3965		-
3966		-
3967		-服务目录管理和服务台的实践对于用户引入尤其重要。这些做法可确保在用户旅程的各个步骤中为用户提供有效且友好的界面。
3968		-
3969		-
3970		-为了启用和有效地提供用户服务（包括用户对可用新服务和相关服务请求的认知），面向用户的服务目录应该：
3971		-
3972		-* 以合理的方式进行结构化，以反映用户的需求和活动方式
3973		-* 以清晰易懂的语言呈现
3974		-* 仅包含与用户相关的服务（并且已可用或已提供）
3975		-* 包括服务和相关的服务请求
3976		-* 保持最新
3977		-* 具有可操作性（并且在可能的情况下，对于用户有资格执行的操作是自动的，例如对服务级别和发起服务请求的细微更改）。
3978		-
3979		-服务台实践有助于有效的用户引入，从而使用户能够参与用户旅程的所有步骤。它提供了各种用户接口，使用户能够以最方便的方式联系服务提供者。这可能包括：
3980		-
3981		-* 移动应用程序，可以与流行的语音接口集成
3982		-* 由机器学习提供支持的联机帮助资源，例如聊天机器人和基于上下文的知识文章
3983		-* 在线工具访问受限的情况下，为用户提供电话热线
3984		-* 现场支持区域。
3985		-
3986		-服务台应该为所有相关类型的用户查询提供接口。这包括咨询、事件、服务请求、投诉和表扬。
3987		-
3988		-
3989		-服务台的界面和渠道应确保能力有限的用户具有访问权限。
3990		-
3991		-
3992		-这可能包括暂时或永久位于覆盖范围有限的区域，或遇到技术或通讯困难的用户。服务台还应该使用适当的界面来联系用户以获取反馈、满意度调查等。
3993		-
3994		-
3995		-|(((
3996		-**ITIL的故事：为用户提供服务**
3997		-
3998		-[[image:1639050311875-982.png||height="47" width="45"]]//Mariana：在eCampus Car Share，我们对客户有一定的要求，以使他们能够租用我们的汽车。例如，所有客户都必须具有有效的驾驶执照才能预订汽车。他们还必须知道如何使用电动汽车并为其充电。//
3999		-
4000		-[[image:1639050322640-448.png||height="48" width="36"]]**S**//olmaz：我们将概述客户的需求，以便通过我们的网站和预订应用程序租用我们的汽车。//
4001		-
4002		-[[image:1639050311875-982.png||height="47" width="45"]]//Mariana：当客户到场取车时，我们会对其所有文件进行彻底检查，以确保他们符合合规性的所有必要规定，以能够租车。//
4003		-
4004		-
4005		-[[image:1639050322640-448.png||height="48" width="36"]]**S**//olmaz：作为引入的一部分，我们检查客户是否熟悉电动车，如果不熟悉，我们会为供应提供他们更多的信息和指导，以确保他们在使用汽车时有顺畅的体验。我们为客户提供有关如何为汽车充电和使用的教学视频访问权。//
4006		-
4007		-[[image:1639050311875-982.png||height="47" width="45"]]//Mariana：我们还会为他们提供充电站和城市路线图、有关交通流量和拥堵的最新信息，以及有关如何使用汽车来帮助他们获得良好体验的常见问题和建议。//
4008		-)))
4009		-
4010		-== 7.5 提升彼此的能力 ==
4011		-
4012		-服务关系涉及所有利益相关者的价值共创。每次服务交互都是提升另一方能力的机会。表7.8解释了如何将每个ITIL指导原则用于一个小组，以提高另一组的能力。
4013		-
4014		-
4015		-表7.8 服务提供者和客户利用ITIL 指导原则提高用户能力的示例
4016		-
4017		-|(% style="width:148px" %)**指导原则**|(% style="width:1146px" %)**优化用户能力的应用示例**
4018		-|(% style="width:148px" %)聚焦价值|(% style="width:1146px" %)用户应了解其工作目的和背景以及服务使用情况。 应鼓励他们提供可能有助于价值共创的服务改进。
4019		-|(% style="width:148px" %)从当前开始|(% style="width:1146px" %)用户体验的改善应基于当前的做法、习惯和期望。 用户体验中的根本性变化很少被视为改善，并且经常受到用户的抵制。
4020		-|(% style="width:148px" %)基于反馈不断迭代|(% style="width:1146px" %)对用户要求、服务交付和评估、服务使用过程以及用户体验的其他方面的所有更改，均应进行测试，并根据用户反馈进行持续审查。 应鼓励用户提供反馈，反馈的后续行动对用户社区应该是透明的。
4021		-|(% style="width:148px" %)合作并提高知名度|(% style="width:1146px" %)在需要联合运营的情况下，用户应了解协作的要求并相互帮助，服务提供商、合作伙伴和供应商以及其他相关方也同样如此。 如果服务无法按预期运行，或者用户不知道如何使用服务，则应安全，轻松并鼓励其寻求帮助或报告事件。
4022		-|(% style="width:148px" %)全面思考和工作|(% style="width:1146px" %)服务及其在价值共创中的作用应对所有相关方透明可见。 用户应了解其工作和依赖项的背景。
4023		-|(% style="width:148px" %)保持简单实用|(% style="width:1146px" %)用户界面和所有其他接触点应尽可能简单。 用户应具有提出改进界面的方法，并且应该认真透明地对待这些提议。
4024		-|(% style="width:148px" %)优化和自动化|(% style="width:1146px" %)用户体验的持续优化和自动化应该是用户和服务提供商之间所有接触点和服务交互的主题。
4025		-
4026		-为了帮助用户和客户变得更好，服务提供者可以考虑使用以下技术：
4027		-
4028		-* 根据角色向特定的用户组、角色和用户特征提供有针对性的用户培训。
4029		-* 考虑将培训重点放在用户的需求而不是产品上。
4030		-* 向用户和客户介绍服务提供者工作中令人兴奋的方面，并强调合作与协作的机会。
4031		-* 促进负责任的服务使用，尤其是在消费需要大量资源或收费基于数量或时间的情况下。
4032		-* 在早期阶段让用户和客户参与服务更改的讨论，以收集反馈并确保参与。
4033		-* 创建一个舒适的环境，使用户可以放心地报告问题和提出问题。
4034		-* 邀请用户和客户提出改进服务关系的方法，包括界面、过程和服务。
4035		-* 建立并支持用户社区，并在适用时让多个服务消费者参与。
4036		-* 让超级用户帮助其他人采用新服务。
4037		-
4038		-这些方法大多数都适用于服务过程中的几个步骤，包括引入。
4039		-
4040		-
4041		-服务消费者组织可以考虑使用以下技术来帮助其服务提供者进行改进：
4042		-
4043		-* 邀请服务提供者的团队直接观察服务消费者的业务。
4044		-* 让参与服务提供的所有团队参与其中，并演示如何使用服务以及它们如何影响服务消费者的业务。
4045		-* 尽早使服务提供者参与有关组织、流程和技术的相关更改的讨论。
4046		-* 提供有关服务关系各个级别的反馈，并提供公众评论以促进跨组织的用户社区。
4047		-* 与服务提供者组成联合专家团队。
4048		-
4049		-当在组织中共享和支持所有方法，并且持续改进时，所有方法都可以更好地发挥作用。
4050		-
4051		-
4052		-|(((
4053		-**ITIL的故事：提升共同能力**
4054		-
4055		-[[image:1639050424360-458.png||height="43" width="39"]]//Mariana：eCampus Car Share运行了最初的几个月后，我们引入了游戏化。当顾客取车时，他们希望汽车清洁并充满电。我们要求客户在取车时给他们的车辆进行星级评价。这些评分被赋予前一个驾驶员的个人资料。//
4056		-
4057		-[[image:1639050433804-264.png||height="43" width="37"]]//Radhika：驾驶员获得的积分越多，他们在排行榜上的地位就越高，对于一直获得五星级评价的任何人，抽奖可在下次预订时提供折扣。//
4058		-
4059		-[[image:1639050451730-405.png||height="49" width="36"]]//Solmaz：这不仅使我们的客户受益，而且有助于我们确保每次预订后都对汽车进行清洁和充电。这为我们节省了一些维护成本，最重要的是，它支持出色的客户体验。//
4060		-)))
4061		-
4062		-== 7.9 撤销客户与用户 ==
4063		-
4064		-与引入类似，应将撤销的动作和职责预先定义为产品和服务设计的一部分，然后针对特定的引入/ 撤销计划进行调整。当两个服务都由同一服务提供者管理时，此方法有效。这类示例诸如，用户在组织中的位置发生了变化，这可能导致用户使用的服务范围的变化。
4065		-
4066		-
4067		-撤销的重要问题包括信息安全和资产管理。重要的是要确保外来用户没有特定的访问权限，并且必须安全地存储他们的创建、使用或有权访问的信息，并且仅对授权用户可用。同样，重要的是要确保先前包含在服务提供中的物理和数字资产在用户撤销后，得到正确地归档、重用、撤回或以其他方式处理。软件许可证或个人设备，例如笔记本电脑和移动电话，就是需要适当撤销的示例。
4068		-
4069		-
4070		-变更使能、信息安全管理、IT资产管理和服务配置管理实践对成功撤销至关重要。如果相关，还可能需要其他实践。组织变革管理实践可能会支持大规模的撤销。
4071		-
4072		-
4073		-撤销计划应按照与引入计划相同的原则进行审查，并应改善服务关系的相同领域。
4074		-
4075		-
4076		-当服务消费者因不满意或纠纷而离开时，确定原因很重要。在这些情况下，在无冲突的环境中流程的每个步骤都已商定时，同意并准备好撤销以确保无缝的撤销就尤为重要。此外，双方应注意不要加剧任何冲突或对任何其他方造成伤害；他们应同意对争端保密。当预期将采取后续法律行动时，这一点尤其重要。
4077		-
4078		-
4079		-=== 7.9.1 客户撤销 ===
4080		-
4081		-当服务协议期满或终止时，由服务提供者执行客户撤销。撤销动作通常包括：
4082		-
4083		-* 与所有相关的利益相关者，包括用户、客户、相关的合作伙伴/供应商和监管机构，就计划的服务终止进行沟通
4084		-* 响应任何要求进一步信息或其他支持的用户
4085		-* 组织和执行从服务消费者到服务提供者的设备移交
4086		-* 删除服务消费者场所中一直在运行的任何服务提供者资源
4087		-* 撤消任何一方对另一方资源的访问权限（如果适用）
4088		-* 存档和保留记录
4089		-* 计算和处理退出付款，包括双方未偿还的金额
4090		-* 更改与终止的服务相关的第三方合同，例如支持技术服务、保险等
4091		-* 保留双方同意和/或适用法规要求的正式撤销记录
4092		-* 执行与处境相关的关系管理动作，例如闭门会议、感谢信、恢复服务关系的邀请等。
4093		-
4094		-这些操作适用于大多数客户撤销场景。具体操作取决于服务的性质以及撤销计划的范围。有些操作由服务提供者或服务消费者执行，而有些可能需要协作。这些通常在引入步骤中事先约定，但可能需要在撤销开始之前进一步鉴证。
4095		-
4096		-
4097		-撤销的一种更复杂的现代方法是服务提供者之间的合作，其中包括相互的撤销协议。在这些情况下，新的服务提供者将服务消费者替换为旧的服务提供者。这是很常见的，因为在提供商之间进行切换是很普遍的，并且受到法律的监管。
4098		-
4099		-
4100		-切换服务提供者可能涉及第三方；例如，共享基础架构的提供者既充当新服务提供者又充当旧服务提供者。
4101		-
4102		-
4103		-表7.9 提供者切换操作示例
4104		-
4105		-(% style="width:817px" %)
4106		-|**服务管理的维度**|(% style="width:527px" %)**切换操作示例**
4107		-|组织和人员|(% style="width:527px" %)(((
4108		-更改用户访问权限
4109		-
4110		-更改服务提供者的访问权限
4111		-)))
4112		-|价值流和流程|(% style="width:527px" %)(((
4113		-更改共同行动的责任
4114		-
4115		-更改程序和接口
4116		-)))
4117		-|信息和技术|(% style="width:527px" %)(((
4118		-频道切换
4119		-
4120		-设备安装和卸载
4121		-
4122		-系统集成
4123		-
4124		-记录存档
4125		-)))
4126		-|合作伙伴和供应商|(% style="width:527px" %)与服务提供者和服务消费者的供应商和合作伙伴终止、切换和建立合同
4127		-
4128		-关于切换提供者的撤销动作类似于服务终止操作；它们应该涵盖表7.9中概述的所有服务管理四维模型。
4129		-
4130		-
4131		-许多ITIL 管理实践都支持撤销，包括：
4132		-
4133		-* 变更使能
4134		-* 部署管理
4135		-* 基础设施和平台管理
4136		-* IT资产管理
4137		-* 发布管理
4138		-* 服务配置管理
4139		-* 服务级别管理
4140		-* 软件开发和管理。
4141		-
4142		-大规模的撤销和切换计划可能需要组织变革管理和项目管理实践来协调撤销动作，并确保所涉及的组织成功实施了变更。
4143		-
4144		-
4145		-=== 7.6.2 用户撤销 ===
4146		-
4147		-用户撤销可能是正在进行的服务关系的一部分，而没有服务或合同终止。常见的示例是用户从服务消费者组织辞职或在组织内的职位变化。这些场景应该在客户引入期间预先约定，并根据此方法进行处理（通常作为标准更改）。但是，在某些情况下，例如大规模撤销，可能需要额外的规划和协调。
4148		-
4149		-
4150		-用户撤销通常包括：
4151		-
4152		-* 沟通计划中的撤销和用户的相关职责
4153		-* 与用户互动，以获取有关计划撤销的更多信息或任何其他支持
4154		-* 组织从用户到服务提供者或服务消费者负责代表的设备移交
4155		-* 更改或取消用户的访问权限
4156		-* 通过归档和保留来保护记录
4157		-* 删除未归档的信息
4158		-* 维护双方同意和/或适用法规要求的正式撤销记录
4159		-* 执行关系管理操作，例如闭幕会议、撰写感谢信等。
4160		-
4161		-正式程度取决于服务关系。例如，当服务提供者位于服务消费者组织内部时，正式程度可能会较低，并且服务消费者代表（例如用户的经理）可能会执行某些操作。
4162		-
4163		-
4164		-随后，撤销应该使用户感到舒适。服务提供者致力于使撤销动作自动化，并最大程度地降低其对所有相关方的日常业务基础的影响。
4165		-
4166		-
4167		-|(((
4168		-**ITIL的故事：撤销客户和用户**
4169		-
4170		-[[image:1639050583142-272.png||height="43" width="47"]]//Mariana：最初，我们预计完成最后一年学习的学生会希望自动退订eCampus Car Share。但是，我们的商业活动模式表明，很多学生选择保留自己的会员资格，这通常是在他们选择继续学业或加入教职员工的情况下。因此，我们不得不重新考虑我们的计划以自动撤销客户。//
4171		-
4172		-[[image:1639050597268-890.png||height="47" width="38"]]//Radhika：我们还发现，学生通常希望在每个学年结束时取消其会员资格，以节省每月的订阅费用。但是，当他们注册第二年时，他们不想再次完成教学视频。//
4173		-
4174		-[[image:1639050583142-272.png||height="43" width="47"]]//Mariana：我们为学生提供了将其会员级别变更到无需每月订阅费用级别的可能。这意味着他们更有可能保留其会员资格，也意味着他们在整个夏季继续接受我们的营销。在新学期开始时，学生可以再次变更其会员级别。//
4175		-
4176		-[[image:1639050610825-462.png||height="53" width="37"]]**S**//olmaz：撤销流程的一部分包括向我们的客户贷记所有剩余的会费。通过使流程自动化，我们不需要花费时间手动释放费用。//
4177		-)))
4178		-
4179		-== 7.7 总结 ==
4180		-
4181		-为了从协议发展到服务提供和消费，各方必须经历一种过渡，其中涉及服务提供者和服务消费者资源的整合或分离。应将此方法定义为服务设计的一部分，并且应该相应地计划、运行和控制引入或撤销活动。引入的主要活动包括建立用户关系、协调全渠道访问，使用户能够使用服务以及提升彼此的能力。
4182		-
4183		-
4184		-= 8. 步骤6：价值共创 =
4185		-
4186		-[[image:1639050669254-786.png]]
4187		-
4188		- 培育服务意识
4189		-
4190		- 正在进行的服务交互
4191		-
4192		- 培育用户社区
4193		-
4194		-当各方准备好交付和使用服务时，旅程的下一步便开始了。它可以说是最重要的；前面的所有步骤都旨在使之成为可能，并确保其取得成功。
4195		-
4196		-此步骤的目的是让参与服务关系的人员共同行动，以确保基于商定的服务产品持续共同创造价值。
4197		-
4198		-服务提供和消费步骤的范围包括：
4199		-
4200		-* 服务的交付和支持
4201		-* 服务的消费
4202		-* 服务的使用。
4203		-
4204		-此步骤是否成功取决于所有利益相关者共享基本原理并采用服务意识的能力。表8.1概述了服务提供和消费的目的。
4205		-
4206		-表8.1 服务提供的用途和消耗量
4207		-
4208		-|**价值共创**|**对于服务消费者**|**对于服务提供者**
4209		-|(% colspan="1" rowspan="7" %)促进成果和体验|最大限度提升服务消费和服务关系的实际成果|提升客户和用户的忠诚度
4210		-|通过正确的消费方式提升用户和客户功能的体验|最大化服务提供和服务关系的结果
4211		-|通过有效的协作提升用户和客户的情感体验|通过反馈和事实瞬间为持续改进获取有价值的输入
4212		-|通过有效的协作获得的经验|
4213		-|提高外部利益干系人满意度|提高员工的满意度
4214		-|提高员工的满意度|提高生产效率
4215		-|提高生产效率|
4216		-|(% colspan="1" rowspan="3" %)优化风险和合规性|通过调整对标和符合实际的期望来降低价值流失的风险|降低影响服务质量的事件及相关中断的发生概率
4217		-|通过响应性支持和以价值为导向的服务改进优先顺序，降低服务质量反复出现偏差的风险|通过忠诚度“信用”提升用户对服务质量偏差的容忍度
4218		-|通过有效的沟通和协作降低信息丢失的风险|
4219		-|优化资源和降低成本|(((
4220		-减少因服务质量下降而造成的损失
4221		-
4222		-优化服务消费成本
4223		-)))|(((
4224		-优化服务提供的运营成本
4225		-
4226		-降低用户支持成本
4227		-)))
4228		-
4229		-== 8.1 培养服务意识 ==
4230		-
4231		-重要的是参与服务提供和消费活动的人员必须以负责任的态度行事，考虑他人的利益，并专注于商定的服务结果。这被称为“ 服务同理心”，该术语通常用于用户支持的狭窄背景以及与服务提供者的支持代理相关的服务交互，但应扩展到整个服务旅程。
4232		-
4233		-|(((
4234		-**定义：服务同理心**
4235		-
4236		-识别、理解，预测和规划利益、需求、意图及经验的能力，以便建立、维持和改善服务关系。
4237		-)))
4238		-
4239		-服务同理心是组织的一项重要能力也是服务管理者的一项重要技能。服务支持代理不需要分担用户的挫折感，但希望得到认可和理解，表达同情，并相应调整自己的支持行动。
4240		-
4241		-服务同理心的重要程度取决于关系的密切程度。成功的伙伴关系相比基础的关系更为关键。
4242		-
4243		-对于合作关系的成功而言，它比基本的关系更为关键。
4244		-
4245		-服务同理心是服务意识的要素，但不是唯一的要素。服务意识还包括驱动组织行为的共同原则并定义其对服务关系和其他相关方的态度。
4246		-
4247		-|(((
4248		-**定义：服务意识**
4249		-
4250		-组织文化的一个重要组成部分，它定义了组织在服务关系中的行为。服务意识包含包括组织采用和遵循的共同价值观和指导原则。
4251		-)))
4252		-
4253		-服务意识包含以下值和原则：
4254		-
4255		-* 了解你的客户/ 用户
4256		-* 了解客户/ 用户期望
4257		-* 专注于客户价值
4258		-* 承担责任
4259		-* 表现出同理心
4260		-* 承认并适应文化
4261		-* 鼓励协作
4262		-* 慷慨大方
4263		-* 表现出独创性，包括有智慧的不服从
4264		-* 永远不要有不道德的行为。
4265		-
4266		-参与服务旅程可见性前期阶段的人员通常具备管理服务关系，并表现出良好人际交往的技能、服务同理心和有效的沟通。然而，在共同创造阶段，参与持续服务提供和消费的人可能不会分享这种服务意识。
4267		-
4268		-=== 8.1.1 适用于服务提供的服务意识 ===
4269		-
4270		-所有参与服务提供的人都应该分享服务意识。指导原则应该指导专业行为的所有方面。表8.2列出了可能有助于培养服务意识的关键问题，并提供了有助于提高相关能力的方法示例
4271		-
4272		-表8.2 服务提供者中的服务意识组织
4273		-
4274		-|**ITIL指导原则**|**关键问题**|**学习和开发方法的示例**
4275		-|(% rowspan="4" %)聚焦价值|谁是潜在客户？|服务消费者的业务简介（可能的情况下，拜访服务消费者的场所）
4276		-|他们如何从服务中感知价值？|用户支持简介（可能的情况下，参与用户支持活动）
4277		-|客户期望什么样的体验？|服务架构及其依赖关系的简介
4278		-|如何让全员为价值共创做出贡献？|
4279		-|(% rowspan="4" %)从你所处的地方开始|服务消费者的背景和历史是什么？|服务架构及其依赖关系历史和背景说明应作为客户导入和新员工入职培训的一部分的
4280		-|服务消费者以前使用过什么产品和服务？|在适用的情况下，进行包容性和特殊的需求认知的培训
4281		-|服务消费者还留有哪些产品或关系？|服务架构及其依赖关系历史和背景说明应作为客户导入和新员工入职培训的一部分的
4282		-|用户有什么特别的需求和需求期望？他们之前的需求是如何被满足的？|
4283		-|(% rowspan="4" %)基于反馈迭代推进|用户和服务提供者之间的关键时刻、接触点和服务的交互点分别是什么？|对反馈收集和处理方法进行培训
4284		-|用户服务动作是什么？如何收集有关它们的反馈？|认知和改进点入门的实践培训
4285		-|提供反馈后，处理反馈的程序是什么？|对处理负面反馈和有效的沟通技巧进行培训
4286		-|如何将反馈纳入持续改进和其他领域？|
4287		-|(% rowspan="7" %)协作和提升可视化程度|在和服务消费者的服务关系中的可视化在哪里呈现？什么是大家一起做的？|在适用的情况下，与用户/客户共同培训和其他活动
4288		-|在共同活动中，谁承担负责人的角色？|服务架构及其依赖关系的简介
4289		-|如何将共同和可见的活动进行可视化？需要使用哪些工具来体现进度？|介绍报告系统，分析面向服务消费者的报告，报告结果与员工的职责范围进行映射
4290		-|客户和用户可以看到哪些指标？|
4291		-|他们需要查看哪些指标？|
4292		-|用户和/或客户应采取哪些决策和行动？|
4293		-|服务关系的文化背景是什么？|
4294		-|(% rowspan="4" %)(((
4295		-
4296		-
4297		-通盘思考和工作
4298		-
4299		-
4300		-)))|服务如何为服务消费者的活动和目标提供整体贡献？|服务架构及其依赖关系简介
4301		-|我们组织中的哪些团队参与了服务关系？|服务消费者的业务简介（可能的情况下，拜访服务消费者的场所）
4302		-|涉及哪些供应商关系和合作伙伴？|介绍报告系统，分析面向服务消费者的报告，报告结果与员工的职责范围进行映射
4303		-|信息如何在各种价值流中流动？信息如何在服务消费者，合作伙伴和供应商之间进行交换？|
4304		-|(% rowspan="4" %)保持简单实用|用户和客户可以使用哪些界面？用户旅程是什么样的？|体验用户旅程
4305		-|用户和客户对服务交互的满意度如何？|服务架构的培训
4306		-|每个决策将如何影响用户体验？|如果适用，为服务提供者的团队提供简化的用户培训
4307		-|如果有体验改进机会点，如何实现？|将意识/培训纳入组织的持续改进实践中
4308		-|(% rowspan="4" %)(((
4309		-
4310		-
4311		-优化和自动化
4312		-)))|哪些服务行为可纳入服务提供和消费执行部分？|如果适用，为服务提供者的团队提供简化的用户培训
4313		-|是否有可以优化的服务操作？|服务架构及其依赖关系简介
4314		-|是否有可以自动执行的手动服务操作？|将意识/培训纳入组织的持续改进实践中
4315		-|改进的机会点如何实现？|如果适用，为服务提供者的团队提供简化的用户培训
4316		-
4317		-|(((
4318		-**关键信息**
4319		-
4320		-不仅是直接面向用户服务的提供商需要具备服务意识。对于提供基础设施，平台，环境和其他服务 并且无直接用户的组织来说同样重要。
4321		-)))
4322		-
4323		-=== 8.1.2 适用于“隐形”用户的服务 ===
4324		-
4325		-服务关系可能涉及服务提供者和服务消费者之间以各种资源组合的服务交互。人员，技术，流程和第三方都可能相互作用。在某些情况下，这些服务交互不涉及用户，该服务以其他维度作为提供给服务消费者的资源。包含如下示例：
4326		-
4327		-* 平台和基础设施即服务。服务提供者的技术资源被服务消费者的技术资源所使用。
4328		-* 服务消费者的IoT设备与服务提供商平台进行通信。
4329		-* 工作时间以外进行办公室的清洁工作。服务提供商的工作人员清洁服务消费者的工作空间，通常与在办公室工作的人员无任何互动。
4330		-* 街道清洁。
4331		-* 审计服务。
4332		-
4333		-这些示例表明，人们可能代表服务消费者组织进行沟通，但是他们不充当用户。通常，这些人被授权为用户代表并代表他们与服务提供商进行交互。
4334		-
4335		-有时，缺乏人与人之间的互动会导致服务提供者仅专注于技术和其他非人力资源。这导致缺少聚焦价值和服务与服务消费者的需求不一致。同样重要的是在提供专业基础设施，平台，环境和其他服务且没有直接用户但影响人们工作和生活的组织之间培养和维护一种服务意识。
4336		-
4337		-服务提供者与用户之间几乎没有人为接触时，重要的是监测和度量关键的服务质量和体验指标，并分析反映用户体验的趋势和模式。服务绩效透明度是关键; 服务供应商和消费者可以从分享服务体验信息的见解中获益，在理解的基础上投入资源进行合作。从本质上讲，他们都将理解信息在服务质量方面的意义，可能会影响价值共创。
4338		-
4339		-=== ​​​​​​​8.1.3 适用于服务消费的服务意识 ===
4340		-
4341		-服务是价值共创的一种手段。价值不能简单地交付；它需要服务消费者的积极参与。如果用户正在使用服务，他们的能力，态度和文化使他们成为价值共创的重要因素。
4342		-
4343		-因此，重要的是确保参与服务消费的所有个人共享服务意识，而不只是服务提供者的团队。都共享一个服务意识。指导原则应该指导职业行为的各个方面。表8.3说明了有助于培养服务意识的关键问题并提供了有助于培养相关能力的方法示例。
4344		-
4345		-服务消费者组织中的表8.3 服务意识
4346		-
4347		-|**ITIL指导原则**|**关键问题**|**学习和开发方法的示例**
4348		-|(% rowspan="7" %)聚焦价值|这项服务的用途是什么？预期的结果和价值是什么？|意识培训：向所有人介绍运营模式，关键价值流以及在
4349		-|期望的服务体验是什么？|组织中服务的角色
4350		-|还有什么有助于预期的结果？服务如何与其他服务和|
4351		-|组织的资源进行交互？|
4352		-|是否存在相互矛盾的利益干系人要求？|
4353		-|客户（或服务提供者）在代表他们感兴趣的领域有多|
4354		-|优秀？|
4355		-|(% rowspan="3" %)从你所处的地方开始|是否还有其他方法可以实现这些结果？|定期召开跨团队会议，同步并保持对当前状态及
4356		-|他们是否被证明有效吗？|其背景知识管理的共同理解，包括获取有关组织
4357		-|在开发/改进服务时，应从当前和之前的实践和关系中保留哪些内容？|实践和经验教训的信息
4358		-|(% rowspan="4" %)基于反馈迭代推进|如何向服务提供者提供反馈？|相关可用反馈渠道的在线和离线信息
4359		-|如何从服务提供者和其他利益干系人处获得反馈？|关键用户和客户与服务提供商的定期会议
4360		-|如何确保反馈的处理进度？|例如测试和培训的联合活动，特别是在服务变更时
4361		-| |组织持续改进实践相关的意识培训和视觉信息
4362		-|(% rowspan="7" %)协作和提升可视化程度|用户和顾客在服务消费过程中的责任是什么？|为用户提供实用且最新的知识库，包括视觉辅助工具、
4363		-|是否满足要求？是否遵循约定的服务消费规则？|联合培训和关键服务行动的演练
4364		-|在与服务提供商的服务关系中，可见性范围在哪里？|服务同理心/融洽的合作培训
4365		-|如何参与服务提供商的联合活动？|采用工作可视化工具（如看板）
4366		-|如何将合作、公开的活动可视化？|了解支持渠道和可用的支持选项（通过培训，视觉材料
4367		-|需要使用哪些工具来展示进度（如看板）？|和知识库）
4368		-|服务提供商应该涉及哪些决策和行动？| 明确在不同情况下服务提供商可以与谁取得联系
4369		-|(% rowspan="3" %)(((
4370		-
4371		-
4372		-通盘思考和工作
4373		-
4374		-
4375		-)))|服务消费者的背景是什么？它如何助推组织的目标和服务消费者的业务？|意识培训：向所有人介绍运营模式，关键价值流以及在组织中服务的角色
4376		-|(((
4377		-服务的消费如何整合到价值流中？
4378		-
4379		-如何改进/优化服务的角色以增加其价值？
4380		-)))|说明和解释组织变更对服务架构和关系的影响
4381		-|消费服务时应考虑哪些依赖关系？|
4382		-|(% rowspan="2" %)保持简单实用|使用服务的最佳方法是什么？|了解支持渠道和可用的支持选项（通过培训，视觉材料
4383		-|如果有体验改进点机会，该如何启动？|和知识库）
4384		-|(% rowspan="4" %)(((
4385		-
4386		-
4387		-优化和自动化
4388		-)))|哪些服务的动作可以作为服务消费的部分?|组织持续改进实践相关的意识培训和视觉信息
4389		-|是否有可以优化的服务操作？|持续改进的激励计划，聚焦改进措施的价值
4390		-|是否有手动服务操作可以自动执行的？|
4391		-|如果有改进机会点，该如何启动？|
4392		-
4393		-== 8.2 进行中的服务交互 ==
4394		-
4395		-向用户提供服务有不同的方法。最常见的选项包括：：
4396		-
4397		-* **拉动或推送**服务动作可由用户发起，例如拉动。这种情形包括当用户在服务门户上请求服务，下载应用程序，呼叫服务台等。它们也可以由服务提供者发起，如推送。例如，用户可以每月获得一份报告作为订阅的一部分，或者服务提供商可以在新版本可用时自动更新用户设备上的软件。
4398		-* **自动或手动**服务操作的启动和实现可以通过不同的方式实现自动化：
4399		-** **无技术**服务提供不涉及技术
4400		-** **技术辅助**技术是用来支持服务提供商提供服务的。例如，服务台代表可以使用信息系统来登记和管理来自用户的请求
4401		-** **技术推动**在部分服务提供过程中服务提供商和用户可以使用相同的技术。例如，当服务台代表和用户讨论问题时可以使用远程访问软件来接管用户的屏幕。
4402		-** **技术中介**消除了服务提供商和用户之间服务提供时的物理距离。例如，用户可以通过短信与服务提供商沟通。
4403		-** **技术产生**服务提供商，服务消费者或双方完全由技术代替。示例包括自服务，聊天机器人，自动向服务提供商请求更多存储的服务消费者应用程序等。
4404		-* **定制或开箱即用**用户和服务提供商之间的交互可以针对所有用户或大部分用户进行标准化或者根据单个用户或小部分用户的需求和偏好进行调整
4405		-* **直接或间接**服务提供商可以使用自身资源和员工或通过代理与用户进行交互。例如，机场代理经常被用来代表航空公司为旅客办理登机手续。通常使用机场代理人代表航空公司办理旅客登机手续。服务消费者还可以代表服务提供商提供服务。例如，客户已与外包公司达成服务协议，但服务消费者的服务台仍为用户提供服务。如图8.1所示。
4406		-
4407		-(% style="text-align:center" %)
4408		-[[image:1639051060438-209.png]]
4409		-
4410		-图片8.1常见的服务技术类型
4411		-
4412		-这些方法被定义为服务架构和设计的一部分，在旅程的早期步骤中达成一致，并在共同创建步骤中得到应用。它们对用户体验有重要的影响；它们在用户体验上具有重要的影响力；服务提供者和服务消费者应在旅程开始阶段就考虑到这种影响。服务提供者和服务消费者应该从开始就考虑使用影响力。
4413		-
4414		-根据服务架构，服务消费者和服务提供者组织之间的服务交互可能包括：
4415		-
4416		-* **联合活动 **单独或共同执行作为服务约定部分的服务动作
4417		-* **服务提供活动：**
4418		-** 提供对约定资源的访问，并将这些资源用作为服务的一部分
4419		-** 提供和消费双方约定的货物
4420		-** 将服务提供涉及的资源的可用性，性能和其他品质特征维持在约定级别
4421		-** 记录，报告，检测和解决事件
4422		-** 记录，处理和履行服务请求
4423		-** 记录和处理投诉和表扬
4424		-** 受理和处理其他用户查询
4425		-** 收集并处理服务质量相关的数据，向利益相关者提供监控信息
4426		-** 在适用的情况下，对提供的服务开具发票。
4427		-
4428		-* **服务消费活动：**
4429		-** 访问和使用作为服务组成的资源和商品
4430		-** 执行服务动作
4431		-** 发起服务请求
4432		-** 提出投诉和表扬
4433		-** 提出其他用户查询
4434		-** 在约定的情况下报告偏差和事件
4435		-** 在适用的情况下为提供的服务支付费用。
4436		-
4437		-重要的是各方理解并塑造在可见的范围内执行活动，但他们也需要对双方的不可见活动进行管理。
4438		-
4439		-在大多数情况下，此步骤中服务消费者组织由用户代表或者其授权的代表。他们通常在服务旅程开始前就服务消费过程中的角色和用户及其代表沟通并达成一致。还包括资格标准、使用规则、安全要求、责任等。
4440		-
4441		-在服务旅程的这个阶段的活动服务提供者组织可以由各种角色代表。有些角色直接与用户打交道（服务台代理，支持专家和为用户或与用户执行服务操作的任何专家）；某些角色专注于服务提供商或服务消费者的各种资源，但可能偶尔与用户产生互动（执行服务维护或服务支持或作为服务提供的一部分处理服务消费者资源的技术专家）。在后一种情况下，重要的是要确保这些专家分享服务意识并专注于服务消费者的价值和可靠的用户体验。
4442		-
4443		-=== ​​​​​​​8.2.1 服务请求 ===
4444		-
4445		-在多数情况下，满足服务请求对于价值共同创造的成功非常重要。
4446		-
4447		-|(((
4448		-**定义：服务请求**
4449		-
4450		-由用户或用户授权代表提出的请求，该请求已被同意作为服务交付的正常部分。
4451		-)))
4452		-
4453		-某些服务请求旨在增强服务的价值并支持服务消费者的业务活动。它们由用户根据需求按照服务消费者流程自行启动。
4454		-
4455		-这些请求通常说明由服务提供商履行的服务操作，包括信息请求，对资源的访问和货品传输。
4456		-
4457		-其他服务请求是用户的责任之一，为了使服务与协议保持一致而被启动。这些通常包括用户启动的维护和支持行动；如未能启动这些操作可能导致诸如服务降级或中断之类的事件。
4458		-
4459		-对于所有类型的服务请求，应商定规则和条件，并传达给服务提供者和服务消费者组织中的所有相关角色。这些可能包括：
4460		-
4461		-* 发起请求的渠道和方式
4462		-* 可用的请求选项
4463		-* 职责
4464		-* 程序
4465		-* 时限范围
4466		-* 授权（例如，安全，财务和架构/技术）
4467		-* 成本和价格
4468		-* 法律和监管要求
4469		-* 其他限制。
4470		-
4471		-服务请求管理有助于服务的成功使用。可以通过以下方式强化此规范：
4472		-
4473		-* 为用户的状况和级别访问请求量身定制的易用且交互式的服务请求目录
4474		-* 用于启动和履行服务请求的自助服务界面
4475		-* 请求履行过程中的状态更新和推送通知
4476		-* 主动沟通服务的状态，请求的可用性和新的选项
4477		-* 友好且专业的支持代理满足请求
4478		-* 尽可能通过用户首选的方式自动完成和交付
4479		-* 收集和处理反馈
4480		-* 适用于请求履行有效的工作流
4481		-* 有效的集成其他管理实践。
4482		-
4483		-通过以下ITIL实践可以成功启动，处理和实现服务请求：
4484		-
4485		-* 变更管理
4486		-* IT资产管理
4487		-* 服务目录管理
4488		-* 服务配置管理
4489		-* 服务台
4490		-* 服务级别管理
4491		-* 服务请求管理.
4492		-
4493		-在某些情况下，可以应用其他ITIL实践来支持服务请求。其中包括容量和性能管理、部署管理、信息安全管理、基础架构和平台管理以及发布管理实践。
4494		-
4495		-|(((
4496		-**关键信息**
4497		-
4498		-服务台实践的目的是为事件解决和服务请求捕获需求。对于所有用户，它也应该是服务提供者的入口和单一联系点。
4499		-)))
4500		-
4501		-=== ​​​​​​​8.2.2 服务台的相互作用 ===
4502		-
4503		-用户与服务提供商进行交互时，他们将通过服务台实践提供的专用接口或渠道进行交互。这些接口可以采用各种形式，但是它们有一个共同的目的：确保用户请求被捕获并根据服务提供者和服务消费者之间建立的协议和期望进行处理。
4504		-
4505		-服务关系要取得成功重要的关键点，服务台的界面，过程和规则必须经过双方的同意并在引入阶段就传达给所有用户。这些界面和过程应该简单，对用户友好并且易于遵循。服务台实践应该根据用户的反馈不断的持续改进，以确保获得积极的用户体验。
4506		-
4507		-服务台应该在服务提供和支持的价值流中与其他实践紧密结合，并支持价值流。这将确保用户发起的各类工单得到有效和及时的处理，并将相关信息传达给用户。表8.4列出了用于服务查询的常见分类标准以及查询处理过程中通常涉及的各个实践。这些实践应与服务台实践结合。
4508		-
4509		-表8.4 用户查询：分类准则及其处理中涉及的关键实践
4510		-
4511		-|**对准则进行分类**|**服务查询类型**|**涉及的关键ITIL实践**
4512		-|违反约定的SLA或|(% rowspan="2" %)突发事件|(% rowspan="2" %)事件管理
4513		-|用户报告的负面体验
4514		-|紧急情况发生时的约定条件或者查询正在发生的灾难|灾难|服务连续性管理
4515		-|从服务请求目录中选择有效的服务请求选项|服务请求|服务请求管理
4516		-|从用户可用的服务目录中选择了有效的变更选项|变更请求|变更启动
4517		-|用户报告的负面体验，被称为未违反任何约定的SLA（投诉）或记录的用户报告的积极体验|投诉与表扬|关系管理
4518		-|用户的建议改进项未被可用的服务目录所覆盖。（包括服务请求目录）|改进建议|持续改进
4519		-|用户报告可能表明信息安全受到威胁的可疑活动或事件|可疑活动和事态|信息安全管理
4520		-
4521		-对于传入查询的分类和优先级划分，应该有一致的规则。用户在处理查询时应该知道约定的时间范围。这取决于以下因素：
4522		-
4523		-* 查询类型
4524		-* 查询时间和日期
4525		-* 联络渠道
4526		-* 服务/资源
4527		-* 服务级别/ 用户
4528		-* 影响
4529		-* 预计解决时间
4530		-* 其他约定因素。
4531		-
4532		-用户还应随时了解其查询过程的进度、估计处理时间的变化以及其他重要信息。这些更新应通过约定的渠道提供。
4533		-
4534		-=== ​​​​​​​8.2.3 当事情出错时 ===
4535		-
4536		-当提供或使用服务时，可能会发生事件和不满意情况。创建完美的服务体验可能会很困难，即使不是不可能。然而，处理不满和事件很重要。服务提供商应对事件和投诉做好准备；在可见范围内操作的每个团队，即使不直接与用户打交道，也应该知道如何解决这些情况。
4537		-
4538		-采用服务意识（包括服务同理心）对于将问题转化为提高服务和用户忠诚度与信任的机会非常重要。遵循ITIL 指导原则，服务提供者可以通过以下方式管理投诉和事件：
4539		-
4540		-* 聚焦价值和价值共创的快速恢复
4541		-* 收集并提供反馈
4542		-* 与受影响的用户透明，诚实地沟通
4543		-* 表现出理解和同理心
4544		-* 保持互动和建议简单实用
4545		-* 适当情况下，练习智能违抗。
4546		-* 以下ITIL惯例可有效地处理事件和不满事件解决：
4547		-* 持续改进
4548		-* 事件管理
4549		-* 知识管理
4550		-* 关系管理
4551		-* 服务台
4552		-* 服务请求管理
4553		-
4554		-将这些实践集成到用户支持价值流中有助于确保有效的沟通、正常服务的快速恢复、减少误解以及改进交互渠道和过程。
4555		-
4556		-=== ​​​​​​​8.2.4 关键时刻 ===
4557		-
4558		-关键时刻是服务提供者和用户之间的关键接触点或服务交互，用户在其中形成或改变他或她对服务体验、服务组织、产品或服务全方面的印象。
4559		-
4560		-关键时刻可能来自积极和消极的事件。尽管每个服务交互或接触点都是潜在的关键时刻，但并非所有的服务交互和接触点都是一个关键时刻。关键时刻是服务交互和接触点，它们构成或破坏了特定用户的服务体验。
4561		-
4562		-因此，服务提供者应该意识到潜在的关键时刻。服务提供商组织应该拥有做出正确决策和提供正确服务的资源和能力。
4563		-
4564		-从本质上讲，服务提供者应该考虑将负面事件转化为积极的关键时刻。
4565		-
4566		-=== ​​​​​​​8.2.5 智能违抗 ===
4567		-
4568		-智能违抗是为了做正确的事情而违反规则的行为。就服务关系而言，感知优势通常包括熟悉度、直接参与服务或了解用户或客户需求等因素。这些知识是有价值和有益的。
4569		-
4570		-智能违抗在我们的日常生活中是简单而普遍的，在大多数情况下，它是有益的和真实的。轻微的智能违抗对改进我们的生活经常被受到赞赏；例如，一个商店经理延迟关门，让顾客完成购物。
4571		-
4572		-在现有规则无法帮助或不合理的情况下，总会有意料之外的问题需要处理。在这种情况下，服务体验取决于与客户和用户交互的工作人员，他们正确地评估是应该遵守规则还是暂停规则。这意味着，为了最大限度地为客户提供价值，服务提供者应该：
4573		-
4574		-* 认识到当前的规则并不是一直适合的
4575		-* 鼓励和培养员工的知识和技能以识别合理的客户要求并感知和满足这些要求
4576		-* 创建一个环境，使员工有信心在情势要求的情况下不遵守规则行事
4577		-* 确保行动被记录用于改进规则和对未来的理解。
4578		-
4579		-对于某些规则不适当的情况智能违抗是一种有价值的工具。但是，重要的是要记住，，对任何既定情况的默认响应都应该遵循规则。当需要智能违抗的情况时，应记录操作以允许审计和控制，以便将来在必要时可以修改规则。智能违抗可以作为改进的来源，需要围绕现有规则将他们塑造成更广泛，更好的规则。显然，让员工违反规则并非没有风险。得不到保证的创新行为能提供比遵循规则更好的服务，即使这些规则对于一线员工来说是错误的。
4580		-
4581		-在某些环境中，例如受到严格监管和合同约束的环境，可能很难说服服务提供商的员工违反规则以做正确的事情。人们可能会担心不合规和情况升级到组织的更高级别。如果在这些环境中智能违抗是可取的，则程序和合同应明确允许存在的偏差并提供清晰的流程以供学习。
4582		-
4583		-=== ​​​​​​​8.2.6 客户和用户反馈 ===
4584		-
4585		-客户和用户的反馈对于服务关系的成功和服务的持续改进非常重要。服务提供者对关于他们的服务以及相关的用户和客户体验等方面公开，直接和全面的意见有兴趣。然而，许多用户和客户都不情愿提供公开和诚实的反馈。这种不情愿通常与过去的负面体验有关。
4586		-
4587		-服务提供商的一项重要任务是收集和处理有效的反馈。表8.5提供了可以帮助完成此任务的思路总结。
4588		-
4589		-表8.5 客户和用户持续反馈的挑战与解决方案
4590		-
4591		-|**利益相关者提供反馈**|**挑战**|**服务提供者应用的可能解决方案**
4592		-|(% rowspan="9" %)用户|人们不相信自己的意见会被听取并付诸行动。|建立并明确传达一个欢迎大家提出意见的策略。
4593		-|反馈渠道不方便或不可用。|单独处理所有反馈，并尽可能手动处理。不要限制对自动消息的响应。
4594		-|人们没有时间提供反馈。|维护由用户反馈发起的服务改进的最新记录；让处理进度对所有用户可见；考虑更新广告订阅。
4595		-|人们可能害怕因负面反馈而受到惩罚。|在可能的情况下，让改进发起人参与测试和实施改进。
4596		-|人们认为其他人早些时候也提供了相同的意见。|奖励积极的反馈和改进措施。在用户社区中使用游戏化（级别、数字徽章）来表扬积极的贡献者。
4597		-| |积极寻求反馈，并奖励有意义的利益参与。
4598		-| |确保反馈渠道和界面方便、安全、符合规定，并按预期工作。在联系用户之前测试所有界面和渠道。
4599		-| |监控社交媒体和用户社区。通过社交媒体提供快速和建设性的响应。
4600		-| |遵循规划、收集和处理反馈的指导原则。
4601		-|(% rowspan="7" %)顾客|客户希望服务提供商收集用户的反馈并认为这样就足够了。|建立并明确传达一个欢迎大家提出意见的策略。
4602		-|客户希望服务提供商要求反馈，而不是等待反馈。|向客户提供用户的反馈信息，并考虑将其纳入SLA报告中。
4603		-|客户没有时间反馈；有时，他们也没有时间听取用户的意见，仅根据报告来看待服务。|定期与客户进行人与人之间的反馈会议，特别是在重要接触点和关键时刻之后。
4604		-|反馈渠道不方便或不可用。|确保反馈渠道和界面方便、安全、符合规定，并按预期工作。
4605		-| |在联系客户之前测试所有界面和渠道。
4606		-| |遵循规划、收集和处理反馈的指导原则。
4607		-| |使反馈处理以各种形式对客户透明。
4608		-
4609		-|(((
4610		-**ITIL的故事：步骤6 –价值共创**
4611		-
4612		-[[image:1639051453545-874.png||height="55" width="40"]]//Radhika：服务推出后，我们发现客户的一个痛点，他们来取已经预定的车辆，结果却发现它尚未归还。我们知道这在高峰时段最常发生，但是我们不明白为什么人们经常迟到还车，或者如何确保减少这样的事情重复发生。//
4613		-
4614		-[[image:1639051462796-307.png||height="47" width="44"]]//Mariana：我们的第一个想法是对逾期归还进行罚款。但是，在我们寻求潜在解决方案之前，我们邀请了一些客户参加设计合作研讨会，以便我们能够理解和同情他们的问题。。//
4615		-
4616		-[[image:1639051472378-508.png||height="49" width="38"]]**S**//olmaz：例如，我们发现我们的客户通常不熟悉本地交通，并且会低估完成任务所需的时间。引入罚款通常不会激励及时还车。在共同创建和深入研究之后，我们正在试用告警系统，它可以通知当前和下一个乘客汽车的位置和预期的归还时间。。//
4617		-
4618		-[[image:1639051500303-603.png||height="42" width="39"]]//Katrina：很高兴能参加此次研讨会，以帮助eCampus Car Share了解和理解客户了解关于延迟还车的问题。滞纳金会让我对这项服务不太满意，因为我不可能预测交通流量。通过共同制定解决方案，我觉得自己的贡献已经得到认可，并且找到了更加公平的解决方案。//
4619		-)))
4620		-
4621		-
4622		-
4623		-== 8.3 培育用户社区 ==
4624		-
4625		-在正常操作，事件和其他困难期间，用户社区可能是服务交互的重要组成部分。同行支持、知识文章、讨论和改进计划有助于减少用户对服务提供商支持的需求，使支持更接近用户（左移），提供有价值的见解和改进机会，并有助于交流新闻和状态更新。
4626		-
4627		-在许多情况下，用户社区是自然形成的，特别是当服务被提供给许多个人和公司服务消费者时。然而，它们也可能出现在组织内部，特别是当用户感觉不到来自服务提供商足够的支持时。无论哪种方式，社区都可以成为用户和服务提供商之间交流与合作的有力手段。
4628		-
4629		-用户社区可以由服务提供者建立，并可以团结所有服务用户。它们还可以由用户小组组成，涵盖来自多个服务提供商的多个服务：例如，服务消费者组织内的社区，或特定领域的专业人员社团。在后一种情况下，服务提供者在社区中的积极参与通常比尝试将用户切换到服务提供者建立的官方社区效果更好。认识到由用户建立的社区和为用户建立的社区，以及在这些社区中有价值的参与，可以提高服务提供商的形象和用户的忠诚度。同时，请务必记住，这些社区可能对某些用户是关闭的。在这种情况下，服务提供商可以使用其他平台和渠道建立一个或多个组。当服务提供给不同的受众时，服务提供者很可能必须使用不同的平台、语言和通信方式来管理多个社区。
4630		-
4631		-在可视化的背后，这些社区可能与共享的知识库相联系，并由相同的专家团队提供支持。
4632		-
4633		-由服务提供商创建和运行的用户社区可以作为服务进行设计和管理。
4634		-
4635		-由用户小组自己创建和运营的用户社区可能会受到服务提供商代表的支持。这种参与通常通过以下ITIL实践实现：
4636		-
4637		-* 事件管理
4638		-* 知识管理
4639		-* 问题管理
4640		-* 关系管理
4641		-* 服务目录管理
4642		-* 服务台
4643		-* 服务请求管理
4644		-* 服务验证和测试。
4645		-
4646		-将这些实践整合到用户支持价值流中有助于捕获社区的问题、提供建议、建议服务和服务请求、推荐解决方案和自助服务解决方案、宣布新机遇等。
4647		-
4648		-=== 8.3.1 超级用户 ===
4649		-
4650		-许多社区和团体根据成员的活动在团体中的重要程度采用用户评级或状态系统。提供更多有用建议和意见的个人会得到某种形式的认可。小组反馈用于评估输入的有用性。这些成员被称为大师或专家，可能在社区中拥有更多的权利和权威。例如，他们可能担任社区管理员，有权主持讨论。
4651		-
4652		-如果这些组是由服务提供商建立的，则超级用户可以由服务提供商任命并参与到服务提供商的实践中。如果这些组是由客户建立的，那么角色和职责、工作流程和程序以及工具支持最好与服务提供商达成一致。如果这些小组是由用户建立的，服务提供者可能会发现与超级用户合作是有益的，为他们提供获得专家知识的机会，让他们参与内部讨论，并以其他方式提高他们在产品和服务方面的专门知识。这可能有助于超级用户发展其专业技能，并优化服务提供商用于支持用户社区的资源。
4653		-
4654		-在企业环境中，服务提供商可以识别用户小组中的超级用户，并让他们参与建立用户社区。超级用户可以参与支持、交流、培训、用户故事和需求的说明、演示、验证和测试，以改善服务提供商和用户之间的关系。建立和维护一个有效的超级用户组并不容易。超级用户很少被指派全职角色，而且通常是义务的。他们受到兴趣、愿意协助和社区认可的激励。因此，服务提供商无法在需要时依赖他们的支持。如果超级用户与客户和赞助人属于同一法律实体，则解决方案可能是在服务提供商、客户和超级用户之间签订第三方协议，为超级用户活动分配一定比例的时间，并确保在不可用期间提供备份。服务提供商还可能经常召集超级用户来告知、教育和培养他们，以增加他们对角色的投入。
4655		-
4656		-|(((
4657		-**ITIL的故事：培育用户社区**
4658		-
4659		-[[image:1639051638220-876.png||height="58" width="38"]]//Mariana：我们正在利用各种知名社交媒体网站上已建立的在线社区与现有和潜在客户进行互动。//
4660		-
4661		-[[image:1639051655927-321.png||height="55" width="37"]]//Solmaz：我们曾考虑为此创建自己的社区，但最终的决定，对于我们目前面对的受众，参与已有大量追随者的现有社区会更有价值。//
4662		-
4663		-[[image:1639051638220-876.png||height="58" width="38"]]//Mariana：与这些社区互动将有助于我们与客户建立更牢固的关系，更好地了解他们在汽车租赁服务中的需求。//
4664		-)))
4665		-
4666		-== 8.4 总结 ==
4667		-
4668		-服务消费者利用可访问的服务提供商资源，消费提供的货品，并与服务提供商基于约定的服务内容一起价值共创价值。服务意识与成熟的实践相结合能有效、无缝、巧妙的处理用户交互和偏差。是价值共创和用户体验的关键。
4669		-
4670	4670	= 9. 第7步：实现价值 =
4671	4671
4672	4672	[[image:1639051700656-416.png]]
...	...	@@ -4720,7 +4720,7 @@
4720	4720
4721	4721	跟踪、评估和评价价值实现的成本可能很高，努力和成本应该与可能的收益相平衡。与此相反，跟踪价值与任何其他服务管理活动一样，需要不断地迭代改进。通过逐步改进价值实现跟踪，并报告结果，可以显著提高价值，从而提高改进跟踪的能力。
4722	4722
4723		-== 9.1 在不同的环境下实现服务价值  ==
	361	+== 9.1 在不同的环境下实现服务价值  ==
4724	4724
4725	4725	服务关系的性质影响价值的跟踪、评估和评价。如表9.2所示。
4726	4726
...	...	@@ -4821,7 +4821,7 @@
4821	4821
4822	4822	图片9.1 ITIL 规划和评价模型
4823	4823
4824		-=== ​​​​​​​9.2.1  跟踪绩效，输出和结果  ===
	462	+=== ​​​​​​​9.2.1  跟踪绩效，输出和结果  ===
4825	4825
4826	4826	直接结果指标比间接结果指标通常更难识别，例如输出和绩效指标。如果能够在结果指标与输出和绩效指标之间建立明确的联系，后者就可以用来间接跟踪服务结果。
4827	4827
...	...	@@ -5179,7 +5179,7 @@
5179	5179	上面介绍的用于跟踪，评估和评估价值实现的方法和技术对服务提供者而言与对服务消费者一样有效。
5180	5180	)))
5181	5181
5182		-=== 9.5.2  跟踪，评估和评价成本  ===
	820	+=== 9.5.2  跟踪，评估和评价成本  ===
5183	5183
5184	5184	跟踪、评估和评估服务成本是服务财务管理程序的一部分；《服务财务管理实践指南》解决了这一问题。服务提供者应该完全了解服务成本的结构，以便对优化资源配置并支付费用。应定期重新审查成本结构和分配，以确保它们符合组织的目标以及产品和服务组合。
5185	5185