典型案例道出“服务台”的价值
引 言：作为运营管理着庞大IT系统的CIO，相信您或多或少都尝试过，或正建有IT服务台（或帮助台），然而您可能依然面临服务效率低下，用户满意度欠佳的 困扰。这其中的原因，多半就在于您的服务台并没发挥好应有的作用。下面，我们就从一个案例来看看服务台究竟应该具备哪些职能，才能真正改善服务效率、提升 用户满意度。
案例
某消费品公司，在全国40多个城市拥有销售门店，总员工数2000余人。近年来，陆续上线的ERP系统和OA系统，在提升业务效率的同时，也给IT部门的运维支持带来了极大压力。
该公司的运维整体是交给外包公司在做，但是各个城市各自为阵，北京、上海和广州三个核心城市，各配有1-2名驻场人员，其他城市则采取OnCall（服务商上门）形式。
由
于工程师被电话一叫就走，用户会经常找不到人，于是，该公司CIO决定将全国所有IT服务请求集中起来，在公司总部设立帮助台，安排3名专职接线员，负责
记录和分派从全国各地来的请求。此举最直接的目的就是保证用户不管何时来电（只要是上班时间），IT部门都有人接收请求，之后进行初级线上支持，更多的则
向运维人员派工。
虽然用户在寻求IT支持时变得容易了，但居高不下的运维成本却日益成为CEO都关注的问题。
服务台基本职能
针对该公司的问题，拥有十多年大型外企IT运营管理服务经验的非凡公司认为，这类型服务台，仅仅主要实现了服务台最基础职能--IT与用户间的单一联系点，而一线解决率太低，造成IT运维人员依旧疲于应付。这正是时下不少公司服务台的现状，也是运维成本居高，效率偏低的根源。
E8.ITSM认为要想改变现状，必须升级服务台。具体来说需要完善以下基本职能：
第
一、完整的服务闭环：除了记录、分派，服务台还需增加解决、升级、关闭等职能。具体来说，在解决环节，需要提供分级运维支持，形成一线（基础工程师）、二
线（资深或现场工程师或IT供应商）、三线（运维专家）体系，最大化利用运维资源。“由于大多数IT服务请求，都是较为简单的问题，因而运营服务台，需要
首先考虑提高服务台的一线解决率。”，一线无法解决的问题，再由服务台升级到二线直至三线。事件处理完毕之后，还需主动向用户通报，以正式关闭请求。
为
什么要重视一线支持？以该公司为例，北上广以外的城市，业务人员有任何请求都需IT到用户现场解决，这是一笔极大的浪费。因为事实上，很多简单的IT应用
问题，由具有一定技术知识的服务台一线工程师通过电话或远程即可解决，所以如果能将一线解决率提高，极大节省该公司的运维成本。
提高一线解决率的常规方法有：选择具有一定技术知识的人员，提供持续性培训，建立和更新知识库等。而后两者也是服务台需要具备的职能。
第
二、服务级别管理：这是指在进行服务分派时需从全局出发，分清轻重缓急。比如，服务器某个问题影响到核心销售系统，那这个问题就是高级别事件，需要立马加
以解决，而如果只是影响到个别办公室人员的日常办公，相对就没那么紧急。当两种问题同时产生时，就需优先安排力量去解决前者。而CIO要做的就是与业务部
门事先确定好这样的服务级别，并按此安排调配运维资源。
这样进行服务级别管理的好处，一是，从全局管理运维需求，避免凭感觉分派，而影响解决真正重要的事件。二是，各种请求在一个相对合理的时间范围内按顺序得到解决，能更好平衡成本和收益。三是，运维有理有据，减少用户投诉。
第三、服务台运行数据报表：这包括服务台的呼损率、处理时长、一线解决率等，有了这些数据统计报表，CIO就能从中发现服务台运营中的问题，不断改进，从而提升服务效率和客户满意度。
变被动为主动--数据收集与分析
除
了服务台本身的运营数据外，整体运维数据的收集则是变被动运维为主动预防的前提。如果不收集数据，CIO就无法知道哪类服务需求比较多，哪类事件比较多。
（服务需求一般分为故障、请求、咨询、新需求、投诉，事件类型一般又分为软件、硬件、网络、数据库、业务等。）而有了这些数据，CIO就能分析这些现象背
后的原因，找到解决办法，提前加以改进，更主动支持业务。
“举例来说，通过分析一段时间的运营数据报表，发现某系统的服务器连接故障较为集中，那么我们就会建议客户拆分现有服务器使用用户，或增加、升级硬件等，通过类似措施，主动减少故障发生量，从而降低运维工作量。”
同时指出，数据分析和改进建议需要有相配套的工具和专业人员：
1.实时的服务台管理工具。通过自动化、可视化、可管理化工具收集服务数据，便于服务台管理人员实时管理，快速生成服务报告，节省管理时间和成本，提高管理效率。
2.经验丰富的服务台专家团队。如果光有数据收集，没有经验丰富的人来分析，并给出正确解决方案，数据收集就会沦为形式，主动改进也就无从谈起。
服务台价值
最后在总结服务台价值时：“完善的服务台，不仅能量化IT服务，让企业CEO看到IT投资的价值，还能随业务而变，更快更及时的优化IT系统。
