文档更改服务管理实践 - 19 服务设计

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,0 +1,1154 @@
	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