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