Insights / Article / Process diagnostics and business process evaluation
ArticleReading process data without a mining tool
Specialist process mining tools help, but much can be learned from simple exports of system data and a spreadsheet. How to find cycle times, the long tail and the gap between data and opinion.
Process mining software has made it possible to reconstruct how work really flows through an organisation from the digital traces left in its systems. The tools are powerful, and for large, complex processes they can be worth the investment. But they take time to set up, need clean data and specialist skills, and come with a cost that is hard to justify before you know what you are looking for.
Specialist tools help, but much can be learned from simple exports of system data. A spreadsheet, a few hours and some curiosity are enough to answer the most important questions about a process: how long it really takes, where the delays are and which cases cause the most trouble.
Export the timestamps
Most systems record when a case was created, changed and closed. These give cycle times.
Whatever the process, whether a customer order, a purchase request, a service ticket, an insurance claim or a job application, the system that manages it almost always records dates and times for key events. At minimum there is usually a creation date and a completion date. Often there are also status changes: submitted, approved, dispatched, invoiced, paid.
- Ask the system owner for an export of all cases closed in the last three to six months, with their unique reference, key attributes such as type, region, customer or value, and every available timestamp.
- Load the export into a spreadsheet and calculate the elapsed time between creation and completion for each case.
- Where status changes are available, calculate the time spent between each pair of steps.
- Summarise the results: the median, the average, and the time taken by the fastest and slowest ten per cent of cases.
The median is usually more useful than the average, because a few very long cases can pull the average up sharply. Comparing the two is itself informative. If the average is much higher than the median, a small number of cases are taking far longer than the rest, which is worth investigating.
Watch the data quality
System timestamps are only as good as the behaviour behind them. If staff update statuses in batches at the end of the day, or close cases without updating intermediate steps, some figures will mislead. Check a few cases by hand against what actually happened before drawing firm conclusions.
Look for the long tail
The slowest ten per cent of cases often hide the biggest causes of delay.
Averages describe the typical case, but problems tend to concentrate in the exceptions. Sort the cases by elapsed time and look closely at the slowest tenth. What do they have in common? Are they a particular type, from a particular region, above a certain value, handled by a particular team, or submitted on a particular day of the week?
Consider a typical business reviewing its supplier invoice process. The median time from receipt to payment might look acceptable. But the slowest cases might turn out to be almost entirely invoices without a purchase order number, which wait in a queue until someone in finance tracks down the right budget holder. That single cause, invisible in the averages, may explain most late payments and most supplier complaints.
- Filter the slowest cases by each attribute in turn and see which values appear far more often than in the full data set.
- Look at the step-by-step timings for slow cases to see where the extra time accumulates.
- Pick five of the slowest cases and trace them manually through the system and with the people involved.
- Check whether slow cases also generate more complaints, rework or contacts.
Count the loops
If the export includes every status change, it can also show rework. Count how many cases pass through the same status more than once, for example being sent back from approval to submission, or reopened after closure. Each loop is a sign of missing information, unclear rules or errors upstream.
Even a rough count is useful. If one case in five is sent back at least once, the cost of rework is probably larger than any single delay in the process. Fixing the cause of the loops, often a missing field or an unclear requirement at the start, can shorten cycle times more than speeding up any one step.
It also helps to check volumes over time. Plot the number of cases opened and closed each week. If openings regularly exceed closures, a backlog is building, and cycle times will rise even if nobody is working more slowly. Many apparent process problems are really capacity problems at particular times of the month or year.
Compare with what people say
Differences between data and opinion are where the learning is.
Before showing anyone the analysis, ask the people who run the process a few questions. How long does a typical case take? Where are the main delays? Which cases cause the most trouble? Write down their answers. Then compare them with the data.
Sometimes the data confirms what people believe, which builds confidence in both. More often there are surprises. A team may believe approvals are the main delay, while the data shows cases waiting longest before anyone picks them up. Managers may believe a process takes a week, while the median is three. Each difference is a prompt for a useful conversation: is the data wrong, or is the belief?
Everyone was certain the delay was in credit checks. The export showed orders sat untouched in a shared inbox for two days before anyone looked at them. That changed the whole discussion.
Finance operations manager, distribution client
When to invest in a tool
Simple analysis has limits. If the process spans several systems, has many variations, or needs continuous monitoring rather than a one-off review, a specialist tool may justify its cost. The spreadsheet analysis then serves as a pilot: it shows where the value lies, which data matters and what questions the tool needs to answer.
To start, choose one process that frustrates customers or staff. Request a three-month export with timestamps, calculate the median and the slowest tenth, and trace five slow cases by hand. Compare the results with what the team believes. You will almost certainly find at least one cause of delay that nobody had named.
Source: Intelliversal analysis.
