服务台定位.docxVIP

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