[原创]面壁ITIL之服务台
本文发表于《中国计算机用户》 2007年2月12日 第7期 管理栏
在2006年底的例行年度总结中,“服务台如何成为事件的主人”被提上今年的议事日程。会开完了,任务随之层层下达,最后一直落到基层的服务台班组长头上。这几日,服务台班组长苦思冥想,搜肠刮肚,却始终不得其解。
“我们服务台的主要工作是向顾客讲解正确的咨询和指引服务”……“服务台通过一段时间的运作和改革后,发现我们的服务是肤浅的,并没有真正的了解顾客的需求。所以我们开展了一系列的改革措施,不仅注重硬件的建设,更侧重窗口形象的建设” 。这是服务台班组长在年终总结里对服务台的工作总结。从具体的职能岗位来看,有这样的认识无可厚非。但从理解ITIL服务台的角度来说,如果我们将服务台仅理解为某个职能岗位,那么上面这位服务台班组长自然无法理解“服务台成为事件主人”的用意。也许有人会问:为什么要成为事件的主人?为什么是服务台要成为事件的主人?
我们先来了解一下什么是事件。在此引用清华大学出版社出版的《现代IT服务管理-基于ITIL的最佳实践》一书中的定义:事件是指没有包含在服务标准运作之内,并且导致(或可能导致)中断服务或降低服务质量的意外事件或突发事件。
要成为事件的主人,也就是说我们要成为“导致(或可能导致)中断服务或降低服务质量的意外事件或突发事件”的主人。作主人,实际上是要求我们对这些事件具备全盘的掌控能力,具有绝对的主导地位。可为什么是服务台要具备这些能力呢?事件管理为什么不可以,问题管理哪里没能力呢?别急,且听我慢慢道来……
呼叫中心、帮助台、服务台,这些概念曾经困扰我很久。如何来理解这些概念,如何来认识服务台?服务台究竟是职能岗位,还是流程的一个环节等等诸如此类的问题一直让我在疑惑中徘徊。当理论理解出现障碍时,我决定从实践中寻找答案。
“一个关键业务、一个关键资源和一个管理中心”这是对客户服务中心IT服务结构的概要描述。
图1-客户服务中心组织结构简图
关键业务是指客户服务中心的实施管理部,包含服务台、任务管理、工程师管理、两个专项维护组(含一线和二线A组)以及一个二线B组。从这一系列的岗位设置可以看出,在关键业务中客户的服务请求经历了受理、调派、维护、跟踪、反馈等多个流程环节。
ITIL理论中有关服务台的描述,我接触到两种说法:
一是,服务台通常所指是帮助台和呼叫中心,强调的是服务职能,而非服务管理流程。没有严格有序的日常运作流程,只是针对用户的请求或根据服务级别协议的要求进行一些日常运作活动。包括:响应用户呼叫、为用户发布信息、客户需求管理和客户关系管理、供应商联络、日常运作管理、基础架构监控等。
二是,服务台是以客户为中心,并由技术专家、业务骨干以及协调能力强的人员构成。在客户与IT服务提供者之间建立了一个集中的单一联系点,不仅处理事件和问题,而且还为其它活动(变更请求、维护合同、配置管理等)提供联系的纽带。
由以上的两点描述,可以看出前者强调服务台是一个职能部门,至于究竟是帮助台,还是呼叫中心,不必过于细究;后者则强调服务台是一个服务流程的起点,对外的单一接触点。
现阶段客户服务中心关键业务中服务台更像是前者,但从整体的服务结构来看,关键业务提供的服务又和后者非常相像。基于流程管理的理念,我个人更倾向于后者的说法。因为以职能划分的IT服务存在一个弊端,那就是往往会产生局部最优的结果。在这种情况下,很少人会从整体的服务流程上去考虑本部门或本岗位的做法将会给流程整体最优带来的影响。
当思想从具体的职能岗位中突围,我认识到:服务台是面向客户的,以服务台为起点和终点的事件服务流程闭环(见图2)。也许是服务台这个极具职能意味的称谓混淆了我的理解,一直未能突破职能岗位的框框,也因此一直无法更深入地理解服务台,理解服务台的功能。

图2-服务台服务流程闭环
因此,在实践中理解服务台概念,我们可以将注意力更多地放在流程上。摆脱岗位的局限,从流程入手对服务台进行必要的再认识。认识到服务台是服务支持流程的第一个环节,服务台人员按岗位职责承担责任,在确保本环节工作的基础上为下一个流程环节提供合乎要求的输入。流程的最终输出再次以反馈的形式返回到服务台,完成一个事件受理、调派、维护、跟踪、反馈的闭环。
话题再回到服务台做事件主人这件事情上。之所以选择服务台作为事件的主人,无非是看中了服务台在服务流程闭环中所处的极具价值的战略位置:既是起点,又是终点。所有的事件都是经过服务台进入到服务支持流程,如果按照以往的职能岗位来理解服务台,那么如何确保进入服务支持流程的事件能够得到最及时的解决常常是令我们头大的难题。因为职能岗位的设置不同,大家关心的多是本部门或本岗位相关的这一段流程,对于脱离自己辖区的事件,只能采用“事不关己,高高挂起”的态度了。但是,如果用流程的眼光来重新审视服务台,我们发现在一个闭环的服务流程中,服务台在识别、记录、跟踪事件方面具有先天的优势,只需改变原有的认识即可将服务台的潜力大大提升。
服务台作为事件的主人,其实质就是需要我们用流程的眼光来看待服务台,改变服务台原有的职能岗位意识,使服务台主动起承担起事件的全程监控,制定呼入事件识别标准,记录呼入事件信息,跟踪呼入事件状态,反馈呼入事件进度等具体措施,确保呼入事件的可见、可控。

推荐到鲜果: 查阅更多相关主题的帖子: ITIL IT服务管理 IT治理



评论
发布者 pctcn
2007-2-1 13:42:02
发布者 ewaysun
2007-2-1 15:37:06
发布者 saralee
2007-2-1 16:42:08
发布者 Seanwhyte
2007-2-15 19:27:41
发布者 ewaysun
2007-2-15 22:11:35
发布者 Seanwhyte
2007-2-15 22:32:10
发布者 ewaysun
2007-2-16 9:11:51
发布者 saralee
2007-2-27 9:34:20
发布者 ewaysun
2007-2-27 9:35:50
哈哈~ 感谢您的关注,
说起来 这个“主人”可难当咯
我曾经一度非常迷恋国外的管理名著(说实话我也不知道是不是名著)
研究“人性的弱点”参考“管理的实践”希望做成一个“卓有成效的管理者”
这段时间又在想。 这些外人的理论,在国人中间是否真的有效呢~~~
我自己本身所处的职能位置少有些尴尬,还需要去为了达到目的去管人~
烦啊
发布者 Seanwhyte
2007-3-2 20:59:48
现实却往往让我们难办.
读了楼上几位的交谈,豁然开朗.
发布者 siraaron
2007-3-29 15:28:22
发布者 ewaysun
2007-3-29 15:37:01
特别是一些跨国企业的分支机构, 他们的IT人员(包括分析员, 主管, 网络工程师, Helpdesk人员)也就那么10来个人. 那么作为IT经理应该怎样对Helpdesk人员提供发展机会呢?
发布者 konglai
2008-2-27 22:48:40
发布者 yuzhd
2008-5-26 20:08:18
发布者 ewaysun
2008-5-26 21:12:47
“服务台成为事件的主人是否可以调整为服务台使客户成为事件的主人”,这个话比较绕。
问题在:这个事件是谁的?
这个事件的主人应该是让客户成为的么?
客户抛出事件,他就是一个第三方了。他在看这个事件的过程与结果。客户对于事件来说是一个监控者,和验收者。
服务台应该是承接“客户抛出的事件”的职责人(即主人);
那么,事件的主人无疑会落到两个部门或者可以说是人的头上:
第一:服务台(接线人)
第二:实施部门(服务工程师)
但是出于不同流程的考虑说谁是主人都有道理,但是对于服务台是主人,我个人也比较赞同,那么感觉上就是一句老话“善始善终”才是完整有序的整体(即流程)。
发布者 匿名用户
2008-6-25 10:36:52
服务台的“善始善终”是真正的伊始,服务完毕也是从这个伊始便为终结的,后续的各方面数据等也是需要从这里得到一手资料。所以服务台自然成为主人
发布者 hu_nick
2008-6-25 10:44:08
发布者 ewaysun
2008-6-25 11:36:02