The Next Generation of BI Isn’t Another Dashboard
The value of data shows up when it changes what the business does.
I have spent most of my career leading data, analytics and business operations: building the infrastructure and BI, and working with go-to-market, product, finance and operating leaders on what to do with it. Dashboards have been central to that work, and they remain valuable. A good dashboard gives a leadership team a shared picture of the business. Plenty of leadership teams never get one.
Some of that work exists to keep the company informed: the core metrics, defined once and sliced for Finance, the board, investors and the market, and the numbers worth watching week to week. That is table stakes, and getting it right is hard and important.
This piece is about the other kind of BI, the dashboards and analysis that are supposed to change what the business does.
But there is a limitation I have run into again and again.
A dashboard can tell you that retention is declining, that conversion is weakening, or that a segment is underperforming. It does not tell you what to do next. And it certainly does not make sure anyone does it.
I have come to believe that the next generation of BI is not a more sophisticated dashboard. It is BI that connects intelligence to execution.
“So what happens next?”
The question I find myself asking most often when I review analytics work is a simple one: so what happens next?
We identified a customer segment with elevated churn risk. Great. Who is going to act on it?
We found an opportunity to improve conversion. Great. What intervention are we proposing?
We discovered that a sales workflow is underperforming. Great. Who owns the change, and how will we know it worked?
This is not a criticism of analytics. The analysis in each of those cases can be excellent. It is a recognition that insight and outcome are separated by execution, and execution needs things a chart cannot provide: an owner, a priority, a place in someone’s workflow, and a way to measure the result.
The three assumptions inside every dashboard
Every operating dashboard quietly assumes three things.
Someone will look. A dashboard is a pull system. It waits to be opened, and the most important changes are often the ones nobody thought to check. The metric that matters this week is rarely the one at the top of the page.
Someone will interpret. A line going down is not an explanation. Someone has to work out whether the change is real or noise, what is driving it, and whether it matters more than the five other things that moved.
Someone will act. Even a well understood problem needs a person who owns the response, a decision about what that response is, and the time to carry it out.
When all three assumptions hold, dashboards work well. In most organizations, they hold some of the time. Leaders are busy, analysts are stretched, and ownership of a cross-functional problem is often unclear. So the insight lands in a meeting, everyone agrees it matters, and a few weeks later someone asks what happened to it.
That is not a tooling failure. It is a design choice built into how BI has worked for decades: the system’s job ends when the information is displayed.
What the next generation looks like
The alternative is to design for the whole path from signal to result, not just the first step. I think of it as six links in a chain:
- Identify a meaningful signal. Not every movement, just the changes that are unusual for this part of the business, measured against its own normal rather than a fixed threshold.
- Understand why it matters. Explain what is driving the change and what it puts at risk, in the language the business already uses.
- Recommend an intervention. Propose a specific action, with the evidence behind it and a suggested owner, so the recommendation can be weighed and challenged.
- Get it into a workflow. Put the recommendation where work actually happens: the weekly operating review, the team’s queue, the owner’s list. Not a separate tool someone has to remember to check.
- Measure whether it worked. Decide before acting what a good result looks like, then check.
- Feed the learning back. Record what was tried, why, and what happened, so the next decision starts smarter than this one.
Most organizations are strong at the first link and some of the second. The rest of the chain is usually informal. It lives in meetings, inboxes and people’s memories, which means it is invisible, unmeasured and hard to improve.
Where BI usually stops
- 01 Signal A meaningful change, against its own normal
- 02 Why it matters What is driving it, and what it puts at risk
Usually informal
- 03 Recommend A specific action, with evidence and an owner
- 04 Into the workflow Where work already happens
- 05 Measure Against what good was defined to look like
- 06 Learn What was tried, why, and what happened
The value of data is not fully realized when someone understands a problem. It is realized when that understanding changes what the business does.
Why this is becoming practical now
None of this is a new idea. Good operators have always tried to close the loop by hand. What has changed is the cost of doing it at scale.
AI makes several of the hard steps far cheaper. It can watch many more signals than any team could review, and bring forward the few that matter. It can explain a change in plain language and show the data behind the explanation. It can draft a recommendation with its reasoning attached, and it can track whether the action was taken and what happened next.
What it should not do is own the decision. The point of connecting intelligence to execution is not to remove people from the loop. It is to make sure the right person sees the right problem early enough to do something about it, with the evidence in front of them. People decide and people act. The system makes that easier and harder to skip.
What changes for data and BizOps teams
If BI is judged on whether it changes what the business does, the data function changes with it. That does not make reporting less important. Trusted company metrics remain a core deliverable, and nothing below replaces them. The shift is in what gets built on top of them. A few things follow.
Count decisions changed, not just work delivered. Reliable reporting will always be part of how a data team is judged. Alongside it, ask which decisions were made differently, or made earlier, because of the team’s work. That number is harder to count, and it is the one that shows the new value.
Know which reports inform and which should drive action. Board and investor reporting exists to inform, and that is its job. Operating dashboards should drive action, so for each one, name the decision it supports and the person who acts on it. If nobody can, it is a candidate for a redesign or for retirement.
Write down why you expect a recommendation to work. If you intend to measure the result, you have to state the expected effect up front. That habit makes recommendations sharper and makes the reasoning reusable.
Partner with the owner of the action. The most useful analysis is designed together with the person who will act on it, not handed over at the end.
In other words, data and BizOps should not stop at explaining business performance. We should help design the mechanisms that improve it. That changes the nature of the function, and I think it is the most significant opportunity data leaders have had in a long time.
A simple place to start
You do not need a new platform to test this. Pick one dashboard your leadership team looks at every week, choose the metric on it that matters most, and answer four questions:
- What change in this metric should make someone act?
- Who is that someone?
- What would they actually do?
- How would we know whether it worked?
If the answers are clear, you have the design for one closed loop. Build that one, run it for a month, and see what it changes.
If the answers are not clear, you have found something more useful: the exact place where your organization’s data stops short of its decisions.