
www.simplify-data.de
Power BI is quick to install, and first reports often take just a few hours. That is exactly why many companies start without a plan and, a few months later, face cluttered workspaces, duplicated data models and conflicting numbers. This article describes a proven rollout process and the mistakes you should avoid.
Phase 1: Clarify goals and scope
Before the first report is built, write down which questions Power BI should answer. Typical goals in mid-sized companies are monthly management reporting, a sales overview or analysis of inventory and purchasing.
At this stage, also clarify:
- Who is responsible on the business side, and who on the technical side?
- Which data sources are needed (ERP, CRM, accounting, Excel lists)?
- How many people will build reports, and how many will only read them?
- Which data is sensitive and may only be seen by certain people?
Phase 2: Prepare licences and tenant
Power BI runs in your company's Microsoft tenant, which you usually already have through Microsoft 365. For collaboration, creators need a Pro or Premium Per User licence. Whether readers also need licences depends on whether you use a Fabric capacity of size F64 or larger. Our article on Power BI licensing covers the details.
In the admin portal you define central settings, for example whether reports may be published to the web or exported to Excel. Review these tenant settings deliberately before the rollout instead of accepting the defaults.
Phase 3: Connect data sources
If your data lives in cloud services, Power BI can usually access it directly. For databases or files on your own network, you need an on-premises data gateway. This is software running on a server in your network that connects the Power BI service to local sources.
Treat the gateway as a production service: install it on an always-on server rather than a workstation, with its own service account and documented credentials.
Also keep refresh limits in mind. According to Microsoft, shared capacity (that is, with Pro licences) allows up to eight scheduled refreshes per day, while PPU or Fabric capacity allows up to 48 (as of November 2026).
Phase 4: Build a central data model
The semantic model is the heart of it all: it contains the tables, their relationships and the metric calculations written in the DAX formula language. A star schema has proven itself, in which a central fact table (such as sales) is linked to descriptive dimension tables (customers, products, dates).
The key principle: one model per subject area, used by several reports. Revenue is then defined only once and is identical in every report.
Phase 5: Pilot report and reconciliation
Start with a clearly scoped report and a small group of users. Compare the figures with your existing reporting and resolve differences together with the business department. Only once the figures are accepted is it worth expanding.
Phase 6: Workspaces, apps and permissions
Organise content in workspaces, for example by department or topic. For distribution to readers, Power BI apps work well: they bundle a workspace's reports in a clear interface without readers needing access to the development environment.
If different people should see different data, such as each sales rep seeing only their region, use row-level security. It is defined in the data model and then applies to every report built on that model.
Phase 7: Training and operations
Plan two kinds of training: a short introduction for readers (filters, drill-down, export) and a more in-depth one for creators (data model, DAX, design). Also decide who monitors failed refreshes, who may create new workspaces and how changes to the data model are approved.
Roles in the project
Even in smaller companies it helps to name three roles clearly, even if one person covers several of them:
- Power BI administrator: manages tenant settings, licences, the gateway and workspaces.
- Model owners: build and maintain the central semantic models and document the metrics.
- Business owners: approve metric definitions, check figures during the pilot and gather requirements from their department.
If one of these roles is missing, tasks fall through the cracks, such as monitoring failed refreshes or approving new metrics.
Common rollout mistakes
| Mistake | Consequence | Better |
|---|---|---|
| Everyone builds their own data models | conflicting numbers, high maintenance | central models per subject area |
| Gateway on a workstation | refreshes fail when the PC is off | gateway on a server with a service account |
| No metric definitions | debates about the "right" numbers | written metric sheet |
| Reports shared by link with everyone | unclear permissions, data protection risks | apps and groups for distribution |
| Licences bought without planning | unnecessary costs or missing access | count creators and readers first |
| No pilot | trust is lost early | one report, reconciled and accepted |
| Tenant settings not reviewed | unintended sharing or exporting | define settings before rollout |
Checklist for getting started
- Define goals and first reports, and name business and technical owners.
- Count creators and readers and choose the licensing model.
- Review and document tenant settings in the admin portal.
- List data sources and, for local sources, set up a gateway on a server.
- Build a central semantic model as a star schema.
- Reconcile a pilot report with existing reporting.
- Set up workspaces, apps and row-level security.
- Train readers and creators and assign operational responsibilities.
How Simplify Data can help
Simplify Data supports mid-sized companies in Kiel, Schleswig-Holstein, Hamburg and remotely across Germany in rolling out Power BI, from licence planning through gateway and data model to training. Find out more on our Power BI page.
