Version 9.1 by superadmin on 2021/12/16, 12:15
Show last authors
1 **服务设计 ITIL4 实践指南**
2
3
4 **申明：**
5
6 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众
7 多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信
8 公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
9
10
11 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
12
13
14 本文档翻译工作参与人员：
15
16 翻译：马建召
17
18 审校：刘雨龙
19
20
21 总审：长河
22
23 审核：刘晓慧
24
25 统筹：常宏
26
27
28
29 ----
30 {{box cssClass="floatinginfobox" title="**Contents**"}}
31 {{toc/}}
32 {{/box}}
33 = **1关于文档** =
34
35 本文档为服务设计实践提供了实践南。它分为五个主要部分，内容包括：
36
37 ● 本实践的一般信息
38
39 ● 本实践相关流程、活动以及其在服务价值链中的作用
40
41 ● 参与本实践的组织和人员
42
43 ●支持本实践的信息和技术
44
45 ●对本实践的合作伙伴和供应商的考虑。
46
47
48 == **1.1 ITIL 4 资格认证计划** ==
49
50 可选择本文内容作为下列教学大纲的一部分进行考查：
51
52 ● ITIL专家：创建、交付和支持（CDS）。
53
54 有关详细信息，请参考相应教学大纲文档。
55
56
57
58 ----
59
60 = **2 基本信息** =
61
62
63 == **2.1目的和描述** ==
64
65 **关键信息**
66
67 服务设计实践的目的是设计出符合目的、适合使用并且可以由组织及其生态系统交付的产品和服务。这包括规划并组织：人员、合作伙伴和供应商，规划并组织：信息、沟通、技术和新的或变更的产品和服务实践，以及组织和客户之间的交互。
68
69
70 如果产品、服务或实践设计不当，就不一定能满足客户需求或促进价值创造。如果他们没有开发适当的体系架构、接口或控制，他们就无法向组织及其内部和外部客户交付其总体构想和需求。
71
72 即使产品或服务设计得很好，也很难以经济有效且富有弹性的方式交付同时满足组织和客户需求的解决方案。因此，在服务设计中考虑迭代和增量方法很重要，这样可以确保引入实时运营的产品和服务以能够不断地适应组织及其客户不断发展的需求。
73
74 如果未形成服务设计，则产品和服务的运行成本可能很高，并且易于失效。这会浪费资源，并且生产或服务不会以客户为中心或不是整体设计的。没有服务设计，要实现需求和客户的期望就非常困难。
75
76 对服务设计的所有方面采用整体、结果驱动的方法，并且在变更或修改服务设计的任何单个元素时，考虑所有其他方面是很重要的。正是由于这个原因，服务设计与整个组织的服务价值系统（SVS）之间的协调就变的至关重要。
77
78 设计一种新的或已变更的产品或服务不应孤立地进行，而应考虑它对下列各方面的影响：
79
80 ● 其他产品及服务
81
82 ● 所有相关方，包括客户、用户和供应商
83
84 ● 现有的架构
85
86 ● 所需的技术
87
88 ● 服务管理实践
89
90 ● 必要的度量和指标。
91
92 考虑这些因素不仅确保设计解决了服务的功能要素，而且还将管理和运营要求视为设计的基本组成部分，而不是在事后考虑。
93
94 当对产品或服务进行的变更是“退役”时，也应该使用服务设计。除非产品/服务的退役是经过精心计划的，否则它可能会对客户或组织造成意想不到的负面影响。
95
96 不是每次对产品或服务的变更都需要相同级别的服务设计活动。每一个变更，无论多么小，都需要一定程度的设计工作，但是确保成功所必需的活动的规模在不同的变更类型之间会有很大的差异。
97
98 组织必须定义每个变更类别所需的设计活动级别，并确保组织中的每个人都清楚这些标准。
99
100 服务设计帮助产品和服务：
101
102 ● 是以业务和客户为导向，聚焦业务和客户，被客户和业务驱动
103
104 ● 是为用户创建的，具有良好的体验
105
106 ● 是物有所值的
107
108 ● 满足组织和任何外部客户的信息和物理安全需求
109
110 ● 灵活，适应性强，但符合交付时的目的
111
112 ● 能够承受在数量和速度上不断增长的需求
113
114 ● 满足不断增长的组织和客户对持续运营的需求
115
116 ● 被管理和操作到可接受的风险水平。
117
118 在组织面临许多压力的情况下，可能会倾向于在服务设计活动的实践和相关方的协调上“偷工减料”，或者完全忽略它们。 应避免这种情况，因为统一和协调对于所交付产品和服务的整体质量是至关重要。
119
120
121
122 == **2.2术语和概念** ==
123
124
125 === **2.2.1 设计思维** ===
126
127 （译者注：这部分内容参考了斯坦福设计学院的“设计思维”五步法，网上有很多文章可辅助理解）
128
129 **设计思维**
130
131 设计思维是一种实践、是以人为中心的一种加速创新方法。它被产品和服务设计者以及组织用来解决复杂的问题，并找到实用的、创造性的解决方案来满足组织和客户的需求。
132
133
134 设计思维可以被看作是精益和敏捷方法的补充方法。设计思维利用逻辑、想象力、直觉和系统思维来探索各种可能性，并创造出令客户受益的期望结果。
135
136 设计思维包括对各种活动的迭代方法，例如：
137
138 **● 灵感与同理心 **通过对人的直接观察，了解他们如何操作产品和服务或与之交互，以及确定他们如何与其他解决方案进行不同的交互。
139
140 **● 创意 ** 它结合了发散性和收敛性思维。发散性思维是提供不同的、独特的或多样性的想法的能力，而收敛性思维是为给定的问题找到最佳解决方案的能力。发散思维确保探索许多可能的解决方案，而收敛思维则将这些问题缩小到最终的首选解决方案。
141
142 **● 原型制作**  用于对想法进行早期测试、迭代和完善。 原型有助于收集反馈并改善创意。 原型使服务设计者可以更好地了解新解决方案的优缺点，从而加快创新过程。
143
144 **● 实现**  从概念变为真实。应该与所有相关的服务管理实践和其他方面进行协调。可以使用敏捷方法以迭代的方式开发和实现解决方案。
145
146 **● 评估 ** （结合其他实践，包括项目管理和发布管理）测量产品或服务实现的实际性能，以确保满足验收标准，并寻找改进的机会。
147
148 多领域团队最适宜采用设计思维；因为它平衡了客户，技术，组织，合作伙伴和供应商的观点，所以他具有高度的综合性，与组织的服务价值系统（SVS）很好地结合，可以成为数字化转型的关键推动力。
149
150
151 === **2.2.2 客户和用户体验** ===
152
153 **客户和用户体验**
154
155 **客户体验（CX） **是**客户**感知到的在服务和服务提供者之间的功能和情感交互的总和
156
157 **用户体验（UX） **是**用户**感知到的在服务和服务提供者之间的功能和情感交互的总和
158
159
160 服务设计的CX和UX对于确保产品和服务为客户和组织提供所需的价值至关重要。CX设计关注于管理整个CX的各个方面，包括时间、质量、成本、可靠性和有效性。UX特别关注产品或服务的易用性以及用户如何与之交互。
161
162 服务体验是服务消费者的一种认知，这种认知是服务消费者基于服务的“技术”输出和如何从人的角度感知服务的结合来评价服务。这意味着服务提供商必须越来越清楚消费者的需求，以及他们可以利用的“资源”来创造价值。服务不是被动接受的：它还需要消费者的努力。服务提供商必须对消费者的行为做出动态响应，并尽可能地适应“例外情况”。这同样适用于消费者。
163
164 精益用户体验（Lean UX）设计是包含精益敏捷方法的一种思维方式、一种文化和一个过程。它以最小可执行来增量实现功能，并通过测量结果与假设结果对比来确定是否成功。精益UX在使用敏捷开发方法的项目中非常有用。其核心目标是尽可能早地获得反馈，以便能够用于快速决策。
165
166 精益UX的典型问题可能包括以下内容：
167
168 ● 谁是该产品/服务的客户，其用途是什么？
169
170 ● 什么时候使用，在什么情况下使用？
171
172 ● 最重要的功能是什么？
173
174 ● 最大的风险是什么？
175
176 每个问题可能有多个答案，这就产生大量的假设，超出实际能处理的范围。因此，团队需要根据它们对组织及其客户造成的风险来对这些假设进行优先级排序。
177
178
179 === **2.2.3 服务设计包** ===
180
181 **服务设计包（ SDP）**
182
183 服务设计文档，定义IT服务的所有方面及其生命周期各个阶段的要求。
184
185 可以为每个新的IT服务生成服务设计包（SDP），并定期进行更新，或者在重大变更和IT服务退役期间进行更新。
186
187
188 服务设计包是通过服务管理实践和客户之间的交互来交付的。服务设计包的目的是确保服务的所有方面都得到了考虑并形成文档。
189
190 SDP的概念对于ITIL来说并不陌生。但是，从价值流的角度来看，其重要性已大大提高。无论采用哪种交付方式或服务提供的范围，SDP都将需求连接到价值。它的目的是向设计师和类似的消费者提供一个清晰的“什么是看起来不错”的陈述；它必须与IT服务的风险模型结合使用，因为最佳的SDP是灵活的，可以根据不同的标准进行调整。
191
192 为了使SDP生效，它应该处理服务的所有四个维度，并聚焦于客户和用户体验。如图2.1所示。
193
194 (% style="text-align:center" %)
195 [[image:1639627583582-794.png]]
196
197
198 图2.1 服务设计包的高级架构
199
200
201 ==== **2.2.3.1定义SDP** ====
202
203 SDP的定义需要一个整体的视图，因为它实际上是其他实践的表示层。服务设计实践不一定定义SDP的所有元素，而是协调和合并其他实践所有者的预期结果。
204
205 有几个关键的注意事项定义SDP：
206
207 ● 设计并记录服务设计策略，包括约定的、可用的不同服务设计包的数量。服务设计策略需要与组织的风险偏好一起开发，因为这两者必须天然地联系在一起。
208
209 ● 确保服务管理的所有四个维度都包含在服务设计包中是很重要的。
210
211 * 组织和人员：运作模式、支持矩阵和培训需求
212 * 信息和技术：工具、监控、数据管理和安全隐患
213 * 合作伙伴和供应商：合适的合同，服务集成，关键成功因素
214 * 价值流和流程：对IT服务的关键路径分析、快速流程。
215
216 ● 开发一个模板，以标识所需信息的类型。例如，说明，指导说明和输出参数。
217
218 ● 与利用相关者沟通，根据服务设计包的级别商定每个实践的参数。
219
220 ● 制定沟通和培训策略，以确保服务设计包能够有效地嵌入到设计中和提供中的服务流程中。
221
222 ● 将使用中的服务设计包的流程嵌入到设计/ 转换、获取/构建和提供/支持的相关价值流中。包括活动如下：
223
224 * 设计检查 – 完成标准/需求分析，客户/ 用户体验
225 * 转换检查 – 功效注意事项
226 * 被嵌入到工具中的与服务保护相关的待办事项。
227
228 服务设计需求将被嵌入到价值流中，以用于引入新的或变更中的服务。
229
230 对于SDP的每个元素，架构师将提供合规性证据。如果受影响的利益相关者不批准服务，则出现的任何问题都需要解决。可能涉及到对设计中使用了哪些技术和服务设计模式的评审，以及风险问卷上的原始答案是否适当地考虑了IT服务的更广泛的环境及其对业务操作的影响。这是一个迭代的过程，取决于有多少问题存在，以及利益相关者在多大程度上对提议的解决方案满意。
231
232
233 === **2.2.4 服务设计特性** ===
234
235 服务设计具有独特的关键特性。
236
237
238 ==== **2.2.4.1 服务规划** ====
239
240 服务规划是一个战略阶段，它的作用是设计和开发“好是什么样的”。 这与端到端服务提供相关，并确保客户/用户体验是任何消费者可用的服务级别供给中固有的。在开发此服务时，组织需要考虑以下的问题：
241
242 ● 设计如何支持所需的业务结果?
243
244 ● 价值是如何创造的?价值创造的可持续性如何?
245
246 ● 组织的风险偏好是什么?
247
248 ● 服务的分层应该如何组织?
249
250 ● 服务应该如何跨层进行变更?
251
252
253 答案由服务管理的四个维度驱动，并定义了组织对消费者价值实现需求的响应能力。
254
255 ●组织和人员
256
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 ==== **2.2.4.2 风险识别** ====
283
284 它包括在设计新的或变更的服务时如何识别风险的治理；确保这些服务适合识别的风险级别。
285
286 应考虑以下问题：
287
288 * 组织想要实现什么？
289 * 他们的目标是什么？
290 * 好是什么样的？
291
292 在确定IT服务的风险时，这些问题比之前提出的传统IT服务级别问题更重要。因此，在寻找风险时，重点应该转移。表2.1给出了一些问题示例，这些问题有助于在设计IT服务时确定目标质量和级别。
293
294 表2.1 传统IT 服务级别问题示例
295
296 [[image:1639627703407-409.png]]
297
298
299 ==== **2.2.4.3 服务设计编排** ====
300
301 **​​​​​​​​​​​​​​服务设计编排**
302
303 服务设计编排确保在设计和转换IT服务时考虑实现结果所需的所有资源，包括供应商、信息、技术、人员、流程和运营模式。
304
305
306 服务设计编排利用服务集成和管理的原则，确保通过以下方式适当管理对组织构成的风险级别：
307
308 ● 设计适合风险水平的运营模式，包括供应商生态系统
309
310 ● 根据与风险水平相匹配的能力设计IT服务及其组件。
311
312
313 **​​​​​​​​​​​​​​服务集成和管理**
314
315 服务集成和管理是一种管理多个服务提供商（业务服务和信息技术服务）并将其集成以提供单一面向业务的IT 组织的方法。
316
317
318 在选择新的服务提供者时，服务需求的服务设计包需要构成需求的一部分。与第三方供应商的任何讨论都需要确保满足这些要求，或者至少不低于这些要求。当多个服务提供者提供服务时，需要有一个运营模型来确定角色和职责，以及使这些提供者如何协作来实现无缝供应。
319
320 当有混合模型时，运营模式的复杂性将增加（提供者包括内部团队和第三方）。在记录角色和职责，升级和重大事件处理时，应考虑使用此需求。
321
322 如果内部和（或）第三方的性能或绩效不满足服务设计矩阵型的要求，则服务设计编排还将包括记录和管理服务设计的弃权和豁免。在这种情况下，需要记录缓解措施。建议在所有情况下都约定一个日期，在该日期之前应有资金和其他资源来取消弃权/豁免。尽管有可能获得持久的弃权或豁免，但不建议这样做。如果未约定里程碑日期，则风险将永久存在，并可能随时间增加风险的危害。里程碑日期可能不相关的唯一时间是业务运营部门接受潜在的风险危害水平，即无论如何都希望继续进行。
323
324 编排的角色通常由人工（例如持续改进登记册）支持。其中可能包括已确定的改进，已批准的弃权和豁免等项目。
325
326 一个组织如何使用这个产品将取决于他们想要管理什么。强烈建议任何组织都建立一个服务改进登记册；这样可以确保所有各方都知道为了减少风险危害，正在进行哪些更改。
327
328 另一种方法是根据服务设计包跟踪性能。这不同于接受服务。针对服务设计包的性能要求，参与IT服务设计和构建的架构师通过他们的分析和决策工具来验证服务。此方法可用于单个服务、一组服务或端到端视图。
329
330 服务设计顾问将通过确保适当和成功地实现所识别的能力，或者通过直接参与整个组织的变更计划，来编排服务的设计。通常，参与服务引入的专家或业务分析师会通过需求收集、测试结果和准备状况监视来促进这些能力的使用。
331
332 表2.2 给出了一些考虑因素的例子。
333
334 |**运营模式考虑因素**|**IT服务设计的考虑因素**
335 |维护和管理服务的角色和职责|可扩展性和对需求的响应能力
336 |供应商能力|可用性、容量和性能需求
337 |事件处理和升级|需要哪些管理信息，哪些需要监控 ？
338
339
340 === **2.2.5 风险建模** ===
341
342
343 对风险进行建模涉及服务设计实践和风险管理实践。风险建模中应该包含几个元素：
344
345 ● 问卷，使本组织能够阐明潜在的影响，涵盖的共同主题的例子如下：（调查问卷需要一些自由形式的答案，但核心部分需要一组商定的答案，以便在所有服务中进行一致的评估。）
346
347 * 数据（保密性，完整性和可用性）
348 * 财务影响
349 * 监管义务
350 * 已知的风险和约束
351 * 声誉/ 品牌损坏
352 * 灾难方案。
353
354
355 ● 达成一致的风险影响矩阵型，详细说明影响类型和影响级别参数。描述影响应该在业务运营级别上，而不是技术级别上，并且与问卷中包含的问题主题有关。考虑使用诸如IRAM2之类的最佳实践来帮助定义应该询问什么并对其进行影响评估。
356
357 * 一种计算这些答案结果的算法。组织需求有以下四点要达成共识：
358 * 他们想要服务等级数
359 * 如何将数分配给问题（例如，10表示危急，7表示严重）
360 * 确定最高数
361 * 每个级别应具有的IT服务百分比（例如2％的1级，10％的2级，30％的3级，58％的4级）
362
363
364 一旦这四个问题被详细描述，下一步就是确定一个合适的具有代表性的IT服务来校准算法。
365
366 ● 详细说明最合适的服务设计包的结果。
367
368
369 风险建模可以而且应该在服务的不同级别上完成。原因如下：
370
371 ● IT组织需要了解整个IT领域中潜在风险影响程度最高的地方。
372
373 ● 业务运营和零售团队需要了解对消费者最有可能产生影响的地方；同样，他们还需要了解一线团队（如呼叫中心或分支机构）将受到何种影响。
374
375 ● 战略规划人员和架构师需要了解服务线的总体潜在风险影响。
376
377 这三个级别具有不同的风险概述。示例如图2.2所示。
378
379 (% style="text-align:center" %)
380 [[image:1639627797186-660.png]]
381
382 图2.2 风险概述示例
383
384
385 打开新的租赁合同被视为组织的关键业务服务线，并且被定为等级1。支持业务服务线的是两个客户旅程，这两个旅程都直接支持服务线，被认为是第1层。当拆散IT服务层时，虽然租赁的合同工具本身是服务的一部分，但业务的连续性措施已经到位，可以手动获取信息并在以后输入。因此，它被评为2级服务。但是，如果没有CRM和分帐工具，则业务将无法打开新的租赁合同。他们是第一层的。
386
387 本质上，在服务中寻找关键路径并确定将阻止消费者完成他们希望执行的任务非常重要。如果IT服务停止了这些任务，则客户会受到直接影响。如果它们会增加延迟，则客户的影响较小（如果有的话）。
388
389 确定服务级别管理结构应反映风险分析的级别是很重要的；因此分析服务线存在的风险，除了IT服务之外，还需要客户旅程、服务线和客户旅程SLA。
390
391
392
393 == **2.3范围** ==
394
395 服务设计实践的范围包括：
396
397 ● 确保服务是符合目的并且适合使用
398
399 ● 识别和记录与风险一致的服务层/包，包括标准、非功能性需求以及领域专家和其他实践/流程所有者批准的能力
400
401 ● 管理和编排整体设计方法
402
403 ● 整合参与服务设计的团队，并促进所有利益相关者之间的信息交流
404
405 ● 通过服务的生命周期更新服务设计包
406
407 ● 不断改进服务设计实践。
408
409 有几个活动和职责领域虽然与服务设计密切相关，但他们不包括在服务设计实践中。表2.3列出了这些活动和职责，并给出了能找到它们的实践。重要的是要记住，ITIL的实践仅仅是价值流的背景中使用的工具。必要时应根据情况合并。
410
411 表2.3 与其他实践指南中描述的服务设计实践相关的活动
412
413 |**实现价值**|**实践指南**
414 |风险识别|风险管理
415 |需求管理|关系管理
416 |架构模式，原则和债务承受能力定义|架构管理
417 |安全控制和合规需求定义|信息安全管理
418 |定义需求|业务分析
419 |定义服务验收标准|服务验证和测试
420 |监控模式定义和事态分类|监控和事态管理
421 |用户反馈收集|服务台
422 |供应商策略，默认合同和供应商评价|供应商管理
423
424
425 == **2.4实践成功因素** ==
426
427 **​​​​​​​实践成功因素**
428
429 实践的一个复杂的功能组成部分，是实践实现其目的所必需的。
430
431
432 实践的成功因素（PSF）不仅仅是一项任务或活动，因为它包括所有服务管理四维模型的组件。活动的性质和实践中PSF的资源可能有所不同，但它们共同确保实践有效。
433
434 服务设计实践包含以下PSF：
435
436 ● 建立和维护有效的组织范围的服务设计方法
437
438 ● 确保服务是符合目的并适合在整个生命周期中使用。
439
440
441 === **2.4.1 建立和维护有效的组织范围的服务设计方法** ===
442
443 服务设计实践包括定义和达成一致的方法和模型，用于设计新的和变更的服务以及服务组件。组织可能会合并几种方法并定义几种服务设计模型，以适应设计和管理的每种类型的产品或服务。
444
445 这应该从评估组织的目标、客户需求以及服务设计的影响开始。由于服务设计是关于协调设计的工作，并且应该是整体的，因此在选择设计方法之前，组织必须评估以下因素：
446
447 ● 战略目标和服务组合
448
449 ● 产品、服务的当前和潜在客户
450
451 ● 同客户、用户进行沟通和信息交换的方式，以及获取、处理反馈的能力
452
453 ● 当前和期望的创新、拥抱变化和重新创造自己的能力
454
455 ● 服务设计的资源约束
456
457 ● 可用于实验的资源
458
459 ● 风险承受力和风险管理方法
460
461 ● 组织管理项目和实施变更的方式
462
463 ● 合作伙伴和供应商的生态系统及其支持服务设计方法的能力。
464
465 这些因素意味着每种组织对待服务设计的方法可能有所不同。这意味着在服务设计流程中拥有更好的客户和用户参与度，或者实施整体方法来设计服务并专注于使用服务设计软件包、转换流程以引入更快的变更和更短的设计生命周期，同时消除了返工或引入了更多的迭代和实验性方法 。
466
467 组织可能有几种服务设计方法，具体取决于其产品组合中的不同产品和服务。服务设计的方法和模型应具有一定的灵活性，以适应不断变化的情况、利益相关者和环境。每种服务设计方法都应该具有一个或几个公认的服务设计模型，可以将其重新用于类似的产品和服务。
468
469 服务设计的方法、模型以及一般的实践应该成为持续改进的主题。不断寻找实现利益相关者期望、增加客户和用户的满意度，消除浪费以及提升效果和效率的方法。
470
471
472 === **2.4.2 确保服务符合目的并适合在整个生命周期中使用** ===
473
474 确保有效的服务设计需要协调所有四个维度（组织和人员、信息和技术、合作伙伴和供应商、价值流和流程）的资源。
475
476 根据服务设计模型的不同，实现设计所需的活动和资源可能会有很大的不同：
477
478 ● 类似于以前设计的简单应用程序的设计，可以使用以前设计的现有模型和服务设计包，并遵循为模型规划的过程，按线性顺序组织。
479
480 ● 设计新的、创新的服务时，可能需要新的方法。可能需要复审现有的服务设计模型和SPD（服务设计包）。从构思到评价，在服务设计流程的任何阶段都可以对实验，假设检查，迭代设计使用一些快速反馈方法。应该特别关注利益相关者的交互和反馈处理。服务设计可以作为项目或主要项目的一部分进行管理，涉及组织内外的许多团队和实践，需要不同级别资源的参与、形式和文档。
481
482 在任何情况下，有效的协调、确保设计的整体方法、信息流、利益相关者的参与以及从服务生命周期的早期阶段对设计模型的良好规划是成功的关键。
483
484 在服务生命周期期间，必须将实践与团队的合作有效结合。服务设计实践的重点是确定任务、关键信息和协调设计实现的参与者。它还就实施过程中使用的程序和技术提出了建议。
485
486 以下有效协调特别重要：
487
488 ● 项目管理
489
490 ● 变更支持
491
492 ● 软件开发和管理
493
494 ● 基础设施和平台管理
495
496 ● 业务分析
497
498 ● 服务验证和测试
499
500 ● 发布管理
501
502 ● 可用性管理
503
504 ● 连续性管理
505
506 ● 容量和性能管理
507
508 ● 服务级别管理
509
510 ● 供应商管理。
511
512
513
514 == **2.5关键指标** ==
515
516 应该在每个实践所贡献的价值流的背景内评估ITIL实践的效果、性能或绩效。与任何工具的性能或绩效一样，只能在应用程序的背景内评估实践的性能或绩效。然而，工具在设计和质量上可能有很大的不同，这些不同定义了工具的潜力，或根据其用途使用时其能力才有效。有关度量标准，关键性能或绩效指标（KPI）的其他指南以及可以帮助解决此问题的其他技术，请参见度量和报告实践指南。
517
518 服务设计的关键指标已映射到它的PSF（实践成功因素）。PSF可以在价值流的背景中用作KPI，以评估服务设计对这些价值流的效果和效率的贡献。表2.4中给出了一些关键指标的示例。有多个相关的度量标准需要监控，这些度量标准可以大致分为以下与实践成功因素相关的组。
519
520 表2.4 实践成功因素的示例指标
521
522 |**实践成功因素（PSF）**|**指标示例**
523 |建立和维护有效的组织范围的服务设计方法|(((
524 ● 遵循组织的产品组合中的服务设计方法
525
526 ● 适用于整个组织的产品组合
527
528 ● 利益相关者对选择的服务设计方法的满意度
529
530 ● 利益相关者对组织使用设计进行创新能力的满意度
531 )))
532 |确保服务适合其用途并适合其整个生命周期的使用|(((
533 ● 产品和服务满足功用和功效要求的百分比
534
535 ● 利益相关者对其所选的服务设计模型和方法的满意度
536
537 ● 利益相关者对组织设计产品和服务能力的满意度
538
539 ● 利益相关者对服务设计的财务效率的满意度
540 )))
541
542 将度量标准正确地聚合到复杂的指标中，将使对价值流的持续管理以及对服务设计实践的定期评估和持续改进变得更容易使用。没有单一的最佳解决方案。度量标准将基于组织的整体服务策略、优先级以及实践贡献的价值流目标。
543
544
545
546
547 ----
548
549 = **3 价值流和流程** =
550
551
552 == **3.1 价值流的贡献** ==
553
554 像任何其他ITIL 管理实践一样，服务设计对多个价值流有贡献。重要的是要记住，价值流不是由单个实践构成的。服务设计与其他实践相结合，可以为消费者提供高质量服务。服务设计对价值链活动的主要贡献是：
555
556 ● 设计和转换
557
558 ● 改进
559
560 ● 获取或构建
561
562 ● 计划。
563
564
565 (% style="text-align:center" %)
566 [[image:1639627911472-243.png]]
567
568 图3.1 服务设计对价值链活动贡献的热图
569
570
571
572 == **3.2 流程** ==
573
574 每个实践可能包含一个或多个流程和活动，它们对于实现该实践的目的可能是必需的。
575
576 **​​​​​​​流程**
577
578 一组相互关联或交互的活动，可将输入转换为输出。流程定义动作的顺序及其依赖。
579
580
581 服务设计实践活动形成两个流程：
582
583 ● 服务设计规划
584
585 ● 服务设计协调。
586
587
588 === **3.2.1 服务设计规划流程** ===
589
590 该流程专注于服务设计实践的持续改、服务设计方法和模型，以及复杂服务设计实例计划的开发。它定期执行，并由事件或请求触发。根据现有模型和程序的效果，可能每两、三个月或更频繁地进行定期审查。该过程包括表3.1中列出的下列活动，并将下列输入转换为输出。
591
592 表3.1 服务设计规划流程的输入活动和输出
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 ● IT资产信息
619
620 ● 与供应商/合作伙伴的协议和合同
621
622 ● 项目管理的方法和经验教训
623
624 ● 软件开发和管理、基础设施和平台管理遵循相关政策和计划（信息安全，连续性，容量）
625
626 ● 使用的技术
627 )))|(((
628 ● 服务/ 产品环境和需求分析
629
630 ● 服务设计方法评审和开发
631
632 ● 服务设计模型评审和开发
633
634 ● 服务设计实例规划
635
636 ● 服务设计计划沟通
637 )))|(((
638 ● 更新的服务设计方法和模型
639
640 ● 服务设计计划
641
642 ● 服务设计包模板
643
644 ● 改进倡议
645
646 ● 变更请求
647
648 ● 更新知识
649
650 ● 管理文章
651
652 ● 经验教训
653 )))
654
655
656 图3.1显示了该流程的工作流程图。
657
658
659 (% style="text-align:center" %)
660 [[image:1639627962923-326.png]]
661
662 图3.1 服务设计规划流程的工作流
663
664
665 表3.2 服务设计规划流程活动
666
667 (% style="width:980px" %)
668 |**活动**|(% style="width:425px" %)**常规评审示例**|(% style="width:455px" %)**复杂服务设计规划示例**
669 |服务/ 产品环境和需求分析|(% style="width:425px" %)(((
670 设计团队与产品/ 服务所有者、架构师和其他团队一起，分析和讨论影响服务设计方法的新或变更的条件：
671
672 ● 创建/修改一组产品和服务的首选方法
673
674 ● 产品或服务组的性质
675
676 ● 组织的架构方法和决策
677
678 ● 客户和用户的反馈，设计的目标受众，现有的反馈渠道，现有的服务级别协议
679
680 ● 组织的风险管理方法和风险承受力
681
682 ● 合规性，政策和技术机遇与制约因素
683
684 ● 市场状况和财务状况
685
686 ● 服务设计方法的财务和成本约束
687
688 ● 对产品或服务组件的控制级别
689
690 在分析和讨论的基础上，定义了新的服务设计方法或者对现有方法提出了更改。
691 )))|(% style="width:455px" %)服务设计团队与产品/ 服务所有者、架构师和其他团队一起分析并讨论影响服务设计实例的因素。
692 |服务设计方法评审和开发|(% style="width:425px" %)团队讨论新的服务设计方法或对现有服务设计方法的更改，并就该方法达成一致。服务设计方法已开发或更新。|(% style="width:455px" %)服务设计团队与产品/服务所有者、架构师和其他团队一起对现有的服务设计方法进行fit/gap分析（匹配/差距分析），并选择适合复杂服务设计实例的方法。
693 |服务设计模型评审和开发|(% style="width:425px" %)基于新的或变更后的方法，服务设计模型被定义或更新，包括，例如，服务设计过程和控制，服务设计包模板，模板计划和时间表，沟通计划和知识文章的模板，等等。|(% style="width:455px" %)(((
694 团队应评估服务设计实例的要求，并考虑创新水平、先前知识、架构、产品或服务环境、SLA和用户关系，以及政策和财务限制；现有的服务设计模型可以在多大程度上支持此设计实例。
695
696 基于评估，团队决定使用新的服务设计还是现有的模型。
697 )))
698 |服务设计实例规划|(% style="width:425px" %) |(% style="width:455px" %)(((
699 团队为服务设计实例规划以下内容：
700
701 ● 用于需求跟踪的方法
702
703 ● 目标受众并与其进行沟通，获取并处理反馈
704
705 ● 规划与合作伙伴和供应商的交互
706
707 ● 财务计划和预算控制方法
708
709 ● 服务设计包的内容
710
711 ● 资源计划
712 )))
713 |服务设计计划沟通|(% style="width:425px" %)对新的或更新的服务设计计划、服务设计包和服务设计方法和流程进行沟通，并由利益相关者进行审核，反馈到服务台和知识管理部门。|(% style="width:455px" %)服务设计计划和服务设计包的沟通由利益相关者准备、审核，并反馈到服务台和知识管理中。
714
715
716 === **3.2.2 服务设计协调流程** ===
717
718 该流程包括以下活动，并将以下输入转换为输出，如表3.3所示。
719
720 表3.3 服务设计协调流程的输入、活动和输出
721
722 |**关键输入**|**活动**|**关键输出**
723 |(((
724 ● 服务设计模型
725
726 ● 服务设计计划
727
728 ● 先前设计的服务设计包模板和SDP
729
730 ● 知识文章
731
732 ● 服务设计记录
733
734 ● 政策法规要求
735
736 ● 业务分析报告
737
738 ● 客户和用户反馈
739
740 ● 服务目录
741
742 ● 服务级别协议
743
744 ●  IT资产信息
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 图3.2显示了该流程的工作流程图
782
783 (% style="text-align:center" %)
784 [[image:1639628031552-968.png]]
785
786
787 图3.2 服务设计协调流程的工作流程
788
789
790 表3.4 进一步描述了这些活动。
791
792 表3.4 服务设计协调流程的活动
793
794 |**实现价值**|**描述**
795 |确定适用的设计模型或计划|服务设计团队评估服务要求、服务的复杂性、服务设计实例与现有服务之间的相互依赖性，预算和服务设计实例的风险，并选择要使用的适当服务设计模型或者使用新的模型。这可能会触发服务设计规划流程。
796 |规划设计活动、资源和能力|(((
797 设计团队基于服务设计模型计划设计活动，确定涉及的团队，计划并请求资源分配。可能需要一些其他能力，这些能力可能必须购买、外包或获得。
798
799 在这个阶段，更新SDP和风险管理的责任被分配。
800 )))
801 |服务设计执行|服务设计执行主要是编排和协调设计中涉及的团队和资源，以及管理需求跟踪、沟通和信息交换，使快速反馈和数据流成为可能，并确保在任何阶段对设计进行整体考虑。这是与其他相关实践一起进行的。可能涉及许多内部和外部团队。
802 |服务设计评审|服务设计团队执行服务设计评审，以确保符合标准和约定，并确保SDP的所有约定需求都已正确完成。因此，团队更新知识库并记录所吸取的教训。产生的服务设计评审报告可能触发服务设计规划过程。
803
804
805
806 ----
807
808 = **4 组织和人员** =
809
810
811 == **4.1 角色，能力和责任** ==
812
813 实践指南没有描述实践所有者或管理者的角色，这些角色应该存在于所有实践中。实践指南着重于每个实践的专门角色。每个角色的结构和命名可能因组织而异，因此ITIL中定义的任何角色都不应该被视为强制的，甚至不应该被推荐。记住，角色不是职位头衔。一个人可以担任多个角色，一个角色可以分配给多个人。
814
815 角色是在流程和活动的上下文中描述的。每个角色都有一个基于表4.1所示模型的能力概要。
816
817 表4.1能力代码和简介
818
819 |**能力代码**|**描述**
820 |L|**领导者 ** 决策、授权、其他活动的监督、激励和动机，以及结果的评估。
821 |А|**管理员 ** 分配任务并确定优先级，记录保存，持续的报告和基本的改进。
822 |C|**协调员/沟通者** 协调多方，利益相关者之间的沟通并执行宣传活动。
823 |М|**方法和技术专家**  设计和实施工作技术、程序文档、过程咨询、工作分析和持续改进。
824 |Т|**技术专家** 该角色专注于技术（IT）专业知识和基于专业知识的任务。
825
826
827 在组织中可能会发现三个特定于实践的角色：服务设计负责人，服务设计顾问和服务设计分析员。这些角色通常介绍给IT服务数量和变更率很高的组织。在其他组织中，服务设计活动由负责架构，产品或服务的人员或团队进行协调。这可能是产品负责人，服务负责人，服务交付经理，IT解决方案架构师或企业架构师。
828
829
830 === **4.1.1 服务设计领导者角色** ===
831
832 如果定义了一个专门的服务设计角色，通常是一位熟知组织产品且有扎实的设计思维能力的专家。（组织产品：架构，服务和相互依赖性；设计思维能力：开发战略设计模式，确定设计的适当性，协调团队合作和良好的风险管理技能）。该角色的能力要求是LMC。该角色通常负责服务设计流程中的专家活动的管理和成熟度，包括：
833
834 ● 服务设计实践的战略方向和成熟度
835
836 ● 服务设计实践的开发，包括培训，沟通和流程
837
838 ● 服务设计流程和控制的治理
839
840 ● 构建，利用和管理服务设计软件包。
841
842 在更复杂的组织中，一些服务设计职责可以委托给服务设计顾问。服务设计顾问专注于服务设计活动的开发和产业化，包括更详细的流程、服务设计包的要素、为变更计划提供咨询和编排服务供给。这个角色的能力要求是MC。
843
844 表4.2中列出了服务设计管理活动中可能涉及的其他角色，以及相关的能力概况和特定技能。
845
846 表4.2 服务设计管理活动中涉及的角色示例
847
848 |**活动**|**负责角色**|**能力简介**|**具体技能**
849 |(% colspan="4" %)服务设计规划流程
850 |服务/ 产品环境和需求分析|(((
851 企业架构师
852
853 服务设计师
854
855 项目经理
856
857 服务负责人
858
859 产品负责人
860
861 客户代表
862
863 开发团队成员
864
865 客户经理
866
867 交付经理
868
869 业务分析员
870 )))|ATC|(((
871 服务环境的知识和服务的相互依赖性
872
873 设计思维
874
875 沟通技巧和收集和处理信息的能力
876 )))
877 |服务设计方法评审和开发|(((
878 服务设计师
879
880 服务负责人
881
882 项目经理
883
884 产品负责人
885
886 开发团队成员
887
888 系统管理员
889
890 客户经理
891
892 交付经理
893 )))|MATC|(((
894 服务设计的方法和技术知识
895
896 流程和程序，政策意识
897
898 基础架构和平台，软件开发专业知识
899
900 沟通技巧和收集和处理信息的能力
901 )))
902 |服务设计模型评审和开发|(((
903 服务设计师
904
905 服务负责人
906
907 项目经理
908
909 产品负责人
910
911 开发团队成员
912
913 系统管理员
914 )))|MATC|(((
915 服务设计的方法和技术知识
916
917 基础架构和平台，软件开发专业知识
918
919 流程和程序，政策意识
920
921 沟通技巧和收集和处理信息的能力
922 )))
923 |服务设计实例规划|(((
924 服务设计师
925
926 服务负责人
927
928 产品负责人
929
930 项目经理
931
932 开发团队成员
933
934 系统管理员
935 )))|AMCT|(((
936 具备资源、沟通、能力和规划方面的知识
937
938 沟通技巧和收集和处理信息的能力
939
940 基础架构和平台，软件开发专业知识
941
942 服务/产品领域的技术知识
943
944 服务架构知识
945 )))
946 |服务设计计划沟通|(((
947 服务负责人
948
949 产品负责人
950
951 关系经理
952
953 客户经理
954
955 交付经理
956
957 服务台代表
958 )))|C|沟通技巧
959 |(% colspan="4" %)服务设计协调流程
960 |确定适用的设计模型或计划|(((
961 服务负责人
962
963 产品负责人
964
965 服务设计师
966
967 开发团队成员
968
969 客户经理
970
971 交付经理
972
973 风险经理
974 )))|MAT|(((
975 服务设计的方法和技术知识
976
977 基础架构和平台、软件开发专业知识
978
979 流程和程序，政策意识
980
981 沟通技巧和收集和处理信息的能力
982
983 基础架构和平台专业知识
984
985 服务/ 产品领域的技术知识
986 )))
987 |规划设计活动|(((
988 服务负责人
989
990 产品负责人
991 )))|ACMT|项目和变更管理技能
992 |资源和能力|(((
993 开发团队成员
994
995 客户经理
996
997 交付经理
998
999 客户代表
1000
1001 风险经理
1002 )))| |(((
1003 具备资源、沟通、能力和规划方面的知识
1004
1005 沟通技巧和收集和处理信息的能力
1006
1007 服务设计的方法和技术知识
1008
1009 服务/ 产品领域的技术知识
1010 )))
1011 |设计执行|(((
1012 设计执行 开发团队成员
1013
1014 系统管理员
1015
1016 信息安全专家
1017 )))|ACM|(((
1018 项目和变更管理技能
1019
1020 具备资源、沟通、能力和规划方面的知识
1021
1022 沟通技巧和收集和处理信息的能力
1023
1024 服务设计的方法和技术知识
1025 )))
1026 |服务设计评审|(((
1027 服务负责人
1028
1029 产品负责人
1030
1031 客户经理
1032
1033 交付经理
1034
1035 开发团队成员
1036
1037 设计师
1038
1039 客户代表
1040
1041 用户
1042
1043 测试专家
1044 )))|ACTM|(((
1045 业务分析
1046
1047 项目和变更管理技能
1048
1049 沟通技巧和收集和处理信息
1050
1051 服务关系和服务质量知识
1052
1053 服务验证和测试专业知识
1054
1055 服务设计和部署方法知识
1056
1057 服务/ 产品领域的技术知识
1058 )))
1059
1060 == **4.2 组织结构和团队** ==
1061
1062 在大型、复杂或跨国组织中，为服务设计实践找到专门的组织结构是不常见的，尽管服务设计顾问的角色更广泛地与正式的职称联系在一起。在以产品为基础的组织中，通常不采用与常规服务设计活动相关的服务设计职务和角色，因为这一实践被集成到产品开发和管理团队的日常活动中，并且在任何可能的情况下都是自动化的。
1063
1064 在更多基于服务的组织中，可能会有专门的服务设计顾问，但是服务设计的活动更有可能由其他团队（例如，架构师，业务分析人员，服务引入和筹备专家）承担。只有那些拥有复杂的服务和产品组合的组织才会选择专门的服务设计实践组织结构。
1065
1066
1067
1068 ----
1069
1070 = **5 信息和技术** =
1071
1072
1073 == **5.1 信息交流** ==
1074
1075 服务设计的效果基于所使用信息的质量。该信息包括但不限于以下信息：
1076
1077 ● 产品和服务及其现有的体系结构和设计，包括这些产品和服务的功能性和非功能性特征的基线
1078
1079 ● 通过风险管理实践定义的风险类别和风险偏好
1080
1081 ● 客户和用户
1082
1083 ● 合作伙伴和供应商，包括他们提供的服务的合同和SLA信息
1084
1085 ● 产品和服务的预期用途和范围，包括对组织的潜在风险
1086
1087 ● 第三方合同，包括与组织预期相比的漏洞和差距。
1088
1089 设计协调过程生成的关键信息包含在SDP中，SDP包含服务设计所需的所有信息。SDP还可以在生命周期的后期阶段支持服务。SDP可以由多个文档组成，可用于知识库、服务目录、配置管理工具等。
1090
1091
1092 == **5.2 自动化和工具** ==
1093
1094 在服务设计的管理活动中，自动化可以带来显著的好处。虽然自动化服务设计顾问角色仍然有好处，但该角色所需的技能包括更高程度的解释和适当性，这将需要复杂的决策自动化。
1095
1096 对于服务设计实践，自动化和工具通过以下方面带来最多的价值：
1097
1098 ● 协作工具，用于在团队与不同的利益干系人组之间提供通信并跟踪任务
1099
1100 ● 需求跟踪工具，反馈收集和处理工具
1101
1102 ● 知识管理促进创新和教育的工具
1103
1104 ● 可视化工具可帮助可视化有关需求，设计解决方案，团队和组件集成等方面的信息
1105
1106 ● 人工智能工具可模仿用户行为或将用户行为集成到设计分析，假设测试等中。
1107
1108
1109
1110
1111 ----
1112
1113 = **6 合作伙伴和供应商** =
1114
1115 仅使用组织自己的资源提供的服务很少。大多数（如果不是全部）依赖于其他服务，这些服务通常由组织之外的第三方提供（请参阅ITIL® Foundation：ITIL 4的2.4节：服务关系的模型）。架构管理和供应商管理的ITIL实践中描述了由支持服务引入的关系和依赖性。有关对第三方服务的依赖性的信息在变更、生命周期、控制、流程的所有步骤中都用在变更控制中，并且可能经常在变更优化流程中使用。
1116
1117 在采购流程期间服务设计通常会发现第三方提供服务中的漏洞。如果设计的产品或服务依赖于合作伙伴和供应商的资源和服务，那么这种依赖性的风险应该得到认真的解决。应对每个合作伙伴或供应商在产品或服务中带来的价值进行评估，以防范其带来的风险。
1118
1119
1120
1121
1122 ----
1123
1124 = **7 重要提醒** =
1125
1126 实践指南的大部分内容都应作为组织在建立和培养自己的实践时可能考虑的领域的建议。实践指南是组织可能考虑的事情的目录，而不是答案的列表。使用实践指南的内容时，组织应始终遵循ITIL 指导原则：
1127
1128 ● 聚焦价值
1129
1130 ● 从你所处的地方开始
1131
1132 ● 基于反馈迭代推进
1133
1134 ● 协作和提升可视化程度
1135
1136 ● 通盘思考和工作
1137
1138 ● 保持简单实用
1139
1140 ● 优化和自动化。
1141
1142 有关指导原则及其应用的更多信息，请参见ITIL® Foundation：ITIL 4第4.3节的内容。
1143
1144
1145
1146
1147 ----
1148
1149 = **8 致谢** =
1150
1151 AXELOS Ltd 非常感谢为本指南开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
1152
1153
1154 == **8.1 作者** ==
1155
1156 Karen Brusch
1157
1158
1159 == **8.2 审稿人** ==
1160
1161 Akshay Anand， Roman Jouravlev
深圳市艾拓先锋企业管理咨询有限公司