Last modified by superadmin on 2024/12/25, 15:40
From version < 10.1 >
edited by superadmin
on 2021/12/16, 12:35
To version < 8.1 >
edited by superadmin
on 2021/12/16, 12:33
< >
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Content
... ... @@ -24,11 +24,9 @@
24 24  
25 25  
26 26  ----
27 -
28 28  {{box cssClass="floatinginfobox" title="**Contents**"}}
29 29  {{toc/}}
30 30  {{/box}}
31 -
32 32  = **1. 关于本文档** =
33 33  
34 34  ----
... ... @@ -41,6 +41,7 @@
41 41  * 支持实践的信息和技术
42 42  * 实践中关于合作伙伴和供应商的考虑事项
43 43  
42 +
44 44  == **1.1 ITIL®4 资格认证计划** ==
45 45  
46 46  本文档中的部分内容可作为以下教学大纲的一部分以供检查：
... ... @@ -62,6 +62,7 @@
62 62  |**关键信息**
63 63  |服务级别管理实践的目的是为设定清晰的基于业务的服务级别目标，同时确保针对这些目标对服务交付进行适当的评估、监测和管理。
64 64  
64 +
65 65  服务级别管理实践有助于建立和管理服务提供者和服务消费者之间针对双方所有关键利益相关者的服务质量共享视图。此共享视图通常在协议文档中描述，该文档可以是不同正式程度的。这适用于从初始到目前为止的期望和实际服务质量中，并涵盖了整个服务关系中的服务正在提供的和建议的价值。服务级别管理实践还包括了实际服务质量的监测和评估，以及服务和协议的持续改进。
66 66  
67 67  图2.1 说明了实践的关键活动。
... ... @@ -89,6 +89,7 @@
89 89  |**定义：服务级别协议**
90 90  |服务提供者和客户之间的一种书面协议，它确定了所需的服务以及预期的服务级别。
91 91  
92 +
92 92  注：SLA可以有不同的形式和正式程度，客户在其定义中的参与程度也可以因情况而异。从广义上讲，SLA可以定义为：
93 93  
94 94  对目标服务级别及其监测、度量和报告方法的描述，服务提供者用来监测和管理其服务质量。
... ... @@ -105,9 +105,11 @@
105 105  |**定义：功用**
106 106  |产品或服务为满足特定的需要而提供的功能。功用可以概括为“ 服务是做什么的”，并且可以用来确定服务是否“ 符合目的”。要拥有功用，服务必须支持消费者的绩效，也需要移除来自消费者的约束。许多服务都需要达成这两点。
107 107  
109 +
108 108  |**定义：功效**
109 109  |确保产品或服务将满足约定的需求。功效可以概括为“ 服务如何执行”，并且可以用来确定服务是否“适合使用”。功效通常与满足服务消费者的需要相一致的服务级别相关。这可能基于正式的协议，也可能是基于市场营销的信息或品牌形象。功效通常解决诸如服务可用性、容量、安全级别和连续性等领域。如果满足所有已定义和约定的条件，可以说服务提供了可接受的保证，或者说“ 功效”。
110 110  
113 +
111 111  从定义中可以假设服务质量（和服务级别）仅指功效和功效需求。事实并不是如此，服务质量和服务级别的管理应该是整体的，并且聚焦价值的。为此，所有服务相关的特性都应该被管理，包括相关的度量指标，感知的领域和反馈。将服务的职能型管理和非职能型管理进行分开管理的习惯（从定义需求到评估质量）来自于将开发和运维团队进行分离。这些特性和团队的分离往往会导致对服务质量的支离破碎和形式化的理解。
112 112  
113 113  总而言之，服务质量同时包含职能型和非职能型的服务特征，因此服务级别也应如此。
... ... @@ -163,6 +163,8 @@
163 163  )))
164 164  |(% style="width:421px" %)监控技术、团队和供应商绩效|(% style="width:188px" %)监控和事态管理
165 165  
169 +
170 +
166 166  == 2.4 **实践成功因素** ==
167 167  
168 168  实践成功因素（PSF）不仅仅是一项任务或实现价值；它包括所有服务管理四维模型的组件。在一个实践中的实践成功因素PSF的活动和资源性质可能不同，但它们在一起可以确保实践的有效性。
... ... @@ -170,6 +170,7 @@
170 170  |**定义：实践成功因素**
171 171  |实践的一个复杂的功能组件，是完成其目的所必须的实践。
172 172  
178 +
173 173  服务级别管理实践包含以下PSFs：
174 174  
175 175  * 与客户建立目标服务级别的共享视图
... ... @@ -177,6 +177,7 @@
177 177  * 执行服务回顾，以确保当前的一系列服务继续满足组织及其客户的需要
178 178  * 捕获并报告改进机会点，包括针对已定义的服务级别的绩效和针对利益干系人满意度。
179 179  
186 +
180 180  === **2.4.1 与客户建立目标服务级别的共享视图** ===
181 181  
182 182  在不同的服务关系模型中，与客户的交互差异很大；例如：在内部和外部服务条款之间；在大型组织之间和个体之间；在定制化的服务和开箱即用服务之间。后者对与客户建立目标服务级别的共享视图的方法的影响最大。
... ... @@ -185,6 +185,7 @@
185 185  |**服务：定制化还是“开箱即用？**
186 186  |“定制化”的服务意味着在服务交付和消费开始之前，就应该就目标服务级别达成一致，这一点具有很大的灵活性。另一方面，“ 开箱即用” 服务具有一个或多个预定义的服务级别可供选择，没有太多的灵活性。
187 187  
195 +
188 188  当服务提供者和客户建立定制化的服务的共享视图时，他们通常会讨论客户的需要和期望，旨在创建一个满足所有利益相关者需求的服务规范，其中包括：
189 189  
190 190  * 在消费者一侧的服务消费的客户、用户和发起人
... ... @@ -272,6 +272,7 @@
272 272  完成服务动作）
273 273  )))
274 274  
283 +
275 275  在某些情况下，组织在所测量的服务级别的范围中包括了对服务消费产出结果的度量。可以通过基于结果的服务功能描述和引入新的度量方式来完成。这种方法需要服务提供者和服务消费者之间的紧密协作关系。
276 276  
277 277  尽管尽了最大的努力来捕获并满足期望，但约定的服务级别通常不同于服务应该满足的期望，有时甚至是相差甚远。通常情况下不可能实现的一种理想的情况，即所有利益相关者事前就所有事项能够达成一致和满意。
... ... @@ -302,6 +302,7 @@
302 302  自动化的SLA报告。
303 303  )))
304 304  
314 +
305 305  === **2.4.2 监督组织如何满足定义的服务级别** ===
306 306  
307 307  当对目标服务级别形成了共同理解，并且实际的服务交付已经开始时，服务提供者应该从三个主要方面控制服务的实际质量：
... ... @@ -317,6 +317,7 @@
317 317  ** 客户
318 318  ** 用户
319 319  
330 +
320 320  * 提供者利益相关者：
321 321  ** 负责客户关系的角色/团队
322 322  ** 产品和服务负责人
... ... @@ -417,6 +417,8 @@
417 417  * 契动
418 418  * 改进。
419 419  
431 +
432 +
420 420  == **3.2 流程** ==
421 421  
422 422  每个实践可能包含一个或多个流程和活动，它们对于实现该实践的目的可能是必要的。
... ... @@ -433,11 +433,13 @@
433 433  |**定义：流程**
434 434  |可将输入转换为输出的一组相互关联或交互的活动。流程接受一个或多个已定义的输入，并将它们转换为已定义的输出。流程定义动作的顺序及其依赖性。
435 435  
449 +
436 436  服务级别管理活动形成两个流程：
437 437  
438 438  * **SLA的管理**  此流程关注于协议及其生命周期。
439 439  * **监督服务级别和服务质量** 此流程在充分了解服务质量的基础上确保持续服务改进。
440 440  
455 +
441 441  === **3.2.1 SLA的管理** ===
442 442  
443 443  该流程包括表3.1中列出的活动，并将输入转换为输出。
... ... @@ -491,6 +491,7 @@
491 491  撤销SLA
492 492  )))
493 493  
509 +
494 494  图3.2 显示了流程的工作流图。
495 495  
496 496  (% style="text-align:center" %)
... ... @@ -503,25 +503,25 @@
503 503  
504 504  表3.2 SLA管理流程的活动
505 505  
506 -(% style="width:938px" %)
507 -|(% style="width:107px" %)**活动**|(% style="width:367px" %)**开箱即用的预定义服务**|(% style="width:461px" %)**定制化服务**
508 -|(% style="width:107px" %)定义客户需求|(% style="width:367px" %)这些基于现有的服务目录，并为服务级别明确定义的选项。客户为他们所需的服务选择最合适的选项/组合。来自面向客户的团队的服务提供者代表可以帮助客户浏览目录，以找到最相关的服务和服务级别。|(% style="width:461px" %)(((
522 +(% style="width:1013px" %)
523 +|(% style="width:117px" %)**活动**|(% style="width:409px" %)**开箱即用的预定义服务**|(% style="width:486px" %)**定制化服务**
524 +|(% style="width:117px" %)定义客户需求|(% style="width:409px" %)这些基于现有的服务目录，并为服务级别明确定义的选项。客户为他们所需的服务选择最合适的选项/组合。来自面向客户的团队的服务提供者代表可以帮助客户浏览目录，以找到最相关的服务和服务级别。|(% style="width:486px" %)(((
509 509  客户根据他们的业务需求沟通对服务的需求。他们可以参考现有目录，但通常要求不限于预定义的选项。
510 510  
511 511  来自面向客户的或业务分析团队的服务提供者代表，或产品和服务所有者都参与撰写需求的过程中
512 512  )))
513 -|(% style="width:107px" %)可行性分析|(% style="width:367px" %)快速检查资源可用性以确认可以满足定义的需求。该活动遵循预定义的模式，并且可以完全自动化。这将导致服务需求的确认或必要的调整。|(% style="width:461px" %)(((
529 +|(% style="width:117px" %)可行性分析|(% style="width:409px" %)快速检查资源可用性以确认可以满足定义的需求。该活动遵循预定义的模式，并且可以完全自动化。这将导致服务需求的确认或必要的调整。|(% style="width:486px" %)(((
514 514  可能需要对资源要求进行手动或半自动分析，以定义是否有可能满足这些需求以及成本。输出主要是估算的成本/价格和时间表。
515 515  
516 516  该分析应包括与服务提供者的供应商和合作伙伴达成的协议，以确保他们将支持所需的服务级别。
517 517  )))
518 -|(% style="width:107px" %)起草SLA|(% style="width:367px" %)为客户起草标准的SLA，并且获得客户的评审和确认。它可以是完全自动化或很大程度上自动化。|(% style="width:461px" %)服务设计者、服务所有者和关系经理参与了基于可行性分析的协议的起草工作。建议将现有的服务和说明书用作构建块，但这项工作仍可能需要专家知识和大家的协作。
519 -|(% style="width:107px" %)SLA谈判|(% style="width:367px" %)客户评审SLA草案并接受其条款和条件或将其退回以进行分析。如果它被返回或者客户需求协助，则来自面向客户团队的服务提供者代表可以通过SLA草案指导客户并回答问题。在其他情况下，此活动可能是全自动的，客户接受SLA即表示是正式确认。|(% style="width:461px" %)客户和服务提供者代表（可能包括服务负责人，关系，经理，服务设计者等）讨论SLA草案并在需要时协商变更，或签字接受该草案。如果不接受，则将草稿退回到可行性分析中。对于可接受的版本，可能需要花费几次迭代才能达成共识。草案通过后，便得到各方的正式确认。
520 -|(% style="width:107px" %)SLA沟通和启用|(% style="width:367px" %)(((
534 +|(% style="width:117px" %)起草SLA|(% style="width:409px" %)为客户起草标准的SLA，并且获得客户的评审和确认。它可以是完全自动化或很大程度上自动化。|(% style="width:486px" %)服务设计者、服务所有者和关系经理参与了基于可行性分析的协议的起草工作。建议将现有的服务和说明书用作构建块，但这项工作仍可能需要专家知识和大家的协作。
535 +|(% style="width:117px" %)SLA谈判|(% style="width:409px" %)客户评审SLA草案并接受其条款和条件或将其退回以进行分析。如果它被返回或者客户需求协助，则来自面向客户团队的服务提供者代表可以通过SLA草案指导客户并回答问题。在其他情况下，此活动可能是全自动的，客户接受SLA即表示是正式确认。|(% style="width:486px" %)客户和服务提供者代表（可能包括服务负责人，关系，经理，服务设计者等）讨论SLA草案并在需要时协商变更，或签字接受该草案。如果不接受，则将草稿退回到可行性分析中。对于可接受的版本，可能需要花费几次迭代才能达成共识。草案通过后，便得到各方的正式确认。
536 +|(% style="width:117px" %)SLA沟通和启用|(% style="width:409px" %)(((
521 521  当双方确认SLA时，服务提供者会启动所需的变更和沟通，以使约定的服务可用于用户。变更和上线沟通可能是完全自动化的，也可能是大部分自动化的。
522 522  
523 523  这些变更和沟通是由服务级别管理实践触发的，但需要其他实践完成。
524 -)))|(% style="width:461px" %)(((
540 +)))|(% style="width:486px" %)(((
525 525  当各方确认SLA时，服务提供者会启动所需的变更和沟通，以使约定的服务可用于用户。这可能需要对所有类型的提供者的资源进行大量的手动和自动更改，也可能需要对消费者的资源进行更改。在某些情况下，这将导致项目或方案的实现。
526 526  
527 527  这些变更和沟通由服务级别触发
... ... @@ -528,7 +528,7 @@
528 528  
529 529  但需要其他实践完成。
530 530  )))
531 -|(% style="width:107px" %)SLA 评审|(% style="width:367px" %)SLA的正式评审可以基于时间周期或事态进行触发（例如：客户请求，策略变更，服务评审或组织变革）。如果评审是基于时间的，并且客户和提供者都对SLA的内容以及条款和条件都感到满意，那么通常会确认SLA可以延长。如果客户的需求已经发生改变，则流程会基于重新定义的需求再次开始。最后，如果不再需要服务，则启动SLA退出。|(% style="width:461px" %)(((
547 +|(% style="width:117px" %)SLA 评审|(% style="width:409px" %)SLA的正式评审可以基于时间周期或事态进行触发（例如：客户请求，策略变更，服务评审或组织变革）。如果评审是基于时间的，并且客户和提供者都对SLA的内容以及条款和条件都感到满意，那么通常会确认SLA可以延长。如果客户的需求已经发生改变，则流程会基于重新定义的需求再次开始。最后，如果不再需要服务，则启动SLA退出。|(% style="width:486px" %)(((
532 532  SLA的正式评审可以基于时间和事态进行触发（例如客户请求、策略的改变、服务评审或组织变革）。
533 533  
534 534  在最初的SLA协商之后进行的第一次评审可能会导致SLA措词的改进，不涉及服务的变化。不管措词是否更改，修订后的SLA都应延续。如果客户的需求已经被更改，则流程可能会以重新定义的需求再次开始。最后，如果不再需要服务，则启动SLA退出。
... ... @@ -537,21 +537,22 @@
537 537  
538 538  （通常是服务所有者所有者和/或关系经理）。
539 539  )))
540 -|(% style="width:107px" %)SLA延长|(% colspan="2" style="width:829px" %)(((
556 +|(% style="width:117px" %)SLA延长|(% colspan="2" style="width:894px" %)(((
541 541  如果SLA被确认可以延长，则可能需要进行沟通和更改（例如，延长与供应商的支持合同）。这可以是完全自动化或部分自动化的。
542 542  
543 543  这些变更和沟通由服务级别触发，但需要其他实践完成。
544 544  )))
545 -|(% style="width:107px" %)SLA退出|(% style="width:367px" %)(((
561 +|(% style="width:117px" %)SLA退出|(% style="width:409px" %)(((
546 546  确认SLA退出后，服务提供者会启动所需的变更和沟通，以使用户无法使用约定的服务。更改和下线沟通可以是完全自动化或部分自动化。
547 547  
548 548  这些更改和沟通都是由服务级别管理实践所触发，但需要其他实践完成。
549 -)))|(% style="width:461px" %)(((
565 +)))|(% style="width:486px" %)(((
550 550  确认SLA退出后，服务提供者会启动所需的变更和沟通，以使用户无法使用约定的服务。
551 551  
552 552  这可能需要对所有类型的提供者的资源进行大量的手动和自动更改，也可能需要对消费者的资源进行更改。在某些情况下，这将会导致一个退出的项目或项目集。这些变更和沟通由服务级别管理实践所触发，但需要其他实践完成。
553 553  )))
554 554  
571 +
555 555  === **3.2.2 对服务级别和服务质量的监督** ===
556 556  
557 557  该流程专注于服务级别的监控和评审，以及服务质量，而不是SLA文档。根据约定的服务级别信息的质量和完整性，SLA在此流程中得到广泛使用。然而，在某些情况下，协议比较高阶且含糊不清，并且服务质量的监控和评估是基于不太结构化和不太客观的数据。无论采用哪种方式执行流程，服务提供者都需要监测和分析测得的服务级别的数据以及用户和客户的反馈，以更好地了解服务质量。
... ... @@ -584,6 +584,7 @@
584 584  服务改进倡议
585 585  )))
586 586  
604 +
587 587  图3.3 显示了流程的工作流程图
588 588  
589 589  (% style="text-align:center" %)
... ... @@ -630,6 +630,8 @@
630 630  )))
631 631  |(% colspan="3" style="width:1107px" %)服务级别管理活动由服务提供者和服务消费者执行，如表3.2和3.4所述。他们可能涉及供应商和合作伙伴。这些活动还受到许多工具和技术的支持（有时甚至是完全自动化或部分自动化）。所有内容都将在以下各节进行描述。
632 632  
651 +
652 +
633 633  ----
634 634  
635 635  = 4.组织和人员 =
... ... @@ -854,6 +854,7 @@
854 854  沟通和谈判
855 855  )))
856 856  
877 +
857 857  === **4.1.1 服务所有者所有者的角色** ===
858 858  
859 859  服务级别管理实践中最重要的角色是服务所有者。
... ... @@ -988,6 +988,8 @@
988 988  )))
989 989  
990 990  
1012 +
1013 +
991 991  ----
992 992  
993 993  = **6. 合作伙伴和供应商** =
深圳市艾拓先锋企业管理咨询有限公司