7 附录 A 价值流示例
附录 A 价值流示例
本节演示了如何将服务价值链应用于实际情况,并提供了价值流的示例。这些价值流显示了活动如何在价值链中流动。这些不是要复制的模型,而只是示例,用于理解应如何使用价值链。
示例包括一些示例工作角色。这些只是描述的虚构组织中可能存在的角色,并非对每个组织都建议使用的角色。为了帮助理解,对第一个价值流进行了一些详细的描述;在随后的示例中,只提供了一个表。
A.1 一个用户需要事件被解决
在价值流的第一个示例中,由于无线接入点发生了故障,仓库中的WiFi无法正常工作。这对业务有重大影响,因为叉车司机不能足够快地收到指示,因此有可能错过业务截止日期。这似乎是一个相对简单的事件。然而,它不能通过简单机械地遵循预定事件管理程序的步骤来解决。
首先,必须有人注意到发生了一个事件并知道如何报告,而且此人必须能够准确地传达情况的紧急性,以便正确地对事件进行排序。接收报告的人员必须具有升级事件的权限和程序,并能够监控事件的进展。资源必须到位,以便足够迅速的升级;必须有人具备调查该事件所需的技能、知识和工具;而且必须有适当的程序,在无需获得额外批准的情况下执行标准变更。必须有人能够访问准确的配置信息,并在修复完成后记录修复过程,还必须能够记录备件已被使用情况,并根据未来的需要重新对其进行订购。如果维修是有任何价值的,不管什么程度,都需要告知仓库发生了什么事,以便可以恢复正常工作。同样重要的是,检查事件的解决情况,以查看是否有可以吸取的教训。
表A.1总结了解决这一看似简单的事件所需的不同行动和资源。该表显示了多个实践如何支持这项工作,有些实践在不同时间支持多个价值链活动。
表A.1 例子:事件解决的价值流
价值链活动/输入/结果 | 实践 | 角色 | 活动 |
需求 | 仓库经理、叉车司机 | 发现仓库的一个区域没有WiFi覆盖。这意味着叉车司机需要在整个仓库中开车来取他们的指令,从而导致延误并有可能错过业务截止日期。 | |
契动 | 服务台、事件管理 | 仓库经理、服务台客服 | 仓库经理打电话给服务台并描述了这个问题。同意这是一个优先级为2的事件,并且将预期的解决时间通知给经理。 有关此事件的信息由服务台客服记录。 |
交付和支持 | 服务台、事件管理 | 服务台客服、网络支持工程师 | 该事件迅速升级到网络支持团队。 |
交付和支持、改进 | 事件管理、变更控制、服务配置管理、IT资产管理、持续改进 | 网络支持工程师 | 网络支持工程师确定无线接入点出现故障,并用备件库提供的备用设备进行替换。 这是一个标准变更,因此工程师无需额外批准。从配置管理系统获得新接入点所需的配置信息。IT资产信息已更新,以显示此备件已被消耗。 网络工程师更新事件管理系统,并将事件标记为已解决。 网络工程师会思考发生了什么,以及他们是否能够预测到这个问题或者更快地解决它。 |
契动 | 服务台、事件管理 | 服务台客服、仓库经理 | 服务台客服联系仓库经理,检查所有工作是否正常,然后关闭事件。 |
价值 | 仓库经理、叉车司机 | WiFi覆盖恢复,叉车司机现在可以高效工作。 | |
契动、改进 | 服务台、事件管理、持续改进 | 仓库经理、服务台经理 | 一份简短的满意度调查通过电子邮件发送给仓库经理,由他们填写并返回。分数用于确定趋势,并将意见传递给服务台经理以供考虑。 |
A.2 第三方软件中的错误为用户带来了问题
在此示例中,用户在使用应用程序时发现问题。供应商有可用的修补程序,需要安装此修补程序以纠正这种情况。请注意,此事件通过服务价值链采取的路径非常不同,并且与上一事件相比,实践平衡有所不同。
表A.2 例子:软件问题的价值流
价值链活动/输入/结果 | 实践 | 角色 | 活动 |
需求 | 行政助理 | 由于他们使用的软件存在错误,办公室的管理员助理无法在日历中输入约会。该软件不允许在房间名称中使用非标准字符。 | |
契动 | 服务台、事件管理 | 行政助理、服务台客服 | 行政助理会致电服务台并说明问题。同意这是优先级为3的事件,并且将预期的解决时间通知行政助理。 有关此事件的信息由服务台客服记录。 |
交付和支持 | 事件管理 | 服务台客服 | 服务台客服研究供应商的网站,并发现此特定问题已在客户端软件的最新版本中得到解决。 |
交付和支持 | 事件管理、供应商管理 | 服务台客服、二线支持 | 该事件已升级为二线支持。二线支持检查供应商合同和客户端软件的发布说明。 |
交付和支持、获取/构建、契动 | 事件管理、服务请求管理,部署管理、服务验证和测试 | 二线支持、行政助理 | 与用户联系并安排他们测试客户端软件的新版本,以查看是否可以解决他们的问题。然后,他们将此版本添加到服务门户,以便用户可以安装它。 |
交付和支持 | 事件管理、服务验证和测试、服务请求管理 | 行政助理、服务台 | 用户使用服务门户安装软件的新版本,并测试是否可以解决他们的问题。服务台确保用户对此解决方案感到满意。 |
价值 | 行政助理 | 该软件现在可以正常工作,并且用户可以使用房间名称中的非标准字符将约会添加到日历中。 | |
契动、改进 | 服务台、事件管理、持续改进 | 行政助理、服务台经理 | 简短的满意度调查将通过电子邮件发送给管理员,由他们完成并返回。分数用于识别趋势,并将意见传递给服务台经理以供考虑。 |
改进 | 持续改进、服务验证和测试、服务请求管理、发布管理、部署管理 | 二线支持 | 二线支持在通过服务门户向所有用户提供新版本的客户端软件之前,对其进行更广泛的测试。升级会以可控的方式部署替换以前的版本。 |
表A.2 例子:软件问题的价值流
A.3 业务需求一个重大的新IT服务
在此示例中,鞋类制造商的内部IT部门确定了对新IT服务的需求。
表A.3例子:用于创建IT服务的价值流
价值链活动/输入/结果 | 实践 | 角色 | 活动 |
需求 | 销售总监,销售经理 | 销售总监和经理确定需要一个新的网站,允许客户设计和订购个性化鞋子。 | |
契动 | 关系管理 | 销售总监、业务关系经理(BRM) | 销售总监和BRM讨论新的网站,并商定调查其价值、结果、成本和风险,以确定是否可行。 |
计划 | 组合管理、架构管理 | BRM、IT战略团队、企业架构师、开发经理 | 讨论了新服务的创建,并确定了各种方法的成本和风险。这次机会优先于其他正在进行的工作,以决定是否有资源可用来执行它。 |
计划 | 服务财务管理、风险管理 | IT财务分析师、开发经理、项目管理办公室 | 讨论了各种方法的潜在的成本和风险,并为组合管理提供了输入。 |
契动 | 关系管理 | 销售总监、BRM | 销售总监和BRM讨论了新服务的预期价值、结果、成本和风险,并同意继续进行。 |
计划 | 组合管理 | BRM、IT战略团队 | 新服务被添加到服务组合中并记录在案。 |
计划、设计和转换 | 组合管理、项目管理、服务设计 | 项目经理、开发经理 | 项目经理与开发经理开始计划创建新服务所需的工作。分配人员做必要的工作。 |
契动 | 关系管理、项目管理、业务分析 | 销售总监、销售经理、业务分析人员、软件开发团队 | 对新IT服务的第一个版本的功用和功效提出了更详细的要求。 |
获取/构建 | 软件开发和管理、项目管理、服务设计 | 软件开发团队 | 软件开发团队构建一个产品待办需求队列,确定最小可行产品,并开发足够的功能,以便业务部门可以对其进行审查和评论。 |
获取/构建、设计和转换、改进 | 软件开发和管理、项目管理、服务设计 | 软件开发团队,BRM、销售总监、销售经理 | 对服务的第一次迭代进行评审并提供反馈。在此基础上,重新确定产品待办需求队列的优先级。 |
获取/构建、设计和转换 | 服务级别管理、可用性管理、容量和绩效管理、信息安全管理、服务连续性管理、测量和报告、事件管理 | 软件开发团队、服务级别经理、基础设施经理、BRM、销售总监 | 新服务的详细功效要求已协商并达成一致。 定义了监视、测量和报告以及支持服务的要求。 |
获取/构建、设计和转换 | 软件开发和管理、服务台、事件管理 | 软件开发团队、服务台经理 | 提供培训和文档,以支持新的服务。 |
获取/构建、设计和转换、改进 | 软件开发和管理、项目管理、服务设计、组织变革管理、部署管理、发布管理 | 软件开发团队、BRM、销售总监、销售经理 | 基于软件开发团队和服务用户之间的密切协作,将创建新服务的更多增量版本。 |
价值 | 项目管理、关系管理、服务级别管理、测量和报告 | 项目经理、BRM、服务级别经理、销售总监、销售经理 | 对新服务的有效性进行评估,以检查其运行状况。并与初始预测进行比较。 就如何度量和报告持续价值达成一致。 |
契动、交付和支持、改进 | 事件管理、问题管理、持续改进 | 服务台、软件开发团队、基础架构支持团队 | 为新服务的事件和问题提供持续支持。 |
价值、改进 | 关系管理、服务级别管理 | 服务级别经理、销售总监 | 每月定期召开会议,讨论服务绩效并确定改进机会。 |
A.4法规变更需要开发新软件
在此示例中,金融机构必须准备好满足新的监管要求。
表A.4 例子:新软件开发的价值流
价值链活动/输入/结果 | 实践 | 角色 | 活动 |
需求 | 法务总监、合规经理 | 许多IT服务需要更新以满足新的监管要求。 | |
契动 | 关系管理 | 法务总监、合规经理、CIO | 讨论新的监管要求,并商定创建一个项目来管理实施。 |
计划 | 组合管理、服务财务管理、风险管理 | CIO、IT战略团队、项目经理、开发经理 | 确定了各种方法的成本和风险,并商定了工作时间表和资源。 |
计划 契动 设计和转换 | 项目管理、服务设计、业务分析 | 项目经理、IT开发经理、业务分析师、产品经理 | 开始制定计划,人员被分派到计划工作。制定沟通计划,并通知所有需要参与的人。 |
获取/构建 | 软件开发和管理、服务验证和测试、服务设计 | 软件开发团队 | 每个软件团队管理一个产品需求待办队列,并为他们分配部分的开发代码并为分配给他们的部分开发代码。每个团队还通过自动化流水线进行开发测试。 所有代码每天都自动集成和测试两次,以确保不同团队编写的代码能协同工作。 |
设计和转换 契动 | 项目管理、服务设计、服务验证和测试 | 项目经理、IT开发经理、软件开发团队、合规经理 | 讨论并商定了发布和部署计划。在部署开始之前,商定所需的测试级别以及对每个部署进行授权的人员。 |
获取/构建 设计和转换 | 服务设计、组织变革管理、部署管理、服务配置管理 | 软件开发团队 | 新软件的部署一旦准备就绪,就会立即启动。不再需要单独的变更请求,因为风险评估已提前完成,并且自动化确保了代码的部署完全按照计划进行。 配置数据用于驱动部署,因此不需要单独的活动来更新。 |
价值 | 项目管理、关系管理 | 项目经理、CIO、法务总监、合规经理 | 对更新的服务进行评估,以确保所有监管要求得到满足。 |
契动 设计和转换 | 项目管理、发布管理、服务台、服务目录管理 | 项目经理、软件开发团队、产品经理、服务目录经理 | 新功能是通过功能开关来发布的,该开关允许用户可以看到新功能。 服务台和其他同事得到通知,新功能已经可以使用。同时服务目录已被更新。 |
价值 改进 | 项目管理、服务设计、关系管理、持续改进 | 项目经理、开发经理、CIO、法务总监、合规经理 | 对该项目进行了审查和关闭。寻找改进机会并将其添加到持续改进登记册中。 |