Process mining or BI: what a dashboard will never show you

The question comes up in every first meeting: we already have dashboards, so what does process mining add? The answer lies in the shape of the data you look at, not in the colour of the charts.

BI aggregates states: an outstanding balance at a given date, revenue by month, a scrap rate by line. Process mining reads timestamped sequences of events and rebuilds the actual path of every case, end to end. One counts, the other narrates.

What an indicator does not say

An average handling time of eleven days tells you neither where those eleven days go, nor how many cases pass through the same step twice, nor whether the delay comes from the team receiving or the team sending. You know there is a problem; you do not know where to put your hand.

• Rework loops: a case that returns three times to the same desk counts as one case in BI.
• Waiting: time spent between two steps sits in no table, it is derived from timestamps.
• Rare paths: four percent of cases taking thirty percent of the time, invisible in an average.
• Handovers between teams, which are data nowhere and are read from the sequence of resources.

What a process graph does not say either

The reverse holds. Process mining does not replace margin tracking, sales management or regulatory reporting. It describes a sequence, not financial performance. Trying to force everything into a process graph produces an unreadable map that serves no one.

Why both in the same tool

Because they read the same sources. The event log feeding the process analysis comes out of the same tables as the indicators. Splitting the two tools means maintaining the same connections twice, the same read permissions twice, and finding out one day that the two do not count the same thing.

The reading order does matter, though: start with the graph to find where time is lost, then open a dashboard to put a number on the gap you found.