2008-05-07 16:51:00 来源:前沿论丛
场景一 总公司信息部
软件开发处的小王正在埋头开发一个帐龄分析报表,突然电话铃响起,小王手一抖,差点选错了对象的属性。无奈的拿起听筒,小王仍然紧盯着那串代码。
“你好,信息部。”
“你好,小王吗,我是天津财务小杨啊。”
“小杨啊,怎么了,是不是财务系统有什么问题呀?”
“不是的,财务系统没问题,是我想要看一下今年的销量和毛利,我们领导让我出个报表,可是成本核算系统我登录不上去啊,怎么回事?”
“这样啊,你需要在成本核算系统里申请权限才能用的。”
“那怎么申请啊?”
“这个我也不太清楚,等我帮你问问啊。”小王站起身,四下望望,然后大喊一声:“成本核算系统哪个在管啊~~~”
“我,是我管的。”运行支持处那边的小李应声探出头来。
“你分机多少?”
“6666”
“唔,小杨啊,这样,你打分机6666找小李给你把权限加上,然后就能用了。”
“好的,谢谢啊!”
“不客气。”小王放下电话,目光回到之前的程序代码上,刚刚写了一半的算法完全找不到思路了。叹口气,小王认命的一边重新看代码,一边重新思考这个算法。
场景二 天津分公司
销售员小张对着电脑直发呆,打水路过的财务小杨凑过来问:“怎么了?”
“crm系统上不去了,客户资料调不出来,我今天跟人家谈什么啊。”
“那你找信息部的人问问呗。”
“以前管这个系统的系统支持处的工程师离职了,信息部几十号人呢,我哪知道该找谁呀。”
“哎,这可不好办了,要不,你给信息部的小王打个电话问问,反正我有事都是找他,停热心的小伙子。”
“那感情好,他分机多少?”
。。。。。。
场景三 总公司信息部
“阿嚏~阿嚏~”小王接连打了2个喷嚏,心里一阵发虚。扭头看看安静的电话,心里开始犯嘀咕:“唉,不知道下次什么时候响起来,Bill,Steve,拜托让它等我写完这个程序再响吧~~”
“叮铃铃——”
。。。。。。
“你能登陆我们内部的员工网站吗?”
“嗯,好像不行。”
“其它人能上吗?”
“好像也上不了。”
“可能是你们那边的网络出了问题。这样,你找硬件维护处的郑工,让他帮你看一下。”
“好的好的,谢谢你啊。”
“不客气。”小王放下电话,再次叹气,又一次开始回顾刚才那段代码。。。。。。
背景介绍
随着信息系统的广泛应用,员工没有电脑就无法工作,企业离开信息系统就无法顺利开展业务。
在案例中,信息部作为企业的内部信息化部门,承担了包括软件开发、系统维护、硬件维护的几乎所有IT相关任务,对保障公司业务系统的正常运作起到了举足轻重的作用。
随着信息化程度的不断提高,企业和员工对IT的依赖程度越来越大,问题也越来越多,既包括硬件维修,也包括软件维护;既包括业务系统的功能使用,也包括后台数据的修改维护;既包括新项目立项,也包括老系统改造。
面对花样百出的各种问题,信息部的硬件工程师、软件开发工程师、系统维护工程师几乎是全民皆兵的四处解决问题,工作强度不断增加,甚至没有时间处理其它事情。可在实际工作中却经常发生这样的现象:硬件工程师风风火火的跑到用户那里去修机器,却发现是业务系统在报错,自己也无能为力;维护工程师经常在尝试了各种调试方法之后发现,原来报表里没有数据是因为局域网断了,连接不上数据库;开发工程师经常在写程序的时候被用户的电话打断,导致开发效率降低。
追根溯源
尽管信息部的工程师们加班加点的努力工作,但工作效率并不高,服务水平也欠佳,而且在其它部门那里得到的评价却往往是——“问题处理不及时”、“出了问题不知道找谁”、“技术人员态度很差而且解决不了问题”,凡此种种,不一而足。
到底原因何在呢?
原因一:没有统一的对外接口
信息部没有统一的对外服务接口,业务人员遇到问题时只能自己联系具体负责的工程师。但是很多时候业务人员并不能判断对口的工程师是哪位,无奈只好利用以前积累下的人脉,找到自己比较熟悉的工程师,请他帮忙处理或寻找相关负责人。
在信息部内部,所有工程师都有可能被迫去为用户解决问题,充当问题的中转站,无论这件事是否该他负责,是否打断思路,是否影响其它工作的完成。既造成了工作效率的下降,也可能造成服务质量不一,解决效果欠佳。业务人员在紧急时刻不知道该找谁,或是找到的人不能迅速解决问题,直接导致了满意度下降。
原因二:缺乏统一调度
工程师遇到自己处理不了的问题后,最直接的反应就是象案例中的小王一样——在办公室里大喊一声,直接寻找责任人或征求意见。这样很有可能因为某个系统的负责人不在而造成信息遗漏,或者因为沟通不充分而造成对问题的误判,以致一个电话转了N次才找到负责人,不仅浪费大量时间,还经常会出错,造成问题长时间得不到解决,用户满意度进一步降低。
因为没有统一的调度,那些工作能力强、与用户接触多的员工经常要承担大量的额外工作,导致这部分员工不堪重负,而另外一部分人可能因为不与用户直接接触而根本就没人找,直接导致了工作量的分配不均,严重影响员工士气。
原因三:缺乏汇总和监控
信息部目前对问题没有作专门的汇总和监控,所以没有人清楚到底有多少个问题正在处理,处理的进度如何。造成的直接后果就是——有些问题拖久了就忘了,根本得不到解决;或者是不了解处理情况,用户询问时无言以对;或者是有了解决方案却没人督促落实,最后不了了之。
对于业务部门来说,问题提出后如同泥牛入海,不亲自打电话追问,根本无从得知处理情况,可这电话又不好打得太勤,怕给人家添麻烦,只好苦等。这样就产生很多不必要的焦虑和误解,也影响了业务人员的工作安排。
原因四:缺乏知识共享
很多时候,由于缺乏知识共享,工程师解决问题时并不知道已经有现成的解决方法,还要从头摸索,“白做工”既耽误时间又浪费精力。
另外,由于缺乏知识共享,工程师在处理问题时只能依靠单兵作战,无法获得来自团队的帮助。如果碰巧遇到不擅长的问题,必然出现和解决不了问题的情况,不可避免的给用户留下解决不了问题的印象。
原因五:分工被打乱
信息部的员工只要接到问题电话,都会责无旁贷的去帮用户解决问题,这样的责任感值得尊敬,但这种做法却并不利于提高工作效率和服务水平。
其实信息部是有明确分工的:硬件维护处、软件开发处和系统支持处。本来大家应该按照既定分工来开展工作,但却被无数个突如其来的“问题电话”打断了,不得不放下手中的工作,中断顺畅的思路,来处理这些额外的情况。这样一来,不仅工程师的工作效率降低了,而且由于专业的局限很容易发生误判或者无力解决的情况,影响到整体的服务水平。
突出重围
“黑盒”和“白盒”是两种软件测试方法。白盒测试是以技术的角度,着眼于内部程序分析;而黑盒测试是以用户的角度,着眼于外部功能实现,不考虑内部逻辑结构。
从案例中的信息部目前的状态来看:
用户需要准确的找到负责的工程师才能保证问题的顺利解决,否则可能绕一个大圈才能搞定。这要求用户了解每个工程师负责的内容,让后向他提出问题,就好像一个“白盒”,你要使用它就必须了解它的内在结构。
使用一个“白盒”对用户来说,基本上是不可能的。对信息部来说呢?在“白盒”状态下,每位工程师都有可能要去处理用户提出的问题,经常有重复劳动的情况发生;相互之间缺乏协作,经常因个人能力所限影响服务质量;没人把握整体情况,面对用户的询问无言以对;由于用户的惯性,那些经常接触用户的工程师承担了大部分工作量,造成有人忙有人闲,伤害了他们的工作热情,不利于团队建设。
那么,信息部应该怎样走出“白盒”的泥沼呢?关键的一步是要向“黑盒”转变。
首先,要明确定位。信息部作为企业重要的支撑部门,是在为其它部门提供服务,需要不断提高自身的服务水平和质量。
其次,要降低门槛。让用户能够轻易的获取帮助,是信息部努力的方向。
再次,要迅速响应。让用户随时了解进展,尽量减少等待时间,可以增强用户的满度程度。
最后,要把握方向。除了日常的技术支持,信息部的另外一项重要职责是规划企业的信息化发展方向,绝对不容忽视。
具体的做法可以参考下面几点:
“黑盒”方略一:建立服务接口人制度
“白盒”时期最令业务部门头疼的问题就是:出了问题不知道该找谁,一旦找错后果会很严重。这其实是“白盒”的特点之一,用户需要了解其内在结构并依靠自己的判断作出正确的选择,显然这对我们的用户来说是有些强人所难了。
如同图1中的蓝色箭头所示,如果用户找到对口的工程师,可能问题处理起来迅速而且高效;如果找错了,可能就像图中的红色箭头一样,转了N道手之后,才交到对口的工程师手上,在转手的过程中还可能发生信息丢失或误传,影响问题的顺利解决。
那么,建立服务接口人制度(Interface Policy)应该是信息部一个很好的选择。信息部可以选派1-2名知识面比较广的工程师来担当服务接口人,处理所有用户提出的问题。如果接口人可以直接处理,问题便到此为止;如果处理不了,接口人需要向用户给出处理方案和期限,然后转交相关的工程师处理,并随时跟踪进展情况。
这样一来,用户不必再头疼该找谁了。只要遇到问题,直接与信息部的接口人联系即可,即使当时解决不了,也可以了解到解决方案和期限,还能从接口人那里了解处理进度。
对信息部来说,服务接口人制度相当于在工程师与用户之间设立了一个缓冲区,将二者隔离开,使工程师们不会被用户的电话打乱工作计划,可以专心于手头的任务,从而提高工作效率。
免责声明:本网站(http://www.ciotimes.com/)内容主要来自原创、合作媒体供稿和第三方投稿,凡在本网站出现的信息,均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性,但不保证有关资料的准确性及可靠性,读者在使用前请进一步核实,并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏,概不负任何法律责任。
本网站刊载的所有内容(包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等)版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时,请及时通知本站,予以删除。