Process measurement goes wrong in a predictable way: one number is chosen, it improves, and the cost appears somewhere nobody is counting. Four measures that constrain each other are harder to game and easier to defend.
This guide covers which four, how to define each so two people produce the same figure, and why the gap between elapsed time and working time is usually the most useful thing you will find.
Key takeaways
- Elapsed time, not working time: In most processes the waiting is four fifths of the total, and that ratio redirects the whole conversation.
- Four measures or none: Any single figure can be improved by damaging another, and a speed target met by skipping checks is the common case.
- Define correct before you count: If a defect is only noticed when a customer reports it, your customers are measuring quality for you.
- Rework is the honest one: It is the measure teams leave uncounted and the one that keeps a time target truthful.
Look for the business signal behind the technology
The signal that a process needs measuring is disagreement about how well it works. When two people describe the same process as fine and as broken, neither has a number, and the argument will continue until somebody produces one.
Measurement can also damage a process. A single target applied to work that varies will push people towards the cases that score well, and the difficult work quietly becomes somebody else's problem. That effect appears in the data months after it appears in the team.
Take one case and time it from trigger to outcome, including the waiting. The ratio between elapsed time and working time is usually the finding, and in most processes it is four or five to one.
Use four lenses to understand the opportunity
Time
Record elapsed time from trigger to outcome, including every wait, rather than the time the work takes when somebody is doing it. The gap between those two numbers is the finding, and in most processes the waiting is four fifths of the total.
Quality
Define what counts as correct and who decides. If a defect is only noticed when a customer reports it, quality is being measured by your customers, and the figure you hold is the share of problems that were bad enough to complain about.
Rework
Count how often the same item comes back round and the step it usually returns to. Rework is the measure that keeps a speed target honest, because any process can be made faster by skipping the check that creates the return.
Outcome
State what the process exists to achieve for the customer, in a way that would still make sense if the process changed completely. Without that line, the other three measures can all improve while the thing the customer wanted gets worse.
Assess the current state without buying software first
Time three cases rather than one, including a case that went wrong. A single trace gets dismissed as unrepresentative by anybody who dislikes the conclusion, and the failed case is where the cost actually is.
Decide what useful measurement looks like
Use four measures rather than one: how long it takes, whether it was right, how often it comes back, and what the customer got. Each one constrains the others, and any single figure published alone will be optimised at the expense of the rest.
Give each a definition, a source and an owner, and write down which of them is currently a guess. Teams usually discover that the quality measure is the guess, and that is also the one the others are supposed to protect.
When software is likely to help
Instrumentation is worth building when the measure will be read regularly and acted on. Until then, a tally sheet and a weekly count answer the same question for nothing, and they force the definition arguments to happen before anything is automated.
Automating a measurement nobody has agreed produces a precise figure that two departments interpret differently. The precision makes the disagreement harder to resolve, because both sides now have a system supporting them.
For how these process figures show up in the staff tools themselves, see Why Back-Office User Experience Matters to Customers.
Start with a bounded improvement
Publish the four figures for one process on a single page for a month and watch what moves. Within four weeks you will see whether an improvement in one is being paid for by another, which is the entire reason for measuring four things.
Separate a structural constraint from a temporary problem
Before treating the figure as a problem, check whether it survives different conditions. Does the cycle time look the same in a quiet month, with the full team in, and without the one unusual customer? A number that only appears under load is a capacity question.
Lay the cases out in a grid: routine and exceptional on one axis, busy and quiet on the other. Look at how time, quality, rework and outcome behave in each square. The grid usually shows that one square produces most of the cost and the rest is fine.
If the pattern is structural, state the target so it can be missed: this step will complete within two days for this case type by the end of the quarter. A target that cannot be missed will be reported as met every month whatever happens.
Risks to make visible
| Lens | Common risk | Early response |
|---|---|---|
| Time | Only working time is measured | Record elapsed time including the queues, for three cases rather than one. |
| Quality | Correct is defined after the fact | Agree what good looks like, and who decides, before the first figure is published. |
| Rework | Returns go uncounted | Count how often the same case comes back and to which step, every week. |
| Outcome | The customer result is missing | State what the process exists to achieve and measure that alongside the rest. |
A 30-day validation plan: Business process metrics
Days 1 to 5: time one case properly. Follow a single case from trigger to outcome and record the clock time at every step, including the hours it sat in a queue. Most teams discover the working time is a small fraction of the elapsed time, and that ratio is the finding that changes where the improvement effort goes. Do it for three cases rather than one, because a single trace is easily dismissed as the unusual example by anyone who dislikes the finding.
Days 6 to 15: define what correct means. Write down what a good outcome looks like for this process and who decides. Then count how often the same case comes back round and which step it returns to. Rework is the metric that keeps the time target honest, and it is the one teams most often leave uncounted. Check whether the returning cases share a cause, since a scattered set of one-off errors needs different treatment from a single broken rule.
Days 16 to 30: publish all four and watch what moves. Put time, quality, rework and outcome on one page and show them weekly. Within a month you will see whether an improvement in one is being paid for by another. That is the whole purpose of measuring four things rather than the single number someone asked for. Keep the page to one side of paper, as a longer report gets read once and a single page gets argued about every week.
A practical worksheet: Business process metrics
Process metrics go wrong when one of them is chosen and the others are left to drift. Pick a single process and fill all four rows, because the point of the set is that they constrain each other.
| Decision area | What to record |
|---|---|
| Time | Elapsed time from trigger to outcome including every wait, not the time the work takes when someone is doing it |
| Quality | What counts as correct, who decides, and how a defect is noticed if the customer does not report it |
| Rework | How often the same item comes back round, and the step it usually returns to |
| Outcome | What the process exists to achieve for the customer, stated in a way that would still make sense if the process changed completely |
| Measurement | Where each of the four numbers comes from, and which of them is currently a guess |
Any single metric can be improved by damaging another one, and a time target met by skipping checks is the common example. Publish the four together or publish none, so improvement has to be real rather than moved.
Related guides
- The measurement side of it is covered in Admin Dashboard Development: Features, Architecture, and Cost Drivers.
- A related mistake worth avoiding is described in Operational Dashboard: KPIs, Examples, and Design.
Should Business Process Metrics: What to Measure and Why lead to the operations tooling your team keeps asking for, Discuss Your Operations Platform.
Ali Boran Gazel