安永冯哲：ITIL 实施的重点及难点案例分享

　　以下内容为安永（中国）企业咨询有限公司高级经理冯哲参加“Future-S第六届中国ITIL管理双城年会2010”时所做的演讲实录。

　　我今天要讲的是IT实施重点和难点。通过5个层面来剖析出来：一，我想花两分钟时间来大致讲一下ITIL到底是什么？ITIL概述以V2的版本来做。从ITIL概述当中想抽取些IT服务支持层面上的流程，来讲一下服务支持流程，ITIL的概念并不是IT专属的。在相对比较成熟的服务行业当中，实际应用就是ITIL的服务概念。接下来我会再讲服务支持流程当中的关系，这些关系跟我们整个ITIL实施当中来看有着重要的关系。因为ITIL不管多少流程，这些流程当中的关系才是真正ITIL实施的精髓。

　　由于时间关系，我没办法一一剖析每一个流程的实施要点，当中挑三个流程出来，或者两个半流程，去介绍整个ITIL流程当中的实施要点，什么才是最主要的地方。最后做一个总结。

　　用这张图来表示ITIL。在ITIL，或者更准确地说是IT服务管理。IT服务管理是ITIL当中一部分的内容，主要包括了服务支持、服务交互两个大的模块和安全管理。在ITIL的IT服务管理当中有服务支持和服务交付这两块。服务支持相对来说比较相对于运营层面，往左看灰色的，相对来说比较是运营层面的。这里面包括事件管理、问题管理、变更管理、发布管理、配置管理这五大流程和一个服务台。也就是说是IT部门每天都要去操作的流程。

　　IT服务交付相对来说是战术层面。一个是战略层面，一个是运营层面，一个是战术层面，还有一个明显的区别在于什么？我经常用这样的比喻，我们都学过物理，知道串联、并联，喜欢把服务支持日常运营层面的内容相比较成为一个串联的电路。也就是说一开始有我的事件管理。事件重复发生以后，或者有更严重事件以后会变成一个问题，如果问题需要解决，或者可解决的时候我变成一个变更。多个变更合在一起发布出去，最后是配置管理，配置管理每一个流程当中都会有接口。它们之间是层层递进的关系。

　　对于服务交付流程相对来说就相当于一个并联电路，发散出去。用服务水平管理，或者有些说服务级别管理。服务级别管理跟服务水平管理当中有什么可用性的服务型水平的要求，对容量服务水平的要求，对持续性水平的要求和财务层面上的要求。这里讲的四大流程需要有服务管理流程来作为依据，这就完成我想讲ITIL的概述。

　　我刚才讲到ITIL的概念，在很多相对来说比较成熟的服务行业里都会用到。我举一个医疗的案例来说：当突然出现一个事件时候，或者说一个紧急事件时候，我们会拨120急救中心，急救中心下一步会有救护车过来。在救护车当中起到作用什么？起到救护车里面的医疗人员能够让这个病人活着到医院去接受治疗，这是一个主要的目的。有了救护车以后送到急救中心，急救中心有急救室，这时候有专业的专家来做咨询，到底病根在哪里。是不是需要开刀，做手术，这时候这个病人的需求跟很多其他病人的手术需求会合并在一起，这时候有人会去做过滤，到底哪些手术跟生命相关，直接影响到生命的会过滤，会做影响分析，最终排出手术的排序来。真正的外科医务人员会操刀做这个手术。这个手术之前会制订整个的手术策略和实际去执行这个病人的手术。这些依靠的是什么？医疗的程序，手术的器械和最终手术做完之后他会去更新这个人的病历。是吗？这是我们经常在医疗行业里面看到的一个服务流程案例。实际它跟ITIL的服务支持流程一模一样。

　　接下来看一下为什么一样。首先有了事件以后，客户会打服务台，服务台用的是事件管理流程。主要目的并不是解决事件，而是使这个信息不会被中断，能够继续地运营下去。当某一个事件不知道原因是什么，变成是一个很严重事件，直接影响到我企业运营时候，它变成一个问题。这个问题我需要做什么？我需要做根源分析，查找到这个问题的真正原因是什么。查到原因之后，我知道解决方案了，问题怎么解决，肯定需要通过变更来完成。这时候我们看到的就是变更管理，变更管理是什么？我需要做影响分析，这个变更到底怎么影响我的企业。最终会变成1、2、3、4、5不同的数值的影响度，然后最终有发布管理来执行这个变更。最后是配置管理做支持。是不是？ITIL跟医疗行业的服务流程异曲同工。

　　我再把这个流程放大一下。经常喜欢用一个倒漏斗来解释在服务支持层面上主要四大流程之间的关系。在四大流程当中有几个概念：一，事件。这是在事件管理当中的，有问题、已知错误，发布。这是一个漏斗，我经常变成一个倒漏斗，在事件管理流程当中数量应该是最多的。有些事件已经知道原因了，可以把这些事件短暂地解决，它就不会变成问题。只有那些不知道原因的，或者对企业影响非常大的，他变成问题了，所以问题的量肯定要比事件小。有问题后并不是所有的问题都在企业当中需要得到解决。

　　原因很多：任何企业都不是福利单位。如果更改、修改这个错误的话，会产生的成本要高于利益的时候，企业往往不会选择去变更。还有一种是可能这个企业IT不具备某一些专门IT能力来修改这些错误。所以问题变成变更的时候，我的变更更加小，当有很多的变更合在一起形成一个发布包时候，那发布还要少。所以是以这种倒过来的漏斗方式来看这四个流程当中的四个主体。在四个主体当中需要有很多的流程来支持。经常我的客户说：我想要做一下事件管理，你设计一个事件管理流程吧。这时候我可能会稍微有一点一头雾水。有些叫标准事件管理流程。在事实过程当中会有些重大事件管理流程，管的是影响到企业很大的方面，影响度非常大的重大事件管理流程，还有些可能是服务请求的流程，一些问题的流程。当有了这个事件管理流程以后，后面的后台需要问题控制和错误控制来支持。相对应在变更流程当中可能会有些普通的变更流程。有些是标准的变更流程，有些是紧急的变更流程，这些流程都会跟前面的事件问题有不同样的接口。我在下面会介绍到。

　　我们知道发布是变更当中的环节，有些企业半年会有一个软件包的东西出来，有些可能是三个月，这些是普通的变更流程。当有些是很紧急事件而产生变更，需要很快解决的时候，我会有一个非常紧急的变更流程来让它能够把这个变更做完，这需要在紧急变更流程当中做。还有一种是标准的变更流程相对应的标准发布流程。

　　总结一下，从整个事件生命周期当中来看，有些事件会变成问题，有些问题会变成已知错误，有些已知错误会变成变更需求，然后发布出去。他可能会经历到的流程是不一样的。列举出当中9个例子：一，标准事件流程。当我在整个企业当中发现一个事件时候，能够落解决这个事件，使得这个商业可以继续进行下去，然后在标准事件当中的流程就结束了。在一个企业当中如果大部分的事件都是可以通过标准事件流程来完成的话，相对来说你这个企业是比较成熟的。有些事件可能没有知识库，解决不了这个问题，那在问题控制当中需要找到原因。但这一类的事件到问题控制的时候，我不会去做更改，这时候可能也会断掉。

　　还有些事件，他通过问题控制，通过错误控制，然后进入不同的变更流程中，有些变更是每天都发生的，你难道要求这个变更每次都经过变更管理委员会吗？肯定不现实。而且这些变更风险非常小的时候，可以通过变更管理流程来使这些变更尽快地运行下去，因为风险比较小，会通过标准变更流程，通过普通发布来发布下去。有些可能需要走普通的变更流程，做完以后还需要很具体的，一步步该谁来做就谁来做，最后通过普通的发布来发布出去。

　　还有一种现实生活当中非常非常多的，可能有些事件是非常非常重大的。银行，当ATM机里取不出钱的时候，这可能是一个很重大的事件。或者一个企业无法运营的时候，可能是很重大的事件。这时候难道还需要走我反复的变更流程吗？不需要了。这里有一个紧急的变更流程，然后通过紧急发布来直接发布出去。实际上后面的服务请求流程和上面有着类似的情况。我就不在这里过了。

　　我在前面想要讲的是什么？这些事件问题变更发布之间有千错万节业的关系，在考虑过程当中需要考虑到这些关系。下面很快地过一下三个流程具体实施的特点和关键点。实际上在一家企业当中，如果要实施ITIL很难，但实际上也不难，主要看你怎么实施。有的企业说我实施ITIL了，把一套流程做出来就行。实际这样的ITIL实施是最没有价值的。为什么？因为我可以说在所有ITIL流程过程当中，如果我们看过V2的书，或者V3的书，流程都是大同小异的，所有的事件都有发现，有识别，然后记录，记录完以后我会把事件做分类，分类完以后如果可以解决的话，那就结束了。如果不能解决的话，那给第二线、第三线人员。企业和企业当中可能会有不同点，在某一点上我设些升级的流程。但不管怎么说，这些流程都是大同小异的。我想要说的是什么？事件管理流程实施本身不是去画这些流程图，他精髓在于几点，特别在事件管理当中要说的是事件的分类。任何一个ITIL实施过程当中，企业和企业当中是类似的，但我从来没有看到一家企业的分类和另一家企业的分类是一样的，从来没有看到过。

　　即使在同一个行业当中，都是银行业，或者都是保险业，都是制造业，这都不同。看一下事件管理流程，如果说这个事件管理流程是一个成功的实施，我主要看几点：一，你事件的输入效率。因为事件本身是海量的，本身应该是海量的。从倒漏斗里看到事件的量是最多的，从事件里可以做分析，分析出到底哪些是问题，最后变更解决掉。事件应该是海量的。事件本身的输入效率非常非常重要，如果在管理系统当中输入一个事件需要花很长的时间，那没人愿意去输入这个事件。最后有很多的事件没有被记录下来。整个事件的输入效率可以通过几个方面来做：一，事件的自动识别。会有些监控系统会自动地生成事件，自动的。有计算器的时候就不需要用算盘了。

　　还有一种事件的输入，经常在事件管理系统里有一个很大的TEXBOX，问你怎么解决，要把解决的步骤写出来，输入这个东西可能需要花30分钟时间，真输入的话。有些人员为了省时间说：已解决、解决完了。如果你花30分钟时间当然没人愿意输入这个东西，所以尽量让整个系统去选择地输入。还有一点，问题管理的库是干什么的，我有着很多现成解决方案在哪里，只要引入问题库中的解决方案就能够完成对事件的解决方式。只要输入一次重复1百次。第一个是事件的输入效率。

　　二，看的是事件的分类。这个分类是否与服务挂钩起来，是否跟CMDB(同音)挂钩起来。我们都知道CMDB非常难见，不容易见。

　　三，看你在事件的最后解决之前有没有对分类做调整。往往在一个事件前期只看到一个表象，而不知道事件产生的真正原因。所以关闭某一个事件时候要尽量地做调整，最终能够看到在服务过程当中到底哪些IT服务是薄弱点。

　　变更管理来看，所有变更管理的流程都类似，我会把这些问题进行分类，分类以后评估，评估完以后优先排序，最后通过发布管理流程我来做PIR。每家企业都流程，流程类似，但差别在于什么？在于变更的评估。有些企业把影响性评估分成1、2、3、4、5，1最重要，5最次要，结果我发现一跑到他变更系统里，大部分都是3。因为我们中国人非常中庸，当不知道这个变更是很重要的1，或者还是非常不重要5的时候，都会放3。是吗？所以真正的变更评估、影响性评估要通过些问卷来做出来。这些问卷相对来说也是每家公司非常非常关注的。你没法拷贝一家公司到另外一家公司用。

　　这里简单地过一下，它是一个总分19分的东西，最低分4分，最高分19分，17到19的影响度是1。多少多少分的影响度是2。它通过多个纬度，第一个纬度，这个变更影响到客户的数字，影响到客户最多的，或者影响到一个很重要客户的时候它的分数是最高的。当不影响客户的时候，分数是零。还有一个纬度是看这个变更所要牵扯到的部门到底有多少。

　　第三个层面他会看整个变更准备的过程需要的时长来看，往往复杂的变更准备的时间会比较长，所以分数比较高。

　　第四个需要看一下所需要的时间来看变更的复杂性。

　　五，时间越长的回馈计划，有可能我的变更越重要。

　　通过五个层面最后加权变成一个总分。把它纳入1、2、3、4、5当中。最后我要讲一个流程。在ITIL十大流程里面，大家最困惑的流程：容量管理。往往有人问我流量管理怎么做，有的人说已经做了容量管理，有一个容量计划。我经常会问你这个问题：你这些容量计划最后数据的依据在哪里？他说没有。一拍脑袋出来的。这种容量计划是空的。所以你要做容量管理最基础的东西是历史数据，历史数据，还是历史数据，没有历史数据永远做不了容量管理。有时候我会问我一个员工说：你在家里平时做不做容量管理？他说：我做容量管理。家里买米，吃的大米做容量管理。我说：你怎么做的？他说：看到米不够的时候，买几斤放在家里。我说：对不起，这不是容量管理。真正的容量要怎么做？要记录你每天大米的使用量和每天吃饭的人到底有多少，最后形成半年、一年的数据，将来这半年、一年你可能要用多少大米。这才叫容量管理。

　　容量管理本身又是做起来相对来说比较复杂的事件。因为它需要些历史数据的积累，并不是所有的东西都需要做容量管理。我简单地总结一下，有三种情况需要做容量管理。一，当这个设备买的时候金额非常非常地高，并且这个设备是我整个IT服务管理、IT服务流程当中很关键的设备，我需要做容量管理。

　　二，可能他的金额不是很高，但能够通过有计划地采购，可以通过一下子买很多来节省费用，这样也可以考虑做容量管理。

　　三，第三个容量管理需要什么时候做？需要这个设备采购的时间非常长，或者比较繁复。很难得到，这时候你需要做容量管理。大米需要不需要容量管理？根本不需要。什么时候需要做？在打仗的时候，米量不够了，需要预测需要多少米，而平时不需要做。

　　这是上一届在北京讲一个ITIL时候讲到的，这是一个卡通，是爱德华熊，可以看到小男孩一直把他拽下楼来的，蹦蹦蹦地拽下来，实际上他一直跟着这个罗斌这么下来，他也知道有更好使这个熊下楼的方式，但对不起，他没有时间好好地想。这总结IT部门每天都在努力地去像救火一样解决些事件，但有更好的方式。什么方式？ITIL里面已经全部解决了，有更好的方式来改变一种思维，去解决问题。但可能大家都没有时间真正地去考虑。

　　最后我再举这么一个例子。曾经我在加拿大做咨询的时候，有一个客户，他问我一个问题说：为什么所有的电话都要通过服务台？我这么回答他：如果你在航空公司，会不会把飞机员放在前台来订机票？不会，明显不会。因为飞行员应该去解决更复杂的问题，通过分工方式来把简单的方式通过前台来解决。当时我说了这么一句话，他马上就笑出来了，理解了里面真正的意义是什么。当你把所有非常有限的资源都放在那儿接听电话的时候，难怪不外乎一些IT经理说我们的IT人不够。