什么是IT 服务台<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
读
者通过第一章生动的情景模拟，对服务台应该有了一个感性的认识。从本章起，我们将主要从理论分析的角度向读者介绍服务台的相关知识。本章主要围绕服务台的概念展开，使读者对IT 服务台有一个初步的了解，并向读者简单介绍了传统帮助台与IT 服务台的区别。
服务台在服务支持中扮演着一个极其重要的角色。完整意义上的服务台可以理解为系统应用部门和服务流程的“前台”，它可以在不需要联系特定技术人员的情况下处理大量的客户请求。对用户而言，服务台起着“应答机”和“路由器”的功能。在碰到任何问题或疑问时，只需通知和联系服务台的工作人员，再由服务台的工作人员指导和协调下一步的处理工作。
1.2.1 ITIL 简介
ITIL 是由CCTA（英国国家计算机和电信局）于20 世纪80 年代末开发的一套IT 业界的服务管理标准库,它把英国各个行业在IT 管理方面最好的方法归纳起来变成规范，旨在提高IT资源的利用效率和质量。ITIL 最初是为解决英国政府部门IT 服务质量不高的问题而开发的，但后来它很快在英国的企业中得到广泛的认同和应用。如今，这套标准已经被欧洲、美洲和澳洲的很多企业采用，目前全球已经有1 万多家知名的公司在参照ITIL 管理自己的IT 系统。
各大IT 服务厂商也都推出了基于ITIL 的服务管理解决方案。
ITIL 主要是帮助企业组织改善他们的IT 服务管理，它所提供的最佳实践方法论可以帮助IT 部门为其客户提供更高质量的IT 服务。企业根据ITIL 进行IT 管理，至少有两方面的好处。
一是业务部门可以根据一套用业务语言描述的可量化的质量指标，“理直气壮”地处理与IT 部门之间的关系；二是IT 部门也可以提高服务质量、降低服务成本、学习以前的经验并处理好和业务部门之间的关系。
1.2.2 服务台与ITIL 的关系
在ITIL 的第一版中，服务台被称为帮助台，是一个面向使用者的模块。而在ITIL 的第二版中则把它分开成服务台及事故管理。其用意在于加重一线支持的功能，在使用者第一次通报问题的时候就实时地设法把它解决，增加事故解决的比例，让IT 部门能更专注于公司业务目标的达成。
在ITIL 框架中，服务管理模块是ITIL 的核心模块。它把IT 管理活动归纳成10 个核心流程和一项管理职能。服务台就是这些活动中的一项管理职能，它与其它十大ITIL 管理流程不同，没有严格定义的执行流程。服务台是连接用户和IT 部门的一个信息交换平台，它能起到双向信息反馈的作用，并且与多个服务管理流程密切相关，为用户提供与问题、变更、服务级别、发布、配置、IT 服务持续等管理流程的接口，它还是提供高效率的IT 营运服务所不可或缺的关键环节。
上一节已简单地提到了服务台和帮助台，本节就两者的区别进行详细的描述。
帮助台与服务台两个术语在实际应用中通常可以交替使用，但两者概念的意义并不完全一样。帮助台的主要任务是记录、解决和监控IT 服务运作过程中产生的问题，主要和事故管理相关联。面向的用户主要是IT 部门内部人员。
而服务台的概念则具有更广泛的内涵，它通过提供一个集中和专职的服务联络点促进了组织业务流程与服务管理基础架构的集成。服务台适用于作为一个广泛的，集中受理的前台支持角色，而不仅仅是帮助台。服务台不仅负责处理事故、问题和客户的询问，同时还为其它活动和流程提供接口。这些活动和流程包括客户变更请求、维护合同、服务级别管理、配置管理、可用性管理和持续性管理等。面向的用户主要是IT 系统的实际使用者。
在ITIL 最佳实践理论中，传统的帮助台与服务台最主要的区别在哪里呢？
|
比较项目
|
帮助台
|
服务台
|
|
联系点
|
分散：
对用户来说，与
IT
部门打交道时，不同的问题需要找不同的人来处理，经常是不知道该找谁。
|
集中统一：
对于所有用户来说，要解决各种问题只需联系
IT
部门的一个接口人。
|
|
知识库
|
零散：
使用许多种不同类型的软件作为支持，填写需求单，查找分布零散的
FAQ
。每个不同的系统都有自己的
FAQ
，但是编写的风格不一致，用户很难准确地查找到自己需要解决问题的方法。难以形成知识库。
|
集中统一：
统一的接入界面，服务台对全部处理过的问题都要经过规范化的风格和流程进行记录，并有统一的数据库处理，因而，能够快速准确地定位需要解决的问题。
|
|
专家支持
|
缺乏：
帮助台与各系统专家交流的很少，造成帮助台无法及时为用户解决问题，各系统专家无法对系统中出现的问题进行归类总结。
|
多线支持：
服务台管理明确定义了二线和多线的后台支持，专职的服务提供者在处理各种问题中积累丰富的经验，能够快速地解决客户提出的各种问题。
|
|
解决问题的能力
|
依赖个人：
帮助台工作人员与其他技术支持组成员无法分享处理问题的一些经验和相关领域的知识。成功的帮助台完全依赖于个人的知识和经验。
缺乏重点和针对性：
对所有的提交的问题，帮助台缺乏一套规范去识别问题的影响度和紧急度。
|
团队协作：
服务支持处理问题的经验可导入知识库共享，使服务台尽最大可能直接解决用户的问题得以保障。
有重点，
针对性强：针对服务级别协议并结合对影响度和紧急度的评估，大大提高了解决问题的针对性。
|
|
统计和分析
|
缺乏数据，难以进行统计和分析：
由于帮助台是处于一种零散的状态，很多数据都分布在不同的个人或其他支持部门中，使得统计和分析的数据缺乏，帮助台经理很难准确地评估
IT
环境的状况对整个部门的影响。
|
数据完备，可作预测分析，提供主动服务：
综合各种服务管理流程，评估
IT
系统可能会出现的影响，在它们变成系统问题之前及早排除。
|
比较项目 帮助台 服务台
1.
联系点
分散：
对用户来说，与
IT
部门打交道时，不同的问题需要找不同的人来处理，经常是不知道该找谁。
集中统一：
对于所有用户来说，要解决各种问题只需联系
IT
部门的一个接口人。
2.
知识库
零散：
使用许多种不同类型的软件作为支持，填写需求单，查找分布零散的
FAQ
。每个不同的系统都有自己的
FAQ
，但是编写的风格不一致，用户很难准确地查找到自己需要解决问题的方法。难以形成知识库。
集中统一：
统一的接入界面，服务台对全部处理过的问题都要经过规范化的风格和流程进行记录，并有统一的数据库处理，因而，能够快速准确地定位需要解决的问题。
3.
专家支持
缺乏：
帮助台与各系统专家交流的很少，造成帮助台无法及时为用户解决问题，各系统专家无法对系统中出现的问题进行归类总结。
多线支持：
服务台管理明确定义了二线和多线的后台支持，专职的服务提供者在处理各种问题中积累丰富的经验，能够快速地解决客户提出的各种问题。
4.
解决问题的能力
依赖个人：
帮助台工作人员与其他技术支持组成员无法分享处理问题的一些经验和相关领域的知识。成功的帮助台完全依赖于个人的知识和经验。
缺乏重点和针对性：
对所有的提交的问题，帮助台缺乏一套规范去识别问题的影响度和紧急度。
团队协作：
服务支持处理问题的经验可导入知识库共享，使服务台尽最大可能直接解决用户的问题得以保障。
有重点，
针对性强：针对服务级别协议并结合对影响度和紧急度的评估，大大提高了解决问题的针对性。
5.
统计和分析
缺乏数据，难以进行统计和分析：
由于帮助台是处于一种零散的状态，很多数据都分布在不同的个人或其他支持部门中，使得统计和分析的数据缺乏，帮助台经理很难准确地评估
IT
环境的状况对整个部门的影响。
数据完备，可作预测分析，提供主动服务：
综合各种服务管理流程，评估
IT
系统可能会出现的影响，在它们变成系统问题之前及早排除。
转载于:https://blog.51cto.com/suyyzhou/286286
368
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
