2 突发事件管理 摆平漏子不罚款

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

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

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

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

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

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

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

　　夏忙反思，网络中心那台出故障的交换机上连接着公司的销售部邮件服务器、库存数据库服务器、人力资源服务器，这一事故将直接影响到公司内关键部门的正常生产，应该属于紧急一级，如果不尽快处理将发生一级生产事故；而急脾气同事的事件则属于一般级别。因此先处理网络中心交换机问题是对的。

　　但是自己在紧急事件的处理工时上把握不够，刚才用了大约3个工时来处理交换机的问题。那么如果当自己在规定的时间内不能解决或没有解决某个突发事件时，又该怎么办？一般来说，如果不能在规定时间内解决，需将处理任务交给更有经验的支持人员。这叫突发事件升级，通常有两种方式：一、职能升级，安排更多的专家或授予更多的特权以解决事故；二、层次升级，出现在所需的权限和资源不够的时候。

　　突发事件管理可以帮助IT部门更加系统、快速地处理突发事件，但是只是规范处理过程，以尽快恢复故障。好比是急诊抢救，治标不治本。

　　要使突发事件管理有质的提高，治标也治本，一种切实有效的方法就是问题管理流程。

　　　　小贴士：

　　当IT服务台必须同时处理数个突发事件时，由于受时间、资源和人力等的限制而无法实现时，首先要排定处理的先后次序，针对不同的优先级处理。

　　确定突发事件处理优先级，需要综合考虑突发事件的影响、紧迫性、大小、范围、复杂程度和当前可供资源。
3 问题管理 主动预防没风险

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

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

　　晚上10点，总算有点头绪。夏忙坐下来，才想起自己几乎{yt}没吃饭、没喝水了。其实想象得到，每次长假后的{dy}天对IT人员来说都是黑色的，这和过节一样已经成为惯例。

　　喝了一杯水、吃了点面包、点上一支烟，夏忙回忆起这{yt}所干的事。长假过后，收邮件高峰会有网络堵塞，南方潮湿闷热的天气也会使得本来条件就差的机房服务器出现接触问题。

　　趁着发牢骚的时间网管们开了个小会，自学了几天IT服务管理的夏忙发现，事实上，今天他和其他两位同事的很多工作具有一定的重复性，业务等几个部门出现的IT问题几乎都是一样的。既然有规律可以循，是不是有办法加强防范，结局岂不皆大欢喜？

　　夏忙想起几天前做过的ITSM的培训，其中有一段说的就是问题管理，说白了就是“归堆儿之后再分类”，要求建立一个知识库，把以前发生的众多问题进行归纳总结，找出规律对号入座，同时总结经验不断丰富。

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

　　其实无论什么公司，员工对IT的需求都有一定的共性。只处理不分析、不总结、不改进的IT永远只能是重复劳动。而如果通过引入问题管理，建立一个知识库，将众多问题归纳总结，找出规律加以实践，同时加强防范，不仅提高了效率，活也在一定程度上“少干”了。

　　夏忙越考虑越觉得有意思，于是打电话给上次给他讲课的蒋得明老师。面对渴求上进的夏忙的困惑，老师打了几个比方：事故管理是“救火”，问题管理是“消防”；事故管理是有病治病，问题管理是预防和保健。具体来说，滚滚来贸易公司在IT管理上，目前仅仅解决了如何规范地xx事故，而没有做到找出导致事故的原因并彻底解决问题。

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

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

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

　　从此，滚滚来公司IT部门的公共文件夹多了一个文件夹，网管们记录每个问题的现象、原因和解决细节。

　　一个月下来，居然积累了300多个问题，共分了16大类，700多个原因。看着眼前的成就，夏忙有了底。

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

　　

　　小贴士：

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

　　

　　如何提升IT服务效率

　　如何提升IT服务效率，提高IT资源的利用率，发挥IT资源的{zd0}效能，降低IT服务成本，量化IT产出，一直是IT管理者面临的难题和挑战。

　　IT服务管理（ITSM）可以形象地称为IT管理的“ERP解决方案”。IT服务管理是用来提升IT服务效率，协调IT服务部门内部运作，改善IT服务部门与业务部门的沟通，帮助企业对信息系统规划、实施和运营进行有效管理的方法。IT服务管理结合企业的环境、组织结构、IT资源和管理流程的特点，从流程、人员和技术三个方面来规划企业的IT结构。它强调企业的运营目标、企业需求和IT服务的交付相协调一致。

　　从组织层面来看，它将企业的IT部门从成本中心转化为服务中心或者利润中心；从具体运营来看，它改变传统的以职能、技术为中心的IT管理方式，以流程为中心，从复杂的IT管理活动中梳理出那些核心的流程，将这些流程标准化、规范化，明确定义各个流程的目标和范围、成本和效益、运营步骤、关键成功因素和绩效指标以及各个流程之间的关系，实现从传统的技术管理向流程管理，再向服务管理的转换。
变更管理 有人“埋坑”不犯难

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

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

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

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

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

　　这事就已经够折腾的了。但是，由于11月份IT部门在忙着一个新系统的安装，所以这事完了以后夏忙一直没来得及跟整个IT部门讨论。

　　哪里想到这个月听了总经理一通训话以后，各个部门都比较积极地革新业务流程。采购部、人事部、财务部……在那几天纷纷都来找IT部门来改流程、改参数。这下惨了，几乎每次更改后都出现了问题。接连几天夏忙更忙了，接连解决更改后出现的问题。

　　累得一塌糊涂的夏忙一闲下来就寻思：这不行呀，总经理训一次话就出现了那么多问题，万一他再训一次话，岂不是又完了；再说了，就算是总经理不训话了，业务部门还是会经常提出要修改系统配置等问题的，毕竟对业务部门来说，“变”是件好事。如果还是像过去那样随便变更，IT部门迟早要被这无数的“变更”给折腾惨了。

　　夏忙心想，还不如趁这个机会建立一个变更管理的机制。这样，一旦业务部门有了新业务、新变化、新流程，需要IT根据这新情况进行变更的时候，IT部门可以事先知道。

　　紧接着，夏忙就针对变更管理这个问题看了很多专业书籍，同时还虚心向同行请教。忙了半个月后，夏忙终于设计出了自己的变更管理流程。

　　夏忙自己动手给IT部门制定出了一个明确的需求变化表。用户有变化需求时必须按照手续提交。拿到需求表以后，IT人员也不能马上修改程序，而是应该判定此需求是否合理，是否会对以前的系统以及其他系统造成影响，必要的时候要与业务部门召开专题讨论会，讨论具体修改事情。同时，在内部网站中的IT服务专栏发布IT作业公告。相关部门如果有异议，可以在反馈期之内反馈。

　　如果判断通过，也不随便就做更改，而是提出明确的时间表、修改方法和意见，征求业务部门同意后，按时按量完成。

　　变更实施完毕以后，还要对变更的实施情况进行总结和评价：变更是否成功实施，业务部门是否满意等；变更是否还有遗留问题，是否存在副作用。

　　“虽然总经理的训话害得我那么苦，但是就这个机会完善了变更管理流程以后，就再不怕其他的变更了，也算是没有白忙乎。”对于这个月的工作，夏忙还是很有成就感。

　　

　　小贴士：

　　实施变更管理流程过程中，有两个要素很重要。

　　其一，要转变IT工程师的观念和行为。变更管理流程的实行，刚开始的时候，对IT工程师的行为是一个约束。工程师对系统做任何修改、调整，都需要在变更管理系统申请、备案。因此，需要加强对IT工程师的宣传和要求，转变观念，使其能够接受并习惯。

　　其二，要明确职责。变更管理包括诸多流程，也涉及不同部门、不同岗位的人员。因此，需要界定各方人员的职责。如变更管理经理的职责，相关部门人员的职责，等等。只有职责清楚，各项职责执行到位，变更管理流程才能有效落实。

5 服务级别管理 　　轻重缓急要掌管

　　前几个月一直表现亮眼的IT部门最近成了老板的心头好，员工们的抱怨没了不说，还进行了好几项突破性的改革，一派鸟枪换炮的新貌。年关将近，夏忙他们几乎看到了可观年终红包的招手。

　　这天，本该春风得意的夏忙长叹了口气：“唉！”其他人忙问：“小夏，你怎么了？连变更管理、突发事件管理……这样的头疼事件都能解决，你还会被难倒不成？”夏忙又叹了口气，说：“各位有所不知，万里长征也不过走出了几小步。前几个月的工作尽管卓有成效，但跟接下来这个月要面对的事情一比，简直就是小巫见大巫。一不小心，我们全体同仁煮熟的鸭子红包恐怕就要飞了。”

　　这可不是夏忙小题大做，让他头疼的正是号称IT服务管理{zd0}难题的—服务级别管理（SLA）。

　　对此，夏忙可有切肤之痛。得到同事们肯定了的IT部门是更加勤快了，但有时候却拣了芝麻丢了西瓜—一次，在他忙着花半小时修理打印机的时候，服务器由于病毒入侵而瘫痪了整整20分钟！公司的网上交易也因此停顿半天，老板的雷霆发了足足有90分钟。

　　什么是服务级别管理？简单地说，建立一套规则，当企业中有多个不同需求同时发生时，应该先响应谁的；以及对于不同的需求应该分配多长的时间。

　　“还是服务级别管理没搞好啊！”夏忙感叹。“我们IT部门应该有一个清楚的清单，列举出我们能够提供哪些服务，以及定义好各种业务部门要求提供的服务的级别。哪个级别高，哪个级别低，级别高的优先响应，级别低的等一等；规定问题的响应时间极限，哪个问题可以等上2个小时，或者等4个小时，哪个一秒钟也不能等……”

　　听来很不错，不过要想搞好服务级别管理，可不是IT部门自己关上门来定一套规矩就行的，夏忙之所以谈“服务级别管理”色变，就是因为知道：服务级别管理的{zd0}难度，在于定义各种服务的级别，而且不同企业也大不相同。

　　因此，IT服务级别的制定必须是业务部门与IT部门共同沟通的结果——服务级别协议。IT服务部门在对IT基础架构进行服务级别设计时，就必须充分调查和了解真实的业务需求。夏忙花了大量的时间和业务部门进行全面沟通。

　　他不仅调查了业务部门对当前服务级别的体验（Perception），还在这个基础上帮助他们分析和梳理那些真实存在却又还未明确的业务需求。

　　为了避免重蹈其他公司推行服务级别管理失败的覆辙，夏忙归纳出了几条“黄金法则”：

1．在服务级别协议中业务部门看不懂的日常术语需要学习。

2．把握好重点业务流程、定期的监控和回顾、适当简化服务级别管理的流程。

3．综合考虑资源水平和成本，避免对服务水平不切实际的承诺；

4．IT与业务部门持续分享流程经验，不断进步。

　　总之， SLM 的任务就是要在 IT 服务质量、客户关系、以及 IT 服务成本三者之间博弈，寻找最有利的平衡点。

　　小贴士：

　　在实际运行中，服务级别管理是个动态的过程，是可以调整的，大可以先简单制定，然后根据实际情况进行调整。

　　经过小半年的忙活，眨眼到了年底，夏忙的年终红包丰厚了许多，他也从一个PC修理工成长为系统管理员，“夏忙”成了“夏工”，修机器、扯皮、投诉离夏忙越来越远，转而代之的是IT规划，开发新系统、数据挖掘。

　　其实，夏忙知道自己离真正的IT服务管理还有不少的路要走，比如合理化规划目前的系统资源，开发新的应，比如进行企业的资产管理，再比如怎么才能让IT为管理搭好桥。

　　这就是夏忙从瞎忙的IT网管成长为合格的IT规划者的道路，也是IT服务管理的灵活运用。

　　

　　做好三个心理准备

　　做IT服务管理，并不是IT自己的事情，因为IT最终也是要为管理服务的，应该说，业务部门也要参与到IT服务管理工作中。所以，无论是IT部门，还是业务部门，做IT服务管理都得有三个心理准备。

　　一是要有改变工作方式和规则的准备。IT部门和业务部门都有习惯性的工作方式，他们会继续采用原有的流程、做法，甚至会拒绝接受新的工作流程、方式。因此，为了保证实施效果，需要把IT服务管理的实施结果与IT人员和业务人员进行充分沟通，使他们能够充分理解IT服务管理的实施对他们带来的影响、好处，知道如何去做才能达到IT服务管理的要求。

　　二是不要操之过急。IT服务管理本身是由国外引入的，与国内的IT管理方式有一定区别，再加上前文提到习惯改变的难度，可以说，做IT服务管理要有磨合期，也是一个循序渐进，螺旋式上升的过程。做好打持久战的准备，磨合期内，不断调整，不断进步，才是正道。

　　三是要充分吸收业务部门的意见和建议。虽然业务部门并不懂IT，甚至有乱指挥的嫌疑，但IT服务管理的最终目的就是提高IT运营效率，满足业务对IT的需求，实现业务目标。IT服务管理中，IT与业务部门的交互比比皆是，满足业务对IT的需求，让业务部门人员参与进来，会极大促进IT人员对IT本身，以及对业务的全面了解，不断提升IT价值，满足业务对IT的需求，实现业务目标。