面壁ITIL之服务台管理实战

2007/06/19

图1－客户服务中心组织结构简图

　　关键业务是指客户服务中心的实施管理部，包含服务台、任务管理、工程师管理、两个专项维护组（含一线和二线A组）以及一个二线B组。从这一系列的岗位设置可以看出，在关键业务中客户的服务请求经历了受理、调派、维护、跟踪、反馈等多个流程环节。

ITIL理论中有关服务台的描述，我接触到两种说法：

　　一是，服务台通常所指是帮助台和呼叫中心，强调的是服务职能，而非服务管理流程。没有严格有序的日常运作流程，只是针对用户的请求或根据服务级别协议的要求进行一些日常运作活动。包括：响应用户呼叫、为用户发布信息、客户需求管理和客户关系管理、供应商联络、日常运作管理、基础架构监控等。

　　二是，服务台是以客户为中心，并由技术专家、业务骨干以及协调能力强的人员构成。在客户与IT服务提供者之间建立了一个集中的单一联系点，不仅处理事件和问题，而且还为其它活动（变更请求、维护合同、配置管理等）提供联系的纽带。

　　由以上的两点描述，可以看出前者强调服务台是一个职能部门，至于究竟是帮助台，还是呼叫中心，不必过于细究；后者则强调服务台是一个服务流程的起点，对外的单一接触点。

　　现阶段客户服务中心关键业务中服务台更像是前者，但从整体的服务结构来看，关键业务提供的服务又和后者非常相像。基于流程管理的理念，我个人更倾向于后者的说法。因为以职能划分的IT服务存在一个弊端，那就是往往会产生局部最优的结果。在这种情况下，很少人会从整体的服务流程上去考虑本部门或本岗位的做法将会给流程整体最优带来的影响。

　　当思想从具体的职能岗位中突围，我认识到：服务台是面向客户的，以服务台为起点和终点的事件服务流程闭环（见图2）。也许是服务台这个极具职能意味的称谓混淆了我的理解，一直未能突破职能岗位的框框，也因此一直无法更深入地理解服务台，理解服务台的功能。

图2－服务台服务流程闭环

　　因此，在实践中理解服务台概念，我们可以将注意力更多地放在流程上。摆脱岗位的局限，从流程入手对服务台进行必要的再认识。认识到服务台是服务支持流程的第一个环节，服务台人员按岗位职责承担责任，在确保本环节工作的基础上为下一个流程环节提供合乎要求的输入。流程的最终输出再次以反馈的形式返回到服务台，完成一个事件受理、调派、维护、跟踪、反馈的闭环。

　　话题再回到服务台做事件主人这件事情上。之所以选择服务台作为事件的主人，无非是看中了服务台在服务流程闭环中所处的极具价值的战略位置：既是起点，又是终点。所有的事件都是经过服务台进入到服务支持流程，如果按照以往的职能岗位来理解服务台，那么如何确保进入服务支持流程的事件能够得到最及时的解决常常是令我们头大的难题。因为职能岗位的设置不同，大家关心的多是本部门或本岗位相关的这一段流程，对于脱离自己辖区的事件，只能采用“事不关己，高高挂起”的态度了。但是，如果用流程的眼光来重新审视服务台，我们发现在一个闭环的服务流程中，服务台在识别、记录、跟踪事件方面具有先天的优势，只需改变原有的认识即可将服务台的潜力大大提升。

　　服务台作为事件的主人，其实质就是需要我们用流程的眼光来看待服务台，改变服务台原有的职能岗位意识，使服务台主动起承担起事件的全程监控，制定呼入事件识别标准，记录呼入事件信息，跟踪呼入事件状态,反馈呼入事件进度等具体措施，确保呼入事件的可见、可控。

畅想网博客