All posts
Perspective2026-05-26

Why your BI tools don't make decisions (and never will)

Retail dashboards have never been clearer, and yet the same problems keep eating margin. Here's why BI tools can't fix what they were never built for.

Damien Didelot12 min read

Ten years ago, the Business Intelligence promise was simple and powerful: "give us your data, we'll give you the visibility to run your business." Retail invested massively. Power BI, Tableau, Looker, Qlik, MicroStrategy — there's barely a chain left that hasn't deployed at least one BI platform, trained its teams, built its operational dashboards, and instituted its weekly review rituals.

The result is paradoxical. Retail leaders have never had more visibility into their data. And yet most of the problems eating their margin — the overstocks piling up, the mistimed markdowns, the stockouts on best-sellers, the late replenishments — persist exactly as before. The dashboards show the problem. Nobody fixes it.

This dissonance isn't an accident. It's not a sign that retailers are using their BI tools wrong, or that their teams lack skill. It's the direct consequence of what a BI platform is by construction: a reading tool, not a decision tool. And until that fundamental distinction is understood, chains will keep piling on dashboards in the hope that at some point, operational performance will eventually follow.

This article looks straight at what BI does very well, what it will never do, and what you need to layer on top to turn visibility into performance.

What BI originally promised: clear sight to decide better

To understand why BI disappoints today, you have to remember what it originally promised. In the early 2010s, the diagnosis on retail organizations was clear: the data existed, but it was locked in silos, exploited in batch mode, presented as static reports good for a monthly meeting. The bet of modern BI was to industrialize all of that. Connect the sources, automate the calculations, produce interactive dashboards, accessible to everyone, refreshed daily.

And it worked — for the visibility part. Today, in most chains, a regional director can open their phone and see near-real-time revenue across their stores, the average basket, the conversion rate, stock cover by category. The merchandiser knows which families are behind plan, which SKUs have the weakest sell-through, which stores are underperforming.

The visibility promise was delivered. But here's the thing: visibility has never solved a single operational problem. Seeing an overstock doesn't make it disappear. Seeing a stockout doesn't create the order that resolves it. Seeing a margin drift doesn't trigger the markdown decision that fixes it. Between the moment the dashboard shows the problem and the moment an action is taken on the ground, there's a gap that BI was never designed to cross.

Three architectural limits BI vendors will never tell you about

This inability to turn visibility into action isn't a teething issue vendors will eventually fix. It's baked into the DNA of BI itself. Three architectural limits explain it.

Limit #1: BI answers questions, it doesn't ask them

A BI tool is, by nature, reactive. It waits for a human to formulate a question — "what's my sell-through this week?", "which stores are underperforming?", "which category is dragging the average basket?" — and answers by presenting the requested numbers as a visualization.

That's useful, and it's insufficient. Because in the real life of a retailer, most good questions are never asked. Not for lack of skill, but because with 50,000 SKUs, 200 stores, and thousands of variables to cross-reference, no human brain can formulate the right questions on every topic, all the time.

Nobody, on a Tuesday morning, is going to wonder: "should the navy linen dress, size M, at our Bordeaux store be transferred to our Saint-Émilion store where it's selling three times faster?". Nobody. And yet that's exactly the kind of question whose answer, multiplied by ten thousand, makes the difference between a winning season and a losing one.

BI doesn't formulate that question. It doesn't know the question exists. It waits for someone to ask — and no one, inside a normal human organization, can ask it on time, on every SKU, in every store, every week.

Limit #2: BI is descriptive, never prescriptive

BI tools excel at telling you what happened. They're mediocre at explaining why, and structurally incapable of telling you what to do.

Take a typical example. A dashboard shows that the gross margin on women's shoes has dropped 3 points over the last month. That's factual, accurate, well visualized. Now what? Why did it drop? A miscalibrated promo? An unfavorable product mix? An early markdown on a sub-category? A store effect concentrated on three locations? And above all: what should you do now?

BI won't answer any of these questions automatically. At best, it'll let a skilled analyst dig, filter, cross-reference, and eventually identify the cause after half a day's work. At worst — and this is the most common case — the alert gets noted, presented in a meeting, and stays without concrete action because nobody has time to go deep.

And even if the cause is identified, the dashboard will never say: "here's the decision to take, here are the SKUs affected, here's the recommended markdown depth, here are the priority stores." That transformation from diagnosis to prescription is exactly what a BI tool doesn't do, because it's not its job.

Limit #3: BI stops at the dashboard, it doesn't execute anything

This is the harshest limit, and the most fundamental. A BI tool displays. It doesn't do.

The SKU to transfer stays displayed in a dashboard. The transfer decision has to be entered elsewhere, in the ERP or the WMS. The markdown identified as necessary has to be triggered in another system. The replenishment alert has to be manually converted into a supplier order. Between the dashboard and the action, there's a chain of re-entries, validations, and cross-team coordination that consumes a disproportionate amount of time and, in practice, destroys all the value of the initial visibility.

That's the great mystification of modern BI. We called "steering" what is really just a visualization window. Steering, in the real life of a retailer, is not looking at well-made charts. It's pushing a decision from the dashboard to the store floor, in five days max, at the scale of tens of thousands of SKU/store pairs. No BI platform in the world was ever built for that.

The myth of the "action-triggering dashboard"

BI vendors have of course sensed the problem, and tried several answers over the years. Automatic alerts, configurable thresholds, "decisional" dashboards, integrations with other tools. On paper, it's appealing. In reality, these attempts hit a conceptual wall.

Alerts are not decisions. Receiving a notification saying "sell-through on category X dropped below 60%" doesn't help anyone until you have, behind it, the analysis that says why, the trade-off that says what to do, and the system that executes the action. Multiply these alerts by a hundred, and you don't get steering — you get background noise the teams ignore. The phenomenon is well known: alert fatigue.

Thresholds are rigid, the world is contextual. A rule that says "trigger an alert if stock cover exceeds 12 weeks" ignores that for certain SKUs, 12 weeks is normal (basics, pre-season products), and for others it's already catastrophic (end of season, trendy items). Without case-by-case contextual intelligence, thresholds mass-produce false positives and false negatives.

Integrations with execution tools stay superficial. Being able to click in a dashboard to open the ERP on a SKU's record is better than nothing. But it's still not execution — it just shortens the re-entry chain by a few seconds. The decision work, the action formalization, the validation of business rules: all of that still has to be done by a human.

The result of this accumulation of half-solutions is familiar to every retail leadership team. We piled on dashboards. We multiplied alerts. We trained the teams. And we keep noting, month after month, the same structural problems — overstocks in some stores, stockouts in others, markdowns too late or too deep, replenishments out of sync.

What really happens in the "last mile" of decision

To understand why BI alone isn't enough, you have to look at what concretely happens between the moment a data point exists and the moment an action takes place on the floor. What you might call the last mile of decision.

Here's a typical day in a merchandising team. Monday 9am: the merchandiser opens her weekly dashboard. She sees three categories are underperforming. She exports the data to Excel for processing. 10:30am: she's identified the 200 most problematic SKUs across the three categories. She starts reviewing them one by one. 11:45am: break, meeting, various urgencies. 2pm: she resumes. 4pm: she has a short-list of 50 SKUs for which she's considering action. She emails pricing. Tuesday: pricing comes back with questions. Wednesday: trade-off in committee. Thursday: decisions formalized and sent for ERP re-entry. Friday evening: store execution. The following Monday: we observe (maybe) an effect.

Count it: five to seven days between signal and action. On a universe of 50,000 SKUs, this human process touched 50 SKUs. That's 0.1% of the assortment. And these are, by construction, the 50 most visible SKUs — the other 49,950 kept silently drifting.

No dashboard, however beautiful, changes this equation. Because the bottleneck isn't visibility. It's human decision bandwidth.

What BI will never be, and what to layer on top

Let's say it clearly: BI will never become an operational decision tool. Not because vendors lack ambition, but because retail decision at scale requires a fundamentally different architecture.

An operational decision platform is not an improved BI. It's a different object, built around four capabilities BI has never carried:

First, a data unification layer oriented toward action, not just reporting. The difference is subtle but crucial: a BI warehouse aggregates data to read it; a decision platform reconciles it to use it in near real-time, at the SKU/store level, with a freshness compatible with operational steering.

Second, a decision engine that asks the questions itself. Instead of waiting for a human to ask "is this SKU at risk?", the engine continuously scans tens of thousands of SKU/store pairs and identifies the ones that deserve action. It doesn't just signal — it proposes a concrete action: transfer, markdown, replenish, return to supplier, or do nothing.

Third, native integration of the chain's business rules. Margin floors, supplier contractual constraints, commercial calendars, category- or brand-specific handling — all the rules that today live in heads or Excel files are codified into the engine and applied systematically. Not to replace human judgment, but to free the teams from the repetitive mechanics and let them focus on high-value trade-offs.

Fourth, execution without breakage. The decision isn't just displayed, it's converted into an operational instruction — transfer order, price update, supplier order generation — and propagated into existing systems (ERP, WMS, e-commerce) without human re-entry. It's this decision-to-execution continuity that turns the promise into actual performance.

The strategic mistake: pitting BI against decision platforms

Important: this isn't about replacing BI. BI tools remain essential for financial reporting, strategic analysis, performance steering, historical KPI reading. They keep playing their role, perfectly.

The strategic mistake many retailers still make is to believe that by adding one more dashboard, one more KPI, one more analytical view, they'll eventually solve their operational problems. They won't. Because what's missing in their tech stack isn't a lack of visibility. It's a missing decision and execution layer between the data and the floor.

That missing layer can't be built by accumulating dashboards. It assumes a different logic: moving from observation to action, from reading to prescription, from dashboard to orchestration.

The Solya approach: from dashboard to executed decision

That's exactly the mission of Solya. Not to replace your BI — keep it for what it does well. But to add, on top of your existing stack, the layer BI has never carried: a retail decision and execution platform that turns your data into concrete actions, at the SKU/store level, continuously.

Concretely, Solya connects to your existing sources — POS, ERP, e-commerce, supply chain, internal tools — and rebuilds a unified, usable view of your network. That data feeds a decision engine that doesn't just display: it continuously identifies the SKU/store pairs that deserve action, proposes the optimal decision (transfer, markdown, replenishment, supplier return, or status quo), applies your business rules — margin floors, supplier constraints, commercial calendars, specific handling — and propagates the validated decisions to your execution systems without re-entry.

The teams keep their hand on every structural trade-off. They define the guardrails, validate sensitive decisions, adjust strategy. Solya takes care of the mechanics: the cascade of small operational decisions which, multiplied by tens of thousands, make the difference between a season you endure and a season you steer.

The paradigm shift is simple to state. A BI platform tells you what's happening. Solya tells you what to do — and pushes it from the dashboard to the store, without breakage.

The real question to ask

How many operational decisions does your organization actually take, every week, across your entire assortment? Not how many are visible in your dashboards. How many are taken — meaning identified, arbitrated, executed on the floor.

If the answer is in the order of a thousand weekly across a network of several hundred stores and tens of thousands of SKUs, you're probably letting through 95 to 99% of the decisions that could have created value. Not out of incompetence — but because no human team can, alone, handle that volume.

It's that reservoir, immense and structurally left on the table, that leading retailers have started addressing. Not with one more dashboard. With a platform built, from the start, to decide and execute, where BI stops at observing.


See the difference between seeing and deciding

At Solya, we offer retail leadership teams a personalized 30-minute diagnostic to map, on your own context, what today separates your visibility from your action capability — and to quantify the value potential you're leaving on the table at every decision cycle.

👉 [Book your Solya diagnostic] — 30 minutes, by video, with one of our retail experts.

You'll walk away with:

  • A map of the operational decisions that aren't being taken today, for lack of bandwidth
  • An estimate of the margin potential recoverable on your scope
  • The first high-ROI use cases to move from visibility to executed steering

Related articles