Unified Data Model (UDM)

Anyone working in a factory with multiple systems – ERP, MES, SCADA, historian, energy monitoring – knows the problem: every system has its own logic, its own terminology, its own IDs. What the ERP calls an "Order" is a "Job" in the MES and a "Batch" in the SCADA system. What the line planner calls a "line" is labeled a "Work Center" or "Cell" in another module of the same platform.

A Unified Data Model (UDM) solves exactly this problem. It is a consistent, cross-system data model that describes all relevant production objects uniformly – regardless of which system the data originally comes from. The result: data is modeled correctly once and can then be used across all applications without building new mapping logic every time.

Why a Unified Data Model? The Cost of Not Having One

Without a UDM, three problems emerge that directly affect operational performance:

Contradictory KPIs: OEE is pulled from the MES for Plant A, from an Excel export for Plant B, and from the historian for Plant C. The results are not comparable – not because the machines are different, but because the data foundation is inconsistent. Strategic decisions based on such figures carry significant risk.

Exploding integration effort: Every new analytics use case – energy consumption per order, end-to-end traceability, predictive maintenance models – requires its own integration logic, its own mappings, its own testing. With four systems and ten use cases, you quickly end up with an unmanageable web of point-to-point connections.

Excel as a permanent workaround: When no common model exists, gaps are bridged with spreadsheets. This is not a failure of individual teams – it is the systemic consequence of a missing semantic layer.

A Unified Data Model acts as that semantic layer: it maps ERP objects, MES events, and SCADA process data onto a single, coherent model.

What Does a Unified Data Model Contain in Manufacturing?

A UDM in a manufacturing context is business-oriented, not system-oriented. It describes how the real production environment works – not how any individual system stores data internally. Typical entities include:

Organization and structure: Enterprise, Site, Area, Line, Work Center, Machine, Asset. This hierarchy provides the spatial and organizational framework into which all other data is placed.

Orders and products: Customer, Product, Variant, Bill of Materials, Routing, Production Order, Operation, Batch, Lot, Serial Number. Without these entities, production data cannot be linked to business processes.

Resources and master data: Material, Tooling, Equipment, Personnel, Shift, Calendar. These data points define the conditions under which production occurred – a prerequisite for meaningful root cause analysis.

Process and event data: Status changes (start, stop, setup, downtime), counters, process values (temperature, pressure, torque), quality events (OK/NOK, inspection values), maintenance events. This layer reflects what actually happens on the shop floor.

KPIs and metrics: OEE, Availability, Performance, Quality, First Pass Yield, Scrap, Rework, Throughput, Lead Time. KPIs calculated on top of a UDM are automatically comparable across plants, lines, and products.

UDM vs. Shared Data Format: What's the Difference?

A common misconception: "We use JSON everywhere – that's a unified format." A shared data format is necessary but not sufficient.

A Unified Data Model goes three steps further:

Semantics, not just structure: Harmonizing column names is not enough. You need to define what an "Order" means in this specific organization – which fields it has, which states it can assume, which relationships it has to other entities. Two systems can both deliver JSON and still operate with completely different concepts of what an "Order" is.

Relationships and hierarchies: Which machine belongs to which line? Which order produces which serial numbers? How do batch, lot, and quality result relate to each other? These relationships are what turn raw data into actionable information.

Governance: Who defines, maintains, and changes the model? How are new entities or fields introduced without breaking existing reports? Without governance, a UDM quickly becomes an uncontrolled tangle of ad hoc additions.

Role in the Interplay Between ERP, MES, and SCADA

The three system layers have clearly defined roles within the UDM:

ERP provides the upper layer: customers, products, orders, costs, delivery dates. The UDM maps these objects to production reality – an ERP production order is assigned to a specific line, work center, and asset.

MES covers the middle layer: production execution, work in progress, OEE, traceability, quality workflows. MES events – starts, stops, downtime, NOK reports, inspection results – are stored as timestamped events in the UDM, making them permanently traceable.

SCADA, automation systems, and historians deliver the lowest layer: process and machine signals, alarms, curves, states. These raw data points are contextualized in the UDM through asset, operation, and order references – only then can process curves be assigned to a specific part, shift, or customer.

With a properly implemented UDM, questions become answerable that are otherwise nearly impossible to address: Which process curves correspond to the NOK parts from Customer X at Plant Y? How does OEE for a given product family differ across plants? Which lines are real bottlenecks – based on data, not intuition?

Architecture: The UDM as Central Data Layer

In a modern digital factory architecture, the Unified Data Model sits between the source systems and the analytics and reporting layers:

Source systems (ERP, MES, SCADA, historian, CMMS, QMS) deliver data in their native formats. An integration or ETL layer extracts, normalizes, and maps this data onto the UDM – either in batch mode or via streaming. The Unified Data Layer stores the harmonized data, for example in a cloud database, a lakehouse, or a specialized platform. The consumption layer – dashboards, KPI apps, analytics models, reporting tools – accesses only this unified layer, not each source system individually.

The practical effect: new analytics use cases build on a model that has already been defined. When a new system is added, it needs to be connected to the UDM once – not to every other existing system separately.

Measurable Benefits of a Unified Data Model

Consistent KPIs across plants: OEE, First Pass Yield, Scrap, Lead Time, and On-Time Delivery are comparable across plants, lines, and products – because they are calculated from the same data foundation.

Faster implementation of new use cases: New reports, dashboards, or analytics models can be built faster because data structures and relationships are already defined. The question "What does an order actually mean in this context?" has already been answered.

Reduced integration effort during system changes: When an MES or BI tool is replaced, only the connection to the UDM needs to be rebuilt – not the integration with every other system.

Shared language between IT, OT, and business: All stakeholders work with the same entities and terminology instead of debating system tables and proprietary IDs. This reduces misunderstandings and accelerates project work.

Foundation for data-driven decisions: Without a UDM, data remains fragmented and difficult to compare. With a UDM, a coherent, reliable view of the entire factory becomes possible.

Frequently Asked Questions About the Unified Data Model

Is a Unified Data Model the same as a data warehouse? No. A data warehouse is a technical platform for storing data. The UDM is the conceptual model that defines which entities exist, how they relate to each other, and what they mean. A UDM can be implemented on a data warehouse, a lakehouse, or other architectures.

Do I need a UDM if I only have one MES and one ERP? With two systems, the integration effort is still manageable. As soon as a historian, energy monitoring, CMMS, or BI platform is added, a UDM becomes economically justified: it prevents an unmanageable web of bilateral integrations and eliminates KPI inconsistencies.

Is a Unified Data Model a one-time project? No – it's a living model. The pragmatic approach: start with the most important entities (Site, Line, Machine, Order, Product, core KPIs) and expand iteratively. Clear governance that defines how changes are introduced is essential throughout.

Who owns the UDM – IT or OT? In practice, responsibility typically sits with a hybrid team of IT architects, OT specialists, and business representatives. None of the three groups can define a meaningful UDM alone: IT knows the systems, OT knows the processes, and business knows what decisions need to be supported.