CHAPTER 4

VALUE STREAMS TO CREATE, DELIVER, AND SUPPORT SERVICES

 

4 Value streams to create, deliver, and support services

This chapter provides guidance on how to:

• document a value stream to understand how work flows across the organization

• understand an archetype value stream to create a new service

• understand an archetype value stream to support a live service.

This chapter will help practitioners understand:

• the role of a value stream in the SVS

• the taxonomy of a value stream

• how to describe the steps in a value stream

• how to apply common mathematical modelling techniques to streamline a value stream

• considerations when designing a value stream.

It is crucial that practitioners understand that value streams are simple, but not necessarily simplistic, representations of work. There are many different value streams, because various types of work follow different routes. They can either represent a design or ideal pattern of activity or reflect the actual, observable patterns of activity. The same resources, such as individuals, tools, suppliers, or processes, can appear in different parts of the value stream; for example, a support agent can be part of user engagement, support investigation, and the deployment of a fix to restore service.

4.1 ITIL service value streams

The ITIL service value chain includes six archetypal activities: engage, plan, improve, design and transition, obtain/build, and deliver and support. A useful way of thinking about value streams is as visualizations of journeys through the activities in the service value chain for specific scenarios or types of demand. For example:

• Different types of incident may require different value streams to describe the work required in each case, such as:

• end-user hardware incidents

• major incidents

• cybersecurity incidents.

• Different types of consumer demand may require different value streams, such as:

• a need for a new product or service feature to increase the efficiency of business operations

• a request for a team member to access a product or service

• a request for new infrastructure capacity to keep a product or service operating normally.

4.1.1 Structure of an ITIL service value stream

The ITIL service value chain is made up of six archetypal value chain activities. A sequence of these activities is referred to as an ITIL service value stream or, more simply, as a value stream. A value chain can:

• mention one, some, or all value chain activities, depending on the context

• repeat value chain activities, depending on the work in progress.

A value stream consists of one or more steps. A step comprises one or more actions that accomplish a specific objective. These actions may occur sequentially or in parallel, and they may either be connected to other actions or independent of each other. An action itself can comprise one or more tasks, which may also be either connected or independent.

Through the value stream model, the organization processes units of work, which may change depending on the context and the level of granularity. For example, when implementing a value stream to create a new service that is triggered by a consumer request:

• At the value stream level, the unit of work can be defined as the consumer request that needs to be fulfilled, which may change to the service portfolio item that is being created during the flow of activities in the value stream.

• At the step level, the unit of work can be defined as the requirements that need to be assessed, which may change to the design characteristics defined in the service design package during the implementation of the value stream.

Figure 4.1 shows the relationship between value chain activities, the value stream, the steps in a value stream, the actions within a step, and the tasks within an action.

A value stream is initiated by demand; for example:

• an incident generated by a monitoring tool

• a request submitted by a user.

A value stream ends in the creation or restoration of value through functioning products or services. Value streams use information provided by:

• one or more stakeholders (external to the organization performing the step or action) as inputs; for example, a server name or the GPS data sent by a user’s mobile device

• another value stream; for example, a value stream to onboard a new team member may use employee ID and other information created when implementing the value stream to hire (or contract with) the new team member.

Value streams use the resources of the service provider and service consumers to generate required outputs, working within the constraints and policies set either by management or governance systems, or by external factors.

A value stream will generate outputs that can be used to create intended outcomes. Outputs can also include information and feedback to be shared with relevant stakeholders to aid in ongoing management or governance activities. In some cases, outputs can serve as input triggers for other value streams within or outside the organization.

4.1.2 Value streams and organizations

ITIL 4 does not equate an organization to a corporate entity. An organization can be a single person (e.g. a self-employed programmer or consultant), a team (e.g. a development or support team acting as a business unit), an enterprise, or even an ecosystem of enterprises working together.

Value streams are fundamentally connected to organizations. Consequently, there can be value streams at every level of granularity and they can be defined for a single person, a team, a business unit, etc. However, it is important to remember that value streams are defined in the context of a system that is established to create value for the organization, its customers, and other stakeholders. A large enterprise can include several distinct organizations managed with certain levels of autonomy, where it is possible to treat every one of them as an SVS with its own value chain and value streams. However, it is unlikely that self-sufficient SVSs will be established at the level of teams.

The overall goals and expectations for a product or service should be described from end to end; that is, from demand to value, rather than simply describing the use of each team in a disparate or un-coordinated set of activities. The value stream will therefore represent work across different teams, impacting different stakeholders, using different processes, tools and people, and sometimes even different suppliers.

ITIL service value streams need to be visualized, with a clear indication of touchpoints, where users interact with the product, service or IT service management professionals. A key advantage of the ITIL value stream technique is the ability to not only identify the multiple stakeholders who are involved but also to see potential points of failure, and explicitly connect value to demand.

Each step in a value stream could be reframed as a process, or as a value stream. The latter is typical for large enterprises and ecosystems where multiple enterprises are involved.

A high-level value stream that adds a new functionality to an IT service may involve a third-party vendor, an internal software development team, a site reliability engineering team, other IT teams, and a user team. Steps performed by the external vendor are likely to be managed as the vendor’s own value stream. Steps performed within the organization are formalized and managed as processes of the involved practices or activities within these processes.

Cascading value streams to lower-level value streams and/or processes allows organizations to:

• focus on value for the higher-level value stream, combining value streams and processes of participating parties

• progress iteratively with feedback from other organizations and teams in the value stream

• collaborate and promote visibility into how work flows across the organizations and teams

• think and work holistically by understanding how the wider organization or ecosystem works and benefits from work being done by the participating parties.

4.1.3 Value stream considerations

4.1.3.1 Selecting the right perspective

A value stream can be documented from one of two perspectives. It can either be designed to reflect the aspirations of the service provider or it can be explored to document the ways work is being done. After it has been documented, it can be compared against observed behaviours.

Deviations between the design and the observed behaviours are likely to trigger improvements. These may include:

• updating the value stream documentation to reflect actual work patterns

• optimizing the workflow by reducing the time taken to convert demand into value, and automating repeatable work.

4.1.3.2 Start and end points

A value stream always starts with demand and ends with value being created or restored for one or more stakeholder. Thus, it is highly desirable to maintain an outside-in tone or language when documenting the value stream, for example, by:

• reflecting business planning milestones and timelines

• using language relevant to the audience

• framing outcomes and value from the customer’s or user’s point of view.

4.1.3.3 Flexibility

A value stream repeats value chain activities, reflecting the context and the environment in which work is performed. A value stream can be as flexible as the organization needs it to be. For example, the organization can add another stage during the work, similar to a waterfall approach, or create iterative loops between value chain activities.

4.1.3.4 Granularity

Value streams are a representation of work, as viewed at a certain level of granularity. For example, a value stream that has Agile software activities can exhibit multiple iterations of work, reflecting the exploratory nature of that approach. Alternatively, the value stream can have a higher-level perspective that allows the work to be represented by a single step. Regardless of how the work is represented, it is critical that the level of granularity is uniform across the entire value stream.

4.1.3.5 Identifying steps

When deciding what constitutes a separate step in a value stream, and what should be included within an existing step, it is necessary to consider:

• the level of detail that would be represented in the value stream. The organization will need to decide whether the value stream will show details of all the actions or simply provide an overview of the work.

• whether hand-offs between individuals and teams could also have an impact on the value stream. Activities that are carried out by different teams are usually best shown as different steps. This can be very helpful for understanding where work is delayed by queues.

• the inclusion of multiple value chain activities, as these could also affect the value stream.

Inclusion of multiple value chain activities

If a step includes both engage and plan activities, it may be reasonable to split it into two separate steps. For example, a single step to determine customer requirements could be split into:

• working with the customer to define their requirements (this maps the engage value chain activity using contributions from service desk, relationship management, etc.)

• assessing the customer requirements (this maps the plan value chain activity, using contributions from business analysis, risk management, etc.).

Similarly, a single step to implement a hotfix from a vendor website could be separated into:

• downloading the hotfix from the website (this maps to the obtain/build value chain activity, using contributions from software development and management, supplier management, etc.)

• deploying the hotfix (this maps to the design and transition value chain activity, using contributions from change management, deployment management, etc.).

Alternatively, if multiple steps are executed by the same group of individuals or resources, it may be better to describe them as a single step positioned in the single value chain activity that best describes the outputs of the combined step. This will help to avoid the impression that work will be waiting in queues between each step.

4.1.3.6 Step order

Although streams often start with the engage activity, other activities can also be the first step. For example, if an engineer notices an incident raised by a monitoring tool (demand), the first step may be to begin investigation (deliver and support); it is unlikely to be to contact potentially impacted customers (engage).

4.1.3.7 Mapping to the service value chain

A step of the value stream can be described as mapping the bulk of its activities to one value chain activity, even though the underlying actions and tasks are mapped to other value chain activities. For example:

• A step to assess customer requirements can be mapped to the plan value chain activity but may have an action or tasks called ‘refine requirements with the customer’ that maps to the engage value chain activity.

• A step to download Hotfix from the vendor website can be mapped to the obtain/build value chain activity, but have an action or task called ‘update workaround’ that maps to the improve value chain activity.

4.1.3.8 Mapping to practices

The steps, actions, or tasks within a value stream can be mapped to a process or procedure within a practice, depending on the level of granularity. For example, a step to develop deployable code may be composed of actions and tasks that map to the following:

• procedures to execute automated tests

• processes for running manual tests.

4.1.4 Designing a service value stream

Practitioners are encouraged to adapt the following approach to the needs of their organization or to explore the use of other approaches.

1. Define the use case or scenario for the value stream by describing: • the demands (preferably in non-technical terms)

• the triggers created by the demand

• the outcomes created by the value stream

• value in the context of the value stream (as value can be created or restored).

2. Document the steps required to traverse the service value chain from demand through to value.

3. Map the steps from Step 2 to the service value chain.

4. If necessary, fragment the steps into actions and tasks.

5. Identify the practices and associated resources that contribute to the successful completion of each step, action, or task, including:

• operational and management teams or individuals

• tools and technology

• information and data (e.g. records, forms)

• any partners and suppliers that create outputs or outcomes using their own resources.

The five steps above should be completed in a collaborative way: as a series of meetings or workshops, for instance. The first stage of documentation is to establish a broad and general understanding, or baseline, of the work needed to respond to demand and generate value.

When a baseline has been established, the value stream can be further explored and optimized by:

• creating simple simulations to test the flow of work

• eliminating work that does not create meaningful outputs, outcomes, or benefits

• shifting work left

• delaying work that can introduce variance in quality, cost, or timeliness⁶

• introducing feedback loops and escalation mechanisms to improve the quality of the outputs and benefits produced by the value stream

• identifying opportunities to automate steps, actions, or tasks that will accelerate the flow of work

• identifying and managing bottlenecks and constraints, which may include redesigning the value stream around the constraint

• introducing triggers to review and, if necessary, improve the value stream. (Reviews can either be impromptu, such as whenever consumers provide feedback, or scheduled to occur regularly.)

4.1.5 Describing a step of the value stream

When describing a step in a value stream, the following need to be identified and documented:

• Name of the step Define what a step is. Decide if the step is to be described in non-technical language. Avoid acronyms and jargon so that those reviewing the value stream can easily understand what it aims to accomplish; for example:

• The phrase ‘register the user incident’ for a value stream step is preferable to ‘log incident ticket using the INC_template’.

• The phrase ‘document customer’s needs’ is preferable to ‘fill out form TK421 with customer input’.

• The input trigger(s) The trigger that will result in the step starting.

• Information The information needed to describe a step. This should be obtained either from an external stakeholder, a previous step in the value stream, or from other organizational resources. It is important to explore what information is required to create the defined outputs or outcomes and when the information will be available to the step.

• Practice contributions The tools, technologies, individuals, and other resources the organization’s practices contribute for the successful completion of the step.

• Actions and tasks What needs to occur to act on the incoming trigger and achieve the required output? Which ones can be executed in parallel and which will require prerequisites? How long will each action or task take?

• Constraints Which policies does the step need to comply with? These may be defined by the service provider or by external stakeholders. It is important to explore the resource constraints that the organization may face.

• Outputs Why the step exists. The outputs the step needs to provide. The value the step creates for the service provider, its consumers, or other stakeholders.

• Estimated or target lead time How long a unit of work should take to complete the step, including time spent waiting in a queue.

The following templates are useful starting points to describe a value stream. The first template, Table 4.1, provides a summary for the value stream, and the second, Table 4.2, provides a structure to describe each step of the value stream. Practitioners are encouraged to utilize the templates as they see fit.

4.1.6 Value stream mapping

Value stream mapping has its origins in Lean manufacturing techniques. It is a method of visualizing the flow, from demand/opportunity to value, and planning how that flow can be improved. In Lean, the core idea is to maximize customer value while minimizing waste. Simply, Lean involves creating more value for service consumers with fewer resources. A Lean organization understands the value of a service to the consumer and focuses its key processes on increasing it.

The goal is to provide perfect value to the service consumer through a perfect value creation process that does not produce any waste. To accomplish this, Lean thinking changes the focus of management from optimizing separate technologies, assets, and vertical departments to optimizing the flow of products and services to the consumer through entire value streams that flow horizontally across technologies, assets, and departments.

Value stream mapping is used to gain insight into an organization’s workflow and has a prominent role within ITIL. It can be used to identify both value-adding activities and non-value-adding activities in a value stream, while providing insight into opportunities for optimization and automation. Value stream mapping includes assessment (e.g. documenting the current state of the workflow from demand/opportunity to value) and planning (e.g. planning the changes that will be made to improve the workflow).

In many organizations, focusing on an individual process leads to optimizing only the steps in the process within a small scope of control, such as for a single team or department, while overlooking the impact of this local optimization on the whole value stream. Local optimization can create a bottleneck further down the value stream and potentially make the overall performance of the value stream worse, not better.

The elimination of waste along entire value streams, instead of at isolated points, creates processes that require less human effort, space, capital, and time, at far less cost and with fewer defects when compared with traditional business systems.

A value stream map is a great tool for optimizing the complete value chain, not just the local steps. This larger view is in perfect alignment with the guiding principle of thinking and working holistically. Value stream mapping⁷ helps organizations by:

• visualizing more than just the single-process level (e.g. assembly, welding, etc., in production), so the flow from opportunity to value is made clear

• making the sources of waste in each value stream more visible

• providing a common language for discussing value streams and processes

• making apparent the decisions that need to be made about the flow, so that they can be discussed (to prevent making ad hoc decisions at lower levels)

• tying together Lean concepts and techniques (to discourage the use of just one or two of them in isolation)

• forming the basis of an implementation or improvement plan. (By helping organizations design how the end-to-end flow should operate, value stream maps become a blueprint for implementation.)

• demonstrating the linkage between the information flow and the material flow.

Value stream mapping was originally developed in a manufacturing context, yet it applies equally well to the creation and delivery of services, as described in ITIL. Any aspect of the SVS that is part of a service value stream should be included in the value stream map.

Many different value streams are to be found in IT and service management, and they vary depending on the origins of the opportunity or demand, the required outcomes, and associated value. For example, the flow of activity for restoring a service as quickly as possible, delivering a service at the agreed levels of availability, or dealing with a service change could each be defined in a service value stream map.

The results of value stream mapping can be used in many contexts, such as writing out a business case, defining priorities, optimizing service value streams and practices within the organization, pinpointing bottlenecks in existing practices, and/or gaining a common understanding of issues affecting the organization. However, the most important role of a value stream map is to determine which improvement actions need to be implemented to achieve the desired future result.

For more information, refer to ITIL^® 4: Direct, Plan and Improve.

4.1.7 Key metrics when analysing a value stream

There are several important metrics which can be defined for any workflow and activity; these are outlined in Table 4.3 and shown in Figure 4.2.

These terms originate from Little’s Law, and more information can be found in operations management or queuing theory literature. Little’s Law can be simplistically represented as:

Work in progress = Throughput × Lead time or

Work in progress = Throughput × (Cycle time + Wait time)

This mathematical representation works for simple systems. In complicated environments, however, where more than one activity, step, or task is occurring simultaneously, it may be more difficult to apply this model.

The simplicity of the system is also a function of the granularity at which the value stream, activity, or task is being considered. For example, a value stream for a new service might be represented simplistically and at a very high level, as shown in Figure 4.3.

Figure 4.4 represents the same value stream with greater accuracy and with a significantly higher complexity at a more granular level. Clearly, it is more difficult to model lead time, queue time, and wait time.

Regardless of the complexity of the environment, Little’s Law leads to the following considerations when designing a value stream, step, or action:

• It is advisable to minimize the number of times work is transferred between resources implementing the various steps/actions/tasks, especially if these resources are individuals. Transfers create queues, and queues create waiting times, thereby increasing lead time. Reducing the number of potential transfers is often accomplished by increasing the level of automation, up-skilling staff to increase the range of tasks they can undertake, or reorganizing teams (often referred to as breaking down silos).

• Throughput, especially in the context of external events and triggers, is often not under the control of the service provider. However, the use of statistical modelling functions (e.g. Poisson distribution, Gaussian distribution, and Pareto distribution) can help estimate the pattern of activity. For example, a supermarket cannot predict the exact number of shoppers visiting each hour of the business day, but it can use statistical models to create estimates.

• In simple systems, wait time can be expressed as a function of cycle time. A new unit of work is cycle time multiplied by the units of work already in the system. For example, if it takes 10 minutes to complete a unit of work, with one unit currently being undertaken and three units waiting to be undertaken, then:

• the next unit of work to enter the system will spend 10 minutes/unit × (1 + 3) units = 40 minutes in the queue

• the lead time for the next unit of work would be 40 minutes wait time + 10 minutes cycle time = 50 minutes

• Depending on the level of granularity and the nature of the work, cycle time can be assumed to be fixed and predictable.

• To create a more predictable cycle time, it may be necessary to limit the work in progress. This technique is a part of the Kanban method and works well in environments where the throughput (intake of work) is predictable. For example, a team might limit their work in progress to three requests at a time and delay working on any additional requests if the work in progress crosses this limit.

4.2 Model value streams for creation, delivery, and support

This section explores the two common value stream models that can be found in nearly all organizations:

• Development of a new service Organizations often find it necessary to create, modify, or retire services. This value stream reflects the common patterns of work required to create a new service and so usually involves significant effort and coordination across the organization.

• Restoration of a live service In modern, complex IT organizations, failure is to be expected and must be managed quickly. This value stream is concerned with the typical activities that are expected when detecting and resolving failures and how these activities can be leveraged to improve the service.

These value stream models should be adapted to the needs of each organization because the context, complexity, level of granularity, number of steps, inputs, and outputs of each step will be different from those depicted here.

Although these models use the templates from section 4.1, many alternatives exist (e.g. the example target lead time and example roles). These clarify how to use the form and should not be interpreted as prescriptive guidance or standard calculations of activities.

When the following sections refer to resources in the context of practice contributions, they include any or all of the four dimensions of service management:

• Organizations and people Skills, management authority, funding, staffing, etc.

• Information and technology Tools, databases, data objects, information objects, etc.

• Partners and suppliers Vendors that provide products and services to the organization, etc.

• Value streams and processes Processes, procedures, templates, etc.

4.2.1 Development of a new service

This value stream archetype explores the activities that organizations commonly undertake to create or significantly modify an existing service. It is indifferent to the nature of the service and can be used to describe a value stream for creating services that are either provided to the customers within the organization or external to the organization.

4.2.1.1 Design considerations

Typical considerations when designing this value stream include:

• Determine how the work will be managed. Will it be in large increments using sequential waterfall phases or in small increments that provide fast feedback and the opportunity to change specifications at short notice (such as an Agile approach), or a mixture of both? It may be necessary to create separate value streams, depending on how the work is managed, and to describe different project management methodologies in each value stream.

• Establish the correct level of oversight to maintain focus on business outcomes rather than outputs.

• Establish the correct level of bureaucracy to ensure effective coordination of activities between the various organizational units and the organization’s partners, suppliers, customers, users, and other key stakeholders.

• Join all of the activities from all of the required practices to create a new service, creating an end-to-end, holistic vision for the work.

• Ensure that the organization has a clear understanding of the customer’s intended goals and expectations, and track each of them from start to finish to ensure that the service supports the required outcomes. The organization should avoid introducing conflicts or inconsistencies when translating customer needs into service specifications (whether functional or non-functional).

• Understand the customer’s journey from demand to value and define requirements from the customer’s point of view rather than relying solely on internal perspectives or the prior experience of team members.

4.2.1.2 The journey from demand to value

This value stream describes the journey from demand in six key steps (as shown in Figure 4.5):

1. Acknowledge and document the service requirements (engage)

2. Decide whether to invest in the new service (plan)

3. Design and architect the new service to meet customer requirements (design and transition)

4. Build, configure, or buy service components (obtain/build)

5. Deploy service components in preparation for launch (design and transition)

6. Release new service to customers and users (deliver and support).

4.2.1.3 Demand and value

This value stream is triggered by a demand to create a new service. It may originate from:

• a service consumer: a sponsor, customer, or user. The service consumer can be external to the service provider or a member of the same organization, depending on the context.

• an external stakeholder other than the service consumer, such as a supplier or regulator.

• a staff member of one of the service provider’s business functions (e.g. sales or marketing), who has sensed a new opportunity. Opportunities external to the SVS can translate into demand for value co-creation.

• members of the organization’s governing body.

The demand can be recognized in many ways, depending on the context and the tools. Generally, the demand is a request made to the senior managers or their authorized representatives. Note that the subsequent steps of this value stream refer to the requester as the individual or role with the demand for value that initiated the value stream; it does not refer to a role within service request management.

It is important at this stage that the demand articulates both desired outcomes and expected value from the service. A useful technique is to adapt the commonly used Agile software development template for epics and user stories, which breaks down the need as follows:

As a <persona> I want <outcome> so that <value>.

For example:

• As a business development manager, I want to track my sales pipeline so that I can focus on closing new deals.

• As an infrastructure engineer, I want to be able to group monitoring alerts so that I can correlate alerts and eliminate duplicates.

Step 1: Acknowledge and document the service requirements

Any request for a new product or service feature starts by acknowledging and documenting the demand. Generally, business case methods are used to collect and assess requirements. It is important to remember that the objective is to collect enough information to submit a business case.

Successful completion of this step requires the organization to engage with the requester and other stakeholders (e.g. marketing and sample users), using surveys and polls to complete the business case template with high-level information about the requirement, benefits (both quantitative and qualitative), costs, and risks. This information is also supplemented by high-level estimates from various technical and service management teams, which consider the cost of development, release, operations, and support.

Practices that commonly contribute to this step include:

• Business analysis Provides the skills, tools, and other resources needed to document customer requirements, as per the business case, to the depth needed to perform a viability assessment.

• Portfolio management Provides information on current, retired, and future (planned) services.

• Relationship management Provides the skills, information, and other resources needed to manage the requester’s expectations and create a rapport with the service provider.

• Service configuration management Provides information on currently operational services and service components so as to provide context when describing the demand.

• Service level management Provides information on current service levels to provide context when describing the demand.

Step 2: Decide whether to invest in the new service

When the request has been refined and documented in the business case, it might be necessary to clarify the initial cost, benefit, and risk assessments so that the organization can plan the work. This would require more detailed discussions with various internal teams, and possibly ongoing conversations with customers and other external stakeholders. When completed, the business case can be considered by the management team, who will then decide whether to grant approval.

Practices that commonly contribute to this step include:

• Business analysis Provides the skills, tools, and other resources needed to work with various specialist teams in gathering additional information and assessments and to perform a viability analysis against the customer requirements that are documented in the business case.

• Infrastructure and platform management Provides supplementary assessments on how infrastructure components of the new service might be engineered and developed, and how this service is impacting on ongoing application management activities. Also contributes as necessary to the business case assessment.

• Portfolio management Provides the resources necessary to allow the service owner to complete the viability assessment and decide whether to authorize the investment in the new service.

• Problem management Provides information on current errors and workarounds that might have an impact on the new features.

• Project management Provides administrative and technical resources to complete the business case assessment. The overview can be used to complete the value stream step template provided in Table 4.2.

• Risk management Provides information on current enterprise risks that may be impacted either positively or negatively by the new features.

• Service configuration management Provides information on currently operational services and configuration items.

• Service design Provides supplementary assessments on how the new service may be designed to meet internal standards and policies around utility, warranty, brand, and other criteria, and contributes as necessary to the business case assessment.

• Service desk Provides supplementary assessments on how the new service might impact current customer and user support channels and contributes as necessary to the business case assessment.

• Service financial management Provides tools and policies to calculate the ROI that new features may provide.

• Service level management Provides information on both the current service levels and the changes the new functionality might introduce.

• Software development and management Provides supplementary assessments on how software components of the new service could be engineered and developed and this service’s impact on ongoing application management activities. Also contributes as necessary to the business case assessment.

Step 3: Design and architect the new service to meet customer requirements

Note: this example assumes that the management team has authorized the investment that is needed to fulfil the request for new features. When the decision has been made to modify the existing service, it will be necessary to review it and modify the design to accommodate the new features. For example:

• integrate the account review system with the payments system

• increase the business, service, and technology capacity

• assess the additional infrastructure required to maintain current service level targets around utility and warranty.

There is also a need at this stage to translate the requested features and updated service design into software and infrastructure designs and specifications. This may result in the creation of an initial backlog of epics and user stories, depending on the methods used to develop software and infrastructure components.

Practices that commonly contribute to this step include:

• Architecture management Provides architectural requirements and constraints.

• Availability management Provides the skills, tools, and other resources needed to describe both the potential demand for the service and the technical, service, and business capacity required to meet that demand (and to document these in the service design package).

• Business analysis Provides the skills, tools, and other resources needed to coordinate the work required and ensures that the outputs are recorded consistently in the service design package.

• Capacity and performance management Provides the skills, tools, and other resources needed to describe both the potential demand for the service and the technical, service, and business capacity needed to satisfy that demand while maintaining expected levels of performance (and to document these in the service design package).

• Information security management Provides the skills, tools, and other resources needed to design the controls that ensure not only the confidentiality, integrity, and availability of information but that the authentication and non-repudiation of customers/users is aligned with the organization’s policies (and to document these controls in the service design package).

• Infrastructure and platform management Provides the skills, tools, and other resources needed to create and refine a high-level design of the infrastructure components required to meet the utility and warranty criteria specified in the service design package.

• Project management Provides the skills, tools, and other resources needed to initiate the project and to identify and plan sufficient resources to complete the tasks that will enable the objectives to be achieved.

• Service configuration management Provides information on currently operational services and configuration items.

• Service continuity management Provides the skills, tools, and other resources needed to design the controls that will ensure that both the availability and performance of the new service are maintained at acceptable levels in the case of a disaster (and to document these in the service design package).

• Service design Provides the skills, tools, and other resources needed to design both the customer experience and user experience when interacting with the new service (and to document these in the baseline service design package).

• Service level management Provides the skills, tools, and other resources needed to set clear business-based targets for service levels (and to document these in the service design package).

• Software development and management Provides the skills, tools, and other resources needed to create and refine an initial list of epics and user stories in line with the specifications in the service design package.

• Supplier management Assists in interactions with partners and suppliers and in selecting new suppliers to source service components.

Step 4: Build, configure, or buy service components

When the design package has been baselined, work to obtain or build service components can begin. A service component is often technical (e.g. software, servers, storage, or networks). Depending on the nature of the service, however, some non-technical service components (e.g. new team structures, new roles, critical skills and competencies, knowledge-based articles, training documentation, and vendor contracts) may also need to be managed.

Thus, it is critical to acknowledge and configure both the technical and non-technical aspects of products and services, which can include:

• technical integration between the applications

• modification of existing back-end and client applications

• an increase in the processing capacity and infrastructure

• the updating and communication of training documents for customer support agents and provision of simple scripts to help customers

• the updating and communication of release notes that can be used to promote the new service

• marketing of the upcoming changes to products and services, without committing to specific features

• updating the service design package to reflect agreed-upon changes made while obtaining or building service components.

Practices that commonly contribute to this step include:

• Infrastructure and platform management Provides the engineering skills, tools, and other resources needed to update the infrastructure and to integrate new systems and other infrastructure components into the existing service.

• Portfolio management Provides the skills, tools, and other resources needed to update and communicate changes to the service portfolio as service components are created.

• Project management Provides cross-team coordination of activities, issue and risk tracking, and regular status updates to the project board.

• Release management Provides the skills, tools, and other resources needed to create and communicate the release plan and then to update and maintain it as the development and deployment activities progress.

• Risk management Provides information on current risks and policies with which the new or modified service components need to comply.

• Service configuration management Provides information on current operational services and configuration items, as well as the skills, tools, and other resources required to update service configuration records as service components are created.

• Service validation and testing Provides the technical skills, tools, and other resources needed to document test cases, carry out automated and manual testing, and supply feedback and reports from testing activities.

• Software development and management Provides the engineering skills, tools, and other resources needed to create new application features and to integrate new systems and other software components into the existing service.

• Supplier management Assists in interactions with partners and suppliers and in selecting new suppliers to source service components.

Step 5: Deploy service components in preparation for launch

When service components have been built, work to modify the live products and services can begin. Owing to the mixed nature of service components, the organization may need to use different approaches to modifying live products and services, for example:

• Software components leverage the CI/CD pipeline and are immediately deployed into production with a feature flag that prevents users from accidentally accessing new or changed features.

• Infrastructure components, such as server, storage, or network configurations, are developed and deployed prior to the launch.

• Internal documentation is developed over the course of the obtain/build step and are distributed just prior to launch.

• Marketing documentation can be developed using stable software features and in conjunction with release plans.

At this stage, two more important pieces of work can also be considered:

• Plan the release of the service When most of the development and configuration work is complete, it is possible to finalize the release plans. Depending on the context and need, it may be more effective to add another step to the value stream (e.g. returning to the plan value chain activity), where the outputs are the release plans.

• Create customer collateral This includes flyers, emails, posters, advertisements, etc. to build awareness of the new features and to promote their benefits.

Practices that commonly contribute to this step include:

• Change enablement Provides the skills, tools, and other resources needed to submit, assess, and approve requests for change, and schedule changes to various service components.

• Deployment management Provides the skills, tools, and other resources needed to deploy various service components (both technical and non-technical) into the live environment.

• Incident management Agrees the duration, channels, and methods to provide early-life support (ELS).

• Knowledge management Provides the skills, tools, and other resources needed to update support scripts.

• Problem management Documents all known defects (technical debt) and workarounds present in the new features.

• Project management Provides cross-team coordination of activities, issue and risk tracking, and regular status updates to the project board.

• Release management Provides the skills, tools, and other resources needed to finalize the release (launch) plan, working with other groups in the organization (e.g. sales and marketing departments) to communicate these plans to users and customers.

• Service configuration management Provides information on currently operational services and configuration items, as well as the skills, tools, and other resources required to update service configuration records as service components are built.

• Service desk Ensures that all customer-facing support roles are adequately trained in the new features, known defects, and workarounds.

• Supplier management Assists in interactions with partners and suppliers and in selecting new suppliers to source service components.

Step 6: Release new service to customers and users

When all of the service components have been deployed, the organization is ready to make them available to end users. The previous step planned the release; this step will implement it.

Releases of service components can be more than technical procedures. It may be necessary to carefully coordinate technical and non-technical work, such as sales and marketing campaigns.

In this step, the service components are provided with ELS for a short period of time, before they move into a business-as-usual mode. ELS can take many forms and is dependent on the needs of the organization and its customers, with options such as:

• Dedicated ELS teams These are drawn from across the value stream. The team focuses on key metrics that are defined in the service design package and often have the autonomy to bypass the normal incident management and change management practices to rapidly deploy fixes. The team also works closely with the product owners across the organization to add priority tasks to the backlogs of various teams.

• Super-users Often drawn from the community of customers and users, super-users act as promoters and champions within their organizations on community forums, social media, and other channels. Promoters for the new or updated product have been trained and briefed to a high standard to enable them to support any teams or users; for example, business users or the first line/service desk.

• On-site, in-person support staff ELS can also be implemented by IT staff making themselves available at customer locations or on site. These staff are colloquially known as floor-walkers.

Practices that commonly contribute to this step include:

• Incident management Provides the skills, tools, and resources needed for ELS, to update support scripts and knowledge articles, and to enable transition from ELS to business-as-usual support.

• Infrastructure and platform management Provides IT operations resources to run the relevant infrastructure components.

• Problem management Documents all known defects (technical debt) and workarounds present in the new service.

• Project management Provides cross-team coordination of activities, issue and risk tracking, and regular status updates to the project board.

• Relationship management Provides the skills, information, and other resources needed to manage customer and user expectations when they contact the organization with issues, requests, and queries.

• Release management Provides the skills, tools, and other resources needed to execute the release (launch) plan, to ensure the release is successfully completed.

• Service configuration management Provides information on currently operational services and configuration items.

• Service desk Provides the skills, tools, and resources needed to capture customer and user demand (e.g. issues, requests, and queries) when the new service is released.

• Software development and management Provides IT application management resources to run the relevant software components.

• Supplier management Assists in interactions with partners and suppliers and in selecting new suppliers to source service components.

When the service components have been released, customers and users can interact with them through the service relationship, thus generating the required outcomes and co-creating value.

It is possible to extend this value stream to include additional activities after the components have been released, for example:

• engaging with the requester to identify any gaps in the new service, or any outcomes, costs, and risks that were not identified during the value stream activities.

• identifying opportunities to improve the service, value stream, and contributing practices.

4.2.2 Restoration of a live service

This value stream model examines the typical activities that organizations undertake to support an existing service. This archetype is indifferent to the nature of the service and can be used to describe a value stream to support services provided to consumers within the organization or external to the organization.

4.2.2.1 Design considerations

Typical considerations when designing this value stream include:

• Identifying stakeholders and what the creation or restoration of value means to them, for example:

• for the user, it could mean the ability to resume using products and services

• for the organization’s compliance officer, it could mean maintaining proper records of the issue and the steps taken to restore the value

• for the service owner, it could mean documenting activities in enough depth to enable trend reporting, problem investigation, and the identification of improvement opportunities.

• Taking an outside-in approach to understanding the impact of incidents and connecting these assessments to descriptions of value for various stakeholders.

• Defining first the scope of the value stream and then defining a single value stream that encompasses all activities within scope to create an end-to-end, holistic vision of how support creates or restores value.

• Highlighting activities performed by partners and suppliers that might introduce risks or dependencies to the successful creation or restoration of value.

• Understanding what (or how) systems should be integrated and data shared across multiple centres of activities.

4.2.2.2 Demand and value

This value stream is triggered by a user who is unable to use a live product or service. This loss of productivity leads to value leakage,⁸ with the service consumer being unable to derive maximum value from the sub-optimal product or service.

Demand could also originate within the service provider, when monitoring tools proactively alert the organization to failures that may or may not have impacted users. In this scenario, the value stream may bypass Step 1 or switch the order of Steps 1 and 2. In other words, the service provider may if required:

• start working to resolve the incident without being prompted to do so by a user

• proactively contact users to notify them of an ongoing incident

• approach users after the incident has been resolved.

The demand for value to be restored drives this value stream.

4.2.2.3 The journey from demand to value

This value stream describes seven key steps (as shown in Figure 4.6):

1. Acknowledge and register the user query (engage)

2. Investigate the query, reclassify it as an incident, and attempt to fix it (deliver and support)

3. Obtain a fix from the specialist team (obtain/build)

4. Deploy the fix (design and transition)

5. Verify that the incident has been resolved (deliver and support)

6. Request feedback from the user (engage)

7. Identify opportunities to improve the overall system (improve).

This value stream branches at Step 2. If the initial attempt to fix the incident is successful, then value is restored without any further activity. This is represented as the dashed line from Step 2 to value.

The restoration of value after Step 5 could be the end of the value stream, but there are further activities, described in Steps 6 and 7, which ask for and process feedback. For example, it is common for organizations to request feedback from a random sample of customers.

Step 1: Acknowledge and register the user query

The first step in the value stream is to engage with the customer or user to recognize and acknowledge the demand and to record details about the query. At this stage, the user contact is still a query,⁹ as it has not yet been triaged and recognized as an incident.

Practices that commonly contribute to this step include:

• Service catalogue management Provides the information, skills, tools, and other resources needed to optimize the registration of the query.

• Service desk Provides the skills, tools, and other resources needed to allow the customer or user to contact service support, enable customer support agents to empathize and manage communications with the customer or user, and retrieve and communicate information about expected resolution time.

Step 2: Investigate the query, reclassify it as an incident, and attempt to fix it

As the query is recorded, a trained support agent or equivalent automation, such as chatbots, can recognize and recategorize the query as an incident, thus initiating a script or standard procedure for classifying the record accordingly. However, this could create a new incident record linked to the initial query, depending on the organization’s procedures and tools.

When a user-initiated incident is registered, an attempt to quickly identify its nature and apply a known solution is usually made.

Support agents often follow a script, or workflow, of activities that allows them to attempt one or more fixes. If one of these fixes recovers the service to its normal state, value has been restored and the value stream can end. If none of these fixes work, then the issue can be escalated to a specialist role for further investigation.

Practices that commonly contribute to this step include:

• Incident management Provides the skills, tools, and other resources needed to register the incident, together with information on how long it might take to resolve.

• Knowledge management Provides the skills, tools, and other resources needed to find technical information and workarounds that can help in the investigation, diagnosis, and fixing of the incident.

• Monitoring and event management Provides access to monitoring tools and logs to assist in the investigation and diagnosis of the incident.

• Service configuration management Assists the investigation and diagnosis of the incident, by providing information on relevant configuration items.

• Service desk Provides the skills, tools, and other resources needed to enable support agents to empathize with and manage communications with the customer or user.

• Service level management Provides information that can be used to assess the impact of the incident and plan restoration of service.

Investigation and diagnosis are often a highly technical activity. However, attention should also be paid to non-technical factors (such as environmental or financial factors) The following are possible examples:

• The reason for the network outage is because a storm is affecting local cables or satellite connectivity.

• The reason why a streaming service no longer works is because the customer’s or user’s credit card has been declined.

Step 3: Obtain a fix from the specialist team

In this step, the incident is escalated to, or referred to, a specialist team because initial attempts to restore the service were unsuccessful. This can happen in several ways, depending on the context, some of which may involve passing control over to the specialist team. For example:

• The support agent can look for a patch on a vendor website. However, this does not pass control of the incident to the vendor.

• The support agent raises an incident with a vendor. This does not pass control of the user’s incident, but instead creates a parallel incident ticket managed by the vendor.

• The support agent escalates the incident to an internal engineering team. This passes control of the incident to the engineering team.

• The support agent asks an outsourced engineering team to provide a fix. This may or may not involve passing control of the incident to the engineering team.

The fix can also be something readily available, such as a publicly available patch or upgrade. In some cases, the fix may be physical, such as replacing a faulty hard drive. Often, when dealing with custom applications or hardware, fixes have to be built before they can be deployed.

Practices that commonly contribute to this step include:

• Incident management Provides the skills, tools, and other resources needed to update the incident record with details of the activities necessary to build and test the fix.

• Infrastructure and platform management Depending on the nature of the incident, this practice might provide the skills, tools, and other resources needed to build or configure the fix to faulty infrastructure or platforms.

• Knowledge management Provides the skills, tools, and other resources needed to find technical information that can help in the investigation and diagnosis of the incident and to update existing knowledge records with information about the fix.

• Service configuration management Provides the skills, tools, and other resources needed to update service configuration records as the fix is created.

• Service desk Provides the skills, tools, and other resources needed to enable support agents to empathize with and manage communications with the customer or user.

• Service financial management Depending on the nature of the fix, this practice might need to pay partners or suppliers for resources or service components needed to resolve the incident.

• Service validation and testing Provides the skills, tools, and other resources to test the fix and confirm that it resolves the incident and meets all relevant policies and standards.

• Software development and management Depending on the nature of the incident, this practice might provide the skills, tools, and other resources needed to build or configure the fix to faulty software.

• Supplier management Depending on the nature of the incident, this practice might provide the skills, tools, and other resources needed to interact with key suppliers who can assist in building the fix.

Step 4: Deploy the fix

When the fix has been obtained, tested, and validated, it can be deployed to the user or to a production environment.

Deployment can take many forms; for example:

• using a CI/CD pipeline to distribute the fix across a production environment

• delivering a hardware component (e.g. a new hard disk) to a data centre, where it is subsequently provisioned

• delivering a hardware component (e.g. a new laptop) to the end-user office, where it is configured by the local IT support staff

• remotely logging on to the user’s PC to install a patch from a network drive.

Practices that commonly contribute to this step include:

• Deployment management Provides the skills, tools, and other resources needed to deploy the fix to the user or to a production environment.

• Incident management Provides the skills, tools, and other resources needed to update the incident record with details of the activities needed to deploy the fix.

• Infrastructure and platform management Depending on the nature of the incident, this practice might provide the skills, tools, and other resources needed to configure and package the fix for deployment.

• Knowledge management Provides the skills, tools, and other resources needed to update existing knowledge records with information about the fix.

• Service configuration management Provides the skills, tools, and other resources needed to update service configuration records as the fix is deployed.

• Service desk Provides the skills, tools, and other resources needed to enable support agents to empathize and manage communications with the customer or user.

• Service financial management Depending on the nature of the deployment, this practice might need to pay partners or suppliers.

• Software development and management Depending on the nature of the fix, this practice might provide the skills, tools, and other resources needed to configure and package the fix for deployment.

• Supplier management Depending on the nature of the incident, this practice might provide the skills, tools, and other resources needed to interact with key suppliers who can assist in configuring and packaging the fix for deployment.

Step 5: Verify that the incident has been resolved

When the fix has been deployed, the next step is to verify that the incident has been resolved. This step is quite similar to Steps 1 and 2 earlier in the value stream, as it involves the support agent communicating and empathizing with the user.

As described in ITIL Foundation, value is the perceived benefit, usefulness, or importance of something. In this model, value can be perceived differently by the user and the organization. For example:

• The user might perceive value leakage as a combination of the time it took to restore the service, associated loss of productivity, frustration from the loss of productivity, any additional issues or complications that may have arisen while waiting for service restoration, experience of working with IT support, and perceived reliability of the service. Efficient removal of the value leakage is, in turn, perceived as valuable.

• The IT support agent might calculate value based on the experience of working with the user, with specialist teams, the time taken to interact with various groups, and update relevant records.

• The specialist team might perceive value based on the experience of working with either the IT support agent or the user, the complexity of creating and deploying the fix, and updating relevant records.

Moreover, even though the incident might be resolved at a technical level, the user might need additional assistance; for example, to:

• know that the service has been restored

• re-enable access and consumption of the service

• address any outstanding or additional concerns that arose due to the incident.

As a result, it is advisable to check back with the user to ensure that value has been restored satisfactorily. This helps in increasing empathy between IT support and the user, which can, in the long term, lead to increased trust between both parties.

The incident can be deemed to be resolved when the affected product or service is operating at optimal levels. In other words, when value leakage has been rectified.

In order to distinguish between resolving and closing an incident, many IT support tools assign statuses to incident records in the following way:

• Resolving an incident means that the underlying technical concerns have been addressed.

• Closing an incident means that the fix, and associated restoration of value, has been confirmed by the user.

• Procedures to resolve or close an incident are part of the underlying design of the incident management practice and are subsequently used by the value stream. In this section, this generally refers to resolving an incident.

Practices that commonly contribute to this step include:

• Incident management Provides the skills, tools, and other resources needed to update (resolve or close) the incident record with details of the user interaction.

• Knowledge management Provides the skills, tools, and other resources needed to update existing knowledge records with information about the fix and the restoration of value.

• Service configuration management Provides the skills, tools, and other resources needed to update service configuration records as the incident is resolved. This overview can be used to fill out the value stream step template provided in Table 4.2.

• Service desk Provides the skills, tools, and other resources needed to enable support agents to empathize and manage communications with the customer or user.

• Service level management Provides information to assess sufficiency of the restored/achieved service level and timeliness of the restoration.

Step 6: Request feedback from the user

Many organizations ask for feedback from users after incidents have been resolved in order to identify opportunities to improve the service, the way they communicate with the users, the procedures used to fix the incident, or the key practices. It is often useful to supplement this with feedback from other roles involved in the value stream, such as the IT support agent and technical specialists.

Whether giving or collecting feedback, it is important to maintain a positive attitude by exploring how to do better, rather than focusing on what went wrong. It is often hard to separate emotion and ego when discussing the history of an incident and its impact. It may also be necessary to identify and filter out environmental, personal, or professional factors that might bias the feedback, as in the following examples:

• A parent worried about a sick child might be overly negative when sharing feedback.

• An IT support agent worried about upcoming layoffs may not be focused on daily work.

• A business development manager who has landed a big sale might be more kind and forgiving of IT support issues.

Increasing empathy and trust between the user and IT support can help improve communication and reduce the impact of biases. Feedback can be collected in a variety of ways but should ultimately be stored in a central location, to aid analysis and management reporting.

Practices that commonly contribute to this step include:

• Continual improvement Provides the skills, tools, and other resources needed to collect feedback from the user.

• Infrastructure and platform management Depending on the nature of the incident and the steps needed to resolve it, this practice might provide the skills, tools, and other resources needed to provide relevant feedback that can be used to identify improvement opportunities.

• Service desk Provides the skills, tools, and other resources needed to enable support agents to empathize and manage communications with various stakeholders.

• Software development and management Depending on the nature of the incident and the steps needed to resolve it, this practice might provide the skills, tools, and other resources needed to provide relevant feedback that can be used to identify improvement opportunities.

• Supplier management Depending on the nature of the incident and the steps needed to resolve it, this practice might provide the skills, tools, and other resources needed to provide relevant feedback that can be used to identify improvement opportunities.

Step 7: Identify opportunities to improve the overall system

When feedback has been collected from all relevant stakeholders, it can be analysed in isolation or in conjunction with other information, such as historical data about the service, the service provider, the service consumer organization, external constraints, etc. In this way, opportunities can be identified to improve the overall system. For example:

• the service provider organization or, more generally, the SVS and its components

• the value stream and associated steps, actions, and tasks

• the relationship with the user, partners, suppliers, and other stakeholders

• the ways of defining and perceiving value.

Any improvements identified should be logged in the service provider’s continual improvement register, thus creating value for both the service provider organization and the provider’s SVS. When logged in the register, improvement opportunities can be prioritized against other work in the SVS.

Practices that commonly contribute to this step include:

• Continual improvement Provides the skills, tools, and other resources needed to identify opportunities to improve the SVS and its components; identify opportunities to improve the way in which feedback is collected and analysed; identify ways in which the service can be improved, and record these in the continual improvement register.

• Deployment management Provides the skills, tools, and other resources needed to identify opportunities to improve the practice and record them in the continual improvement register.

• Incident management Provides the skills, tools, and other resources needed to identify opportunities to improve the practice and record them in the continual improvement register.

• Infrastructure and platform management Provides the skills, tools, and other resources needed to identify opportunities to improve the practice and record them in the continual improvement register.

• Knowledge management Provides the skills, tools, and other resources needed to identify opportunities to improve the practice and record them in the continual improvement register.

• Monitoring and event management Provides the skills, tools, and other resources needed to identify opportunities to improve the practice and record them in the continual improvement register.

• Problem management Provides the skills, tools, and other resources to investigate and mitigate possible causes of the incident(s).

• Risk management Provides the skills, tools, and other resources to manage new risks that have arisen, or existing risks that have changed, due to the incident or the fix.

• Service configuration management Provides the skills, tools, and other resources needed to identify opportunities to improve the practice and record them in the continual improvement register.

• Service desk Provides the skills, tools, and other resources needed to identify opportunities to improve the practice and record them in the continual improvement register.

• Service financial management Provides the skills, tools, and other resources needed to identify opportunities to improve the practice and record them in the continual improvement register.

• Service validation and testing Provides the skills, tools, and other resources needed to identify opportunities to improve the practice and record them in the continual improvement register.

• Service level management Provides the information, tools, and skills to register and assess service improvement initiatives.

• Software development and management Provides the skills, tools, and other resources needed to identify opportunities to improve the practice and record them in the continual improvement register.

• Supplier management Provides the skills, tools, and other resources needed to identify opportunities to improve the practice and record them in the continual improvement register.

4.3 Using value streams to define a minimum viable practice

The value stream design and documentation techniques described in earlier sections help the service provider understand the nature and flow of work, from demand to value, and the contributions from organizational resources and practices that enable that flow.

The same techniques can also be used to define the minimum set of contributions needed from a practice that benefits the organization or a stakeholder and allows for learning and continual improvement.

For instance, if it was assumed that the two value stream models discussed in section 4.2 were the only value streams in the service provider organization, then the practice contributions could be consolidated using the template that is Table 4.4.

So, for example, the contributions could be consolidated as required by service configuration management, as shown in Table 4.5.

Thus, if challenged about the lack of a specific functionality or skill set, the logical response would be to investigate what value stream step requires that contribution, which may lead to one of two options:

• dropping the requirement to build the functionality or skill set

• documenting a new value stream, or amending an existing value stream, that acknowledges the need for a new functionality.

In the example above, if a senior manager challenges the service configuration management practice owner on why the practice does not support the regular audit of the IT landscape to identify configuration items that have not been recorded, the discussion could lead to either of the following outcomes:

• Mutual agreement that the functionality is not needed.

• The identification of a new, or hitherto undocumented, value stream in which configuration items are regularly audited.

The adoption of a minimum viable practice approach will help organizations avoid investing in skills, tools, processes, and other resources that are not needed by the organization. This will:

• lower the total cost of ownership (TCO) of the practice

• increase the return on investment in service configuration management.

4.4 Summary

A value stream is a representation of a journey through the service value chain, showing how work flows across an organization as it creates, enhances, or supports products and services that co-create value with the service consumer. Value streams and processes are one of the dimensions of service management, depicting the steps, actions, and tasks required to co-create value from demand.

Value streams are also highly contextual and reflect the scope of control and influence of the organization, as well as the scenario or type of demand. Value streams reflect a level of granularity that is sufficient to communicate the flow of work. Value streams can be depicted as linear flows or as iterative loops. They can reflect an aspiration of how work should flow, or they might reflect how work flows across the organization.

In certain scenarios, value streams can also cascade across several organizations. For example, a step in a cross-organizational value stream could be the entire value stream of one participating organization.

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