07 附录 A 价值流示例

author	version	line-number	content
1
2
3
4	[[阅读下一章>>http://itil4hub.cn/bin/view/1.1%20%E5%9F%BA%E6%9C%AC%E6%93%8D%E4%BD%9C/8%20%E8%BF%9B%E4%B8%80%E6%AD%A5%E7%9A%84%E7%A0%94%E7%A9%B6/]] [[返回上一章>>http://itil4hub.cn/bin/view/1.1%20%E5%9F%BA%E6%9C%AC%E6%93%8D%E4%BD%9C/6%20%E5%B0%BE%E6%B3%A8%20ITIL%E7%9A%84%E6%95%85%E4%BA%8B%EF%BC%8C%E4%B8%80%E5%B9%B4%E8%BF%87%E5%8E%BB%E4%BA%86/]]
5
6	{{box cssClass="floatinginfobox" title="Contents"}}
7	{{toc/}}
8	{{/box}}
9
10	= 附录 A 价值流示例 =
11
12	本节演示了如何将服务价值链应用于实际情况，并提供了价值流的示例。这些价值流显示了活动如何在价值链中流动。这些不是要复制的模型，而只是示例，用于理解应如何使用价值链。
13
14
15	示例包括一些示例工作角色。这些只是描述的虚构组织中可能存在的角色，并非对每个组织都建议使用的角色。为了帮助理解，对第一个价值流进行了一些详细的描述；在随后的示例中，只提供了一个表。
16
17
18
19	== A.1 一个用户需要事件被解决 ==
20
21	在价值流的第一个示例中，由于无线接入点发生了故障，仓库中的WiFi无法正常工作。这对业务有重大影响，因为叉车司机不能足够快地收到指示，因此有可能错过业务截止日期。这似乎是一个相对简单的事件。然而，它不能通过简单机械地遵循预定事件管理程序的步骤来解决。
22
23	首先，必须有人注意到发生了一个事件并知道如何报告，而且此人必须能够准确地传达情况的紧急性，以便正确地对事件进行排序。接收报告的人员必须具有升级事件的权限和程序，并能够监控事件的进展。资源必须到位，以便足够迅速的升级；必须有人具备调查该事件所需的技能、知识和工具；而且必须有适当的程序，在无需获得额外批准的情况下执行标准变更。必须有人能够访问准确的配置信息，并在修复完成后记录修复过程，还必须能够记录备件已被使用情况，并根据未来的需要重新对其进行订购。如果维修是有任何价值的，不管什么程度，都需要告知仓库发生了什么事，以便可以恢复正常工作。同样重要的是，检查事件的解决情况，以查看是否有可以吸取的教训。
24
25	表A.1总结了解决这一看似简单的事件所需的不同行动和资源。该表显示了多个实践如何支持这项工作，有些实践在不同时间支持多个价值链活动。
26
27
28	表A.1 例子：事件解决的价值流
29
30	\|(% style="width:169px" %)价值链活动/输入/结果\|(% style="width:233px" %)实践\|(% style="width:214px" %)角色\|(% style="width:679px" %)活动
31	\|(% style="width:169px" %)需求\|(% style="width:233px" %) \|(% style="width:214px" %)仓库经理、叉车司机\|(% style="width:679px" %)发现仓库的一个区域没有WiFi覆盖。这意味着叉车司机需要在整个仓库中开车来取他们的指令，从而导致延误并有可能错过业务截止日期。
32	\|(% style="width:169px" %)契动\|(% style="width:233px" %)服务台、事件管理\|(% style="width:214px" %)仓库经理、服务台客服\|(% style="width:679px" %)(((
33	仓库经理打电话给服务台并描述了这个问题。同意这是一个优先级为2的事件，并且将预期的解决时间通知给经理。
34
35	有关此事件的信息由服务台客服记录。
36	)))
37	\|(% style="width:169px" %)交付和支持\|(% style="width:233px" %)服务台、事件管理\|(% style="width:214px" %)服务台客服、网络支持工程师\|(% style="width:679px" %)该事件迅速升级到网络支持团队。
38	\|(% style="width:169px" %)交付和支持、改进\|(% style="width:233px" %)事件管理、变更控制、服务配置管理、IT资产管理、持续改进\|(% style="width:214px" %)网络支持工程师\|(% style="width:679px" %)(((
39	网络支持工程师确定无线接入点出现故障，并用备件库提供的备用设备进行替换。
40
41	这是一个标准变更，因此工程师无需额外批准。从配置管理系统获得新接入点所需的配置信息。IT资产信息已更新，以显示此备件已被消耗。
42
43	网络工程师更新事件管理系统，并将事件标记为已解决。
44
45	网络工程师会思考发生了什么，以及他们是否能够预测到这个问题或者更快地解决它。
46	)))
47	\|(% style="width:169px" %)契动\|(% style="width:233px" %)服务台、事件管理\|(% style="width:214px" %)服务台客服、仓库经理\|(% style="width:679px" %)服务台客服联系仓库经理，检查所有工作是否正常，然后关闭事件。
48	\|(% style="width:169px" %)价值\|(% style="width:233px" %) \|(% style="width:214px" %)仓库经理、叉车司机\|(% style="width:679px" %)WiFi覆盖恢复，叉车司机现在可以高效工作。
49	\|(% style="width:169px" %)契动、改进\|(% style="width:233px" %)服务台、事件管理、持续改进\|(% style="width:214px" %)仓库经理、服务台经理\|(% style="width:679px" %)一份简短的满意度调查通过电子邮件发送给仓库经理，由他们填写并返回。分数用于确定趋势，并将意见传递给服务台经理以供考虑。
50
51	== A.2 第三方软件中的错误为用户带来了问题 ==
52
53	在此示例中，用户在使用应用程序时发现问题。供应商有可用的修补程序，需要安装此修补程序以纠正这种情况。请注意，此事件通过服务价值链采取的路径非常不同，并且与上一事件相比，实践平衡有所不同。
54
55
56	表A.2 例子：软件问题的价值流
57
58	\|(% style="width:177px" %)价值链活动/输入/结果\|(% style="width:320px" %)实践\|(% style="width:129px" %)角色\|(% style="width:668px" %)活动
59	\|(% style="width:177px" %)需求\|(% style="width:320px" %) \|(% style="width:129px" %)行政助理\|(% style="width:668px" %)由于他们使用的软件存在错误，办公室的管理员助理无法在日历中输入约会。该软件不允许在房间名称中使用非标准字符。
60	\|(% style="width:177px" %)契动\|(% style="width:320px" %)服务台、事件管理\|(% style="width:129px" %)行政助理、服务台客服\|(% style="width:668px" %)(((
61	行政助理会致电服务台并说明问题。同意这是优先级为3的事件，并且将预期的解决时间通知行政助理。
62
63	有关此事件的信息由服务台客服记录。
64	)))
65	\|(% style="width:177px" %)交付和支持\|(% style="width:320px" %)事件管理\|(% style="width:129px" %)服务台客服\|(% style="width:668px" %)服务台客服研究供应商的网站，并发现此特定问题已在客户端软件的最新版本中得到解决。
66	\|(% style="width:177px" %)交付和支持\|(% style="width:320px" %)事件管理、供应商管理\|(% style="width:129px" %)服务台客服、二线支持\|(% style="width:668px" %)该事件已升级为二线支持。二线支持检查供应商合同和客户端软件的发布说明。
67	\|(% style="width:177px" %)交付和支持、获取/构建、契动\|(% style="width:320px" %)事件管理、服务请求管理，部署管理、服务验证和测试\|(% style="width:129px" %)二线支持、行政助理\|(% style="width:668px" %)与用户联系并安排他们测试客户端软件的新版本，以查看是否可以解决他们的问题。然后，他们将此版本添加到服务门户，以便用户可以安装它。
68	\|(% style="width:177px" %)交付和支持\|(% style="width:320px" %)事件管理、服务验证和测试、服务请求管理\|(% style="width:129px" %)行政助理、服务台\|(% style="width:668px" %)用户使用服务门户安装软件的新版本，并测试是否可以解决他们的问题。服务台确保用户对此解决方案感到满意。
69	\|(% style="width:177px" %)价值\|(% style="width:320px" %) \|(% style="width:129px" %)行政助理\|(% style="width:668px" %)该软件现在可以正常工作，并且用户可以使用房间名称中的非标准字符将约会添加到日历中。
70	\|(% style="width:177px" %)契动、改进\|(% style="width:320px" %)服务台、事件管理、持续改进\|(% style="width:129px" %)行政助理、服务台经理\|(% style="width:668px" %)简短的满意度调查将通过电子邮件发送给管理员，由他们完成并返回。分数用于识别趋势，并将意见传递给服务台经理以供考虑。
71	\|(% style="width:177px" %)改进\|(% style="width:320px" %)持续改进、服务验证和测试、服务请求管理、发布管理、部署管理\|(% style="width:129px" %)二线支持\|(% style="width:668px" %)二线支持在通过服务门户向所有用户提供新版本的客户端软件之前，对其进行更广泛的测试。升级会以可控的方式部署替换以前的版本。
72
73	表A.2 例子：软件问题的价值流
74
75
76	== A.3 业务需求一个重大的新IT服务 ==
77
78	在此示例中，鞋类制造商的内部IT部门确定了对新IT服务的需求。
79
80
81	表A.3例子：用于创建IT服务的价值流
82
83	\|(% style="width:167px" %)价值链活动/输入/结果\|(% style="width:274px" %)实践\|(% style="width:368px" %)角色\|(% style="width:486px" %)活动
84	\|(% style="width:167px" %)需求\|(% style="width:274px" %) \|(% style="width:368px" %)销售总监，销售经理\|(% style="width:486px" %)销售总监和经理确定需要一个新的网站，允许客户设计和订购个性化鞋子。
85	\|(% style="width:167px" %)契动\|(% style="width:274px" %)关系管理\|(% style="width:368px" %)销售总监、业务关系经理(BRM)\|(% style="width:486px" %)销售总监和BRM讨论新的网站，并商定调查其价值、结果、成本和风险，以确定是否可行。
86	\|(% style="width:167px" %)计划\|(% style="width:274px" %)组合管理、架构管理\|(% style="width:368px" %)BRM、IT战略团队、企业架构师、开发经理\|(% style="width:486px" %)讨论了新服务的创建，并确定了各种方法的成本和风险。这次机会优先于其他正在进行的工作，以决定是否有资源可用来执行它。
87	\|(% style="width:167px" %)计划\|(% style="width:274px" %)服务财务管理、风险管理\|(% style="width:368px" %)IT财务分析师、开发经理、项目管理办公室\|(% style="width:486px" %)讨论了各种方法的潜在的成本和风险，并为组合管理提供了输入。
88	\|(% style="width:167px" %)契动\|(% style="width:274px" %)关系管理\|(% style="width:368px" %)销售总监、BRM \|(% style="width:486px" %)销售总监和BRM讨论了新服务的预期价值、结果、成本和风险，并同意继续进行。
89	\|(% style="width:167px" %)计划\|(% style="width:274px" %)组合管理\|(% style="width:368px" %)BRM、IT战略团队\|(% style="width:486px" %)新服务被添加到服务组合中并记录在案。
90	\|(% style="width:167px" %)计划、设计和转换\|(% style="width:274px" %)组合管理、项目管理、服务设计\|(% style="width:368px" %)项目经理、开发经理\|(% style="width:486px" %)项目经理与开发经理开始计划创建新服务所需的工作。分配人员做必要的工作。
91	\|(% style="width:167px" %)契动\|(% style="width:274px" %)关系管理、项目管理、业务分析\|(% style="width:368px" %)销售总监、销售经理、业务分析人员、软件开发团队\|(% style="width:486px" %)对新IT服务的第一个版本的功用和功效提出了更详细的要求。
92	\|(% style="width:167px" %)获取/构建\|(% style="width:274px" %)软件开发和管理、项目管理、服务设计\|(% style="width:368px" %)软件开发团队\|(% style="width:486px" %)软件开发团队构建一个产品待办需求队列，确定最小可行产品，并开发足够的功能，以便业务部门可以对其进行审查和评论。
93	\|(% style="width:167px" %)获取/构建、设计和转换、改进\|(% style="width:274px" %)软件开发和管理、项目管理、服务设计\|(% style="width:368px" %)软件开发团队，BRM、销售总监、销售经理\|(% style="width:486px" %)对服务的第一次迭代进行评审并提供反馈。在此基础上，重新确定产品待办需求队列的优先级。
94	\|(% style="width:167px" %)获取/构建、设计和转换\|(% style="width:274px" %)服务级别管理、可用性管理、容量和绩效管理、信息安全管理、服务连续性管理、测量和报告、事件管理\|(% style="width:368px" %)软件开发团队、服务级别经理、基础设施经理、BRM、销售总监\|(% style="width:486px" %)(((
95	新服务的详细功效要求已协商并达成一致。
96
97	定义了监视、测量和报告以及支持服务的要求。
98	)))
99	\|(% style="width:167px" %)获取/构建、设计和转换\|(% style="width:274px" %)软件开发和管理、服务台、事件管理\|(% style="width:368px" %)软件开发团队、服务台经理\|(% style="width:486px" %)提供培训和文档，以支持新的服务。
100	\|(% style="width:167px" %)获取/构建、设计和转换、改进\|(% style="width:274px" %)软件开发和管理、项目管理、服务设计、组织变革管理、部署管理、发布管理\|(% style="width:368px" %)软件开发团队、BRM、销售总监、销售经理\|(% style="width:486px" %)基于软件开发团队和服务用户之间的密切协作，将创建新服务的更多增量版本。
101	\|(% style="width:167px" %)价值\|(% style="width:274px" %)项目管理、关系管理、服务级别管理、测量和报告\|(% style="width:368px" %)项目经理、BRM、服务级别经理、销售总监、销售经理\|(% style="width:486px" %)(((
102	对新服务的有效性进行评估，以检查其运行状况。并与初始预测进行比较。
103
104	就如何度量和报告持续价值达成一致。
105	)))
106	\|(% style="width:167px" %)契动、交付和支持、改进\|(% style="width:274px" %)事件管理、问题管理、持续改进\|(% style="width:368px" %)服务台、软件开发团队、基础架构支持团队\|(% style="width:486px" %)为新服务的事件和问题提供持续支持。
107	\|(% style="width:167px" %)价值、改进\|(% style="width:274px" %)关系管理、服务级别管理\|(% style="width:368px" %)服务级别经理、销售总监\|(% style="width:486px" %)每月定期召开会议，讨论服务绩效并确定改进机会。
108
109	== A.4法规变更需要开发新软件 ==
110
111	在此示例中，金融机构必须准备好满足新的监管要求。
112
113
114	表A.4 例子：新软件开发的价值流
115
116
117	\|(% style="width:132px" %)价值链活动/输入/结果\|(% style="width:251px" %)实践\|(% style="width:250px" %)角色\|(% style="width:661px" %)活动
118	\|(% style="width:132px" %)需求\|(% style="width:251px" %) \|(% style="width:250px" %)法务总监、合规经理\|(% style="width:661px" %)许多IT服务需要更新以满足新的监管要求。
119	\|(% style="width:132px" %)契动\|(% style="width:251px" %)关系管理\|(% style="width:250px" %)法务总监、合规经理、CIO\|(% style="width:661px" %)讨论新的监管要求，并商定创建一个项目来管理实施。
120	\|(% style="width:132px" %)计划\|(% style="width:251px" %)组合管理、服务财务管理、风险管理\|(% style="width:250px" %)CIO、IT战略团队、项目经理、开发经理\|(% style="width:661px" %)确定了各种方法的成本和风险，并商定了工作时间表和资源。
121	\|(% style="width:132px" %)(((
122	计划
123
124	契动
125
126	设计和转换
127	)))\|(% style="width:251px" %)项目管理、服务设计、业务分析 \|(% style="width:250px" %)项目经理、IT开发经理、业务分析师、产品经理\|(% style="width:661px" %)开始制定计划，人员被分派到计划工作。制定沟通计划，并通知所有需要参与的人。
128	\|(% style="width:132px" %)获取/构建\|(% style="width:251px" %)软件开发和管理、服务验证和测试、服务设计\|(% style="width:250px" %)软件开发团队\|(% style="width:661px" %)(((
129	每个软件团队管理一个产品需求待办队列，并为他们分配部分的开发代码并为分配给他们的部分开发代码。每个团队还通过自动化流水线进行开发测试。
130
131	所有代码每天都自动集成和测试两次，以确保不同团队编写的代码能协同工作。
132	)))
133	\|(% style="width:132px" %)(((
134	设计和转换
135
136	契动
137	)))\|(% style="width:251px" %)项目管理、服务设计、服务验证和测试\|(% style="width:250px" %)项目经理、IT开发经理、软件开发团队、合规经理\|(% style="width:661px" %)讨论并商定了发布和部署计划。在部署开始之前，商定所需的测试级别以及对每个部署进行授权的人员。
138	\|(% style="width:132px" %)(((
139	获取/构建
140
141	设计和转换
142	)))\|(% style="width:251px" %)服务设计、组织变革管理、部署管理、服务配置管理\|(% style="width:250px" %)软件开发团队\|(% style="width:661px" %)(((
143	新软件的部署一旦准备就绪，就会立即启动。不再需要单独的变更请求，因为风险评估已提前完成，并且自动化确保了代码的部署完全按照计划进行。
144
145	配置数据用于驱动部署，因此不需要单独的活动来更新。
146	)))
147	\|(% style="width:132px" %)价值\|(% style="width:251px" %)项目管理、关系管理\|(% style="width:250px" %)项目经理、CIO、法务总监、合规经理\|(% style="width:661px" %)对更新的服务进行评估，以确保所有监管要求得到满足。
148	\|(% style="width:132px" %)(((
149	契动
150
151	设计和转换
152	)))\|(% style="width:251px" %)项目管理、发布管理、服务台、服务目录管理\|(% style="width:250px" %)项目经理、软件开发团队、产品经理、服务目录经理\|(% style="width:661px" %)(((
153	新功能是通过功能开关来发布的，该开关允许用户可以看到新功能。
154
155	服务台和其他同事得到通知，新功能已经可以使用。同时服务目录已被更新。
156	)))
157	\|(% style="width:132px" %)(((
158	价值
159
160	改进
161	)))\|(% style="width:251px" %)项目管理、服务设计、关系管理、持续改进\|(% style="width:250px" %)项目经理、开发经理、CIO、法务总监、合规经理\|(% style="width:661px" %)对该项目进行了审查和关闭。寻找改进机会并将其添加到持续改进登记册中。
162
163
164
165	[[阅读下一章>>http://itil4hub.cn/bin/view/1.1%20%E5%9F%BA%E6%9C%AC%E6%93%8D%E4%BD%9C/8%20%E8%BF%9B%E4%B8%80%E6%AD%A5%E7%9A%84%E7%A0%94%E7%A9%B6/]] [[返回上一章>>http://itil4hub.cn/bin/view/1.1%20%E5%9F%BA%E6%9C%AC%E6%93%8D%E4%BD%9C/6%20%E5%B0%BE%E6%B3%A8%20ITIL%E7%9A%84%E6%95%85%E4%BA%8B%EF%BC%8C%E4%B8%80%E5%B9%B4%E8%BF%87%E5%8E%BB%E4%BA%86/]]

[[阅读下一章>>http://itil4hub.cn/bin/view/1.1%20%E5%9F%BA%E6%9C%AC%E6%93%8D%E4%BD%9C/8%20%E8%BF%9B%E4%B8%80%E6%AD%A5%E7%9A%84%E7%A0%94%E7%A9%B6/]] [[返回上一章>>http://itil4hub.cn/bin/view/1.1%20%E5%9F%BA%E6%9C%AC%E6%93%8D%E4%BD%9C/6%20%E5%B0%BE%E6%B3%A8%20ITIL%E7%9A%84%E6%95%85%E4%BA%8B%EF%BC%8C%E4%B8%80%E5%B9%B4%E8%BF%87%E5%8E%BB%E4%BA%86/]]

= **附录 A 价值流示例** =

本节演示了如何将服务价值链应用于实际情况，并提供了价值流的示例。这些价值流显示了活动如何在价值链中流动。这些不是要复制的模型，而只是示例，用于理解应如何使用价值链。

13

14

15

示例包括一些示例工作角色。这些只是描述的虚构组织中可能存在的角色，并非对每个组织都建议使用的角色。为了帮助理解，对第一个价值流进行了一些详细的描述；在随后的示例中，只提供了一个表。

== **A.1 一个用户需要事件被解决** ==

20

21

在价值流的第一个示例中，由于无线接入点发生了故障，仓库中的WiFi无法正常工作。这对业务有重大影响，因为叉车司机不能足够快地收到指示，因此有可能错过业务截止日期。这似乎是一个相对简单的事件。然而，它不能通过简单机械地遵循预定事件管理程序的步骤来解决。

22

23

首先，必须有人注意到发生了一个事件并知道如何报告，而且此人必须能够准确地传达情况的紧急性，以便正确地对事件进行排序。接收报告的人员必须具有升级事件的权限和程序，并能够监控事件的进展。资源必须到位，以便足够迅速的升级；必须有人具备调查该事件所需的技能、知识和工具；而且必须有适当的程序，在无需获得额外批准的情况下执行标准变更。必须有人能够访问准确的配置信息，并在修复完成后记录修复过程，还必须能够记录备件已被使用情况，并根据未来的需要重新对其进行订购。如果维修是有任何价值的，不管什么程度，都需要告知仓库发生了什么事，以便可以恢复正常工作。同样重要的是，检查事件的解决情况，以查看是否有可以吸取的教训。

24

25

表A.1总结了解决这一看似简单的事件所需的不同行动和资源。该表显示了多个实践如何支持这项工作，有些实践在不同时间支持多个价值链活动。

表A.1 例子：事件解决的价值流

|(% style="width:169px" %)**价值链活动/输入/结果**|(% style="width:233px" %)**实践**|(% style="width:214px" %)**角色**|(% style="width:679px" %)**活动**

31

|(% style="width:169px" %)**需求**|(% style="width:233px" %) |(% style="width:214px" %)仓库经理、叉车司机|(% style="width:679px" %)发现仓库的一个区域没有WiFi覆盖。这意味着叉车司机需要在整个仓库中开车来取他们的指令，从而导致延误并有可能错过业务截止日期。

32

|(% style="width:169px" %)**契动**|(% style="width:233px" %)服务台、事件管理|(% style="width:214px" %)仓库经理、服务台客服|(% style="width:679px" %)(((

33

仓库经理打电话给服务台并描述了这个问题。同意这是一个优先级为2的事件，并且将预期的解决时间通知给经理。

有关此事件的信息由服务台客服记录。

)))

|(% style="width:169px" %)**交付和支持**|(% style="width:233px" %)服务台、事件管理|(% style="width:214px" %)服务台客服、网络支持工程师|(% style="width:679px" %)该事件迅速升级到网络支持团队。

38

|(% style="width:169px" %)**交付和支持、改进**|(% style="width:233px" %)事件管理、变更控制、服务配置管理、IT资产管理、持续改进|(% style="width:214px" %)网络支持工程师|(% style="width:679px" %)(((

39

网络支持工程师确定无线接入点出现故障，并用备件库提供的备用设备进行替换。

40

41

这是一个标准变更，因此工程师无需额外批准。从配置管理系统获得新接入点所需的配置信息。IT资产信息已更新，以显示此备件已被消耗。

42

43

网络工程师更新事件管理系统，并将事件标记为已解决。

44

45

网络工程师会思考发生了什么，以及他们是否能够预测到这个问题或者更快地解决它。

46

)))

47

|(% style="width:169px" %)**契动**|(% style="width:233px" %)服务台、事件管理|(% style="width:214px" %)服务台客服、仓库经理|(% style="width:679px" %)服务台客服联系仓库经理，检查所有工作是否正常，然后关闭事件。

48

|(% style="width:169px" %)**价值**|(% style="width:233px" %) |(% style="width:214px" %)仓库经理、叉车司机|(% style="width:679px" %)WiFi覆盖恢复，叉车司机现在可以高效工作。

49

|(% style="width:169px" %)**契动、改进**|(% style="width:233px" %)服务台、事件管理、持续改进|(% style="width:214px" %)仓库经理、服务台经理|(% style="width:679px" %)一份简短的满意度调查通过电子邮件发送给仓库经理，由他们填写并返回。分数用于确定趋势，并将意见传递给服务台经理以供考虑。

50

51

== **A.2 第三方软件中的错误为用户带来了问题** ==

52

53

在此示例中，用户在使用应用程序时发现问题。供应商有可用的修补程序，需要安装此修补程序以纠正这种情况。请注意，此事件通过服务价值链采取的路径非常不同，并且与上一事件相比，实践平衡有所不同。

表A.2 例子：软件问题的价值流

|(% style="width:177px" %)**价值链活动/输入/结果**|(% style="width:320px" %)**实践**|(% style="width:129px" %)**角色**|(% style="width:668px" %)**活动**

59

|(% style="width:177px" %)**需求**|(% style="width:320px" %) |(% style="width:129px" %)行政助理|(% style="width:668px" %)由于他们使用的软件存在错误，办公室的管理员助理无法在日历中输入约会。该软件不允许在房间名称中使用非标准字符。

60

|(% style="width:177px" %)**契动**|(% style="width:320px" %)服务台、事件管理|(% style="width:129px" %)行政助理、服务台客服|(% style="width:668px" %)(((

61

行政助理会致电服务台并说明问题。同意这是优先级为3的事件，并且将预期的解决时间通知行政助理。

有关此事件的信息由服务台客服记录。

)))

|(% style="width:177px" %)**交付和支持**|(% style="width:320px" %)事件管理|(% style="width:129px" %)服务台客服|(% style="width:668px" %)服务台客服研究供应商的网站，并发现此特定问题已在客户端软件的最新版本中得到解决。

66

|(% style="width:177px" %)**交付和支持**|(% style="width:320px" %)事件管理、供应商管理|(% style="width:129px" %)服务台客服、二线支持|(% style="width:668px" %)该事件已升级为二线支持。二线支持检查供应商合同和客户端软件的发布说明。

67

|(% style="width:177px" %)**交付和支持、获取/构建、契动**|(% style="width:320px" %)事件管理、服务请求管理，部署管理、服务验证和测试|(% style="width:129px" %)二线支持、行政助理|(% style="width:668px" %)与用户联系并安排他们测试客户端软件的新版本，以查看是否可以解决他们的问题。然后，他们将此版本添加到服务门户，以便用户可以安装它。

68

|(% style="width:177px" %)**交付和支持**|(% style="width:320px" %)事件管理、服务验证和测试、服务请求管理|(% style="width:129px" %)行政助理、服务台|(% style="width:668px" %)用户使用服务门户安装软件的新版本，并测试是否可以解决他们的问题。服务台确保用户对此解决方案感到满意。

69

|(% style="width:177px" %)**价值**|(% style="width:320px" %) |(% style="width:129px" %)行政助理|(% style="width:668px" %)该软件现在可以正常工作，并且用户可以使用房间名称中的非标准字符将约会添加到日历中。

70

|(% style="width:177px" %)**契动、改进**|(% style="width:320px" %)服务台、事件管理、持续改进|(% style="width:129px" %)行政助理、服务台经理|(% style="width:668px" %)简短的满意度调查将通过电子邮件发送给管理员，由他们完成并返回。分数用于识别趋势，并将意见传递给服务台经理以供考虑。

71

|(% style="width:177px" %)**改进**|(% style="width:320px" %)持续改进、服务验证和测试、服务请求管理、发布管理、部署管理|(% style="width:129px" %)二线支持|(% style="width:668px" %)二线支持在通过服务门户向所有用户提供新版本的客户端软件之前，对其进行更广泛的测试。升级会以可控的方式部署替换以前的版本。

表A.2 例子：软件问题的价值流

== **A.3 业务需求一个重大的新IT服务** ==

77

78

在此示例中，鞋类制造商的内部IT部门确定了对新IT服务的需求。

表A.3例子：用于创建IT服务的价值流

|(% style="width:167px" %)**价值链活动/输入/结果**|(% style="width:274px" %)**实践**|(% style="width:368px" %)**角色**|(% style="width:486px" %)**活动**

84

|(% style="width:167px" %)**需求**|(% style="width:274px" %) |(% style="width:368px" %)销售总监，销售经理|(% style="width:486px" %)销售总监和经理确定需要一个新的网站，允许客户设计和订购个性化鞋子。

85

|(% style="width:167px" %)**契动**|(% style="width:274px" %)关系管理|(% style="width:368px" %)销售总监、业务关系经理(BRM)|(% style="width:486px" %)销售总监和BRM讨论新的网站，并商定调查其价值、结果、成本和风险，以确定是否可行。

86

|(% style="width:167px" %)**计划**|(% style="width:274px" %)组合管理、架构管理|(% style="width:368px" %)BRM、IT战略团队、企业架构师、开发经理|(% style="width:486px" %)讨论了新服务的创建，并确定了各种方法的成本和风险。这次机会优先于其他正在进行的工作，以决定是否有资源可用来执行它。

87

|(% style="width:167px" %)**计划**|(% style="width:274px" %)服务财务管理、风险管理|(% style="width:368px" %)IT财务分析师、开发经理、项目管理办公室|(% style="width:486px" %)讨论了各种方法的潜在的成本和风险，并为组合管理提供了输入。

88

|(% style="width:167px" %)**契动**|(% style="width:274px" %)关系管理|(% style="width:368px" %)销售总监、BRM |(% style="width:486px" %)销售总监和BRM讨论了新服务的预期价值、结果、成本和风险，并同意继续进行。

89

|(% style="width:167px" %)**计划**|(% style="width:274px" %)组合管理|(% style="width:368px" %)BRM、IT战略团队|(% style="width:486px" %)新服务被添加到服务组合中并记录在案。

90

|(% style="width:167px" %)**计划、设计和转换**|(% style="width:274px" %)组合管理、项目管理、服务设计|(% style="width:368px" %)项目经理、开发经理|(% style="width:486px" %)项目经理与开发经理开始计划创建新服务所需的工作。分配人员做必要的工作。

91

|(% style="width:167px" %)**契动**|(% style="width:274px" %)关系管理、项目管理、业务分析|(% style="width:368px" %)销售总监、销售经理、业务分析人员、软件开发团队|(% style="width:486px" %)对新IT服务的第一个版本的功用和功效提出了更详细的要求。

92

|(% style="width:167px" %)**获取/构建**|(% style="width:274px" %)软件开发和管理、项目管理、服务设计|(% style="width:368px" %)软件开发团队|(% style="width:486px" %)软件开发团队构建一个产品待办需求队列，确定最小可行产品，并开发足够的功能，以便业务部门可以对其进行审查和评论。

93

|(% style="width:167px" %)**获取/构建、设计和转换、改进**|(% style="width:274px" %)软件开发和管理、项目管理、服务设计|(% style="width:368px" %)软件开发团队，BRM、销售总监、销售经理|(% style="width:486px" %)对服务的第一次迭代进行评审并提供反馈。在此基础上，重新确定产品待办需求队列的优先级。

94

|(% style="width:167px" %)**获取/构建、设计和转换**|(% style="width:274px" %)服务级别管理、可用性管理、容量和绩效管理、信息安全管理、服务连续性管理、测量和报告、事件管理|(% style="width:368px" %)软件开发团队、服务级别经理、基础设施经理、BRM、销售总监|(% style="width:486px" %)(((

95

新服务的详细功效要求已协商并达成一致。

96

97

定义了监视、测量和报告以及支持服务的要求。

98

)))

99

|(% style="width:167px" %)**获取/构建、设计和转换**|(% style="width:274px" %)软件开发和管理、服务台、事件管理|(% style="width:368px" %)软件开发团队、服务台经理|(% style="width:486px" %)提供培训和文档，以支持新的服务。

100

|(% style="width:167px" %)**获取/构建、设计和转换、改进**|(% style="width:274px" %)软件开发和管理、项目管理、服务设计、组织变革管理、部署管理、发布管理|(% style="width:368px" %)软件开发团队、BRM、销售总监、销售经理|(% style="width:486px" %)基于软件开发团队和服务用户之间的密切协作，将创建新服务的更多增量版本。

101

|(% style="width:167px" %)**价值**|(% style="width:274px" %)项目管理、关系管理、服务级别管理、测量和报告|(% style="width:368px" %)项目经理、BRM、服务级别经理、销售总监、销售经理|(% style="width:486px" %)(((

102

对新服务的有效性进行评估，以检查其运行状况。并与初始预测进行比较。

就如何度量和报告持续价值达成一致。

)))

|(% style="width:167px" %)**契动、交付和支持、改进**|(% style="width:274px" %)事件管理、问题管理、持续改进|(% style="width:368px" %)服务台、软件开发团队、基础架构支持团队|(% style="width:486px" %)为新服务的事件和问题提供持续支持。

107

|(% style="width:167px" %)**价值、改进**|(% style="width:274px" %)关系管理、服务级别管理|(% style="width:368px" %)服务级别经理、销售总监|(% style="width:486px" %)每月定期召开会议，讨论服务绩效并确定改进机会。

108

109

== **A.4法规变更需要开发新软件** ==

110

111

在此示例中，金融机构必须准备好满足新的监管要求。

表A.4 例子：新软件开发的价值流

|(% style="width:132px" %)**价值链活动/输入/结果**|(% style="width:251px" %)**实践**|(% style="width:250px" %)**角色**|(% style="width:661px" %)**活动**

118

|(% style="width:132px" %)**需求**|(% style="width:251px" %) |(% style="width:250px" %)法务总监、合规经理|(% style="width:661px" %)许多IT服务需要更新以满足新的监管要求。

119

|(% style="width:132px" %)**契动**|(% style="width:251px" %)关系管理|(% style="width:250px" %)法务总监、合规经理、CIO|(% style="width:661px" %)讨论新的监管要求，并商定创建一个项目来管理实施。

120

|(% style="width:132px" %)**计划**|(% style="width:251px" %)组合管理、服务财务管理、风险管理|(% style="width:250px" %)CIO、IT战略团队、项目经理、开发经理|(% style="width:661px" %)确定了各种方法的成本和风险，并商定了工作时间表和资源。

121

|(% style="width:132px" %)(((

**计划**

**契动**

**设计和转换**

)))|(% style="width:251px" %)项目管理、服务设计、业务分析 |(% style="width:250px" %)项目经理、IT开发经理、业务分析师、产品经理|(% style="width:661px" %)开始制定计划，人员被分派到计划工作。制定沟通计划，并通知所有需要参与的人。

128

|(% style="width:132px" %)**获取/构建**|(% style="width:251px" %)软件开发和管理、服务验证和测试、服务设计|(% style="width:250px" %)软件开发团队|(% style="width:661px" %)(((

129

每个软件团队管理一个产品需求待办队列，并为他们分配部分的开发代码并为分配给他们的部分开发代码。每个团队还通过自动化流水线进行开发测试。

130

131

所有代码每天都自动集成和测试两次，以确保不同团队编写的代码能协同工作。

132

)))

133

|(% style="width:132px" %)(((

**设计和转换**

**契动**

)))|(% style="width:251px" %)项目管理、服务设计、服务验证和测试|(% style="width:250px" %)项目经理、IT开发经理、软件开发团队、合规经理|(% style="width:661px" %)讨论并商定了发布和部署计划。在部署开始之前，商定所需的测试级别以及对每个部署进行授权的人员。

138

|(% style="width:132px" %)(((

**获取/构建**

**设计和转换**

)))|(% style="width:251px" %)服务设计、组织变革管理、部署管理、服务配置管理|(% style="width:250px" %)软件开发团队|(% style="width:661px" %)(((

143

新软件的部署一旦准备就绪，就会立即启动。不再需要单独的变更请求，因为风险评估已提前完成，并且自动化确保了代码的部署完全按照计划进行。

144

145

配置数据用于驱动部署，因此不需要单独的活动来更新。

146

)))

147

|(% style="width:132px" %)**价值**|(% style="width:251px" %)项目管理、关系管理|(% style="width:250px" %)项目经理、CIO、法务总监、合规经理|(% style="width:661px" %)对更新的服务进行评估，以确保所有监管要求得到满足。

148

|(% style="width:132px" %)(((

**契动**

**设计和转换**

)))|(% style="width:251px" %)项目管理、发布管理、服务台、服务目录管理|(% style="width:250px" %)项目经理、软件开发团队、产品经理、服务目录经理|(% style="width:661px" %)(((

153

新功能是通过功能开关来发布的，该开关允许用户可以看到新功能。

154

155

服务台和其他同事得到通知，新功能已经可以使用。同时服务目录已被更新。

156

)))

157

|(% style="width:132px" %)(((

**价值**

**改进**

)))|(% style="width:251px" %)项目管理、服务设计、关系管理、持续改进|(% style="width:250px" %)项目经理、开发经理、CIO、法务总监、合规经理|(% style="width:661px" %)对该项目进行了审查和关闭。寻找改进机会并将其添加到持续改进登记册中。

[[阅读下一章>>http://itil4hub.cn/bin/view/1.1%20%E5%9F%BA%E6%9C%AC%E6%93%8D%E4%BD%9C/8%20%E8%BF%9B%E4%B8%80%E6%AD%A5%E7%9A%84%E7%A0%94%E7%A9%B6/]] [[返回上一章>>http://itil4hub.cn/bin/view/1.1%20%E5%9F%BA%E6%9C%AC%E6%93%8D%E4%BD%9C/6%20%E5%B0%BE%E6%B3%A8%20ITIL%E7%9A%84%E6%95%85%E4%BA%8B%EF%BC%8C%E4%B8%80%E5%B9%B4%E8%BF%87%E5%8E%BB%E4%BA%86/]]

Wiki源代码07 附录 A 价值流示例