ITIL V3 路漫漫其修远兮
所谓实施了ITIL V3其实不是一个规范的说法,因为ITIL V3也是一个框架库,用户完全可以选择其中某一部分有用的来实施,可以采纳并修改,这属于局部实施,还有一种更常见的,就是可以选出一些流程组和职能组,结合一些ITIL V3概念形成一套贴合自己的管理模式,这属于项目制实施,CIO时代网 :各位网友大家好,欢迎收看CIO时代网推出的信息化百家讲坛栏目。我是 李军侠,本期栏目我们很荣幸的邀请到了上海翰纬信息管理咨询有限公司高级讲师刘颋刘老师,刘老师同时也是翰纬咨询高级咨询顾问及培训部交付经理,在IT服务管理领域具有丰富的理论和实践经验。那么我们本期的话题是关于IT服务管理中最佳实践框架ITIL V3的落地与实施。那么首先有请刘老师做一下简单的自我介绍。
我个人的经历比较复杂,在IT这个行业内经过了十多年的历练,其中工作包括IT运维工作、开发工作、管理工作甚至有许多工作是与业务相关。那么最近几年来我主要的精力是放在ITSM这个专业领域内,包括培训工作、项目咨询以及研究工作。最近比较忙,重要的工作是参加撰写中国IT服务管理标准,以及即将推出的《IT服务指南二》,这也是行业内大家比较瞩目的一套出版物,我也是主编之一,最近当然有一些项目也在做,包括上海理想、首信、阿里巴巴等项目中也不同程度地担当一些重要的咨询工作,另外课程排的比较紧,这就是我的一些个人经历。
CIO时代网 : 作为业内人士都知道,ITIL V3 于 2007 年 5 月 31 日 全球首发,将生命周期原理贯穿于实践,它把IT上升到企业战略资产管理的高度,充分展示了IT服务的价值。 刘老师作为IT服务管理领域的专家,对于ITIL V3应该有比较深刻的理解,可否给我们做一些讲解?
刘颋:作为专家我觉得有些过了,在业内很少有人自称为专家的,大家都本着解决实际问题的心态去投入到这个领域,但是对于ITIL V3的这个领域我是很乐意来分享的,因为翰纬是最早将ITIL V3本地化的机构之一,当时我也作为编写者之一,我们最早把它引入到中国来本土化。对于ITIL尽管才推出第三个版本,但它的历史是非常悠久了, ITIL的全称是IT Infrastructure Library,意为IT基础架构库,我们一般称之为IT服务的最佳实践框架,因为它来自于最佳实践,而且也跟一个历史事件有关系。在八十年代初期的时候, ITIL V1版本便推出来了,在ITIL V1推出来的时候,有三四十本书,我能找到的是三十七本书,那么这里面描述了很多最佳实践,最早推出来的是职能化管理概念,对于当时来说,进步意义还是很大的,在99年前后,英国商务部OGC正式的把它买过来,开发出了ITIL V2,就是我们很经典的十个流程加一个职能,那么不管ITIL 自身承不承认,他把ITIL 开发成为十个流程,以至于我们在内的不少业内人士都习惯性地把实施了哪些流程来体现是否实施了ITIL,这是V2的一个经典之作,发展到现在也有十年了。
ITIL V3的发展我曾经在不同场合表达过我的看法,我认为最大的改变在于三方面:
第一个就像你刚才也提到的引入了服务生命周期的概念,原来 ITIL V2是一种草根文化,是自下而上的发布,另外是阶段性的,好比是只列出了人生中的小学和大学,但是对于人生前乃至胎教,人生后包括墓志铭其实都应该纳入到生命周期里来,ITIL V3将服务全生命周期引入进来后,把服务战略直到服务改进都纳入体系,这无疑是一个非常有意义的事情,使得IT服务管理更体系化了,这点改变是非常大的,非常值得我们去探索的。
第二方面是它更加强调价值观,它使得我们IT服务更加以价值为中心,每一个章节,每一个细节,它甚至将很多流程都淡化了,他讲了很多概念化的东西,而流程却减少了篇幅,这对我们后面具体实施上其实也带来了一些挑战。
第三个改变是在流程上做了很多细化拓展的工作,这点我觉得也是非常优秀的。那么这是我对ITIL V3正面的三个看法。
CIO时代网 :ITIL V3是引入中国了,但是大家真正比较关心的还是ITIL V3从07年引入中国到目前两年来实施状况如何?在现实中是否真的是掷地有声?
刘颋:像你这个问题,我几乎每天都会遇到,刚才我提到了我对ITIL V3有三个正面的看法,言下之意当然还有一些负面的看法,这个暂且不多提,不过有一点我想首先可以纠正一点,所谓实施了ITIL V3其实不是一个规范的说法,因为ITIL V3也是一个框架库,你完全可以选择其中某一部分对你有用的来实施,你可以采纳并修改,这属于局部实施,还有一种更常见的,也是我个人经常实施的,就是你可以选出一些流程组和职能组,结合一些ITIL V3概念形成一套贴合自己的管理模式,这属于项目制实施,还有一种实施就是完全按照ITIL的套路来梳理,我们姑且称为全面实施,这点实际上在全世界可以说是凤毛麟角,其实也不存在,大部分企业都会根据自身的情况作相应的调整。所以说这点是首先需要明确的,到底什么叫实施ITIL V3。那么大家很关注的应该是尝试做的事情,在业内我至少听过两家外资企业说他们实施了ITIL,其中一家在我实际的考察中发现,他们只不过是列出了很多流程经理的称谓,但在全面建设上,实际上还只处于规划阶段,另外有一家企业不屑地说,ITIL V3是学习他们的,是采用了他们的实践。这点我相信,因为ITIL V3本来就采用了很多业内的最佳实践。但这是否等同于我们所说的“实施”了ITIL V3呢?
提到ITIL 的实施,你首先要清楚ITIL V3本身是取决于最佳实践的,它具有一些重叠性并不意外,另外OGC或者ITSMF他们把这些最佳实践形成一个框架,理论化,毕竟现在才两年时间,而ITIL V2十年了,但其实落地较多的还是我们常说的五加一,就是服务支持中的流程以及服务级别管理, 当然还有服务台是和事件管理一起来做的,算在服务支持块里。你也不能说全部实施了ITIL V2,所以对于ITIL V3的实施,我只能说大家在探索中,并且在逐步实施中,并且我未来想要全面实施ITIL V3,全面符合ITIL V3,恐怕这种可能还是比较小的。这是我的一个基本的看法。
CIO时代网 :听您讲了这么多, ITIL V3实施起来其实不是那么容易,感觉还是道路漫长的感觉,但是目前来说如果作为企业的实践者来说,最想要听的还是具体实施的方法,刘老师在这方面能否给一些建议?
刘颋:这两年我们与很多实践者和探索者也在努力做很多事情,那么我想在接下来的时间我们可以花点时间把ITIL V3整个生命周期中的每个模块,到底我该怎么做,或者说别人怎么做,咱们倒是可以来探讨一下,希望能够给大家一些提示。
首先ITIL V3分为五个模块,就是大家所熟知的服务战略,服务设计,服务转换,服务运营和服务改进。那么我曾经做过一个比喻,它好比装修房子的一个过程。
服务战略
那么首先服务战略这个模块,这个模块是大家争议比较多的一块,这个模块的实施最首先感觉的一点就是比较难以把握,因为我的结论是并不是一个企业没有实施,而是往往实施之后的结论很简单,比如说一个公司的这块做的比较好,但是最后可能也只会归纳成为一句话:某某企业有效利用自身某某资源与某某能力,将某某产品与某某服务转换为具有效果与保障的价值,传递给某某客户,中间产生了很多utility,就是效果,有很多security,就是保障。客户很满意,投资方很赚钱,好像就结束了,这是这个部分的特点。但是实际上,这部分已经有很多成功案例,在ITIL V3以前就有了。我举一个简单的例子,比如移动公司,针对年轻人、老百姓和商务人士,根据各个群体的移动使用业务,制定出动感地带、神州行、商务通等不同的套餐。这个其实是一个非常有效的战略之一,在ITIL V3的服务战略的需求管理中,则可以体现为PBA结合UP产生SLP。 这个模块的实施是很模糊的,我的看法是:如果我们企业或者IT组织的相关管理者,能根据ITIL V3服务战略中的指导方向,有效调配我们的资源与能力,识别服务资产的类别,了解产品组合的基本方法,最终,很重要的是,能将服务真正产品化,市场化,价值化,我认为这就是实施了ITIL V3的服务战略。这个模块不同于另外一些以流程为主的模块,通篇几乎就没有明确的流程,所以这个部分成功实施不等于说我们做了什么流程。好比我们看了德鲁克的管理学,你说有没有实施呢?我们实施了,可能体现在决策之中,我们的交付物将会是决策的结果,而并非流程手册。所以说这块的实施如果企业能够根据ITIL V3的指导思想,能够理解什么是我的资源,什么是我的能力,什么是我的产品组合,什么是我的市场需求,什么是我的价值共产化,最重要的一点是你能不能产生一个服务产品化,我觉得如果能够做的话就是在实施。(根据现有资源和自己的能力,组合产生有需求的产品)
服务设计
关于服务设计这个模块,我们不会陌生,包括V2时期的服务级别管理、可用性管理、能力管理以及可持续性管理,这些流程虽然不陌生,但是除了服务级别管理外全面实施的本来就不多,原因是牵涉面较大,无法协调管理,但平时日常工作中,这些工作一点也没有少做,重要的是没有形成规范流程而已,这也和大部分ITIL工具只擅长工作流,不擅长价值判断有很大关系。值得注意的是,这个部分加了三个流程,一个是服务目录管理、一个是供应商管理,还有一个是安全管理。这都是很有价值,尤其是服务目录管理,我们几年前就开始在很多企业的服务级别管理当中去实施过,最近几年随着服务产品化的推出,我们的工作更多了,互联网行业由于特殊性,在这方面走得比较早,有一些企业在我们带动下,内部也逐步形成了服务目录制定的热潮,我一度把服务目录和知识库、配置管理数据库称为三个最难逾越但最值得逾越的难关。服务目录实施中最重要的是要理解一个浅显的道理,就是能让客户看明白和用明白。除了互联网企业,有些企业开始印刷了一些以服务为导向Catalog,很好,虽然产品体系没有建立,但是感觉对了,还有的企业做了很细致的产品操作说明,这点要注意了,这可以作为产品目录的一部分,但是切忌只有自己能看懂。
供应商管理的落地不多,因为机会不多,很多IT组织的采购工作会由一些采购部门进行,不过他们可能没有意识到,ITIL V3很有可能涉及到的部门并非只是IT部门,这个以后还可以谈。关于安全管理,其实从V1开始一直有,不过一直有些姥姥不疼舅舅不爱,我觉得重点在于这些内容更多是关注在一些政策上,而实际中的安全管理需要落地到技术才有用。很多年前,我们慕名从国外花了一千多人民币,买了本相关的书未来,一百多页,看了半天,大家只得出一个结论:就是IT信息安全管理很重要。然后没了,我们当即无语。其实服务设计这本书是我个人比较喜欢的书,除了一些流程的设计外,很多有用的模型如RACI等等流程外的内容也很有用。我建议有了一定规模的IT组织好好学习这个部分,有些地方可以开始实施起来了。
服务转换
服务转换部分包含大家熟悉的配置与资产管理、发布与部署管理以及变更管理,同时加了知识管理、评估、验证与测试等一些流程。首先我们说说原来V2有的三个流程,发布与变更我们很多时候是作为一个项目来实施的,配置管理则一般基于建设CMDB作为关键点,均是比较难实施的流程,重点在于它不仅仅只是设计流程那么简单,还需要最大限度考虑组织的组织架构以及组件架构,更难的是遵行与维护,我们几度访谈以往的客户,往往在后期不能加强管理,使得这些流程和模型变成鸡肋,不管是V2还是V3,这都是我们要重点去关注的,我可以讲一个案例,有个企业最初有四个小组,他们的小组长很愿意实施变更管理,因为老是变更有冲突,后来他们直接都担任变更经理,有一位作为主导者来召开CAB,变更经理们负责录单和分配工作,按道理没有问题。但几个月后我们去回访,发现里面单子填写得敷衍了事,服务台也反映仍然有多次变更冲突事件。原因呢?其实这几个组长很苦恼,因为他们工作太忙,填单的事情太复杂。好吧,那么就请个专职的变更经理,但烦事又来了,他们希望这位未来的变更经理,又要懂技术,又要懂流程,又要会沟通,又要能铁面无私,技术还得不比他们差,结果每天做录单的活……这个事情我估计我也不愿意干。其实变更经理真的要是多面手吗?他其实重点在于流程的熟悉与KPI的熟悉,并且能有基本的IT知识,有主持CAB的能力是关键。在我们帮助下,他们逐步改变了招聘政策--案例是次要的,问题是,如果我们不回访,谁会去逐步改进这个流程呢?所以这几个流程实施还是很有挑战的,这和V2还是V3的关系不是太大。不过另外几个流程就是新增的流程,我很难回答大家有没有实施它,因为它本来就是从很多软件开发环境中采纳的最佳实践,这个部分的落实关键点不是流程,而在于开发与运维的关系,现在IT服务管理中非常难的一个事情是,明明IT开发工作是服务交付的重要一环,但偏偏运维经理几乎就无法调用开发人员的资源,并且开发人员长期以来对于什么是故障,什么是问题,什么需要快速处理哪怕只是用应急措施,什么需要根本解决也处于相对茫然。所以对于其它的大部分流程来说,难点其实就是在于组织间的整合,倒并非是流程的采纳。
另外有一点很重要的是,知识系统管理,知识库的建设是业内常讨论的话题,知识系统管理的野心远远大于知识库,它几乎包含了ITIL V3的所有相关数据与信息乃至支持系统,但我们现实中实施更多的还是知识库,知识库的建设是个永恒的话题,我们这次就不多提。
运营管理
接下来就是原来实施得最多的运营管理,这个部分事件管理,服务台,问题管理可以讲是ITIL里面的老兵,如果你了解过ITIL,你就不可能没有听说过它们,不过这次ITIL V3加了三个流程,一个是服务请求实施,一个是安全访问,一个是事件管理,这个事件管理是event management,先谈谈最后的Event management,这个流程我们尝试在一些企业实施过了,我们可以理解为是故障,问题,变更前的一个哨兵,比如设定一些阈值,超过了某个阈值是记录呢还是自动响应,还是说转往故障管理流程。这个流程实施不难,很多企业自己都有,就是没有规范化,对工具的依赖性很强,我也曾考虑过是否需要专门设定这样的流程。安全访问流程其实也被很多企业在技术上采纳了,只是没有规范起来,而服务请求实施就是把一些服务请求,如标准变更,密码修改,咨询,文档要求等一些非故障类事情单独设流程。有些企业也实施了,比如他们把该类请求转到一个专门的部门,对于这个部门主要是考核客户满意度,不着重考核平均修复时间。其实这几个新添的流程从很大意义上是考虑到了呼叫处理的多样性,在以往我们实施的案例中,都或多或少涉及过。至于如今是否需要新设流程,我觉得要根据实际情况来分析。
服务改进
最后一个模块是服务改进,和服务战略有类似的地方,里面更多的是方法论,一堆方法论足以让你们看得头晕。但是优化改进是很重要的,这个部分如何实施?我觉得当你打算进行优化的时候,就已经开始实施了,因为你实施中可以根据ITIL提供的一些方法论和模型进行指导即可,中间的细节工作,如考核,考评还是要根据实际情况来。对于服务改进,也是一个非流程的实施单元,而是个思想实施与参考实施的单元。
CIO时代网 :刘老师不亏是ITIL V3实施的专家,给出这么多的关于实施的真知灼见。假如实施一个系统的话,会考虑实施是否成功,那么就ITIL V3实施的话怎么样才算是成功了?这个有没有一个可以借以判断的标准?
刘颋:首先ISO20000确实是itSMF与国际标准组织来评估IT组织IT服务管理水平的一种方法,不过,大家都知道在中国无论是企业还是个人,都很擅长应对“考试”,所以我们往往存在尽管ISO20000通过了却未必意味着内部管理提升的现实。因而我们一般做项目的时候会根据实际情况来选择对组织的“关键流程”进行细化处理,已达到效果。
至于说什么是ITIL的成功案例,这个问题你会觉得很有趣,因为我知道很多企业都会把他们实施过的案例都称为成功案例,比如有个着名的保险公司,曾经于五年前几乎全面实施ITIL,被誉为成功案例,但在一个月,我和他们的关键人聊起来,他们很痛苦的是,如果企业因为工具等方面的原因,开始全面抵制ITIL,新的领导甚至提出了“赶走ITIL,还我实效”的口号,作为最佳实践的框架,被人称为不实际是很可悲的,但是这个现象也是广泛的。你能说我会承认这是成功案例吗?
重点在于,ITIL的实施不能完全是项目制的,而是长期要进行的,需要定期的优化,定期的改进。
所以你要问我心目中什么是ITIL的成功案例?
我会说,首先跑起来了,在一定时期内能得到有效反馈,有专人,根据各种指标进行问题分析和优化改进,能逐步为客户、员工及相关利益者所接受,最终产生价值。
所以即便在翰纬,成功案例只是一个相对值,如果哪个企业由于主动或被动去放弃优化改进,我们都很难称之为成功案例。
当然在我心目中,我们和阿斯利康、阿里巴巴、浦发银行、佛山电力、上海电信以及各地一些移动公司、地铁公司等大概几十个企业做的项目,个人还是比较满意的,因为我们形成了一种共同创造价值的文化,只要有这种文化,就意味着改进会不断进行,这种持续改进则是我心目中的成功案例。
CIO时代网 :刚刘老师提到了有很多案例是比较成功的,但是成功判断也是有一定的,ITIL V3实施了,也成功运营了,但是能不够给企业带来预期的绩效呢?运维绩效评估也是我们比较关注的,绩效评估是否也有一些具体的实施方法或者流程?
刘颋:你的意思我明白就是说你说你是一个成功的人士,为了建设与改进一些流程和模型,我们确确实实地采用了许多评估方法。一般的评估方法是采用PPT结构,即Process流程,People人,Technology&Tools工具与技术的方面进行。
对于工具的评估,有很多方法,不过我们一般是把它作为流程评估的一部分来进行。
对于流程的评估我们是比较熟悉的,一般采用的是将一些成熟的模型对应到一些定制化的问题上,而我们访谈的时候,也并非采用机械式的问答,而是采用开放式的问题,利用我们的经验逐步将开放问题映射到既定问题上,然后做周密的差距分析,从科学的方法得出正确的结论。这种方法也是我们大多数咨询项目与研究项目中的方法,我在授课时也偶尔会将一些自己在项目中的实例拿来帮助学员理解知识的实践方法。
重点要谈一谈People这一块,对于人员的评估,存在不少的挑战,尽管有很多人力资源的管理方法论和模型,但是对于IT人员,尤其是IT服务人员的评估方法是很匮乏的。但是IT服务人员的价值急需得以体现,不然就会出现他做了一百件好事情没有人说好,做错一件事情天天有人追着跑,还有很多吃力不讨好的事情。但是现在很多人是通过对部门的考核或流程的考核来考核人,或者根据技术岗位来考核,这不是很公平的,比如说,服务台的人员考核不应该专以技术来考核,单纯考核客户满意度和平均修复时间也未必是最科学的。当然这有难度,第一难在服务的特质,二难在这类岗位本来就没有标准规范。这点ITIL V3试图做到,比如大家可以去细读服务运营这本书里面,除了服务台,它加了三个职能,是技术管理,应用管理和运营管理,就提到了很多相关的Responsibility,但是即便如此,它没有,也不大可能有去映射到具体岗位的评估。
不过现在还好,因为在我们主编的中国IT服务管理标准中,特别提到了IT服务人员的岗位设定,如IT服务产品经理、IT服务销售经理等以往大家一直在做,但很少定义的位置。
所以我们正在开发一套ITHRM的体系,不久就会和大家见面,为此包括我在内的不少同事也正在一起开发IT服务人才培养方案,希望这些行为都能给大家做绩效评估提供一些有价值的方法。
CIO时代网 :由于时间关系,我们只能讲到这里,但是关于ITIL V3实施我想刘老师是不是能够提几点最关键的建议?
刘颋:是啊,时间真快,不过和我平时的工作比,今天讲的内容其实真不多,在有限的时间内,我能讲的也就这些了,希望大家不要见怪。象李 刚才提到希望我能归纳几条ITIL,尤其是ITIL V3实施的建议,我想,这样一个高效运作的大机器,一定不会是几条建议就能解决根本问题的,不过我还是简单说几个我在实施项目中的基本原则吧。
1、步骤要对,我们一般采用意识运动、评估、访谈、差距分析、设定流程,设定指标、上工具、预实施等方法,切忌依赖工具,以为一了百了。
2、不要盲目去对ITIL V3 做映射,但是要考虑ITIL V3的思想,建立属于自己的服务生命周期。然后去用ITIL V3 框架提到的方法。
3、第三,还是那句话,工具,流程,人员都要考虑的同时,千万也忘记优化改进。
很多企业ITIL实施最大的失败处,很简单,就是缺少一个Owner,没有人专门对流程改进负责。这点无论是ITIL V2还是ITIL V3都通用。
最后,大家也可以看到,ITIL V3多了这么多流程和思想,甚至很多组织还没有实施过ITIL V2时代的最佳实践。我建议采用quick win 方式。比如说服务台的工作很多,但是实施的时候,考虑多方面因素,很多组织先落地之时,只是建立呼叫中心,但是进行了有效的管理和记录,说的结论是,这样很好!但别忘了改进!
这就是我今天给大家讲的一些主要心得,希望能帮助大家开拓一些思路,同时也欢迎大家和我进一步探讨,谢谢!
CIO时代网 :非常感谢刘老师给我们带来ITIL V3专业的知识讲解、实施建议、以及评估指导,如果有对ITIL V3以及IT服务管理领域感兴趣的网友可以跟CIO时代网或者刘老师保持沟通,进行更多的交流!谢谢大家,本期节目到此结束,下次再见!
---------
RACI是一个相对直观的模型,用以明确组织变革过程中的各个角色及其相关责任。 我们知道,变革过程是不可能自发或者自动进行的, 必须有人对其进行作用,促使进程发生变化。 因而,就很有必要对谁做什么,以及促发什么样的变革进行定义和描述。
除了RACI以外,还有RASCI或RASIC都是用来描述变革过程中的角色、任务的。
RACI的具体含义 英文缩写
. 谁负责(R = Responsible), 即负责执行任务的角色,他/她具体负责操控项目、解决问题。
. 谁批准(A = Accountable), 即对任务负全责的角色,只有经他/她同意或签署之后,项目才能得以进行。
. 谁支持(S = Supportive), 即提供信息资源,辅助执行任务的人员。
. 咨询谁(C = Consulted), 拥有完成项目所需的信息或能力的人员。
. I =应该是消息灵通的。 即拥有特权、应及时被通知结果的人员,却不必向他/她咨询、征求意见。
RACI模型通常利用RACI表来帮助讨论、交流各个角色及相关责任。(参见右图)
RACI的步骤
1. 辨识整个流程、找出各项活动,将它们记录在RACI表的左侧。
2. 辨识流程、活动中的所有角色,将它们记录在RACI表的上方。
3. 完成RACI表的方格单元: 辨识每一个流程、活动的角色(R、A、S、C、I)。
4. 每一个流程最好只有一个“R”角色,这是RACI的一般原则。 当一个流程找不到“R”角色时,则出现缺口。 当一个流程有多个“R”角色时,则出现交叠。
5. 解决交叠问题。 每个流程只能有一个“R”角色,以便明确流程的具体拥有者和责任。 如果不止一个“R”存在,那么就要对该流程进行再分解,然而再对“R”进行分配。
6. 解决缺口问题。 如果某个流程找不到“R”角色,这时对流程或项目负全责的权威人士则应该在现有角色中(或者发现新人选)挑选、任命一人担任“R”。 更新RASCI表,对各个角色及其相关责任进行阐述RACI |