The order-to-cash dashboard is green. Average days to ship: 2.9, comfortably inside the two-day-plus-one target that was agreed last year. On-time delivery: 91 per cent. The weekly volume chart is steady. Every tile is the colour it is supposed to be.
And the customer-service team is still fielding the same complaint every week: orders promised in two days arriving in five.
Both are true. The dashboard is not wrong; it is answering a different question from the one the complaints are about. It is built to say how much and how fast on average. The complaints are about how some orders travel through the process, and why those ones are late. That question lives in data the dashboard was never designed to read.
This article is about that gap: what a dashboard can see, what it structurally cannot, why, and how to close it without throwing out the BI estate you have already built.
What a dashboard is built to answer
Business intelligence is very good at one kind of question. How many orders shipped last week? What was revenue by region? Which products are below margin? What is the average cycle time, and is it moving?
All of these are questions about the state of records. An order has a value, a customer, a region, a status and a set of dates. The data model behind the dashboard, whether it lives in Power BI, SAP Analytics Cloud or anything else, is a set of tables describing those records, joined and aggregated. Counting them, summing them and averaging them is what the model is for, and modern BI does it extremely well.
The limitation is in the word state. A record describes where something is, or where it ended up. It does not describe the route it took to get there.
Four things a dashboard cannot see
Loops. Order 20471 went through credit check twice: once on Monday, when it was held against a stale limit, and again on Wednesday, when someone noticed and released it. The order record shows one credit-check date, usually the last one, and a final status of approved. The first pass, the hold and the two days in between are not in the record at all. Rework is invisible to a model that stores one row per order.
Waiting. Most of the time a case spends in a process is not spent being worked on. It is spent waiting: in a queue, between two systems, for a person in another team to pick it up. Time in queue is rarely a field in any table. A dashboard can show that orders took 2.9 days on average; it cannot show that 1.8 of those days were spent sitting between the warehouse system and the carrier booking, because nobody ever wrote “waiting” into a column.
Variants. The average is a single number describing many different journeys. In a typical order-to-cash process, most orders take the designed path and a significant minority take one of a dozen others. If 69 per cent of orders ship in under two days and 31 per cent loop through credit check and take five, the average can still look healthy, and it will hide exactly the orders the complaints are about.
Deviations. A dashboard can tell you how many orders were approved. It cannot tell you how many were approved without the required second check, shipped before credit was cleared, or invoiced before delivery was confirmed. Conformance is a property of the sequence, and the sequence is not in the record.
Why it cannot see them
The reason is not the BI tool. It is the shape of the data underneath it.
A dashboard reads entities: one row per order, per invoice, per customer, with the current value of each attribute. When the status changes from held to approved, the row is updated and the old value is gone. That is the right design for reporting how much and how many, and it is the wrong design for reconstructing what happened.
Process intelligence reads events: one row per thing that happened to a case, with a timestamp. Order 20471 has six rows, not one: received, credit check, credit check again, approved, picked and packed, shipped. From those six rows the loop, the wait and the variant are simply visible, because the history was never overwritten.
Both come from the same source systems. The event history is usually already there, in the audit or change-history tables that ERP, CRM and workflow tools keep for their own purposes; we covered where it hides in what your event log needs before process mining will work. The dashboard simply reads the other table.
The same orders, two ways
Put the two views side by side on the same quarter of orders and the difference stops being abstract.
The dashboard says: 2.9 days average to ship, 91 per cent on time, volume steady.
The process view of the same orders says: 31 per cent of orders pass through credit check twice. Those orders take a median 2.4 days longer. They account for most of the late deliveries. And the second credit check is triggered almost entirely by high-value orders from one sales channel, where the first check runs against a limit that is refreshed weekly instead of daily.
The second view does not contradict the first. It explains it. The 9 per cent of late orders are not random; they are mostly the loop. And the fix is not “speed up fulfilment” or “add warehouse staff”, which is what the dashboard alone would suggest. It is “refresh the credit limit for that channel daily”, which the dashboard could never have pointed to.
Not either/or: put both on one screen
The conclusion is not that dashboards are the wrong tool. They are the right tool for the question they answer, and most organisations have years of investment in them. The goal is to give them the one thing they lack.
Bring process attributes into the semantic model. Once the event log has been mined, every case can carry a handful of new attributes: which variant it followed, whether it was reworked, how long it waited and where, whether it deviated from the designed path. These are ordinary columns. They can be added to the same semantic model the dashboards already read, alongside region, product and customer.
Then the dashboard can see the bottleneck. On-time delivery by variant. Revenue at risk from reworked orders. Average wait time between warehouse and carrier, by site. The tiles people already trust start carrying the process insight, and nobody has to learn a new tool to see it.
Keep the process view for diagnosis. The process map stays where analysts and process owners investigate why: drilling into a variant, following individual cases, testing a change. The dashboard says where to look; the process view says what to fix.
This is the pattern we use when a client already has a mature BI estate and wants process intelligence without a second reporting world. It works because the two were always reading the same systems; they just needed to be reading the same model.
Five signs your dashboard is hiding a process problem
- The averages are green and the complaints have not changed.
- Two teams each report their part of the process as on target, and the end-to-end result is still late.
- “Rework”, “re-submission” or “exception” are words people use daily, and none of them is a measure on any dashboard.
- Every improvement initiative starts with a workshop to find out how the process actually works.
- Someone has built a spreadsheet that tracks a subset of cases by hand, because that is the only way to follow them end to end.
Any two of those, and the problem is probably not the dashboard. It is that nobody is reading the event history.
Where to start
The first step is the same one every time: check that the event history exists and is usable. The readiness check takes five questions and a minute. If the answer is yes, a two-week pilot mines one process from your real data and shows you, on day ten, the loops and waits your dashboard has been averaging away, with the attributes ready to add to the model your teams already use.