Case study

A stalled Power BI rollout, taken over and brought back on track

Mechanical engineering

A mechanical engineering company whose Power BI implementation had stalled, with inconsistent models and source systems that had never been connected. It now runs on one KPI framework, a report catalogue and a budgeting process built into the model.

Read the engagement brief(opens in a new tab)
Started
09/2025, ongoing
Company
50–250 people
Focus
Finance and budgeting
A schematic: the separate reports this engagement started from, the one consolidated reporting layer that replaced them, and the technologies underneath.

One-off files, replaced by a catalogue with owners

The Power BI rollout had stopped halfway. Reports had multiplied as one-off files, the models underneath them disagreed, and several source systems had never been connected. We audited what existed, made it consistent and put one binding set of KPI definitions under all of it, the budget included.

report catalogue, with an owner and a purpose per report
1
binding KPI framework under every report, the budget included
1
steps in the takeover, each built on the one before
4

No outcome figures are published for this engagement: nothing exists that would let you check them, so what was built is described in full instead. Anonymised by sector and size, because the confidentiality that protects this client would protect you too. Sector and outcomes are real; identifying detail is not.

Before and after

Before and after the engagement

One-off files

  • Reports as one-off filesNo stated owner, no stated purpose
  • Models that disagreedThe same measure built more than one way
  • Source systems never connectedData the reporting was meant to cover
  • Budget in a separate workbookPlan against actual needed reconciliation first

A report catalogue

  • One catalogue, one owner per reportEach report with its owner and its purpose
  • One version of each measureCleaned models under a binding KPI framework
  • The missing systems connectedSources that had never been integrated
  • Budget inside the modelNext to the actuals it is measured against
Before, reports were one-off files with no stated owner or purpose. Now each report sits in one catalogue with its owner and its purpose.

The engagement in full

Client
A mechanical engineering company of 50 to 250 people, with a Power BI implementation that had been started and then stalled.
Situation
Reports had multiplied as one-off files with no stated owner or purpose, the models underneath them disagreed, and several source systems had never been connected. A report nobody owns is a report nobody corrects.
Mandate
Take over the implementation, make what existed consistent, connect the systems it was missing, and bring the budgeting process into the model.

How the platform is run

Refresh routines are scheduled in a known order, so figures are current when people open them, and changes reach the reports through a defined release rather than ad hoc. Models, measures and reports are named the same way throughout, and the whole of it is written down so the client’s team can run the platform themselves.

How the takeover ran

Each step builds on the one before: nothing new was added until what existed was consistent.

  1. Audit what existsReports with no owner, models that disagree
  2. Clean up models and measuresOne version of each measure
  3. Connect the missing systemsSources that had never been integrated
  4. Put the KPI framework on topDefinitions, time intelligence, variance logic

The budgeting process, end to end

The budgeting process redesigned from data collection through to plan-against-actual reporting.

  1. Data collectionBudget inputs gathered in one routine
  2. Budget in the modelNext to the actuals it is measured against
  3. Plan against actualReported from the same model

The architecture

Sources: Existing sources · Newly connected systems. Semantic layer: Cleaned models · KPI framework · Budget data. What reads it: Report catalogue · Plan against actual
Existing and newly connected sources feed cleaned models under one KPI framework, which the catalogued reports and the budget reporting both read.

Architecture decisions

DecisionRejected alternativeWhy
Audit before buildingAdding new reports on topThe models underneath disagreed, so every new report would have inherited the disagreement.
A catalogue with an owner per reportMore one-off filesA report nobody owns is a report nobody corrects, and the sprawl was the original problem.
One binding KPI frameworkDefinitions kept per reportTime intelligence and variance logic decided once mean every report answers the same way.
Budget inside the modelBudget kept in a separate workbookPlan and actual read from one place, so plan against actual needs no reconciliation.

What the client has today

  • A report catalogue in place of the one-off files, with an owner and a purpose for each report.
  • Consistent models and measures, with the source systems that were missing now connected.
  • A binding KPI framework as the single source of truth for definitions, time intelligence and variance.
  • A budgeting process that runs from data collection to plan against actual inside the model.
  • Refresh and release routines, naming conventions and documentation for a clean handover.
Where it stands
A rollout that had stopped now has one set of definitions, an owner for every report and the budget in the same model as the actuals.
Stack
  • Power BI
  • DAX
  • Semantic modelling
  • SQL
  • Dataflows
  • Data governance
All case studies

The other engagements

  • Retail

    Foundation then Activation then Acceleration alongside Stewardship

    Store revenue, executive questions and forecasting on one set of definitions

    A retailer with Microsoft Fabric already in production, semantic models over Direct Lake and store revenue streaming in, who wanted forecasting, Copilot questions and anomaly detection on top of it.

    • Microsoft Fabric
    • Power BI semantic models
    • Direct Lake
    • Copilot in Power BI
    • Fabric AI Functions
    • Activator

  • Industrial manufacturing

    Foundation then Activation then Acceleration

    Governed reporting across a production network

    An industrial manufacturer reporting across a production network of sites, each with its own view of what was running.

    • Microsoft Fabric
    • OneLake
    • OneLake Security
    • Direct Lake
    • Spark
    • MES
    • OPC UA
    • Power BI
    • DAX
    • Azure Key Vault
    • Purview
    • Azure DevOps

  • Hospitality and real estate

    Foundation then Activation

    A CFO cockpit over a group that closed its books separately

    A holding group across hospitality and real estate, with entities that each closed their own books and a CFO who had to answer for all of them.

    • Microsoft Fabric
    • OneLake
    • Direct Lake
    • Databricks Mirrored Catalog
    • Fabric Data Factory
    • Power BI
    • DAX
    • Calculation groups
    • Row-level security
    • Azure DevOps
    • Azure Key Vault
    • Purview

  • Multi-brand retail

    Foundation then Activation

    One governed model across a multi-brand retail group

    A retail group running several brands, each with its own systems, its own reporting habits and its own answer to what a margin is.

    • Microsoft Fabric
    • Direct Lake
    • Databricks
    • Eventstream
    • KQL Database
    • Power BI
    • DAX
    • SAP
    • Salesforce
    • Azure DevOps
All case studies

Free consultation

Know where your data stands in an hour.

A free 60-minute consultation. No pitch, no invoice. You’ll leave knowing whether your data is ready for AI, and whether we’re a good fit.

Book your free consultation(opens in a new tab)