Microsoft Fabric for Mid-Market Manufacturing in 6 Weeks

The phrase "digital transformation" has become a reliable way to get a room of operations leaders to check their phones. It implies 18-month programmes, steering committees, consultants in suits showing slides about maturity models. None of that is what mid-market industrials actually need from data and analytics.

What they need is to stop making production and supply chain decisions from a spreadsheet that was last refreshed at 8 a.m.

Mid-market industrials sit in an awkward position. At 200–5,000 employees and USD 50M–USD 1B in revenue, you are large enough to have complex data — multiple ERP instances, a MES on the shopfloor, a WMS in the warehouse, supplier data living in email threads — but not large enough to have a dedicated data engineering team to consolidate it.

You are probably already running SAP ByDesign, SAP S/4HANA, Microsoft Dynamics 365, NetSuite, or Epicor. You have Power BI licences, possibly a workspace or two that someone set up during lockdown. The dashboards exist. They are just not trusted, not live, and not connected to the systems that actually run the plant.

The result: plant managers run the morning meeting from a PDF someone emailed at 06:45. Operations directors chase the supply chain team for OTIF numbers that are already a day old. Finance closes the month from a spreadsheet because the BI tool isn't connected to the ERP in a way anyone trusts.

Microsoft Fabric is designed for exactly this situation. The question is what a realistic first deployment looks like — not the eventual vision, but the first six weeks.

The promise at MyData Insights is specific: first value in 6 weeks — not a 50-slide roadmap.

That means one named metric, one source system, one published Power BI report on Direct Lake. Not a data warehouse migration. Not a governance framework document. Not a pilot with seventeen stakeholders in a steering committee.

Here is what it looks like in a manufacturing context. The metric is OTIF — On Time In Full. The source system is SAP ByDesign. The outcome is a Direct Lake-connected Power BI report showing OTIF by customer, by SKU, by dispatch week, refreshed in near real time from the OneLake lakehouse.

At the end of week six, the Supply Chain Director opens a report on their laptop that shows exactly where OTIF is breaking — which carriers, which product lines, which customers — without waiting for someone to pull a spreadsheet from SAP ByD.

That is the prototype. It is not the complete solution. But it is real, it is live, and it answers a question that was previously answered by argument.

Older approaches to this problem involved extracting data from the ERP, loading it into a data warehouse, building semantic models on top of the warehouse, and then connecting Power BI. That process took months and required a team.

Direct Lake mode in Microsoft Fabric changes the economics. Data lands in OneLake as Delta Parquet files. Power BI reads directly from those Delta files — no import, no duplication, no separate warehouse layer to maintain. For a mid-market industrial that needs one or two operational metrics connected and live, this is the architecture that makes a six-week prototype feasible.

The engineering work in the prototype is: build the ingestion pipeline from the source system into OneLake using Azure Data Factory, ensure the Delta Lake table structure is optimised for Direct Lake, build the Power BI semantic model with the correct measures and hierarchies, publish and schedule. That is it. Not simple — but scoped.

For manufacturers who are less focused on supply chain and more focused on production, the same prototype shape applies to OEE — Overall Equipment Effectiveness. Instead of pulling from SAP ByD or Dynamics 365, the source is the MES or SCADA layer. OEE by line, by shift, by machine centre — published to Power BI Direct Lake, refreshed on a frequency aligned to the shift handover.

The value proposition is the same: the shift supervisor should not be calculating OEE on a whiteboard or waiting for a morning email from the maintenance team. The data should be there when the shift starts.

Whether the metric is OTIF, OEE, fill rate, scrap rate, or forecast accuracy, the prototype logic is identical. One metric. One source. One live report. Then expand.

A FMCG manufacturer with approximately 400 employees and SAP ByDesign as their core ERP had no reliable view of customer OTIF below the monthly management report level. The supply chain team was spending 6–8 hours per week extracting, cleaning, and distributing a spreadsheet that was out of date before it reached the recipient.

A six-week prototype connected SAP ByD to OneLake via Azure Data Factory, built a Direct Lake semantic model in Microsoft Fabric, and published a Power BI report covering OTIF by customer and by SKU. Refresh latency dropped from a weekly manual process to a 15-minute automated pipeline. The weekly spreadsheet was retired.

The prototype then became the foundation for expanding to supplier on-time delivery, inventory ageing, and demand vs. actuals — all on the same OneLake estate, using the same governance model.

The six-week prototype is the Prototype phase, not the destination — and the reason it works is that everything after it reuses the foundation rather than rebuilding it. Once OTIF or OEE is live on OneLake, the second metric is not a second project. Supplier on-time delivery, inventory ageing, demand-versus-actuals, scrap by SKU — each is another source landed through Azure Data Factory into the same lakehouse and another measure added to the same Power BI semantic model. The marginal cost of metric three is a fraction of metric one, because the ingestion pattern, the governance, and the Direct Lake model already exist.

Expand is also where the estate gains breadth across systems. The prototype proved one source; the Deploy and Expand phases fold in the MES alongside the ERP, the WMS alongside the MES, until the morning meeting reads from one governed view instead of three. The discipline that keeps this from sprawling is that every new source maps to the same master data and the same semantic definitions on the way in — so the estate stays consistent as it grows rather than accumulating new variants of the truth.

This is the answer to the question every mid-market CFO eventually asks: does the six-week spend lead anywhere, or is it a one-off? It leads to a platform. Unify one source, prove it, then expand onto the same OneLake foundation — Discover, Prototype, Deploy, Expand, in that order — so each phase compounds the last instead of starting over.

The case for the six-week shape is as much commercial as technical. A traditional 18-month data programme asks a mid-market business to fund a steering committee, a maturity-model assessment, and a warehouse migration before anyone sees a working dashboard — and the CFO who approved it is asking "where is the value?" at week 12 with nothing live to point at. The six-week prototype inverts that: the first artefact is a production report on real data, and the investment decision for the next phase is made against a result, not a slide.

It also de-risks the spend in a way the big programme cannot. Scoping to one metric, one source, one report means the failure modes surface in weeks, not quarters — if the master data is poor or the SAP integration is not ready, you find out in Discover at a small cost, not eighteen months in at a large one. You are not funding a learning exercise; you are funding a specific, testable outcome with a clear definition of done.

And the economics favour reuse over scale. Capacity is sized to the actual workload in Discover — typically an F4 to F16 for a single-plant mid-market manufacturer, not an over-provisioned SKU bought on a vendor's projection — and right-sized after 30 days of real usage. The result is a platform that grows with the business and a cost that tracks consumption, rather than a large fixed commitment justified by a roadmap nobody has yet validated.

If your organisation does not yet have an ERP — if you are running operations on spreadsheets and email — a Fabric prototype is not the right first step. The data infrastructure problem is upstream of the analytics problem. An ERP selection and implementation needs to happen before a data layer makes sense.

If you are post-ERP but your master data is in poor condition — item codes duplicated across systems, customer records inconsistent, no standard site or cost centre hierarchy — the prototype will surface those problems quickly. That is not necessarily a reason to delay, but it is a reason to scope the Discover phase carefully and set realistic expectations about what the first six weeks can produce.

If your primary goal is regulatory compliance reporting rather than operational visibility, the prototype shape may be different. A compliance-first deployment has different data governance requirements and a different definition of "done".

Week one and two: Discover — source system audit, metric definition, stakeholder alignment, OneLake architecture design. Week three and four: build the ADF ingestion pipeline, structure the Delta Lake tables, validate data against the source ERP. Week five and six: build the Power BI semantic model on Direct Lake, publish the report, run it alongside the existing process to validate, hand over to the business.

At the end of week six, one operational metric is live. The Expand phase — adding more sources, more metrics, more consumers — starts from that foundation.