Power BI Shows You the Data. But Is the Data Right?

If your dashboards are built on bad data, they’re just confident liars.

The Question Everyone Asks

“Why do we need Capstone if we already have Power BI?”

Microsoft Power BI has over 30 million monthly active users and can build operational dashboards. Why add another system?

You don’t, unless your dashboards are giving you the wrong answers. Then you need both urgently.

From Raw Data to Insight: The Five Steps

A BI tool shows you data. A data platform makes sure the data is right. Those are different jobs. To see where the boundary falls, look at the journey from raw operational data to insight. There are five distinct steps:

1. Collect. Extract data from your MES, ERP, quality systems, energy monitors, and other operational systems.
2. Integrate & Model. Combine sources, resolve conflicts, establish common definitions, build a coherent data model.
3. Aggregate & Compute. Apply mathematical rules to calculate the metrics that matter. This is where ratio logic, hierarchy traversal, and aggregation rules live.
4. Analyse. Apply business logic, interpret patterns, compare against targets, form conclusions.
5. Visualise. Present results in dashboards, reports, and interactive tools.

Power BI owns step 5. A data platform owns steps 1–3. Step 4 is where they overlap, but they contribute differently.

When operations teams say “we can do this all in Power BI,” they usually mean “we can do steps 4 and 5 in Power BI.” And they can. But steps 1–3 still have to happen somewhere. If you compress them into Power BI, you’re asking a visualisation tool to do data engineering.

Where Power BI Excels

Power BI is an excellent tool, and it keeps getting better:

• Dashboard design and interactivity: slicers, drill-downs, natural language Q&A, decomposition trees
• DAX modelling: calculation groups, time intelligence, sophisticated measures — real analytical power when the underlying data is sound
• Composite models and DirectQuery: connect to multiple sources without importing everything; live connections to operational databases
• The Fabric semantic model: shared definitions across reports, reducing the “different numbers in different dashboards” problem at the presentation layer
• Report storytelling: visuals that guide narrative, with strong mobile and embedded options

When Power BI Alone Is Enough

If your data comes from one or two well-structured sources, your metrics are straightforward (revenue, throughput, counts), and you have a dedicated BI developer who understands your business rules Power BI alone works well. Many organisations run effective reporting this way, and adding a data platform would be over-engineering.

The problems start when you have multiple source systems with conflicting definitions, ratio metrics that need to aggregate correctly across an organisational hierarchy, or dozens of calculated KPIs that interact with each other. Here’s a quick test: if two report authors can produce different numbers for the same KPI from the same underlying data, you’ve crossed the line. What Did Yesterday’s Production Actually Cost? describes the typical situation: production data in one system, costs in another, quality in a third, with no common thread between them. That’s when Power BI starts doing work it wasn’t designed for.

Where Power BI Struggles

Even with DAX calculation groups and the Fabric semantic model, Power BI wasn’t designed to be your aggregation engine or your hierarchy resolver. When you ask it to handle steps 1–3, the cost is high:

• Brittle DAX formulas: Custom measures that enforce correct aggregation logic are complex to write and fragile to maintain. Calculation groups help, but they still require someone to manually encode every ratio metric’s aggregation behaviour, and to get it right across every hierarchy level.
• No enforcement: Power BI doesn’t stop a report author from dragging a ratio metric into a pivot and letting the default aggregation run. If that default is wrong, the dashboard displays the wrong answer. Beautifully.
• Per-report logic: DAX measures live inside individual semantic models. When business logic changes, you update it in one model and hope the others stay in sync. There’s no single place where “cost per tonne is a ratio that must be recalculated from components” is enforced globally.
• Hidden dependencies: Business logic encoded in formulas is hard to find, harder to audit, and breaks when data structures change.

To see what these aggregation errors look like in practice — and why they’re not rounding errors but structural mistakes — Why Spreadsheets Lie About Cost Per Unit works through the full pattern for ratio metrics, and From OEE Percentage to Dollar Impact translates the gap to dollars.

“Can’t We Just Build a Data Pipeline?”

Fair question. You don’t need Capstone specifically to solve the data quality problem. Azure Data Factory, dbt, Snowflake, Databricks: the modern data stack gives you plenty of tools to extract, transform, and warehouse data before Power BI touches it. If you have data engineers on staff, you can absolutely build a pipeline that handles steps 1–3.

So why would you use a purpose-built platform instead?

Domain knowledge is the difference. A general-purpose ETL pipeline doesn’t know that OEE is multiplicative, that cost per unit is a ratio that can’t be summed, or that your organisational hierarchy needs different aggregation rules at each level. Your data engineers have to encode all of that logic manually, and maintain it when metrics change, org structures shift, or new sites come online.

A manufacturing data platform has that domain logic built in. It knows which metrics are additive and which are ratios. It understands hierarchy traversal. It enforces aggregation rules at every level without custom code.

The practical difference: in a recent multi-site deployment, 37 production inputs across three sites produced 76 calculated metrics and 4 interactive dashboards. Build time was 40 hours with zero custom code. All configuration, no engineering. That same scope in a custom-built pipeline (writing the transformation logic, testing the aggregation rules, handling hierarchy edge cases) is engineering months, not days.

You can build it yourself. The question is whether that’s the best use of your data team’s time, given that a platform already handles the manufacturing-specific logic. Microsoft Fabric and Capstone: Different Problems, Different Tools walks through the architecture and integration patterns in detail.

The architecture is straightforward: a data platform handles steps 1–3, publishes clean metrics, and Power BI pulls them into steps 4–5. The organisations that run this way trust their numbers at 11 p.m. when they need to replan tomorrow’s production. They don’t get surprised by month-end reconciliations. I’ve watched ops managers at other sites lose entire shifts arguing over a dashboard figure that turned out to be an aggregation artefact. That doesn’t happen when the data is right before it reaches the dashboard.

Two tools aren’t complexity for the sake of it. It’s the same reason you don’t ask your welder to do your QA paperwork.

Ready to separate correct data from beautiful dashboards? Schedule a 30-minute Capstone walk-through →

Related reading: Why Spreadsheets Lie About Cost Per Unit, What Did Yesterday’s Production Actually Cost?, Microsoft Fabric and Capstone: Different Problems, Different Tools, From OEE Percentage to Dollar Impact