[原创]ITIL V3与ITIL V2的价值差异

ITIL V3自从2007年推出后，已经将近两年了，这两年时间足够令相关的研究者和爱好者能知晓这个名词。对于新的名词、概念或者技术推出后，往往会有三个时期存在较多的争论，最热闹的时候一般是刚推出或临近推出的时期，而后慢慢冷淡一段时间后，不少有机会深入这些新事物的人慢慢地又会有第二个阶段的争论，最后一个阶段常常是这个新事物真正深入实际后，实施者之间就各自的差异进行的争论。

争论这个词并非贬义词。但第一个阶段的争论往往产生出商业的价值更高一些。不少爱好者能第一时间拿到有关资料，会很欣喜地与他人分享，但很快便有反对者，其实这段时间大家对新事物的争论比较多的建立在初步感知上，过于片面的地方较多，最终收益的往往是新事物的发布者。而第三个阶段则具有实践意义，这种争论一般会超越工具或理论的本身，而是讨论哪种方法更为贴切效果。

笔者认为第二个阶段的争论则在对框架的科学性提升上功不可没，因为这时候的争论者一般都对该新事物的实质上有了较为深刻的认识，但还来不及过多加入干扰性元素，会更注重历史的分析与逻辑的严密。

对于ITIL V3来说，无疑逐渐会进入第二个阶段。根据一份EXIN年报，在2008年（截止当年10月份）统计的历年数据中，在北美地区通过ITIL V3的学员数达9123人，超过了该地区同时期ITIL V2的7638学员数目，在亚太地区，ITIL V3的同时期所占比例则要低一些，在7498人，是同地区同时期ITIL V2学员数的1/3多一些，但考虑到ITIL V3是于2007年才发布，所以也明显呈现出上升趋势。报考人在ITIL V3上的逐步倾斜对于OGC来说，是一种欣慰的举动。但同时也有更多的人在质疑ITIL V3对于ITIL V2来说，到底有什么价值上的差异？我遇到过一些学员，在接受我的课程培训前也接受过一些机构的ITIL V3培训，他们接受的培训中其实大部分还是沿用了ITIL V2的套路在讲述ITIL V3，仅仅在一些不同的概念上做了概念上的“朗读”。这点倒也并不意外，因为直到今天不少人还是觉得ITIL V3仅仅是加了一些战略上的概念并把次序重组。实际上，在专业领域，这依然是争论的一个焦点。

按惯例，我们还是显示一下ITIL V3与ITIL V2在框架上的不同（见图一），以下白色为两者不同的地方、蓝色为两者相同的地方，另一个浅蓝色则是职能（Function），在 ITIL V2中，仅有服务台职能（Service Desk Function），在ITIL V3中则多出了运营管理职能（Operation Management Function）、技术管理（Technical Management Function）和应用管理（Application Management Function）。

本来这幅图已经能说明问题了，但往往问题的表面不是大家所关注的。其实在价值是否有所提升方面，很多人真正关注的应该是两个方面：一、采用生命周期的结构是否具有真正的指导意义？二、多出的几个流程是否有必要？

我们在思考一个方法论的时候，尤其是如同ITIL这样的在IT服务领域涉及面较广的方法论来说，用“拿来即用”的“工具化”思维并不是最恰当的。在ITIL V2时期便已经有很多人向我说：ITIL不具备可实施性，或者ITIL没法拿来用。其实“有用”两个字是应该具有充分必要的主谓宾语的。比如我们年轻的时候会说，父母的唠叨没有用，因为没办法帮助我们考试拿高分，帮助我们拿高薪。我们会一度信仰一个我们自己都知道并不算正确的理论，就是只有钱才能改变一切。但父母的唠叨这的没用吗？在你基本的价值观中，在你行为的潜意识中，在你需要亲情的时候，这就是支持我们的支柱，没有这些支柱我们还真的未必就有高分和高薪。但多年来急功近利的思想使我们往往忽视“指导性”的意义而更着重“指示性”。

ITIL作为一个方法论，尽管它提出了很多流程的目标（Objective）、益处（Benefits）、价值（Value）、关键绩效指标（KPI）、存在的问题（Problem）……，但并不是说，这些内容立刻就能用，它更象父母的唠叨，不厌其烦地告诉我们：按老人的经验来说，这样做是对的。但你有你的个性化生活，所以你可以去改变，如果你不知道怎么做，你可以参考ITIL，如果你很清楚你该怎么做，也请尊重ITIL这个“老人的唠叨”，因为他毕竟经历过，他是最佳实践（Best Practice）的集合。

有了这么一个认识后，我们再来看待ITIL V3的第一个重大改变，就是关于生命周期的引入。

这个词听起来很“酷”，但其实并不神秘，所谓“生命周期”所形容的过程就如同我们自身的生命有一个从摇篮（Cradle）到坟墓（Tomb）的过程。从这点来看，ITIL V3从意念上能提升IT服务管理的价值应该是毫无争议的，因为在ITIL V2时期，核心部分以服务支持（Service Support）和服务交付（Service Delivery）为主，对运营较注重，其次是计划与文档（战术层面）。在如业务视角、应用规划与管理中当然也涉及到了一些其它部分，但相对零散与薄弱，有些章节所表现出的价值甚至让人不敢恭维。

对于一项IT服务来说，是一个过程，从我们去识别乃至揣度客户的需求开始，经过设计，然后开发，然后交付，然后运营，最后还没有结束，因为还要改进，终于一个周期的结束了，但立即又步入另一个生命的周期。

很多时候，我们的IT运营人员能在自我的范围内将工作处理得完美，但很不幸，大部分时候我们的IT人员总是被各种各样的事情所阻碍，所干扰。于是我们通过服务支持的事故管理（Incident Management）、问题管理（Problem Management）、服务台（Service Desk）能把很多应急的事情处理得井井有条，然后通过变更管理（Change Management）与发布管理（Release Management）保障发布时候会最小风险，为此还会建立一个配置管理（Configuration Management）来建立CMDB作为技术地图。那么有人说，事先不计划好也不行啊？没错，于是我们又可以采用能力管理（Capacity Management）、可用性管理（Availability Management）、可持续性管理（Service Continuity Management）来进行各种组件的计划。接下来有人说，我们必须要和我们的客户讲清楚，不然做了白做，或者没依据，所以服务级别管理（Service Level Management）可以解决这个问题。最后，发现如果要解决最后的价值谈判，还要有专业财务分析方法，于是财务管理（Service Financial Management）也出现了……

这就是ITIL V2给我们带来的价值，是最佳实践，是我们在全球的IT管理中逐步形成的方法论。所以，我们能通过系统的培训和学习，对这套体系产生基本的认同，并且经过十年来各个企业的实际实施，为其做了许多优化与改进，成为不愧业界的事实上行业标准，也因此衍生了ISO20000这个国际标准。

问题在于：我们做的真的是客户所需要的吗？或者说：我们做的是客户未来能持续需要的吗？

在ITIL V2时期，我们常爱说一句话：“ITIL中所有的流程都在为SLA打工”，这句话背后则隐藏一个我们普遍认为它没有解答的问题，就是SLA从何处来？现今恐怕大家都感受到，技术不是生存的根本，根本在于我们是否具备“被需求的技术”呢？IT人员的价值没有体现的现象依然存在。恐怕ITIL V3引入生命周期能优于ITIL V2最大的价值便在此处！

“生命周期”的引入使得以往相对个体化的模块以一种价值链的方式做了联系，同时又采用PDCA的模式能使各模块之间具备横向的联系，于是这个价值链转变成一个无垠的价值网。如果按照一种理想的状况来说，在ITIL V3的思想中，我们是“在客户想到之前去思考问题”。于是焦点不再是SLA，可以往SLA以前推到服务目录（Service Catalogue），再往前推到服务组合（Service Portfolio），而服务组合之前还能推到需求的识别，财务的预测，战略的制定……

因而结论是，至少在理论上，生命周期概念的引入是对服务管理的一种科学化管理！这其实也回答了另一个问题，就是所谓把次序的重组并非只是一个噱头，而是把这种科学化进行到底。

接下来我们来讨论一下多出的几个流程是否有价值，这也是大家比较关心的话题，在本文中，我们考虑到篇幅，可以找出几个代表性的例子来阐述，更多的流程区别可以参见拙作《ITIL V3 新增的流程与职能》。这些阐述代表了或许更多的是个人在授课与咨询项目中对价值上的一种判断。我觉得完全可以进一步讨论。我们主要对需求管理（Demand Management）、服务目录管理（Service Catalogue）和事件管理（Event Management）三个流程分别做些剖析。

先说需求管理（Demand Management），对于这个部分，我们在ITIL V2中曾经有过一面之缘，在能力管理（Capacity Management）流程中我们提到，这个流程目的是在客户需求与IT组件中做出一个平衡。这个流程虽然ITIL V2中有，但我们完全可以理解为是一个全新的流程，主要从两点考虑：第一，ITIL出版物很明确地把需求管理这个前沿工作从战术层（设计层）前移到战略层；第二，这个流程提出更多具体的方法论。

记得在讲解需求管理的时候，我们会常常采用“削峰填谷”的概念。常常会问大家为什么我们的备份工作会放在半夜进行而不是上午十点，为什么打长途电话半夜可以便宜，为什么北京要分单双号来安排汽车行驶，这些均可以认为是削峰填谷的概念，也是朴素的需求管理思想。不仅进入到ITIL V3的模块中，这个朴素的思想变得华丽而生动了。PBA（Patterns of Business Activities）与UP（User Profile）共同形成SLP（Service Level Package）的模式使不少IT服务管理人员与需求管理乃至业务拓展人员眼前一亮。

可能有很多读者还不是特别能理解这个概念，我们可以举个例子，比如我们用手机可以打电话、发短信、漫游、上网……这些行为就可以整理成移动运营商的客户PBA，然后我们再来区分UP，比如有年轻族、普通市民、商务人士……，经过分析，我们发现商务人士可能重通话质量，普通市民重实惠，年轻族则更看重各种炫目的功能。于是我们把一组PBA对应到一个UP上，形成了三个SLP，一个叫“全球通”，请濮存昕做广告，一个叫“神州行”，请葛优做广告，还有一个叫“动感地带”请周杰伦做广告。这样的结果是：移动的客户能获得他们认为满意的服务包，而运营商也能产生最大ROI。

至少从这个例子，我们可以感觉ITIL V3中的一些流程增加还是很大意义上改进了我们价值体现的方法。那么我们再看第二个例子，服务目录管理（Service Catalogue Management）。我个人觉得在ITIL中有三个库或文档是很有价值但很难建立的，其中一个是服务目录（Service Catalogue），另外两个是知识库（Knowledge Base）与配置管理数据库（CMDB，Configuration Management Database）。当然，在ITIL V2中，并没有明确提出知识库的概念，不过我们觉得知识库还是值得在这里体系中讨论的。

服务目录（Service Catalogue）在ITIL V2中的地位并不高，仅仅是服务级别管理（Service Level Management）流程中的一个概念，但到了ITIL V3中则独立成一个流程。这点让我欣慰，因为服务目录（Service Catalogue）是服务提供者（IT Service Provider）与客户（Customer）之间的重要沟通工具，是默契的基础，其地位当如同在餐馆的菜单。不过，在我的研读中，这个部分的内容并没有给出太多的惊喜。对于概念的扩充多于方法的指导。而这类问题频繁在ITIL V3的出版物的各个章节中出现。这使ITIL V3出版物堪称一本IT服务管理的大百科全书，但逻辑性与指导性难免有些折扣。

应该讲，这个有代表性的流程是让我对ITIL V3出版物最为无奈的体现，便是思路开阔了，服务生命线全了，但能让我们拿来即用的东西却少了。这使得我们在很长时间之内都不敢轻易地说，这些流程到底价值是有还是无。但我们又不能否认这些章节能让IT服务管理的体系更健全，而我们有一点又可以相信的便是未来会不断有人在这个环节的实施上提供更多的方案与优化。所以，价值点应该还是算正数吧。

最后一个要讨论的流程是事件管理（Event Management），这个流程更多的是侧重在事故（Incident）爆发前的监控预警。对于这个流程，在我的朋友圈内有过争议，便是这个流程的存在价值。很多人笑说，这个部分是HP为了推广它的某个著名监控软件（这个章节是HP编写），我也觉得这个流程更像是一个职能，并觉得这个流程完全可以体现在事故管理（Incident Management）与问题管理（Problem Management）中。不过很有意思，有一次我给大约四十余名HP的员工做培训，我问他们：这个流程是否多余呢？他们很严肃地异口同声告诉我：不多余，很有必要！在深刻感受到惠普企业文化的同时，也不免使得在对该流程设立的立场上发生动摇。直到即将搁笔，我也无法用很确定的态度来衡量ITIL V3中这些流程设立的价值。这其实就是ITIL V3自身所遇到的最大问题：一方面完善的流程设立使得体系结构更完善，另一方面过于庞大的体系不仅造成内容深度不够，并且使一些流程之间存在重叠性，这种重叠性导致大家对流程无法用清晰的脉络来认知与实施。

关于ITIL V2与ITIL V3的比较，我们简单说了一些，但是可以讨论的地方尚有不少。总的来说，笔者对于ITIL V3用生命周期的方式来加强价值的提升持肯定态度。对于ITIL V3存在的不易理解与不易实施的方面，恰恰是我们需要去探索和优化的。