Short answer: when a dashboard dies in a winery, the post-mortem almost never finds a Power BI problem — it finds a translation problem. The developer modelled a vintage-based batch process like a retail ledger, mixed tonnes of fruit with finished litres, defined “yield” a way no winemaker recognises, and couldn’t join block to pick to tank to barrel because nobody told them that lot chain is the whole point. The cellar spotted one wrong number, trust died, and the report became wallpaper. The tooling was fine. The domain knowledge wasn’t there — and in winemaking, domain knowledge is load-bearing.
This is part two of the winery process-intelligence series. Part one mapped the four analytics onto cellar work. This post is about the uncomfortable pattern wine businesses know well: a capable Power BI developer arrives, builds genuinely polished reports, and a vintage later the cellar has quietly gone back to the whiteboard and the lab notebook. What happened?
It is almost never the tool
Let’s clear this first: Power BI is not the problem. The same developer who built a superb DTC and distribution dashboard — and wineries have plenty of those, because club orders and depletions look like every other industry’s transactions — hits a wall at the cellar door. Sales data is rows of transactions; the modelling patterns are universal. Winemaking data is a process tied to a vintage, and that has shape: lots that split across tanks and merge in blends, transformations with losses at every racking, time measured in days on skins and months in barrel, and quantities whose units are themselves domain knowledge. Generic BI skill transfers to the first kind of data and silently fails on the second.
The five walls
Units that bite. Is that figure tonnes of fruit or finished litres of wine? Is sugar in Brix, Baumé or Oechsle? Is that acidity titratable acidity or pH — and they move independently, so a dashboard that treats them as interchangeable is meaningless. A developer who doesn’t know these distinctions exist will sum tonnes with litres into one “volume” measure and produce a stock figure that is confidently, recognisably wrong to anyone who has done a vintage.
Lot genealogy, or the missing spine. The question winemaking actually asks is why: why did this lot stick, why does this blend taste like the press fraction crept in. Answering it requires the chain — block → pick → tank → additions and temperature trace → barrel → bottle — joined end to end, with the many-to-many of blending intact. Transactional schemas don’t have this spine; nobody tells the developer to build it; and without it the dashboard can only ever say what, never why. That caps the whole project at the bottom rung of the analytics ladder forever.
KPIs that don’t match the trade. Oenology doesn’t define “quality” or “yield” the way a consultant’s template does. Yield per hectare, press yield, Brix at pick, YAN at inoculation, titratable acidity, free and total SO₂ — these have established definitions, and winemakers know them cold. A dashboard that invents its own “yield %” — even a defensible one — shows people a number that contradicts the one they calculate themselves. They will trust their own. They are right to.
Time is vintage time. Ferments are compared by elapsed days and by curve shape, not by calendar date; ageing lives in months-in-barrel and years-in-bottle; the vintage is the organising unit and a single vintage is a single data point. Date-table reflexes from finance reporting mangle all of this, and the resulting charts feel subtly off to cellar people in ways they act on by not coming back.
Cellar data is honest about being messy. A hand-written addition log, a refractometer reading taken in the vineyard, a lab panel with a transcription slip. A developer who hasn’t stood on the crush pad treats it as clean input; the first impossible value propagates into a report, and — this is the killer — the winemaker recognises it instantly. They know that tank can’t hold that volume and that Brix can’t jump that far overnight. One recognised wrong number and the verdict is rendered: “the dashboard is wrong.” Trust, once lost in a cellar, does not come back with a patch release.
Why “sustainable” is the hard part
Even a dashboard that launches correct then has to stay correct, and this is where the second wave dies. The operation changes — new vineyard blocks, a different tank layout, a move to amphora or concrete — and the measures quietly drift out of alignment with reality. Without an owner who understands both the DAX and the cellar, nobody notices until the numbers diverge from the morning meeting, and the lab notebook wins. Sustainability isn’t a technical property; it’s domain semantics plus ownership: measures defined the way oenology defines them, documented so the next developer can’t mangle them, and a person accountable for keeping model and process in step. This is the same discipline as building the data foundation before AI — unglamorous, and the whole game.
Where this breaks
Fairness demands the other side. This is not a developer-bashing post — a BI developer was never trained in Brix and Brett, and dropping them into a winery without process documentation or a domain counterpart is an organisational failure, not a personal one. Winemakers fail in the mirror-image way: a winemaker with Power BI Desktop and no modelling discipline builds a beloved, unmaintainable hairball that dies when they move cellars. And sometimes the dashboard is right and the cellar is wrong — an uncalibrated refractometer out-lies any report, and a culture that always sides with the lab notebook against the data will never improve either. The honest conclusion isn’t “domain beats BI” or “BI beats domain” — it’s that winery intelligence sits in the overlap, and the overlap is rare.
The bottom line
Power BI dashboards die in wineries because the data model doesn’t speak winemaking’s language: wrong units, missing lot genealogy, invented KPIs, calendar time forced onto vintage time, and cellar data trusted naively. Winemakers give a report exactly one chance, and a single recognisably wrong number ends it. The fix is not a better tool — Fabric makes the plumbing dramatically better and changes none of this — it’s putting oenological knowledge and modelling discipline in the same room, or, rarer and better, in the same head. What that looks like is the final post in this series.
Frequently asked questions
Why do Power BI dashboards fail in wineries? Rarely because of Power BI. They fail because the data model doesn’t match winemaking: transactional star schemas forced onto vintage-based batch production, KPIs that don’t match how winemakers think (yield per hectare, Brix, YAN, titratable acidity, pH), unit confusion (tonnes of fruit vs finished litres, Brix vs Baumé vs Oechsle), and no lot genealogy linking block to pick to tank to barrel to bottle. Winemakers spot one wrong number, trust dies, and the dashboard is abandoned.
What is process intelligence in a winery? Analytics built around the winemaking process itself — yield, fermentation performance, additions, fault risk, barrel ageing — rather than around sales transactions. It needs lot-level data joined end to end from block to bottle, KPIs defined the way oenology defines them, and time handled as vintage and process time (days on skins, months in barrel), not just calendar dates.
What makes a winery dashboard sustainable? Three things: measures defined with winemaking’s own semantics so the cellar recognises its numbers; a data model built on lot genealogy so “why did this lot go wrong” can be answered; and an owner who keeps it aligned as the cellar and vineyard change. A dashboard nobody trusts or maintains decays within a vintage regardless of how well it was built.