1、谁动了网管的红包 IT 服务管理五个心得 IT 部门当然是业务辅助部门，但这并不意味着 IT 部门只能充当被动救火员的身份。规范好，管理好 IT 业务，让 IT 管理员从简单的修机器、收邮件等低级劳动中摆脱出来，真正成为为 IT 管理服务的典范。这就是 IT 服务管理的理念。其实，实现 IT 服务管理，并不难。夏忙，28 岁，2004 年 4 月进入滚滚来贸易公司，负责 IT 工作。滚滚来贸易公司以做进出口为主，这几年发展尤其快，从最初的几十人到了现在的 200 多人，而且基本上是人手一台 PC。网络、邮件已经逐步替代了以前的电话、传真，成为最新的办公手段。IT 部门有三个人，夏忙一来就发现这
2、三个人基本都不在自己的座位上，因为公司的200 多台机器，总有这样、那样的问题报过来。于是，夏忙也就很快投入了战斗一线，修机器、调邮件、杀病毒，成了被拎来拎去的“八抓鱼” 。忙归忙，可是每到月底填写考核表的时候，夏忙就一点都想不起来这个月干了什么。好像每天都没闲着，也好像每天都当救火队员，但是看看这个月有什么进步？除了扑了几次一样的火，修了几次机器以后，再也没有什么可以书写的记录了。最让他郁闷和委屈的是，累死累活一个月下来，虽然忙得手脚不着地，可挨领导的批评也更多了，因为虽然问题是解决了，却收到了更多的投诉：找不到人、反应速度太慢、相似的问题总出现、没有预防措施总之，每天早晨，夏忙最担心一件事
3、，今天会不会发生灾难性事件；每个月底，夏忙担心另外一件事，这个月因为遭遇投诉工资被扣了多少钱。1 一站式服务 少干活多挣钱2004 年 8 月 31 号，工资发下来之后，夏忙发现被扣了很多钱，IT 部门的其他同事也是一样。后来才知道，主要原因是他帮大家修机器时不在座位，别人有事打电话总找不到人，自然提意见。从加盟滚滚来公司到现在已有半年时间，夏忙越来越忙，因为单位人员在不断增加，系统越上越多，加上最近病毒等“天灾” 频频光临公司，事情也越来越多。时下 IT 部门只有3 个人，人手实在是太少了，有时候大家一起打电话求助，夏忙苦于应付，遇到不该自己管的事情，夏忙就总是告诉打电话者该找小欧，放不下手
4、里活的小欧只好说，你找小王，结果是被集体投诉推托责任。夏忙也有委屈，一个人分身乏术，人家业务部门的人一打电话来肯定得冲到一线，三个人都放出去，一旦活够复杂，电话没人接也就成了常有的事。从 8 月中旬开始，夏忙陆续接触了 IT 服务管理的“一站式”服务概念。所谓“ 一站式”服务，就是业务部门可以一次性获取 IT 热线、IT 现场等各种形式的 IT 服务，解决所有日常办公 IT 问题。“一站式” 服务的精髓是 IT 服务台。IT 服务台是用户与 IT 服务部门的中心联络点，客户的 IT 问题通过 IT 服务台获取答案和帮助。对于夏忙，通常来说，IT 服务台可以有两种表现形式，一是电话申请服务，当用
5、户的系统出现问题时，可以拨打服务台电话，根据语音提示选择不同的问题类别；二是网络申请服务。在 IT 网络服务中，夏忙建立了一个简单的基于 Web 形式统一入口，业务部门可通过 Web 的形式提出问题，问题自动提交到相应的 IT 工程师并进行解答,工程师之间也可以互相转移。作为一种很好的互动式服务渠道，是电话服务的补充。建立 IT 服务台之后，夏忙他们三个人针对分工不同，排除了接了电话乱找人的情况，并定义了首问负责制：哪位工程师最先接到业务部门的电话，就成为该 CASE 的责任人，他需要自己或者协调相关人员解决并关闭这个“CASE”。这也解决了工程师间互相推委的现象。服务台建立起来后，并非万事大
6、吉。大家还是觉得电话方便，随叫随到。夏忙只好向老板申请，把 IT 部门新的服务方式形成制度，大家来学习和维护。机器加人工，基本上满足了同事们的救援需求。小贴士：问题响应方式固然重要，但让大家知道并且习惯也是一个过程。对于 IT 人员来说，要公示响应方式，让业务部门能够主动使用、愿意使用并满意使用。2 突发事件管理 摆平漏子不罚款建立了服务台管理之后，夏忙从八爪鱼变成了随需应变的百变神形。因为响应及时，夏忙最近没听见什么抱怨。一天，电脑提示收到一封事件警报邮件，同时，另外三封事件报警邮件也发到了夏忙的信箱。桌上的电话刺耳地响起，另外两位同事的电话声此起彼伏。销售部的同事反映无法接收邮件。夏忙刚刚
7、扑到销售部查问题，不多久，人事那边也找夏忙，人事部的 PC 系统崩溃了，夏忙指挥同事去人事部处理这一问题。事情还在处理中，忽然又接到一个报警，说财务的机器上不了网，现在是月底要报税，事情紧急。于是IT 部门最后一个人去了财务部。夏忙忙乱得一头大汗，他不知道假如再来一桩突发事件，他该怎么办。此时，一直有人在找夏忙，有的机器中毒，有的机器蓝屏了等等。夏忙只好不停地说，“稍等，稍等 ”，一位急脾气的同事不耐烦了， “我急着要一份数据，硬盘却坏了，能不能先给我看看？”“手边有紧急的事没处理完呢。”“那你得分个轻重缓急啊。” 夏忙一听，觉得有理，层出不穷的技术故障让 IT 部门的人疲于奔命，成了“救火队
8、”。可状态不能老这么持续下去，需要有一套流程和方法来有序地处理。他决定把手边的事情忙完之后，好好思考一下。经过紧张的排查，夏忙得出的结论是，网络中心的一台交换机出了故障，夏忙迅速联系网络中心并启用了备用的交换机。20 分钟后，网络恢复正常。趁着尘埃暂定，夏忙赶紧翻资料，能给目前无序的忙乱状态理出一个解决思路。他发现，对于突发事件，最重要的是避免业务中断。对此，首先要确定突发事件管理流程，通过区分突发事件的优先级来确保流程的有效执行。显然，每个人都会认为自己故障是最紧急的，因此必须理清是火烧眉毛还是常规慢性病。夏忙反思，网络中心那台出故障的交换机上连接着公司的销售部邮件服务器、库存数据库服务器、
9、人力资源服务器，这一事故将直接影响到公司内关键部门的正常生产，应该属于紧急一级，如果不尽快处理将发生一级生产事故；而急脾气同事的事件则属于一般级别。因此先处理网络中心交换机问题是对的。 但是自己在紧急事件的处理工时上把握不够，刚才用了大约 3 个工时来处理交换机的问题。那么如果当自己在规定的时间内不能解决或没有解决某个突发事件时，又该怎么办？一般来说，如果不能在规定时间内解决，需将处理任务交给更有经验的支持人员。这叫突发事件升级，通常有两种方式：一、职能升级，安排更多的专家或授予更多的特权以解决事故；二、层次升级，出现在所需的权限和资源不够的时候。突发事件管理可以帮助 IT 部门更加系统、快速
10、地处理突发事件，但是只是规范处理过程，以尽快恢复故障。好比是急诊抢救，治标不治本。要使突发事件管理有质的提高，治标也治本，一种切实有效的方法就是问题管理流程。小贴士：当 IT 服务台必须同时处理数个突发事件时，由于受时间、资源和人力等的限制而无法实现时，首先要排定处理的先后次序，针对不同的优先级处理。确定突发事件处理优先级，需要综合考虑突发事件的影响、紧迫性、大小、范围、复杂程度和当前可供资源。3 问题管理 主动预防没风险解决了突发事件，正赶上十一放长假，夏忙去了趟华山，彻底休息了一下。10 月 8 日一大早，夏忙的电话就响个不停。也难怪，一上班大家就忙着收邮件，积累了几天的邮件把服务器搞得巨
11、慢；许多节前已经预约的客户需要尽快联系，可邮件一遍一遍就是发不出去；网络更是不知犯了什么病，很多机器死活上不去网一整天，夏忙都在忙来跑去解决问题，面对抱怨，连解释的时间都没有。晚上 10 点，总算有点头绪。夏忙坐下来，才想起自己几乎一天没吃饭、没喝水了。其实想象得到，每次长假后的第一天对 IT 人员来说都是黑色的，这和过节一样已经成为惯例。喝了一杯水、吃了点面包、点上一支烟，夏忙回忆起这一天所干的事。长假过后，收邮件高峰会有网络堵塞，南方潮湿闷热的天气也会使得本来条件就差的机房服务器出现接触问题。趁着发牢骚的时间网管们开了个小会，自学了几天 IT 服务管理的夏忙发现，事实上，今天他和其他两位同
12、事的很多工作具有一定的重复性，业务等几个部门出现的 IT 问题几乎都是一样的。既然有规律可以循，是不是有办法加强防范，结局岂不皆大欢喜？夏忙想起几天前做过的 ITSM 的培训，其中有一段说的就是问题管理，说白了就是“归堆儿之后再分类”，要求建立一个知识库，把以前发生的众多问题进行归纳总结，找出规律对号入座，同时总结经验不断丰富。大道理谁也会讲，但夏忙还是不太理解。每天记录发生的问题，隔段时间再进行归纳总结和分类，多麻烦啊！本来工作量就大，哪有时间写日志呢？正因为有这样的想法，夏忙一直没当回事。不过今天看来，如果有这样的一个知识库就不至于这么狼狈。其实无论什么公司，员工对 IT 的需求都有一定的
13、共性。只处理不分析、不总结、不改进的 IT 永远只能是重复劳动。而如果通过引入问题管理，建立一个知识库，将众多问题归纳总结，找出规律加以实践，同时加强防范，不仅提高了效率，活也在一定程度上“少干”了。夏忙越考虑越觉得有意思，于是打电话给上次给他讲课的蒋得明老师。面对渴求上进的夏忙的困惑，老师打了几个比方：事故管理是“救火” ，问题管理是 “消防”；事故管理是有病治病，问题管理是预防和保健。具体来说，滚滚来贸易公司在 IT 管理上，目前仅仅解决了如何规范地消除事故，而没有做到找出导致事故的原因并彻底解决问题。蒋老师还说，在现实中，问题是无法避免的，有技术架构、产品缺陷、操作失误等等很多原因。夏忙
14、又头疼了，这么多的原因怎么分类呢？蒋老师继续说，对问题的归类直接决定着问题管理的效果，问题归类涉及五个方面：确定与问题相关联的领域，比如硬件、软件等；影响度，问题对业务流程的影响程度；问题需要得到解决的紧急程度；优先级，综合考虑影响度、紧迫性、风险和可用资源后得出的解决问题的先后顺序；状态，描述事故目前所处的状况。另外就是找原因，包括现实的原因和潜在的原因，当发现更好的或新的应急措施时，问题管理还要将其在记录中更新以便事故控制使用。从此，滚滚来公司 IT 部门的公共文件夹多了一个文件夹，网管们记录每个问题的现象、原因和解决细节。一个月下来，居然积累了 300 多个问题，共分了 16 大类，70
15、0 多个原因。看着眼前的成就，夏忙有了底。有了这个草创的“知识库 ”，夏忙的工作进入了快车道，进入了 “主动治本”阶段。此后，大家对夏忙所在的 IT 部门有了好评，意见明显少了。小贴士：问题管理乍看起来对于 IT 人员来说是个费时间的活，但磨刀不误砍柴功。有了这些积累，加上分类、分析、预防等工作，效率明显提高了。对于 IT 人员来说，关键是排除抵触和为难情绪。如何提升 IT 服务效率如何提升 IT 服务效率，提高 IT 资源的利用率，发挥 IT 资源的最大效能，降低 IT 服务成本，量化 IT 产出，一直是 IT 管理者面临的难题和挑战。IT 服务管理（ITSM）可以形象地称为 IT 管理的“
16、ERP 解决方案” 。IT 服务管理是用来提升 IT 服务效率，协调 IT 服务部门内部运作，改善 IT 服务部门与业务部门的沟通，帮助企业对信息系统规划、实施和运营进行有效管理的方法。IT 服务管理结合企业的环境、组织结构、IT 资源和管理流程的特点，从流程、人员和技术三个方面来规划企业的 IT 结构。它强调企业的运营目标、企业需求和 IT 服务的交付相协调一致。从组织层面来看，它将企业的 IT 部门从成本中心转化为服务中心或者利润中心；从具体运营来看，它改变传统的以职能、技术为中心的 IT 管理方式，以流程为中心，从复杂的IT 管理活动中梳理出那些核心的流程，将这些流程标准化、规范化，明确
17、定义各个流程的目标和范围、成本和效益、运营步骤、关键成功因素和绩效指标以及各个流程之间的关系，实现从传统的技术管理向流程管理，再向服务管理的转换。4 变更管理 有人“埋坑”不犯难11 月 1 日，总经理召集各业务部门开会，简直就是一个批判会，总经理对 10 月各个部门的表现都不满意，特别是销售部门，惟独对 IT 部门提出了表扬，这让夏忙有一些宽慰. 第二天好不容易轻松一点的夏忙晚到了公司一会，半路接到公司里电话，这个说有一封很紧要的邮件一直没法收；那个说说好要给一个重要客户把报价发过去的，但是现在也不能发原来是公司的邮件服务器出问题。可是昨天下班的时候这邮件服务器还好好的呀，夏忙赶紧给轮值的小
18、欧打了个电话，问他昨天晚上都干什么了。原来在总经理训话结束以后，销售经理就立刻召集了销售部门人员开了个会。为了改变目前的状态，销售部门讨论的结果是改变现有的工作流程。昨天晚上加班开完会确认了新流程后，销售经理把小欧找来要求系统也随着这个新流程做些更改。于是，小欧就根据销售经理的需求更改了几个参数。“改完后我仔细检查了一下，没发现什么问题呢。谁会想到邮件系统会出现问题呢？”小欧也很委屈。夏忙明白了怎么回事以后，赶紧亲自到服务器上去恢复原来参数，让邮件服务器先正常工作。这一天夏忙没干别的，他花了整整一天的时间处理销售经理递交过来的需求。夏忙发现，销售经理拿过来的需求，有一些根本就不合理的。于是，夏
19、忙又去找来销售经理“论理”。两人分析了半天，才讨论出了双方都满意的解决方案。这事就已经够折腾的了。但是，由于 11 月份 IT 部门在忙着一个新系统的安装，所以这事完了以后夏忙一直没来得及跟整个 IT 部门讨论。哪里想到这个月听了总经理一通训话以后，各个部门都比较积极地革新业务流程。采购部、人事部、财务部在那几天纷纷都来找 IT 部门来改流程、改参数。这下惨了，几乎每次更改后都出现了问题。接连几天夏忙更忙了，接连解决更改后出现的问题。累得一塌糊涂的夏忙一闲下来就寻思：这不行呀，总经理训一次话就出现了那么多问题，万一他再训一次话，岂不是又完了；再说了，就算是总经理不训话了，业务部门还是会经常提出
20、要修改系统配置等问题的，毕竟对业务部门来说，“变” 是件好事。如果还是像过去那样随便变更，IT 部门迟早要被这无数的“ 变更”给折腾惨了。夏忙心想，还不如趁这个机会建立一个变更管理的机制。这样，一旦业务部门有了新业务、新变化、新流程，需要 IT 根据这新情况进行变更的时候，IT 部门可以事先知道。紧接着，夏忙就针对变更管理这个问题看了很多专业书籍，同时还虚心向同行请教。忙了半个月后，夏忙终于设计出了自己的变更管理流程。夏忙自己动手给 IT 部门制定出了一个明确的需求变化表。用户有变化需求时必须按照手续提交。拿到需求表以后，IT 人员也不能马上修改程序，而是应该判定此需求是否合理，是否会对以前的
21、系统以及其他系统造成影响，必要的时候要与业务部门召开专题讨论会，讨论具体修改事情。同时，在内部网站中的 IT 服务专栏发布 IT 作业公告。相关部门如果有异议，可以在反馈期之内反馈。如果判断通过，也不随便就做更改，而是提出明确的时间表、修改方法和意见，征求业务部门同意后，按时按量完成。变更实施完毕以后，还要对变更的实施情况进行总结和评价：变更是否成功实施，业务部门是否满意等；变更是否还有遗留问题，是否存在副作用。“虽然总经理的训话害得我那么苦，但是就这个机会完善了变更管理流程以后，就再不怕其他的变更了，也算是没有白忙乎。”对于这个月的工作，夏忙还是很有成就感。小贴士：实施变更管理流程过程中，有
22、两个要素很重要。其一，要转变 IT 工程师的观念和行为。变更管理流程的实行，刚开始的时候，对 IT工程师的行为是一个约束。工程师对系统做任何修改、调整，都需要在变更管理系统申请、备案。因此，需要加强对 IT 工程师的宣传和要求，转变观念，使其能够接受并习惯。其二，要明确职责。变更管理包括诸多流程，也涉及不同部门、不同岗位的人员。因此，需要界定各方人员的职责。如变更管理经理的职责，相关部门人员的职责，等等。只有职责清楚，各项职责执行到位，变更管理流程才能有效落实。5 服务级别管理轻重缓急要掌管前几个月一直表现亮眼的 IT 部门最近成了老板的心头好，员工们的抱怨没了不说，还进行了好几项突破性的改革
23、，一派鸟枪换炮的新貌。年关将近，夏忙他们几乎看到了可观年终红包的招手。这天，本该春风得意的夏忙长叹了口气：“唉！” 其他人忙问： “小夏，你怎么了？连变更管理、突发事件管理这样的头疼事件都能解决，你还会被难倒不成？”夏忙又叹了口气，说：“各位有所不知，万里长征也不过走出了几小步。前几个月的工作尽管卓有成效，但跟接下来这个月要面对的事情一比，简直就是小巫见大巫。一不小心，我们全体同仁煮熟的鸭子红包恐怕就要飞了。”这可不是夏忙小题大做，让他头疼的正是号称 IT 服务管理最大难题的服务级别管理（SLA）。对此，夏忙可有切肤之痛。得到同事们肯定了的 IT 部门是更加勤快了，但有时候却拣了芝麻丢了西瓜一
24、次，在他忙着花半小时修理打印机的时候，服务器由于病毒入侵而瘫痪了整整 20 分钟！公司的网上交易也因此停顿半天，老板的雷霆发了足足有 90 分钟。什么是服务级别管理？简单地说，建立一套规则，当企业中有多个不同需求同时发生时，应该先响应谁的；以及对于不同的需求应该分配多长的时间。“还是服务级别管理没搞好啊！” 夏忙感叹。“我们 IT 部门应该有一个清楚的清单，列举出我们能够提供哪些服务，以及定义好各种业务部门要求提供的服务的级别。哪个级别高，哪个级别低，级别高的优先响应，级别低的等一等；规定问题的响应时间极限，哪个问题可以等上 2 个小时，或者等 4 个小时，哪个一秒钟也不能等”听来很不错，不过
25、要想搞好服务级别管理，可不是 IT 部门自己关上门来定一套规矩就行的，夏忙之所以谈“服务级别管理 ”色变，就是因为知道：服务级别管理的最大难度，在于定义各种服务的级别，而且不同企业也大不相同。因此，IT 服务级别的制定必须是业务部门与 IT 部门共同沟通的结果服务级别协议。IT 服务部门在对 IT 基础架构进行服务级别设计时，就必须充分调查和了解真实的业务需求。夏忙花了大量的时间和业务部门进行全面沟通。 他不仅调查了业务部门对当前服务级别的体验（Perception），还在这个基础上帮助他们分析和梳理那些真实存在却又还未明确的业务需求。为了避免重蹈其他公司推行服务级别管理失败的覆辙，夏忙归纳出
26、了几条“黄金法则” ：1在服务级别协议中业务部门看不懂的日常术语需要学习。2把握好重点业务流程、定期的监控和回顾、适当简化服务级别管理的流程。3综合考虑资源水平和成本，避免对服务水平不切实际的承诺；4IT 与业务部门持续分享流程经验，不断进步。总之， SLM 的任务就是要在 IT 服务质量、客户关系、以及 IT 服务成本三者之间博弈，寻找最有利的平衡点。小贴士：在实际运行中，服务级别管理是个动态的过程，是可以调整的，大可以先简单制定，然后根据实际情况进行调整。经过小半年的忙活，眨眼到了年底，夏忙的年终红包丰厚了许多，他也从一个 PC 修理工成长为系统管理员，“夏忙 ”成了“夏工” ，修机器、扯
27、皮、投诉离夏忙越来越远，转而代之的是 IT 规划，开发新系统、数据挖掘。其实，夏忙知道自己离真正的 IT 服务管理还有不少的路要走，比如合理化规划目前的系统资源，开发新的应，比如进行企业的资产管理，再比如怎么才能让 IT 为管理搭好桥。这就是夏忙从瞎忙的 IT 网管成长为合格的 IT 规划者的道路，也是 IT 服务管理的灵活运用。做好三个心理准备做 IT 服务管理，并不是 IT 自己的事情，因为 IT 最终也是要为管理服务的，应该说，业务部门也要参与到 IT 服务管理工作中。所以，无论是 IT 部门，还是业务部门，做 IT 服务管理都得有三个心理准备。一是要有改变工作方式和规则的准备。IT 部
28、门和业务部门都有习惯性的工作方式，他们会继续采用原有的流程、做法，甚至会拒绝接受新的工作流程、方式。因此，为了保证实施效果，需要把 IT 服务管理的实施结果与 IT 人员和业务人员进行充分沟通，使他们能够充分理解 IT 服务管理的实施对他们带来的影响、好处，知道如何去做才能达到 IT 服务管理的要求。二是不要操之过急。IT 服务管理本身是由国外引入的，与国内的 IT 管理方式有一定区别，再加上前文提到习惯改变的难度，可以说，做 IT 服务管理要有磨合期，也是一个循序渐进，螺旋式上升的过程。做好打持久战的准备，磨合期内，不断调整，不断进步，才是正道。三是要充分吸收业务部门的意见和建议。虽然业务部门并不懂 IT，甚至有乱指挥的嫌疑，但 IT 服务管理的最终目的就是提高 IT 运营效率，满足业务对 IT 的需求，实现业务目标。IT 服务管理中，IT 与业务部门的交互比比皆是，满足业务对 IT 的需求，让业务部门人员参与进来，会极大促进 IT 人员对 IT 本身，以及对业务的全面了解，不断提升 IT 价值，满足业务对 IT 的需求，实现业务目标。
