A practical guide to connecting ERP, MES, machine and supply-chain data without weakening operational control.
A manufacturer rarely has a shortage of data. It has a shortage of agreement about what the data means. The ERP system records orders, stock and cost. The manufacturing execution system records what happened on the line. Historians and sensors capture machine conditions. Quality, maintenance, product and customer information may sit in several more applications, plus the spreadsheets people use when those systems do not quite meet in the middle.
Each source can be accurate within its own boundary and still leave the business with a fragmented view. A production order may have one identifier in ERP and another in MES. A downtime event may be measured to the second while the financial effect is calculated by day or accounting period. Two sites may use the same label for different measures. Putting those records in one location does not resolve the disagreement.
That is why a unified data platform for manufacturing is more than a storage project. It is an architecture for making operational and commercial data usable together, with clear ownership, shared definitions, controlled access and enough lineage to understand where a figure came from. The platform should support better decisions without pretending that every factory system belongs in one application or one database.
Three key takeaways
- 1.Unified means consistent and governed, not merely centralised. Manufacturers need common identifiers, definitions, ownership and access rules as much as they need pipelines and storage.
- 2.Operational systems should remain authoritative for operational work. Dynamics 365, MES, PLM, maintenance and factory systems feed the wider data platform; the analytics layer should not blur their responsibilities.
- 3.Start with a decision, not a data migration. A focused production, quality, maintenance or supply-chain use case is a better foundation than copying every available record and looking for value afterwards.
What is a unified data platform in manufacturing?
A unified data platform connects information from business systems and factory operations so that approved users and applications can work from a coherent view. It normally includes ingestion, storage, transformation, semantic modelling, analytics, governance and monitoring. Some data is copied into a data warehouse or lakehouse. Other data can be accessed through replication, virtualisation or shortcuts. The right pattern depends on the source, latency, volume, ownership and recovery requirements.
The word unified should not be read as ‘one giant database’. ERP transactions, high-frequency telemetry, engineering documents and customer records have different structures and retention needs. A useful platform lets those domains remain understandable while providing shared keys and trusted data products for cross-functional work.
For example, a production-performance view might combine the planned order and standard cost from ERP, actual output and scrap from MES, downtime events from a historian and inspection results from the quality system. The platform has to preserve the grain of each source, reconcile identifiers and explain how the final measure was calculated. Without that work, a dashboard can be visually consistent and operationally wrong.
Why manufacturing data is difficult to unify
Manufacturing data spans two environments that are related but managed differently. Information technology systems focus on transactions, people, finance and planning. Operational technology controls or observes physical processes where availability, timing and safety are central. A modern data platform needs information from both, but it should not create an uncontrolled route back into production equipment.
The systems also work at different speeds. A general-ledger balance may be updated by posting. Inventory can change whenever a movement is registered. A machine signal may arrive many times a second. Not every decision needs the fastest possible feed. A maintenance alert may require near-real-time processing, while a monthly cost analysis does not. ‘Right time’ is a more useful design target than making every report real time.
Context is another problem. A temperature reading has little value unless the platform knows which asset produced it, the unit of measure, the operating state, the product being made and the time window that matters. The same issue appears in master data: item, customer, supplier, work-centre and asset identifiers often differ across systems. Data engineering can move records, but the business still has to decide which definitions are trusted.
The architecture behind a usable manufacturing data platform
A practical architecture separates responsibilities. That makes it easier to change a source system, improve a data product or tighten access without redesigning the whole estate. The layers below are not a fixed product map; they describe the jobs the architecture needs to perform.
- Source and control Manufacturing examples: ERP, MES, PLM, quality, maintenance, SCADA and historians. Design decision: Which system owns each transaction, master record and control action?
- Ingestion Manufacturing examples: APIs, files, change data capture, gateways and event streams. Design decision: What latency, replay, duplicate handling and failure recovery are required?
- Storage and processing Manufacturing examples: Data warehouse, lakehouse, event store and curated data products. Design decision: Which records are retained, transformed, copied or accessed in place?
- Operational context Manufacturing examples: Asset, site, line, product, order, batch, lot and unit hierarchies. Design decision: How are identifiers, units, timestamps and relationships made consistent?
- Semantic and analytical Manufacturing examples: Measures, forecasting features, Power BI models and APIs. Design decision: Which definitions are certified, and at what grain are they valid?
- Governance and security Manufacturing examples: Ownership, catalogue, lineage, classification, roles and audit. Design decision: Who can discover, use, share and change each data product?
Where Microsoft Fabric and Dynamics 365 fit
Microsoft Dynamics 365 is important to the architecture but it is not the whole unified data platform. Dynamics 365 Supply Chain Management can hold operational records for products, procurement, inventory, manufacturing, warehousing and assets. Business Central can play a similar system-of-record role for many small and mid-sized manufacturers. Dynamics 365 Sales, Customer Service and Dataverse may hold the commercial and service context around those operations.
Microsoft Fabric provides the wider analytics platform. Its integrated workloads cover data ingestion, transformation, data engineering, data science, real-time stream processing, data warehousing and Power BI reporting. That makes it possible to build a data product across several operational sources without asking the ERP system to perform every analytical job.
OneLake is the logical data lake built into Fabric. Microsoft documents it as a tenant-wide place for analytics data, with open table formats, common security controls and options such as shortcuts and mirroring. Those options can reduce unnecessary copies, but they do not remove the need to decide where data is mastered, how long it is retained and which team owns it.
Fabric Real-Time Intelligence is designed for continuously arriving data and event-driven analysis. Manufacturing scenarios can include IoT readings, alarms, application logs and other time-based signals. A production design still needs an industrial connectivity layer, buffering, network segmentation and a clear boundary between analytical actions and machine control.
Original inline image from the InteliSense IT article, showing production information used on the factory floor.
What a unified data platform can improve:
Production visibility that people can reconcile
A shared production view can put plan, output, scrap, downtime and cost in the same analytical context. The value is not another wallboard. It is the ability to trace a number back to the underlying order, line, period and source. When operations and finance use the same definitions, they can investigate the cause of a variance instead of debating which spreadsheet is correct.
Planning and supply-chain decisions
Supply-chain teams often need to compare demand, supplier performance, inventory, capacity and transport constraints. Those records rarely have the same planning horizon or level of detail. A unified platform can prepare consistent analytical models for scenario testing and business intelligence, while Dynamics 365 Supply Chain Management continues to execute the approved purchase, production, warehouse and inventory transactions.
Maintenance based on operating context
Condition data becomes more useful when it is connected to the asset hierarchy, maintenance history, spare parts and production schedule. Dynamics 365 Supply Chain Management includes an Asset Management module for assets and maintenance jobs. Combining that operational record with telemetry can help planners prioritise inspection and maintenance work, although predictive maintenance still depends on reliable sensors, sufficient failure evidence and a defined response process.
Microsoft's Asset Management documentation describes the module as part of Dynamics 365 Supply Chain Management and explains how equipment and maintenance work are managed. The data platform can extend that view for cross-system analysis; it should not create a parallel maintenance record with unclear ownership.
Quality, traceability and investigation
A quality investigation may need material lot, supplier, process parameter, operator, machine, inspection and customer-return data. Connecting those records can shorten the search for affected products and reveal patterns across sites or suppliers. The platform must preserve the original evidence and the final disposition. An analytical correlation is a lead for investigation, not a replacement for the approved quality process.
Financial and operational performance
Manufacturing margin is influenced by yield, energy, labour, downtime, purchase price, freight and mix. A Microsoft Power BI model can bring these measures together, but only if time, currency, allocation and production-volume rules are explicit. A report labelled ‘cost per unit’ should not silently change its treatment of scrap or overhead from one site to another.
A stronger foundation for AI
AI needs more than access to a large volume of records. It needs relevant context, dependable features, permissions and an evaluation method. A model cannot infer the approved meaning of an asset code or the correct version of a work instruction from volume alone. Data quality, lineage and semantic definitions help an AI system retrieve the right evidence and allow a reviewer to challenge its output.
Data governance is part of the platform
Unifying access can make analysis easier, but it can also increase the impact of a poor permission or an incorrect data product. Governance therefore needs to be designed with the pipelines and models. Each domain should have an owner, each certified measure should have a definition and each sensitive source should have a clear access rule.
The Microsoft Purview Data Map captures metadata across analytical, software-as-a-service and operational systems, including schema, classifications, ownership and lineage. Within Fabric, the OneLake Catalog supports discovery and governance of Fabric data and analytics items. A catalogue is useful only when owners maintain the metadata and users understand which assets are approved for which purpose.
Security should follow least privilege. Engineers, analysts, suppliers and executives do not need the same view of every record. OneLake supports granular permissions and sensitivity labels across analytical experiences, but technical controls still need an operating process for access requests, periodic review, incident investigation and removal when a role changes.
Common mistakes in manufacturing data modernisation
The first mistake is treating ingestion as completion. A pipeline that copies a table successfully has not established whether the table is current, complete or understood. The second is building executive dashboards before agreeing the measures. That usually moves the debate from spreadsheets into Power BI without resolving it.
Another mistake is imposing one latency target on every workload. Streaming every available signal can increase cost and operational noise without improving a decision. At the other extreme, a daily batch may be too slow for an event that needs immediate inspection. Latency should be matched to the action and tested under failure conditions.
Manufacturers should also avoid connecting analytical workloads directly to production controllers merely because the data is available. Supported edge, historian, gateway and streaming patterns provide a safer separation. Any route that can write back into an operational system needs stronger identity, validation, approval and recovery controls than a read-only dashboard.
Finally, buying a Microsoft Fabric capacity does not create data ownership. Fabric implementation, data engineering and Power BI development can establish the technical platform, but business and operational teams still need to own the definitions and decide how information is used. A platform with no operating model will reproduce the silos it was meant to remove.
How to build a unified manufacturing data platform
The safest programme starts with one decision that already matters to the plant or business. The following sequence creates a thin but complete route from source data to action before the architecture is expanded.
- 1.Define the decision and baseline. Name the user, the current delay or uncertainty, the action they need to take and the measure that will show whether the new view helps.
- 2.Map the source and ownership. Identify the systems, interfaces, data owners, operational constraints and system of record for every field that the use case needs.
- 3.Agree the business meaning. Resolve identifiers, units, timestamps, hierarchies, calculation rules and the grain at which each measure is valid.
- 4.Build a thin data product. Use only the pipelines, storage, transformations and semantic model required for the first decision. Include logging, access control and recovery from the start.
- 5.Validate with operators and finance. Reconcile the output against source transactions and real operating events. Investigate differences before users are asked to trust the dashboard or model.
- 6.Operate, measure and extend. Assign service ownership, monitor data freshness and quality, review capacity cost and add the next use case only when the first product is stable.
Frequently asked questions
Is Dynamics 365 a unified data platform?
Dynamics 365 provides connected business applications and can be the operational system of record for important manufacturing, supply-chain, finance, sales and service processes. A manufacturer with MES, PLM, IoT, historian or specialist quality systems normally needs a wider analytical architecture. Microsoft Fabric can complement Dynamics 365 by combining and governing data for analytics, Power BI and AI workloads.
Does a unified data platform replace ERP or MES?
Usually not. ERP and MES continue to execute and record their operational processes. The data platform makes approved information from those systems usable together. Replacement may be a separate transformation decision if a source system cannot support the required process, data quality, integration or security.
What is the difference between a data warehouse and a lakehouse?
A data warehouse is designed around structured, governed analytical tables and SQL reporting. A lakehouse combines data-lake storage with database-style tables and analytical processing, which can suit mixed data engineering, data science and business intelligence workloads. Many manufacturing architectures use both patterns for different data products.
Does unified data mean keeping one copy of everything?
No. Some records need to be copied and transformed for performance, history or isolation. Others can be accessed through shortcuts, mirroring or supported virtualisation. The design should state why a copy exists, how it is refreshed, who owns it and what happens if the source changes.
How does Microsoft Fabric support manufacturing analytics?
Microsoft Fabric combines Data Factory, Data Engineering, Data Science, Data Warehouse, Real-Time Intelligence, OneLake and Power BI within one analytics platform. Manufacturers can use those workloads to ingest business and factory data, create governed data products, process events and deliver reporting or AI features. The exact design depends on the source systems, latency, security and scale.
Where should a manufacturer begin?
Begin with a problem where the decision, data and owner are known: for example, reconciling production and cost, investigating downtime, tracing quality events or improving a supply-chain view. Build one end-to-end data product, prove its accuracy and operating model, then reuse the architecture for the next priority.
Create one trusted route from data to decision
A unified data platform is useful when it makes a manufacturing decision easier to explain and act on. That requires more than connecting systems. The organisation has to preserve the authority of ERP and factory applications, establish shared meaning, secure the data and operate each data product as a service with an owner. InteliSense IT helps manufacturers connect Dynamics 365, Microsoft Fabric, Power BI, Microsoft Power Platform and wider operational systems. Our work can cover data strategy, data modernisation, Fabric implementation, Microsoft Fabric analytics, integration, governance and the practical use cases that sit on top of the platform.
Speak to InteliSense IT about a manufacturing data-platform assessment. We can help you map the current data estate, identify a credible first use case and design a governed Microsoft architecture that connects operational data to reporting, analytics and AI.
Advisory note: Microsoft product names, licensing, feature availability and implementation guidance can change. Confirm the current official documentation and complete appropriate architecture, security, data-protection and operational-safety reviews before deployment.
