[原创征文]抛开ISO20000谈20000

最近一直从事ISO20000的相关工作，对国内ISO20000的审核现状颇为汗颜，不吐不快。

ISO20000本是BS15000演变而来，应该说在最初的英国和后来的逐渐推广中都对很多公司的IT起到了推波助澜的作用。我国自开始ISO20000审核以来截止今年4月已经有超过130家企业通过了企业认证，而在IT行业起主导的北美洲却区区16家，足见我国IT行业之强大，在认证上把他们远远的甩在了后面，我们有10个微软、10个苹果、10个谷歌，有趣的是我们还要抢注一个苹果公司的商标，饶了他们吧。

其实我们都明白，我们就是能拿证。同类公司我们有证我们有实惠，同一公司我们分公司有证我们招人爱，同一分公司我拿到证我比前任强，拿证心理又主导了认证行业，除了DNV、BSI这些公司大把有钱赚，协助做ISO20000的公司也如雨后春笋且各个赚个盆满钵满。而众多机构和出版社也大肆出版类似ISO20000审核宝典，成了考证的推手，复制了应试教育的悲剧。有趣的是京城某A类高等学府也加入了过证的行列，领证之后又羞于公之于众，原因为何？你知我知他她它知。

ISO20000到底该是什么，可以带给我们什么呢？它是一个审核的标准，好比我们写作文，老师拿着ISO20000给我们判分，那么照着评分标准可以做出好的答卷么？IT治理从IT诞生那天就开始了，但是我国起步比较晚，好的企业照着标准做一个60分然后加上自己的见解和企业文化向更高地方看齐，虽然本末倒置但也立竿见影不失为一件好事儿。

谈ISO20000，其实应该抛开ISO20000不谈，这里借用ITIL v3的划分把下文分为五个部分，分别是服务战略、服务设计、服务转换、服务运营和服务持续提高。不得不承认ITIL这种先入为主，相对于Cobit更容易被大家接受。

一、服务战略

从治理层面而言，Cobit给我们以很大的启示，让我们知道从上至下的去思考问题，再由前向后的去做事情。从CEO对IT的重视，做出适合公司业务现状和发展的决策，并在资金层面给予足够的支持。有数据显示很多成功的公司都把营业额的4%以上投入到了IT建设中。CEO要明白，IT投资和其他投资一样是具有风险的，股市可能有赢有赔，IT也是如此，不可以只想着成功而惧怕失败。不管是UPS还是Delta航空都在IT发展中做出过重大变革，而他们都因为最高领导的决策得到了丰厚的收益。

仅仅最高领导层的拍板是远远不够的，接下来就要CIO登场了。国内一个最可怕的现象就是CIO当做CTO使唤，CTO又代理了CIO角色，不是我们不花钱是我们觉得花这个钱不值得。CIO不同于技术部门货信息中心负责人，而是和CFO、COO一样进入到公司最高决策层，对公司命运起到了至关重要的作用。CIO应做的事情就是准确的分析市场发展现状对IT的需求，定力IT政策、授权基础架构师设计IT蓝图，其中要以下几点注意切合业务，关注客户满意度，提高投入产出比，监控并及时改进。

1、 切合业务。一切从实际出发，不可好高骛远造成不必要的浪费；也不可扣扣索索才上线几天就捉襟见肘，要推到从来。众多大型IT公司和咨询公司往往挖出一个大坑给企业，然后一期二期三期的做下去，钱是吸进去不少，一个2000人的公司的IT做的像20000人用的，我们就当他们有远见吧。从实施角度来讲，要从核心业务做起，保证核心业务可以最好的发挥效用，再做上升层面的业务，风险的随之增加相应的给能力管理、信息安全管理、连续可用性管理等施加压力，如果到了超越层面，投入肯定是成几何倍数的增长。虽然如此，一些在浪尖上的公司，比如苹果、VISA还是给出我们很好的体验。需求管理决定IT命运。

2、 客户满意度一直是服务类企业最关注的方面。在ITIL 2011版本中也加入客户关系管理这一流程同时配有客户关系经理这一角色。这一角色对我们而言并不陌生，一方面是ISO20000最初版本中就有提及，另一方面，我国文化对关系这个词的理解是非常到位的。让我有些费解的是，ITIL中客户关系经理的职责是让客户的TOP MANAGER满意，这虽然不难理解但是我们当然是希望所有上帝都满意。这个时候可以参见Delta的案例了。

3、 提高投入产出比。在一部分内容上和切合业务有重合的部分，但是IT Value和ROI概念的提出告诉了人们IT是可以创造价值甚至引领业务的。有人说过，IT投资就像 一样，总有一半是没用的，而我们却不知道是哪一半。其实就现在而言，除了纯粹的IT服务企业，很多企业的IT价值体现还不够明显，所谓的ROI也是无法计算的。但至少在金融行业、医药行业这种依靠IT手段减少了人工工作量等角度还是可见一斑。IT的投入目标不管是划分为七类资产还是九类资产，都必须经过详尽的分析，通常来讲IT基础架构的投入会占到50%左右。现如今虚拟化和云计算的来临可以讲原有的资产和设备得到重新利用或者更高效的利用，对于IT升级和IT转型的投入可能有所下降。财务管理又是一个和IT一样大的系统不赘述。不过值得一提的是，IT财务部门的建立，对于IT部门来说有诸多好处。

4、 监控和不断改进。不管是我们较为熟悉的PDCA（I）模型还是Cobit ME模块成熟度测评或是ITIL v3服务提高七步法都为我们展现了不断改进的方法，同时我们也看到持续改进的重要性。有人曾经说过，我们可以不时时提高，但是当我想到要去补一下功课的时候就发现为时已晚。在实际工作中可以做到CSI是面临很大难度的，特别是多个输入来源需要众多部门的配合而且提高过程又要返回到财务这一致命的环节。所以在提出改进计划时一定选择什么是我们必须提高的，什么是我们应该提高的，什么是我们将要提高的，而且用最有穿透力的语言说服最高决策者。民生银行更换核心就是被业务压迫到无法继续支持，具有一定的必然性和客观性，但是不管主动也好被动也好，见效了就好。

服务战略部分说了很多，因为战略始终是重中之重，虽然整个运营可能占到80%的时间，但是如果舵手方向没有掌握好，可能其他的努力都会付之东流。服务组合管理因为和服务设计联系紧密就不在这里表述。

二、服务设计

不管是哪个IT管理系统都在这里反复强调和业务的统一性，内部组件的统一性，目标的统一性和应用的统一性。所以又回到上面的话题，从低到高的实施治理是行不通的，因为我们是现有总体目标或者大目标才能有业务层面支持层面的小目标。

服务组合管理和服务目录管理是包含与被包含的关系，服务组合中还包括开发中的服务和退役的服务。服务目录是展示给客户和支持人员最直观的界面，比如我们看到的Amazon的商品目录、银行的业务类型、医院挂号网的科室之类都是给客户展现的目录，作为后台有更多的支持目录给支持人员，通常来讲前段有30个服务，后台可能有200个支持服务。服务目录通常要保证所显示的内容是及时的准确的全面的，并且和众多相关流程进行接口和集成。

能力管理原来被称作容量管理。在ITIL V3中因为重新定义了九种资产包括了组织、人这些内容所以不再适合用空间性更强的“容量”来表述。事实上，真正容量的部分是相对容易做到的，比如硬盘、带宽。而其他很多资产给能力管理带来真正的压力。因为能力管理跨越多太多层面，所以要协调起来难度非常大。比如按照阐述，能力管理要负责对员工的培训，在人员短缺时提出招聘计划，这样能力管理和人力资源管理之间就进入了相互纠缠的地步，这样看来能力管理经理还需要高层领导兼任，矛盾的是任务量又大的惊人，因为任何错误的出现都可以归结到能力不足或者经验不足。所以这个概念的引入是好的，实施起来我认为还是有难度的。

连续可用性做起了容易，做好了难。现在一般公司都做好了BCP以应对突发事件，但是我所经历的众多事故中，BCP经常无法发挥作用甚至有反作用。比如，经常见到有些4s店装有UPS和发电机，结果一出事故UPS起不来，发电机虽然能用不过柴油却没有。既然是一种应急机制，就不能形同虚设，用能支撑几十分钟的UPS来支撑全部业务，而且两年都不测试一次，那必然是会出问题的。BCP应该保证周期性的检测，并且这个计划要随着业务的增长不断的改进，设备也要提高相应的性能。当然，我们也面对很多困难，比如双电双网很多时候是没法实现的，市政根本不允许拉两个电厂的线，但是我们仍然可以通过很多渠道进行解决。相比较而言，最怕风险的银行的容灾计划就做的有声有色，基本保证了1:1同步数据，虽然成本是上去了，但是有备无患。连续可用性主要是一个观念，把可能遇到的风险都尽量避免，让影响在自己可接受范围内。

我们大多对服务基本管理比较关注，这主要是因为它是衡量服务质量的一个标尺。拍着脑子就敢定SLA的年代已经过去了，在SLA中签订100%也已经过去了。连6sigma级别还有百万分之几的次品率，我们还是不要把冒傻气当做精益求精吧。服务级别协议本身是不具有法律效力的，但是对于双方都有约束力，这种约束其实是一种道德是一种操守。有时候SLA协定的内容其实是很少的，有巴掌那么大一点地方就可以，这样的话可以给双方很多理由规避责任。有些SLA签的像是标书，设定几十个目标，看得人眼花缭乱像是看到乏味的 。SLA的签署一定是有草稿的，是经过市场风险、财务分析、风险评估等一些列活动，还要结合能够达成服务的OLA、UC进行结合，然后与客户商定修改签署的。里面的内容要简单明确扼要，除了名称之类意外就是大的目标、达成可用率、相关责任权利。有些具体小的目标、或者是细节可以设立子集。往往有些提供商为了能中标提出相当高的SLA，这样提心吊胆完成合约都得了心脏病，而且高风险并不仅仅是经济赔偿，还包括在业界的名声，6sigma级别的SLA伤不起啊。

提到信息安全不得不再次引入ISO家族成员，ISO27000系列，这个国内企业通过率也是颇高啊，令国外众多企业望其项背。用ISO270001的130多条绳子捆住自己，然后呼吸，然后做运动，完全是和自己过不去。作为IT管理，有20个点左右的管控应该就足够了，其实在技术层面对信息安全进行把控已经到了很高的层面了，但是从人员角度做到信息不泄密就很难保证了。就在我们拼命想做好公司的信息安全的时候，忽然听说招行已经把我们信息卖掉了，后来听说电信运营商早就卖过了，再后来听说他们都是下手晚的。哎，做猎头的都知道一组个人信息值多少钱，我们只是阿Q，告诉自己我们不在乎。

供应商管理作为服务设计的一部分，是IT战略成功与否的保证，但就目前国内市场而言有些寡头垄断、有些矬子里拔将军，所以供应商都是大爷，UC是一纸空文，我也不在这里扯淡。

三、服务转换

从战略到计划，再计划到实施，这个时候才该看到一些真刀真枪的东西了。其实到了这里一股脑的很多东西都涌现出来，比较好理解的是变更管理，因为这个和运营联系非常密切就在后面服务运营一起说，另外的部分资产与配置管理、发布与部署管理还有CMDB的建设都是让人头疼的问题，不做好这些东西，所有的目标都只能是空谈。

资产与配置管理首先要给资产进行分类，有效的标签，要知道什么要写在上面什么不写在上面，这是一个比较矛盾的事情，比如有500台笔记本，我们是否要记录下硬盘号、内存条编号、网卡物理地址。有人说这个是需要的，能多详尽就多详尽，那我们雇佣一大批人进行拆机带来的只能是员工流泪、笔记本经销商拒保。到时候我们也说是蟑螂造成了问题人家才懒得理你呢。可是，在IPv6时代的IP段是要记录网卡Mac地址的，如果对网卡Mac地址的登记很可能对将来网络中出现病毒或者恶意攻击也或者是信息安全的其他问题时候都可以最快时间定位。所以配置项的颗粒度有多大，就好比内网IP段选用10.0.0.0 - 10.255.255.255还是172.16.0.0 - 172.31.255.2都是因需求而用。配置项和服务目录等具有非常大的关联，所有配置项的变更必须及时并且通知相关接口流程。

因为没有IT背景所以我对于CMDB的建设也是持有很多疑虑的，但是就目前情况而言，大多数IT类企业还是拥有类似CMDB的数据库，只是经常过于分散而不能同步以至于无法及时调用，那么他的作用就会被削弱。CMDB本身也是可以存在多个，但是必须保证他们都可以被最快速度调用到最新配置项。对于CMDB的梳理也是一个跨部门的漫长过程，所以从一开始就应该确立规范，把前期工作做足，免得亡羊补牢。

匆匆谈过两个大难题其实等于什么也没说，再发布与部署阶段所要协调和调配的资源就比较丰富了。在现有的情况下，一般都是由总包商或者集成商来完成，所以合理的授权和分清责任至关重要。在经过了反复测试之后，所有相关部门必须都对自己应该负责的部分进行评估，一旦有重大出入实施的过程就应该重新布置，这时候实施部署的逆转和补救方案就要生效。不管是发布和部署的都应该层层推进不可一蹴而就。

四、服务运营

谈到运营，大家都觉得这个好理解，因为这个和自己贴的最紧密，所以在ITIL v3中级考试中挂的也最多，为什么呢？因为我们一直在按照自己的思路和所在企业的思路去做运营，我不是说这是错的，但是应该在不断反思现有情况和建议的情况进行对比改进。

服务运营如果说起来就遇到了一个瓶颈那就是词语的标准化，所以我在个别单词使用英文。运营中的Event管理流程并不是一个紧迫的流程，主要是因为它所涵盖的内容包括大量的中性的信息，只有部分Alert会引发Incident和变更。所以对Event管理流程来讲，如果公司足够大，信息量也足够丰富的话还是有必要上一下的。

Incident管理的最初肯定是对什么是Incident予以定义，并且参照优先级表，参照SLA、OLA，以及SOP对Incident予以控制和解决。但是肯定的说Incident的目标是最快时间恢复应提供的服务，换句话说是work around，而非从根本角度解决这个问题。好比牙疼，我们吃了甲硝锉、芬必得可以阵痛，但是如果真的要根除恐怕要杀死牙神经。那么什么时候我们才会去杀死牙神经呢？当第一次发病时牙医就诊断了要杀死牙神经，或者是多次牙疼造成不得不先杀而后快，这个判断的过程就已经进入到了问题管理。

问题管理流程必须先于变更管理进行实施，因为只有经过问题管理判断问题、已知错误才会又可能导向变更管理。问题管理活动的根本在于找到根本原因，但是是否要解决还要看很多因素。其中最有决定性的是这个问题是否已经影响了满足SLA，如果SLA依然可以实现，那么在不影响客户满意度的情况下，可以继续使用现有服务。如果严重影响了SLA基本上就要走入下一个流程。

变更管理是服务转换的一部分内容，因为服务转换的概念就是对新的服务和变更的服务的过程。它的来源是多方面的，在运营管理阶段，Event和Incident都是如入的源头。变更请求（RFC）和变更的批准人和执行人一定要进行分开，就好比做会计的人也做出纳就会导致很多潜在的风险。除去已经授权的标准变更外，重大变更和紧急变更必须由变更委员会（CAB）和紧急变更委员会（ECAB）或者是有的公司的变更控制委员会（CCB）进行审批，这样才能进行实施。在实际应用中，这种批准和财务批准等其他批准是一样操作的，原则上是不可以违规的。

服务请求管理、访问管理略过。

五、服务持续改进

服务持续提高的部分在2011版本的ITILv3中已经简化了很多，对于之前的很多流程和模型都归入了通用模型，大家可以在很多服务体系的书中见到。服务持续改进的意义自然不用说，随着业务的增长，现有过程出现的问题和IT本身技术的突破等都引发服务持续改进。

要做到服务持续改进，应该在各个流程运行中进行调查质量问卷、满意度调查、专业评测、内审、外审。外审的目的是为了纠正错误而不要再次想到是拿证。

通过几个模块的描述已经把我自己所认为重要的点都囊括了，另外就是两个重要职能：服务台和技术支持。

服务台是运营管理中的一个职能，它的目的就是为了直接和客户进行交流，一般也成为一线人员。一线人员一定要有敏锐的获取信息的能力，包括从监控中获取信息，从event、incident中获得信息，从客户电话中获得信息，并且进行相应的分类，通过管理工具找到最有效的解决渠道，争取达到最高的一线解决率。如果在一线技术和设备层面无法解决的时候，考虑有效的双向升级，尽量减小对客户的影响，并提高客户满意度。服务台的通过服务软件一定要将所有细节都记录在案。服务方一定要保证最多的渠道，最快的时间相应客户，不能像很多 一样想打进去要持续捧着电话。

技术支持方面有CTO负责，我们通常是拥有一套ITSM管理体系，并在ITSM体系中加入很多工具平台，有支持业务层面的ERP平台，还有相应的流程平台，流程平台再嵌入具体模块，比如财务模块。科学技术和管理技术相结合才是第一生产力。

不谈及ISO20000的实施是专注于提高工作质量，提高工作效益的。虽然我能力有限，篇幅也有限，但是还是希望更多的企业能够从ITSM中收益。最后在引用一个例子，有 问杰克韦尔奇为什么流行的管理学理论大家都知道但是却没有他们取得那么大成功，杰克韦尔奇说：“因为他们知道的我们做到了”。