网站建设如何工作,vi设计是设计什么东西,网站空间支持下载但不能下载文件,邢台市建设局培训中心网站4. 创建、交付和支持服务的价值流
本章节提供了有关如何#xff1a;
记录一个价值流以理解工作流程如何贯穿该组织了解创建一个新服务的原型价值流了解支持一个现场服务的原型价值流
本章将帮助从业者理解#xff1a;
价值流在 服务价值系统(SVS) 中的作用价值流的分类如…4. 创建、交付和支持服务的价值流
本章节提供了有关如何
记录一个价值流以理解工作流程如何贯穿该组织了解创建一个新服务的原型价值流了解支持一个现场服务的原型价值流
本章将帮助从业者理解
价值流在 服务价值系统(SVS) 中的作用价值流的分类如何阐述一个价值流中存在的步骤如何将常见的数学建模理论应用于简化价值流当设计一个价值流时需要考虑的内容
实践者必须要理解价值流是简单易做的但不一定是简化的工作表现形式。 不同种类的工作遵循着不同的路线因此也有着很多种不同的价值流它们既可以指代设计或理想的活动模式也可以表达实际的、可观察的活动模式。相同的资源如个人、工具、供应商、或流程可以出现在价值流的不同部分例如一个运维专员可以是用户契动支持调查为恢复服务部署修复程序这些活动中的一部分。
4.1 ITIL服务价值流
ITIL价值链包括六种原型活动 参与、计划、改进、设计和移交、契动和交付和支持。一种思考价值流的有用方法是通过服务中的活动的旅程的可视化特定场景或需求类型的价值链。例如
不同类型的事件可能需要不同的价值流去描述每种情况下所需的工作例如 终端用户的硬件事件主要事件网络安全事件。 不同类型的客户需求可能需要不同的价值流例如 一个新产品或者增加业务运营效率的服务特性的需求一个要求团队成员访问产品或服务的请求一个要求新的基础设施能力以保留产品或服务正常运行的请求。
4.1.1 ITIL 服务价值流的结构 定义: ITIL 服务价值链 适用于服务提供商的运营模式涵盖了有效管理产品和服务所需的所有关键活动。
ITIL服务价值链由6个原型价值链活动组成。这些一系列活动被称为 ITIL服务价值流或者更简单地说价值流。一个价值链可以
提及一项、部分或所有价值链活动具体取决于的内容重复价值链活动依赖于进行中的工作
价值流包含一个或多个步骤一个步骤包含一个或多个用以实现特定目标的活动。这些活动可以是串行或并行的方式并且它们也可以连接到其他活动或彼此独立。活动本身可以包含一个或多个任务这些任务也可以是连接的或独立的。 定义: 价值流 组织为消费者创建并提供产品和服务而采取的一系列步骤
通过价值流模型服务组织可以将工作单元组成流程这些工作单元可能会根据环境和颗粒度级别而不同。例如在由消费者自发创建服务请求的价值流中
在价值流层面这个工作单元可以被定义作为客户的需求要被满足这可能改变这个在价值流中的服务组合的活动流向。在步骤层面可定义的工作单元作为需求需要被估算在价值流实施过程中这可能改变服务设计包中的角色定义的设计
图4.1显示了价值链活动、价值流、价值流中的步骤、步骤中的活动以及活动中的任务之间的关系。
价值流由需求发起的例如
由监控工具生成的事件用户提交的请求。 图 4.1 价值流活动层次结构
价值流通过创造或恢复功能性产品或服务的价值而截止。价值流需要使用到以下内容信息
一个或多个利益相关者执行步骤或行动的外部组织的输入例如通过用户移动设备发送的服务器名称或GPS 数据其他价值流例如一个价值流需要使用新员工入职的ID信息或其他信息这些信息来自雇用或签约新员工的价值流。
价值流使用服务提供者的资源服务消费者生成所需的输出并在管理体系、治理系统、外部因素、约束和原则内工作。
价值流将产生用于创造预期结果的输出。此输出可以包括与利益相关者共享的信息和反馈并有助于执行管理活动或治理活动。在某些情况下这些输出也可作为组织内部或外部的其他价值流的触发器。
4.1.2 价值流和组织
ITIL 4 并不将组织等同于公司实体。组织可以是一个人例如个体经营者程序员或顾问、团队例如开发或支持作为业务单位的团队、企业甚至企业协同工作的生态系统.
价值流从根本上与组织有关。因此每个颗粒度的层次都可能存在价值流它们可以为单个人、一个团队、一个业务部门等。但是重要的是要记住该价值流是被所建立的系统的环境定义的而其目的是为组织、其客户和其他利益相关者创造价值。一个大型企业可以包括几个不同的拥有一定程度的自主权管理的组织可以将它们中的每一个都视为具有自身价值的 服务价值系统(SVS)价值链和价值流。但是其自给自足的可能性不大服务价值系统(SVS) 需要在团队级别建立。
应从头到尾描述产品或服务的总体目标和期望也就是说从需求到价值而不是简单地描述每个团队在一组不同或不协调的活动中的使用。因此价值流将代表不同团队的工作影响不同的利益相关者使用不同的流程工具和人员有时甚至是不同的供应商。
ITIL 服务价值流需要可视化并明确指出用户与产品、服务或 IT 服务管理专业人员交互的接触点。ITIL 价值流技术的一个关键优势是不仅能够识别多个利益相关者的参与但也要看到潜在的故障点并将价值与需求明确联系起来。 关键信息 价值流和流程之间的主要区别在于它们的关注点以及使用方式。可以将许多输入转化为输出的相互关联的活动视为流程。 价值流的关注点围绕在从需求或机会到客户价值实现的活动流。流程分类法、流程管理工具或技术可以被用于价值流。因此许多流程并不是价值流。
价值流中的每一步都可以重新定义为一个过程或者一个价值流。后者对于涉及多个企业的大型企业和生态系统来说是典型的。 示例 乘火车旅行的乘客可能会与多个服务提供商互动这取决于所选择的国家和路线。这些服务提供商中有一些是运送人员的铁路公司。其他服务提供商有车站管理、售票、安全保障调度和火车导航等。铁路旅行是一个复杂的生态系统许多组织通过合作和协作来创造无缝和舒适的用户旅程。每个组织都需管理好自己的SVS这其中包含多个价值流。同时这些组织为价值流协作做出了贡献进而实现并支撑了铁路旅行。价值流的某些步骤实际上是由参与组织的价值流实现的。
为 IT服务添加新功能的高级价值流可能涉及第三方供应商、内部软件开发团队、站点可靠性工程团队、其他IT团队和用户团队。 外部供应商执行的步骤很可能作为供应商自己的价值流进行管理。在组织内进行的步骤是形式化的作为这些过程中涉及的行为或活动的流程管理。
将价值流级联到较低级别的价值流或流程允许组织
专注于更高层次价值流的价值结合参与方的价值流和流程迭代改进依赖价值流中其他组织或团队的反馈 协作并提升跨组织和团队工作流程的可见性通过了解更广泛的组织或生态系统如何运作和受益以及参与方所做的工作整体思考和工作。
4.1.3 价值流注意事项
4.1.3.1 选择正确的视角
价值流可以从两个角度中的一个来记录。一方面可以被设计成反映服务提供商的愿望另一方面记录工作执行情况进行研究。当记录下来后可以将设计与观察到的行为进行比较。
设计与观察到的行为之间的差异可能会触发改进。这些可能包括
更新价值流文档以反映实际的工作模式通过减少转换时间来优化工作流程将需求转化为价值并自动化可重复的工作。
4.1.3.2 起点和终点
价值流始终以需求为开始以为一个或多个利益干系人创建价值或实现价值而结束。因此一种可取的方式是在记录价值流时应保持一种由外而内的声音例如通过以下方式
能够反映业务计划的里程碑和时间表能够使用与观众相关的语言从客户或用户的角度构建成果和价值。
4.1.3.3 灵活性
根据执行工作的背景和环境价值流重复使用价值链中的活动。价值流可以根据组织的需要而灵活定制。例如组织可以在工作期间添加某一阶段类似于瀑布方法或者在价值链活动之间创建迭代循环。
4.1.3.4 颗粒度
价值流在一定程度上可以体现工作的颗粒度。例如使用敏捷软件活动的价值流可以展示出多个工作迭代从而反映出该方法所具备的探索性质。或者价值流可以体现更高层次的视角该视角允许工作表示为一个步骤。无论工作如何表示在整个价值流中颗粒度保持统一是至关重要的。
4.1.3.5 识别步骤
价值流应该使用哪些步骤这些步骤应该包括什么活动在决策时应该考虑以下几点
价值流的详细程度。组织需要决定应显示所有操作的详细信息还是仅提供工作概述。个人或团队之间的工作交接会对价值流产生的影响。通常最好将不同团队执行的活动显示为不同的步骤。这有助于了解队列中哪些工作存在延迟。对价值流产生影响的价值链中的多个活动。
包括多个价值链活动
如果一个步骤同时包含契动和计划两个活动更合理的方式是将其分为两个单独的步骤。例如步骤“确定客户需求”可以分为
与客户一起定义需求可使用服务台、关系管理等实践的贡献映射到价值链中的契动活动评估客户需求可使用业务分析、风险管理等实践的贡献映射到价值链中的计划活动。
同样步骤“通过供应商网站实施补丁程序”可以分为
从网站下载补丁程序可使用软件开发和管理、供应商管理等实践的内容映射到价值链中的获取/构建活动部署此补丁程序可使用变更管理、部署管理等实践的贡献映射到价值链中的设计和转换活动。
如果多个步骤是由同一组人或同一组资源执行最好能将它们作为价值链活动中的单独步骤进行描述这样就能最好地描述组合步骤的输出。这也有助于避免每个步骤之间排队等待对工作的影响。
4.1.3.6 步骤顺序
尽管价值流通常以契动作为活动的开始但其他活动也可以作为第一步。例如如果工程师通过监控工具发现的事件需求则第一步活动可能是开始调查交付和支持这种情况不太可能去直接联系受影响的客户契动。
4.1.3.7 映射到服务价值链
价值流的步骤可以通过映射到价值链的活动中进行描述其实价值链的活动也是通过基础性活动或任务的映射进行描述。例如
评估客户需求的步骤可以映射到价值链中的计划活动但是也可以映射到价值链中契动活动的被称为 “与客户一起完善需求”的活动或任务。从供应商网站下载补丁程序的步骤可以映射到价值链中的获取/构建活动但是也可以映射到价值链中的改进活动的被称为“更新解决方法”的活动或任务。
4.1.3.8 映射到实践
可以根据颗粒度级别将价值流中的步骤、活动或任务映射到实践中的流程或过程。例如开发部署代码的步骤可以映射到以下的活动和任务
执行自动化测试的程序执行人工测试的流程
4.1.4 设计服务价值流
鼓励从业人员使用以下方法或尝试其他方法以确保满足组织需求。
1、通过以下内容定义价值流的用例或场景
需求最好是非技术的术语产生需求的触发因素价值流创造的结果在价值流环境中的价值因为价值可以是创建或被恢复。
2、从需求到价值的整个服务价值链中记录所需的步骤。
3、从步骤2开始映射到服务价值链。
4、如果有必要将步骤拆分为活动或任务。
5、确定相关实践或相关资源以有助于每个步骤、活动或任务的成功完成包括
运营或管理团队或个人工具和技术信息和数据例如记录、表格任何合作伙伴或供应商他们可以通过自有资源实现输出或成果。
以上五个步骤应以协作的方式完成例如可以组织一系列的会议或研讨。编制文档的首要任务是建立广泛而基础的理解并形成基线以便有针对性地响应需求、创造价值。
建立基线后可以通过以下方式进一步尝试或优化价值流
创建简单的模拟来测试工作流程消除对输出、结果或收益没有意义的工作左移工作延迟可能造成质量偏差、成本偏差或时间偏差的工作引入反馈机制和升级机制以确保不断改善价值流的输出质量和收益从步骤、活动或任务等方面识别自动化改进机会以加速工作流识别并管理瓶颈或约束这可能需要围绕约束重新设计价值流引入审查触发机制必要时改进价值流。审查可以是随机的”例如可以在消费者反馈时“也可以是定期进行。
4.1.5 描述价值流的步骤
在描述价值流中的步骤时需要识别并记录以下内容
步骤名称 定义步骤是什么。决定是否要使用非技术语言描述该步骤。避免使用首字母缩写词和行话以便价值流评估人可以轻松地理解其目标是什么例如 价值流步骤的短语“注册用户事件”比“使用INC_template记录事件工单”更好。短语“记录客户需求”比“用客户输入填写TK421表”更好。输入触发器 触发器可导致步骤开始。信息 描述步骤所需的信息。应该在执行价值流活动之前从外部利益干系人或其他组织获得资源。实践的贡献 有助于组织成功完成实践步骤的工具、技术、个人和其他资源。活动或任务 根据触发器条件和输出结果要求明确需要执行哪些活动哪些活动可以并行哪些活动需要有先决条件每个活动或任务需要的执行时间约束 该步骤需要遵循哪些原则这些原则由服务提供者或外部利益相关者来定义。最重要的是组织应探索可能面临的资源限制。输出 步骤存在的原因。步骤需要实现输出并为服务提供者、使用者或其他利益相关者创造价值。估计或目标交货时间 完成一个步骤应该花费的时长包括队列等待所花费的时间。
以下模板可以作为价值流描述的初始参考。第一个模板表4.1提供了价值流的摘要第二个模板表4.2提供了描述价值流的步骤结构。鼓励从业者使用他们认为合适的模板。
表格 4.1 服务值流描述模板
价值流名称所有人价值流及其用例的描述需求触发器结果已创造价值预估交货时间或目标交货时间
表格 4.2价值流步骤描述模板
价值流名称步骤编号步骤名称价值链活动契动、计划、改进、设计和转换、获取/构建、交付和支持输入触发器和信息输出触发器和信息预期结果交货时间的估计值或交货时间的目标值支持实践实践名称描述实践如何为此步骤做出贡献角色和责任A负责任的R执行的C被咨询的I被告知的
注意应以整体的方式描述实践贡献避免使用技术术语如果可行。
4.1.6 价值流映射
价值流映射起源于精益制造技术。这是一种从需求机会到价值实现的可视化工作流其工作流可有计划地持续改进。在精益中核心思想是最大化客户价值同时将浪费最小化。简而言之精益涉及以更少的资源为服务消费者创造更多价值。精益组织了解服务对消费者的价值并将其关键流程集中在增加价值上。
我们的目标是通过不产生任何浪费的完美价值创造过程为服务消费者提供完美价值。为实现这个目标精益思想通过将横跨技术、资产和部门的水平价值流将管理的重点从优化单独的技术、资产和垂直部门转变为对消费者的产品和服务的流程进行优化。
价值流映射用于深入了解组织的工作流程并在ITIL中发挥重要作用。它可用于识别价值流中的增值活动和非增值活动同时可以发现优化和自动化的改进机会。价值流映射包括评估例如记录工作流程从需求机会到价值实现的真实状态和计划例如规划对工作流程进行改进的变更。
在许多组织中关注单个流程会导致仅在较小的控制范围内优化流程中的步骤例如针对单个团队或部门因而忽略了此局部优化对整个价值流的影响。局部优化会对价值流造成深入的瓶颈并有可能使价值流的整体性能变差而不是更好。
与传统业务系统相比消除整个价值流中的浪费而不是孤立在某些点可以创建人力、空间、资金和时间所需更少、成本更低、缺陷更少的流程。
价值流图是优化整个价值链不仅仅是局部优化的绝佳工具。这种全局的观点与整体思考和工作的指导原则完全吻合。价值流映射通过以下方式帮助组织
流程可视化不仅在单个流程级别例如生产中的装配、焊接等可以使从机会到价值的整体流程更清晰使每个价值流中的资源浪费更加明显提供用于讨论价值流和流程的统一语言使有关流程的决策变得清晰化以便可以进行讨论以防止在较低级别上做出随意的决策将精益的概念和技术联系在一起以防止孤立地使用其中的一两个形成实施或改进点计划的基础。通过帮助组织设计端到端工作流的操作方式价值流图成为实施的蓝图。展示了信息流和物料流之间的联系。
价值流映射最初是在制造背景中开发的但是如ITIL中所述它同样适用于服务的创建和交付。在服务价值体系中涉及服务价值流的任何方面都应包含在价值流图中。
在IT和服务管理中可以找到许多不同的价值流它们因机会或需求的来源、所需的结果以及相关的价值的差异而有所不同。例如在服务价值流映射中分别定义了用于尽快恢复服务的流程活动按照商定可用性级别交付服务的流程活动以及处理服务变更的流程活动。
价值流映射的结果可用于多种情况例如编写业务案例、定义优先级、优化组织内的服务价值流和实践、查明现有实践中的瓶颈、和获得对影响组织问题的共识。但是价值流图的最重要的作用是确定需要实现哪些改进点动作才能实现未来期望的结果。
有关更多信息请参见ITIL®4指导计划和改进。
4.1.7 分析价值流时的关键指标
可以为任何工作流程和活动定义以下几个重要的指标。这些在表4.3中概述并在图4.2中显示。
表格 4.3 工作流程指标
术语描述节点周期完成离散工作单元将输入转换为输出所需的时间。例如花费五分钟填写一个新的事件表格则周期就是五分钟。等待时间工作开始之前离散工作单元在队列中等待的时间。例如事故单在开始工作之前平均等待四个小时则等待时间为四个小时。交货时间节点周期和等待时间的总和。交货时间表示完成离散工作单元从其进入流程队列到流程结束所需的总时间。流程队列等待流程处理的离散工作单元的数量。在制品WIP正在操作但尚未完成的离散工作单元的数量吞吐量工作进入或退出系统的速率 图 4.2处理时序
这些术语源自利特尔定律有关更多信息请参见运营管理或排队理论文献。利特尔定律可以简单地表示为
进行中的工作 吞吐量×交货时间 或 进行中的工作 吞吐量×周期时间等待时间
这种数学表示形式适用于简单的系统。但是在复杂的环境中同时发生多个活动、步骤或任务的情况下应用此模型可能会更加困难。
系统的简单性取决于价值流、活动或任务的粒度。例如新服务的价值流可能被简单地表示并且处于高阶层次如图4.3所示。 图4.3 价值流的简单表示
图4.4表示相同的价值流它具有更高的准确性并且在更精细的级别上具有明显更高的复杂性。显然将前置时间队列时间和等待时间进行建模更加困难。 图 4.4价值流的复杂表示
无论环境如何复杂在设计价值流、步骤或行动时利特尔定律都提出以下注意事项
在执行各种步骤/操作/任务时建议尽量减少各类资源间传递工作的次数尤其是如果这些资源是独立的。传递就会产生队列队列就会产生等待时间从而增加了交货时间。减少潜在传递的数量通常是通过提高自动化程度提高人员技能以增加他们可以完成任务的程度或重组团队通常称为分解竖井来实现。吞吐量通常不受服务提供者的控制尤其是在外部事件和触发器的背景中。但是使用统计建模功能例如泊松分布高斯分布和帕累托分布可以帮助评估活动模式。例如超场无法预测在工作日的每个小时内购物者的确切人数但是它可以使用统计模型来创建估计值。在简单的系统中等待时间可以表示为节点周期的函数。一个新的工作单元是周期时间乘以系统中已有的工作单位。例如如果完成一个工作单元需要10分钟当前正在执行一个单元而正在等待三个单元则 队列中进入系统的下一个工作单位将花费10分钟/单位×1 3单位 40分钟下一个工作单元的交货时间将是40分钟等待时间 10分钟节点周期 50分钟根据粒度级别和工作性质节点周期可以假定认为是固定的和可预测的。为了创建更可预测的节点周期可能有必要限制在制品数量。该技术是看板方法的一部分在可预测吞吐量工作量的环境中效果很好。例如一个团队可能一次将其在制品限制为三个请求因此如果在制品超过此限制则延迟处理任何其他请求。
ITIL 故事: ITIL 服务价值
亨利:艾克苏汽车租赁采用服务价值流来绘制整个组织的工作流程。价值流展示了组织如何利用信息、工具、流程和其他结构化的工作方式来创建产品和服务。它们有助于我们通过任何给定场景或利益相关者的价值链活动形象化过程例如当我们为用户创建新功能或为客户服务台更新脚本时
索尔马兹: 我们利用ITIL的服务价值流帮助我们的员工、合作伙伴和供应商了解如何为客户创造价值。我们定期审查我们的价值流以确定改进运营的方法。
雷尼: 我们将利用从试点中吸取的经验教训通过价值流的使用规范我们如何应对常见问题。我们已经确定了两个需要优先考虑的场景新功能的开发以及当客户体验到服务降级时我们向他们提供的支持级别。在我们的待办事项中还有许多其他场景例如自行车归还时服务缓慢。
4.2 价值流模型用于创建、交付和支持
本节探讨了几乎在所有组织中都可以找到的两种常见的价值流模型
新服务的开发 组织经常发现有必要创建、修改或淘汰服务。这种价值流反映了创建新服务所需的常见工作模式因此通常需要在整个组织中付出大量的努力和协调。恢复现有服务 在现代复杂的IT组织中可以预料到故障必须对其进行快速管理。此价值流与检测和解决故障时的典型活动有关以及如何将这些活动用于改进服务。
这些价值流模型应适合每个组织的需求因为背景、复杂性、粒度级别、步骤数、每个步骤的输入和输出都将有所不同。
尽管这些模型使用第4.1节中的模板但存在许多替代方法例如示例目标交货时间和示例角色。这些阐明了如何使用表格不应将其解释为规范性指导或标准的活动计算。
当以下各节内容涉及到实践贡献中的资源时它们包括服务管理的四个维度的任何或全部
组织和人员 技能管理权限资金人员配备等信息和技术 工具数据库数据对象信息对象等合作伙伴和供应商 为组织等提供产品和服务的供应商。价值流和流程 流程过程模板等
4.2.1 开发新服务
这种价值流原型研究组织在创建新服务或修改现有服务时的常规活动。它与服务的性质无关可以用来描述用于创建服务的价值流这些服务可以提供给组织内部的客户也可以提供给组织外部的客户。
4.2.1.1 设计考虑
设计此值流时典型的注意事项包括
确定如何管理工作。使用顺序瀑布阶段应对较大的增量或以快速反馈的方式在短时间内更改规格例如敏捷方法应对较小的增量或者两者混合根据工作的管理方式可能有必要创建单独的价值流并在每个价值流中描述不同的项目管理方法。建立正确的监督级别以保持对业务成果而不是仅关注输出物。建立正确的层级管理机构以确保各个组织单位与组织的合作伙伴、供应商、客户、用户和其他主要利益相关者之间的活动得到有效协调。融入所有必需的实践活动用以创建新服务实现端到端贯通实现整体愿景的工作成果。确保组织对客户的预期目标和期望有清晰的了解并从头到尾跟踪每个目标和期望以确保服务支持所需的结果。在将客户需求转换为服务成果功能性或非功能性时组织应避免引入冲突或不一致。了解客户从需求到价值的过程并从客户的角度定义需求而不是仅仅依靠内部视角或团队成员的先前经验。
4.2.1.2 从需求到价值的旅程
此价值流通过六个关键步骤描述了从需求出发的过程如图4.5所示
确认并记录服务要求契动决定是否投资新服务计划设计和架构新服务以满足客户要求设计和转换构建配置或购买服务组件获取/构建部署服务组件以准备启动设计和转换为客户和用户发布新服务交付和支持。 图 4.5 开发新的服务
4.2.1.3 需求和价值
此价值流是由创建新服务的需求触发的。它可能来自
服务消费者赞助商、客户或用户。服务消费者可以在服务提供者外部也可以是同一组织的成员取决于具体环境。服务消费者以外的外部利益干系人例如供应商或监管机构。提供者服务职能部门例如销售或市场营销的一名工作人员已经感觉到新的机会。SVS外部的机会可以转化为共同创造价值的需求。该组织的治理主体的成员。
依据环境和工具可以有多种方式识别需求。通常需求是高级经理或其授权代表的要求。请注意此值流的后续步骤将请求者视为发起价值流的个人或角色。它并不视为在服务请求管理中的角色。
在此阶段重要的一点是需求必须阐明服务的期望结果和期望值。一种有用的技术是使常用的Agile软件开发模板描述重要事情和用户故事从而分解了以下需求
作为角色我想要结果以便价值。
例如
作为业务开发经理我想跟踪我的销售流水线以便专注于完成新交易。作为基础架构工程师我希望能够对报警通知进行分组以便可以关联警报并消除重复项。
步骤1确认并记录服务需求 对新产品或服务特性的任何请求均始于确认并记录需求。通常业务案例方法用于收集和评估需求。重要的是要记住目标是收集足够的信息以提交业务案例。
成功完成此步骤要求服务组织与请求者和其他利益相关者例如市场用户和样本用户共同驱动使用调查和民意测验来完成业务案例模板获得包含有关需求、收益定量和定性两者、成本、风险的高阶信息。各种技术和服务管理团队在综合考量开发、发布、运营和支持的成本的情况下完成高阶估算并补充信息。
通常对此步骤有贡献的实践包括
业务分析 根据业务案例提供记录客户需求所需的技能、工具和其他资源以进行深度适合的可行性评估。组合管理 提供有关当前退休和将来计划的服务的信息。关系管理 提供技能、信息和其他资源以管理请求者的期望并与服务提供者建立融洽关系。服务配置管理 提供有关当前运行的服务和服务组件的信息以便在描述需求时提供内容。服务级别管理 提供有关当前服务级别的信息以在描述需求时提供内容。
步骤2决定是否投资新服务 当请求细化并记录在业务案例中后可能有必要澄清初始成本、收益和风险评估以便服务组织可以计划工作。这将需要与各个内部团队进行更详细的讨论并可能需要与客户和其他外部利益相关者进行持续的对话。完成后管理团队可以评估业务案例然后由管理团队决定是否授予批准。
通常对此步骤有贡献的实践包括
业务分析 提供与各种专家团队合作所需的技能、工具和其他资源针对业务案例中记录的客户需求收集补充信息并进行可行性分析。基础设施和平台管理 提供有关设计和开发新服务的基础结构组件的补充评估以及对于正运行的应用程序影响分析的补充评估。还根据需要为业务案例评估做出贡献。组合管理 提供必要的资源以允许服务所有者完成可行性评估并决定是否对新服务的投资授权问题管理 提供有关当前错误和解决方法的信息这些错误和解决方法可能会影响新功能。项目管理 提供管理和技术资源以完成业务案例评估。概述可用于完成表4.2中的价值流步骤模板。风险管理 提供有关新功能可能在正面或负面带来企业风险的信息。服务配置管理 提供有关当前运行服务和配置项的信息。服务设计 提供有关设计新服务以满足功用、功效、品牌或其他指标的内部标准和政策的补充评估并在必要时为业务案例评估做出贡献。服务台 提供有关新服务影响当前客户和用户支持渠道的补充评估并在必要时对业务案例评估做出贡献。服务财务管理 提供工具和策略来计算新功能可能达到的ROI。服务级别管理 提供有关当前服务级别以及新功能可能带来变更的信息。软件开发和管理 提供有关设计和开发新服务的软件组件的补充评估以及对运行的应用程序活动影响的补充评估。根据需要为业务案例评估做出贡献。
步骤3设计和架构师新服务以满足客户需求 注意此示例假定管理团队已授权研发新功能所需的投资。在决定修改现有服务后有必要审查并修改设计以适应新功能。例如
将帐户审查系统与支付系统集成增加业务、服务和技术的容量
在此阶段还需要将请求的功能和更新的服务设计转换到软件和基础架构设计规范。根据软件和基础架构组件的开发方法这可能会创建关于重要事情和用户故事的初始待办项。
通常对此步骤有贡献的实践包括
架构管理 提供架构要求和约束。可用性管理 提供了用以描述服务潜在需求以及为满足该需求所需的技术、服务和业务能力所需的技能、工具和其他资源并将这些需求记录在服务设计包中。业务分析 提供协调工作所需的技能、工具和其他资源并确保输出被一致地记录在服务设计包中。容量和性能管理 提供所需的技能工具和其他资源用以描述服务潜在需求以及在满足预期性能水平所需的技术、服务和业务容量并将这些内容记录在服务设计包中。信息安全管理 提供设计管控所需的技能、工具和其他资源这些管控不仅可以确保信息的机密性、完整性和可用性而且还可以确保对客户/用户的身份验证和不可抵赖性与组织的策略保持一致并将这些管控内容记录在服务设计包中。基础设施和平台管理 提供创建和完善基础架构组件高阶设计所需的技能、工具和其他资源以满足服务设计包中规定的功用和功效的标准要求。项目管理 提供所需的技能、工具和其他资源以确保项目启动、并具备足够的资源按照既定计划完成任务实现目标。服务配置管理 提供有关当前运行的服务和配置项的信息。服务连续性管理 提供设计管控所需的技能、工具和其他资源这些管控将确保在发生灾难的情况下可将新服务的可用性和性能都维持在可接受的水平并将这些内容记录在服务设计包中 。服务设计 提供所需的技能、工具和其他资源确保在设计新服务时考虑客户体验和用户体验并将这些内容作为基准记录在服务设计包中。服务级别管理 提供所需的技能、工具和其他资源以根据清晰的业务目标设置服务级别并将这些内容记录在服务设计包中。软件开发和管理 提供所需的技能、工具和其他资源以根据服务设计包中的规范创建和提炼重要事情和用户故事列表。供应商管理 协助与合作伙伴和供应商进行互动并选择新供应商采购服务组件。
步骤4构建、配置或购买服务组件 将设计包作为基准之后就可以开始获取或构建服务组件的工作。服务组件通常是技术性的例如软件、服务器、存储或网络。但是根据服务的性质可能还需要管理一些非技术服务组件例如新的团队结构、新的角色、关键的技能和胜任力、知识资料、培训文档和供应商合同。
因此至关重要的是从产品和服务的技术和非技术两方面进行确认和配置其中可能包括
应用之间的技术集成修改现有的后端和客户端应用程序处理能力和基础设施的扩容客户代理机构的培训文档的更新和沟通以及帮助客户提供简单的脚本文档推广新服务的发布说明文档的更新和交流即将实现的产品和服务的变更的市场营销而无需承诺特定功能更新服务设计包并在服务组件的获取或构建时实现议定的变更。
通常对此步骤有贡献的实践包括
基础设施和平台管理 提供所需的工程技能、工具和其他资源确保更新基础架构并将新系统和其他基础架构组件集成到现有服务中。组合管理 提供所需的技能、工具和其他资源在创建服务组件时与服务组合保持更新和沟通。项目管理 提供活动、问题和风险跟踪的跨团队协调以及定期将状态更新到项目委员会。发布管理 提供所需的技能工具和其他资源创建和沟通发布计划并随着开发和部署活动而进行更新和维护。风险管理 提供有关新的或修改的服务组件需要遵守的风险和策略信息。服务配置管理 提供有关当前运行的服务和配置项的信息以及在创建服务组件、更新服务配置项记录时所需的技能、工具和其他资源。服务验证和测试 提供所需的技术技能、工具和其他资源用以记录测试用例、执行自动和手动测试以及提供测试活动的反馈和报告。软件开发和管理 提供所需的工程技能工具和其他资源用以创建新应用程序功能并将新系统和其他软件组件集成到现有服务。供应商管理 协助与合作伙伴和供应商进行互动并选择新的供应商来采购服务组件。
步骤5部署服务组件以准备启动 服务组件完成构建后便可以开始修改实时产品和服务的工作。鉴于服务组件的复杂性组织可能需要使用不同的方法来修改实时产品和服务例如
软件组件经由CI / CD 流水线即时打上特性标志并部署到生产环境中该标志可防止用户意外访问新功能或有更改的功能。服务器存储或网络配置等基础结构组件需在上线之前完成开发和部署。在获取/构建的同时编制内部文档并且在发布之前完成分发。综合考虑稳定的软件功能以及发布计划来编制营销文档。
在这个阶段还可以考虑两项更重要的工作
规划服务发布 完成大多数开发和配置工作后就可以给发布计划定版。根据背景和需求将另一个以发布计划为输出的步骤例如回到“计划价值链”活动添加到价值流中可能更有效率。创建客户宣传品 包括传单电子邮件海报广告等以构建新功能的认知并宣传其优势。
通常有助于此步骤的做法包括
变更支持 提供了提交评估和批准变更请求以及安排对各种服务组件的变更所需的技能工具和其他资源。部署管理 提供将各种服务组件技术和非技术部署到实际环境中所需的技能工具和其他资源。事件管理 同意提供前期支持ELS的期限服务渠道和方法。知识管理 提供更新支持用脚本所需的技能工具和其他资源。问题管理 记录新特性中存在的所有已知缺陷技术债务及解决方法。项目管理 提供在活动、问题、 风险跟踪以及给项目委员会的定期状态更新等方面的跨团队协作机制。发布管理 提供了发布上线计划定版所需的技能工具和其他资源并与组织中的其他组例如销售和营销部门合作将这些计划传达给用户和客户。服务配置管理 提供有关当前运行的服务和配置项的信息以及在构建服务组件时更新服务配置记录所需的技能工具和其他资源。服务台 确保在新特性已知缺陷和解决方法方面对所有面向客户的支持角色进行了充分的培训。供应商管理 在与合作伙伴及供应商的交互以及选择提供服务组件的新供应商方面提供帮助。
步骤6为客户和用户提供发布新服务 部署完所有服务组件后组织即可将其提供给最终用户使用。本步骤实现在上一步中规划的发布。
服务组件的发布可能不仅限于技术过程。可能有必要细致协调技术与非技术工作例如销售及市场营销。本步骤中服务组件成为日常业务的一部分之前会有一小段时间在ELS的支持下运转。ELS可以采用多种形式并取决于组织及其客户的需求可能的形式例如
专门的ELS团队 这些团队来自整个价值流。团队专注于服务设计包中定义的关键指标通常具有跳过正常的事件管理和变更管理实践以快速部署修复程序的自治权。该团队还与组织中的产品负责人紧密合作以将优先任务添加到各个团队的待办事项列表中。超级用户 超级用户通常来自客户和用户社区活跃在社区论坛社交媒体或其他渠道上是产品推进者和拥护者。推进者接受了对新产品或更新产品的高水平培训及综述以使他们能够为其他团队或用户提供支持例如业务用户或一线/服务台。驻场面对面支持人员 ELS也可以由IT人员在客户所在地或现场实施。通常称此类工作人员为内勤人员。
通常有助于此步骤的做法包括
事件管理 提供ELS所需的技能工具和资源以更新支持脚本和知识文章并实现从ELS阶段到日常业务支持阶段的过渡。基础设施和平台管理 提供IT运营资源来运行相关的基础设施组件。问题管理 记录新服务中存在的所有已知缺陷技术债务和解决方法。项目管理 提供活动问题和风险跟踪的跨团队协调并为项目委员会提供定期状态更新报告。关系管理 提供了在客户和用户联系组织提出问题、需求或信息请求时管理他们的期望所需要的技能信息和其他资源。发布管理 提供执行发布上线计划所需的技能工具和其他资源以确保成功完成发布。服务配置管理 提供有关当前运行的服务和配置项的信息。服务台 提供在发布新服务时捕获客户和用户需要例如问题、需求或信息请求所需的技能工具和资源。软件开发和管理 提供IT应用程序管理资源来运行相关软件组件。供应商管理 为与合作伙伴和供应商的互动以及选择新的供应商来采购服务组件等事宜提供协助。
服务组件发布后客户和用户可以通过服务关系与他们进行互动从而产生所需的结果并共同创造价值
发布组件后可以扩展此值流以包括其他活动例如
与请求者互动以识别新服务中的任何差距或价值流活动中未发现的任何结果成本和风险。找出改进服务、价值流以及积累实践的机会。
4.2.2 恢复现有服务
此价值流模型检查组织为支持现有服务而进行的典型活动。此场景与服务的性质无关可用于描述各类为组织内外部消费者提供支持服务的价值流。
4.2.2.1 设计考虑因素
设计此值流时典型的注意事项包括
识别利益干系人以及价值的创造或恢复对他们意味着什么例如 对于用户而言这意味着可以恢复使用产品和服务的能力对于组织的合规性人员而言这可能意味着维护问题内容以及为恢复价值而采取的步骤的正确记录对于服务所有者这可能意味着要对活动进行足够的文档化以支撑趋势报告问题调查和改进点机会识别。采用由内而外的方法来了解事件的影响并将这些评估与各种利益干系人的价值描述联系起来。首先定义价值流的范围然后定义一个涵盖范围内所有活动的单体价值流以建立关于如何支持创建或恢复价值的端到端的、整体的构想。强调合作伙伴和供应商执行的活动这些活动可能会给成功创造或恢复价值引入风险或依赖关系。了解应集成哪些或如何集成系统并在多个活动中心之间共享数据。
4.2.2.2 需求和价值
此价值流由无法使用现有产品或服务的用户触发。8由于服务消费者无法从次优产品或服务中获取最大价值生产力的损失导致产出价值下降。
当监视工具发出预警提醒组织出现了或对用户产生影响的故障时需求也可能源自服务提供者。在这种情况下价值流可能会绕过步骤1或交换步骤1和2的顺序。换句话说如果需要服务提供者可以
无须用户提醒直接解决问题尽早与用户联系以通知他们正在发生的事件事件解决后与用户联系。恢复价值的需求推动了这一价值流。
4.2.2.3 从需求到价值的旅程
此价值流描述了七个关键步骤如图4.6所示 图4.6实时服务的还原
确认并登记用户查询参与调查查询将其重新分类为事件然后尝试修复它交付和支持从专家团队处获取修复程序获取/构建部署修复程序设计和过渡验证事件是否已解决交付和支持征集用户反馈参与识别整体系统改进机会改进
该价值流在步骤2分支。如果成功解决此问题的初始尝试成功那么价值就在无须后续活动的情况下恢复了。从步骤2到价值的虚线代表这种情况。
在步骤5之后价值得到恢复价值流就可以结束了还可以进一步开展如步骤6和7所述的活动请求并处理客户反馈。例如组织通常要求从随机的客户样本中获取反馈。
步骤1确认并登记用户查询 价值流中的第一步是与客户或用户进行互动以识别和确认需求并记录有关查询的详细信息。在此阶段用户联系只是查询9因为尚未对其进行分类并识别为事件。
通常有助于此步骤的做法包括
服务目录管理 提供优化登记查询所需的信息技能工具和其他资源。服务台 提供所需的技能工具和其他资源以允许客户或用户联系服务支持并使客户支持专员能够与联系人产生共情管理与客户或用户的沟通方式获取及传递有关预期解决时间的信息
步骤2调查查询将其重新分类为事件然后尝试将其修复 记录查询时训练有素的支持专员或等效自动化程序例如聊天机器人可以将查询识别为事件并将其重新分类从而启动脚本或标准过程以对记录进行相应分类。由于组织的过程和工具的不同也可能会创建一个链接到初始查询的新事件记录
登记用户发起的事件后通常会尝试快速识别其性质并应用已知的解决方案。
支持专员通常遵循允许他们尝试一个或多个修复程序的活动的脚本或工作流。如果这些修复程序之一将服务恢复到正常状态则价值恢复价值流就可以结束。如果所有这些修复程序均不起作用则可以将问题上报至专家角色以开展进一步调查。
通常有助于此步骤的做法包括
事件管理 提供了登记事件所需的技能工具和其他资源以及有关可能需要多长时间解决的信息。知识管理 提供查找技术信息和权变措施所需的技能工具和其他资源这些信息可以帮助调查诊断和解决事件。监控和事态管理 提供对监视工具和日志的访问以帮助调查和诊断事件。服务配置管理 通过提供相关配置项的信息来协助事件的调查和诊断。服务台 提供使支持专员能够与客户或用户产生共情并管理与客户或用户的沟通渠道所需的技能工具和其他资源。服务级别管理 提供可用于评估事件影响和规划服务恢复的信息。
调查和诊断通常是一项高度技术性的活动。但是还应注意非技术因素例如环境或经济因素以下是可能的示例
网络中断的原因是风暴影响了本地电缆或卫星连接。流媒体服务中止服务的原因是客户或用户的信用卡被银行拒付。
步骤3从专家团队处获取修复程序 在此步骤中由于最初尝试恢复服务失败因此该事件将上报专家团队或要求参考专家团队意见。在不同的情况下专家团队的介入可能会以不同方式发生其中一些方式可能涉及控制权的移交。例如
支持专员可以在供应商网站上查找补丁。但是事件的控制权不会因此移交给供应商。支持专员向供应商发起事件。对用户事件的控制权并不移交而是创建由供应商管理的并行事件工单。支持专员将事件上报给内部工程团队。事件的控制权将随之移交给工程团队。支持专员要求外包的工程团队提供修复程序。这可能会或可能不会涉及将事件的控制权交给工程团队。
该修复程序也可以是容易获得的东西例如公开可用的补丁或升级。在某些情况下修复程序可能要操作物理设备例如更换有故障的硬盘驱动器。通常在处理自定义应用程序或硬件时必须先构建修复程序然后才能进行部署。
通常有助于此步骤的做法包括
事件管理 提供了更新事件记录所需的技能工具和其他资源其中包含构建和测试此修复程序所必需的活动的详细信息。基础设施和平台管理 根据事件的性质提供构建或配置故障基础设施或平台的修复程序所需的技能工具和其他资源。知识管理 提供所需的技能工具和其他资源以查找可以帮助调查和诊断事件的技术信息并使用有关修复的信息更新现有的知识记录。服务配置管理 提供创建修复程序时更新服务配置记录所需的技能工具和其他资源。服务台 提供使支持专员能够与客户或用户产生共情并管理与客户或用户的沟通渠道所需的技能工具和其他资源。服务财务管理 根据修复程序的性质可能需要为解决事件所需的资源或服务组件向合作伙伴或供应商付款。服务验证和测试 提供技能工具和其他资源以测试修复程序并确认它可以解决此事件且符合所有相关的政策和标准。软件开发和管理 根据事件的性质提供构建或配置故障软件的修复程序所需的技能工具和其他资源。供应商管理 根据事件的性质提供同协助构建修复程序的关键供应商进行交互所需的技能工具和其他资源。
步骤4部署修复程序 获得了修复程序并通过测试及验证后可以将其部署到用户或生产环境。部署可以采用多种形式。例如
使用CI / CD 流水线在整个生产环境中分发修复程序将硬件组件例如新硬盘交付给数据中心随后在该中心进行配置将硬件组件例如新笔记本电脑交付给最终用户办公室由本地IT支持人员进行配置远程登录用户的PC以从网络驱动器安装补丁。
通常有助于此步骤的做法包括
部署管理 提供将修复程序部署到用户或生产环境所需的技能工具和其他资源。事件管理 提供了更新事件记录所需的技能工具和其他资源以及部署修复程序所需活动的详细信息。基础设施和平台管理 根据事件的性质提供配置和打包要部署的修复程序所需的技能工具和其他资源。知识管理 提供了使用有关修复程序的信息更新现有知识记录所需的技能工具和其他资源。服务配置管理 提供了在部署修复程序时更新服务配置记录所需的技能工具和其他资源。服务台 提供使支持代理能够使用共情并管理与客户或用户的沟通渠道所需的技能工具和其他资源。服务财务管理 根据部署的性质可能需要向合作伙伴或供应商付款。软件开发和管理 根据修复程序的性质提供配置和打包用于部署的修复程序所需的技能工具和其他资源。供应商管理 根据事件的性质提供与能够协助配置和打包待部署的修复程序的关键供应商进行交互所需的技能工具和其他资源。
步骤5验证事件是否已解决 部署修复程序后下一步是验证事件是否已解决。此步骤与价值流中先前的步骤1和2十分相似因为它涉及支持专员与用户开展沟通和共情。
如ITIL Foundation中所述价值是对事物的利益有用性或重要性的感知。在此模型中用户和组织对价值的感知是不同的。例如
用户可能将一系列现象视为价值流失包括恢复服务所花费的时间相关的生产力损失生产力损失造成的挫败感等待服务恢复时可能出现的任何其他问题或复杂情况 IT支持期间的服务体验和服务的可靠性等。而有效地消除价值流失被认为是有价值的。IT支持专员可能依据与用户及专家团队合作的经验与各个小组进行交互所花费的时间以及更新相关记录等来计算价值。专家团队可能会依据与IT支持专员或用户合作的经验创建和部署修复程序以及更新相关记录的复杂性来计算价值。
而且即使事件在技术层面上解决了用户也可能需要其他帮助。例如
有人告知服务已恢复重新赋予服务的访问权和使用权解决由于该事件引起的任何未决或额外问题。
因此建议您与用户进行核对以确保价值值已经令人满意地恢复了。这有助于增加IT支持与用户之间的共情增进双方长期信任。
当受影响的产品或服务以最佳水平运行时可以认为该事件已解决。换句话说价值流失已得到纠正。
为了区分事件的解决和结束许多IT支持工具通过以下方式将状态分配给事件记录
解决事件意味着已解决了潜在的技术问题。结束事件意味着修复程序和相关的价值恢复已经得到用户确认。解决或关闭事件的过程是事件管理实践的基础设计的一部分随后被价值流引用。在本节中通常是指解决事件。
通常有助于此步骤的做法包括
事件管理 提供根据用户交互详情更新解决或关闭事件记录所需的技能工具和其他资源。知识管理 提供根据修复程序和价值恢复相关信息来更新现有知识记录所需的技能工具和其他资源。服务配置管理 提供解决事件后更新服务配置记录所需的技能工具和其他资源。其概述可用于填写表4.2中提供的价值流步骤模板。服务台 提供使支持专员能够产生共情并管理与客户或用户的沟通渠道所需的技能工具和其他资源。服务级别管理 提供信息以评估恢复/已达到的服务水平以及恢复的及时性。
步骤6征集用户反馈 解决事件后许多组织征求用户反馈以便确定服务、与用户通信的方式、解决事件的过程或关键做法等的改进机会。通常将其与价值流中涉及的其他角色例如IT支持专员和技术专家的反馈相补充会很有用。
无论是提供反馈还是收集反馈重要的是要通过探索如何做得更好来保持积极的态度而不是专注于出了问题的地方。在讨论事件的历史及其影响时通常很难区分情绪和自我。可能还需要识别并过滤掉可能会影响反馈的环境个人或专业因素例如
担心生病的孩子的父母在分享反馈意见时可能会过分消极。担心即将裁员的IT支持专员可能不会专注于日常工作。刚刚大赚一笔的业务开发经理可能更友善并且对IT支持问题较为宽容。
用户与IT支持人员之间越来越多的共情和信任可以帮助改进进行沟通并减少偏差的影响。反馈可以通过多种方式收集但最终应存储在集中的位置以帮助分析和管理报告。
通常有助于此步骤的做法包括
持续改进 提供收集用户反馈所需的技能工具和其他资源。基础设施和平台管理 根据事件的性质和解决事件所需的步骤提供可用于识别改进机会的相关反馈所需的技能工具和其他资源。服务台 提供使支持专员能够产生共情并管理与各利益干系人的沟通渠道所需的技能工具和其他资源。软件开发和管理 根据事件的性质和解决该事件所需的步骤提供可用于识别改进机会的相关反馈所需的技能工具和其他资源。供应商管理 根据事件的性质和解决事件所需的步骤提供可用于识别改进机会的相关反馈所需的技能工具和其他资源。
步骤7:识别整体系统改进机会 收集到所有相关利益干系人的反馈后可以将其单独或与其他信息进行分析例如有关服务服务提供者服务消费者组织外部约束等的历史数据。可以依此识别整体系统的改进机会。例如
服务提供者组织或更一般而言是SVS及其组件价值流以及相关的步骤动作和任务与用户合作伙伴供应商和其他利益干系人的关系定义与感知价值的方式。
识别的任何改进都应记录在服务提供商的持续改进登记册中从而为服务提供商组织和提供者的SVS都能创造价值。写入登记册后改进机会将优先于SVS中的其他工作。
通常有助于此步骤的做法包括
持续改进 提供识别改进SVS及其组件的机会所需的技能工具和其他资源识别改进收集和分析反馈方式的机会识别改进服务的方式并将其记录在持续改进登记册中。部署管理 提供所需的技能工具和其他资源以识别改进实践的机会并将其记录在持续改进登记册中。事件管理 提供所需的技能工具和其他资源以识别改进实践的机会并将其记录在持续改进登记册中。基础设施和平台管理 提供所需的技能工具和其他资源以识别改进实践的机会并将其记录在持续改进登记册中。知识管理 提供所需的技能工具和其他资源以识别改进实践的机会并将其记录在持续改进登记册中。监控和事态管理 提供所需的技能工具和其他资源以识别改进实践的机会并将其记录在持续改进登记册中。问题管理 提供技能工具和其他资源以调查并减轻事件的可能原因。风险管理 提供技能工具和其他资源以管理由于事件或修复而引发的新风险或现有风险的变化。服务配置管理 提供所需的技能工具和其他资源以识别改进实践的机会并将其记录在持续改进登记册中。服务台 提供所需的技能工具和其他资源以识别改进实践的机会并将其记录在持续改进登记册中。服务财务管理 提供所需的技能工具和其他资源以识别改进实践的机会并将其记录在持续改进登记册中。服务验证和测试 提供所需的技能工具和其他资源以识别改进实践的机会并将其记录在持续改进登记册中。服务级别管理 提供登记并评估服务改进提案所需的信息工具和技能。软件开发和管理 提供所需的技能工具和其他资源以识别改进实践的机会并将其记录在持续改进登记册中。供应商管理 提供所需的技能工具和其他资源以识别改进实践的机会并将其记录在持续改进登记册中。
ITIL 故事: 用于创建、交付和支持的模型价值流
雷尼:有多种识别创建和记录价值流的技术
索尔马兹: 最初我们使用物理看板板通过便签纸记录了我们的价值流。随着试点工作的进展和增长我们创建了一个电子看板以便我们可以在两个项目地点之间共享它并调整我们的价值流。
雷尼: 由于这是一项新提案因此我们的价值流包含许多未知数。我们决定采用最小可行产品方法使我们能够增量地开展服务适配在自行车租赁过程的每个阶段测试客户的需求了解如何根据指标衡量绩效并评估结果
弗朗西斯:在说明价值流时我们结合了来自试点客户的反馈并利用了艾克苏服务组合中的现有价值流。在创建用于实现新功能的价值流时我们使用了ITIL模板。我们将不断调整我们的价值流使它们与客户不断变化的需求保持一致
雷尼:在可视化价值流之后我们能够识别我们需要投入新服务的额外资源。例如我们发现迫切需要能够快速轻松地取回废弃或损坏的自行车以帮助服务顺利运行。
4.3 使用价值流来定义最小可行实践
前文描述的价值流设计和文档编制技术有助于服务提供商了解工作性质和从需求到价值的流动以及组织资源和实践为实现这种流动所做的贡献。
同样的技术也可以用于定义从对组织或利益干系人并允许学习和持续改进的实践中所需的最小贡献集。
例如如果假定第4.2节中讨论的两个价值流模型是服务提供者组织中的唯一价值流则可以使用表4.4的模板合并实践贡献。
表格 4.4 最小可行实践贡献
实践名称贡献目的价值流步骤
因此例如服务配置管理可以根据需要合并贡献如表4.5所示。
表格 4.5 服务配置管理的最小可行实践贡献示例
服务配置管理实践贡献目的进入价值流1或2*提供有关当前操作服务和配置项的信息以及在构建服务组件时更新服务配置记录的技能、工具和其他资源构建配置或购买服务组件价值流1中的步骤4提供有关当前运行的服务和相关配置项的信息决定是否投资新服务价值流1中的步骤2提供有关当前运行的服务和配置项的信息以及在构建服务组件时更新服务配置记录的技能工具和其他资源部署服务组件以准备启动价值流1中的步骤5提供技能工具和其他资源以在部署修复程序时更新服务配置记录部署修复程序值流2中的步骤4提供有关当前运行的服务和相关配置项的信息设计和架构师提供新服务以满足客户需求价值流1中的步骤3提供识别改进实践机会并将其记录在持续改进登记册中所需的技能工具和其他资源识别整体系统改进机会价值流2中的步骤7通过提供有关配置项的信息来协助调查和诊断事件调查查询将其重新分类为事件然后尝试将其修复值流2中的步骤2提供有关当前运行的服务和相关配置项的信息了解并记录服务要求提供有关当前实时服务和服务组件的信息以在描述需求时提供背景确认并记录服务需求价值流1中的步骤1提供解决事件后更新服务配置记录的技能工具和其他资源验证事件是否已解决值流2中的步骤5
* 价值流1开发新服务在第4.2.1节中价值流2恢复现有服务在第4.2.2节中
因此如果在特定功能或技能集的缺失方面面临挑战那么符合逻辑的响应是调查哪个价值流步骤需要哪些贡献可能走向如下两种后续之一
放弃构建功能或技能集的要求记录新的价值流或修改现有的价值流以确认对新功能的需求。
在上面的示例中如果高级经理质疑服务配置管理实践所有者为何不支持对IT领域进行定期审核以识别未记录的配置项则可能导致以下结果之一
相互同意不需要该功能。标识新的或迄今未记录的价值流其中定期审核配置项。
采用最小可行实践方法将帮助组织避免对组织不需要的技能工具流程和其他资源进行投资。有助于
降低业务的总拥有成本TCO增加服务配置管理的投资回报。
ITIL 故事: 使用价值流来定义最小可行方法
雷尼: 定义34种ITIL做法所需的最小贡献集将很有用它将对组织或利益干系人有利。例如我们当前的支持服务旨在提供路边援助但是这并不延伸到我们的客户可能希望探索的山间小道。对于最初的城市自行车车队我们可以采用当前的做法但是如果我们将服务组合扩展到包括山地车租赁在内那么我们还需要扩展支持能力。
4.4 总结
价值流是服务价值链中的一段旅程的阐述方式表达了工作如何在组织中创建增强或支持与服务消费者共同创造价值的产品和服务时如何在组织中流动。价值流和流程是服务管理的维度之一描述了从需求共同创造价值所需的步骤动作和任务。
价值流与其上下文环境紧密关联体现了组织的控制范围和影响以及场景或需求类型。价值流的粒度代表沟通工作流的需要。价值流可以是线性流动的或迭代循环的。模式的选择体现工作应该如何流动的愿望也可以体现工作如何在整个组织中流动。
在某些情况下价值流也可以跨多个组织级联。例如跨组织价值流中的一个步骤可能是其中一个参与组织的整个价值流。
在价值流、步骤、行动或任务中组织可以识别组织的实践需要提供的贡献人员、工具、信息、过程等。这些信息可用于优化服务价值体系及其组件。
