3、服务台建设
服务台建设(1)平常心是道
佛家禅语
“春有百花秋有月，夏有凉风冬有雪。若无闲事心头挂，便是人间好时节。”这是宋朝无门慧开的作品，意即“平常心是道”。
记录下这句佛家禅语 , 是因为服务实在是个难做的事情,好与坏的评价对于服务台来说,不是“一时”而是 “一世”哈,开个玩笑。
但一件小事情如果因为处理不得当有可能会造成坏的影响。因此提供服务的人应该保持良好的心态，既要追求好的服务目标，也要“平常心是道”。
ITIL中将服务台(SERVICE DESK)作为一个职能，独立于服务支持（SERVICE SUPPORT）的流程管理模块之外,因此这一章将系统介绍作者所在企业的服务台建设情况，内容包括技术架构设计＼组织架构设计＼服务台模式设计，另外还包含服务级别管理（SERVICE
LEVEL MANAGEMENT SLA）的设计内容．
服务台建设(2)建立服务级别协议SLA
在讨论服务台的服务请求管理的时候，老外专家建议我们应该先建立标准的SLA(Service Level
Agreement服务级别管理协议).他问：你们有SLA吗？
我想了想答道：在工作中曾经制定过《IT服务管理流程规范》下发到各个营业单位，内容包括 IT服务项目列表、服务时限和服务要求、支持方式等内容，但和标准的SLA
是有差距的。他说GOOD,这就是SLA.
哦， 原来在我还不知道什么是SLA的时候，它就早已经落地了。但是我们规范服务台的目标是建立一个标准的SLA,因此还是温习一下相关的定义与概念，以下内容来自
服务级别管理（Service Level Management)。
概念与定义
- 服务级别协议（SLA）
- 由IT部门和客户之间签订的描述将要提供的一项或多项服务的一份协议；
- 用非技术语言进行描述；
- 在协议期间它可作为评价和调整IT服务的标准。
- 运营级别协议（OLA）
- 与IT部门内部某个具体的职能或岗位就某项IT服务所签订的协议；
- 支持IT部门提供各种服务；
- 是对SLA的细化。
- 支持合同（UC）
- 与外部提供商就某项服务的供应所签订的合同；
- 通常是正式的合同，而SLA和OLAs通常不是法律文本。
当初准备ITIL SM考试的时候，感觉理解这几个英文名词有些困难。但在实际的服务台工作中几乎天天都会打个照面。
SLM是在服务台搭建之前进行的规划活动，总结企业内进行SLM相关的活动内容如下：
1.识别和采集客户需求，可以应用VOC（客户之声）流程进行信息采集。
2.定义 服务级别需求（SLR）o
3.制定协议约定。主要关于
a.根据客户需求结合科技支持部门的能力制定服务目录（Service Catalogue）列表，
b.签订服务级别协议（Service level Agreement）
c.与外包的支持公司签订 支持合同 Underpinning Contract (s)
d.与内部的技术支持部门签署 （Operational Level Requirements ）
4.制定服务质量计划。以上的内容都综合记录在一份文档中。
5.定期生成 服务水平报告，我们是每月编写一份。
6.管理层会根据SLA进行监控并定期评审，最终制定改进措施--- 服务改进计划Service Improvement
Program.
在具体实施时不难看出，SLM管理的目标是通过制定相关协议、监控服务绩效、定期评审并报告的不断循环进行的，最终目标是实现企业服务质量的提升，这同样也是一个PDCA的正向循环的过程。
服务台建设(3)模式选择
ITIL理论中，根据不同的业务需要，服务台的模式有分布式服务台、集中式服务台和虚拟式服务台三种模式可供参考选择。我们来温习一下：
（引用了Chuancy总结的提纲，在此感谢）
1、集中式服务台：在集中式服务台模式下，所有用户呼叫由一个物理上集中的服务台统一接收和记录。用户呼叫被区分为技术或业务应用相关的呼叫。根据服务台处理这两类请求的方式（物理上单一的一个实体统一处理两类呼叫或集中的两个不同的实体分别对呼叫进行处理），集中式服务台又进一步被区分为两类：
功能集成－集中式服务台：在一个功能集成－集中式服务台环境下，业务运营支持台与集中服务台合二为一，为用户提供单一的联系点。
功能分离－集中式服务台：当IT组织只提供信息系统给用户，但不支持信息系统的运营，该组织被认为构建了功能分离－集中式服务台。在这种服务台环境下，集中服务台和业务运营支持台是两个独立的实体。用户对业务应用的服务呼叫可以直接向业务运营支持台寻求迅速和有效的支持反馈。
为了迅速解决用户请求，服务台可以直接联系运营相关的部门，如生产或运营部。服务台和运营相关部门的连接点被称为运营桥。
2、分布式服务台：在分布式服务台结构中，多个服务台分布在不同的地点以支持具有不同文化背景的本地用户使用。然而，由于多个服务台分布在不同的地点，要管理分布式服务台非常困难。
若按与用户的联系点来区分，分布式服务台有三种不同的类型：
中心联系点：中心联系点类型的分布式服务台由一个中心联系点接收所有用户的呼叫请求，然后将这些请求分配给合适的本地服务台进行处理。中心联系点也记录用户报告的事件（任何不符合标准操作且引起或可能引起服务中断和服务质量下降的事件。）
。
本地联系点：本地联系点(LPC，Local Point of Contact)从特定的本地用户处接收请求和抱怨。不同的LPC处理各自的用户呼叫请求。所有LPC与一个中心联系点进行交互，中心联系点负责汇总事件信息。
LPCs具有以下功能：
用本地化的语言服务本地用户
作为成本中心分摊IT支持成本
呼叫中心：呼叫中心式的分布式服务台为用户提供一个中心电话号码（如1860）来响应用户的呼叫请求。当用户向呼叫中心提交呼叫请求时，语音菜单启动，菜单让用户选择特定的服务。基于用户的请求，呼叫自动流转到特定的支持团队。
3、虚拟服务台：虚拟式服务台利用远程通讯技术整合分布各地的服务台网络。如，整合遍布世界不同时区的服务台能为用户提供24小时的服务。由于各地服务台相互交错，功能就像一个单一实体，用户并不知道服务台的具体位置。但是，这种服务台模式不能为用户提供现场支持服务。
老外专家介绍他们所在的企业采用的是集中式的服务台， 包括SERVICE DESK和CALL CENTER
都采用这种模式，当然这种构建模式的基础是与企业的组织架构密切相关的，而中国的企业一般采用总分体制的组织架构，因此我们的服务台选择的是物理集中-逻辑分布的服务台模式。
物理集中
a.全国共用一套放在集团总部的平台系统，共用一个数据库。
逻辑分布
b.各个省份分布着独立运转的服务台组织，需要垮地域处理的事情，才会流转至集团总部的总服务台（即中心联系点）进行协调转派。
c.一个省内还会有多个城市，每个城市的也组建了虚拟的服务台组织（即本地联系点），负责所辖区域的技术支持服务工作，他们是真正的一线人员。
从全国范围看集团企业的服务台，整体采用的是分级分流的处理模式，这种物理集中-逻辑分布模式大大提高了事件和服务请求的处理效率。同时由于数据库在总部，又便于集中监控整个企业的服务台信息数据、也便于统一规范流程，可以说是一举两得的事情，因此这种模式在实践中被证明是一种较为成功的服务台组织管理模式。
服务台建设(4)集成的架构设计
接入渠道
在企业内部进行全面地统一规范流程管理后，制度规定服务台(SERVICE DESK)的事件故障、服务请求的接入渠道只能有以下三种形式：
a. WEB 页面登陆：一般的请求信息
b. 呼叫中心接入：紧急的请求事件
c. 监控系统 ：报警事件的自动接入
因此需要服务台集成呼叫中心和监控系统，接入这两个系统过来的事件请求单。
通知方式
服务台(SERVICE DESK)可以通过以下三种的通知方式将信息发送给支持人员和用户：
a. 企业内部邮件
b. 短信
c. 呼叫中心外呼
公告方式
服务台(SERVICE DESK)可以通过以下三种的方式将公告内容发送给支持人员和用户：
a. 服务台网站公告栏
b. 短信
c. 呼叫中心的语音导航提示
集成后的逻辑架构
服务台建设(5)意识宣传与关键人沟通
集中式服务台构建的是单一联系点（single point of contact），那么建设服务台后会直接影响哪些人的行为习惯呢？答案一个是用户，另外一个会影响到的是运维支持人员的工作模式。
用户：
弊-->
常有用户抱怨说用了服务台后，却发现比以前更加麻烦了，没有服务台的时候，当部门的电脑出现问题了，只需要给管设备维修的小A
打个电话，小A叫随到立即开始处理。但是现在不能直接打电话了，需要登陆服务台录事件单，而到最后等待有人来处理问题直到解决问题，中间有可能要经过多个环节。
运维支持人员：
弊-->
以前干完活就可以走人，现在不但要登陆SERVICE DESK平台将处理过程录入进去，还要被动等待被服务对象的满意度评价,
真是自找麻烦、自捆手脚。
万事开头难，对于新的事物，特别是管理制度方面的变动，人们在没有看到立竿见影的好处时总是习惯用怀疑的眼光看待一切变动，放大管理变动对于自己习惯所带来的不利影响。于是组织中一般会产生一种消极抵触的情绪。
因此在西方管理的战术活动中出现了AwarenessCampaign这样一个名词， 这也是老外专家在
项目启动计划时经常出现的活动之一，中文直接翻译过来是“宣传运动”。偏左了宏观放大地说是“整风运动”，偏右了微观狭隘地说就是“吹风大会"。呵呵，开个玩笑啊。（啥时候阳春白雪的ITIL也在中国这么土的落地来着。。）
吹风的目标是谁呢？当然首先是头儿了，一个是业务用户的老总，一个是负责运维的一线和二线支持的负责人，也是未来的事件经理。
| 
