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