Reading processes from system data: where it snags

Anyone recording a process asks the people involved first - and gets an honest but incomplete answer. People describe the workflow as it is meant to be: order comes in, gets checked, approved, delivered, invoiced. What they systematically leave out are the exceptions that have become so ordinary they no longer register. The rush order pushed forward by phone. The query to accounting that leaves a case waiting for two days. The approval that is regularly withdrawn and reissued. These patterns belong to the daily routine, but not to the story people tell about it.

The fault is not bad faith but the way memory works. The standard case is present because it is frequent; the special case is suppressed because it is uncomfortable. A flowchart drawn from such conversations therefore shows the main path in high resolution and the deviations not at all. Yet the deviations are exactly what makes a process slow, expensive and error-prone. Surveys regularly name a lack of process transparency as one of the biggest obstacles to automation; the Deloitte study on the subject lists process transparency at 51 percent (Deloitte) as the main benefit of process mining, ahead of ongoing process monitoring at 41 percent (Deloitte).

There is also the effort. A thorough interview-based recording ties up people from several departments over weeks - and digitisation in mid-size companies most often fails for lack of time anyway: 60 percent (Bitkom) of firms name it as an obstacle, alongside 74 percent (Bitkom) citing the skills shortage. Building the recording instead from data the systems already produce saves exactly that time. That is the core of what the term process mining covers - and the reason Gartner expects 25 percent (Gartner) of organisations worldwide to use such methods by 2026.

Once the workflow is built from data, three kinds of pattern emerge that a drawn diagram never contains. The first is loops and rework: cases that pass through a step more than once. An approval that gets withdrawn. An invoice that is cancelled and reissued. A check that becomes necessary a second time because a detail was missing. Every loop is duplicate work, and its frequency can be quantified exactly. In the example log, the share of orders checked twice sits at around a fifth - not a law of nature, but a hint of a missing detail earlier in the workflow.

The second pattern is special paths and variants. The described process knows one path; the lived one often knows dozens. Orders that skip the credit check because they are flagged urgent. Receipts posted directly, past the approval. Customers created without a customer number. Each variant on its own may be rare, but together they make up a substantial share - and they are precisely what stops a workflow from being automated as long as nobody knows about them. Anyone wanting to know which processes to tackle first will find a good initial filter in the number of variants.

The third pattern is waiting times. Between two timestamps sits the wait, and it is almost always longer than the actual work. A receipt is posted in seconds but sits three days in the inbox first. An order is picked in minutes but waits half a day for approval. These gaps can be calculated straight from the timestamps. They are the fastest route to noticeable improvements because they need no new software - the same logic sits behind the idea of shortening lead times through the waiting time rather than through faster processing.

The value of the method shows most clearly in comparison. Both routes produce a picture of the workflow, but they differ in what you can rely on. The following comparison sums up where the data-based recording holds and where the conversation is still needed - because one does not replace the other, it complements it.

The blind spot of data analysis deserves special attention: it only sees what is in a system. If part of the workflow is handled by a quick word, on paper or in a private spreadsheet, it does not appear in the log - and the workflow looks faster than it is. Exactly these breaks between system and manual work are a topic of their own; how to find them systematically is shown in the article on media breaks in your company. Data analysis reveals them indirectly, because where the manual work sits, an unexplained gap opens up in the timeline.

An analysis that ends in a report has not earned its keep. The point lies in the decisions it enables - and those usually fall into one of four directions. A loop is removed by asking for the missing detail earlier. A waiting time is shortened by allowing an approval to pass to a deputy. A media break is closed by connecting two systems through an interface. Or a recurring, cleanly running step is automated, because the analysis shows it runs without variants.

The last point is the real advantage of the method over the interview: it is repeatable. The same analysis, re-run a quarter later, shows whether a measure worked - without a new round of meetings. That turns a one-off recording into an ongoing check, which can be carried over into a regular metrics and reporting routine. Whether an automation pays off at all then no longer hangs on a gut feeling but on measured figures; the calculation behind it is described in the article on bottlenecks in order processing.