Leveraging power BI for business intelligence

Power BI is the default business intelligence choice for a large share of Swiss mid-market companies, mostly because it is already in the Microsoft licence. That is a legitimate reason and it is not the same as it being the right tool for every job.

This is what it does well, where it stops, and what to settle before rolling it out.

The pieces, briefly

Four components, and the distinction matters for both cost and compliance:

• Desktop — where reports are built. Free, runs locally.
• Service — the cloud platform where reports are published, shared and scheduled. This is where your data goes, and where the residency question lives.
• Datasets and semantic models — the shaped data behind reports. The part that actually determines performance.
• Dashboards and reports — a report is multi-page and interactive; a dashboard is a single-page summary, often pinned from several reports.

Most quality problems trace back to the third item. Teams tune visuals when the model is the constraint.

What it does genuinely well

Connecting to what you already have. The connector range is broad, and for an organisation running Microsoft infrastructure the integration is close to free.

Putting analysis in non-specialist hands. A finance or operations person can build something useful without a developer, which removes a queue that otherwise limits how many questions get asked.

Scheduled distribution. Reports that arrive reliably in the right inbox or channel are more valuable than better reports nobody opens.

Where it stops being the right tool

Worth being straight about, because the default choice gets stretched.

It is not a data warehouse. Loading large raw tables into Power BI and shaping inside it works until it does not, usually around the point where refresh times become unworkable. Shaping belongs upstream.

It is not a transactional application. Write-back capabilities exist and they are not a substitute for an application with proper validation, audit and concurrency handling.

It is weak where governance has to be strict. Self-service is the strength and the risk — without discipline you get forty datasets computing revenue five different ways, which is a master-data problem the tool will not solve.

Cost is not obvious. Per-user licensing is fine for a few analysts and less so when the whole company needs access; capacity licensing changes the arithmetic and should be modelled before rollout rather than after.

Governance that prevents the usual mess

The failure mode is predictable: eighteen months in, nobody knows which report is authoritative, and executive meetings argue about whose number is right.

Four controls prevent most of it:

• Certified shared datasets for anything business-critical, built once and reused. Self-service builds on top of these, not beside them.
• An agreed definition per key metric, written down. If two departments count customers differently, the tool will faithfully produce both numbers.
• A retirement rule. Reports accumulate; without something removing unused ones the estate only grows.
• Named ownership per certified dataset. Not a team — a person.

This is the same underlying requirement as any data initiative, covered in AI architecture: why data governance decides the outcome.

The residency and access questions, before rollout

For a Swiss company this is the item to settle first, because reversing it after two years of reports is expensive.

Where does the Service store and process your data? Tenant region is a deployment decision, and for some organisations it constrains which capabilities are usable.

Who can reach it? Vendor support access, administrator accounts with standing privileges, and sub-processors behind the platform. Under revDSG/nDSG and GDPR this is the half that gets audited; storage location is the half in the marketing material.

Does the report need personal data? Aggregated and pseudonymised data usually answers the business question at a fraction of the obligation. The cheapest control available.

Row-level security applied in the model, not by hiding visuals from a user. Hidden is not inaccessible.

For FINMA-supervised businesses, add the standard outsourcing expectations: documented risk assessment, audit rights and a demonstrable exit.

A sensible rollout sequence

1. Settle residency and access, and write the answers down
2. Define the five to seven metrics that matter, with owners and agreed definitions
3. Build certified datasets for those, upstream shaping included
4. Then open self-service, building on the certified layer
5. Set a review cadence that includes retiring what nobody opens

The common error is starting at step 4. It produces fast early enthusiasm and the governance problem above within two years.

Related reading

• Power BI visualisation techniques that change decisions
• KPI dashboards that Swiss executives actually use
• Data, AI & analytics

If you are rolling this out and want the residency and governance questions settled first, book a call. No obligation.