A manufacturing data architecture connects ERP business context, MES production execution and IoT equipment events through governed ingestion and shared identifiers. A lakehouse can retain and prepare these records; a semantic model turns them into consistent operational measures. The difficult work is aligning orders, assets, time and quality—not simply connecting three feeds.

Key takeaways

• Keep ERP, MES and plant-control responsibilities distinct.
• Choose batch or streaming ingestion from the business freshness requirement.
• Preserve event time, source identity and equipment context.
• Validate joins and measurement definitions before presenting KPIs.
• Keep analytical recommendations outside safety-critical control loops.

What ERP, MES and IoT contribute

Consider a fictional plant that wants to explain why an order is behind plan. ERP supplies the planned order and product context. MES records execution events and produced quantities. Equipment telemetry describes machine behavior. None of these sources alone establishes the complete explanation.

These are proposed responsibilities, not universal product guarantees. Confirm each plant’s actual systems and process ownership before designing a connector or a cross-system metric.

Do not make the analytics platform the accidental master for production orders or asset configuration. Record which system owns a value and how approved corrections reach downstream consumers.

A reference manufacturing data architecture

ERP orders + product context ── approved batch/change feed ─┐
MES execution + quality ─────── approved events/extracts ───┤
IoT sensors → plant edge → authorized outbound telemetry ──┘
                              ↓
Landing: original records + source metadata + ingestion time
                              ↓
Validation: schema, units, identity, duplicates, late events
                              ↓
Curated production facts + effective-dated master data
                    ┌─────────┴──────────┐
                    ↓                    ↓
Lakehouse analytics             Eventhouse for event queries
                    └─────────┬──────────┘
                              ↓
Governed semantic measures → dashboards + reviewed actions

Control and safety systems retain their operational authority

This original reference diagram describes an analytical pattern, not a deployed customer system or a plant-control design. A real implementation may use only one analytical store initially. Avoid adding every platform feature before a concrete workload needs it.

Microsoft’s Fabric ingestion overview distinguishes batch pipelines, streaming Eventstreams, Mirroring and shortcuts. Choose supported source and destination combinations after checking their current capabilities and operational constraints.

A plant gateway or integration boundary should control how data leaves the operational environment. Analytics connectivity must not create an unmanaged inbound path to machinery. Plan access and network boundaries with the plant’s responsible OT and security teams.

Select ingestion from freshness and recovery needs

An hourly planning report and an equipment-state dashboard need different delivery paths. Write the freshness requirement as a business expectation, then measure source-to-consumer delay. Fast transport cannot fix a source record that is only finalized at shift close.

Keep both event time and ingestion time. A buffered plant device can deliver yesterday’s event today; labeling it as current production because it just arrived produces misleading results.

Use a stable event identity where available. Where one is not available, define and test a deduplication rule with the source owner. Do not discard legitimate repeated measurements solely because their value is identical.

Backfill should use the same validation and transformation contracts as normal ingestion. Tag its scope so operators can distinguish a historical replay from live activity.

Build shared identities before cross-system dashboards

Start with plant, asset, product, production order, operation and time identifiers. Maintain explicit mappings when ERP and MES use different keys. A machine name written in a spreadsheet is not a reliable join contract.

Preserve historical context. If a product or asset mapping changes, decide whether the report should show the mapping valid at the event time or the current organizational view. Store enough history to answer that question deliberately.

A proposed curated event record might contain the following fields. It is a modeling example, not a mandated industry schema.

source_system, source_event_id
plant_id, asset_id, production_order_id, operation_id
event_type, event_time_utc, source_time_zone
ingested_at_utc, schema_version
measurement_value, measurement_unit
quality_status, source_record_version

Not every event needs every field. Missing order context may be legitimate for a maintenance event, but unexpected for a completed operation. Validate requirements by event type rather than forcing every record through one universal rule.

Keep high-frequency measurements separate from order-level facts where their grain differs. Joining each order directly to every sensor reading can multiply rows and inflate totals.

Quality controls and semantic models

Microsoft’s storage overview describes Lakehouse for files and Delta tables and Eventhouse for event analytics. Pick the serving approach that matches the query pattern, team and latency needs; a storage choice does not itself establish trustworthy business measures.

Define the grain and owner of every important measure. Planned quantity, produced quantity, accepted quantity and shipped quantity are different concepts. A rejected item that later passes rework must not be silently counted twice.

For OEE or other production measures, agree the denominator, planned stops, ideal rate, quality treatment and time windows with operations. Publishing a standard-looking percentage without these definitions can conceal differences between plants.

Surface data freshness and unresolved quality exceptions with the report. A dashboard should not present incomplete information as a definitive operational result.

A decision checklist for a first plant

1. Choose one operational question and accountable owner.
2. Inventory source systems and approved interfaces.
3. Define freshness, outage recovery and replay behavior.
4. Agree asset, order and operation mappings.
5. Specify event-time and measurement-unit handling.
6. Separate raw, validated and business-ready records.
7. Define semantic measures and their grain.
8. Reconcile representative shifts, corrections and rework.
9. Test source outages, duplicate delivery and late events.
10. Review OT boundaries, access, monitoring and support ownership.

Expand only after the first plant’s definitions and exceptions are understood. A reusable contract is more valuable than copying a dashboard whose assumptions are undocumented.

Acceptance should include an operator explaining a result from its source records and an engineer recovering a failed ingestion without changing business totals. No production benchmark or savings outcome is claimed here.

Common questions

Connect manufacturing data around a practical decision

Bring the plant systems, reporting problem and operational constraints. Discuss a domain-specific AI solution built on governed data and explicit engineering boundaries.