学习资料： ITIL先锋论坛专家讲堂直播 300期视频回放
一、内部市场化
前段时间做了两次售前支持。客户明确提出要根据他们的自身情况设计ITIL流程。参加过ITILF的培训回到公司曾实践过的学员就是有想法。疑惑过、失败过之后他们更深一步体会到ITIL的学习和实践存在一个较大的落差。
ITIL无疑是规范的、周全的。IT运维管理中的方方面面虽然没有一无巨细地谈到，但也给了我们比较明确的思路指导。
初学者用ITIL来指导自身的IT运维管理可能会遇到很多的不适。如果是IT部门自己在张罗着ITIL，那么ITIL实践不是落不落地的问题而是根本不可能落地。ITIL落地不是一个部门的事情。
由IT部门先做一个试点，小范围实施ITIL看看效果可能是很多人的想法。但正是这种带有试试看的想法容易让ITIL的落地在小范围试点中夭折。服务台、事件管理没有相关部门的配合，如何做好事件的规范受理？如何解释明白实施ITIL之后出现的不如原来工作方式便利等问题？没有前道工序的规范，哪有后续工序的规范？
试点之前不妨先找个时间和业务相关部门坐下来聊聊IT服务的事情，形式不限。我们准备规范IT运维，你们有什么想法？可能在试点过程中会遇到些问题，希望你们能多多配合······虽然这些谈心不一定能带来ITIL实施的畅行无阻，但从灌输ITIL上来讲，我个人觉得也是必须的。推行ITIL，不先灌输ITIL怎么行呢？即使小范围试点也要拉上相关业务部门一起加入。不仅是为灌输ITIL思想，也是为了让业务部门体验一把ITIL。
当然这么做也是有背景考虑，如果企业本身的管理水平较高，IT部门的地位较高，那么推行试点还是容易些。反之，管理水平的制约则会大大影响ITIL推行的实效。
“顾客是上帝”这句话的背后有一个潜台词：上帝是要付费的。我服务了你如果没有一个考量，那么服务的积极性就会受挫。要么给绩效、要么给表扬。不能服务了之后什么都没得到，时间久了服务就会打折，再之后就是劣质服务。企业内部能够树立起内部市场化的思路。那么我分门别类提供IT服务，你选择需要的服务并付费对实施ITIL将大有裨益。
IT提供免费服务的传统思想本身并没有多大的错误。但问题是，往往免费的不一定得到用户的珍惜会导致IT部门原本就不足的人力资源更加紧张。因此，在平衡服务水平和服务成本的时候，我觉得客户内部领导层提出的“内部市场化”倒是一条不错的管理建议。
二、ITIL勿用流程之名行职能之实
从ITSM咨询的角度看ITIL比以往我在IT运维内部更能看出整体的问题。做IT运维管理，特别是主管级别，往往为工作视野所累考虑问题时多有局限。比如：做事件管理时，我考虑的更多是如何做好事件的识别、记录、简单分析、升级、报告以及问题的反馈等等。这么做下来，实际上还是没有脱离职能型组织的框框。无非是用流程之名行职能之实。
学习ITILF的时候，我们都会分流程讲谁来做服务台经理、谁来做事件经理。但是，究竟谁来做ITIL流程的“总”经理呢？说白了，这就是流程的协调问题。从个人的经验看，没有这个“总”经理那么ITIL流程往往会显出“人人在流，但流程不流”的问题。公司小可能没这个烦恼，IT主管一个人就能控制整个流程的运作，省却了协调的问题。但IT部门规模比较大的时候流程的协调问题必然会凸显出来。
身处具体部门，操心于细微末节。不是不知道流程的协调重要，而是无权无力去协调。除非我的职责就是“专职流程协调员”。之前我写过一篇服务报告的总结，其中总结问题有一条就是设计了应急流程但无人协调，导致流程不流，应急不急。制定应急方案的人有考虑不周、敷衍了事的问题，但审核这份报告的经理也有问题。问题在哪里？很简单，流程的制定只是为了“好玩”。也就是说只是为了给别人看我有了应急流程，但并不关心流程是否真的能用，是否真的能流转。
所以说：流程的协调关键在于上司是否真正关注流程，下属是否真正理解流程并执行流程。关注才能重视，重视才能真正设计好流程、执行好流程、协调好流程。否则，流程就是一张废纸！
三、混沌的平衡
忙碌了一周，终于有时间静下来想些问题。这两天一直在访谈客户。今天在和服务台主管访谈时，我发现客户与我之前服务的公司实在有着太多的相似。用一句话可以来总结他们的相似点，那就是：他们都垄断了垄断行业的IT服务。单调的客户、没有竞争的服务。这样的环境本来不适合不断提升IT服务水平和能力的。我一直这么认为，只要你服务的不是太差任何事情都比较容易谈。但是，来了这家客户我改变了一个认识。如果你的IT服务影响的是国计民生，那么垄断的IT服务就不容易接手了。
因为涉及国计民生。出现故障有可能带来一定的政治风险，所以他们对IT服务要求相对不涉及国计民生的垄断行业要高很多，所以客户才会在2004年就开始引入ITIL。他们用了3年多的时间来准备、学习、实施ITIL。这期间他们的做法不为人理解，被认为想法太超前。但现在回首望去，没有当年的前瞻，哪有今天的从容。不由得佩服当年决定引入ITIL的人，这些年一直坚持ITIL的人。也许这些人是领导，也许只是普通的职员。他们坚持了自己的选择。从ERP实施到ITIL实施历来都将领导重视和参与放在项目成功因素的第一步。现在我从客户身上深切地体会到什么是领导重视和参与，眼界的开阔是重视的前提条件，信念的坚持是积极参与的动力。没有前瞻的眼界，没有3年的坚持，他们的ITIL早就在众多的质疑声中半途夭折。所以，在此向有远见且坚持的领导致敬！
在看破子的文章，总结了一句话：混沌的平衡。当时没想明白怎么来理解。这两天访谈的过程倒是让我恍然大悟并进一步对此作了一个解释：混沌是从外人角度看表现出的结构不合理、分工不明确、定位不清晰、服务不规范。平衡则是在内人看来，熟悉的组织结构、习惯的分工模式、适应的角色定位、顺手的随意服务让他们做起IT服务来得心应手。
这两天在合肥，去年底在杭州，以前曾呆过温州。这里仅用过马路的红绿灯与上海做一个比较。温州过马路，我至今还记得是人在车之间穿行，车在人群中抢道；杭州因为最近在修路，交通不是很规范，但红绿灯的作用还是起到了交通管理的职能；合肥的斑马线不少，但红绿灯偏少，有时候过斑马线还是要和汽车抢道。上海呆久了已习惯红绿灯的约束，没有感觉这种约束有何不妥，反而觉得这是安全的保障。转了几个城市之后发现没有约束反而变得不适应，过马路的时候提心吊胆。看着身边潇洒的行人，我觉得自己小心翼翼地象个异类。他们已习惯没有约束的随意，而我总希望能看着路对面放行的绿灯通过。习惯，我们的习惯区别在于：他们习惯混沌，我习惯有序。我是小城镇出生、长大。经历过没有红绿灯、有红绿灯但无人遵守、有红绿灯有人遵守、有红绿灯习惯遵守最后再到没有红绿灯也想着红绿灯。
所以有人曾说：没有ITIL也能做服务。是的，没有ITIL并不意味这IT服务暗无天日。说不定也活得很滋润。因为混沌也能平衡，也能收到服务费。但从服务角度说，改进才能提升服务，不断提升的服务客户才能不断的满意。客户不断的满意才能更加满意，更加忠诚。如果仅满足于混沌的IT服务，那么我们也没必要去谈什么ITIL。混沌状态有其存在的理由和环境，但任何一个不满足于现状的IT服务提供商都不愿意停留在混沌的状态，有序平衡才是追求的目的。合理的组织架构、明确的职能分工、清晰的角色定位、规范的服务提供才是有他们需要的。
也许ITIL的引入也要经历类似红绿灯认知这样的过程吧。
四、IT组织框架对ITIL的影响
在做运维的时候，始终将注意力放在了流程上。设计完流程就开始执行。这也是中层管理人员需要考虑的事情。从来没有考虑过我设计的流程是否在现有的组织框架下能够体现最大价值。也可能是现行的IT组织框架比较合理，所以没有对流程的设计产生什么不利影响。当跳出自己工作的环境时，突然发现IT组织框架对流程的设计还是有很大影响。
讲ITIL，我们喜欢拿职能型和流程型两种组织做比较。得出的结论就是流程型组织更适合实施ITIL。回头看看，如果当年我们没有对运维体系做了事先的变动，采用运维和管理分开。依然沿用按技术分运维小组的结构，每个小组有一个主管，分管各自一摊事情。那么设计流程时可能就会遇到一些障碍。比如：流程之间的协调涉及两个不同的运维组就会出现扯皮的现象。分开之后，运维流程基本上在运维小组中运行，好坏都是自己的事情没那么多借口推脱。运维和管理分开不仅可以减少“小国林立”带来的割据弊端，而且能够整合服务资源，统一对服务资源进行管理、监督和控制。
也许实施ITIL的IT部门或多或少都会调整原有组织框架以适应新的IT管理需要，对于ITSM咨询而言，“望、闻、问、切”中的“望”首先是要来看看他们的IT部门组织框架。看看这种框架是否清晰明了，看看这种框架是否适合ITIL的推行。一般而言，IT组织框架都是IT部门多年运行形成的稳定结构。不管是否清晰，能够应付客户的运维需求就有其存在的理由。也正是这个原因，他们在实践ITIL的时候可能会忽略组织架构的影响，进而在设计流程时受到一些不自主的约束。虽然有人能够大刀阔斧进行结构调整，但是更多的人还是默认了这种结构。不管默认与否，建议是在设计ITIL流程时，先考虑一下自己的组织框架。
五、ITIL咨询心得
这两天一直在整理问题。上周一KickOff。第二天的ITIL认知培训由我给客户做了一天的讲解。一天下来不知什么原因，上颚上火有些发炎。也许很久没这么讲课了，想当年做实施，给客户做一天的培训也很正常。看来有些东西不经常练习能力就会下降。因为ITIL认知培训，没赶上第一天对老总的访谈。随后的访谈持续了一个礼拜。
服务总监、部门经理、运行主管、核心人员逐一访谈。经过数日的你问我答，逐步将客户的问题一一列出。乍看上去好像整理出不少问题，心里有些兴奋。原来可以问出这么多的问题来，咨询的价值体现出来了。当完成访谈开始整理问题时，我发现自己高兴的太早。问题问了不少，但不够细致。离开了当时的访谈环境，现在再回顾问题才知道问题没有问细，还存在疑问。所以，访谈的过程不是总结客户的问题，而是应该不断地问客户“为什么要这么做”、“为什么这么设计”、“为什么响应时间慢”······要有打破砂锅问到底的精神。否则，等到整理问题的时候就会发现当初这里没问到，那里不清楚。当然访谈不仅仅是追问为什么，也要掌握总结问题的技巧。客户的思路是散的，说完一段作为咨询顾问也要具备整理其思路的能力。但有时候这样会带来误导访谈对象的问题。所以说，访谈很有技巧。
弄清客户的意图对做咨询来说很重要。不摸清领导的意图，那就是瞎折腾。领导对咨询的方向起着旗帜的作用。当然领导不支持的除外。更多的时间还是放在访谈上，在开始写报告之前这是最主要的工作了。
这次项目我们对客户做了一个IT服务成熟度调查。这是项目经理设计的一个有关IT服务成熟度问卷。他曾在别的客户那里使用过。我看了看觉得挺有意思，所以就先自己做了一个测试。将我之前服务的公司做了问卷，完成之后评分，感觉还是能够说明问题，定位基本准确。随后我们将问卷发放至客户，对老总、服务总监、部门经理和核心工程师等进行调查。但发放问卷之前我们就预估这份问卷适合中层以上的人员，对核心工程师作用不大。最后结果也证明了我们的预见正确。最有效的还是管理层回答的问卷。而且他们的选择更接近实际情况。
问题整理阶段是紧张的，能否拿出客户满意的答卷，这一阶段很重要。此次咨询的价值也就体现在这里了。（EwaySun原创）
|
转播
分享
淘帖
()
