A Value Stream Can Fail Like an Asset

A pump usually announces a serious failure.

An alarm sounds. A trip occurs. Production changes. Someone owns the response.

A value stream often fails more quietly.

People are busy. Meetings continue. Materials move. Approvals are chased. Data is re-entered. Workarounds keep the system moving. Every function may appear active while the customer promise becomes less predictable.

Lead time grows. Handoffs become uncertain. Rework returns. Problems are discovered later than they should be.

The system has not stopped completely.

It has lost its ability to flow reliably.

That raises a useful question: can the reliability, availability, and maintainability lens normally applied to assets help us see a value stream differently?

I believe it can—provided we use it as a diagnostic analogy, not as a direct transfer of asset calculations into business processes.

The point is not to calculate the mean time between failures of an approval chain. The point is to ask three disciplined questions:

1. Can the value stream perform its required function consistently?
2. Are the conditions required for flow available at the moment of need?
3. When flow breaks, can the system recover quickly—and preserve the learning?

Those questions can expose weaknesses that a static process map or a monthly average may leave hidden.

A system is more than equipment

NASA defines reliability around a system performing its intended function under stated conditions and over its intended life. NASA systems-engineering guidance also treats a system as a combination of interacting elements that may include hardware, software, people, communications, support, and operations.¹

That matters because a value stream is also a system.

It combines work, information, decisions, resources, technology, responsibilities, and handoffs to produce an outcome for a customer. Rother and Shook’s value-stream approach makes that end-to-end material and information flow visible rather than treating each process step as an isolated unit.²

The translation is useful, but it needs clear boundaries.

This is a management lens—not a claim that process flow and physical assets are technically identical.

Three complementary books deepen this bridge without turning the analogy into a formula. Tortorella anchors customer-focused, verifiable reliability and maintainability requirements. Hopp and Spearman explain how variability, queues, capacity, and control shape flow. Rother and Shook connect those system conditions to end-to-end value-stream practice.²³⁴

A fast process can still be unreliable

Many improvement efforts begin with average speed.

How long does the process take? Where is the longest queue? Which activity consumes the most time? What can be removed, combined, simplified, or automated?

Those are useful questions.

But averages can hide instability.

A process may complete most orders quickly while a smaller group repeatedly becomes trapped in missing information, unclear ownership, late decisions, or rework loops. The average looks acceptable. The customer experience does not.

A maintenance-planning process may issue many work packages on time, yet the packages reaching the field may not be consistently executable. A project-control process may produce reports on schedule while decisions still arrive too late to protect the work. A procurement process may meet an average cycle-time target while urgent items repeatedly require expediting.

In each case, the value stream is operating.

It is simply not dependable.

A reliability lens asks more than, “How fast is the process?” It asks:

Under the real conditions in which this work operates, can the system be trusted to deliver the required result repeatedly?

That moves the conversation from average performance to the pattern of failure.

Availability is lost when the conditions are not ready

For repairable systems, availability reflects both how often failure occurs and how quickly function can be restored.¹

For a value stream, the useful analogy is flow readiness.

The work arrives, but an input is missing.

The technician is ready, but the equipment has not been released.

The material is present, but the specification is wrong.

The analysis is complete, but the decision-maker is unavailable.

The permit exists, but the isolation does not.

The next process has capacity, but not the information required to act.

These are not formal RAM calculations. They are practical signs that the complete set of execution conditions is not available when the value stream needs to move.

The loss often becomes visible at the point of work, but the mechanism may sit several handoffs upstream.

Operations science reaches a similar conclusion from a different direction: variability, queues, capacity, and control interact across the system, so a delay visible at one step may be created elsewhere in the flow.³

Availability, in this adapted sense, means more than whether a person or machine is present.

It means whether the whole set of conditions for execution is ready at the moment of need.

Maintainability is more than a workaround

Organizations are often good at recovery.

An experienced supervisor finds a workaround. A planner calls a supplier. An engineer answers an urgent question. A manager approves an exception. A high performer carries the missing knowledge in their head.

The work moves again.

That can look like resilience. Sometimes it is.

But repeated heroic recovery can also hide a value stream that is difficult to restore and maintain.

For this diagnostic analogy, maintainability should mean more than restarting work. It should include:

• detecting the abnormal condition early;
• making recovery ownership clear;
• identifying and testing the failure mechanism;
• restoring expected flow;
• verifying that the condition changed;
• updating the standard, design, or management routine so the learning remains.

The distinction matters:

Recovery returns the process to operation. Improvement reduces the likelihood or consequence of recurrence.

Without the second step, the organization becomes very efficient at repairing yesterday’s system.

A value-stream map is the starting point—not the control system

Rother and Shook use value-stream mapping to make the complete material and information flow visible and to connect the current state to a practical future-state plan.²

That is already close to a reliability conversation.

The gap appears when the map is treated as a workshop artifact rather than a living management model.

A current-state map captures a condition at a point in time. The value stream then returns to a changing environment: demand shifts, equipment degrades, people move, priorities compete, information quality varies, and new work enters the system.

The future state will not sustain itself because the arrows looked good on the wall.

The organization needs a way to see when flow is beginning to fail—and a disciplined path from detection to verified recovery.

The value-stream reliability evidence loop

The visual model uses eight connected steps.

1. Customer promise

Start with the result the customer depends on.

What must be delivered? To whom? At what quality, timing, volume, and condition?

2. Required function

Translate the promise into an operational function the complete value stream must perform.

Without a clear required function, reliability becomes a vague feeling rather than something the organization can observe.

3. Functional failure

Define the condition in which the value stream does not perform the required function—or performs it in a degraded, intermittent, or unpredictable way.

Failure does not need to mean complete stoppage.

4. Failure pattern

See how the failure becomes visible.

Where does work wait? Which handoff repeatedly breaks? Under which demand, staffing, priority, or operating conditions does the pattern appear?

The visible delay identifies where to investigate. It does not automatically explain why the system failed.

5. Operating conditions

Examine the conditions surrounding the pattern:

• information quality;
• workload and queues;
• capacity;
• access and readiness;
• decision rights;
• standards;
• interfaces;
• competing priorities;
• management routines.

6. Cause testing

A delay is not automatically a root cause.

Neither is “communication,” “planning,” or “lack of accountability.” Those labels often describe the location of frustration rather than the mechanism producing it.

Test competing cause hypotheses against evidence before selecting the preferred response.

7. Control or redesign

Match the action to the problem.

Contain an immediate disruption where necessary. Correct a local defect when the relationship is clear. Escalate a cross-functional constraint. Redesign an interface when the weakness is systemic. Adapt the operating approach when uncertainty is genuinely high.

8. Verified recovery and learning

Do not close the action because the meeting occurred, the procedure changed, or the task was marked complete.

Look for evidence:

• Did the abnormal condition change?
• Did the value stream recover faster?
• Did first-pass quality improve?
• Did the blocked-work pattern reduce?
• Did the workaround disappear—or merely move?
• Can the team now detect and respond without depending on the same hero?

Verification turns activity into learning and strengthens future performance.

Daily management should follow the health of the flow

This reliability lens also changes daily management.

Many daily meetings are organized vertically: operations reviews operations, maintenance reviews maintenance, supply reviews supply, and engineering reviews engineering.

The value stream moves horizontally across all of them.

Daily management therefore needs two views at the same time:

• vertical accountability for the work each team controls;
• horizontal visibility for the conditions affecting end-to-end flow.

The purpose is not to bring every function into one enormous meeting. It is to make handoff failures, blocked conditions, and recovery ownership visible at the right tier before they become monthly results.

A refinery, mine, manufacturing plant, project organization, or service operation will use different signals. The principle is the same:

Manage the conditions that make reliable flow possible—not only the lagging result after reliability has already been lost.

Three questions worth taking to the gemba

Reliability

• What outcome must this value stream deliver consistently?
• Under which conditions does performance become unstable?
• Which failure patterns repeat even after actions are closed?

Availability

• What must be ready at the exact moment the work needs to move?
• Where are material, information, access, capacity, or decisions repeatedly unavailable?
• Which handoff makes the customer wait without making the delay visible?

Maintainability

• When flow breaks, who can restore it and through what route?
• How long does recovery take, and what makes it difficult?
• What evidence shows that recovery addressed the mechanism rather than only the symptom?

Those questions do not replace a value-stream map, RAM analysis, root-cause method, or daily-management system.

They connect them.

The deeper opportunity

A value stream can be fast on average and still unreliable.

It can be fully staffed and still unavailable.

It can recover repeatedly and still be difficult to maintain.

That is why the most useful question is not only:

“How quickly does work move?”

It is also:

“Can this system be trusted to deliver, recover, and learn under the conditions in which it actually operates?”

RAM thinking brings discipline to function, failure, readiness, and recovery.

Value-stream thinking makes material and information flow visible across organizational boundaries.

Daily management keeps changing conditions in view.

Problem solving tests why the failure occurs and whether the countermeasure changed it.

Used together, they offer a stronger way to manage industrial flow—not as a one-time map, but as a living system whose health can be seen, restored, and improved.