Home / Knowledge centre / Analyze

Analyze · Teaching guide

Input–process–output measurement matrix

Connect outcomes, process behavior, and candidate inputs with operational measurement definitions.

Read the method, follow the developed example, and examine the assumptions and decisions before applying the tool.

01 · Mechanics and boundaries

Mechanics and boundaries

An input–process–output measurement matrix links what enters a process, what happens inside it, and what the process delivers. It prevents a common analytical error: measuring only the final result and then guessing which internal condition produced it. Inputs may include order size, stock availability, and release timing. Process measures include waiting, resource availability, and first-pass completion. Outputs include correct parcels and handover within the promised interval.

A variable's role depends on the boundary. Packed parcels are an output of packing and an input to loading. A candidate input is not automatically a controllable cause. Order complexity may be a demand characteristic; release batch size may be adjustable; customer address accuracy may require an upstream agreement.

02 · Construct the analysis

Construct the analysis

Start with the customer outcome and define it operationally. Work backward through the observed route to identify process measures that could explain that outcome. Then identify inputs whose variation could change those process measures. For every variable specify unit, event boundary, source, sampling approach, owner, and interpretation. Distinguish an order-level measure from a shift-level measure.

Build only the links relevant to a decision. “Late handover” connects plausibly to pick waiting and stock holds; staff birthdays do not warrant collection. Separate prospective hypotheses from established relationships. Verify data availability and measurement agreement before commissioning a large extract. A matrix with precise definitions and a small reliable sample is more useful than dozens of weak indicators.

03 · Worked warehouse-dispatch example

Worked warehouse-dispatch example

The fictional North Quay warehouse dispatches a single parcel-order family. Its boundary starts when an order is accepted for release and ends at confirmed carrier handover. Demand is 240 orders in a 420-minute net working day. Each order contains three lines on average, but the example keeps the parcel order as the unit of flow. No number below describes a real organization or a demonstrated improvement. The purpose is to make the reasoning traceable rather than to present a success story.

A representative order spends 12 minutes awaiting release, 2 minutes being released, 18 minutes awaiting picking, 8 minutes being picked, 24 minutes awaiting packing, 5 minutes being packed, 10 minutes awaiting checking, 2 minutes being checked, 15 minutes awaiting loading, and 3 minutes being loaded. These mutually exclusive intervals total 99 minutes: 20 minutes of processing and 79 minutes of waiting. They describe one complete normal-route trace, not a statistically estimated mean for every order. A separate 100-order diagnostic sample contains 20 late orders, defined as handover more than 120 minutes after acceptance. The normal trace and late-order sample therefore answer different questions.

Three pickers, three packers, two checkers, and two loaders work in parallel within their respective stages. At the illustrated processing times, theoretical stage capacities are 157.5, 252, 420, and 280 orders per day. Picking is below the 240-order requirement even before interruptions or rework. Release has two staff and a theoretical capacity of 420. These capacities assume dedicated resources, identical order mix, and no overlapping assignments. They are not observed outputs and should never be reported as effective capacity.

The matrix defines output lateness as handover beyond 120 minutes after acceptance. The process measure pick waiting starts after release completion and ends at first picking action. The input stock hold is a yes/no event with a reason code and start/end timestamps. Line count is retained to check whether complex orders confound the association.

For 100 orders, 20 are late; 12 have replenishment holds and 8 of those are late. The matrix therefore enables a comparison between 8/12 and 12/88, while preserving line count and release time for a fairer analysis. It also identifies that a printer event log cannot substitute for physical loading completion. A missing handover timestamp must be investigated, not coded as an on-time order.

RoleMeasureDefinition
InputLine countLines required at acceptance
InputReplenishment holdRecorded start and end of stock wait
ProcessPick waitingRelease complete to picking start
OutputLate orderHandover elapsed time exceeds 120 min

04 · Interpretation and decisions

Interpretation and decisions

Use the matrix to detect missing links in the explanation. If only stock-hold counts and daily late totals exist, order-level association cannot be calculated reliably. Matching orders across records may become the first analytical task. If two observers disagree on when picking starts, improve the definition before comparing picker performance.

A weak matrix labels “speed” as a process measure and “satisfaction” as an output without units or collection rules. A sound matrix states the exact interval and outcome threshold, documents exceptions, and distinguishes missing from zero. Review whether a measure encourages harmful behavior: counting releases alone may reward flooding a stage that already lacks capacity.

05 · Sound application and adaptations

Sound application and adaptations

Add contextual columns for route, order complexity, shift, equipment state, and relevant changes. For repeated events, store an event-level child record rather than overwriting the first hold with the last. This supports both total hold duration and number of interruptions without losing sequence.

The matrix is a measurement design aid, not a causal model or control dashboard by itself. Avoid treating every recorded input as a lever. For advanced work, draw hypothesized links and identify common causes before regression or experiments. Monitor data completeness over time; apparent improvement can come from a changed logging rule. Retire measures that no longer support a decision and maintain definitions for the ones that do.

06 · Evidence and follow-through

Evidence and follow-through

Make the observation auditable before debating a countermeasure. Preserve an anonymous order identifier, acceptance and handover timestamps, route, line count, shift, exception flag, and the observer's definitions. A timestamp from a completed screen action may describe data entry rather than physical completion. Reconcile several records with direct observation and ask the person doing the work what each event actually means. Keep an uncertainty note when clocks differ or two actions overlap; rounding cannot repair an ambiguous boundary.

Observe ordinary work and exceptions over a period that includes opening, replenishment, breaks, and the carrier cutoff. Selecting only easily followed orders produces a clean-looking but biased picture. When an order is unfinished at observation end, keep it visible as unfinished rather than silently deleting it. For multi-line orders, establish whether timing ends at the first line or the complete order. Include all three lines in the latter case, because the customer receives the order only after its final requirement is satisfied.

Turn the analysis into a bounded decision. Describe the proposed change, the mechanism expected to alter performance, the measure that would detect the change, and the conditions under which it would be withdrawn. A small layout change might reduce walking yet increase congestion; an extra release wave might lower one queue yet overload picking. Monitor handover performance, first-pass accuracy, work in process, and staff workload together. Treat the proposed numbers as planning assumptions until a comparable observation period supplies evidence.

07 · Boundary and robustness review

Boundary and robustness review

Before implementing the selected countermeasure, check the boundary one more time. If the analysis starts after order release, an upstream acceptance hold is outside its measured lead time even though the customer experiences it. If the analysis ends at the loading bay, a parcel waiting for the carrier is still incomplete within the stated dispatch outcome. Keep those events inside the customer-facing boundary, or state exactly why a narrower operational measure is also being used.

Assess robustness across normal variation. A proposed operating rule should specify what happens when an urgent order arrives, stock is unavailable, a staff member is absent, or the carrier changes collection time. Those conditions do not invalidate the main analysis; they define where its assumptions need adaptation. Rehearse an exception through the proposed route with the people responsible for each decision. Record which assumptions remain unverified and what evidence would be sufficient to proceed.

Finish with an explicit learning statement: what the evidence currently supports, what it does not establish, and which observation is needed next. A quantified hypothesis can be useful without becoming a guaranteed result. Retain the current-state observations so a later comparison can use the same event definitions and population. When the observed outcome differs from the prediction, revisit the mechanism and resource assumptions rather than adjusting the target after the fact.

Connections

Related methods and phase use

Placed under Analyze because of the outcome it supports. Use the method in other phases when its purpose and assumptions fit the work; the phase list is a guide to selection, not a compulsory sequence.

Sources

Professional foundations and further reading

The explanation and fictional teaching examples are written for LeanTrainingLab. Linked primary sources provide professional foundations; example values and local conventions are stated in the guide. The accepted toolset draws on Six Sigma+Lean Toolset, second edition (Lunau, editor; Springer, 2013). No book text or examples are reproduced here.