Wiki source code of 05. 步骤3：供应

Version 29.1 by superadmin on 2024/04/03, 16:35
Show last authors
1
2
3
4 [[阅读下一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E9%A9%B1%E5%8A%A8%E5%88%A9%E7%9B%8A%E7%9B%B8%E5%85%B3%E8%80%85%E4%BB%B7%E5%80%BC%E3%80%8BDSV/6.%20%E6%AD%A5%E9%AA%A44%EF%BC%9A%E5%8D%8F%E8%AE%AE/]]  [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E9%A9%B1%E5%8A%A8%E5%88%A9%E7%9B%8A%E7%9B%B8%E5%85%B3%E8%80%85%E4%BB%B7%E5%80%BC%E3%80%8BDSV/4.%20%E6%AD%A5%E9%AA%A42%EF%BC%9A%E5%A5%91%E5%8A%A8/]]
5
6 {{box cssClass="floatinginfobox" title="**Contents**"}}
7 {{toc/}}
8 {{/box}}
9
10 = **5. 步骤3：供应** =
11
12
13 [[image:1639115614664-761.png]]
14
15 管理需求和机会
16
17 指定和管理客户需求
18
19 设计服务供应和用户体验
20
21 销售并获得服务产品
22
23
24 客户和服务提供者之间的服务关系越密切，就越能进一步形成客户需求和服务供应。供应步骤有助于客户阐明其需求和要求，并帮助服务提供者设计匹配的服务供应。本章描述了基于价值驱动、数据驱动和以用户为中心的服务设计来确定、设计、销售和获得产品和服务所需的服务交互和接触点。无论服务来自内部还是外部服务提供者，本指南均适用。表5.1概述了形成需求和服务提供的目的。
25
26
27 表5.1 形成需求和服务提供的目的
28
29 (% style="width:464px" %)
30 |(% style="width:83px" %)**供应**|(% style="width:163px" %)**对于服务消费者**|(% style="width:216px" %)**对于服务提供者**
31 |(% style="width:83px" %)促进成果和体验|(% style="width:163px" %)确保客户清楚表达了服务消费者的需求和要求|(% style="width:216px" %)(((
32 了解如何为服务消费者和服务提供者创建价值，以及服务提供者如何支持该价值共创
33
34 使服务提供者能够平衡供应和需求
35 )))
36 |(% style="width:83px" %)优化风险和合规性|(% style="width:163px" %)(((
37 最小化购买服务而不满足实际需要的风险
38
39 减少供应商误解消费者需求的风险
40 )))|(% style="width:216px" %)(((
41 尽量减少无法履行承诺服务的风险
42
43 尽量减少客户不满意的风险
44 )))
45 |(% style="width:83px" %)优化资源并最小化成本|(% style="width:163px" %)确保将资金投资于能够优化投资回报的领域|(% style="width:216px" %)确保在最佳区域使用时间和资源
46
47 |(((
48 **ITIL故事：步骤3 – 供应**
49
50 [[image:1639115675132-360.png||height="51" width="47"]]//Mariana：我们的eCampus汽车共享服务已受到大学学生和员工的欢迎。我们为普通汽车用户提供订阅会员资格，为间歇性用户提供不同的定价等级。我们的汽车是电动的，这使它们比传统的汽车更环保，因为它们排放的废气更少。另外，汽车共享会降低汽车拥有率，减少道路上的汽车行驶次数，并减少客户出行次数，因为客户会将差事合并为一次出行以最大程度地增加支出。我们为自己能提供一个干净、安全、可靠的往返于校园的其他交通选择而自豪。//
51 )))
52
53 (% class="wikigeneratedid" %)
54 == ==
55
56 == 5.1 管理需求和机会 ==
57
58
59 就服务而言，需求和容量是相互关联的。服务无法存储供以后使用。当服务价值只有在服务提供者的供给满足服务使用者的需求时才能被共同创造。如果需求得不到满足，设施和资源就会浪费。同样，当需求高于容量时，也会丢失机会。为了优化服务机会，服务提供者应调整容量和影响需求。正确理解不同的客户群体和部门如何使用其服务至关重要。
60
61
62
63 === 5.1.1 业务活动模式 ===
64
65
66 要了解如何使用服务，分析业务活动的模式很有用的。事实和图表是通过监控和日志记录生成的，反映了服务的使用情况。这些信息将有助于采取措施满足需求高峰。
67
68
69 |(((
70 **定义：业务活动模式（PBA）**
71
72 一个或多个业务活动的工作负载描述。PBA用于帮助服务提供者理解和支持不同级别的服务消费者活动。
73 )))
74
75 表5.2描述了一个会计流程的PBA。
76
77
78 表5.2 会计处理的业务活动模式示例
79
80 (% style="width:333px" %)
81 |(% style="width:55px" %)**角色**|(% style="width:150px" %)**实现价值创建高峰工作量**|(% style="width:125px" %)**高峰时间**
82 |(% style="width:55px" %)雇员|(% style="width:150px" %)所有员工填写工时表|(% style="width:125px" %)每周五午餐后
83 |(% style="width:55px" %)会计|(% style="width:150px" %)获取或构建，报告和质量检查准备工资|(% style="width:125px" %)每月12日至15日
84 |(% style="width:55px" %)会计|(% style="width:150px" %)年终结账|(% style="width:125px" %)每年十一月/十二月
85
86 另一种可以识别的模式是通过分析来电。例如，结果可以表明，所有支助请求中平均有85%是在每个工作日的两个短期间提出的:10:00-11:00和15:00-16:00。服务台还可以看到所需的特定服务。有了这些信息，服务台可以通过在高峰时段提供额外人员或创建自助服务解决方案来管理需求。
87
88
89 业务活动模式非常有用，因为它们允许组织做出基于事实的决策。检测到的模式可以反映不同的趋势。有些模式是重复的，例如表5.2中的示例；其他模式显示增长或下降。一些服务业经历了快速增长，这将对容量产生影响。需要进一步的业务分析来理解总体情况并做出正确的决策。
90
91
92 一旦确定了模式，就可以使用不同的选择来调整和管理容量以形成需求。
93
94
95 === 5.1.2 优化容量 ===
96
97
98 |(((
99 **容量和性能管理实践**
100
101
102 容量和性能管理实践为容量管理提供了三个视角：
103
104 * **业务容量管理 **由客户触发的容量需求计划。
105 * **生产和服务容量管理 **管理特定生产或服务的端到端容量。
106 * **组件容量管理 **监视并调整生产或服务组件的容量。如果其中一个组件没用更多的容量，则整个服务将受到影响。在IT中，大多数组件都可以通过监视和调优进行设置，以避免容量问题。
107
108 读者应参阅容量和性能管理实践指南以了解更多详细信息。
109 )))
110
111 由于容量和需求是相互交织的，为了更好地利用稀缺资源，必须同时考虑两者。管理需求的目的是了解不同的用户概况并影响其行为。容量和性能管理代表等式的另一侧。如图5.1所示，这是关于根据实际需求确定容量大小的问题。
112
113
114 有多种方法可以调整和管理容量。一些措施包括：
115
116 * 在高峰期增加容量
117 * 避免在高峰时段运行其他繁重的工作量
118 * 不允许在变更生产或服务时引入冻结期。
119
120 需求可以是固定的，也可以是可变的。如果需求是可变的，最好的做法可能是将其与可变容量相匹配，以帮助服务消费者将固定成本转换为可变成本。这就是云计算通常的工作方式。客户(例如开发团队)使用灵活的自服务机制，在需要的时候添加额外的基础设施容量，在完成工作时释放它，从而使容量可供其他用户使用。
121
122
123 优化资源容量的另一种方法是将工作量转移到服务消费者。在为数字化转型设计技术服务时，这是相关的。数字化服务允许服务消费者管理自己的银行账户，在线订购机票以及预订自己的航班和酒店，以减轻服务提供者的需求负担，并增加服务消费者对服务的控制。
124
125
126 (% style="text-align:center" %)
127 [[image:1639121095316-395.png]]
128
129 图片5.1容量和供应之间的关系
130
131
132 === 5.1.3 成形或平滑需求 ===
133
134
135 服务提供者经常受到服务需求的巨大差异和有限容量的挑战。如果不能形成与供应相匹配的需求，将导致容量投资的回报率很低。例如，服务台的训练有素的支持人员数量有限。因此，使需求与服务容量相匹配是一项重要的学科。
136
137
138 允许服务消费者提前预订时间的预订服务有助于平滑需求。为了最大程度地减少损失，监控错过预约的比率并以类似比率补偿超额预订是很常见的。服务提供者通常通过延迟承诺时间、增加取消费用、或发送提醒以确保消费者提前一天确认预订来防止风险出现。
139
140
141 服务提供者通常供应价格激励来影响消费者的行为。差别收费是根据使用时间对同一服务收取不同的价格。例如，电力公司可能会在一天的不同时间收取不同的价格。给电动汽车充电最便宜的时间可能是在晚上。这样，运营者可以影响白天的服务容量，同时在非高峰时段实现更好的利用率。
142
143
144 收益管理是一种对利用价格激励来优化容量的技术。这是一个高度自动化的流程，使用历史和实时数据估算未来的需求，并相应地调整价格。例如，当在互联网浏览即将到来的旅行时，如果提前几个月搜索，则价格可能相对较低。然而，随着旅行日期的临近，同一次旅行的价格将大幅上涨。
145
146
147 ==== 5.1.3.1 定价和计费机制 ====
148
149
150 差异性收费和收益管理是使用定价和计费机制管理容量和需求的示例。这些机制可用于驱动服务使用者在服务的许多方面的行为。既然它是如此强大的工具，就应该有意识地使用它来驱动正确的行为。例如，如果云服务提供者希望其服务消费者在不需要时清除容量，则“按单位付费” 策略将正确地影响行为。
151
152
153 计费作为一种需求管理机制存在不利的副作用。这些副作用的一些示例如表5.3所示。应进行适当的评估和测试，以确保定价机制驱动预期行为。这是由思考和整体工作的指导原则和迭代的反馈进展所支持的。
154
155
156 在服务关系中，定价和计费机制应经常进行评估和评价，以确保它们按预期工作。这些机制通常在合同协商阶段就已达成共识，但对它们如何影响行为和价值创造却知之甚少。
157
158 一些重要的问题是：
159
160 * 驱动行为的机制是否以一种对双方都有最大价值的方式存在？
161 * 这些机制是否能够实现资源的双赢和最佳利用？
162 * 双方是否有激励措施来推动服务的改进？
163
164 表5.3 计费机制的不良负作用示例
165
166 [[image:1641543155649-541.png]]
167
168
169 (% class="wikigeneratedid" %)
170 ==== ====
171
172 ==== 5.1.3.2 服务改进点机会 ====
173
174
175 服务质量取决于对改进点机会的管理。来自客户的冲突请求、糟糕的定价激励或缺乏专门的改进点预算可能是冲突的来源。因此，服务提供者必须专业地处理改进点机会。持续改进需要所有权、服务改进点预算和透明的流程，以确定如何识别、捕获、评估、优先级和处理改进点机会。
176
177
178 服务改进点的机会来源广泛。一些示例包括：
179
180 * 服务使用情况分析
181 * 事件、投诉和问题分析
182 * 服务请求模式分析
183 * 自助服务模式分析和知识文章的使用
184 * 变更请求和改进点请求
185 * 用户反馈
186 * 客户反馈和客户满意度调查
187 * 服务需求增加
188 * 新技术和创新
189 * 市场变化
190 * 来自服务提供者团队的反馈。
191
192 目的旨在收集有关服务如何促进利益相关者价值的事实。这是价值驱动和数据驱动洞察力的一个方面。业务分析人员可以协助分析数据、识别需要、阐明需求并推荐解决方案。分析应基于定期且频繁捕获的真实数据。为了加深理解并做出正确的决定，需要进行深入的业务分析。
193
194
195 持续改进实践指南和ITIL®4：指导计划和改进中介绍了有关如何完成结构化服务改进的详细指南。业务分析实践指南中介绍了执行业务分析的任务和技术。
196
197
198
199 === 5.1.4 构建客户商业案例 ===
200
201
202 当需要和需求得到理解和解决时，可以起草通过新的或变更的产品和服务来满足需求的商业案例。
203
204
205 |(((
206 **定义：商业案例**
207
208 组织资源支出的理由，提供有关成本、收益、选择、风险和问题的信息。
209 )))
210
211 商业案例的核心是财务分析，用于评估收益率和风险的支出。此分析应同时考虑定性和定量方面。商业案例为正表示预期收益超过支出和风险。
212
213
214 服务商业案例理想地应覆盖完整的服务的所有区域，从服务消费者用途到产品和资源，如图片1.11所示。它应包括所有相关的收益，成本和风险。
215
216
217 商业案例涉及的主要问题包括：
218
219 * 目的是什么？
220 * 这种新的或变更的服务如何支持组织的战略目标？
221 * 需要解决的问题是什么？
222 * 期望的成果是什么？
223 * 谁是利益相关者，它将如何影响他们？
224 * 预期的收益和损害是什么？
225 * 需要哪些资源和投资？
226 * 预算和预期成本是什么？
227 * 有什么风险？
228 * 流程的时间表是什么？
229 * 我们什么时候需要资源和投资？
230 * 总体拥有成本（TCO）是多少？
231 * 预期的投资回报率（ROI）或净现值（NPV）是多少？
232 * 为了创造价值和实现收益，需要进行哪些组织上的变革？
233
234 商业案例的目的是为明智的决策奠定基础，但它是基于假设的。这些假设存在不确定性，并且常常与需求和利益冲突。不同的视角会影响业务分析人员对用户需求进行优先排序的能力。表5.4突出显示了冲突和不确定性的典型领域。
235
236
237 表5.4 典型冲突和不确定性领域的示例
238
239
240 (% style="width:435px" %)
241 |(% style="width:114px" %)**调查范围**|(% style="width:319px" %)**组织中冲突区域的典型示例**
242 |(% style="width:114px" %)(((
243 **价值**
244
245 **理解真实的需求**
246 )))|(% style="width:319px" %)(((
247 谁是关键利益相关者？如何优先考虑他们的需求？
248
249 服务的用户可能具有与客户/发起人不同的需求和优先级（请参见表5.5）。其他利益相关者组也可能具有相互冲突的需求。
250 )))
251 |(% style="width:114px" %)(((
252 **成果**
253
254 **理解收益**
255 )))|(% style="width:319px" %)可能只考虑短期利益而牺牲长期利益，这很诱人。另一方面，长期收益通常会面临更多的不确定性和风险。
256 |(% style="width:114px" %)(((
257 **成本**
258
259 **理解资本和运营支出**
260 )))|(% style="width:319px" %)我们的生产或服务需要什么样的投资？实施的成本是多少？维护和支持成本是多少？使用成本是多少？需要多少培训？需要什么样的组织变革？
261 |(% style="width:114px" %)(((
262 **风险**
263
264 **理解不确定性和影响**
265 )))|(% style="width:319px" %)很难事先知道服务提供者是否愿意并且能够满足服务消费者的需求。重要的是要从一开始就建立良好的关系，不仅要与销售人员建立联系，而且还要与将成为服务提供关键资源的人员建立联系。在协议和合同中包含建立关系的激励措施和双赢文化是很好的。
266
267 表5.5中描述了优先级与需求冲突的一些传统领域。
268
269
270 表5.5 客户和用户优先级与需求
271
272 [[image:1641543406646-794.png]]
273
274
275 对时间和成本的短期关注可能会在以后造成大量成本：
276
277 * **时间不足** 如果没有足够的时间让用户参与进来，则可能导致他们的需求得不到满足。因此，该服务可能无法让用户更好地完成工作，并可能会导致负面的商业案例。
278 * **选择最便宜的提供者** 在这种情况下，价格和成本承受着巨大的压力，这可能会使服务提供者的利润空间很小，也可能会阻止服务提供者在不亏损的情况下保持灵活性。这可能会导致一种以牺牲价值为代价的紧张关系。
279
280
281
282 === 5.1.5 构建服务提供者商业案例 ===
283
284
285 服务提供者需要构建和维护一个可盈利的、可行的商业案例。否则，服务提供者可能会赔钱，最终倒闭。在构建商业案例时，服务提供者应该考虑客户的商业案例。
286
287
288 在为服务准备商业案例时，确定服务如何适合于现有的和未来的服务组合是非常重要的。组合管理和财务管理实践是这项工作的关键资源。
289
290
291 服务是一种通过促进客户希望实现（想要达到）的结果，而无需客户管理特定成本和风险，从而实现价值共创的一种手段。风险作为服务的一部分转移到服务提供者。
292
293
294 为了建立商业案例，服务提供者需求理解提供服务的成本。要做到这一点，它需要有一个考虑所有所需资源的成本模型。分析所有服务管理四维模型中的成本因素可能会有所帮助。这可以包括以下内容：
295
296 * 服务所依赖的技术和基础架构的投资和管理
297 * 需要价值流和流程才能操作服务并便利所需的成果（运营服务和促进预期结果所需的价值流和流程）
298 * 合作伙伴和供应商，它将成为服务提供的一部分
299 * 组织方面，例如资源数量以及员工的技能和能力。
300
301 许多ITIL 管理实践都可以为客户、组织和服务提供者的新的服务或变更的服务提供输入。这些包括：
302
303 * 可用性管理
304 * 容量和性能管理
305 * 信息安全管理
306 * 组合管理
307 * 关系管理
308 * 服务连续性管理
309 * 服务财务管理。
310
311 |(((
312 (((
313
314
315 **ITIL的故事：管理需求和机遇**
316
317 [[image:1639121261076-787.png||height="49" width="40"]]//Mariana：我们分析了我们服务的业务活动模式，发现需求在学期中期的几周内最高，而在假期期间最低。周末需求低于工作日需求。晚间曾经使用很受欢迎，但最近几个月有所下降。我们将此归功于当地政府针对学生开展的一项运动，该运动旨在告诉学生在酒精或毒品影响下开车的危险性。//
318
319 [[image:1639121269170-649.png||height="61" width="38"]]**S**//olmaz：我们对我们所提供的服务有影响力并能创造需求。例如，我们在非高峰期提供租车折扣，这样我们就可以将一些需求转移到那段时间。这有助于我们在繁忙时期进行容量规划。//
320
321 [[image:1639121279281-823.png||height="52" width="43"]]**R**//adhika：我们已经确定了服务台的两个繁忙时期：学年开始时，客户注册每月订阅；年末，他们会要求退还每月会员费的剩余费用。在此期间，我们增加了服务台的资源。//
322 )))
323
324 (((
325
326 )))
327 )))
328
329 (% class="wikigeneratedid" %)
330 == ==
331
332 (% class="wikigeneratedid" %)
333 == ==
334
335 == 5.2 指定和管理客户要求 ==
336
337
338 需求规范应该出现在可视化线中。理想情况下，客户应该让服务提供者参与到一个开放且透明的需求规范流程中。如果在流程中过早的密封了需求，则服务提供者可能无法形成最佳的服务并满足服务消费者需求。
339
340
341 许多组织利用业务分析人员与与利益相关者进行契动，以引出和分析代表服务提供者或服务消费者需求。业务分析人员将使用本节中描述的许多技术。业务分析实践指南提供了有关此主题的指南。
342
343
344 |(((
345 **定义：业务分析**
346
347 分析业务或业务的某些元素，定义其需求并推荐解决方案以满足这些需求和/或解决业务问题，并为利益相关者创建价值的实践。
348
349 业务分析使组织能够以有意义的方式传达其需求，表达变更的基本原理，并设计和描述支持与组织目标相一致的价值创造的解决方案。
350 )))
351
352 |(((
353 (((
354
355
356 **ITIL故事：指定和管理客户要求**
357
358 [[image:1639121261076-787.png||height="49" width="40"]]//Mariana：我们发现了新的客户需求：我们的许多客户在这一年中不得不搬家。当他们为此目的使用我们的汽车时，他们需要多次出行，并且比往常更频繁地为汽车充电。他们还将较低电荷的汽车退还，从而很难将汽车出租给下一个客户。此外，它还损害了我们提供环境可持续服务的愿景。//
359
360 [[image:1639121269170-649.png||height="61" width="38"]]//Tomas：我鼓励Mariana与艾克苏汽车租赁公司合作，向客户提供拖车，这样他们就可以最大程度地减少出行次数。//
361
362 [[image:1639121279281-823.png||height="52" width="43"]]//Katrina：我的室友们已经离开大学回到欧洲的家中，这是我两个月来第二次不得不搬家！eCampus Car Share公司发现，客户偶尔需要拖车来帮助他们搬家，这真是太棒了。现在，我不必寻找其他选择。//
363 )))
364
365 (((
366
367 )))
368 )))
369
370 (% class="wikigeneratedid" %)
371 === ===
372
373
374 (% class="wikigeneratedid" %)
375 === ===
376
377 === 5.2.1 角色和责任 ===
378
379
380 明确的角色和职责是指定和管理需求的关键。权威人士必须得到识别，并说明如何捕获、表达和表示用户需求和期望。
381
382
383 在大型组织中，客户和用户有时是分开的。结果，期望和要求可能无法协调和统一，如图5.2所示。
384
385 (% style="text-align:center" %)
386 [[image:1639121359204-637.png]]
387
388 图5.2 服务交付三角形：将需求转换为需求所涉及的角色
389
390
391 服务提供者和客户之间需要协商并达成协议的事实可能是一个挑战。为了管理感知到的服务质量，必须对期望和需求进行管理。
392
393
394 因此，服务提供者可能成为客户和用户之间的中介。为防止这种情况发生，服务消费者需要采取有效的沟通和协调措施。
395
396
397 表5.6说明了服务需求规范中涉及的角色和职责编排的一些场景。
398
399
400 表5.6 服务消费者角色和需求规范场景的示例
401
402 [[image:1641543481289-623.png]]
403
404 业务分析人员可以帮助阐明和确定需求的优先级，并将其转换为服务提供者可以理解的语言和格式。这可以用作设计和构建服务的基础。
405
406
407 === 5.2.2 管理需求 ===
408
409
410 不仅应指定要求，还应在整个流程中对其进行管理和跟踪。需求所有者负责：
411
412 * 确定利益相关方群体及其代表
413 * 教育代表代表他们的利益相关者群体清楚地表达需求
414 * 收集、记录、管理、跟踪和沟通需求
415 * 持续确保以正确的方式解释和理解需求
416 * 验证产品和服务符合要求。
417
418 客户的需求不是一成不变的；随着新的知识和经验的获得，客户的需求也会发生变化。因此，确保将需求集中在客户需求上，以使需求的定义与生产或服务的测试之间的时间尽可能短。
419
420
421 需求必须是可测试的。因此，定义如何测试是否满足要求是很重要的。在测试驱动的开发中，需求甚至是由它们必须通过的测试来定义的，以便被认为是满足的。
422
423
424 功用需求确保新的或变更的生产或服务是符合目的。功用需求涵盖了数据、信息和功能要求。
425
426
427 非功能性需求确保新的或变更的生产或服务在限制范围内使用。非功能性需求的类别包括但不限于：
428
429 * 可用性
430 * 可用性和可靠性
431 * 容量和性能
432 * 信息安全
433 * 合规性
434 * 连续性
435 * 可维护性
436 * 可操作性
437 * 可度量性和可报告性
438 * 可扩展性。
439
440
441
442 === 5.2.3 将问题与解决方案分开 ===
443
444
445 我们已经说过，需求应该基于利益相关者需要。然而，指定一个解决方案，而不是将需要转换成需求可能会很有吸引力。在阐明需求时，必须将问题与解决方案分开，以考虑到解决方案无法解决潜在问题的事实。这也有助于将当前的解决方案与所有可能的未来解决方案区分开。表5.7概述了一种简单的技术来帮助完成此流程。
446
447
448 表5.8显示了此技术用于服务库的示例。此外，提炼，模型和演示之类的技术还可以帮助利益相关者确保他们真正解决了潜在的问题。
449
450
451 表5.7 问题规范技术
452
453 (% style="width:509px" %)
454 |(% style="width:82px" %) |(% style="width:185px" %)**当前**|(% style="width:240px" %)**未来**
455 |(% style="width:82px" %)什么？|(% style="width:185px" %)当前问题的本质和需要做的事情的本质|(% style="width:240px" %)真正的需要什么？什么是“本质”？
456 |(% style="width:82px" %)怎么样？|(% style="width:185px" %)当前执行所需工作的方式|(% style="width:240px" %)将来有什么可能的方法来解决问题？
457
458 表5.8 问题规范技术的使用示例
459
460 (% style="width:540px" %)
461 |(% style="width:74px" %) |(% style="width:213px" %)**当前**|(% style="width:252px" %)**未来**
462 |(% style="width:74px" %)什么？|(% style="width:213px" %)一个人需要阅读一本特定的书。|(% style="width:252px" %)一个人需要可以了解一个特定的主题。
463 |(% style="width:74px" %)怎么样？|(% style="width:213px" %)(((
464 去图书馆询问图书管理员。
465
466 图书管理员使用数据库查找图书并登记借出。
467 )))|(% style="width:252px" %)当我们识别问题的本质并探索解决问题的不同方法时，可以采用多种不同的解决方法，包括在线阅读，有声读物，相关文章以及内容摘要。
468
469 (% class="wikigeneratedid" %)
470 === ===
471
472 (% class="wikigeneratedid" %)
473 === ===
474
475 === 5.2.4 最小化可行产品 ===
476
477
478 在Eric Ries (Ries, 2011)所描述的精益创业方法中，关键的信息是制作一个好的商业案例的原型，并在真实的用户中进行测试，以获得反馈。对于原型设计，他依赖于最小可行产品的概念。
479
480
481 最小化可行产品是具有足够功能，来满足早期客户的需求并为将来的生产开发提供反馈的产品。该概念已在敏捷开发中广泛使用：服务提供者根据特定的需求设计最小化可行产品，并相应地指定了需求，然后开发产品并将其交付给用户以收集反馈。反馈用于阐明未来的需求，并且通过迭代的方法，产品将根据需求和优先级进行开发。
482
483
484 |(((
485 **关键信息**
486
487 如云计算、大数据、自动化、机器人、物联网和人工智能等新兴技术，需要新兴产品和服务。最小化可行产品和敏捷开发等概念使新兴的数字产品和服务成为可能。
488 )))
489
490 |(((
491 **ITIL故事：最小可行产品**
492
493 [[image:1639121495793-938.png||height="51" width="45"]]//Mariana：对于我们的拖车租赁，最小化可行产品将不包括任何自动化，例如跟踪或在线预订。当我们测试和证明我们的观念时，客户需要手动预订拖车。//
494
495 [[image:1639121503640-486.png||height="50" width="38"]]**T**//omas：Mariana使用迭代的方法，Mariana发现顾客也需要手推车作为产品供应的一部分。这是她在试租拖车之前没有考虑过的事情。//
496 )))
497
498 (% class="wikigeneratedid" %)
499 === ===
500
501 (% class="wikigeneratedid" %)
502 === ===
503
504 === 5.2.5  用户故事和故事映射 ===
505
506
507 用户故事映射是表达服务需求的常用方法。用户故事是一种表示利益相关者所需功能领域的方式，这种方式可以在团队成员之间引起讨论和理解，帮助他们共同努力，将需求转变为有效的产品和服务。用户故事用于描述生产或服务的片段。该技术可以有不同的用途。
508
509
510 基于人物角色，设计人员可以收集有关客户旅程和需求的数据，并在小而明确的用户故事中清晰的阐明相应的需求。用户故事具有非常具体和简单的形式：用户可能需要某种东西来实现某种利益。例如，一个人可能需要大汽车才能带家人去度假；其他人可能需要在机场用特快专车来接他们去开会。用户故事易于编写、理解、确定优先级和检查。改进和演示可以帮助您以很少的投资来解决问题。
511
512
513 故事映射在不同环境中的处理方式有所不同。映射生产或服务需求的一种常见方法是将生产或服务描述为史诗，然后将史诗分解为特性，然后进一步细分为用户故事。此方法如图5.3所示，并在表5.9中进一步说明。
514
515
516 第一个冲刺提供了最小化可行产品（MVP），该产品发布给用户，用于共同创建价值并收集反馈，然后再将更多的故事添加到生产或服务中。
517
518
519 INVEST首字母缩略词提供了一个有用的提示，即用户故事应为：
520
521 * 独立的
522 * 可讨论的
523 * 有价值的
524 * 可估计的
525 * 小的
526 * 可测试的
527
528 (% style="text-align:center" %)
529 [[image:1639121523248-506.png]]
530
531 图片5.3 故事映射的示例
532
533
534 表5.9 使用史诗、功能、促成因素和故事来阐明需求
535
536 [[image:1641647603766-545.png]]
537
538 故事映射通常与敏捷服务设计方法（例如Scrum方法）结合使用。在Scrum方法中，产品负责人负责对每个冲刺中的用户故事进行优先级排序。在冲刺的末尾，生产团队将向实际用户演示这些功能并收集反馈。
539
540
541 === ​​​​​​​5.2.6 MoSCoW方法 ===
542
543
544 MoSCoW方法是一种用于管理需求的简单优先级排序技术。它可让利益相关者明确地就不同的优先级达成一致。
545
546
547 该方法还涵盖了无法交付的需求。这很有用，因为列表通常会被不必要的需求填满，例如没人需要的报告。这些需求增加了成本却没有增加价值。
548
549
550 MoSCoW的缩写代表：
551
552 * 必须 涵盖最重要需要的强制性需求。
553 * 应该 在可能的情况下应包括的需求。
554 * 可能 如果不影响“应该”或“必须”的需求，那么可以包括的需求。
555 * 不会 本次不包括但可能包含在未来版本的需求。
556
557
558
559 === ​​​​​​​5.2.7 加权最短作业优先 ===
560
561
562 有时需求具有匹配的优先级。在这些情况下，MoSCoW方法可以被更细粒度的技术（例如气泡排序）所取代或与之结合。然而，如果利益相关者的观点需要一致，这些方法可能不可行。
563
564
565 另一种替代方法是使用加权最短作业优先（WSJF）方法（Reinertsen，2009），该方法采用计算机操作系统中使用的调度算法。在这种方法中，作业的权重除以持续时间或规模。特别推荐用于生产或服务开发的权量是延迟成本。延迟成本是一种衡量价值实现程度的指标，以损失的结果和保留的不确定性来度量。在传统的服务管理术语中，延迟成本可视为延迟对服务影响（服务成果），紧急度（时间临界）和风险（不确定性）的结果。对每个作业或需求进行评分，然后根据延迟成本除以持续时间（CD3）对其进行优先级排序。该方法如图5.4所示。
566
567 (% style="text-align:center" %)
568 [[image:1639121576909-947.png]]
569
570 图5.4 延迟成本除以适应服务管理条款的持续时间
571
572
573
574 == ​​​​​​​5.3 设计服务供应和用户体验 ==
575
576
577 现代软件开发方法使新一代数字服务成为可能。这些方法有一个重要的共同点因素：它们在产品和服务的整个设计和的实现流程中都涉及到客户和用户。
578
579
580 价值驱动和数据驱动的服务设计意味着一种基于频繁反馈、持续试验和学习的迭代方法，以确保在设计过程的每个步骤中共同创造价值。这需要服务提供者和服务消费者在不同角色之间进行契动、参与和交互。
581
582
583 服务提供者将提供其在开发方法上的专业知识，但其成功与否将取决于客户契动。客户应该准备好为流程提供最适合的资源，并确保他们有权代表组织做出决策。
584
585
586 重要的是要注意，协议或合同可能会限制敏捷和灵活交付模型的可能性。解决复杂问题时，允许敏捷和灵活的模型的协议是提供者和客户能够在建设性的合作关系中工作的先决条件。
587
588
589 === ​​​​​​​5.3.1 精益思维 ===
590
591
592 精益思维可以被描述为一种流程改进哲学，它将流动效率置于资源效率之上。在精益中，流动是指工作在系统中进行的方式。工作单元可以定义为流经价值流的一件工作。一个好的流动意味着工作单元可以稳定且可预测地移动，而一个坏的流动则描述了一个包含大量队列的系统，其中工作单元将不得不停止并等待。
593
594
595 精益定义了五项基本原则，在表5.10中概述。关于利益相关者价值，这些原则集中于支持设计产品和服务的高效且连续的流动。
596
597
598 表5.10 精益的五项原则
599
600 (% style="width:423px" %)
601 |(% style="width:82px" %)**精益原则**|(% style="width:338px" %)**说明**
602 |(% style="width:82px" %)识别客户价值|(% style="width:338px" %)首先是要了解客户及需要。是什么为客户创建价值？所需的成果是什么？为什么需要它？何时何地需要它？多少？多久一次？
603 |(% style="width:82px" %)映射价值流|(% style="width:338px" %)接下来是了解和映射价值流。从服务提供者接收到来自客户的新的或变更的生产或服务的请求起，就需要设计、构建、转换和交付所需的活动。关键是定义工作单元（请求、生产、服务）并映射它如何流过价值链。每个流代表一个价值流。
604 |(% style="width:82px" %)创建流动|(% style="width:338px" %)工作单元在价值流中可能会遇到几个瓶颈。从工作单元的角度来看，这是浪费。通过消除浪费改进流。
605 |(% style="width:82px" %)建立拉动|(% style="width:338px" %)创建流后，下一步就是将优化转换为价值流。该“拉式” 原则确保不会将工作推向下游。它允许限制批量大小和在制品，以便及时完成工作单元。
606 |(% style="width:82px" %)寻求完美|(% style="width:338px" %)该原则反映了持续改进。
607
608 价值流映射是一种用于说明和分析价值流逻辑的精益技术：一种将从需求/机会到价值的流动可视化的方法，然后计划如何改进该流动。价值流图以图形的方式概述了物料和信息的流动，并指出了需要改进的地方。这是理解活动如何联系和创造价值的良好基础。
609
610
611 关于精益思维如何应用于服务管理的更详细说明请参见ITIL®4：高速IT。
612
613
614 === ​​​​​​​5.3.2 敏捷生产和服务开发 ===
615
616
617 软件开发的敏捷方法始于2001年的敏捷宣言，它鼓励人们优先考虑个人和交互，而不是工作流和工具，工作产品优先于综合文档，客户协作优先于合同，并对计划之后的变更做出响应。
618
619
620 敏捷理念的一个方面是应用精益思维。敏捷开发流程中的工作单元是特性（这是职能有限的一部分），还是促进因素（这是职能的技术前提）。
621
622
623 另一个方面是迭代开发。在Scrum方法中，需求被捕获在待办项中，该需求由产品负责人连续为下一个冲刺分配优先级。开发团队将在冲刺的末尾进行演示，以在冲刺中进行最大程度的开发，以捕获来自实际用户的反馈。在每个冲刺末尾的评审会议上，将评估方法和团队合作精神。
624
625
626 这种方法有助于服务提供者和服务消费者共同成长。他们可以先定义一个最小可行产品，该最小可行产品从合作关系的开始就可以工作并实现价值，然后随着双方的共同成熟，可以在服务功用，功效和体验上进行扩展。
627
628
629 持续部署是敏捷理念的另一方面。这意味着特性和促进因素将被不断集成、测试和部署，以便客户准备就绪后就可以发布它们。这方面需要服务提供者和客户之间紧密的协作，这意味着客户和发布必须连续提供客户。持续部署使用的一些方法包括：
630
631 * **特征开关（特征标记特性中已编程的“开/关”按钮）**。客户准备就绪时，就可以打开特征开关。如果有问题，该功能可以再次关闭。
632 * **暗发布** 新功能已启动，但是在该功能足够成熟之前，新功能的链接是不可见的。
633 * **金丝雀发布** 一个暗发布，邀请一些测试用户测试新功能。
634 * **蓝绿部署** 用来测试两种可选方案中哪一种方案是最好的一种技术。它可以是另一种图形设计或功能。消费者被随机分为两组，测试相同功能的两个不同版本。
635
636 这些技术使快速开发发布和新功能成为可能和安全。
637
638
639 === ​​​​​​​5.3.3 以用户为中心的设计 ===
640
641
642 以用户为中心的设计是一个迭代的设计流程，它使用户置于整个项目流程中所有设计决策的中心。以用户为中心的设计确保生产和服务专注于用户需求和用户体验。
643
644
645 === ​​​​​​​5.3.4 服务设计思维 ===
646
647
648 服务设计思维是解决问题的有效方法。由于该方法的核心是探索、原型，并收集来自真实用户的反馈，因此它是价值驱动、数据驱动和以用户为中心的服务设计的一个很好的例子。它鼓励用户定义价值，并且是一种不断收集有关什么有效和无效的反馈的方法。
649
650
651 服务设计思维流程的最终目标是为最初的挑战确定可取的、可行的和可实行的解决方案。
652
653
654 === ​​​​​​​5.3.5 服务蓝图 ===
655
656
657 蓝图是建筑设计的建筑图纸。这些蓝图描绘了建筑物的外观以及建造所需的所有规格。对于数字化服务，蓝图是可视化服务使用的图表，旨在优化用户体验。
658
659
660 在服务蓝图中，关键元素由三条水平线隔开：
661
662 * **交互线** 这条线确定了客户/ 用户和服务提供者之间的直接服务交互。
663 * **可视化线 **这条线客户和用户可见的服务活动与不可见的活动分开。可见的活动显示在此线上方，不可见的活动显示在此线下方。
664 * **内部交互线** 这条线将联系的员工与不直接支持与客户和用户进行交互的员工区分开来。
665
666 对于一个服务，如果有多个不同的场景，则可能会有多个蓝图。在绘制蓝图时，，从最上面一行开始，然后沿着模板向下，这一点很重要。
667
668
669 图5.5 显示了服务蓝图的示例。
670
671 (% style="text-align:center" %)
672 [[image:1639121634681-607.png]]
673
674 图片5.5 服务蓝图的示例
675
676
677 服务蓝图可用于以下目的：
678
679 * 将客户旅程与生产和服务联系过来
680 * 突显用户接触点和服务交互
681 * 发现弱点并确定优化机会
682 * 努力搭建跨部门的桥梁，避免双重工作量。
683
684 总之，服务蓝图帮助组织了解服务提供者如何实现服务，以及客户和用户如何使用服务。服务蓝图确定了面向员工的流程和面向客户/用户的流程之间的依赖关系。它还可以帮助服务提供者识别痛点，优化复杂的相互，并了解改进服务设计和客户旅程以及降低成本的可能性。
685
686
687 关于如何制作服务蓝图的模板和更多信息可以在业务分析实践指南中找到。
688
689
690 === ​​​​​​​5.3.6 为引入设计 ===
691
692
693 作为以用户为中心方法中的一部分，应该为每个产品、服务和服务供应定义引入方法，并作为设计的一部分，以平滑引入。
694
695
696 文档化的引入方法用于规划引入计划。引入方法包括范围、行动、利益相关者、时间表和其它引入方面。它们可能会根据服务供应的结构，消费者资源、规模、法律和法规要求、风险等等，而有所不同。
697
698
699 一个极端是狭窄的可视化线，而另一个极端（例如广泛的可视化线）可以是综合的转换方案（包括员工和基础设施的转移），实现相关组织之间的集成实施，建立共同的治理结构，和退运旧产品和服务。在服务期间，应仔细计划和测试引入方法。
700
701
702 在定义引入方法和规划引入计划时，组织应考虑服务管理四维模型。它也应该受到外部因素的影响（ITIL Foundation，第3.5节）。
703
704
705 构造引入方法的一种方法是遵循持续改进模型的步骤，如表5.11所示。
706
707
708 表5.11 持续改进模型和引入方法
709
710 (% style="width:419px" %)
711 |(% style="width:141px" %)**持续改进步骤**|(% style="width:275px" %)**引入方法**
712 |(% style="width:141px" %)**愿景是什么？**|(% style="width:275px" %)定义引入的预期结果。
713 |(% style="width:141px" %)**我们现在在哪里？**|(% style="width:275px" %)建立基线并确定引入的范围，包括所需的资源。
714 |(% style="width:141px" %)**我们想去哪里?**|(% style="width:275px" %)定义引入目标，包括资源的理想组合和交互。
715 |(% style="width:141px" %)**我们如何实现目标？**|(% style="width:275px" %)计划引入的行动和责任
716 |(% style="width:141px" %)**采取行动**|(% style="width:275px" %)根据计划运行引入行动
717 |(% style="width:141px" %)**我们做到了吗?**|(% style="width:275px" %)控制和引入并确保其成功：与基线和目标相比较的控制和度量
718 |(% style="width:141px" %)**我们如何保持动力?**|(% style="width:275px" %)评审和改进
719
720 当引入方法被设计为产品、服务或服务供应的一部分时，主要活动包括：
721
722 * 识别将与消费者的资源进行交互的提供者的资源
723 * 识别将与提供者的资源进行交互的消费者的资源
724 * 确定引入每对资源的需求
725 * 探索优化和自动化引入的机会
726 * 创建需要手动或人工控制引入的规程
727 * 测试规程并根据测试结果进行更新（根据需要重复）
728 * 文档化并与有关各方进行沟通。
729
730 以下ITIL实践支持产品和服务的设计，以实现平稳有效的用户引入：
731
732 * 架构管理
733 * 服务设计
734 * 服务级别管理
735 * 服务验证和测试
736 * 软件开发和管理。
737
738 |(((
739 **ITIL的故事：设计服务产品和用户体验**
740
741 [[image:1639121698951-807.png||height="52" width="48"]]//Mariana：我们的拖车租赁在客户中很成功。我们的下一步是迭代构建将拖车的自动预订流程构建到艾克苏’s 的预订应用程序中。在我们的手动迭代中，我们发现包含不同拖车类型的图片是很有用的，以便客户可以确定哪种拖车适合其需求。//
742
743 [[image:1639121707255-977.png||height="54" width="39"]]//Henri：我们将做一个预告片自动预订流程的金丝雀版本，只有几个测试用户。然后，我们可以将其推广给客户，并随着我们的进展而开发功能。//
744 )))
745
746 (% class="wikigeneratedid" %)
747 == ==
748
749 == 5.4 销售并获得服务供应 ==
750
751
752 设计产品、服务和服务供应之后，就需要进行销售。这可能发生在它们构建之前或之后，这取决于服务的性质和服务关系。内部和外部服务提供者都需要销售他们的服务。销售活动将根据客户是内部客户还是外部客户而有所不同。
753
754
755
756 === 5.4.1 定价 ===
757
758
759 定价需要决定客户将被收取多少费用。可以使用许多定价选项为服务定价，如表5.12所示。要使一项服务可行，它必须产生足够的收入来支付投资和成本，并产生利润，除非服务提供者是非营利组织。
760
761
762 对于商业服务提供者，计费与成本的关系较少，而与感知服务的价值和竞争对手提供的类似服务的相对成本的关系较大。在这些情况下，成本模型将显示影响盈利能力之前的最低收费水平。商业服务提供者也可以根据首选定价模型或服务销售的预期价值以及一年中的消费趋势来做出决定。
763
764
765 表5.12 定价选项
766
767 [[image:1641543643896-688.png]]
768
769 (% style="width:546px" %)
770 |(% style="width:543px" %)(((
771 **关键信息**
772
773 在决定一项服务的价格时，应考虑以下几个因素：
774
775 * 服务提供者在传递服务的价值方面有多好？
776 * 客户愿意支付多少？
777 * 市场上有类似的服务吗？
778 * 同类服务的定价如何？
779 * 扩展服务容易？
780 * 引入新客户容易吗？
781 * 这项服务是否可以用来弥补亏损？
782 * 服务提供者有多成熟？
783 * 三重底线方法会影响定价吗？
784
785 在某些情况下，定价可以在短期内用于破坏竞争。
786 )))
787
788 (% class="wikigeneratedid" %)
789 === ===
790
791 === ​​​​​​​5.4.2 内部销售 ===
792
793
794 对内部客户而言，提高对可用服务的认知是销售的第一步。内部销售和促销，综合激励措施和定价机制，对于管理需求非常重要。
795
796
797 向对内部客户销售的一些好处是：
798
799 * 提高现有服务的利用率
800 * 更好的控制服务需求
801 * 改进与客户和用户的沟通
802 * 关于服务如何满足需求的反馈。
803
804 内部销售有助于内部服务提供者的整体客户感知。
805
806
807 内部销售流程中最重要的工具之一是服务目录：一种促进服务的沟通工具。对于服务提供者，它有助于定义并使产品和服务可见。服务目录对于关系管理，促进现有服务以及发现新服务的需求至关重要。在定义服务级别时，它也是服务级别管理的关键工具。
808
809
810 对于服务消费者，最重要的是正在使用的服务。服务台在这方面发挥着关键作用，通常会为用户提供订购表和自助服务系统，并提供有关如何使用产品和服务的必要指导和帮助。因此，服务台将始终是内部销售流程和用户体验的关键贡献者。
811
812
813 有关更多信息，请参考以下ITIL实践：
814
815 * 关系管理
816 * 服务目录管理
817 * 服务台
818 * 服务级别管理
819 * 服务请求管理。
820
821 此外，服务提供者也可以应用大多数用于外部销售的传统技术。
822
823
824 === ​​​​​​​5.4.3 对外销售 ===
825
826
827 外部客户的销售更像是传统的销售技巧，例如广告和销售活动。销售流程取决于服务关系的类型、各方的性质和背景因素。其中包括：
828
829 * 在高度监管的环境和公共部门，获取货品和服务可能会受到监管；某些服务提供者可能已被预授权销售其产品和服务。
830 * 一些服务消费者要求由采购团队完成采购。
831 * 其他人可能已经定义了正式的采购流程，其中包括正式的请求方法，例如信息请求、报价请求、提议请求、概念验证、演示等。
832
833 表5.13显示了请求产品和服务的不同方法
834
835
836 表5.13 请求产品和服务的不同方法
837
838 (% style="width:416px" %)
839 |(% style="width:136px" %)**信息请求**|(% style="width:147px" %)**报价邀请函**|(% style="width:129px" %)**需求建议书**
840 |(% style="width:136px" %)(((
841 收集信息以识别潜在供应商
842
843 当你在寻找信息的时候
844
845 提出一般性问题
846
847 随意的
848
849 快速
850 )))|(% style="width:147px" %)(((
851 针对特定产品或服务的定价请求
852
853 当你知道你需要什么的时候
854
855 询问有关需求的问题
856
857 结构化的
858
859 关注价格
860 )))|(% style="width:129px" %)(((
861 战略性密集建议流程
862
863 当您要比较建议时
864
865 提出特定问题
866
867 正式的
868
869 供应商比较
870 )))
871
872 成功的销售流程取决于良好的沟通、信任和公平。服务提供者应避免为服务创造高于客户价值的价格。服务消费者应避免压低价格，以免服务提供者难以交付。
873
874
875 一个典型的错误是通过促销多种产品和服务来开始销售。相反，服务提供者应该提出问题并倾听。这样，服务提供者在尝试实现客户的需求之前就会了解客户的需求。
876
877
878 重要的是，服务消费者在与潜在的服务提供者进行交谈之前，不要根据过时产品的经验来准备需求清单。相反，他们应该根据实际的需要描述需求，然后听取服务提供者的意见。服务提供者可以根据他们的产品和服务组合以及与其他客户的以往经验，提供新的更好的方式来满足特定的需求。
879
880
881 |(((
882 **ITIL的故事：销售并获得服务产品**
883
884 [[image:1639121791803-860.png||height="42" width="37"]]**M**//ariana：我们需要引入新的拖车租赁服务，这意味着将其添加到我们的服务目录中，向我们的支持人员介绍拖车的可用性，并管理拖车的需求。当学生最有可能搬家时，拖车租赁在每个学期的开始和结束时达到顶峰，但中期租赁确实会发生。//
885 )))
886
887 (% class="wikigeneratedid" %)
888 == ==
889
890 (% class="wikigeneratedid" %)
891 == ==
892
893 == 5.5 总结 ==
894
895 ​​​​​​​
896
897 为了确定利益相关者是否可以从相互的服务关系中受益，服务消费者和服务提供者需要构建商业案例，确定并匹配其需求和供应，并以需求和服务供应的形式阐明其需求和机会。只有真正了解服务消费者的需求，才能设计出产品和服务。
898
899
900
901 [[阅读下一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E9%A9%B1%E5%8A%A8%E5%88%A9%E7%9B%8A%E7%9B%B8%E5%85%B3%E8%80%85%E4%BB%B7%E5%80%BC%E3%80%8BDSV/6.%20%E6%AD%A5%E9%AA%A44%EF%BC%9A%E5%8D%8F%E8%AE%AE/]]  [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E9%A9%B1%E5%8A%A8%E5%88%A9%E7%9B%8A%E7%9B%B8%E5%85%B3%E8%80%85%E4%BB%B7%E5%80%BC%E3%80%8BDSV/4.%20%E6%AD%A5%E9%AA%A42%EF%BC%9A%E5%A5%91%E5%8A%A8/]]
深圳市艾拓先锋企业管理咨询有限公司