由 superadmin 于 2024/12/25, 15:37 最后修改
从版本< 11.2 >
由superadmin编辑
在2021/01/26, 16:26上
到版本
由superadmin编辑
在2021/01/26, 16:29上
< >
修改评论 该版本没有评论

Summary

Details

Icon Page properties
Content
... ... @@ -2,10 +2,9 @@
2 2  (((
3 3  (% class="container" %)
4 4  (((
5 -= [[开始阅读>>doc:01 服务台.1 关于本文件.WebHome]] =
5 += =
6 6  
7 7  
8 -
9 9  需要下载 **ITIL 4服务台实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“服务台实践”即可。
10 10  
11 11  [[image:http://itil4hub.cn/bin/download/C%20%E5%AE%9E%E8%B7%B5%E6%8C%87%E5%8D%97/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/WebHome/%E5%BE%AE%E4%BF%A1%E5%9B%BE%E7%89%87_20200929154759.png?rev=1.2||alt="微信图片_20200929154759.png"]]
... ... @@ -22,6 +22,350 @@
22 22  )))
23 23  )))
24 24  
24 +
25 += 1 关于本文档 =
26 +
27 +[[编辑>>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=1]]
28 +
29 +本文档提供服务台实践实用指南，分为五个主要部分，涵盖：
30 +
31 +●本实践的一般信息
32 +
33 +●本实践相关的流程和活动及其在服务价值链中的作用
34 +
35 +●参与本实践的组织和人员
36 +
37 +●支持本实践的信息和技术
38 +
39 +●对本实践的合作伙伴和供应商的考虑
40 +
41 +== 1.1 ITIL 4资格认证计划 ==
42 +
43 +[[编辑>>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]]
44 +
45 +本文档中的部分内容可作为以下教学大纲的一部分以供检查：
46 +
47 +● ITIL专家创建、交付和支持
48 +
49 +● ITIL专家交付利益干系人价值
50 +
51 +详情请参考各部分教学大纲。
52 +
53 +
54 +
55 += 2  一般信息 =
56 +
57 +[[编辑>>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=1]]
58 +
59 +== ==
60 +
61 +[[编辑>>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=2]]
62 +
63 +== 2.1 目的和描述 ==
64 +
65 +[[编辑>>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=3]]
66 +
67 +* **关键信息**
68 +
69 +服务台实践的目的是获取事件解决和服务请求的需求。服务台还应该是服务提供者为所有用户提供的接入点和单一联系点。
70 +
71 +注：在一些组织中，服务台实践的主要目的是在服务提供者与用户之间建立有效的沟通界面，事件和服务请求只是沟通的两个主题。在这些组织中，这种实践的目的可能是：与所有用户建立有效的接入点和单一联系点；捕获事件解决和服务请求需求。组织可以并且应根据他们的目标和客观环境调整ITIL各项实践的目的声明和其他建议。
72 +
73 +与其他实践一样，该实践涉及服务管理四维度模型的所有维度：
74 +
75 +|服务管理维度  |服务台实践资源示例
76 +|组织和人员|专门小组，有时被称为“服务台”
77 +|信息和技术|专用信息系统，有时被称为“服务台”
78 +|价值流和流程|与用户沟通的工作流和程序
79 +|合作伙伴和供应商|相关第三方，在某些情况下被称为“服务台”
80 +
81 +表2.1 服务管理维度示例
82 +
83 +术语“服务台”可以指各种类型的资源和资源组。例如，许多组织中，服务台被认为是一个职能或一个团队。与任何团队一样，服务台团队可能会参与一些实践活动。这些可能包括服务台、事件管理、服务请求管理、问题管理、服务配置管理、关系管理等实践。
84 +
85 +本实践指南描述服务台实践。当讨论其他团队、软件工具或流程时，这些实践会被明确指出。
86 +
87 +服务台实践涉及服务提供商与用户沟通的所有价值流，其目的是确保这些沟通对所有相关方都是有效和便利的。
88 +
89 +== 2.2 术语和概念 ==
90 +
91 +[[编辑>>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]]
92 +
93 +=== 2.2.1 沟通渠道 ===
94 +
95 +服务台实践包括在用户和服务提供商之间建立有效、便利的沟通渠道。通常存在多个渠道时，需要进行有效渠道整合提供无缝、便捷的用户体验。
96 +
97 +良好的沟通渠道允许用户和服务提供商以对各方都便利的方式交换信息，并保证信息质量。在这种情况下，术语“便利”的特征如表2.2所述。
98 +
99 +|**“便利”特性**|**解释**
100 +|可访问性|沟通渠道应该可访问。这可能包括语言、格式，以及用于任何视觉或其他方面受损的用户的特殊功能。可能需要通过特殊的应用程序、设备以及技能的界面访问沟通渠道。
101 +|保障性|各方应确保沟通渠道真实、安全，并符合适用的法规、政策和规则。
102 +|可用性|沟通渠道应在任何需要的地点和时间可用。根据服务的不同，沟通渠道可能包括各种范围的移动接口（从仅在组织内到覆盖全球范围）和可用时间的选项（从仅在工作时间内到连续可用）。
103 +|情境智能化|在可能的情况下，应整合沟通渠道和相关情景信息。该信息可以包括预先填写的情景数据、沟通历史、用户档案等。
104 +|情感一致性（Emotional Alignment）|在某些情况下，沟通渠道用于交流情感、感觉以及事实数据。在这种情况下，服务提供商应该促进服务同理心。这通常需要一个类似电话或面对面沟通的人机界面。
105 +|熟悉度|熟悉的沟通渠道比陌生的新渠道更便利。社交媒体、论坛、电子邮件、聊天室和其他沟通渠道可以有效地用于与服务提供商的联系。
106 +|整合性|服务提供商经常使用多种渠道与用户沟通。此外，服务交互中可能涉及多个其他系统。应整合这些系统，以减少或消除重复的数据输入，并防止信息丢失（参见以下全渠道沟通的定义）。
107 +|易用性（Usability）|(((
108 +所有类型的界面都应该清晰、直观、有用和实用。
109 +
110 +
111 +)))
112 +
113 +表2.2沟通渠道的便利特性
114 +
115 +表2.2中概述的特征与常用于评估和管理信息质量的特征类似，这些特征包括可用性、可靠性、可访问性、及时性、准确性和相关性。需要注意的是，信息质量可能取决于沟通质量；其他信息特征则取决于信息源和相关方。
116 +
117 +多渠道通常用于服务提供者与用户之间的沟通。多渠道沟通可能很便利，但若不进行整合也会带来混乱。多渠道沟通提供无缝体验和信息流，其发展的极致即为全渠道沟通。
118 +
119 +* **定义：全渠道沟通**
120 +
121 +跨多个渠道的统一沟通，基于跨渠道的信息共享，提供无缝的沟通体验。
122 +
123 +=== 2.2.2 服务同理心 ===
124 +
125 +* **定义：服务同理心**
126 +
127 +通过识别、理解、预测和展现另一方的兴趣、需求、意图和体验，以建立、维护和改进服务关系的能力。
128 +
129 +服务同理心对组织和那些参与服务管理的人很重要。服务支持客服不可能分担用户的沮丧，但他们应认同并理解和表示同情，同时相应地调整自身的行为。
130 +
131 +尽管自动化沟通系统可以通过新兴技术的情感分析能力（基于语言、声音和面部表情）得到增强，但这些系统无法实现同理心。服务同理心通常是通过聊天、视频和语音通话等渠道以及面对面交流的人际互动实现。
132 +
133 +服务同理心是用户满意度提升和服务提供商成功的重要因素。作为一个概念，服务同理心不仅应用于用户支持和相关服务交互的狭窄情景，它适用于所有的服务交互。
134 +
135 +=== 2.2.3 用户满意度 ===
136 +
137 +服务台作为一种交流界面，对用户满意度、客户满意度提升和服务关系的整体成功具有重要影响。用户满意度的关键因素包括沟通渠道和互动的有效性与便利性。
138 +
139 +* **定义： 决定性时刻（Moment Of Truth）**
140 +
141 +客户或用户与组织的某个方面接触并对其服务质量产生印象的任何一段经历。它是设定和实现客户期望并最终达到客户满意的基础。
142 +
143 +服务关系中的许多决定性时刻发生在用户和服务提供商的沟通过程中，因此在服务台实践中相当常见。总体用户满意度由许多因素决定，事实上通常来说服务质量比沟通便利更重要。
144 +
145 +服务台实践也用于收集关于用户满意度的信息。调查或其他满意度研究工具通常使用这种实践建立的沟通渠道。为了有效地收集这些信息，本实践的沟通渠道应该被用户认为是可信的、有效的和方便的；否则，对调查和其他沟通的反馈可能会受到影响。
146 +
147 +== 2.3 范围 ==
148 +
149 +[[编辑>>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]]
150 +
151 +服务台实践的范围包括：
152 +
153 +1. 在服务供应商和用户之间建立和维护沟通渠道和界面
154 +1. 授权（enabling）、记录和跟踪服务提供商和用户之间的沟通
155 +
156 +尽管一些活动和责任领域与服务台密切相关，但不包括在服务台实践中。表2.3中列出了这些活动和责任领域，以及对应的实践供参考。重要的是要记住，ITIL实践仅仅是在价值流情景下使用的工具集合，它们应根据情况的需要而组合起来使用。
157 +
158 +|**活动**|**实践指南**
159 +|事件解决和管理|事件管理
160 +|服务请求的管理和实现|服务请求
161 +|用户和服务提供商之间沟通的内容、时机和格式的定义|向用户提供信息或使用用户信息的所有实践，包括事件管理、问题管理、变更支持、发布管理、项目管理、软件开发和管理、基础设施和平台管理、信息安全管理以及许多其他内容
162 +|技术和服务性能监控|监控和事态管理
163 +|改进计划的管理|持续改进
164 +|服务提供商和利益相关方之间的沟通，而非与用户的沟通|关系管理
165 +|维护和改进信息与知识的使用|知识管理
166 +
167 +表2.3其他实践中描述的与服务台实践相关的活动
168 +
169 +== 2.4 实践成功因素 ==
170 +
171 +[[编辑>>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]]
172 +
173 +* **定义：实践成功因素（Practice Success Factor，PSF）**
174 +
175 +实践为实现其目的所需的复杂功能性组件。
176 +
177 +实践成功因素（PSF）不仅仅是一项任务或活动，它包括服务管理所有四个维度的组成部分。在一项实践中，PSFs相关的活动和资源的性质可能不同，但这些活动和资源共同确保实践的有效性。
178 +
179 +服务台的实践包括以下PSFs：
180 +
181 +1. 在服务提供者及其用户间实现有效、高效和便利的沟通并持续改进
182 +1. 实现用户沟通与价值流的有效整合
183 +
184 +=== ===
185 +
186 +=== 2.4.1 在服务提供商与用户间实现有效、高效和便利的沟通并持续改进 ===
187 +
188 +用户和客户可用的支持渠道应该高效、有效且便利。通过为用户和客户提供满足其需求的渠道可以达到便利。用户的需求可能会根据地理区域、时间、首选语言和可访问性要求的不同而变化。服务越便利，用户体验越好。
189 +
190 +沟通渠道和界面的选择由多种因素决定，这些因素包括：
191 +
192 +* 服务关系模型
193 +
194 +* 内部或外部
195 +* 商业或资助（subsidized）
196 +* 大规模、开箱即用或定制
197 +* 企业或个人
198 +
199 +* 服务关系类型
200 +
201 +* 基本、合作或伙伴关系
202 +
203 +* 服务用户档案
204 +
205 +* 语言
206 +* 年龄
207 +* 社交媒体活动
208 +* 技术使用模式和偏好
209 +* 位置
210 +* 文化
211 +* 多样性
212 +
213 +* 服务提供商档案
214 +
215 +* 位置和组织架构
216 +* 用户满意度战略
217 +* 服务组合的规模和可变性
218 +* 技术能力和限制
219 +
220 +* 影响服务关系的外部因素，包括政治、经济、社会、技术、法律和环境因素
221 +
222 +交流不仅仅是发送信息。永远不要假设一条信息已经被认可和理解。每位收件人可能会根据个人情况对消息进行不同的解读或理解。发送方应确保其消息达到预期的结果接收方应该检查并确认正确理解了收到的消息。
223 +
224 +在选择和设计服务渠道时，非常重要的是考虑用户对服务使用的准备度以及相关的风险和机会。不同的渠道会带来不同的挑战；组织必须准备好克服这些挑战。表2.4列出了其中的一些挑战。
225 +
226 +| |**渠道**|**挑战示例**|**解决方案示例**
227 +|(% rowspan="6" %)(((
228 +用
229 +
230 +户
231 +
232 +与
233 +
234 +人
235 +
236 +的
237 +
238 +互
239 +
240 +动
241 +)))|语音|(((
242 +有限的可扩展性
243 +
244 +主观态度和情绪
245 +)))|投资于支持型客服的职业发展、情商、对不同文化的认知和兴趣
246 +|实时聊天|主观态度和情绪|将人力支持限制在需要和合理的地方
247 +|电子邮件|(((
248 +非结构化信息
249 +
250 +主观态度和情绪
251 +)))|在适当的情况下，利用可用资源自动记录非结构化信息
252 +|走访|(((
253 +有限的可扩展性
254 +
255 +主观态度和情绪
256 +)))|(% rowspan="3" %)(((
257 +
258 +
259 +情况合适时推行自助服务以增加接待能力
260 +
261 +提供明确的安全参数，并定期测试其有效性
262 +)))
263 +|驻场|(((
264 +有限的规模和可用性
265 +
266 +主观态度和情绪
267 +)))
268 +|社交媒体|(((
269 +病毒效应，错误和冲突的高曝光率
270 +
271 +主观态度和情绪
272 +
273 +非结构化信息
274 +
275 +安全约束
276 +)))
277 +|(((
278 +用
279 +
280 +户
281 +
282 +与
283 +
284 +技
285 +
286 +术
287 +
288 +的
289 +
290 +互
291 +
292 +动
293 +)))|网络门户，（电话）互动语音菜单，移动应用，聊天机器人以及其他|(((
294 +用户可以在其安全级别上完成范围有限的任务
295 +
296 +数据不充分、不足够
297 +
298 +用户技术技能不充分、不足够
299 +
300 +缺乏服务同理心和情商
301 +
302 +面对复杂环境的有限适用性
303 +)))|(((
304 +在实施自助前，评估用户技能和可用的支持操作范围
305 +
306 +使用用户熟悉的渠道和界面
307 +
308 +确保高质量的历史数据和知识支持
309 +
310 +当使用机器学习时，确保数据和算法的高质量
311 +
312 +提供人工备份支持选项
313 +
314 +改进信息质量和导航工具
315 +
316 +确保尽可能容易获得自助工具和行动
317 +)))
318 +
319 +表2.4 渠道示例及其挑战
320 +
321 +在大多数情况下，服务提供者使用多种渠道。重要的是确保各渠道间有效整合。沟通应是全渠道，而非多渠道。一段无缝的用户旅程，有可能在信息不丢失或损坏的情况下，在不同的渠道间切换，促进积极的用户体验。没有充分整合的多渠道沟通很可能会造成混乱并引发错误。图2.1演示了如何使用多种渠道支持用户。
322 +
323 +[[image:/bin/download/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/1600929628284-534.png?rev=1.1||alt="1600929628284-534.png"]]
324 +
325 +图2.1多种沟通渠道
326 +
327 +在非集成的多渠道沟通中，渠道间会有信息隔阂。例如，电话问询、在移动应用程序中的预约以及与来访工程师的沟通都可能需要重新输入（重新沟通）以触发呼叫支持服务。另一方面，在全渠道沟通中，情景将不断更新，并且可重用的数据将在任何关联的地方都可用。例如，用户在同一登录账号下执行的所有浏览和咨询都会添加到情景中，支持专家都可以看到。用户支持客服和来访工程师都可以获得所有相关数据。
328 +
329 +换而言之，在多渠道沟通中，用户将在每条渠道开始新的旅程。在全渠道沟通中，旅程持续并在不同渠道间便利地切换。
330 +
331 +=== 2.4.2 实现用户沟通与价值流的有效整合 ===
332 +
333 +作为服务提供商与用户双向沟通的节点，服务台实践的一个关键重点是有效地捕获、记录沟通信息并将其集成到相关的价值流中。像所有实践一样，本实践涉及多条价值流：只要服务提供商和用户之间需要沟通。
334 +
335 +由服务提供者发起的沟通由价值流中涉及的一个或多个其他实践共同定义和执行。例如，关于服务计划变更的沟通由变更支持实践和发布管理实践共同发起和执行。作为服务台实践的一部分，建立和管理沟通渠道，但沟通的内容、格式和时间的定义是价值流情景中变更支持实践和发布管理实践的一部分。
336 +
337 +然而，当用户发起沟通时，并不清楚属于哪条价值流，应该触发哪项ITIL实践活动。服务台实践为所有用户问询（包括咨询、事件、服务请求、投诉和表扬）的有效分类提供沟通界面和程序。当对用户查询进行分类并确定相关的价值流和实践后，将根据各自实践的流程和程序处理查询。有时，这涉及服务台团队资源和/或信息系统。
338 +
339 +== 2.5 关键指标 ==
340 +
341 +[[编辑>>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]]
342 +
343 +应在每个实践所贡献的价值流情境中评估ITIL实践的有效性和绩效。与任何工具的绩效一样，实践的绩效只能在其应用的情景中评估。然而，在设计和质量上，工具可能有很大的差异。当根据工具的目的使用时，这些差异定义了工具有效性的潜力或能力。关于度量标准、关键绩效指标（Key Performance Indicators， KPIs）和其他有助于实现这一点的技术的进一步指导，请参见度量和报告实践指南。
344 +
345 +服务台实践的关键指标映射到其PSFs上。这些PSFs可以用作价值流情景下的KPIs，评估实践对这些价值流效能和效率的贡献。表2.5给出了一些关键指标的示例。
346 +
347 +|实践成功因素|指标示例
348 +|在服务提供者及其用户间实现有效、高效和便利的沟通并持续改进|(((
349 +通过服务台渠道接收的信息的质量，根据商定的信息质量标准衡量
350 +
351 +服务台沟通渠道和界面的便利性，根据商定的便利性标准衡量
352 +
353 +沟通关键利益相关者对信息质量和服务台沟通渠道的便利性的满意度
354 +)))
355 +|实现用户沟通与价值流的有效整合|(((
356 +与价值流的要求相比，通过服务台渠道接收到的信息的质量
357 +
358 +关键利益相关者对通过服务台渠道传达信息的的满意度
359 +
360 +用户查询分类不正确的数量和百分比
361 +)))
362 +
363 +表2.5实践成功因素的关键指标示例
364 +
365 +将度量标准正确地聚合到复杂的指标中，将使数据更容易用于价值流的持续管理以及服务台实践的定期评估和持续改进。对此没有唯一的最佳解决方案。度量标准基于组织的整体服务策略和优先级，以及实践所贡献的价值流的目标。
366 +
367 +
25 25  (% class="row" %)
26 26  (((
27 27  (% class="col-xs-12 col-sm-4" style="left: 106px; top: 362px;" %)
深圳市艾拓先锋企业管理咨询有限公司