学习资料：IT运维管理社区专家讲堂直播300期视频回放

业产品开发和运维之间有冲突如同家常便饭

但是当两者矛盾加剧的时候，

CIO们，你咋看？

通常情况下，CIO们一般站在开发项目组角度说话，因为对于企业老总来说，开发能产生新产品，能产生新的服务、获得利润，这是能够看到的。但其实这种现状一直在逐渐改变，CIO们，你们找到准确方向了吗？

6月2日,苏州IT人俱乐部在苏州同程旅游大楼组织了一场沙龙活动，现场特邀讲师Jason做了关于CIO看待ITIL的干货分享。

Jason，华东地区最资深的ITIL专业咨询顾问，在本领域已经耕耘了13年，同时也是中国大数据治理国标编写组专家成员之一。在他做咨询过程的当中，经常会遇到负责开发和运维的老大们起冲突。对于这种现状，Jason总结数年工作心得，现场做了关于《从CIO角度如何看待ITIL》的主题分享。

以下是现场干货分享回顾，略修改。

---

在业内，从IT治理的层面，高层领导一般会怎么去思考呢？也就是说，站在CIO和IT经理们的角度，他们怎么去思考公司的IT治理？根据国际信息系统审计协会（ISACA）编写的COBIT，还有IT治理领域的国际标准ISO38500的介绍，有三个职责活动是IT高管层面，站在治理的高度需要考虑的，业内叫做EDM，即评估、指导和监控，接下来我们详细解释一下。

第一个是指导，定战略，定组织，定架构，把这些游戏规则设定好。第二个是接受反馈，能够建立起一套监控机制，通过监控机制可以把我们的中层管理者，还有我们的运营层的信息及时反馈上来，看之前定的战略等规则是否不择不扣的执行了。第三个是分析评估，通过收集到的反馈结果来看我们的目标有没有达成，战略是不是有缺失，组织架构是否定义合理。这三项工作是业内公认的、在治理层面上CIO们首当应该考虑的内容。

在这个EDM模型的下方紧跟着就是管理层，这层其实就包含了今天的主题ITIL。这个层面主要会有哪些内容呢？刚才有介绍到治理层（Top-levelDesign），第二层ManagementSystem，就是我们要介绍的在管理层领域，它相当于是治理层的具体落地。治理层考虑顶层架构的设计，它属于战略，到这一层就属于战术层，战术层里面一般会涉及很多内容，比如质量管理、项目管理、投资、服务管理、风险、信息安全、业务连续性、供应商等等很多很多内容。一般情况下，业内把IT在管理层分成四块。首先是项目管理，因为通过项目才能给企业带来新的产品和服务，给企业带来盈利。第二块是风险管理，在很多大公司里面，他们会有专门的部门叫做风险合规部，作用就是控制企业在运营过程当中的风险，包括IT层面、法律层面、行业监管要求层面的合规风险。不同类型的企业关注侧重点可能不一样，比如说互联网公司，会优先关注产品投入、研发投入，而在传统的金融行业老大们往往会关注风险控制，因为对他们来说，企业赚不赚钱和领导没有关系，因为它的垄断地位，因为在资源层面的独占性，导致谁来做领导高层业绩都一样，反而是下面的技术骨干具有不可替代的作用，所以对这些老大们来说，更关注是在我任职期间不能出错，特别是不能犯大错，不要影响领导们的晋升，所以风险控制，合规这块往往成为高层非常关注的内容。第三块就是IT的运维，如何保证运维工作的稳健，这是企业里面生存的底线。第四块就是开发与测试。

今天我们主要要讲的内容是其中的第三块，也就是IT运维。在IT运维里面，ITIL是怎样一个地位呢？我先介绍一下ITIL背景，IT（InformationTechnology），IL（InfrastructureLibrary）基础架构/基础设施库，在老外眼里认为只要在运维过程当中涉及到的方方面面不仅是设备、软件、基础架构，甚至是人都可以作为一个要素纳入到ITIL管理过程中。ITIL这个东西是英国人发明的，英国人是出于什么背景来发明这个东西呢？上个世纪80年代英国人他们的商品在国际上的地位非常尴尬，因为性价比他们拼不过日本，价廉物美他们拼不过亚洲四小龙这些新兴国家和地区。论质量好、毛利率高，英国产品又拼不过德国产品，所以他们的地位非常尴尬，每年的出口不断在萎缩，所以从国家领导层层面（内阁）就非常头疼有什么办法可以提升英联邦国家这些产品的竞争力，他们想到了一点就是IT，通过IT成熟度的提升，降低因为故障或不成功变更带来的不必要的额外成本。因为在上世纪80年代，英国人IT普及率还是很高的，他在想，能不能把业内做得优秀的企业，他们的运维怎么管的经验，他们的数据中心，机房建设是怎么做的，把这些经验抽象出来，形成一套知识库或者叫最佳实践库，然后在全英联邦国家和地区进行推广，从而提升他们在IT上面的成熟度和竞争力，来给他们的产品带来竞争力，出于这个目的，他们花了九年时间，从1980年代初，到1980年代末，推出了第一个版本的ITIL。

现在已经2016年了，目前为止ITIL最新版本是第三版，同时在2011年打了一个补丁包。英国人在设计这套体系的时候认为，我们所有IT运维干的这些活都可以把它包装和抽象，抽象成服务这样一个载体。最新的ITIL版本内部逻辑结构就是以服务的生命周期为涉及的思路，首先服务的第一个阶段是战略制定，比如说公司的目标在哪里？市场空间和目标体在哪里？应该提交什么样的服务满足他们的需求，从而来给企业带来源源不断地盈利，这就是在战略阶段要去定的。当战略阶段定好要生产什么样服务的时候，接下去第二个阶段就是服务设计，相当于我们要开始立项，开始做成本控制，通过开发团队也好或者供应商也好，把这些一开始拍脑袋出来的服务和产品最终转化为现实，最后出来的产出就是我们最终的产品和服务。紧接着进入到第三个阶段服务转换，转换这个词不太常见，在IT体系里面它是什么呢？就是说当我们的产品从实验室里拿出来，想部署到我们现实环境里面去用的时候或者卖给客户去用的时候，往往需要计划设计方案，而且往往发现有太多的问题和风险，这些产品或方案在实际生产环境根本落不了地用不了，为什么？因为内嵌的这些流程、功能，在客户这边场景不一样，没有办法和现实的实际需求相匹配。往往我们要做一个很重要的工作,业内管它叫做客户定制化，所以在这个环节上往往这些大的企业，产品供应商他们会有更为庞大的实施团队,他们的任务就是在我们客户的现场，然后听客户新的需求，去改造他们现有的产品，最后确保他们的产品能够在我们的客户现场落地。而服务转换这个阶段主要目的就是为了利用变更等流程来控制期间的风险和成本，控制方案的设计和审批，确保最终成功地将设计的产品和服务部署上线。

那么在大家日常工作中可能经常会听到这样一个矛盾，开发团队与运维团队之间有矛盾。开发团队做出来一个新产品之后，他希望赶紧上线，这样就能够把项目成员早点释放掉，可以去接新的项目，去满足新的业务需求。可是往往站在运维的角度不愿意去做交接棒，为什么？往往在现实当中需求范围是变化的，是蔓延或者镀金的，范围控制不住，就导致开发周期边长，最终挤压的是测试的时间，因为在很多公司，最后的上线日期是不能改的，所以开发团队交给我们运维团队的这些产品我们心理都有数，BUG会有很多，尽管可能根据公司规章制度都会有相应的测试报告，测试报告上都签过了字，画过了押，但是大家心里都知道，脚本本身的质量和覆盖面是不可控的，所以就导致了从运维老大的角度是非常不愿意做这样的交接。你缺文档，缺培训，产品又是bug很多，一旦我接过来就是运维接下去的事情，如果进入运维环节产品再有这个那个问题，从最终用户和客户使用者角度，他们不会分析这是运维的问题还是开发代码的问题。他肯定认为是我们服务的问题，最终由运维来背所有的责任，所以从这个角度来说，往往公司内部的交接维就会出现冲突和交不过去的现象。甚至在某些公司会出现这样一个匪夷所思的现象。一个游戏产品已经用了很多年了，很多玩家对这个产品游戏都已经不玩了，最后下线的时候，它的版本依然叫做β版。什么叫β版？一般在企业里面，α版是内部测试，β版是在小范围体里面找一些粉丝来测，也就是说β版意味着没有交接，运维始终不认为这是正式产品移交。正式产品移交应该给他1.0的版本，可想而知，连这个游戏都要下线了，这个交接还没有交接成。所以这是业内站在CIO角度非常头疼的一个问题，开发的老大和运维的老大经常会有矛盾，有时还会吵到CIO面前。所以CIO会头疼，怎么办呢？既然都吵，那么你们就轮岗呗，运维的老大做一下开发的老大，开发的老大做一下运维的老大，然后互相知道彼此工作的不容易。说实话，如果真有这么大的决心来做这样调整的企业也不多，也只有一些小而美，小而精的互联网公司才有足够大的执行力来做这个事情。一旦服务转换工作完成了，产品和服务正式上线了，就进入下一个阶段服务运营，在运营过程中，我们的这些运维人员就像救火队员一样，或者换一个词，他就像主刀医师一样，而且这个主刀医师是心脏科的主刀医师，因为数据中心、机房现在就是企业的心脏，公司的决策层是大脑，离开了心脏，公司不能继续开展业务，甚至不能生存，这种趋势越来越明显。大家都是这个行业里面的老兵了，都会感觉到，这两年国家层面都在说“互联网+”，都在说大数据，这些都依赖于数据，而数据存放在哪里呢？都在我们IT运维团队管理的数据中心和机房，在我们的服务器上，而这些都是我们运维团队在维护，是企业的生命线，所以我们运维的作用越来越重要，而且其实我们IT运维可以做得更多。

在我们接触的这些IT部门老大的心目当中，他们往往心中都有一个愿景，他们希望能够把运维的工作尽可能做到标准化，因为当你把所有事儿做到标准化的时候，我才可以做下一步工作，也就是自动化。当自动化又能做好的情况下，才能进入新的领域叫做智慧化/智能化。因为你的位置越高，你担的风险责任就越大，其实那些老大们很孤单的。经常有的时候晚上深更半夜打一个电话，打到他这个地方，他心里就很拔凉拔凉的。晚上睡不好觉，睡不着觉。因为远远还没有做到标准化，更别谈后面的自动化、智慧化了，谁都保不齐今晚会不会有电话打过来，生产会不会中断和受影响。所以我们需要ITIL，需要运维领域里的最佳实践，我们从中吸取营养，来为我们的企业保障心脏的安全稳定“跳动”。

当这些生命周期的阶段都做完之后，在ITIL体系里面还有一个兜底的模块叫持续改进。在管理这个领域，我们很少能够一口吃个大胖子，今天是一个民营企业，通过做了个ITIL或者ISO20000项目，明天就能达到GE或者西门子等500强企业高度的成熟度，这是很难想象的。所以管理的提升必然是一个系统，是一个慢活，是需要小步快走的，这就需要持续性的服务改进，逐步的改善和提高。可是要想做到这一点有多难，我们可以拍脑袋想一想各位企业目前的现状，要建立一种机制，让这种机制在企业里面能够有生命力，能够确保每一个工作人员或者领导都有这个意识，知道我今天做这个工作，我一定要做好，要把它标准化下来，同时要有一双眼睛帮我去看看这些工作还有哪些可圈可点之处，哪些可以改进之处，这样的机制建立在很多企业里面是非常难做到的。但是可喜的是在很多互联网公司，与生俱来就有这种快速迭代，不断试错，快速改进的机制，在这种企业里面ITIL这样的机制就能落地的很好，而对大部分的企业和机构来说，就需要持续改进的机制来慢慢提升管理的成熟度。

接下来我们看看ITIL到底有什么样具体的流程？根据2011版第三版的定义，这些流程分别落在之前我们介绍的五个生命周期模块中，服务战略、设计、转化、运营和持续改进。看到这张流程的全景图，大家会不会感觉到好像很难实现，因为东西太多了。现实当中是什么样呢？即使那些五百强企业也很少把这么多流程都做得很好，都一一在企业里面落实，如果我们企业真的照这样去做的话，这里面的管理成本会很高。在现实当中我们怎么裁剪，如何去落地呢？

当年我在惠普做最佳实践库的时候，我们面对全世界的客户，就在最合理最具有普适性的流程，最后我们设计出来的流程图，如果贴在墙上，非常地复杂，能把一件40多平米的房间墙壁都贴满。站在中国企业的角度，尤其是那些小而美的企业，讲究迭代速度的企业这是不可想象的，不能接受的，太复杂，不具备可操作性，我们必须要先做最有价值的，能够在企业落地的，立竿见影的流程。

这张PPT就是我们多年经验的总结，大家看到有很多的输入和输出，里面有很多的方框，每一个活动其实就是指一个流程，那么从哪来呢？我们先从最上面开始看起，最上面有一个总纲，刚才给大家介绍过，ITIL这个体系很复杂，英国人写了30年想出来这个东西，信息量肯定是非常非常大的。这套体系在我们企业落地的时候，我们一般把这种项目叫做一把手工程，什么叫一把手工程？就是说这样的项目必须要IT老大层面，至少要运维数据中心老大层面必须优先关注的，因为要保证它的生命必须我们要建一套体系，体系是很复杂的，不是说头痛医头，脚痛医脚的，而是我们建立体系之后，这个体系是自己能够有自我修复机制，在企业里有生命力，能够不断进化的，所以体系最上层需要有总纲。在这个总纲里面，往往我们会定义，这个体系它的最终领导是谁？目的是什么？范围是什么？里面的人员组织架构是什么？游戏规则是什么？各个角色的职责是什么？方针策略怎么样？都要定清楚。就有点类似一开始我们开篇给大家介绍的治理，从治理层面要做的事情，一般都是定战略，定班子，定体系架构，班子就是组织架构，要去把这个东西定义清楚，然后把这个架构给设计好，在总纲之下，会有四个主要的支撑性流程，分别是文档流程，因为体系会包括很多的制度，会有很多的模板要标准化下来，在企业里面会有很多的指引，规范，SOP这些东西，你要把他们的规则定清楚，谁可以修改，在哪儿归档，命名规则是什么？这些需要在文档流程中定义清楚。除了文档，我们还需要建立内部审核和管理评审的流程机制，这是个什么概念？在西方目前主流的管理体系里面，他们一般会遵循X理论，什么叫X理论？即认为人性本恶，如果你的权利很大，没有人监管，肯定会做坏事，所以在企业里面往往会有执行部门，管理部门，同时还会有一套监管的团队，就像军队里的宪兵。在银行，我们一般叫做三道防线，第一道防线就是执行部门，谁执行了，谁负责第一道防线来控制风险，第二道风险往往是企业的合规和风险部门，第三道防线往往是审计部门，可以是内部审计，也可以请专业的，外部的审核机构来确保我们有没有按照我们制定的制度要求去执行，我们希望利用内审和管审流程，也能够建立这么一个机制，就像明朝的东厂和西厂，当然我们不会“白色恐怖”，但当我们的员工不遵守我们体系里面的制定的这些规则和要求时，我们希望能及时发现，及时纠正。们刚才听了大家介绍，在座诸位有很多是来自制造业的朋友，在你们企业里面肯定会落地5S，6s，6sigma，TQM，其实在这些体系里面，都会有这样的角色出现，第三块就是持续改进的机制，就是刚才我们说的ITILv3模型中最外圈的内容，在很多企业里面往往会这样一个匪夷所思的情况，领导开会，经常开会，会上有很多决议，但是感觉这些决议表决是通过了，但谁来执行，谁来检查，谁来跟踪，什么时候完成，就没有下文了，为了开会而开会，浪费很多大家宝贵的时间，管理成本也很高，这个持续改进机制就是来保证，相当于每次开会的时候，每次出报告的时候，每次我们做审核的时候，那些发现的有问题的点，都有专人去记录下来，直接向高层领导去汇报，把它记在自己的日志或者专门的登记册里，记录下来，然后规定好谁整改，什么时间点交付，怎样的机制来保障这个方案的可落地性，有这套这种监控和跟踪的机制，这就是我们的持续改进。最后一块是我们的培训，因为大家知道，好的企业，往往很舍得在员工的培训上花工夫，你看这些500强的企业，往往重视意识层面的培训，我们业内往往开玩笑叫“洗脑”，反复的洗，最后大家的行为习惯都一致，企业的目的就达到了，其实从这一点讲，在公司管理机制过程当中，很多情况下，越来越成熟的公司，就越来越趋向于标准化，流水线化，什么意思？就是希望我们的IT的每个员工，就像我们生产车间里面的工人一样，你负责螺丝钉就是负责做螺丝钉，新的员工进来了，经过两三个星期的培训，马上上岗了，不会因为在企业里面某些II的老人，这些专家牛人，离开公司或被竞争对手挖掉，最后我们服务的产品质量发生大幅度的一个变化，这是领导层面非常不愿意看到的，所以在落地ITIL的过程当中，往往我们的一些员工，尤其我们一线员工很容易抵制，为什么？你想，平时我重启服务器，或者是装一个硬盘，分分秒就做掉了，五分钟，十几分钟就搞定了，现在有了ITIL，我要先填单，领导再审批，层层授权，如果万一重要领导在开会或者在休假，等他批下来，有可能黄花菜都凉了，而业务部门的人这时候就会觉得我们运维的人官僚，要层层汇报，领导批完，我们再去做，业务这些的压力就已经顶不住了，所以他们往往觉得ITIL，在企业里面，非常有效的扼杀了我们工作的效益，我不知道各位有没有这种困惑。非常有效率地扼杀了我们运维的效率，提高了我们管理的成本。往往这也就是为什么在很多企业里面，如果不是500强，基于他们根深蒂固的企业文化，很多企业在落地ITIL的时候，会有很大的意识形态上的阻碍，一线工作人员会反对，甚至有些管理层的领导也许会觉得这个东西不靠谱，我们如何理解呢，难道老外想了30年的东西真的是糟粕吗？为了理解这个问题，我拿开车举例，在座的各位，你们都开过车，至少都坐过车，对一个司机来说怎么开车是最有效？一脚油门踩到底，想怎么开就怎么开，想怎么漂移就怎么漂移，对司机来说是最有效的，但是试想，如果我们每一个司机都这么开车，那结果就是到处都是交通事故，导出都有交通拥堵，不可想象的。所以我们定那么多的交通规则，定义红绿灯的机制，还设了交警，目的是为了什么？目的不是为了限制司机，而是为了让有限的交通道路资源尽可能公平合理在我们广大的司机中间得到分享，从一个更高层面来确保整个国家的交通机制是最有效运作的，所以ITIL也是一样，一定程度上它的确会牺牲个人的效率，但是从公司层面来说，这是合适的，这是可取的，这是必须要做的，而且关键是这是节省成本的，因为每一次的服务中断和性能下降，都能被记录，都能被追溯分析，都可以借机改进并形成知识库传承，这要比不做管理，每次都是靠天吃饭，高管层每晚都担心出事，出了事也没有办法确保下次不出事，要省成本的多。利用ITIL机制，确保企业的运维管理走在正确的不断良性循环改善提升的道路上，尽管上ITIL开始是个人效率降低了，也有一定的投入，但从长远来看，这是值得的,尤其当我们员工的规模，运维团队要提供服务的系统和服务器数量不断上升的时候，这个事就必须要做，靠人治的方式已经管不过来了，而这也是当初英国人设计ITIL的初衷，节省成本并确保生产环境稳定运行。

在落地ITIL的过程当中，除了以上说的总纲和四大支撑流程之外，我们还会有哪些流程帮助我们呢？我们看这张图，大家看到，左边有很多的方框，这往往是企业里面的监管或者是客户团队，他们会关注什么呢？如何确保他们的满意度呢？我们需要有业务关系流程，业务关系在很多IT的部门里面做得不好，因为我们IT的人比较实诚，往往就是苦干，蛮干，然后也不知道怎么表现自己。所以从领导层面看不到我们的辛勤劳动，业务关系管理的目的就是让我们领导看到我们IT的成绩，就像刚才我们看到的同程展示的很高大上的大数据分析界面，这其实就是一个很好的展示平台。

同样我们要有服务级别管理流程，相当于我们要和我们的业务部门达成一个协议，你要我们运维团队，要我们数据中心，要求到底要达到什么样的一个质量要求，咱们名面上讲，白纸黑字地写下来，这样我们的IT运维的目标非常地明确，而且反过来可以去规范和约束客户这些需求的，因为很多情况下，客户的需求是无止境的。你今天给了他五分，他明天要七分，他后天要更多，这个东西要和我们的后面的成本关联，要和客户的付出关联。

我们还需要有报告机制，报告的内容可以包括很多，会有我们的可用性，连续性和容量等信息，连续性指的是什么意思？当我们的服务中断的情况下，我如何快速地把我们的灾备系统切换出来，两地三中心就是来做这样的事情。容量的定义是什么？当我一个新系统上线的时候，我要考虑到我现在的硬件软件够不够用，我的人够不够，我这些人的培训意识有没有达到我的要求，这是需要在容量这方面进行很好的规划的。

我们再看右边，右边往往是我们最终IT产品和服务的使用者，当他们报一些故障或者是一些请求的时候，往往会通过我们建立的服务台，服务台接收他们的一些工单的时候，我们会分为两类，一个叫做服务请求，一个叫做事件，有的企业里面叫做故障，是指我们的业务或IT系统真的中断了，是否我们IT的错，如果是则需要纳入事件流程的管理，而服务请求指的是什么？我们IT没有错，是业务部门用户需要我们的帮助，他需要一些信息，需要咨询，需要我们提供报表或者需要我们为他们做点风险较小的变更时，就会提到服务请求，区分了事件和服务请求，这样拉出报告，哪些是我们IT做得不好，哪些是帮我们的客户的内容，就有了分门别类，除此之外，事件还会跟问题进行区分和关联，事件团队更多的像一个救火员，往往他们的方案都是临时性的，比如说重装，重启，重新购买，相当于治标不治本，但是有些事情必须要治本，因为这些故障对我们企业来说是不可承受之重，我们往往叫做零容忍的故障，所以必须要有一个问题团队在这儿，去层层抽丝剥茧，找到根本原因，找到永久解决方案，把这个事情解决了，这个是问题团队要去做的，而不管是事件还是问题，最终这些方案都要通过变更去实施，所以我们需要变更流程去执行控制，设计变更方案，获得相关领导审批，在生产环境部署上线实施，我们变更的对象则会放到一个叫做CMDB配置管理库的地方，里面所有的配置项CI信息都在里面得以呈现，最重要的是有一张CI配置项的关系图。有了这张图，我们就可以清晰地看到，我们的那些业务和系统，和服务器，和软件，和其它相关配置项之间的关系，这些逻辑或物理关系，在一个配置项往上看，可以清晰地看到此次变更影响的范围有多大，往下看，当做HA高可用的时候，我就会知道，哪些点是我们的单点故障，是我们需要投入冗余资源的地方，所以这张关系图非常重要。

各流程之间要进行必要的打通，在这些流程里面还有一个比较奇怪的流程，叫做新增或变更的服务管理流程，这个流程是干嘛的，ITIL体系里面没有，但是我们的实践过程中我们认为它非常重要，在ISO20000中就有出现，这个流程就是要解决刚开始给大家抛的那个问题，开发和运维团队之间的矛盾，这个流程就是来规范开发和运维之间要交接什么，要提什么样验收标准，要有什么样的审批，授权，我们把这些标准定清楚，这样在交接的过程中才能有法可依，而不是凭关系远近，大家关系好，我运维团队的老大就硬着头皮，把这个事给接了，结果最后的很多的脏活累活往往都全部由我们运维来抗，所以这个流程就是处理交接维的。

除了上面介绍的流程外，我们还有两个流程，在有些单位里就非常重要，一个是IT的预算和核算，一个是供应商管理。

为什么呢？随着我们IT的重要性越来越高，其实我们IT的老大非常地希望，当我们运维团队做那些服务的时候，希望知道，我做一个变更到底花多少钱，我给客户提供一个服务，后面的成本是多少，希望能够算清楚这笔账，然后和收益做比较，算ROI。算清楚成本有什么好处呢？因为我们做咨询，经常见到各种各样的客户，我们会发现现在越来越多企业里面的IT部门会慢慢有了这种需求，他希望数据中心能够从公司里面独立出来成为一家能够独立运营结算的IT子公司，而成本模型的建立，合理的预算核算机制就是独立运营的前提，除此以外还有一块非常重要的领域叫供应商管理，因为我们现在的IT部门越来越严重依赖供应商，去年我帮一家国有商业银行总行做了一个全球供应商的管理规划，在做项目的过程中，就发现了，他们银行里面的正式员工和供应商的外包人员的比例是1：3，平均每个正式员工需要管3个外包员工，这比例是相当高的，必须要对供应商进行统一的管理，从入围，招投标，到项目中的绩效评价，到年底的供应商打分入库都需要专业的流程和工具去管理。

最后就以这张大图向大家展示了利用ITIL，在企业中最迫切需要落地最立竿见影的几个主线流程以及他们之间的关联关系，希望能给大家带来思考和启发，我今天要演讲的部分就是这些，谢谢大家。

来自微信IT人俱乐部

学习资料：IT运维管理社区专家讲堂直播300期视频回放

业产品开发和运维之间有冲突如同家常便饭

但是当两者矛盾加剧的时候，

CIO们，你咋看？

通常情况下，CIO们一般站在开发项目组角度说话，因为对于企业老总来说，开发能产生新产品，能产生新的服务、获得利润，这是能够看到的。但其实这种现状一直在逐渐改变，CIO们，你们找到准确方向了吗？

6月2日,苏州IT人俱乐部在苏州同程旅游大楼组织了一场沙龙活动，现场特邀讲师Jason做了关于CIO看待ITIL的干货分享。

Jason，华东地区最资深的ITIL专业咨询顾问，在本领域已经耕耘了13年，同时也是中国大数据治理国标编写组专家成员之一。在他做咨询过程的当中，经常会遇到负责开发和运维的老大们起冲突。对于这种现状，Jason总结数年工作心得，现场做了关于《从CIO角度如何看待ITIL》的主题分享。

以下是现场干货分享回顾，略修改。

---

在业内，从IT治理的层面，高层领导一般会怎么去思考呢？也就是说，站在CIO和IT经理们的角度，他们怎么去思考公司的IT治理？根据国际信息系统审计协会（ISACA）编写的COBIT，还有IT治理领域的国际标准ISO38500的介绍，有三个职责活动是IT高管层面，站在治理的高度需要考虑的，业内叫做EDM，即评估、指导和监控，接下来我们详细解释一下。

第一个是指导，定战略，定组织，定架构，把这些游戏规则设定好。第二个是接受反馈，能够建立起一套监控机制，通过监控机制可以把我们的中层管理者，还有我们的运营层的信息及时反馈上来，看之前定的战略等规则是否不择不扣的执行了。第三个是分析评估，通过收集到的反馈结果来看我们的目标有没有达成，战略是不是有缺失，组织架构是否定义合理。这三项工作是业内公认的、在治理层面上CIO们首当应该考虑的内容。

在这个EDM模型的下方紧跟着就是管理层，这层其实就包含了今天的主题ITIL。这个层面主要会有哪些内容呢？刚才有介绍到治理层（Top-levelDesign），第二层ManagementSystem，就是我们要介绍的在管理层领域，它相当于是治理层的具体落地。治理层考虑顶层架构的设计，它属于战略，到这一层就属于战术层，战术层里面一般会涉及很多内容，比如质量管理、项目管理、投资、服务管理、风险、信息安全、业务连续性、供应商等等很多很多内容。一般情况下，业内把IT在管理层分成四块。首先是项目管理，因为通过项目才能给企业带来新的产品和服务，给企业带来盈利。第二块是风险管理，在很多大公司里面，他们会有专门的部门叫做风险合规部，作用就是控制企业在运营过程当中的风险，包括IT层面、法律层面、行业监管要求层面的合规风险。不同类型的企业关注侧重点可能不一样，比如说互联网公司，会优先关注产品投入、研发投入，而在传统的金融行业老大们往往会关注风险控制，因为对他们来说，企业赚不赚钱和领导没有关系，因为它的垄断地位，因为在资源层面的独占性，导致谁来做领导高层业绩都一样，反而是下面的技术骨干具有不可替代的作用，所以对这些老大们来说，更关注是在我任职期间不能出错，特别是不能犯大错，不要影响领导们的晋升，所以风险控制，合规这块往往成为高层非常关注的内容。第三块就是IT的运维，如何保证运维工作的稳健，这是企业里面生存的底线。第四块就是开发与测试。

今天我们主要要讲的内容是其中的第三块，也就是IT运维。在IT运维里面，ITIL是怎样一个地位呢？我先介绍一下ITIL背景，IT（InformationTechnology），IL（InfrastructureLibrary）基础架构/基础设施库，在老外眼里认为只要在运维过程当中涉及到的方方面面不仅是设备、软件、基础架构，甚至是人都可以作为一个要素纳入到ITIL管理过程中。ITIL这个东西是英国人发明的，英国人是出于什么背景来发明这个东西呢？上个世纪80年代英国人他们的商品在国际上的地位非常尴尬，因为性价比他们拼不过日本，价廉物美他们拼不过亚洲四小龙这些新兴国家和地区。论质量好、毛利率高，英国产品又拼不过德国产品，所以他们的地位非常尴尬，每年的出口不断在萎缩，所以从国家领导层层面（内阁）就非常头疼有什么办法可以提升英联邦国家这些产品的竞争力，他们想到了一点就是IT，通过IT成熟度的提升，降低因为故障或不成功变更带来的不必要的额外成本。因为在上世纪80年代，英国人IT普及率还是很高的，他在想，能不能把业内做得优秀的企业，他们的运维怎么管的经验，他们的数据中心，机房建设是怎么做的，把这些经验抽象出来，形成一套知识库或者叫最佳实践库，然后在全英联邦国家和地区进行推广，从而提升他们在IT上面的成熟度和竞争力，来给他们的产品带来竞争力，出于这个目的，他们花了九年时间，从1980年代初，到1980年代末，推出了第一个版本的ITIL。

现在已经2016年了，目前为止ITIL最新版本是第三版，同时在2011年打了一个补丁包。英国人在设计这套体系的时候认为，我们所有IT运维干的这些活都可以把它包装和抽象，抽象成服务这样一个载体。最新的ITIL版本内部逻辑结构就是以服务的生命周期为涉及的思路，首先服务的第一个阶段是战略制定，比如说公司的目标在哪里？市场空间和目标体在哪里？应该提交什么样的服务满足他们的需求，从而来给企业带来源源不断地盈利，这就是在战略阶段要去定的。当战略阶段定好要生产什么样服务的时候，接下去第二个阶段就是服务设计，相当于我们要开始立项，开始做成本控制，通过开发团队也好或者供应商也好，把这些一开始拍脑袋出来的服务和产品最终转化为现实，最后出来的产出就是我们最终的产品和服务。紧接着进入到第三个阶段服务转换，转换这个词不太常见，在IT体系里面它是什么呢？就是说当我们的产品从实验室里拿出来，想部署到我们现实环境里面去用的时候或者卖给客户去用的时候，往往需要计划设计方案，而且往往发现有太多的问题和风险，这些产品或方案在实际生产环境根本落不了地用不了，为什么？因为内嵌的这些流程、功能，在客户这边场景不一样，没有办法和现实的实际需求相匹配。往往我们要做一个很重要的工作,业内管它叫做客户定制化，所以在这个环节上往往这些大的企业，产品供应商他们会有更为庞大的实施团队,他们的任务就是在我们客户的现场，然后听客户新的需求，去改造他们现有的产品，最后确保他们的产品能够在我们的客户现场落地。而服务转换这个阶段主要目的就是为了利用变更等流程来控制期间的风险和成本，控制方案的设计和审批，确保最终成功地将设计的产品和服务部署上线。

那么在大家日常工作中可能经常会听到这样一个矛盾，开发团队与运维团队之间有矛盾。开发团队做出来一个新产品之后，他希望赶紧上线，这样就能够把项目成员早点释放掉，可以去接新的项目，去满足新的业务需求。可是往往站在运维的角度不愿意去做交接棒，为什么？往往在现实当中需求范围是变化的，是蔓延或者镀金的，范围控制不住，就导致开发周期边长，最终挤压的是测试的时间，因为在很多公司，最后的上线日期是不能改的，所以开发团队交给我们运维团队的这些产品我们心理都有数，BUG会有很多，尽管可能根据公司规章制度都会有相应的测试报告，测试报告上都签过了字，画过了押，但是大家心里都知道，脚本本身的质量和覆盖面是不可控的，所以就导致了从运维老大的角度是非常不愿意做这样的交接。你缺文档，缺培训，产品又是bug很多，一旦我接过来就是运维接下去的事情，如果进入运维环节产品再有这个那个问题，从最终用户和客户使用者角度，他们不会分析这是运维的问题还是开发代码的问题。他肯定认为是我们服务的问题，最终由运维来背所有的责任，所以从这个角度来说，往往公司内部的交接维就会出现冲突和交不过去的现象。甚至在某些公司会出现这样一个匪夷所思的现象。一个游戏产品已经用了很多年了，很多玩家对这个产品游戏都已经不玩了，最后下线的时候，它的版本依然叫做β版。什么叫β版？一般在企业里面，α版是内部测试，β版是在小范围体里面找一些粉丝来测，也就是说β版意味着没有交接，运维始终不认为这是正式产品移交。正式产品移交应该给他1.0的版本，可想而知，连这个游戏都要下线了，这个交接还没有交接成。所以这是业内站在CIO角度非常头疼的一个问题，开发的老大和运维的老大经常会有矛盾，有时还会吵到CIO面前。所以CIO会头疼，怎么办呢？既然都吵，那么你们就轮岗呗，运维的老大做一下开发的老大，开发的老大做一下运维的老大，然后互相知道彼此工作的不容易。说实话，如果真有这么大的决心来做这样调整的企业也不多，也只有一些小而美，小而精的互联网公司才有足够大的执行力来做这个事情。一旦服务转换工作完成了，产品和服务正式上线了，就进入下一个阶段服务运营，在运营过程中，我们的这些运维人员就像救火队员一样，或者换一个词，他就像主刀医师一样，而且这个主刀医师是心脏科的主刀医师，因为数据中心、机房现在就是企业的心脏，公司的决策层是大脑，离开了心脏，公司不能继续开展业务，甚至不能生存，这种趋势越来越明显。大家都是这个行业里面的老兵了，都会感觉到，这两年国家层面都在说“互联网+”，都在说大数据，这些都依赖于数据，而数据存放在哪里呢？都在我们IT运维团队管理的数据中心和机房，在我们的服务器上，而这些都是我们运维团队在维护，是企业的生命线，所以我们运维的作用越来越重要，而且其实我们IT运维可以做得更多。

在我们接触的这些IT部门老大的心目当中，他们往往心中都有一个愿景，他们希望能够把运维的工作尽可能做到标准化，因为当你把所有事儿做到标准化的时候，我才可以做下一步工作，也就是自动化。当自动化又能做好的情况下，才能进入新的领域叫做智慧化/智能化。因为你的位置越高，你担的风险责任就越大，其实那些老大们很孤单的。经常有的时候晚上深更半夜打一个电话，打到他这个地方，他心里就很拔凉拔凉的。晚上睡不好觉，睡不着觉。因为远远还没有做到标准化，更别谈后面的自动化、智慧化了，谁都保不齐今晚会不会有电话打过来，生产会不会中断和受影响。所以我们需要ITIL，需要运维领域里的最佳实践，我们从中吸取营养，来为我们的企业保障心脏的安全稳定“跳动”。

当这些生命周期的阶段都做完之后，在ITIL体系里面还有一个兜底的模块叫持续改进。在管理这个领域，我们很少能够一口吃个大胖子，今天是一个民营企业，通过做了个ITIL或者ISO20000项目，明天就能达到GE或者西门子等500强企业高度的成熟度，这是很难想象的。所以管理的提升必然是一个系统，是一个慢活，是需要小步快走的，这就需要持续性的服务改进，逐步的改善和提高。可是要想做到这一点有多难，我们可以拍脑袋想一想各位企业目前的现状，要建立一种机制，让这种机制在企业里面能够有生命力，能够确保每一个工作人员或者领导都有这个意识，知道我今天做这个工作，我一定要做好，要把它标准化下来，同时要有一双眼睛帮我去看看这些工作还有哪些可圈可点之处，哪些可以改进之处，这样的机制建立在很多企业里面是非常难做到的。但是可喜的是在很多互联网公司，与生俱来就有这种快速迭代，不断试错，快速改进的机制，在这种企业里面ITIL这样的机制就能落地的很好，而对大部分的企业和机构来说，就需要持续改进的机制来慢慢提升管理的成熟度。

接下来我们看看ITIL到底有什么样具体的流程？根据2011版第三版的定义，这些流程分别落在之前我们介绍的五个生命周期模块中，服务战略、设计、转化、运营和持续改进。看到这张流程的全景图，大家会不会感觉到好像很难实现，因为东西太多了。现实当中是什么样呢？即使那些五百强企业也很少把这么多流程都做得很好，都一一在企业里面落实，如果我们企业真的照这样去做的话，这里面的管理成本会很高。在现实当中我们怎么裁剪，如何去落地呢？

当年我在惠普做最佳实践库的时候，我们面对全世界的客户，就在最合理最具有普适性的流程，最后我们设计出来的流程图，如果贴在墙上，非常地复杂，能把一件40多平米的房间墙壁都贴满。站在中国企业的角度，尤其是那些小而美的企业，讲究迭代速度的企业这是不可想象的，不能接受的，太复杂，不具备可操作性，我们必须要先做最有价值的，能够在企业落地的，立竿见影的流程。

这张PPT就是我们多年经验的总结，大家看到有很多的输入和输出，里面有很多的方框，每一个活动其实就是指一个流程，那么从哪来呢？我们先从最上面开始看起，最上面有一个总纲，刚才给大家介绍过，ITIL这个体系很复杂，英国人写了30年想出来这个东西，信息量肯定是非常非常大的。这套体系在我们企业落地的时候，我们一般把这种项目叫做一把手工程，什么叫一把手工程？就是说这样的项目必须要IT老大层面，至少要运维数据中心老大层面必须优先关注的，因为要保证它的生命必须我们要建一套体系，体系是很复杂的，不是说头痛医头，脚痛医脚的，而是我们建立体系之后，这个体系是自己能够有自我修复机制，在企业里有生命力，能够不断进化的，所以体系最上层需要有总纲。在这个总纲里面，往往我们会定义，这个体系它的最终领导是谁？目的是什么？范围是什么？里面的人员组织架构是什么？游戏规则是什么？各个角色的职责是什么？方针策略怎么样？都要定清楚。就有点类似一开始我们开篇给大家介绍的治理，从治理层面要做的事情，一般都是定战略，定班子，定体系架构，班子就是组织架构，要去把这个东西定义清楚，然后把这个架构给设计好，在总纲之下，会有四个主要的支撑性流程，分别是文档流程，因为体系会包括很多的制度，会有很多的模板要标准化下来，在企业里面会有很多的指引，规范，SOP这些东西，你要把他们的规则定清楚，谁可以修改，在哪儿归档，命名规则是什么？这些需要在文档流程中定义清楚。除了文档，我们还需要建立内部审核和管理评审的流程机制，这是个什么概念？在西方目前主流的管理体系里面，他们一般会遵循X理论，什么叫X理论？即认为人性本恶，如果你的权利很大，没有人监管，肯定会做坏事，所以在企业里面往往会有执行部门，管理部门，同时还会有一套监管的团队，就像军队里的宪兵。在银行，我们一般叫做三道防线，第一道防线就是执行部门，谁执行了，谁负责第一道防线来控制风险，第二道风险往往是企业的合规和风险部门，第三道防线往往是审计部门，可以是内部审计，也可以请专业的，外部的审核机构来确保我们有没有按照我们制定的制度要求去执行，我们希望利用内审和管审流程，也能够建立这么一个机制，就像明朝的东厂和西厂，当然我们不会“白色恐怖”，但当我们的员工不遵守我们体系里面的制定的这些规则和要求时，我们希望能及时发现，及时纠正。们刚才听了大家介绍，在座诸位有很多是来自制造业的朋友，在你们企业里面肯定会落地5S，6s，6sigma，TQM，其实在这些体系里面，都会有这样的角色出现，第三块就是持续改进的机制，就是刚才我们说的ITILv3模型中最外圈的内容，在很多企业里面往往会这样一个匪夷所思的情况，领导开会，经常开会，会上有很多决议，但是感觉这些决议表决是通过了，但谁来执行，谁来检查，谁来跟踪，什么时候完成，就没有下文了，为了开会而开会，浪费很多大家宝贵的时间，管理成本也很高，这个持续改进机制就是来保证，相当于每次开会的时候，每次出报告的时候，每次我们做审核的时候，那些发现的有问题的点，都有专人去记录下来，直接向高层领导去汇报，把它记在自己的日志或者专门的登记册里，记录下来，然后规定好谁整改，什么时间点交付，怎样的机制来保障这个方案的可落地性，有这套这种监控和跟踪的机制，这就是我们的持续改进。最后一块是我们的培训，因为大家知道，好的企业，往往很舍得在员工的培训上花工夫，你看这些500强的企业，往往重视意识层面的培训，我们业内往往开玩笑叫“洗脑”，反复的洗，最后大家的行为习惯都一致，企业的目的就达到了，其实从这一点讲，在公司管理机制过程当中，很多情况下，越来越成熟的公司，就越来越趋向于标准化，流水线化，什么意思？就是希望我们的IT的每个员工，就像我们生产车间里面的工人一样，你负责螺丝钉就是负责做螺丝钉，新的员工进来了，经过两三个星期的培训，马上上岗了，不会因为在企业里面某些II的老人，这些专家牛人，离开公司或被竞争对手挖掉，最后我们服务的产品质量发生大幅度的一个变化，这是领导层面非常不愿意看到的，所以在落地ITIL的过程当中，往往我们的一些员工，尤其我们一线员工很容易抵制，为什么？你想，平时我重启服务器，或者是装一个硬盘，分分秒就做掉了，五分钟，十几分钟就搞定了，现在有了ITIL，我要先填单，领导再审批，层层授权，如果万一重要领导在开会或者在休假，等他批下来，有可能黄花菜都凉了，而业务部门的人这时候就会觉得我们运维的人官僚，要层层汇报，领导批完，我们再去做，业务这些的压力就已经顶不住了，所以他们往往觉得ITIL，在企业里面，非常有效的扼杀了我们工作的效益，我不知道各位有没有这种困惑。非常有效率地扼杀了我们运维的效率，提高了我们管理的成本。往往这也就是为什么在很多企业里面，如果不是500强，基于他们根深蒂固的企业文化，很多企业在落地ITIL的时候，会有很大的意识形态上的阻碍，一线工作人员会反对，甚至有些管理层的领导也许会觉得这个东西不靠谱，我们如何理解呢，难道老外想了30年的东西真的是糟粕吗？为了理解这个问题，我拿开车举例，在座的各位，你们都开过车，至少都坐过车，对一个司机来说怎么开车是最有效？一脚油门踩到底，想怎么开就怎么开，想怎么漂移就怎么漂移，对司机来说是最有效的，但是试想，如果我们每一个司机都这么开车，那结果就是到处都是交通事故，导出都有交通拥堵，不可想象的。所以我们定那么多的交通规则，定义红绿灯的机制，还设了交警，目的是为了什么？目的不是为了限制司机，而是为了让有限的交通道路资源尽可能公平合理在我们广大的司机中间得到分享，从一个更高层面来确保整个国家的交通机制是最有效运作的，所以ITIL也是一样，一定程度上它的确会牺牲个人的效率，但是从公司层面来说，这是合适的，这是可取的，这是必须要做的，而且关键是这是节省成本的，因为每一次的服务中断和性能下降，都能被记录，都能被追溯分析，都可以借机改进并形成知识库传承，这要比不做管理，每次都是靠天吃饭，高管层每晚都担心出事，出了事也没有办法确保下次不出事，要省成本的多。利用ITIL机制，确保企业的运维管理走在正确的不断良性循环改善提升的道路上，尽管上ITIL开始是个人效率降低了，也有一定的投入，但从长远来看，这是值得的,尤其当我们员工的规模，运维团队要提供服务的系统和服务器数量不断上升的时候，这个事就必须要做，靠人治的方式已经管不过来了，而这也是当初英国人设计ITIL的初衷，节省成本并确保生产环境稳定运行。

在落地ITIL的过程当中，除了以上说的总纲和四大支撑流程之外，我们还会有哪些流程帮助我们呢？我们看这张图，大家看到，左边有很多的方框，这往往是企业里面的监管或者是客户团队，他们会关注什么呢？如何确保他们的满意度呢？我们需要有业务关系流程，业务关系在很多IT的部门里面做得不好，因为我们IT的人比较实诚，往往就是苦干，蛮干，然后也不知道怎么表现自己。所以从领导层面看不到我们的辛勤劳动，业务关系管理的目的就是让我们领导看到我们IT的成绩，就像刚才我们看到的同程展示的很高大上的大数据分析界面，这其实就是一个很好的展示平台。

同样我们要有服务级别管理流程，相当于我们要和我们的业务部门达成一个协议，你要我们运维团队，要我们数据中心，要求到底要达到什么样的一个质量要求，咱们名面上讲，白纸黑字地写下来，这样我们的IT运维的目标非常地明确，而且反过来可以去规范和约束客户这些需求的，因为很多情况下，客户的需求是无止境的。你今天给了他五分，他明天要七分，他后天要更多，这个东西要和我们的后面的成本关联，要和客户的付出关联。

我们还需要有报告机制，报告的内容可以包括很多，会有我们的可用性，连续性和容量等信息，连续性指的是什么意思？当我们的服务中断的情况下，我如何快速地把我们的灾备系统切换出来，两地三中心就是来做这样的事情。容量的定义是什么？当我一个新系统上线的时候，我要考虑到我现在的硬件软件够不够用，我的人够不够，我这些人的培训意识有没有达到我的要求，这是需要在容量这方面进行很好的规划的。

我们再看右边，右边往往是我们最终IT产品和服务的使用者，当他们报一些故障或者是一些请求的时候，往往会通过我们建立的服务台，服务台接收他们的一些工单的时候，我们会分为两类，一个叫做服务请求，一个叫做事件，有的企业里面叫做故障，是指我们的业务或IT系统真的中断了，是否我们IT的错，如果是则需要纳入事件流程的管理，而服务请求指的是什么？我们IT没有错，是业务部门用户需要我们的帮助，他需要一些信息，需要咨询，需要我们提供报表或者需要我们为他们做点风险较小的变更时，就会提到服务请求，区分了事件和服务请求，这样拉出报告，哪些是我们IT做得不好，哪些是帮我们的客户的内容，就有了分门别类，除此之外，事件还会跟问题进行区分和关联，事件团队更多的像一个救火员，往往他们的方案都是临时性的，比如说重装，重启，重新购买，相当于治标不治本，但是有些事情必须要治本，因为这些故障对我们企业来说是不可承受之重，我们往往叫做零容忍的故障，所以必须要有一个问题团队在这儿，去层层抽丝剥茧，找到根本原因，找到永久解决方案，把这个事情解决了，这个是问题团队要去做的，而不管是事件还是问题，最终这些方案都要通过变更去实施，所以我们需要变更流程去执行控制，设计变更方案，获得相关领导审批，在生产环境部署上线实施，我们变更的对象则会放到一个叫做CMDB配置管理库的地方，里面所有的配置项CI信息都在里面得以呈现，最重要的是有一张CI配置项的关系图。有了这张图，我们就可以清晰地看到，我们的那些业务和系统，和服务器，和软件，和其它相关配置项之间的关系，这些逻辑或物理关系，在一个配置项往上看，可以清晰地看到此次变更影响的范围有多大，往下看，当做HA高可用的时候，我就会知道，哪些点是我们的单点故障，是我们需要投入冗余资源的地方，所以这张关系图非常重要。

各流程之间要进行必要的打通，在这些流程里面还有一个比较奇怪的流程，叫做新增或变更的服务管理流程，这个流程是干嘛的，ITIL体系里面没有，但是我们的实践过程中我们认为它非常重要，在ISO20000中就有出现，这个流程就是要解决刚开始给大家抛的那个问题，开发和运维团队之间的矛盾，这个流程就是来规范开发和运维之间要交接什么，要提什么样验收标准，要有什么样的审批，授权，我们把这些标准定清楚，这样在交接的过程中才能有法可依，而不是凭关系远近，大家关系好，我运维团队的老大就硬着头皮，把这个事给接了，结果最后的很多的脏活累活往往都全部由我们运维来抗，所以这个流程就是处理交接维的。

除了上面介绍的流程外，我们还有两个流程，在有些单位里就非常重要，一个是IT的预算和核算，一个是供应商管理。

为什么呢？随着我们IT的重要性越来越高，其实我们IT的老大非常地希望，当我们运维团队做那些服务的时候，希望知道，我做一个变更到底花多少钱，我给客户提供一个服务，后面的成本是多少，希望能够算清楚这笔账，然后和收益做比较，算ROI。算清楚成本有什么好处呢？因为我们做咨询，经常见到各种各样的客户，我们会发现现在越来越多企业里面的IT部门会慢慢有了这种需求，他希望数据中心能够从公司里面独立出来成为一家能够独立运营结算的IT子公司，而成本模型的建立，合理的预算核算机制就是独立运营的前提，除此以外还有一块非常重要的领域叫供应商管理，因为我们现在的IT部门越来越严重依赖供应商，去年我帮一家国有商业银行总行做了一个全球供应商的管理规划，在做项目的过程中，就发现了，他们银行里面的正式员工和供应商的外包人员的比例是1：3，平均每个正式员工需要管3个外包员工，这比例是相当高的，必须要对供应商进行统一的管理，从入围，招投标，到项目中的绩效评价，到年底的供应商打分入库都需要专业的流程和工具去管理。

最后就以这张大图向大家展示了利用ITIL，在企业中最迫切需要落地最立竿见影的几个主线流程以及他们之间的关联关系，希望能给大家带来思考和启发，我今天要演讲的部分就是这些，谢谢大家。

来自微信IT人俱乐部