ITIL 4—Create, Deliver, and Support—Create, deliver, and support the value stream of services

4. Value streams that create, deliver and support services

This chapter provides information on how to:

• Document a value stream to understand how workflow flows through the organization
• Understand the prototype value stream for creating a new service
• Understand the prototype value stream supporting a field service

This chapter will help practitioners understand:

• The role of value stream in Service Value System (SVS)
• Classification of value streams
• How to describe the steps in a value stream
• How to apply common mathematical modeling theory to simplify value streams
• Things to consider when designing a value stream

Practitioners must understand that value streams are simple and easy to do, but not necessarily simplified work presentations. Different kinds of work follow different routes, and therefore there are many different value streams. They can refer to either designed or ideal patterns of activity, or they can express actual, observable patterns of activity. The same resources, such as individuals, tools, vendors, or processes, can be present in different parts of the value stream; for example, an operations specialist can be part of user engagement, support investigations, and deploy fixes for recovery services. .

4.1 ITIL service value stream

The ITIL value chain includes six prototyping activities: participation, planning, improvement, design and handover, engagement, and delivery and support. A useful way to think about a value stream is to visualize the journey through the activities in a service's value chain for a specific scenario or need type. For example:

• Different types of events may require different value streams to describe the work required in each case, for example:
  • End user hardware events
  • main event
  • Cyber ​​security incident. 
• Different types of customer needs may require different value streams, such as:
  • The need for a new product or service feature that increases the efficiency of business operations
  • A request for a team member to access a product or service
  • A request for new infrastructure capabilities to preserve the normal operation of a product or service.

4.1.1 Structure of ITIL Service Value Stream

Definition: ITIL Service Value Chain An operating model for service providers that covers all the key activities required to effectively manage products and services.

The ITIL service value chain consists of 6 prototype value chain activities. These series of activities are called: ITIL service value stream, or more simply: value stream. A value chain can:

• Mention one, some or all value chain activities, depending on the content
• Duplicate value chain activities, dependent on work in progress

A value stream consists of one or more steps, and each step consists of one or more activities to achieve a specific goal. These activities can be serial or parallel, and they can be connected to other activities or independent of each other. An activity itself can contain one or more tasks, which can also be connected or independent.

Definition: value stream The series of steps an organization takes to create and deliver products and services to consumers

With a value stream model, service organizations can organize units of work into processes, which may vary depending on context and level of granularity. For example, in a value stream where consumers spontaneously create service requests:

• At the value stream level, this unit of work can be defined as a customer need to be satisfied, which may change the flow of activities in the service portfolio within the value stream.
• At the step level, definable units of work need to be estimated as requirements, which may change the design of role definitions in the service design package during value stream implementation.

Figure 4.1 shows the relationship between value chain activities, value streams, steps within the value stream, activities within steps, and tasks within activities.

Value streams are initiated by requirements; for example:

• Events generated by monitoring tools
• User-submitted requests.

Figure 4.1 Value stream activity hierarchy

A value stream ends by creating or restoring value to a functional product or service. The value stream requires the following content information:

• Input from one or more stakeholders (external organizations that perform steps or actions), such as server names or GPS data sent via the user’s mobile device;
• Other value streams​, for example: One value stream needs to use ID information or other information for onboarding new employees, which comes from the value stream that hires (or signs) the new employee.

Value streams use the resources of service providers, service consumers to generate required outputs, and work within management systems, governance systems, external factors, constraints and principles.

The value stream will produce outputs that are used to create the desired results. This output can include information and feedback shared with stakeholders and assist in the execution of management activities or governance activities. In some cases, these outputs can also serve as triggers for other value streams within or outside the organization.

4.1.2 Value stream and organization

ITIL 4 does not equate organizations with corporate entities. An organization can be a person (such as a self-employed programmer or consultant), a team (such as a development or support team as a business unit), a business, or even an ecosystem of businesses working together.

Value streams are fundamentally about organizations. Therefore, value streams may exist at each level of granularity, and they may be a single person, a team, a business unit, etc. However, it is important to remember that the value stream is defined by the context of the system being built, and its purpose is to create value for the organization, its customers and other stakeholders. A large enterprise can include several different organizations that have a certain degree of autonomy in management, and each of them can be regarded as a Service Value System (SVS) value chain and value stream with its own value. However, it is unlikely to be self-sufficient. A Service Value System (SVS) needs to be established at the team level.

The overall goals and expectations of a product or service should be described from start to finish; that is, from need to value, rather than simply describing each team's use in a different or uncoordinated set of activities. Therefore, value streams will represent the work of different teams, impact different stakeholders, use different processes, tools and people, and sometimes even different suppliers.

The ITIL service value stream needs to be visualized and clearly indicate the touch points where users interact with products, services or IT service management professionals. A key advantage of ITIL value stream techniques is the ability to not only identify the involvement of multiple stakeholders, but also see potential points of failure and clearly link value to requirements.

Key Information The main difference between value streams and processes is their focus and how they are used. Interrelated activities that transform many inputs into outputs can be thought of as processes. Value stream focuses on the flow of activities from a need or opportunity to the realization of customer value. Process taxonomies, process management tools or techniques can be used for value streams. Therefore, many processes are not value streams.

Each step in the value stream can be redefined as a process, or a value stream. The latter is typical for large enterprises and ecosystems involving multiple businesses.

Example Passengers traveling by train may interact with multiple service providers, depending on the country and route chosen. Some of these service providers are railroad companies that transport people. Other service providers include station management, ticketing, security, dispatching and train navigation. Rail travel is a complex ecosystem with many organizations collaborating and collaborating to create a seamless and comfortable user journey. Each organization needs to manage its own SVS, which contains multiple value streams. At the same time, these organizations contribute to value stream collaboration that enables and supports rail travel. Certain steps of the value stream are actually realized by participating organizations' value streams.

High-level value streams for adding new functionality to IT services may involve third-party vendors, internal software development teams, site reliability engineering teams, other IT teams, and user teams. Steps performed by an external supplier are likely to be managed as the supplier's own value stream. The steps performed within an organization are formalized as process management of the actions or activities involved in these processes.

Cascading a value stream to lower-level value streams or processes allows organizations to:

• Focus on the value of higher-level value streams, integrating the value streams and processes of participating parties
• Improve iteratively, relying on feedback from other organizations or teams in the value stream 
• Collaborate and increase visibility into workflows across organizations and teams
• Think and work holistically by understanding how the wider organization or ecosystem operates and benefits and what the parties involved do.

4.1.3 Value stream considerations

4.1.3.1 Choose the right perspective

Value streams can be documented from one of two perspectives. On the one hand it can be designed to reflect the wishes of the service provider, on the other hand it records the performance of the work for research. When documented, the design can be compared with the observed behavior.

Differences between design and observed behavior may trigger improvements. These may include:

• Update value stream documentation to reflect actual work patterns
• Optimize workflows by reducing changeover time Turn demand into value and automate repeatable work.

4.1.3.2 Starting point and ending point

A value stream always starts with a requirement and ends with the creation or realization of value for one or more stakeholders. Therefore, it is advisable to maintain an outside-in voice when documenting value streams, for example, by:

• Milestones and timelines that reflect the business plan
• Ability to use language that is relevant to the audience
• Build outcomes and value from the customer or user's perspective.

4.1.3.3 Flexibility

Value streams reuse activities in the value chain depending on the context and environment in which the work is performed. Value streams can be flexibly customized according to the needs of the organization. For example: Organizations can add a stage during the work, similar to a waterfall approach, or create iterative loops between value chain activities.

4.1.3.4 Granularity

Value stream can reflect the granularity of work to a certain extent. For example, a value stream using agile software activities can exhibit multiple iterations of work, reflecting the exploratory nature of the approach. Alternatively, a value stream can embody a higher-level perspective that allows work to be represented as a step. Regardless of how the work is represented, it is critical that granularity remains consistent throughout the value stream.

4.1.3.5 Identification steps

Which steps should be used for the value stream, what activities should these steps include, and the following points should be considered when making decisions:

• Level of detail of the value stream. Organizations need to decide whether details of all operations should be displayed, or just an overview of the work.
• The impact of handoffs between individuals or teams on the value stream. It is often best to show activities performed by different teams as separate steps. This helps understand which jobs in the queue are experiencing delays.
• Multiple activities in a value chain that have an impact on the value stream.

Includes multiple value chain activities

If a step includes both action and planning activities, it makes more sense to break it into two separate steps. For example: the step "Determine customer needs" can be divided into:

• Define requirements with customers (contributions from practices such as service desk and relationship management can be used to map to enabling activities in the value chain)
• Assess customer needs (contributions from practices such as business analysis, risk management, etc. can be used, mapped to planned activities in the value chain).

Likewise, the step "Implement the patch via vendor website" can be divided into:

• Download the patch from the website (can use content from practices such as software development and management, supplier management, etc., mapped to acquire/build activities in the value chain)
• Deploy this patch (contributions from practices such as change management, deployment management, etc. can be used, mapped to design and transformation activities in the value chain).

If multiple steps are performed by the same group of people or the same set of resources, it is best to describe them as separate steps in the value chain activities so that the output of the combined steps can best be described. This also helps avoid the impact of waiting in queues between each step on your work.

4.1.3.6 Sequence of steps

Although a value stream typically begins with an engagement, other activities can also serve as first steps. For example, if an engineer discovers an incident through a monitoring tool (requirement), the first step activity may be to initiate an investigation (delivery and support), in which case it is unlikely to contact the affected customer directly (action).

4.1.3.7 Mapping to service value chain

The steps of the value stream can be described by mapping to the activities of the value chain. In fact, the activities of the value chain are also described by mapping basic activities or tasks. For example:

• The step of assessing customer needs can be mapped to the planning activity in the value chain, but it can also be mapped to an activity or task in the value chain called "refining requirements with the customer" that is the driving activity in the value chain.
• The step of downloading a patch from the supplier's website can be mapped to the Get/Build activity in the value chain, but there is also an activity or task called "Update Workaround" that can be mapped to the Improvement activity in the value chain.

4.1.3.8 Mapping to practice

Depending on the level of granularity, steps, activities, or tasks in a value stream can be mapped to processes or procedures in practice. For example, the steps of developing and deploying code can be mapped to the following activities and tasks:

• Program to perform automated testing
• The process of performing manual testing

4.1.4 Design service value stream

Practitioners are encouraged to use the following methods or try other methods to ensure that organizational needs are met.

1. Define the use cases or scenarios of the value stream through the following:

• Requirements (preferably in non-technical terms)
• Triggers that create demand
• Value stream creates results
• Value in the context of a value stream (because value can be created or restored).

2. Record the required steps in the entire service value chain from demand to value.

3. Start mapping to the service value chain from step 2.

4. If necessary, break the steps into activities or tasks.

5. Identify relevant practices or related resources to facilitate the successful completion of each step, activity, or task, including:

• Operations or management team or individual
• Tools and techniques
• Information and data (e.g. records, forms)
• Any partner or supplier who can achieve outputs or results through their own resources.

The above five steps should be completed in a collaborative manner: for example, a series of meetings or workshops could be organized. The first task of preparing documentation is to establish a broad and basic understanding and form a baseline in order to respond to needs and create value in a targeted manner.

Once you have established a baseline, you can further experiment or optimize your value stream by:

• Create a simple mock to test your workflow
• Eliminate work that does not contribute meaningful output, results or benefits
• shift left work
• Delaying work that may result in quality, cost, or time deviations
• Introduce feedback mechanisms and upgrade mechanisms to ensure continuous improvement in the output quality and benefits of the value stream
• Identify automation improvement opportunities from steps, activities, or tasks to accelerate workflows
• Identify and manage bottlenecks or constraints, which may require redesigning the value stream around constraints
• Introduce review triggers and improve value streams where necessary. (Reviews can be random, such as during consumer feedback, or on a regular basis.)

4.1.5 Steps in describing the value stream

When describing the steps in the value stream, you need to identify and document the following:

• The step name  defines what the step is. Decide whether you want to use non-technical language to describe the step. Avoid acronyms and jargon so that value stream evaluators can easily understand what their goals are; for example:
  • A better value stream step would be the phrase "Register a user incident" than "Log an incident ticket using INC_template".
  • The phrase "record customer requirements" is a better phrase than "fill out the TK421 form with customer input."
• Enter a trigger.  A trigger causes a step to start.
• Information  describes the information required for the step. Resources should be obtained from external stakeholders or other organizations before performing value stream activities.
• Practice Contributions  The tools, techniques, individuals, and other resources that contribute to the organization's successful completion of the practice steps.
• What activities or tasks  need to be performed clearly based on trigger conditions and output result requirements? Which activities can be parallelized? Which activities require prerequisites? How long does each activity or task take to perform?
• What principles need to be followed to constrain  this step? These principles are defined by service providers or external stakeholders. Most importantly, organizations should explore the resource constraints they may face.
• The reason why the output  step exists. Steps need to achieve outputs and create value for service providers, users, or other stakeholders.
• Estimated or target delivery time  The length of time it should take to complete a step, including: time spent waiting in queues.

The following template can be used as an initial reference for value stream description. The first template (Table 4.1) provides a summary of the value stream, and the second template (Table 4.2) provides a step structure describing the value stream. Practitioners are encouraged to use templates they see fit.

Table 4.1 Service value flow description template

value stream name

everyone

Description of the value stream and its use cases

need

trigger

result

value created

Estimated delivery time or target delivery time

Table 4.2 Value stream step description template

value stream name
step number
step name
value chain activities	Activate, Plan, Improve, Design and Transform, Acquire/Build, Deliver and Support
enter	Triggers and messages
output	Triggers and messages
expected outcome
Delivery time estimate or delivery time target
support practice
Practice name	Describe how practices contribute to this step
Roles and Responsibilities
A responsible
R executed
C consulted
I was told

Note: Practice contributions should be described in a holistic manner, avoiding the use of technical jargon (where feasible).

4.1.6 Value stream mapping

价值流映射起源于精益制造技术。这是一种从需求机会到价值实现的可视化工作流，其工作流可有计划地持续改进。在精益中，核心思想是最大化客户价值，同时将浪费最小化。简而言之，精益涉及以更少的资源为服务消费者创造更多价值。精益组织了解服务对消费者的价值，并将其关键流程集中在增加价值上。

我们的目标是通过不产生任何浪费的完美价值创造过程为服务消费者提供完美价值。为实现这个目标，精益思想通过将横跨技术、资产和部门的水平价值流，将管理的重点从优化单独的技术、资产和垂直部门转变为对消费者的产品和服务的流程进行优化。

价值流映射用于深入了解组织的工作流程，并在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所示）：

1. 确认并记录服务要求（契动）
2. 决定是否投资新服务（计划）
3. 设计和架构新服务以满足客户要求（设计和转换）
4. 构建，配置或购买服务组件（获取/构建）
5. 部署服务组件以准备启动（设计和转换）
6. 为客户和用户发布新服务（交付和支持）。

图 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 故事: 使用价值流来定义最小可行方法

Rainey:  It would be useful to define the minimum set of contributions required for the 34 ITIL practices that would benefit the organization or stakeholders. For example, our current support service is designed to provide roadside assistance; however, this does not extend to mountain trails that our customers may wish to explore. For an initial fleet of city bikes, we can stick with our current approach, but if we expand our service portfolio to include mountain bike rentals, we will also need to expand our support capabilities.

4.4 Summary

A value stream is an articulation of a journey in a service value chain, expressing how work flows through an organization as it creates, enhances or supports products and services that co-create value with service consumers. Value streams and processes are one of the dimensions of service management that describe the steps, actions and tasks required to co-create value from requirements.

A value stream is closely related to its context, reflecting the organization's scope of control and impact, as well as the type of scenario or need. The granularity of the value stream represents the need to communicate the workflow. Value streams can be linear or iterative. The choice of model reflects a desire for how work should flow and can also reflect how work flows throughout the organization.

In some cases, value streams can also be cascaded across multiple organizations. For example, a step in a cross-organizational value stream may be the entire value stream for one of the participating organizations.

Within a value stream, step, action, or task, an organization can identify the contributions (people, tools, information, processes, etc.) that the organization's practices need to provide. This information can be used to optimize the service value system and its components.