Value Stream

A value stream describes how an organization creates value from the point of view of the person receiving it. For a customer buying insurance, the value stream might run from requesting a quote, through underwriting and issuing a policy, to receiving confirmation. For an employee, a hiring value stream might run from a job request to a productive new team member. Each stage in the stream produces something the next stage needs, and together they deliver an outcome the stakeholder cares about.

Value streams help organizations look across departmental boundaries. Most outcomes depend on several teams, systems and processes, and problems often arise at the handoffs between them. By mapping the whole stream, leaders can see where time is lost, where costs accumulate and which capabilities and systems each stage depends on. For enterprise architecture and IT finance, value streams connect investment in capabilities and technology to the outcomes customers and the business actually experience.

Definition of Value Stream

In business architecture, a value stream is an end-to-end collection of value-adding stages that creates an overall result for a customer, stakeholder or end user. Each stage has an entrance and exit condition and a value item it contributes.

Value streams are a core model in business architecture, alongside the business capability map. Each value stream stage draws on one or more capabilities.

Value Streams in Business Architecture and Lean

In business architecture, value streams are relatively stable, high-level models that describe what stages are needed to deliver value, without detailing how the work is done.

In lean and agile practice, the term often refers to value stream mapping, a detailed analysis of process steps, wait times and waste in a specific flow of work. This practice is described under value stream mapping.

The two uses complement each other. Business architecture value streams show where to focus, and lean value stream mapping shows how to improve the work at that point.

Elements of a Value Stream

The triggering stakeholder starts the value stream, such as a customer requesting a service or a manager requesting a hire. Naming the stakeholder keeps the value stream focused on outcomes rather than internal activity.

Stages are the major steps in delivering value, each named for what it achieves, such as "assess risk" or "confirm coverage." Most value streams have between five and ten stages.

The value proposition describes what the stakeholder receives at the end. Each stage is linked to the capabilities that enable it, and often to the applications, teams and costs involved.

Importance of Value Streams in Enterprise Architecture

Value streams keep architecture focused on outcomes. They show how capabilities and systems combine to deliver results that customers and the business care about. This helps business leaders see architecture in terms they recognize.

They reveal problems at handoffs. Delays, rework and errors often occur where one team or system passes work to another, and value streams make these points visible. These problems are often invisible to each department, since each sees only its own part.

They also help prioritize investment, since improving a weak stage in an important value stream often delivers more benefit than improving an isolated capability.

Connecting Value Streams to Cost and Investment

Linking each value stream stage to the capabilities, applications and teams involved allows organizations to estimate the cost of delivering each outcome.

Comparing that cost with the value delivered, or with competitors' performance, highlights where simplification or investment is most needed.

Many organizations now organize teams and funding around value streams rather than projects, so that persistent teams own the improvement of specific outcomes. This approach is closely related to product-based IT operating models.

Capability-based planning often uses value streams to show which capability improvements will have the greatest effect on outcomes.

Common Challenges

Value streams can become confused with detailed process maps, losing their value as a high-level, stable view. Keeping detailed process steps in separate models avoids this.

Defining value streams around internal departments rather than stakeholder outcomes recreates the silos they are meant to cross. Each value stream should be named for what the stakeholder receives.

Without links to capabilities, systems and costs, value streams remain diagrams rather than tools for decisions. The links are what make them useful.