#
由 superadmin 于 2024/04/12, 10:27 最后修改
Show last authors
1
2
3
4 **申明：**
5
6 本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注**微信公众号：ITILXF**，并回复**“服务设计”或“设计”**即可。
7
8
9 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
10
11
12 本文档翻译工作参与人员：
13
14 翻译：马建召
15
16 审校：刘雨龙
17
18
19 总审：长河
20
21 审核：刘晓慧
22
23 统筹：常宏
24
25
26
27 ----
28
29 {{box cssClass="floatinginfobox" title="**Contents**"}}
30 {{toc/}}
31 {{/box}}
32
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 (% style="width:513px" %)
335 |(% style="width:236px" %)**运营模式考虑因素**|(% style="width:275px" %)**IT服务设计的考虑因素**
336 |(% style="width:236px" %)维护和管理服务的角色和职责|(% style="width:275px" %)可扩展性和对需求的响应能力
337 |(% style="width:236px" %)供应商能力|(% style="width:275px" %)可用性、容量和性能需求
338 |(% style="width:236px" %)事件处理和升级|(% style="width:275px" %)需要哪些管理信息，哪些需要监控 ？
339
340 === **2.2.5 风险建模** ===
341
342
343 对风险进行建模涉及服务设计实践和风险管理实践。风险建模中应该包含几个元素：
344
345 ● 问卷，使本组织能够阐明潜在的影响，涵盖的共同主题的例子如下：（调查问卷需要一些自由形式的答案，但核心部分需要一组商定的答案，以便在所有服务中进行一致的评估。）
346
347 * 数据（保密性，完整性和可用性）
348 * 财务影响
349 * 监管义务
350 * 已知的风险和约束
351 * 声誉/ 品牌损坏
352 * 灾难方案。
353
354 ● 达成一致的风险影响矩阵型，详细说明影响类型和影响级别参数。描述影响应该在业务运营级别上，而不是技术级别上，并且与问卷中包含的问题主题有关。考虑使用诸如IRAM2之类的最佳实践来帮助定义应该询问什么并对其进行影响评估。
355
356 * 一种计算这些答案结果的算法。组织需求有以下四点要达成共识：
357 * 他们想要服务等级数
358 * 如何将数分配给问题（例如，10表示危急，7表示严重）
359 * 确定最高数
360 * 每个级别应具有的IT服务百分比（例如2％的1级，10％的2级，30％的3级，58％的4级）
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 (% style="width:443px" %)
412 |(% style="width:283px" %)**实现价值**|(% style="width:157px" %)**实践指南**
413 |(% style="width:283px" %)风险识别|(% style="width:157px" %)风险管理
414 |(% style="width:283px" %)需求管理|(% style="width:157px" %)关系管理
415 |(% style="width:283px" %)架构模式，原则和债务承受能力定义|(% style="width:157px" %)架构管理
416 |(% style="width:283px" %)安全控制和合规需求定义|(% style="width:157px" %)信息安全管理
417 |(% style="width:283px" %)定义需求|(% style="width:157px" %)业务分析
418 |(% style="width:283px" %)定义服务验收标准|(% style="width:157px" %)服务验证和测试
419 |(% style="width:283px" %)监控模式定义和事态分类|(% style="width:157px" %)监控和事态管理
420 |(% style="width:283px" %)用户反馈收集|(% style="width:157px" %)服务台
421 |(% style="width:283px" %)供应商策略，默认合同和供应商评价|(% style="width:157px" %)供应商管理
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 (% style="width:595px" %)
521 |(% style="width:232px" %)**实践成功因素（PSF）**|(% style="width:360px" %)**指标示例**
522 |(% style="width:232px" %)建立和维护有效的组织范围的服务设计方法|(% style="width:360px" %)(((
523 ● 遵循组织的产品组合中的服务设计方法
524
525 ● 适用于整个组织的产品组合
526
527 ● 利益相关者对选择的服务设计方法的满意度
528
529 ● 利益相关者对组织使用设计进行创新能力的满意度
530 )))
531 |(% style="width:232px" %)确保服务适合其用途并适合其整个生命周期的使用|(% style="width:360px" %)(((
532 ● 产品和服务满足功用和功效要求的百分比
533
534 ● 利益相关者对其所选的服务设计模型和方法的满意度
535
536 ● 利益相关者对组织设计产品和服务能力的满意度
537
538 ● 利益相关者对服务设计的财务效率的满意度
539 )))
540
541 将度量标准正确地聚合到复杂的指标中，将使对价值流的持续管理以及对服务设计实践的定期评估和持续改进变得更容易使用。没有单一的最佳解决方案。度量标准将基于组织的整体服务策略、优先级以及实践贡献的价值流目标。
542
543
544
545
546 ----
547
548 = **3 价值流和流程** =
549
550
551 == **3.1 价值流的贡献** ==
552
553 像任何其他ITIL 管理实践一样，服务设计对多个价值流有贡献。重要的是要记住，价值流不是由单个实践构成的。服务设计与其他实践相结合，可以为消费者提供高质量服务。服务设计对价值链活动的主要贡献是：
554
555 ● 设计和转换
556
557 ● 改进
558
559 ● 获取或构建
560
561 ● 计划。
562
563
564 (% style="text-align:center" %)
565 [[image:1639627911472-243.png]]
566
567 图3.1 服务设计对价值链活动贡献的热图
568
569
570
571 == **3.2 流程** ==
572
573 每个实践可能包含一个或多个流程和活动，它们对于实现该实践的目的可能是必需的。
574
575 **流程**
576
577 一组相互关联或交互的活动，可将输入转换为输出。流程定义动作的顺序及其依赖。
578
579
580 服务设计实践活动形成两个流程：
581
582 ● 服务设计规划
583
584 ● 服务设计协调。
585
586
587 === **3.2.1 服务设计规划流程** ===
588
589 该流程专注于服务设计实践的持续改、服务设计方法和模型，以及复杂服务设计实例计划的开发。它定期执行，并由事件或请求触发。根据现有模型和程序的效果，可能每两、三个月或更频繁地进行定期审查。该过程包括表3.1中列出的下列活动，并将下列输入转换为输出。
590
591 表3.1 服务设计规划流程的输入活动和输出
592
593 [[image:1642336864834-656.png]]
594
595 图3.1显示了该流程的工作流程图。
596
597
598 (% style="text-align:center" %)
599 [[image:1639627962923-326.png]]
600
601 图3.1 服务设计规划流程的工作流
602
603
604 表3.2 服务设计规划流程活动
605
606 [[image:1642336921452-619.png]]
607
608 [[image:1642336939536-376.png]]
609
610 [[image:1642336955974-592.png]]
611
612
613
614 === **3.2.2 服务设计协调流程** ===
615
616 该流程包括以下活动，并将以下输入转换为输出，如表3.3所示。
617
618 表3.3 服务设计协调流程的输入、活动和输出
619
620 [[image:1642337043542-690.png]]
621
622 [[image:1642337056767-690.png]]
623
624
625
626 图3.2显示了该流程的工作流程图
627
628 (% style="text-align:center" %)
629 [[image:1639628031552-968.png]]
630
631
632 图3.2 服务设计协调流程的工作流程
633
634
635 表3.4 进一步描述了这些活动。
636
637 表3.4 服务设计协调流程的活动
638
639 (% style="width:671px" %)
640 |(% style="width:134px" %)**实现价值**|(% style="width:534px" %)**描述**
641 |(% style="width:134px" %)确定适用的设计模型或计划|(% style="width:534px" %)服务设计团队评估服务要求、服务的复杂性、服务设计实例与现有服务之间的相互依赖性，预算和服务设计实例的风险，并选择要使用的适当服务设计模型或者使用新的模型。这可能会触发服务设计规划流程。
642 |(% style="width:134px" %)规划设计活动、资源和能力|(% style="width:534px" %)(((
643 设计团队基于服务设计模型计划设计活动，确定涉及的团队，计划并请求资源分配。可能需要一些其他能力，这些能力可能必须购买、外包或获得。
644
645 在这个阶段，更新SDP和风险管理的责任被分配。
646 )))
647 |(% style="width:134px" %)服务设计执行|(% style="width:534px" %)服务设计执行主要是编排和协调设计中涉及的团队和资源，以及管理需求跟踪、沟通和信息交换，使快速反馈和数据流成为可能，并确保在任何阶段对设计进行整体考虑。这是与其他相关实践一起进行的。可能涉及许多内部和外部团队。
648 |(% style="width:134px" %)服务设计评审|(% style="width:534px" %)服务设计团队执行服务设计评审，以确保符合标准和约定，并确保SDP的所有约定需求都已正确完成。因此，团队更新知识库并记录所吸取的教训。产生的服务设计评审报告可能触发服务设计规划过程。
649
650 ----
651
652 = **4 组织和人员** =
653
654
655 == **4.1 角色，能力和责任** ==
656
657 实践指南没有描述实践所有者或管理者的角色，这些角色应该存在于所有实践中。实践指南着重于每个实践的专门角色。每个角色的结构和命名可能因组织而异，因此ITIL中定义的任何角色都不应该被视为强制的，甚至不应该被推荐。记住，角色不是职位头衔。一个人可以担任多个角色，一个角色可以分配给多个人。
658
659 角色是在流程和活动的上下文中描述的。每个角色都有一个基于表4.1所示模型的能力概要。
660
661 表4.1能力代码和简介
662
663 (% style="width:607px" %)
664 |(% style="width:114px" %)**能力代码**|(% style="width:491px" %)**描述**
665 |(% style="width:114px" %)L|(% style="width:491px" %)**领导者 ** 决策、授权、其他活动的监督、激励和动机，以及结果的评估。
666 |(% style="width:114px" %)А|(% style="width:491px" %)**管理员 ** 分配任务并确定优先级，记录保存，持续的报告和基本的改进。
667 |(% style="width:114px" %)C|(% style="width:491px" %)**协调员/沟通者** 协调多方，利益相关者之间的沟通并执行宣传活动。
668 |(% style="width:114px" %)М|(% style="width:491px" %)**方法和技术专家**  设计和实施工作技术、程序文档、过程咨询、工作分析和持续改进。
669 |(% style="width:114px" %)Т|(% style="width:491px" %)**技术专家** 该角色专注于技术（IT）专业知识和基于专业知识的任务。
670
671 在组织中可能会发现三个特定于实践的角色：服务设计负责人，服务设计顾问和服务设计分析员。这些角色通常介绍给IT服务数量和变更率很高的组织。在其他组织中，服务设计活动由负责架构，产品或服务的人员或团队进行协调。这可能是产品负责人，服务负责人，服务交付经理，IT解决方案架构师或企业架构师。
672
673
674 === **4.1.1 服务设计领导者角色** ===
675
676 如果定义了一个专门的服务设计角色，通常是一位熟知组织产品且有扎实的设计思维能力的专家。（组织产品：架构，服务和相互依赖性；设计思维能力：开发战略设计模式，确定设计的适当性，协调团队合作和良好的风险管理技能）。该角色的能力要求是LMC。该角色通常负责服务设计流程中的专家活动的管理和成熟度，包括：
677
678 ● 服务设计实践的战略方向和成熟度
679
680 ● 服务设计实践的开发，包括培训，沟通和流程
681
682 ● 服务设计流程和控制的治理
683
684 ● 构建，利用和管理服务设计软件包。
685
686 在更复杂的组织中，一些服务设计职责可以委托给服务设计顾问。服务设计顾问专注于服务设计活动的开发和产业化，包括更详细的流程、服务设计包的要素、为变更计划提供咨询和编排服务供给。这个角色的能力要求是MC。
687
688 表4.2中列出了服务设计管理活动中可能涉及的其他角色，以及相关的能力概况和特定技能。
689
690 表4.2 服务设计管理活动中涉及的角色示例
691
692 [[image:1642337140758-426.png]]
693
694 [[image:1642337159991-744.png]]
695
696 [[image:1642337183859-914.png]]
697
698 [[image:1642337200274-628.png]]
699
700 [[image:1642337262218-988.png]]
701
702
703
704 == **4.2 组织结构和团队** ==
705
706 在大型、复杂或跨国组织中，为服务设计实践找到专门的组织结构是不常见的，尽管服务设计顾问的角色更广泛地与正式的职称联系在一起。在以产品为基础的组织中，通常不采用与常规服务设计活动相关的服务设计职务和角色，因为这一实践被集成到产品开发和管理团队的日常活动中，并且在任何可能的情况下都是自动化的。
707
708 在更多基于服务的组织中，可能会有专门的服务设计顾问，但是服务设计的活动更有可能由其他团队（例如，架构师，业务分析人员，服务引入和筹备专家）承担。只有那些拥有复杂的服务和产品组合的组织才会选择专门的服务设计实践组织结构。
709
710
711
712 ----
713
714 = **5 信息和技术** =
715
716
717 == **5.1 信息交流** ==
718
719 服务设计的效果基于所使用信息的质量。该信息包括但不限于以下信息：
720
721 ● 产品和服务及其现有的体系结构和设计，包括这些产品和服务的功能性和非功能性特征的基线
722
723 ● 通过风险管理实践定义的风险类别和风险偏好
724
725 ● 客户和用户
726
727 ● 合作伙伴和供应商，包括他们提供的服务的合同和SLA信息
728
729 ● 产品和服务的预期用途和范围，包括对组织的潜在风险
730
731 ● 第三方合同，包括与组织预期相比的漏洞和差距。
732
733 设计协调过程生成的关键信息包含在SDP中，SDP包含服务设计所需的所有信息。SDP还可以在生命周期的后期阶段支持服务。SDP可以由多个文档组成，可用于知识库、服务目录、配置管理工具等。
734
735
736 == **5.2 自动化和工具** ==
737
738 在服务设计的管理活动中，自动化可以带来显著的好处。虽然自动化服务设计顾问角色仍然有好处，但该角色所需的技能包括更高程度的解释和适当性，这将需要复杂的决策自动化。
739
740 对于服务设计实践，自动化和工具通过以下方面带来最多的价值：
741
742 ● 协作工具，用于在团队与不同的利益干系人组之间提供通信并跟踪任务
743
744 ● 需求跟踪工具，反馈收集和处理工具
745
746 ● 知识管理促进创新和教育的工具
747
748 ● 可视化工具可帮助可视化有关需求，设计解决方案，团队和组件集成等方面的信息
749
750 ● 人工智能工具可模仿用户行为或将用户行为集成到设计分析，假设测试等中。
751
752
753
754
755 ----
756
757 = **6 合作伙伴和供应商** =
758
759 仅使用组织自己的资源提供的服务很少。大多数（如果不是全部）依赖于其他服务，这些服务通常由组织之外的第三方提供（请参阅ITIL® Foundation：ITIL 4的2.4节：服务关系的模型）。架构管理和供应商管理的ITIL实践中描述了由支持服务引入的关系和依赖性。有关对第三方服务的依赖性的信息在变更、生命周期、控制、流程的所有步骤中都用在变更控制中，并且可能经常在变更优化流程中使用。
760
761 在采购流程期间服务设计通常会发现第三方提供服务中的漏洞。如果设计的产品或服务依赖于合作伙伴和供应商的资源和服务，那么这种依赖性的风险应该得到认真的解决。应对每个合作伙伴或供应商在产品或服务中带来的价值进行评估，以防范其带来的风险。
762
763
764
765
766 ----
767
768 = **7 重要提醒** =
769
770 实践指南的大部分内容都应作为组织在建立和培养自己的实践时可能考虑的领域的建议。实践指南是组织可能考虑的事情的目录，而不是答案的列表。使用实践指南的内容时，组织应始终遵循ITIL 指导原则：
771
772 ● 聚焦价值
773
774 ● 从你所处的地方开始
775
776 ● 基于反馈迭代推进
777
778 ● 协作和提升可视化程度
779
780 ● 通盘思考和工作
781
782 ● 保持简单实用
783
784 ● 优化和自动化。
785
786 有关指导原则及其应用的更多信息，请参见ITIL® Foundation：ITIL 4第4.3节的内容。
787
788
789
790
791 ----
792
793 = **8 致谢** =
794
795 AXELOS Ltd 非常感谢为本指南开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
796
797
798 == **8.1 作者** ==
799
800 Karen Brusch
801
802
803 == **8.2 审稿人** ==
804
805 Akshay Anand， Roman Jouravlev

导航

需要帮助？

如果您需要有关XWiki的帮助，可以联系：

深圳市艾拓先锋企业管理咨询有限公司