Hide last authors
author | version | line-number | content |
---|---|---|---|
![]() |
12.2 | 1 | = 7. 步骤5:引入 = |
2 | |||
3 | [[image:1639123237595-418.png]] | ||
4 | |||
5 | 计划引入 | ||
6 | |||
7 | 与用户相关并建立关系 | ||
8 | |||
9 | 提供用户参与和交付渠道 | ||
10 | |||
11 | 使用户能够使用服务 | ||
12 | |||
13 | 提升彼此的能力和撤销客户与用户 | ||
14 | |||
15 | |||
16 | 引入包括服务消费者开始使用服务和服务提供者准备交付服务所需的所有活动。这些范围包括从打开并可供使用的服务(例如,连接到网络的移动电话)到合同协议、用户感知、培训和资源共享(例如,外包桌面设备)。 | ||
17 | |||
18 | |||
19 | 有效的引入支持服务的提供和使用,提高服务的使用效率,改善用户体验,确保满意度,并增进服务提供者和服务消费者之间的关系。 | ||
20 | |||
21 | |||
22 | 表7.1总结了服务提供者、服务消费者和其他利益相关方为何应投资有效的引入和撤销。 | ||
23 | |||
24 | |||
25 | 引入在协议达成或更改之后,但在服务消费启动之前发生。引入为用户创造了第一个服务印象,这可能会严重影响发起人和客户就服务关系做出的任何进一步决定。 因此,应根据商定的计划仔细计划和管理每个引入计划。 | ||
26 | |||
27 | |||
28 | 表7.1 引入和撤销的目的 | ||
29 | |||
![]() |
20.1 | 30 | (% style="width:803px" %) |
31 | |(% style="width:165px" %)**引入和撤销**|(% style="width:307px" %)**对于服务消费者**|(% style="width:328px" %)**对于服务提供者** | ||
32 | |(% style="width:165px" %)促进成果和体验|(% style="width:307px" %)((( | ||
![]() |
12.2 | 33 | 通过有效使用服务来确保更好的投资回报 |
34 | |||
35 | 改善用户体验 | ||
36 | |||
37 | 通过有效使用服务来提高业务运营的效果和效率 | ||
38 | |||
39 | 通过与新的服务提供者合作来最大化价值 | ||
![]() |
20.1 | 40 | )))|(% style="width:328px" %)((( |
![]() |
12.2 | 41 | 通过与新的服务消费者/客户/用户的合作来最大化价值 |
42 | |||
43 | 提高对新的服务和服务提供者的总体了解 | ||
44 | |||
45 | 提高客户和用户的忠诚度和参与度 | ||
46 | ))) | ||
![]() |
20.1 | 47 | |(% style="width:165px" %)优化风险和合规性|(% style="width:307px" %)((( |
![]() |
12.2 | 48 | 降低与新服务和用户有关的用户事件及问题的可能性 |
49 | |||
50 | 缩短过渡到新服务/提供者的时间 | ||
![]() |
20.1 | 51 | )))|(% style="width:328px" %)((( |
![]() |
12.2 | 52 | 降低服务质量中事件和相关违规的可能性 |
53 | |||
54 | 防止/减少用户对新服务和/或服务提供者的抵制 | ||
55 | ))) | ||
![]() |
20.1 | 56 | |(% style="width:165px" %)优化资源并最小化成本|(% style="width:307px" %)((( |
![]() |
12.2 | 57 | 减少过渡到新服务/提供者相关的成本和损失 |
58 | |||
59 | 优化用户培训成本 | ||
60 | |||
61 | 优化用户支持成本 | ||
![]() |
20.1 | 62 | )))|(% style="width:328px" %)((( |
![]() |
12.2 | 63 | 减少过渡成本 |
64 | |||
65 | 减少用户支持成本 | ||
66 | |||
67 | 优化入门成本和整体资源利用率 | ||
68 | ))) | ||
69 | |||
70 | 引入包括: | ||
71 | |||
72 | * 在利益相关者中构建有关新服务消费者(或与现有消费者的服务关系的新范围)的认知 | ||
73 | * 确保为服务提供准备好服务范围内的所有资源 | ||
74 | * 确保客户和用户已准备好使用服务消费。 | ||
75 | |||
76 | 引入通常被认为是服务提供者的活动,而服务消费者参与却很少。但是,成功的引入涉及服务提供者和服务消费者。如果服务消费者的参与需要大量资源,组织通常会同意,并提前与客户达成引入的方法。重要的是要确保其他合作伙伴和供应商知道并接受引入方法和计划(如果它们将参与其实现)。当将引入详细定义为产品、服务和服务产品设计的一部分时,用于特定计划的规划则更容易、更安全、更快捷。因此,在第5章中将引入方法定义为产品、服务和服务提供设计的一部分。在本章中,引入方法适用于特定引入计划的计划。 | ||
77 | |||
78 | |||
79 | 从服务提供者角度来看,成功的引入依赖于以下ITIL 管理实践: | ||
80 | |||
81 | * 部署管理 | ||
82 | * 组织变革管理 | ||
83 | * 发布管理 | ||
84 | * 服务配置管理 | ||
85 | * 服务设计 | ||
86 | * 服务台 | ||
87 | * 服务级别管理。 | ||
88 | |||
89 | 规划和执行引入计划中可能还涉及其他实践。例如,有时将引入作为项目进行管理,需要项目管理实践。 | ||
90 | |||
91 | |||
92 | |||
93 | |((( | ||
94 | **ITIL故事:第5步– 引入** | ||
95 | |||
96 | [[image:1639123311962-491.png||height="49" width="39"]]//Mariana:汽车共享与传统汽车租赁不同。我们希望与客户保持持续的关系,并且客户必须对法律以及他们对汽车共享俱乐部中其他驾驶员的义务负责。// | ||
97 | |||
98 | [[image:1639123322395-843.png||height="47" width="35"]]**S**//olmaz:我们已经为客户建立了会员等级。他们中的一些人将成为常规用户,而某些人将不再需要汽车。普通客户将支付月租费和较低的预订费,而很少使用的客户将支付较高的预订费以避免月租费。我们所有的客户都需要完成相同的引入流程。// | ||
99 | |||
100 | [[image:1639123311962-491.png||height="49" width="39"]]//Mariana:在我们的引入过程中,我们请客户同意他们将遵守所有驾驶法规。这包括关于遵守交通信号灯和标志,不在酒精或毒品影响下驾驶的法律以及停车法。我们还要求所有客户在使用我们的汽车时携带驾驶执照和其他身份证明。// | ||
101 | ))) | ||
102 | |||
![]() |
20.1 | 103 | [[image:1639123345078-830.png]] |
![]() |
12.2 | 104 | |
105 | |||
106 | == 7.1 规划引入 == | ||
107 | |||
108 | 引入规划实际上是将一种或多种服务产品的引入方法适应于该引入计划的范围和背景的行为。引入计划应该考虑服务关系的当前状况、引入计划的范围、资源的当前配置以及相关的风险。 | ||
109 | |||
110 | |||
111 | 规划引入计划是客户和服务提供者之间的协作。客户参与: | ||
112 | |||
113 | * 定义引入目标和相关指标 | ||
114 | * 确定引入所覆盖的服务提供者和服务消费者资源((访问和集成) | ||
115 | * 规划引入行动,包括时间表和职责 | ||
116 | * 审核并接受引入计划。 | ||
117 | |||
118 | 引入计划应该回答以下问题: | ||
119 | |||
120 | * 引入目标是什么? | ||
121 | * 引入范围是什么? | ||
122 | * 引入行动是什么? | ||
123 | * 谁负责引入行动? | ||
124 | * 如何控制引入并确保其成功? | ||
125 | |||
126 | === 7.1.1 引入目标 === | ||
127 | |||
128 | 服务提供者应该与利益相关者就引入目标定义、同意并构建认知。引入目标应在每个引入计划的背景中定义。引入目标的示例包括: | ||
129 | |||
130 | * 确保服务消费者顺利迁移到协议服务 | ||
131 | * 确保服务消费者从内部技术平台平稳迁移到云 | ||
132 | * 支持所选服务的用户数量的临时增加 | ||
133 | * 支持服务消费者从一个(第三方)供应商切换到另一个。 | ||
134 | |||
135 | 应该根据议定的目标(成果)来评估引入的成功,而不是仅仅检查计划的引入行动(输出)的进度和完成情况。 | ||
136 | |||
137 | |||
138 | 负责与服务消费者之间的关系以及范围内产品和服务管理的团队,应设定引入目标。 这些人可能扮演以下角色: | ||
139 | |||
140 | * 产品负责人 | ||
141 | * 服务负责人 | ||
142 | * 客户经理 | ||
143 | * 关系经理 | ||
144 | * 业务合作伙伴。 | ||
145 | |||
146 | 在服务消费者方面,客户有责任同意引入的目标,并将其传达给组织内的相关利益相关方,以及组织的合作伙伴和供应商(如果它们是引入的一部分或受其影响)。 | ||
147 | |||
148 | |||
149 | 在关键利益相关方接受引入目标之后,应通过详细的引入计划使引入方法适应计划的背景。计划由服务提供者驱动。但是,服务消费者代表将被告知、被咨询或对此负责,因为引入是一项联合行动,可能需要双方大量资源。 | ||
150 | |||
151 | |||
152 | == 7.1.2 引入范围 == | ||
153 | |||
154 | 要定义引入的范围,应考虑以下问题: | ||
155 | |||
156 | * 需要引入的消费者资源是什么? | ||
157 | * 引入需要哪些提供者资源? | ||
158 | * 引入什么时候开始和结束? | ||
159 | |||
160 | 引入方法有望回答所有这些问题,但是每个引入计划都需要根据该计划的范围,对引入方法进行审查和调整。 | ||
161 | |||
162 | |||
163 | 表7.2概述了与服务管理四维模型有关的消费者资源引入的可能范围。 | ||
164 | |||
165 | |||
166 | 表7.2 引入的消费者资源示例 | ||
167 | |||
168 | (% style="width:842px" %) | ||
169 | |**服务管理维度**|(% style="width:296px" %)**资源实例**|(% style="width:427px" %)**需要引入的示例** | ||
170 | |组织和人员|(% style="width:296px" %)用户(消费者组织的雇员)|(% style="width:427px" %)为了有效利用服务,用户需要接受有关服务使用和支持设置方面的培训 | ||
171 | |价值流和流程|(% style="width:296px" %)消费者组织程序、动作和工作流程|(% style="width:427px" %)应调整程序以整合服务、技术和服务提供商人员 | ||
172 | |信息和技术|(% style="width:296px" %)消费者组织的技术、数据和IT服务|(% style="width:427px" %)应该授予服务提供商代表访问消费者组织的IT资源的权限; IT资源应与服务提供商的IT资源整合在一起; 数据和信息应迁移和/或转换 | ||
173 | |合作伙伴和供应商|(% style="width:296px" %)用户(消费者组织的供应商和合作伙伴的雇员充当新服务用户)|(% style="width:427px" %)用户(代表消费者组织的供应商和合作伙伴)需要使用服务和支持程序方面的培训 | ||
174 | |||
175 | 引入方法将影响一个或多个资源。当为引入方案创建引入计划时,服务提供者应基于引入方法识别需要引入的特定资源和所需的操作。 | ||
176 | |||
177 | |||
178 | 对于客户旅程,引入暗示以下或类似的场景之一: | ||
179 | |||
180 | * 引入新的服务消费者组织开始使用一系列服务 | ||
181 | * 在现有服务消费者组织内加入新客户 | ||
182 | * 引入现有客户开始使用一系列新服务 | ||
183 | * 从其它服务提供者迁移服务消费者 | ||
184 | * 从其它服务提供者迁移服务和/或生产。 | ||
185 | |||
186 | 这些场景旨在连接服务提供者资源和服务消费者,服务消费者可能涉及多个服务、用户、位置和供应商。最复杂的引入计划可以作为项目或项目群来运行。在设计产品和服务时,服务提供者旨在最大程度地减少引入的成本,并使服务消费的启动变得无缝和便捷。 | ||
187 | |||
188 | |||
189 | 对于用户旅程,引入意味着以下或类似的场景之一: | ||
190 | |||
191 | * 引入新的用户开始使用一项或多项服务 | ||
192 | * 引入现有的用户以开始使用一项或多项服务 | ||
193 | * 引入现有用户切换到一个或多个服务的较新版本 | ||
194 | * 将现有的用户从当前的服务迁移到另一个服务。 | ||
195 | |||
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 | === 7.1.3 引入客户和用户:引入活动 === | ||
221 | |||
222 | 在同意引入计划的范围之后,应规划引入活动。根据引入计划的范围和规模,以及组织的政策、规则和实践,用于计划的方法和工具可能会有所不同。表7.3提供了可能为服务管理四维模型资源计划的引入活动示例。 | ||
223 | |||
224 | |||
225 | 表7.3中的示例描述了服务提供者、服务消费者和服务消费者的合作伙伴/供应商如何参与引入计划。可以根据应该与服务消费者进行交互的资源类型来定义更具体的操作。例如,向服务消费者介绍服务提供者的应用程序可能需要进行在线培训,但是在研讨会上向他们介绍服务提供者员工会更好。 | ||
226 | |||
227 | |||
228 | 用户引入是用户体验的重要组成部分。当向个人消费者提供服务时,客户和用户引入通常会合并在一起,并且引入操作涵盖了这两个方面。当向大型组织提供服务,并且客户和用户的角色可能会分开时,客户和服务提供者将一起计划用户引入活动。这可能会导致从消费者组织的角度描述引入方法。 | ||
229 | |||
230 | |||
231 | 在许多情况下,尤其是为个人消费者提供服务时,服务提供商会标准化引入并使之自动化。这通常是通过使用高度标准化和兼容的IT解决方案来实现,例如通用平台、标准库和协议、微服务等。无缝引入通常由以下因素维护: | ||
232 | |||
233 | * 多语言界面 | ||
234 | * 高度直观的界面 | ||
235 | * 高可用性支持,包括自助服务和同行支持 | ||
236 | * 自动化软件安装和更新 | ||
237 | * 跨平台可用性。 | ||
238 | |||
239 | 表7.3 服务提供者、服务消费者和供应商/合作伙伴引入活动的示例 | ||
240 | |||
![]() |
24.1 | 241 | (% style="width:870px" %) |
242 | |(% style="width:116px" %)**服务消费者资源即将启用**|(% style="width:232px" %)**服务提供者执行的引入活动**|(% style="width:256px" %)**服务消费者执行的引入活动**|(% style="width:265px" %)**服务消费者的合作伙伴/ 供应商执行的引入活动** | ||
![]() |
23.1 | 243 | |(% style="width:116px" %)服务消费者的组织和人员|(% style="width:232px" %)((( |
![]() |
12.2 | 244 | 提供培训和培训材料 |
245 | |||
246 | 介绍了联系和支持界面 | ||
247 | |||
248 | 授予用户访问服务的权限 | ||
249 | |||
250 | 传达了必要的警告(安全和责任)以及条款和条件 | ||
251 | |||
252 | 成立治理组织 | ||
![]() |
24.1 | 253 | )))|(% style="width:256px" %)((( |
![]() |
12.2 | 254 | 用户学习培训材料(阅读、参加培训、学习教程等) |
255 | |||
256 | 组织同意并分配了使用新服务的责任 | ||
257 | |||
258 | 角色和/或团队已更改以优化服务消费 | ||
259 | |||
260 | 组织变革管理 | ||
![]() |
24.1 | 261 | )))|(% style="width:265px" %)((( |
![]() |
12.2 | 262 | 如果供应商服务受引入影响,则提供培训和培训材料 |
263 | |||
264 | 对服务的访问权限进行审查并在需要时进行更改 | ||
265 | ))) | ||
![]() |
23.1 | 266 | |(% style="width:116px" %)服务消费者的信息和技术|(% style="width:232px" %)((( |
![]() |
12.2 | 267 | 信息系统集成 |
268 | |||
269 | 数据迁移和/或转换,建立数据交换 | ||
270 | |||
271 | 进行必要的配置和自定义 | ||
272 | |||
273 | 部署了监视工具和其他操作工具 | ||
274 | |||
275 | 建立了数据交换协议、集成和工具 | ||
![]() |
24.1 | 276 | )))|(% style="width:256px" %)((( |
![]() |
12.2 | 277 | 服务提供者的专家可以访问信息资源 |
278 | |||
279 | 信息系统与服务提供者的系统集成在一起 | ||
280 | |||
281 | 冗余信息系统已停用 | ||
282 | |||
283 | 建立了数据交换协议、集成和工具 | ||
![]() |
24.1 | 284 | )))|(% style="width:265px" %)((( |
![]() |
12.2 | 285 | 受引入影响的服务变更(基础架构支持) |
286 | |||
287 | 服务消费者委托合作伙伴/供应商执行的任何操作 | ||
288 | ))) | ||
![]() |
23.1 | 289 | |(% style="width:116px" %)服务消费者的价值流和流程|(% style="width:232px" %)((( |
![]() |
12.2 | 290 | 同意服务提供商参与服务消费者的流程; 角色、职责得到同意、分配和测试 |
291 | |||
292 | 在需要的地方提供流程改进咨询 | ||
![]() |
24.1 | 293 | )))|(% style="width:256px" %)((( |
![]() |
12.2 | 294 | 为服务消费更改/优化组织流程 |
295 | |||
296 | 价值流得到优化,以最大化服务价值 | ||
297 | |||
298 | 冗余程序(由服务替换或自动化)被删除或更新 | ||
![]() |
24.1 | 299 | )))|(% style="width:265px" %)((( |
![]() |
12.2 | 300 | 审核合作伙伴/供应商对服务消费者流程的参与;在需要时就角色、职责进行约定、、分配和测试 |
301 | |||
302 | 在需要的地方提供流程改进咨询 | ||
303 | ))) | ||
![]() |
23.1 | 304 | |(% style="width:116px" %)服务消费者的合作伙伴和供应商|(% style="width:232px" %)((( |
![]() |
12.2 | 305 | 服务消费者的合作伙伴/供应商的授权代表可以使用服务 |
306 | |||
307 | 在需要时提供退役/迁移协助 | ||
![]() |
24.1 | 308 | )))|(% style="width:256px" %)((( |
![]() |
12.2 | 309 | 与合作伙伴/供应商的合同已更新,以适应新的流程和价值流 |
310 | |||
311 | 冗余(替换)服务的合同被取消或更改 | ||
312 | |||
313 | 传达服务的新/变更要求 | ||
![]() |
24.1 | 314 | )))|(% style="width:265px" %)((( |
![]() |
12.2 | 315 | 必要时对合同进行审查和更新 |
316 | |||
317 | 作为用户的供应商代表应学习所需的材料(通过阅读、参加培训、学习教程等) | ||
318 | ))) | ||
319 | |||
320 | 但是,在许多引入计划中,用户需要引起极大关注,并且必须将其引入新服务,包括所有四个维度的资源。这种类型的用户引入通常与客户引入相吻合,在客户引入中,向大量用户提供了一项或多项新服务。表7.4概述了用户引入活动类型的示例。 | ||
321 | |||
322 | |||
323 | 表7.4 用户引入活动的示例 | ||
324 | |||
325 | |**服务**|**动作** | ||
326 | |技术(应用和设备)|((( | ||
327 | 在线教程、正式培训、模拟器、自定进度的培训,以及各种形式的手册 | ||
328 | |||
329 | 指导安装和设置 | ||
330 | |||
331 | 培训超级用户以领导同行 | ||
332 | ))) | ||
333 | |流程(活动和过程)|((( | ||
334 | 海报、手册和培训 | ||
335 | |||
336 | 演练和指导 | ||
337 | |||
338 | 根据用户的动机来激发正确的行为 | ||
339 | |||
340 | 阻止访问旧的工作方式 | ||
341 | ))) | ||
342 | |提供者的人员(操作和支持)|((( | ||
343 | 面对面或虚拟介绍,联合研讨会和培训 | ||
344 | |||
345 | 通讯录和明确的角色描述 | ||
346 | |||
347 | 团队建设 | ||
348 | ))) | ||
349 | |第三方人员(操作和支持)|((( | ||
350 | 面对面或虚拟介绍,联合研讨会以及培训, | ||
351 | |||
352 | 通讯录和明确的角色描述 | ||
353 | |||
354 | 团队建设 | ||
355 | ))) | ||
356 | |||
357 | 这些引入活动受多种ITIL惯例的支持,包括: | ||
358 | |||
359 | * 变更使能 | ||
360 | * 部署管理 | ||
361 | * 组织变革管理 | ||
362 | * 项目管理 | ||
363 | * 发布管理 | ||
364 | * 服务台 | ||
365 | * 服务请求管理 | ||
366 | * 劳动力和人才管理。 | ||
367 | |||
368 | === 7.1.4 引入控制 === | ||
369 | |||
370 | 当规划引入计划时,必须就控制和验证技术的方法达成一致,以确保计划成功。这种方法通常由引入计划的管理决定来主导。表7.5列出了根据情况可以组合的各种可用选项。 | ||
371 | |||
372 | |||
373 | 保持简单实用的指导性原则适用于引入控制。在许多情况下,最好将引入的控制定义为引入方法的一部分。但是,与引入方法的其他组件一样,应在规划期间对其进行检查和调整。 | ||
374 | |||
375 | |||
376 | 对已完成的引入计划的正式评审可能是有价值的练习。根据引入控制的一般方法,评审可能包括以下内容: | ||
377 | |||
378 | * 正式确认所有计划的引入活动均已完成 | ||
379 | * 评审用户、客户和其他利益相关者的满意度和体验 | ||
380 | * 评审未决的操作和错误 | ||
381 | * 风险评估 | ||
382 | * 持续改进实践的改进登记 | ||
383 | |||
384 | 表7.5 引入控制方法示例 | ||
385 | |||
386 | |**引入计划的管理方式**|**如何控制和验证引入进度和成功**|**ITIL实践支持方法**|**适用性** | ||
387 | |项目集|项目集和项目计划、工作包、评审和KPI|组织变革管理、项目管理|大型客户和用户引入计划需要对各种资源进行复杂的更改 | ||
388 | |项目|项目计划、工作包、评审和KPI|组织变革管理、项目管理|企业服务的大多数服务消费者引入计划 | ||
389 | |一般变更|自定义清单|变更使能、部署管理、组织变革管理、发布管理、服务验证和测试|较小的服务消费者引入计划,主要是向现有消费者引入新服务的地方 | ||
390 | |标准变更|预定义清单|变更使能、部署管理,组织变革管理、发布管理以及服务验证和测试|企业服务的大多数用户引入计划 | ||
391 | |自动化部署和发布(例如,即插即用)|预装的自动化测试和控制|部署管理、基础架构和平台管理、监控和事态管理,发布管理以及软件开发和管理|提供给个人服务消费者的大多数数字服务引入计划,以及企业服务的许多用户引入计划 | ||
392 | |审计与保证|第三方审核、审计意见、保证书、现场检查等|信息安全管理、度量和报告、风险管理和供应商管理|正式服务关系或高度管制环境中的关系 | ||
393 | |||
394 | 引入评审可能会导致下述各种改进: | ||
395 | |||
396 | * 产品、服务和服务提供设计 | ||
397 | * 用户接口和程序 | ||
398 | * 服务组合 | ||
399 | * 服务目录 | ||
400 | * 与合作伙伴和供应商的关系 | ||
401 | * 服务提供者的管理实践 | ||
402 | * 正在进行的引入计划和举措 | ||
403 | |||
404 | |((( | ||
405 | **ITIL故事:规划引入** | ||
406 | |||
407 | [[image:1639123531858-955.png||height="42" width="41"]]//Mariana:引入的目标是确保客户对使用电动车的各个方面感到满意。他们还需要知道如何预订车辆,并且必须同意在我们的道路上以合法和负责任的方式行事。// | ||
408 | |||
409 | [[image:1639123541408-541.png||height="51" width="33"]]**R**//adhika:在我们能够将其发布给我们的第一批客户之前,指导视频经过了一些规划。艾克苏没有专门的电动汽车教育视频,而汽车共享是该公司的一项新服务。客户需要事先做出一些决定,例如他们首选的会员等级。// | ||
410 | |||
411 | [[image:1639123531858-955.png||height="42" width="41"]]//Mariana:我们还希望能够参考视频中的巴西法律法规。艾克苏提供了预算,将视频制作外包给一个小的本地团队,其中包括一名作家、导演和两个演员。我们拍摄了汽车收藏、汽车充电和事件报告。我们还介绍了如何联系道路救援,以及如何计划可能包括公共充电站的旅程。此外,我们希望确保视频中有多种语言的字幕,因为该大学拥有大量的国际学生和教职员工。// | ||
412 | |||
413 | [[image:1639123548518-524.png||height="52" width="40"]]**S**//olmaz:我们的第一批客户对引入给予了积极的反馈。新车共享客户在第一个月内致电服务台的电话,每个客户不超过两次。// | ||
414 | ))) | ||
415 | |||
416 | == 7.2 与用户相关并建立关系 == | ||
417 | |||
418 | 由于服务提供者与服务消费者的技术和信息进行了更多的交互,因此某些服务不包括服务提供者与用户之间的广泛交互。机器对机器服务(例如IoT设备、技术微服务、信息系统维护和数据存储)是此类服务关系的示例。 | ||
419 | |||
420 | |||
421 | 但是,大量的服务包括活动的、频繁的和重要的接触点以及与服务用户的交互。服务提供者代表、过程和技术(例如用户应用程序和可穿戴/嵌入式技术)是交互式的。 | ||
422 | |||
423 | |||
424 | 当用户与服务提供者交互时,用户体验成为服务成功的关键因素。糟糕的用户体验导致生产效率下降,并给服务和服务提供者带来负面印象。这意味着服务提供者和客户在客户旅程的所有步骤中都应注意用户体验。对于任何包含直接用户交互作用的服务,积极的用户体验应该是最重要的要求之一。 | ||
425 | |||
426 | |||
427 | 如果客户对用户体验的关注不足或对用户体验的要求不明确,那么创建积极的用户体验仍然很重要。服务提供者应该与用户一起培育关系,即使客户并不直接要求它也是如此。 | ||
428 | |||
429 | |||
430 | 用户体验应该被视为产品和服务的设计、开发、测试,过渡到运行环境,持续交付以及定期评估和评审的一部分。它也应该是持续改进的主题。 | ||
431 | |||
432 | |||
433 | 用户引入会影响用户对服务和服务提供者的态度。对于成功的服务消费而言,这很重要,因为它可以实现价值的价值共创,并有助于与用户和消费者组织建立和维护可持续的关系。 | ||
434 | |||
435 | |||
436 | |||
437 | === 7.2.1 建立与企业用户的关系 === | ||
438 | |||
439 | 在大型组织环境中,用户引入通常是由组织所使用的服务的更改,用户组的更改(例如组织中的新成员)或人员角色和职位的更改触发的。 | ||
440 | |||
441 | |||
442 | 当服务消费者组织大于几个人时,用户和客户角色之间的区别变得明显且重要。客户成为组织的代表,并就新的和更改的服务与服务提供者进行沟通。这可能会导致首次用户交互出现在引入期间。在某些情况下,用户不愿接受新的服务或更改的服务,也拒绝引入。这种抵制可能会影响服务的整体生产效率和价值。 | ||
443 | |||
444 | |||
445 | 为了防止抵制新服务并建立良好的关系,服务消费者和服务提供者组织应该在客户旅程的每个步骤中共同努力。这可以通过以下方式完成: | ||
446 | |||
447 | * 考虑客户体验在客户旅程的每个步骤中如何受到影响 | ||
448 | * 规划用户引入作为每个新服务实施的一部分 | ||
449 | * 实行组织变革管理 | ||
450 | * 让用户参与需求表达 | ||
451 | * 让用户参与测试服务和引入活动 | ||
452 | * 设计用户友好的界面 | ||
453 | * 理解和利用人们作为私人用户的体验及其相关期望 | ||
454 | * 提供有用、方便且相关的服务目录,包括服务请求目录 | ||
455 | * 持续监控用户满意度以改进服务体验 | ||
456 | * 让用户参与服务测试、评估和审查 | ||
457 | * 让有影响力的用户参与服务推广和对等同行支持计划 | ||
458 | * 培育用户社区并积极支持其成员 | ||
459 | * 对画像执行服务使用情况分析,并主动使用实时终端用户计算数据。 | ||
460 | |||
461 | 当组织的用户社区的变化触发引入时,IT服务引入可能会成为更广泛的引入计划的一部分。这包括人力资源、法律、财务和其他团队。在这些情况下,重要的是要确保与包括内部和外部服务提供程序在内的多方进行有效的集成和交互。这会影响用户对组织的看法。为了成功引入新用户,需要特别关注所涉及服务提供者之间的集成和一致性。使单个团队或角色负责用户/员工引入可能会很有用;这可以是人力资源团队/ 角色,也可以是专注于用户参与和福利的团队/ 角色。 | ||
462 | |||
463 | |||
464 | 当企业用户参与进来时,保持联系和参与很重要。用于此目的的工具和技术包括: | ||
465 | |||
466 | * 服务提供者积极支持的具有用户组和对等同行支持的企业社交网络 | ||
467 | * 使用便捷的渠道,可提供有效且高度可用的服务台 | ||
468 | * 用户参与的服务评审和改进 | ||
469 | * 仪表板和报告让用户社区可以清楚地了解服务质量。 | ||
470 | |||
471 | === 7.2.2与个人消费者一起培育关系 === | ||
472 | |||
473 | 当服务消费者是个人时,有很多因素会影响服务提供者在客户旅程期间如何管理服务关系。表7.6列出了其中一些因素。 | ||
474 | |||
475 | |||
476 | 表7.6 与个人服务消费者的关系管理 | ||
477 | |||
![]() |
25.1 | 478 | (% style="width:828px" %) |
479 | |**步骤**|(% style="width:376px" %)**挑战性**|(% style="width:363px" %)**服务提供商应用的示例解决方案** | ||
480 | |探索|(% style="width:376px" %)((( | ||
![]() |
12.2 | 481 | 服务消费者未明确表达其需求和期望 |
482 | |||
483 | 有时服务消费者没有意识到他们的需求和机会 | ||
484 | |||
485 | 个人意见不一定代表更大的消费群体的需求 | ||
![]() |
25.1 | 486 | )))|(% style="width:363px" %)((( |
![]() |
12.2 | 487 | 市场营销和社会学调查 |
488 | |||
489 | 有代表性的小组进行的安全失效实验 | ||
490 | |||
491 | 旨在提高认识和创造需求的营销活动 | ||
492 | ))) | ||
![]() |
25.1 | 493 | |契动|(% style="width:376px" %)((( |
![]() |
12.2 | 494 | 由于用户数量众多且服务提供者的能力有限,因此个人面对面的联系通常是不可能或效率低下的 |
495 | |||
496 | 售前和售后受到严格监管,以保护消费者权益 | ||
497 | |||
498 | 社区、影响者和同行的意见对于最初的契动决定很重要 | ||
![]() |
25.1 | 499 | )))|(% style="width:363px" %)((( |
![]() |
12.2 | 500 | 使用相关渠道和媒体公开广告 |
501 | |||
502 | 广泛使用社交媒体、影响者和用户群体 | ||
503 | |||
504 | 使用直接营销和对等的代理商 | ||
505 | |||
506 | 基于对用户互联网活动的监视、搜索引擎优化以及其他针对目标受众的工具的情境广告 | ||
507 | |||
508 | 优化基于互联网的服务目录(网站、登录页面、社交媒体帐户等) | ||
509 | |||
510 | 在相关和合理的情况下,销售和支持办公室网络 | ||
511 | ))) | ||
![]() |
25.1 | 512 | |供应|(% style="width:376px" %)((( |
![]() |
12.2 | 513 | 大量的服务消费者 |
514 | |||
515 | 需要简单快捷的签约程序和界面 | ||
![]() |
25.1 | 516 | )))|(% style="width:363px" %)((( |
![]() |
12.2 | 517 | 标准服务目录、合同和协议 |
518 | |||
519 | 目录和协议中的用户友好的简单语言描述 | ||
520 | |||
521 | 广泛使用移动平台和应用程序 | ||
522 | ))) | ||
![]() |
25.1 | 523 | |同意|(% style="width:376px" %)((( |
![]() |
12.2 | 524 | 高水平的国际、国家和行业法规 |
525 | |||
526 | 需要简单明确的语言 | ||
![]() |
25.1 | 527 | )))|(% style="width:363px" %)((( |
![]() |
12.2 | 528 | 高度自动化的签约,广泛使用数字文档和签名 |
529 | |||
530 | 与电子支付系统(卡、PayPal等)集成 | ||
531 | |||
532 | 自动尽职调查检查(如果适用) | ||
533 | ))) | ||
![]() |
25.1 | 534 | |引入|(% style="width:376px" %)((( |
![]() |
12.2 | 535 | 大量具有不同技能和背景的服务消费者 |
536 | |||
537 | 需要简单快速的引入 | ||
538 | |||
539 | 不同的技术背景 | ||
![]() |
25.1 | 540 | )))|(% style="width:363px" %)((( |
![]() |
12.2 | 541 | 自动化的介绍和初步培训 |
542 | |||
543 | 经过严格测试的引入说明和规程 | ||
544 | |||
545 | 有关用户支持资源的专门章节,以帮助引入 | ||
546 | |||
547 | 自动化资格和兼容性检查 | ||
548 | ))) | ||
![]() |
25.1 | 549 | |价值共创|(% style="width:376px" %)((( |
![]() |
12.2 | 550 | 大量具有不同技能和背景的服务消费者 |
551 | |||
552 | 不同的技术背景 | ||
553 | |||
554 | 不同的语言和沟通技巧 | ||
555 | |||
556 | 通过社交媒体高度暴露用户体验和意见 | ||
![]() |
25.1 | 557 | )))|(% style="width:363px" %)((( |
![]() |
12.2 | 558 | 可用、方便且最新的在线状态支持常规业务 |
559 | |||
560 | 为具有技能、背景和能力的用户优化的界面 | ||
561 | |||
562 | 便捷的支持和沟通渠道(电话、支持办公室、社交媒体帐户、直接消息传递) | ||
563 | |||
564 | 社交媒体监控,并在投诉和其他问题时提供积极支持 | ||
565 | |||
566 | 促进用户社区成为服务提供商及对等同行支持的渠道 | ||
567 | |||
568 | 主动沟通(尤其是在重大事件时)、透明度和高可用性 | ||
569 | |||
570 | 利用媒体和营销手段进行损害控制和被动式声明 | ||
571 | |||
572 | 监视和事态管理以主动纠正服务质量偏差,或联系服务使用者 | ||
573 | ))) | ||
574 | |((( | ||
575 | 实现 | ||
576 | |||
577 | 价值 | ||
![]() |
25.1 | 578 | )))|(% style="width:376px" %)((( |
![]() |
12.2 | 579 | 大量服务消费者 |
580 | |||
581 | 个人经验对服务质量和满意度统计的影响很小 | ||
582 | |||
583 | 对每个服务消费者进行直接服务评估的效率低下或不可能 | ||
584 | |||
585 | 服务支持的不同期望和需求 | ||
![]() |
25.1 | 586 | )))|(% style="width:363px" %)((( |
![]() |
12.2 | 587 | 用于服务质量监控和报告的自动化接口, |
588 | |||
589 | 持续监控社交媒体反馈 | ||
590 | |||
591 | 对用户满意度和态度的独立调查 | ||
592 | |||
593 | 使用用户忠诚度指标(例如,净推荐值) | ||
594 | |||
595 | 使用自动体验指标 | ||
596 | |||
597 | 服务消费者要求的服务评估专用支持渠道 | ||
598 | ))) | ||
599 | |||
600 | 服务提供者可以控制有关这些因素的决策。但是,与个人服务消费者的关系可能要遵守组织必须遵守的规定。例如,预期或法律上要求服务提供者要特别考虑残疾用户。 | ||
601 | |||
602 | |||
603 | 为了使服务取得成功,用户(个人和公司)可以通过有效的渠道和接口访问用于选择、引入、使用、支持和评审的服务尤为重要。 | ||
604 | |||
605 | |||
606 | |((( | ||
607 | **示例** | ||
608 | |||
609 | 英国监管机构要求移动通信提供商制定并遵循政策和规范,以确保公平、恰当地对待弱势消费者,他们或因年龄、身体或学习障碍、身体或精神疾病、识字率低、沟通困难而脆弱,或因情势变化而脆弱,例如丧亲。 | ||
610 | |||
611 | |||
612 | 这些政策和做法应解决: | ||
613 | |||
614 | * 关键功能的可访问界面 | ||
615 | * 通过高度可访问的界面访问重要信息 | ||
616 | * 获得紧急服务 | ||
617 | * 优先故障修复 | ||
618 | * 第三方账单管理 | ||
619 | * 无障碍格式的票据和合同 | ||
620 | * 数据保护。 | ||
621 | ))) | ||
622 | |||
623 | == 7.3 提供用户参与和交付渠道 == | ||
624 | |||
625 | 重要的是要建立适当的用户参与和交付渠道,以提供良好的用户体验。 | ||
626 | |||
627 | |||
628 | 用户使用社交媒体、聊天、热线和电子邮件等渠道与服务提供者进行互动。他们还可以在每个用户旅程中使用多个渠道。例如,用户可以通过自助门户网站报告事件,通过电子邮件为该事件中提供更多的信息,通过电话询问状况,并通过在线聊天回复服务提供者的问题。 跨所有渠道、接触点和服务交互来管理用户体验称为全渠道管理。 全渠道管理的目的是为用户提供无缝的用户旅程。 这些原理如图7.1所示。 | ||
629 | |||
630 | (% style="text-align:center" %) | ||
631 | [[image:1639123629885-318.png]] | ||
632 | |||
633 | |||
634 | 图7.1 通过全渠道管理实现无缝的用户旅程 | ||
635 | |||
636 | |||
637 | 随着技术的发展,服务提供者会对其进行测试,并将其用于服务交付,并在适用的情况下为用户提供支持以及客户和用户旅程的其他步骤。影响选择和设计的趋势包括: | ||
638 | |||
639 | * 许多服务提供者尝试将左移法应用于服务支持。这可能包括将一些支持任务从服务提供者转移到用户,以及扩大自助服务选项的范围。说明,视频教程和逐步向导可以支持此方法。 | ||
640 | * 许多服务提供商将社交媒体用于对等和服务提供者支持。该方法被广泛用于提供给可能是社交网络中活跃用户的个人用户的服务,并且通常由多个渠道来启用。 | ||
641 | * 用户期望公司和个人服务提供他们习惯的体验,并且是基于他们日常的智能手机、个人计算机、可穿戴设备和常用应用程序的使用。为了满足此需求,服务提供商使用或模拟熟悉的接口来为其服务提供交付和支持。他们还更新了这些接口,以与操作系统、移动设备、流行的应用程序和社交网络的发展保持一致。 | ||
642 | * 一个普遍的趋势是使用机器学习功能来自动化用户支持。聊天机器人是这种方法的一个示例。这可能包括人工认知支持、自然语言理解及处理和翻译、自动语音识别以及在与服务提供者联系之前和期间预测用户行为。 | ||
643 | * 机器学习还可以用于基于用户画像和服务消费模式的优化支持和交付渠道。这可能包括高级路径,以找到针对用户的最佳支持代理或资源,包括基于技能、基于语言、基于国家/地区、基于产品、基于客户和基于技术的路径。 | ||
644 | * 对自动界面不满意时,许多用户珍视与人工支持代理进行交谈的机会,尤其是在发生事件的情况下。为了满足这种需求,一些服务提供者通过电话、电子邮件、聊天或社交媒体引入,重新引入或改进人工支持。使用这种方法时,确保高可用性和快速响应尤其重要。在某些情况下,物理上的存在(例如在现场中心中)仍然是联系服务提供者的最理想方式。 | ||
645 | * 为基于技术的服务提供远程用户支持时,通常的做法是使用带有视频功能的移动设备,以允许支持代理查看用户正在疲于应付的设备和应用程序。这可能是支持缺乏技术技能的用户的有效方法。 | ||
646 | * 监控和事态管理技术帮助服务提供者远程主动地监视、管理和修复服务组件,从而使用户在请求支持时无需执行诊断操作。 | ||
647 | |||
648 | 这些方法与服务提供者必须考虑的挑战有关。表7.7说明了其中一些挑战。 | ||
649 | |||
650 | |||
651 | 表7.7 服务提供者必须考虑的全渠道挑战示例 | ||
652 | |||
653 | |||
654 | |**方法**|**挑战示例**|**解决方案示例** | ||
655 | |左移,增加自助服务|((( | ||
656 | 用户没有足够的技术技能和/或动力来使用自助服务工具 | ||
657 | |||
658 | 用户在访问服务的级别上只能完成有限的任务 | ||
659 | |||
660 | 用户在自助服务期间犯的错误可能导致更多事件 | ||
661 | |||
662 | 基于知识的导航可能很困难 | ||
663 | )))|((( | ||
664 | 实施自助服务之前,评估用户技能和可用的支持行动范围 | ||
665 | |||
666 | 与具有代表性的用户组全面测试所有自助服务说明和工具 | ||
667 | |||
668 | 确保自助服务工具和操作安全且易于使用 | ||
669 | |||
670 | 改善信息质量和导航工具 | ||
671 | ))) | ||
672 | |社交媒体支持|((( | ||
673 | 情绪化且难以控制的沟通方式 | ||
674 | |||
675 | 病毒效应、容易出错和发生冲突 | ||
676 | |||
677 | 非结构化信息 | ||
678 | |||
679 | 多个渠道进行监控和回复 | ||
680 | |||
681 | 处理个人和合同信息方面的限制 | ||
682 | |||
683 | 没有集成的诊断工具 | ||
684 | |||
685 | 没有正式记录系统在服务提供者的控制之下 | ||
686 | )))|((( | ||
687 | 培训社交媒体传播中的支持人员 | ||
688 | |||
689 | 使用标签和服务/服务提供商的其他提及来自动监视用户证据 | ||
690 | |||
691 | 将社交媒体渠道与专门的支持系统集成。 保留记录并处理这些系统中的敏感信息 | ||
692 | |||
693 | 确保用户对社交媒体的所有支持请求都得到迅速响应并处理得令其满意 | ||
694 | ))) | ||
695 | |熟悉的界面|((( | ||
696 | 服务提供者使用的旧版系统可能会限制兼容性和接口设计 | ||
697 | |||
698 | 常用的应用程序和操作系统不断发展,通常多个平台和版本共存 | ||
699 | |||
700 | 一些服务需要专门的设备和接口 | ||
701 | )))|((( | ||
702 | 设计产品和服务以实现持续发展和灵活性,最大程度地减少使用大一统的和旧的产品 | ||
703 | |||
704 | 考虑提供适合不同平台用户的界面 | ||
705 | |||
706 | 提供自定义接口时,进行可用性设计,并在可能的情况下遵循常用服务和接口的使用模式 | ||
707 | ))) | ||
708 | |机器学习:聊天机器人|((( | ||
709 | 适用范围有限 | ||
710 | |||
711 | 机器学习的数据不足和不恰当 | ||
712 | |||
713 | 多语言支持的困难 | ||
714 | )))|((( | ||
715 | 在成功程度足够高之前,请勿使用基于机器学习的人机界面来代替; 提供人工备份 | ||
716 | |||
717 | 迭代地扩展基于机器学习的服务交互的范围,包括多个反馈循环 | ||
718 | |||
719 | 不断提高用于与用户进行服务交互的所有语言的数据质量 | ||
720 | |||
721 | 跟踪和利用机器学习方面的发展 | ||
722 | ))) | ||
723 | |机器学习:优化的交付渠道|((( | ||
724 | 适用范围有限 | ||
725 | |||
726 | 机器学习的数据不足和不恰当 | ||
727 | |||
728 | 用户行为和支持组织的改变 | ||
729 | |||
730 | 资源有限,无法支持多个渠道 | ||
731 | )))|((( | ||
732 | 关注最重要和最受欢迎的支持方式 | ||
733 | |||
734 | 确保高质量的支持历史记录数据 | ||
735 | |||
736 | 优化,然后自动化 | ||
737 | |||
738 | 与经验丰富的支持代理商一起将新技术解决方案付诸实施 | ||
739 | ))) | ||
740 | |终端支持人员|((( | ||
741 | 扩展性有限 | ||
742 | |||
743 | 错误的可能性 | ||
744 | |||
745 | 情绪态度 | ||
746 | |||
747 | 高成本 | ||
748 | )))|((( | ||
749 | 支持人员的动力、忠诚度和专业发展 | ||
750 | |||
751 | 将人工支持限制在需要和合理的情况下 | ||
752 | |||
753 | 考虑点对点同行支持以增加可伸缩性并优化成本 | ||
754 | ))) | ||
755 | |视频诊断|((( | ||
756 | 用户设备的使用可能会受到技术、法律和法规监管的限制 | ||
757 | |||
758 | 隐私问题 | ||
759 | |||
760 | 使用视频数据可能会给用户带来额外的费用 | ||
761 | )))|((( | ||
762 | 警告用户可能的风险和成本 | ||
763 | |||
764 | 确保符合适用法规 | ||
765 | |||
766 | 实施控制措施以防止滥用技术 | ||
767 | ))) | ||
768 | |增强监控|技术和隐私限制,尤其是在使用服务消费者的基础架构提供服务时|((( | ||
769 | 与客户讨论收益、风险和成本,考虑与用户讨论 | ||
770 | |||
771 | 确保符合适用法规 | ||
772 | |||
773 | 实施控制措施以防止滥用技术 | ||
774 | ))) | ||
775 | |||
776 | 只有将这些方法编排为无缝的用户支持体验时,才能获得专注于用户的真正全渠道支持。这可以通过以下方式完成: | ||
777 | |||
778 | * 跨所有渠道唯一地识别和辨识用户 | ||
779 | * 系统地收集和分析用户数据 | ||
780 | * 利用所有遇到的用户数据 | ||
781 | * 监控并管理所有用户旅程中的绩效。 | ||
782 | |||
783 | 在公司环境中提供服务时,通常很容易同意与用户进行交互的渠道。但是,人们希望他们在工作场所的体验与在家一样顺畅舒适。。服务提供者必须响应此需求,并提供更广泛的渠道和接口。这可能包括在没有加强数据保护的情况下,通过个人设备或公司设备提供业务服务。服务提供者和服务消费者在讨论并协定服务时应考虑收益、风险和成本。 | ||
784 | |||
785 | |||
786 | 如表7.7所示,有可能克服这些挑战。但是,表7.7中列出的解决方案只能在财务、技术或组织方面有足够的资源才能应用。所需资源的示例包括: | ||
787 | |||
788 | * 服务提供者团队和用户的技能和能力 | ||
789 | * 用于支持的数据质量 | ||
790 | * 接口的效率和可用性 | ||
791 | * 与参与支持互动的供应商和合作伙伴整合 | ||
792 | * 确保符合安全以及法律和法规要求 | ||
793 | * 远程支持的连接性,包括用户端的支持 | ||
794 | |||
795 | 选择和设计服务渠道时要考虑的一个重要因素是用户准备使用服务以及相关的风险和机遇。 | ||
796 | |||
797 | |||
798 | |((( | ||
799 | **ITIL的故事:提供用户参与和交付渠道** | ||
800 | |||
801 | [[image:1639123694155-801.png||height="45" width="40"]]//Mariana:eCampus Car Share是一款新的服务,我们尚未完全了解客户的业务活动模式。随着服务的成熟,我们将学习他们的定期通勤和旅程。然后,我们将能够使用推送通知来提醒他们即将发生的事件,例如周末节日或工作日封路。。// | ||
802 | |||
803 | [[image:1639123701310-435.png||height="48" width="31"]]**S**//olmaz:我们可以使用社交媒体和在线实时视频流来使客户了解有关流动流量和事件的最新信息。// | ||
804 | ))) | ||
805 | |||
806 | == 7.4 使用户能够使用服务 == | ||
807 | |||
808 | 某些服务需要特殊的用户技能。这些技能可能包括使用某些应用程序或设备,或者了解在使用服务的环境中安全操作的规则。例如,要被允许租用汽车,要求一个人具有有效的驾驶执照,该执照可证明根据特定国家/地区接受的交通法规来驾驶某种类型的汽车。 | ||
809 | |||
810 | 要启用用户,服务提供者应考虑: | ||
811 | |||
812 | * 向相关利益相关者收集需求 | ||
813 | * 根据要求采取措施 | ||
814 | * 控制实施并不断检查需求的相关性。 | ||
815 | |||
816 | 对于许多服务,都有某些要求。为了使用户能够正确、安全和有效地使用这些服务,应在用户开始使用该服务之前满足这些要求。某些要求是由监管机构定义的;一些则是由服务消费者和服务提供者组织推出的。 | ||
817 | |||
818 | |||
819 | 同样重要的是,确保用户在使用服务目录或请求支持时,只能看到他们有权使用的服务以及可以使用的级别。适当的访问级别,再加上正确清晰地显示可用选项,有助于改进用户体验,防止混乱并降低信息安全风险。 | ||
820 | |||
821 | |||
822 | 这些要求可能需要: | ||
823 | |||
824 | * 尽职调查,只有具有一定访问权限的人员才可以访问服务中提供的信息和技术。 | ||
825 | * 用户培训和认证,只有具有公认的知识和技能的人才能使用某些服务。 | ||
826 | * 安全培训和认证,只有具有安全规程知识的人才能使用某些服务。 | ||
827 | * 年龄控制和身份检查,只有经过验证身份的用户才能访问某些服务或服务级别。 | ||
828 | * 有效管理对服务、服务目录和支持接口的访问。 | ||
829 | * 有效的服务目录展示,包括服务请求目录。 | ||
830 | * 其他措施,以确保用户有权使用服务。 | ||
831 | |||
832 | 这些措施中的许多都可以作为引入计划的一部分。有些可能需要定期确认,以作为持续消费的一部分。服务消费者和服务提供者组织应在提议和协定步骤上就措施达成一致。 | ||
833 | |||
834 | |||
835 | 业务分析、部署管理、信息安全管理、服务目录管理、服务设计、服务台和服务级别管理实践用于确保捕获用户需求,提供给相关方,满足并定期进行审查。 | ||
836 | |||
837 | |||
838 | 服务目录管理和服务台的实践对于用户引入尤其重要。这些做法可确保在用户旅程的各个步骤中为用户提供有效且友好的界面。 | ||
839 | |||
840 | |||
841 | 为了启用和有效地提供用户服务(包括用户对可用新服务和相关服务请求的认知),面向用户的服务目录应该: | ||
842 | |||
843 | * 以合理的方式进行结构化,以反映用户的需求和活动方式 | ||
844 | * 以清晰易懂的语言呈现 | ||
845 | * 仅包含与用户相关的服务(并且已可用或已提供) | ||
846 | * 包括服务和相关的服务请求 | ||
847 | * 保持最新 | ||
848 | * 具有可操作性(并且在可能的情况下,对于用户有资格执行的操作是自动的,例如对服务级别和发起服务请求的细微更改)。 | ||
849 | |||
850 | 服务台实践有助于有效的用户引入,从而使用户能够参与用户旅程的所有步骤。它提供了各种用户接口,使用户能够以最方便的方式联系服务提供者。这可能包括: | ||
851 | |||
852 | * 移动应用程序,可以与流行的语音接口集成 | ||
853 | * 由机器学习提供支持的联机帮助资源,例如聊天机器人和基于上下文的知识文章 | ||
854 | * 在线工具访问受限的情况下,为用户提供电话热线 | ||
855 | * 现场支持区域。 | ||
856 | |||
857 | 服务台应该为所有相关类型的用户查询提供接口。这包括咨询、事件、服务请求、投诉和表扬。 | ||
858 | |||
859 | |||
860 | 服务台的界面和渠道应确保能力有限的用户具有访问权限。 | ||
861 | |||
862 | |||
863 | 这可能包括暂时或永久位于覆盖范围有限的区域,或遇到技术或通讯困难的用户。服务台还应该使用适当的界面来联系用户以获取反馈、满意度调查等。 | ||
864 | |||
865 | |||
866 | |((( | ||
867 | **ITIL的故事:为用户提供服务** | ||
868 | |||
869 | [[image:1639123784450-617.png||height="42" width="37"]]//Mariana:在eCampus Car Share,我们对客户有一定的要求,以使他们能够租用我们的汽车。例如,所有客户都必须具有有效的驾驶执照才能预订汽车。他们还必须知道如何使用电动汽车并为其充电。// | ||
870 | |||
871 | [[image:1639123792517-180.png||height="49" width="34"]]**S**//olmaz:我们将概述客户的需求,以便通过我们的网站和预订应用程序租用我们的汽车。// | ||
872 | |||
873 | [[image:1639123784450-617.png||height="42" width="37"]]//Mariana:当客户到场取车时,我们会对其所有文件进行彻底检查,以确保他们符合合规性的所有必要规定,以能够租车。// | ||
874 | |||
875 | [[image:1639123792517-180.png||height="49" width="34"]]**S**//olmaz:作为引入的一部分,我们检查客户是否熟悉电动车,如果不熟悉,我们会为供应提供他们更多的信息和指导,以确保他们在使用汽车时有顺畅的体验。我们为客户提供有关如何为汽车充电和使用的教学视频访问权。// | ||
876 | |||
877 | [[image:1639123784450-617.png||height="42" width="37"]]//Mariana:我们还会为他们提供充电站和城市路线图、有关交通流量和拥堵的最新信息,以及有关如何使用汽车来帮助他们获得良好体验的常见问题和建议。// | ||
878 | ))) | ||
879 | |||
880 | == 7.5 提升彼此的能力 == | ||
881 | |||
882 | 服务关系涉及所有利益相关者的价值共创。每次服务交互都是提升另一方能力的机会。表7.8解释了如何将每个ITIL指导原则用于一个小组,以提高另一组的能力。 | ||
883 | |||
884 | |||
885 | 表7.8 服务提供者和客户利用ITIL 指导原则提高用户能力的示例 | ||
886 | |||
![]() |
26.1 | 887 | (% style="width:1047px" %) |
888 | |(% style="width:130px" %)**指导原则**|(% style="width:915px" %)**优化用户能力的应用示例** | ||
889 | |(% style="width:130px" %)聚焦价值|(% style="width:915px" %)用户应了解其工作目的和背景以及服务使用情况。 应鼓励他们提供可能有助于价值共创的服务改进。 | ||
890 | |(% style="width:130px" %)从当前开始|(% style="width:915px" %)用户体验的改善应基于当前的做法、习惯和期望。 用户体验中的根本性变化很少被视为改善,并且经常受到用户的抵制。 | ||
891 | |(% style="width:130px" %)基于反馈不断迭代|(% style="width:915px" %)对用户要求、服务交付和评估、服务使用过程以及用户体验的其他方面的所有更改,均应进行测试,并根据用户反馈进行持续审查。 应鼓励用户提供反馈,反馈的后续行动对用户社区应该是透明的。 | ||
892 | |(% style="width:130px" %)合作并提高知名度|(% style="width:915px" %)在需要联合运营的情况下,用户应了解协作的要求并相互帮助,服务提供商、合作伙伴和供应商以及其他相关方也同样如此。 如果服务无法按预期运行,或者用户不知道如何使用服务,则应安全,轻松并鼓励其寻求帮助或报告事件。 | ||
893 | |(% style="width:130px" %)全面思考和工作|(% style="width:915px" %)服务及其在价值共创中的作用应对所有相关方透明可见。 用户应了解其工作和依赖项的背景。 | ||
894 | |(% style="width:130px" %)保持简单实用|(% style="width:915px" %)用户界面和所有其他接触点应尽可能简单。 用户应具有提出改进界面的方法,并且应该认真透明地对待这些提议。 | ||
895 | |(% style="width:130px" %)优化和自动化|(% style="width:915px" %)用户体验的持续优化和自动化应该是用户和服务提供商之间所有接触点和服务交互的主题。 | ||
![]() |
12.2 | 896 | |
897 | 为了帮助用户和客户变得更好,服务提供者可以考虑使用以下技术: | ||
898 | |||
899 | * 根据角色向特定的用户组、角色和用户特征提供有针对性的用户培训。 | ||
900 | * 考虑将培训重点放在用户的需求而不是产品上。 | ||
901 | * 向用户和客户介绍服务提供者工作中令人兴奋的方面,并强调合作与协作的机会。 | ||
902 | * 促进负责任的服务使用,尤其是在消费需要大量资源或收费基于数量或时间的情况下。 | ||
903 | * 在早期阶段让用户和客户参与服务更改的讨论,以收集反馈并确保参与。 | ||
904 | * 创建一个舒适的环境,使用户可以放心地报告问题和提出问题。 | ||
905 | * 邀请用户和客户提出改进服务关系的方法,包括界面、过程和服务。 | ||
906 | * 建立并支持用户社区,并在适用时让多个服务消费者参与。 | ||
907 | * 让超级用户帮助其他人采用新服务。 | ||
908 | |||
909 | 这些方法大多数都适用于服务过程中的几个步骤,包括引入。 | ||
910 | |||
911 | |||
912 | 服务消费者组织可以考虑使用以下技术来帮助其服务提供者进行改进: | ||
913 | |||
914 | * 邀请服务提供者的团队直接观察服务消费者的业务。 | ||
915 | * 让参与服务提供的所有团队参与其中,并演示如何使用服务以及它们如何影响服务消费者的业务。 | ||
916 | * 尽早使服务提供者参与有关组织、流程和技术的相关更改的讨论。 | ||
917 | * 提供有关服务关系各个级别的反馈,并提供公众评论以促进跨组织的用户社区。 | ||
918 | * 与服务提供者组成联合专家团队。 | ||
919 | |||
920 | 当在组织中共享和支持所有方法,并且持续改进时,所有方法都可以更好地发挥作用。 | ||
921 | |||
922 | |||
923 | |((( | ||
924 | **ITIL的故事:提升共同能力** | ||
925 | |||
![]() |
19.1 | 926 | [[image:1639124333710-206.png||height="36" width="30"]]//Mariana:eCampus Car Share运行了最初的几个月后,我们引入了游戏化。当顾客取车时,他们希望汽车清洁并充满电。我们要求客户在取车时给他们的车辆进行星级评价。这些评分被赋予前一个驾驶员的个人资料。// |
![]() |
12.2 | 927 | |
![]() |
19.1 | 928 | [[image:1639124343281-805.png||height="49" width="34"]]//Radhika:驾驶员获得的积分越多,他们在排行榜上的地位就越高,对于一直获得五星级评价的任何人,抽奖可在下次预订时提供折扣。// |
![]() |
12.2 | 929 | |
![]() |
19.1 | 930 | [[image:1639124353057-972.png||height="50" width="39"]]//Solmaz:这不仅使我们的客户受益,而且有助于我们确保每次预订后都对汽车进行清洁和充电。这为我们节省了一些维护成本,最重要的是,它支持出色的客户体验。// |
![]() |
12.2 | 931 | ))) |
932 | |||
933 | == 7.9 撤销客户与用户 == | ||
934 | |||
935 | 与引入类似,应将撤销的动作和职责预先定义为产品和服务设计的一部分,然后针对特定的引入/ 撤销计划进行调整。当两个服务都由同一服务提供者管理时,此方法有效。这类示例诸如,用户在组织中的位置发生了变化,这可能导致用户使用的服务范围的变化。 | ||
936 | |||
![]() |
19.1 | 937 | |
![]() |
12.2 | 938 | 撤销的重要问题包括信息安全和资产管理。重要的是要确保外来用户没有特定的访问权限,并且必须安全地存储他们的创建、使用或有权访问的信息,并且仅对授权用户可用。同样,重要的是要确保先前包含在服务提供中的物理和数字资产在用户撤销后,得到正确地归档、重用、撤回或以其他方式处理。软件许可证或个人设备,例如笔记本电脑和移动电话,就是需要适当撤销的示例。 |
939 | |||
![]() |
19.1 | 940 | |
![]() |
12.2 | 941 | 变更使能、信息安全管理、IT资产管理和服务配置管理实践对成功撤销至关重要。如果相关,还可能需要其他实践。组织变革管理实践可能会支持大规模的撤销。 |
942 | |||
![]() |
19.1 | 943 | |
![]() |
12.2 | 944 | 撤销计划应按照与引入计划相同的原则进行审查,并应改善服务关系的相同领域。 |
945 | |||
![]() |
19.1 | 946 | |
![]() |
12.2 | 947 | 当服务消费者因不满意或纠纷而离开时,确定原因很重要。在这些情况下,在无冲突的环境中流程的每个步骤都已商定时,同意并准备好撤销以确保无缝的撤销就尤为重要。此外,双方应注意不要加剧任何冲突或对任何其他方造成伤害;他们应同意对争端保密。当预期将采取后续法律行动时,这一点尤其重要。 |
948 | |||
![]() |
19.1 | 949 | |
![]() |
12.2 | 950 | === 7.9.1 客户撤销 === |
951 | |||
952 | 当服务协议期满或终止时,由服务提供者执行客户撤销。撤销动作通常包括: | ||
953 | |||
954 | * 与所有相关的利益相关者,包括用户、客户、相关的合作伙伴/供应商和监管机构,就计划的服务终止进行沟通 | ||
955 | * 响应任何要求进一步信息或其他支持的用户 | ||
956 | * 组织和执行从服务消费者到服务提供者的设备移交 | ||
957 | * 删除服务消费者场所中一直在运行的任何服务提供者资源 | ||
958 | * 撤消任何一方对另一方资源的访问权限(如果适用) | ||
959 | * 存档和保留记录 | ||
960 | * 计算和处理退出付款,包括双方未偿还的金额 | ||
961 | * 更改与终止的服务相关的第三方合同,例如支持技术服务、保险等 | ||
962 | * 保留双方同意和/或适用法规要求的正式撤销记录 | ||
963 | * 执行与处境相关的关系管理动作,例如闭门会议、感谢信、恢复服务关系的邀请等。 | ||
964 | |||
965 | 这些操作适用于大多数客户撤销场景。具体操作取决于服务的性质以及撤销计划的范围。有些操作由服务提供者或服务消费者执行,而有些可能需要协作。这些通常在引入步骤中事先约定,但可能需要在撤销开始之前进一步鉴证。 | ||
966 | |||
![]() |
19.1 | 967 | |
![]() |
12.2 | 968 | 撤销的一种更复杂的现代方法是服务提供者之间的合作,其中包括相互的撤销协议。在这些情况下,新的服务提供者将服务消费者替换为旧的服务提供者。这是很常见的,因为在提供商之间进行切换是很普遍的,并且受到法律的监管。 |
969 | |||
![]() |
19.1 | 970 | |
![]() |
12.2 | 971 | 切换服务提供者可能涉及第三方;例如,共享基础架构的提供者既充当新服务提供者又充当旧服务提供者。 |
972 | |||
![]() |
19.1 | 973 | |
![]() |
12.2 | 974 | 表7.9 提供者切换操作示例 |
![]() |
19.1 | 975 | |
976 | |**服务管理的维度**|**切换操作示例** | ||
977 | |组织和人员|((( | ||
978 | 更改用户访问权限 | ||
979 | |||
980 | 更改服务提供者的访问权限 | ||
981 | ))) | ||
982 | |价值流和流程|((( | ||
983 | 更改共同行动的责任 | ||
984 | |||
985 | 更改程序和接口 | ||
986 | ))) | ||
987 | |信息和技术|((( | ||
988 | 频道切换 | ||
989 | |||
990 | 设备安装和卸载 | ||
991 | |||
992 | 系统集成 | ||
993 | |||
994 | 记录存档 | ||
995 | ))) | ||
996 | |合作伙伴和供应商|与服务提供者和服务消费者的供应商和合作伙伴终止、切换和建立合同 | ||
997 | |||
998 | 关于切换提供者的撤销动作类似于服务终止操作;它们应该涵盖表7.9中概述的所有服务管理四维模型。 | ||
999 | |||
1000 | |||
1001 | 许多ITIL 管理实践都支持撤销,包括: | ||
1002 | |||
1003 | * 变更使能 | ||
1004 | * 部署管理 | ||
1005 | * 基础设施和平台管理 | ||
1006 | * IT资产管理 | ||
1007 | * 发布管理 | ||
1008 | * 服务配置管理 | ||
1009 | * 服务级别管理 | ||
1010 | * 软件开发和管理。 | ||
1011 | |||
1012 | 大规模的撤销和切换计划可能需要组织变革管理和项目管理实践来协调撤销动作,并确保所涉及的组织成功实施了变更。 | ||
1013 | |||
1014 | |||
1015 | === 7.6.2 用户撤销 === | ||
1016 | |||
1017 | 用户撤销可能是正在进行的服务关系的一部分,而没有服务或合同终止。常见的示例是用户从服务消费者组织辞职或在组织内的职位变化。这些场景应该在客户引入期间预先约定,并根据此方法进行处理(通常作为标准更改)。但是,在某些情况下,例如大规模撤销,可能需要额外的规划和协调。 | ||
1018 | |||
1019 | |||
1020 | 用户撤销通常包括: | ||
1021 | |||
1022 | * 沟通计划中的撤销和用户的相关职责 | ||
1023 | * 与用户互动,以获取有关计划撤销的更多信息或任何其他支持 | ||
1024 | * 组织从用户到服务提供者或服务消费者负责代表的设备移交 | ||
1025 | * 更改或取消用户的访问权限 | ||
1026 | * 通过归档和保留来保护记录 | ||
1027 | * 删除未归档的信息 | ||
1028 | * 维护双方同意和/或适用法规要求的正式撤销记录 | ||
1029 | * 执行关系管理操作,例如闭幕会议、撰写感谢信等。 | ||
1030 | |||
1031 | 正式程度取决于服务关系。例如,当服务提供者位于服务消费者组织内部时,正式程度可能会较低,并且服务消费者代表(例如用户的经理)可能会执行某些操作。 | ||
1032 | |||
1033 | |||
1034 | 随后,撤销应该使用户感到舒适。服务提供者致力于使撤销动作自动化,并最大程度地降低其对所有相关方的日常业务基础的影响。 | ||
1035 | |||
1036 | (% style="width:1187px" %) | ||
1037 | |(% style="width:1184px" %)((( | ||
1038 | **ITIL的故事:撤销客户和用户** | ||
1039 | |||
1040 | [[image:1639124431523-355.png||height="46" width="38"]]//Mariana:最初,我们预计完成最后一年学习的学生会希望自动退订eCampus Car Share。但是,我们的商业活动模式表明,很多学生选择保留自己的会员资格,这通常是在他们选择继续学业或加入教职员工的情况下。因此,我们不得不重新考虑我们的计划以自动撤销客户。// | ||
1041 | |||
1042 | [[image:1639124439796-946.png||height="45" width="39"]]//Radhika:我们还发现,学生通常希望在每个学年结束时取消其会员资格,以节省每月的订阅费用。但是,当他们注册第二年时,他们不想再次完成教学视频。// | ||
1043 | |||
1044 | [[image:1639124431523-355.png||height="46" width="38"]]//Mariana:我们为学生提供了将其会员级别变更到无需每月订阅费用级别的可能。这意味着他们更有可能保留其会员资格,也意味着他们在整个夏季继续接受我们的营销。在新学期开始时,学生可以再次变更其会员级别。// | ||
1045 | |||
1046 | [[image:1639124450170-484.png||height="50" width="40"]]**S**//olmaz:撤销流程的一部分包括向我们的客户贷记所有剩余的会费。通过使流程自动化,我们不需要花费时间手动释放费用。// | ||
1047 | ))) | ||
1048 | |||
1049 | == 7.7 总结 == | ||
1050 | |||
1051 | 为了从协议发展到服务提供和消费,各方必须经历一种过渡,其中涉及服务提供者和服务消费者资源的整合或分离。应将此方法定义为服务设计的一部分,并且应该相应地计划、运行和控制引入或撤销活动。引入的主要活动包括建立用户关系、协调全渠道访问,使用户能够使用服务以及提升彼此的能力。 | ||
1052 | |||
1053 |