Changes for page 06. 步骤4：协议

Last modified by superadmin on 2024/04/03, 16:45

From version < 18.1 >

edited by superadmin
on 2021/12/21, 16:04

To version < 9.1 >

edited by superadmin
on 2021/12/10, 15:48

< >

Change comment: 上传新附件1639122515850-102.png

Raw
Rendered

Summary

Page properties (3 modified, 0 added, 0 removed)
Attachments (0 modified, 0 added, 2 removed)
- 1639122639018-563.png
- 1639122695136-545.png

Details

Page properties

Title

...	...	@@ -1,1 +1,0 @@
1		-06. 步骤4：协议

Parent

...	...	@@ -1,1 +1,0 @@
1		-ITIL 4《驱动利益相关者价值》DSV.WebHome

Content

@@ -1,720
          +1,0 @@
--{{box cssClass="floatinginfobox" title="**Contents**"}}
--{{toc/}}
--{{/box}}
--
--= 6. 步骤4：协议 =
--
--[[image:1639122005647-281.png]]
--
--                                                                                                               约定和规划价值共创
--
--                                                                                                               谈判和约定服务
--
--
--协议步骤的目的是在服务提供者和服务消费者之间统一期望，并建立对目标服务范围和质量的共享视图。
--
--
--在某些情况下，协议可以包括签定合同，这可能需要法律顾问或合同经理等专家的参与。
--
--
--表6.1总结了服务提供者、服务消费者和其他利益相关者为何应在统一期望和约定服务方面进行投资。
--
--
--表6.1 统一期望和约定服务的目的
--
--(% style="width:778px" %)
--|(% style="width:146px" %)**协议**|(% style="width:329px" %)**对于服务消费者**|(% style="width:300px" %)**对于服务提供者**
--|(% style="width:146px" %)促进成果和经验|(% style="width:329px" %)(((
--确保提供的服务满足客户和用户的要求和期望
--
--通过服务和服务关系增加潜在价值
--
--确保所有利益相关者对服务质量达成共识
--
--确保对利益相关者的责任有共同的理解
--)))|(% style="width:300px" %)(((
--确保所有相关利益相关者对服务质量达成共识
--
--确保对利益相关者的责任有共同的了解
--
--确保对服务和服务关系的现实期望
--
--通过服务交付和服务关系增加潜在价值
--)))
--|(% style="width:146px" %)优化风险和合规性|(% style="width:329px" %)(((
--确保对服务质量的充分控制和服务状态的透明度
--
--消除有关当事方之间的误解和错位
--
--降低违规风险
--
--确保对服务相关风险达成共识
--
--为无法通过协议共享或转移的风险安排补偿性控制
--)))|(% style="width:300px" %)(((
--消除有关当事方之间的误解和错位
--
--降低违规风险
--
--确保对服务相关风险达成共识
--
--确保对服务价格和相关付款有共同的了解，并减少付款纠纷或延误的风险
--)))
--|(% style="width:146px" %)优化资源并最小化成本|(% style="width:329px" %)(((
--确保对服务消费成本和相关付款有共同的了解
--
--优化服务消费成本
--
--优化谈判和协议成本以及整体资源利用
--)))|(% style="width:300px" %)(((
--确保对服务提供成本有共同的了解
--
--优化服务提供成本
--
--确保对服务价格和相关付款有共同了解
--
--优化谈判和协议成本以及整体资源利用
--)))
--
--服务的目标范围和质量应得到各方的同意；在服务关系的其余步骤中，它们将被称为“约定的服务范围和质量”。遗憾的是，约定的目标不可能总能实现，因此应定期将已实现的服务范围和质量与目标进行比较，以评估协议的履行情况。目标也可能随时间的推移而变化。因此，在旅程中协议步骤可能会被多次重新审视。
--
--
--在用户旅程的背景中，其目的非常相似：与服务提供者建立目标服务范围和质量的共享视图。但是，根据用户和客户角色之间的关系，这可能会有所不同。在某些情况下，范围和质量受限于客户和服务提供者之间的协议，因此对于用户，“同意”可能仅限于未经（或非常有限）协商的接受。但是，这仍然是用户旅程中的重要一步：了解可用服务及其约定的质量对于用户有效工作非常重要。
--
--
--|(((
--**ITIL故事：步骤4 –协议**
--
--[[image:1639122073544-139.png||height="55" width="49"]]//Mariana：当我们的客户加入我们的汽车共享俱乐部时，他们同意我们在会员资格中规定的条款和条件。每次预订均受使用条款和条件的约束。例如，我们与艾克苏达成的有关汽车故障的协议是，当汽车发生故障或发生事故时，可以提供道路救援。 但是它不适用于常规维护（如爆胎）。//
--
--**[[image:SO.png||height="60" width="49"]]S**//olmaz：客户在实际租车时也会与我们达成协议，以遵守租车的条款和条件。//
--)))
--
--== 6.1 约定和规划价值共创 ==
--
--应该就如何以及何时共同创造、跟踪、评估和评价价值达成共识。 这类规划的一种方法是，首先就驱动价值的因素达成一致，并概述预期的服务成果和经验，然后计划如何以及何时衡量、评估、报告和评价价值共创。 该规划应包括风险管理、合规和成本以及资源管理。
--
--
--
--=== 6.1.1 服务价值驱动类型 ===
--
--在服务价值系统（SVS）中，通过实现服务消费者目标可以实现服务消费者目的。实现服务消费者目标的动力来自于消费者的绩效和相关体验。服务消费者的绩效取决于服务绩效，并被视为功用和功效。最终，服务绩效由组合的和单独的资源、实践和产品的绩效决定。图1.11说明了这些关系。
--
--
--服务产品通常包括三种形式的服务绩效驱动：
--
--* 商品从服务提供者转移到服务消费者
--* 服务消费者访问服务提供者的资源
--* 由服务提供者、服务消费者或二者共同实施的服务动作
--
--大多数服务产品都结合了几种形式。基于技术的服务通常包括对服务提供者资源的访问，有时还包括对服务动作的访问。表6.2提供了一些价值驱动的示例。
--
--
--表6.2适用于不同类型服务产品的价值驱动示例
--
--(% style="width:884px" %)
--|(% style="width:123px" %)**服务示例**|(% style="width:162px" %)**商品转移**|(% style="width:278px" %)**访问资源**|(% style="width:319px" %)**服务动作**
--|(% style="width:123px" %)企业会计|(% style="width:162px" %)N/A|(% style="width:278px" %)财务部门的员工可以访问：具有约定功能的会计应用程序；约定质量的财务和其他数据；以及服务台和其他支持接口|(% style="width:319px" %)(((
--用户动作：通过应用程序在会计系统中进行的任何交易或查询
--
--服务提供者的动作：
--
--定期更新来自不同业务部门的合并数据
--
--联合动作：服务台代理登记用户报告的事件
--)))
--|(% style="width:123px" %)面向个人消费者的宽带互联网服务|(% style="width:162px" %)将具有所有权的Wi-Fi路由器和用户手册出售给用户|(% style="width:278px" %)(((
--客户授权的所有用户都可以以约定的速度访问局域网和广域网
--
--向客户提供用于支付、报告和服务管理的用户接口访问权限
--)))|(% style="width:319px" %)(((
--用户动作：查看帐户状态；变更订阅；管理用户帐户
--
--服务提供者的动作：向客户发送发票
--
--联合行动：当客户搬到新地方时，更改服务提供的地址
--)))
--|(% style="width:123px" %)一家小型咖啡店的刷卡支付处理|(% style="width:162px" %)读卡器设备所有权转让给客户|(% style="width:278px" %)(((
--访问与客户的收银机和银行帐户集成的支付处理服务
--
--访问用于接收和管理支付的移动应用
--
--访问支持热线
--)))|(% style="width:319px" %)(((
--用户动作：接收卡或设备支付；取消支付；重置设备； 与智能手机配对
--
--服务提供者的动作：通知客户有关应用程序更新和其他重要事件
--
--联合动作：更换有故障的读卡器设备
--)))
--|(% style="width:123px" %)内部IT基础架构团队为产品开发团队提供的基础架构平台服务|(% style="width:162px" %)N/A|(% style="width:278px" %)平台即服务的访问|(% style="width:319px" %)(((
--用户动作：安装和更新应用程序； 通过标准化接口配置资源并安装、调试、启动、停止和停用平台组件
--
--服务提供者的动作：监控和报告服务水平；组件打补丁； 开票给客户
--
--联合行动：对平台进行重大更新； 解决共同的问题
--)))
--
--在表6.2中，第一个和第三个示例主要是在服务动作的上下文中被客户和用户感知。 这对于旨在使业务活动自动化的服务来说是典型的。第二个和第四个示例主要是通过服务提供者提供的资源质量来感知。不同点通常反映在服务协议的格式中，因为它们更加关注所提供的资源质量或服务动作的执行情况。
--
--
--对于服务提供者而言，识别、约定和衡量提供给服务消费者的资源的特征非常容易。 在许多情况下，这些都是可衡量且明确的技术特征。 定义对服务消费者重要的服务动作则比较困难。
--
--
--=== 6.1.2 服务交互方法 ===
--
--服务交互方法有助于基于用户和服务提供者在服务消费期间执行的关键服务交互的绩效来描述和评估服务结果。 它可以帮助各方进行价值共创的规划。
--
--
--**服务交互方法示例**
--
--银行有向其客户提供个人贷款的价值流。该价值流包括一系列活动，其中大多数活动由IT服务实现的。在对价值流进行映射和分析后，确定了以下服务交互，如下所示。
--
--(% style="width:917px" %)
--|(% style="width:448px" %)**服务交互**|(% style="width:237px" %)**需求**|(% style="width:230px" %)**约束条件**
--|(% style="width:448px" %)贷款申请的处理|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)1.当前不良信用检查|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)2.负担能力计算|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)3.信用等级评估|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)4. 申请评分|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)5.基于风险的利息计算|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)6.报价的确认或更新|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)…|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)贷款协议的签署与转帐|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)8.贷款协议和相关协议的自动登记|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)9.开户并创建付款时间表|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)10.设置直接付款指令|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)…|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)贷款协议持续管理|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)14.利息计算和帐户信息更新|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)…|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)付款处理|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)28.如果客户请求全额偿还贷款，计算应付款项|(% style="width:237px" %) |(% style="width:230px" %)
--|(% style="width:448px" %)…|(% style="width:237px" %) |(% style="width:230px" %)
--
--根据此列表，服务提供者和客户就下表中列出的某些服务交互的服务级别要求和度量标准达成一致
--
--(% style="width:925px" %)
--|(% colspan="3" style="width:922px" %)**约定的服务级别要求和指标**
--|(% style="width:456px" %)服务级别特征|(% style="width:180px" %)客户需求|(% style="width:287px" %)服务级别指标
--|(% style="width:456px" %)自动贷款申请处理时间|(% style="width:180px" %)少于60秒|(% style="width:287px" %)及时处理贷款申请的百分比
--|(% style="width:456px" %)银行分行中使用的所有贷款相关系统的服务中断的最大持续时间|(% style="width:180px" %)少于10分钟|(% style="width:287px" %)单次中断最长持续时间
--|(% style="width:456px" %)一个工作日内总不可用时间|(% style="width:180px" %)少于15分钟|(% style="width:287px" %)一段时间内未满足需求的天数和百分比
--
--此方法包括以下阶段：
--
--* 识别服务交互，包括服务提供者动作、服务消费者动作和联合动作
--* 将已识别的服务交互与服务提供者的服务目录进行匹配
--* 协定服务交互目标绩效
--* 与客户和服务提供者团队就服务的度量和测量标准达成一致。
--
--识别服务交互的最佳方法是映射服务提供者和服务消费者价值流。对于组织而言，拥有价值流和流程的最新地图非常有帮助。根据这些信息，服务提供者和服务消费者可以得出服务、相关的服务交互以及绩效需求所支持的动作列表。
--
--
--但是，在组织中通常找不到价值流和流程的正确且最新的地图。在没有这些图的情况下，可以利用组织的文档和标准来识别服务交互。由此产生的列表将更加通用，但对于规划价值共创而言可能就足够了。客户和服务提供者对服务交互绩效的要求，可以从组织的相关内部程序和标准中得出。
--
--
--这项工作应该由一个团队来完成，其中可能包括：
--
--* 服务和/或产品所有者
--* 客户
--* 服务/系统架构师
--* 服务设计师
--* 业务分析师
--* 服务目录管理员
--
--=== 6.1.3 服务的固有和指定特征 ===
--
--
--|(((
--**定义**
--
--* **服**务质量，与服务满足既定和隐含需求的能力相关的服务特征的整体。
--* **服**务级别，一个或多个用于定义预期或已实现的服务质量的度量标准。
--)))
--
--组织通常会同意一种定义服务质量的方法。这些协议包括基于资源或服务运营的服务规范和度量的首选方法。
--
--
--服务的固有特征可能包括：
--
--* 功能和性能
--* 架构
--* 接口和兼容性
--* 费用
--
--服务的指定特征可能包括：
--
--* 价格
--* 风险与合规
--* 服务交付的透明度
--* 监控
--* 报告
--* 灵活性
--* 社会责任
--
--固有特征基于相应产品的资源。指定特征大多定义为服务和服务提供设计的一部分。它们描述了服务的交付、支持和改进方式，并且可以在不对相关产品进行重大变更的情况下进行修改。
--
--
--这种区别虽然对服务管理有所帮助，但并不是确定的。某些特征，例如兼容性或安全性，可以是固有的（集成接口是产品设计的一部分），也可以是指定的（集成是引入和持续支持的一部分）。服务提供者决定哪些特征应包括在服务质量规范中，哪些应留给服务交付情况、条款和条件的讨论。
--
--(% style="text-align:center" %)
--[[image:1639122266422-714.png]]
--
--(% style="text-align:center" %)
--[[image:1639122297686-461.png||height="225" width="629"]]
--
--== 6.2 协商并同意服务 ==
--
--根据服务关系模型，协商和同意服务的方法可能会有很大不同。但大多数情况下，范围包括：
--
--* 提供和使用的服务
--* 服务的固有质量特性，例如功用、功效和体验
--* 服务的指定特征，例如价格、地区和提供期限
--* 服务范围和质量的共同控制和改进的方法
--
--=== 6.2.1 协议表格 ===
--
--有几种方法可以确定服务关系中的服务范围和质量。 这些关系可以是：
--
--* 基于义务
--* 基于协议
--* 基于承诺
--* 根据社会规则和期望
--
--这些方式具有不同级别的形式、协商流程以及控制和改进的方法。
--
--
--==== 6.2.1.1 基于义务的服务关系 ====
--
--基于义务的服务关系是通过对组织的强制性要求定义的，通常是法律或其他法规规定的。法律可能要求提供最低级别的服务；有时它也要求服务消费。示例包括：
--
--* 社会服务，例如医疗服务和教育
--* 基础设施服务，例如运输或设施安全
--* 社会责任服务，例如司机或旅行者的强制性保险。
--
--尽管这些服务大多数可以由商业服务提供商提供，但服务消费者的最低服务级别和价格通常由国家规定。这意味着，无论服务协议的形式如何，它都必须包括某些服务质量特性，并保证最低服务级别。如果仅提供了最低的强制性服务级别，则没有协商和协议的空间。
--
--
--在某些情况下，各方从强制性服务级别开始，但同意对其进行扩展，并相应地设置服务级别的目标。在这种情况下，他们根据自己的义务建立自己的协议，并扩展为基于协议的关系。
--
--
--|(((
--**ITIL故事：基于义务的服务协议**
--
--[[image:1639122366161-300.png||height="51" width="32"]]**S**//olmaz：为了开展国际业务，艾克苏租车必须尊重国家之间存在的双边和区域贸易协定。这些是基于义务的协议，这些协议支配着我们如何开展业务，如何在当地雇用员工以及如何投资以获得回报。//
--)))
--
--==== 6.2.1.2 基于协议的服务关系 ====
--
--基于协议的服务关系，意味着服务关系所涉及的各方就服务的范围和质量进行协商并达成一致。他们可能会以电子或书面方式记录该协议，并利用它来监视和管理服务的实际质量。在大多数情况下，该协议称为服务级别协议（SLA）。根据关系不同，它可以采用谅解备忘录的形式，或更常见的是法律合同的形式。
--
--
--|(((
--**定义：服务级别协议（SLA）**
--
--服务提供者和客户之间的书面协议，标识了所需的服务和服务的预期级别。
--)))
--
--SLA是双方之间正确讨论的结果，这一点很重要。即使服务提供者不灵活，也没有提供太多的谈判空间，也应在知情同意的情况下向客户提供SLA中定义的服务。认知和同意是基于协议的关系的最低要求。
--
--
--SLA可能具有不同的形式级别。形式化的水平可能反映了服务提供者和服务消费者之间的信任程度。如果信任度较低，则组织将试图在协议中包含尽可能多的细节。如果信任度很高，并且是通过关系的正面体验获得的，则各方倾向于将重点放在最重要和特定的服务特性上，这意味着协议中未提及的内容将根据既定的惯例和期望进行交付和消费，这些含义可以描述为承诺。
--
--
--在高度信任的服务关系中，或者如果服务特性较简单，则可以口头或通过简短的电子邮件或文本消息来达成协议。
--
--
--==== 6.2.1.3 基于承诺的服务关系 ====
--
--基于承诺的服务关系最初由Mark Burgess（Burgess，2004）在2004年提出的承诺理论描述。它适用于以下情况：服务提供者和服务消费者的意图没有被记录，而是由以前的经验、社会规范或共同认可的迹象所暗示。
--
--(% style="text-align:center" %)
--[[image:1639122384072-300.png]]
--
--
--==== 6.2.1.4 基于社会规则和期望的关系 ====
--
--在已建立的长期服务关系中，非正式的承诺和强加很常见。根据以前的经验，服务的隐含特性在初始阶段就向服务消费者公开。此外，服务提供者期望参与方（例如客户、用户、赞助者和服务消费者资源）将按照既定的标准和约定的规则行事。
--
--
--有许多描述社会契约的哲学和社会学理论。本质上，社会契约是对社会及其政府施加的规则的接受。特别是，在具有合法影响力的地区生活、工作和互动的个人和组织都接受它。接受可以是显式或隐式的。
--
--
--这个概念可能会影响服务关系，因为政府的标准和要求经常会影响组织的期望，并且对服务的范围和质量特性施加了约束。在某些情况下，正式服务协议会包含有关合规性的声明。
--
--
--法律、当地传统、社区规则和其他要求，通常是由社会契约施加。这是明确接受合同的一个示例，当其中一个组织不熟悉这些要求时可能会有用；例如，建立国际服务关系时。
--
--
--|(((
--示例
--
--当组织决定将内部服务职能转变为单独的公司时，他们通常希望根据多年的以往经验，来获得他们习惯了的服务范围和质量。但是，这几乎是不可能的，尤其是在新服务公司有望在商业上取得成功的情况下。
--
--不管新的正式签署的服务级别协议如何，都期望可能继续基于先前建立的规范。有效地管理此类组织变更很重要，这样才能保持所需的服务质量、成本和用户满意度。
--)))
--
--在实践层面上，服务关系始终由服务提供者和服务消费者之间的显式或隐式协议来支持。重要的是要平衡正式记录的服务隐含特性和协议本身。还应记住，隐含协议基于共同的假设和共同的价值。在应用非明示协议时，尤其是在与新的消费者或提供者建立服务关系时，组织应考虑文化、背景、以前的经验和法规。对默示协议的误解和曲解可能会导致紧张和冲突。
--
--
--=== 6.2.2 基于成果的协议 ===
--
--在合作关系和伙伴关系中，组织倾向于从价值和结果角度讨论服务质量。指定功用和功效级别很有用，因为它使服务的监控和管理保持一致。当讨论服务消费者的价值时，讨论可能集中在预期的结果上，或涵盖服务减少或引入的风险和成本。
--
--
--价值的书面定义成为规划价值共创和价值实现的联合跟踪、评估和评价的基础，这将在第9章中进一步讨论。价值的定义对于组织而言通常比遵守服务级别要求更为重要，尽管期望两者都应满足。如果信任级别足够高，则即使已经达到约定的服务级别，也可以允许服务提供者调整服务级别并启动服务改进。组织可以在同意步骤中就服务改进和价值实现的方法达成协议，并在其合作关系协议中记录此方法。
--
--
--基于价值和基于成果的服务级别管理方法同样适用于内部和外部关系。需求包括共同的目标、相互信任和组织敏捷性。
--
--
--|(((
--**ITIL的故事：基于成果的协议**
--
--[[image:1639122366161-300.png||height="51" width="32"]]//Solmaz：我们与汽车清洁公司的协议基于成果。对于此协议，我们不按资源或清洁时间付费；取而代之的是，我们根据干净状态下退还给我们的车辆数量付款，那些影响客户的体验。//
--)))
--
--=== 6.2.3 从服务消费者需求到协议 ===
--
--根据服务关系和模型，服务提供者和服务消费者组织之间对服务质量的协商存在很大差异。影响谈判的一些因素是：
--
--* 内部或外部关系
--* 个人（一个人组织）或公司服务消费者
--* 基本服务或战略合作关系
--* 量身定制的或开箱即用服务
--
--所有这些因素都会影响旅程的所有步骤。表6.3列出了这种影响的一些示例。
--
--
--表6.3  不同情况下服务关系旅程差异的示例。
--
--(% style="width:829px" %)
--|**影响因素**|(% style="width:610px" %)**因素影响的例子**
--|内部服务关系|(% style="width:610px" %)(((
--服务提供和服务消费可能具有相同的发起人
--
--服务提供者和服务消费者可能具有相同的战略目标
--
--可能没有合法的服务合同
--
--关系可能基于命令和控制，而不是合作关系
--)))
--|个人服务消费者|(% style="width:610px" %)(((
--发起人或赞助人（隶属于服务消费）、客户和用户可能是同一个人，并且有利益冲突
--
--客户数量可能非常大；个人谈判方法不可行
--
--关系可能是规范且正式的，而不是基于个人需求和类似合作关系的关系
--
--简单且通常为自动化的协议规程
--)))
--|基本服务|(% style="width:610px" %)(((
--高度标准化的服务产品和服务要求
--
--简单且通常为自动化的协议规程
--
--协议不太可能专注于结果或价值
--)))
--|量身定制的服务|(% style="width:610px" %)(((
--协商、交付和评估服务的个性化方法
--
--量身定制的协议（格式、服务级别目标、评估和报告）
--)))
--
--服务消费者和服务提供者应意识到的一个重要共性是，协商旨在缩小服务质量特性的范围。图6.1中对此进行了说明。
--
--
--参与谈判的所有各方均应了解，约定的服务级别（尤其是以合法的合同的形式）仅包含可以高度保证且明确衡量的特性和目标。包含此内容的另一个原因是，在流程期间可能会丢失信息，包括从建立需求和期望到明确陈述的需求，再到协议。
--
--
--此外，对于开箱即用服务，客户需求不会直接转换为服务特性；它们必须与预定义和已发布的服务描述进行比较和匹配，而这些描述可能是在没有客户参与的情况下设计的。这意味着仅关注履行正式协议不足以管理服务的质量。监视和讨论用户和客户的满意度，以及服务消费的结果和价值非常重要。
--
--
--尽管SLA不足以用于服务度量、评估、评价和改进，但它们仍然有用。协议有多种形式。
--
--
--(% style="text-align:center" %)
--[[image:1639122476757-538.png]]
--
--
--图片6.1协议限制：从服务消费者需求到协议
--
--
--|(((
--**SLA的内容和结构**
--
--SLA的基本结构由名称表示：
--
--* **Service 服**务定义协议的范围
--* **Level 级**别定义服务的特性以及每个特性的商定指标和目标
--* **Agreement 协**议涵盖了服务提供和使用的条款和条件。
--
--如果协议涵盖多种服务或反映了消费者组织的复杂结构，则该结构可能会变得更加复杂。例如，“级别”和“协议”部分可能包含适用于每种服务或客户的段落，以及特定于服务或客户的段落。
--
--
--与外部组织的协议（SLA是法律合同的一种或一部分）中，协议部分通常会变得更加复杂。在订购协议中，它可能包含特定条款，例如订购期限、取消的规则和费用以及收取定期付款的方法。无论哪种结构对组织更有效，遵循此指导原则都是很重要的：使其简单实用。在不可避免的复杂情况下，建议（或法规要求）以简洁明了的语言提供简短的解释。这对于敏感服务（例如贷款）尤其重要。
--)))
--
--|(((
--**ITIL的故事：从服务消费者需求到协议**
--
--[[image:1639122515850-102.png||height="60" width="35"]]//Solmaz：根据我们向汽车清洁公司提出的初始价格，该公司回应说不再使用环保产品。环保可持续性在艾克苏汽车租赁公司中，对我们的愿景至关重要，因此我们不得不重新协商互利的成果。//
--)))
--
--=== 6.2.4 协商并协定服务功用、功效和体验 ===
--
--SLA的“级别”部分通常包括针对服务功用和功效的议定服务级别目标。
--
--
--|(((
--**定义**
--
--* **功用，**产品或服务提供的可满足特定需求的功能。功用可以概括为“ 服务的用途”，并且可以用来确定服务是否“ 符合目的”。要具有功用，服务必须支持消费者的性能或绩效，或消除消费者的约束。许多服务都可以做到。
--* **功**效，确保产品或服务将满足约定的要求。功效可以概括为“ 服务的执行方式”，并且可以用来确定服务是否“适合使用”。功效通常涉及与服务消费者的需求相符的服务水平。这可以基于正式的协议，也可能是市场营销信息或品牌图像。功效通常涉及诸如服务的可用性、其容量、安全级别和连续性等领域。如果满足所有定义和约定的条件，则可以说服务提供了可接受的保证或“功效”。
--)))
--
--服务质量和服务级别的管理应该着重于价值，并且应该管理服务的所有相关特性。这包括相关的指标、体验领域和反馈。从需求的规范到已实现的质量的评价，分离服务的功能和非功能特性的方法来自于开发和运营团队的分离。这些特性和团队的分离通常导致对服务质量的零碎理解。
--
--
--==== 6.2.4.1 功用 ====
--
--服务的功用特性通常被描述为由服务提供者的人员和其他资源执行的功能，或服务动作（由服务提供者执行，可供用户使用或共同执行）。表6.4提供了服务功用描述和指标的一些示例。
--
--
--表6.4显示功用特性通常是二进制的（它起作用或不起作用）。关联的指标通常基于重要功能或性能不可用或性能太低而无法接受的事件。但是，服务功用的整体评估可以基于多个特性和相关指标的集成。例如，如果系统的某些功能不可用或执行时出错很多，则可以将它们评估为约定的功用的百分比，而不是二进制指标。有关服务指标和度量的更多信息，请参见第9章和服务级别管理实践指南。
--
--
--表6.4  服务功用说明和指标的示例
--
--(% style="width:884px" %)
--|(% style="width:171px" %)**服务**|(% style="width:255px" %)**功能示例**|(% style="width:455px" %)**指标和目标示例**
--|(% style="width:171px" %)移动网络|(% style="width:255px" %)(((
--连接到全球互联网
--
--用于语音和视频通话的IP电话、SMS
--)))|(% style="width:455px" %)(((
--无法访问互联网资源发生的事件数（每月<2）
--
--平均连接速度（> 10 Mbps）
--
--连接中断的呼叫百分比（<5％）
--
--音频或视频质量被用户评估为5星中的3星，或更少（<10％）
--
--无法建立呼叫或应用程序连接（<5％）
--
--交付时间超过一分钟的SMS的百分比（<5％）
--)))
--|(% style="width:171px" %)商务旅行机票搜索与预订|(% style="width:255px" %)(((
--按日期、航空公司和票价搜索航班
--
--选择和预订航班
--
--飞行常客卡的识别和申请
--
--政策符合性检查
--
--将差旅费用分配给正在进行的代码和项目预算代码
--)))|(% style="width:455px" %)(((
--无法完成搜索的事件数（<1％）
--
--服务未提供通过其他搜索引擎提供更好票价或航班的已报告事件的数量（每月少于5个）
--
--未正确分配给预算代码的预订数量和百分比（每月<5或<2％）
--
--由于技术问题而无法完成航班搜索，预订或付款的事件的数量和百分比（每月<2或<1％）
--
--搜索、预订或付款交易超时（每月<5或<2％）的事件数量和百分比
--)))
--
--==== 6.2.4.2 功效 ====
--
--服务功效描述了在约定的条件下提供约定的功用的保证级别。条件可能包括：
--
--* 服务提供的地区和期限
--* 需求/工作量
--* 威胁和相关风险
--* 用户的准备情况
--* 适用法律
--
--“保证级别”是指在约定的条件下，提供了某些级别的可用性、性能、容量、连续性、安全、可用性、合规性和其他服务质量特性。表6.5给出了移动互联网服务的一些示例。
--
--
--表6.5  功效需求和相关指标的示例
--
--(% style="width:828px" %)
--|**功效需求**|(% style="width:350px" %)**指标和目标**|(% style="width:381px" %)**条件**
--|可用性|(% style="width:350px" %)(((
--可用性超过一个月的百分比（> 99％）
--
--中断次数（每月<3）
--
--最长中断时间（<15分钟）
--
--中断之间的最小正常运行时间（> 3小时）
--)))|(% style="width:381px" %)(((
--在约定的服务提供时间和范围内，
--
--包括本地区和漫游目的地
--)))
--|性能|(% style="width:350px" %)(((
--最低下载速度（> 5 Mbps）
--
--一段时间内的平均下载速度（> 10 Mbps）
--
--最低上传速度（> 3 Mbps）
--
--下载一小时视频的平均时间（少于5分钟）
--
--视讯通话或视频流中断或延迟的事件数（每月<3）
--)))|(% style="width:381px" %)(((
--同时下载进程的最大数量为3
--
--有关官方视频托管和通信服务的商定列表
--
--在商定的服务提供区域内，仅家庭网络
--)))
--|容量|(% style="width:350px" %)(((
--最大并发流量的应用程序数量，例如视频流/下载和视频通话（5）
--
--覆盖范围（建筑物的所有房间）
--
--每月流量（无限制）
--)))|(% style="width:381px" %)(((
--官方认可的应用
--
--在家庭网络和选定的漫游目的地内
--)))
--|信息安全|(% style="width:350px" %)每月来自互联网的恶意软件引起的安全事件数（0）|(% style="width:381px" %)只要用户不更改安全设置和防病毒软件设置，并且所有用户都遵循信息安全准则
--|合规性|(% style="width:350px" %)服务提供和服务符合有关个人数据保护、版权保护和内容控制的国家法规|(% style="width:381px" %)只要用户不更改内容控制设置，并且用户遵循信息处理准则
--|连续性|(% style="width:350px" %)(((
--发生重大网络中断时的最长服务恢复时间（<12小时）
--
--发生重大网络事件时切换到备份解决方案的最长时间（<3小时）
--)))|(% style="width:381px" %)(((
--如果国家电网可用
--
--如果至少有一个移动运营商合作伙伴的网络可用
--)))
--|辅助功能|(% style="width:350px" %)所有界面清晰可见，易于使用|(% style="width:381px" %)只要用户没有视力障碍，并且可以阅读和说英语、德语、法语或西班牙语
--
--==== 6.2.4.3 体验 ====
--
--如前所述，组织越来越多地在协议中包含用户体验目标。许多体验指标与服务接口性能相关；其他的可能表示用户对界面或服务的总体满意度。其中的度量可以集成到数字化服务中。体验指标的示例包括：
--
--* 用户错误
--* 返回上一级（后退按钮用法）
--* 帮助（F1）呼叫
--* 丢弃（未完成）服务操作
--* 在广告休息期间切换到其他频道的用户
--* 试用期过后取消订阅的用户
--* 确认用户同意条款但不阅读条款和条件的用户。
--
--表6.6 提供了一些商务旅行机票搜索和预订服务的体验特性和指标的示例。
--
--
--表6.6 体验特性和指标示例
--
--(% style="width:863px" %)
--|**体检特性**|(% style="width:560px" %)**指标和目标**
--|不间断地完成用户操作|(% style="width:560px" %)每月未完成的预订数量和百分比（<50或<5％）
--|用户对服务的满意度|(% style="width:560px" %)用户在一段时间内对服务给予的平均和最低评分（> 4分，共5分；> 2.9分）
--|界面清晰便捷|(% style="width:560px" %)(((
--每月用户使用界面帮助的交易数量和百分比（<10或<5％）
--
--用户在一段时间内对服务界面给予的平均和最低评分（> 4，共5；> 3.5）
--)))
--
--其背后的想法是直接测量用户体验，而不仅仅是询问用户。术语体验级别协议或XLA™由Marco Gianotten（Gianotten，2017年）提出。基于体验的服务定义和度量方法适用于服务动作是服务的重要组成部分的服务。有很多服务没有用户交互，也很少交互。例如基础设施即服务（IaaS）或平台作为服务（PaaS）。
--
--
--(% style="text-align:center" %)
--[[image:1639122639018-563.png]]
--
--
--=== 6.2.5 协商并同意其他条款和条件 ===
--
--服务提供者与客户之间的协议通常包括功用、功效或体验所未涵盖的条款和条件。这些条款和条件可能包括：
--
--* 服务提供的地区和期限/时间表
--* 服务提供的前提条件（用户培训、保险、基础设施和软件兼容性）
--* 引入和撤销的规则和条件
--* 更改协议的规则和条件
--* 更改涵盖产品和服务、执行测试等的规则和条件。
--* 服务协议终止和延期的规则和条件
--* 角色和责任
--* 协议中利益相关者的组织
--* 沟通与沟通渠道
--* 协议的治理
--* 服务提供的资金来源
--* 价格、价格计算规则以及付款方式和付款期限
--* 执法方法（例如，奖励措施、处罚措施、积分的赚取/扣除、信任分数、反馈会议、合同合规性的发布、法律步骤和媒体使用）
--* 纠纷
--* 服务提供者和服务消费者保证并遵守相关标准和其他要求
--* 权利以及进行第三方审核和审查、请求独立的审计报告等的访问权限
--
--其中大多数都属于SLA结构的协议部分。它们描述了为满足条件的功用提供同意的保证级别或功效的条件。
--
--
--此服务协议的详细程度和形式取决于服务关系类型和SLA结构。与企业内部的非商业服务提供相比，向外部服务消费者提供商业服务需要记录更多的手续。
--
--
--|(((
--**关键信息**
--
--即使非正式协议也应包括服务评估和改进的规则和程序。重要的是要确保所有相关的利益相关者都意识到这一点，并愿意参加相关的活动，例如反馈调查、服务评审会议和改进计划。
--)))
--
--=== 6.2.6 标准化和自动化协议 ===
--
--如同客户旅程的所有其他步骤一样，此步骤在很大程度上可以标准化和自动化，尤其是在与各个消费者建立服务关系时。表6.7说明了它可能有多简单和快速。
--
--
--这些步骤之后，会自动形成正式的协议，并应由各方（通常以电子方式）签署。之后，服务消费者和服务提供者进入引入，将在第7章中进行讨论。
--
--
--为了实现这一点，服务提供者需要仔细地设计和测试其服务、服务目录和支持工具。重要的是要确保其服务符合所选关系模型的目的。预定义的自动协商方法和协议不能解决所有服务关系。许多服务关系是基于自定义的单独方法构建的，无法自动执行。
--
--
--表6.7 针对向许多个人消费者提供服务的典型协议操作示例
--
--(% style="width:747px" %)
--|**同意的要素**|(% style="width:618px" %)**谈判和协议动作**
--|范围|(% style="width:618px" %)(((
--可用的服务由服务提供者预先定义。客户从可用目录中进行选择，无论是否咨询服务提供者。
--
--通过自动界面进行选择。
--)))
--|固有的质量特性|(% style="width:618px" %)对于选定的服务，可以使用一些预定义的选项。 这些选项可以自定义或预先包装在服务级别软件包中。 客户选择最能满足他们需求和要求的选项。
--|指定的质量特性|(% style="width:618px" %)对于选定的服务和质量，可以使用一些预定义的交付选项，例如付款方式和时间表、服务提供期限，服务提供范围等。客户选择最能满足其需求和要求的选项。
--|控制和改进方法|(% style="width:618px" %)服务提供者预先定义了控制的方法、报告和反馈。客户被告知并被迫接受这些条件以继续执行协议。
--
--=== 6.2.7应用实践 ===
--
--为了成功达到有关服务关系和服务质量的协议，组织应采用以下ITIL 管理实践：
--
--* 业务分析
--* 关系管理
--* 服务目录管理
--* 服务财务管理
--* 服务级别管理
--* 供应商管理。
--
--读者应参阅相应的ITIL 实践指南以了解详细信息。
--
--
--|(((
--**ITIL的故事：标准化和自动化协议**
--
--[[image:1639122695136-545.png||height="45" width="44"]]//Mariana：我们用于预订汽车的服务可通过艾克苏预订应用程序在线自动进行。eCampus Car Share与客户之间不会进行协商。但是，在接受预订后，我们要求客户明确同意您租车的条款和条件。他们同意后，便与我们签订了协议。他们无需在每次预订汽车时签署冗长的法律文件。//
--)))
--
--== 6.3 总结 ==
--
--要驱动和跟踪利益干系人的价值，必须调整期望，映射和计划价值共创，并且就服务范围和质量达成共识。
--
--
--该方法取决于关系的类型以及产品和服务的性质，但是服务关系始终由服务提供者和服务消费者之间的显式或隐式协议来支持。
--
--

1639122639018-563.png

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.superadmin

Size

...	...	@@ -1,1 +1,0 @@
1		-203.5 KB

Content

1639122695136-545.png

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.superadmin

Size

...	...	@@ -1,1 +1,0 @@
1		-6.1 KB

Content

粤ICP备17056641号

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