Changes for page ITIL4核心著作 - ③ 《驱动利益相关者价值》DSV
                  Last modified by superadmin on 2024/12/25, 15:29
              
      Summary
- 
          
                      - 1639048000162-709.png
- 1639048009299-382.png
- 1639048305942-643.png
- 1639048338706-431.png
- 1639048447665-961.png
- 1639048543615-528.png
- 1639048688182-294.png
- 1639048741852-426.png
- 1639048791347-982.png
- 1639049066141-786.png
- 1639049191757-274.png
- 1639049245149-501.png
- 1639049400385-584.png
- 1639049408203-780.png
- 1639049435845-855.png
- 1639049867583-763.png
- 1639049876815-154.png
- 1639049903595-695.png
- 1639050104902-799.png
- 1639050210407-577.png
- 1639050219865-483.png
 
Details
- Page properties
- 
      - Content
-   ... ... @@ -259,11 +259,13 @@ 259 259 * **保持简单实用** 如果流程,服务,性能或指标无法提供价值或生产有用的成果,则将其消除。 260 260 * **优化和自动化** 应该充分利用所有类型的资源,尤其是HR。 261 261 262 + 262 262 == 治理 == 263 263 264 264 治理是指挥和控制组织的手段。角色和治理在ITIL SVS中的位置将根据在组织中使用SVS的方式而有所不同。 265 265 266 266 268 +(% class="wikigeneratedid" %) 267 267 == == 268 268 269 269 == 持续改进 == ... ... @@ -284,6 +284,7 @@ 284 284 * 合作伙伴和供应商 285 285 * 价值流和流程 286 286 289 + 287 287 四个维度代表了与整个SVS相关的观点,包括整个服务价值链和所有ITIL实践。四个维度受一些外部因素的约束或影响,这些因素通常超出SVS的控制。 288 288 289 289 ... ... @@ -322,6 +322,7 @@ 322 322 * 合同经理 323 323 * 客户体验/ 用户体验(UX)设计人员。 324 324 328 + 325 325 本指南假定读者熟悉ITIL Foundation,其中介绍了ITIL 4的基本服务管理概念 326 326 327 327 ... ... @@ -377,6 +377,7 @@ 377 377 * 使用服务的用户 378 378 * 为服务消费授权预算的赞助者 379 379 384 + 380 380 这些角色可以由一个或多个人员或团队来完成,通常取决于消费者组织的类型和大小。在角色分开的组织中,沟通和协调至关重要。为了在服务提供者和服务消费者之间培育有效的服务关系,有必要投入资源来协调双方。 381 381 382 382 (% style="text-align:center" %) ... ... @@ -412,6 +412,7 @@ 412 412 |(% style="width:185px" %)典型的协定类别|(% style="width:306px" %)标准合同,服务级别协议以及主要针对大众市场的基于体验的协议|(% style="width:364px" %)高级的服务级别协议,基于体验的协议或结果导向的协议|定制合同,结果导向的协议或没有协议 413 413 |(% style="width:185px" %)举例|(% style="width:306px" %)正如服务提供者预期,服务消费者清晰表达他们的期望值。例子可以在提供给广大的个人外部服务消费者的标准化服务找到。这就是移动运营商和运输公司如何运作。|(% style="width:364px" %)取决于服务提供者和服务消费者的关系,服务提供者可能很难完全了解服务消费者想实现的成果。在某些情况下,他们会一起工作去定义渴望的成果。举例,内部IT和HR部门的关系经理可能和客户谈话和讨论他们的需求和期望。|基于服务供应和产品的服务是依照客户规定要求去规划和创建。在敏捷产品开发那里,服务消费者和服务提供者在共享团队中共同创建产品。 414 414 420 + 415 415 === 1.2.4 客户旅程 === 416 416 417 417 客户旅程是服务消费者和服务提供者之间关于接触点和交互的整体感知。 ... ... @@ -489,6 +489,7 @@ 489 489 * 客户旅程仅包含可视化线的一部分价值流活动。 490 490 * 由于组织的价值流对其他方不可见,因此某些价值流将不是客户旅程的直接部分。 491 491 498 + 492 492 客户旅程很少遵循预定义的路径。有时,旅程进行是从一个接触点到下一个接触点,但是最常见的旅程是从一个接触点到另一个接触点然后返回。旅程也可能从期望路径的中途开始,然后靠近期望的起点。 493 493 494 494 ... ... @@ -512,6 +512,7 @@ 512 512 用户体验是客户所感知到服务的功能性以及与服务提供者情感交互的总和。 513 513 ))) 514 514 522 + 515 515 === 1.2.5 可视化 === 516 516 517 517 在客户旅程期间,有一条可视线,超出界限客户无法看到服务提供者的活动。类似地,也有一条可视线,超出界限服务提供者无法看到客户的活动。这适用于内部和外部客户以及服务提供者。 ... ... @@ -633,6 +633,7 @@ 633 633 |优化资源并最小化成本|与服务提供者一起在服务的生命周期期间提交和优化资源的使用|与服务消费者一起在服务生命周期期间提交和优化资源的使用 634 634 | | |关于费用公平透明 635 635 644 + 636 636 ITIL故事:客户旅程 637 637 638 638 [[image:1638951475719-992.png||height="51" width="41"]]//Solmaz:作为艾克苏的业务转型经理,我将帮助Mariana创建她的汽车共享服务。我们将映射设计客户旅程,以确保我们与利益相关者共同创建价值,并构建一个对艾克苏、我们的用户、消费者和客户有利的服务。// ... ... @@ -673,6 +673,7 @@ 673 673 * **服务交互** 服务提供者和服务消费者之间的互惠活动,它们共同创建价值。 674 674 ))) 675 675 685 + 676 676 服务交互包括: 677 677 678 678 * 货品的转让 ... ... @@ -760,6 +760,7 @@ 760 760 * **//什么影响我//**// 朋友和同事;在线博客,文章和营销。// 761 761 * **//希望与梦想//**// 环游世界,并有足够的灵活性,去喜欢的地方,说走就走,而不必担心财务状况。// 762 762 773 + 763 763 === 2.3.2 场景 === 764 764 765 765 场景是有关用户画像试图通过在上下文中使用服务或生产来实现其目标的简短故事。因此,客户场景特定于客户细分和上下文。 ... ... @@ -1090,6 +1090,7 @@ 1090 1090 |(% style="width:358px" %)法律、人事、安全|(% style="width:313px" %) 1091 1091 |(% style="width:358px" %)治理、风险和合规性|(% style="width:313px" %) 1092 1092 1104 + 1093 1093 === 3.1.2 外部因素 === 1094 1094 1095 1095 成功的策略的先决条件是了解组织的背景,包括市场、客户和其他利益相关者。PESTLE分析是一种广泛使用的探索外部背景的技术。PESTLE分析是一种战略工具,可为组织的战略和方向以及内部政策和程序提供输入。 ... ... @@ -1421,6 +1421,7 @@ 1421 1421 //我决定尝试电子化校园汽车共享服务,因为它不仅得到了大学的认可,还提供专门针对我需求的服务。它还为大学生提供有竞争力的价格,这是额外的惊喜!// 1422 1422 ))) 1423 1423 1436 + 1424 1424 == 3.3 了解市场 == 1425 1425 1426 1426 市场通常由服务消费者子群和具有一个或多个共同特征的潜在消费者子群组成,因此它们具有相似的产品和服务需求。要了解谁是潜在的服务消费者,服务提供者可能需要进行市场分析和规划。市场分析是市场的定量和定性评估;它探讨了市场规模,及其在数量和价值的机会。这包括: ... ... @@ -1442,13 +1442,11 @@ 1442 1442 1443 1443 === 3.3.1 市场细分 === 1444 1444 1445 -(% class="wikigeneratedid" id="H5E02573A7EC6520651418BB8670D52A163D04F9B800594885BF95177670972795B9A97006C42548C671F671B76845BA2623730026BCF4E2A7EC652065E02573A90FD662F552F4E007684FF0C5E948BE591C753D64E0D540C768465B96CD53002" %) 1446 -市场细分允许服务提供者针对具有特定需求和期望的客户。每个细分市场都是唯一的,应该采取不同的方法。 1458 +==== 市场细分允许服务提供者针对具有特定需求和期望的客户。每个细分市场都是唯一的,应该采取不同的方法。 ==== 1447 1447 1448 1448 1449 1449 服务提供者了解客户做出决定背后的原因很重要。目的将让服务提供者能够基于客户的需求和行为对其进行分组,以便服务提供者可以解决相应的问题。 1450 1450 1451 - 1452 1452 通常,有三种因素可以标识不同的市场细分: 1453 1453 1454 1454 * 细分的同质性或通用需求 ... ... @@ -1525,12 +1525,13 @@ 1525 1525 [[image:1638973980626-580.png||height="49" width="48"]]//Mariana//**:**//我们已经能够利用艾克苏的内部营销部门来帮助促进和增强服务供应。现在,我们可以聚焦两种不同的细分营销信息:关注安全性的女性和家长,以及重视成本和便利性的学生。// 1526 1526 ))) 1527 1527 1528 -== 3.4 瞄准市场 == 1529 1529 1540 +== 3.4 瞄准市场 == 1541 + 1530 1530 为了使构建品牌和吸引目标客户,内部和外部服务提供者应进行营销投资。市场营销推广产品和服务供应,并提升品牌。营销是一个综合领域;许多服务提供者都有专门的市场部门来承担这项工作。 1531 1531 1532 1532 1533 -=== 3.4.1 价值主张 === 1545 +=== 3.4.1 价值主张 === 1534 1534 1535 1535 价值主张是一个声明,它明确指出了服务消费者从特定的服务供应中将获得什么益处(Buttle,2009年)。这是使您的服务或产品快速区分于竞争对手的绝佳方法。 \ 1536 1536 ... ... @@ -1556,6 +1556,7 @@ 1556 1556 考虑您所针对的组织中典型决策者的观点。例如,人力资源经理可能是招聘工具的决策者,因此在设计价值主张时考虑人力资源经理的观点将很有用。 1557 1557 ))) 1558 1558 1571 + 1559 1559 === 3.4.2 市场和市场空间 === 1560 1560 1561 1561 服务提供者必须使用探索不同的渠道,才能在市场和市场空间中的目标市场吸引他们的客户。市场是物理世界,而市场空间是由Internet上可用的所有可能渠道定义的。 ... ... @@ -1583,10 +1583,11 @@ 1583 1583 * 聊天机器人 1584 1584 * 大数据、物联网IoT和针对目标市场的人工智能(AI)。 1585 1585 1599 + 1586 1586 (Bordoloi等人,2018) 如今,企业在两个世界中竞争:人与物的物理世界(称为市场)和信息虚拟世界(称为市场空间) 1587 1587 1588 1588 1589 -=== 3.4.3 个性化和画像 === 1603 +=== 3.4.3 个性化和画像 === 1590 1590 1591 1591 画像是一种跟踪服务消费者行为的方法,旨在了解消费者的需求,使目标市场销售活动成为可能。个性化就是要了解客户最有可能希望获得哪些服务产品,并向客户展示这些特定的产品。 1592 1592 ... ... @@ -1594,7 +1594,7 @@ 1594 1594 随着有关客户和用户的个人信息的积累,通过征求同意来保护个人隐私非常重要。许多国家/地区已经严格规范了隐私立法,但在获得同意的情况下,服务提供者可以通过市场空间为其客户和用户增加价值。 1595 1595 1596 1596 1597 -=== 3.4.4 目标市场 === 1611 +=== 3.4.4 目标市场 === 1598 1598 1599 1599 当服务提供者根据特定人群,及其需求和期望量身定制信息时,营销活动效果最好。为了有效地做到这一点,必须使用特定的用户描述(用户画像)。这能让服务提供者向潜在客户传递个性化信息,以解决他们的真正的需求问题。 1600 1600 ... ... @@ -1609,12 +1609,12 @@ 1609 1609 图片3.4 AIDA 模型 1610 1610 1611 1611 1612 -=== 3.4.5 品牌和声誉 === 1626 +=== 3.4.5 品牌和声誉 === 1613 1613 1614 1614 品牌是人们关于组织及其在市场上的产品和服务的综合感知。因此,发展与目标市场的优质关系是影响品牌的重要组成部分。品牌是迭代建立的,反映在人们谈论组织及其人员、产品和服务的方式中。 1615 1615 1616 1616 1617 -=== 3.4.6 可持续性和三重底线 === 1631 +=== 3.4.6 可持续性和三重底线 === 1618 1618 1619 1619 可持续性是一个对品牌和声誉影响重大的区域。可持续性可以定义为“在不损害后代满足他们自己的需求的能力的情况下,满足当前代的需求的发展”(Brundtland等,1987)。 1620 1620 ... ... @@ -1635,6 +1635,7 @@ 1635 1635 * **再售 **满意客户更有可能获得新的服务。 1636 1636 * **品牌 **满意的客户可能会向其他消费者推荐服务。 1637 1637 1652 + 1638 1638 一旦利益相关者了解了共同创造价值的机会,他们也就准备好建立良好的服务关系。 1639 1639 1640 1640 ... ... @@ -1646,6 +1646,7 @@ 1646 1646 [[image:1639038062590-279.png||height="61" width="42"]]//Radhika//**:**//间歇性用户通常将事务打包成一趟行程,一天租用几个小时的汽车,而不是每天使用。// 1647 1647 ))) 1648 1648 1664 + 1649 1649 1650 1650 == 3.5 总结 == 1651 1651 ... ... @@ -1676,6 +1676,7 @@ 1676 1676 * 凭借高度信任,客户会倾向于增加需求,可以有效促进价值共创。 1677 1677 * 表现出色的服务提供者会获得资源为服务消费者创建和交付高质量的产品或服务,有助于增强竞争优势。 1678 1678 1695 + 1679 1679 在低度信任的关系中,所有内容都趋于固定、文档和规范。在高度信任的关系中,它更加灵活,接触点和服务交互性的数量可能会增加。因此,协作变得更容易。 1680 1680 1681 1681 ... ... @@ -1745,6 +1745,7 @@ 1745 1745 [[image:1639038356665-888.png||height="60" width="48"]]//Radhika:我们的客户信任eCampus Car Share在需要时提供清洁,安全,可行驶的车辆。他们相信服务能够通过使用绿色清洁产品和校园内可靠的计费站来达到愿景环保可持续性的要求。他们还信任公司保护自己的私人信息,并诚实,适当地管理其帐户。// 1746 1746 ))) 1747 1747 1765 + 1748 1748 1749 1749 == 4.1 沟通与协作 == 1750 1750 ... ... @@ -1790,6 +1790,7 @@ 1790 1790 服务提供者通过调查,社交媒体,客户评论,电子邮件,反馈表,服务使用情况分析等与服务消费者进行沟通。 1791 1791 )))|(% style="width:211px" %)同理心的倾听 1792 1792 1811 + 1793 1793 === 4.1.1 倾听模式 === 1794 1794 1795 1795 倾听是有效沟通的关键,可以通过实践和训练来提高。糟糕的倾听会导致错误、误解和合作失败。 ... ... @@ -1803,6 +1803,7 @@ 1803 1803 * 专注倾听 集中注意力听说话者所说的话。 1804 1804 * 同理心的倾听 倾听并回应理解说话者的言语、意图和感受。 1805 1805 1825 + 1806 1806 该层次可以进一步简化为三种基本的倾听模式。表4.2中描述了三种倾听模式及其在不同服务管理情况下的应用方式。 1807 1807 1808 1808 ... ... @@ -1823,6 +1823,7 @@ 1823 1823 * 最后得出可执行的结论 1824 1824 * 不断地与工作程序保持一致。 1825 1825 1846 + 1826 1826 |((( 1827 1827 **ITIL的故事:沟通与协作** 1828 1828 ... ... @@ -1831,6 +1831,7 @@ 1831 1831 [[image:1639038531211-275.png||height="68" width="47"]]**S**//olmaz:我们正在利用艾克苏的服务台进行事件报告。作为eCampus Car Share 培训和意识的一部分,本地服务台成员已被派往西雅图,以协作方式为我们的圣保罗客户提供支持。// 1832 1832 ))) 1833 1833 1855 + 1834 1834 == 4.2 理解服务关系类型 == 1835 1835 1836 1836 与服务消费者的契动包括但不限于建立和维持关系、理解需求以及评估相互准备和成熟程度 。然而,这些活动因客户追求的目标、服务的类型、服务提供者的类型可能有所不同。这些依赖关系如表4.3所示。 ... ... @@ -1920,6 +1920,7 @@ 1920 1920 人们普遍认为,信任越多越好。然而,在服务关系中过度投资以建立信任是有可能的,但这种投资不会为相关方增加价值。 1921 1921 ))) 1922 1922 1945 + 1923 1923 === 4.2.1 基础关系 === 1924 1924 1925 1925 当以服务运营效率为基石时,基础关系通常适用于标准产品和服务。在这样的关系中的服务提供者对弹性且重复的操作感兴趣,这些操作能够以最小的努力和偏差实现特定的服务水平。商业服务提供者的主要目的是续约,它通常避免与服务消费者建立关系,因为产品或服务可能无利可图。在这种关系中,客户通常对服务提供者的服务有良好的控制,在达到服务水平,但往往难以评估服务价值。 ... ... @@ -1965,6 +1965,7 @@ 1965 1965 很少有机会提供差异化客户体验 1966 1966 ))) 1967 1967 1991 + 1968 1968 === 4.2.2 合作关系 === 1969 1969 1970 1970 在合作的服务关系中,服务提供者通常根据服务消费者需求来定制产品和服务。客户期望服务提供者会考虑服务成果和体验,而不仅仅是服务水平。由于服务提供者需要寻找新的机会来为服务消费者创造额外的价值,因此相关各方之间应该轻松交换信息。对于商业服务提供者,在成为一个值得信赖的供应商和提供高价值的服务而得不到投资回报的过程中,存在花费太多时间和资源的风险。 ... ... @@ -1999,6 +1999,7 @@ 1999 1999 相比客户减少了效率和控制 2000 2000 ))) 2001 2001 2026 + 2002 2002 === 4.2.3 伙伴关系 === 2003 2003 2004 2004 在合作伙伴中,服务提供者和服务消费者可以充当跨各种职能和流程的一种组织协调活动。随着相互依赖程度和集成的增长,双方可能会通过共同设定目标和优先级来在战略层面上保持一致。 ... ... @@ -2035,6 +2035,7 @@ 2035 2035 吸引更大,更具战略性客户的机会 2036 2036 )))|(% style="width:307px" %)分离既痛苦又费时 2037 2037 2063 + 2038 2038 |((( 2039 2039 **ITIL故事:了解服务关系类型** 2040 2040 ... ... @@ -2045,6 +2045,7 @@ 2045 2045 [[image:1639038900744-862.png||height="51" width="38"]]**H**//enri:艾克苏的合作关系和eCampus Car Share共享利润,资源和策略。艾克苏提供了资金,专业知识,基础架构和技术来设置和维护服务。当我们将服务的汽车份额扩展到其他地区时,Mariana的体验将对规划和设计中的汽车具有不可估量的价值。// 2046 2046 ))) 2047 2047 2074 + 2048 2048 == 4.3 建立服务关系 == 2049 2049 2050 2050 关系管理可以是角色、职能、和/或组织的能力或实践。在本出版物中,关系管理主要被视为一种实践,其详细描述可以在关系管理实践指南中找到。 ... ... @@ -2157,6 +2157,7 @@ 2157 2157 确保适当的容量和服务提供的功能 2158 2158 ))) 2159 2159 2187 + 2160 2160 === 4.3.1 创建容许契动关系模式的环境 === 2161 2161 2162 2162 为了成功使用服务消费者进行契动,服务提供者可以指导客户进行表4.8中所示的步骤。 ... ... @@ -2170,6 +2170,7 @@ 2170 2170 * 开始对话的初始邀请 2171 2171 * 支持与标准和非标准服务供应有关的讨论。 2172 2172 2201 + 2173 2173 服务目录可以采用多种形式(例如文档,在线门户或工具)来使当前服务列表能够传达给受众。这些表单对于不同的受众有不同的视图(例如,发起人、客户、用户、IT到IT-客户视图)(ITIL Foundation,第5.2.10.1节)。客户视图可以提供服务绩效和财务数据。然而,服务目录可能不包括客户为了做出明智的决定而需要的关于风险和约束的完整信息。服务提供者应该与客户合作,以提供有关选择的明确信息,并概述客户愿意接受的风险。只有客户可以决定服务消费者愿意接受哪些风险,但服务提供者有责任澄清风险的性质和范围,并根据客户的偏好进行处理。 2174 2174 2175 2175 ... ... @@ -2185,6 +2185,7 @@ 2185 2185 * 服务事件可能导致客户归咎于服务提供者的情况。在这些情况下,应该管理冲突。 2186 2186 * 服务提供者组织、客户组织或市场上总会有一些干扰。风险管理实践可以指出哪些风险对合作环境的威胁最大。 2187 2187 2217 + 2188 2188 |((( 2189 2189 **ITIL故事:建立服务关系** 2190 2190 ... ... @@ -2200,6 +2200,7 @@ 2200 2200 ))) 2201 2201 2202 2202 2233 + 2203 2203 === 4.3.2 建立和维持信任与关系 === 2204 2204 2205 2205 由于服务提供商和客户必须共同创造价值,他们需要建立和管理一种透明的关系,这种关系支持相互信任,注重在优化成本和风险的同时实现服务成果。为了有效地做到这一点,这些操作通常被称为科目:业务关系管理(对于内部服务提供者)和CRM(对于商业服务提供者)。在ITIL中,关系管理实践指南涵盖了这两个学科。 ... ... @@ -2210,6 +2210,7 @@ 2210 2210 * **基于知识** 随着时间的推移,对另一组人的认识可以提高信任度。 2211 2211 * **基于核算** 在服务关系中,信任可以快速建立。在这种情况下,这两个组都可以权衡潜在的机会与风险。 2212 2212 2244 + 2213 2213 ==== 4.3.2.1 信任和关系因素 ==== 2214 2214 2215 2215 可信赖的特征分为三个维度(Hacker等,1999): ... ... @@ -2218,6 +2218,7 @@ 2218 2218 * **承诺** 关心共同目标以及他人的成功和福利 2219 2219 * **一致性** 以同样的方式完成预期任务的能力。 2220 2220 2253 + 2221 2221 图4.3显示了模型中的这些维度。这些维度提供了个人、团队或组织的信任关系的基础(Hacker等,1999)。 2222 2222 2223 2223 ... ... @@ -2271,6 +2271,7 @@ 2271 2271 披露足够数量的信息 2272 2272 ))) 2273 2273 2307 + 2274 2274 ==== 4.3.2.2 建立信任和关系活动 ==== 2275 2275 2276 2276 表4.10中列出了客户和服务提供者为建立信任而执行的不同方法和活动的描述。这些活动同样适用于内部和外部关系。 ... ... @@ -2345,6 +2345,7 @@ 2345 2345 关注变化环境中的价值实现,而不是固定的成果 2346 2346 ))) 2347 2347 2382 + 2348 2348 ==== 4.3.2.3 持续建立信任和关系 ==== 2349 2349 2350 2350 许多因素威胁着信任和关系,包括: ... ... @@ -2355,6 +2355,7 @@ 2355 2355 * 任何一方的新员工改变了服务关系的性质(确保与与新员工及时接触很重要) 2356 2356 * 不可避免的客户投诉(正式的客户投诉和升级流程可以缓解这一因素)。 2357 2357 2393 + 2358 2358 |((( 2359 2359 **ITIL的故事:建立和维持信任与关系** 2360 2360 ... ... @@ -2363,6 +2363,7 @@ 2363 2363 [[image:1639039554566-680.png||height="45" width="32"]]**R**//adhika:在新的学年开始之初,我们可能需要在服务台上配备更多人员,以管理注册数量的增加。// 2364 2364 ))) 2365 2365 2402 + 2366 2366 === 4.3.3 理解服务提供者能力 === 2367 2367 2368 2368 理解和评估服务提供者能力的最流行方法是通过审计和成熟度评估。 ... ... @@ -2431,6 +2431,7 @@ 2431 2431 [[image:1639039664566-243.png||height="53" width="47"]]//Mariana:为了与新的汽车清洁合作伙伴契动,我们进行了一次审计,以确保它们在财务上是可行的。我们检查了其他乘客对其服务的评论。我们还确保他们有能力提供绿色清洁产品。// 2432 2432 ))) 2433 2433 2471 + 2434 2434 === 4.3.4 了解客户需求 === 2435 2435 2436 2436 重要的是要记住,客户不购买服务;他们购买的是特定需求的实现。他们有工作要做(克里斯滕森等,2016),服务提供者必须理解这些工作,才能识别服务消费者的需求、偏好以及期望的成果和体验。 ... ... @@ -2446,6 +2446,7 @@ 2446 2446 * **基于价值的方法(自上而下)** 服务提供者讨论客户最紧迫的问题或目标,然后分析计划(如何解决或实现它们)、促成因素(实施计划需要什么功能或资源)和技术(生产或服务如何交付这些能力和促成因素)。 2447 2447 * **基于解决方案的方法(自下而上) **服务提供者讨论其产品和服务,并试图将与紧迫的消费者问题或目的连接起来,以相反的顺序回答与基于价值的方法相同的问题。 2448 2448 2487 + 2449 2449 客户需求通常是由具体问题引起的。研究这些问题可以提供通过产品和服务实现需求的最佳方法。需要考虑的问题有: 2450 2450 2451 2451 * 主要问题是什么? ... ... @@ -2453,6 +2453,7 @@ 2453 2453 * 这些问题如何影响服务消费者的目的、目标和绩效? 2454 2454 * 当前的服务消费者背景是什么,包括影响或受这些问题影响的战略、架构和组织结构? 2455 2455 2495 + 2456 2456 不要将客户需要与客户需求混淆。了解需要后,服务提供者仍然需要理解需求。然后,各方就可将服务消费者的需要作为具体的需求表达出来。这些活动将在第5章中进一步介绍。 2457 2457 2458 2458 (% style="text-align:center" %) ... ... @@ -2588,6 +2588,7 @@ 2588 2588 * 在合作关系中,客户可以使用审计和成熟度评估工具评估服务提供者成熟度。与基础关系相比,协作和沟通机制的准备也变得非常重要。在所有利益相关者之间明确协调成果并就反馈程序达成一致是至关重要的。 2589 2589 * 在伙伴关系中,开放和信任是相互成功的关键因素。因此,尽管可能会进行正式的能力成熟度和以往的绩效检查,但是协作的准备是至关重要的。 2590 2590 2631 + 2591 2591 表4.14 显示了不同类型的评估与不同类型的关系的相关性。 2592 2592 2593 2593 ... ... @@ -2638,8 +2638,7 @@ 2638 2638 外包商品服务技术驱动的业务功能是推动市场差异化的IT催化剂 2639 2639 ))) 2640 2640 |((( 2641 -(% class="wikigeneratedid" id="H4F194F3451737CFB" %) 2642 -伙伴关系 2682 +==== 伙伴关系 ==== 2643 2643 )))|(% style="width:363px" %)((( 2644 2644 创新与成长 2645 2645 ... ... @@ -2720,6 +2720,7 @@ 2720 2720 服务提供者是否确保所有各方遵守所有协议以及法律和法规要求? 2721 2721 ))) 2722 2722 2763 + 2723 2723 ==== 4.3.5.3 评估协作的准备情况 ==== 2724 2724 2725 2725 利益相关者之所以对协作感兴趣,是因为与其他利益相关者的持续合作更容易实现目标。为了评估协作的准备情况,必须考虑表4.17中概述的信息。 ... ... @@ -2747,6 +2747,7 @@ 2747 2747 跨协作组织分配资源(主要是人员,技术和信息) 2748 2748 ))) 2749 2749 2791 + 2750 2750 ==== 4.3.5.4 评估组织变革准备情况 ==== 2751 2751 2752 2752 在某些情况下,成功交付服务可能需要转换组织惯例和例程,以便从服务获得价值。这需要组织变革管理。ITIL Foundation定义了以下有效组织变革管理实践的属性: ... ... @@ -2756,6 +2756,7 @@ 2756 2756 * 愿意和有准备的参与者 2757 2757 * 持续的改进点。 2758 2758 2801 + 2759 2759 为了评估组织变革的准备情况,可以使用表4.18中所示的检查表。 2760 2760 2761 2761 ... ... @@ -2808,6 +2808,7 @@ 2808 2808 * **价值共创** 创建消费服务并与供应商进行服务交互 2809 2809 * **实现价值 ** 持续跟踪、评估和评价价值实现,并改进整个过程。 2810 2810 2854 + 2811 2811 服务消费者和提供者具有不同的视角和关注领域。通常不同的方面是服务集成和编排。服务集成负责协调或编排参与产品或服务的采购和提供的所有供应商。它侧重于端到端的提供服务,确保控制供应商的所有接口和结果,并促进了供应商之间的协作(ITIL Foundation ,第5.1.13节)。 2812 2812 2813 2813 ... ... @@ -2821,6 +2821,7 @@ 2821 2821 * **服务守护者 **供应商除了管理其他供应商外,还提供服务集成和管理职能以及一个或多个交付职能 2822 2822 * **独立的服务集成商 **即使供应商不向组织提供任何服务,也可以由供应商提供服务集成和管理职能并管理所有其他供应商。 2823 2823 2868 + 2824 2824 如果服务提供者充当服务集成商,则通常代表客户建立关系和协作。在某种程度上,现在每个服务提供商都是服务集成商。 2825 2825 2826 2826 ... ... @@ -2855,6 +2855,7 @@ 2855 2855 评估更大的供应链,管理与供应商及其分包商有关的风险,以影响供应商提供服务的能力 2856 2856 ))) 2857 2857 2903 + 2858 2858 供应商管理实践可用于为参与服务交付的所有供应商创建一个单一的可视点,以确保一致性并实现价值。这有助于回答以下问题: 2859 2859 2860 2860 * 服务提供者在管理其合作伙伴和供应商时是否有效? ... ... @@ -2862,6 +2862,7 @@ 2862 2862 * 关键供应商停工对服务运营可能导致的影响是什么? 2863 2863 * 供应商是否与服务提供者的价值链无缝集成? 2864 2864 2911 + 2865 2865 此实践还确保与供应商的协议与预期的服务结果和客户需求相一致,并监督其绩效,以确保条款、条件和目标得到满足。 2866 2866 2867 2867 ... ... @@ -2881,6 +2881,7 @@ 2881 2881 [[image:1639040414134-638.png||height="47" width="39"]]**S**//olmaz:我们正在寻求与充电运营商更紧密的合作,以减少我们的汽车无法正确充电的机会。// 2882 2882 ))) 2883 2883 2931 + 2884 2884 == 4.5 总结 == 2885 2885 2886 2886 良好的关系是管理合作关系、伙伴关系和基础关系所必须的。培养良好的关系包括创建能够契动的关系模式,建立信任并理解相互需求和价值的环境。 ... ... @@ -2928,6 +2928,7 @@ 2928 2928 ))) 2929 2929 |优化资源并最小化成本|确保将资金投资于能够优化投资回报的领域|(% style="width:583px" %)确保在最佳区域使用时间和资源 2930 2930 2979 + 2931 2931 |((( 2932 2932 **ITIL故事:步骤3 – 供应** 2933 2933 ... ... @@ -2934,6 +2934,7 @@ 2934 2934 [[image:1639040709737-670.png||height="50" width="44"]]//Mariana:我们的eCampus汽车共享服务已受到大学学生和员工的欢迎。我们为普通汽车用户提供订阅会员资格,为间歇性用户提供不同的定价等级。我们的汽车是电动的,这使它们比传统的汽车更环保,因为它们排放的废气更少。另外,汽车共享会降低汽车拥有率,减少道路上的汽车行驶次数,并减少客户出行次数,因为客户会将差事合并为一次出行以最大程度地增加支出。我们为自己能提供一个干净、安全、可靠的往返于校园的其他交通选择而自豪。// 2935 2935 ))) 2936 2936 2986 + 2937 2937 == 5.1 管理需求和机会 == 2938 2938 2939 2939 就服务而言,需求和容量是相互关联的。服务无法存储供以后使用。当服务价值只有在服务提供者的供给满足服务使用者的需求时才能被共同创造。如果需求得不到满足,设施和资源就会浪费。同样,当需求高于容量时,也会丢失机会。为了优化服务机会,服务提供者应调整容量和影响需求。正确理解不同的客户群体和部门如何使用其服务至关重要。 ... ... @@ -2950,6 +2950,7 @@ 2950 2950 一个或多个业务活动的工作负载描述。PBA用于帮助服务提供者理解和支持不同级别的服务消费者活动。 2951 2951 ))) 2952 2952 3003 + 2953 2953 表5.2描述了一个会计流程的PBA。 2954 2954 2955 2955 ... ... @@ -2982,9 +2982,11 @@ 2982 2982 * **生产和服务容量管理 **管理特定生产或服务的端到端容量。 2983 2983 * **组件容量管理 **监视并调整生产或服务组件的容量。如果其中一个组件没用更多的容量,则整个服务将受到影响。在IT中,大多数组件都可以通过监视和调优进行设置,以避免容量问题。 2984 2984 3036 + 2985 2985 读者应参阅容量和性能管理实践指南以了解更多详细信息。 2986 2986 ))) 2987 2987 3040 + 2988 2988 由于容量和需求是相互交织的,为了更好地利用稀缺资源,必须同时考虑两者。管理需求的目的是了解不同的用户概况并影响其行为。容量和性能管理代表等式的另一侧。如图5.1所示,这是关于根据实际需求确定容量大小的问题。 2989 2989 2990 2990 ... ... @@ -2994,6 +2994,7 @@ 2994 2994 * 避免在高峰时段运行其他繁重的工作量 2995 2995 * 不允许在变更生产或服务时引入冻结期。 2996 2996 3050 + 2997 2997 需求可以是固定的,也可以是可变的。如果需求是可变的,最好的做法可能是将其与可变容量相匹配,以帮助服务消费者将固定成本转换为可变成本。这就是云计算通常的工作方式。客户(例如开发团队)使用灵活的自服务机制,在需要的时候添加额外的基础设施容量,在完成工作时释放它,从而使容量可供其他用户使用。 2998 2998 2999 2999 ... ... @@ -3035,6 +3035,7 @@ 3035 3035 * 这些机制是否能够实现资源的双赢和最佳利用? 3036 3036 * 双方是否有激励措施来推动服务的改进? 3037 3037 3092 + 3038 3038 表5.3 计费机制的不良负作用示例 3039 3039 3040 3040 |**案例**|**定价机制**|**不受欢迎的行为**|**问题**|**解决方案** ... ... @@ -3041,6 +3041,7 @@ 3041 3041 |由内部服务提供者提供的业务关键信息系统|为了弥补成本,服务提供者为每个用户定义了一个昂贵的许可证成本。|由于高昂的许可证成本,业务单元只购买了一到两个人的许可证,并让他们“服务”单位的其余部分。|服务提供者无法覆盖成本,并且需要提高许可证价格。|当检测到这种模式时,管理层决定在业务部门之间平均分担成本,使所有员工都能够使用服务。 3042 3042 |复印和打印|没有定价机制。|因为是免费的,所以做了很多不必要的彩印。|没有“打印前思考”的动机,也没有意识到彩印的成本。|通过引入收费和宣传活动,打印量减少了50%,用户切换到黑白默认设置。 3043 3043 3099 + 3044 3044 ==== 5.1.3.2 服务改进点机会 ==== 3045 3045 3046 3046 服务质量取决于对改进点机会的管理。来自客户的冲突请求、糟糕的定价激励或缺乏专门的改进点预算可能是冲突的来源。因此,服务提供者必须专业地处理改进点机会。持续改进需要所有权、服务改进点预算和透明的流程,以确定如何识别、捕获、评估、优先级和处理改进点机会。 ... ... @@ -3060,11 +3060,13 @@ 3060 3060 * 市场变化 3061 3061 * 来自服务提供者团队的反馈。 3062 3062 3119 + 3063 3063 目的旨在收集有关服务如何促进利益相关者价值的事实。这是价值驱动和数据驱动洞察力的一个方面。业务分析人员可以协助分析数据、识别需要、阐明需求并推荐解决方案。分析应基于定期且频繁捕获的真实数据。为了加深理解并做出正确的决定,需要进行深入的业务分析。 3064 3064 3065 3065 3066 3066 持续改进实践指南和ITIL®4:指导计划和改进中介绍了有关如何完成结构化服务改进的详细指南。业务分析实践指南中介绍了执行业务分析的任务和技术。 3067 3067 3125 + 3068 3068 3069 3069 === 5.1.4 构建客户商业案例 === 3070 3070 ... ... @@ -3077,6 +3077,7 @@ 3077 3077 组织资源支出的理由,提供有关成本、收益、选择、风险和问题的信息。 3078 3078 ))) 3079 3079 3138 + 3080 3080 商业案例的核心是财务分析,用于评估收益率和风险的支出。此分析应同时考虑定性和定量方面。商业案例为正表示预期收益超过支出和风险。 3081 3081 3082 3082 ... ... @@ -3100,6 +3100,7 @@ 3100 3100 * 预期的投资回报率(ROI)或净现值(NPV)是多少? 3101 3101 * 为了创造价值和实现收益,需要进行哪些组织上的变革? 3102 3102 3162 + 3103 3103 商业案例的目的是为明智的决策奠定基础,但它是基于假设的。这些假设存在不确定性,并且常常与需求和利益冲突。不同的视角会影响业务分析人员对用户需求进行优先排序的能力。表5.4突出显示了冲突和不确定性的典型领域。 3104 3104 3105 3105 ... ... @@ -3131,6 +3131,7 @@ 3131 3131 **理解不确定性和影响** 3132 3132 )))|(% style="width:1133px" %)很难事先知道服务提供者是否愿意并且能够满足服务消费者的需求。重要的是要从一开始就建立良好的关系,不仅要与销售人员建立联系,而且还要与将成为服务提供关键资源的人员建立联系。在协议和合同中包含建立关系的激励措施和双赢文化是很好的。 3133 3133 3194 + 3134 3134 表5.5中描述了优先级与需求冲突的一些传统领域。 3135 3135 3136 3136 ... ... @@ -3188,11 +3188,13 @@ 3188 3188 这项服务在使用期间是否可用? 3189 3189 )))|客户可能有用户不感兴趣的战略问题。|借助IT服务,许多例行公事任务可以实现自动化,使员工能够更加专注于创新。 3190 3190 3252 + 3191 3191 对时间和成本的短期关注可能会在以后造成大量成本: 3192 3192 3193 3193 * **时间不足** 如果没有足够的时间让用户参与进来,则可能导致他们的需求得不到满足。因此,该服务可能无法让用户更好地完成工作,并可能会导致负面的商业案例。 3194 3194 * **选择最便宜的提供者** 在这种情况下,价格和成本承受着巨大的压力,这可能会使服务提供者的利润空间很小,也可能会阻止服务提供者在不亏损的情况下保持灵活性。这可能会导致一种以牺牲价值为代价的紧张关系。 3195 3195 3258 + 3196 3196 === 5.1.5 构建服务提供者商业案例 === 3197 3197 3198 3198 服务提供者需要构建和维护一个可盈利的、可行的商业案例。否则,服务提供者可能会赔钱,最终倒闭。在构建商业案例时,服务提供者应该考虑客户的商业案例。 ... ... @@ -3211,6 +3211,7 @@ 3211 3211 * 合作伙伴和供应商,它将成为服务提供的一部分 3212 3212 * 组织方面,例如资源数量以及员工的技能和能力。 3213 3213 3277 + 3214 3214 许多ITIL 管理实践都可以为客户、组织和服务提供者的新的服务或变更的服务提供输入。这些包括: 3215 3215 3216 3216 * 可用性管理 ... ... @@ -3221,6 +3221,7 @@ 3221 3221 * 服务连续性管理 3222 3222 * 服务财务管理。 3223 3223 3288 + 3224 3224 |((( 3225 3225 **ITIL的故事:管理需求和机遇** 3226 3226 ... ... @@ -3231,6 +3231,7 @@ 3231 3231 [[image:1639041359021-160.png||height="51" width="41"]]**R**//adhika:我们已经确定了服务台的两个繁忙时期:学年开始时,客户注册每月订阅;年末,他们会要求退还每月会员费的剩余费用。在此期间,我们增加了服务台的资源。// 3232 3232 ))) 3233 3233 3299 + 3234 3234 == 5.2 指定和管理客户要求 == 3235 3235 3236 3236 需求规范应该出现在可视化线中。理想情况下,客户应该让服务提供者参与到一个开放且透明的需求规范流程中。如果在流程中过早的密封了需求,则服务提供者可能无法形成最佳的服务并满足服务消费者需求。 ... ... @@ -3248,6 +3248,7 @@ 3248 3248 业务分析使组织能够以有意义的方式传达其需求,表达变更的基本原理,并设计和描述支持与组织目标相一致的价值创造的解决方案。 3249 3249 ))) 3250 3250 3317 + 3251 3251 |((( 3252 3252 **ITIL故事:指定和管理客户要求** 3253 3253 ... ... @@ -3258,6 +3258,7 @@ 3258 3258 [[image:1639041475311-111.png||height="44" width="45"]]//Katrina:我的室友们已经离开大学回到欧洲的家中,这是我两个月来第二次不得不搬家!eCampus Car Share公司发现,客户偶尔需要拖车来帮助他们搬家,这真是太棒了。现在,我不必寻找其他选择。// 3259 3259 ))) 3260 3260 3328 + 3261 3261 === 5.2.1 角色和责任 === 3262 3262 3263 3263 明确的角色和职责是指定和管理需求的关键。权威人士必须得到识别,并说明如何捕获、表达和表示用户需求和期望。 ... ... @@ -3306,6 +3306,7 @@ 3306 3306 ))) 3307 3307 |服务提供者为大众市场设计一种新的商品服务。|需求由服务提供者拥有和管理,在将需求转换为需求的过程中,服务提供者可能涉及服务消费者,也可能不涉及服务消费者。 3308 3308 3377 + 3309 3309 业务分析人员可以帮助阐明和确定需求的优先级,并将其转换为服务提供者可以理解的语言和格式。这可以用作设计和构建服务的基础。 3310 3310 3311 3311 ... ... @@ -3319,6 +3319,7 @@ 3319 3319 * 持续确保以正确的方式解释和理解需求 3320 3320 * 验证产品和服务符合要求。 3321 3321 3391 + 3322 3322 客户的需求不是一成不变的;随着新的知识和经验的获得,客户的需求也会发生变化。因此,确保将需求集中在客户需求上,以使需求的定义与生产或服务的测试之间的时间尽可能短。 3323 3323 3324 3324 ... ... @@ -3341,6 +3341,7 @@ 3341 3341 * 可度量性和可报告性 3342 3342 * 可扩展性。 3343 3343 3414 + 3344 3344 === 5.2.3 将问题与解决方案分开 === 3345 3345 3346 3346 我们已经说过,需求应该基于利益相关者需要。然而,指定一个解决方案,而不是将需要转换成需求可能会很有吸引力。在阐明需求时,必须将问题与解决方案分开,以考虑到解决方案无法解决潜在问题的事实。这也有助于将当前的解决方案与所有可能的未来解决方案区分开。表5.7概述了一种简单的技术来帮助完成此流程。 ... ... @@ -3356,6 +3356,7 @@ 3356 3356 |什么?|(% style="width:279px" %)当前问题的本质和需要做的事情的本质|(% style="width:259px" %)真正的需要什么?什么是“本质”? 3357 3357 |怎么样?|(% style="width:279px" %)当前执行所需工作的方式|(% style="width:259px" %)将来有什么可能的方法来解决问题? 3358 3358 3430 + 3359 3359 表5.8 问题规范技术的使用示例 3360 3360 3361 3361 | |**当前**|**未来** ... ... @@ -3366,6 +3366,7 @@ 3366 3366 图书管理员使用数据库查找图书并登记借出。 3367 3367 )))|当我们识别问题的本质并探索解决问题的不同方法时,可以采用多种不同的解决方法,包括在线阅读,有声读物,相关文章以及内容摘要。 3368 3368 3441 + 3369 3369 === 5.2.4 最小化可行产品 === 3370 3370 3371 3371 在Eric Ries (Ries, 2011)所描述的精益创业方法中,关键的信息是制作一个好的商业案例的原型,并在真实的用户中进行测试,以获得反馈。对于原型设计,他依赖于最小可行产品的概念。 ... ... @@ -3388,6 +3388,7 @@ 3388 3388 [[image:1639041663609-946.png||height="49" width="44"]]**T**//omas:Mariana使用迭代的方法,Mariana发现顾客也需要手推车作为产品供应的一部分。这是她在试租拖车之前没有考虑过的事情。// 3389 3389 ))) 3390 3390 3464 + 3391 3391 === 5.2.5 用户故事和故事映射 === 3392 3392 3393 3393 用户故事映射是表达服务需求的常用方法。用户故事是一种表示利益相关者所需功能领域的方式,这种方式可以在团队成员之间引起讨论和理解,帮助他们共同努力,将需求转变为有效的产品和服务。用户故事用于描述生产或服务的片段。该技术可以有不同的用途。 ... ... @@ -3463,6 +3463,7 @@ 3463 3463 * 可能 如果不影响“应该”或“必须”的需求,那么可以包括的需求。 3464 3464 * 不会 本次不包括但可能包含在未来版本的需求。 3465 3465 3540 + 3466 3466 === 5.2.7 加权最短作业优先 === 3467 3467 3468 3468 有时需求具有匹配的优先级。在这些情况下,MoSCoW方法可以被更细粒度的技术(例如气泡排序)所取代或与之结合。然而,如果利益相关者的观点需要一致,这些方法可能不可行。 ... ... @@ -3507,6 +3507,7 @@ 3507 3507 |(% style="width:102px" %)建立拉动|(% style="width:1192px" %)创建流后,下一步就是将优化转换为价值流。该“拉式” 原则确保不会将工作推向下游。它允许限制批量大小和在制品,以便及时完成工作单元。 3508 3508 |(% style="width:102px" %)寻求完美|(% style="width:1192px" %)该原则反映了持续改进。 3509 3509 3585 + 3510 3510 价值流映射是一种用于说明和分析价值流逻辑的精益技术:一种将从需求/机会到价值的流动可视化的方法,然后计划如何改进该流动。价值流图以图形的方式概述了物料和信息的流动,并指出了需要改进的地方。这是理解活动如何联系和创造价值的良好基础。 3511 3511 3512 3512 ... ... @@ -3534,6 +3534,7 @@ 3534 3534 * **金丝雀发布** 一个暗发布,邀请一些测试用户测试新功能。 3535 3535 * **蓝绿部署** 用来测试两种可选方案中哪一种方案是最好的一种技术。它可以是另一种图形设计或功能。消费者被随机分为两组,测试相同功能的两个不同版本。 3536 3536 3613 + 3537 3537 这些技术使快速开发发布和新功能成为可能和安全。 3538 3538 3539 3539 ... ... @@ -3561,6 +3561,7 @@ 3561 3561 * **可视化线 **这条线客户和用户可见的服务活动与不可见的活动分开。可见的活动显示在此线上方,不可见的活动显示在此线下方。 3562 3562 * **内部交互线** 这条线将联系的员工与不直接支持与客户和用户进行交互的员工区分开来。 3563 3563 3641 + 3564 3564 对于一个服务,如果有多个不同的场景,则可能会有多个蓝图。在绘制蓝图时,,从最上面一行开始,然后沿着模板向下,这一点很重要。 3565 3565 3566 3566 ... ... @@ -3579,6 +3579,7 @@ 3579 3579 * 发现弱点并确定优化机会 3580 3580 * 努力搭建跨部门的桥梁,避免双重工作量。 3581 3581 3660 + 3582 3582 总之,服务蓝图帮助组织了解服务提供者如何实现服务,以及客户和用户如何使用服务。服务蓝图确定了面向员工的流程和面向客户/用户的流程之间的依赖关系。它还可以帮助服务提供者识别痛点,优化复杂的相互,并了解改进服务设计和客户旅程以及降低成本的可能性。 3583 3583 3584 3584 ... ... @@ -3614,6 +3614,7 @@ 3614 3614 |**我们做到了吗?**|(% style="width:472px" %)控制和引入并确保其成功:与基线和目标相比较的控制和度量 3615 3615 |**我们如何保持动力?**|(% style="width:472px" %)评审和改进 3616 3616 3696 + 3617 3617 当引入方法被设计为产品、服务或服务供应的一部分时,主要活动包括: 3618 3618 3619 3619 * 识别将与消费者的资源进行交互的提供者的资源 ... ... @@ -3624,6 +3624,7 @@ 3624 3624 * 测试规程并根据测试结果进行更新(根据需要重复) 3625 3625 * 文档化并与有关各方进行沟通。 3626 3626 3707 + 3627 3627 以下ITIL实践支持产品和服务的设计,以实现平稳有效的用户引入: 3628 3628 3629 3629 * 架构管理 ... ... @@ -3632,6 +3632,7 @@ 3632 3632 * 服务验证和测试 3633 3633 * 软件开发和管理。 3634 3634 3716 + 3635 3635 |((( 3636 3636 **ITIL的故事:设计服务产品和用户体验** 3637 3637 ... ... @@ -3640,6 +3640,7 @@ 3640 3640 [[image:1639042099419-158.png||height="52" width="46"]]//Henri:我们将做一个预告片自动预订流程的金丝雀版本,只有几个测试用户。然后,我们可以将其推广给客户,并随着我们的进展而开发功能。// 3641 3641 ))) 3642 3642 3725 + 3643 3643 == 5.4 销售并获得服务供应 == 3644 3644 3645 3645 设计产品、服务和服务供应之后,就需要进行销售。这可能发生在它们构建之前或之后,这取决于服务的性质和服务关系。内部和外部服务提供者都需要销售他们的服务。销售活动将根据客户是内部客户还是外部客户而有所不同。 ... ... @@ -3681,9 +3681,11 @@ 3681 3681 * 服务提供者有多成熟? 3682 3682 * 三重底线方法会影响定价吗? 3683 3683 3767 + 3684 3684 在某些情况下,定价可以在短期内用于破坏竞争。 3685 3685 ))) 3686 3686 3771 + 3687 3687 === 5.4.2 内部销售 === 3688 3688 3689 3689 对内部客户而言,提高对可用服务的认知是销售的第一步。内部销售和促销,综合激励措施和定价机制,对于管理需求非常重要。 ... ... @@ -3696,6 +3696,7 @@ 3696 3696 * 改进与客户和用户的沟通 3697 3697 * 关于服务如何满足需求的反馈。 3698 3698 3784 + 3699 3699 内部销售有助于内部服务提供者的整体客户感知。 3700 3700 3701 3701 ... ... @@ -3713,6 +3713,7 @@ 3713 3713 * 服务级别管理 3714 3714 * 服务请求管理。 3715 3715 3802 + 3716 3716 此外,服务提供者也可以应用大多数用于外部销售的传统技术。 3717 3717 3718 3718 ... ... @@ -3724,6 +3724,7 @@ 3724 3724 * 一些服务消费者要求由采购团队完成采购。 3725 3725 * 其他人可能已经定义了正式的采购流程,其中包括正式的请求方法,例如信息请求、报价请求、提议请求、概念验证、演示等。 3726 3726 3814 + 3727 3727 表5.13显示了请求产品和服务的不同方法 3728 3728 3729 3729 ... ... @@ -3762,6 +3762,7 @@ 3762 3762 供应商比较 3763 3763 ))) 3764 3764 3853 + 3765 3765 成功的销售流程取决于良好的沟通、信任和公平。服务提供者应避免为服务创造高于客户价值的价格。服务消费者应避免压低价格,以免服务提供者难以交付。 3766 3766 3767 3767 ... ... @@ -3777,6 +3777,7 @@ 3777 3777 [[image:1639042297905-281.png||height="46" width="43"]]**M**//ariana:我们需要引入新的拖车租赁服务,这意味着将其添加到我们的服务目录中,向我们的支持人员介绍拖车的可用性,并管理拖车的需求。当学生最有可能搬家时,拖车租赁在每个学期的开始和结束时达到顶峰,但中期租赁确实会发生。// 3778 3778 ))) 3779 3779 3869 + 3780 3780 == 5.5 总结 == 3781 3781 3782 3782 为了确定利益相关者是否可以从相互的服务关系中受益,服务消费者和服务提供者需要构建商业案例,确定并匹配其需求和供应,并以需求和服务供应的形式阐明其需求和机会。只有真正了解服务消费者的需求,才能设计出产品和服务。 
 
- 1639048000162-709.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -6.5 KB 
- Content
 
- 1639048009299-382.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -4.5 KB 
- Content
 
- 1639048305942-643.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -188.5 KB 
- Content
 
- 1639048338706-431.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -81.1 KB 
- Content
 
- 1639048447665-961.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -4.5 KB 
- Content
 
- 1639048543615-528.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -228.0 KB 
- Content
 
- 1639048688182-294.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -4.9 KB 
- Content
 
- 1639048741852-426.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -46.6 KB 
- Content
 
- 1639048791347-982.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -4.6 KB 
- Content
 
- 1639049066141-786.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -203.5 KB 
- Content
 
- 1639049191757-274.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -6.9 KB 
- Content
 
- 1639049245149-501.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -18.2 KB 
- Content
 
- 1639049400385-584.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -6.5 KB 
- Content
 
- 1639049408203-780.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -4.6 KB 
- Content
 
- 1639049435845-855.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -192.4 KB 
- Content
 
- 1639049867583-763.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -6.5 KB 
- Content
 
- 1639049876815-154.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -4.1 KB 
- Content
 
- 1639049903595-695.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -4.4 KB 
- Content
 
- 1639050104902-799.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -36.1 KB 
- Content
 
- 1639050210407-577.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -6.4 KB 
- Content
 
- 1639050219865-483.png
-   - Author
-   ... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin 
- Size
-   ... ... @@ -1,1 +1,0 @@ 1 -4.4 KB 
- Content
 

 ITIL 4官方核心著作
  ITIL 4官方核心著作 
   
   
   
   
  

 Copy
 Copy Export
 Export Print preview
 Print preview View Source
 View Source Children
 Children Content
 Content Comments
 Comments Attachments (167)
 Attachments (167) History
 History Information
 Information

