Built once. Used at scale.
Trusted by the people who decide.

Usage data. Power BI tracks every view via the activity API. We pull 90 days of usage logs, find the 20 reports that drive 80% of the views, and rebuild those on the new governed model first. The other 380 either get archived or auto-converted. We have done this with Power BI estates of 50, 400 and 1,200 reports — the 80/20 pattern holds every time.

No. Power BI works with everything. We assess whether the move is worth the migration cost. For some mid-market clients the answer is stay on SQL Server and add a semantic model layer. For others — high data volume, multiple source systems, real-time requirements — Fabric pays back in 9–12 months. We tell you which one you are during Discover.

We migrate them. We have moved estates from each. Honest framing: Tableau is better at exploratory data analysis. Power BI is better at governed, scaled, embedded BI. If your buyer is an analyst Tableau may win. If your buyer is an Operations Director or a CFO, Power BI usually wins. We will not promise that migration is fun — but we have run it enough times to know the patterns.

We price Power BI work the same way as our Fabric engagements: a fixed fee on a fixed scope, confirmed after a 30-minute diagnostic — never open-ended time and materials. The commitment we make upfront is the timeline. The Foundation build — governed semantic model, Direct Lake, and core dashboards — delivers first value in 6 weeks and production at 8. If you want to prove one governed dashboard first, the 2-week Starter Sprint is a fixed-scope entry point. Power BI Pro and Fabric capacity are separate Microsoft licences (capacity from an F2 SKU, about USD 262/month).

For Discover, usually yes. For Prototype, depends on data access readiness on your side — connector credentials, RLS scope, source-system access for our team. We send a Discover prep checklist on day one of the engagement so the gap closes fast.

A governed Power BI semantic model is a single, owned data model where each measure — OEE, OTIF, fill rate — is defined once, named for the business term, and secured at the model layer. It matters because without it, teams build conflicting versions of the same metric and leadership reviews argue about whose number is right. On Microsoft Fabric the model reads Delta tables in OneLake, so every report inherits the same definitions.

Model one business domain at a time — Manufacturing first — with measures named for the business term, row-level security at the model layer, and calculation groups for time intelligence. Build it on Direct Lake over OneLake so it reads live Delta tables with no refresh. Assign a named owner on your team so it stays maintained after go-live; we deliver the first production domain model in a 2-week Prototype.

Replace user-built models with one governed semantic model per domain, where OEE and OTIF are each defined once and owned by a named person. Calculation groups handle the time-intelligence variants, so there are not 27 versions of YTD. When every report reads the same model, the leadership review stops debating whose number is correct.

Calculation groups let you define time-intelligence logic — YTD, PYTD, MAT — once and apply it across every measure, instead of writing a separate measure for each combination. A model with 27 hand-built YTD variants collapses to one calculation group. It cuts maintenance and removes the inconsistencies that come from copy-pasted DAX.

Name one person on your team as the model owner before go-live, and hand over with documentation and training so they can extend it. Deployment pipelines and Git integration make changes reviewable, so ownership does not depend on tribal knowledge. The common failure is a model built by a contractor that nobody owns the day they leave — we build to prevent that.

Direct Lake reads Delta tables in OneLake directly with no data copy, so the report reflects new data as it lands and there is no refresh to schedule or fail. Import loads a separate copy into the model, so the report is only as fresh as the last refresh and large models can take hours or time out. Direct Lake needs the data in OneLake Delta format; Import works with any source. For large operational models, Direct Lake removes the refresh window while keeping query latency within 10-15% of Import.

Audit the existing Import model for unsupported DAX patterns, rebuild the semantic model on Delta Parquet in OneLake, and parallel-run new against old for two weeks before cutover. The refresh window disappears and capacity cost typically drops 20-35%. We size the Fabric F-SKU to actual workload rather than guessing at procurement time.

Move the model from Import to Direct Lake so there is no refresh to run — the report reads live Delta tables in OneLake. Where Import must stay, we fix the real bottleneck: bad DAX, missing aggregation tables, or an oversized model. We have taken 4-hour refreshes to 12 minutes by fixing the model, not the gateway.

Profile the report with DAX Studio and Tabular Editor to name the real bottleneck, then refactor the offending measures and add aggregation tables where Direct Query is the right shape. Most slow reports are four bad measures, not how Power BI works — we have taken 40-second visuals to 1.2 seconds by rewriting them. Capacity load analysis often shows the fix is workload distribution, not more SKU.

Direct Lake removes the data-hydration cost of Import — there is no refresh consuming capacity — so the same workload runs on a smaller Fabric F-SKU. Clients typically see the capacity bill drop 20-35% after migration. We size the capacity to measured workload using Fabric Capacity Metrics, not a procurement guess.

Implement row-level security at the semantic model layer so every report inherits plant-level, region-level, or customer-level rules without per-report configuration. One model, every report secured, new reports inherit automatically. This replaces the per-report RLS hacks that break each time someone publishes a copy.

Dynamic RLS maps the signed-in user to their data using Entra ID attributes, so a plant manager sees only their plant without a separate role per person. Joiner-mover-leaver changes are handled through user attributes, not manual role edits. It scales to multi-plant, multi-region estates without a spreadsheet access matrix.

Power BI Deployment Pipelines with Git integration give you Dev, Test, and Prod stages for semantic models and reports, with a branch-per-feature workflow. Automated checks on data quality and measure performance run before promotion to production. You get an audit trail of who changed what, visible in seconds rather than searched through Teams.

Use Deployment Pipelines and Git so changes are promoted Dev to Test to Prod rather than edited live, and a broken measure stays in a branch instead of taking production down. Automated performance and data-quality checks gate promotion. Every change is reviewable and revertible, so production stability stops depending on luck.

Harden the semantic model first, document every measure with synonyms and example questions, then scope Copilot to the governed workspace so it cannot run over un-curated models. Train plant managers and operations leads on what Copilot answers well and what it does not. Done this way, managers ask questions in plain English at the morning huddle.

Copilot reflects whatever sits in the semantic model, so garbage measures become confident wrong answers. Before enabling it, we clean and name every measure, add synonyms and example questions, and remove orphaned or duplicate measures. Copilot is enabled only after the model is governed — not before.

Copilot maps a natural-language question to the measures in your governed semantic model, so "what was OEE on Line 3 yesterday" resolves to the one defined OEE measure. Accuracy depends on the model being documented with synonyms so business terms map correctly. Because it reads the governed model, the answer matches the dashboards.

When plant managers and supply-chain leads can ask Copilot directly against a governed model, the ad-hoc requests that fill the analyst inbox drop sharply — typically 40-60%. The analysts move from answering "where is OEE on Line 3" to building new models. The prerequisite is a hardened, documented semantic model.

An FMCG operations dashboard in Power BI should carry fill rate, OTIF, forecast accuracy, inventory turns, days inventory outstanding, and case-fill by SKU and region. Build them on one governed semantic model so the same fill-rate number appears everywhere. On Direct Lake the dashboard reflects live ERP data rather than an overnight extract.

Land ERP, WMS, and TMS data in OneLake — via Mirroring or Azure Data Factory — and build the dashboard in Power BI on Direct Lake so it reflects shipments as they move. Track OTIF, dwell time, and cost-to-serve against one governed model. Fabric Activator can raise an alert when a shipment breaches its window.

Stream MES and machine data into OneLake through Fabric Eventstream, model availability, performance, and quality in the gold layer, and read it in Power BI with Direct Lake. The OEE dashboard updates as the line runs, so a drop shows within minutes. One governed OEE measure means every plant reports it the same way.

Model inventory turns, days inventory outstanding, and fill rate once in a governed semantic model over OneLake, then surface them in Power BI on Direct Lake. Because the measures are defined once, planning and finance read the same numbers. Live data means the stock position reflects today, not last night's extract.

For EPC, build a Power BI model that tracks earned value, cost-to-complete, schedule variance, and committed vs actual cost by project and work package. Connect ERP and project systems into OneLake so the numbers reconcile to finance. One governed model gives the project director and the CFO the same figures.

A supply-chain-director dashboard leads with OTIF, fill rate, forecast accuracy, inventory cover, and cost-to-serve — the few numbers that drive the weekly decision — with drill-through to plant and SKU detail. Build it on one governed semantic model so the headline numbers reconcile to the operational reports beneath. On Direct Lake it reflects live data, so the review runs on current numbers.

Build a DIFOT (Delivered In Full, On Time) dashboard in Power BI on a governed model fed by ERP, WMS, and TMS data in OneLake. Track DIFOT by customer, lane, and carrier with drill-through to the failed deliveries behind the number. Direct Lake keeps it current, and Fabric Activator can flag a customer trending below target.

We map the Tableau estate — workbooks, data sources, RLS rules, embedded reports — identify which patterns transfer cleanly, and rebuild the rest on a governed Power BI semantic model. Honest framing: Tableau is stronger for exploratory analysis; Power BI is stronger for governed, scaled, embedded BI for operations leaders. We have moved several estates and know which patterns rebuild versus convert.

We migrate Qlik apps by rebuilding the data model as a governed Power BI semantic model rather than porting Qlik script line by line. Usage logs identify the apps that matter, so effort goes to the 20% that drive most views. The result is one governed model with RLS and deployment pipelines, not a like-for-like copy of the Qlik mess.

Power BI's activity API logs every view. We pull 90 days of usage data, find the 20% of reports that drive 80% of views, and rebuild those first — the rest are archived or auto-converted. The 80/20 pattern has held across estates of 50, 400, and 1,200 reports.

Usage logs turn a rebuild from guesswork into a ranked list: which reports drive views, which are orphaned, which semantic models are worth governing first. You rebuild the high-value 20% on the new model and stop spending effort on reports nobody opens. It is how we sequence a migration so business value lands first.