ITIL4-foundation Book中文翻译版【推荐】

乐迪学堂独家整理
ITIL 4 基金会
关于此出版物
ITIL 4 基金会是 ITIL 4 的首次发布，这是 ITSM 采用最广泛的指南的最新演变。其受众
范围从 IT 和业务学生在服务管理方面迈出第一步，到熟悉早期版本的 ITIL 和其他行业最
佳实践来源的经验丰富的专业人士。
ITIL 4 基金会将：
⚫ 让读者了解 ITIL 4 服务管理框架，以及 ITIL 4 服务管理框架如何演变为

采用现代技术和工作方式
⚫ 解释服务管理框架的概念，以支持参加 ITIL 4 基础考试的考生
⚫ 作为从业者在工作中、进修和专业发展中可以使用的参考指南。
我们希望你会发现它有用。
关于 ITIL 故事
本出版物中提供的指南可以采用并适用于各种组织和服务。为了展示 ITIL 的概念如何实际
应用于组织的活动，ITIL 基金会遵循虚构公司在其 ITIL 旅程中的利用。
这家公司，Axle CarHire，正在经历一项转型，以使其服务现代化，提高客户满意度和保
留率，并正在利用 ITIL 做到这一点。在本文的每一章中，Axle 的员工将描述公司如何改进
其服务，并解释他们如何使用 ITIL 最佳实践来执行此操作。
ITIL 故事情节部分显示整个文本与有色覆盖。
Axle 租车
Axle 租车公司是一家全球性公司，总部设在西雅图。Axle 成立于 10 年前，目前在欧

洲、美国和亚太地区拥有约 400 名员工。
最初，公司经历了强劲的增长和持续的高客户满意度评级。在头六年中，重复业务占所有
预订的 30%左右。股东们可以期待可观的季度股息。然而，在过去的四年里，公司经历了
一次低迷。客户满意度持续下降，重复预订很少。竞争对手为传统的车辆租赁提供了新的
创新选择。拼车、拼车和无人驾驶汽车是大有作为。客户也期望在线和应用程序接口作为
公司服务的标准。
ITIL 4 基金会
在这个不断发展的市场中，Axle 租车面临着不确定的未来。董事会渴望提高客户满意度水
平。他们希望吸引和留住客户，提高公司的底线。他们任命了一位新的首席信息官亨利·杜
兰。Henri 之所以被选中，是因为他在数字化服务方面的经验，以及他在成功、大规模 IT
转型方面的记录。他了解数字服务产品的影响，不仅对客户满意度水平，而且对员工保留
率的影响。
Henri 在 ITIL 和 ITSM 方面拥有强大的背景，这意味着他重视 ITIL 认证，他的招聘政

策反映了这一点。在与设计思维、DevOps 和敏捷方法合作后，他认为可持续业务需要一
种混合式 ITM 方法。
Henri 渴望了解他的团队如何重新定义租车体验，并确保 Axle 租车是新客户和现有客户

的首选。
认识员工
以下是 Axle 租车的四名关键员工：
⚫ 亨利是 Axle 租车公司的新首席信息官。他是一位成功的企业高管，他准备

改变现状。他相信 ITSM 采用综合方法。
⚫ Su 是 Axle 租车产品经理，具有旅行经验，过去五年来一直为 Axle 工

作。苏聪明、一丝不苟、对环境充满热情。
⚫ Radhika 是 Axle 租车 IT 业务分析师，她的职责是了解 Axle 租车员工和

消费者的用户要求。她好奇而精力充沛，努力与内部和外部的所有客户保
持积极的关系。Radhika 主要从事发现和规划活动，而不是 IT 运营。她
问了很多问题，擅长发现模式和趋势。
⚫ Marco 是 Axle 租车 IT 交付经理。他受流程驱动，并不断引用 ITIL 框

架，以帮助他管理积极的服务关系。但是，Marco 很少接触混合或协作的
服务管理方法。
ITIL 4 基金会
1 简介
1.1 现代世界中的 IT 服务管理
根据世界贸易组织，1服务业是发达和发展中经济体中最大和最具活力的组成部分。服务是
组织为自己及其客户创造价值的主要方式。如今，几乎所有服务都支持 IT，这意味着组织
在创建、扩展和改进其 IT 服务管理能力方面受益匪浅。
如今，技术正以前所未有的速度发展。云计算、基础设施即服务（IaaS）、机器学习和区
块链等开发为价值创造开辟了新的机会，使 IT 成为重要的业务驱动因素和竞争优势的来
源。反过来，这又将 IT 服务管理定位为一项关键战略能力。
为了确保这些机会仍然具有相关性和成功，许多组织正在着手实施重大转型方案，以利用
这些机会。虽然这些转换通常被称为"数字"，但它们不仅仅是技术。它们是组织工作方式
的演变，这样它们就能在重大和持续的变化面前蓬勃发展。组织必须在稳定性和可预测性
需求与对运营敏捷性和速度提高日益增长的需求之间取得平衡。信息和技术正与其他组织
能力更彻底地集成，孤岛正在崩溃，跨职能团队得到更广泛的利用。服务管理正在发生变
化，以应对和支持这种组织转变，并确保从新技术和新的工作方式中实现机会最大化。
服务管理也在不断发展，ITIL 也是如此，ITIL 是世界上最广泛采用的 IT 服务管理

（ITSM）指南。
1.2 关于 ITIL 4
30 多年来，ITIL 一直以指导、培训和认证计划引领 ITSM 行业。ITIL 4 通过在客户体

验、价值流和数字化转型的更广泛背景下重塑许多既定的 ITSM 实践，以及采用精益、敏
捷和 DevOps 等新的工作方式，使 ITIL 成为最新的。
ITIL 4 为组织应对新的服务管理挑战和利用现代技术的潜力提供了指导。它旨在确保一个
灵活、协调和集成的系统，用于有效管理启用 IT 的服务。
1 https://www.wto.org/english/tratop_e/serv_e/serv_e.htm
ITIL 4 基金会
1.3 ITIL 4 框架的结构和优势
ITIL 4 框架的关键组件是 ITIL 服务价值系统（SVS）和四维模型。
1.3.1 ITIL SVS
ITIL SVS 表示组织的各个组件和活动如何协同工作，通过支持 IT 的服务促进价值创造。

可以灵活组合，这需要集成和协调，以保持组织的一致性。ITIL SVS 促进了这种集成和协
调，并为组织提供了强大、统一、注重价值的方向。ITIL SVS 的结构如图 1.1 所示，并在
第 4 章中再次重复，其中将更详细地描述它。
图 1.1 服务价值系统
ITIL SVS 的核心组件包括：
| ITIL 服务价值链 l ITIL 实践
l ITIL 指导原则 l 治理 l 持续改进。
ITIL 服务价值链为服务的创建、交付和持续改进提供了运营模式。它是一个灵活的模型，
它定义了六个关键活动，可以以多种方式组合，形成多个值流。服务价值链非常灵活，可
适应多种方法，包括 DevOps 和集中式 IT，以满足多式联运服务管理的需求。价值链的
适应性使组织能够以最有效和最有效的方式对利益相关者不断变化的需求做出反应。
ITIL 实践进一步增强了服务价值链的灵活性。每个 ITIL 实践都支持多种服务价值链活动，

为 ITSM 从业人员提供全面且通用的工具集。
ITIL 指导原则可用于指导组织的决策和行动，并确保在整个组织中共享理解和共同的服务
管理方法。ITIL 指导原则为组织的文化和行为奠定了基础，从战略决策到日常运营。
ITIL 4 基金会
ITIL SVS 还包括治理活动，使组织能够持续调整其运营与管理机构制定的战略方向保持一

致。
ITIL SVS 的每个组件都得到持续改进的支持。ITIL 为组织提供了一个简单而实用的改进模

型，以在不断变化的环境中保持其弹性和敏捷性。
1.3.2 四维模型
为了确保对服务管理采取整体方法，ITIL 4 概述了服务管理的四个维度，从中应考虑 SVS

的每个组件。四个维度是：
l 组织与人员 l 信息与技术 l
合作伙伴和供应商 l 价值流和
流程。
通过赋予四个维度中每个维度适当的关注度，组织可确保其 SVS 保持平衡和有效。

第 3 章描述了这四个维度。
ITIL 故事：CIO 对 Axle 的愿景
亨利：如今，行业变革的步伐很快，"第四次工业革命"一词现在被广泛使用。Axle 等公司
正在与包括无人驾驶汽车和汽车共享在内的颠覆者展开竞争。
自 10 年前创建 Axle 以来，服务期望发生了变化。客户希望通过应用和在线服务立即访

问服务。Axle 的预订应用程序已经过时，我们的技术跟不上服务产品的变化。
我对 Axle 的愿景是，我们成为世界上最知名的租车品牌。我们将继续提供卓越的客户服
务，同时保持有竞争力的租车费率。毕竟，Axle 现在不仅仅是雇佣一辆车。我们必须专注
于客户的整体旅行体验。
2 服务管理的关键概念
组织和个人对 ITIL 的关键概念和术语的共同理解对于有效利用本指南来解决实际服务管理
挑战至关重要。为此，本章解释了服务管理的一些最重要的概念，包括：
ITIL 4 基金会
l 价值和价值共同创造的性质 l 组织、服务提供商、服务消费者和其他利益相
关者 l 产品和服务关系 l l 价值：结果、成本和风险。
这些概念适用于所有组织和服务，无论其性质和基础技术如何。但首先要概述的是最根本
的问题：什么是"服务管理"？
定义：服务管理
一组专门的组织功能，以服务的形式为客户创造价值。
发展定义中提到的专门组织能力需要了解：
⚫ 价值的性质 l 所涉及的利益相关者的性质和范围，以及如何通过服
务实现价值创造。
ITIL 的故事：Axle 的服务
苏：在 Axle，我们的服务是旅行体验。我们为客户提供这项服务，为他们和 Axle 创造价

值。服务管理有助于我们实现这一价值。
ITIL 故事：Axle 的客户

ITIL 4 基金会
以下是 Axle Car Hire 的三个常客，随着故事的展开，您将遇到这些客户：
⚫ 吉吉是一个正在度假的大学生，没有固定的计划。她希望参观音乐节，作
为她旅行体验的一部分。除此之外，她的旅行很灵活。她精通技术，能够
快速适应新的应用和解决方案。她对尝试新的和令人兴奋的数字服务感兴
趣。
⚫ 法鲁克 Is 最近退休了，通常只有假期。他周到，喜欢学习和采用新技
术。Faruq 经常根据个人或健康考虑，制定旅行计划，因为他的需求可能
会发生变化。
⚫ Amelia 是一家名为"燃料食品"的有机食品分销公司的设施经理。他们的总
部在伦敦市中心，但许多燃料食品消费者都在地区。这意味着乘坐公共交
通工具通常不频繁、不可靠且成本高昂。因此，食品燃料为销售人员提供
车辆，使他们能够方便和可靠地访问现有和潜在客户。
ITIL 4 基金会
2.1 价值和价值共同创造
关键消息
组织的目的是为利益相关者创造价值。
"价值"一词定期用于服务管理，它是 ITIL 4 的一个关键重点;因此必须明确界定。
定义：值
感知到的东西的好处、有用性和重要性。
此定义中固有的理解是，价值取决于利益相关者的看法，无论他们是服务的客户还是消费
者，还是服务提供商组织的一部分。价值可以是主观的。
2.1.1 价值共同创造
在一段时间，自称为"服务提供商"的组织认为，它们的角色与交付公司将包裹交付给建筑
物的方式大致相同，即为客户提供价值。此视图将服务提供者和服务使用者之间的关系视
为单向和远程。提供商提供服务，使用者获得价值;消费者在为自己创造价值方面起不起任
何作用。这没有考虑到现实中存在的高度复杂和相互依存的服务关系。
组织越来越认识到，价值是通过提供商和消费者以及作为相关服务关系一部分的其他组织
之间的积极协作共同创造的。提供商不应再尝试孤立地工作，以定义对其客户和用户有价
值的内容，而应积极寻求与其消费者建立互利、互动的关系，使他们能够成为服务价值链
中的创造性合作者。服务价值链中的利益相关者有助于定义需求、服务解决方案的设计，
甚至有助于服务创建和/或配置本身（参见第 4.5 节）。
ITIL 4 基金会
本章稍后将更深入地探讨价值。但是，在此之前，必须概述参与价值共同创造的各个利益
相关者以及 ITIL 中用于描述它们的语言。
ITIL 故事：价值
Marco：我们计划发布一个慷慨的新产品，每次预订时都会额外租车一天。
亨利：然而，我们必须记住，价值对不同的人有不同的意义。Axle 拥有广泛的客户，他们
每个人都有自己的租车要求。我们需要确保我们的服务的任何改变实际上为我们的客户提
供某种价值。
吉：对我来说，"价值"意味着行动自由。我希望我的旅行是容易，无忧无虑，灵活。我选择
加入邮件列表和订阅时，它适合我。我经常短途旅行，很少两次访问同一地点。多租一天
的车并不总是适合我的计划。
法鲁克：我不经常旅行，所以我没有自己的车。租车服务对我的价值是汽车按需可用性，
适合我的需求。我每年花在租车上的钱比维持和经营自己的汽车要少。
价值意味着它符合我的预算。退休意味着我很灵活，承诺或期限很少。当我在度假时，我
只提前几天计划。多租一天的车给我带来了真正的价值。
阿米莉亚：我组织租车的价值，燃料食品，是双重的。首先，我们需要能够接触到我们的
客户。其次，我们热衷于通过租用汽车来降低成本和风险，而不是运行我们自己的车队。
作为代表我的销售代表和员工预订租车的普通客户，我重视一致可靠的服务标准。燃料食
品旅行和租车是预先计划好的，通常只需要每日租用。对于我的组织来说，多租车一天没
有多大价值。
亨利：我们还得考虑如何为 Axle 创造价值。当我们出租汽车时，我们得到的最明显的价值

是收入。对于我们的服务消费者来说，价值包括在需要时轻松使用车辆，无需支付汽车拥
有量的总体费用。在这两种情况下，我们需要两者的组合来实现值。通过这种方式，我们
通过我们的服务关系共同创造价值。
ITIL 4 基金会
2.2 组织、服务提供商、服务使用者和其他利益相关者
在服务管理中，有许多不同类型的利益相关者，每一种利益相关者都必须在以服务形式创
造价值的背景下理解。首先，需要定义"组织"一词。
定义：组织
具有自身职能、有责任、权威和关系以实现其目标的个人或群体。
组织的规模和复杂性各不相同，与法律实体的关系各不相同，从单个个人或团队到由共同
目标、关系和当局统一的复杂法律实体网络。
随着社会和经济的发展，各组织之间和内部的关系变得更加复杂。每个组织在运营和发展
上都依赖于其他组织。组织可能担任不同的角色，具体取决于所讨论的观点。例如，协调
冒险假期的组织可以在旅行社销售假期时向旅行社填充服务提供商的角色，同时在购买悬
挂式郊游时填充服务消费者的角色，以添加到其度假套餐。
2.2.1 服务提供商
关键消息
预配服务时，组织将承担服务提供商的角色。提供程序可以是使用者组织的外部，也可以
是同一组织的一部分。
在 ITSM 最传统的观点中，提供商组织被视为公司的 IT 部门，而公司其他部门或其他职

能部门被视为消费者。然而，这只是一个非常简单的提供者-使用者模型。提供商可以在公
开市场上向其他企业、个人消费者销售服务，也可以是服务联盟的一部分，合作向消费者
组织提供服务。关键是，提供商角色中的组织清楚地了解其处于特定情况中的使用者，以
及相关服务关系中的其他利益相关者是谁。
ITIL 4 基金会
ITIL 故事：服务提供商
亨利：Axle 租车公司充当服务提供商。我们提供出租汽车。与此同时，其他组织，如机械
师和我们购买汽车的公司，充当 Axle 的服务提供商。
2.2.2 服务使用者
关键消息
接收服务时，组织将承担服务使用者的角色。
服务使用者是一种通用角色，用于简化服务关系结构的定义和描述。实际上，服务消费中
涉及更具体的角色，如客户、用户和赞助商。这些角色可以分开或组合。
定义
⚫ 客户定义服务要求并负责服务消费结果的人员。
⚫ 用户使用服务的人员。l 赞助授权服务消费预算的人。
例如，如果公司希望从无线运营商（服务提供商）为其员工购买移动电话服务，则各种使
用者角色的分配方式可能如下：
⚫ 首席信息官（CIO）和主要通信团队成员在分析公司员工的移动通信要

求、与无线运营商谈判合同以及监控运营商的移动通信时，将扮演客户的
角色。根据合同要求履行业绩。
⚫ 首席财务官（CFO）在审核拟议的服务安排并通过谈判批准合同成本

时，应担任发起人的角色。
⚫ 员工（包括 CIO、CFO 和通信团队成员）在根据商定的合同订购、接收和

使用移动电话服务时，将担任用户的角色。
ITIL 4 基金会
在另一个示例中，同一无线运营商（使用移动网络的人员）的个人私人使用者同时充当用
户、客户和赞助商。
在服务关系中确定这些角色非常重要，以确保有效的沟通和利益相关者管理。每个角色可
能有不同的，有时甚至是来自服务的期望，有时甚至是相互冲突的期望，以及不同的价值
定义。
ITIL 故事：Axle 的服务消费者
Su：我们最明显的服务消费者是租用我们的汽车、访问我们的办公室以及使用我们的网站
和预订应用程序的人和组织。例如，Yoshi 和 Faruq 是服务消费者，燃料食品也是如此。
他们也是我们的客户。
拉迪卡：用户是利用我们的服务的人。我们的租车用户是我们车辆的司机和乘客。
马可：赞助商是授权预算的人。对于 Axle 租车，我们的赞助商包括来自"燃料食品"的

Amelia，她批准她的组织的旅行预算，即使她自己也不旅行。
Henri：像 Yoshi 和 Faruq 这样的个人服务消费者批准他们自己的预算，定义他们的租车

要求，并驾驶汽车。因此，Yoshi 和 Faruq 充当赞助商、客户和用户。不过，有时他们可
能会与其他司机（朋友或家人）分享这次旅行。在这种情况下，他们的合同将包括其他用
户。
2.2.3 其他利益相关者
服务管理和 ITIL 的一个关键重点是组织通过服务关系与其消费者共同创造价值的方式。除

了使用者和提供者角色之外，通常还有许多其他利益相关者对价值创造非常重要。例如，
供应商组织、合作伙伴和供应商、投资者和股东、政府组织（如监管机构）和社会团体的
个人员工。
为了成功，甚至组织的持续存在，理解和管理与所有关键利益相关者群体的关系非常重
要。如果利益相关者对组织做什么或如何做不满意，则提供商与其消费者的关系可能会受
到威胁。
ITIL 4 基金会
产品和服务以多种方式为利益相关者创造价值。有些是相当直接的，如创收，而另一些则
更间接，如员工经验。表 2.1 提供了几种不同类型的利益相关者的价值示例。
表 2.1 不同类型的利益相关者的价值示例
利益相关者利益相关者价值示例
服务消费者取得的成果;成本和风险优化
服务提供商消费者的资金;业务发展;图像改进
服务提供商员工财政和非财政奖励;职业和职业发展;目的感
社会和社区就业;税收;组织对社区发展的贡献
慈善组织其他组织的财政和非财务捐款
股东财务收益，如股息;保证和稳定性
关于不同利益相关者价值管理的详细建议，请参阅其他 ITIL 4 出版物和补充材料（如

有）。
ITIL 4 基金会
2.3 产品和服务
当然，服务管理的核心部分是服务。现在将考虑服务的性质，并概述服务与产品之间的关
系。
2.3.1 配置资源以创造价值
关键消息
组织提供的服务基于一个或多个产品。组织拥有或有权访问各种资源，包括人员、信息和
技术、价值流和流程以及供应商和合作伙伴。产品是组织创建的这些资源的配置，对于其
客户来说可能很有价值。
定义
服务一种通过促进客户想要实现的结果来实现价值共同创造的方法，而客
户无需管理特定的成本和风险。
产品为向消费者提供价值而设计的组织资源的配置。
组织提供的每个产品都考虑到多个目标消费者群体的创建，并且产品将针对这些群体具有
吸引力并满足这些群体的需求而量身定制。产品并非独占一个使用者群体，可用于满足多
个不同组的需求。例如，软件服务可以作为"精简版"版本、单个用户或更全面的公司版本
提供。
产品通常很复杂，并且对使用者不完全可见。消费者实际看到的产品部分并不总是表示构
成产品并支持其交付的所有组件。组织定义消费者看到的产品组件，并针对目标消费者群
体进行定制。
ITIL 4 基金会
2.3.2 服务产品
关键消息
服务提供商以服务产品的形式向消费者提供服务，这些服务基于一个或多个产品描述一个
或多个服务。
定义：服务产品
一个或多个服务的描述，旨在满足目标使用者群体的需求。服务产品可能包括商品、资源
和服务操作。
服务产品可能包括：
⚫ 要提供给消费者的商品（例如，移动电话）。商品应该从供应商转移到消费
者，消费者负责他们未来的使用
⚫ 根据商定的条款和条件（例如，对移动网络或网络存储）授予或许可给使
用者的资源的访问权限。资源仍由提供商控制，并且仅在商定的服务消耗
期间由使用者访问
⚫ 为满足消费者需求（例如，用户支持）而执行的服务操作。这些操作由服
务提供商根据与使用者的协议执行。
表 2.2 显示了不同类型的服务产品示例。
服务提供给目标使用者组，这些组可以是服务提供商组织的内部或外部。可以基于同一产
品创建不同的产品，从而允许以多种方式使用它来满足不同消费群体的需求。例如，软件
服务可以作为有限的免费版本提供，也可以作为基于服务提供商的一个产品的综合付费版
本提供。
ITIL 4 基金会
ITIL 故事：Axle 的服务产品
Su： Axle 的服务服务包括租车和我们提供的各种选项，以满足不同的旅行需求。这些产

品包括折扣保险、忠诚计划以及免费旅游产品，包括瓶装水、纸巾、停车许可证徽章持有
人和婴儿座椅。
我们的消费者是一个多元化的群体，希望不同的旅行体验。例如，我们的企业消费者通常
不需要婴儿座椅或周末价格。同时，如果一些个人客户只在当地旅行，他们对免费机场汽
车收集不感兴趣。
我们所有的服务包括访问我们的网站和预订应用程序。
表 2.2 服务产品的组成部分
组件描述例子
货物提供给消费者手机
所有权转让给消费者物理服务器
消费者需要
未来使用的责任
访问资源所有权不会转让给消费者访问移动网络或网络存储
根据商定的条款和条件授予
消费者访问权限或许可给消
费者
消费者只能在约定的消费期
内，并按照其他商定的服务
条款访问资源
服务操作由服务提供商执行以满足消用户支持

费者需求
更换设备
根据与消费者的协议执行
ITIL 4 基金会
2.4 服务关系
要创造价值，组织必须不仅仅简单地提供服务。它还必须在服务关系中与消费者合作。
关键消息
两个或多个组织之间建立了服务关系，以共同创造价值。在服务关系中，组织将承担服务
提供商或服务使用者的角色。这两个角色不是互斥的，组织通常在任何给定时间提供和使
用许多服务。
定义
⚫ 服务关系服务提供者与服务使用者之间的合作。服务关系包括服务提供、
服务消耗和服务关系管理。
⚫ 服务提供组织为提供服务而执行的活动。服务提供包括：
⚫ 管理提供程序的资源，配置为提供服务
⚫ 用户获得这些资源，实现商定的服务操作，即服务级别管理和持续改
进。
服务提供还可包括供应货物。
⚫ 服务消耗组织为使用服务而执行的服务消耗活动。服务消耗包括：
⚫ 管理使用用户执行的服务 l 服务操作所需的使用者资源，包括利用提供
程序的资源，以及请求执行服务操作。服务消费也可以包括接收（获取）
货物。
⚫ 服务关系管理由服务提供商和服务消费者共同开展的活动，以确保基于商
定和可用的服务产品持续共同创造价值。
ITIL 4 基金会
2.4.1 服务关系模型
当提供程序提供服务时，它们会为服务使用者创建新资源，或修改其现有资源。例如：
l 培训服务提高了消费者员工的技能，宽带服务允许消费者的计算机进行
l 租车服务，使消费者的员工能够访问客户，软件开发服务为服务消费者创
造了一个新的应用程序。
服务使用者可以使用其新的或修改的资源创建自己的产品，以满足另一个目标使用者群体
的需求，从而成为服务提供商。这些交互如图 2.1 所示。
图 2.1 服务关系模型
ITIL 故事：Axle 的服务关系
Henri： Axle 与许多服务提供商和内部和外部消费者建立了服务关系。向 Axle 提供的一

些服务为业务创造了新的资源，例如汽车制造商向我们销售汽车。其他服务，例如我们的
内部汽车清洁团队为我们所做的工作，以及 Axle 以外的机械师，通过确保我们的汽车清
洁和功能，从而改变我们的现有资源。
Axle 可以在其他关系中利用这些资源，以租车的形式向消费者（即我们的客户）提供自己
的服务。
这些只是 Axle 具有的服务关系的几个示例。整个组织还有更多。
2.5 价值：结果、成本和风险
本节将重点介绍一个组织在服务提供者的作用下应如何评估其服务应做什么，以及如何提
供服务以满足消费者的需求。
ITIL 4 基金会
关键消息
实现预期的结果需要资源（因此需要成本），而且往往与风险相关。服务提供商帮助消费者
取得成果，并在此过程中承担一些相关风险和成本（参见第 2.3.1 节中的服务定义）。另一
方面，服务关系可能会带来新的风险和成本，在某些情况下，可能会对某些预期结果产生
负面影响，同时支持其他结果。
服务关系只有在具有比负面效应更积极的影响时才被视为有价值的，如图 2.2 所示。
图 2.2 实现价值：结果、成本和风险
结果，以及它们如何影响和受到其他因素的影响，现在将更详细地加以研究。
2.5.1 结果
作为服务提供商，组织生成有助于其消费者实现某些结果的输出。
ITIL 4 基金会
定义 l 输出某项活动的有形或无形交付成果。l 结果由一个或多个输出启用的
利益相关者的结果。
必须明确产出和结果之间的区别。例如，婚纱摄影服务的一个输出可能是一个
相册，其中精选的照片被巧妙地排列。但是，服务的结果是
保存记忆和夫妇和他们的家人和朋友的能力，很容易回忆这些记忆，通过看专辑。
根据提供者和消费者之间的关系，提供商可能难以完全理解消费者想要实现的结果。在某
些情况下，他们将共同努力，确定预期的结果。例如，内部 IT 或人力资源部门的业务关
系经理（BRM）可能会定期与客户交谈，讨论他们的需求和期望。在其他情况下，消费
者非常明确地表达了他们的期望，并且提供商希望他们这样做，例如当向广泛的消费者群
体提供标准化服务时。这就是移动运营商、宽带服务提供商和运输公司通常的运作方式。
最后，一些服务提供商预测甚至创造对某些结果的需求，形成其服务的目标群体。这种服
务可能通过创新服务来实现，满足消费者以前甚至没有意识到的需求。这方面的示例包括
社交网络或智能家居解决方案。
ITIL 故事：产出和结果
亨利：在 Axle，我们的主要产出是一辆清洁、适道和保养良好的汽车。
苏：对于我们的服务消费者来说，结果包括方便和实惠的旅行，并满足各种需求。这包括
自驾度假、客户现场访问和探亲访友。
ITIL 4 基金会
2.5.2 成本
定义：成本
用于特定活动或资源的资金金额。
从服务使用者的角度来看，服务关系涉及两种类型的成本：
⚫ 服务从使用者中删除的成本（价值主张的一部分）。这可能包括员工、技术
和其他资源的成本，消费者不需要提供这些资源
⚫ 服务给消费者带来的成本（服务消耗成本）。消耗服务的总成本包括服务提
供商收取的价格（如果适用），以及其他费用，如员工培训、网络使用成
本、采购等。一些消费者将这种情况描述为他们为了消费服务而必须"投资"
的东西。
当使用者评估他们希望服务创建的值时，将考虑这两种类型的成本。为了确保对服务关系
做出正确的决策，必须充分理解这两种类型的成本。
从供应商的角度来看，对提供服务的成本有充分和正确的了解至关重要。提供者需要确保
服务在预算限制范围内提供，并满足组织的财务期望（见第 5.1.11 节）
。
2.5.3 风险
定义：风险
可能造成伤害或损失，或使目标更难实现的可能事件。也可以定义为结果的不确定性，并
可用于测量积极结果和负结果的概率。
ITIL 4 基金会
与成本一样，服务消费者也关注两种类型的风险：
⚫ 服务从使用者中移除的风险（价值主张的一部分）。这些可能包括使用者的
服务器硬件故障或缺乏员工可用性。在某些情况下，服务可能只会降低消
费者的风险，但消费者可能会确定这种减少足以支持价值主张
⚫ 服务给消费者带来的风险（服务消耗的风险）。例如，服务提供商停止交易
或遇到安全漏洞。
提供商有责任代表消费者管理详细的风险水平（参见第 5.1.10 节）。这应该根据对消费者

和提供者最重要的内容的平衡来处理。消费者通过以下方式降低风险做出贡献：
⚫ 积极参与服务要求的定义和对其所需成果的澄清
⚫ 清楚地传达适用于服务的关键成功因素（CSF）和约束
⚫ 确保提供商在整个服务关系中访问使用者的必要资源。
2.5.4 公用事业和保修
为了评估服务或服务产品是否有助于消费者所需的结果，从而为他们创造价值，应评估服
务的整体效用和保修。
定义
⚫ 实用程序产品或服务提供的满足特定需求的功能。实用程序可以概括为"服
务的作用"，并可用于确定服务是否"适合用途"。要具有实用程序，服务必
须支持使用者的性能或从使用者中删除约束。许多服务同时执行这两种操
作。
⚫ 保修保证产品或服务将满足商定的要求。保修可以概括为"服务如何执行"，
并可用于确定服务是否"适合使用"。保修通常与服务消费者的需求相关的服
务级别相关。这可能基于正式协议，或者可能是营销信息或品牌形象。保
修通常涉及服务的可用性、容量、安全级别和连续性等领域。如果满足所
有已定义和商定的条件，服务可能会提供可接受的保证或"保证"。
ITIL 4 基金会
对服务的评估必须考虑到成本和风险对公用事业和保修的影响，以便全面了解服务的可行
性。
公用事业和保修对于服务都至关重要，有助于实现预期结果，从而有助于创造价值。例
如，休闲主题公园可能提供许多令人兴奋的游乐设施，旨在为公园游客提供惊险的体验
（实用），但如果大量游乐设施因机械困难而经常无法使用，则公园不会履行保修（不适合
使用），消费者将得不到预期价值。同样，如果游乐设施始终在广告时段启动和运行，但它
们没有提供访客期望的兴奋程度的功能，则即使保修已足够，实用程序也无法实现。同
样，消费者不会收到预期值。
ITIL 故事：一个新的供应商（克雷格的清洁）
苏：Axle 最近的客户满意度调查一直显示 low 汽车清洁度评级较低。这阻碍了我们客户的

旅行体验，是重复预订率低的一个因素。
Henri： Axle 租车公司决定将所有车辆的清洁外包给服务提供商。以前，我们的车队由内

部部门进行清洁。维护设备、更新名册和管理僵化的劳动力的成本和努力是不可持续的。
请务必了解，外包任何任务或服务的风险是组织失去技能和能力。然而，汽车清洁是一项
需要专业设备以及灵活和积极进取的员工队伍的服务。持续投资这项服务是不利于 Axle。
从表面上看，外包可能比使用内部资源给组织造成更大的成本。最初，这可能是事实;然
而，随着时间的推移，以及正确管理，外包服务应该对组织和供应商都有好处。Axle 的好
处是我们可以专注于核心业务。毕竟，我们不是一家清洁公司。
马可：外包总是有利弊的。让我们来看看引入和消除的结果、成本和风险。
优点缺点
用户将对我们的汽车的清洁度感到满意 Axle 将失去提供汽车清洁服务的机会
Axle 不再需要维护自己的清洁设施 Axle 需要支付清洁公司
清洁过程中汽车损坏的风险将从 Axle 上清 Axle 将失去提供汽车清洁服务的机会

除。这种风险现在将由供应商及其保险公
司承担
ITIL 4 基金会
用户将对我们的汽车的清洁度感到满意 Axle 将严重依赖外部清洁公司，其员工将

可以广泛进入我们的办公场所
苏：通过与专业清洁组织合作，Axle 可以专注于为我们的用户提供更好的服务。它还将有
助于优化我们的成本，增加组织的价值。
克雷格是克雷格清洁公司的老板。克雷格有条不紊，可靠，深受其员工的尊重。克雷格和
他的团队渴望为 Axle 提供高标准的旅行体验的愿景做出贡献。
克雷格：Axle 租车公司决定外包其汽车清洁服务，克雷格的清洁被选中接受。我的组织现
在负责整个 Axle 车队的清洁。
Henri：克雷格的清洁服务只是 Axle 客户体验的一个组成部分。清洁汽车是我们整体服务

的一个输出，它们直接有助于客户的旅行体验。这有助于 Axle 的客户实现其成果。
苏：克雷格的清洁工作做得很好！汽车从未如此清洁，我们对汽车清洁度的客户满意度评
价也在稳步上升。
Axle 和 Craig 的清洁工作一起完成清洁计划，重点是高峰时段的汽车清洁周转时间。

Axle 负责及时向 Craig 及其团队提供可能影响此时间表的任何更改的通知。例如，Axle
可能需要根据新的服务产品（如 Marco 正在开发的服务产品）来扩展其清洁要求。
Marco：Axle 的目标是成为一家更环保的公司，帮助环境。我们希望克雷格的清洁支持我
们这个目标，并致力于相同的可持续增长，因为我们。
2.6 摘要
本章介绍了服务管理中的关键概念，特别是价值和价值共同创造的性质、组织、产品和服
务。它探讨了服务提供者和消费者以及所涉及的各利益攸关方之间往往复杂的关系。本章
还介绍了消费者价值的关键组成部分：收益、成本和风险，以及了解客户在设计和提供服
务时的需求的重要性。这些概念将在接下来的几章的基础上，并指导以实际和灵活的方式
应用它们。
ITIL 4 基金会
3 服务管理的四个维度
上一章概述了服务管理的关键概念。一个组织的目标是为其利益攸关方创造价值，这是通
过提供和使用服务来实现的。ITIL SVS 描述了组织的各个组件和活动共同创建此值的方
式。但是，在进一步探讨这一点之前，必须引入服务管理的四个方面。这些维度与 SVS 的
所有元素相关，并影响 SVS 的所有元素。
为了达到预期成果并尽可能有效地开展工作，各组织应考虑其行为的所有方面。然而，在
实践中，各组织往往过于注重其倡议的一个领域，而忽视了另一个领域。例如，流程改进
可以在计划时不考虑所涉及的人员、合作伙伴和技术，或者可以实施技术解决方案，而不
必对他们应该支持的过程或人员进行适当照顾。服务管理有多种方面，在孤立考虑时，这
些方面都不足以产生所需的结果。
关键消息
为了支持服务管理的整体方法，ITIL 定义了四个维度，它们对于以产品和服务的形式为客
户和其他利益相关者有效、高效地促进价值至关重要。它们是：
l 组织与人员 l 信息与技术 l
合作伙伴和供应商 l 价值流和
流程。
这四个维度表示与整个 SVS 相关的视角，包括整个服务价值链和所有 ITIL 实践。四个维

度受到一些外部因素的限制或影响，这些因素通常不受 SVS 的控制。
图 3.1 中表示了四个维度及其之间的关系。
ITIL 4 基金会
图 3.1 服务管理的四个维度
未能正确处理所有四个维度可能会导致服务无法交付，或不符合质量或效率的期望。例
如，如果不能从整体上考虑价值流和流程维度，可能会导致浪费工作、工作重复，或者更
糟的是，工作与组织其他方面的工作相冲突。同样，忽视合作伙伴和供应商层面可能意味
着外包服务与组织的需求不一致。四个维度没有锐边界，可能会重叠。它们有时会以不可
预知的方式交互，具体取决于组织运作的复杂性和不确定性程度。
需要注意的是，服务管理的四个维度适用于所有正在管理的服务，以及一般 SVS。因此，
必须为每个服务考虑这些观点，并在各级管理和改进 SVS 时处理每一个观点。
下面概述了四个维度，其他 ITIL 4 出版物中提供了关于解决实际维度的更详细的指南。
ITIL 故事：服务管理的四个维度
Henri：作为一个 IT 团队，我们负责 Axle 租车公司的信息和技术。但是，有效的 IT 管理

不仅仅是管理技术。我们还必须考虑参与 Axle 租车服务的更广泛组织和人员、我们与合
作伙伴和供应商的关系以及我们使用的价值流、流程和技术。
ITIL 4 基金会
3.1 组织和人员
服务管理的第一个方面是组织和人员。
关键消息
组织的复杂性正在增加，必须确保组织的组织结构和管理方式及其作用、责任以及权威和
沟通系统得到明确定义和支持其总体战略和操作模式。
单靠正式确立的结构或权力制度无法保证组织的效力。本组织还需要一种支持其目标的文
化，以及其工作人员的能力和能力水平。组织领导者必须倡导和倡导以理想方式工作的价
值观。然而，最终，组织开展工作的方式创造了共同的价值观和态度，随着时间的推移，
这些价值观和态度被视为组织的文化。
例如，在鼓励其成员提出问题和上报问题并在任何问题对客户产生影响之前促进纠正措施
的组织中，促进信任和透明文化是很有用的。采用 ITIL 指导原则是建立健康组织文化的良
好起点（参见第 4.3 节）。
人员（无论是客户、供应商的员工、服务提供商的员工还是服务关系中的任何其他利益相
关者）都是此维度的关键要素。不仅要注意团队或个人成员的技能和能力，还要关注管理
和领导风格，以及沟通和协作技能。随着实践的发展，人们还需要更新他们的技能和能
力。人们越来越了解他们的专长和角色与组织中其他人之间的接口，以确保适当的协作和
协调水平。例如，在 IT 的某些领域（如软件开发或用户支持）中，人们越来越认识到，
每个人都应该对组织的其他领域具有广泛的一般知识，并结合在某些领域的深度专业化。
组织中的每个人应清楚地了解他们对为组织、其客户和其他利益相关者创造价值的贡献。
促进注重价值创造是打破组织孤岛的有效方法。
服务的组织和人员层面包括角色和责任、正式组织结构、文化以及所需的人员配置和能
力，所有这些都与服务的创建、交付和改进有关。在查看与 SVS 相关的此维度时，重点应
放在同一方面，但在充当服务提供者的组织上下文中。
ITIL 4 基金会
ITIL 故事：Axle 的组织和人员
Henri：Axle 租车服务的组织和人员包括我的 IT 团队和组织内的其他团队，如采购、人力

资源和设施。
3.2 信息和技术
服务管理的第二个方面是信息与技术。与其他三个维度一样，信息和技术既适用于服务管
理和所管理服务。
关键消息
当应用于 SVS 时，信息和技术层面包括管理服务所需的信息和知识，以及所需的技术。它

还纳入了 SVS 的不同组成部分之间的关系，例如活动和做法的投入和产出。
有关信息和技术在服务管理中的作用的详细指导，请参阅其他 ITIL 出版物。
支持服务管理的技术包括但不限于工作流管理系统、知识库、库存系统、通信系统和分析
工具。服务管理日益受益于技术发展。人工智能、机器学习和其他认知计算解决方案在所
有级别都使用，从战略规划和产品组合优化到系统监控和用户支持。使用移动平台、云解
决方案、远程协作工具、自动测试和部署解决方案已成为服务提供商的常见做法。
在特定 IT 服务的上下文中，此维度包括在提供服务和使用过程中创建、管理和使用的信
息，以及支持和启用该服务的技术。具体的信息和技术取决于所提供服务的性质，通常涵
盖所有级别的 IT 体系结构，包括应用程序、数据库、通信系统及其集成。在许多领域，IT
服务使用最新的技术发展，如区块链、人工智能和认知计算。这些服务为早期采用者提供
了业务差异化潜力，尤其是在竞争激烈的行业。其他技术解决方案（如云计算或移动应
用）已成为全球许多行业的常见做法。
ITIL 4 基金会
关于这一方面的信息部分，各组织应考虑以下问题：
⚫ 服务管理哪些信息？
⚫ 交付和管理服务需要哪些支持信息和知识？
⚫ 如何保护、管理、存档和处置信息和知识资产？
对于许多服务来说，信息管理是实现客户价值的主要手段。例如，人力资源服务使组织能
够访问和维护有关其员工、其雇佣关系和福利的准确信息，从而促进客户创造价值，而无
需将私人信息暴露给未经授权的方。网络管理服务通过维护和提供有关组织活动网络连接
和利用率的准确信息，从而促进用户的价值创造，从而允许其调整其网络带宽容量。信息
通常是业务客户使用的大多数 IT 服务的关键输出。
此维度的另一个关键考虑因素是不同服务和服务组件之间如何交换信息。需要充分理解和
持续优化各种服务的信息体系结构，同时考虑到所提供信息的可用性、可靠性、可访问
性、及时性、准确性和相关性等标准。用户和服务之间交换。
信息管理的挑战，如安全和法规遵从性要求带来的挑战，也是这一方面的重点。例如，一
个组织可能受欧洲联盟的《一般数据保护条例》
（GDPR）的约束，该条例影响其信息管理
政策和做法。其他行业或国家可能有条例，对跨国公司数据的收集和管理施加限制。例
如，在美国，1996 年的《健康保险可移植性和责任法》为保护在美国收集的医疗信息提
供了数据隐私和安全规定。
如今，大多数服务都基于 IT，并且严重依赖 IT。在考虑用于产品或服务的规划、设计、过

渡或操作的技术时，组织可能会提出的问题包括：
⚫ 此技术是否与组织及其客户的当前体系结构兼容？组织及其利益相关者使
用的不同技术产品如何协同工作？新兴技术（如机器学习、人工智能和物
联网）如何破坏服务或组织？
⚫ 此技术是否引发了组织的政策和信息安全控制或其客户的政策和信息安全
控制的任何法规或其他合规性问题？
⚫ 这是一种在可预见的将来继续可行的技术吗？组织是否愿意接受使用老化
技术的风险，或接受新兴或未经证实的技术的风险？
⚫ 此技术是否符合服务提供商或其服务使用者的策略？
⚫ 组织是否拥有支持和维护该技术的合适员工和供应商的技能？
⚫ 此技术是否具有足够的自动化功能，以确保能够高效地开发、部署和操
作？
⚫ 此技术是否提供了可能用于其他产品或服务的其他功能？
ITIL 4 基金会
⚫ 此技术是否给组织带来了新的风险或约束（例如，将其锁定在特定供应商
中）？
组织的文化可能会对它选择使用的技术产生重大影响。有些组织可能比其他组织更感兴趣
的是处于技术进步的前沿。同样，一些组织的文化可能侧重于一种更传统的工作方式。一
家公司可能乐于利用人工智能技术，而另一家公司可能几乎还没有准备好使用先进的数据
分析工具。
业务的性质也会影响它使用的技术。例如，与政府客户有重大业务的公司可能对某些技术
的使用有限制，或者存在必须解决的更高安全问题。其他行业，如金融或生命科学，也受
到技术使用的限制。例如，在处理敏感数据时，它们通常不能使用开源和公共服务。
ITIL 故事：Axle 的信息和技术
Henri：Axle 租车的信息和技术维度代表团队创建和管理的信息。它还包括支持和启用我
们的服务的技术。应用和数据库，如我们的预订应用程序和财务系统也是信息和技术维度
的一部分。
定义：云计算
支持按需网络访问可配置计算资源的共享池的模型，只需最少的管理工作量或提供程序交
互即可快速提供这些资源。
ITIL 4 基金会
现代世界中的 ITSM：云计算
多年来，ITSM 一直关注用户和客户的价值，这种关注通常是与技术无关：重要的不是技
术，而是它为客户创造的机会。尽管这在很大程度上是一种完全可以接受的方法，但组织
不能忽视新的体系结构解决方案和一般技术的发展。云计算已成为 IT 领域的一种架构转
变，带来了新的机遇和风险，组织必须以对自己、客户和其他利益相关者最有利的方式对
此做出反应。
云计算的主要特点包括：
⚫ 按需可用性（通常是自助服务）l 网络访问（通常是 Internet 访问）l l
资源池（通常在多个组织中）l l 快速弹性（通常是自动）l l 测
量服务（通常从服务消费者的角度来看）。
在 ITSM 环境中，云计算会更改服务体系结构以及服务使用者、服务提供商及其合作伙伴
之间的责任分配。它尤其适用于内部服务提供商，即组织的内部 IT 部门。在典型情况
下，采用云计算模型：
⚫ 将以前由服务提供商管理的某些基础结构替换为合作伙伴的云服务
⚫ 减少或消除对基础设施管理专业知识和服务提供商资源的需求
⚫ 将服务监控的重点从内部基础设施转移到合作伙伴的服务
⚫ 改变服务提供商的成本结构，删除具体的资本支出，引入新的运营支出，
并需要适当管理这些支出
⚫ 对网络可用性和安全性引入更高的要求 l 引入了新的安全性和合规性风
险和要求，适用于提供云服务的服务提供商及其合作伙伴
⚫ 为用户提供通过简单的标准请求（甚至不带任何请求）使用自助服务扩展
服务消耗的机会。
所有这些都影响多个服务提供商的做法，包括但不限于：
⚫ 服务级别管理 l 测量和报告 l 信息安全管理 l 服务连续性管理 l
供应商管理 l 事件管理 l 问题管理 l 服务请求管理 l 服务配
置管理。
云计算的另一个重要影响是计算资源的弹性，即云基础架构可以显著更快地部署新的和更
改的服务，从而支持高速服务交付。能够以与新应用程序相同的速度配置和部署计算资
ITIL 4 基金会
源，是 DevOps 和类似计划取得成功的重要先决条件。这支持现代组织加快其服务上市和

数字化步伐。
考虑到云计算对组织的影响，在组织的战略级别（从治理到运营）涉及各级利益相关者，
必须做出有关使用此模型的决策。
3.3 合作伙伴和供应商
服务管理的第三个方面是合作伙伴和供应商。每个组织和每个服务在某种程度上都依赖于
其他组织提供的服务。
关键消息
合作伙伴和供应商维度包括组织与参与服务设计、开发、部署、交付、支持和/或持续改进
服务的其他组织的关系。它还纳入了组织与其合作伙伴或供应商之间的合同和其他协议。
组织之间的关系可能涉及不同程度的整合和形式。这包括明确职责分离的正式合同，以及
各方共同目标和风险的灵活伙伴关系，以及协作达到预期的结果。表 3.1 显示了组织之间
关系的一些示例。
表 3.1 组织间的关系
合作形式输出输出的重从取得成果的责正式程度例子
任
商品供应供应的货供应商客户正式供应合同/ 计算机和电

物发票话的采购
ITIL 4 基金会
服务交付提供的服供应商客户正式协议和灵活云

务案例计算
（平台即服
务的基础设
施）
服务伙伴关共同创建提供商与客提供商与客户之共同目标、通用员工入职（人

系的值户之间共享间共享协议、灵活的案力资源、设施
例安排和共享）
IT）
请注意，表 3.1 中描述的合作形式不是固定的和独特的，而是作为一个尺度存在的。作为

服务提供商的组织将具有这种规模的职位，这因客户关系的战略和目标而异。同样，当一
个组织充当服务消费者时，它所发挥的作用将取决于其采购和供应商管理的战略和目标。
在使用合作伙伴和供应商时，组织的战略应基于其目标、文化和业务环境。例如，一些组
织可能认为，将注意力集中在发展某些核心能力上，利用合作伙伴和供应商提供其他需
求，将最有利于它们。其他组织可以选择尽可能少地依靠自己的资源，利用合作伙伴和供
应商。当然，这两种相反的方法之间有许多差异。
组织可用于解决合作伙伴和供应商维度的一种方法是服务集成和管理。这包括使用专门设
立的集成商，以确保服务关系得到适当的协调。服务集成和管理可以保存在组织内，也可
以委派给受信任的合作伙伴。
在使用供应商时可能影响组织战略的因素包括：
⚫ 有些组织可能更愿意专注于其核心能力，将非核心支持职能外包给第三方;
另一些组织可能更愿意保持尽可能自给自足，保持对所有重要职能的完全
控制。
⚫ 企业文化有些组织历来倾向于一种方法而不是另一种方法。没有令人信服
的理由，长期的文化偏见是难以改变的。
⚫ 资源稀缺如果所需的资源或技能集中短缺，则服务提供商可能很难在不与
供应商接洽的情况下获得所需的资源。
⚫ 成本问题决策可能受服务提供商是否认为从供应商处获取特定要求更经济
的影响。
⚫ 主题专业知识服务提供商可能认为，使用已在所需领域拥有专业知识的供
应商的风险较低，而不是试图内部开发和维护主题专业知识。
ITIL 4 基金会
⚫ 外部限制政府监管或政策、行业行为准则以及社会、政治或法律限制可能
会影响组织的供应商战略。
⚫ 需求模式客户活动或服务需求可能是季节性的，或表现出高度的可变性。
这些模式可能会影响组织使用外部服务提供商来处理可变需求的程度。
在过去十年中，提供技术资源（基础设施）或能力（平台、软件）"即服务"的公司出现爆
炸式发展。这些公司将商品和服务捆绑到单个产品中，这些产品可作为一种实用程序使
用，通常视为运营支出。这免除了公司对昂贵的基础设施和软件资产的投资，这些资产需
要作为资本支出核算。
ITIL 4 基金会
ITIL 故事：Axle 的合作伙伴和供应商
Henri：Axle 的合作伙伴和供应商包括 Go Go 燃气和克雷格清洁等供应商，以及互联网服

务提供商和开发商。
3.4 价值流和流程
服务管理的第四个维度是价值流和流程。与其他维度一样，值流和流程维度通常适用于
SVS 以及特定产品和服务。在这两种情况下，它定义实现商定目标所需的活动、工作流、
控制和程序。
关键消息
应用于组织及其 SVS，价值流和流程维度涉及组织的各个部分如何以集成和协调的方式工
作，以便通过产品和服务创造价值。该维度侧重于组织开展哪些活动以及如何组织这些活
动，以及组织如何确保有效和高效地为所有利益相关者创造价值。
ITIL 为作为服务提供商的组织提供了一个运营模式，涵盖有效管理产品和服务所需的所有
关键活动。这称为 ITIL 服务价值链（参见第 4.5 节）。
服务价值链运营模式通用;然而，在实践中，它可以遵循不同的模式。价值链操作中的这些
模式称为价值流。
3.4.1 服务管理的价值流
模板版权 TSO 页面35的

237
ITIL 4 基金会
关键消息
价值流是组织用于创建产品和服务并将其交付给服务使用者的一系列步骤。价值流是组织
的价值链活动的组合（有关价值链活动的更多详细信息，请参阅第 4.5 节，有关价值流示
例的附录 A）
。
定义：价值流
组织承诺为消费者创建产品和服务并交付产品和服务的一系列步骤。
识别和了解组织的各种价值流对于提高其整体绩效至关重要。围绕价值流构建组织的服务
和产品组合，可以清楚地了解其提供的内容和方式，并持续改进其服务。
组织应检查他们如何执行工作，并映射他们可以识别的所有价值流。这将使他们能够分析
其当前状态，并查明工作流程和非增值活动的任何障碍，即浪费。应消除浪费活动以提高
生产力。
在整个服务价值链中可以找到增加增值活动的机会。这些可能是新的活动或对现有活动的
修改，这可以使组织更有成效。价值流优化可能包括流程自动化或采用新兴技术和工作方
法，以提高效率或增强用户体验。
价值流应由组织为其每个产品和服务定义。根据组织的战略，可以重新定义价值流，以响
应不断变化的需求和其他情况，或长时间保持稳定。无论如何，应不断改进它们，以确保
组织以最佳方式实现其目标。其他 ITIL 4 出版物将更详细地介绍价值流映射。
3.4.2 流程

237
ITIL 4 基金会
关键消息
流程是将输入转换为输出的一组活动。流程描述为实现目标而完成的任务，而定义良好的
流程可以提高组织内部和跨组织的工作效率。它们通常详细介绍过程，其中概述了参与流
程的人员，以及解释如何执行这些操作的工作说明。
定义：流程
一组相互关联或交互的活动，将输入转换为输出。进程需要一个或多个定义的输入，并将
其转换为定义的输出。进程定义操作的顺序及其依赖项。
相同的结构（价值链、价值流、流程、流程、流程和工作说明）适用于特定服务：要成功
创建、交付和改进服务，需要回答以下问题：
⚫ 什么是服务的通用交付模型，服务如何工作？
⚫ 交付服务的约定输出涉及哪些价值流？
⚫ 谁执行所需的服务操作？
这些问题的答案因服务的性质和体系结构而异。
ITIL 故事：Axle 的价值流和流程
Radhika：值流和流程维度表示在 Axle 内执行的一系列活动。价值流帮助 Axle 识别浪费活

动，并消除阻碍其生产力的障碍。

237
ITIL 4 基金会
3.5 外部因素
服务提供商不单独运行。它们受到许多外部因素的影响，在动态和复杂的环境中工作，这
些环境可能表现出高度的波动性和不确定性，并对服务提供者的工作方式施加限制。为了
分析这些外部因素，使用了 PESTLE（或 PESTEL）模型等框架。PESTLE 是限制或影响服
务提供商运营方式的政治、经济、社会、技术、法律和环境因素的缩写。
这些因素共同影响组织如何配置其资源并解决服务管理的四个方面。例如：
⚫ 政府和社会对无害环境产品和服务的态度可能导致本组织在满足外部期望
的工具和技术方面投入更多。组织可以选择与其他组织（或外部提供商的
源服务）合作，这些组织可以展示环保证书。例如，一些公司发布产品环
境报告，描述其

237
ITIL 4 基金会
产品在气候变化、安全材料和其他资源方面的政策表现。
⚫ 经济和社会因素可能会影响组织创建同一产品的多个版本，以解决显示不
同购买模式的各种消费群体。一个例子是音乐和视频流媒体服务，其中许
多服务有免费套餐（带广告），高级套餐（不含广告），在某些情况下，还
有"家庭计划"，允许多个个人配置文件在一个付费帐户下。
⚫ 数据保护法律或法规（如 GDPR）改变了公司收集、处理、访问和存储客
户数据的方式，以及它们与外部合作伙伴和供应商的合作方式。
3.6 摘要
这四个方面代表了服务管理的整体方法，组织应确保每个维度之间有一个重点平衡。还应
考虑外部因素对四个维度的影响。所有四个方面和影响这些因素的外部因素都应随着它们
的发展而加以处理，并考虑新出现的趋势和机会。必须从所有四个维度考虑组织的 SVS，
因为未能充分解决或考虑一个维度或外部因素可能导致产品和服务不理想。
ITIL 的故事：平衡四个维度
Marco：为了使 Axle 的服务尽可能有效，我们使用人员、团队、价值流和工作方式的最

佳组合。现在，我们采用混合式服务管理方法，将 DevOps、设计思维和敏捷融入产品开
发中。我们还使用机器人、AI 和机器学习等新技术，力求高效和精益，并尽可能自动化。
4 ITIL 服务价值系统
4.1 服务价值系统概述
为了使服务管理正常运行，它需要作为一个系统工作。ITIL SVS 描述了对该系统的输入

（机会和需求）、该系统的元素（组织治理、服务管理、持续改进以及组织的能力和资源）
和产出（实现组织目标以及组织、其客户和其他利益相关者的价值）。

237
ITIL 4 基金会
关键消息
ITIL SVS 描述了组织的所有组件和活动如何作为一个系统协同工作，以实现价值创造。每

个组织的 SVS 都与其他组织建立了接口，形成了一个生态系统，从而反过来可以为这些
组织、其客户和其他利益相关者带来价值。
SVS 的关键投入是机会和需求。机会是为利益相关者增加价值或以其他方式改善组织的选
项或可能性。需求是内部和外部消费者对产品和服务的需求或愿望。SVS 的结果是价值，
即感知到的东西的好处、有用性和重要性。ITIL SVS 可以为广泛的利益相关者群体创造许
多不同类型的价值。
ITIL SVS 包括以下组件：
⚫ 指导原则建议，无论组织的目标、战略、工作类型或管理结构如何变化，
都可以在所有情况下指导组织。
⚫ 治理组织被指导和控制的手段。
⚫ 服务价值链组织为向消费者提供有价值的产品或服务并促进价值实现而执
行的一组相互关联的活动。
⚫ 练习为执行工作或完成目标而设计的组织资源集。
⚫ 持续改进定期组织活动在所有级别执行，以确保组织绩效持续满足利益相
关者的期望。ITIL 4 支持 ITIL 持续改进模式的持续改进。
SVS 的目的是确保组织通过使用和管理产品和服务，不断与所有利益相关者共同创造价
值。SVS 的结构如图 4.1 所示。图的左侧显示了从内部和外部来源馈入 SVS 的机会和需
求。右侧显示为组织、其客户和其他利益相关者创建的价值。

237
ITIL 4 基金会
图 4.1 ITIL 服务价值系统
ITIL SVS 描述了组织的所有组件和活动如何作为一个系统协同工作，以实现价值创造。随

着情况的变化，这些组件和活动以及组织的资源可以灵活配置和重新配置，但这需要整合
和协调活动、实践、团队、权威和责任，以及各方要真正有效。
组织在尝试以共同愿景高效工作或变得更加敏捷和弹性时，可能面临的最大挑战之一是组
织孤岛的存在。组织孤岛可以以多种方式和许多不同的原因形成。Silos 可以抵制更改，并
可阻止轻松访问整个组织中存在的信息和专业知识，从而提高效率并增加成本和风险。
Silos 还使不同组之间的通信或协作更加困难。
孤立的组织不能迅速采取行动，利用机会或优化整个组织的资源使用。由于可见性有限和
许多隐藏的议程，它往往无法就更改做出有效的决策。实践也可能成为孤岛。许多组织实
施了组织变更管理或事件管理等实践，但与其他实践没有明确接口。所有实践都应具有多
个接口。做法之间的信息交流应在工作流的关键点触发，对组织的正常运作至关重要。
ITIL SVS 的体系结构特别支持灵活性，并阻止孤立工作。服务价值链活动与 SVS 中的做

法并不形成固定、僵化的结构。相反，它们可以组合在多个价值流中，以满足组织在各种
方案中的需求。此发布提供了服务值流的示例，但没有一个是明确或规范的。组织应该能
够以灵活、安全、高效的方式定义和重新定义其价值流。这就要求在组织各级开展持续改
进活动;ITIL 持续改进模型有助于构建此活动。最后，ITIL 指导原则决定了组织的持续改进
和整体运作。指导原则为整个组织之间的共享文化奠定了基础，从而支持团队内部和团队
之间的协作与合作，并消除了以前孤岛提供的限制和控制的需要。
借助这些组件，ITIL SVS 支持许多工作方法，如敏捷、DevOps 和精益（见术语表），以

及传统的流程和项目管理，以及灵活的面向价值的运营模型。

237
ITIL 4 基金会
An organization can take any number of forms, including, but not limited to, sole
trader, company, corporation, firm, enterprise, authority, partnership, charity or
institution, or any part or combination thereof, whether incorporated or not, and
be either 公共或私人。这意味着 SVS 的范围可以是整个组织或该组织的较小子集。为了
从 SVS 中实现最大值并妥善解决组织孤岛问题，最好将整个组织包括在作用域中，而不
是将整个组织包含在作用域中。
本章的其余部分将探讨 SVS 的每个元素。
组织敏捷性和组织弹性
组织要取得成功，就必须实现组织敏捷性，以支持内部变革，以及组织抵御甚至在不断变
化的外部环境中茁壮成长的能力。还必须将组织视为组织更大生态系统的一部分，所有这
些组织都提供、协调和消费产品和服务。
组织敏捷性是组织快速、灵活、果断地移动和适应以支持内部变革的能力。这些可能包括
对组织范围的更改、合并和收购、改变组织实践或需要不同技能或组织结构的技术以及改
变与合作伙伴和供应商的关系。
组织弹性是组织从外部角度预测、准备、应对和适应增量变化和突然中断的能力。外部影
响可以是政治、经济、社会、技术、法律或环境。如果不对本组织的优先事项和目标有共
同的理解，就不可能实现复原力，即使外部环境发生变化，本组织也能确定方向并促进协
调。
ITIL SVS 提供了实现组织敏捷性和弹性以及促进采用强大的统一方向、注重价值和被组织

中的每个人理解的方法。它还使整个组织不断改进。
4.2 机会、需求和价值

237
ITIL 4 基金会
关键消息
机会和需求触发 ITIL SVS 中的活动，这些活动导致价值的创造。机会和需求总是进入系

统，但组织不会自动接受所有机会或满足所有需求。
机会是为利益相关者增加价值或以其他方式改善组织的选项或可能性。这些机会可能还没
有需求，但它们仍然可以触发系统内的工作。组织应优先考虑具有改进机会的新服务或更
改的服务，以确保其资源得到正确分配。
需求代表内部和外部客户对产品和服务的需求或需求。
第 2 章可以找到价值的定义以及不同利益相关者的价值构成。
4.3 ITIL 指导原则
关键消息
指导原则是指导组织在任何情况下，无论其目标、战略、工作类型或管理结构的变化。指
导原则是普遍和持久的。
此处定义的指导原则体现了 ITIL 和总体服务管理的核心信息，支持各种类型和各级的成功

行动和良好决策。在采用服务管理方法并根据自身特定需求和环境调整 ITIL 指导时，它们
可用于指导组织开展工作。指导原则鼓励和支持各组织在各级不断改进。
这些原则还反映在许多其他框架、方法、标准、哲学和/或知识体中，如精益、敏捷、
DevOps 和 COBIT。这允许组织有效地将多种方法的使用集成到服务管理的整体方法中。
指导原则普遍适用于几乎所有倡议和与利益攸关方群体的所有关系。例如，第一项原则，
注重价值，可以（而且应该）不仅适用于服务消费者，而且适用于所有相关利益干系人及
其各自的价值定义。

237
ITIL 4 基金会
表 4.1 对指导原则有高级别介绍。本章稍后将介绍每个原则的其他详细信息。表 4.1 指

导原则概述
指导原则描述
注重价值组织所做的一切需要直接或间接地映射，以便为利益相关者带来价
值。
注重价值原则包括许多观点，包括客户和用户的体验。
从现在开始不要从头开始，在不考虑已经可以利用的方面构建新事物。在目前
的服务、进程、方案、项目和人员中，可能有很多可用于创造预期
结果的人。
应直接调查和观察当前状态，以确保完全理解。
通过反馈迭代进度不要试图同时做所有的事情。即使是巨大的倡议也必须迭代地完
成。通过将工作组织成可以及时执行和完成的更小、可管理的部
分，更容易对每项工作保持更集中的关注。
在每个迭代之前、整个迭代和之后使用反馈将确保操作集中且适
当，即使情况发生变化也是如此。
协作并提升可见性跨越国界合作会产生更多认同、与目标更相关以及增加长期成功可
能性的结果。
实现目标需要信息、理解和信任。工作和后果应变得可见，避免隐
藏议程，并尽可能共享信息。
思考和工作没有任何服务或用于提供服务的元素单独存在。除非组织对整个服
整体务工作，而不仅仅是在其部分，否则服务提供商和服务使用者取得
的成果将受到影响。
通过有效、高效的管理以及信息、技术、组织、人员、实践、合作
伙伴和协议的动态集成，将结果交付给内部和外部客户，所有这些
协议都应加以协调，以提供定义的值。
保持简单实用如果流程、服务、操作或指标未能提供价值或产生有用的结果，请
消除它。在流程或过程中，使用完成
目标。始终使用基于结果的思维来产生切实可行的解决方案，从而
取得成果。

237
ITIL 4 基金会
优化和自动化所有类型的资源，特别是人力资源资源，都应最佳使用。消除任何
真正浪费的东西，并使用技术来实现它能够实现的任何目标。人类
干预只应在真正贡献价值的地方进行。
ITIL、敏捷和开发
敏捷是一种专注于小型团队需求交付和演变的方法。它是一种定时框、灵活和自适应的 IT
工作方法，允许对更改做出快速响应。敏捷的工作方式赋予开发团队自主权，并允许他们
自我组织，该方法可促进客户、用户和开发团队之间在一切机会中的协作。
对于敏捷的工作方式，要有效并生成常规版本，需要建立基本的组织能力。敏捷的重点往
往放在提供更多功能和修复上，而不是改进服务。因此，在没有 ITIL 的情况下运行敏捷会
导致成本随时间增加、时间估计不准确以及服务质量降低。它可能导致迭代构建的工程过
度工程项目，而不考虑整体服务。
借助 ITIL，敏捷团队可以更有效地工作，从而实现更快、更稳定的部署到实时环境。组织
将看到服务的持续成本降低，以及敏捷项目与可能不适用于敏捷方法的服务/业务的其他领
域之间的更好协调。在更广泛的服务范围内，更加注重提供最佳价值和高效。
敏捷与 ITIL 共享许多共同的主题，他们可以相互支持，以产生高效的实践，例如持续改

进、问题管理、更改控制、发布管理和部署管理。如表 4.2 所示，敏捷宣言和 ITIL 指导
原则彼此良好一致。
敏捷方法侧重于在时间框迭代中工作，这可能会带来在持续服务中引入不稳定的风险。由
于敏捷专注于自动化和交付速度，团队也使用 DevOps 来帮助改进 ITIL 和敏捷实践的协
同工作方式可能是有益的。DevOps 产生于敏捷软件项目的日益成功，导致组织更频繁地
发布。
DevOps 专注于向实时环境交付软件的过程，重点是统一技术操作和交付。任何负责变更
控制、发布管理和服务操作的人都应该是敏捷团队的一部分，以确保团队有效地协同工
作。
当 ITIL 和敏捷合并时，整个服务团队需要参与整个敏捷开发过程。应该采用敏捷开发团队
青睐的通信方法，并且通信需要成为整个服务生命周期中涉及的每个人的优先事项。
团队中的敏捷角色可以是多用途的，并且与服务管理角色保持一致;例如：

237
ITIL 4 基金会
l 产品经理/所有者可以履行服务所有者 l Scrum 大师的角色，可以履行
变更经理 l Scrum 大师的角色，这可以是更广泛的持续改进实践的一部
分，因为他们已经在运行回顾，并确保吸取教训。
ITIL 和敏捷可能是伟大的盟友。敏捷团队通过整体服务的镜头关注客户需求和满意
度，将在更短的时间内提供更大的价值。
表 4.2 比较敏捷和 ITIL 原则

敏捷宣言 ITIL 指导原则
个人和流程和工具的交互保持简单实用
从现在开始
通过全面文档工作软件注重价值
整体思考和工作
客户在合同谈判中的协作注重价值
协作并提升可见性
响应计划后的变化通过反馈迭代进度
保持简单实用
ITIL 的故事：Axle 的新技术
Axle 正在考虑在他们的汽车中引入几项新技术。在以下各节中，Axle 团队将介绍哪些新技

术可以引入，并使用 ITIL 指导原则来帮助确定最佳行动方案。
苏：我们正在考虑的服务的一个方面是车辆的收集和返还。此过程仍然非常手动。我们的
一些区域仓库继续使用纸质表格来注册客户。客户不想在在线预订过程中提供此信息时浪
费填写表格进行身份证明。
为了改进客户识别流程，Axle 可以使用生物识别技术来识别我们的客户。

237
ITIL 4 基金会
Marco：生物识别技术使用扫描的图形数据进行个人识别。它快速可靠，广泛应用于其他
行业。例如，航空业正将其用于安检、办理登机手续，甚至用于飞机登机。我们可以使用
指纹或面部识别扫描来快速识别我们的客户，并自动执行汽车收集和返回过程。
拉迪卡：我们需要注意 GDPR 等法规，以及这项技术可能带来的数据安全可能面临的风

险。
Marco：Axle 还希望尝试自动识别返回的车辆的损坏情况，包括划痕、凹痕和断灯。这项
技术甚至可以识别燃油水平。这将自动计算客户承担的任何燃油费用，这也是一个手动过
程。
苏：我们的客户希望简单和速度，同时保持舒适和安全的道路上。生物识别技术和汽车扫
描将是满足不断变化的客户需求的机会来源。
Marco：我们的服务已经依靠技术和智能手机和个人设备的智能来满足客户的需求和期
望。生物识别技术的采用是一个自然的过程。任何人谁可以访问他们的手机与指纹或面部
识别将舒适和自信使用相同的技术收集或返回汽车。
Henri：我们不能犯一个错误，试图一次实施每一项创新，即使它们听起来都像是 Axle 租
车的理想解决方案。我们需要一个框架，以确保价值实现，并管理我们的决定。同样重要
的是，即使我们冒险进入新的环境，我们现有的客户都无一处于不利地位。例如，并非所
有客户都精通技术。对于我们占休闲旅游客户群很大比例的老年客户来说尤其如此。我们
亦须平衡创新与现时的营运需求。
4.3.1 注重价值
关键消息
组织所做的一切应直接或间接地与自身、客户和其他利益相关者的价值联系起来。

237
ITIL 4 基金会
本节主要侧重于为服务使用者创造价值。但是，服务也有利于组织和其他利益相关者的价
值。此值可能以各种形式出现，例如收入、客户忠诚度、降低成本或增长机会。以下建议
可以进行调整，以解决各种利益有关群体以及组织为他们创造的价值。
4.3.1.1 谁是服务消费者？
当专注于价值时，第一步是知道谁正在被服务。因此，在每种情况下，服务提供商必须确
定服务使用者是谁以及主要利益相关者是谁（例如，客户、用户或发起人;有关详细信息，
请参阅第 2.2 节）。在此过程中，服务提供商应考虑谁将从交付或改进的内容中获得价
值。
4.3.1.2 消费者的价值视角
接下来，服务提供商必须了解什么是真正对服务使用者的价值。服务提供商需要知道：
⚫ 为什么消费者使用服务 l 服务帮助他们做什么，服务如何帮助他们实
现目标，即成本/财务后果对服务使用者的作用，以及服务消费者面临
的风险。
价值可以有多种形式，例如生产率提高、负面影响减少、成本降低、追求新市场的能力或
更好的竞争地位。服务使用者的价值：
⚫ 由他们自己的需求定义
⚫ 通过支持预期结果和优化服务消费者的成本和风险来实现
⚫ 随时间和不同情况而变化。
ITIL 故事：关注价值
Radhika：当 Axle 扩展到亚太地区时，我们专注于在本国境外旅行的客户进行研究。结

果发现，前往这些地区的美国和欧洲客户对不熟悉的道路规则和安全感到担忧。
Marco： Axle 正在引入一种经过认证的第三方驾驶员辅助系统，称为 Axle 感知系统。系

统检查车内的外部环境和内部条件。它包括监控汽车周围区域的摄像头，以及带有当地道
路规则的人工智能程序。它甚至可以让驾驶员知道疲劳何时开始开始开始。

237
ITIL 4 基金会
该系统将提醒驾驶员注意接近危险和潜在的违反道路规则的行为。例如，在澳大利亚，当
地道路规则规定，司机在以 60 公里/小时或更低的速度通过骑车人时，必须给予至少 1
米，当车速超过 60 公里/小时时，则要求给予 1.5 米。
苏：很多游客大多集中在路右侧开车，不知道这个规则，但 Axle 感知系统会这样！
马可：研究表明，这样的系统大大降低了事故率和严重伤害。
苏：这意味着对我们的消费者来说，价值是更安全的旅行体验。这也会更便宜，因为他们
对违反他们不熟悉的规则的处罚会更少！
Henri：Axle 租车的价值是提高客户满意度，降低维修成本，降低保险费。
马可：这种创新也将为我们的一些合作伙伴和供应商提供额外的价值。
Radhika：例如，我们已经更新了我们与车队维护合作伙伴的合同。维护现在将包括 Axle
感知。我们的维护合作伙伴的价值是额外的收入。
4.3.1.3 客户体验
价值的一个重要元素是服务使用者在与服务和服务提供商交互时所体验的体验。这通常称
为客户体验（CX）或用户体验（UX），具体取决于采用的定义，并且必须主动管理它。
CX 可以定义为客户与组织及其产品之间的全部交互。此体验可以确定客户对组织及其产品
和服务的感受。
CX 既客观又主观。例如，当客户订购产品并收到他们按承诺价格和承诺的交货时间订购的
产品时，其经验的这一方面的成功是客观上可以衡量的。另一方面，如果他们不喜欢他们
订购的网站的风格或布局，这是主观的。另一位客户可能真正喜欢这种设计。
4.3.1.4 应用原则
要成功应用此原则，请考虑以下建议：
⚫ 了解服务使用者如何使用每项服务了解其预期结果、每项服务如何为这些
服务做出贡献以及服务使用者如何看待服务提供商。持续收集价值反馈，
而不仅仅是在服务关系开始时。
⚫ 鼓励所有员工注重价值教师了解客户是谁，并了解 CX。

237
ITIL 4 基金会
⚫ 在正常运营活动期间以及改进计划期间，注重价值整个组织都有助于客户
感知的价值，因此组织内的每个人都必须最大化他们创造的价值。价值的
创造不应只留给从事令人兴奋的项目和新事物的人。
⚫ 在任何改进计划的每一步都注重价值，参与改进计划的人需要了解计划试
图促进哪些成果，如何衡量其价值，以及它们应该如何促进共同创造这一
价值。
4.3.2 从您所处的位置开始
关键消息
在消除旧的、不成功的方法或服务并创造更好的事物的过程中，可以有很大的诱惑力去消
除过去所做的事情，并构建一些全新的东西。这很少是必要的，或者是一个明智的决定。
这种方法可能非常浪费，不仅在时间方面，而且在现有服务、流程、人员和工具的损失方
面，这些服务、流程、人员以及工具在改进工作中具有重大价值。不要重新开始，而不首
先考虑已经可以利用的。
ITIL 故事：Axle 的预订应用程序
Marco：Axle 预订应用程序是两年前首次开发的。该应用程序不再满足业务需求。它无法
适应我们现在使用的技术的进步，例如生物识别系统和驾驶员辅助系统。
例如，我们需要我们的应用程序能够扫描和验证客户的指纹和面部图像。当前编码根本无
法支持。我们需要一个新的应用程序！

237
ITIL 4 基金会
4.3.2.1 评估您所处的位置
应直接测量和/或观察已经提供的服务和方法，以正确了解其当前状态以及可以从这些服务
和方法重用哪些服务和方法。关于如何进行的决定应基于尽可能准确的信息。在组织内
部，报告与现实之间经常存在差异。这是因为难以准确测量某些数据，或者无法通过报告
产生的数据的无意偏差或失真。从源获取数据有助于避免假设，如果证明这些假设是毫无
根据的，对时间表、预算和结果质量可能是灾难性的。
那些观察活动的人不应该害怕问什么似乎是愚蠢的问题。有时，对服务知之甚少或事先不
了解服务的人来说，成为观察的一部分是有益的，因为他们对服务没有成见，而且可能会
发现那些与服务关系更密切的人会错过的事情。
4.3.2.2 测量的作用
测量的使用对这一原则很重要。然而，它应当被用来支持对所观察到的进行分析，而不是
取代它，因为过分依赖数据分析和报告会无意中在决策中引入偏见和风险。组织应考虑各
种技术，以培养对工作环境的了解。虽然某些事物只能通过测量其影响（例如，自然现
象，如风）来理解，但直接观察应始终是首选选择。使用现有数据时往往不考虑直接的个
人调查。
需要注意的是，测量行为有时会影响结果，使其不准确。例如，如果服务台知道它被监控
在电话上花费的时间长度，它可能会过于注重最小化客户参与度（从而导致良好的报告），
而不是实际帮助用户解决问题，使其满意。人们非常有创造力地找到方法来满足他们衡量
的指标。因此，指标必须有意义，并直接关系到预期的结果。
当一项措施成为目标时，它不再是古德哈特定律的好措施
ITIL 故事：评估当前状态
Henri：每个人都喜欢新应用的想法，IT 渴望开始收集用户需求，以便我们开始开发。但
是，在开发一个全新的应用之前，让我们评估应用的当前状态，我们必须查看是否有任何
功能可以重复使用。
当前租车预订流程符合基本要求，无需更改。我们只需要其他功能。例如，记录、存储和
计算我们忠诚度计划的积分的过程不会改变。

237
ITIL 4 基金会
我们还应考虑客户使用的技术的局限性。如果我们想要引入生物识别数据识别，用户将需
要拥有现代设备。我不确定他们是否都这样做，所以我们应该在这里调查限制和机会。
马可：我们目前的预订应用程序工作良好。事件数据显示，客户很少致电服务台。这表明
当前功能适合使用，并满足客户要求。
Henri：但是，我们的焦点小组表示客户会避免使用该应用程序，因为它速度慢且难以使
用。以前，升级侧重于技术，而不是客户的要求。我们没有灵活性轻松配置功能以匹配新
的和不断变化的服务产品。因此，不能仅使用记录的事件中的数据来评估预订应用的可靠
性和可用性。
我们需要与其他研究确认这些发现。
4.3.2.3 应用原则
正确了解服务和方法的当前状态对于选择重用、更改或构建哪些元素非常重要。要成功应
用此原则，请考虑以下建议：
⚫ 以客户或期望的结果为起点，尽可能客观地查看存在的内容。当前状态的
元素是否适合用途和适合使用？可能有许多元素
当前服务、实践、项目和技能可用于创造预期的未来状态，前提是做出此
判断的人是客观的。
当在当前状态下找到成功实践或服务的示例时，确定是否可以以及如何复制或
扩展这些实践或服务以实现所需的状态。在许多情况下（如果不是大多数）情
况下，利用现有内容将减少从当前状态过渡到所需状态所需的工作量。有
⚫ 应该专注于学习和改进，而不仅仅是复制和扩展。
⚫ 运用您的风险管理技能。重用现有做法和流程存在风险，例如旧行为的继
续对服务造成损害。此外，还有与新内容相关的风险，例如新程序未正确
执行。这些应视为决策过程的一部分，并评估进行或不进行更改以决定最
佳行动方针的风险。
⚫ 认识到有时不能重用当前状态。无论重复使用、重新使用和回收，甚至上
周期，都多么可取，有时实现预期结果的唯一方法是完全重新开始。然
而，应当指出，这些情况非常罕见。

237
ITIL 4 基金会
4.3.3 迭代进度，提供反馈
关键消息
抵制一次做每一件事的诱惑。即使是巨大的倡议也必须迭代地完成。通过将工作组织成可
以及时执行和完成的较小、可管理的部分，对每项工作的关注将更加清晰且更易于维护。
改进迭代可以连续进行，也可以同时进行，具体取决于改进的要求以及可用的资源。每个
单独的迭代都应易于管理和管理，确保及时返回实际结果，并基于创建进一步改进。
一项重大的改进倡议或方案可组织成若干重大改进举措，而每一项举措可能反过来包括较
小的改进努力。必须不断重新评估和可能修订的总体倡议或方案及其组成部分迭代，以反
映情况的任何变化，并确保对价值的关注不会丧失。这种重新评估应利用广泛的反馈渠道
和方法，确保适当理解该倡议的状况及其进展。
4.3.3.1 反馈的作用
无论是改进服务、服务组、实践、流程、技术环境还是其他服务管理元素，在真空中都不
会发生改进迭代。在进行迭代时，情况可能会发生变化，并可能会出现新的优先级，迭代
的需要可能会更改甚至消除。在每个迭代之前、整个迭代和之后查找和使用反馈将确保行
动集中且适当，即使在不断变化的环境中也是如此。
反馈循环是一个术语，通常用于指活动输出的一部分用于新输入的情况。在运作良好的组
织中，反馈会沿着价值链积极收集和处理。结构良好的反馈机制有助于了解：
l 最终用户和客户对所创造价值的看法（l 价值链活动的效率和有效性，即服
务治理的有效性以及管理控制 l 组织与其合作伙伴和供应商网络之间的接口，
即对产品和服务的需求。
收到反馈后，可以分析反馈，以确定改进机会、风险和问题。

237
ITIL 4 基金会
4.3.3.2 迭代和反馈一起
以时间框、迭代方式工作，将反馈循环嵌入到流程中，允许：
提高灵活性，加快对客户和业务需求的响应，以及
尽早发现和应对故障的能力，即质量的整体提高。
在活动参与者之间建立适当的反馈循环，使他们更好地了解其工作来自何处、产出的走向
以及他们的行动和产出如何影响结果，从而使他们能够做得更好决定。
ITIL 故事：迭代进度
Marco：自从 Axle 发布其新应用程序的第一次迭代以来，已经三个月了。我们首先向值得

信赖的 VIP 客户提供服务。我们与他们的反馈合作，以完善预订流程。
Radhika：我们了解到应用程序需要灵活，以便我们可以根据快速发展的客户需求轻松进
行更改。例如，我们的业务客户希望应用程序自动记录行驶距离。与我们的产品团队合
作，我们可以轻松地添加此功能。
Su：应用程序现在很容易配置，允许 Axle 根据客户反馈快速添加新的功能和功能。
4.3.3.3 应用原则
⚫ 理解整体，但做某事有时最大的敌人是渴望理解和解释一切。这可能导致
有时被称为"分析瘫痪"，在这种瘫痪中，花了太多时间分析情况，以至于对
此无能为力。理解大局很重要，但取得进展也很重要。
⚫ 生态系统在不断变化，因此反馈是不断变化的要素，因此，始终在各个级
别寻求和使用反馈非常重要。
⚫ 快速并不意味着不完整，因为迭代足够小，可以快速完成并不意味着它不
应该包括成功所需的所有元素。任何迭代都应根据最小可行产品的概念进

237
ITIL 4 基金会
行生成。最小可行的产品是最终产品的版本，它允许以最少的精力进行最
大数量的验证学习。
4.3.4 协作并提升可见性
关键消息
当计划让合适的人担任正确的角色时，努力将受益于更好的支持、更相关性（因为更好的
信息可用于决策）和增加长期成功的可能性。
创造性的解决方案、热情的贡献和重要的观点可以从意想不到的来源获得，因此包容通常
比排斥更好的政策。合作与协作比孤立的工作要好，后者通常被称为"孤岛活动"。孤岛可
以通过个人和团队的行为发生，但也通过结构原因发生。当组织中的职能或业务部门受到
阻碍或无法协作时，通常会发生这种情况，因为它们的流程、系统、文档和通信仅满足组
织特定部分的需求。全面运用思考和工作的指导原则（见第 4.3.5 节）可以帮助组织打破工
作孤岛之间的障碍。
认识到真正协作的必要性是推动现在称为 DevOps 的驱动力之一。如果没有有效的协作，

敏捷、精益或任何其他 ITSM 框架或方法都不起作用。
以一种能带来真正成就的方式合作需要信息、理解和信任。工作及其成果应变得可见，应
避免隐藏议程，并尽可能尽可能分享信息。人们越是了解正在发生的事情和原因，他们就
越愿意提供帮助。
当改善活动在相对沉默中发生时，或者只有一小群人知道细节时，假设和谣言可能占上
风。随着工作人员猜测变革的变化及其如何影响变革，人们往往会对变革产生抵制。
4.3.4.1 与谁协作
确定和管理组织处理的所有利益相关者组非常重要，因为成功协作所需的人员和观点可以
来自这些利益相关者群体。顾名思义，利益相关者是参与组织活动的人，包括组织本身、
客户和/或用户以及许多其他组织。利益相关者的范围可以广泛。

237
ITIL 4 基金会
第一个也是最明显的利益相关者群体是客户。服务提供商的主要目标是促进其客户感兴趣
的结果，因此客户在服务提供商有效管理服务的能力方面拥有很大的利益。但是，有些组
织在与客户互动方面做得很差。服务提供商可能会觉得很难从客户那里获得输入或反馈，
并且由此造成的延迟是浪费时间。同样，客户可能会认为，在确定其要求后，服务提供商
可以无需进一步联系即可提供服务。当涉及到改进服务提供商的做法时，客户可能根本不
认为有任何需要参与。但是，最终，与客户进行适当级别的协作将为组织、其客户和其他
利益相关者带来更好的结果。
利益相关者协作的其他示例包括：
⚫ 开发人员与其他内部团队合作，确保正在开发的内容能够高效、高效地运
行。开发人员应与技术和非技术运营团队协作，以确保他们准备好、愿意
并能够将新的或更改的服务转换到操作中，甚至可能参与测试。开发人员
还可以与运营团队合作，调查缺陷（问题），并制定解决方法或永久修复方
法来解决这些缺陷
⚫ 供应商与组织合作，确定其要求，并针对客户问题集思广益解决方案
⚫ 关系经理与服务消费者协作，全面了解服务消费者的需求和优先级
⚫ 客户相互协作，共同了解其业务问题
⚫ 内部和外部供应商相互协作，审查共享流程，并确定优化和潜在自动化的
机会。
4.3.4.2 沟通改进
应了解对改进每个级别每个利益攸关方群体的贡献;定义与他们接触的最有效方法也很重
要。例如，公共云服务客户对改进的贡献可能是通过针对不同功能的调查或选项清单。对
于内部客户组，对改进的贡献可能来自通过研讨会或组织 Intranet 上的协作工具征求的反
馈。
一些贡献者可能需要在非常详细的级别参与，而其他贡献者可能只是作为审阅者或审批人
参与。根据服务以及服务提供商与服务使用者之间的关系，对协作级别和类型的期望值可
能有很大差异。
4.3.4.3 通过可见性提高紧迫性
当利益相关者（无论是内部或外部）对工作量和工作进度的可见性较差时，就存在造成工
作不是优先事项的印象的风险。如果一项计划传达给团队、部门或其他组织，然后不再或
很少再次提及，则认为变革并不重要。同样，当工作人员试图将改进工作与其他具有日常

237
ITIL 4 基金会
紧迫性的任务列为优先事项时，改进工作似乎是一项低优先级的活动，除非其重要性已变
得透明，并且得到本组织的支持。管理。
工作可见性不足会导致决策不力，进而影响组织提高内部能力的能力。然后，将很难推动
改进，因为不清楚哪些改进可能对结果产生最大的积极影响。为了避免这种情况，组织需
要执行以下关键分析活动：
l 了解正在进行的工作流程，识别瓶颈，以及覆盖
废物的过剩产能。
必须让各级利益攸关方参与并满足其需要。各级领导还应在自己与他人的沟通中提供有关
改进工作的适当信息。这些行动将共同加强正在采取的行动、为什么正在采取的行动，以
及这些行动与本组织的既定愿景、使命、目标和目的的关系。确定此类消息传递的类型、
方法和频率是与通信相关的中心活动之一。
ITIL 故事：协作工作
Henri：除了迭代外，我们关于新的 Axle 预订应用程序的工作也是协作性的。我们包括许

多团队，如开发人员、测试人员和支持人员，当然还有我们的客户和用户。这种方法使我
们能够根据反馈，以响应更迅速和更有针对性的方式改进我们的服务。
4.3.4.4 应用原则
⚫ 协作并不意味着共识在继续之前，没有必要，甚至总是明智的，从参与一
项倡议的每个人那里获得共识。一些组织非常关注获得共识，
他们试图让每个人都快乐，最终要么什么都不做，要么生产出一些不适合
任何人需要的东西。
⚫ 以受众可以听到的方式进行沟通，试图将不同的利益相关者引入循环，许
多组织使用非常传统的通信方法，或者对所有通信使用相同的方法。为每
个受众选择正确的方法和消息对于成功至关重要。

237
ITIL 4 基金会
⚫ 决策只能对可见数据做出决策在没有数据的情况下做出决策是有风险的。
应就需要哪些数据作出决定，因此需要使哪些工作可见。收集数据可能要
付出代价，组织必须平衡成本与数据的好处和预期用途。
4.3.5 整体思考和工作
关键消息
没有任何服务、实践、流程、部门或供应商是孤立的。除非组织以综合方式处理其整体活
动，而不是作为单独的部分，否则组织交付给自身、其客户和其他利益相关者的产出将受
到影响。本组织的所有活动都应侧重于价值的交付。
服务通过协调和集成服务管理的四个维度交付给内部和外部服务消费者（见第 3 章）。
采取整体方法进行服务管理包括了解组织的所有部门如何以集成方式协同工作。它需要端
到端地了解需求是如何捕获并转化为结果的。在一个复杂的系统中，一个要素的改变可以
影响其他要素，并在可能的情况下，需要查明、分析和规划这些影响。
ITIL 的故事：整体思考和工作
苏：目前，Axle 正在制定许多举措。我们有我们新的预订应用程序的迭代版本的时间表，
以及我们的 Axle Aware 高级驾驶员辅助系统，以及新的生物识别扫描，用于收集和返回车
辆。
Henri：由于活动如此频繁，我们需要了解上游和下游的影响。例如，决定扩展我们的预订
应用程序与新功能将需要考虑任何资源限制为我们的支持团队。

237
ITIL 4 基金会
4.3.5.1 应用原则
⚫ 认识到系统的复杂性不同的复杂性要求不同的启发式决策。在复杂的系统
中，应用为简单系统设计的方法和规则可能无效甚至有害，因为组件之间
的关系很复杂，变化更频繁。
⚫ 如果建立适当的机制，使所有相关利益攸关方及时协作，协作是思考和全
面工作的关键，则有可能全面解决任何问题，而不会受到不当拖延。
⚫ 在可能的情况下，寻找系统元素的需求和交互的模式利用每个领域的知识
来确定成功的关键，以及元素之间的关系影响结果。有了这些信息，可以
预测需求，可以设定标准，并实现整体观点。
⚫ 在有机会和有足够的资源可用的情况下，自动化可以促进整体工作，自动
化可以支持组织的端到端可见性，并提供有效的集成管理手段。
4.3.6 保持简单实用
关键消息
始终使用最小步骤数来完成目标。应利用基于结果的思维来产生切实可行的解决方案，从
而产生宝贵的成果。如果流程、服务、操作或指标未能提供值或产生有用的结果，则消除
它。虽然这一原则似乎显而易见，但经常被忽略，导致工作方法过于复杂，很少使结果最
大化或成本最小化。
尝试为每个异常提供解决方案通常会导致过度复杂。创建流程或服务时，设计人员需要考
虑异常，但它们不能涵盖所有异常。相反，应设计一般可用于处理异常的规则。

237
ITIL 4 基金会
ITIL 的故事：保持简单实用
苏：Axle 的营销部门已经表示，他们希望推出新的年终促销活动。促销将包括在 2 月份免

费升级豪华车，以及有机会赢得海外假期。
要进入，客户将提交一篇题为"我最好的驾驶假日冒险"的文章。然后，营销团队将收集和分
析客户数据，并创建一个应用程序，以他们的旅行偏好为目标。
Henri：我们的开发人员已经忙于生物识别服务的实现时间表。我们需要速度来推销此功
能。我们必须根据预期价值确定工作的优先次序。
4.3.6.1 判断保留什么
在分析实践、流程、服务、指标或其他改进目标时，始终询问它是否有助于创造价值。
在设计或改进服务管理时，最好从简单方法开始，然后仔细添加控件、活动或指标，当看
到确实需要它们时。
保持服务管理简单和实用的关键，是确切地了解某物如何促进价值创造。例如，所涉业务
工作人员可能认为一个进程中的一个步骤是浪费时间。然而，从公司的角度来看，同样的
步骤对于法规遵从性可能很重要，因此在间接但仍然重要的方式上很有价值。有必要建立
和传达组织工作的整体视图，以便各个团队或团队能够全面思考他们的工作如何受到其他
人的影响，进而影响其他人。
ITIL 的故事：判断要保留什么
Marco：我们的原始预订应用程序捕获了大量数据，例如客户在预订应用中完成每个表单需
要多长时间。但是我们发现，这些数据对决策几乎没有价值。真正的价值在于整个预订过程
需要多长时间。我们完善了预订应用程序字段，并通过删除此数据捕获功能提高了其整体速
度。

237
ITIL 4 基金会
4.3.6.2 冲突目标
在设计、管理或操作实践时，请注意相互冲突的目标。例如，组织的管理层可能希望收集
大量数据来做出决策，而必须执行记录保存的人员可能需要一个不需要那么多数据输入的
更简单流程。通过适用这一原则和其他指导原则，本组织应商定其相互竞争的目标之间的
平衡。在此示例中，这可能意味着服务应仅生成真正为决策过程提供价值的数据，并在可
能的情况下简化和自动化记录保存，以最大化价值并减少非增值工作。
4.3.6.3 应用原则
⚫ 确保价值每个活动都应有助于创造价值。
⚫ 简单是终极的复杂性它似乎更难简化，但它通常更有效。
⚫ 少做点事，但最好把活动最小化，只包括那些对一个或多个利益相关者有
价值的活动，这样可以更加关注这些行动的质量。
⚫ 尊重所涉人员的时间一个过于复杂和官僚主义的过程是对所涉人员时间的
不当利用。
⚫ 更易于理解，更有可能采用嵌入实践，请确保它易于遵循。
⚫ 简单性是实现快速获胜的最佳途径，无论是在项目中，还是在改进日常运
营活动时，快速获胜都使组织能够展示进步并管理利益相关者的期望。以
迭代方式处理反馈将定期快速交付增量值。
4.3.7 优化和自动化
关键消息
各组织必须最大限度地发挥其人力和技术资源所开展工作的价值。四个维度模型（第 3 章
概述）提供了设计、管理或操作组织时应考虑的各种约束、资源类型和其他领域的整体视
图。技术可以帮助组织扩大规模并承担频繁和重复的任务，从而允许将人力资源用于更复
杂的决策。然而，如果没有人工干预的能力，技术不应总是依赖，因为自动化的实现可以
增加成本，降低组织的鲁棒性和弹性。

237
ITIL 4 基金会
优化意味着使某些东西变得有效和有用。在活动能够有效地自动化之前，应对其进行优
化，使其达到任何可能且合理的程度。必须对服务和实践的优化设置限制，因为它们存在
于一组限制中，其中可能包括财务限制、合规性要求、时间限制和资源可用性。
4.3.7.1 优化之路
有许多方法可以优化实践和服务。ITIL 中描述的概念和做法，特别是持续改进和测量和报
告实践（参见第 5.1.2 节和 5.1.5 节）对于这一努力至关重要。组织用于改进和优化绩效
的具体实践可能借鉴 ITIL、精益、DevOps、看板和其他来源的指导。无论采用哪种具体
技术，优化路径都遵循以下高级步骤：
⚫ 了解并同意建议的优化存在的上下文这包括同意组织的总体愿景和目标。
⚫ 评估建议的优化的当前状态这将有助于了解改进的位置以及哪些改进机会
可能产生最大的积极影响。
⚫ 同意组织的未来状态和优先事项，重点是简化和重视这通常还包括实践和
服务的标准化，这将使以后更容易自动或进一步优化。
l 确保优化具有适当的利益相关者参与和承诺水平
⚫ 以迭代方式执行改进使用指标和其他反馈来检查进度、保持正轨并根据需
要调整优化方法。
⚫ 持续监控优化的影响这将有助于确定改进工作方法的机会。
4.3.7.2 使用自动化
自动化通常是指在有限或无人工干预下正确、一致地使用技术执行步骤或一系列步骤。例
如，在采用连续部署的组织中，它是指从开发到实时自动和连续发布代码，并且通常在每
个环境中进行自动测试。但是，自动化最简单的形式还可能意味着手动任务的标准化和简
化，例如定义流程的一部分规则，以便"自动"做出决策。通过减少人类参与以停止和评估
流程的每个部分，可以大大提高效率。
在整个组织中可以找到自动化的机会。寻找自动化标准和重复任务的机会有助于节省组织
成本、减少人为错误并改善员工体验。

237
ITIL 4 基金会
ITIL 故事：优化和自动化
马可：Axle 已经开始试验新的生物识别技术，测试进展顺利。我们渴望在所有仓库中实施
这项技术。
Radhika：在 Axle 引入生物识别技术之前，有许多基于纸张的手动流程。Axle 工作人员使

用纸质检查表进行车辆损坏检查。然后，他们的笔记必须输入数据库，数据库仅在台式计
算机上可用。它不是实时的，也不是跨其他系统访问的。
苏：这项工作通常被搁置到一天结束，细节经常丢失。在自动化之前，我们必须改进数据
捕获过程。
拉迪卡：我们几乎可以自动执行任何操作。但是，让我们先把业务规则和流程弄对。
4.3.7.3 应用原则
⚫ 在自动化之前简化和/或优化尝试自动执行复杂或次优的东西不太可
能达到预期结果。花些时间尽可能规划标准和重复流程，并尽可能
简化（优化）流程。从那里，你可以开始自动化。
⚫ 定义指标优化的预期和实际结果应使用一组适当的指标进行评
估。使用相同的指标定义基线并衡量成就。确保指标基于结果并侧
重于价值。
⚫ 在应用此指导原则时，在优化和自动化时，遵循其他原则也很聪
明：
⚫ 通过反馈迭代进度迭代优化和自动化将使进度可见，并增加利益相
关者对未来迭代的认同。
⚫ 保持简单和实用的东西可能是简单，但不是优化，所以在选择改进
时一起使用这两个原则。
⚫ 注重价值选择什么来优化和自动化以及如何做到这一点应该基于什
么将创造组织的最佳价值。
⚫ 从您所处的位置开始组织中已有的技术可能具有当前尚未开发或未
充分利用的功能。利用已有的实现快速、经济的优化和自动化机
会。

237
ITIL 4 基金会
4.3.8 原则交互
除了了解 ITIL 指导原则外，必须认识到它们相互影响并相互依赖。例如，如果组织致力于

迭代反馈，它也应该从整体上思考和工作，以确保改进的每一次迭代都包含提供实际结果
所需的所有元素。同样，利用适当的反馈是协作的关键，而专注于真正对客户有价值的东
西可以更容易地保持简单和实用。
组织不应只使用一两项原则，而应考虑每个原则的相关性及其如何共同适用。并非所有原
则在每种情况下都至关重要，但应在每一次审查这些原则，以确定这些原则是否适当。
4.4 治理
4.4.1 理事机构和治理
关键消息
每个组织都由理事机构领导，即对组织的业绩和遵守情况负责的最高级别负责的个人或群
体。组织的所有规模和类型都执行治理活动;理事机构可以是董事会或执行经理，他们在从
事治理活动时承担单独的治理角色。理事机构对本组织遵守政策和任何外部条例负责。
组织治理是一个指导和控制组织的系统。通过以下活动实现治理：
⚫ 评估组织、其战略、投资组合和与其他各方的关系的评估。随着利益攸关
方的需要和外部环境的发展，理事机构定期对本组织进行评估。
⚫ 指导理事机构负责并指导组织战略和政策的制定和实施。战略为组织活
动、未来投资等确定了方向和优先级。政策规定了整个组织的行为要求，
并酌情规定了供应商、合作伙伴和其他利益相关者的行为要求。
⚫ 监督管理机构监测组织的业绩及其做法、产品和服务。其目的是确保绩效
符合政策和方向。
组织治理评估、指导和监视组织的所有活动，包括服务管理活动。

237
ITIL 4 基金会
4.4.2 SVS 中的治理
治理在 ITIL SVS 中的角色和位置取决于 SVS 在组织中的应用方式。SVS 是一种通用模

型，可应用于整个组织或其一个或多个单位或产品。在后一种情况下，一些组织授权在不
同级别执行治理活动。本组织的理事机构应保留这方面的监督，以确保与本组织的目标和
优先事项保持一致。
在 ITIL 4 中，指导原则和持续改进适用于 SVS 的所有组件，包括治理。在组织中，管理

机构可以采用 ITIL 指导原则并对其进行调整，或定义自己的特定原则集，并在组织内传达
这些原则。理事机构还应了解持续改进活动的成果以及衡量组织及其利益攸关方的价值。
无论 SVS 的范围和组件的定位如何，确保：
⚫ 服务价值链和组织的做法符合理事机构给出的方向
⚫ 该组织的理事机构，无论是直接或通过授权，保持对 SVS 的监督
⚫ 各级理事机构和管理层通过一套明确的共同原则和目标保持一致
⚫ 各级治理和管理不断得到改善，以满足利益相关者的期望。
4.5 服务价值链
SVS 的核心内容是服务价值链，这是一种运营模式，它概述了通过创建和管理产品和服务
来响应需求和促进价值实现所需的关键活动。
如图 4.2 所示，ITIL 服务价值链包括六个价值链活动，这些活动导致产品和服务的创建，

进而带来价值。

237
ITIL 4 基金会
图 4.2 ITIL 服务价值链
关键消息
六个价值链活动是：
⚫ 计划 l 改进
l 承诺
⚫ 设计和过渡获
得 /构建 l 交付
和支持。
这些活动表示组织在创造价值时采取的步骤。每项活动通过将特定投入转换为产出，为价
值链做出贡献。这些投入可能是价值链之外的需求，也可以是其他活动的产出。通过这种
方式，活动相互连接并相互交互，每个活动接收并提供触发器，以便采取进一步行动。
要将输入转换为输出，价值链活动使用 ITIL 实践的不同组合（专为执行某些类型的工作而

设计的资源集）。每项活动可能利用内部或第三方资源、流程、技能和能力，从一个或多个
实践。例如，参与价值链活动可能借鉴许多做法，包括供应商管理、服务台管理、关系管
理和服务请求管理，以应对对产品和服务、决策或来自各种利益相关者的信息。有关实践
的更多信息，请参阅第 5 章。
要执行特定任务或响应特定情况，组织创建服务价值流。服务价值流是活动和实践的特定
组合，每个组合都是针对特定方案设计的。一旦设计，价值流应不断改进。
例如，对于服务用户需要解决事件的情况，可能会创建价值流。价值流将专门设计用于此
方案，并将提供有关解决问题所涉及的活动、实践和角色的完整指南。有关此值流的其他
示例的更详细概述，请参阅附录 A。

237
ITIL 4 基金会
服务价值链、其实践和价值流的示例
移动应用程序开发公司拥有价值链，实现了应用程序开发和管理的完整周期，从业务分析
到开发、发布和支持。公司开发了许多实践，并辅之以专门的资源和技术：
⚫ 业务分析 l 开发 l 测试 l 发布和部署 l 支持。
尽管高级步骤是通用的，但不同的产品和客户需要不同的工作流。例如：
⚫ 为新客户开发新应用程序从初始参与（预售）开始，然后进行业务分析、
原型设计、协议起草、开发、测试，并最终发布和支持。
⚫ 更改现有应用程序以满足现有客户的新要求不包括预售，并且以不同的方
式涉及业务分析、开发、测试和支持。
⚫ 修复实时应用程序中的错误可能会在支持中启动，继续回滚到以前的稳定
版本（版本）
，然后转到修复的开发、测试和发布。
⚫ 使用新或现有应用程序进行实验以扩展目标受众，可能从创新规划和原型
设计开始，然后进行开发，并最终对有限的用户群体进行试点发布，以测
试他们对所做更改的看法。
这些是价值流的例子：它们以各种方式将实践和价值链活动结合起来，以改进产品和服
务，增加消费者和组织的潜在价值。
现代世界中的 ITSM：敏捷 ITSM
组织要取得成功，就必须能够适应不断变化的环境，同时保持功能性和有效性。这可能包
括对其提供和使用产品和服务的更改，以及对其结构和实践的更改。在现代世界中，IT 对
所有组织都至关重要，IT 和 IT 管理应该是敏捷的。
对于许多 IT 专业人员来说，敏捷性是指软件开发，并与 2001 年宣布的敏捷宣言相关

联。宣言推广了软件开发的新方法，并重视客户体验、协作以及详细规划和文档、控制和

237
ITIL 4 基金会
要求的快速变化。自那时以来，许多公司和软件团队都采用了敏捷软件开发方法，在许多
情况下被证明是有效的。
敏捷软件开发通常包括：
⚫ 通过反馈分析和直接观察收集的不断变化的需求
⚫ 将开发工作分解为小增量和迭代

237
ITIL 4 基金会
l
建立基于产品的跨职能团队
⚫ 可视化演示（看板），并定期讨论（每日站立）工作进度
⚫ 在每次迭代结束时向利益相关者展示一个工作（至少，最低可行）的软
件。
如果成功应用，敏捷软件开发可以快速响应服务消费者不断变化的需求。但是，在许多组
织中，敏捷软件开发没有提供预期的好处，通常是由于在服务生命周期的其他阶段缺乏敏
捷方法。这种支离破碎的敏捷性对于组织来说毫无意义，因为价值链的整体绩效是由最慢
的部分定义的。应该采用一种全面的服务价值链方法，以确保服务提供商在整个服务生命
周期中都是敏捷的。这意味着敏捷性应该成为所有服务管理维度和所有服务价值链活动的
质量。
服务价值链敏捷性的最大障碍之一曾经是基础设施解决方案的刚性。为新的软件程序部署
必要的基础结构可能需要数月时间，这使得所有开发敏捷性不可见，并且与服务使用者无
关。随着技术的发展，这个问题在很大程度上得到了解决。虚拟化、快速宽带和移动连接
以及云计算使组织能够将其 IT 基础架构视为服务或代码，从而以以前只有软件才能的速
度为基础架构更改提供.一旦技术问题得到解决，敏捷方法就可以应用于基础结构配置和部
署。这刺激了软件和基础设施团队之间的集成，进而促进了开发和运营之间的集成。
敏捷开发的许多原则可以而且应该应用于服务操作和支持。运营更改和服务请求可以通过
专门的产品或服务中心团队在小型迭代中处理，并具有恒定的反馈和较高的可见性。日常
运营活动可以而且应该与其他任务一起可见并列为优先级。所有服务管理活动可以而且应
该持续提供、收集和处理反馈。
敏捷不是软件开发功能;敏捷性不是软件开发功能。它是整个组织的重要品质。敏捷活动需
要敏捷资金以及调整后的财务和合规性控制、敏捷资源、敏捷合同、敏捷采购等。如果将
敏捷作为一个关键原则，组织应该能够在不断变化的环境中生存和繁荣。敏捷方法以零碎
的方式应用，可能成为一种成本高昂且浪费的并发症。

237
ITIL 4 基金会
l
ITIL 故事：价值链和价值流
Henri：在 Axle 租车公司，价值链是我们公司建立和运营的方式。它有多个值流。每个价

值流都采用并调整价值链的活动以执行特定任务。例如，有一个创新价值流，另一个用于
向现有客户提供标准服务。
向现有客户提供标准服务的价值流表示客户租车时执行的活动。这从参与开始，当客户联
系 Axle，然后在收到汽车时继续交付（尽管在此阶段仍可能发生参与）
。
某些价值链活动可能在整个特定价值流中进行，或者根本不参与。在此流中，规划活动是
连续的，但设计和采购活动通常不会涉及。流以更多的参与活动结束，当客户返回汽车
时，提供反馈，关闭订单。
马可：价值链活动不必按特定顺序发生。Axle 的创新价值流由机会触发，然后用于规划、
设计、建造或获取、过渡，最后进行交付。此流通常包括采购活动。例如，我们为生物识
别解决方案采购软件和硬件。
Henri：我们针对不同目标管理价值流，将价值链活动与实践相结合，并加以支持。每个
价值流都应该是有效和高效的，并且需要不断改进。
以下各节概述了价值链活动，并定义了每个活动的目的、输入和输出。由于每个价值流由
不同的活动和实践组合组成，因此列出的输入和输出并不总是适用，因为它们特定于特定
的价值流。例如，计划价值链活动的"战略、战术和行动计划"输出分别由战略、战术和业
务规划组成。每个级别可能涉及不同的资源，具有不同的规划周期，并由不同的事件触
发。给出的输入和输出列表不是规定性的，在组织设计其价值流时，可以而且应该进行调
整。
4.5.1 计划

237
ITIL 4 基金会
l
关键消息
计划价值链活动的目的是确保共同了解整个组织的所有四个维度以及所有产品和服务的愿
景、现状和改进方向。
此活动的主要输入是：
⚫ 组织管理机构提供的政策、要求和约束
⚫ 通过参与 l 价值链绩效信息、改进计划以及改进提供的计划提供的综合需
求和机会
⚫ 改进状态报告从改进
有关新的和更改的产品和服务的知识和信息，从设计和过渡，并获得/构建
⚫ 有关参与的第三方服务组件的知识和信息。
此活动的主要输出是：
⚫ 战略、战术和业务计划 l 设计和过渡的体系结构和策略的投资组合决
策 a product ，以及设计和过渡的提升机会， improvement
opportunities for improve 改善 l 产品和服务组合，用于参与 l 合
同和协议要求。
4.5.2 改进
关键消息
改进价值链活动的目的是确保在所有价值链活动和服务管理的四个方面持续改进产品、服
务和做法。

237
ITIL 4 基金会
此价值链活动的主要输入包括：
⚫ 交付和支持利益相关者提供的反馈提供的产品和服务绩效信息
⚫ 所有价值链活动提供的业绩信息和改进机会
⚫ 有关新的和更改的产品和服务的知识和信息，从设计和过渡，并获得/构建
此价值链活动的主要输出是：
⚫ 所有价值链活动的改进计划和计划 l 计划价值链绩效信息，l 以及所
有价值链活动的改进状态报告 l 合同和参与 l 服务绩效信息的签订
要求，用于设计和过渡。
4.5.3 参与
关键消息
参与价值链活动的目的是充分了解利益相关者的需求、透明度、持续参与以及与所有利益
相关者的良好关系。
此价值链活动的主要输入包括：
⚫ 计划提供的产品和服务组合
⚫ 对内部和外部客户提供的服务和产品的高级需求
⚫ 客户对服务和产品的详细要求 l 客户请求和客户反馈 l 事件、服务
请求和用户反馈 l l 信息从当前和潜在客户和用户提供和支持 l 营

237
ITIL 4 基金会
l
销机会以及合作机会和反馈中提供和支持的潜在客户和支持由合作伙伴和
供应商提供 l 合同和协议要求，所有价值链活动 l 知识和信息关于
新的和更改的产品和服务从设计和过渡，并获得/构建
⚫ 供应商和合作伙伴提供有关第三方服务组件的知识和信息
⚫ 产品和服务性能信息来自交付和支持 l 改进计划，以及改进改进状态报
告的改进。
此价值链活动的主要输出是：
⚫ 针对计划 l 产品和服务需求的整合需求和机会，用于设计和过渡 l 用
户支持任务，以交付和支持 l 改进机会，以及利益相关者的反馈，以
改善 l 更改或项目启动请求以获得/构建
⚫ 与外部和内部供应商和合作伙伴签订的合同和协议，以便设计和过渡，并
获得/构建
有关所有价值链活动的第三方服务组件的知识和信息
⚫ 为客户提供服务绩效报告。
4.5.4 设计和过渡
关键消息
设计和过渡价值链活动的目的是确保产品和服务持续满足利益相关者对质量、成本和上市
时间的期望。

237
ITIL 4 基金会
l
⚫ 计划 l 体系结构和由计划 l 提供的产品和服务要求提供的组合决策由参
与 l 改进计划提供，计划由改进 l 改进状态报告提供
⚫ 通过交付和支持提供的服务性能信息，并改进
⚫ 从获取/生成的服务组件
⚫ 有关参与的第三方服务组件的知识和信息
⚫ 有关获取/构建的新的和更改的产品和服务的知识和信息。
⚫ 获得/生成 l 合同的要求和规格以及参与新的和更改的产品和服务
的协议要求，以便交付和支持 l 有关新产品和服务和更改产品和服务的
知识和信息
所有价值链活动
⚫ 绩效信息和改进机会。
4.5.5 获取/生成
关键消息
获取/构建价值链活动的目的是确保服务组件在需要时和地点可用，并符合商定的规范。
⚫ 计划提供的体系结构和策略
⚫ 与外部和内部供应商和合作伙伴签订的合同和协议，以及由参与提供
外部和内部供应商和合作伙伴提供的商品和服务 l 设计和过渡 l 改进计

划提供的要求和规格，改进 l 改进状态报告从改进 l 变化或

237
ITIL 4 基金会
l
⚫ 由交付和支持提供的参与/ 变更请求提供的项目启动请求
⚫ 有关设计和过渡中新产品和服务和更改产品和服务的知识和信息
⚫ 用于交付和支持用于设计和转换的服务组件的服务组件
⚫ 有关新的和已更改的服务组件的知识和信息
所有价值链活动
⚫ 合同和协议要求，参与绩效信息和改进机会的改进。

237
ITIL 4 基金会
4.5.6 交付和支持
关键消息
交付和支持价值链活动的目的是确保按照商定的规范和利益相关者的期望交付和支持服
务。
⚫ 设计和过渡 l 与外部和内部供应商和合作伙伴签订的合同和协议提供
新的和更改的产品和服务
⚫ 由获取/构建 l 改进计划提供的服务组件，以及由改进 l 改进状态
报告提供的改进 l 用户支持任务提供
⚫ 有关新的和更改的服务组件和服务的知识和信息，从设计和过渡，并获取
/生成
⚫ 向客户和用户提供的服务 l 信息，用于参与 l 产品和服务性能信息
的用户支持任务，以便参与和改进 l 改进机会，提高 ll 合同和协议
要求，以便获得/生成 l 服务用于设计和过渡的性能信息。
有关服务价值链活动的进一步详细信息，请参阅其他 ITIL 4 出版物和补充材料。
4.6 持续改进
本组织所有领域和各级，从战略到业务，都不断得到改善。为了最大限度地提高服务的有
效性，每一个为提供服务作出贡献的人都应该牢记持续改进，并应始终寻找改进的机会。

237
ITIL 4 基金会
持续改进模型适用于 SVS 的全部，以及组织的所有产品、服务、服务组件和关系。为了支

持所有级别的持续改进，ITIL SVS 包括：
⚫ ITIL 持续改进模型，为组织提供结构化实施改进的方法
⚫ 改善服务价值链活动，将持续改进融入价值链
⚫ 持续改进实践，支持组织在当今改进中的努力。
ITIL 持续改进模型可用作支持改进计划的高级指南。使用该模型会增加 ITSM 计划成功的

可能性，将重点放在客户价值上，并确保改进工作能够与组织的愿景联系起来。该模型支
持迭代改进方法，将工作划分为可管理部分，并实现可以增量实现的单独目标。
图 4.3 提供了 ITIL 持续改进模型的高级概述。
图 4.3 持续改进模型
请务必记住，模型每个步骤的范围和细节将因主题和改进类型而有很大差异。应该认识
到，此模型可以用作工作流，但它也可以简单地用作合理思维过程的高级提醒，以确保正
确管理改进。该流程旨在确保改进与组织的目标挂钩，并适当确定优先次序，并确保改进
行动产生可持续的结果。

237
ITIL 4 基金会
逻辑和常识在使用持续改进模型时应始终占上风。此模型的步骤不需要以线性方式执行，
可能需要在某个点重新评估并返回到上一步。使用此模型时应始终应用关键判断。
ITIL 的故事：改进 Axle
Henri 希望 Axle 成为一家更环保的公司，并在其工作中引入更环保的做法。在以下几节

中，Axle 团队使用持续改进模型的步骤来实现对组织的更改。
亨利：在 Axle，我们努力在各个层面持续改进。我们的目标之一是成为更环保的企业，并
将可持续原则纳入每个业务决策。我的团队致力于这一计划。作为我们服务关系模式的一
部分，我们的合作伙伴和供应商也参与其中。
4.6.1 持续改进模型的步骤
本节详细介绍了持续改进模型的每一步。组织可以根据其文化和目标调整这些步骤。该模
型简单灵活，在敏捷文化中与更传统的瀑布文化中一样容易使用。
4.6.1.1 步骤 1：什么是愿景？
关键消息
每项改进计划都应支持组织的目标和目的。持续改进模型的第一步是确定计划的愿景。这
为以后的所有决策提供了背景，并将个别行动与组织的未来愿景联系起来。
此步骤重点介绍两个关键领域：

237
ITIL 4 基金会
⚫ 需要为特定业务单位、部门、团队和/或个人翻译组织的愿景和目标，以便
了解任何改进计划的背景、目标和界限。
⚫ 需要为计划的改进制定高级别愿景。
此步骤中的工作应确保：
⚫ 高层方向已被理解
⚫ 计划的改进计划在此背景下描述和理解
⚫ 利益相关者及其角色已得到理解 the expected value to be realized is
understood and agreed
⚫ 负责实施改进的个人或团队在实现组织愿景方面的作用是明确的。
如果跳过此步骤，改进可能仅针对所涉及的人员或团队进行优化，而不是针对整个组织进
行优化，否则非增值活动可能成为改进的唯一焦点。
ITIL 的故事：愿景是什么？
Henri：Axle 的愿景是让企业成为全球三大绿色租车公司之一。为此，成立了一个名为
"Axle 绿色"的持续改进计划。
克雷格：作为 Axle 的清洁服务供应商，我会支持他们进行改进计划。
4.6.1.2 第 2 步：我们现在在哪里？

237
ITIL 4 基金会
关键消息
改进计划的成功取决于对倡议起点和影响的明确和准确的理解。改进可以看作是从点 A 到
点 B 的旅程，此步骤清楚地定义了点 A 的外观。如果起点不详，则无法规划行程。
此步骤的一个关键要素是当前状态评估。这是对现有服务的评估，包括用户对所收到价值
的看法、人们的能力和技能、所涉及的流程和程序以及/或现有技术解决方案的能力。组织
的文化，即所有利益相关者群体的普遍价值观和态度，也需要理解，以决定需要何种级别
的组织变革管理。
当前状态评估应尽可能通过客观衡量进行。这将使能够准确理解与当前状态有关的问题，
并在实施倡议后，能够适当衡量与初始状态相比达到的改进水平。如果建立了良好的测量
系统，在最初记录拟议的改进时，可能已经提供了完成此步骤的信息。
如果跳过此步骤，则不会理解当前状态，也不会有客观的基线测量。因此，很难跟踪和衡
量改进活动的有效性，因为以后无法将新状态与以前的状态进行比较。
ITIL 的故事：我们现在在哪里？
苏：我们需要了解基线。如果我们不知道我们从哪里开始，我们怎么知道我们是否有所改
善？目前，我们车队中只有 5%的车辆是电动的。
克雷格：我的清洁产品只有 20%是可生物降解的。
4.6.1.3 第 3 步：我们想要去哪里？

237
ITIL 4 基金会
关键消息
正如上一步（步骤 2）描述了改进过程中的点 A 一样，步骤 3 概述了目标 B（旅程下一

步的目标状态）应是什么样子。如果目的地不明确，则无法规划行程。
根据前两个步骤的结果，可以进行差距分析，评估从起点到实现倡议愿景的距离的范围和
性质。必须指出，这项倡议的最初设想是令人向往的，可能永远不会完全实现。改进是目
标，而不是完美。此步骤应根据起点上已知的操作定义一个或多个完成改进愿景的优先级
操作。可以根据差距分析确定改进机会并确定其优先级，并可以确定改进目标以及关键成
功因素（CSF）和关键绩效指标（KPI）。
商定的目标、CSF 和 KPI 需要遵循所谓的 SMART 原则。它们应具体、可衡量、可实

现、相关且有时限。如果确切目的地已知，则定义改进旅程的路线要容易得多。必须指
出，目标状态代表实现愿景的进展，而不是实现整个愿景。
如果跳过此步骤，目标状态将保持不明确。很难对主要利益攸关方从改进倡议中获得哪些
好处作出令人满意的解释，这可能导致支持不足，甚至倒退。
ITIL 的故事：我们想要去哪里？
苏：在五年内，我们希望 50%的车队由电动汽车组成。另一半应符合汽油和柴油汽车最严
格的生态要求。
克雷格：我的 KPI 之一是，我 90%的清洁产品将在未来两年内进行生物降解。
拉迪卡：这是一个伟大的倡议。在我们的 IT 团队中，我们希望使用可生物降解的杯子。我
们也希望 Axle 在所有的办公室使用环保灯泡。
4.6.1.4 步骤 4：我们如何到达那里？

237
ITIL 4 基金会
现在，改进旅程的开始和结束点已经确定，可以商定特定路线。基于对改进愿景的理解以
及目前和目标国家，并将这些知识与主题专门知识相结合，可以制定应对该倡议挑战的计
划。
关键消息
步骤 4 的计划可以是完成单个简单改进的一条简单直接路径，或者可能涉及更多。执行改
进的最有效方法可能并不明确，有时需要设计实验，以测试哪些选项具有最大的潜力。
即使要遵循的路径是明确的，在一系列迭代中执行工作可能也是最有效的，每个迭代都会
推动改进的一部分。每次迭代时，都有机会检查进度、重新评估方法以及酌情更改方向。
如果跳过此步骤，则改进的执行可能会失败，并且无法实现所需的改进。失败的改进会削
弱信心，并难以为未来的改进提供支持。
ITIL 的故事：我们如何到达那里？
克雷格：我的计划是，在我们用完时，用可生物降解的选择来取代我们目前的清洁产品库
存。同时，我们将测试新产品，以找到价格和质量的最佳平衡。
苏：有时候知道你如何到达那里是很容易的，但是用电动汽车替换我们一半的车队是一个
更大的挑战。我们不希望多余的汽车在我们的车很多，如果他们不被使用。我们亦必须考
虑不同国家的具体情况和基础设施，以及地方法规。
拉迪卡：我们鼓励使用陶瓷杯而不是塑料杯。我们停止购买塑料杯，我们正在购买陶瓷杯
我们所有的办公室。

237
ITIL 4 基金会
4.6.1.5 步骤 5：采取行动
关键消息
在步骤 5 中，将执行改进计划。这可能涉及传统的瀑布式方法，但通过试验、迭代、更改
方向甚至回到以前的步骤来遵循敏捷方法可能更合适。
一些改进是一项大计划的一部分，它进行了大量变革，而其他改进则很小，但意义重大。
在某些情况下，通过实现多个较小的改进迭代来实现更大的更改。即使完成改进的道路在
计划时似乎很清楚，但在整个方法过程中保持开放以改变也是很重要的。达到预期的结果
是目标，而不是僵化地坚持如何继续的一种观点。
在改进过程中，需要持续关注衡量愿景进展和管理风险，以及确保对举措的可见性和整体
意识。ITIL 实践，如组织变革管理（第 5.1.6 节）、计量和报告（第 5.1.5 节）、风险管理
（第 5.1.10 节）以及当然持续改进（第 5.1.2 节）是在这一步骤中取得成功的重要因素.
完成此步骤后，工作将处于旅程的终点，从而产生新的当前状态。
ITIL 故事：采取行动
克雷格：我们已经开始用可生物降解的选择来取代我们的清洁产品库存。我们找到了一些
伟大的新产品使用，甚至设法节省资金通过使用更便宜的替代品，不损害质量。
苏：我们已经开始逐步淘汰一些旧的汽油和柴油汽车，代之以新的电动车型。我们已彻底
检查我们所饲养的汽油和柴油汽车，以确保它们符合生态要求，并将采取行动，在它们不
达标的地方解决这个问题。
Radhika：我们把新的可生物降解的杯子和环保灯泡带到我们的办公室，并开始拆除塑料
杯。

237
ITIL 4 基金会
4.6.1.6 第 6 步：我们到那里了吗？
此步骤涉及检查行程的目的地，以确保已达到所需点。
关键消息
往往，一旦一个改进计划启动，假定已经实现了预期的好处，而且可以把注意力转向下一
个倡议。在现实中，改进之路充满了各种障碍，因此必须验证成功。
对于改进倡议的每一次迭代，都需要检查和确认进展（已经实现了最初目标吗？如果未达
到预期结果，则选择并执行完成工作的其他操作，通常会导致新的迭代。
如果跳过此步骤，则很难确定是否实际实现了预期或承诺的结果，并且此迭代中的任何经
验教训（如果需要，将支持课程更正）都将丢失。
ITIL 的故事：我们到那里了吗？
克雷格：几个月后，我们成功实现了 90%的产品可生物降解的目标。
苏：电动汽车正在推出，但由于后勤原因，更换汽油和柴油汽车比我们预期的要困难得
多。如果我们要达到我们的五年目标，我们需要以更快的速度做到这一点。我们现在可能
必须重新考虑我们的目标，并决定我们是否应该采取更多工作来支持它，或者是否需要修
订。
Radhika：我们的办公室现在有可生物降解的杯子和环保灯泡。一些旧的塑料杯仍在使
用，但我们已经停止购买更多，所以一旦它们用完，它们就会消失。

237
ITIL 4 基金会
4.6.1.7 步骤 7：我们如何保持势头？
关键消息
如果改进实现了预期价值，则倡议的重点应转向营销这些成功，并加强采用的任何新方
法。这是为了确保取得的进展不会丧失，并为下一步的改进建立支持和势头。
应利用组织变革管理和知识管理做法将变革嵌入组织，并确保改进和改变的行为不会面临
回归风险。领导者和管理者应帮助团队真正将新的工作方法融入日常工作中，并将新行为
制度化。
如果改进的预期结果没有实现，则需要向利益攸关方通报该倡议失败的原因。这需要对改
进进行彻底分析，记录和传达经验教训。这应包括根据收集到的体验，描述在下一次迭代
中可以采取哪些不同操作的内容。无论当前迭代的结果如何，透明度对于将来的努力都很
重要。
如果跳过此步骤，则改进很可能仍然是孤立的独立举措，并且随着时间的推移，所取得的任
何进展都可能丢失。可能也很难获得对未来改进的支持，并难以将持续改进嵌入到组织文
化中。
ITIL 的故事：我们如何保持这种势头？
克雷格：现在我们已经达到了目标，我们将监控我们购买的任何新产品，以确保它们符合
我们的可生物降解标准。我们亦会留意任何机会，以更环保的替代品取代我们剩余的非生
物降解产品。
苏：我们在 Axle 车队中增加了新的电动汽车，但还没有达到我们的目标。现在，我们需要

分析是什么阻碍了我们达到我们的目标，记录我们学到了什么教训，并决定今后可以采取
哪些不同的做法，使电动汽车的引入更加有效。

237
ITIL 4 基金会
Radhika：我们将继续为办公室购买陶瓷杯和环保灯泡。我们亦会考虑进一步的方法，使
我们的办公室更环保，并与员工一起开展运动，鼓励他们更环保。
4.6.2 持续改进和指导原则
遵循持续改进模型，组织可能会从应用 ITIL 指导原则中获益匪浅。所有原则都适用，在改

进计划的每一步都适用并相关。然而，一些指导原则与持续改进模式的具体步骤特别相
关。在改进的每一步都遵循这些原则，增加了步骤和整体改进计划取得成功的机会。表 4.3
概述了持续改进模式每个指导原则的哪些步骤特别相关，尽管所有原则都适用于某一级的
所有步骤。
表 4.3 持续改进模型的步骤与最相关的 ITIL 指导原则相关联

注重价从现在通过反馈协作并提升思考和工保持简单优化和自
值开始迭代进度可见性作实用动化
整体
愿景是什 * * *
么？
我们现在在 * *
哪里？
我们想去 * * * *
哪里？
我们怎么去 * * * *
那里？
采取行动 * * *
我们到那里 * * *
了吗？
我们如何保 * * * *
持
势头去？

237
ITIL 4 基金会
持续改进与约束理论
在日益活跃的商业环境中，企业快速变化的能力，无论是为了应对外部因素还是扰乱市
场，都能使失败与成功之间产生不同的影响。
在规划改进时，必须专注于最优先的工作。
根据约束理论（ToC），价值链中最薄弱的环节决定了系统的流动和吞吐量。最薄弱的环节
必须尽可能提升（有时揭示新的最薄弱环节），价值链中的所有其他步骤都必须围绕它组
织。
可以通过价值流映射确定价值流的最弱环节。这是一种精益实践，它检查流，量化其浪费
（例如，延迟），并在此过程中识别其最薄弱的环节。
如果最薄弱的环节是信息系统的开发，那么敏捷原则和实践的应用可以提高功能开发的质
量和速度。这包括业务和 IT 之间的关键交互，其中所需的功能与非功能要求一起定义。
ITIL 4 个对此有帮助的实践包括软件开发和管理、业务分析和关系管理。
如果最薄弱的环节是部署的速度和可靠性，那么使用 DevOps 原则、技术实践和工具可以

产生显著的影响。与此相关的 ITIL 4 实践包括部署管理、发布管理和组织更改管理。
最后，如果最薄弱的环节是 IT 服务的交付和支持，则可以使用 IT 运营实践和工具，例如

ITIL 4 事件管理、问题管理、服务台以及基础架构和平台管理实践。
持续改进不仅是精益的组成部分，也是敏捷（回顾）、DevOps（持续实验和学习、掌握）
和其他框架的组成部分。它是 ITIL SVS 的关键组件之一，与指导原则一起为成功的服务管
理提供了坚实的平台。
4.7 实践
实践是一组组织资源，专为执行工作或完成目标而设计。这些资源被分组到第 3 章概述的
服务管理的四个维度中。ITIL SVS 包括一般管理实践、服务管理实践和技术管理实践，所有
这些都在第 5 章中介绍。

237
ITIL 4 基金会
4.8 摘要
ITIL SVS 描述了组织的所有组件和活动如何作为一个系统协同工作，以实现价值创造。每

个组织的 SVS 都与其他组织建立了接口，形成了一个生态系统，为组织、其客户和其他
利益相关者创造价值提供便利。
ITIL SVS 是现代产品和服务治理和管理的强大整体结构，使组织能够与消费者共同创造价

值。SVS 包括由通用和整体实践支持的服务价值链活动，使组织能够管理和满足所有类型
的需求。这些需求包括让组织在竞争环境中蓬勃发展和发展的战略需求，以及信息、服务
或支持的运营要求。每个组织都参与此处描述的某种形式的价值链活动，即使其中许多活
动是由供应商和合作伙伴执行的。ITIL 4 指南可以进行调整和采用，以促进整个 SVS 的
价值、反馈和持续改进。

237
ITIL 4 基金会
5 ITIL 管理实践
ITIL SVS 包括 14 项一般管理实践、17 项服务管理实践和 3 个技术管理实践，所有这些
都受服务管理的四个维度的约束（见第 3 章）
。
关键消息
在 ITIL 中，管理实践是一组组织资源，专为执行工作或完成目标而设计。做法的起源如
下：
⚫ 一般管理做法已经采用并调整为一般业务管理领域的服务管理。
⚫ 服务管理和 ITSM 行业已制定服务管理实践。
⚫ 技术管理实践已从技术管理领域调整，用于服务管理目的，将其重点从技
术解决方案扩展或转移到 IT 服务。
表 5.1 列出了 34 个 ITIL 管理实践。
表 5.1 ITIL 管理实践

一般管理实践服务管理实践技术管理实践

237
ITIL 4 基金会
架构管理可用性管理部署管理
持续改进业务分析基础设施和平台管理
信息安全管理容量和性能管理软件开发和管理
知识管理更改控制
测量和报告事件管理
组织变革管理 IT 资产管理
投资组合管理监控和事件管理
项目管理问题管理
关系管理发布管理
风险管理服务目录管理
服务财务管理服务配置管理
战略管理服务连续性管理
供应商管理服务设计
劳动力和人才管理服务台
服务级别管理
服务请求管理
服务验证和测试
现代世界中的 ITSM：高速服务管理
在业务创新和差异化中，快速上市是一个关键的成功因素。如果组织实施新业务理念的时
间太长，则其他人可能会更快地完成。因此，组织开始要求其 IT 服务提供商缩短上市时
间。
对于一直使用现代技术的服务提供商来说，这不是一个很大的挑战。他们采用现代方式扩
展资源，并为 IT 服务的项目和产品管理、测试、集成、部署、发布、交付和支持建立了
适当的实践。这些做法已记录在案，并触发了新的 IT 管理运动和实践（如 DevOps）的

237
ITIL 4 基金会
发展。但是，对于拥有旧 IT 体系结构和 IT 管理实践（侧重于控制和成本效益）的组织来

说，新的业务需求带来了更大的挑战。
高速服务交付模式包括：
⚫ 专注于快速向用户交付新的和更改的 IT 服务，持续分析为 IT 服务提供
的反馈，在其生命周期的每个阶段
⚫ 处理反馈的灵活性，导致 IT 服务持续快速改进
⚫ 服务生命周期的端到端方法，从构思到创建和交付，到服务使用
⚫ 整合产品和服务管理实践，实现 IT 基础设施的数字化，采用云计
算，实现服务交付链的广泛自动化。
高速服务交付影响服务提供商的所有实践，包括一般管理实践、服务管理实践和技术管理
实践。例如，旨在以比其他人更快速地交付和改进其服务的组织需要考虑：
⚫ 敏捷项目管理 l 敏捷财务管理 l 基于产品的组织结构 l 自适应风
险管理，审计和合规性管理 l 柔性体系结构管理 l 特定的体系结
构技术解决方案，如微服务 l 复杂合作伙伴和供应商环境 l 持续监
控技术创新，并试验 l 以人为中心的设计，以及以云计算为重点的基
础设施管理。
即使提供商产品组合中的某些服务需要高速交付，也需要大规模组织变革来实现这一点，
尤其是在组织具有低速服务、做法和习惯的传统时。此外，双模态 IT 将高速服务管理与
传统实践相结合，带来了更加复杂和更大的挑战。然而，对于许多现代组织来说，高速服
务交付不再是一种选择，而是一种必要，它们必须改进其服务管理实践，以应对这一挑
战。
5.1 一般管理做法
5.1.1 架构管理

237
ITIL 4 基金会
关键消息
体系结构管理实践的目的是了解构成组织的所有不同要素以及这些要素之间的相互关系，
使组织能够有效地实现其当前和未来的目标。它提供了原则、标准和工具，使组织能够以
结构化和敏捷的方式管理复杂的更改。
正如现代组织的环境和生态系统变得更加复杂一样，其挑战也日益严峻。这不仅包括如何
提高效率和自动化，还包括如何更好地管理环境的复杂性以及如何实现组织敏捷性和弹
性。如果没有适当的体系结构管理实践带来的可见性和协调性，组织可能会成为第三方合
同的迷宫、跨不同组织孤岛的变体流程、为不同客户不必要地自定义的各种产品和服务以
及传统基础架构。结果是一个复杂的环境，任何变化都变得更加难以实现，并带来更高的
风险。
完整的体系结构管理实践应解决所有体系结构域：
业务、服务、信息、技术和环境。对于更小、不太复杂的组织，架构师可以开发单个集成
体系结构。
体系结构类型
业务架构
业务体系结构允许组织根据它们如何与为组织及其客户创造价值所需的所有详细活动保持
一致来查看其功能。然后，将这些因素与组织的战略进行比较，并针对当前功能对目标状
态进行差距分析。确定基线和目标状态之间的差距是优先排序的，这些能力差距是逐步解
决的。"路线图"描述了实现组织战略从当前状态到未来状态的转变。
服务架构
服务体系结构使组织能够查看它提供的所有服务，包括描述结构（服务组件如何组合在一
起）的服务和服务模型之间的交互（活动、流程每个服务的资源和交互）。服务模型可用作
多个服务的模板或蓝图。

237
ITIL 4 基金会
信息系统体系结构，包括数据和应用程序体系结构
信息体系结构描述组织的逻辑和物理数据资产以及数据管理资源。它显示了如何管理和共
享信息资源，以利于组织。
信息是组织的宝贵资产，具有实际和可衡量的价值。信息是决策的基础，因此信息必须始
终完整、准确，并且对于有权访问信息的人员进行访问。因此，信息系统的设计和管理时
必须考虑到这些概念。
技术架构
技术体系结构定义了支持产品和服务组合所需的软件和硬件基础结构。
环境建筑
环境体系结构描述了影响组织的外部因素和变革驱动因素，以及环境控制及其管理的所有
方面、类型、级别。环境包括发展、技术、商业、运营、组织、政治、经济、法律、监
管、生态和社会影响。
图 5.1 架构管理对价值链活动的贡献热图
图 5.1 显示了体系结构管理对服务价值链的贡献，所有价值链活动都涉及这种做法;但是，
它在规划、改进、设计和过渡价值链活动中发挥最大作用：

237
ITIL 4 基金会
⚫ 规划体系结构管理实践负责开发和维护一个参考体系结构，用于描述业
务、信息、数据、应用程序、技术和环境透视的当前和目标体系结构。这
用作所有计划价值链活动的基础。
⚫ 改进通过审查业务、服务、信息、技术和环境体系结构，确定了许多改进
机会。
⚫ 参与架构管理实践有助于了解组织是否准备好应对新的或服务不足的市场
以及更广泛的产品和服务，并更快地响应不断变化的环境。体系结构管理
实践负责评估组织的能力，使其与共同为组织及其客户创造价值所需的所
有详细活动保持一致。
⚫ 设计和过渡一旦批准开发新的或更改的产品或服务，体系结构、设计和构
建团队将持续评估产品/服务是否符合投资目标。体系结构管理实践负责服
务体系结构，它描述服务的结构（服务组件如何组合在一起）和服务的动
态（活动、资源流和交互）。服务模型可用作多个服务的模板或蓝图，对于
设计和转换活动至关重要。
⚫ 获取/构建参考体系结构（业务、服务、信息、技术和环境）便于识别需要
获取或构建哪些产品、服务或服务组件。
⚫ 交付和支持参考体系结构不断用作产品和服务的操作、恢复和维护的一部
分。
5.1.2 持续改进
关键消息
持续改进实践的目的是通过不断识别和改进服务、服务组件、实践或高效、高效地管理产
品和服务。
持续改进实践的范围包括开发与改进相关的方法和技术，并在整个组织中传播持续改进文
化，与组织的总体战略保持一致。持续改进的承诺和实践必须融入到组织的每一个纤维
中。如果不是，则存在一种实际风险，即日常运营问题和重大项目工作将掩盖持续改进工
作。

237
ITIL 4 基金会
持续改进实践的一部分的关键活动包括：
l 鼓励整个组织持续改进，确保持续改进的时间和预算，l 确
定和记录改进机会，评估和改进机会并确定其优先级，为
改进行动制定业务案例，规划和实施改进 l 衡量和评估改
进结果，协调整个组织的改进活动。
有许多方法、模型和技术可用于改进。不同类型的改进可能需要不同的改进方法。例如，
一些改进最好地组织成多阶段项目，而其他改进可能更适合作为单个快速工作。
ITIL SVS 包括持续改进模型（参见图 4.3），可应用于任何类型的改进，从高级组织更改到

单个服务和配置项（CI）。该模型在第 4.6 节中进行了描述。
在评估当前状态时，可以使用许多技术，例如强度、弱点、机会和威胁（SWOT）分
析、平衡记分卡审核、内部和外部评估和审计，甚至几种技术。各组织应发展满足其需要
的方法和技术能力。
持续改进的方法在许多地方都有。精益方法为消除浪费提供了视角。敏捷方法侧重于以节
奏逐步进行改进。DevOps 方法全面有效，确保改进不仅设计良好，而且应用有效。虽然
有许多方法可用，但各组织不应尝试正式承诺采用太多不同的方法。最好选择一些适合组
织通常处理的改进类型的关键方法，并培养这些方法。这样，团队将共同了解如何共同改
进，从而以更快的速度促进更多变革。
然而，这并不意味着组织不应尝试新的方法或允许创新。应鼓励组织中具有替代方法技能
的人员在有意义的时候应用这些方法，如果此努力成功，则可将替代方法添加到组织的剧
目中。如果取得更好的结果，较老的方法可能会逐渐被停用，转而采用新的方法。
持续改进是每个人的责任。虽然可能有一组工作人员全职关注这项工作，但本组织的每个
人都必须明白，积极参与持续改进活动是他们工作的核心部分。为了确保这不仅仅是一个
良好的意图，明智的做法是将所有职务描述和每个员工的目标以及与外部供应商和承包商
的合同中持续改进。
组织最高层需要承担责任，将持续改进融入人们思考和工作的方式。没有他们的领导才能
和对持续改进的明显承诺，态度、行为和文化就不会发展到在各级所做的一切中都考虑改
进的程度。
应向工作人员提供培训和其他辅助援助，帮助他们感到愿意为持续改进作出贡献。尽管每
个人都应该以某种方式做出贡献，但至少应该有一个小型团队专职领导持续改进工作，并

237
ITIL 4 基金会
在整个组织中倡导这种做法。该团队可以担任协调员、指导和导师，帮助组织中的其他人
发展所需的技能，并驾驭可能遇到的任何困难。
当第三方供应商构成服务环境的一部分时，它们也应该成为改进努力的一部分。在为供应
商服务签订合同时，合同应包括他们在合同生命周期内如何衡量、报告和改进其服务的详
细信息。如果需要供应商提供数据才能进行内部改进，则应在合同中指定。仔细分析和理
解的准确数据是基于事实的决策改进的基础。持续改进做法应得到相关数据源和数据分析
的支持，以确保充分理解和确定每个潜在改进的优先级。
为了跟踪和管理从识别到最终操作的改进想法，组织使用称为持续改进寄存器（CIR）的
数据库或结构化文档。组织中可以有多个 CIR，因为可以在个人、团队、部门、业务单位
和组织级别维护多个 R。某些组织维护单个主 CIR，但划分如何使用它以及由谁在更精细
的级别使用。
改进想法最初也可以在其他地方通过其他实践（如在项目执行或软件开发活动期间）捕
获。在这种情况下，记录作为持续持续改进的一部分提出的改进想法非常重要。随着新想
法的记录在案，CIR 被使用来不断重新确定改进机会的优先级。使用 R 提供了附加价值，
因为它们有助于使事物可见。这不仅仅限于目前正在做什么，而且还包括已经完成哪些工
作已经完成，哪些已经预留给以后进一步审议。
CIR 中的信息结构的确切方式并不重要，也不需要在任何给定组织中调用改进想法的集
合。重要的是，改进想法被捕获、记录、评估、优先处理和适当行动，以确保组织及其服
务始终得到改进。
持续改进实践是所有服务以及 SVS 本身的完整生命周期的发展和维护不可或缺的。这就是

说，有些做法对持续改进作出了特殊贡献。例如，组织的问题管理实践可以发现将通过持
续改进进行管理的问题。如果没有组织变革管理的关键贡献，通过持续改进启动的变革可
能会失败。许多改进计划将使用项目管理实践来组织和管理其执行。

237
ITIL 4 基金会
图 5.2 持续改进对价值链活动的贡献热图
图 5.2 显示了持续改进对服务价值链的贡献，所有价值链活动都涉及这种做法：
⚫ 计划持续改进实践应用于规划活动、方法和技术，以确保它们与组织当前
目标和上下文相关。
⚫ 持续改进实践是这种价值链活动的关键。它构建资源和活动，使本组织和
SVS 各级的改进成为可能。
⚫ 设计、过渡、获取/构建、交付和支持每个价值链活动都有待持续改进，持
续改进实践适用于所有。
5.1.3 信息安全管理
关键消息
信息安全管理实践的目的是保护组织开展业务所需的信息。这包括了解和管理信息的机密
性、完整性和可用性的风险，以及信息安全的其他方面，如身份验证（确保某人是他们声
称的身份）和不否认（确保有人不能否认他们采取了行动）
。

237
ITIL 4 基金会
所需的安全性是通过策略、流程、行为、风险管理和控制来建立的，它们必须在以下两者
之间保持平衡：
l 预防确保安全事件不发生 l 检测快速可靠地检测无法阻止的事件 l 更正在检测
到事件后从事件中恢复。
在保护组织免受伤害和允许组织创新之间取得平衡也很重要。过于严格的信息安全控制可
能弊大于利，或者被试图更轻松地完成工作的人规避。
信息安全控制应考虑组织的所有方面，并与其风险偏好保持一致。
信息安全管理与所有其他实践进行交互。它创建每个实践在规划如何完成工作时必须考虑
的控件。它还依赖于其他实践来帮助保护信息。
信息安全管理必须根据明确理解的治理要求和组织政策从组织最高级级别驱动。大多数组
织都有专门的信息安全团队，负责进行风险评估并定义策略、程序和控制措施。在高速环
境中，信息安全尽可能纳入发展和行动的日常工作，将对过程控制的依赖转向核查专门知
识和完整性等先决条件。
信息安全在很大程度上取决于整个组织人员的行为。经过良好培训并注意信息安全策略和
其他控制的员工可以帮助检测、预防和更正信息安全事件。培训不足或积极性不足的员工
可能是一个主要弱点。
支持信息安全管理需要许多流程和程序。
其中包括：
⚫ 信息安全事件管理流程 l 风险管理流程 l 控制审查和审核流程 l 身
份和访问管理流程 l 事件管理 l l 渗透测试、漏洞扫描等程序。
⚫ 用于管理与信息安全相关的更改的过程，如防火墙配置更改。

237
ITIL 4 基金会
图 5.3 信息安全管理对价值链活动的贡献热图
图 5.3 显示了信息安全管理对服务价值链的贡献，所有价值链活动都涉及以下做法：
⚫ 在所有规划活动中必须考虑计划信息安全，并且必须融入到每个实践和服
务中。
⚫ 在所有改进价值链活动中必须考虑提高信息安全，以确保在进行改进时不
会引入漏洞。
⚫ 必须了解和捕获新服务和更改服务的信息安全要求。从业务到战略性各级
参与必须支持信息安全，并鼓励必要的行为。所有利益相关者都必须为信
息安全做出贡献，包括客户、用户、供应商等。
⚫ 设计和过渡在整个价值链活动中必须考虑信息安全，并设计和过渡到运
营。所有服务的设计和转换必须考虑信息安全方面以及所有其他公用事业
和保修要求。
⚫ 获取/构建信息安全必须基于信息安全管理定义的风险分析、策略、过程和
控制构建到所有组件中。无论组件是内部制造还是从供应商采购，这都适
用。
⚫ 交付和支持信息安全事件的检测和更正必须是此价值链活动的一个组成部
分。

237
ITIL 4 基金会
ITIL 故事：Axle 的信息安全管理
Su：我们的旅游应用程序存储了很多敏感数据，包括客户和信用卡详细信息。我们的职责
是确保这些数据是安全的。
Marco：部分数据也由我们的合作伙伴存储和处理，他们帮助我们开发应用程序，并继续
代表我们支持应用程序。
Radhika：我们使用这些数据来分析客户需求和车队使用情况，跟踪我们的汽车状况，并
分析客户的偏好，以创建量身定制的产品。
苏：我们的消费者需要知道他们的数据是安全的，不会被滥用。我们定期接受外部审计，
为我们的利益相关者提供保证，并确认遵守国家和国际法规。
Henri：作为 CIO，我确保在 Axle 工作并与之合作的每一个人都了解信息安全的重要

性，并遵循与信息安全管理有关的 Axle 政策和程序。
5.1.4 知识管理
关键消息
知识管理实践的目的是保持和改进整个组织的信息和知识的有效、高效和方便使用。
知识是组织最有价值的资产之一。知识管理实践提供了一种结构化的方法，以各种形式定
义、构建、重用和共享知识（即信息、技能、实践、解决方案和问题）
。随着获取和共享知
识的方法越来越趋向于数字解决方案，知识管理实践变得更加重要。
重要的是要明白，"知识"不仅仅是信息。知识是在特定环境中使用信息。这需要了解这一
点，同时了解用户的知识和相关情况。例如，以 300 页手册形式显示的信息对于需要找到
快速解决方案的服务台分析人员没有用处。适合目的的知识的更好示例可能是一组简化的
说明或参考点，使分析人员能够快速查找相关内容。

237
ITIL 4 基金会
知识管理旨在确保利益相关者根据其访问级别和其他相关政策，以适当的格式、正确的级
别和正确的时间获得正确的信息。这需要一个获取知识的程序，包括开发、获取和收集非
结构化知识，无论是正式和有文件记载的，还是非正式和默示知识。
图 5.4 知识管理对价值链活动的贡献热图
图 5.4 显示了知识管理对服务价值链的贡献，所有价值链活动都涉及以下实践：
⚫ 计划知识管理可帮助组织做出合理的投资组合决策，并确定其战略和其他
计划，并支持财务管理。
⚫ 改进此价值链活动基于对当前情况和趋势的理解，并辅以历史信息。知识
管理为评估成果和改进规划提供了背景。
⚫ 从战略到运营，从战略到运营的各级参与关系都基于对这些关系的背景和
历史的理解。知识管理有助于更好地了解利益相关者。
⚫ 设计和过渡随着获取/构建价值链活动，对可用解决方案和技术的了解以及
信息的重用，可以使这种价值链活动更加有效。
⚫ 获得/构建这种价值链活动的效率可以显著提高，只要充分了解现有的解决
方案和技术，并通过重新利用信息。
⚫ 通过在标准情况下重用解决方案，以及更好地了解需要分析的非标准情
况，提供和支持这一领域的持续价值链活动，受益于知识管理。

237
ITIL 4 基金会
ITIL 故事：Axle 的知识管理
Radhika：由于我们在应用开发中使用敏捷部署，我们需要确保我们的员工掌握有关新功
能的最新知识。同样重要的是，知识在过时时需要停用。例如，我们最近发现我们的应用
程序的打印功能没有被我们的客户使用。我们删除了打印，并将其替换为一个新功能，以
通过电子邮件发送应用程序的信息。作为发布管理的一部分，我们已经向服务台提供了更
新的知识文章，以反映更改。
苏：知识管理不仅仅是数据收集。在 Axle，我们专注于开放沟通和知识共享。为了促进协
作和可见性，我们确保我们的团队和分支机构之间公开共享信息、问题和顾虑。
亨利：但是我们还需要遵循信息安全政策，确保开放并不意味着粗心大意。
Marco：我们正在测试基于 AI 的新系统，以改进我们在从战略规划到用户支持等各个级
别的预测和决策。
5.1.5 测量和报告
关键消息
衡量和报告做法的目的是通过降低不确定性水平来支持良好的决策和持续改进。这是通过
收集各种托管对象的相关数据并在适当的上下文中有效评估这些数据来实现的。托管对象
包括但不限于产品和服务、实践和价值链活动、团队和个人、供应商和合作伙伴以及整个
组织。
其中许多托管对象是连接的，它们各自的指标和指标也是如此。例如，要为衡量和报告设
定明确的目标，需要了解组织目标。这些可以基于多个领域：利润、增长、竞争优势、客

237
ITIL 4 基金会
户保留、运营/公共服务等（参见第 4.3.1 节中对价值指导原则的关注）。在这种情况下，

在高级别和次级目标与与其有关的目标之间建立明确的关系十分重要。
对于设定的目标，可以定义运营关键成功因素（CSF）。基于这些 CSF，可以商定一组相

关的关键绩效指标（KPI），并在此基础上衡量其成功与否。
定义
⚫ 关键成功因素（CSF）实现预期结果的必要先决条件。
⚫ 关键绩效指标（KPI）用于评估实现目标成功与否的重要指标。
5.1.5.1 KPI 和行为
个人的 KPI 可以作为竞争激励因素发挥作用，如果 KPI 设置为满足明确的业务目标，这

将推动积极的结果。然而，为个人设定目标也可能有消极的一面，导致不恰当或不适当的
行为。如果过于关注单个 KPI，通常会发生这种情况。例如，服务台员工可能会被迫缩短
呼叫时间，但如果问题得不到妥善处理，这可能会对客户满意度甚至解决时间产生负面影
响。
理想情况下，应该为团队设置运营 KPI，而不是过于关注个人。这意味着团队在整个允许
的目标和行为方面可以有一定的灵活性。当然，个人仍然需要一些具体的绩效准则，但这
应明确符合团队和组织的目标，所有目标都应在为组织提供价值的背景下设定。
5.1.5.2 报告
作为指标收集的数据通常以报表或仪表板的形式显示。请务必记住，报告旨在支持良好的
决策，因此其内容应与信息的接收者相关，并与其所需主题相关。报表和仪表板应使收件
人能够轻松查看需要执行的操作，然后采取措施。因此，一个好的报告或仪表板应该回答
两个主要问题：我们离目标有多远，以及哪些瓶颈阻碍我们取得更好的结果？

237
ITIL 4 基金会
图 5.5 衡量和报告对价值链活动的贡献热图
图 5.5 显示了衡量和报告对服务价值链的贡献，所有价值链活动都涉及这种做法：
⚫ 计划衡量和报告通过提供产品和服务当前绩效的详细信息，实现战略和服
务组合决策。
⚫ 不断监控和评估绩效，以支持持续改进、一致性和价值创造。
⚫ 与利益相关者的接洽基于以仪表板和报告形式提供的正确、最新和足够的
信息。
⚫ 设计和过渡测量和报告在上线前每个阶段为管理决策提供信息。
⚫ 做法确保所有开发和采购活动的透明度，从而能够进行有效的管理和与所
有其他价值链活动的整合。
⚫ 交付和支持产品和服务的持续管理基于正确、最新和足够的性能信息。
5.1.6 组织变革管理

237
ITIL 4 基金会
关键消息
组织变革管理实践的目的是确保组织变革顺利成功实施，并通过管理变革的人性化方面实
现持久效益。
改进总是要求人们改变工作方式、行为，有时需要改变他们的角色。无论变革是实践、组
织结构、技术相关，还是引入新的或改变的服务，人们对于变革的成功至关重要。组织变
革管理实践旨在确保受变革影响的每个人都接受和支持变革。这是通过消除或减少对变革
的阻力、消除或消除不利影响，并提供培训、认识和其他手段，确保成功过渡到变化状态
来实现的。
组织变革管理有助于 SVS 的每个部分，无论需要相关人员的合作、参与和热情。为了成功

改进倡议，无论变革的水平或范围如何，都有某些要素对于解决人为因素至关重要。组织
变更管理必须确保在整个变革过程中建立和维护以下事项：
⚫ 明确和相关的目标要获得支持，变革的目标必须明确，并基于组织背景对
利益相关者有意义。必须认为这种变化有实际价值。
⚫ 坚强和坚定的领导变革必须获得组织内发起人和日常领导者的积极支持。
发起人是经理或业务领袖，他们将倡导并授权更改。领导者应明确支持并
始终如一地传达他们对变革的承诺。
⚫ 愿意和准备好的参与者要取得成功，需要由愿意的参与者做出改变。部分
地，这种意愿将来自与会者对变革重要性的深信不疑。此外，准备越多的
参与者觉得，他们要通过相关的培训、意识和定期沟通来改变他们要求的
变化，他们就越热衷于向前推进。
⚫ 持续改善许多变化失败，因为，经过一段时间后，人们又回到了旧的工作
方法。组织变革管理旨在通过定期沟通、处理变革的任何影响和后果以及
发起人和领导者的支持，不断强化变革的价值。当使用指标验证消息时，
值的通信将更强。
5.1.6.1 组织变革管理活动
表 5.2 概述了有效组织变革管理的关键活动。表 5.2 组织变革管理活动
活动帮助交付

237
ITIL 4 基金会
创造紧迫感明确和相关的目标，愿意参与
利益相关者管理坚强和忠诚的参与者
赞助商管理坚强和坚定的领导
通信愿意和准备好的参与者
授权准备好的参与者
电阻管理愿意参加者
加固持续改善
组织变革管理的活动与许多其他做法的活动相互作用，特别是持续改进和项目管理。与组
织变革管理有重要联系的其他实践包括衡量和报告、员工和人才管理以及关系管理。
必须确定受变革影响的各种受众，并确定其特征。并非所有人都会响应相同的消息，或者
由相同的驱动程序激励。在组织变革管理中，考虑到文化差异，无论是基于地理、国籍、
公司历史还是其他因素，都尤为重要。
与其他做法不同，组织变更管理的责任不能移交给外部供应商。组织内部的人员必须负责
组织变更管理，即使执行部分或全部组织变更管理活动委托给其他人或团体（包括供应
商）。但是，可以寻求外部专门知识来补充组织的组织变革管理能力。有时，组织难以掌握
组织变革管理所需的关键技能，并可以从外部供应商的支持和指导中获益。即使使用外部
帮助，总体领导支持仍必须来自组织本身。

237
ITIL 4 基金会
图 5.6 组织变革管理对价值链活动的贡献热图
图 5.6 显示了组织变更管理对服务价值链的贡献，所有价值链活动都涉及这种做法：
⚫ 计划有关项目组合级别变更的决策，导致启动组织变更管理以支持已批准
的计划。
⚫ 改进没有适当的组织变革管理，改进就无法持续。
⚫ 参与组织变革管理实践，在变革的各个阶段与利益相关者积极互动。
⚫ 设计和过渡组织更改管理对于部署新服务或对现有服务进行重大更改至关
重要。
⚫ 获得/建立组织变更管理确保项目内部和项目之间的参与与合作。
⚫ 交付和支持组织变革管理在实时运营和支持期间继续进行，以确保变革得
到采纳和持续。
5.1.7 投资组合管理

237
ITIL 4 基金会
关键消息
组合管理做法的目的是确保组织拥有适当的方案、项目、产品和服务组合，以在其资金和
资源限制范围内执行组织的战略。
项目组合管理是战略决策的协调集合，共同实现组织变革和一切业务的最有效平衡。项目
组合管理通过以下活动来实现这一点：
⚫ 制定和应用一个系统框架，以定义和提供一系列产品、服务、方案和项
目，以支持具体的战略和目标。
⚫ 明确定义产品和服务并将其与实现商定结果联系起来，从而确保服务价值
链中的所有活动都与价值定义和相关 CSF 保持一致。
⚫ 根据资源限制、现有承诺以及组织的战略和目标，评估和确定传入产品、
服务或项目提案和其他变革计划的优先次序。
⚫ 基于对价值、成本、风险、资源约束、相互依赖和对现有业务活动的影响
的理解，实施战略投资评估和决策过程。
⚫ 根据产品、服务、计划和项目对组织及其客户的价值分析和跟踪投资。
⚫ 监测整个项目组合的业绩，并针对组织优先事项的任何变化提出调整建
议。
⚫ 根据进度、结果、成本、风险、收益和战略贡献审查投资组合。
项目组合管理在在整个组织中分配、部署和管理资源方面发挥着重要作用。这有助于将资
源和功能与客户成果保持一致，作为 ITIL SVS 战略执行的一部分。
投资组合管理包括许多不同的投资组合，包括：
⚫ 产品/服务组合产品/服务组合是由组织管理的全套产品和/或服务，它代表
组织在所有客户和市场空间的承诺和投资。它还代表当前的合同承诺、新
的产品和服务开发，以及因持续改进而启动的持续改进计划。该产品组合
还可能包括第三方产品和服务，这是向内部和外部客户提供的产品不可或
缺的一部分。
⚫ 项目组合项目组合用于管理和协调已授权的项目，确保在时间和成本限制
和规格范围内实现目标。项目组合还确保项目不重复，项目保持在商定的

237
ITIL 4 基金会
范围内，并确保每个项目都有资源可用。它是用于管理单个项目和由多个
项目组成的大型方案的工具。
⚫ 客户组合客户组合由组织的关系管理实践维护，为投资组合管理实践提供
了重要的输入。客户组合用于记录组织的所有客户，是关系经理对从组织
接收产品和/或服务的内部和外部客户的看法。
项目组合管理使用客户组合来确保业务成果、客户和服务之间的关系得到
充分理解。它记录了这些联系，并通过关系管理实践与客户进行了验证。
敏捷投资组合管理
方案和项目的成功历来取决于在预算内按时完成执行的程度，并交付了所需的产出、成果
和效益。然而，在许多情况下，各组织一直难以证明其投资回报来自变革，人们越来越认
识到，只有方案或项目是第一个执行"正确"倡议，才有可能取得真正的成功。地方。敏捷
项目组合管理进一步关注战略主题的可视化，并能够快速重新确定项目组合的优先级、增
加工作流程、减少批处理工作规模以及控制长期开发队列的长度.
传统的项目组合管理侧重于自上而下的规划，工作期限较长，但敏捷组合管理采用构建-度
量-学习周期的概念，由各个敏捷团队使用，并将其应用于整个组织基础。团队协同工作，
使用模块化设计，并分享调查结果。这带来了极大的灵活性，将重点从继续执行不灵活的
计划转向根据业务战略和目标交付价值和取得实际进展。
实践敏捷组合管理的组织在整个业务中尽可能多地沟通。他们分享知识，打破组织孤岛之
间的障碍。

237
ITIL 4 基金会
图 5.7 投资组合管理对价值链活动的贡献热图
图 5.7 显示了投资组合管理对服务价值链的贡献，所有价值链活动都涉及该实践：
⚫ 计划组合管理提供有关当前正在管道或目录中的项目、产品和服务状态以
及它们旨在满足哪些战略目标的重要信息，这对于规划至关重要。投资组
合管理还包括从进度、价值创造、成本、风险、收益和战略贡献的角度审
查投资组合。
⚫ 改进项目组合管理可发现提高效率和增加协作的机会，消除项目之间的重
复，并识别和降低风险。改进计划优先，如果获得批准，可添加到相关产
品组合中。
⚫ 当组织确定机会或需求时，如何确定这些机会或需求的优先级将根据组织
的战略以及风险评估和资源可用性做出决策。
⚫ 设计和过渡、获取/构建以及交付和支持投资组合管理负责确保产品和服务
被明确定义并与实现业务成果相关联，以便这些价值链活动与价值保持一
致。

237
ITIL 4 基金会
5.1.8 项目管理
关键消息
项目管理实践的目的是确保组织中的所有项目都成功交付。这是通过规划、授权、监控和
维护对项目各个方面的控制，并保持相关人员的积极性来实现的。
项目是向组织引入重大变革的方法之一，可以定义为根据商定的业务案例为交付一个或多
个输出（或产品）而创建的临时结构。它们可能是一项独立倡议，也可以是一个更大的方
案的一部分，以及其他相互关联的项目，用于更复杂的转型。但是，即使是独立的项目也
应在本组织的项目组合中加以考虑。
交付项目的方式有不同的方法，瀑布和敏捷方法最为常见：
⚫ 瀑布方法适用于预先知道需求（不太可能显著改变）以及工作定义比交付
速度更重要的环境中。
⚫ 当需求不确定且可能随时间而快速变化（例如，随着业务需求和优先级的
变化），以及交付速度通常优先于精确需求定义的优先级时，敏捷方法效果
最佳。
成功的项目管理非常重要，因为组织必须平衡其需要：
⚫ 有效、高效地维持当前业务运营，将业务运营转变为改变、生存和市场竞
⚫ 不断改进其产品和服务。
项目和"一切照旧"之间的这种平衡可能会影响许多领域，包括资源（人员、资产、财务）、
服务级别、客户关系和工作效率，因此组织的能力和能力必须被视为其项目管理方法的一
部分。

237
ITIL 4 基金会
项目取决于项目团队和更广泛的组织内人员的行为。如果合适的人在正确的时间没有参
与，最好的项目计划就很少了。项目与组织之间的关系也需要考虑，因为许多项目团队成
员将从业务运营中全部或部分借调。
图 5.8 项目管理对价值链活动的贡献热图
图 5.8 显示了项目管理对服务价值链的贡献，所有价值链活动都涉及以下做法：
⚫ 计划项目管理使用方法和工具支持战略和战术规划。
⚫ 改进许多改进计划是庞大而复杂的，因此项目管理是管理这些计划的相关
实践。
⚫ 让利益相关者参与是成功交付任何项目的关键因素。项目管理为组织提供
了利益相关者管理工具和技术。
⚫ 实践或服务的设计与转换设计可以作为项目或较大项目中的迭代进行管理;
这同样适用于某些转换。
⚫ 获取/生成获取新资源以及开发和集成通常作为项目执行。各种项目管理技
术适用于此活动。

237
ITIL 4 基金会
⚫ 交付和支持需要精心策划和执行对内部或外部服务使用者进行设计、过渡
和移交，以确保一切正常运营不会受到影响。项目管理实践确保这种情况
发生。
5.1.9 关系管理
关键消息
关系管理实践的目的是在战略和战术层面建立和培养本组织与其利益攸关方之间的联系。
它包括识别、分析、监测和持续改进与利益相关者的关系和利益相关者之间的关系。
关系管理实践确保：
⚫ 了解利益相关者的需求和驱动因素，并适当确定产品和服务的优先级
⚫ 利益相关者的满意度很高，组织与利益相关者之间建立和维护建设性关系
⚫ 客户根据预期业务成果确定并阐明客户对新产品和服务的优先级
⚫ 任何利益相关者的投诉和升级都通过同情（但正式）程序妥善处理
⚫ 产品和服务为服务消费者以及组织创造价值
⚫ 组织根据组织的战略和优先事项，促进所有利益相关者创造价值
⚫ 冲突的利益相关者要求得到适当的调解。
服务提供商自然会将大部分精力集中在与服务消费者（赞助商、客户和用户）的关系上。
它是一个非常重要的利益相关者群体;但是，组织应确保了解和管理与内部和外部各种利益
相关者的关系。关系管理实践应适用于所有相关方。这意味着该实践有助于所有服务价值
链活动和多个价值流。

237
ITIL 4 基金会
图 5.9 关系管理对价值链活动的贡献热图
图 5.9 显示了关系管理对服务价值链的贡献，所有价值链活动都涉及该实践：
⚫ 计划关系管理提供有关内部和外部客户的要求和期望的信息。它还协助跨
投资组合进行战略评估和优先次序，以及评估当前和未来市场空间，这是
规划的基本方面。
⚫ 改善关系管理旨在协调和协同与内部和外部客户建立不同的组织关系，通
过持续改进实现有针对性的利益。
⚫ 参与关系管理是负责与内部和外部客户接洽以了解其要求和优先事项的实
践。
⚫ 设计和过渡关系管理在协调内部和外部客户的反馈方面发挥着关键作用，
作为设计的一部分。它还确保避免或尽量减少过渡期间给客户的不便和不
利影响。
⚫ 获取/构建关系管理提供客户要求和优先级，以帮助选择要获得或构建的产
品、服务或服务组件。

237
ITIL 4 基金会
⚫ 交付和支持关系管理负责确保建立和维护高水平的客户满意度以及组织与
客户之间的建设性关系。
5.1.10 风险管理
关键消息
风险管理实践的目的是确保组织了解并有效地处理风险。管理风险对于确保组织的持续可
持续性和为客户创造价值至关重要。风险管理是所有组织活动的组成部分，因此是组织
SVS 的核心（关于风险定义的第 2.5.3 节）。
风险通常被视为要避免的东西，因为它与威胁有关，虽然这通常是真实的，风险也与机会
有关。未能抓住机会本身就是一种风险。服务不足的市场空间和未满足的需求的机会成本
是一个需要避免的风险。
组织的投资组合可以映射到要管理的风险基础组合。当服务管理有效时，服务目录和管道
中的产品和服务是为客户、组织和其他利益相关者创造和获取价值的机会。否则，这些产
品和服务可能会构成威胁，因为可能失败，因为它们吸引的需求模式、它们需要的承诺以
及它们产生的成本。实施策略通常需要更改产品和服务组合，这意味着管理相关风险。
有关风险的决策需要平衡，以便潜在收益对组织的价值大于处理风险的成本。例如，创新
本质上是有风险的，但在改善产品和服务、实现竞争优势以及提高敏捷性和弹性方面可能
提供重大好处。组织限制其风险敞口的能力也将具有相关性。目标应该是准确评估特定情
况下的风险，并分析潜在好处。应界定每个行动方针提供的风险和机会，以确定适当的对
策。
为了有效的风险管理，风险需要：
⚫ 查明的可能影响在特定组织活动范围内实现目标的不确定因素。必须考
虑这些不确定性，然后加以描述，以确保有共同的理解。

237
ITIL 4 基金会
⚫ 评估必须估计单个风险的概率、影响和邻近程度，以便确定这些风险的
优先级，并了解与组织活动相关的总体风险（风险敞口）。
⚫ 必须计划对风险采取适当的应对措施，分配所有者和操作者，然后实
施、监控和控制风险。
以下原则特别适用于风险管理实践：
⚫ 风险是业务的一部分组织应确保风险得到适当管理。这并不意味着所有
风险都是可以避免的。相反，为确保长期可持续性，需要冒险。但是，
需要根据组织愿意承担的风险级别（即风险偏好）确定、理解和评估风
险，并对其进行适当管理和监测。
⚫ 整个组织风险管理必须保持一致风险管理，必须全面管理风险管理实
践，以实现整个组织的一致性。为确保有效性，应不断与利益攸关方协
商，并为组织的不同部门提供适当灵活性。这种灵活性将允许制定量身
定制的风险管理程序，以便解决组织单位和/或客户特定情况。
⚫ 风险管理文化和行为很重要组织各级人员所展示的适当文化和行为至关
重要，必须作为"我们做事的方式"的一部分加以嵌入。这种行为和信念
将证明这一点：：
⚫ 理解有效的风险管理对组织的可持续性至关重要，并支持实现业务目标
⚫ 使用主动风险管理行为
⚫ 确保风险管理程序、角色、责任和问责制的透明度和明确性
⚫ 积极鼓励和跟踪风险、事件和机会的报告
⚫ 确保薪酬结构支持预期行为（即这不应妨碍报告事件或鼓励过度报告）
⚫ 积极鼓励从组织的经验和其他组织的经验中学习和成长。

237
ITIL 4 基金会
ISO 31000：2018 风险管理
这些准则全面、笼统地展望了风险管理的目的和原则。它们适用于任何类型的组织的所有
级别。最高原则是"风险管理的目的是创造和保护价值"，风险管理"提高绩效，鼓励创新，
支持实现目标"。

237
ITIL 4 基金会
图 5.10 风险管理对价值链活动的贡献热图
图 5.10 显示了风险管理对服务价值链的贡献，所有价值链活动都涉及该实践：
⚫ 计划风险管理为组织的战略和规划提供重要投入，重点是能够推动结果可
变性的风险。其中包括：l 客户需求和优先事项的转移，以及法律和法规改
革 l 竞争对手
⚫ 对供应商和合作伙伴的依赖性 l 技术变革与利益冲突的利益相关者要
求。
⚫ 改进所有改进计划都应评估并持续控制风险管理实践。风险管理为改进优
先级、规划和审查确立了重要视角。
⚫ 参与风险管理实践有助于识别关键利益相关者，并根据风险偏好和风险简
介等信息优化参与度。
⚫ 设计和过渡产品和服务应旨在解决优先风险。例如，它们应可扩展，以支
持需求随时间的变化。对于组织而言，新的或更改的服务具有不同的风险
级别，应在批准更改之前确定和评估这些风险级别。如果获得批准，风险
应作为更改的一部分进行管理，包括发布、部署和项目。

237
ITIL 4 基金会
l
⚫ 获取/构建风险管理应为有关获取或构建产品、服务或服务组件的决策提供
信息。
⚫ 交付和支持风险管理有助于确保产品和服务的持续交付保持在商定的水
平，并确保根据它们引入的风险有效管理所有事件。
5.1.11 服务财务管理
关键消息
服务财务管理实践的目的是通过确保有效利用组织的财政资源和投资来支持组织的服务管
理战略和计划。
服务财务管理支持理事机构的决策和组织管理层在何处最好地分配财政资源。它提供了与
产品和服务相关的预算、成本核算和会计活动的可见性。为了在 SVS 中有效，这种做法
需要与组织在项目组合管理、项目管理和关系管理方面的政策和做法保持一致。
财务是使组织能够与其利益相关者进行有效沟通的共同语言。服务财务管理负责管理组织
的预算、成本核算、会计和收费，同时充当服务提供商和服务使用者：
⚫ 预算/成本核算这是一项侧重于预测和控制组织内资金的收入和支出的活
动。预算编制包括一个定期谈判周期，以制定预算和持续监测当前预算。
为了实现这一目标，它侧重于捕获预测和实际服务需求。它将这一需求转
化为用于制定预算和费率以确保为产品和服务提供充足的资金的预期业务
和项目费用。基于服务的预算编制力求了解预算，并根据提供服务或消费
服务的全部成本建立供资模式。
⚫ 会计此活动使组织能够充分考虑其资金的使用方式，从而能够比较预测与
实际成本和支出（特别是按客户、服务和活动/成本中心确定使用情况和成
本的能力）。它通常涉及会计系统，包括分类帐、会计图表和日记帐。

237
ITIL 4 基金会
l
⚫ 向此活动收费是正式为服务使用者（通常是外部）为其提供的服务开具发
票所必需的。必须指出，虽然收费是一种任择做法，但所有服务都需要一
种供资模式，因为所有费用都需要通过商定的方法提供充足的资金。
图 5.11 服务财务管理对价值链活动的贡献热图
图 5.11 显示了服务财务管理对服务价值链的贡献，所有价值链活动都涉及以下做法：
⚫ 各级计划都需要基于信息（包括财务）的资金。服务财务管理支持使用预
算、报告、预测和其他相关信息进行规划。
⚫ 改进所有改进都应优先考虑投资回报。服务财务管理为改进评估和确定优
先级提供了工具和信息。
⚫ 参与财务考虑对于与服务消费者、供应商和合作伙伴建立和维护服务关系
非常重要。对于一些利益相关者（投资者、发起人）来说，这种关系的财
务方面是最重要的。本实践通过提供财务信息支持这种价值链活动。
⚫ 设计和过渡服务财务管理通过提供财务规划和控制手段，有助于保持这项
活动的成本效益。它还确保服务提供商产品和服务费用的透明度，并考虑
到设计和过渡支出。
⚫ 获得/建立所有类型的资源由预算（确保足够的资金）和会计（确保透明度
和评价）提供支持。

237
ITIL 4 基金会
l
⚫ 交付和支持持续运营成本是组织支出的重要组成部分。对于商业组织，持
续服务
交付活动也是收入来源。服务财务管理有助于确保充分理解两者。计费
（如果适用）支持服务提供商和服务使用者与计费和报告的关系。
新技术财务管理的演变
财务管理是指以最适当的方式高效有效地管理资金，以实现组织的财务目标。财务管理学
科自成立以来，经历了不同程度的变革、改进和创新。这一变化的一个关键组成部分是新
技术的出现。许多技术发展都影响了财务管理，但三个关键创新是引入更多的数字技术、
区块链、IT 预算和支付模式。
数字技术
主要金融机构正在分析和使用最新的技术，如云、大数据、分析和人工智能（AI），以获
得甚至只是为了保持市场竞争优势。但是，新的财务组织也在使用这些技术，无需任何遗
留的 IT、技术债务或官僚流程即可开始运营，这意味着他们往往更加敏捷。
财务组织正在利用大数据和分析来更深入地洞察和理解其客户。捕获的数据量惊人，需要
可扩展的计算能力来高效且经济高效地处理数据。作为回报，这种更深入的客户理解正促
使金融机构开发新的创新产品和服务。数据现在被称为"新石油"，因为组织正争先恐后地
捕获、分析和利用它。
区块链
财务管理的另一个演变是通过一种称为区块链的特定创新实现的，这种创新只能通过基于
云的服务实现。最初开发区块链是为了实现加密货币的去集中管理，允许自动和廉价地审
核和验证交易。
区块链技术用于管理公共数字账本。这些数字分类账记录跨许多全球分布的计算机的事
务。记录分布可确保在不更改所有后续记录（也称为块）且没有整个分布式分类帐（也称
为网络）的共识的情况下，无法更改每个记录。

237
ITIL 4 基金会
l
全球金融机构正在研究这种区块链技术如何通过简化后台功能和降低银行交易结算利率来
为他们提供竞争优势。新的金融组织正在研究区块链，以传统银行的成本和开销的一小部
分提供替代银行功能。
IT 预算和支付模型
新技术的出现不仅影响了金融机构，还影响了每个组织从财务角度管理其 IT 服务的方
式。目前的大部分技术发展浪潮是由云计算实现的，而且这种情况似乎在可预见的未来会
持续下去。这导致 IT 服务获得、资助和由组织支付的方式发生了重大变化。
传统上，IT 资源是使用前期资本支出（CAPEX）获得的。但是，在云模式下，提供 IT

基础结构、平台和软件是"即服务"。此模型通常使用基于订阅的即用即付收费机制，这些
机制由运营支出（OPEX）支付。
出现变化的另一个领域是组织设置和管理 IT 预算的方法。需要灵活的 IT 预算来满足以敏

捷和按需方式扩展基于云的服务的成本。固定 IT 预算（通常提前几个月预测）很难以这
种方式考虑 IT 资源的扩展。
组织内的采购规则也不得不改变。固定价格的 IT 项目和服务仍有一席之地;但是，基于云
的数字服务通常以可变价格模式出售，即使用和使用越多，支付越多，反之亦然。因此，
那些尚未更新其采购规则以允许它们购买可变定价的 IT 资源的组织将面临一个很大的自
制障碍，阻止他们使用基于云的数字服务。为了尽可能有效，组织必须更新其政策并教育
其员工，以确保他们能够在可变定价模式下购买 IT。
5.1.12 战略管理
关键消息
战略管理做法的目的是制定本组织的目标，并通过实现这些目标所需的行动方针和资源分
配。战略管理确定组织的方向，集中工作，定义或阐明组织的优先事项，并针对环境提供
一致性或指导。

237
ITIL 4 基金会
战略管理的出发点是了解组织的上下文并定义预期的结果。本组织的战略确立了标准和机
制，帮助决定如何最好地确定资源、能力和投资的优先级，以实现这些结果，而实践确保
战略得到定义、商定、维护和实现。
战略管理的目标是：
⚫ 分析组织存在的环境，以确定对组织有利的机会
⚫ 确定可能妨碍实现业务成果的限制，并定义如何消除这些限制或减少其影
响
⚫ 决定组织的观点和方向与相关利益相关者，包括其愿景、使命和原则
⚫ 建立组织相对于客户和竞争对手的视角和地位。这包括定义哪些服务和产
品将提供给哪些市场空间以及如何保持竞争优势
⚫ 确保该战略已转化为预期要实施战略的每一个组织单位的战术和行动计
划，确保通过执行战略计划和协调战略、战术和行动各级的努力来实施
战略
⚫ 管理策略和相关文档的更改，确保战略跟上内部和外部环境的变化以及其
他相关因素。
战略管理通常被视为一个组织高级管理层和理事机构的责任。它使他们能够确定组织的目
标，具体说明组织将如何实现这些目标，并确定实现这些目标所需的投资的优先级。然
而，在当今复杂、瞬息万变的环境中，基于深思熟虑、广泛研究和情景规划的传统战略实
践也在不断发展。战略正变得越来越灵活，人们越来越注重确定一个组织的基本宗旨和原
则，即使情况发生变化，本组织也可以作为其所有行动的指导方向。例如，精益策略流程
可用于平衡严格规划和不受控制实验的极端情况。该战略为组织提供了整体方向和一致
性，既是创新理念必须通过的屏幕，也是评估 SVS 成功的基础。它鼓励员工发挥创造
力，同时确保他们与组织和谐相处，只追求宝贵的机会。
战略必须为组织实现价值创造。良好的业务模式描述了实现组织目标的方法。组织的战略
应包括某种方式使其服务和产品对其客户具有独特的价值;因此，它必须定义组织提供更好
价值的方法。战略的必要性并不限于较大的组织;因此，战略需要不仅限于大型组织。对于
较小的公司来说，这同样重要，使他们能够有一个清晰的观点、定位和计划，以确保他们
与客户保持相关性。

237
ITIL 4 基金会
l
客户希望的解决方案能够突破性能障碍，在成本很少或根本没有增加时实现更高质量的结
果。此类解决方案通常通过创新产品和服务提供。该战略应平衡组织提供高效和有效运营
与创新和面向未来活动的需求。
从客户或组织的角度来看，产品和服务的价值可能会随着时间的推移而随着条件、事件或
组织无法控制的其他因素的变化而发生变化。战略管理可确保对组织与客户的关系采取经
过深思熟虑的方法，以及处理定义这些关系的价值变化时的敏捷性和弹性。
高性能战略使组织能够随着时间的推移、跨业务周期、行业中断期间以及当领导层发生变
化时始终超越竞争替代方案。它应侧重于整个组织需要做些什么，以促进价值的创造。
图 5.12 战略管理对价值链活动的贡献热图
图 5.12 显示了战略管理对服务价值链的贡献，所有价值链活动都涉及以下做法：
⚫ 计划战略管理确保组织的战略已转化为预期交付该战略的每个组织单位的
战术和行动计划。
⚫ 改进战略管理提供了用于确定改进优先级和评估改进的战略和目标。
⚫ 当组织确定机会或需求时，有关如何确定这些机会或需求优先级的决策基
于组织的战略以及风险评估和资源可用性。

237
ITIL 4 基金会
l
⚫ 设计和过渡、获取/构建以及交付和支持战略管理确保通过与这些活动协调
执行战略计划来实施战略。它还提供反馈，以便在设计和过渡期间对产品
和服务进行测量和评估。
5.1.13 供应商管理
关键消息
供应商管理实践的目的是确保对组织的供应商及其绩效进行适当的管理，以支持无缝提供
高质量的产品和服务。这包括与关键供应商建立更紧密、更协作的关系，以发现和实现新
价值，降低失败风险。
实践的核心活动包括：
l 创建单一的可见性和控制点以确保一致性这应跨越内部和外部供应商（包
括作为供应商的客户）提供或操作的所有产品、服务、服务组件和程序。
l 维护供应商战略、政策和合同管理信息
⚫ 谈判和商定合同和安排协议需要与业务需求和服务目标保持一致。与外部
供应商的合同可能需要通过组织的法律、采购、商业或合同职能进行谈判
或商定。对于内部供应商，需要签订内部协议。
⚫ 管理与内部和外部供应商的关系和合同在规划、设计、建造、编排、过渡
和运营产品和服务时，应与采购和绩效管理密切合作。
⚫ 应监控供应商绩效管理供应商绩效，以确保它们符合合同和协议的条款、
条件和目标，同时旨在提高从供应商获得的资金价值及其提供的产品/服
务。
5.1.13.1 采购、供应商战略和关系
供应商战略（有时称为采购战略）定义了组织的计划，以确定其将如何利用供应商在实现其
总体服务管理战略方面的贡献。

237
ITIL 4 基金会
l
有些组织可能采取一种战略，规定只有在非常具体和有限的情况下才使用供应商，而另一
个组织可以选择在提供产品和服务时广泛使用供应商。成功的采购战略需要全面了解组织
的目标、实施该战略所需的资源、环境因素（例如市场因素）以及与实施特定方法相关的
风险。
组织与其供应商之间存在不同类型的供应商关系，需要将其视为组织采购战略的一部分。
其中包括：
⚫ 外包产品或服务由组织内部开发和/或交付。
⚫ 外包外部供应商提供以前在内部提供的产品和服务的过程。外包涉及替
代，即由供应商取代内部能力。
⚫ 单一来源或合作伙伴从一个供应商处采购产品或服务。这可以是直接提供
所有服务的单个供应商，也可以是管理与所有供应商的关系并代表组织集
成其服务的外部服务集成商。这些密切的关系（以及他们创造的相互依存
关系）培养了高质量、可靠性、短时间以及合作行动。
⚫ 多源从多个独立供应商采购产品或服务。这些产品和服务可以组合起来，
形成组织可以向内部和外部客户提供的新服务。随着组织更加注重提高专
业化和能力的划分以提高敏捷性，多采购越来越成为首选选择。传统上，
组织在组织的不同部门单独管理这些供应商，但正在朝着开发内部服务集
成功能或选择外部服务集成商的方向发展。
个别供应商可以提供支持服务和产品，这些服务和产品独立地在价值生成中具有相对次要
和相当间接的作用，但共同为此和实施组织战略。
5.1.13.2 供应商的评价和选择
组织应根据以下情况评估和选择供应商：
⚫ 供应商提供的服务对企业的价值的重要性和影响
⚫ 风险与使用服务相关的风险 l 成本服务的成本及其提供。
评估和选择供应商的其他重要因素包括供应商在多供应商环境中定制其产品或合作工作的
意愿或可行性;组织或服务集成商对供应商绩效的影响程度;以及一个供应商对其他供应商的
依赖程度。

237
ITIL 4 基金会
l
5.1.13.3 活动
供应商管理实践的活动包括：
⚫ 供应商规划此活动的目的是了解新的或更改的服务要求，并审查相关的企
业文档，以制定采购战略和供应商管理计划，并结合其他实践，如业务分
析、项目组合管理、服务设计和服务级别管理。
⚫ 评估供应商和合同此活动的目的是确定、评估和选择供应商，以便提供新
的或更改的业务服务。
⚫ 供应商和合同谈判此活动的目的是制定、谈判、审查、更新、最终确定和
授予供应商合同。谈判失败将触发新合同、更新合同或合同终止。
⚫ 供应商分类本程序旨在定期对供应商进行分类，并在授予新的或更新的合
同之后。常用类别包括战略、战术和商品供应商。
⚫ 供应商和合同管理此活动的目的是确保组织获得物有所值，并针对合同和
目标交付供应商的商定履约。
⚫ 保修管理本活动的目的是管理保修要求或条款，并在出现保修问题时与性
能管理一起提出保修索赔。
⚫ 绩效管理此活动包括与内部和外部供应商共同商定的操作措施的设置和持
续跟踪。它侧重于关键措施，然后可以合并到供应商记分卡上。监测将有
助于查明系统性问题和改进机会，并为报告提供依据。
⚫ 合同续签和/或终止本程序旨在管理合同续签和终止，这些合同的续签和终
止是由对供应商绩效进行特定或定期审查触发的。
5.1.13.4 服务集成
服务集成负责协调或协调参与产品和服务开发和交付的所有供应商。它侧重于端到端提供
服务，确保控制供应商的所有接口和结果，并促进供应商之间的协作。组织可以执行服务
集成器本身的角色，也可以使用第三方服务集成商。可以开发混合模型，其中组织负责某
些服务集成功能，并将该功能与外部服务集成器的功能增强。服务集成功能也可以由领先
供应商操作。服务集成商也负责保证;这包括绩效管理和报告、确定角色和责任、保持各方
关系，以及领导定期论坛和指导委员会解决问题、商定优先事项和做出决策。

237
ITIL 4 基金会
图 5.13 供应商管理层对价值链活动的贡献热图
图 5.13 显示了供应商管理对服务价值链的贡献，所有价值链活动都涉及这种做法：
⚫ 计划供应商管理提供组织批准的采购战略和计划。
⚫ 改进实践确定与现有供应商的改进机会，参与选择新供应商，并提供持续
的供应商绩效管理。
⚫ 聘请供应商管理层负责与所有供应商接触，评估和选择供应商;谈判和商定
合同和协议;以及持续管理供应商关系。
⚫ 设计和过渡供应商管理层负责根据组织的需求和服务目标，定义与新产品
或服务相关的合同和协议的要求。
⚫ 获取/构建供应商管理支持从第三方采购或获取产品、服务和服务组件。
⚫ 现场服务的交付和支持供应商绩效由此实践管理，以确保供应商符合其合
同和协议的条款、条件和目标。

237
ITIL 4 基金会
l
ITIL 故事：Axle 的供应商管理
马可：我被分配到 Axle 的供应商管理角色。这意味着我将与我们的供应商一起管理每月的

治理论坛，以跟踪其服务级别协议中概述的服务绩效。我将确保供应商的合同义务符合车
车租赁业务成果。
拉迪卡：例如，我们向客户保证，汽车将始终清洁。我们过去每周都会清洗汽车，但为了
满足新的服务承诺，克雷格的清洁会每次返回停车场时清洁汽车。
Henri：Axle 的服务依赖于多个合作伙伴和供应商。我们与汽车经销商和制造商、轮胎制
造商、清洁工和路边辅助供应商合作。我们也有 Axle 代理，他们推广我们的产品，以及
忠诚计划的合作伙伴，他们以特殊条件为客户提供服务。
Radhika：我们的 IT 系统也使用许多合作伙伴和供应商的服务。这支持 Axle 在从互联网

接入到软件开发等多个层面的工作。
Marco：在 Axle 实现更大的数字化意味着有更多机会将 IT 融入我们的服务产品中。

Axle 应用程序通过个人设备预订和支付租车费用成为可能。Axle 感知系统安装在每辆车
上，并得到 IT 和我们的合作伙伴的支持。车队维护是根据车辆的租用历史进行规划的，
并由我们的 IT 系统控制。
Henri：因此，Axle 的业务现在严重依赖 IT 和非 IT 供应商。整合和协调这些服务是供

应商管理的一部分。我们期望我们的供应商为 Axle 和我们的客户提供一致的质量水平。
5.1.14 劳动力和人才管理
关键消息
员工队伍和人才管理实践的目的是确保组织拥有具备适当技能和知识并发挥正确角色支持
其业务目标的合适人员。实践涵盖一系列广泛的活动，重点是成功与组织的员工和人力资
源互动，包括规划、招聘、入职、学习和发展、绩效衡量和继任规划。

237
ITIL 4 基金会
劳动力和人才管理通过帮助组织主动了解和预测未来的服务需求，在建立组织速度方面发
挥着至关重要的作用。它还确保具备必要能力的合适人员能够在正确的时间提供所需的服
务。
实现这一目标可减少积压，提高质量，避免缺陷导致的重新工作，减少等待时间，同时缩
小知识和技能差距。随着组织转变实践、自动化和组织能力以支持数字经济并提高上市速
度，拥有合适的人才变得至关重要。
定义：组织速度
组织运行的速度、有效性和效率。组织速度影响市场、质量、安全、成本和风险的时间。
劳动力和人才管理使组织、领导者和管理者能够专注于制定有效和可操作的员工战略，并
在组织内的各个级别执行该战略。一个好的战略应该支持确定角色和相关知识，以及保持
组织日常运转所需的技能和态度。它还应处理为组织未来增长定位所需的新兴技术、领导
力和组织变革能力。
管理和培养组织的员工和人才的想法并不新鲜。然而，随着第三方供应商使用量的增加以
及自动化对可重复工作的迅速采用，传统角色发生了巨大变化。因此，员工和人才管理应
该是整个组织各级领导和管理者的责任。
定义
⚫ 能力可观察和可衡量的知识、技能、能力和态度相结合，有助于提高员工
绩效并最终实现组织成功。
⚫ 技能在思想、言语交流或身体动作方面培养了熟练程度或灵巧性。

237
ITIL 4 基金会
l
⚫ 能力从事与职业或行业相关的身体或精神活动的能力或能力。
⚫ 知识通过经验或教育对事实或信息的理解;对一门学科的理论或实际理解。
⚫ 对特定对象、人员、事物或事件的态度一组情感、信念和行为。
5.1.14.1 劳动力和人才管理活动
这种做法的活动涉及广泛的领域，由各种角色为特定目的执行，包括：
⚫ 员工规划将组织的战略和目标转化为所需的组织能力，然后转化为能力和
角色。
⚫ 招聘招聘新员工和承包商，以填补与预期能力相关的已查明的空白。
⚫ 绩效衡量根据预先确定的能力，根据既定的工作角色定期提供绩效衡量和
评估。
⚫ 员工使用已发布的工作角色和能力框架主动规划个人成长和提升。
⚫ 学习与发展使用各种正式和非正规方法有针对性地进行教育和体验性学习
机会。
⚫ 指导和继任规划由领导提供的正式指导、参与和继任规划活动。
图 5.14 介绍了劳动力和人才管理的活动。

237
ITIL 4 基金会
图 5.14 劳动力和人才管理活动
图 5.15 显示了劳动力和人才管理对服务价值链的贡献，所有价值链活动都涉及这种做法;然
而，它是计划和改进活动的主要重点：
⚫ 计划员工计划是此价值链活动的特定输出，因为领导层和管理层会根据组
织资源的未来需求以及服务组合中定义的产品和服务来评估其当前组织能
力。
⚫ 改进所有改进都需要足够熟练和有积极性的人。员工队伍和人才管理实践
确保了解和满足这些要求。
⚫ 参与劳动力和人才管理与这一价值链活动密切相关。它与关系管理、服务
请求管理和服务台等实践合作，了解和预测不断变化的服务需求需求，以
及这将如何影响并指导员工规划和人才管理活动。

237
ITIL 4 基金会
l
⚫ 设计和过渡人才管理对于这种价值链活动非常重要。具体重点放在与系统
和设计思维相关的知识、技能和能力上。
⚫ 获取/构建人才管理尤其侧重于与协作、客户关注、质量、速度和成本管理
相关的知识、技能和能力。
⚫ 人才管理的具体关注点集中在与客户服务、绩效管理、客户互动和关系相
关的知识、技能和能力上。
图 5.15 劳动力和人才管理对价值链活动的贡献热图
5.2 服务管理实践
5.2.1 可用性管理
关键消息
可用性管理实践的目的是确保服务提供商定的可用性级别，以满足客户和用户的需求。

237
ITIL 4 基金会
定义：可用性
IT 服务或其他配置项在需要时执行其约定功能的能力。
可用性管理活动包括：
⚫ 谈判并商定可实现的可用性目标
⚫ 设计能够提供所需可用性级别的基础架构和应用程序
⚫ 确保服务和组件能够收集衡量可用性所需的数据
⚫ 监控、分析和报告可用性，规划可用性改进。
简单地说，服务的可用性取决于服务失败的频率以及服务在失败后恢复的速度。这些通常
表示为故障（MTBF）和平均恢复服务时间之间的平均时间（MTRS）：
⚫ MTBF 测量服务失败的频率。例如，MTBF 为四周的服务平均每年失败

13 次。
⚫ 地铁公司衡量故障后恢复服务的速度。例如，地铁服务服务为 4 小时，平
均在四小时内完全从故障中恢复过来。这并不意味着服务总是在四小时内
恢复，因为地铁系统是许多事故的平均值。
较旧的服务通常采用非常高的 MTBF 设计，因此不会经常失败。最近，当局已转向优化服

务设计，以尽量减少地铁服务，使服务能够很快恢复。最有效的方法是设计防易碎的解决
方案，这些解决方案能够自动、非常快速地恢复，几乎没有业务影响。对于某些服务，即
使是很短的故障也是灾难性的，对于这些服务，更重要的是专注于增加 MTBF。
定义可用性的方式必须适用于每个服务。了解用户和客户对可用性的看法并定义适当的指
标、报表和仪表板非常重要。许多组织根据 MTBF 和 MTRS 计算可用百分比，但这些百
分比数字很少与客户体验相匹配，并且不适合大多数服务。应考虑的其他事项包括：

237
ITIL 4 基金会
l
⚫ 哪些重要的业务功能受不同的应用程序故障 l 影响，在哪个时候性能缓
慢，导致服务实际上无法使用
⚫ 服务何时需要可用，服务提供商何时可以执行维护活动。
对某些服务工作良好的测量包括：
⚫ 用户中断分钟按事件持续时间乘以受影响的用户数计算，或将每个用户的
分钟数相加
受到影响。这适用于直接支持用户工作效率的服务;例如，电子邮件服务。
⚫ 通过从该时间段内预期发生的交易记录数中减去交易记录数来计算损失的
交易记录数。这非常适合支持基于事务的业务流程的服务，如制造支持。
⚫ 业务价值损失通过衡量支持服务故障对业务生产力的影响进行计算。客户
很容易理解这一点，并且可用于规划投资以提高可用性。但是，很难确定
哪些业务价值损失是由 IT 服务故障引起的，哪些原因也会导致其他原因。
⚫ 用户满意度服务可用性是服务中最重要、最明显的特点之一，对用户满意
度影响很大。除了满足正式商定的可用性目标外，确保用户对服务可用性
感到满意非常重要。
大多数组织没有专门的可用性管理人员。所需的活动通常分布在组织周围。有些组织将可
用性管理活动作为风险管理的一部分，而另一些组织将其与服务连续性管理或容量和性能
管理相结合。某些组织拥有站点可靠性工程师（SREs），他们管理并提高了特定产品或服
务的可用性。
定期测试故障转移和恢复机制需要一个过程。许多组织还有一个计算和报告可用性指标的
过程;但是，可用性管理受到文化、经验和知识的驱动，以及遵循以下过程。
图 5.16 显示了可用性管理对服务价值链的贡献，所有价值链活动都涉及这种做法：
⚫ 在服务组合决策中以及为服务和实践设定目标和方向时，必须考虑计划可
用性管理。
⚫ 改进在规划和进行改进时，可用性管理可确保服务不会降级。
⚫ 必须了解并捕获新服务和更改服务的可用性要求。
⚫ 设计和过渡新服务和更改服务必须设计为满足
在过渡期间需要可用性目标和可用性控制测试。

237
ITIL 4 基金会
l
⚫ 在构建组件或从第三方获取组件时，获取/生成可用性是一个考虑因素。
⚫ 交付和支持此活动包括衡量可用性和对可能影响满足可用性目标的能力的
事件做出反应。
图 5.16 可用性管理对价值链活动的贡献热图
5.2.2 业务分析
关键消息
业务分析实践的目的是分析企业或其某些要素，确定其相关需求，并推荐解决这些需求和/
或解决业务问题的解决方案，这必须促进利益相关者创造价值。业务分析使组织能够以有
意义的方式传达其需求，表达变革的理由，并设计和描述能够根据组织目标创造价值的解
决方案。
分析和解决方案应以整体方式处理，包括考虑流程、组织变革、技术、信息、政策和战略
规划。业务分析工作主要由业务分析师（B）执行，尽管其他人可能会做出贡献。

237
ITIL 4 基金会
l
在 IT 中，业务分析实践经常应用于软件开发项目，但它们也适用于高级体系结构、服务
和组织的服务价值系统（SVS）。仅仅将业务分析应用于软件开发就是存在开发不完整解
决方案的风险。
与业务分析相关的关键活动包括：
⚫ 分析不断变化的内部和外部环境中的业务系统、业务流程、服务或体系结
构
⚫ 确定 SVS 的某些部分以及需要改进的部分产品和服务以及创新机会的优先
级
⚫ 评估和提出可以采取的行动，以创建所需的改进。行动不仅包括 IT 系统更
改，还包括流程更改、组织结构更改和员工发展
⚫ 记录支持服务的业务需求，以实现所需的改进
⚫ 在对收集到的需求进行分析后，建议解决方案，并与利益相关者核实这些
需求。
业务需求可以以实用程序为中心，也可以以保修为中心。
定义
⚫ 保修要求通常非功能性要求捕获为关键利益相关者和其他实践的输入。组
织应致力于管理预定义的保修验收标准库，用于项目管理和软件开发和管
理等实践。
⚫ 实用程序要求由客户定义且对特定产品独一无二的功能要求。
业务分析应确保最有效和全面的完成这些活动，但如果没有后续行动的意图，就不会出
错。组织不应试图如此深入或长时间地分析一个问题，从而无法及时解决问题，或试图用
一项无法在足够时间内促进价值创造的实际用途的单个大规模倡议来解决每个问题。与这
种做法相关的过程应防止这些错误。

237
ITIL 4 基金会
l
业务分析实践的工作范围包括使用和评估来自运营和支持的信息，以积累有关服务和做法
在实时环境中表现的知识。这些知识不仅有助于确定当前服务设计需要改进的领域，而且
还将揭示将改进未来设计的经验教训。
业务分析的角色可能因组织而异，但它是具有一组特定技能的公认学科。业务分析不仅需
要批判性思维和评估，还需要倾听、沟通和便利技能、分析和记录业务流程和用例以及执
行数据分析和建模的能力。
当正在分析的系统或服务跨越许多组织边界时，所涉及的各业务部门必须采用合作伙伴关
系，以确保进行全面分析和全面的解决方案建议。如果需要一个或多个这些单位进行妥
协，则类似合作伙伴的协作关系将促进为各方提供价值的解决方案。
没有正确的信息，业务分析就无法成功，要有效，它需要访问与分析区域有关的所有信
息。例如，对于业务流程，业务分析师需要访问所有流程文档，包括流程、过程和工作说
明、策略和流程指标。他们不仅需要面试负责业务流程的人员，还需要采访参与流程每个
部分的人员，以便对流程和相关问题进行清晰查看。
部署的技术通常包括组织用于收集和记录需求的任何系统，以及用于收集和处理数据和信
息以进行分析的项目管理系统和报告工具。在显示分析结果时，其他可以提供帮助的技术
是可视化建模和映射工具以及许多典型的办公室工作效率套件（如电子表格、演示软件和
文字处理）的功能。
与所有实践一样，业务分析无法单独确保成功的解决方案。例如，战略管理实践为业务分
析提供高级指导，然后指导分析和解决方案建议。反过来，业务分析的建议会影响技术和
其他战略。为了确保权利方的参与，业务分析依赖于关系管理。此外，通过服务价值链的
自然发展需要业务分析活动与服务设计、软件开发和管理、测量和报告等活动之间的交
互。

237
ITIL 4 基金会
图 5.17 业务分析对价值链活动的贡献热图
图 5.17 显示了业务分析对服务价值链的贡献，所有价值链活动都涉及业务分析：
⚫ 计划业务分析有助于战略决策，包括将做什么和如何执行。
⚫ 改进所有级别的评估和改进，从业务分析中获益，这在战略和战术层面特
别适用。
⚫ 参与业务分析是在此价值链活动中收集需求的关键。
⚫ 设计和过渡收集、优先级和准确需求分析有助于确保设计和进度到操作的
高质量解决方案。
⚫ 获取/构建业务分析技能是商定解决方案定义不可或缺的一部分。
⚫ 在设计服务更改时，以及在寻找持续改进机会时，从持续提供服务中交付
和支持数据可能是业务分析活动的一部分。
5.2.3 容量和性能管理

237
ITIL 4 基金会
l
关键消息
容量和性能管理实践的目的是确保服务实现商定的预期绩效，以具有成本效益的方式满足
当前和未来的需求。
定义：性能
衡量系统、人员、团队、实践或服务所实现或交付的内容的度量。
服务性能通常与在时间范围内执行的服务操作数和在给定需求级别完成服务操作所需的时
间相关联。服务性能取决于服务容量，该服务容量定义为 CI 或服务可以提供的最大吞吐
量。容量和性能的特定指标取决于服务或 CI 的技术和业务性质。
容量和性能管理实践通常涉及服务性能和它所依赖的支持资源（如基础结构、应用程序和
第三方服务）的性能。在许多组织中，能力和业绩管理实践也涵盖人员的能力和业绩。
容量和性能管理实践包括以下活动：
⚫ 服务性能和容量分析：
⚫ 研究和监测当前服务绩效 l 容量和性能模型
⚫ 服务性能和容量规划：l 容量需求分析、需求预测和资源规划 l 性
能改进规划。
服务绩效是客户和用户期望和要求的一个重要方面，因此有助于他们满意度和感知到的服
务价值。容量和性能分析和规划有助于服务规划和建设，以及持续提供服务、评估和改
进。了解容量和性能模型和模式有助于预测需求并处理事件和缺陷。

237
ITIL 4 基金会
图 5.18 容量和性能管理对价值链活动的贡献热图
图 5.18 显示了容量和性能管理对服务价值链的贡献，所有服务价值链活动都涉及以下实
践：
⚫ 规划容量和性能管理支持战术和操作规划，提供有关实际需求和性能的信
息，以及建模和预测工具和方法。
⚫ 改进改进由本实践提供的性能信息确定和驱动。
⚫ 参与客户和用户的期望由有关性能和容量限制和功能的信息进行管理和支
持。
⚫ 设计和过渡容量和性能管理对于产品和服务设计至关重要：它有助于确保
新服务和更改的服务设计为最佳性能、容量和可扩展性。
⚫ 获取/构建能力和性能管理有助于确保获得或构建的组件和服务满足组织的
性能需求。
⚫ 交付和支持服务和服务组件由性能和容量目标、指标和度量以及报告目标
和工具提供支持和测试。

237
ITIL 4 基金会
l
5.2.4 更改控制
关键消息
变更控制实践的目的是通过确保正确评估风险、授权进行更改以及管理更改计划，最大限
度地增加成功的 IT 更改数量。
定义：更改
添加、修改或删除任何可能对服务产生直接或间接影响的东西。
更改控制的范围由每个组织定义。它通常包括所有 IT 基础结构、应用程序、文档、流
程、供应商关系以及任何可能直接或间接影响产品或服务。
区分变更控制与组织变更管理很重要。组织变革管理管理变革的人员方面，以确保改进和
组织变革计划成功实施。变更控制通常侧重于产品和服务的变化。
变更控制必须平衡进行有益更改的需求，从而提供附加价值，并保护客户和用户免受更改
的不利影响。所有变化都应由能够了解风险和预期收益的人员进行评估;然后，在部署更改
之前，必须授权这些更改。然而，这种评估不应造成不必要的拖延。
授权更改的个人或组称为变更颁发机构。必须为每个类型更改分配正确的更改权限，以确
保更改控制既高效又有效。在高速组织中，分散变更审批是一种常见做法，使同行评审成
为高性能的顶级预测变量。
有三种类型的更改都以不同的方式管理：

237
ITIL 4 基金会
l
⚫ 标准更改这些是低风险、预先授权的更改，已充分理解并完整记录，无需
额外授权即可实施。它们通常作为服务请求启动，但也可能是操作更改。
创建或修改标准更改程序时，应像对任何其他更改一样进行全面的风险评
估和授权。每次实施标准更改时，不需要重复此风险评估;它只需要做，如
果有一个修改，它执行的方式。
⚫ 正常更改这些是需要按照标准流程进行计划、评估和授权的更改。基于更
改类型的更改模型决定了评估和授权的角色。一些正常的变化风险较低，
而这些变更的权威通常是能够做出快速决策的人，通常使用自动化来加快
更改速度。其他正常更改非常重大，变更权限可能与管理委员会（或同
等）一样高。正常更改的启动由创建更改请求触发。这可能是手动创建
的，但具有用于持续集成和持续部署（CI/CD）的自动化管道的组织通常
会自动执行更改控制过程的大多数步骤。
⚫ 紧急更改这些是必须尽快实施的更改;例如，要解决事件或实施安全修补程
序。紧急更改通常不包括在更改计划中，并加快评估和授权流程，以确保
快速实施这些更改。紧急更改应尽可能接受与正常更改相同的测试、评估
和授权，但可以将某些文档推迟到实施更改之后，有时由于时间限制，有
必要以较少的测试实施更改。对于紧急变更，可能还有单独的变更机构，
通常包括少数了解相关业务风险的高级管理人员。
更改计划用于帮助规划更改、帮助沟通、避免冲突和分配资源。它还可以在部署更改后使
用，以提供事件管理、问题管理和改进规划所需的信息。
无论变革机构是谁，他们可能需要在整个组织中广泛沟通。例如，风险评估活动可能要求
他们从许多具有专业知识的人那里收集意见。此外，通常需要传达有关更改的信息，以确
保 IT 人员和业务部门人员在部署更改之前做好充分准备。

237
ITIL 4 基金会
图 5.19 变革控制对价值链活动的贡献热图
图 5.19 显示了变更控制对服务价值链的贡献，所有价值链活动都涉及变革控制：
⚫ 计划对产品和服务组合、策略和实践的更改都需要一定程度的控制，并且
更改控制实践用于提供它。
⚫ 改进许多改进需要进行更改，并且这些改进应像所有其他更改一样进行评
估和授权。
⚫ 接洽客户和用户可能需要咨询或告知更改，具体取决于更改的性质。
⚫ 设计和转换许多更改都是由于新的或更改的服务而启动的。更改控制活动
是过渡的主要贡献者。
⚫ 获取/构建组件更改受变更控制，无论是内部内置还是从供应商处获得。
⚫ 交付和支持更改可能会影响交付和支持，有关更改的信息必须传达给执行
此价值链活动的人员。这些人也可能在评估和授权变革方面发挥作用。

237
ITIL 4 基金会
l
ITIL 故事：更改控制
亨利：租车市场的发展比以往任何时候都快。为了确保 Axle 满足客户需求并充分利用机

会，我们需要快速上市。此外，我们需要空间来尝试新的想法。我们在 Axle 的新服务产
品将看到我们组织的巨大变化。有些团队需要将规模扩大一倍以满足需求。其他团队可能
会看到减少。我们需要让公司里的每个人都踏上这段旅程。
Radhika：Axle 的变更控制实践确保我们的服务在灵活性和可靠性方面实现适当的平衡。
Marco：我们的一些流程高度自动化，专为快速部署更改而设计。这些非常适合更改我们
的预订应用和一些 IT 系统。
Su：在其他情况下，例如当我们更新车辆时，我们使用手动和自动测试的组合。例如，
Axle 感知道路监控和安全系统需要咨询和批准，然后才能更新它。
Marco：Axle 感知等系统不能像预订应用程序一样被更改。这些更改的优先级是，我们安
全行事并遵守适当的法规。这比上市时间更重要。
5.2.5 事件管理
关键消息
事件管理的目的是通过尽快恢复正常的服务操作，将事件的负面影响降至最低。
定义：事件
服务意外中断或服务质量下降。

237
ITIL 4 基金会
事件管理会对客户和用户满意度以及客户和用户对服务提供商的看法产生巨大影响。应记
录和管理每个事件，以确保在满足客户和用户期望的时间内解决。商定、记录和传达目标
解决时间，以确保期望是现实的。事件根据商定的分类确定优先级，以确保首先解决业务
影响最大的事件。
组织应设计其事件管理实践，以便为不同类型的事件提供适当的管理和资源分配。影响较
低的事件必须有效地管理，以确保它们不会消耗过多的资源。
影响较大的事件可能需要更多资源和更复杂的管理。通常有单独的流程来管理重大事件和
管理信息安全事件。
有关事件的信息应存储在适当的工具中的事件记录中。理想情况下，此工具还应提供指向
相关 C、更改、问题、已知错误和其他知识的链接，以便快速高效地诊断和恢复。现代 IT
服务管理工具可以自动匹配事件与其他事件、问题或已知错误，甚至可以提供事件数据的
智能分析，从而生成帮助处理未来事件的建议。
处理事件的人必须及时提供高质量的更新。这一点很重要。这些更新应包括有关症状、业
务影响、受影响 C、已完成的操作以及计划执行的操作的信息。其中每一个都应该有一个
时间戳和有关相关人员的信息，以便了解相关人员或感兴趣的人。可能还需要良好的协作
工具，以便处理事件的人能够有效地协作。
事件可能由许多不同的组中的人诊断和解决，具体取决于问题的复杂性或事件类型。所有
这些团队都需要了解事件管理流程，以及他们对此的贡献如何帮助管理所提供服务的价
值、结果、成本和风险：
⚫ 某些事件将由用户自己使用自助解决。应捕获特定自助记录的使用，用于
测量和改进活动。
⚫ 某些事件将由服务台解决。
⚫ 更复杂的事件通常会升级为支持团队进行解决。通常，路由基于事件类
别，这应该有助于确定正确的团队。
⚫ 事件可能会升级为供应商或合作伙伴，他们为提供的产品和服务提供支
持。

237
ITIL 4 基金会
l
⚫ 最复杂的事件和所有重大事件通常需要临时团队共同努力确定解决方案。
该团队可能包括许多利益相关者的代表，包括服务提供商、供应商、用户
等。
⚫ 在某些极端情况下，可能会调用灾难恢复计划来解决事件。服务连续性管
理实践（第 5.2.12 节）描述了灾难恢复。
有效的事件管理通常需要团队内部和团队之间的高级别协作。这些团队可能包括服务台、
技术支持、应用程序支持和供应商。协作可以促进信息共享和学习，并有助于更有效和更
有效地解决这一事件。
提示
某些组织使用称为"蜂拥"的技术来帮助管理事件。这涉及到许多不同的利益相关者最初一
起工作，直到很明显，他们中哪一个最适合继续，哪些可以转移到其他任务。
用作服务组成部分的第三方产品和服务需要支持协议，使供应商的义务与服务提供商向客
户作出的承诺保持一致。事故管理可能需要经常与这些供应商互动，而供应商合同的这一
方面的例行管理通常是事件管理实践的一部分。供应商还可以充当服务台，记录和管理所
有事件，并根据需要将其上报给相关主题专家或其他各方。
应该有一个记录和管理事件的正式过程。此过程通常不包括有关如何诊断、调查和解决事
件的详细过程，但可以提供提高调查和诊断效率的技术。在初始接触期间，可能有用于从
用户收集信息的脚本，这直接可能导致简单事件的诊断和解决。调查更复杂的事件往往需
要知识和专门知识，而不是程序步骤。
处理事件可以在每个价值链活动中发生，但最明显的（由于对用户的影响）是操作环境中
的事件。

237
ITIL 4 基金会
图 5.20 事件管理对价值链活动的贡献热图
图 5.20 显示了事件管理对服务价值链的贡献，实践主要应用于参与、交付和支持价值链
活动。除计划外，其他活动可能使用有关事件的信息来帮助设置优先级：
⚫ 改进事件记录是改进活动的关键输入，在事件频率和严重性方面都具有优
先级。
⚫ 用户可以看到参与事件，客户也会看到重大事件。良好的事件管理需要定
期沟通，以了解问题、设定期望值、提供状态更新，并同意问题已解决，
以便关闭事件。
⚫ 设计和转换事件可能发生在测试环境中以及服务发布和部署期间。事件管
理实践确保及时、可控地解决这些事件。
⚫ 获取/生成事件可能发生在开发环境中。事件管理实践确保及时、可控地解
决这些事件。
⚫ 交付和支持事件管理为支持做出了重大贡献。此价值链活动包括解决事件
和问题。

237
ITIL 4 基金会
l
ITIL 故事：Axle 的事件管理
Radhika：Axle 面临许多潜在的 IT 和非 IT 事件。汽车可能会发生故障，可能发生交通

事故，或者我们的客户可能会面临不熟悉的道路规则的挑战。
Marco：汽车预订可能会受到应用程序错误的影响，或者由于我们的软件导航错误而丢失
的用户。当事件发生时，我们必须准备好尽快恢复正常服务。我们还必须确保我们的团队
知道如何以及何时从预定义的恢复程序切换到蜂拥而至和集体分析。
拉迪卡：我们还确保此类案件得到调查和改进。
Henri： Axle 已经为所有类型的事件制定了清晰的流程，为频繁发生的案例（如轮胎穿刺

或互联网连接丢失）提供了解决方法。
Radhika：我们的团队与我们的供应商和合作伙伴合作，确保快速有效的事件响应。我们
与参与我们经历的任何事件的合作伙伴一起开发和测试恢复程序。
5.2.6 IT 资产管理
关键消息
IT 资产管理实践的目的是规划和管理所有 IT 资产的整个生命周期，以帮助组织：
⚫ 最大化价值 l 控制成本 l 管理风险
⚫ 支持有关购买、再使用和资产报废的决策，符
合法规和合同要求。

237
ITIL 4 基金会
定义：IT 资产
有助于交付 IT 产品或服务的任何重要组件。
IT 资产管理的范围通常包括所有软件、硬件、网络、云服务和客户端设备。在某些情况
下，它还可能包括非 IT 资产，如建筑物或信息，这些资产具有财务价值，并且需要提供
IT 服务。IT 资产管理可以包括运营技术（OT）
，包括属于物联网的设备。这些设备通常
传统上不被视为 IT 资产，但现在包括嵌入式计算功能和网络连接。
了解资产的成本和价值对于理解产品和服务的成本和价值也至关重要，因此是服务提供商
所做的一切的重要基础因素。IT 资产管理有助于资产及其价值的可见性，这是成功管理服
务的关键因素，也有利于其他实践。
资产管理类型
资产管理是一种公认的做法，包括收购、运营、护理和处置组织资产，尤其是关键基础设
施。
IT 资产管理（ITAM）是资产管理的子实践，专门用于管理 IT 设备和基础架构的生命周

期和总成本。
软件资产管理（SAM）是 IT 资产管理的一个方面，专门用于管理软件资产的获取、开

发、发布、部署、维护和最终停用。SAM 程序提供软件资产的有效管理、控制和保护。
IT 资产管理需要准确的库存信息，这些信息保存在资产登记册中。此信息可以在审核中收
集，但最好将其捕获为更改资产状态的进程的一部分，例如，在交付新硬件时或请求云服

237
ITIL 4 基金会
l
务的新实例时。如果 IT 资产管理与其他实践（包括服务配置管理、事件管理、更改控制
和部署管理）有良好的接口，则可以以更少的精力维护资产状态信息。仍然需要审核，但
这些审计可能不太频繁，并且在已有准确的资产登记时更容易执行。
IT 资产管理有助于优化宝贵资源的使用。例如，组织需要的备用计算机数可以基于服务级
别协议承诺、服务请求的测量性能以及容量和性能管理的需求预测来计算。
在软件供应商要求对许可证使用情况进行审核后，某些组织发现需要 IT 资产管理。如果
所需信息没有得到维护，这可能导致大量费用，既在进行审计，又支付所查明的任何额外
的许可证费用，则可能会带来很大的压力。简单地维护有关软件许可证使用的信息作为正
常 IT 资产管理活动的一部分，并针对任何供应商请求提供这些信息要便宜得多，也更容
易。软件在硬件上运行，因此软件和硬件资产的管理应合并，以确保所有许可证都得到妥
善管理。出于同样的原因，还应包括基于云的资产的管理。
如果组织不像其他 IT 资产那样管理这些服务，云服务的成本很容易失控。每个单独使用
云服务可能相对便宜，但通过少量支出，很容易消耗比计划更多的资源，从而使组织拥有
相应的大额账单。同样，良好的 IT 资产管理可以帮助控制这种情况。
IT 资产管理的活动和要求因不同类型的资产而异：
⚫ 必须标记硬件资产以进行清晰标识。了解它们的位置并帮助保护它们免遭
盗窃、损坏和数据泄露非常重要。在重复使用或退役时，它们可能需要特
殊处理;例如，磁盘驱动器的擦除或粉碎取决于信息安全要求。硬件资产也
可能受
法规要求，如欧盟废弃电气和电子设备指令。
⚫ 必须保护软件资产免受非法复制，这可能导致未经许可的使用。组织必须
确保遵守许可条款，并确保许可证只能以合同允许的方式重复使用。请务
必保留经过验证的购买证明和运行软件的权利。当设备停用时，很容易丢
失软件许可证，因此 IT 资产管理流程必须收回这些许可证，并酌情将其重
新使用。
⚫ 基于云的资产必须分配给特定产品或组，以便可以管理成本。必须管理资
金，以便组织能够在需要时灵活地调用新的云使用实例，并删除不需要的
实例，而不会造成成本失控的风险。合同安排必须理解并遵守，就像软件
许可证一样。

237
ITIL 4 基金会
l
⚫ 客户资产必须分配给负责其照顾的个人。需要处理流程来管理丢失或被盗
的设备，可能需要工具从设备中擦除敏感数据，或者以其他方式确保此数
据不会随设备丢失或被盗。
在所有情况下，组织都需要确保管理每个资产的整个生命周期。这包括管理资产配置;接
收、退役和返回;硬件处理;软件重用;租赁管理;和潜在的许多其他活动。
IT 资产管理维护有关资产、其成本和相关合同的信息。因此，IT 资产寄存器通常与存储在
配置管理系统（CMS）中的信息相结合（或联合）。如果两者是分开的，那么资产可以在
它们之间映射非常重要，通常使用标准命名约定。可能还需要将 IT 资产登记册与用于管
理其他金融资产的系统或用于管理供应商的系统合并（或联合）。
在某些组织中，有一个集中的团队负责 IT 资产管理。此团队可能还负责配置管理。在其
他组织中，每个技术团队可能负责管理它们支持的 IT 资产;例如，存储团队可以在网络团
队管理网络资产时管理存储资产。每个组织必须考虑自己的上下文和文化，才能选择适当
的集中化级别。但是，拥有一些中心角色有助于确保资产数据质量，并开发软件许可和库
存系统等特定方面的专门知识。
IT 资产管理通常包括以下活动：
⚫ 定义、填充和维护资产登记簿，包括资产和相关媒体的存储设施
⚫ 与其他做法协作控制资产生命周期（例如，升级过时的软件或使用笔记本
电脑和移动电话加入新员工），并记录资产的所有更改（状态、位置、特
征、任务等）
⚫ 提供有关 IT 资产的其他实践的当前和历史数据、报告和支持
⚫ 审核资产、相关媒体和合规性（尤其是符合法规和许可条款和条件），并推
动纠正和预防改进，以处理检测到的问题。

237
ITIL 4 基金会
图 5.21 IT 资产管理对价值链活动的贡献热图
图 5.21 显示了 IT 资产管理对服务价值链的贡献，实践主要应用于设计和过渡，获取/构

建价值链活动：
⚫ 规划 IT 资产管理的大多数政策和指导都来自服务财务管理实践。某些资产
管理策略由治理驱动，有些策略由信息安全管理等其他实践驱动。IT 资产
管理可被视为一种战略实践，可帮助组织了解和管理成本和价值。
⚫ 改进此价值链活动必须考虑对 IT 资产的影响，一些改进将直接涉及 IT 资
产管理，以帮助了解和管理成本。
⚫ 利益相关者对 IT 资产管理可能有一些需求。例如，用户可能会报告手机丢
失或被盗，或者客户可能需要报告 IT 资产的价值。
⚫ 设计和过渡此价值链活动更改 IT 资产的状态，从而推动大多数 IT 资产管

理活动。
⚫ 获取/构建 IT 资产管理支持资产采购，以确保资产从生命周期开始就可追
溯。
⚫ 交付和支持 IT 资产管理有助于查找 IT 资产、跟踪其移动并控制其在组织

中的状态。

237
ITIL 4 基金会
l
5.2.7 监测和事件管理
关键消息
监视和事件管理实践的目的是系统地观察服务和服务组件，并记录和报告确定为事件的状
态的选定更改。这种做法确定基础结构、服务、业务流程和信息安全事件的优先级并确定
其优先级，并针对这些事件建立适当的响应，包括响应可能导致潜在故障或事件。
定义：事件
对管理服务或其他配置项（CI）具有重要意义的任何状态更改。事件通常通过 IT 服务、

CI 或监视工具创建的通知来识别。
监视和事件管理实践管理整个事件的生命周期，以防止、最小化或消除事件对业务的负面
影响。
实践的监测部分侧重于对服务和信息服务的系统观察，这些服务是服务的基础，以检测具
有潜在意义的条件。监控应以高度自动化的方式执行，并且可以主动或被动地完成。事件
管理部分侧重于记录和管理组织定义为事件的状态受监视的更改，确定其重要性，并标识
并启动正确的控制操作来管理它们。通常，正确的控制操作是启动另一种实践，但有时除
了继续监视情况之外，没有其他操作。监视对于事件管理是必要的，但不是所有监视结果
都用于检测事件。
并非所有事件都具有相同的意义或需要相同的响应。事件通常分为信息、警告和异常。信
息事件在识别时不需要采取行动，但分析以后从这些事件收集的数据可能会发现对服务有
益的可取的、主动的步骤。警告事件允许在业务实际遭受任何负面影响之前采取行动，而

237
ITIL 4 基金会
l
异常事件表明已发现违反既定规范的行为（例如，对服务级别协议）。异常事件需要采取行
动，即使尚未遇到业务影响。
监测和事件管理实践所需的流程和程序必须处理这些关键活动，更多：
⚫ 确定应监视哪些服务、系统、C 或其他服务组件，并建立监视策略
⚫ 实施并维持监控，利用所观察到元素的本机监测功能以及使用设计用途的
监控工具
⚫ 建立和维护阈值和其他标准，以确定将哪些状态更改视为事件，并选择定
义每种类型的事件的标准（信息、警告或异常）
⚫ 建立和维护策略，以处理每种类型的检测到的事件，以确保适当的管理
⚫ 实施操作定义的阈值、标准和策略所需的流程和自动化。
这种做法与参与服务价值链的其他实践高度互动。例如，某些事件将指示当前问题，该问
题符合事件条件。在这种情况下，正确的控制操作是在事件管理实践中启动活动。显示性
能超出所需水平的重复事件可能是潜在问题的证据，这将在问题管理实践中启动活动。对
于某些事件，正确的响应可能是启动更改，在这种情况下，将参与更改控制实践。
虽然这种做法的工作一旦到位，是高度自动化的，但人类干预仍是必需的，而且事实上是
必不可少的。对于监控策略和特定阈值和评估标准的定义，它可以帮助您引入广泛的视
角，包括基础设施、应用程序、服务所有者、服务级别管理和保修相关实践的表示形式。
请记住，这种做法的起点可能很简单，为以后复杂性的增加设定了阶段，因此管理参与者
的期望非常重要。
各组织和人员对于根据政策和组织优先事项对受监测的数据和事件作出适当反应也至关重
要。角色和责任必须明确界定，每个人或团队必须能够轻松、及时地访问履行其职责所需
的信息。
自动化是成功监控和事件管理的关键。某些服务组件配备了内置的监视和报告功能，这些
功能可以配置为满足实践的需要，但有时需要实施和配置专用的监视工具。监视本身可以
是主动的，也可以是被动的。在活动监视中，工具将轮询密钥 C，查看其状态，在发现异
常条件时生成警报。在被动监视中，CI 本身生成操作警报。
自动化工具也应用于事件的相关性。这些功能可能由监视工具或其他工具（如 ITSM 工作
流系统）提供。这种做法可能会生成大量数据，但如果没有明确的策略和策略来限制、筛
选和使用这些数据，则对组织毫无价值。

237
ITIL 4 基金会
l
如果第三方在整体服务架构中提供产品或服务，它们还应提供其产品的监控和报告能力方
面的专业知识。在尝试操作监视和事件管理策略和工作流时，利用这些专业知识可以节省
时间。如果某些 IT 功能（如基础结构管理）部分或全部外包给供应商，他们可能不愿意
公开与其管理的元素相关的监视或事件数据。不要要求不需要真正需要的数据，但如果需
要数据，请确保提供这些数据是供应商服务合同的明确部分。
图 5.22 监测和事件管理对价值链活动的贡献热图
图 5.22 显示了监控和事件管理对服务价值链的贡献，除计划外，所有价值链活动都涉及
该实践：
⚫ 改进监控和事件管理实践对于密切观察环境以评估并主动提高环境健康稳
定性至关重要。
⚫ 参与监控和事件管理可能是内部参与行动的来源。
⚫ 设计和过渡监视数据为设计决策提供信息。监视是过渡的重要组成部分：
它提供了有关所有环境中过渡成功的信息。
⚫ 获取/构建监视和事件管理支持开发环境，确保其透明度和可管理性。
⚫ 交付和支持实践指导组织如何管理已识别事件的内部支持，并酌情启动其
他实践。

237
ITIL 4 基金会
l
5.2.8 问题管理
关键消息
问题管理的目的是通过识别事件的实际和潜在原因以及管理解决方法和已知错误来减少事
件的可能性和影响。
定义
我问题一个或多个事件的原因或潜在原因。
我已知错误已分析但尚未解决的问题。
每个服务都有可能导致事件的错误、缺陷或漏洞。它们可能包括服务管理四个维度中的任
何一个的错误。在服务投入使用之前，将识别并解决许多错误。但是，有些服务仍然不明
或未解决，并且可能存在提供实时服务的风险。在 ITIL 中，这些错误称为问题，它们由问
题管理实践解决。
问题与事件有关，但应加以区分，因为它们的管理方式不同：
⚫ 事件对用户或业务流程有影响，必须解决，以便正常的业务活动能够发
生。
⚫ 问题是事件的原因。它们需要调查和分析，以确定原因，制定解决方法，
并建议更长期的解决方案。这减少了未来事件的数量和影响。
问题管理涉及三个不同的阶段，如图 5.23 所示。

237
ITIL 4 基金会
图 5.23 问题管理的各个阶段
问题识别活动识别和记录问题。其中包括：
⚫ 对事件记录进行趋势分析
⚫ 用户、服务台和技术支持人员检测重复和重复的问题
⚫ 在重大事故管理期间，确定事件可能再次发生的风险
⚫ 分析从供应商和合作伙伴收到的信息
⚫ 分析从内部软件开发人员、测试团队和项目团队收到的信息。
其他信息来源也可能导致查明问题。
问题控制活动包括问题分析，以及记录解决方法和已知错误。
问题根据问题构成的风险优先进行分析，并根据潜在影响和概率作为风险进行管理。分析
每一个问题都并非必要;在最高优先级问题上取得重大进展比调查组织知道的每个次要问题
更有价值。
事件通常有许多相互关联的原因，它们之间的关系可能很复杂。问题控制应考虑所有促成
原因，包括导致事件持续时间和影响的原因，以及导致事件发生的原因。从服务管理的所
有四个方面分析问题非常重要。例如，由于文档不准确而导致的事件可能不仅需要更正该
文档，还需要对支持人员、供应商和用户进行培训和认识。
当问题无法快速解决时，根据对问题的理解，查找和记录未来事件的解决方法通常很有
用。解决方法记录在问题记录中。这可以在任何阶段完成;它不需要等待分析完成。如果在
问题控制的早期记录了解决方法，则应在完成问题分析后对其进行检查和改进。
定义：解决方法
减少或消除尚未提供完整解决方案的事件或问题的影响的解决方案。某些解决方法降低了
发生事件的可能性。

237
ITIL 4 基金会
有效的事件解决方法可以成为解决某些问题的永久方法，当问题解决不可行或成本效益高
时。在这种情况下，问题仍停留在已知错误状态，并且在发生相关事件时应用了记录的解
决方法。每个记录在案的解决方法都应包括其应用的症状的明确定义。在某些情况下，解
决方法应用程序可以自动化。
对于其他问题，应找到一种修复错误的方法。这是错误控制的一部分。错误控制活动管理
已知错误，这些是已完成初始分析的问题;它通常意味着已识别故障部件。错误控制还包括
确定潜在的永久解决方案，这些解决方案可能会导致实施解决方案的更改请求，但前提是
在成本、风险和收益方面可以证明其合理性。
错误控制定期重新评估尚未解决的已知错误的状态，包括对客户的总体影响、永久解决方
案的可用性和成本以及解决方法的有效性。每次使用解决方法时，都应评估解决方法的有
效性，因为可以根据评估改进解决方法。
问题管理活动与事件管理密切相关。这些实践需要设计为在价值链内协同工作。这两种做
法中的活动可能相辅相成（例如，确定事件的原因是可能导致事件解决的问题管理活动），
但它们也可能发生冲突（例如，调查事件的原因可能会延迟恢复服务所需的操作）
。
问题管理、风险管理、变更控制、知识管理和持续改进之间的接口示例如下：
⚫ 问题管理活动可以作为风险管理的一个具体案例进行组织：它们旨在识
别、评估和控制服务管理四个维度中的任何一个的风险。采用风险管理工
具和技术进行问题管理是很有用的。
⚫ 问题解决的实施往往不在问题管理的范围之内。问题管理通常通过变更控
制启动解决方案，并参与实施后审查;但是，审批和实施更改已不是问题管
理实践的范围。
⚫ 问题管理实践的输出包括有关解决方法和已知错误的信息和文档。此外，
问题管理可以利用知识管理系统中的信息来调查、诊断和解决问题。
⚫ 问题管理活动可以确定服务管理所有四个方面的改进机会。在某些情况
下，可以将解决方案视为改进机会，因此它们包含在持续改进寄存器
（CIR）中，并且使用持续改进技术来确定和管理解决方案的优先级，有
时是产品积压工作的一部分。

237
ITIL 4 基金会
l
许多问题管理活动依赖于工作人员的知识和经验，而不是遵循详细的程序。负责诊断问题
的人通常需要理解复杂系统的能力，并思考不同的故障是如何发生的。发展这种分析和创
新能力的结合需要指导和时间，以及适当的培训。
图 5.24 问题管理对价值链活动的贡献热图
问题管理通常侧重于操作环境中的错误。图 5.24 显示了问题管理对服务价值链的贡献，

实践主要应用于改进、交付和支持价值链活动：
⚫ 改进这是问题管理的主要重点领域。有效的问题管理提供了减少事件数量
和无法预防的事件的影响所需的理解。
⚫ 客户和用户可以看到对服务有重大影响的"参与问题"。在某些情况下，客户
可能希望参与问题优先级处理，并且应传达管理问题的状态和计划。解决
方法通常通过服务门户呈现给用户。
⚫ 设计和过渡问题管理提供的信息有助于改进测试和知识转移。
⚫ 获取/生成产品缺陷可能由问题管理识别;然后作为此价值链活动的一部分进
行管理。
⚫ 交付和支持问题管理通过防止事件重复和支持及时事件解决做出了重大贡
献。

237
ITIL 4 基金会
ITIL 故事：Axle 的问题管理
Henri： Axle 参与我们所有汽车制造商的反馈计划。我们与他们共享维护和维修数据，帮

助他们不断改进服务。作为回报，他们提醒我们注意车辆中的任何潜在问题。
拉迪卡：最近，我们接到了舰队中潜在问题的警报。一家汽车制造商召回了我们车队中流
行的车型，以修复安全气囊激活系统中的错误。
苏：幸运的是，在 Axle 遇到任何事件之前，它被发现了，但问题仍有可能发生，这意味着

我们必须处理这个问题。
Marco：我们对我们的其他系统和服务，包括我们使用的所有 IT 组件，也遵循类似的做
法。
Radhika：Axle 的事件管理实践是我们系统中错误的最重要信息来源之一。我们经历过的
任何重大事件之后，都正在调查可能的原因。有时，这将引导我们查找和修复系统中的错
误，我们经常确定减少 Axle 将来将发生的事件数量的方法。
5.2.9 发布管理
关键消息
发布管理实践的目的是使新的和更改的服务和功能可供使用。

237
ITIL 4 基金会
l
定义：发布
可供使用的服务或其他配置项或配置项的集合。
版本可能包括许多不同的基础结构和应用程序组件，这些组件协同工作以提供新功能或更
改的功能。它还可能包括文档、培训
（对于用户或 IT 人员）
、更新的流程或工具以及任何其他组件
必填。发布的每个组件可以由服务提供商开发或从第三方采购，并由服务提供商集成。
版本的大小范围从非常小（仅涉及一个小更改的功能）到非常大的组件，这些组件提供全
新的服务。在这两种情况下，发布计划将指定要提供的新组件和更改组件的确切组合，以
及发布这些组件的时间。
发布计划用于记录发布的时间安排。此时间表应与客户和其他利益相关者协商并商定。实
施后发布审核有助于学习和改进，并有助于确保客户满意。
在某些环境中，几乎所有发布管理工作都在部署之前进行，并制定计划，具体计划在特定
版本中部署哪些组件。然后，部署使新功能可用。
图 5.25 显示了如何在传统/瀑布环境中处理发布管理。在这些环境中，发布管理和部署可
以合并并作为单个进程执行。
图 5.25 传统/瀑布环境中的发布管理

237
ITIL 4 基金会
l
在敏捷/DevOps 环境中，部署后可能会有重要的发布管理活动。在这些情况下，软件和基
础结构通常以较小的增量部署，发布管理活动可在以后启用新功能。这可能是一个很小的
变化。图 5.26 显示了在这种环境中如何处理发布管理。
发布管理通常分阶段进行，向少数用户提供试点版本，以确保在发布给其他组之前一切工
作正常。此暂存方法可用于图 5.25 和 5.26 所示的两个序列之一。有时，必须同时向所
有用户提供发布，因为需要对基础共享数据进行重大重组。
图 5.26 敏捷/DevOps 环境中的发布管理
通常使用蓝色/绿色版本或功能标志实现发布暂存：
⚫ 蓝色/绿色版本（或 A/B 版本）使用两个镜像生产环境。用户可以使用网

络工具将用户连接到正确的环境，从而切换到已使用新功能更新的环境。
⚫ 功能标志允许以受控方式向单个用户或组释放特定功能。新功能将部署到
生产环境，而不会被释放。然后，用户配置设置根据需要向单个用户（或
用户组）发布新功能。
在 DevOps 环境中，发布管理通常与 CI/CD 工具链集成。发布管理的工具可能是专门人

员的责任，但有关发布的决策可以由开发团队做出。在更传统的环境中，通过部署组件启
用版本。每个版本都由 ITSM 工具上的发布记录描述。发布记录链接到 C 并更改记录，
以维护有关发布的信息。
发布组件通常由第三方提供。第三方组件的示例包括云基础架构、软件即服务组件和第三
方支持。作为应用程序开发一部分，将第三方软件或开源软件包括在内也很常见。发布管
理需要跨组织边界工作，以确保所有组件都兼容，并为用户提供无缝体验。它还需要考虑
对第三方组件的更改的影响，并计划如何发布这些更改。

237
ITIL 4 基金会
图 5.27 发布管理对价值链活动的贡献热图
图 5.27 显示了发布管理对服务价值链的贡献，所有价值链活动都涉及此做法：
⚫ 计划发布的策略、指导和时间表由组织策略和服务组合驱动。应规划和管
理每个版本的大小、范围和内容。
⚫ 提供改进可能需要改进或更改的版本，并且这些版本应像任何其他版本一
样进行规划和管理。
⚫ 参与发布的内容和节奏必须设计为满足客户和用户的需求和期望。
⚫ 设计和过渡发布管理可确保以受控方式为客户提供新的或更改的服务。
⚫ 获取/生成组件更改通常包含在版本中，这些更改需要以受控方式交付。
⚫ 交付和支持发布可能会对交付和支持产生影响。这种做法提供了培训、文
档、发行说明、已知错误、用户指南、支持脚本和其他知识，以方便服务
恢复。

237
ITIL 4 基金会
l
ITIL 故事：Axle 的发布管理
Marco：当我们发布预订应用的更新时，我们会确保这些更新伴随着用户、客户和团队的
用户意识和营销活动。我们为服务台和支持团队提供内部和外部的具体培训。
Radhika：某些更改可能需要额外的支持或引入新组件。例如，Axle 感知发布时，带有新
的用户手册来解释系统。我们还确保感知系统可以在发布之前与 Axle 预订应用程序同
步。
Henri：对新应用和 Axle Aware 的支持确实帮助发布了这两款新产品，在用户和客户以

及我们自己的团队中获得了良好的第一印象和强大的采用率。
5.2.10 服务目录管理
关键消息
服务目录管理的目的是提供关于所有服务和服务产品的单一信息来源，并确保向相关
受众提供这些信息。
服务目录中的服务列表表示当前可用的服务列表，是服务提供商服务组合中跟踪的服务列
表总数的子集。服务目录管理确保明确表达服务和产品描述，以便目标受众支持利益相关
者的参与和服务交付。服务目录可能采取多种形式，如文档、在线门户或工具，以便将当
前服务列表传达给受众。
5.2.10.1 服务目录管理活动
服务目录管理实践包括与发布、编辑和维护服务和产品描述及其相关产品相关的一系列持
续活动。它提供了关于可用服务的范围和条款的视图。服务目录管理实践由服务所有者和
其他角色提供支持，这些角色负责在介绍、更改或停用可用服务时进行管理、编辑和更新
可用服务列表。

237
ITIL 4 基金会
定制视图
如上所述，服务目录能够创造价值，并且被服务价值链中的许多不同的实践所使用。因
此，它需要根据预期用途灵活应对它提供哪些服务详细信息和属性。因此，各组织不妨考
虑向不同的受众提供目录的不同观点。
服务目录中的服务的完整列表可能并不适用于所有客户和/或用户。同样，服务的各种属性
（如技术规格、产品、协议和成本）并不适用于所有服务使用者类型。这意味着服务目录
应该能够向不同的利益相关者提供不同的观点和详细程度。视图的示例包括：
⚫ 用户视图提供有关可请求的服务产品的信息以及预配详细信息。
⚫ 客户视图提供服务级别、财务和服务性能数据。
⚫ IT 到 IT 客户视图提供技术、安全和流程信息，用于服务交付。
虽然可以对服务目录进行多种意见，但应尽可能避免在不同技术系统中创建单独或隔离的
服务目录，因为这将促进隔离、可变性和复杂性。
要将服务目录视为有用的客户组织，它必须不仅仅是提供一个发布 IT 服务信息的静态平
台。除非服务目录通过支持与标准和非标准服务产品相关的讨论和/或自动执行请求和订单
履行流程，否则持续采用其作为有用和有意义的资源的可能性微乎其微。因此，许多组织
对服务目录的看法侧重于服务产品的消耗性或可订购要素。这些通常称为请求目录。
定义：请求目录
服务目录视图，提供有关现有和新的服务的服务请求的详细信息，可供用户使用。

237
ITIL 4 基金会
图 5.28 服务目录管理对价值链活动的贡献热图
图 5.28 显示了服务目录管理对服务价值链的贡献，所有价值链活动都涉及这种做法：
⚫ 计划服务目录通过提供有关当前服务范围和产品的详细信息，实现战略和
服务组合投资决策。
⚫ Service 不断监控和评估改进服务目录描述和需求模式，以支持持续改
进、对齐和价值创造。
⚫ 参与 The 服务目录通过启用和潜在自动化各种实践（如关系管理、请求
管理和服务台），与客户和用户建立战略、战术和业务关系。
⚫ 设计和过渡 The 服务目录确保考虑和发布服务的效用和保修方面，包括

信息安全策略、IT 服务连续性级别、服务级别协议和服务产品。其他活动
包括定义和创建要发布的服务说明、请求模型和视图。
⚫ 获取/构建服务目录管理通过提供组件和服务采购的服务目录视图支持此价
值链活动。
⚫ 交付和支持 The 服务目录提供了如何交付和支持服务的环境，并发布与

协议和性能相关的期望。

237
ITIL 4 基金会
l
5.2.11 服务配置管理
关键消息
服务配置管理实践的目的是确保在需要时以及何处提供有关服务配置和支持它们的 C 的准
确可靠的信息。这包括有关如何配置 C 及其之间的关系的信息。
定义：配置项
任何需要管理以提供 IT 服务的组件。
服务配置管理收集和管理有关各种 C 的信息，通常包括硬件、软件、网络、建筑物、人
员、供应商和文档。服务也被视为 C，配置管理可帮助组织了解导致每个服务的许多 C
如何协同工作。图 5.29 是一个简化的图表，显示了多个 C 如何为 IT 服务做出贡献。

237
ITIL 4 基金会
图 5.29 典型 IT 服务的简化服务模型
配置管理提供有关有助于每个服务及其关系的 C 的信息：它们如何相互交互、关联和依
赖，为客户和用户创造价值。这包括有关服务之间的依赖关系的信息。此高级视图通常称
为服务映射或服务模型，是服务体系结构的一部分。
收集和维护配置信息所需的工作量必须与信息创建的值相平衡，这一点很重要。维护有关
每个组件及其与其他组件的关系的大量详细信息可能成本高昂，而且可能提供很少的价
值。配置管理的要求必须基于对组织目标的理解，以及配置管理如何促进价值创造。
配置管理创造的价值是间接的，但使许多其他实践能够高效、高效地工作。因此，配置管
理的规划应从了解谁需要配置信息、如何使用配置信息、获取配置信息的最佳方式以及谁
可以维护和更新此信息开始。有时，在需要时简单地收集信息会更有效，而不是事先收集
和维护信息，但在其他情况下，在配置管理系统（CMS）中提供信息至关重要。每种 CI
记录的信息类型和数量应基于该信息的价值、维护信息的成本以及信息的使用方式。
定义：配置管理系统
一组用于支持服务配置管理的工具、数据和信息。

237
ITIL 4 基金会
配置信息应以受控方式共享。有些信息可能是敏感的;例如，对于试图违反安全控制的人可
能很有用，或者可能包括有关用户的个人信息，如电话号码和家庭地址。
配置信息可以存储并发布到整个组织的单个配置管理数据库（CMDB），但分布在多个源

中更常见。在这两种情况下，维护配置记录之间的链接都很重要，以便人们能够查看所需
的完整信息集，以及各个 C 如何协同工作。某些组织联合 CMDB 以提供集成视图。其他
人可能维护不同类型的数据;例如，为资产管理数据设置单独的数据存储（参见第 5.2.6
节）、配置详细信息、服务目录信息和高级服务模型。
用于记录事件、问题和更改的工具需要访问配置记录。例如，试图识别服务问题的组织可
能需要查找与特定软件版本或磁盘驱动器模型相关的事件。了解对此信息的需求有助于确
定应该为此组织存储哪些 CI 属性;在这种情况下，软件版本和磁盘驱动器型号。要诊断事
件，可能需要查看最近对受影响 C 的更改，因此必须维护 C 和更改之间的关系。
许多组织使用数据收集工具从基础结构和应用程序收集详细的配置信息，并用它来填充
CMS。这可以有效，但也可以鼓励收集过多的数据，而没有足够的关系信息，以及组件如
何协同工作以创建服务。有时，配置信息用于实际创建 CI，而不仅仅是记录它。此方法用
于"基础结构作为代码"，其中有关基础结构的信息在数据存储库中管理，并用于自动配置
环境。
大型组织可能具有专门负责配置管理的团队。在其他组织中，这种做法可以与组织变更管
理相结合，也可以有一个团队负责更改、配置和发布管理。某些组织应用分布式模型，其
中职能团队拥有在其控制和监督范围内更新和维护 C 的所有权。
配置管理通常需要流程：
⚫ 标识新的 C，并在部署更改时将它们添加到 CMS l 更新配置数据中，检
查配置记录是否正确，以及审核应用程序和基础结构，以识别任何未记
录。

237
ITIL 4 基金会
图 5.30 服务配置管理对价值链活动的贡献热图
图 5.30 显示了配置管理对服务价值链的贡献，所有价值链活动都涉及以下实践：
⚫ 计划配置管理用于规划新服务或更改的服务。
⚫ 改进配置管理，与服务管理的其他每一个方面一样，应经过衡量和持续改
进。由于配置管理的价值通常来自于它如何促进其他实践，因此了解这些
实践对配置信息有何用，然后确定如何改进配置信息非常重要。
⚫ 让某些利益相关者（合作伙伴和供应商、消费者、监管机构等）可能需要
和使用配置信息，或向组织提供其配置信息。
⚫ 设计和转换配置管理记录资产如何协同工作以创建服务。此信息用于支持
许多价值链活动，并作为过渡活动的一部分进行更新。
⚫ build Configuration 在此价值链活动期间，可以创建获取/生成配置记

录，描述新的或更改的服务和组件。有时，配置记录用于创建正在构建的
代码或图事实。
⚫ 交付和支持 Information 有关 C 的信息对于支持服务恢复至关重要。配

置信息用于支持事件管理和问题管理实践的活动。

237
ITIL 4 基金会
l
5.2.12 服务连续性管理
关键消息
服务连续性管理实践的目的是确保在发生灾难时将服务的可用性和性能保持在足够的水
平。这种做法为建立组织复原力提供了一个框架，能够产生有效的应对措施，保障关键利
益相关者的利益以及组织的声誉、品牌和创造价值活动。
服务连续性管理通过确保 IT 和服务能够在灾难或危机后所需的商定业务时间范围内恢
复，从而支持整体业务连续性管理（BCM）和规划功能。当服务中断或组织风险发生的
规模大于组织处理正常响应和恢复实践（如事件和重大事件管理）的能力时，将触发该事
件。如此规模的组织事件通常称为灾难。
每个组织都需要了解在其自身上下文中构成灾难的原因。在组织和每个服务级别触发事件
之前，必须考虑和定义灾难的含义，并使用业务影响分析。业务连续性研究所将灾难定义
为：
'...给组织造成巨大损害或严重损失的突发计划外事件。它会导致组织未能在一
定的时间内提供关键业务功能。
触发救灾和恢复的资料来源多种多样和复杂，利益攸关方的数量和潜在组织影响的不同方
面也各不相同。与表 5.3 中的示例相关的复杂风险管理条件使得必须彻底考虑服务连续性
管理实践，设计灵活性，并定期进行测试，以确保服务能够以企业生存所需的速度恢复。
表 5.3 灾害源、所涉利益攸关方和组织影响的例子
灾害源参与的利益相关者组织影响

237
ITIL 4 基金会
l
供应链故障员工收入损失
恐怖主义高管声誉受损
天气理事机构失去竞争优势
网络攻击供应商违反法律、健康和安全条

例
卫生紧急情况 IT 团队
对人身安全的风险
政治或经济事件客户
直接和长期失去市场份额
技术故障用户
公共危机社区
定义
⚫ 恢复时间目标（RTO）服务中断后可接受的最长时间段，在业务功能不
足之前可能会消失，严重影响组织。这表示必须恢复产品或活动或必须恢
复资源的最大商定时间。
⚫ 恢复点目标（RPO）必须还原活动使用的信息以使活动在恢复时运行的
点。
⚫ 灾难恢复计划一组明确定义的计划，涉及组织如何从灾难中恢复以及返回
到灾难前状态，并考虑服务管理的四个维度。
⚫ 业务影响分析（BIA）服务连续性管理实践中的关键活动，用于标识重
要的业务功能（VbF）及其依赖关系。这些依赖关系可能包括供应商、人
员、其他业务流程和 IT 服务。BIA 定义了 IT 服务的恢复要求。这些要求
包括每个 IT 服务的 RPO、RPO 和最低目标服务级别。

237
ITIL 4 基金会
l
服务连续性管理与事件管理
服务连续性管理侧重于业务认为足够重要，足以被视为灾难的事件。作为事件管理或重大
事件管理的一部分，将处理不太重要的事件。灾害、重大事件和事件之间的区别需要预先
定义、商定和记录，并有明确的阈值和触发器，以便调用下一层响应和恢复以采取行动，
而不会造成不必要的延误和风险。
随着各组织越来越依赖技术支持的服务，对高可用性解决方案的需求对组织复原力和竞争
力至关重要。组织通过业务规划、技术架构恢复能力、可用性规划、主动风险和信息安全
管理相结合，以及通过事件管理和问题实现高可用性管理。
图 5.31 服务连续性管理对价值链活动的贡献热图
图 5.31 显示了服务连续性管理对服务价值链的贡献，所有价值链活动都涉及以下做法：
⚫ 计划 The 组织领导层和管理机构通过定义的范围、政策、供应商战略和
对恢复选项的投资，为组织建立初始风险偏好。服务连续性管理通过有关
组织当前连续性状态的相关信息以及规划和预测的工具和方法支持这一
点。

237
ITIL 4 基金会
l
⚫ 改进服务连续性管理可确保根据不断变化的内部和外部环境不断监测和改
进连续性计划、措施和机制。
⚫ Engagement 这种做法支持与各利益攸关方接触，就组织应对灾害的准
备情况提供保证。
⚫ 设计和过渡服务连续性管理确保根据组织的连续性要求设计和测试产品和
服务。
⚫ 获取/构建服务连续性管理可确保将连续性内置到组织的服务和组件中，并
确保采购的组件和服务满足组织的连续性要求。
⚫ 交付和支持持续交付、运营和支持根据连续性要求和政策执行。
5.2.13 服务设计
关键消息
服务设计实践的目的是设计适合目的、适合使用、且可以由组织及其生态系统提供的产品
和服务。这包括规划和组织人员、合作伙伴和供应商、信息、通信、技术和新产品和服务
或更改的产品和服务的实践，以及组织与客户之间的互动。
如果产品、服务或实践设计不当，它们不一定满足客户需求或促进价值创造。如果它们在
没有适当的体系结构、接口或控件的情况下发展，则它们就更无法提供组织及其内部和外
部客户的总体愿景和需求。
即使产品或服务设计良好，也很难以经济高效的弹性方式提供满足组织和客户需求的解决
方案。因此，考虑迭代和增量服务设计方法非常重要，这些方法可确保引入实时运营的产
品和服务能够根据组织及其客户不断变化的需求不断调整.
在没有正式服务设计的情况下，产品和服务的运行成本过高，容易出现故障，导致资源浪
费，产品或服务不是以客户为中心或整体设计。任何改进计划都不可能首先实现适当的设

237
ITIL 4 基金会
l
计能够取得什么成果。如果没有服务设计，提供客户需要和期望的具有成本效益的产品和
服务将很难实现。
服务设计实践还应确保客户从需求到价值实现的旅程尽可能愉快且无摩擦，并尽可能提供
最佳的客户结果。这是通过关注客户体验（CX）和用户体验（UX）来实现的。
采用并实施以 CX 和 UX 为中心的服务设计实践将：
⚫ 提供以客户为中心的产品和服务，包括设计活动中的利益相关者
⚫ 考虑产品或服务的整个环境
⚫ 使项目能够更准确地估计与服务设计相关的成本、时间、资源要求和风险
⚫ 导致更多的成功更改，使设计方法更容易被人们采用和遵循，使服务设
计资产能够在项目和服务之间共享和重用
⚫ 提高新产品或服务可以交付到规范中的信心，而不会意外影响其他产品、
服务或利益相关者
⚫ 确保新的或更改的产品和服务是可维护且具有成本效益的。
重要的是，对服务设计的所有方面采用一种全面、以结果为导向的方法，并且在更改或修
改服务设计的任何单个元素时，应考虑所有其他方面。因此，服务设计与整个组织的 SVS
协调性至关重要。设计和开发新的或更改的产品或服务不应孤立地进行，而应考虑它对以
下方面的影响：
⚫ 其他产品和服务 l 所有相关方，包括客户和供应商 l 现有体系结构 l
所需的技术 l 服务管理实践 l 必要的度量和指标。
考虑这些因素不仅将确保设计解决服务的功能要素，而且确保管理和操作要求被视为设计
的基本部分，而不是作为事后考虑添加。
当对产品或服务所做的更改是停用时，也应使用服务设计。除非仔细计划停用产品/服务，
否则可能会对客户或组织造成意外的负面影响，否则这些负面影响本来是可以避免的。
并非所有产品或服务的更改都需要相同级别的服务设计活动。每一次更改，无论多么小，
都需要一定程度的设计工作，但确保成功所需的活动规模将因更改类型而异。组织必须定
义每个类别更改所需的设计活动级别，并确保组织内的每个人都清楚这些标准。
服务设计支持产品和服务：

237
ITIL 4 基金会
l
⚫ 以业务和客户为导向，专注和驱动，是具有成本效益的
⚫ 满足组织和任何外部客户的信息和物理安全要求
⚫ 灵活且适应性强，但适合在交货点满足，在变化量和速度方面可满足不
断增长的组织和客户对持续运营的要求
⚫ 管理和操作的风险水平可接受的水平。
由于组织面临许多压力，在协调实践和相关方进行服务设计活动方面可能会"走捷径"，或
者完全忽略它们。应避免这样做，因为集成和协调对所交付的产品和服务的整体质量至关
重要。
5.2.13.1 设计思维
设计思维是一种以人为中心的实用方法，可以加速创新。它被产品和服务设计人员以及组
织用于解决复杂问题，并找到满足组织及其客户需求的实用、创造性的解决方案。它可以
被看作是精益和敏捷方法的补充方法。设计思维利用逻辑、想象力、直觉和系统思维来探
索各种可能性，并创造有利于客户的预期结果。
设计思维包括一系列活动：
⚫ 灵感和同情，通过直接观察人们及其工作方式或如何与产品和服务互动，
以及确定他们如何与其他解决方案以不同的方式互动。
⚫ 思想，它结合了发散和融合思维。发散思维是提供不同、独特或变体想法
的能力，而融合思维是找到特定问题的首选解决方案的能力。发散思维可
确保探索许多可能的解决方案，而融合思维则将这些解决方案缩小到最终
的首选解决方案。
⚫ 原型设计，这些想法在早期测试、迭代和精炼。原型有助于收集反馈和改
进想法。原型让服务设计人员更好地了解新解决方案的优缺点，从而加快
了创新过程。
⚫ 实施，使概念栩栩如生。这应与所有相关的服务管理做法和其他各方协
调。敏捷方法可用于以迭代方式开发和实施解决方案。
⚫ 评估（结合其他做法，包括项目管理和发布管理）衡量产品或服务实施的
实际绩效，以确保满足验收标准，并找到任何改进机会。
设计思维最好由多学科团队应用;因为它平衡了客户、技术、组织、合作伙伴和供应商的观
点，因此具有很强的集成性，与组织的 SVS 非常一致，并且可能是数字化转型的关键推
动因素。

237
ITIL 4 基金会
l
5.2.13.2 客户和用户体验
CX 和 UX 服务设计的方面对于确保产品和服务为客户和组织提供所需的价值至关重要。
CX 设计侧重于管理整个 CX 的各个方面，包括时间、质量、成本、可靠性和有效性。UX
特别关注产品或服务的易用性以及客户如何与其交互。
精益用户体验
精益用户体验（Lean UX）设计是一种心态、文化和包含精益敏捷方法的过程。它以最

小的可行增量实现功能，并通过根据结果假设测量结果来确定成功。精益 UX 在开发使用
敏捷开发方法的项目时非常有用。核心目标是尽早获得反馈，以便用于快速决策。
精益 UX 的典型问题可能包括：此产品/服务的客户是谁，它将用于什么用途？何时使用，
在什么情况下使用？最重要的功能是什么？最大的风险是什么？
每个问题可能有多个答案，这会产生比实际处理更多的假设。然后，团队将根据这些假设
向组织及其客户表示的风险确定优先级。
风险识别、评估和治疗是所有设计活动中的关键要求;因此，风险管理必须作为服务设计的
一个综合方面加以包括。这将确保提供产品和服务以及实践、技术和测量方法的操作所涉
及的风险与组织风险和影响保持一致，因为风险管理已嵌入到所有设计流程和活动中。

237
ITIL 4 基金会
图 5.32 服务设计对价值链活动的贡献热图
图 5.32 显示了服务设计对服务价值链的贡献，所有价值链活动都涉及以下实践：
⚫ 计划服务设计实践包括规划和组织人员、合作伙伴和供应商、信息、通
信、技术和新产品和服务或更改的产品和服务的实践，以及组织与客户之
间的互动。
⚫ 改进服务设计可用于改进现有服务以及从头开始创建新服务。服务可以设
计为最低可行的服务，部署，然后迭代和改进，以便根据反馈进一步增加
价值。
⚫ 接合服务设计融合了 CX 和 UX，这是参与的典型示例。
⚫ 设计和过渡 The 服务设计的目的是设计易于使用、可取且可以由组织提

供的产品和服务。
⚫ 获取/构建服务设计包括标识需要为新或更改的服务获取或构建的产品、服
务和服务组件。
⚫ 交付和支持服务设计通过服务的操作、恢复和维护来管理用户的完整旅
程。

237
ITIL 4 基金会
l
5.2.14 服务台
关键消息
服务台实践的目的是捕获对事件解决和服务请求的需求。它还应是服务提供商及其所有用
户的入口点和单一联系点。
服务台为用户提供了一条清晰的路径，以便用户报告问题、查询和请求，并让他们得到确
认、分类、拥有和操作。如何管理和交付此实践可能有所不同，从轮班工作的实际人员团
队到几乎连接的分布式人员组合，或自动化技术和机器人。函数和值保持不变，无论模型
如何。
随着自动化程度的提高和技术债务的逐步消除，服务台的重点是为"人员和企业"提供支
持，而不仅仅是技术问题。服务台越来越多地被用来安排、解释和协调各种事项，而不仅
仅是修复损坏的技术，服务台已成为任何服务操作的重要组成部分。
需要理解的一个关键点是，无论服务台及其人员的效率如何，总会有需要升级的问题，并
支撑其他团队的支持。支持和开发团队需要与服务台密切合作，向用户和客户提供"联合"
方法。
服务台可能不需要高度技术性，尽管有些是。但是，即使服务台相当简单，它在提供服务
方面仍然起着至关重要的作用，并且必须由其对等组积极支持。还必须了解服务台对用户
体验以及用户对服务提供商的看法有重大影响。
一个好的服务台的另一个关键方面是它对更广泛的组织、业务流程和用户的实际理解。服
务台不仅通过事件日志记录等事务行为来增加价值，还通过理解和根据此操作的业务上下
文采取行动来增加价值。服务台应该是服务提供商与其用户之间的同情和知情链接。
随着自动化、AI、机器人过程自动化（RPA）和聊天机器人的提高，服务台正在通过在

线门户和移动应用程序直接提供更多自助服务日志记录和解析。对服务台的影响是减少了
电话联系，减少了低级工作，并且在需要时更有能力专注于优秀的 CX。服务台提供各种
通道。其中包括：

237
ITIL 4 基金会
l
⚫ 电话呼叫，其中可以包括专门技术，如交互式语音响应（IVR）、电话会
议、语音识别等
⚫ 服务门户和移动应用程序，由服务和请求目录支持，以及知识库
⚫ 聊天，通过实时聊天和聊天机器人 l 电子邮件进行记录和更新，以及后
续调查和确认。非结构化电子邮件可能难以处理，但基于 AI 和机器学习
的新兴技术已开始解决此问题
⚫ 走进服务台在某些行业越来越普遍，例如，
高等教育，那里有需要身体存在的高峰活动
⚫ 文本和社交媒体消息，可用于重大事件情况下的通知和联系特定利益相关
者组，但也可用于允许用户请求支持
⚫ 公共和公司社交媒体和论坛，用于联系服务提供商和点对点支持。
某些服务台具有有限的支持窗口，提供服务覆盖（例如，08.00~20.00，周一至周五）。因
此，工作人员应采用轮班模式，提供一致的支助水平。
在某些情况下，服务台是一个有形的团队，在单个位置工作。集中式服务台需要支持技
术，例如：
⚫ 智能电话系统，结合计算机电话集成、IVR 和自动呼叫分发 l 工作流
系统，用于路由和上报，以及劳动力管理和资源规划系统，即知识库
⚫ 呼叫记录和质量控制 l 远程访问工具 l 仪表板和监控工具 l 配置管
理系统。
在其他情况下，虚拟服务台允许座席在地理上分散的多个位置工作。虚拟服务台需要更复
杂的支持技术，涉及更复杂的路由和升级;这些解决方案通常是基于云的。
服务台员工需要跨多个广泛的技术和业务领域进行培训和能力培训。特别是，他们需要展
示优秀的客户服务技能，如同理心、事件分析和优先级、有效的沟通和情商。关键技能是
能够充分理解和诊断特定事件的业务优先级，并采取适当行动，使之得到解决，使用可用
的技能，知识，人和流程。

237
ITIL 4 基金会
图 5.33 服务台对价值链活动的贡献热图
图 5.33 显示了服务台对服务价值链的贡献，除计划外，所有价值链活动都涉及这种做
法：
⚫ 改进服务台活动不断受到监控和评估，以支持持续改进、协调和价值创
造。服务台收集用户的反馈，以支持持续改进。
⚫ 参与 The 服务台是战术和操作与用户互动的主渠道。
⚫ 设计和过渡 The 服务台提供了一个渠道，以便与用户沟通有关新服务和

更改的服务。服务台员工参与发布规划、测试和早期生活支持。
⚫ 获取/构建服务台工作人员可以参与获取服务组件，用于满足服务请求和解
决事件。
⚫ 交付和支持 The 服务台是管理事件和服务请求的协调点。
5.2.15 服务级别管理

237
ITIL 4 基金会
l
关键消息
服务级别管理实践的目的是为服务性能设置明确的基于业务的目标，以便根据这些目标对
服务的交付进行适当的评估、监视和管理。
这种做法涉及服务级别的定义、文档和主动管理。由于服务可能涉及各种和不同的活动的"
捆绑"，其中一些活动需要合并和聚合，以反映现实的观点。
服务级别管理提供组织的服务的端到端可见性。为此，服务级别管理：
⚫ 与客户建立服务和目标服务级别的共享视图
⚫ 通过收集、分析、存储和报告已标识服务的相关指标，确保组织满足定义
的服务级别
⚫ 执行服务审核，以确保当前服务集继续满足组织及其客户的需求
⚫ 捕获和报告服务问题，包括针对定义的服务级别的性能。
服务级别管理的技能和能力包括关系管理、业务联络、业务分析以及商业/供应商管理。这
种做法需要务实地注重整个服务，而不仅仅是其组成部分;例如，不应将简单的单个指标
（如系统可用性百分比）用于表示整个服务。
5.2.15.1 服务级别协议
服务级别协议（SL）长期以来一直被用作从客户角度衡量服务性能的工具，重要的是在

更广泛的业务环境中达成一致。使用 SL 可能会带来许多挑战;它们通常不能充分反映更广
泛的服务性能和用户体验。
定义：服务级别协议
服务提供商与客户之间的书面协议，用于标识所需的服务和预期的服务级别。

237
ITIL 4 基金会
l
成功 SL 的一些关键要求包括：
⚫ 它们必须与服务目录中定义的"服务"相关;否则，它们只是没有目的的单个
指标，不能提供足够的可见性或反映服务视角。
⚫ 它们应与定义的结果相关，而不仅仅是操作指标。这可以通过平衡的指标
捆绑包来实现，例如客户满意度和关键业务成果。
⚫ 它们应反映"协议"，即服务提供商和服务使用者之间的参与和讨论。让所有
利益相关者（包括合作伙伴、赞助商、用户和客户）参与进来非常重要。
⚫ 它们必须简单写，易于理解和使用各方。
在许多情况下，将基于单系统的指标作为目标可能会导致服务合作伙伴之间在服务交付成
功和用户体验方面出现不一致和脱节。例如，如果 SLA 仅基于服务的正常运行时间百分
比，则提供商可以将其视为成功，但仍会错过对消费者重要的重大业务功能和结果。这称
为"西瓜 SLA"效果。
西瓜 SLA 效应
传统的 SL 基于单个活动，如事件解决时间、系统可用性（'99.9'）和卷指标（例如处理

的事件或请求数）。如果没有业务环境，这些指标通常毫无意义。例如，尽管 99.6% 的系
统可用性令人印象深刻，但这仍然需要与关键业务需求保持一致。系统可能具有可接受的
0.4% 的不可用率，但如果该时间发生在发生重要流程（如商业交易、正在使用的营业厅
或正在使用的营业厅），则无论是否满足 SLA，客户/用户满意度都将很低。
如果服务提供商认为它工作出色（报告都是绿色的），则对服务提供商来说，这可能是个问
题，因为实际上其客户对收到的服务不满意，并且对提供商没有注意到这一点感到沮丧。
这被称为西瓜 SLA 效应，就像西瓜一样，SLA 在外侧可能呈绿色，但里面实际上是红色
的。
服务级别管理确定真实反映客户实际体验和对整个服务的满意度的指标和度量。这些差
异因组织而异，了解这些内容的唯一方法是直接从客户那里了解这些内容。

237
ITIL 4 基金会
l
服务级别管理需要集中和努力来参与和倾听客户的需求、问题、顾虑和日常需求：
⚫ 需要参与来了解和确认客户的实际持续需求和要求，而不仅仅是服务提供
商解释或几年前商定的内容。
⚫ 倾听作为建立关系和建立信任的活动非常重要，旨在向客户展示他们受到
重视和理解。这有助于使提供商远离始终处于"解决方案模式"状态，并建立
新的、更具建设性的伙伴关系。
参与和倾听的活动为建立改善的关系和专注于真正需要交付的内容提供了绝佳的机会。它
还使服务交付员工能够基于经验地了解使用他们的技术完成的日常工作，使他们能够提供
更以业务为中心的服务。
服务级别管理涉及整理和分析来自多个来源的信息。这些来源包括：
⚫ 客户参与 This 这涉及初始倾听、发现和信息捕获，以基于这些指标、衡

量和持续的进展讨论。考虑向客户提出一些简单的开放式问题，例如：ll
你的工作涉及什么？l 技术对您有什么帮助？
⚫ 您的主要业务时间、区域、人员及活动是什么？
⚫ 美好的一天和糟糕的一天有什么区别？l 哪些活动对您最重要？
⚫ 您今年的目标、目标和衡量标准是什么？l 衡量你成功的最佳标准是什
么？
⚫ 您如何对服务或 IT/技术提出意见和评估？我们怎样才能为您提供更多帮
助？
⚫ 客户反馈最好从许多正式和非正式来源收集，包括：
⚫ 调查这些可以从即时反馈（如特定事件的后续问题）或更反思性的定期调
查（衡量对整体服务体验的反馈）进行。这两种类型都是基于事件的。
⚫ 关键业务相关措施 These 这些是服务提供商与其客户根据客户所商定的

措施
值非常重要。这可能是一束 SLA 指标或非常具体的业务活动，如

销售交易、项目完成或运营功能，例如在 x 分钟内将救护车送往事
故现场。
⚫ 操作指标 These 这些是各种操作活动的低级指标，可能包括系统可用

性、事件响应和修复时间、更改和请求处理时间以及系统响应时间。

237
ITIL 4 基金会
l
⚫ 业务指标这些可以是客户认为有用或有价值的任何业务活动，并用作衡量
服务成功与否的手段。这些指标可能与一些简单的交易二进制措施不同，
例如 ATM 或 POS 终端在营业时间（每天 09：00~ 17：00）或成功完
成商务活动（如乘客办理登机手续）时的可用性。
收集并整理此反馈以便进行持续审核后，可用作设计适当测量和报告模型和做法的输入。
图 5.34 服务级别管理对价值链活动的贡献热图
图 5.34 显示了服务级别管理对服务价值链的贡献，实践主要应用于计划和参与活动：
⚫ 规划服务级别管理支持规划产品和服务组合和服务产品，并提供有关实际
服务性能和趋势的信息。
⚫ 改善用户的服务反馈以及客户的要求，可能是改进服务的动力。
参与服务级别管理可确保通过反馈处理和持续服务审查与客户和用户持续
互动。
⚫ 设计和过渡新服务与变更服务的设计与开发通过与客户的互动以及过渡中
反馈回路的一部分，从这种做法中获得输入。
⚫ 获取/构建服务级别管理为组件和服务性能以及产品和服务的测量和报告功
能提供目标。

237
ITIL 4 基金会
l
⚫ 交付和支持服务级别管理将服务绩效目标传达给运营和支持团队，并收集
他们的反馈，作为改进服务的投入。
ITIL 故事：Axle 的服务级别管理
苏：我们定期收集客户的反馈，分析他们的要求和需求，并更新我们的服务产品，以满足
他们的期望。
Radhika：我们不能把每一个客户的期望都投入到我们的租赁协议中，但我们关心所有客
户，并尽最大努力满足这些期望。
苏：我们还监控合作伙伴和供应商提供的服务的质量，例如克雷格清洁公司为我们所做的
工作。执行此操作时，我们需要确保我们每个服务部分的质量都满足或超过用户的期望。
5.2.16 服务请求管理
关键消息
服务请求管理实践的目的是通过以有效和用户友好的方式处理所有预定义、用户启动的服
务请求来支持服务约定的质量。

237
ITIL 4 基金会
l
定义：服务请求
来自用户或用户授权代表的请求，该请求启动已作为服务交付正常部分商定的服务操作。
每个服务请求可能包括以下一个或多个：
⚫ 请求服务交付操作（例如，提供报告或更换碳粉盒）
⚫ 信息请求（例如，如何创建文档或办公室的工作时间）
⚫ 提供资源或服务的请求（例如，向用户提供电话或笔记本电脑，或为开发
团队提供虚拟服务器）
⚫ 访问资源或服务的请求（例如，提供对文件或文件夹的访问）
⚫ 反馈、表扬和投诉（例如，对新界面的投诉或对支持团队的赞扬）。
满足服务请求可能包括对服务或其组件的更改;通常这些是标准更改。
服务请求是服务交付的正常部分，不是作为事件处理的服务失败或降级。由于服务请求是
预先定义和预先约定的，作为服务交付的正常部分，因此通常可以正式化，并采用明确的
标准程序进行启动、批准、履行和管理。某些服务请求具有非常简单的工作流，例如信息
请求。其他人员（如新员工的设置）可能相当复杂，需要许多团队和系统的贡献才能实
现。无论复杂性如何，满足请求的步骤都应众所周知并加以验证。这允许服务提供商商定
履行时间，并为用户提供请求状态的明确沟通。
某些服务请求需要根据财务、信息安全或其他策略进行授权，而其他请求可能不需要任何
授权。要成功处理，服务请求管理应遵循以下准则：
⚫ 服务请求及其履行应尽可能标准化和自动化。
⚫ 应制定政策，规定在有限或甚至没有额外批准下满足哪些服务请求，以便
简化履行。
⚫ 用户对履行时间的期望应根据组织能够实际交付的内容明确设定。
⚫ 应确定并实施改进机会，以缩短实现时间并利用自动化。
应包含策略和工作流，以记录和重定向作为服务请求提交但实际应作为事
件或更改管理的任何请求。

237
ITIL 4 基金会
l
某些服务请求可以通过从提交到关闭的自动化完全满足，从而获得完整的自助服务体验。
示例包括客户端软件安装或虚拟服务器的预配。
服务请求管理依赖于精心设计的流程和程序，这些流程和程序通过跟踪和自动化工具进行
操作，以最大限度地提高实践的效率。不同类型的服务请求将具有不同的实现工作流，但
如果确定了数量有限的工作流模型，效率和可维护性都将得到改善。当需要将新的服务请
求添加到服务目录中时，应尽可能利用现有的工作流模型。
图 5.35 服务请求管理对价值链活动的贡献热图
图 5.35 显示了服务请求管理对服务价值链的贡献，除计划活动外，所有服务价值链活动
都涉及该实践：
⚫ 改进服务请求管理可以为改进计划、表扬和用户投诉提供渠道。它还通过
提供有关满足请求的趋势、质量和反馈信息，从而有助于改进。
⚫ 接合服务请求管理包括定期通信，以收集特定于用户的要求、设置期望值
并提供状态更新。
⚫ 设计和转换标准对服务更改可以作为服务请求启动和完成。
⚫ 获取/构建服务请求的履行可能需要获取预先批准的服务组件。

237
ITIL 4 基金会
l
交付和支持服务请求管理对正常服务交付做出了重大贡献。价值链的这一
活动主要涉及确保用户继续富有成效，有时在很大程度上取决于满足其要
求。
5.2.17 服务验证和测试
关键消息
服务验证和测试实践的目的是确保新的或更改的产品和服务满足定义的要求。服务价值的
定义基于客户、业务目标和法规要求的投入，并作为设计和过渡价值链活动的一部分进行
记录。这些投入用于建立可衡量的质量和性能指标，以支持确定保证标准和测试要求。
5.2.17.1 服务验证
服务验证侧重于建立部署和发布管理验收标准（必须满足生产就绪条件的条件），这些标准
通过测试进行验证。验收标准可以是以实用程序或保修为中心的，并且通过了解客户、监
管、业务、风险管理和安全要求来定义。
本实践的服务验证活动建立、验证和记录以实用程序和保修为中心的服务保证标准，并构
成测试活动的范围和重点的基础。
5.2.17.2 测试
测试策略定义了测试的总体方法。它可以应用于环境、平台、一组服务或单个服务。应在
内部开发的系统和外部开发的解决方案上同样进行测试。测试策略基于服务接受标准，应
符合相应利益相关者的要求，以确保测试符合风险偏好并符合目的。
典型的测试类型包括：
⚫ 实用程序/功能测试：
⚫ 单元测试单个系统组件的测试
⚫ 系统测试系统整体测试，包括软件和平台

237
ITIL 4 基金会
l
⚫ 集成测试一组从属软件模块一起测试
⚫ 回归测试测试以前工作函数是否受到影响。
保修/非功能测试：l 性能和容量测试在负载 l 安全测试测试漏洞、策略合规
性、渗透和拒绝服务风险下检查速度和容量
⚫ 合规性测试检查是否满足法律和法规要求
⚫ 备份、事件监视、故障转移、恢复和报告的操作测试
⚫ 保修要求测试检查必要的文档、培训、支持模型定义和知识转移
⚫ 用户接受测试新系统或更改系统的用户为批准发布而执行的测试。
图 5.36 服务验证和测试对价值链活动的贡献热图
图 5.36 显示了服务验证和测试对服务价值链的贡献，除计划活动外，所有价值链活动都
涉及该实践：
⚫ 改进服务验证和测试指标（如针对 SL 的转义缺陷、测试覆盖率和
服务性能）是改进 CX 和降低风险的关键成功措施。
⚫ 让一些利益相关者参与服务验证和测试活动，有助于吸引他们，提
高服务的可见性和采用率。

237
ITIL 4 基金会
l
⚫ 设计和过渡服务设计、知识管理、性能管理、部署管理和发布管理
都与服务验证和测试实践紧密集成。
获取/构建服务验证和测试活动与与从外部服务提供商获取服务相关的所有
实践以及瀑布和敏捷方法中的项目管理和软件开发活动密切相关。
⚫ 交付和支持已知错误通过服务验证和测试捕获，并与服务台和事件
管理实践共享，以实现更快的服务恢复时间。同样，有关服务中断
或逃逸缺陷的信息将反馈到服务验证和测试中，以提高验收标准和
测试活动的有效性和覆盖范围。
5.3 技术管理实践
5.3.1 部署管理
关键消息
部署管理实践的目的是将新的或更改的硬件、软件、文档、流程或任何其他组件移动到实
时环境。它还可能涉及将组件部署到其他环境以进行测试或暂存。
部署管理与发布管理和更改控制紧密配合，但只是一个单独的实践。在某些组织中，"预配
"一词用于描述基础结构的部署，部署仅用于表示软件部署，但在这种情况下，术语部署用
于表示两者。
有许多不同的方法来部署。许多组织结合使用这些方法，具体取决于其特定的服务和要求
以及发布大小、类型和影响。
⚫ 分阶段部署新组件或更改的组件一次只部署到生产环境的一部分，例如部
署到一个办公室或一个国家/地区的用户。在部署完成之前，此操作根据需
要重复多次。
⚫ 持续交付组件在需要时进行集成、测试和部署，为客户反馈循环提供频繁
的机会。

237
ITIL 4 基金会
l
⚫ 大爆炸部署新组件或更改的组件同时部署到所有目标。当依赖项阻止同时
使用新旧组件时，有时需要此方法。例如，可能有一个数据库架构更改与
某些组件的早期版本不兼容。
拉取部署新软件或更改的软件在受控存储库中可用，用户在选择时将软件
下载到客户端设备。此方法使用户能够控制更新的时间，并可以与请求管
理集成，使用户能够仅在需要时请求软件。
可用于部署的组件应保存在一个或多个安全位置，以确保在部署之前不对其进行修改。这
些位置统称为软件和文档的最终媒体库，以及硬件组件的最终硬件存储。
支持部署的工具多种多样。它们通常与配置管理工具集成，可以为审核和更改管理提供支
持。大多数组织都有用于部署客户端软件的工具，这些工具可以与服务门户集成以支持请
求管理实践。
围绕部署的通信是发布管理的一部分。在发布单个部署之前，用户和客户通常不会感兴
趣。
如果基础结构作为服务提供，则新服务器或更改的服务器、存储或网络的部署通常由组织
管理，通常将基础结构视为代码，以便组织可以自动部署。在这些环境中，某些部署可能
由供应商控制，例如安装固件更新，或者如果它们提供操作系统以及他们可能会部署操作
系统修补程序的基础结构。IT 组织必须确保他们知道计划部署以及已执行哪些部署，以维
护受控环境。
如果应用程序开发作为服务提供，则部署可能由外部应用程序开发人员、内部 IT 部门或
服务集成商执行。同样，组织必须了解所有部署，以便维护受控环境。
在具有多个供应商的环境中，了解每个组织部署活动的范围和边界以及这些活动将如何交
互非常重要。大多数组织都有部署过程，标准工具和详细过程通常支持此流程，以确保以
一致的方式部署软件。对于不同的环境，通常有不同的流程。例如，部署客户端应用程序
软件可能有一个过程，而部署服务器操作系统修补程序的过程则完全不同。
图 5.37 显示了部署管理对服务价值链的贡献，实践主要应用于设计和转换，获取/构建价
值链活动，还用于改进活动：
⚫ 改进某些改进可能需要在交付组件之前进行部署，并且这些组件应像任何
其他部署一样进行规划和管理。
⚫ 设计和过渡部署管理移动新的和更改

237
ITIL 4 基金会
l
组件的生活环境，所以它是这种价值链活动的重要组成部分。
⚫ 获取/生成更改可以作为此价值链活动的一部分增量部署。这在 DevOps
环境中尤为常见，因为其中完整的 CI/CD 工具链可以自动实现。

237
ITIL 4 基金会
图 5.37 部署管理对价值链活动的贡献热图
ITIL 故事：Axle 的部署管理
Marco：在将更改部署到预订应用之前，我们会将更改发布到测试环境。经过彻底测试，
我们将更改提供给用户和客户。
Radhika：我们最近意识到，同样的逻辑可以应用于我们的一些非数字服务和组件。例
如，上个月我们推出了两个全新的混合模型，供一些大城市租用。我们为新车创建了促销
服务，更新了我们的营销材料，培训了技术人员使用新车型，并提前部署了所有产品，包
括车辆。这发生在制造商正式推出混合动力汽车之前。当然，这是在他们的许可下发生
的。

237
ITIL 4 基金会
苏：到发射日期时，我们已经准备好走了。那天我们把车租好。
Henri：与我们的制造商合作意味着我们成功且准备充分的发布，在我们的客户和客户中
引起了轰动。
5.3.2 基础设施和平台管理
关键消息
基础结构和平台管理实践的目的是监督组织使用的基础结构和平台。如果执行得当，这种
做法可以监测组织可用的技术解决方案，包括外部服务提供商的技术。
IT 基础架构是提供提供 IT 服务所需的环境的物理和/或虚拟技术资源，如服务器、存
储、网络、客户端硬件、中间件和操作系统软件。这包括客户用于访问服务或使用产品的
任何 CI。IT 基础结构可能由服务提供商或外部供应商作为专用、共享或云服务进行管
理。基础结构和平台管理还可能包括组织用于运行其 IT 基础结构的建筑物和设施。
基础设施和平台管理实践包括提供必要的技术，以支持为组织及其利益攸关方创造价值的
活动。这可能包括准备采用新技术，如机器学习、聊天机器人、人工智能、移动设备管理
和企业移动管理。
237
ITIL 4 基金会
云服务模型
云服务模型包括：
⚫ 软件即服务（SaaS）使用者可以使用在云基础架构中运行的应用程序，
而无需控制甚至管理底层云基础结构。
⚫ 平台即服务（PaaS）使用者可以部署到使用供应商支持的编程语言、服
务、库和/或工具创建的云获取的应用程序上，而无需控制甚至管理底层云
基础架构。它们可以控制已部署的应用程序，有时还可以控制应用程序和
托管环境的配置设置。
⚫ 基础架构即服务（IaaS）使用者无需控制底层基础结构即可获取处理、存
储和/或任何其他计算资源。
云服务部署模型
每个服务模型都可以通过多种方式部署，无论是独立部署还是使用以下组合：

237
ITIL 4 基金会
⚫ 私有云这种类型的云可能位于组织内部或外部。它是一个云基础结构或平
台，由特定组织专门使用，同时，可以具有一个或多个使用者。此云通常
由组织、提供商或两者的组合管理和拥有。
⚫ 公共云这种类型的云位于云提供商的场所。它预配用于开放用途，并且可
能由任何有意使用它的组织拥有、管理和操作。
⚫ 社区云社区云可能由社区中的一个或多个利益相关者拥有、管理和运行，
并且它可能存在于组织的场所内或外部。此云部署模型由多个云服务组
成，这些服务旨在支持和共享具有相同要求的云服务客户的集合，并且它
们彼此有关系。
⚫ 混合云此云基础架构由两个或多个不同的云基础架构（私有、社区或公
共）组成，这些基础架构仍然是唯一的实体，但由标准化或专有技术绑定
在一起，可实现数据和应用程序可移植性。
必须考虑，每个组织都必须制定自己的战略，以便通过任何类型的基础结构或平台实现预
期结果。每个组织都应设计自己的云管理系统，以协调基础架构和平台的所有相互关联的
组件及其业务目标以及预期的服务质量和运营效率。

237
ITIL 4 基金会
图 5.38 基础设施和平台管理对价值链活动的贡献热图
图 5.38 显示了基础设施和平台管理对服务价值链的贡献，除参与活动外，所有价值链活
动都涉及该实践：
⚫ 计划基础结构和平台管理提供有关用于组织战略和战术规划的技术机会和
限制的信息。
⚫ 改进有关技术机会的信息，以支持持续改进，以及本做法对正在使用的技
术的任何限制。
⚫ 设计和过渡产品和服务设计受益于所提供的技术机会和限制信息。
⚫ 获取/构建基础结构和平台管理是此活动的关键贡献者，因为它提供有关要
获取的组件的必要信息。

237
ITIL 4 基金会
⚫ 在运营级别，基础结构和平台管理支持持续维护服务和基础结构，包括执
行修补程序管理、备份等。
ITIL 实践和云计算
云的出现是 IT 领域数十年来面临的最大挑战和机遇之一。轻触按钮即可获得快速、弹性
存储和 IT 服务的承诺是许多组织难以在内部提供的，不是因为没有好处，而是因为他们
自己的 ITSM 流程和控制没有被改编为支持一种完全不同的工作方式。
无论 IT 部门位于何处，IT 服务的管理和控制都是 IT 部门的一项关键技能，ITIL 提供的
流程和控制易于适应以支持这些云服务的管理。
对云服务管理做出协调一致的响应至关重要。试图仅将云服务提供作为操作问题解决的组
织将在战术方面遭受损失，就像试图在战术战线上控制云服务的组织将在战略层面遭受损
失一样。需要采取一种联合办法，涵盖战略、战术和作战这三个层次。
除了基础架构和平台管理实践外，基于云的服务的操作和管理还涉及许多其他实践。应当
指出，这不是一个全面清单：
⚫ 服务财务管理 IT 部门通常对云计算做出的调整之一是更改其财务计划，
通常同时使用传统的资本支出（CAPEX）和运营支出（OPEX）。随着
云计算的出现，现在人们倾向于使用 OPEX 而不是 CAPEX，因为云服务

237
ITIL 4 基金会
通常用作实用程序，并且从运营预算中支付。如果云服务被认为比内部服
务更快、更容易访问，则随着业务中更多部分使用云服务，与之相关的成
本将会增加。必须了解 IT 成本模型的调整，ITIL 服务财务管理实践可帮
助确定所需的技术和控制措施，以确保组织不会意外耗尽 OPEX。
⚫ 供应商管理这种做法的重点需要从简单地选择供应商并加入供应商转变为
作为全面发布管理流程的前端。这将确保在加入新的云产品之前定期评估
IT 安全、数据保护和法规遵从性等领域。
⚫ 容量和性能管理与服务财务管理相结合，此做法应建立并监控预算，如果
需求上升导致云服务成本增加，应跟踪阈值并发布警告。
⚫ 更改控制这种做法的边界必须重新定义，因为云服务提供商通常以最少的
客户参与度进行更改，并且几乎没有客户批准。构建在云服务之上的产品
和服务需要更多地利用标准更改来释放云平台（和相关业务模式）提供的
优势。
⚫ 事件管理这种做法的重点将从知道如何解决内部问题，到了解哪个云提供
商支持哪个服务，以及他们需要哪些信息来解决问题。需要更加谨慎来支
持受影响的客户和团队。
⚫ 部署管理这种做法对 IT 部门仍然至关重要，但安全上船或外载云提供商
的能力将成为 IT 部门的常见要求。部署管理将是成功的 IT 组织的关键
功能，以确保快速部署新的云功能并将其嵌入内部服务产品中。

237
ITIL 4 基金会
5.3.3 软件开发和管理
关键消息
软件开发和管理实践的目的是确保应用程序满足内部和外部利益相关者在功能、可靠性、
可维护性、合规性和可审计性方面的需要。
术语"软件"可用于描述从单个程序（或程序套件）到较大构造（如操作系统、操作环境或
数据库）的任何内容，各种较小的应用程序、流程或工作流都可以在其上运行。因此，该
术语包括但不限于桌面应用程序或移动应用程序、嵌入式软件（控制计算机和设备）和网
站。
软件应用程序，无论是内部开发还是合作伙伴或供应商开发，对于在支持技术的业务服务
中交付客户价值至关重要。因此，软件开发和管理是每个现代 IT 组织的关键实践，可确
保应用程序适合用途和使用。
软件开发和管理实践包括以下活动：

237
ITIL 4 基金会
⚫ 解决方案体系结构 l 解决方案设计（用户界面、CX、服务设计等）l
软件开发
⚫ 软件测试（可以包括多个组件，如单元测试、集成测试、回归测试、信息
安全测试和用户验收测试）
⚫ 管理代码存储库或库，以保持人工制品 l 包创建的完整性，以便有效
和高效地部署应用程序 l 版本控制、共享和持续管理较小的代码
块。
两种普遍接受的软件开发方法称为瀑布和敏捷方法（有关这些方法的详细信息，请参阅第
5.1.8 节）。
软件管理是一种更广泛的实践，包括正在进行的设计、测试、操作和改进软件应用程序的
活动，以便它们继续促进价值创造。可以使用跟踪组件从构思到持续改进并最终停用的生
命周期持续评估软件组件。此生命周期如图 5.39 所示。

237
ITIL 4 基金会
图 5.39 软件生命周期
图 5.40 软件开发和管理对价值链活动的贡献热图

237
ITIL 4 基金会
图 5.40 显示了软件开发和管理对服务价值链的贡献，除参与活动外，所有价值链活动都
涉及该实践：
⚫ 计划软件开发和管理提供有关与组织软件的创建和更改相关的机会和限制
的信息。
⚫ 改进服务改进，包括服务的软件组件，尤其是内部开发的服务组件，依赖
于这种做法。
⚫ 设计和过渡软件开发和管理使组织能够全面设计和管理产品和服务的更
改。
⚫ 内部产品的创建和合作伙伴和供应商开发的产品的配置取决于这种做法。
⚫ 交付和支持软件开发和管理为交付和支持团队提供使用有助于共同创造价
值的产品所需的文档。
ITIL 的故事：一年
亨利加入 Axle 租车公司已经一年了。在此期间出现了显著的积极变化。新的服务，如生
物识别和先进的驾驶员辅助系统，正被 Axle 的消费者广泛采用，公司继续获得快速可靠
的服务的声誉。

237
ITIL 4 基金会
客户忠诚度提高了，重复预订数量大幅增加。Axle 还被两个主要客户（包括燃料食品）
评为年度合作伙伴。
Axle Green 改进计划正在进行中，许多目标使公司更加环保。用电动汽车弥补 Axle 车队
一半的努力也进展顺利，该公司在实现这一目标方面取得了很大进展。Henri 成为全球最
知名的租车品牌，提供全面的旅行体验，这一愿景触手可及。
Axle 了解 ITIL 的概念如何帮助其实现其目标。采用和调整 ITIL 指南有助于 Axle 提供
高质量的服务，并为自身及其客户创造价值。

237
ITIL 4 基金会
附录 A：价值流示例
本节演示如何将服务价值链应用于实际情况，并提供价值流的示例。这些值流显示活动如
何流经价值链。这些不是要复制的模型，而只是示例，以便了解如何使用价值链。
这些示例包括一些示例作业角色。这些只是描述虚构的组织中可能存在的角色，并非建议
每个组织的角色。为了帮助理解，对第一个价值流进行了一些详细的描述;在随后的示例
中，只提供了一个表。
A.1 用户需要解决事件
在价值流的第一个示例中，由于无线接入点出现故障，仓库中的 WiFi 无法正常工作。这
对业务有重大影响，因为叉车驾驶员无法足够快地收到指令，因此可能会错过业务截止时
间。这似乎是一个相对直接的事件;但是，不能简单地按照预定的事件管理程序的步骤机械
地解决它。
首先，必须有人注意到发生了事件，并知道如何报告，并且必须能够准确地传达情况的紧
迫性，以便正确确定事件优先级。收到报告的人必须既有权使事件升级，也有权监督事件
的进展。必须建立资源，以便足够迅速地升级;某人必须具备调查事件所需的技能、知识和
工具;并且必须制定程序，允许实施标准更改，而无需获得额外的批准。必须有人可以访问
准确的配置信息，并在修复完成后记录修复。还必须能够记录备件已消耗，并针对未来需
要重新排序。但是，如果维修值任何值，则需要告知仓库已发生的情况，以便恢复正常工
作。同样重要的是，检查事件解决得如何，看看是否有任何教训需要吸取。

237
ITIL 4 基金会
表 A.1 总结了解决这一看似简单的事件所需的不同操作和资源。下表显示了多个实践如
何支持此工作，其中一些实践支持不同时间中的多个价值链活动。
表 A.1 事件解决的值流
价值链活动实践角色活动
/SVS 组件
需求仓库经理，发现仓库的一个区域没有 WiFi 覆盖
叉车驾驶员范围。这意味着叉车驱动程序需要通
仓库，以拿起他们的指示，造成延误
和风险错过业务期限。
参与服务台，事件仓库经理，服仓库经理给服务台打电话并描述问
管理务台代理题。同意这是优先级 2 事件，并且
经理将收到预期的解决时间通知。
有关此事件的信息由服务台代理记录。
交付和支持服务台，事件服务台代理、事件已迅速升级为网络支持团队。
管理网络支持工程

237
ITIL 4 基金会
交付和支持，事件管理、变网络支持工程网络支持工程师识别无线接入点出现
改进更控制、服务师故障，并将其替换为商店的备用设
配置管理，备。
IT 资产
这是标准更改，因此工程师无需额外
管理，持续改
批准。配置新接入点所需的信息是从
进
CMS 获取的。更新 IT 资产信息以显
示已使用此备件。
网络工程师更新事件管理系统，
并将案例标记为已解决。
网络工程师考虑发生了什么，以及他
们是否可以预测这个问题或更快地解
决它。
参与服务台，事件服务台代理、服务台代理与仓库经理联系，检查所
管理仓库经理有操作是否正常，然后关闭事件。
价值仓库经理， WiFi 覆盖范围已恢复，叉车驱动程序
叉车驾驶员现在可以高效工作。
参与、改进服务台、事件仓库经理，服简短的满意度调查通过电子邮件发送
管理、持续改务台经理给仓库经理，他们完成并返回。分数
进用于识别趋势，注释将传递给服务台
经理进行考虑。

237
ITIL 4 基金会
A.2 第三方软件中的错误会给用户带来问题
在此示例中，用户发现使用应用程序时出现问题。供应商有一个可用的修补程序，需要安
装此修补程序来纠正这种情况。请注意，此事件通过服务价值链采用的路径非常不同，并
且由与上一事件不同的实践平衡支持。
表 A.2 软件问题的价值流
/SVS 组件
需求管理由于正在使用的软件中存在错误，办
助理公室的管理员助理无法在其日历中输
入约会。该软件不允许在房间名称中
使用非标准字符。
参与服务台，事件管理管理员助理给服务台打电话并描述问
管理助理，服务台题。同意这是优先级 3 事件，并且
代理将通知管理助理预期的解决时间。
有关此事件的信息由服务台代理记录。
交付和支持事件服务台代理服务台代理研究供应商网站，发现此
管理特定问题在最新版本的客户端软件中
得到解决。

237
ITIL 4 基金会
交付和支持事件管理，供应服务台代理，事件升级为二线支持。二线支持检查
商二线支持供应商合同和客户端软件的发行说
管理明。
交付和支持，事件管理，二线支持，二线支持联系用户，并安排他们测试
获取/构建，参服务请求管理、管理客户端软件的新版本，以查看这是否
与部署助理解决了他们的问题。然后，他们将此
管理版本添加到服务门户，以便用户可以
服务验证和测试安装它。
交付和支持事件管理用户使用服务门户安装软件的新版
管理助理，服务台本，并测试这是否解决了他们的问
服务验证和测试，题。服务台确保用户对此解决方案感
服务请求管理到满意。
价值管理该软件现在工作正常，用户可以使用
助理房间名称中的非标准字符向日历添加
约会。
参与、改进服务台，事件管理简短的满意度调查通过电子邮件发送
管理，持续改进助理给管理员助理，他们完成并返回。分
服务台经理数用于识别趋势，注释将传递给服务
台经理进行考虑。

237
ITIL 4 基金会
提高持续改进、服务二线支持二线支持对新版本的客户端软件进行
验证和测试、服更广泛的测试，然后通过服务门户向
务请求管理、发所有用户提供。然后以受控方式部署
布管理、部署管替换以前版本的升级。
A.3 对重大新 IT 服务的业务需求
在此示例中，鞋制造商的内部 IT 部门标识了对新 IT 服务的需求。
表 A.3 创建 IT 服务的价值流
价值链活动/SVS 实践角色活动
组件
需求销售总监、销售经销售总监和经理确定需要一个新的网
理站，允许客户设计和订购个性化的鞋
子。
参与关系管理销售总监、业务关销售总监和 BRM 讨论新网站，并同意
系经理（BRM）调查实施新网站的价值、结果、成本和
风险，看看是否可行。

237
ITIL 4 基金会
计划投资组合 BRM，IT 战略讨论了新服务的创建，并确定了各种
管理、架构团队，企业方法的成本和风险。此机会优先于正
管理建筑师，开发经在完成的其他工作，以确定是否有资
理源可用于执行。
计划服务财务管理，财务分析师，IT 讨论了各种方法的潜在成本和风险，并
风险开发经理，项目提供给投资组合管理。
管理管理
办公室
参与关系管理销售总监，销售总监和 BRM 讨论新服务的预期
Brm 价值、结果、成本和风险，并同意他
们希望继续。
计划投资组合 BRM，IT 战略新服务将添加到服务组合并记录在
管理团队案。
规划、设计和过渡投资组合项目经理、开发项目经理和开发经理开始规划创建新
管理经理服务所需的工作。人被指派做必要的
项目工作。
管理、服务设计
参与关系管理，销售总监、销售为新 IT 服务的第一个版本的实用程
项目经理、业务分析序和保修制定了更详细的要求。
管理、业务分析师、软件开发团

237
ITIL 4 基金会
获取/生成软件开发和管软件开发团队软件开发团队构建积压工作，确定最
理，低可行产品，并开发足够的功能，以
项目便企业可以对此进行审查和评论。
管理、服务设计
获取/构建、设计软件开发和管软件开发审核服务的第一次迭代并提供反馈。
和过渡，改进理，团队， BRM，基于此，将重新确定产品积压工作的
项目销售总监、销售优先次序。
管理、服务设计经理
获取/构建、设服务级别软件开发团队、协商并商定了新服务的详细保修
计和过渡管理服务级别经理、要求。为监控、测量和报告以及
可用性基础设施支持服务定义了要求。
管理、容量和性能管经理，BRM，
理，销售总监
信息安全管理、服务
连续性管理、测量和
报告、事件管理
获取/构建、设软件开发和管理，软件开发团队，提供培训和文件，以支持新服
计和过渡服务台，事故管理服务台经理务。

237
ITIL 4 基金会
获取/构建、设软件开发和管理、项软件开发团队、根据软件开发团队与服务用户之
计和过渡，改目管理、服务设计、 BRM、销售总间的密切合作，创建新服务的进
进组织变更管理、部署监、销售经理一步增量版本。
管理、发布管理
价值项目管理、关系管项目经理、评估新服务的有效性，以检查其
理、服务级别管理、 BRM、服务级别工作情况。这与初始预测进行比
测量和报告经理、销售总较。
监、销售经理
商定如何衡量和报告持续价值。
参与、交付和事件管理、问题管服务台、软件开发为新服务的事件和问题提供持续
支持，改进理、团队、基础设施支支持。
持续改进持团队
价值，提高关系管理、服务级别服务级别经理、销每月定期举行会议，讨论服务绩
管理售总监效并确定改进机会。
A.4 法规变更需要新的软件开发
在此示例中，财务组织必须准备好满足新的监管要求。
表 A.4 新软件开发的价值流

237
ITIL 4 基金会
/SVS 组件
需求法律总监、合规需要更新许多 IT 服务以满足新的法
经理规要求。
参与关系管理法律总监、合规讨论了新的监管要求，并同意将创建
经理、首席信息一个项目来管理实施。
计划投资组合首席信息官、IT 确定了各种方法的成本和风险。商定
管理战略团队、项目了工作的时间尺度和资源。
服务经理、IT 开发经
金融理
管理
风险
管理
规划、参与、项目管理，项目经理、IT 开工作规划开始。人被指派去工作。制
设计和过渡服务设计、业发经理、业务分定沟通计划，并通知所有需要参与的
务分析析师、产品经理员工。

237
ITIL 4 基金会
获取/生成软件开发和管软件开发团队每个软件团队管理积压工作并为分配
理，给他们的区域开发代码。每个团队还
服务验证和测开发测试，以便包含在自动 CI/CD
试、服务设计管道中。
CI/CD 管道每天自动集成和测试所
有代码两次，确保由不同团队编写的
代码协同工作。
设计和过渡，项目项目经理、IT 开讨论并商定发布和部署计划。在部署
参与管理发经理、软件开开始之前，就同意所需的测试级别以
服务设计、服发团队、合规经及谁将授权每个部署。
务验证和测试理
获取/构建、设服务设计、组软件开发团队新软件的部署一准备就绪即触发。不
计和过渡织变更管理、需要个人更改请求，因为风险评估已
部署管理、提前执行，自动化可确保代码完全按
服务计划部署。
配置管理
配置数据用于驱动部署，因此不需要单
独的活动来更新此部署。

237
ITIL 4 基金会
价值项目管理，项目经理、首评估更新的服务，以确保满足所有法规
关系席信息官、法要求。
管理律总监、合规
经理
参与、设计和过项目管理，发项目经理、软新功能通过设置一个标志来发布，使新
渡布件开发团队、功能对用户可见。
管理、服务产品经理、服
服务台和其他需要了解现已启用此功能
台、服务目录务目录经理
的员工将收到通知。
管理
服务目录已更新。
价值，提高项目项目经理，IT 项目经过审核和关闭。
管理开发
改进机会被识别并添加到持续改
服务设计，经理、首席信
进登记册中。
关系息官、法律总
管理，持续改监、合规经理

237
ITIL 4 基金会
词汇
验收标准服务或服务组件必须满足的最低要求列表，以便关键利益干系人能够
接受。
敏捷框架和技术集合的一个总括术语，使团队和个人能够以协作、优先
级、迭代和增量交付以及时间盒的典型方式工作。有几种特定方法
（或框架）被归类为敏捷，如 Scrum、精益和看板。
体系结构管理实践提供对组成组织的所有不同要素的理解以及这些要素如何相互联系的
做法。
资产登记册数据库或资产列表，捕获关键属性（如所有权和财务价值）
。
可用性 IT 服务或其他配置项在需要时执行其约定功能的能力。
可用性确保服务提供商定的可用性水平以满足客户和用户需求的做法。
管理实践
基线作为可以评估进度或更改的起点的报告或指标。
最佳实践一种已被多个组织证明是成功的工作方式。
大数据使用来自各种来源的大量结构化和非结构化数据来获得新的见解。
业务分析实践分析企业或企业的某些要素，确定其需求，并推荐解决方案以解决这
些需求和/或解决业务问题，并为利益相关者创造价值。
商业案例组织资源支出的理由，提供有关成本、收益、选项、风险和问题的信
息。

237
ITIL 4 基金会
业务影响分析（BIA）服务连续性管理实践中的一项关键活动，用于标识重要的业务功能及
其依赖关系。
业务关系经理负责与一个或多个客户保持良好关系的角色。
（BRM）
叫与服务台的互动（例如电话）。呼叫可能导致记录事件或服务请求。
呼叫中心/联络中心处理大量传入和传出呼叫和其他交互的组织或业务部门。
能力组织、人员、流程、应用程序、配置项或 IT 服务执行活动的能力。
容量和性能管理实践确保服务达到商定和预期绩效水平，以具有成本效益的方式满足当前
和未来的需求。
容量规划创建管理资源以满足服务需求的计划的活动。
改变添加、修改或删除任何可能对服务产生直接或间接影响的东西。
更改权限负责授权更改的个人或团体。
变更控制实践确保正确评估风险、授权进行更改以及管理更改计划以最大化成功的
IT 更改次数的做法。
更改模型管理特定类型更改的可重复方法。
更改计划显示计划和历史更改的日历。
充电为服务分配价格的活动。
云计算支持按需网络访问可配置计算资源的共享池的模型，只需最少的管理
工作量或提供程序交互即可快速提供这些资源。

237
ITIL 4 基金会
合规确保遵循标准或一套准则，或采用适当、一致的会计或其他做法。
保密确保信息不提供给未经授权的实体或向未经授权的实体披露的安全目
标。
配置配置项（C）或其他资源的排列，这些资源协同工作以交付产品或
服务。还可用于描述一个或多个 C 的参数设置。
配置项（CI）任何需要管理以提供 IT 服务的组件。
配置用于在其整个生命周期中存储配置记录的数据库。CMDB 还维护配
管理数据库置记录之间的关系。
（CMDB）
配置管理系统一组用于支持服务配置管理的工具、数据和信息。
（CMS）
配置记录包含配置项（CI）详细信息的记录。每个配置记录记录单个 CI 的
生命周期。配置记录存储在配置管理数据库中。
持续改进实践通过不断发现和改进参与有效管理产品和服务的所有要素，使组织的
做法和服务与不断变化的业务需求保持一致的做法。
连续一组集成的实践和工具，用于合并开发人员的代码、生成和测试生成
的软件，并对其进行打包，以便它可供部署。

237
ITIL 4 基金会
集成/连续交付
（CI/CD）
控制管理风险、确保实现业务目标或遵循流程的方法。
成本用于特定活动或资源的资金金额。
成本中心向其分配成本的业务单位或项目。
关键成功因素（CSF）实现预期成果的必要先决条件。
文化一组由一群人共同的价值观，包括对人们应该如何行为、想法、信仰
和实践的期望。
客户定义服务要求并负责服务消耗结果的人员。
客户体验（CX）服务使用者认为的服务和服务提供商的功能和情感交互的总和。
仪表板数据的实时图形表示形式。
交付和支持确保服务根据商定的规格和利益相关者的期望交付和支持的价值链活
动。
需求根据内部和外部利益相关者的机遇和需求，对服务价值系统进行投
入。
部署任何服务组件的移动到任何环境。
部署管理实践将新的或更改的硬件、软件、文档、流程或任何其他服务组件移动到
实时环境的做法。

237
ITIL 4 基金会
设计和过渡确保产品和服务持续满足利益相关者对质量、成本和上市时间的期望
的价值链活动。
设计思维产品和服务设计人员采用的实用且以人为本的方法，用于解决复杂
问题，并找到满足组织及其客户需求的实用和创造性解决方案。
开发环境用于创建或修改 IT 服务或应用程序的环境。
DevOps 旨在改善客户价值流的组织文化。DevOps 专注于文化、自动化、
精益、测量和共享（CALMS）。
数字化转型传统商业模式的演变，以满足高度授权的客户的需求，技术发挥着
推动作用。
灾难恢复计划考虑到服务管理的四个方面，一套明确定义的计划，涉及组织如何
从灾难中恢复以及返回到灾难前状态。
司机影响战略、目标或要求的东西。
有效性衡量一项实践、服务或活动的目标是否已经实现。
效率衡量实践、服务或活动是否使用了适当数量的资源。
紧急变更必须尽快引入的更改。
参与价值链活动，提供对利益相关者需求的良好理解、透明度、持续参
与以及与所有利益相关者的良好关系。

237
ITIL 4 基金会
环境用于特定目的（例如实时环境或测试环境）的 IT 基础结构的子
集。也可能意味着影响或影响某物的外部条件。
错误可能导致事件的缺陷或漏洞。
错误控制用于管理已知错误的问题管理活动。
升级共享认识或转移问题或工作项目的所有权的行为。
事件对管理服务或其他配置项有意义的状态的任何更改。
外部客户为服务提供商以外的组织工作的客户。
失败丧失按规范操作或交付所需输出或结果的能力。
反馈回路一种技术，用于将系统某一部分的输出用作系统同一部分的输入。
服务管理的四个维度四个观点对于以产品和服务的形式切实有效地促进客户和其他利益相
关者的价值至关重要。
治理组织被指导和控制的方法。
身份用于标识和授予用户、人员或角色的系统访问权限的唯一名称。
提高确保在所有价值链活动以及服务管理的四个维度中不断改进产品、服
务和实践的价值链活动。
事件服务意外中断或服务质量下降。
事件管理通过尽快恢复正常服务操作，尽量减少事件的负面影响。

237
ITIL 4 基金会
信息与技术服务管理的四个维度之一。它包括用于提供服务的信息和知识，以及
用于管理服务价值系统各个方面的信息和技术。
信息安全管理实践通过了解和管理信息的机密性、完整性和可用性的风险来保护组织的
做法。
信息安全策略管理组织信息安全管理方法的策略。
基础设施和平台管理监督组织使用的基础结构和平台的做法。这支持监控可用的技术解决
实践方案，包括来自第三方的解决方案。
诚信确保信息仅由授权人员和活动修改的安全目标。
内部客户与服务提供商为同一组织工作的客户。
物联网通过互联网互连的设备，传统上并不被视为 IT 资产，但现在包括嵌
入式计算能力和网络连接。
IT 资产有助于交付 IT 产品或服务的任何重要组件。
IT 资产管理实践规划和管理所有 IT 资产的整个生命周期的实践。
IT 基础设施开发、测试、交付、监控、管理和支持 IT 服务所需的所有硬件、软
件、网络和设施。
IT 服务基于信息技术的服务。
Itil IT 服务管理的最佳实践指南。

237
ITIL 4 基金会
ITIL 指导原则可以指导组织在任何情况下的建议，而不管其目标、战略、工作类
型或管理结构的变化如何。
ITIL 服务价值链服务提供商的运营模式，涵盖有效管理产品和服务所需的所有关键活
动。
看板可视化工作、识别潜在阻塞和资源冲突以及管理正在进行的工作的方
法。
关键绩效指标（KPI）用于评估实现目标成功与否的重要指标。
知识管理实践维护和提高整个组织信息和知识的有效、高效和方便使用的实践。
已知错误已分析但尚未解决的问题。
精益一种侧重于通过消除浪费来最大化价值来改进工作流程的方法。
生命周期服务、产品、实践或其他实体生命周期中的完整阶段、过渡和相关状
态集。
住指在实时环境中运行的服务或其他配置项。
生活环境用于向服务使用者提供 IT 服务的受控环境。
可维护性维修或修改服务或其他实体的难易程度。
重大事件具有重大业务影响的事件，需要立即协调解决。
管理系统相互关联的或相互作用的要素，这些要素制定政策和目标，并使我们
能够实现这些目标。

237
ITIL 4 基金会
成熟衡量组织、实践或流程的可靠性、效率和有效性。
故障之间的平均时间衡量服务或其他配置项失败频率的指标。
（MTBF）
恢复服务的平均时间衡量服务在故障后恢复速度的指标。
（MTRS）
测量和报告通过降低不确定性水平来支持良好的决策和持续改进。
度量监控或报告的用于管理和改进的测量或计算。
最低可行产品（MVP）具有足够功能的产品，可满足早期客户的需求，并为未来产品开发提
供反馈。
任务说明对组织的总体目的和意图的简短而完整的描述。它规定要实现什么，
而不是应该如何做到这一点。
模型用于理解和预测其行为和关系的系统、实践、流程、服务或其他实体的
表示形式。
建模创建、维护和利用模型的活动。
监测重复观察系统、实践、流程、服务或其他实体，以检测事件并确保已
知当前状态。
监控和事件管理实践系统地观察服务和服务组件，记录和报告被确定为事件的状态的选定
变化。

237
ITIL 4 基金会
获取/生成确保服务组件在需要时和何处可用，并确保它们符合商定的规范的价
值链活动。
操作活动、产品、服务或其他配置项的例行运行和管理。
操作技术通过直接监控和/或控制阀门、泵等物理设备来检测或导致物理过程
变化的硬件和软件解决方案。
组织具有自身职能、有责任、权威和关系以实现其目标的个人或群体。
组织变革管理实践确保组织变革顺利和成功实施，并通过管理变革的人性化方面实现持
久效益的实践。
组织复原力组织预测、准备、响应和适应计划外影响的能力。
组织速度组织运行的速度、有效性和效率。组织速度影响市场、质量、安全、
成本和风险的时间。
组织和人员服务管理的四个维度之一。它确保组织的结构和管理方式，以及其角
色、职责以及权威和沟通系统得到明确定义，并支持其总体战略和运
营模式。
结果由一个或多个输出启用的利益相关者的结果。
输出活动的有形或无形交付。
外包外部供应商提供以前在内部提供的产品和服务的过程。

237
ITIL 4 基金会
合作伙伴和供应商服务管理的四个维度之一。它包括组织与参与服务设计、开发、部
署、交付、支持和/或持续改进的其他组织的关系。
伙伴关系两个组织之间的关系，涉及密切合作以实现共同的目标。
性能衡量系统、人员、团队、实践或服务所实现或交付的内容的度量。
飞行员在实时环境中具有有限作用域的服务的测试实现。
计划确保共享了解组织所有四个维度和所有产品和服务的愿景、现状和改
进方向的价值链活动。
政策正式记录管理层的期望和意图，用于指导决策和活动。
投资组合管理实践确保一个组织拥有适当的方案、项目、产品和服务组合，以在其资金
和资源限制范围内执行其战略的做法。
实施后审查实施变更后进行审核，以评估成功并发现改进机会。
实践一组组织资源，专为执行工作或完成目标而设计。
问题一个或多个事件的原因或潜在原因。
问题管理实践通过识别事件的实际和潜在原因，并管理解决方法和已知错误来减少
事件的可能性和影响。
程序执行活动或流程的有文档记录的方式。
过程一组相互关联或交互的活动，将输入转换为输出。进程需要一个或多
个定义的输入，并将其转换为定义的输出。进程定义操作的顺序及其
依赖项。

237
ITIL 4 基金会
产品旨在为使用者提供价值的组织资源的配置。
生产环境请参阅实时环境。
程序一组相关的项目和活动，以及为指导和监督它们而创建的组织结构。
项目为根据商定的业务案例交付一个或多个输出（或产品）而创建的临时
结构。
项目管理实践确保组织的所有项目都成功交付的实践。
快速获胜预期在短期内提供投资回报的一项改进，成本和工作量相对较小。
记录说明取得的成果并提供所开展活动的证据的文件。
恢复在发生故障后将配置项返回到正常操作的活动。
恢复点目标（RPO）必须还原活动使用的信息，以使活动在恢复时能够运行。
恢复时间目标（RTO）服务中断后可接受的最长时间段，在业务功能不足之前可能会消失，
严重影响组织。
关系管理实践在战略和战术层面建立和培育组织与其利益攸关方之间的联系的做
法。
释放可供使用的服务或其他配置项或配置项的集合。
发布管理实践使新的和更改的服务和功能可供使用的做法。
可靠性产品、服务或其他配置项在指定时间段内或周期数内执行其预期功能
的能力。

237
ITIL 4 基金会
请求目录服务目录视图，提供有关现有和新的服务的服务请求的详细信息，可
供用户使用。
更改请求（RFC）用于启动更改控制的拟议更改的说明。
分辨率解决事件或问题的行动。
资源执行活动或实现目标所需的人员或其他实体。
退休永久退出产品、服务或其他配置项的行为。
风险可能造成伤害或损失，或使目标更难实现的可能事件。也可以定义
为结果的不确定性，并可用于测量积极结果和负结果的概率。
风险评估识别、分析和评估风险的活动。
风险管理实践确保组织了解并有效处理风险的实践。
服务通过促进客户想要实现的结果来实现价值共同创造，而客户无需管
理特定的成本和风险，从而实现价值共同创造。
服务体系结构组织提供的所有服务的视图。它包括服务之间的交互，以及描述每
个服务的结构和动态的服务模型。
服务目录有关服务提供商所有服务和服务产品（与特定目标受众相关）的结
构化信息。

237
ITIL 4 基金会
服务目录管理实践提供所有服务和服务产品单一来源的一致信息，并确保相关受众能
够获得这些信息。
服务配置管理实践确保在需要时提供有关服务配置和支持它们的配置项的准确可靠的
信息的做法。
服务消耗组织为使用服务而执行的活动。它包括管理使用服务所需的消费者
资源、用户执行的服务操作以及接收（获取）商品（如果需要）。
服务连续性管理实践确保在发生灾难时将服务可用性和性能保持在足够的水平。
服务设计实践设计适合目的、适合使用、且可以由组织及其生态系统提供的产品
和服务的实践。
服务台服务提供者与其所有用户之间的通信点。
服务台实践捕获事件解析和服务请求的需求的做法。
服务财务管理实践通过确保有效利用组织的财政资源和投资，支持组织的服务管理战
略和计划的做法。
服务级别一组可测量参数，定义预期或实现的服务质量。
服务级别协议（SLA）服务提供商与客户之间的书面协议，用于标识所需的服务和预期的服
务级别。
服务级别管理实践为服务性能设置明确的基于业务的目标，以便根据这些目标对服务的
交付进行适当的评估、监视和管理。

237
ITIL 4 基金会
服务管理一组专门的组织功能，以服务的形式为客户创造价值。
服务提供一个或多个服务的描述，旨在满足目标使用者群体的需求。服务产品
可能包括商品、资源和服务操作。
服务所有者负责提供特定服务的角色。
服务组合由组织在其整个生命周期中管理的一整套产品和服务。
服务提供商组织在服务关系中为向使用者提供服务而执行的角色。
提供服务组织为提供服务而执行的活动。它包括资源管理、配置为提供服务、
用户访问这些资源、完成商定的服务操作、服务性能管理和持续改
进。它还可能包括货物供应。
服务关系服务提供商和服务使用者之间的合作。服务关系包括服务提供、服务
消耗和服务关系管理。
服务关系管理由服务提供商和服务消费者共同开展的活动，以确保基于商定和可用
的服务产品持续共同创造价值。
服务请求来自用户或用户授权代表的请求，该请求启动已作为服务交付正常部
分商定的服务操作。
服务请求管理实践通过以有效和用户友好的方式处理所有预定义、用户启动的服务请求
来支持商定的服务质量。
服务验证和测试实践确保新的或更改的产品和服务满足定义的要求的做法。

237
ITIL 4 基金会
服务价值系统一个模型，表示组织的所有组件和活动如何协同工作以促进价值创
造。
软件开发和管理实践确保应用程序满足利益相关者在功能、可靠性、可维护性、合规性和
可审计性方面的需要的实践。
采购规划和从特定源类型获取资源的活动，可以是内部或外部、集中或分
布式，以及开放或专有。
规范产品、服务或其他配置项属性的文档描述。
赞助授权服务消耗预算的人员。还可用于描述为计划提供财务或其他支持
的组织或个人。
利益相关者对组织、产品、服务、实践或其他实体感兴趣或参与的个人或组织。
标准以协商一致方式制定并由认可机构批准的文件，其中规定其主体的共
同和重复使用、强制性要求、准则或特征。
标准变更低风险、预先授权的更改，已广为人知且记录完好，无需额外授权即
可实施。
地位实体在给定时间可以具有的特定状态的说明。
战略管理实践制定一个组织的目标，并通过实现这些目标所需的行动方针和分配必
要的资源的做法。
供应商负责提供服务的利益相关者。

237
ITIL 4 基金会
供应商管理实践确保对组织的供应商及其绩效水平进行适当管理以支持提供无缝质量
的产品和服务的做法。
支持团队负责维护正常操作、解决用户请求以及解决与指定产品、服务或其他
配置项相关的事件和问题的团队。
系统为达到一个或多个所述目的而组织和维护的交互元素的组合。
系统思维整体分析方法，侧重于系统组成部分随时间以及在其他系统上下文中
工作、相互关联和交互的方式。
技术债务通过选择解决方法而不是需要更长的时间的系统解决方案而累积的总
的重新工作积压工作。
测试环境为测试产品、服务和其他配置项而建立的受控环境。
第三方组织外部的利益相关者。
吞吐量产品、服务或其他系统在给定时间段内执行的工作量的度量。
交易由两个或多个参与者或系统之间的交换组成的工作单元。
用例一种使用实际实际方案来定义功能要求和设计测试的技术。
用户使用服务的人。
实用产品或服务为满足特定需求而提供的功能。
效用要求由客户定义且对特定产品独有的功能要求。
验证确认系统、产品、服务或其他实体是否符合商定的规范。

237
ITIL 4 基金会
价值感知到的东西的好处、有用性和重要性。
价值流组织承诺为消费者创建产品和服务并交付产品和服务的一系列步骤。
值流和流程服务管理的四个维度之一。它定义了实现商定目标所需的活动、工作
流、控制和程序。
视觉一个组织将来想成为什么样的人。
保修保证产品或服务满足商定的要求。
保修要求通常，非功能性需求被捕获为关键利益相关者和其他实践的输入。
瀑布法线性和顺序的开发方法，每个阶段开发目标不同。
工作指令要执行活动应遵循的详细说明。
解决方案减少或消除尚未提供完整解决方案的事件或问题的影响的解决方案。
某些解决方法降低了发生事件的可能性。
劳动力和人才管理实践确保组织拥有具有适当技能和知识的合适人员，并发挥正确的角色来
支持其业务目标。

237
ITIL 4 基金会

237

ITIL4-foundation Book中文翻译版【推荐】

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ITIL4-foundation Book中文翻译版【推荐】

Uploaded by

Copyright:

Available Formats

乐迪学堂 独家整理

⚫ 让读者了解 ITIL 4 服务管理框架，以及 ITIL 4 服务管理框架如何演变为

⚫ 解释服务管理框架的概念，以支持参加 ITIL 4 基础考试的考生

Axle 租车公司是一家全球性公司，总部设在西雅图。Axle 成立于 10 年前，目前在欧

Henri 在 ITIL 和 ITSM 方面拥有强大的背景，这意味着他重视 ITIL 认证，他的招聘政

Henri 渴望了解他的团队如何重新定义租车体验，并确保 Axle 租车是新客户和现有客户

以下是 Axle 租车的四名关键员工：

⚫ 亨利是 Axle 租车公司的新首席信息官。他是一位成功的企业高管，他准备

⚫ Su 是 Axle 租车产品经理，具有旅行经验，过去五年来一直为 Axle 工

⚫ Radhika 是 Axle 租车 IT 业务分析师，她的职责是了解 Axle 租车员工和

⚫ Marco 是 Axle 租车 IT 交付经理。他受流程驱动，并不断引用 ITIL 框

1.1 现代世界中的 IT 服务管理

服务管理也在不断发展，ITIL 也是如此，ITIL 是世界上最广泛采用的 IT 服务管理

30 多年来，ITIL 一直以指导、培训和认证计划引领 ITSM 行业。ITIL 4 通过在客户体

1.3 ITIL 4 框架的结构和优势

ITIL 4 框架的关键组件是 ITIL 服务价值系统 （SVS） 和四维模型。

1.3.1 ITIL SVS

ITIL SVS 表示组织的各个组件和活动如何协同工作，通过支持 IT 的服务促进价值创造。

ITIL SVS 的核心组件包括：

| ITIL 服务价值链 l ITIL 实践

l ITIL 指导原则 l 治理 l 持续改进。

ITIL 实践进一步增强了服务价值链的灵活性。每个 ITIL 实践都支持多种服务价值链活动，

ITIL SVS 还包括治理活动，使组织能够持续调整其运营与管理机构制定的战略方向保持一

ITIL SVS 的每个组件都得到持续改进的支持。ITIL 为组织提供了一个简单而实用的改进模

为了确保对服务管理采取整体方法，ITIL 4 概述了服务管理的四个维度，从中应考虑 SVS

通过赋予四个维度中每个维度适当的关注度，组织可确保其 SVS 保持平衡和有效。

ITIL 故事：CIO 对 Axle 的愿景

自 10 年前创建 Axle 以来，服务期望发生了变化。客户希望通过应用和在线服务立即访

⚫ 价值的性质 l 所涉及的利益相关者的性质和范围，以及 如何通过服

ITIL 的故事：Axle 的服务

苏：在 Axle，我们的服务是旅行体验。我们为客户提供这项服务，为他们和 Axle 创造价

ITIL 故事：Axle 的客户

以下是 Axle Car Hire 的三个常客，随着故事的展开，您将遇到这些客户：

"价值"一词定期用于服务管理，它是 ITIL 4 的一个关键重点;因此必须明确界定。

亨利：我们还得考虑如何为 Axle 创造价值。当我们出租汽车时，我们得到的最明显的价值

在 ITSM 最传统的观点中，提供商组织被视为公司的 IT 部门，而公司其他部门或其他职

⚫ 首席信息官 （CIO） 和主要通信团队成员在分析公司员工的移动通信要

⚫ 首席财务官 （CFO） 在审核拟议的服务安排并通过谈判批准合同成本

⚫ 员工（包括 CIO、CFO 和通信团队成员）在根据商定的合同订购、接收和

ITIL 故事：Axle 的服务消费者

马可：赞助商是授权预算的人。对于 Axle 租车，我们的赞助商包括来自"燃料食品"的

Henri：像 Yoshi 和 Faruq 这样的个人服务消费者批准他们自己的预算，定义他们的租车

服务管理和 ITIL 的一个关键重点是组织通过服务关系与其消费者共同创造价值的方式。除

关于不同利益相关者价值管理的详细建议，请参阅其他 ITIL 4 出版物和补充材料（如

ITIL 故事：Axle 的服务产品

Su： Axle 的服务服务包括租车和我们提供的各种选项，以满足不同的旅行需求。这些产

访问资源 所有权不会转让给消费者 访问移动网络或网络存储

服务操作 由服务提供商执行以满足消 用户支持

⚫ 用户获得这些资源，实现 商定的服务操作，即 服务级别管理和持续改

ITIL 故事：Axle 的服务关系

Henri： Axle 与许多服务提供商和内部和外部消费者建立了服务关系。向 Axle 提供的一

这些只是 Axle 具有的服务关系的几个示例。整个组织还有更多。

服务关系只有在具有比负面效应更积极的影响时才被视为有价值的，如图 2.2 所示。

提供商有责任代表消费者管理详细的风险水平（参见第 5.1.10 节）。这应该根据对消费者

⚫ 清楚地传达适用于服务的关键成功因素 （CSF） 和约束

苏：Axle 最近的客户满意度调查一直显示 low 汽车清洁度评级较低。这阻碍了我们客户的

Henri： Axle 租车公司决定将所有车辆的清洁外包给服务提供商。以前，我们的车队由内

用户将对我们的汽车的清洁度感到满意 Axle 将失去提供汽车清洁服务的机会

Axle 不再需要维护自己的清洁设施 Axle 需要支付清洁公司

清洁过程中汽车损坏的风险将从 Axle 上清 Axle 将失去提供汽车清洁服务的机会

用户将对我们的汽车的清洁度感到满意 Axle 将严重依赖外部清洁公司，其员工将

Henri：克雷格的清洁服务只是 Axle 客户体验的一个组成部分。清洁汽车是我们整体服务

Axle 和 Craig 的清洁工作一起完成清洁计划，重点是高峰时段的汽车清洁周转时间。

这四个维度表示与整个 SVS 相关的视角，包括整个服务价值链和所有 ITIL 实践。四个维

乐迪学堂独家整理

ITIL 4 框架的关键组件是 ITIL 服务价值系统（SVS）和四维模型。

⚫ 价值的性质 l 所涉及的利益相关者的性质和范围，以及如何通过服

⚫ 首席信息官（CIO）和主要通信团队成员在分析公司员工的移动通信要

⚫ 首席财务官（CFO）在审核拟议的服务安排并通过谈判批准合同成本

访问资源所有权不会转让给消费者访问移动网络或网络存储

服务操作由服务提供商执行以满足消用户支持

⚫ 用户获得这些资源，实现商定的服务操作，即服务级别管理和持续改

⚫ 清楚地传达适用于服务的关键成功因素（CSF）和约束

商品供应供应的货供应商客户正式供应合同/ 计算机和电

服务交付提供的服供应商客户正式协议和灵活云

服务伙伴关共同创建提供商与客提供商与客户之共同目标、通用员工入职（人

⚫ 为什么消费者使用服务 l 服务帮助他们做什么，服务如何帮助他们实

现目标，即成本/财务后果对服务使用者的作用，以及服务消费者面临