What turns up when a Power BI that "runs slow" gets audited

There is a complaint that repeats across very different companies: "we have Power BI, but it runs slow and people do not trust the numbers". And a temptation that repeats too: open the report, change four visuals and assume the problem was cosmetic.

It almost never is. Audit after audit, the list of what turns up looks much the same from one company to the next. It is worth having at hand before calling anyone: whoever recognises three or four points already knows where to start.

The seven usual findings

• One giant flat table. The report was built on a forty-column Excel and imported as is. No facts, no dimensions. Every filter scans the whole table and every measure is computed over millions of rows nobody needed to look at.
• Calculated columns where measures belonged. Hundreds of them. They take up memory, recalculate on every refresh and do not respond to filter context. The classic symptom: the total does not match the sum of the parts.
• No date table. Without one, every "versus last year" comparison is a different formula handwritten on each page. None of them match.
• Full refresh every night. Two hours of loading to bring in data most of which has not changed. When it fails, nobody has a report in the morning.
• Thirty pages nobody opens. The report grew by accumulation: every request became a new page. The four that matter are buried among the other twenty-six.
• Security by hand. One copy of the report per department, each with its filter set manually. When someone changes teams, it gets forgotten. When it gets forgotten, someone sees what they should not.
• Nobody knows what the KPI means. "Margin" on the sales page and "margin" on the management page are two different formulas. Both are correct. Neither is the official one.

What can be fixed in a week

More than it seems. A date table, moving the heaviest calculated columns to measures, turning on incremental refresh and pruning the pages nobody uses usually brings load and response times down to a fraction. With that, the report stops hurting.

What cannot be fixed in a week

The model. If the source is a flat table, everything else is a patch. Rebuilding the model into facts and dimensions is the real work, and it has to be said plainly instead of selling that four tweaks are enough.

That is why a serious audit has a fixed scope and ends in a report with a roadmap and an estimated cost. KubiqX Pulse works that way: so the decision to rebuild or not is made with numbers, not with the feeling that it "runs slow".

What lies behind it

In almost every case the report was built with good intentions and without anyone who knew how to model. It is not the fault of whoever built it: Power BI allows building things it should not allow.

A report that takes more than ten seconds to apply a filter almost certainly has more than one of the seven points above. The question is which ones, and that is found by measuring, not by looking at the report.