Short answer: when a dashboard dies in a distillery, the post-mortem almost never finds a Power BI problem — it finds a translation problem. The developer modelled a batch process like a retail ledger, mixed bulk litres with litres of pure alcohol, defined “yield” a way no stillman recognises, and couldn’t join grain to mash to wash to cask because nobody told them that chain is the whole point. The operators spotted one wrong number, trust died, and the report became wallpaper. The tooling was fine. The domain knowledge wasn’t there — and in process industries, domain knowledge is load-bearing.
This is part two of the process-intelligence series. Part one mapped the four analytics onto distillery work. This post is about the uncomfortable pattern everyone in this industry has seen: a capable Power BI developer arrives, builds genuinely polished reports, and eighteen months later production has quietly gone back to the whiteboard and the spreadsheet. 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 sales dashboard — and drinks companies have plenty of those, because depletions and invoices look like every other industry’s transactions — hits a wall at the brewhouse door. Sales data is rows of transactions; the modelling patterns are universal. Production data is a process, and a process has shape: batches that split and merge, transformations with losses at every step, time measured in fermentation hours and maturation years, 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 tank figure bulk litres or litres of pure alcohol? Is gravity in °Plato or SG, and was it temperature-corrected? Is yield per tonne quoted as-is or at a standard moisture? A developer who doesn’t know these distinctions exist will sum bulk litres with LPA into one measure — and produce a stock figure that is confidently, recognisably wrong to anyone who has ever done a warehouse return.
Batch genealogy, or the missing spine. The question production actually asks is why: why was this week’s spirit yield down, why does this vatting taste different. Answering it requires the chain — grain lot → mash → washback → still charge → spirit receiver → cask — joined end to end. 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. The IBD doesn’t define “efficiency” the way a consultant’s template does. Predicted spirit yield against actual, original gravity, attenuation, percentage overall yield — these have industry definitions, and operators 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 isn’t calendar time. Fermentations are compared by elapsed hours, not by date; maturation lives in years-in-wood and age bands; a production week rarely matches a reporting month. Date-table reflexes from finance reporting mangle all of this, and the resulting charts feel subtly off to process people in ways they can’t always articulate — but act on, by not coming back.
Floor data is honest about being messy. Manual dips, a stillman’s log, a regauge done in the rain. A developer who hasn’t stood there treats it as clean input; the first impossible value propagates into a report, and — this is the killer — the operators recognise it instantly. They know that tank can’t hold that volume. One recognised wrong number and the verdict is rendered: “the dashboard is wrong.” Trust, once lost on a production floor, 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 process changes — a new washback, a changed cut regime, a warehouse re-rack — and the measures quietly drift out of alignment with reality. Without an owner who understands both the DAX and the distillery, nobody notices until the numbers diverge from the morning meeting’s whiteboard, and the whiteboard wins. Sustainability isn’t a technical property; it’s domain semantics plus ownership: measures defined the way the industry 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 wort and wood, and dropping them into a distillery without process documentation or a domain counterpart is an organisational failure, not a personal one. Domain experts fail in the mirror-image way: a distiller with Power BI Desktop and no modelling discipline builds a beloved, unmaintainable hairball that dies when they change jobs. And sometimes the dashboard is right and the floor is wrong — an uncalibrated dip stick out-lies any report, and a culture that always sides with the whiteboard against the data will never improve either. The honest conclusion isn’t “domain beats BI” or “BI beats domain” — it’s that production intelligence sits in the overlap, and the overlap is rare.
The bottom line
Power BI dashboards die in distilleries and breweries because the data model doesn’t speak the process’s language: wrong units, missing batch genealogy, invented KPIs, calendar time forced onto process time, and floor data trusted naively. Operators 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 process 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 breweries and distilleries? Rarely because of Power BI. They fail because the data model doesn’t match the process: transactional star schemas forced onto batch production, KPIs that don’t match how operators think (litres of pure alcohol per tonne, original gravity, attenuation), unit confusion (bulk litres vs LPA, °P vs SG), and no batch genealogy linking grain to mash to wash to spirit to cask. Operators spot one wrong number, trust dies, and the dashboard is abandoned.
What is process intelligence in a distillery or brewery? Analytics built around the production process itself — yields, losses, fermentation performance, cut decisions, maturation — rather than around sales transactions. It needs batch-level data joined end to end through the process, KPIs defined the way the industry defines them, and time handled as process time (fermentation hours, maturation years), not just calendar dates.
What makes a production dashboard sustainable? Three things: measures defined with the industry’s own semantics so operators recognise their numbers; a data model built on batch genealogy so “why” questions can be answered; and an owner who keeps it aligned as the process changes. A dashboard nobody trusts or maintains decays in months regardless of how well it was built.