Insights / Guide / Process diagnostics and business process evaluation
GuideProcess diagnostics and evaluation: the complete guide
Most organisations know something is slow or costly but cannot say exactly where. How to map how work really flows, measure it and decide what to fix first.
Most organisations know something is slow or costly but cannot say exactly where. Orders take too long to ship, month-end close drags on, customers complain about being passed between departments. Everyone has a theory, and the theories rarely agree. Without facts, improvement efforts either stall in debate or chase the most visible symptom rather than the real cause.
A process diagnostic replaces opinion with evidence. It maps how work really flows, measures it, and shows the bottlenecks, duplication and control gaps worth fixing first. This guide brings together the briefings in our process series and sets out a practical approach any organisation can follow, with or without specialist tools.
Documented is not actual
Written procedures describe how work should happen. Observation shows how it does. The two often differ, sometimes dramatically. People develop workarounds for system limitations, skip steps that seem pointless and add checks after a past mistake. Over the years, the real process drifts away from the manual, and nobody updates the manual.
That is why a diagnostic begins with reality, not documents. Sit with the people doing the work and watch several real cases from start to finish. Ask what they do when something goes wrong, because exceptions reveal the real rules. Once you know what actually happens, you can decide whether to fix the document or the practice, and be honest about which.
Map the real process in a day
Process mapping does not need weeks of interviews. A focused session with the right people can reveal most of the issues in a single day, provided you include those who do the work at each step, not just their managers. Frontline staff know the workarounds, the waits and the rework that managers often never see.
- Choose one process and define where it starts and ends, for example from customer order to cash received.
- Gather one or two people from each step, plus someone who can approve changes.
- Follow a real, recent case from trigger to completion on a wall or whiteboard.
- Record every step, handoff, system, wait and point where work is checked or redone.
- Mark the pain points: steps that cause delay, error or frustration.
- Agree the top five pain points before anyone leaves the room.
Handoffs hide the delay
In most processes the work itself takes minutes or hours; the waiting between teams takes days. When you map, pay as much attention to the gaps between boxes as to the boxes themselves.
Measure with data
Mapping shows the shape of a process; data shows its performance. Use system data to measure volumes, cycle times, rework and exceptions, and to find patterns that interviews miss. People stop noticing problems they live with every day, but system logs do not.
Specialist process-mining tools help, but much can be learned from simple exports. Most systems record when a case was created, changed and closed. Exporting those timestamps into a spreadsheet gives cycle times for each step and for the process as a whole.
Be careful with the data, too. Timestamps are only as good as the habits behind them. If staff close cases in batches at the end of the week, or reopen old records instead of creating new ones, the numbers will mislead. Spend an hour with someone who uses the system daily to understand what each date really means before drawing conclusions from it.
- Look at the distribution, not just the average. The slowest ten per cent of cases often hide the biggest causes of delay.
- Count how often cases go backwards, for example an invoice returned for correction.
- Measure the share of cases handled as exceptions rather than through the standard path.
- Compare what the data shows with what people said in the mapping session. The differences are where the learning is.
Review controls at the handoffs
A diagnostic should check controls as well as efficiency: approvals, segregation of duties and exposure to errors and fraud. Many control failures occur not inside a step but between steps, where responsibility passes from one person, team or system to another.
List every point where work changes hands or systems. At each one, ask what is checked, by whom and how it is recorded. A typical example is a purchase order approved in one system and a supplier invoice paid from another, with nobody confirming that the goods actually arrived. Simple checks, clear ownership and basic records close most of these gaps at little cost.
Benchmarking helps put the findings in context. Score each process against good practice on a simple maturity scale, covering standardisation, measurement, control and ownership. The scores show where the gap between today and good practice is largest, which is often a better guide to priority than the loudest complaint.
Know when a process needs redesigning
Some processes can be tuned; others need a fresh design. Tuning works when the basic flow is sound and the problems are local, such as a missing check or a slow approval. Redesign is needed when the flow itself is the problem.
- Handoffs keep growing as the process crosses more teams.
- People keep hidden spreadsheets and side emails to get work done.
- Nobody owns the result end to end.
- Exceptions outnumber standard cases.
- Cycle times vary wildly for similar cases.
- The same data is entered into several systems.
- Customers have to chase to find out where their request is.
If three or more of these apply, small fixes are unlikely to be enough, and an end-to-end redesign deserves serious consideration.
Prioritise the opportunities
A good diagnostic ends with a ranked list, not a long report. Rank each improvement by value, effort and risk, and agree with the process owner where to start. Quick wins with clear value build momentum and credibility for the larger changes that follow.
Keep the list honest about effort. Improvements that depend on another team, a system change or a policy decision by the board will take longer than those the process owner can make alone. Showing who needs to act on each item, and by when, turns the list from a wish list into a plan that can be tracked at the next monthly review.
Remember that not every problem needs a system. Many of the most valuable fixes are policy or ownership changes that cost little: removing an unnecessary approval, naming a single owner for a process, agreeing a standard for how a form is completed. Technology investments make more sense once the process is clean and stable.
We were about to buy a new system to fix our order delays. The diagnostic showed most of the delay was a credit check that waited for one person’s sign-off. We changed the limit and the problem largely went away.
Finance director, wholesale client
Done well, a diagnostic leaves you with a factual baseline of how each process performs, a ranked list of what to fix first, control gaps seen and owned, and a shared language across teams for how the process works. Start with the process customers or finance complain about most, run a one-day mapping session next month, and export the timestamps from the main system that supports it.
Source: Intelliversal analysis, drawing on the briefings in this series.
