Microsoft Fabric and Power BI for manufacturers: one governed model where a measure is defined once, access modes chosen by the latency each decision needs, and security that follows the plant hierarchy.
Building a semantic model looks like a technical task. It is the point at which somebody has to write down what availability excludes, what the ideal cycle time is based on, and where the shift boundary falls, because a model cannot hold two answers.
These are the complaints that start a BI modernisation. In five of the six cases the cause is upstream of the platform, which matters because replacing the platform will not address it.
Reporting fragmented across ERP, MES and plant systems
Each with its own extract and its own owner.
Production reporting built in Excel
Maintained by one person who is quietly critical.
KPI definitions that differ by plant
Per our Operational & Production Analytics page.
No enterprise view that anybody believes
Because the plants do not recognise their own numbers.
Consolidation that takes days
When the decision window was hours.
A reporting estate nobody can inventory
Hundreds of reports, unknown usage.
Self-service that produced sprawl
Because there was no governed model underneath.
BI security and governance managed request by request
With no model of who should see what, and no catalogue.
Look at what people export from your current reports, and what they do to it afterwards. That is your requirements list, written by the people who need the data, ranked by how often they need it. It costs nothing to collect and it is more accurate than any workshop. In most cases it reveals three or four missing combinations that would retire a dozen spreadsheets.
A Fabric implementation is mostly data engineering and semantic modelling, both well understood. The step that determines whether it is adopted is the definitional one, and it belongs to operations rather than to the platform team.
We run that step explicitly and early, with the people whose numbers are at stake, because it cannot be avoided and it gets more expensive the later it happens.
Step 1
Assess BI maturity and inventory the current reporting estate
Step 2
Collect the measure definitions in use, as calculations
Step 3
Agree the definitions with operations, engineering and finance
Step 4
Assess the current Microsoft estate, licensing and tenant governance
Step 5
Design the OneLake and lakehouse structure
Step 6
Design the ingestion and transformation per source
Step 7
Build the semantic model: measures once, definitions visible
Step 8
Choose the access mode per model from the latency required
Step 9
Build the reporting for three audiences
Step 10
Configure workspace structure, security and the hierarchy model
Step 11
Deploy through pipelines with dev, test and production
Step 12
Measure adoption and retire what the new reporting replaces
Before the platform work starts, get two plants to agree one measure definition in writing. Pick availability or OEE. If that agreement can be reached in a few weeks, the Fabric implementation will go well. If it cannot, the programme now knows its real critical path, and that is considerably better than discovering it during semantic modelling with a delivery date already committed.
Grouped by what each part does. The semantic model group is where the definitions live, which makes it the part with the most governance attached and the least visible work.
Platform
Microsoft Fabric implementation within your existing tenant and licensing position
OneLake structure designed by domain and by plant, with the layering stated rather than assumed
Lakehouse and warehouse solutions, chosen per workload rather than standardised on one
Workspace architecture and environment separation, so development does not happen in production
Azure and wider Microsoft ecosystem integration, including identity and governance tooling
Data engineering
Data Factory pipelines and orchestration across ERP, MES, SCADA, historian and quality sources
Transformation into the shape the business asks questions in, per our Manufacturing Data Platform Engineering page
Real-time ingestion where the latency requirement justifies it, for shift-level and condition views
Incremental loading, because reloading everything is the cause of the refresh problem in section 2
Data quality and validation at the boundary, with rejects visible rather than dropped
Semantic models and reporting
Manufacturing semantic models with each measure defined once and the definition visible at the point of use
Measure logic versioned and under change control, per section 7
Enterprise dashboards for the three audiences: the line, the plant, the group
Shop-floor display design, which is a different build from a management report and is frequently neglected
Self-service enabled inside the governed model, with certified datasets distinguished from exploratory ones
Automated distribution, subscriptions and alerting, including the exception report that replaces a meeting
Governance and operations
Identity integration, workspace security and row-level security on the hierarchy model from section 3
Deployment pipelines and change control for reports and models
Cataloguing, lineage and sensitivity classification using your Microsoft governance tooling
Capacity management and refresh scheduling as a contention decision, per section 8
Report estate rationalisation, including retiring what the new reporting replaces
These are the reporting jobs a manufacturer wants. The model requirement is named for each, because that is what determines whether it can be delivered from one governed model or becomes another exception.
Executive manufacturing performance
A group view of output, performance, quality and cost across sites.
OEE and production efficiency
The three components and the losses behind them.
Multi-plant comparison
Like-for-like performance across comparable sites.
Quality and defect analytics
Defect rates, types and trends joined to product, line and process.
Inventory and supply chain
Stock positions, coverage, movement and shortage risk.
Maintenance and equipment performance
Asset availability, maintenance activity, cost and recurrence.
Manufacturing financial performance
Cost, variance and margin by product, line and plant.
Energy and sustainability reporting
Consumption, intensity and the reporting somebody external will read.
Planning and schedule adherence
Planned against actual, by order, line and period.
Before building the group dashboard, show one plant its own numbers computed the group way. Their reaction is the most useful information in the programme. If they recognise the figures, the definitions are aligned and the roll-up is safe. If they do not, you have just found the work, before an executive saw a number that was going to be contested.
We work within your existing Microsoft estate, licensing position and tenant governance. The components below are the ones a manufacturing implementation uses; the decisions that matter are about shape and latency rather than about which service is involved.
OneLake
The storage foundation, organised by domain and plant with the layering stated.
Data Factory
Ingestion and orchestration across ERP, MES, SCADA, historian and quality.
Lakehouse and warehouse
Chosen per workload rather than standardised on one.
Real-time intelligence
For the shift-level and condition views where latency justifies it.
Semantic models
Measures once, definitions visible, versioned, under change control.
Power BI reporting
Three audiences, including a shop-floor build.
Identity and security
Entra ID, workspace roles, and row-level security on the hierarchy.
Governance tooling
Cataloguing, lineage and sensitivity using your Microsoft governance stack.
Deployment pipelines
Development, test and production, with change control.
ERP, MES, SCADA, historian and quality sources through the routes our Manufacturing Data Platform Engineering page sets out, read-only at the plant boundary
Incremental loading wherever the volume justifies it, since reloading everything is the usual cause of a refresh that misses the morning
Real-time paths built only where a decision depends on them, per the three-latency argument on the data platform page
Where a non-Microsoft platform already holds the industrial data, we integrate rather than replace, since the industrial layer rarely needs to move
And no dependency on a specific platform behaviour that we have not verified in your tenant, because capability in this area changes and a design should be checked rather than assumed
Once a semantic model holds the definitions the business runs on, changing it is a management action rather than a technical one. Most of the governance on this page follows from that.
Identity
Entra ID integration, with access derived from the organisation rather than granted ad hoc.
Workspace security
Roles by function and environment, with production restricted.
Row and object level security
On the hierarchy model from section 3, tested with real identities.
Measure change control
A definition change is a change record with an approver.
Data governance and cataloguing
A catalogue people can search, with lineage so a figure traces to the records behind it.
Sensitivity classification
Applied where commercial, personal or confidential data is involved.
Data quality
Validated at the boundary, with the as-at time surfaced.
Environment governance
Development, test and production separated and promoted through pipelines.
In a shared capacity, one heavy operation affects everybody else. That makes refresh scheduling an operational decision rather than a configuration setting, and it is the cause of most morning reporting failures.
Capacity utilisation over the day, with the peaks identified rather than an average, since the average never fails and the peak does
Refresh success, duration and completion time against the moment the business needs the data, which is the measure that matters
Refresh contention: which operations overlap, and whether the morning load is competing with something that could run later
Pipeline reliability per source, with an alarm on the run that did not start as well as the one that failed
Semantic model size and query duration, which is the section 6 shape question expressed as a measure
Report performance by report and by user, since a slow report used by fifty people is a different problem from a slow one used by two
Data freshness surfaced to users, not only monitored by the platform team
Adoption per report and per plant, which is how the estate gets rationalised honestly
Reports nobody has opened in months, which are candidates for retirement rather than migration
Export volume and destination, per section 2, as a requirements signal rather than a violation
Access requests and their pattern, since a recurring request type is a gap in the security model
And the cost position, with the capacity consumption attributable to workloads rather than reported as one figure
Ask what time your morning reporting actually completes, on its worst day last month. Not the average and not the schedule: the worst completion time. If that is after the time the plant needs it, the reporting is unreliable for the decision it exists to support, and the fix is usually incremental loading and refresh sequencing rather than more capacity.
Outcomes depend on the state of your definitions, your Microsoft estate and your current reporting sprawl. These are the changes the work is aimed at.
One definition per measure, in one model, visible where the number is used, which is what makes enterprise KPIs consistent rather than merely centralised
Plants recognise their own numbers in the group view, which is what makes the group view usable
Reporting is consolidated rather than recreated, with a falling net count of reports and models
Morning reporting completes before the plant needs it, on its worst day
Reports are fast because the model is shaped for the questions
Access follows the organisation and survives a reorganisation
Certified and exploratory content are visibly different, so people know which number to take to a meeting
The shop floor has a screen built for the shop floor rather than a shrunken management report
Exports are treated as a requirements signal and the gaps behind them get closed
And what the new reporting replaced has actually been switched off
Improvement continues after go-live, because the cadence below reviews definitions, certification, retirement and capacity with decisions attached rather than reporting on them
Bring us your reporting estate and two plants that disagree, and we will inventory what exists, collect the definitions as calculations, show you exactly where they differ, and design the model so a measure is defined once.
CaliberFocus implements Microsoft Fabric and Power BI for manufacturers around one governed semantic model where each measure is defined once and the definition is visible where the number is used. We settle the definitions with operations, engineering and finance first, choose access modes by latency, and build security that follows the plant hierarchy.
- One definition per measure, settled before modelling begins
- Access mode chosen per model from latency and cost
- Row-level security driven by data, surviving reorganisations
- A shop-floor build, and retirement of what the new reporting replaces
Security & Compliance
