2007-11-14 11:00
背景介绍
随着信息系统的广泛应用,员工没有电脑就无法工作,企业离开信息系统就无法顺利开展业务。
信息部作为企业的内部信息化部门,承担了包括软件开发、系统维护、硬件维护的几乎所有IT相关任务,对保障公司业务系统的正常运作起到了举足轻重的作用。
随着信息化程度的不断提高,企业和员工对IT的依赖程度越来越大,问题也越来越多,既包括硬件维修,也包括软件维护;既包括业务系统的功能使用,也包括后台数据的修改维护;既包括新项目立项,也包括老系统改造。
面对花样百出的各种问题,信息部的硬件工程师、软件开发工程师、系统维护工程师几乎是全民皆兵的四处解决问题,工作强度不断增加,甚至没有时间处理其它事情。可在实际工作中却经常发生这样的现象:硬件工程师风风火火的跑到用户那里去修机器,却发现是业务系统在报错,自己也无能为力;维护工程师经常在尝试了各种调试方法之后发现,原来报表里没有数据是因为局域网断了,连接不上数据库;开发工程师经常在写程序的时候被用户的电话打断,导致开发效率降低。
追根溯源
尽管信息部的工程师们加班加点的努力工作,但工作效率并不高,服务水平也欠佳,而且在其它部门那里得到的评价却往往是——“问题处理不及时”、“出了问题不知道找谁”、“技术人员态度很差而且解决不了问题”,凡此种种,不一而足。
到底原因何在呢?
原因一:没有统一的对外接口
信息部没有统一的对外服务接口,业务人员遇到问题时只能自己联系具体负责的工程师。但是很多时候业务人员并不能判断对口的工程师是哪位,无奈只好利用以前积累下的人脉,找到自己比较熟悉的工程师,请他帮忙处理或寻找相关负责人。
在信息部内部,所有工程师都有可能被迫去为用户解决问题,充当问题的中转站,无论这件事是否该他负责,是否打断思路,是否影响其它工作的完成。既造成了工作效率的下降,也可能造成服务质量不一,解决效果欠佳。业务人员在紧急时刻不知道该找谁,或是找到的人不能迅速解决问题,直接导致了满意度下降。
原因二:缺乏统一调度
工程师遇到自己处理不了的问题后,最直接的反应就是象案例中的小王一样——在办公室里大喊一声,直接寻找责任人或征求意见。这样很有可能因为某个系统的负责人不在而造成信息遗漏,或者因为沟通不充分而造成对问题的误判,以致一个电话转了N次才找到负责人,不仅浪费大量时间,还经常会出错,造成问题长时间得不到解决,用户满意度进一步降低。
因为没有统一的调度,那些工作能力强、与用户接触多的员工经常要承担大量的额外工作,导致这部分员工不堪重负,而另外一部分人可能因为不与用户直接接触而根本就没人找,直接导致了工作量的分配不均,严重影响员工士气。
原因三:缺乏汇总和监控
信息部目前对问题没有作专门的汇总和监控,所以没有人清楚到底有多少个问题正在处理,处理的进度如何。造成的直接后果就是——有些问题拖久了就忘了,根本得不到解决;或者是不了解处理情况,用户询问时无言以对;或者是有了解决方案却没人督促落实,最后不了了之。
对于业务部门来说,问题提出后如同泥牛入海,不亲自打电话追问,根本无从得知处理情况,可这电话又不好打得太勤,怕给人家添麻烦,只好苦等。这样就产生很多不必要的焦虑和误解,也影响了业务人员的工作安排。
原因四:缺乏知识共享
很多时候,由于缺乏知识共享,工程师解决问题时并不知道已经有现成的解决方法,还要从头摸索,“白做工”既耽误时间又浪费精力。
另外,由于缺乏知识共享,工程师在处理问题时只能依靠单兵作战,无法获得来自团队的帮助。如果碰巧遇到不擅长的问题,必然出现和解决不了问题的情况,不可避免的给用户留下解决不了问题的印象。
原因五:分工被打乱
信息部的员工只要接到问题电话,都会责无旁贷的去帮用户解决问题,这样的责任感值得尊敬,但这种做法却并不利于提高工作效率和服务水平。
其实信息部是有明确分工的:硬件维护处、软件开发处和系统支持处。本来大家应该按照既定分工来开展工作,但却被无数个突如其来的“问题电话”打断了,不得不放下手中的工作,中断顺畅的思路,来处理这些额外的情况。这样一来,不仅工程师的工作效率降低了,而且由于专业的局限很容易发生误判或者无力解决的情况,影响到整体的服务水平。
突出重围
“黑盒”和“白盒”是两种软件测试方法。白盒测试是以技术的角度,着眼于内部程序分析;而黑盒测试是以用户的角度,着眼于外部功能实现,不考虑内部逻辑结构。
从案例中的信息部目前的状态来看:
用户需要准确的找到负责的工程师才能保证问题的顺利解决,否则可能绕一个大圈才能搞定。这要求用户了解每个工程师负责的内容,让后向他提出问题,就好像一个“白盒”,你要使用它就必须了解它的内在结构。
使用一个“白盒”对用户来说,基本上是不可能的。对信息部来说呢?在“白盒”状态下,每位工程师都有可能要去处理用户提出的问题,经常有重复劳动的情况发生;相互之间缺乏协作,经常因个人能力所限影响服务质量;没人把握整体情况,面对用户的询问无言以对;由于用户的惯性,那些经常接触用户的工程师承担了大部分工作量,造成有人忙有人闲,伤害了他们的工作热情,不利于团队建设。
那么,信息部应该怎样走出“白盒”的泥沼呢?关键的一步是要向“黑盒”转变。
具体的做法可以参考下面几点:
“黑盒”方略一:建立服务接口人制度
“白盒”时期最令业务部门头疼的问题就是:出了问题不知道该找谁,一旦找错后果会很严重。这其实是“白盒”的特点之一,用户需要了解其内在结构并依靠自己的判断作出正确的选择,显然这对我们的用户来说是有些强人所难了。
如同图1中的蓝色箭头所示,如果用户找到对口的工程师,可能问题处理起来迅速而且高效;如果找错了,转了N道手之后,才交到对口的工程师手上,在转手的过程中还可能发生信息丢失或误传,影响问题的顺利解决。
那么,建立服务接口人制度(Interface Policy)应该是信息部一个很好的选择。信息部可以选派1-2名知识面比较广的工程师来担当服务接口人,处理所有用户提出的问题。如果接口人可以直接处理,问题便到此为止;如果处理不了,接口人需要向用户给出处理方案和期限,然后转交相关的工程师处理,并随时跟踪进展情况。
这样一来,用户不必再头疼该找谁了。只要遇到问题,直接与信息部的接口人联系即可,即使当时解决不了,也可以了解到解决方案和期限,还能从接口人那里了解处理进度。
对信息部来说,服务接口人制度相当于在工程师与用户之间设立了一个缓冲区,将二者隔离开,使工程师们不会被用户的电话打乱工作计划,可以专心于手头的任务,从而提高工作效率。
“黑盒”方略二:设立调度办公室
对于人员少而且职责简单的信息部门来说,设立了接口人已经足够了。但是案例中的信息部承担了包括软件、硬件在内的所有服务支持任务,而且人员各有分工,人员也不在少数,仅设立接口人恐怕并不能解决所有问题。
有些问题处理起来会很耗时,占用人员也很多,接口人由于能力和职责所限,可能无法作出正确的判断,也没有权限直接调度工程师。这时就需要一个更高的管理机构,根据人员的工作量和任务安排,结合问题的实际情况作出判断,并将任务分配给相关人员来负责。这个管理机构就是调度办公室(Control Office)。
有了调度办公室,就可以从信息部整体的高度来考虑各类问题的解决方案,根据问题的紧迫性来安排进度,根据人员占用情况来分配任务,根据工程师的技术特点把问题交到最合适的人手里——以此来避免因调度协调不力导致的响应不及时、解决期限过长、工作量分配不均、额外工作影响绩效等情况的发生。
“黑盒”方略三:设立协作平台
建立了接口人制度和调度办公室之后,信息部不但增强了对问题了解和控制能力,而且也可以为用户提供及时准确的进展情况,满足了内部和外部两方面的知情需要。
但是,由于各类问题的信息都集中到接口人或调度办公室手上,各方的询问无形中增加了他们的工作量,可能会影响到对其它问题的处理,就好像开发人员不断被打扰时的情况一样,以致于降低工作效率和工作质量。
怎样解决这个问题呢?建立一个统一的协作平台也许是个不错的选择。而且我们可以依托信息部的软件开发能力,搭建起简便易用的网站平台作为内外沟通的桥梁:
用户可以在这里查询到问题的处理情况和进展,并据此调整工作安排,提高工作效率;用户可以在这里搜索到类似问题的解决方案,那些简单的问题自己就可以解决,既减轻了信息部的工作负荷也节约了自己的时间;
工程师可以通过这个平台了解问题的相关信息,接口人和调度办公室可以对问题的处理情况和进展进行跟踪和监控;
工程师们可以通过这个平台查询以往的处理方法和所需知识,达到知识共享和提高个人能力的目的,从而缩短处理时间,提高处理效率。
信息共享对促进内外部沟通和提高处理问题的能力都有很大帮助,而且这个协作还可以作为整个公司的信息共享和知识共享平台,发挥更大的作用。
信息部门作为信息化的主力军,更应该为其他部门作出表率,积极的利用信息系统提高自己的工作效率和水平,为其他部门提供更加方便快捷的服务。
“黑盒”方略四:完善内部流程
业务部门提出的问题当中,除了日常应用的问题外,还可能有关于新功能开发、老系统升级等问题,这些关系到信息化规划与发展的需求应当等到更高的关注程度和支持力度。
这就要求信息部完善项目立项、系统变更、权限申请等内部流程。对这些内部流程,也可以整合到前边提到的协作平台上来,既方便业务部门及时提出新的需求,也有利于增强信息部对重要业务需求的响应速度和关注程度。
“黑盒”方略五:制定中长期规划
除了日常的软硬件维护之外,信息部的另外一项重要职责是:制定企业的信息化发展规划。随着对信息化的依赖程度不断增加,信息化建设逐渐上升到了战略层面,直接关系到企业未来的发展,我们必须投入足够的时间和人手来考虑这个问题。
根据企业的中长期战略规划,可以制定出信息系统建设的中长期规划,得到行动路线图;利用从业务部门了解到的情况,可以分析出业务的发展方向并制定出短期规划。根据这些规划,可以有针对性的开展技术培训,进行人员储备,为下一步的信息系统建设做好准备。
乘胜追击
业务部门也建立接口人制度
我们梳理了信息部内部的工作流程和人员配置,提高了信息部对外的综合响应能力,降低了业务部门与信息部打交道的难度,使得业务部门可以轻松方便的获得技术支持。那么,信息部在与业务部门打交道的情况怎样呢?
由于业务部门也存在和信息部一样的问题,在工程师作需求调研时,需要找多位员工了解情况,这些情况很可能会出现自相矛盾的情况,严重影响调研的质量的速度。在系统实施阶段也有类似的情况,工程师需要培训所有用户,因而工作量巨大而且进展缓慢。
为了避免上述情况的不断重演,我们可以在业务部门也推行“业务接口人”制度。这样在调研时,业务接口人可以提供相关情况;在实施时,接口人可以自己先学会然后去培训其他人;在业务变化时,接口人可以及时提出立项或是变更申请,以保证业务系统的顺利运转。
根据自身情况实施ITIL
信息部可以根据自身的情况和特点来选择是否借鉴ITIL的做法来设计流程,改善“白盒”状态下的混乱局面。
小结
如何改善目前的混乱状况,提高IT服务的水平,塑造一个良好的部门形象,是许多信息部门都面临的问题,例如案例当中的信息部。
要想做好IT治理的工作,首先要把自己放到服务提供者得位置上,更好的为其它部门服务。其次是整合内部流程,形成部门合力,为用户提供稳定有效的技术支持。然后是简化接口,提供简单明了的服务标准和服务规范。最后,建立信息平台,为用户提供便捷高效的IT支持。