全球专业中文经管百科,由121,994位网友共同编写而成,共计436,047个条目

服务级别管理

用手机看条目

出自 MBA智库百科(https://wiki.mbalib.com/)

服务级别管理(Service-level Management)

目录

什么是服务级别管理

  服务级别管理是指对一个组织的服务质量(QOS)的关键绩效指标KPI)的监视和管理。关键绩效指标从粗糙的可效性和使用统计到详细的组织所含的每个服务指标。服务级别管理涉及实际绩效跟预定期望之间的比较、决定适当的行动以及产生有意义的报告。服务级别管理向给定组织方案提供一种质量“适宜范围”。

  服务级别管理是ITIL中的一个流程,属于ITIL中服务交付范畴,它的目标是要与客户就所要提供的IT服务的类型和质量签订清晰的协议,并确保这些协议得以实施。因此,服务级别管理需要有关客户需求、IT部门可提供的设施以及可供利用的财务资源等方面的信息

  服务级别管理是定义协商、订约、检测和评审提供给客户的服务的质量水准的流程。有关所提供的服务和这些服务的质量水准记录在服务级别协议中。服务级别协议规定服务双方各自的责任权利和义务,是IT服务成功运作的重要保障。[1]

服务级别管理适用目标

  服务级别管理确保客户需要的IT服务得到秩序的维护和改进,这些目标主要通过针对IT部门的运作绩效进行协商、监控和报告,以及在IT部门及其客户之间建立有效的业务管理来实现。有效的服务级别管理可以改进客户业务运作的绩效,并因此提高客户满意度

  大体上讲,服务级别管理的引进可以产生如下的效益[1]

  IT服务可以被恰当的设计以满足定义在服务级别需求中的那些期望;

  服务绩效可以被测度

  更好的控制资源管理,降低使用成本

  提高客户满意度,建立更好的客户关系

  客户和IT部门清楚自身的定位,减少不必要的误会和疏忽;

服务级别管理流程分析[1]

  服务级别管理是围绕服务级别协议、运营级别协议和支持合同的签订、实施和考核等活动展开的,基本的出发点是客户的业务需求。

  关键环节分析:

  1、服务级别管理实施初始化

  在服务级别管理实施的初级阶段,需要进行计划的制定和一系列的准备工作。主要的活动包括:

  任命成立服务级别管理团队,并为之分配必要的支持人员;

  进行使命陈述,明确服务级别管理项目的目的;

  定义该项目的目标和范围;

  举行概念推广活动,并向信息化运维/管理人员说明服务级别管理会在何时对他们造成什么样的影响。

  定义角色、任务和职责。

  活动、人员、资金、质量标准的量化。

  识别风险。

  制定服务目录和SLA结构的计划

  起草试运行的SLA格式。

  识别支持工具,尤其是SLA监控工具。

  和用户、内部服务提供者(IT部门内部)、外部服务提供者(厂商)一起,设定统一的事件优先级别和扩展路径(与服务台和问题管理相联系)。

  2、识别、定义需求

  服务级别需求和服务级别协议制定是一个反复的过程。一旦SLA结构得到认同,就必须起草第一个SLA。在开始的时候要把用户包含进来,把第一个大纲初稿作为一个起点来进行更详细深入的讨论。

  需求是抽象的,很难描述,因为用户本身也许并不了解他们需要什么,特别是如果以前没有问过这样的问题,这样在理解和定义其需求时就需要得到协助。还需要注意的一点是,最初提出的需求不一定是最终得到认可的需求——当考虑了预算控制等方式后,需求很有很能发生变化。在所追求的目标和所能实现、能承受的程度之间达到平衡之前,可能需要多次谈判和修订。

  服务级别需求应当是服务设计标准中的主要部分,服务功能说明书也是其中的一部分。它们应当从最开始就成为测试标准的一部分,一直出现在服务的设计、开发和完成各个阶段。服务级别需求的草案应当随着服务本身不断的发展,并且在服务真正投入到实际应用之前得以定案。

  3、生成服务目录

  信息系统的服务目录包括所有的IT服务,并对每个IT服务的特征和相应用户的详细资料进行描述。编制IT服务目录的过程中,需要采用一些调研和访谈来完成目录的编制,同时要和系统的用户进行良好的沟通,让用户接受这种顺利完成调研访谈的反馈。应包括对历史文档的筛选、查找已完成的项目档案、与员工、信息系统的用户进行沟通、分析已获得的信息以及与供应商进行交流,等等。通过IT服务支持流程的梳理和建立,配置管理数据库(Configuration Management Database,CMDB)或其他的数据库的建成,将成为整个IT服务目录编制过程中重要的数据信息源。

  为了避免歧义,在服务目录中需要定义服务的层次结构,需要明确各种不同的服务类型,例如,业务服务,基础设施服务,网络服务,以及应用服务(对系统用户不可见,但是支撑系统用户服务的重要组成部分)。

  IT系统服务目录编制完成后,其完整的目录格式应包含矩阵、图表以及电子数据表。下一步需要把服务目录集成到配置管理数据库(CMDB)中,并将其维护工作也作为配置管理数据库的一部分。在配置管理过程中,将每个服务定义为一个配置项(Configuration Item,CI),并且关联相应的服务形成目录的层次结构,这样就可以将发生的事件与具体的服务联系起来。

  4、制定服务级别协议

  在建立服务目录后,必须设计最合理的服务级别协议构架,以确保覆盖所有的服务和所有的IT系统的用户。构建SLA的方法有三种主要方法:

  基于服务

  制定的每一个服务级别协议针对一个服务,除非不同的用户对同一个服务有各不相同的特殊要求。在这种情况下,同一个服务级别协议下需要设立不同的指标体系。签署服务级别协议的时候,需要考虑到用户范围,让不同的用户范围代表签署。或者可以采取分开签署不同的协议来加以避免一些不必要的麻烦。

  基于用户

  确保一个服务级别协议只针对内部一个单独的用户群后,那么这个协议将包括用户使用的所有服务,能够包含所有的服务和所有的用户。

  从用户的角度来说,他们可能会倾向这种协议,其所有的需求都被包含在同一份文件里。一般只要一次签字就可以了,这种比较简单,但是对服务级别管理项目推动小组来说,可能工作量会有所增加。

  多层次服务级别管理

  在服务级别协议初步稳定实施一段时间后,可以根据需要选择采用多层次SLA结构。比如类似以下三层结构

  (1)公司层面:包含适合所有用户的大类服务级别管理问题。适用于比较稳定的服务,系统不会频繁更迭和升级。

  (2)用户层面:包含所有与个别用户群体有关的服务级别管理问题,不管这个用户组使用什么样的服务。

  (3)服务层面:针对中国移动通信内部某个特殊用户群体,以及与这个用户群体相关的某个特殊服务。

  服务级别管理项目组应将服务级别协议草案作为一个基础,然后根据需要与用户或用户代表进行谈判,确定SLA的最终内容以及初始的目标服务水平,还要与服务提供商进行谈判,以确保这些内容和目标的实现。谈判对象应该是用户组的经理和熟悉系统的关键用户

  如果没有经历过服务级别管理,那么推荐从试点服务级别协议(Pilot SLA)开始。首先要做出决定的是哪些服务/用户要从试点开始。如果被选择的用户非常热心,并且愿意参与——可能因为他们渴望看到服务质量得到改进,这对试点非常有利。最初的用户感知调查结果能给合适的试点提供线索。

  需要注意的是避免选择存在大问题的领域作为试点。尽量选择那些能快速见成效并能发展服务级别管理流程的领域。试点应用的成功直接决定着将来能不能大面积推广,甚至服务级别管理项目的成败。

  整个SLA制定过程中还应该考虑到的是IT提供商(不管是IT提供商本身还是第三方提供商)所派出的合意代表。他们必须判定目标是否现实、行不行得通以及预算上值不值得。在谈判阶段,也应该征求提供商的观点,任何有关协议方面的内容都要进行记录。

  一旦试点完成,而且最初的困难也被克服后,就要逐步向其他的服务/用户介绍服务级别协议。如果从一开始就决定要实现一个多层结构,那么在试点初始阶段就要先为所有用户找出问题,尽量想周全些。当然在试点阶段对这些问题进行试验也是值得的。

  还有一点要确保的是,在起草和谈判流程结束时,服务级别协议必须由能够代表组织/部门的相关人士签字。多方的承诺可以保证所有人都会尽力去完成这个协议。一般来说,签字代表人级别越高,承诺就越可靠。一旦服务级别协议签署好,要做的事就是进行大量公开宣传,确保用户和IT提供商意识到此协议以及其主要目标的存在。

  5、明确运营级别协议和支持合同

  服务级别管理的实施计划必须根据与外部服务供应商所制订的支持合同以及与内部IT支持人员所达成的运作级别协议来制定,从而能够保证对服务级别协议中的基础性服务的支任何现有的UC或OLA必须在设计过程中得到修改,每一个相关的人员都必须清楚任何一份适用于某项特定的服务供应的UC或OLA。

  6、服务级别管理的实施监控

  建立SLA之后,必须建立起有效的监控机制,并对监测指标达成共识。如果缺乏有效的监控机制,服务级别管理项目小组可能会在实施SLM过程中招致各种争端,影响到项目实施成功的信心。然而,许多企业的实践证明该过程是非常困难的,不仅体现在财务上的成本投入,还由于对原有企业文化的冲击而造成某些负面影响,可能会给信息化办公室增加额外的负担,建立监控机制时非常关键的一点是,要能监控用户感知到的服务。而事实上这一点也是最难达到的。如果不能对影响服务水平的所有因素进行监控,就不能保证用户最终获得的服务。同样的,用户遇到困难时,也需要及时向服务级别管理项目小组反映,通过双方互动不断完善监控机制。

  7、服务级别管理的监控报告

  一旦SLA达成,必须开始进行监控并制作服务成绩报告。必须经常性地制作运营报告(每日——甚至可能更频繁),并在可能的情况下,如果违反了SLA(或是因为制定了适当的阈限而得以预警,SLA受到威胁的情况下)将生成例外报告。

  在对SLA评审前,服务级别管理项目小组必须制作定期报告并将其传递给用户或者用户代表,以及IT运行维护的工作人员,这样可以保证任何疑问或争执可以在评审会议之前得以解决。那么会议就不会因为这些问题而发生方向性偏移。

  定期报告应该体现对照SLA目标的绩效细节以及任何趋势性或为改进服务质量所采取的特殊行动的详细内容。监控报告可以作为对IT运维绩效考核以及评审供应商合同履行状况使用。

  8、服务评审与改进

  针对SLA的报告机制,时间间隔和报告形式必须明确定义并取得用户的认同。为保证服务级别管理的有效进行,应定期召开评审会,和全体用户或者用户代表一起回顾上一阶段的服务绩效,并预先了解下一阶段的可能出现的任何问题。服务评审会议的频度和形式也同样需要用户的认可。推荐采用规律性间隔。定期的报告应该与评估周期相匹配。这样的会议应该每月举行,最少也要每季度举行一次。

  服务级别管理项目小组应该合理采纳用户以及供应商的意见,以改进SLA中那些没有达到目标的薄弱环节。对每次服务回顾评审会议的内容都应该详细加以记录,并在下一次会议上回顾所获得的进步,以确定有关行动事项已被后续跟进,并被很好的执行。

  根据在评审会中发现的问题,可以确定对服务质量产生逆向冲击的潜在困难,服务级别管理必须结合问题管理和可用性管理,对于任何可以克服困难和重塑服务质量的行为,都应当加入到服务改进计划中确定和实施。服务改进计划的行动也可以关注诸如用户培训、系统检测和文件等问题。这些问题应该涉及相关的人员,并获得适当的反馈,以便于在未来改进。如果把IT运维服务外包给第三方,应当在一开始就把服务改进的问题提出来,并在合同(以及预算)中包含进去,否则,如果供应商已经履行了合同的义务,而改善服务又要产生额外的费用的话,他们就没有动力在合同期内改进服务。

参考文献

本条目对我有帮助2
MBA智库APP

扫一扫,下载MBA智库APP

分享到:
  如果您认为本条目还有待完善,需要补充新内容或修改错误内容,请编辑条目投诉举报

本条目由以下用户参与贡献

Tracy,刘维燎,nonameh.

评论(共0条)

提示:评论内容为网友针对条目"服务级别管理"展开的讨论,与本站观点立场无关。

发表评论请文明上网,理性发言并遵守有关规定。

打开APP

以上内容根据网友推荐自动排序生成

官方社群
下载APP

闽公网安备 35020302032707号