由 superadmin 于 2024/12/25, 15:29 最后修改
修改评论
该版本没有评论
Summary
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,2846 +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 3137 = 7. 步骤5:引入 = 3138 3138 3139 3139 [[image:1639049245149-501.png]] ... ... @@ -3546,8 +3546,6 @@ 3546 3546 [[image:1639049903595-695.png||height="60" width="43"]]**S**//olmaz:我们的第一批客户对引入给予了积极的反馈。新车共享客户在第一个月内致电服务台的电话,每个客户不超过两次。// 3547 3547 ))) 3548 3548 3549 - 3550 - 3551 3551 == 7.2 与用户相关并建立关系 == 3552 3552 3553 3553 由于服务提供者与服务消费者的技术和信息进行了更多的交互,因此某些服务不包括服务提供者与用户之间的广泛交互。机器对机器服务(例如IoT设备、技术微服务、信息系统维护和数据存储)是此类服务关系的示例。 ... ... @@ -3602,7 +3602,6 @@ 3602 3602 * 用户参与的服务评审和改进 3603 3603 * 仪表板和报告让用户社区可以清楚地了解服务质量。 3604 3604 3605 - 3606 3606 === 7.2.2与个人消费者一起培育关系 === 3607 3607 3608 3608 当服务消费者是个人时,有很多因素会影响服务提供者在客户旅程期间如何管理服务关系。表7.6列出了其中一些因素。 ... ... @@ -4181,7 +4181,7 @@ 4181 4181 为了从协议发展到服务提供和消费,各方必须经历一种过渡,其中涉及服务提供者和服务消费者资源的整合或分离。应将此方法定义为服务设计的一部分,并且应该相应地计划、运行和控制引入或撤销活动。引入的主要活动包括建立用户关系、协调全渠道访问,使用户能够使用服务以及提升彼此的能力。 4182 4182 4183 4183 4184 -= 1352 += 8. 步骤6:价值共创 = 4185 4185 4186 4186 [[image:1639050669254-786.png]] 4187 4187 ... ... @@ -4720,7 +4720,7 @@ 4720 4720 4721 4721 跟踪、评估和评价价值实现的成本可能很高,努力和成本应该与可能的收益相平衡。与此相反,跟踪价值与任何其他服务管理活动一样,需要不断地迭代改进。通过逐步改进价值实现跟踪,并报告结果,可以显著提高价值,从而提高改进跟踪的能力。 4722 4722 4723 -== 9.1 在不同的环境下实现服务价值 1891 +== 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 跟踪绩效,输出和结果 1992 +=== 9.2.1 跟踪绩效,输出和结果 === 4825 4825 4826 4826 直接结果指标比间接结果指标通常更难识别,例如输出和绩效指标。如果能够在结果指标与输出和绩效指标之间建立明确的联系,后者就可以用来间接跟踪服务结果。 4827 4827 ... ... @@ -5179,7 +5179,7 @@ 5179 5179 上面介绍的用于跟踪,评估和评估价值实现的方法和技术对服务提供者而言与对服务消费者一样有效。 5180 5180 ))) 5181 5181 5182 -=== 9.5.2 跟踪,评估和评价成本 2350 +=== 9.5.2 跟踪,评估和评价成本 === 5183 5183 5184 5184 跟踪、评估和评估服务成本是服务财务管理程序的一部分;《服务财务管理实践指南》解决了这一问题。服务提供者应该完全了解服务成本的结构,以便对优化资源配置并支付费用。应定期重新审查成本结构和分配,以确保它们符合组织的目标以及产品和服务组合。 5185 5185