论文部分内容阅读
摘 要：服务台发挥服务职能，知识库提高服务效率。服务台和知识库是IT服务管理的基本要素。
关键词：服务台；知识库知识；自助服务；知识管理
中图分类号：G467 文献标识码：B 文章编号：1673-8454(2011)17-0057-03
一、前言
在ISO20000体系的认识和实践过程中，起初我们建立的是“流程 工具”的概念，认为有了流程和技术支持工具，我们就有了对服务和运行维护的源头、过程和结果的全面掌控，也就有了可管理的能力。于是，我们首先选择了一个流程和界面可以灵活配置、可以集成LDAP认证和短息通知的技术支持工具，建立了基于用户和基于服务支持人员的两个支撑平台，并依托平台建立了事件管理、问题管理、配置管理、变更管理等13个管理流程。但是，如何推动流程运行？如何提高服务的效率？
于是，我们建立了服务台和知识库。一是让服务台发挥服务职能，统一受理、过程跟踪、有效反馈，推动流程的运行。二是在组织机构层面上协调保障流程的运行，通过建立流程执行的规范准则以及服务相关的报告制度和审核机制，保障员工参与和执行流程。三是通过建立知识库，在用户和支持人员两个层面建立一条可以自助服务和自主学习的渠道，为员工建立一个体系意识、操作方案和专业技能的培训平台和信息共享的平台，从而提高服务的效率。
二、服务台
1．服务台职能
服务台不是一个服务管理过程，而是一种服务职能。与服务管理流程不同，它没有标准化的处理流程，只是针对用户的请求或根据服务级别协议的要求进行包括响应服务请求、发布服务信息、用户关系管理、供应商联络、基础架构监控等活动。
我们把服务台理解为两个层次：第一层次是帮助台，主要任务是记录、解决和监控，主要和事件管理关联。第二层才是真正意义上的服务台，它是IT服务支持管理中心，不仅负责处理事故、服务请求、投诉等，还负责协调服务、调动资源和评估质量。同时还为其他活动和流程提供接口。它是内部服务支持流程的纽带，是与用户的连接点。现实中，帮助台和服务台在职能上越来越融合在一起。即便是第二层意义上的服务台，也还可以细化为技能型服务台和专家型服务台，区别就在于只是根据文档化的解决方案处理大量繁琐事件还是能够独立解决大部分突发性事件和重大事件。
根据服务台的结构和目标，服务台的人力资源、技术装备以及管理职能的设置也不尽相同。我们当前所建立的服务台应该还处在第一层次，没有专门的技术工具作为支撑。职能定位：让服务台在我们服务支持过程中扮演服务入口和出口的角色。管理归属用户服务室。
在服务台的职能规划中重点强调：统一入口、唯一接点，支持并监控服务级别目标的完成。
在功能设计上涵盖：（1）受理所有与IT服务相关的请求包括投诉和建议；（2）在不需要联系特定技术人员的情况下处理大量咨询、查询类的服务请求；（3）事件的初步判断并分派或报告；（4）跟踪处理结果、关闭事件；（5）用户方满意度评价和回访；（6）部分运行监控；（7）解决网络接入层故障；（8）支持网络的建设和运行维护。
服务台流程的主线是：（1）接受用户的事件申告，对事件进行确认；（2）登记事件信息，对事件进行分级和分类；（3）对职责内的事件进行处理；（4）将事件正确分派给一线或二线支持组；（5）跟踪事件的处理过程，对违反SLA的事件进行升级；（6）对已解决的事件回访，并确定关闭事件；（7）与用户沟通的话术设计与改进；（8）与用户沟通的渠道的管理。
服务台的预期设计目标是：连接我们与用户的纽带，服务支持的调度台，服务资源的控制台、服务质量的评估台、运行维护的监控台。
2．服务台职能的边界确立
从服务台的职能上不难看出，它既展现服务又调控服务，既是服务的指挥官，又是事件的执行人，也是服务过程监督者，还是服务供需多方的连接环。在其职能边界定位上，是让服务台偏重于成为强大的指挥官，建立明晰的多层级服务管理，还是偏重于全面的执行力，建立庞大的执行团队？
我们的服务类型比较多，服务层次多。例如，事件的范围也不仅局限在网络故障，而是包括校园网络、应用软件、服务器主机和运行管理系统在内的多个业务系统的运行故障，服务请求更涵盖了所有业务职能中的业务办理。如果更强调管理和调度指挥职能，那么面对服务类型和层次的繁多，服务台内部无需建立细致的分组机制，无需深入到具体的服务处理层面，只需简单地判断和记录事件，起到初步的支持作用，建立庞大的后续支持团队，职能层次和职能划分更加明晰，服务台更多关注服务过程的到位、效率，关注服务级别协议的符合，关注与用户的沟通关系、关注服务反馈以及服务考核。如果更强调执行力，那么服务台就要建立庞大的运行和维护的支持团队，拥有深入的支持能力，这样可以快速执行事件的处理，无需更多的责任划分，无需更多过程的管控，更容易建立落实首问负责制。
但是，强大的管理能力和强大的执行能力之间存在着不可调和的矛盾。管理能力过分强大，服务台不够深入，可能会在用户和支持人员之间遭遇双重指责，用户指责服务台解决不了问题，层层转派，没有效率。支持人员指责服务台所有简单事件都下派，甚至不能理解事件，不能准确记录事件，时常错派事件。执行力过分强大时，服务参与深入，服务过程出自同一个体，谁去落实效率？谁去监督服务过程？不仅会让服务台陷入流程的瓶颈，还会陷入既当裁判又当球员的怪圈。要减少矛盾冲突，减少推诿指责，提高效率和质量，就要在管理能力和执行能力之间寻找平衡点。我们的做法是在服务台中建立简单的分组层级，受理事件同时兼并一部分一线支持职能，做到适度的专业化，能够减少递转，高效响应和处理简单事件。适当简化支持层级，让二线支持高度专业化，分工明细，主要完成审核人物，处理复杂事件，让主管领导协调第三方支持，参与处理重大事件。这样，服务台可以监控服务过程，督促落实，沟通用户。同时，由中心办公室监控投诉事件的处理过程和结果，由中心评价委员会实施事件管理的绩效考核。 这样，在一定程度上兼顾了效率、管理、监督和质量。
另外，服务台在受理服务请求时，需要快速了解用户需求，这不是依靠服务台所拥有的专业知识可以完成的，而是依靠服务台训练有素，掌握一套成熟的“话术”。“话术”顾名思义是指说话的艺术，或者是说话的技巧。因此，良好的话术设计有助于平和用户抱怨，有助于更有效率地处理服务请求。同时，建立一个完备的用户数据库，一个带有菜单功能的语音系统，会在技术层面为服务台提高受理效率、沟通用户、展开智能分析开拓主动服务起到帮助作用。
三、知识库
1．知识库的作用
问题管理是一个主动流程。在事件管理中可以解决职责、流程的问题，却不能解决能力和效率问题。在问题管理流程中，通过调查、分析将问题变成了已知错误。知识库是已知错误和解决方案的集合。
知识库的主要作用就是实现知识共享、知识转化，避免知识流失，提高运维和服务的响应速度和质量。
人们常常会将知识库理解为用于对人员的技能或知识的培训，或者是用于用户的自服务。这样的理解是将知识库的概念引申，还是对知识库概念理解不准确，我们至今不能确定。我们在建立知识库的过程中，也存在对知识库的理解困惑。一方面定位于辅助事件处理的已知错误和解决方案集合，一方面也定位于用户自服务。通过角色权限划分进行内容访问控制。
现实中， IT运维和服务团队的人员流动大，长时间的新员工培训也不可行，支持人员处理事件的能力又是从工作中锻炼和积累的。新员工要快速学习和成长，独立应对事件，就需要系统的指导和团队的分享，知识库往往在这个方面发挥作用。基于我们高校的用户特点，年轻、素质高，接受能力强，知识库同时又可以在自主学习和自助服务方面发挥作用。
不容乐观的是，现实中的知识库，很容易变成杂货铺甚至垃圾库，亦或是空壳子。管理不严谨不科学，随意将什么都当做知识放进去，不仅不能指导事件的处理，还可能造成误导酿成更大的事件。不仅不能自助服务和自主学习，反而会以讹传讹。分类和管理的粗糙和混乱，使知识的学习过程变得艰苦和无助，也起不到积极的作用。我们的做法是：通过权限和角色控制，将知识库分为面向用户的公共知识库和面向支持人员的私有知识库。将定义已知错误和提交知识库的过程作了“一级审批”的过程控制，避免定义的不准确或者泛滥，在一定程度上对内容进行管控。至于科学的分类以及建立，或许还很有必要借助专业的力量进行帮助。同时，如何让支持人员主动地发现问题，共享知识，避免知识库成为空壳子也是值得探讨的问题。
2．知识库的建立
毋庸置疑，知识库会给IT运行维护、服务管理带来效率和质量。要建设好的知识库却并非易事。依照现实，笔者非常赞成建立一个能够快速查找、方便使用的简单实用的知识库的观点。
（1）知识库模式
如果知识库能够自动分析提交事件的标题，查找统计，分析可能最贴近的方案并推荐给支持人员，这将大大节省支持人员的时间。退一步，即便是需要支持人员来手动搜索，建立一个内置的知识库也比需要跳转查询的外置知识库效率更高。
（2）知识的分类分级
科学的分类分级不仅可以使知识库简明易用，还可以对内容进行比较完善的访问、添加和更新的权限和角色控制。
（3）知识内容的界定
知识的抽取步骤为：提交→分派→审批→发布。图中的用户是指知识库的用户。
不管理论上对于知识和知识库如何定义，根据自身现实，首先要具体界定知识库所包含的内容范围，其次具体界定什么样的已知问题才能作为知识提交到知识库中，避免知识库成为杂货铺。
（4）知识的管理
知识来自各个环节、各个部门、各个时期。对知识库的管理主要是两个方面，一是知识的动态更新管理，二是知识内容和分类管理。设立专门的知识管理员非常必要。至于知识库管理员需要什么样的专业技能，需要多大程度的管理权力，如何监督和考核知识库管理员的工作，我还需要更深入的探讨。
四、结束语
服务台是服务职能的体现，它扮演了多重角色：受理所有用户的“响应台”和“记录台”，以知识库为基础的“应答台”，事件的“过滤台”和“分派台”，连接用户和供应商的“连接台”，服务信息的“发布台”，服务请求的“终结台”，服务质量的“控制台”。
在ISO20000体系中，特别强调了培训，培训意识、培训技能，通过培训让员工真正融入到体系实践中，使体系产生保证服务质量和效率的作用。的确，IT服务管理的理念以及体系中的流程需要每个员工去理解、参与和执行。流程的执行是被动的，但是对流程的认识是主动的，符合流程要求也是主动的。在体系建立之后，各个业务部门从原来只管自己的业务到执行跨部门的流程，虽然流程是规范标准的，但是执行中的沟通和分享所占分额更多了。创建知识库，无疑是为了辅助处理事件、助力培训、共享信息，通过对知识的有效管理，使知识最终转化为生产力，实现服务目标。
在许多IT服务管理的解决方案中，都以建立服务台为核心，以知识库为基础，以事件管理、问题管理、变更管理和配置管理等几个核心管理流程作为配合，以服务级别协议作为依据来实现。有些简单的方案甚至只建立服务台和知识库就完成了IT服务管理的运行。因此，服务台和知识库是IT服务管理的基本要素。
参考文献：
[1]ISO/IEC20000-2:2005 Information technology-Service management[M].
[2]Jan van Bon主编,章斌译.基于ITIL的IT服务管理(基础篇)[M].北京:清华大学出版社.
[3]Gad J Selig著,中治研（北京）国际信息技术研究院译.实施IT治理[M].
[4]左天祖.ITIL白皮书[M].
（编辑：金冉）
关键词：服务台；知识库知识；自助服务；知识管理
中图分类号：G467 文献标识码：B 文章编号：1673-8454(2011)17-0057-03
一、前言
在ISO20000体系的认识和实践过程中，起初我们建立的是“流程 工具”的概念，认为有了流程和技术支持工具，我们就有了对服务和运行维护的源头、过程和结果的全面掌控，也就有了可管理的能力。于是，我们首先选择了一个流程和界面可以灵活配置、可以集成LDAP认证和短息通知的技术支持工具，建立了基于用户和基于服务支持人员的两个支撑平台，并依托平台建立了事件管理、问题管理、配置管理、变更管理等13个管理流程。但是，如何推动流程运行？如何提高服务的效率？
于是，我们建立了服务台和知识库。一是让服务台发挥服务职能，统一受理、过程跟踪、有效反馈，推动流程的运行。二是在组织机构层面上协调保障流程的运行，通过建立流程执行的规范准则以及服务相关的报告制度和审核机制，保障员工参与和执行流程。三是通过建立知识库，在用户和支持人员两个层面建立一条可以自助服务和自主学习的渠道，为员工建立一个体系意识、操作方案和专业技能的培训平台和信息共享的平台，从而提高服务的效率。
二、服务台
1．服务台职能
服务台不是一个服务管理过程，而是一种服务职能。与服务管理流程不同，它没有标准化的处理流程，只是针对用户的请求或根据服务级别协议的要求进行包括响应服务请求、发布服务信息、用户关系管理、供应商联络、基础架构监控等活动。
我们把服务台理解为两个层次：第一层次是帮助台，主要任务是记录、解决和监控，主要和事件管理关联。第二层才是真正意义上的服务台，它是IT服务支持管理中心，不仅负责处理事故、服务请求、投诉等，还负责协调服务、调动资源和评估质量。同时还为其他活动和流程提供接口。它是内部服务支持流程的纽带，是与用户的连接点。现实中，帮助台和服务台在职能上越来越融合在一起。即便是第二层意义上的服务台，也还可以细化为技能型服务台和专家型服务台，区别就在于只是根据文档化的解决方案处理大量繁琐事件还是能够独立解决大部分突发性事件和重大事件。
根据服务台的结构和目标，服务台的人力资源、技术装备以及管理职能的设置也不尽相同。我们当前所建立的服务台应该还处在第一层次，没有专门的技术工具作为支撑。职能定位：让服务台在我们服务支持过程中扮演服务入口和出口的角色。管理归属用户服务室。
在服务台的职能规划中重点强调：统一入口、唯一接点，支持并监控服务级别目标的完成。
在功能设计上涵盖：（1）受理所有与IT服务相关的请求包括投诉和建议；（2）在不需要联系特定技术人员的情况下处理大量咨询、查询类的服务请求；（3）事件的初步判断并分派或报告；（4）跟踪处理结果、关闭事件；（5）用户方满意度评价和回访；（6）部分运行监控；（7）解决网络接入层故障；（8）支持网络的建设和运行维护。
服务台流程的主线是：（1）接受用户的事件申告，对事件进行确认；（2）登记事件信息，对事件进行分级和分类；（3）对职责内的事件进行处理；（4）将事件正确分派给一线或二线支持组；（5）跟踪事件的处理过程，对违反SLA的事件进行升级；（6）对已解决的事件回访，并确定关闭事件；（7）与用户沟通的话术设计与改进；（8）与用户沟通的渠道的管理。
服务台的预期设计目标是：连接我们与用户的纽带，服务支持的调度台，服务资源的控制台、服务质量的评估台、运行维护的监控台。
2．服务台职能的边界确立
从服务台的职能上不难看出，它既展现服务又调控服务，既是服务的指挥官，又是事件的执行人，也是服务过程监督者，还是服务供需多方的连接环。在其职能边界定位上，是让服务台偏重于成为强大的指挥官，建立明晰的多层级服务管理，还是偏重于全面的执行力，建立庞大的执行团队？
我们的服务类型比较多，服务层次多。例如，事件的范围也不仅局限在网络故障，而是包括校园网络、应用软件、服务器主机和运行管理系统在内的多个业务系统的运行故障，服务请求更涵盖了所有业务职能中的业务办理。如果更强调管理和调度指挥职能，那么面对服务类型和层次的繁多，服务台内部无需建立细致的分组机制，无需深入到具体的服务处理层面，只需简单地判断和记录事件，起到初步的支持作用，建立庞大的后续支持团队，职能层次和职能划分更加明晰，服务台更多关注服务过程的到位、效率，关注服务级别协议的符合，关注与用户的沟通关系、关注服务反馈以及服务考核。如果更强调执行力，那么服务台就要建立庞大的运行和维护的支持团队，拥有深入的支持能力，这样可以快速执行事件的处理，无需更多的责任划分，无需更多过程的管控，更容易建立落实首问负责制。
但是，强大的管理能力和强大的执行能力之间存在着不可调和的矛盾。管理能力过分强大，服务台不够深入，可能会在用户和支持人员之间遭遇双重指责，用户指责服务台解决不了问题，层层转派，没有效率。支持人员指责服务台所有简单事件都下派，甚至不能理解事件，不能准确记录事件，时常错派事件。执行力过分强大时，服务参与深入，服务过程出自同一个体，谁去落实效率？谁去监督服务过程？不仅会让服务台陷入流程的瓶颈，还会陷入既当裁判又当球员的怪圈。要减少矛盾冲突，减少推诿指责，提高效率和质量，就要在管理能力和执行能力之间寻找平衡点。我们的做法是在服务台中建立简单的分组层级，受理事件同时兼并一部分一线支持职能，做到适度的专业化，能够减少递转，高效响应和处理简单事件。适当简化支持层级，让二线支持高度专业化，分工明细，主要完成审核人物，处理复杂事件，让主管领导协调第三方支持，参与处理重大事件。这样，服务台可以监控服务过程，督促落实，沟通用户。同时，由中心办公室监控投诉事件的处理过程和结果，由中心评价委员会实施事件管理的绩效考核。 这样，在一定程度上兼顾了效率、管理、监督和质量。
另外，服务台在受理服务请求时，需要快速了解用户需求，这不是依靠服务台所拥有的专业知识可以完成的，而是依靠服务台训练有素，掌握一套成熟的“话术”。“话术”顾名思义是指说话的艺术，或者是说话的技巧。因此，良好的话术设计有助于平和用户抱怨，有助于更有效率地处理服务请求。同时，建立一个完备的用户数据库，一个带有菜单功能的语音系统，会在技术层面为服务台提高受理效率、沟通用户、展开智能分析开拓主动服务起到帮助作用。
三、知识库
1．知识库的作用
问题管理是一个主动流程。在事件管理中可以解决职责、流程的问题，却不能解决能力和效率问题。在问题管理流程中，通过调查、分析将问题变成了已知错误。知识库是已知错误和解决方案的集合。
知识库的主要作用就是实现知识共享、知识转化，避免知识流失，提高运维和服务的响应速度和质量。
人们常常会将知识库理解为用于对人员的技能或知识的培训，或者是用于用户的自服务。这样的理解是将知识库的概念引申，还是对知识库概念理解不准确，我们至今不能确定。我们在建立知识库的过程中，也存在对知识库的理解困惑。一方面定位于辅助事件处理的已知错误和解决方案集合，一方面也定位于用户自服务。通过角色权限划分进行内容访问控制。
现实中， IT运维和服务团队的人员流动大，长时间的新员工培训也不可行，支持人员处理事件的能力又是从工作中锻炼和积累的。新员工要快速学习和成长，独立应对事件，就需要系统的指导和团队的分享，知识库往往在这个方面发挥作用。基于我们高校的用户特点，年轻、素质高，接受能力强，知识库同时又可以在自主学习和自助服务方面发挥作用。
不容乐观的是，现实中的知识库，很容易变成杂货铺甚至垃圾库，亦或是空壳子。管理不严谨不科学，随意将什么都当做知识放进去，不仅不能指导事件的处理，还可能造成误导酿成更大的事件。不仅不能自助服务和自主学习，反而会以讹传讹。分类和管理的粗糙和混乱，使知识的学习过程变得艰苦和无助，也起不到积极的作用。我们的做法是：通过权限和角色控制，将知识库分为面向用户的公共知识库和面向支持人员的私有知识库。将定义已知错误和提交知识库的过程作了“一级审批”的过程控制，避免定义的不准确或者泛滥，在一定程度上对内容进行管控。至于科学的分类以及建立，或许还很有必要借助专业的力量进行帮助。同时，如何让支持人员主动地发现问题，共享知识，避免知识库成为空壳子也是值得探讨的问题。
2．知识库的建立
毋庸置疑，知识库会给IT运行维护、服务管理带来效率和质量。要建设好的知识库却并非易事。依照现实，笔者非常赞成建立一个能够快速查找、方便使用的简单实用的知识库的观点。
（1）知识库模式
如果知识库能够自动分析提交事件的标题，查找统计，分析可能最贴近的方案并推荐给支持人员，这将大大节省支持人员的时间。退一步，即便是需要支持人员来手动搜索，建立一个内置的知识库也比需要跳转查询的外置知识库效率更高。
（2）知识的分类分级
科学的分类分级不仅可以使知识库简明易用，还可以对内容进行比较完善的访问、添加和更新的权限和角色控制。
（3）知识内容的界定
知识的抽取步骤为：提交→分派→审批→发布。图中的用户是指知识库的用户。
不管理论上对于知识和知识库如何定义，根据自身现实，首先要具体界定知识库所包含的内容范围，其次具体界定什么样的已知问题才能作为知识提交到知识库中，避免知识库成为杂货铺。
（4）知识的管理
知识来自各个环节、各个部门、各个时期。对知识库的管理主要是两个方面，一是知识的动态更新管理，二是知识内容和分类管理。设立专门的知识管理员非常必要。至于知识库管理员需要什么样的专业技能，需要多大程度的管理权力，如何监督和考核知识库管理员的工作，我还需要更深入的探讨。
四、结束语
服务台是服务职能的体现，它扮演了多重角色：受理所有用户的“响应台”和“记录台”，以知识库为基础的“应答台”，事件的“过滤台”和“分派台”，连接用户和供应商的“连接台”，服务信息的“发布台”，服务请求的“终结台”，服务质量的“控制台”。
在ISO20000体系中，特别强调了培训，培训意识、培训技能，通过培训让员工真正融入到体系实践中，使体系产生保证服务质量和效率的作用。的确，IT服务管理的理念以及体系中的流程需要每个员工去理解、参与和执行。流程的执行是被动的，但是对流程的认识是主动的，符合流程要求也是主动的。在体系建立之后，各个业务部门从原来只管自己的业务到执行跨部门的流程，虽然流程是规范标准的，但是执行中的沟通和分享所占分额更多了。创建知识库，无疑是为了辅助处理事件、助力培训、共享信息，通过对知识的有效管理，使知识最终转化为生产力，实现服务目标。
在许多IT服务管理的解决方案中，都以建立服务台为核心，以知识库为基础，以事件管理、问题管理、变更管理和配置管理等几个核心管理流程作为配合，以服务级别协议作为依据来实现。有些简单的方案甚至只建立服务台和知识库就完成了IT服务管理的运行。因此，服务台和知识库是IT服务管理的基本要素。
参考文献：
[1]ISO/IEC20000-2:2005 Information technology-Service management[M].
[2]Jan van Bon主编,章斌译.基于ITIL的IT服务管理(基础篇)[M].北京:清华大学出版社.
[3]Gad J Selig著,中治研（北京）国际信息技术研究院译.实施IT治理[M].
[4]左天祖.ITIL白皮书[M].
（编辑：金冉）