张主任有些无奈：一头是上级的要求、一头是员工的抵制。要想在“行驶中换轮子”，还真有些力不从心。他怎样解决运行管理的问题呢？

张主任是某省电信公司计费业务中心主任。五、六十人的计费业务中心负责全省计费、经营分析等重要业务系统的建设和运行工作。

计费业务中心虽说人不少，但具体到每个系统，也就一、两个人负责。由于业务变化快、系统升级改造频繁，这些人的主要精力放在了项目建设和工程施工上，运行保障工作基本处在比较初级的自发状态：工作以“救火队”方式的被动响应为主，故障处理和系统维护过程基本没有记录和总结。

过去几年，计费业务中心投入了大量资金建设了多期ITSM（IT服务管理）咨询、系统监控和流程电子化项目，但一直存在着员工使用不积极、系统功能不完善、建设成效不显著的问题，更谈不上投资回报。

张主任理解，ITIL（信息技术基础架构库）建设是管理项目，ITIL标准的确先进，咨询专家说得也绝对正确，大厂商昂贵的软件功能确实很多，但落实到本部门实际工作中，总感到很隔膜。听专家和厂家介绍起来头头是道，只要买了他们的产品和服务就能包治百病，但真花了很多钱之后似乎什么病也没治好，还说不清人家的东西哪里不好。是ITIL到了国内水土不服，还是国际大厂商开出的药方不对症？总不能说自己生的病不对吧？

张主任也参加过多次ITIL培训，算得上半个ITIL专家了。作为多年的国内大企业的中层经理，对大型国企文化很清楚。张主任总结了本单位运行工作的特点：

◆ 都说强调“服务”是ITIL的精髓，但计费业务中心主要还是为几个业务系统“服务”的，部门不直接面向客户，只面向内部员工。与保障系统比起来，对人的服务压力并不是很大；

◆ 部门基本是智能型组织架构，下属经理各管一摊，每个员工各管一块。管UNIX服务器运行的小张负责多个厂家100多台服务器，算得上是专家了，处理系统故障是个行家。但要让他填什么事件、问题、变更、配置、发布工单，说他既是事件的一线支持，又是什么配置管理员、问题专家、变更执行者，就把他的脑袋都搞大了；

◆ 系统建设任务重。每个系统只有一、两个人负责，每个系统的建设或升级从可行性研究到上线怎么着也得一年半载的，试运行结束没多久就要进行下一版本升级建设。项目管理和施工任务占用了大部分精力，运行工作往往要托付给开发商，但质量很难控制；

◆ 张主任非常希望通过ITIL建设使管理上台阶，使本部门在集团公司中拔尖，但这与员工的诉求并不一致。没有很好的利益机制，要做到令行禁止不是那么容易。

让张主任困惑的是，在这样的环境下，ITIL究竟怎么建设，按什么步骤建设才能逐步取得成效呢？是改造ITIL适应他们，还是他们适应ITIL呢？ITIL建设中流程梳理和流程电子化工具到底是什么关系？工具不完善能否做好ITIL？

几年来，集团公司作为上级单位，对运行维护工作的规范性和主动性要求越来越高。计费业务中心在前几天上级统一组织的评比中成绩不理想，部门绩效和员工奖金恐怕会受影响；业务部门对计费系统近期的几次系统停机也颇有微词，上次总经理办公会上几乎成了各部门的围攻对象，这些自上而下的压力使张主任寝食难安。

张主任也知道，目前这种“扬汤止沸”式运行维护模式确实有些被动和无序，应该加强主动管理，形成良性循环，这需要计费业务中心全体员工多做很多工作。

想到前一段时间的流程电子化项目，张主任还有些心有余悸。考虑到一些老员工及按政策安排的专业人员技术能力差，工作不饱满，想把电话支持、故障记录跟踪、例行检查等事务性工作安排给他们。结果有消极怠工的，有到公司领导面前告状的，还有在部门会议上直接顶撞的。他一向依赖的技术骨干也说“工作量太重，再加码就受不了了”，最后任务落实不了了之。

想到这些，张主任有些无奈：一头是上级的要求、一头是员工的抵制。要想在“行驶中换轮子”，还真有些力不从心。张主任苦恼的是：他们有钱，愿意花钱，但怎样才能找到一付“对症良药”，真正解决运行管理的问题呢？（华锋）

勿让ITIL成“北枳”

企业在IT运营过程中遇到的80%的问题是由管理原因导致，而管理问题需要采用管理的手段加以解决，这也是身为IT管理最佳实践的ITIL如此受到推崇的原因之一。

然而，尽管ITIL拥有国外各大企业成功实践的“纯正血统”，但正如“南桔北枳”的道理一样，对他人成功的简单移植却并不一定能够确保自己的成功。根据我们对国内各大企业的调查表明，国内企业上马ITIL的不少，但真正能够有效利用并体现其价值的却寥寥无己。大家讨论的话题也逐渐地由What转移到了How。如何在组织内部正确地实施ITIL，使其最佳实践的理念和方法在国内IT的土壤中生根发芽、茁壮成长，最终收获期望的果实，如何让“北枳”与“南桔”一样甜美，甚至超过“南桔”变成世人称道的“北桔”，成为一个严峻而富有挑战的现实问题。

“南桔”成“北枳”

虽然ITIL在开篇就明确表明了自己的“实践”身份，但国内企业对其的认识还是一个逐渐深入和理解的过程。ITIL在企业的应用大多经历了两个阶段：一是ITIL项目实施阶段，二是ITIL体系运营阶段。ITIL项目实施阶段有点像当年大张旗鼓的网络和ERP建设，企业大多是被动接受理念的宣导和灌输，然后带有一定盲目性地匆匆上马。而当企业投入血本引入流程和平台进入运营阶段后，才发现收获的并非设想中的甜蜜的“南桔”，而是味道苦涩难当的“北枳”，张主任的无奈已经很好地诠释了这一点。在对这个案例分析后，可以发现，ITIL在该企业中的应用归结下来主要有以下几方面问题：

◆ 系统建设耗费大量部门资源，无力进行运行保障工作；

◆ 部分员工不愿接受ITIL带来的变化；

◆ 流程“一人多角”现象严重，执行层面阻力较大；

◆ 流程工具使用情况不理想，系统建设成效不够显著。

ITIL强调系统的运营过程，而如果系统建设耗费大量资源，自然就很难保证足够的资源来进行系统运行保障工作，这属于组织层面的缺陷。部分员工不愿接受ITIL带来的变化，这属于人员层面的缺陷。流程中“一人多角”现象严重，执行层面阻力较大，这属于流程层面的缺陷。

流程工具功能不够完善，使用情况不理想，这属于工具层面的缺陷。暂且不管这些缺陷的如何修复，为什么在ITIL项目实施完毕后，这些问题才被发现，哪些问题是可以预防和避免的，这其中值得我们深思。

北方如何收“南桔”

对近年来国内多个企业ITIL实施案例进行分析后，我们发现，如果只是单单设计流程或是实施工具，结果往往是失败的。但当我们将企业的ITIL项目当作一项组织层面的系统工程来建设时，很多问题其实是可以避免的。如下图所示，如果我们在流程设计和工具实施之前，首先对组织进行必要的调整，使其成为ITIL运行的一个良好容器；然后对人员进行ITIL意识和技能的培养，保证组织内部每个人统一语言、目标一致，并建立与角色职责相符的技能水平；在组织和人员这两个先决条件都已经准备好的前提下，再上流程和工具平台，这样的效果会得到很大的改善。下面我们将针对案例，就此作进一步阐述。

在此案例中，如果企业认识到应首先对部门的组织结构进行改造，以适应ITIL流程的需要，则可以避免后面出现类似“系统建设耗费大量部门资源，无力进行运行保障工作”的问题。张主任可以考虑将一部分系统建设的常用人员从组织中剥离出来，成为一个系统建设小组。这个小组内主要包含两类人员：一类是开发建设人员，我们可以通过对历史数据的分析，选择那些超过80%的时间都在进行系统建设的人员，他们往往在系统建设方面的技能和经验强于系统运营方面。彻底将其划归在系统建设小组，不仅明确职责，方便考核，而且有助于使其将有限精力集中在系统建设的专业层面。另一类人是项目管理人员，这些人负责对新项目的计划和控制，并在需要时对部门内部或第三方资源进行协调和管理。

在对组织进行必要改造后，接下来应对组织成员进行必要的培养。ITIL本身是对IT管理思想和方式的一次变革，这种变革将不可避免地要求组织里的每一个成员发生变化。对于案例中的部分员工来说，这种变化难以接受。因此，对每个员工的再培养就显得尤为重要。这种培养分为两方面：一方面是意识层面的培养，一方面是技能层面的培养。

当然，除了组织改造和人员培养以外，保证ITIL成功实施也离不开流程的合理设计。对于案例中一人多角色的问题，是ITIL在国内企业推广时最为常见的问题之一。

建议张主任可以考虑在资源允许的条件下为这些重要人员设置A/B岗，这样在其因特殊原因不可获得时，有一个备份人员可以临时顶替，保证流程的运转效率不受影响。同时应考虑采用一些激励或者考核机制。

解决“不好用”和“用不好”

在流程设计完毕之后，如果没有工具的辅助，流程永远无法真正落地。但落地言易行难，正像案例中描述的那样，国内太多客户都面临流程工具利用率不高的窘境。这其中主要可以概括为“不好用”和“用不好”两方面。“不好用”主要是指工具本身功能或者性能方面无法达到期望，建议对反映最强烈的或对流程效率影响最大的点进行分析和改进。比如事件表单的设计，本来事件流程就强调解决时间，但很多工具往往在事件记录时耗费了大量时间。面对这种情况，应考虑如下原则：

◆ 减少一些不必要的字段，只保留核心的信息字段

◆ 多做“选择题”，少做“填空题”，尽量不做“问答题”

◆ 建立信息之间的关联，以便填写某字段后，大量相关信息自动带出

◆ 多使用模版进行记录

至于“用不好”，就得从工具的价值层面来考虑了。如果使用工具无法为员工带来益处，推动使用工具自然是阻力重重。因此，我们不能简单地将工具强制“推”给员工，而是应当对工具价值充分挖掘，以“吸引”员工使用。

相关链接：1980年以来，英国政府商务办公室（GOC,原称政府计算机与通信中心）为解决“IT服务质量不佳”的问题，逐步提出和完善了一整套对IT服务的质量进行评估的方法体系，称为ITIL（信息技术基础架构库）。

2001年，英国标准协会在国际IT服务管理论坛（itSMF)上正式发布了以ITIL为核心的英国国家标准BS15000。

通过ITIL了解业务请求，了解IT的能力。目前，ITIL已经在全球IT服务管理领域得到了广泛的认同和支持。在2000年至2003年期间推出了ITIL V2.0版本。今年7月份ITSMF推出ITIL V3.0版本（《中国计算机用户》26期有详细报道）引发ITIL应用新的关注。

ITIL的“三要”、“三不要”

从案例描述的张主任及其单位的情况可以看出，张主任所处的是非常典型的“复杂IT运维环境”。该环境下IT运维体系的建设在我国现阶段具有自己的特点和要求，也就是说具有中国特色和时代特点。这种环境下，要借鉴ITIL理念，更要汲取本土运维体系建设的经验和教训。笔者从2000年开始专注于运维管理领域，亲历或目睹了多个客户建设IT运维体系的悲欢离合。希望这里总结的“三要三不要”对复杂IT运行环境下运行部门经理的工作有实际的参考意义。

那么，什么是“复杂IT运维环境”呢？这种环境下IT的运行维护管理工作有什么不同之处吗？所谓“复杂IT运维环境”，是与中小型IT环境相对而言的。一般说来，复杂IT运维环境中IT系统所承载的均为关键业务系统：一旦出现问题，会给单位带来较大的经济损失和不良的社会影响；系统规模往往较大：一般是分布式网络环境、少则数十台高端生产服务器、成百数千台业务终端、多套大型数据库系统和业务系统、海量业务数据；该环境的运行维护部门往往是专门的信息中心、电脑部等，拥有数十上百专业的运行维护人员和较为完善的运行管理制度。

正如案例所说的，这样的客户很多都曾做过ITSM咨询、系统监控和流程电子化项目。您在Google上搜索“ITSM案例”，可以看多许多成功经验的介绍。笔者在较大范围内走访过一些比较“成功”的用户，做过一些较为深入细致的研究和分析，发现能够在某些方面取得一定成效已经算是非常成功了，能够全面落实的更为凤毛麟角，很难见到。其中的经验和教训非常多，甚至多到了使人无所适从的地步。但我想告诫那些准备进行或正在进行运维体系建设的IT部门经理们，只要能够做到下面所说的“三要三不要”，就基本能够实现“行驶中换轮子”的目标。

找准靶子

明确目标和范围，你先得知道ITIL里说的几大流程对本部门到底是什么意思。例如粗略地说，ITIL事件、问题管理说的是用户电话申诉和系统故障的处理过程的规范化管理，它不能代替专家解决技术难题；变更、发布管理说的是工程和系统割接申请和上线过程的规范化管理；服务持续性管理主要强调容灾的常规演练过程管理等等。这样你就会知道实施ITIL能做什么，不能做什么，你就能够判断先上什么，后上什么，你就能大体判断有多大变化，有多大阻力。

把ITIL作为灵丹妙药、指望其解决很多问题是不现实的，一次解决一、两个管理问题就很不容易了。是想强调规范性还是灵活性？是想部门内员工受益还是系统的用户受益？不同目标虽不完全冲突，但要想同时达到就有点不切实际了，而且会使执行人员无所适从。所以找准一个核心目标对IT部门经理来说是最为关键的。

“用对干部”

确立了具体明确目标，然后就要“用对干部”了。一般来说，IT部门经理不大可能亲自主刀进行具体操作，往往要指定一个项目负责人协调和负责具体工作。负责人员必须既有动力又有能力，才能够协调和推动各项任务，达到预定的目标。因此，能够代表部门经理的资深骨干具体负责往往是建设成功的前提保障。

用对人的另一个方面就是选择好建设的乙方单位了。选到既上得厅堂、又下得厨房，既有高度又有深度，既能干又肯干的乙方单位也不是很容易的事。但没有好的搭档，指定的负责人就会孤掌难鸣，难收全功。

“买卖力道”

最后，在体系建设过程中，部门经理还必须帮助负责人理顺部门内部的利益关系。大家都知道，ITIL体系建设对不同人员利益的影响是不同的，这种影响会使有些人起赞成和推动作用，有些人起牵制和阻碍作用。当然，这种牵制和阻碍会通过间接方式，从不同的渠道体现出来。

股票分析中有一个“买卖力道”的概念，用来衡量买卖双方力量的大小。同样，ITIL体系建设也必须进行“驱动力分析”，并调整和推行必要的利益格局，鼓励正面推动因素，遏制负面制约因素。该项工作必须由作为一把手的部门经理亲自落实。

与介绍ITIL经验的各种文章相比，这里介绍的“三要”的特点是现实可行。它不要求IT部门经理学习高深的概念，工作内容是在IT部门经理的时间、精力和职权范围内可以实现的，也是笔者与多位IT部门经理沟通交流的心得。下面所说的“三不要”是以前ITIL体系建设中常见的问题，希望IT部门经理能够注意。

不要求大求全

如果您按照“要找准靶子”的建议花一两天时间进行了思考，就会明白ITIL体系建设的艰巨性。求大求全往往是没有经过仔细思考、不够成熟的表现。

一般经验是，一次能够进行一到两个流程建设是能够落到实处的，同时进行四个、六个甚至十个流程的建设，其后果往往花了十倍的钱，落实的仍然是那一两个，甚至一个都落实不了。结果骑虎难下，甚至众叛亲离。

不要迷信“咨询专家”

这里说的权威首先就是ITIL本身。我们知道，ITIL只不过是欧洲IT运维管理经验的总结，我们是拿来借鉴的，不是拿来崇拜的。结合本土文化“取其精华，去其糟粕”才是明智的做法。还有就是不能迷信“咨询专家”，对待咨询专家的正确态度应该是听其言，观其行，自己进行判断和决策。

从抵制到离不开

凡事贵在坚持，ITIL体系改变的是员工的工作习惯和做事方式，推广落实是受到各种责难和抵制是正常的。从抵制到习惯，从习惯到离不开往往是需要一段较长的时间的。

负责人长期投入精力跟进和督促体系的落实并进行持续改进是保证落实的关键，请乙方派出流程经理，协助进行长期的推广落实和持续改进工作是弥补负责人时间精力和经验不足的有效方法。

ITIL不是“灭火器”

又一个反映对ITIL理解不够透彻的案例。这种对从国外“进口”的各种管理理念、方法、技术等理解不透不深，便应用到组织的情况，在国内非常普遍，它不只是发生在信息化领域、IT管理等方面，而且存在于国内经济、教育、医疗等各个行业的管理。

对于该案例张主任应用ITIL过程中遇到的困惑，ITIL到了国内水土不服？还是国际大厂商开出的药方不对症？ITIL究竟怎么建设、按什么步骤建设才能逐步取得成效呢？是应该改造ITIL适应组织，还是改造组织适应ITIL呢？这都反映出对ITIL的理解和认识片面。因此，作为被使用的ITIL要说话：“其实你不懂我的心”。

考虑“着火”的类型和原因

ITIL不可能面面俱到。首先，它只提供了一个指导性公共框架，这个框架可以保留组织现有的IT管理方法和技术中的合理部分，同时增加必要的方法和技术。其次，ITIL是根据实践而不是理论开发的，它只列出了各个服务管理流程的“最佳”目标、活动、输入和输出以及各个流程之间的关系，但并没有说明具体的日常运营活动。其重点是保证流程实现其应有的功能并与其他流程相协调。至于具体怎样实现这些功能，组织可根据实际需要采取不同的方式。此外，ITIL也一直在不断修改完善，由原先的1.0版到3.0版，这说明了现有ITIL存在一定局限性。因此，明确企业自身需求，有选择应用ITIL方法和流程是关键。

就本案例来说，工作以“救火队”方式的被动响应为主，那么企业在建设ITIL时，是否分析考虑“着火”的类型和原因，这些原因能够通过ITIL哪个流程来解决？故障处理和系统维护过程基本没有记录和总结，企业是否清楚为什么需要记录和总结，哪些应该记录，哪些不应该记录，现有的记录都是必需的吗？有了记录之后，如何处理这些记录？只有把握清楚企业自身存在的主要问题，运用ITIL的相应流程，制定适应自己资源、组织结构、人员能力等要求的详细流程。

另外，在变更管理流程中，通常可以将变更请求分为常规变更、标准变更、紧急变更和项目变更等类型，不同的变更类型应该制定不同的变更管理程序和相应的授权审批规定，这是一条通用模式。不同企业在设计变更管理流程时，需要结合企业实际，确定哪些为常规变更、哪些为标准变更，这些规定应是有别于其他企业，也正是这些特殊之处，才体现了ITIL的方法。

遵守ITIL生存铁律

任何理论、方法和技术都有其产生的特殊背景、应用环境和条件，离开所需环境和条件，理论、方法和技术便会失去应有的作用，无视这条铁律，事情只会是要么认为理论、方法和技术不好，统统不用，要么将这些理论、方法和技术当作无所不治的“灵丹妙药”，不加改进的应用。

ITIL建设，同样需要满足一定的条件，更多的是要充分理解ITIL的思想，关注自身的能力，科学评估自己的资源和条件，企业运用先进管理理念的标尺，目前的治理结构、管理体制和人员素质能够支持ITIL的建设，有足够的能力、资源和领导的决策支持具体实施。

如案例中张主任遇到的困惑，我认为很大程度是在上ITIL建设项目时，未能仔细、科学和严格地评估ITIL建设所需的各种资源和条件、所遇到的风险，而随意上马造成的。因此，了解ITIL成功实施所具备的条件，改进自身的条件去适应，才能很好地建设和实施ITIL。

变革中的愤怒情绪

实施ITIL，不是简单地制定流程和制度，不是简单的流程电子化就能够做好的，而是涉及到原有企业组织人员的职责调整、工作重新安排、既得利益影响以及原有工作习惯的改变。能否成功实施ITIL，基本上受到员工积极参与程度的高低决定，而人员的积极性非单纯的说教能够发挥作用的，需要企业运用多种管理手段，才能有效实施ITIL。

许多企业实施ITIL失败，与未能正确认识到变革存在的风险有关，变革失败的原因之一是低估了所需的工作规模。员工、用户和客户必须适应新的工作方法和规则。在引入新工具或流程的初期，他们可能很有热情。

但随着事件的发展，不熟悉的工作习惯、细小的麻烦和“速战速决”行动效果的迟迟未出现就可能降低他们的参与热情。他们对变革的态度也发生改变，有时甚至会出现愤怒情绪。就如案例中的员工使用不积极，ITIL建设与员工诉求不完全一致，缺少很好的利益机制，难以做到令行禁止。因此，对于ITIL实施变革中的阻力，可以采取以下一些方法：

向员工个人、小组甚至整个企业说明实施ITIL的必要性和合理性。有效组织员工完成日常工作，形成严谨的操作规范和工作习惯；引进专业技术管理团队进行顾问服务；对管理和技术骨干进行实习培训等建议。

应建立一系列的管理制度和标准；建立强有力的管理支撑的平台，比如，集中硬件监控、集中平台监控、集中应用监控，通过事件管理产生事件，通过事件产生问题，通过帮助系统进行管理等。针对案例中的公司在实施ITIL之后，仍然有员工绕过帮助台与熟识的相关技术人员直接对话的情况，就需要通过严格的考核管理制度，加强执行力度，将原先不适应的习惯彻底纠正过来。

CCU读者俱乐部 会员评论

“能借力”与“会使力”

ITIL首先不是一种技术，而是一种管理理念；或者说ITIL的技术方面是依附于其理念方面的，所以推行ITIL显然要先从理念的更新入手。

然而理念的更新只是前提，ITIL顺利实施需要的工作习惯的改变是需要“力”的。这种“力”一方面用于抵消原来工作模式的惯性，一方面用于推动新的工作模式的运行。

这就要求张主任要有力，能借力，会使力。“有力”就是要能调动部下按照新的工作要求开展工作而不是因循原来，不思改变甚至抵触；“能借力”就是要搞好上下级的关系，使来自上级的压力能转化成下级人员工作的动力；“会使力”就是建立机制使新的工作模式能够不被老的工作模式“复辟”。

“救火式”工作方式是效率最低的工作方式，但是由于其“成效”直接而最常被人们采用，ITIL的思想就是为了解决这种低效，然而若从“救一场火”的一时来看，效率未必会提高甚至更低，所以张主任首先应该从将下属从短视中解脱出来，取得下属们的配合，然后再利用各种控制力。(安宇)

不被理解的投资

本案例中，我觉得主要问题还是出在张主任身上，他虽然非常希望通过ITIL建设使管理上台阶，可实际效果如何呢？让我们看他是怎么做的吧。

系统升级改造频繁，影响关键业务系统，必然会导致大家的服务意识降低；人员过于分散，每个系统只有一、两个人负责，项目管理又占了他们大部分精力，缺乏竞争和奖励机制，不能调动员工积极性。

投入了大量资金建设了多期ITSM咨询、系统监控和流程电子化项目，却出现了员工使用不积极，系统功能不完善，建设成效不显著的问题，这说明了投资的随意性，缺少大家的理解和支持。

显然主要问题不是出在使用什么系统，而是管理上，成绩不理想也是必然的。改进工作，提高管理水平是张主任首要解决的问题，还可以借鉴其他单位好的经验，并让大家能真正理解和认识ITIL。