服务级别管理流程分析_第1页
服务级别管理流程分析_第2页
服务级别管理流程分析_第3页
服务级别管理流程分析_第4页
服务级别管理流程分析_第5页
已阅读5页,还剩2页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、服务级别管理流程分析在一个it运维管理项目中,同事写给我关于服务级别管理一封邮件,作为项目管理制度体 系的参考框架。服务级别管理流程分析1、什么是服务级别管理(service level management)服务级别管理(service level management)是itil中的一个流程,属于itil中服务交付 范畴,它的kl标是要与客户就所要提供的it服务的类型和质量签订清晰的协议,并确保这 些协议得以实施。因此,服务级别管理需要有关客户需求、tt部门可提供的设施以及可供 利用的财务资源等方而的信息。服务级别管理是定义、协商、订约、检测和评审提供给客户的服务的质量水准的流程。冇关 所

2、提供的服务和这些服务的质量水准记录在服务级别协议中。服务级别协议规定了服务双方 各口的责任、权利和义务,是it服务成功运作的重要保障。在服务级别管理中需要明确一卜儿个基木概念:服务级别协议(sla)服务级别协议是it服务提供方和客八之间就服务提供中关键的服务目标及双方责任等有关 问题签订的协议。运营级别协议(ola)运营级别i办议是指tt服务提供方和组织内部it部门就某个具体服务项目的提供而达成的协 议,例如:网络的可用性、打卬机的可用性等支持合同(uc)支持合同是指it服务提供方与外部供应商就某一特定服务项冃的提供与支持所签订的协 议。服务级别需求(slr)服务级别需求是指有关客户业务需求的

3、详细定义,通常作为设计服务和制定服务级别协议的 一个蓝本。服务目录(sc)服务目录是从用户角度描述的服务项目以及有关服务级别的简单概要,例如:宕机时间、应 川中断时间等。服务说明书(sp)服务说明书描述了功能(与客户预订的)和技术(在tt部门内部实施的)之间的关系,并 为服务提供了一个详细的说明。服务改进方案(sip)服务改进方案通常作为一个项目來实施,定义了改进一项tt服务相关的活动、阶段和相应 的里程碑。服务质量计划(sqp)服务质量技术定义了服务管理流程和运营管理的流程参数,服务级别协议说明了我们应该提 供什么服务,服务质量技术则是关于我们应该怎么提供这些服务的。2、服务级别管理适用目标

4、服务级别管理确保客户需要的tt服务得到秩序的维护和改进,这些目标上要通过针对tt 部门的运作绩效进行协商、监控和报告,以及在1t部门及其客户z间建立有效的业务管理 來实现。有效的服务级别管理可以改进客户业务运作的绩效,并因此捉高客户满意度。大体上讲,服务级别管理的引进可以产生如下的效益:it服务可以被恰当的设让以满足定义在服务级别需求中的那些期望;服务绩效可以被测度;更好的控制资源管理,降低使用成本;提高客户满意度,建立更好的客户关系;客户和it部门清楚自身的定位,减少不必要的误会和疏忽;3、服务级别管理流程分析服务级别管理是围绕服务级别协议、运营级别协议和支持介同的签订、实施和考核等活动展

5、开的,基本的出发点是客户的业务需求。如下图所示:关键环节分析:(1)、服务级别管理实施初始化在服务级别管理实施的初级阶段,需要进行计划的制尬和一-系列的准备工作。主要的活动包 括:任命成立服务级別管理才i队,并为z分配必要的支持人员;迹行使命陈述,明确服务级别管理项目的目的;定义该项忖的h标和范围;举行概念推广活动,并向信息化运维/管理人员说明服务级别管理会在何吋对他们造成 什么样的影响。定义角色、任务和职责。活动、人员、资金、质量标准的量化。识别风险。制定服务目录和sla结构的计划。起草试运行的sla格式。识别支持工具,尤其是sla监控工具。和用户、内部服务提供者(tt部门内部)、外部服务提

6、供者(厂商)一起,设定统一 的事件优先级别和扩展路径(与服务台和问题管理札i联系)。(2)、识别、定义需求服务级别需求和服务级别协议制定是一个反复的过程。一旦sla结构得到认同,就必须 起草笫一个sla。在开始的时候要把用户包含进來,把笫一个人纲初稿作为一个起点來进行 更详细深入的讨论。需求是抽象的,很难描述,因为用户本身也许并不了解他们需要什么,特别是如果以前 没有问过这样的问题,这样在理解和定义其需求时就需要得到协助。还需要注意的一点是, 最初提出的盂求不一定是最终得到认m的盂求一一当考虑了预算控制等方式后,需求很有很 能发牛变化。在所追求的目标和所能实现、能承受的程度z间达到平衡z前,町

7、能需耍多次 谈判和修订。服务级别需求应当是服务设计标准中的主要部分,服务功能说明书也是其中的一部分。 它们应当从最开始就成为测试标准的一部分,一直出现在服务的设计、开发和完成各个阶段。 服务级别需求的草案应当随着服务本身不断的发展,并ii在服务真正投入到实际应用z前得 以定案。(3) 、生成服务h录信息系统的服务目录包括所有的it服务,并対每个it服务的特征和相应用户的详细资 料进行描述。编制tt服务|录的过程屮,需要采用一些调研和访谈來完成ii录的编制,同 时要和系统的用户进行良好的沟通,让用八接受这种顺利完成调研访谈的反馈。应包括对历 史文档的筛选、查找己完成的项目档案、与员工、信息系统的

8、用户迓行沟通、分析已获得的 信息以及与供应商进行交流,等等。通过1t服务支持流程的梳理和建立,配置管理数据库 (configuration management database, cmdb)或其他的数据库的建成,将成为整个it 服务i录编制过程屮重要的数据信息源。为了避免歧义,在服务目录中需要定义服务的层次结构,需要明确各种不同的服务类型, 例如,业务服务,基础设施服务,网络服务,以及应用服务(对系统用户不可见,但是支撑 系统用户服务的重要组成部分)。it系统服务目录编制完成后,其完幣的目录格式应包含矩阵、图衣以及电子数据表。下一 步需要把服务目录集成到配置管理数据库(cmdb)中,并将其维

9、护工作也作为配置管理数据 库的一部分。在配置管理过程中,将每个服务定义为一个配置项(configuration item, cl), 并且关联相应的服务形成目录的层次结构,这样就可以将发生的事件与具体的服务联系起 来。(4) 、制定服务级别协议在建立服务日录后,必须设计最介理的服务级别协议构架,以确保覆盖所有的服务和所 有的it系统的用户。构建sla的方法有三种主要方法:基于服务制定的每一个服务级别协议针对一个服务,除非不同的用户对同一个服务冇各不相同的 特殊要求。在这种情况下,同一个服务级别协议下需要设立不同的指标体系。签署服务级别 协议的时候,需要考虑到川户范围,让不同的川户范围代表签署。

10、或者町以采取分开签署不 同的协议来加以避免一些不必要的麻烦。基于用户确保一个服务级别协议只针对内部一个单独的川户群后,那么这个协议将包括用户使用 的所冇服务,能够包含所冇的服务和所冇的用户。从用户的角度來说,他们可能会倾向这种协议,其所有的需求都被包含在同一份文件里。一 般只要一次签字就可以了,这种比较简单,但是对服务级别管理项ii推动小组來说,町能工 作量会有所增加。多层次服务级别管理在服务级别协议初步稳定实施一段时间后,可以根据需要选择采用多层次sla结构。比 如类似以下三层结构:1. 公司层面:包含适介所有川户的人类服务级别管理问题。适川于比较稳定的服务, 系统不会频繁更迭和升级。2.

11、用户层面:包含所有与个别用八群体有关的服务级别管理问题,不管这个用八组使 用什么样的服务。3. 服务层面:针对中国移动通信内部某个特殊用八群体,以及与这个用八群体相关的 某个特殊服务。服务级別协议的制定流程如下图所示:服务级别管理项目组应将服务级别协议草案作为一个基础,然后根据需要与用八或用八 代表进行谈判,确定sla的最终内容以及初始的目标服务水平,还要与服务提供商进行谈判, 以确保这些内容和目标的实现。谈判対象应该是用户组的经理和熟悉系统的关键用户如果没有经历过服务级别管理,那么推荐从试点服务级别协议(pilot sla)开始。首 先要做出决定的是哪些服务/用户要从试点开始。如果被选择的用

12、户非常热心,并且愿意参 与一一可能因为他们渴望看到服务质量得到改进,这対试点非常有利。最初的用八感知调査 结果可能给合适的试点提供线索。需要注意的是避免选择存在大问题的领域作为试点。尽暈选择那些能快速见成效并能发 展服务级别管理流程的领域。试点应用的成功直接决定着将來能不能大面积推广,其至服务 级別管理项目的成败。整个sla制定过程中还应该考虑到的是tt提供商(不管是it提供商本身还是第三方提 供商)所派出的合意代表。他们必须判定h标是否现实、行不行得通以及预算上值不值得。 在谈判阶段,也应该征求提供商的观点,任何冇关协议方面的内容都要进行记录。一旦试点完成,而且最初的困难也被克服后,就要逐步

13、向其他的服务/用户介绍服务级 别协议。如果从一开始就决定要实现一个多层结构,那么在试点初始阶段就要先为所有用户 找出问题,尽量想周全些。当然在试点阶段対这些问题进行试验也是值得的。还冇一点要确保的是,在起草和谈判流程结束时,服务级别协议必须由能够代表组织/ 部门的相关人士签字。多方的承诺可以保证所有人都会尽力去完成这个协议。一般來说,签 字代表人级别越高,承诺就越可靠。一旦服务级别协议签署好,要做的事就是进行人量公开 宣传,确保用户和it提供商意识到此协议以及其主要日标的存在。(5)、明确运营级别协议和支持合同服务级别管理的实施计划必须根据与外部服务供应商所制订的支持合同以及与内部tt 支持人

14、员所达成的运作级别协议来制定,从而能够保证对服务级别协议中的基础性服务的支 持。任何现有的uc或ola必须在设计过程屮得到修改,每一个相关的人员都必须清处任何 一份适用于某项特定的服务供应的uc或olao(6)、服务级别管理的实施监控建立slaz后,必须建立起冇效的监控机制,并对监测指标达成共识。如果缺乏冇效的 监控机制,服务级别管理项目小组可能会在实施slm过程中招致各种争端,影响到项日实施 成功的信心。然而,许多企业的实践证明该过程是非常因难的,不仅体现在财务上的成本投 入,还由于对原有企业文化的冲击而造成某些负面影响,可能会给信息化办公室增加额外的 负担,建立监控机制时非常关键的一点是,

15、要能监控用户感知到的服务。而事实上这一点也 是最难达到的。如果不能对影响服务水平的所冇因素进行监控,就不能保证用户最终获得的 服务。同样的,用八遇到困难时,也需要及吋向服务级别管理项日小组反映,通过双方互动 不断完善监控机制。(7)、服务级别管理的监控报告一口 sla达成,必须开始进行监控并制作服务成绩报告。必须经常性地制作运营报告(每 h其至可能更频繁),并在可能的情况下,如果违反了 sla(或是因为制定了适当的阈 限而得以预警,sla受到威胁的惜况下)将牛成例外报告。在对sla评审前,服务级别管理项目小组必须制作定期报告并将具传递给用户或者用户 代表,以及it运行维护的工作人员,这样可以保

16、证任何疑问或争执可以在评审会议z前得 以解决。那么会议就不会因为这些问题而发生方向性偏移。定期报告应该体现对照sla hl标的绩效细节以及任何趋势性或为改进服务质量所采取的特 殊行动的详细内容。监控报告可以作为对it运维的绩效考核以及评审供应商合同履行状况 使用。(8)、服务评审与改进针対sla的报告机制,时间间隔和报告形式必须明确定义并取得用八的认同。为保证服 务级别管理的冇效进行,应定期召开评审会,和全体用户或者用户代表一起回顾上一阶段的 服务绩效,并预先了解下一阶段的可能出现的任何问题。服务评审会议的频度和形式也同样 需要川户的认可。推荐采川规律性间隔。定期的报告应该与评估周期相匹配。这样的会议应 该每月举行,最少也要每季度举行一次。服务级别管理项目小组应该合理采纳用户以及供应商的意见,以改进sla中那些没有达 到忖标的薄弱环节。对每次服务回顾评审会议的内容都应该详细加以记录,并在下一次会议 上冋顾所获得的进步,以确立有关行动事项已被后续跟进,并被很好的执行。根据在评审会中发

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论