I’ve seen — and built — BI dashboards that looked impressive in a demo and were ignored within a month of launch. The data was accurate. The visualisations were clean. The stakeholders had asked for them. So why did no one use them?
The answer, almost every time, was the same: the dashboard was built around the data that existed, not around the decisions that needed to be made.
The Decision-First Approach
Before writing a single DAX formula or building a data model, I now start every BI project with a process mapping session. Specifically, I want to answer three questions:
- What decision does this metric inform? Not “what does this number mean”, but “what action changes based on this number being high vs. low?”
- Who makes that decision, and when? A metric that informs a weekly planning meeting needs different latency than one used in a real-time operational dashboard.
- What does “good” look like? Surprising how rarely this is defined before a dashboard is built.
This sounds obvious. It almost never happens in practice.
At Rhyton Home
When I joined, there were several existing reports — mostly Excel sheets updated manually each week. The data covered sales, inventory levels, and customer acquisition. The problem was that these reports described what happened, but gave no clear signal for what to do next.
I spent the first two weeks mapping the actual decision workflows: how the sales team decided which products to promote, how inventory reorder decisions were made, how marketing spend was allocated. This revealed that most decisions relied on intuition because the data wasn’t structured to support them.
The dashboards I then built were much simpler than the original reports — fewer metrics, tighter focus, but each KPI was directly connected to an action someone actually needed to take. Usage went up, and more importantly, decisions that previously took a weekly meeting to make could be made in real time.
BPMN as a BI Tool
I’ve started using BPMN (Business Process Model and Notation) diagrams not just for process documentation, but as a design input for BI work. Mapping the process first shows you exactly where information gaps exist — where a human has to make a decision without data, or where data is collected but never flows to the person who needs it.
Those gaps become your dashboard requirements. Everything else is noise.
If you’re building a BI solution and it’s not grounded in a documented workflow, I’d suggest pausing before writing any more queries. Let’s talk about it →