文档更改服务管理实践 - 11 服务级别

由 superadmin 于 2024/12/25, 15:40 最后修改

从版本< 6.1 >

由superadmin编辑
在2021/12/16, 12:28上

到版本

由superadmin编辑
在2021/12/16, 12:33上

< >

修改评论该版本没有评论

Raw
已渲染

Summary

Page properties (3 modified, 0 added, 0 removed)

Details

Page properties

标题

...	...	@@ -1,0 +1,1 @@
	1	+ITIL 4服务级别管理实践

父

...	...	@@ -1,0 +1,1 @@
	1	+ITIL 4 服务设计实践中文版.WebHome

Content

@@ -1,0
          +1,1066 @@
++**申明：**
++
++本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众
++多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信
++公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
++
++
++请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
++
++
++本文档翻译工作参与人员：
++
++翻译：卢曦
++
++审校：庄严
++
++
++总审： 长河
++
++审核： 李锐
++
++统筹： 常宏
++
++
++
++----
++{{box cssClass="floatinginfobox" title="**Contents**"}}
++{{toc/}}
++{{/box}}
++= **1. 关于本文档** =
++
++----
++
++本文档为服务级别管理实践提供了实践指南。内容分为五个主要部分，包括：
++
++* 实践的一般信息
++* 实践的流程和活动以及其在服务价值链中的作用
++* 实践中涉及的组织和人员
++* 支持实践的信息和技术
++* 实践中关于合作伙伴和供应商的考虑事项
++
++
++== **1.1 ITIL®4 资格认证计划** ==
++
++本文档中的部分内容可作为以下教学大纲的一部分以供检查：
++
++* ITIL专家 创建、交付和支持
++* ITIL专家 驱动利益干系人价值
++
++详细信息请参考各部分教学大纲。
++
++
++
++----
++
++= **2. 基础信息** =
++
++
++== **2.1 目标和描述** ==
++
++|**关键信息**
++|服务级别管理实践的目的是为设定清晰的基于业务的服务级别目标，同时确保针对这些目标对服务交付进行适当的评估、监测和管理。
++
++
++服务级别管理实践有助于建立和管理服务提供者和服务消费者之间针对双方所有关键利益相关者的服务质量共享视图。此共享视图通常在协议文档中描述，该文档可以是不同正式程度的。这适用于从初始到目前为止的期望和实际服务质量中，并涵盖了整个服务关系中的服务正在提供的和建议的价值。服务级别管理实践还包括了实际服务质量的监测和评估，以及服务和协议的持续改进。
++
++图2.1 说明了实践的关键活动。
++
++(% style="text-align:center" %)
++[[image:1639628606263-229.png]]
++
++图2.1 服务级别管理实践的关键活动
++
++
++== **2.2 术语和概念** ==
++
++|**定义：服务质量**
++|服务能够满足规定和潜在需求的特征和特性总和。
++
++为了管理服务的质量，组织通常定义指标，这些指标正式定义了具体服务的服务级别。
++
++
++|**定义：服务级别**
++|用于定义预期的或已实现的服务质量的一个或多个指标。
++
++要定义和管理服务级别，通常需要约定相关的指标和目标值，以及已实现服务级别的度量、评价、报告和改进的方法。这通常通过使用服务级别协议（SLA）来完成。
++
++
++|**定义：服务级别协议**
++|服务提供者和客户之间的一种书面协议，它确定了所需的服务以及预期的服务级别。
++
++
++注：SLA可以有不同的形式和正式程度，客户在其定义中的参与程度也可以因情况而异。从广义上讲，SLA可以定义为：
++
++对目标服务级别及其监测、度量和报告方法的描述，服务提供者用来监测和管理其服务质量。
++
++它也可以称为服务级别的公共（或外部）规范，因为它通常被用来和客户以及用户沟通。这并不意味着客户总是参与服务级别的定义。在大规模交付和消费的情况下，此时服务以预先定义的、开箱即用的方式交付给数千或数百万消费者，客户通常必须接受服务提供者定义的服务级别，或者根本不使用服务。
++
++在某些情况下，并非所有的服务质量特性都可以通过规范的方式来约定、度量和控制。这意味着所控制的服务级别的范围总是小于它需要规范的服务质量范围。可以通过收集反馈信息来获得在服务级别中没有包含的服务质量的相关方面。这就增加了一个主观的视角来验证服务的可度量的特性。结合服务级别的度量结果与相关利益干系人的充分反馈，将提供更全面的服务质量视图，并有助于为服务消费者定义和共创价值。它还有助于防止所谓的服务报告西瓜效应，即所有指标从外部看起来都是“绿色”，而从在内部看，消费者对服务的感知是“红色”。
++
++为确保服务级别管理实践以价值为中心，重要的是将可度量的服务级别的定义和控制与相关反馈的收集和分析结合起来。当客户没有参与服务级别定义时，这点就变得特别重要。
++
++
++=== **2.2.1 功用和功效** ===
++
++|**定义：功用**
++|产品或服务为满足特定的需要而提供的功能。功用可以概括为“ 服务是做什么的”，并且可以用来确定服务是否“ 符合目的”。要拥有功用，服务必须支持消费者的绩效，也需要移除来自消费者的约束。许多服务都需要达成这两点。
++
++
++|**定义：功效**
++|确保产品或服务将满足约定的需求。功效可以概括为“ 服务如何执行”，并且可以用来确定服务是否“适合使用”。功效通常与满足服务消费者的需要相一致的服务级别相关。这可能基于正式的协议，也可能是基于市场营销的信息或品牌形象。功效通常解决诸如服务可用性、容量、安全级别和连续性等领域。如果满足所有已定义和约定的条件，可以说服务提供了可接受的保证，或者说“ 功效”。
++
++
++从定义中可以假设服务质量（和服务级别）仅指功效和功效需求。事实并不是如此，服务质量和服务级别的管理应该是整体的，并且聚焦价值的。为此，所有服务相关的特性都应该被管理，包括相关的度量指标，感知的领域和反馈。将服务的职能型管理和非职能型管理进行分开管理的习惯（从定义需求到评估质量）来自于将开发和运维团队进行分离。这些特性和团队的分离往往会导致对服务质量的支离破碎和形式化的理解。
++
++总而言之，服务质量同时包含职能型和非职能型的服务特征，因此服务级别也应如此。
++
++
++=== **2.2.2 服务的财务可行性** ===
++
++通常，将服务提供者的责任限定在已商定的服务级别中，而不在隐含或预期的服务质量中。然而，只有不断地达成商定的服务级别，并且最重要的是，让客户和用户感到满意，才能实现可持续的服务关系。该满意度以其服务体验为基础，并包括已达成的和暗示的服务质量。因此，服务提供者通常旨在超越已约定的服务级别，以确保他们的用户和客户都很满意。然而，服务提供通常是基于已约定的服务级别进行预算的，而更好的满足了服务级别会导致提供者的额外费用。
++
++
++为了维持有效的服务关系，服务对于服务提供者和服务消费者都应在财务上是可行的。这通常是发起人的关键关注点：
++
++* 服务消费的发起人（定义见ITIL Foundation：ITIL 4版本）要求为服务消费者提供服务的最优价格。
++* 服务提供的发起人（对于服务提供者来讲的一个预算授权的角色）需要一个最优的服务提供成本。
++
++这些角色可以由不同的人在不同的场景中执行：
++
++当内部服务提供者得到了组织资助时，供应和消费的发起人就是IT 预算的所有者。当向外部消费者提供商业服务时，服务提供预算通常由服务提供者一侧的发起人拥有，而服务消费的发起人是消费者方的授权人。应该注意的是，尽管这些是发起人最常见的角色，但其他的角色组合也是可能的。
++
++无论服务关系模型如何，服务级别管理实践都能通过管理客户和用户期望，并满足发起人要求的服务级别，从而有助于服务的财务可行性做。它还提供有关约定的服务级别和预期的服务质量之间的预期差距，以及是否需要专用的预算来解决此差距等信息，以支持服务设计和编制预算。
++
++
++
++== **2.3 范围** ==
++
++服务级别管理实践的范围包括：
++
++* 与客户就预期的、已约定的和实际的服务质量及其服务体验进行策略层面和运营层面的沟通，包括收集反馈。
++* 与客户协商、制定和维护SLA
++* 理解服务的设计和架构，以及服务与其他配置项之间的依赖关系
++* 持续回顾达成的服务级别与商定的和预期的服务级别的差异
++* 启动服务改进，包括对协议、监控和报告的改进。
++
++尽管许多活动和职责领域与服务级别管理实践紧密相关，但它们并不包含在其中。表2.1 中列出了这些内容，以及对可以找到它们的实践的引用。重要的是要记住，ITIL实践只是价值流环境中使用的工具的集合；根据情况，应将它们组合在一起。
++
++表2.1在其他实践指南中描述的与服务级别管理实践相关的活动
++
++(% style="width:611px" %)
++|(% style="width:421px" %)与客户和发起人的战略沟通|(% style="width:188px" %)关系管理
++|(% style="width:421px" %)与用户进行运营沟通|(% style="width:188px" %)服务台
++|(% style="width:421px" %)与供应商和合作伙伴建立和管理合同|(% style="width:188px" %)供应商管理
++|(% style="width:421px" %)识别和记录服务|(% style="width:188px" %)服务目录管理
++|(% style="width:421px" %)产品和服务的设计|(% style="width:188px" %)服务设计
++|(% style="width:421px" %)为现有功用和功效之外的服务分析创新机会和新需求|(% style="width:188px" %)业务分析
++|(% style="width:421px" %)为商业服务交付而设计和控制财务模型|(% style="width:188px" %)服务财务管理
++|(% style="width:421px" %)持续改进的管理和实施|(% style="width:188px" %)持续改进
++|(% style="width:421px" %)实施产品和服务的变更|(% style="width:188px" %)(((
++变更使能
++
++项目管理
++
++其他实践
++)))
++|(% style="width:421px" %)监控技术、团队和供应商绩效|(% style="width:188px" %)监控和事态管理
++
++
++
++== 2.4 **实践成功因素** ==
++
++实践成功因素（PSF）不仅仅是一项任务或实现价值；它包括所有服务管理四维模型的组件。在一个实践中的实践成功因素PSF的活动和资源性质可能不同，但它们在一起可以确保实践的有效性。
++
++|**定义：实践成功因素**
++|实践的一个复杂的功能组件，是完成其目的所必须的实践。
++
++
++服务级别管理实践包含以下PSFs：
++
++* 与客户建立目标服务级别的共享视图
++* 通过收集、分析、存储和报告已识别服务的相关指标，监督组织如何满足定义的服务级别
++* 执行服务回顾，以确保当前的一系列服务继续满足组织及其客户的需要
++* 捕获并报告改进机会点，包括针对已定义的服务级别的绩效和针对利益干系人满意度。
++
++
++=== **2.4.1 与客户建立目标服务级别的共享视图** ===
++
++在不同的服务关系模型中，与客户的交互差异很大；例如：在内部和外部服务条款之间；在大型组织之间和个体之间；在定制化的服务和开箱即用服务之间。后者对与客户建立目标服务级别的共享视图的方法的影响最大。
++
++
++|**服务：定制化还是“开箱即用？**
++|“定制化”的服务意味着在服务交付和消费开始之前，就应该就目标服务级别达成一致，这一点具有很大的灵活性。另一方面，“ 开箱即用” 服务具有一个或多个预定义的服务级别可供选择，没有太多的灵活性。
++
++
++当服务提供者和客户建立定制化的服务的共享视图时，他们通常会讨论客户的需要和期望，旨在创建一个满足所有利益相关者需求的服务规范，其中包括：
++
++* 在消费者一侧的服务消费的客户、用户和发起人
++* 在提供者一侧的服务交付团队和服务提供发起人。
++
++如果正在讨论的服务尚未创建，则应该涉及服务架构师和服务设计人员以及业务分析人员和服务开发团队。但是，如果已经设计了服务并且当前可供客户使用，则可能不需要这些团队。
++
++通常，从消费需要的概述到约定的SLA，所讨论的服务质量范围随着每一步流程的执行而缩小。例如：
++
++* 当客户表达对服务提供者的期望时，他们仅代表组织的需要。
++* 当客户和服务提供者代表就服务需求达成一致（基于沟通后的期望）时，所讨论的范围再次被缩小。
++* 最终，在服务提供者创建了一个服务级别的描述之后，该服务级别可以按照所需的保证和义务进行交付，这样范围会变得更加狭窄（图2.2）。
++
++对于开箱即用服务，可用的服务级别通常由服务提供者根据市场和业务智能进行预先定义。例如：
++
++* 服务提供者的营销团队和业务分析团队对消费者的需要进行了探索和分析。这些可能不同于任何一个给定消费者的需求。
++* 服务提供者的架构师和设计师基于对消费者的需求的假设，创建了服务和支持服务的质量规范。这通常不能满足消费者的所有被识别的需求。
++* 规范的一些特性随后作为服务产品向潜在的消费者公布（有时具有不同的服务级别，例如金牌，银牌，铜牌等）
++* 最后，在正式达成协议的SLA（图2.3）中确认了已发布产品的某些组件。
++
++定义为已商定服务级别的所有度量指标应明确清晰的度量和报告方法。对于定制化服务，定义此方法可以成为初始目标服务级别协商的一部分。
++
++对于开箱即用的服务，在服务设计期间通常预先定义了可用的度量和度量方法，并将度量和报告工具集成到服务中。
++
++术语“ 服务级别”可以用多种方式定义，具有不同的正式程度。然而，可能要对服务质量的关键方面进行讨论并协商一致。表2.2列出了这些方面，并提供了可能会包含在商定（或暗示）的服务级别中的度量的示例。
++
++
++(% style="text-align:center" %)
++[[image:1639628685393-483.png]]
++
++图2.2 定制化服务：从客户需求到SLA
++
++(% style="text-align:center" %)
++[[image:1639628697903-771.png]]
++
++
++图2.3 开箱即用服务：从消费者需求到SLA
++
++
++表2.2 服务质量的关键方面以及服务级别度量标准的示例
++
++(% style="width:667px" %)
++|**服务质量方面**|(% style="width:375px" %)**服务级别指标示例**
++|功能性|(% style="width:375px" %)(((
++可用功能的完整性
++
++功能操作的正确性
++
++集成功能的索引
++)))
++|可用性|(% style="width:375px" %)(((
++最大服务中断时间
++
++不可用的总时间
++
++可用性百分比
++
++系统故障平均间隔时间（MTBSI）
++)))
++|绩效|(% style="width:375px" %)(((
++服务行动执行间隔时间
++
++响应时间
++
++与执行和响应时间相关的事件数量和百分比
++
++服务吞吐量
++)))
++|及时性|(% style="width:375px" %)延期完成的服务数量和百分比
++|用户支持|(% style="width:375px" %)(((
++支持请求处理的及时性
++
++支持请求处理的质量
++)))
++|准确性|(% style="width:375px" %)在数据和信息中的错误数量和影响
++|用户体验(UX)|(% style="width:375px" %)(((
++用户错误的数量和频率
++
++返回上一步的次数和频率（例如，后退按钮）
++
++帮助请求的界面数量和频率
++
++中断的服务操作的数目和百分比（退出界面而没有
++
++完成服务动作）
++)))
++
++
++在某些情况下，组织在所测量的服务级别的范围中包括了对服务消费产出结果的度量。可以通过基于结果的服务功能描述和引入新的度量方式来完成。这种方法需要服务提供者和服务消费者之间的紧密协作关系。
++
++尽管尽了最大的努力来捕获并满足期望，但约定的服务级别通常不同于服务应该满足的期望，有时甚至是相差甚远。通常情况下不可能实现的一种理想的情况，即所有利益相关者事前就所有事项能够达成一致和满意。
++
++尽管如此，对于服务关系的成功非常重要的是，服务提供者和消费者对服务质量具有共同的看法。可以通过应用ITIL 指导原则来确保，如表2.3所示。请注意，指导原则应该应用于整个服务级别管理实践，因此表2.3仅作为示例。
++
++
++表2.3 ITIL 指导原则在建立目标服务级别共享视图的应用
++
++|**ITIL 原则**|**应用**
++|聚焦价值|聚焦于服务消费者组织和用户体验的结果，而不是技术细节和相关度量标准。
++|从你所处的地方开始|(((
++根据你以前的经验，以及服务提供者和使用者之间的当前关系来达成协议
++
++如果基于历史关系有充分的信任，协议关注的就是成果和隐含的承诺，而不是正式的义务。如果没有以前的经验，请考虑使用行业基准。
++)))
++|基于反馈的过程迭代|要承认从一开始并不是所有的与服务质量相关的特性能够被理解和达成，并且期望和需求将持续的变化。应该基于达成情况和反馈对已达成的服务级别进行持续的评审。
++|协作和促进可视化|在讨论中包含利益相关方（例如：关键用户）。与会受到服务级别影响的人讨论已达成的服务级别，并告知他们任何限制，以建立现实的期望。同时，提供足够的运营透明度，以促进所有权意识和管理期望。
++|整体思考和工作|(((
++不要只关注一些服务的质量特性，而要确保涵盖功用和功效。考虑所需的结果以及服务产品的组件（货品/ 访问
++
++资源/ 服务操作）。
++)))
++|保持简单和实用|不要试图把每一件事情都放到协议中，而要着重于重要的事情以及可以实际度量和管理的事情。
++|优化和自动化|(((
++定期评审协议。优化他们的结构和内容以反映利益相关方的需要并删除多余的内容。考虑提供仪表盘和其他形式的
++
++自动化的SLA报告。
++)))
++
++
++=== **2.4.2 监督组织如何满足定义的服务级别** ===
++
++当对目标服务级别形成了共同理解，并且实际的服务交付已经开始时，服务提供者应该从三个主要方面控制服务的实际质量：
++
++* **达成服务级别 **根据达成一致的服务级别，基于达成一致的度量标准
++* **服务用户满意度 **基于临时反馈、交易反馈和定期调查
++* **服务的客户满意度 **基于定期的讨论、调查、或在社交媒体上实时了解客户情绪
++
++应该收集、存储、分析来自这些来源的数据，并将结果信息报告给提供者和消费者双方的利益相关者。这些可能包括（但不限于）：
++
++* 消费者利益相关者：
++** 发起人
++** 客户
++** 用户
++
++
++* 提供者利益相关者：
++** 负责客户关系的角色/团队
++** 产品和服务负责人
++** 服务交付团队的主管
++** 服务交付的供应商/合作伙伴代表
++
++提供服务达成信息的最常见方法是定期的报告，结合基于事件的服务中断和其他重要事件报告。然而，在某些情况下，最好能够提供一个接口来持续监控服务级别，并在适用的情况下监控用户满意度。这有助于增加服务质量的可视化和服务关系的透明度。
++
++服务级别仪表盘可用于向服务提供者团队、用户或客户展示服务的当前状况。请注意，所呈现信息的格式和范围可能会因目标受众而异。
++
++服务级别管理实践不包括设计和收集服务级别数据。这是通过服务设计、监控和事态管理和度量和报告实践来完成的。服务级别管理实践的重点是从收集到的数据中发现其意义。然后，重点是与利益相关者（从客户开始）沟通和审查数据。
++
++
++=== **2.4.3 执行服务评审** ===
++
++服务评审的目的是建立对服务所实现的服务质量和价值的共享视图，并在适当的情况下启动必要的服务改进。在商业服务关系中，服务评审也可以成为为消费者开具发票的先决条件或调整账单的触发器。
++
++服务评审可以基于时间间隔或基于事态。基于时间间隔的评审会在约定的时间段定期进行。时间间隔取决于诸如服务和先前的满意度之类的因素；自上次评审以来服务引入的更改数量；以及服务期望/需求发生变化的可能性。然而，基于时间间隔的服务评审通常不超过1次/月，并且如果间隔三个月以上进行，则无法有效地进行。
++
++基于事态的服务评审可能由以下事件触发，例如重大事件，服务中的重要变更请求或业务需要/服务需求中的变更。
++
++服务评审不需要作为正式会议进行；但是，这是处理定制化服务时的常用方法，尤其是提供给内部使用者的方法。对于开箱即用服务，服务评审可以采用许多不同的形式，尤其是提供给外部使用者的形式。
++
++例如，服务提供者可以每月执行评审服务提供给所有或某些消费者。该评审可以按特定的准则分组或单独进行选择。服务提供者将使用这些达成服务级别并来自于同一周期中的用户反馈、其他的类比数据（例如：服务提供者的成本和收入）对服务进行评估。同时，服务消费者将执行自己的服务评审，以评估服务消费在相同或不同时间段内的结果、成本和风险。服务提供者和服务消费者可以共享其服务评审的输入和输出。通常，最好是双方协调其评审以促进可持续发展的服务关系。
++
++不管评审采用哪种形式，以及它是联合发生还是单独发生，服务评审都是服务提供和消费中非常重要的部分。此外，评审的质量与服务的最终质量和利益相关方满意度之间具有直接的关系。除了它们提供的其他好处之外，服务评审也是服务改进机会的主要来源。
++
++
++=== **2.4.4 识别并报告改进机会** ===
++
++服务级别管理实践包括改进机会的识别和服务改进的启动。这些改进可能旨在纠正实际的服务质量（以使其符合约定的服务级别）或提升服务中的用户和客户满意度。还可以在实践的流程、工具或其他资源等方面进行改进，目的是改进实践和相关的客户体验。
++
++当改进由客户或用户反馈以及服务的联合评审触发时，确保改进计划、进度和结果对客户和用户的透明度非常重要。这符合ITIL协作和推广可视化的指导原则。
++
++所有与实践相关的改进都应遵循组织执行改进所使用的模型（有关持续改进模型的概述，请参见ITIL Foundation：ITIL 4 Edition的4.6节，有关更详细的指导，请参见持续改进实践指南）。大多数服务改进倡议的所有者是负责产品或服务的人员（例如，产品所有者或服务所有者）。
++
++确保不仅启动而且有效实施服务改进，这一点很重要。持续改进实践指南中描述了实现改进的方法。但是，至关重要的是在价值流的背景中使用多种实践，以保持持续改进服务的势头。
++
++
++
++== **2.5 关键度量指标** ==
++
++应该在每个实践所贡献的价值流的环境中评估ITIL实践的有效性或绩效。与任何工具的绩效是一样的，只能在应用环境中评估实践的绩效。
++
++但是，工具在设计和质量上可能会有很大差异，这些差异定义了工具的潜力或能力，以便根据其用途有效地使用。有关度量标准，关键绩效指标（KPI）以及其他有帮助的技术的指南，请参见度量和报告实践指南。
++
++服务级别管理实践的关键指标已映射到其实践成功因素PSF。它们可以用作价值流的环境中的关键绩效指标KPI，以评估实践对这些价值流的效果和效率的贡献。表2.4中给出了一些关键指标的示例。
++
++
++表2.4 实践成功因素的关键指标示例
++
++(% style="width:931px" %)
++|**实践成功因素**|(% style="width:480px" %)**关键度量标准**
++|与客户建立目标服务级别的共享视图|(% style="width:480px" %)(((
++SLA的客户满意度
++
++评审过期的SLA百分比
++
++没有达成目标级别的与服务相关的运营（事件、变更等）百分比
++)))
++|监督组织如何满足定义的服务级别|(% style="width:480px" %)(((
++使用服务级别度量方法定义的SLA百分比
++
++定期生成SLA报告的服务百分比
++
++服务级别监控的带仪表盘的服务/ SLA的百分比
++
++系统收集的满意度数据服务的百分比
++)))
++|执行服务评审|(% style="width:480px" %)(((
++服务报告中的客户满意度
++
++已计划了常规服务评审的服务/客户/ SLA的百分比
++
++服务评审的客户满意度
++)))
++|识别并报告改进机会|(% style="width:480px" %)(((
++最近三个月的平均服务质量指标/最近12个月的平均服务质量指标
++
++服务改进生产效率指标
++)))
++
++将度量数据正确汇总到复杂的指标中，将使数据更易于用于价值流的持续管理，以及用于服务级别管理实践的定期评审和持续改进。没有唯一的最佳解决方案。度量指标将基于服务战略的整体和组织的优先级，以及实践所贡献的价值流的目标。
++
++
++
++
++----
++
++= **3. 价值流和流程** =
++
++
++== **3.1 价值流贡献** ==
++
++像任何其他ITIL 管理实践一样，服务级别管理实践也有助于多个价值流。重要的是要记住，价值流永远不会由单个实践形成。服务级别管理实践与其他实践相结合，可以为消费者提供高质量服务。实践贡献的主要价值链活动是：
++
++* 计划
++* 契动
++* 改进。
++
++
++
++== **3.2 流程** ==
++
++每个实践可能包含一个或多个流程和活动，它们对于实现该实践的目的可能是必要的。
++
++图3.1 中显示了服务级别管理实践对服务价值链的贡献。
++
++
++(% style="text-align:center" %)
++[[image:1639628847306-108.png]]
++
++图3.1 服务级别管理实践对价值链的贡献的热力图活动
++
++
++|**定义：流程**
++|可将输入转换为输出的一组相互关联或交互的活动。流程接受一个或多个已定义的输入，并将它们转换为已定义的输出。流程定义动作的顺序及其依赖性。
++
++
++服务级别管理活动形成两个流程：
++
++* **SLA的管理**  此流程关注于协议及其生命周期。
++* **监督服务级别和服务质量** 此流程在充分了解服务质量的基础上确保持续服务改进。
++
++
++=== **3.2.1 SLA的管理** ===
++
++该流程包括表3.1中列出的活动，并将输入转换为输出。
++
++表3.1 SLA的管理的输入、活动和输出
++
++|**关键输入**|**活动**|**关键输出**
++|(((
++客户需求
++
++服务目录
++
++服务说明书
++
++服务模型和配置模型
++
++与供应商和合作伙伴的协议
++
++用户和客户反馈
++
++改进计划和注册
++
++财务信息
++)))|(((
++客户需求的定义
++
++可行性分析
++
++起草SLA
++
++SLA谈判
++
++SLA沟通和启用
++
++SLA 评审
++
++SLA延长
++
++SLA退出
++)))|(((
++服务级别需求（文件化的）
++
++SLA草案
++
++签署的SLA
++
++导入沟通
++
++变更请求
++
++撤销SLA
++)))
++
++
++图3.2 显示了流程的工作流图。
++
++(% style="text-align:center" %)
++[[image:1639628865867-178.png]]
++
++图3.2 SLA的管理的工作流
++
++
++该流程可能会有所不同，具体取决于所应用的服务或服务关系模型的类型。表3.2概述了这些变化。
++
++表3.2 SLA管理流程的活动
++
++(% style="width:1013px" %)
++|(% style="width:117px" %)**活动**|(% style="width:409px" %)**开箱即用的预定义服务**|(% style="width:486px" %)**定制化服务**
++|(% style="width:117px" %)定义客户需求|(% style="width:409px" %)这些基于现有的服务目录，并为服务级别明确定义的选项。客户为他们所需的服务选择最合适的选项/组合。来自面向客户的团队的服务提供者代表可以帮助客户浏览目录，以找到最相关的服务和服务级别。|(% style="width:486px" %)(((
++客户根据他们的业务需求沟通对服务的需求。他们可以参考现有目录，但通常要求不限于预定义的选项。
++
++来自面向客户的或业务分析团队的服务提供者代表，或产品和服务所有者都参与撰写需求的过程中
++)))
++|(% style="width:117px" %)可行性分析|(% style="width:409px" %)快速检查资源可用性以确认可以满足定义的需求。该活动遵循预定义的模式，并且可以完全自动化。这将导致服务需求的确认或必要的调整。|(% style="width:486px" %)(((
++可能需要对资源要求进行手动或半自动分析，以定义是否有可能满足这些需求以及成本。输出主要是估算的成本/价格和时间表。
++
++该分析应包括与服务提供者的供应商和合作伙伴达成的协议，以确保他们将支持所需的服务级别。
++)))
++|(% style="width:117px" %)起草SLA|(% style="width:409px" %)为客户起草标准的SLA，并且获得客户的评审和确认。它可以是完全自动化或很大程度上自动化。|(% style="width:486px" %)服务设计者、服务所有者和关系经理参与了基于可行性分析的协议的起草工作。建议将现有的服务和说明书用作构建块，但这项工作仍可能需要专家知识和大家的协作。
++|(% style="width:117px" %)SLA谈判|(% style="width:409px" %)客户评审SLA草案并接受其条款和条件或将其退回以进行分析。如果它被返回或者客户需求协助，则来自面向客户团队的服务提供者代表可以通过SLA草案指导客户并回答问题。在其他情况下，此活动可能是全自动的，客户接受SLA即表示是正式确认。|(% style="width:486px" %)客户和服务提供者代表（可能包括服务负责人，关系，经理，服务设计者等）讨论SLA草案并在需要时协商变更，或签字接受该草案。如果不接受，则将草稿退回到可行性分析中。对于可接受的版本，可能需要花费几次迭代才能达成共识。草案通过后，便得到各方的正式确认。
++|(% style="width:117px" %)SLA沟通和启用|(% style="width:409px" %)(((
++当双方确认SLA时，服务提供者会启动所需的变更和沟通，以使约定的服务可用于用户。变更和上线沟通可能是完全自动化的，也可能是大部分自动化的。
++
++这些变更和沟通是由服务级别管理实践触发的，但需要其他实践完成。
++)))|(% style="width:486px" %)(((
++当各方确认SLA时，服务提供者会启动所需的变更和沟通，以使约定的服务可用于用户。这可能需要对所有类型的提供者的资源进行大量的手动和自动更改，也可能需要对消费者的资源进行更改。在某些情况下，这将导致项目或方案的实现。
++
++这些变更和沟通由服务级别触发
++
++但需要其他实践完成。
++)))
++|(% style="width:117px" %)SLA 评审|(% style="width:409px" %)SLA的正式评审可以基于时间周期或事态进行触发（例如：客户请求，策略变更，服务评审或组织变革）。如果评审是基于时间的，并且客户和提供者都对SLA的内容以及条款和条件都感到满意，那么通常会确认SLA可以延长。如果客户的需求已经发生改变，则流程会基于重新定义的需求再次开始。最后，如果不再需要服务，则启动SLA退出。|(% style="width:486px" %)(((
++SLA的正式评审可以基于时间和事态进行触发（例如客户请求、策略的改变、服务评审或组织变革）。
++
++在最初的SLA协商之后进行的第一次评审可能会导致SLA措词的改进，不涉及服务的变化。不管措词是否更改，修订后的SLA都应延续。如果客户的需求已经被更改，则流程可能会以重新定义的需求再次开始。最后，如果不再需要服务，则启动SLA退出。
++
++SLA评审由客户（涉及发起人和关键用户）以及服务提供者代表执行
++
++（通常是服务所有者所有者和/或关系经理）。
++)))
++|(% style="width:117px" %)SLA延长|(% colspan="2" style="width:894px" %)(((
++如果SLA被确认可以延长，则可能需要进行沟通和更改（例如，延长与供应商的支持合同）。这可以是完全自动化或部分自动化的。
++
++这些变更和沟通由服务级别触发，但需要其他实践完成。
++)))
++|(% style="width:117px" %)SLA退出|(% style="width:409px" %)(((
++确认SLA退出后，服务提供者会启动所需的变更和沟通，以使用户无法使用约定的服务。更改和下线沟通可以是完全自动化或部分自动化。
++
++这些更改和沟通都是由服务级别管理实践所触发，但需要其他实践完成。
++)))|(% style="width:486px" %)(((
++确认SLA退出后，服务提供者会启动所需的变更和沟通，以使用户无法使用约定的服务。
++
++这可能需要对所有类型的提供者的资源进行大量的手动和自动更改，也可能需要对消费者的资源进行更改。在某些情况下，这将会导致一个退出的项目或项目集。这些变更和沟通由服务级别管理实践所触发，但需要其他实践完成。
++)))
++
++
++=== **3.2.2 对服务级别和服务质量的监督** ===
++
++该流程专注于服务级别的监控和评审，以及服务质量，而不是SLA文档。根据约定的服务级别信息的质量和完整性，SLA在此流程中得到广泛使用。然而，在某些情况下，协议比较高阶且含糊不清，并且服务质量的监控和评估是基于不太结构化和不太客观的数据。无论采用哪种方式执行流程，服务提供者都需要监测和分析测得的服务级别的数据以及用户和客户的反馈，以更好地了解服务质量。
++
++该流程包括表3.3中列出的活动，并将输入转换为输出。
++
++
++表3.3 监督服务级别和服务质量的输入，活动和输出
++
++|**关键输入**|**活动**|**关键输出**
++|(((
++服务绩效数据
++
++SLA
++
++用户和客户反馈，包括表扬和投诉
++
++服务改进计划
++)))|(((
++客户和用户满意度调查
++
++正在进行的服务质量监控
++
++服务评审
++
++服务质量报告
++)))|(((
++各种利益相关者的服务质量仪表盘和报告
++
++服务改进倡议
++)))
++
++
++图3.3 显示了流程的工作流程图
++
++(% style="text-align:center" %)
++[[image:1639628918675-923.png]]
++
++图3.3 监督服务级别和服务质量的工作流
++
++
++监督流程可能会有所不同，具体取决于所应用服务的服务级别目标的形式化级别。表3.4概述了这些变化。
++
++表3.4 服务级别和质量监督流程的活动
++
++(% style="width:1110px" %)
++|(% style="width:98px" %)**活动**|(% style="width:485px" %)**形式化程度高（详细的SLA）**|(% style="width:525px" %)**形式化程度低（潜在服务级别和概念协议）**
++|(% style="width:98px" %)客户和用户满意度调查|(% style="width:485px" %)服务提供者运行定期的满意度调查，收集用户和客户的反馈。各方可以正式商定调查的形式和规则。服务所有者和服务提供者的关系经理会评估反馈并将其包含在服务评审的范围中。|(% style="width:525px" %)(((
++服务提供者不断从用户和客户那里收集信息，以确保他们对服务感到满意，并识别改进的机会。调查包括非正式达成一致的或未形成文件的服务质量的各个方面。这有助于维护客户的期望的认识以及如何感知服务；此类信息应不断的仔细的评审。
++
++服务所有者和服务提供者的关系经理对反馈进行评估，并将其包含在服务评审的范围中。
++)))
++|(% style="width:98px" %)正在进行的服务质量监控|(% style="width:485px" %)(((
++服务提供者监控用于服务交付的资源的绩效（此工作涉及许多实践），并收集服务用于制定SLA的相关数据。同时，从用户和其他相关的利益相关者那里收集了即时反馈。服务所有者和服务提供者的关系经理会监控这些服务，以确保它们按照约定进行交付。
++
++某些服务质量数据可能以商定格式在仪表盘上供用户和客户使用，因此他们也可以监控服务质量。
++)))|(% style="width:525px" %)(((
++从用户和其他相关的利益相关者那里收集定期的即时反馈。它与资源绩效数据结合使用，并与服务提供者定义的技术规范和基准进行了比较。
++
++服务所有者、产品所有者和关系经理监控服务，以确保所有系统均按预期工作。
++)))
++|(% style="width:98px" %)服务评审|(% style="width:485px" %)(((
++服务所有者在指定的时间段内或依赖于事态进行服务质量的评审。服务所有者涉及服务提供者的利益相关者（产品所有者、技术团队所有者、关系经理、供应商管理人员等）以及可能包括客户。
++
++关键输出是内部服务质量报告和改进方案。
++
++客户进行服务质量的评审，涉及关键用户，以及可能包括服务提供者代表。
++)))|(% style="width:525px" %)(((
++主要的输出是给发起人和其他消费者利益相关方使用的服务价值报告，以及将与服务提供者讨论的改进倡议。这些倡议用作服务提供者的服务评审输入。
++
++对客户的服务和提供者的评审可能联合进行，并可能导致联合改进倡议。对于这两种形式的定制化服务来说，这都是很常见的，但是对于开箱即用的大众市场服务来说，这种情况相对较少。
++)))
++|(% style="width:98px" %)服务质量报告|(% style="width:485px" %)服务提供者向客户和其他同意的接收者生成报告和仪表盘，展示服务级别的成就和满意度的级别。这些是通过事先约定的方式沟通。|(% style="width:525px" %)(((
++服务提供者生成报告（有时是仪表盘），以证明满意度的级别和所选的服务级别的成就（在行业中普遍接受且与用户满意度相关）。
++
++这些是通过事先约定的方式沟通。
++)))
++|(% colspan="3" style="width:1107px" %)服务级别管理活动由服务提供者和服务消费者执行，如表3.2和3.4所述。他们可能涉及供应商和合作伙伴。这些活动还受到许多工具和技术的支持（有时甚至是完全自动化或部分自动化）。所有内容都将在以下各节进行描述。
++
++
++
++----
++
++= 4.组织和人员 =
++
++
++== **4.1 角色，能力和责任** ==
++
++ITIL实践没有描述实践管理的角色，例如实践所有者，实践主管或实践教练。相反，他们专注于特定于每个实践的专家角色。每个角色的结构和命名可能随着不同的组织有所不同，因此ITIL中定义的任何角色都不应被视为强制性的，甚至不建议使用。请记住，角色不是职务。一个人可以担任多个角色，一个角色可以分配给多个人。
++
++在流程和活动的环境中描述了角色。每个角色都具有基于表4.1中所示的模型的能力概况。
++
++
++表4.1 能力代码和描述
++
++|**能力代码**|**能力描述（活动和技能）**
++|L|**领导者** 决策、委派、监督其他活动，提供激励和动机以及评估结果
++|A|(((
++**管理员** 分配任务并确定优先级，保留记录，正在进行的报告，
++
++和启动基础改进
++)))
++|C|**协调员/沟通者** 协调多方，维护利益相关者之间的沟通，并开展宣传活动活动
++|M|**方法和技术专家** 设计和实施工作技术，编写程序文档，流程咨询，工作分析和持续改进
++|T|**技术专家** 提供技术（IT）专业知识，并进行基于专家经验的任务。
++
++负责所有服务级别管理和活动的角色通常是服务所有者。在服务级别管理实践的环境中此角色的能力配置文件为CLA，尽管每种能力的重要性在活动和活动之间是不同的。表4.2中列出了负责服务级别管理活动的角色示例以及相关的能力概况。
++
++
++表4.2 负责服务级别管理活动的角色示例
++
++|**活动**|**角色的职责**|**能力简介**|**具体技能**
++|(% colspan="4" %)SLA流程的管理
++|客户|(((
++客户需求的定义
++
++关系经理
++
++服务架构
++
++服务设计师
++
++服务所有者
++)))|CTA|(((
++对服务消费者的业务有很好的了解
++
++熟悉服务提供者的组合
++
++沟通和协调
++)))
++|产品所有者|(((
++可行性分析
++
++服务架构
++
++服务设计
++
++服务所有者
++
++供应商经理
++
++技术专家
++)))|TC|(((
++业务分析
++
++风险分析
++
++熟悉服务提供者组合
++)))
++|起草SLA|(((
++关系经理
++
++服务设计者
++
++服务所有者
++)))|CAT|(((
++熟悉服务提供者组合
++
++对产品有很好的了解，包括其架构和配置
++
++业务分析
++)))
++|SLA谈判|(((
++客户
++
++关系经理
++
++服务所有者
++)))|CA|(((
++沟通与谈判
++
++对产品有很好的了解，包括其架构和配置
++)))
++|SLA沟通和启用|(((
++产品所有者
++
++项目经理
++
++服务台代理
++
++服务所有者
++
++供应商经理
++)))|CAT|(((
++管理与协调
++
++沟通技巧
++)))
++|SLA 评审|(((
++客户
++
++关系经理
++
++服务设计者
++
++服务所有者
++)))|CA|(((
++分析能力
++
++对服务的理解
++
++对消费者背景的理解
++
++了解协议和期望
++)))
++|SLA延长|(((
++客户经理
++
++服务所有者
++
++技术专家
++)))|CA|(((
++协调与沟通
++
++了解协议和期望
++)))
++|SLA退出|(((
++客户经理
++
++服务所有者
++
++技术专家
++)))|CAT|(((
++对产品的理解，包括架构和配置
++
++理解协议
++
++管理和协调
++)))
++|(% colspan="4" %)监督服务级别和服务质量流程
++|客户和用户的满意度调查|(((
++客户经理
++
++产品所有者
++
++关系经理
++
++服务所有者
++)))|CA|(((
++对协议和期望的认识
++
++理解消费者的背景
++
++沟通
++)))
++|(((
++正在进行的服务质量
++
++监控
++)))|(((
++产品所有者
++
++服务所有者
++
++供应商经理
++
++技术专家
++)))|TC|(((
++分析能力
++
++了解协议和期望
++
++理解消费者的背景
++
++对产品深入的了解，包括它的架构和配置
++)))
++|Service评审|(((
++客户
++
++产品所有者
++
++关系经理
++
++服务所有者
++
++供应商经理
++
++技术专家
++)))|CT|(((
++分析能力
++
++对协议和期望的认识
++
++理解消费者的背景
++
++对产品的深入了解，包括其架构和配置
++
++沟通
++
++管理和协调
++)))
++|服务质量报告|(((
++客户
++
++关系经理
++
++服务所有者
++)))|CA|(((
++对协议和期望的认识
++
++理解消费者的背景
++
++沟通和谈判
++)))
++
++
++=== **4.1.1 服务所有者所有者的角色** ===
++
++服务级别管理实践中最重要的角色是服务所有者。
++
++服务所有者负责特定IT服务的端到端管理。服务所有者对特定服务的职责与基础技术组件、服务或能力所在的位置无关。
++
++服务的所有权对于服务管理至关重要。可以将此角色与产品所有者结合使用。在某些情况下，它与客户经理的角色或关系经理结合使用，特别是如果为特定的消费者或消费者团队创建或定制服务的情况下。
++
++服务所有者具有以下职责（与服务级别管理实践相关的职责以斜体表示）：
++
++* //确保持续提供的服务满足约定的客户需求//
++* //理解客户需求并将其转换为服务设计和SLA草案//
++* //确保与客户就服务相关的查询和问题保持一致和适当的沟通//
++* //协助定义服务模型并评估影响的新服务或对现有服务的变更//
++* //识别服务改进的机会，与客户讨论这些机会，并发起改进倡议//
++* //在服务价值流中与适当的利益相关者保持联系//
++* //征集所需的数据和报告以进行分析并促进有效的服务监控和绩效//
++* //代表跨组织的服务//
++* //理解服务（组件等）//
++* //作为处理与服务有关的重大事件的升级（通知）点//
++* //控制对服务的变更//
++* //进行服务的评审//
++* //确保有关服务的信息（在服务目录和其他记录中）是准确且最新的//
++* //协商与服务有关的SLA//
++* //识别改进的机会，并启动和推动对服务的改进。//
++
++服务所有者负责服务持续改进和影响服务的变更管理。服务所有者是所有底层ITIL实践中的主要利益相关方，这些实践实现并支持他们所拥有的服务。
++
++
++== 4.2 **组织结构和团队** ==
++
++尽管产品所有者、服务所有者、客户经理和关系经理的角色可以通过正式职位和职位描述得到支持，但服务级别管理实践的专用组织结构并不常见。一些组织创建了专门针对服务提供的战略和战术管理的委员会（服务委员会，服务质量委员会等）。这些委员会通常在较高级别上将服务评审包括在其议程中，例如“为私人客户提供的服务”或“在北美地区的服务”。同样，当组织向外部消费者提供服务时，他们可能会有专门的面向客户的团队（销售团队，客户经理等）专注于关系管理实践，并且经常大量参与服务级别管理活动。
++
++
++
++----
++
++= **5. 信息和技术** =
++
++
++== **5.1 信息交流：输入和输出** ==
++
++服务级别管理实践的效果基于所使用信息的质量。这包括但不限于以下信息：
++
++* 客户和用户
++* 服务（它们的架构和设计）
++* 合作伙伴和供应商，包括有关它们提供的服务合同和SLA信息
++* 规范服务提供的策略和需求
++* 服务的持续交付中，包括有关以下信息：
++* 服务的当前运营状态
++* 事件
++* 计划的和正在进行的变更
++* 用户和客户满意度
++* 服务交付的财务状况（成本、收入、过期账单等）
++* 服务改进的状态
++
++根据服务关系（内部或外部服务提供，定制的或开箱即用服务等），此信息可以采用各种形式。实践的关键输入和输出在第3节中列出。
++
++
++
++== **5.2 自动化和工具** ==
++
++在某些情况下，服务级别管理实践的工作可以大大受益于自动化（更多信息，请参见第3节）。在这种情况下，自动化是可能且有效的，它可能涉及表5.1中概述的解决方案。
++
++表5.1服务级别管理活动的自动化解决方案
++
++(% style="width:1067px" %)
++|(% style="width:278px" %)**流程活动**|(% style="width:239px" %)**自动化手段**|(% style="width:272px" %)**关键功能**|(% style="width:274px" %)**实践的效果上的影响**
++|(% colspan="4" style="width:1064px" %)SLA流程的管理
++|(% style="width:278px" %)定义客户需求 |(% style="width:239px" %)服务目录和服务门户|(% style="width:272px" %)选择要订购的服务和服务级别的选项|(% style="width:274px" %)在标准化服务量很高的情况下，非常高
++|(% style="width:278px" %)可行性分析|(% style="width:239px" %)(((
++配置管理数据库（CMDB），服务模型，可用性和容量监控和
++
++管理工具和资产管理工具
++)))|(% style="width:272px" %)控制提供所需服务资源的可用性和容量|(% style="width:274px" %)在标准化服务量很高的情况下，非常高
++|(% style="width:278px" %)起草SLA|(% style="width:239px" %)合同工具和服务门户|(% style="width:272px" %)起草报价单/ SLA|(% style="width:274px" %)(((
++在标准化服务量很高的情况下，非常高，尤其是通过
++
++互联网订购
++)))
++|(% style="width:278px" %)SLA谈判|(% style="width:239px" %)(((
++合同工具，以及
++
++服务门户和应用
++)))|(% style="width:272px" %)备选方案的选择|(% style="width:274px" %)中等
++|(% style="width:278px" %)SLA沟通和启用|(% style="width:239px" %)变更的发起和控制工具|(% style="width:272px" %)变更发起，|(% style="width:274px" %)在标准化服务量很高的地方非常高，尤其是如果以数字方式交付
++|(% style="width:278px" %)电子邮件和其他沟通渠道，账单和支付工具，资产管理工具（包括许可证控制）|(% style="width:239px" %)(((
++资产重新分配
++
++
++)))|(% style="width:272px" %)工作任务分配，账单和付款流程，培训和交流，用户支持，|(% style="width:274px" %)提供了约定服务级别的确定来源
++|(% style="width:278px" %)(((
++SLA 评审
++
++SLA延长
++
++SLA退出
++)))|(% style="width:239px" %)(((
++管理工具，用户支持
++
++知识管理工具和文档存储库
++
++文档控制工具和存档
++)))|(% style="width:272px" %)控制失效日期、版本控制和文件归档|(% style="width:274px" %)(((
++从低到高，取决于要管理的文档量
++
++监督对服务级别和服务质量流程
++)))
++|(% style="width:278px" %)客户和用户满意度调查|(% style="width:239px" %)调查工具，分析工具，沟通系统和社交媒体|(% style="width:272px" %)调查的分发和推广，收集反馈意见，处理数据，发布调查结果|(% style="width:274px" %)非常高，尤其是在受访者人数众多的地方
++|(% style="width:278px" %)(((
++正在进行的服务质量j监控
++
++基础设施和系统服务健康数据的收集，用户和客户反馈的收集，处理和分析以及仪表盘和报告设计以及展示
++)))|(% style="width:239px" %)监控|(% style="width:272px" %)应用程序监控和报告工具，内置用户行为监控工具，仪表盘和报告工具，高级分析工具，调查和满意度监控工具，用户门户和应用程序以及社交媒体，|(% style="width:274px" %)在标准化服务量很高的情况下非常高，尤其是如果以数字方式交付
++|(% style="width:278px" %)服务评审|(% style="width:239px" %)(((
++报告工具，合同工具和
++
++报告的演示，
++)))|(% style="width:272px" %)SLA延长和主动记录改进|(% style="width:274px" %)(((
++低到中，取决于
++
++标准化服务量
++
++服务的服务门户和
++
++应用程序
++)))
++|(% style="width:278px" %)服务质量报告|(% style="width:239px" %)报告和仪表盘工具，服务门户和应用，电子邮件和其他通讯工具|(% style="width:272px" %)报告的演示|(% style="width:274px" %)(((
++从低到高，取决于
++
++标准化服务的数量以及必须向哪些利益相关者进行报告以及社交媒体
++)))
++
++
++
++
++----
++
++= **6. 合作伙伴和供应商** =
++
++几乎没有服务仅仅依靠组织内部资源就能够交付。许多组织都依赖于第三方提供的服务（请参阅ITIL 4 Foundation的2.4节：服务关系的模型的ITIL 4版本）。服务设计，架构管理和供应商管理的实践指南中描述了由支持服务引入的关系和依赖性。服务级别管理实践中将有关对第三方服务的依赖性的信息用作服务设计信息的一部分，主要用于可行性分析的实现价值。改进规划中也使用了它，特别是在未达到服务级别且需要进行重大改进的地方。
++
++服务级别管理实践是实现组织提供的服务所有权的一种实践，因此很少看到它被外包。
++
++但是，某些情况下可能会委派某些服务级别管理活动。一些活动可以提供外包机会。第三方可以充当服务提供者的代理，代表其提供服务。在此身份下，第三方可以收集客户需求，起草和商议SLA，通过启动发布，参与SLA的沟通，并参与SLA 评审、延长和退出。这些可以应用于高度标准化的服务，尤其是大批量交付的服务。
++
++将服务级别管理实践委派给第三方的另一个机会是在服务集成和管理（SIAM）中，其中供应商（集成商）的服务管理实践在很大程度上替代了服务提供者的服务管理实践。但是，看到这种级别的授权并不寻常。
++
++同时，使用外部或外包资源作为组织的服务级别管理实践的一部分是很常见的情况。这些可能包括人员，自动化工具和支持服务，例如满意度调查和其他数据收集服务。尽管如此，服务的所有权和监督仍然是组织的职责。
++
++
++
++
++----
++
++= **7. 重要提醒** =
++
++实践指南的大部分内容都应作为组织在建立和培养自己的实践时可能考虑的领域的建议。实践指南是组织可能考虑的主题目录，而不是答案列表。使用实践指南的内容时，组织应始终遵循ITIL 指导原则：
++
++* 聚焦价值
++* 从你所处的地方开始
++* 基于反馈迭代推进
++* 协作和提升可视化程度
++* 通盘思考和工作
++* 保持简单实用
++* 优化和自动化
++
++有关指导原则及其应用程序的更多信息，请参见参考资料I//TIL Foundation：ITIL 4版。//
++
++
++
++
++----
++
++= **8. 致谢** =
++
++AXELOS Ltd非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
++
++
++== 8.1作者 ==
++
++德米特里·伊赛琴科（Dmitriy Isaychenko），罗马·朱拉夫列夫（Roman Jouravlev）。
++
++
++== 8.2 审稿人 ==
++
++Akshay Anand, Pavel Demin, Sofi Fahlberg, Piia Karvonen, Antonina Klentsova, Mark O’Loughlin, Anton Lykov, Paula Määttänen, Christian F. Nissen, Tatiana Orlova, Elina Pirjanti, Stuart Rance.
++
++

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司