由 superadmin 于 2024/12/25, 15:40 最后修改
从版本< 9.1 >
由superadmin编辑
在2021/12/16, 12:35上
到版本
由superadmin编辑
在2021/12/16, 12:33上
< >
修改评论 该版本没有评论

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