Changes for page 服务管理实践 - 01 服务台

Last modified by superadmin on 2024/12/25, 15:37

From version < 26.1 >

edited by superadmin
on 2021/01/29, 22:08

To version < 18.1 >

edited by superadmin
on 2021/01/29, 21:51

< >

Change comment: 上传新附件1600930001924-317.png

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)
Attachments (0 modified, 0 added, 1 removed)
- 1600930052354-753.png

Details

Page properties

Content

@@ -38,7
          +38,6 @@
  ●对本实践的合作伙伴和供应商的考虑
--
  == 1.1 ITIL 4资格认证计划 ==
  [[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=2]]
@@ -89,7
          +89,6 @@
  服务台实践涉及服务提供商与用户沟通的所有价值流，其目的是确保这些沟通对所有相关方都是有效和便利的。
--
  == 2.2 术语和概念 ==
  [[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=4]]
@@ -116,7
          +116,6 @@
  表2.2沟通渠道的便利特性
--
  表2.2中概述的特征与常用于评估和管理信息质量的特征类似，这些特征包括可用性、可靠性、可访问性、及时性、准确性和相关性。需要注意的是，信息质量可能取决于沟通质量；其他信息特征则取决于信息源和相关方。
  多渠道通常用于服务提供者与用户之间的沟通。多渠道沟通可能很便利，但若不进行整合也会带来混乱。多渠道沟通提供无缝体验和信息流，其发展的极致即为全渠道沟通。
@@ -125,7
          +125,6 @@
  跨多个渠道的统一沟通，基于跨渠道的信息共享，提供无缝的沟通体验。
--
  === 2.2.2 服务同理心 ===
  * **定义：服务同理心**
@@ -138,7
          +138,6 @@
  服务同理心是用户满意度提升和服务提供商成功的重要因素。作为一个概念，服务同理心不仅应用于用户支持和相关服务交互的狭窄情景，它适用于所有的服务交互。
--
  === 2.2.3 用户满意度 ===
  服务台作为一种交流界面，对用户满意度、客户满意度提升和服务关系的整体成功具有重要影响。用户满意度的关键因素包括沟通渠道和互动的有效性与便利性。
@@ -151,7
          +151,6 @@
  服务台实践也用于收集关于用户满意度的信息。调查或其他满意度研究工具通常使用这种实践建立的沟通渠道。为了有效地收集这些信息，本实践的沟通渠道应该被用户认为是可信的、有效的和方便的；否则，对调查和其他沟通的反馈可能会受到影响。
--
  == 2.3 范围 ==
  [[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=5]]
@@ -174,7
          +174,6 @@
  表2.3其他实践中描述的与服务台实践相关的活动
--
  == 2.4 实践成功因素 ==
  [[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=6]]
@@ -327,7
          +327,6 @@
  表2.4 渠道示例及其挑战
--
  在大多数情况下，服务提供者使用多种渠道。重要的是确保各渠道间有效整合。沟通应是全渠道，而非多渠道。一段无缝的用户旅程，有可能在信息不丢失或损坏的情况下，在不同的渠道间切换，促进积极的用户体验。没有充分整合的多渠道沟通很可能会造成混乱并引发错误。图2.1演示了如何使用多种渠道支持用户。
  (% style="text-align:center" %)
@@ -335,12
          +335,10 @@
  图2.1多种沟通渠道
--
  在非集成的多渠道沟通中，渠道间会有信息隔阂。例如，电话问询、在移动应用程序中的预约以及与来访工程师的沟通都可能需要重新输入（重新沟通）以触发呼叫支持服务。另一方面，在全渠道沟通中，情景将不断更新，并且可重用的数据将在任何关联的地方都可用。例如，用户在同一登录账号下执行的所有浏览和咨询都会添加到情景中，支持专家都可以看到。用户支持客服和来访工程师都可以获得所有相关数据。
  换而言之，在多渠道沟通中，用户将在每条渠道开始新的旅程。在全渠道沟通中，旅程持续并在不同渠道间便利地切换。
--
  === 2.4.2 实现用户沟通与价值流的有效整合 ===
  作为服务提供商与用户双向沟通的节点，服务台实践的一个关键重点是有效地捕获、记录沟通信息并将其集成到相关的价值流中。像所有实践一样，本实践涉及多条价值流：只要服务提供商和用户之间需要沟通。
@@ -349,7
          +349,6 @@
  然而，当用户发起沟通时，并不清楚属于哪条价值流，应该触发哪项ITIL实践活动。服务台实践为所有用户问询（包括咨询、事件、服务请求、投诉和表扬）的有效分类提供沟通界面和程序。当对用户查询进行分类并确定相关的价值流和实践后，将根据各自实践的流程和程序处理查询。有时，这涉及服务台团队资源和/或信息系统。
--
  == 2.5 关键指标 ==
  [[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=7]]
@@ -376,605
          +376,16 @@
  表2.5实践成功因素的关键指标示例
--
  将度量标准正确地聚合到复杂的指标中，将使数据更容易用于价值流的持续管理以及服务台实践的定期评估和持续改进。对此没有唯一的最佳解决方案。度量标准基于组织的整体服务策略和优先级，以及实践所贡献的价值流的目标。
  ----
--= 3 价值流和流程 =
--
--== 3.1价值流贡献 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=3]]
--
--像任何其他ITIL管理实践一样，服务台实践对多条价值流有帮助。重要的是要记住，价值流从来不是由单一实践形成的。服务台实践与其他实践相结合，为客户提供高质量的服务。这种实践促成的主要价值链活动有：
--
--●契动
--
--●交付和支持。
--
--服务台实践对服务价值链的贡献如图3.1所示
--
--(% style="text-align:center" %)
--[[image:1600929812191-791.png]]
--
--图3.1 服务台实践对价值链贡献的热力图
--
--
--== 3.2过程 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=4]]
--
--每个实践可以包括一个或多个流程和活动，这是实现这一实践目的所必需的。
--
--* **定义：流程**
--
--将输入转换为输出的一组相互关联或相互作用的活动。流程接受一个或多个已定义的输入，并将其转换为已定义的输出。流程定义了操作的顺序及依赖关系。
--
--服务台活动分为三个流程：
--
--1. 用户查询处理
--1. 与用户沟通
--1. 服务台优化
--
--===   ===
--
--=== 3.2.1 用户查询处理 ===
--
--该流程确保对用户查询的捕获、验证和分类，以便进一步处理。它包括表3.1中列出的活动，并将输入转化为输出。
--
--|**关键输入**|**活动**|**关键输出**
--|用户查询|确认并记录用户的查询|记录并分类用户的查询
--|服务管理记录，例如，事件记录、变更记录、问题记录等|用户查询的验证|开始处理已分类的用户查询
--|服务配置信息、IT资产信息以及其它相关信息|对用户查询进行初步处理并启动适当的活动|
--
--表3.1 用户查询处理流程的输入、活动和输出
--
--
--图3.2 展示该流程的工作流图
--
--(% style="text-align:center" %)
--[[image:1600929854496-543.png]]
--
--图3.2 用户查询处理的工作流
--
--
--表3.2将用户查询处理过程中每个人工交互和自动化活动进行比较。
--
--|**活动**|**与服务台团队的人工交互**|**自动化自服务**
--|确认并记录用户查询|(((
--当用户出于任何原因访问服务提供者时，期望得到快速的人工响应。
--
--尽管有越来越多的替代和更有效的方法帮助用户，传统的电话支持、电子邮件和走访习惯不太可能消失。
--
--在纯技术或B2B服务交付环境中，人工交互也能使人产生同理心和安慰。
--
--除了自动化支持之外，任何抵达服务台客服的查询都应以礼貌和标准的方式满足，这样用户就可以感受到一定质量级别的服务，表明其查询受到服务提供者的欢迎。
--
--每个交互都必须记录下来（例如，在查询日志或用户查询管理和工作流工具中唯一标识）。
--
--需要设计激励机制鼓励服务台客服记录问询信息。保存的记录是服务质量的宝贵数据来源，而自动化是是实现这一点的关键。
--)))|(((
--在用户需要人工响应前，可在预处理阶段响应查询，目的是快速解决问题 。这些通常称为自服务工具。
--
--例如，当用户呼叫服务台电话号码时，可能会有一个预先录制的问候语，这是称为IVR（交互式语音应答）的自动化系统的一部分。IVR的几个更广泛的功能可以帮助呼叫者：
--
--* 提供用户呼叫原因的分类选项。这既可以自动化查询分类，又可以向调用者建议查询已知解决方案的路径
--* 发布重要通知，关于正在进行的服务暂停或即将发生的影响用户的变更
--* 提供自动化参考服务
--* 提供语音邮件功能
--* 确认来电者身份
--)))
--|验证用户查询|(((
--服务台客服可以在记录查询时执行查询验证。不同的检查适用于某些类型的查询：
--
--* 用户是否是他们声称的那个人
--* 用户及其组织是否有资格使用指定的服务。这在提供商业服务时尤其重要，因为商业服务需要收费，且容易出现欺诈
--* 呼叫的原因是否与相关服务有关；例如，是否在服务提供者的职责范围内?
--* 在处理查询过程中是否需要传达任何受保护的信息，如果需要，是否需要进行额外的呼叫者身份检查
--
--虽然数据源（如服务目录或IAM）支持这些检查，但服务台客服负责验证查询。
--)))|(((
--当使用自服务工具自动处理用户与服务提供者间的首次联系时，查询验证的某些方面将实现自动化。
--
--自动验证可以内置到用户旅程中，进行增强和定制化，并限制用户体验的可变性。
--
--例如，若用户在自服务门户中通过了授权和身份验证检查，集成的工具集可以根据服务目录匹配其记录，并根据资格、角色、地理位置、可用库存等向其提供适用的服务产品和功能。
--)))
--|对用户查询进行出初步处理并启动适当的活动|(((
--初步处理通常意味着根据对象的特征、紧急程度和处理它们可能带来的收益，对呼入队列进行排序。服务提供者对用户查询初步处理还意味着对查询进行归类，并可以对已知的查询类型使用预定义的活动序列。
--
--对一些基本的问询初步处理可以使服务台坐席在与用户的首次对话过程中就解决掉问询问题。服务台需要谨慎地平衡其处理问询和进行技术技巧沟通的能力，对于时间密集型任务更是如此。
--
--然而在通常情况下，初步处理的结果涉及到启动一个特定的价值流。
--
--因此，服务台实践需要与服务提供的其他实践紧密结合。这些实践将为服务台实践提供有关初步处理特性及其相对重要性的指导。参考//ITIL驱动利益相关者价值//，表8.4（译注：此处为笔误）给出了一个初步处理标准的示例映射，以及满足标准时触发的相关实践。
--
--最后，即使查询不需要进一步操作（例如“错误号码”的呼叫），服务台客服也必须确保在查询记录中捕获了足够的关于交互的信息，这些信息至少包括时间、持续时长和内容。
--)))|(((
--用户查询处理的自动化确保交互的公正记录。对于预估用户支持的总体需求或计算未解决呼叫的比率等基本的改进和优化活动，也是非常有用的。
--
--基于前面步骤中收集的数据，自动查询分类可以减少人工工作和在初步处理和路由查询上所花费的时间。
--
--使用自动化后，一些查询类型可在无人工交互的情况下解决（例如，分析查询的情景并向用户建议自助指南或诊断步骤），或者使用最少的人工交互解决。
--
--后一种方法的一个例子是将新应用的服务的所有查询直接路由到新服务早期支持团队。关于该服务的任何查询都将绕过服务台，直接发送到相应的团队。这确保用户的快速响应体验，并减轻了服务台团队的压力。它也相对容易实施解决方案和消除问题。
--
--可以引入更复杂的规则，根据查询的参数将查询路由到特定的解决团队。重要的是要平衡问询表单的复杂性和自动化用户界面的简单性。界面设计应该鼓励用户沟通他们的问询，以便服务提供者可捕获最大可能的需求。
--)))
--
--表3.2自动化与人工交互比较
--
--
--=== 3.2.2 与用户沟通 ===
--
--这个过程确保通过适当的渠道将各种类型的信息传达给用户。它包括表3.3所列的活动，并将输入转换成输出。
--
--|**关键输入**|**活动**|**关键输出**
--|(((
--用户沟通需求
--
--沟通的信息
--
--以前的沟通记录
--
--服务管理记录，例如事件记录、变更记录、问题记录等
--
--服务配置信息、IT资产信息及其他相关信息
--)))|(((
--识别并确认目标受众
--
--识别并确认沟通渠道
--
--信息打包
--
--信息发送
--
--收集和处理接受者的确认和反馈
--)))|(((
--沟通消息
--
--沟通报告
--)))
--
--表3.3 与用户沟通过程的输入、活动和输出
--
--
--服务提供者和用户间的所有沟通都应该包括在此过程中。与用户沟通过程的需求通常由各种实践确定。沟通通常是标准化和自动化的，例如关于事件状态变化的通知。在某些情况下，还需要使用沟通流程将异常或其他重要信息传达给不同的受众。
--
--图3.3展示该流程的工作流图。
--
--(% style="text-align:center" %)
--[[image:1600930001924-317.png]]
--
--图3.3与用户沟通过程的工作流
--
--
--表3.4概述了与先前已登记的查询相关的沟通过程活动。
--
--|**活动**|**针对之前登记的查询进行个性化沟通**|**公众沟通**
--|识别并确认目标受众|(((
--无论目标受众数量多少，服务台的每次对外交互都必须符合服务提供者所维护的一致的质量标准。
--
--问询记录的状态更新也是一种需要仔细设计的对外沟通。根据问询的性质，可以有利益相关者或服务提供者的员工等多个消息接收者。大多数情况下，用户查询管理和工作流工具将跟踪每个用户查询的接收者，服务台实践将提供此项功能设计的输入。
--)))|(((
--这可以是重大事件解决通知、与变更相关的即将到来的服务中断、年度用户满意度调查等。
--
--无论公众沟通的需求来自于哪种实践或过程，服务台实践保证沟通的标准，对传播的内容进行质量控制，并代表服务提供者组织收集反馈。
--
--服务提供者应该定义一个服务台请求公众沟通的流程。这种沟通的目标受众可以由请求者提出，但应由服务台验证。这是因为服务台最了解用户是谁，用户喜欢何种沟通风格等等。
--
--集中式用户沟通的另一个重要的文化挑战是确保服务台团队受到重视。
--)))
--|识别并确认沟通渠道|(((
--在全渠道范例中，用户应能决定服务提供者应通过哪个渠道交付信息。
--
--服务提供者可决定在SLA中包含的用户沟通需求，这时服务台客服应选择适当的渠道。
--)))|(((
--定义目标受众后，服务台必须为该受众和消息类型定义适当的沟通渠道。
--
--一般性通知等沟通可以在自助服务门户或社交媒体上以醒目形式发布。而选定的用户计算机的IT资产核查等其他沟通可能需要保证交付和反馈闭环。
--
--理想情况下，沟通渠道应通过SLA协商并确定。若非如此，服务台团队应视为最适合的沟通渠道中了解用户受众的专家。
--
--这不包括为客户和赞助商服务的营销沟通。因为这些受众和消息超出了服务台实践的目的范围。然而，服务台团队可能会参与传递此类消息。
--)))
--|信息打包|(((
--在自动化服务交付环境中，通常用一组模板生成问询记录生命周期中所有的通知类型。
--
--用户查询管理和工作流工具通常与配置和资产管理工具以及其他数据源集成在一起。应该定期验证标准问询通知模板，这样对链接数据源的变更就不会产生空白项，避免消息显得不专业。商业和大规模服务提供商尤其应该避免使用过于复杂和伪个性化的模板。
--
--问询记录生命周期更新之外的自定义人工沟通也应以公司模板的形式呈现，并清晰地说明沟通的目的、相关的查询记录和内容。一些服务提供商将企业沟通培训纳入服务台团队发展计划中；其他提供商则由服务台经理或其他管理部门批准服务台客服发起对外沟通的策略。
--)))|(((
--服务台应审查和编纂任何请求沟通的实际消息，以便更有可能以用户最了解的术语和样式沟通。
--
--例如，从用户的角度看，“WEBAPPS_SRV01因为安装核心补丁将在周六晚上暂停服务”和“这周末我们将优化系统。预计网上银行将从周六下午6点到周日下午12点无法提供服务。我们的新手机银行应用程序将照常运行。谢谢你的耐心!”相比，前者远无法让人满意。
--)))
--|信息发送|(((
--通常沟通信息是自动发出的，电子邮件最常用于用户沟通。然而，在一些规范的服务交付环境中，书面沟通或个人访问更为合适。
--
--根据用户沟通环境的不同，必须向服务台人员提供明确的指导，说明哪种交付格式适合哪种类型的用户和沟通。例如，终止与公用事业提供商服务契约的查询，需要在处理正常的问询记录的同时，通过挂号信服务的方式向客户发送最终帐户余额信息。
--)))|(((
--服务台工作人员还可以对用户的文化有第一手了解，这将使他们能够选择适当的沟通和交付方式。
--
--对于某些类型的通信可以有一个最终的批准程序，通常服务台经理或具有同等权力的角色可以以服务提供者服务台的名义发出这类消息。
--)))
--|收集和处理接收者确认和反馈|(((
--“请不要回复此邮件”可以说是一种不完美的做法，但仍广泛采用。即使消息的内容与他们有关，这一行文字也不鼓励大多数用户回复该消息。
--
--欢迎来自用户的反馈总是明智的。在全渠道范例中，用户应该能够选择任何合法及合理的渠道，尽可能方便地访问服务提供者。
--
--收集和处理反馈还伴随着对某些类型的商业沟通的法定要求，要求来自服务用户的响应以进行后续查询，例如接收者的确认或报价的接受。在这些情况下，服务台客户需要有开放式任务跟踪未回复的请求，并通过不同的沟通渠道联系用户。应该控制不成功尝试的阈值，以避免激怒用户。
--)))|(((
--每个公众沟通需要有一个明确的参考反馈渠道，用户应该使用这一渠道。这个渠道可能会返回到服务台，与特定公众沟通相关的查询必须被标识、记录和处理（可能由该沟通的发起者进行处理）。
--
--未能处理的公众沟通反馈可能会导致信誉的急剧下降和用户对来自服务提供商的公众沟通的关注。
--)))
--
--表3.4关于先前已登记的查询的沟通过程活动
--
--
--=== 3.2.3 服务台优化 ===
--
--这一流程确保从管理用户沟通中吸取经验教训，并不断改进这一实践。它包括表3.5中列出的活动，并将输入转化为输出。
--
--|**关键输入**|**活动**|**关键输出**
--|(((
--服务台绩效报告
--
--满意度调查结果
--
--技术机遇
--
--事件和服务请求报告
--)))|(((
--服务台回顾
--
--服务台优化启动
--
--服务台优化沟通
--)))|服务台优化沟通
--
--表3.5 服务台优化流程的输入、活动和输出
--
--
--图3.4展示服务台优化流程的工作流图
--
--(% style="text-align:center" %)
--[[image:1600930052354-753.png]]
--
--图3.4服务台优化过程的工作流
--
--
--表3.6概述了服务台优化过程的活动。
--
--|**活动**|**描述**
--|服务台回顾|服务台团队经理与其他相关干系人一起回顾各种输入。确定改进这一实践的机会。
--|服务台优化启动|服务台团队经理记录改进计划。计划将通过引入持续改进实践或启动变更请求进行处理。
--|服务台优化沟通|如果服务台成功地完成优化，这一事实将会传达给相关的利益相关者。这通常由服务台经理通过沟通过程完成。
--
--表3.6 服务台优化过程活动
--
------
--
--= 4 组织和人员 =
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=1]]
--
--==   ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=2]]
--
--== 4.1 角色、能力和责任 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=3]]
--
--实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定的每个实践的专家角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。记住，角色并非职位头衔。一个人可担任多个角色，一个角色也可以分配给多个人员。
--
--在流程和活动的情景中描述角色。每个角色都有一个基于表4.1所示模型的能力类型。
--
--|能力代码|能力类型（活动和技能）
--|L|**领导Leader **决策、授权、监督其他活动，提供激励和动力，并评估结果
--|A|**管理员Administrator** 分配任务并确定优先级，保存记录，持续报告，并启动基本改进
--|C|**协调者/沟通者 **协调多方，维护利益相关者之间的沟通，并开展宣传活动
--|M|**方法和技巧专家 **设计和实施工作技巧、记录步骤、流程咨询、工作分析和持续改进
--|T|**技术专家 **提供技术（IT）专业知识并执行基于专家经验的作业
--
--表4.1 能力代码和能力类型
--
--
--表4.2列出了服务台实践中可能涉及的其他角色示例，以及相关的能力类型和特定技能。
--
--|**活动**|**负责角色**|**能力类型**|**特定技能**
--|(% colspan="4" %)用户问询处理
--|确认和记录用户问询|服务台客服|CA|沟通、书写、业务、服务意识以及某一层次的技术技能
--|验证用户问询|服务台客服|CM|理解用户验证的方法
--|初步处理用户问询并启动合适的活动|服务台客服|MATC|理解需求并基于过程规则分类
--|(% colspan="4" %)与用户沟通
--|识别并确认目标受众|服务台客服|CM|理解消息和沟通需求
--|识别并确认沟通渠道|服务台客服|CTM|理解用户沟通需求
--|信息打包|服务台客服|CMT|(((
--沟通和写作技能
--
--渠道技术专长
--)))
--|信息发送|服务台经理|AMT|渠道技术专长
--|收集和处理接收者确认和反馈|(((
--服务台客服
--
--服务台经理
--)))|CMA|(((
--反馈工具
--
--技术专长
--)))
--|(% colspan="4" %)服务台优化
--|服务台回顾|服务台经理|LM|决策制定，监管其他活动，以及评价产出
--|启动服务台优化|服务台经理|MA|与持续改进过程相关的知识
--|服务台优化沟通|服务台经理|CT|沟通技巧，运用可用沟通工具的技术技巧
--
--==   ==
--
--== 4.2 组织架构和团队 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=4]]
--
--在其他实践中，组织单元根据其参与的价值流活动扮演不同的实践角色。与其他实践不同，服务台实践通常有一个专注于执行其流程的专业团队。
--
--通常，服务台团队是用户支持的第一线。除了与用户沟通之外，该团队还可以应用文档化或部分自动化的技术解决某些用户（和客户）的查询。通过知识管理工具，事件管理、问题管理、请求履行和服务级别管理等实践将这些技术的知识传递给服务台。应根据服务台实践的目的及其对服务台团队的影响，不断评估执行这些技术所产生的额外工作量。
--
--本节介绍了不同的组织模型。这些模型可以适应传统上分配给服务台团队的任务。
--
--
--=== 4.2.1 服务台组织模式 ===
--
--当服务提供商组织规模很小且致力于有限数量的服务时，服务台客服的角色可在员工之间共享。然而，这是一种与用户沟通的低效方式，随着服务和产品的不断发展会带来较大的工作量，而且单一用户交互产生的价值有限。
--
--即使是小型内部服务提供商也可以受益于专门处理用户查询的员工，在后台服务组件的技术和方法能力与最终用户服务消费相去甚远时更是如此。服务台员工，作为面向消费者的专业人士，通常有很强的沟通技巧和友好、自信的举止。他们也能在不同的任务之间快速切换，并且通常也具有一定技术能力。
--
--有几种常见的方式组建一个专门的用户交流团队，这将在4.2.1.1小节中讨论。
--
--
--**4.2.1.1 本地服务台团队**
--
--当服务台在物理上能够管理全渠道沟通时，或者说用户地理位置紧凑时，这种组织模式就能发挥作用。例如，可以为所有为客户服务的员工提供单一的办公空间，甚至可以为走访渠道提供单独团队，这时就适用本地服务台组织。
--
--这样做的优点是：
--
--1. 团队内部和服务提供商组织之间快速高效的沟通。服务台团队应尽可能物理上与其他服务提供商团队在一起，以便能够快速了解信息和变化。
--1. 易于人与人之间的接触。服务台团队创建信任，并将服务提供者呈现为可访问资源。
--
--这方面的挑战是：
--
--1. 集中式联合团队倾向于较少使用查询自动化工具。工作是透明的，人们不理解为什么查询需要被记录。同样，流程和指南也是口头传达和更新的。这可能导致缺乏对用户沟通的控制。
--1. 物理上的邻近会导致对特定个人，而非特定角色的依赖。这种风险应该通过流程控制减轻，但个人关系可能会形成“走后门式”的支持，并且在这些人离开后对服务提供造成干扰。
--
--
--**4.2.1.2 分布式服务台团队**
--
--该模型类似于本地服务台团队模型：用户群分布在多个位置，但IT和服务台团队之间仍有物理沟通渠道。用户的每个地理区域都与一个专门的服务台团队联系，每个服务台团队采用共同的沟通标准协调工作。
--
--这样做的优点是：
--
--1. 能够随着客户组织或客户数量的增长而扩展服务提供者的存在，保证了存在和沟通标准。服务行为是任何服务提供的重要组成部分；确保服务行为可见很重要，可以保持积极和合作的声誉。
--1. 对用户查询的快速反应。分布式服务台组织对用户最有益之处在于用户在所有地点的服务查询都能得到一致和快速的响应。
--
--这方面的挑战是：
--
--1. 协调和自动化。由于团队是分布式的，因此需要通过一致的协作环境理解当前组织的事态。所有团队都需要类似的、一致的培训和控制。一些服务提供商采用单一的分布式团队名册管理需求波动并减轻职责，以适应工作场所的通勤时间（例如，所有团队成员都在同一个都市圈内）。
--1. 不管如何自动协调，分布式服务台导致重复的专业知识和管理开销。一般来说，服务台工作人员处理的非沟通任务越多(处理模式化事件、IMAC请求或为用户提供支持)，团队之间的重复工作就会越多。服务提供者应该严格考查分布式服务台的价值（例如，面对面的交互），应对冗余安排造成的协调问题和共享成本。
--
--
--**4.2.1.3 虚拟服务台团队**
--
--服务台团队无法与用户在物理上协同工作时就出现了虚拟服务台团队模式。这与提供公众服务的商业服务提供商，如互联网接入提供商或用户软件供应商，尤其相关。
--
--在这种情况下，虚拟服务台团队在结构上可能类似于协同工作的本地或分布式团队，或者可能是一组使用通用用户查询管理和工作流工具在家工作的个人。
--
--虚拟服务台客服和用户之间没有物理交互，这将通过更先进的沟通渠道弥补。
--
--优点是：
--
--1. 团队压力较小（当信息技术服务不完善时，压力可能会很大）。技术屏障界限有助于创造节奏，减少双方不适当的沟通。
--1. 降低每次问询的成本。除了使用电话支持，其他大多数沟通渠道都是不连续的。每一方向另一方发送信息都有一个时间差。此外，服务台人员可以在电子邮件或在线聊天问询之间切换，但是电话对话需要服务台人员持续投入注意力。
--
--挑战是：
--
--1. 服务提供者必须承诺在工具的设计和实现方面进行广泛和持续的投资，支持各种沟通渠道和记录管理。自动化工具（在5.2节中描述）可确保客户能够快速、方便地提交查询并轻松地找到并与相关的服务提供者沟通。应向寻求真人互动的用户提供各种便利且非常容易获取的工具，如在线聊天、电子邮件或电话。服务提供商必须仔细分析每种技术的价值和成本。
--
--
--**4.2.1.4 混合式服务台组织**
--
--大多数服务提供商需在本地和虚拟组织模式间选择一个最优点。这种权衡包括几种已知的妥协：
--
--* **驻场服务** 取代冗余的服务台团队的分布式网络，服务提供商可以决定在客户现场提供有限数量的员工和服务活动，并为用户的问询提供集中的跟踪系统。驻场服务是一种安排，即少量服务台客服在营业时间出现在客户场所，处理走访查询。这些客服可以自主处理基本的最终用户任务，例如：操作系统的小故障排查、业务应用程序支持、重要公告告知、客户沟通（与用户沟通相反），甚至是小的IMAC查询，少量次要组件（键盘、电池等）的现场维护。如果问题超出了他们的专业知识，或者如果等候队列超过了该服务点的某个阈值，他们就会通过已知的途径上报问询。这些问询在中央虚拟场所管理。驻场处理的问询必须与其他问询（电话、在线等）一起记录在中央问询管理工具中。对分布式服务台团队来说，这是一个合理且备受期待的折衷方案，与企业界中的数字转型一致。
--
--* **外勤服务 **客户组织中有用户在远程地点，并且服务提供商无法确保有常驻服务人员的情况下，处理物理上的工作可使用外勤服务。这些服务会产生服务提供者员工的差旅和住宿等费用，可能需要额外批准。在设计服务基础设施时，可以采用SaaS、授权用户或将一些现场服务委托给第三方的方式，减少这种模式存在的必要性。
--
--* **离岸和共享服务台团队** 这是从呼叫中心继承下来的实践。根据呼叫的来源，话务员使用不同的“行动手册”处理呼叫者的请求。一些大型的全球服务提供商和消费者技术供应商在劳动力成本较低的地方创建大型服务台中心，提供成本相对较低的服务台业务。尽管这种高度虚拟化的方法存在挑战，但其低廉的价格足以极大地推动对这种模式的需求。
--
--
--=== 4.2.2 服务台规模 ===
--
--并没有一种单一的方法确定服务提供商需要多少服务台团队。
--
--可以从影响工作量关键因素的简单思维图开始分析。这些因素包括：
--
--1. 服务台组织类型
--1. 排队理论或厄兰变量（Erlang Variables, 查询呼入率、可接受的等待时间、掉线率、队列长度等）
--1. 服务台团队因其他实践（典型事件，IMAC请求，调查等）而产生的额外工作量
--1. 用户和客户服务水平期望
--1. 预期员工流失率
--
--
--**4.2.2.1 扁平vs垂直**
--
--传统认为服务台业务是一项职能或一个团队。将服务台实践和服务台团队区分很重要。服务台团队可能负责几项实践，并将与服务台、事件管理、服务请求管理、问题管理和服务级别管理实践等许多实践互动。构建和定位服务台团队有许多方法，合适的解决方案因组织而异。下面将详细介绍主要的选项，但组织可能需要建立一种结合了多类选项的结构，以便完全满足业务需求。
--
--
--**4.2.2.2 垂直或横向结构**
--
--在垂直结构中，服务台团队可能包括几个级别（层或线），如果用户问询在当前级别无法解决，则会升级到更高级别。技术知识水平通常随着级别的提高而提高，专业能力也是如此。垂直结构最大限度地减少了昂贵资源的使用，并专注于在尽可能低的级别上解决用户问询。
--
--在横向结构中，服务台团队拥有更好的沟通线、团队精神和知识共享文化。通常，常见的用户问询待办项与其他工作项一起维护。这样的团队经常使用多功能团队分担问询解决方案的责任。在这种结构中，可伸缩性可能是一个挑战。
--
--
--**4.2.2.3 本地或集中结构**
--
--在本地部署中，服务台团队位于其所服务的用户办公内或附近。这种部署常有助于沟通，并显示其存在，一些用户喜欢这种方式。这种结构效率低、耗费资源。此外，组织要占据多个地理位置可能不可行。
--
--将工作人员聚集到一个或多个集中式服务台团队结构中，可使服务台团队合并到一个或较少数量的地点，从而减少服务台团队的数量。这可能更高效、更具成本效益，允许更少的总计人数处理更大数量的用户问询。这种结构还可以通过处理大量熟悉的频繁事态提高技能水平。该结构可能仍然需要保留一些本地人员处理实际的支持需求，但这些人员可以通过集中式服务台控制和部署。
--
--广域的沟通技术正变得越来越便宜，这意味着更容易拥有远程服务台团队。这种结构还允许弹性化关键技术人员的办公地点，可以是居家工作、离岸外包、二级支持小组和外包。这种结构应特别关注语言和文化差异，以及客户满意度。用户可能会感到被忽视，并认为与服务台团队的关系是官方的和/或缺少人情味的。虚拟的无休服务台团队是集中式服务台团队结构的一个示例。
--
--
--**4.2.2.4 专业化考虑 **
--
--在规划服务台团队时，了解关键专家归属（在哪个团队、位置、向谁报告等）和工作约束条件很重要。
--
--
--**4.2.2.5 服务设计方法**
--
--用于组织服务设计的不同方法可能会影响服务台团队的组织方式。在CI/CD方法中，开发和运维间的界限可能模糊，这可能影响服务台团队结构。
--
------
--
--=   =
--
--= 5. 信息和技术 =
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=1]]
--
--==   ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=2]]
--
--== 5.1 信息交流 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=3]]
--
--服务台实践的有效性取决于所用信息的质量。这些信息包括但不限于以下信息：
--
--1. 用户
--1. 服务，包括服务目录、服务请求目录，以及服务级别
--1. 知识管理系统
--1. 计划和执行的变更、变更时间表以及变更的可能影响
--1. 合作伙伴和供应商，包括关于其提供服务的信息
--1. 规范服务提供的策略和要求
--1. 利益相关方对实践的满意度
--
--信息可有多种形式。实践的关键输入和输出在第3节中列出。
--
--
--== 5.2 自动化和工具 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=4]]
--
--在许多情况下，服务台的工作可从自动化中获得很大好处。在可行且有效的情况下，它可能涉及表5.1中概述的解决方案。
--
--|**过程活动**|**自动化方式**|**关键功能**|**对实践有效性的影响**
--|(% colspan="4" %)人工处理用户查询
--|收集初始需求|用户查询管理和工作流工具、协作工具|事件的早期发现和关联，启动事件管理，启动服务请求管理和其他服务记录类型|高
--|验证用户身份|用户查询管理和工作流工具|辅助多因素用户识别|高
--|获取授权|用户查询管理和工作流工具|获得授权|高
--|需求分类以进行后续处理|用户查询管理和工作流工具、协作工具、配置管理工工具、基于机器学习的分类引擎|快速和准确的分类并分配用户查询|非常高，尤其当查询量大时
--|(% colspan="4" %)用户沟通
--|识别并确认目标受众|用户查询管理和工作流工具|检测位置和语言首选项，选择解决团队路由|高
--|识别并确认沟通渠道|用户查询管理和工作流工具|检测适用于该类型沟通的常规沟通场景|中
--|信息打包|用户查询管理和工作流工具|(((
--信息格式化
--
--固定响应模板管理
--)))|中
--|信息发送|用户查询管理和工作流工具、协作工具|沟通审批|中
--|收集和处理接收者确认和反馈|用户查询管理和工作流工具、协作工具|实时服务体验数据|高
--|(% colspan="4" %)服务台优化
--|服务台回顾|(((
--协作系统
--
--分析和报告系统
--)))|(((
--远程协作
--
--服务台数据分析
--)))|中到高，尤其是事件数多时
--|服务台优化启动|工单和工作流系统，待办项管理工具|优化的正式登记|低到中
--|服务台优化沟通|沟通工具、协作工具|与受影响团队沟通更新|中到高，尤其当组织较大、更新较多时
--
--表5.1服务台活动的自动化解决方案
--
--
------
--
--= 6 合作伙伴和供应商 =
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/6%20%E5%90%88%E4%BD%9C%E4%BC%99%E4%BC%B4%E5%92%8C%E4%BE%9B%E5%BA%94%E5%95%86/WebHome?section=1]]
--
--很少的服务是仅用组织自身资源就能交付的。大部分（如果不是全部的话）依赖于其他服务，通常是由组织外的第三方提供的服务（参见ITIL Foundation：ITIL 4出版物第2.4节，服务关系模型）。支持服务引入的关系和依赖关系在《ITIL供应商管理和服务级别管理实践指南》中有相关叙述。
--
--全球的外部IT服务提供商能够积累和利用相当数量的特定服务台知识和经验。例如，为应对高流动率和工作倦怠的趋势，外部服务提供者必须为服务台员工发明并不断改进高度专业化的招聘、培训和绩效管理技术。这在高速变化的客户和数字转型的背景下尤为重要。
--
--在商业利益的驱动下，外包服务台流程和团队可以成为组建服务台团队的宝贵资源。在EUC的竞争环境中，最成功的服务台方法应易于根据PSFs选择。潜在客户或良好实践的采用者应该询问某个服务台的想法是否让用户更便利地使用沟通渠道，服务台管理的信息是否能为用户增值。
--
--当组织的目标是确保快速有效的服务台实践时，他们通常会尝试与合作伙伴和供应商达成紧密合作，消除沟通、协作和决策制定中形式化的官僚壁垒。有关这方面的更多信息，请参阅《供应商管理》实践指南。
--
--
------
--
--= 7 重要提醒 =
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/7%20%E9%87%8D%E8%A6%81%E6%8F%90%E9%86%92/WebHome?section=1]]
--
--实践指南的大部分内容应视为组织在建立和培育自身实践相关领域时可考虑的建议。实践指南是组织可以考虑的主题目录而非答案列表。在使用ITIL实践指南的内容时，各组织应始终遵循ITIL指导原则：
--
--1. 聚焦价值
--1. 从你所处的地方开始
--1. 基于反馈迭代推进
--1. 协作和提升可视化程度
--1. 通盘思考和工作
--1. 保持简单实用
--1. 优化和自动化
--
--关于指导原则及其应用的更多信息，请参见ITIL Foundation：ITIL 4出版物第4.3节。
--
--
------
--
--= 8 致谢 =
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/8%20%E8%87%B4%E8%B0%A2/WebHome?section=1]]
--
--AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：
--
--
--== 8.1 作者 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/8%20%E8%87%B4%E8%B0%A2/WebHome?section=2]]
--
--Jamie Bell, Miroslav Hlohovsky, Roman Jouravlev, Konstantin Naryzhny, Helen Nunn
--
--
--== 8.2 审阅者 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/8%20%E8%87%B4%E8%B0%A2/WebHome?section=3]]
--
--Don Page, Aale Roos
--
------
--
  (% class="row" %)
  (((
  (% class="col-xs-12 col-sm-4" style="left: 106px; top: 362px;" %)
  (((
--
--
--
--
--
--
--
  )))
  )))

1600930052354-753.png

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.superadmin

Size

...	...	@@ -1,1 +1,0 @@
1		-60.4 KB

Content

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司