服务台设计方案案例参考材料.doc

服务台概述 服务台的一大优势表现为，它是目标客户与技术服务专家进行联络的单一接合点。它为世界各地的繁忙人群提供了一个快捷有效的解决方案，而一些不起眼的事情往往关乎企业成败。 服务台为遭遇 IT 基础架构疑难问题的客户提供了交流园地、信息资料和解决方案。困扰商务企业的某些问题可能包括： ? 缺乏现成可用的结构化客户支持机制。 ? 客户对 IT 部门缺乏信心。 ? 组织机构的规模扩张超出了支持体系的承受能力。 ? 支持资源受到严格管控。 ? 支持资源持续被琐事困扰或不断解决相同问题。 ? 支持资源根据服务中断故障排除需求进行配置。 ? 过度依赖关键技术人员。 ? IT 部门无法集中力量从事当前研发项目。 ? 发生未经协调和/或未经记录的变化。 ? 企业领导和/或工作人员无法应对所面临的改变。 ? 人力资源和成本控制需求不明确。 ? 求助响应质量和响应时间缺乏连贯性。 ? 缺乏基本决策管理信息。 定义支持过程（包括定义角色与职责）并对用户支持途径加以整合有助于克服上述问题，并提高企业获得成功的机率。 目的与目标 明确界定服务台的用途和目标并将其记录在案具有至关重要的意义。编制任务说明或明确界定支持提供途径属于实现上述目标的一种方法。 在计划阶段及早明确项目意图可确保全体团队成员围绕公司既定目标开展密切协同。考虑到企业希望通过服务台提供的服务类型各不相同，因此，上述目标可能取决于组织机构规模和服务台既定职能范畴等众多因素。现举例说明某些服务目标： ? 在用户与 IT 部门之间提供单一、集中联络点。 ? 为用户提供通往其它服务管理职能（如变更管理、问题管理、配置管理和发布管理等）的切入点。 ? 提交实现业务目标所需高质量支持服务。 ? 辨别并压缩 IT 服务总体拥有成本（TCO）。 ? 跨越业务、技术和过程界限为变更提供支持。 ? 提高客户满意程度。 ? 保持客户忠实度。 ? 发现更多商业机遇。 关键定义 下面是服务台管理职能涉及的关键术语。 ? 呼叫。 呼叫是由客户通过一切通信手段（包括电话、电子邮件、语音邮件等）向服务台发出的联络信息。 ? 事故。事故指不属于标准服务运转范畴并可能导致服务中断或服务质量下降的事件。 ? 重大事故。重大事故指具有严重影响或可能导致严重影响的事故，通常需要采取超出一般事故的应对措施。重大事故往往在企业间协作、管理升级、资源机动和联络改进等方面提出更高要求。 ? 服务请求。服务请求是针对新增或变更服务提出的调用需求。不同组织机构可能提出不同类型的服务请求，但常规服务请求无外乎变更请求（RFC）、信息请求（RFI）和服务扩展等。 ? 问题。 问题是导致一或多次事故却未经查明的根源。 ? 已知错误。已知错误是指已查明根源并找到权宜之计或永久替代方案的事故或问题。业务问题一旦出现，变更请求（RFC）就会产生，但它无论如何都属于已知错误——除非已被某项变更修复。 ? 应对方案。 应对方案是为确保常规服务得到恢复而对特定事故加以排除的已知手段；当然，这种手段将首先解决引发事故的问题。 ? 解决方案/永久性修复。 解决方案/永久性修复是能够从根本上杜绝某种特定事故或问题的已知手段。 ? 一线支持团队。一线支持团队是直接提供事故与服务请求受理支持的专门团队。一线支持团队负责在与客户进行联络的第一时间通过辨别已知应对方案、使用诊断脚本或运用自身知识等手段尝试排除事故。服务台在大量组织机构中充当着一线支持团队。 ? 解决方案小组。解决方案小组是负责对一线支持团队无法应付的事故和服务请求加以处置的专家团队。不同机构具有不同的支持团队组织架构，其中一些采取层次化架构（包括第一层、第二层和第三层……），而另一些则组建面向平台或应用的专门团队（如主机团队、桌面团队、网络团队和数据库团队等）。 服务台结构 我们可通过多种方式在组织机构范围内营造服务台。我们必须在项目计划阶段内确定所需运用的服务台结构。（其它相关文档将详细描述服务台构造方法；鉴于后文中的某些过程设计考量取决于所选结构，因此，我们将对服务台构造做简单介绍。） 表1 服务台结构 服务台类型 要求 工具 优势 集中式 集中式服务台可为广泛分布在不同地理位置的全体企业用户提供支持。 清晰的组织领导脉络和紧密衔接的伺服任务。 注意： 集中式服务台仍需得到解决方案小组的技术支持，而后者则可能处于分散状态且/或与用户同处一地。 允许用户通过单键拨号呼叫服务台的电话系统。 这种工具包括用来接听拨入电话的交互式语音应答（IVR）、自动呼叫分配（ACD）和计算机—电话集成（CTI）等应用技术。 专供服务台接收电子邮件求助呼叫并发送应答信息的电子邮件帐户。 针对服务台操作流程（呼叫记录、监控和报告等）支持工具的访问调用权限。这