学习资料： ITIL培训基地专家讲堂直播 300期视频回放

跟大家分享个故事：大家都比较清楚，IT部门虽然不是生产部门，但是他依然是业务辅助部门，可以形象的比喻为“后勤部门”但这并不意味着IT部门只能充当被动救火员的身份。规范好，管理好IT业务，让IT管理员从简单的修机器、收邮件等低级劳动中摆脱出来，真正成为为IT管理服务的典范。这就是IT服务管理的概念。

其实，实现IT服务管理，并不难。

1. 夏忙，28岁，2004年4月进入滚滚来贸易公司，负责IT工作。滚滚来贸易公司以做进出口为主，这几年发展尤其快，从最初的几十人到了现在的200多人，而且基本上是人手一台PC。网络、邮件已经逐步替代了以前的电话、传真，成为最新的办公手段。

IT部门有三个人，夏忙一来就发现这三个人基本都不在自己的座位上，因为公司的200多台机器，总有这样、那样的问题报过来。于是，夏忙也就很快投入了战斗一线，修机器、调邮件、杀病毒，成了被拎来拎去的“八抓鱼”。

忙归忙，可是每到月底填写考核表的时候，夏忙就一点都想不起来这个月干了什么。好像每天都没闲着，也好像每天都当救火队员，但是看看这个月有什么进步？除了扑了几次一样的火，修了几次机器以后，再也没有什么可以书写的记录了。

最让他郁闷和委屈的是，累死累活一个月下来，虽然忙得手脚不着地，可挨领导的批评也更多了，因为虽然问题是解决了，却收到了更多的投诉：找不到人、反应速度太慢、相似的问题总出现、没有预防措施......

总之，每天早晨，夏忙最担心一件事，今天会不会发生灾难性事件；每个月底，夏忙担心另外一件事，这个月因为遭遇投诉工资被扣了多少钱。

2004年8月31号，工资发下来之后，夏忙发现被扣了很多钱，IT部门的其他同事也是一样。后来才知道，主要原因是他帮大家修机器时不在座位，别人有事打电话总找不到人，自然提意见。

从加盟滚滚来公司到现在已有半年时间，夏忙越来越忙，因为单位人员在不断增加，系统越上越多，加上最近病毒等“天灾”频频光临公司，事情也越来越多。时下IT部门只有3个人，人手实在是太少了，有时候大家一起打电话求助，夏忙苦于应付，遇到不该自己管的事情，夏忙就总是告诉打电话者该找小欧，放不下手里活的小欧只好说，你找小王，结果是被集体投诉推托责任。

夏忙也有委屈，一个人分身乏术，人家业务部门的人一打电话来肯定得冲到一线，三个人都放出去，一旦活够复杂，电话没人接也就成了常有的事。

从8月中旬开始，夏忙陆续接触了IT服务管理的“一站式”服务概念。所谓“一站式”服务，就是业务部门可以一次性获取IT热线、IT现场等各种形式的IT服务，解决所有日常办公IT问题。“一站式”服务的精髓是IT服务台。IT服务台是用户与IT服务部门的中心联络点，客户的IT问题通过IT服务台获取答案和帮助。对于夏忙，通常来说，IT服务台可以有两种表现形式，一是电话申请服务，当用户的系统出现问题时，可以拨打服务台电话，根据语音提示选择不同的问题类别；二是网络申请服务。在IT网络服务中，夏忙建立了一个简单的基于Web形式统一入口，业务部门可通过Web的形式提出问题，问题自动提交到相应的IT工程师并进行解答,工程师之间也可以互相转移。作为一种很好的互动式服务渠道，是电话服务的补充。

建立IT服务台之后，夏忙他们三个人针对分工不同，排除了接了电话乱找人的情况，并定义了首问负责制：哪位工程师最先接到业务部门的电话，就成为该CASE的责任人，他需要自己或者协调相关人员解决并关闭这个“CASE”。这也解决了工程师间互相推委的现象。

服务台建立起来后，并非万事大吉。大家还是觉得电话方便，随叫随到。夏忙只好向老板申请，把IT部门新的服务方式形成制度，大家来学习和维护。

机器加人工，基本上满足了同事们的救援需求。

小贴士1：

问题响应方式固然重要，但让大家知道并且习惯也是一个过程。对于IT人员来说，要公示响应方式，让业务部门能够主动使用、愿意使用并满意使用。

2. 建立了服务台管理之后，夏忙从八爪鱼变成了随需应变的百变神形。因为响应及时，夏忙最近没听见什么抱怨。

一天，电脑提示收到一封事件警报邮件，同时，另外三封事件报警邮件也发到了夏忙的信箱。桌上的电话刺耳地响起，另外两位同事的电话声此起彼伏。

销售部的同事反映无法接收邮件。夏忙刚刚扑到销售部查问题，不多久，人事那边也找夏忙，人事部的PC系统崩溃了，夏忙指挥同事去人事部处理这一问题。事情还在处理中，忽然又接到一个报警，说财务的机器上不了网，现在是月底要报税，事情紧急。于是IT部门最后一个人去了财务部。夏忙忙乱得一头大汗，他不知道假如再来一桩突发事件，他该怎么办。此时，一直有人在找夏忙，有的机器中毒，有的机器蓝屏了等等。夏忙只好不停地说，“稍等——，稍等——”，一位急脾气的同事不耐烦了，“我急着要一份数据，硬盘却坏了，能不能先给我看看？”

“手边有紧急的事没处理完呢。”

“那你得分个轻重缓急啊。”夏忙一听，觉得有理，层出不穷的技术故障让IT部门的人疲于奔命，成了“救火队”。可状态不能老这么持续下去，需要有一套流程和方法来有序地处理。他决定把手边的事情忙完之后，好好思考一下。

经过紧张的排查，夏忙得出的结论是，网络中心的一台交换机出了故障，夏忙迅速联系网络中心并启用了备用的交换机。20分钟后，网络恢复正常。

趁着尘埃暂定，夏忙赶紧翻资料，能给目前无序的忙乱状态理出一个解决思路。他发现，对于突发事件，最重要的是避免业务中断。对此，首先要确定突发事件管理流程，通过区分突发事件的优先级来确保流程的有效执行。显然，每个人都会认为自己故障是最紧急的，因此必须理清是“火烧眉毛”还是“常规慢性病”。

夏忙反思，网络中心那台出故障的交换机上连接着公司的销售部邮件服务器、库存数据库服务器、人力资源服务器，这一事故将直接影响到公司内关键部门的正常生产，应该属于紧急一级，如果不尽快处理将发生一级生产事故；而急脾气同事的事件则属于一般级别。因此先处理网络中心交换机问题是对的。但是自己在紧急事件的处理工时上把握不够，刚才用了大约3个工时来处理交换机的问题。那么如果当自己在规定的时间内不能解决或没有解决某个突发事件时，又该怎么办？一般来说，如果不能在规定时间内解决，需将处理任务交给更有经验的支持人员。这叫突发事件升级，通常有两种方式：一、职能升级，安排更多的专家或授予更多的特权以解决事故；二、层次升级，出现在所需的权限和资源不够的时候。

突发事件管理可以帮助IT部门更加系统、快速地处理突发事件，但是只是规范处理过程，以尽快恢复故障。好比是急诊抢救，治标不治本。要使突发事件管理有质的提高，治标也治本，一种切实有效的方法就是问题管理流程。

小贴士2：

当IT服务台必须同时处理数个突发事件时，由于受时间、资源和人力等的限制而无法实现时，首先要排定处理的先后次序，针对不同的优先级处理。确定突发事件处理优先级，需要综合考虑突发事件的影响、紧迫性、大小、范围、复杂程度和当前可供资源。

3. 解决了突发事件，正赶上十一放长假，夏忙去了趟华山，彻底休息了一下。

10月8日一大早，夏忙的电话就响个不停。也难怪，一上班大家就忙着收邮件，积累了几天的邮件把服务器搞得巨慢；许多节前已经预约的客户需要尽快联系，可邮件一遍一遍就是发不出去；网络更是不知犯了什么病，很多机器死活上不去网......一整天，夏忙都在忙来跑去解决问题，面对抱怨，连解释的时间都没有。

晚上10点，总算有点头绪。夏忙坐下来，才想起自己几乎一天没吃饭、没喝水了。其实想象得到，每次长假后的第一天对IT人员来说都是黑色的，这和过节一样已经成为惯例。　　喝了一杯水、吃了点面包、点上一支烟，夏忙回忆起这一天所干的事。长假过后，收邮件高峰会有网络堵塞，南方潮湿闷热的天气也会使得本来条件就差的机房服务器出现接触问题。

趁着发牢骚的时间网管们开了个小会，自学了几天IT服务管理的夏忙发现，事实上，今天他和其他两位同事的很多工作具有一定的重复性，业务等几个部门出现的IT问题几乎都是一样的。既然有规律可以循，是不是有办法加强防范，结局岂不皆大欢喜？夏忙想起几天前做过的ITSM的培训，其中有一段说的就是问题管理，说白了就是“归堆儿之后再分类”，要求建立一个知识库，把以前发生的众多问题进行归纳总结，找出规律对号入座，同时总结经验不断丰富。

大道理谁也会讲，但夏忙还是不太理解。每天记录发生的问题，隔段时间再进行归纳总结和分类，多麻烦啊！本来工作量就大，哪有时间写日志呢？正因为有这样的想法，夏忙一直没当回事。不过今天看来，如果有这样的一个知识库就不至于这么狼狈。

其实无论什么公司，员工对IT的需求都有一定的共性。只处理不分析、不总结、不改进的IT永远只能是重复劳动。而如果通过引入问题管理，建立一个知识库，将众多问题归纳总结，找出规律加以实践，同时加强防范，不仅提高了效率，活也在一定程度上“少干”了。夏忙越考虑越觉得有意思，于是打电话给上次给他讲课的蒋得明老师。面对渴求上进的夏忙的困惑，老师打了几个比方：事故管理是“救火”，问题管理是“消防”；事故管理是有病治病，问题管理是预防和保健。具体来说，滚滚来贸易公司在IT管理上，目前仅仅解决了如何规范地消除事故，而没有做到找出导致事故的原因并彻底解决问题。

蒋老师还说，在现实中，问题是无法避免的，有技术架构、产品缺陷、操作失误等等很多原因。夏忙又头疼了，这么多的原因怎么分类呢？

蒋老师继续说，对问题的归类直接决定着问题管理的效果，问题归类涉及五个方面：确定与问题相关联的领域，比如硬件、软件等；影响度，问题对业务流程的影响程度；问题需要得到解决的紧急程度；优先级，综合考虑影响度、紧迫性、风险和可用资源后得出的解决问题的先后顺序；状态，描述事故目前所处的状况。

另外就是找原因，包括现实的原因和潜在的原因，当发现更好的或新的应急措施时，问题管理还要将其在记录中更新以便事故控制使用。

从此，滚滚来公司IT部门的公共文件夹多了一个文件夹，网管们记录每个问题的现象、原因和解决细节。一个月下来，居然积累了300多个问题，共分了16大类，700多个原因。看着眼前的成就，夏忙有了底。

有了这个草创的“知识库”，夏忙的工作进入了快车道，进入了“主动治本”阶段。此后，大家对夏忙所在的IT部门有了好评，意见明显少了。

小贴士3：

问题管理乍看起来对于IT人员来说是个费时间的活，但磨刀不误砍柴功。有了这些积累，加上分类、分析、预防等工作，效率明显提高了。对于IT人员来说，关键是排除抵触和为难情绪。

4. 11月1日，总经理召集各业务部门开会，简直就是一个批判会，总经理对10月各个部门的表现都不满意，特别是销售部门，惟独对IT部门提出了表扬，这让夏忙有一些宽慰.

第二天.好不容易轻松一点的夏忙晚到了公司一会，半路接到公司里电话，这个说有一封很紧要的邮件一直没法收；那个说说好要给一个重要客户把报价发过去的，但是现在也不能发......

原来是公司的邮件服务器出问题。可是昨天下班的时候这邮件服务器还好好的呀，夏忙赶紧给轮值的小欧打了个电话，问他昨天晚上都干什么了。

原来在总经理训话结束以后，销售经理就立刻召集了销售部门人员开了个会。为了改变目前的状态，销售部门讨论的结果是改变现有的工作流程。昨天晚上加班开完会确认了新流程后，销售经理把小欧找来要求系统也随着这个新流程做些更改。于是，小欧就根据销售经理的需求更改了几个参数。“改完后我仔细检查了一下，没发现什么问题呢。谁会想到邮件系统会出现问题呢？”小欧也很委屈。

夏忙明白了怎么回事以后，赶紧亲自到服务器上去恢复原来参数，让邮件服务器先正常工作。这一天夏忙没干别的，他花了整整一天的时间处理销售经理递交过来的需求。夏忙发现，销售经理拿过来的需求，有一些根本就不合理的。于是，夏忙又去找来销售经理“论理”。两人分析了半天，才讨论出了双方都满意的解决方案。
.......

谢谢分享!

很有启发

待续