由 superadmin 于 2024/12/25, 15:37 最后修改
Show last authors
1 {{info}}
2
3 {{/info}}
4
5
6 **申明：**
7
8 本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注微信公众号：**ITILXF**，并回复“**服务台实践**”即可。
9
10 {{box cssClass="floatinginfobox" title="**Contents**"}}
11 {{toc/}}
12 {{/box}}
13
14 (((
15
16
17 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
18
19 **翻译**：傅盛        **审校**：秦佩君        **审核**：姚凯 、严宝龙
20
21
22
23 ----
24
25
26 )))
27
28
29 = 1 关于本文档 =
30
31
32 本文档提供服务台实践实用指南，分为五个主要部分，涵盖：
33
34 ●本实践的一般信息
35
36 ●本实践相关的流程和活动及其在服务价值链中的作用
37
38 ●参与本实践的组织和人员
39
40 ●支持本实践的信息和技术
41
42 ●对本实践的合作伙伴和供应商的考虑
43
44
45 == 1.1 ITIL 4资格认证计划 ==
46
47
48 本文档中的部分内容可作为以下教学大纲的一部分以供检查：
49
50 ● ITIL专家创建、交付和支持
51
52 ● ITIL专家交付利益干系人价值
53
54 详情请参考各部分教学大纲。
55
56
57 ----
58
59
60 = 2  一般信息 =
61
62
63
64
65
66 == 2.1 目的和描述 ==
67
68
69 * **关键信息**
70
71 服务台实践的目的是获取事件解决和服务请求的需求。服务台还应该是服务提供者为所有用户提供的接入点和单一联系点。
72
73 注：在一些组织中，服务台实践的主要目的是在服务提供者与用户之间建立有效的沟通界面，事件和服务请求只是沟通的两个主题。在这些组织中，这种实践的目的可能是：与所有用户建立有效的接入点和单一联系点；捕获事件解决和服务请求需求。组织可以并且应根据他们的目标和客观环境调整ITIL各项实践的目的声明和其他建议。
74
75 与其他实践一样，该实践涉及服务管理四维度模型的所有维度：
76
77 (% style="width:445px" %)
78 |(% style="width:152px" %)服务管理维度  |(% style="width:290px" %)服务台实践资源示例
79 |(% style="width:152px" %)组织和人员|(% style="width:290px" %)专门小组，有时被称为“服务台”
80 |(% style="width:152px" %)信息和技术|(% style="width:290px" %)专用信息系统，有时被称为“服务台”
81 |(% style="width:152px" %)价值流和流程|(% style="width:290px" %)与用户沟通的工作流和程序
82 |(% style="width:152px" %)合作伙伴和供应商|(% style="width:290px" %)相关第三方，在某些情况下被称为“服务台”
83
84 表2.1 服务管理维度示例
85
86 术语“服务台”可以指各种类型的资源和资源组。例如，许多组织中，服务台被认为是一个职能或一个团队。与任何团队一样，服务台团队可能会参与一些实践活动。这些可能包括服务台、事件管理、服务请求管理、问题管理、服务配置管理、关系管理等实践。
87
88 本实践指南描述服务台实践。当讨论其他团队、软件工具或流程时，这些实践会被明确指出。
89
90 服务台实践涉及服务提供商与用户沟通的所有价值流，其目的是确保这些沟通对所有相关方都是有效和便利的。
91
92
93 == 2.2 术语和概念 ==
94
95
96 === 2.2.1 沟通渠道 ===
97
98 服务台实践包括在用户和服务提供商之间建立有效、便利的沟通渠道。通常存在多个渠道时，需要进行有效渠道整合提供无缝、便捷的用户体验。
99
100 良好的沟通渠道允许用户和服务提供商以对各方都便利的方式交换信息，并保证信息质量。在这种情况下，术语“便利”的特征如表2.2所述。
101
102 (% style="width:572px" %)
103 |(% style="width:178px" %)**“便利”特性**|(% style="width:392px" %)**解释**
104 |(% style="width:178px" %)可访问性|(% style="width:392px" %)沟通渠道应该可访问。这可能包括语言、格式，以及用于任何视觉或其他方面受损的用户的特殊功能。可能需要通过特殊的应用程序、设备以及技能的界面访问沟通渠道。
105 |(% style="width:178px" %)保障性|(% style="width:392px" %)各方应确保沟通渠道真实、安全，并符合适用的法规、政策和规则。
106 |(% style="width:178px" %)可用性|(% style="width:392px" %)沟通渠道应在任何需要的地点和时间可用。根据服务的不同，沟通渠道可能包括各种范围的移动接口（从仅在组织内到覆盖全球范围）和可用时间的选项（从仅在工作时间内到连续可用）。
107 |(% style="width:178px" %)情境智能化|(% style="width:392px" %)在可能的情况下，应整合沟通渠道和相关情景信息。该信息可以包括预先填写的情景数据、沟通历史、用户档案等。
108 |(% style="width:178px" %)情感一致性（Emotional Alignment）|(% style="width:392px" %)在某些情况下，沟通渠道用于交流情感、感觉以及事实数据。在这种情况下，服务提供商应该促进服务同理心。这通常需要一个类似电话或面对面沟通的人机界面。
109 |(% style="width:178px" %)熟悉度|(% style="width:392px" %)熟悉的沟通渠道比陌生的新渠道更便利。社交媒体、论坛、电子邮件、聊天室和其他沟通渠道可以有效地用于与服务提供商的联系。
110 |(% style="width:178px" %)整合性|(% style="width:392px" %)服务提供商经常使用多种渠道与用户沟通。此外，服务交互中可能涉及多个其他系统。应整合这些系统，以减少或消除重复的数据输入，并防止信息丢失（参见以下全渠道沟通的定义）。
111 |(% style="width:178px" %)易用性（Usability）|(% style="width:392px" %)(((
112 所有类型的界面都应该清晰、直观、有用和实用。
113
114
115 )))
116
117 表2.2沟通渠道的便利特性
118
119
120 表2.2中概述的特征与常用于评估和管理信息质量的特征类似，这些特征包括可用性、可靠性、可访问性、及时性、准确性和相关性。需要注意的是，信息质量可能取决于沟通质量；其他信息特征则取决于信息源和相关方。
121
122 多渠道通常用于服务提供者与用户之间的沟通。多渠道沟通可能很便利，但若不进行整合也会带来混乱。多渠道沟通提供无缝体验和信息流，其发展的极致即为全渠道沟通。
123
124 * **定义：全渠道沟通**
125
126 跨多个渠道的统一沟通，基于跨渠道的信息共享，提供无缝的沟通体验。
127
128
129 === 2.2.2 服务同理心 ===
130
131 * **定义：服务同理心**
132
133 通过识别、理解、预测和展现另一方的兴趣、需求、意图和体验，以建立、维护和改进服务关系的能力。
134
135 服务同理心对组织和那些参与服务管理的人很重要。服务支持客服不可能分担用户的沮丧，但他们应认同并理解和表示同情，同时相应地调整自身的行为。
136
137 尽管自动化沟通系统可以通过新兴技术的情感分析能力（基于语言、声音和面部表情）得到增强，但这些系统无法实现同理心。服务同理心通常是通过聊天、视频和语音通话等渠道以及面对面交流的人际互动实现。
138
139 服务同理心是用户满意度提升和服务提供商成功的重要因素。作为一个概念，服务同理心不仅应用于用户支持和相关服务交互的狭窄情景，它适用于所有的服务交互。
140
141
142 === 2.2.3 用户满意度 ===
143
144 服务台作为一种交流界面，对用户满意度、客户满意度提升和服务关系的整体成功具有重要影响。用户满意度的关键因素包括沟通渠道和互动的有效性与便利性。
145
146 * **定义： 决定性时刻（Moment Of Truth）**
147
148 客户或用户与组织的某个方面接触并对其服务质量产生印象的任何一段经历。它是设定和实现客户期望并最终达到客户满意的基础。
149
150 服务关系中的许多决定性时刻发生在用户和服务提供商的沟通过程中，因此在服务台实践中相当常见。总体用户满意度由许多因素决定，事实上通常来说服务质量比沟通便利更重要。
151
152 服务台实践也用于收集关于用户满意度的信息。调查或其他满意度研究工具通常使用这种实践建立的沟通渠道。为了有效地收集这些信息，本实践的沟通渠道应该被用户认为是可信的、有效的和方便的；否则，对调查和其他沟通的反馈可能会受到影响。
153
154
155 == 2.3 范围 ==
156
157
158 服务台实践的范围包括：
159
160 1. 在服务供应商和用户之间建立和维护沟通渠道和界面
161 1. 授权（enabling）、记录和跟踪服务提供商和用户之间的沟通
162
163 尽管一些活动和责任领域与服务台密切相关，但不包括在服务台实践中。表2.3中列出了这些活动和责任领域，以及对应的实践供参考。重要的是要记住，ITIL实践仅仅是在价值流情景下使用的工具集合，它们应根据情况的需要而组合起来使用。
164
165 (% style="width:540px" %)
166 |(% style="width:217px" %)**活动**|(% style="width:320px" %)**实践指南**
167 |(% style="width:217px" %)事件解决和管理|(% style="width:320px" %)事件管理
168 |(% style="width:217px" %)服务请求的管理和实现|(% style="width:320px" %)服务请求
169 |(% style="width:217px" %)用户和服务提供商之间沟通的内容、时机和格式的定义|(% style="width:320px" %)向用户提供信息或使用用户信息的所有实践，包括事件管理、问题管理、变更支持、发布管理、项目管理、软件开发和管理、基础设施和平台管理、信息安全管理以及许多其他内容
170 |(% style="width:217px" %)技术和服务性能监控|(% style="width:320px" %)监控和事态管理
171 |(% style="width:217px" %)改进计划的管理|(% style="width:320px" %)持续改进
172 |(% style="width:217px" %)服务提供商和利益相关方之间的沟通，而非与用户的沟通|(% style="width:320px" %)关系管理
173 |(% style="width:217px" %)维护和改进信息与知识的使用|(% style="width:320px" %)知识管理
174
175 表2.3其他实践中描述的与服务台实践相关的活动
176
177
178 == 2.4 实践成功因素 ==
179
180
181 * **定义：实践成功因素（Practice Success Factor，PSF）**
182
183 实践为实现其目的所需的复杂功能性组件。
184
185 实践成功因素（PSF）不仅仅是一项任务或活动，它包括服务管理所有四个维度的组成部分。在一项实践中，PSFs相关的活动和资源的性质可能不同，但这些活动和资源共同确保实践的有效性。
186
187 服务台的实践包括以下PSFs：
188
189 1. 在服务提供者及其用户间实现有效、高效和便利的沟通并持续改进
190 1. 实现用户沟通与价值流的有效整合
191
192 === 2.4.1 在服务提供商与用户间实现有效、高效和便利的沟通并持续改进 ===
193
194 用户和客户可用的支持渠道应该高效、有效且便利。通过为用户和客户提供满足其需求的渠道可以达到便利。用户的需求可能会根据地理区域、时间、首选语言和可访问性要求的不同而变化。服务越便利，用户体验越好。
195
196 沟通渠道和界面的选择由多种因素决定，这些因素包括：
197
198 * 服务关系模型
199
200 * 内部或外部
201 * 商业或资助（subsidized）
202 * 大规模、开箱即用或定制
203 * 企业或个人
204
205 * 服务关系类型
206
207 * 基本、合作或伙伴关系
208
209 * 服务用户档案
210
211 * 语言
212 * 年龄
213 * 社交媒体活动
214 * 技术使用模式和偏好
215 * 位置
216 * 文化
217 * 多样性
218
219 * 服务提供商档案
220
221 * 位置和组织架构
222 * 用户满意度战略
223 * 服务组合的规模和可变性
224 * 技术能力和限制
225
226 * 影响服务关系的外部因素，包括政治、经济、社会、技术、法律和环境因素
227
228 交流不仅仅是发送信息。永远不要假设一条信息已经被认可和理解。每位收件人可能会根据个人情况对消息进行不同的解读或理解。发送方应确保其消息达到预期的结果接收方应该检查并确认正确理解了收到的消息。
229
230 在选择和设计服务渠道时，非常重要的是考虑用户对服务使用的准备度以及相关的风险和机会。不同的渠道会带来不同的挑战；组织必须准备好克服这些挑战。表2.4列出了其中的一些挑战。
231
232 [[image:1642235400045-491.png]]
233
234 [[image:1642235424757-755.png]]
235
236 表2.4 渠道示例及其挑战
237
238
239 在大多数情况下，服务提供者使用多种渠道。重要的是确保各渠道间有效整合。沟通应是全渠道，而非多渠道。一段无缝的用户旅程，有可能在信息不丢失或损坏的情况下，在不同的渠道间切换，促进积极的用户体验。没有充分整合的多渠道沟通很可能会造成混乱并引发错误。图2.1演示了如何使用多种渠道支持用户。
240
241 (% style="text-align:center" %)
242 [[image:1600929628284-534.png]]
243
244 图2.1多种沟通渠道
245
246
247 在非集成的多渠道沟通中，渠道间会有信息隔阂。例如，电话问询、在移动应用程序中的预约以及与来访工程师的沟通都可能需要重新输入（重新沟通）以触发呼叫支持服务。另一方面，在全渠道沟通中，情景将不断更新，并且可重用的数据将在任何关联的地方都可用。例如，用户在同一登录账号下执行的所有浏览和咨询都会添加到情景中，支持专家都可以看到。用户支持客服和来访工程师都可以获得所有相关数据。
248
249 换而言之，在多渠道沟通中，用户将在每条渠道开始新的旅程。在全渠道沟通中，旅程持续并在不同渠道间便利地切换。
250
251
252 === 2.4.2 实现用户沟通与价值流的有效整合 ===
253
254 作为服务提供商与用户双向沟通的节点，服务台实践的一个关键重点是有效地捕获、记录沟通信息并将其集成到相关的价值流中。像所有实践一样，本实践涉及多条价值流：只要服务提供商和用户之间需要沟通。
255
256 由服务提供者发起的沟通由价值流中涉及的一个或多个其他实践共同定义和执行。例如，关于服务计划变更的沟通由变更支持实践和发布管理实践共同发起和执行。作为服务台实践的一部分，建立和管理沟通渠道，但沟通的内容、格式和时间的定义是价值流情景中变更支持实践和发布管理实践的一部分。
257
258 然而，当用户发起沟通时，并不清楚属于哪条价值流，应该触发哪项ITIL实践活动。服务台实践为所有用户问询（包括咨询、事件、服务请求、投诉和表扬）的有效分类提供沟通界面和程序。当对用户查询进行分类并确定相关的价值流和实践后，将根据各自实践的流程和程序处理查询。有时，这涉及服务台团队资源和/或信息系统。
259
260
261 == 2.5 关键指标 ==
262
263 应在每个实践所贡献的价值流情境中评估ITIL实践的有效性和绩效。与任何工具的绩效一样，实践的绩效只能在其应用的情景中评估。然而，在设计和质量上，工具可能有很大的差异。当根据工具的目的使用时，这些差异定义了工具有效性的潜力或能力。关于度量标准、关键绩效指标（Key Performance Indicators， KPIs）和其他有助于实现这一点的技术的进一步指导，请参见度量和报告实践指南。
264
265 服务台实践的关键指标映射到其PSFs上。这些PSFs可以用作价值流情景下的KPIs，评估实践对这些价值流效能和效率的贡献。表2.5给出了一些关键指标的示例。
266
267 (% style="width:721px" %)
268 |(% style="width:258px" %)实践成功因素|(% style="width:460px" %)指标示例
269 |(% style="width:258px" %)在服务提供者及其用户间实现有效、高效和便利的沟通并持续改进|(% style="width:460px" %)(((
270 通过服务台渠道接收的信息的质量，根据商定的信息质量标准衡量
271
272 服务台沟通渠道和界面的便利性，根据商定的便利性标准衡量
273
274 沟通关键利益相关者对信息质量和服务台沟通渠道的便利性的满意度
275 )))
276 |(% style="width:258px" %)实现用户沟通与价值流的有效整合|(% style="width:460px" %)(((
277 与价值流的要求相比，通过服务台渠道接收到的信息的质量
278
279 关键利益相关者对通过服务台渠道传达信息的的满意度
280
281 用户查询分类不正确的数量和百分比
282 )))
283
284 表2.5实践成功因素的关键指标示例
285
286
287 将度量标准正确地聚合到复杂的指标中，将使数据更容易用于价值流的持续管理以及服务台实践的定期评估和持续改进。对此没有唯一的最佳解决方案。度量标准基于组织的整体服务策略和优先级，以及实践所贡献的价值流的目标。
288
289
290
291 ----
292
293 = 3 价值流和流程 =
294
295
296 == 3.1价值流贡献 ==
297
298
299 像任何其他ITIL管理实践一样，服务台实践对多条价值流有帮助。重要的是要记住，价值流从来不是由单一实践形成的。服务台实践与其他实践相结合，为客户提供高质量的服务。这种实践促成的主要价值链活动有：
300
301 ●契动
302
303 ●交付和支持。
304
305 服务台实践对服务价值链的贡献如图3.1所示
306
307 (% style="text-align:center" %)
308 [[image:1600929812191-791.png]]
309
310 图3.1 服务台实践对价值链贡献的热力图
311
312
313 == 3.2过程 ==
314
315
316 每个实践可以包括一个或多个流程和活动，这是实现这一实践目的所必需的。
317
318 * **定义：流程**
319
320 将输入转换为输出的一组相互关联或相互作用的活动。流程接受一个或多个已定义的输入，并将其转换为已定义的输出。流程定义了操作的顺序及依赖关系。
321
322 服务台活动分为三个流程：
323
324 * 用户查询处理
325 * 与用户沟通
326 * 服务台优化
327
328 === 3.2.1 用户查询处理 ===
329
330 该流程确保对用户查询的捕获、验证和分类，以便进一步处理。它包括表3.1中列出的活动，并将输入转化为输出。
331
332 (% style="width:594px" %)
333 |(% style="width:223px" %)**关键输入**|(% style="width:178px" %)**活动**|(% style="width:191px" %)**关键输出**
334 |(% style="width:223px" %)用户查询|(% style="width:178px" %)确认并记录用户的查询|(% style="width:191px" %)记录并分类用户的查询
335 |(% style="width:223px" %)服务管理记录，例如，事件记录、变更记录、问题记录等|(% style="width:178px" %)用户查询的验证|(% style="width:191px" %)开始处理已分类的用户查询
336 |(% style="width:223px" %)服务配置信息、IT资产信息以及其它相关信息|(% style="width:178px" %)对用户查询进行初步处理并启动适当的活动|(% style="width:191px" %)
337
338 表3.1 用户查询处理流程的输入、活动和输出
339
340
341 图3.2 展示该流程的工作流图
342
343 (% style="text-align:center" %)
344 [[image:1600929854496-543.png]]
345
346 图3.2 用户查询处理的工作流
347
348
349 表3.2将用户查询处理过程中每个人工交互和自动化活动进行比较。
350
351
352 [[image:1642580581960-553.png]]
353
354 [[image:1642580603544-786.png]]
355
356 [[image:1642580673860-313.png]]
357
358 表3.2自动化与人工交互比较
359
360
361 === 3.2.2 与用户沟通 ===
362
363 这个过程确保通过适当的渠道将各种类型的信息传达给用户。它包括表3.3所列的活动，并将输入转换成输出。
364
365 (% style="width:533px" %)
366 |(% style="width:199px" %)**关键输入**|(% style="width:219px" %)**活动**|(% style="width:113px" %)**关键输出**
367 |(% style="width:199px" %)(((
368 用户沟通需求
369
370 沟通的信息
371
372 以前的沟通记录
373
374 服务管理记录，例如事件记录、变更记录、问题记录等
375
376 服务配置信息、IT资产信息及其他相关信息
377 )))|(% style="width:219px" %)(((
378 识别并确认目标受众
379
380 识别并确认沟通渠道
381
382 信息打包
383
384 信息发送
385
386 收集和处理接受者的确认和反馈
387 )))|(% style="width:113px" %)(((
388 沟通消息
389
390 沟通报告
391 )))
392
393 表3.3 与用户沟通过程的输入、活动和输出
394
395
396 服务提供者和用户间的所有沟通都应该包括在此过程中。与用户沟通过程的需求通常由各种实践确定。沟通通常是标准化和自动化的，例如关于事件状态变化的通知。在某些情况下，还需要使用沟通流程将异常或其他重要信息传达给不同的受众。
397
398 图3.3展示该流程的工作流图。
399
400 (% style="text-align:center" %)
401 [[image:1600930001924-317.png]]
402
403 图3.3与用户沟通过程的工作流
404
405
406 表3.4概述了与先前已登记的查询相关的沟通过程活动。
407
408 [[image:1642235731662-569.png]]
409
410 [[image:1642235775142-492.png]]
411
412 [[image:1642235790279-634.png]]
413
414 表3.4关于先前已登记的查询的沟通过程活动
415
416
417 === 3.2.3 服务台优化 ===
418
419 这一流程确保从管理用户沟通中吸取经验教训，并不断改进这一实践。它包括表3.5中列出的活动，并将输入转化为输出。
420
421 (% style="width:427px" %)
422 |(% style="width:156px" %)**关键输入**|(% style="width:132px" %)**活动**|(% style="width:137px" %)**关键输出**
423 |(% style="width:156px" %)(((
424 服务台绩效报告
425
426 满意度调查结果
427
428 技术机遇
429
430 事件和服务请求报告
431 )))|(% style="width:132px" %)(((
432 服务台回顾
433
434 服务台优化启动
435
436 服务台优化沟通
437 )))|(% style="width:137px" %)服务台优化沟通
438
439 表3.5 服务台优化流程的输入、活动和输出
440
441
442 图3.4展示服务台优化流程的工作流图
443
444 (% style="text-align:center" %)
445 [[image:1600930052354-753.png]]
446
447 图3.4服务台优化过程的工作流
448
449
450 表3.6概述了服务台优化过程的活动。
451
452 (% style="width:510px" %)
453 |(% style="width:128px" %)**活动**|(% style="width:379px" %)**描述**
454 |(% style="width:128px" %)服务台回顾|(% style="width:379px" %)服务台团队经理与其他相关干系人一起回顾各种输入。确定改进这一实践的机会。
455 |(% style="width:128px" %)服务台优化启动|(% style="width:379px" %)服务台团队经理记录改进计划。计划将通过引入持续改进实践或启动变更请求进行处理。
456 |(% style="width:128px" %)服务台优化沟通|(% style="width:379px" %)如果服务台成功地完成优化，这一事实将会传达给相关的利益相关者。这通常由服务台经理通过沟通过程完成。
457
458 表3.6 服务台优化过程活动
459
460
461
462 ----
463
464 = 4 组织和人员 =
465
466
467
468
469
470 == 4.1 角色、能力和责任 ==
471
472
473 实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定的每个实践的专家角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。记住，角色并非职位头衔。一个人可担任多个角色，一个角色也可以分配给多个人员。
474
475 在流程和活动的情景中描述角色。每个角色都有一个基于表4.1所示模型的能力类型。
476
477 |能力代码|能力类型（活动和技能）
478 |L|**领导Leader **决策、授权、监督其他活动，提供激励和动力，并评估结果
479 |A|**管理员Administrator** 分配任务并确定优先级，保存记录，持续报告，并启动基本改进
480 |C|**协调者/沟通者 **协调多方，维护利益相关者之间的沟通，并开展宣传活动
481 |M|**方法和技巧专家 **设计和实施工作技巧、记录步骤、流程咨询、工作分析和持续改进
482 |T|**技术专家 **提供技术（IT）专业知识并执行基于专家经验的作业
483
484 表4.1 能力代码和能力类型
485
486
487 表4.2列出了服务台实践中可能涉及的其他角色示例，以及相关的能力类型和特定技能。
488
489 [[image:1642235912449-908.png]]
490
491 [[image:1642235925791-414.png]]
492
493
494
495 == 4.2 组织架构和团队 ==
496
497
498 在其他实践中，组织单元根据其参与的价值流活动扮演不同的实践角色。与其他实践不同，服务台实践通常有一个专注于执行其流程的专业团队。
499
500 通常，服务台团队是用户支持的第一线。除了与用户沟通之外，该团队还可以应用文档化或部分自动化的技术解决某些用户（和客户）的查询。通过知识管理工具，事件管理、问题管理、请求履行和服务级别管理等实践将这些技术的知识传递给服务台。应根据服务台实践的目的及其对服务台团队的影响，不断评估执行这些技术所产生的额外工作量。
501
502 本节介绍了不同的组织模型。这些模型可以适应传统上分配给服务台团队的任务。
503
504
505 === 4.2.1 服务台组织模式 ===
506
507 当服务提供商组织规模很小且致力于有限数量的服务时，服务台客服的角色可在员工之间共享。然而，这是一种与用户沟通的低效方式，随着服务和产品的不断发展会带来较大的工作量，而且单一用户交互产生的价值有限。
508
509 即使是小型内部服务提供商也可以受益于专门处理用户查询的员工，在后台服务组件的技术和方法能力与最终用户服务消费相去甚远时更是如此。服务台员工，作为面向消费者的专业人士，通常有很强的沟通技巧和友好、自信的举止。他们也能在不同的任务之间快速切换，并且通常也具有一定技术能力。
510
511 有几种常见的方式组建一个专门的用户交流团队，这将在4.2.1.1小节中讨论。
512
513
514 **4.2.1.1 本地服务台团队**
515
516 当服务台在物理上能够管理全渠道沟通时，或者说用户地理位置紧凑时，这种组织模式就能发挥作用。例如，可以为所有为客户服务的员工提供单一的办公空间，甚至可以为走访渠道提供单独团队，这时就适用本地服务台组织。
517
518 这样做的优点是：
519
520 * 团队内部和服务提供商组织之间快速高效的沟通。服务台团队应尽可能物理上与其他服务提供商团队在一起，以便能够快速了解信息和变化。
521 * 易于人与人之间的接触。服务台团队创建信任，并将服务提供者呈现为可访问资源。
522
523 这方面的挑战是：
524
525 * 集中式联合团队倾向于较少使用查询自动化工具。工作是透明的，人们不理解为什么查询需要被记录。同样，流程和指南也是口头传达和更新的。这可能导致缺乏对用户沟通的控制。
526 * 物理上的邻近会导致对特定个人，而非特定角色的依赖。这种风险应该通过流程控制减轻，但个人关系可能会形成“走后门式”的支持，并且在这些人离开后对服务提供造成干扰。
527
528 **4.2.1.2 分布式服务台团队**
529
530 该模型类似于本地服务台团队模型：用户群分布在多个位置，但IT和服务台团队之间仍有物理沟通渠道。用户的每个地理区域都与一个专门的服务台团队联系，每个服务台团队采用共同的沟通标准协调工作。
531
532 这样做的优点是：
533
534 * 能够随着客户组织或客户数量的增长而扩展服务提供者的存在，保证了存在和沟通标准。服务行为是任何服务提供的重要组成部分；确保服务行为可见很重要，可以保持积极和合作的声誉。
535 * 对用户查询的快速反应。分布式服务台组织对用户最有益之处在于用户在所有地点的服务查询都能得到一致和快速的响应。
536
537 这方面的挑战是：
538
539 * 协调和自动化。由于团队是分布式的，因此需要通过一致的协作环境理解当前组织的事态。所有团队都需要类似的、一致的培训和控制。一些服务提供商采用单一的分布式团队名册管理需求波动并减轻职责，以适应工作场所的通勤时间（例如，所有团队成员都在同一个都市圈内）。
540 * 不管如何自动协调，分布式服务台导致重复的专业知识和管理开销。一般来说，服务台工作人员处理的非沟通任务越多(处理模式化事件、IMAC请求或为用户提供支持)，团队之间的重复工作就会越多。服务提供者应该严格考查分布式服务台的价值（例如，面对面的交互），应对冗余安排造成的协调问题和共享成本。
541
542 **4.2.1.3 虚拟服务台团队**
543
544 服务台团队无法与用户在物理上协同工作时就出现了虚拟服务台团队模式。这与提供公众服务的商业服务提供商，如互联网接入提供商或用户软件供应商，尤其相关。
545
546 在这种情况下，虚拟服务台团队在结构上可能类似于协同工作的本地或分布式团队，或者可能是一组使用通用用户查询管理和工作流工具在家工作的个人。
547
548 虚拟服务台客服和用户之间没有物理交互，这将通过更先进的沟通渠道弥补。
549
550 优点是：
551
552 * 团队压力较小（当信息技术服务不完善时，压力可能会很大）。技术屏障界限有助于创造节奏，减少双方不适当的沟通。
553 * 降低每次问询的成本。除了使用电话支持，其他大多数沟通渠道都是不连续的。每一方向另一方发送信息都有一个时间差。此外，服务台人员可以在电子邮件或在线聊天问询之间切换，但是电话对话需要服务台人员持续投入注意力。
554
555 挑战是：
556
557 * 服务提供者必须承诺在工具的设计和实现方面进行广泛和持续的投资，支持各种沟通渠道和记录管理。自动化工具（在5.2节中描述）可确保客户能够快速、方便地提交查询并轻松地找到并与相关的服务提供者沟通。应向寻求真人互动的用户提供各种便利且非常容易获取的工具，如在线聊天、电子邮件或电话。服务提供商必须仔细分析每种技术的价值和成本。
558
559 **4.2.1.4 混合式服务台组织**
560
561 大多数服务提供商需在本地和虚拟组织模式间选择一个最优点。这种权衡包括几种已知的妥协：
562
563 * **驻场服务** 取代冗余的服务台团队的分布式网络，服务提供商可以决定在客户现场提供有限数量的员工和服务活动，并为用户的问询提供集中的跟踪系统。驻场服务是一种安排，即少量服务台客服在营业时间出现在客户场所，处理走访查询。这些客服可以自主处理基本的最终用户任务，例如：操作系统的小故障排查、业务应用程序支持、重要公告告知、客户沟通（与用户沟通相反），甚至是小的IMAC查询，少量次要组件（键盘、电池等）的现场维护。如果问题超出了他们的专业知识，或者如果等候队列超过了该服务点的某个阈值，他们就会通过已知的途径上报问询。这些问询在中央虚拟场所管理。驻场处理的问询必须与其他问询（电话、在线等）一起记录在中央问询管理工具中。对分布式服务台团队来说，这是一个合理且备受期待的折衷方案，与企业界中的数字转型一致。
564
565 * **外勤服务 **客户组织中有用户在远程地点，并且服务提供商无法确保有常驻服务人员的情况下，处理物理上的工作可使用外勤服务。这些服务会产生服务提供者员工的差旅和住宿等费用，可能需要额外批准。在设计服务基础设施时，可以采用SaaS、授权用户或将一些现场服务委托给第三方的方式，减少这种模式存在的必要性。
566
567 * **离岸和共享服务台团队** 这是从呼叫中心继承下来的实践。根据呼叫的来源，话务员使用不同的“行动手册”处理呼叫者的请求。一些大型的全球服务提供商和消费者技术供应商在劳动力成本较低的地方创建大型服务台中心，提供成本相对较低的服务台业务。尽管这种高度虚拟化的方法存在挑战，但其低廉的价格足以极大地推动对这种模式的需求。
568
569 === 4.2.2 服务台规模 ===
570
571 并没有一种单一的方法确定服务提供商需要多少服务台团队。
572
573 可以从影响工作量关键因素的简单思维图开始分析。这些因素包括：
574
575 * 服务台组织类型
576 * 排队理论或厄兰变量（Erlang Variables, 查询呼入率、可接受的等待时间、掉线率、队列长度等）
577 * 服务台团队因其他实践（典型事件，IMAC请求，调查等）而产生的额外工作量
578 * 用户和客户服务水平期望
579 * 预期员工流失率
580
581 **4.2.2.1 扁平vs垂直**
582
583 传统认为服务台业务是一项职能或一个团队。将服务台实践和服务台团队区分很重要。服务台团队可能负责几项实践，并将与服务台、事件管理、服务请求管理、问题管理和服务级别管理实践等许多实践互动。构建和定位服务台团队有许多方法，合适的解决方案因组织而异。下面将详细介绍主要的选项，但组织可能需要建立一种结合了多类选项的结构，以便完全满足业务需求。
584
585
586 **4.2.2.2 垂直或横向结构**
587
588 在垂直结构中，服务台团队可能包括几个级别（层或线），如果用户问询在当前级别无法解决，则会升级到更高级别。技术知识水平通常随着级别的提高而提高，专业能力也是如此。垂直结构最大限度地减少了昂贵资源的使用，并专注于在尽可能低的级别上解决用户问询。
589
590 在横向结构中，服务台团队拥有更好的沟通线、团队精神和知识共享文化。通常，常见的用户问询待办项与其他工作项一起维护。这样的团队经常使用多功能团队分担问询解决方案的责任。在这种结构中，可伸缩性可能是一个挑战。
591
592
593 **4.2.2.3 本地或集中结构**
594
595 在本地部署中，服务台团队位于其所服务的用户办公内或附近。这种部署常有助于沟通，并显示其存在，一些用户喜欢这种方式。这种结构效率低、耗费资源。此外，组织要占据多个地理位置可能不可行。
596
597 将工作人员聚集到一个或多个集中式服务台团队结构中，可使服务台团队合并到一个或较少数量的地点，从而减少服务台团队的数量。这可能更高效、更具成本效益，允许更少的总计人数处理更大数量的用户问询。这种结构还可以通过处理大量熟悉的频繁事态提高技能水平。该结构可能仍然需要保留一些本地人员处理实际的支持需求，但这些人员可以通过集中式服务台控制和部署。
598
599 广域的沟通技术正变得越来越便宜，这意味着更容易拥有远程服务台团队。这种结构还允许弹性化关键技术人员的办公地点，可以是居家工作、离岸外包、二级支持小组和外包。这种结构应特别关注语言和文化差异，以及客户满意度。用户可能会感到被忽视，并认为与服务台团队的关系是官方的和/或缺少人情味的。虚拟的无休服务台团队是集中式服务台团队结构的一个示例。
600
601
602 **4.2.2.4 专业化考虑 **
603
604 在规划服务台团队时，了解关键专家归属（在哪个团队、位置、向谁报告等）和工作约束条件很重要。
605
606
607 **4.2.2.5 服务设计方法**
608
609 用于组织服务设计的不同方法可能会影响服务台团队的组织方式。在CI/CD方法中，开发和运维间的界限可能模糊，这可能影响服务台团队结构。
610
611
612
613 ----
614
615 = 5. 信息和技术 =
616
617
618
619
620
621 == 5.1 信息交流 ==
622
623
624 服务台实践的有效性取决于所用信息的质量。这些信息包括但不限于以下信息：
625
626 * 用户
627 * 服务，包括服务目录、服务请求目录，以及服务级别
628 * 知识管理系统
629 * 计划和执行的变更、变更时间表以及变更的可能影响
630 * 合作伙伴和供应商，包括关于其提供服务的信息
631 * 规范服务提供的策略和要求
632
633 1. 利益相关方对实践的满意度
634
635 信息可有多种形式。实践的关键输入和输出在第3节中列出。
636
637
638 == 5.2 自动化和工具 ==
639
640
641 在许多情况下，服务台的工作可从自动化中获得很大好处。在可行且有效的情况下，它可能涉及表5.1中概述的解决方案。
642
643 [[image:1642236032706-313.png]]
644
645 [[image:1642236047390-499.png]]
646
647 表5.1服务台活动的自动化解决方案
648
649
650
651 ----
652
653 = 6 合作伙伴和供应商 =
654
655
656 很少的服务是仅用组织自身资源就能交付的。大部分（如果不是全部的话）依赖于其他服务，通常是由组织外的第三方提供的服务（参见ITIL Foundation：ITIL 4出版物第2.4节，服务关系模型）。支持服务引入的关系和依赖关系在《ITIL供应商管理和服务级别管理实践指南》中有相关叙述。
657
658 全球的外部IT服务提供商能够积累和利用相当数量的特定服务台知识和经验。例如，为应对高流动率和工作倦怠的趋势，外部服务提供者必须为服务台员工发明并不断改进高度专业化的招聘、培训和绩效管理技术。这在高速变化的客户和数字转型的背景下尤为重要。
659
660 在商业利益的驱动下，外包服务台流程和团队可以成为组建服务台团队的宝贵资源。在EUC的竞争环境中，最成功的服务台方法应易于根据PSFs选择。潜在客户或良好实践的采用者应该询问某个服务台的想法是否让用户更便利地使用沟通渠道，服务台管理的信息是否能为用户增值。
661
662 当组织的目标是确保快速有效的服务台实践时，他们通常会尝试与合作伙伴和供应商达成紧密合作，消除沟通、协作和决策制定中形式化的官僚壁垒。有关这方面的更多信息，请参阅《供应商管理》实践指南。
663
664
665
666 ----
667
668 = 7 重要提醒 =
669
670
671 实践指南的大部分内容应视为组织在建立和培育自身实践相关领域时可考虑的建议。实践指南是组织可以考虑的主题目录而非答案列表。在使用ITIL实践指南的内容时，各组织应始终遵循ITIL指导原则：
672
673 1. 聚焦价值
674 1. 从你所处的地方开始
675 1. 基于反馈迭代推进
676 1. 协作和提升可视化程度
677 1. 通盘思考和工作
678 1. 保持简单实用
679 1. 优化和自动化
680
681 关于指导原则及其应用的更多信息，请参见ITIL Foundation：ITIL 4出版物第4.3节。
682
683
684
685 ----
686
687 = 8 致谢 =
688
689
690 AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：
691
692
693 == 8.1 作者 ==
694
695
696 Jamie Bell, Miroslav Hlohovsky, Roman Jouravlev, Konstantin Naryzhny, Helen Nunn
697
698
699 == 8.2 审阅者 ==
700
701
702 Don Page, Aale Roos
703
704 ----
705
706 (% class="row" %)
707 (((
708 (% class="col-xs-12 col-sm-4" style="left: 106px; top: 362px;" %)
709 (((
710
711
712
713
714
715
716
717
718 )))
719 )))
深圳市艾拓先锋企业管理咨询有限公司