Unified Data Model (UDM): Bedeutung, Aufbau und Nutzen

Wer in einer Fabrik mit mehreren Systemen arbeitet – ERP, MES, SCADA, Historian, Energiemonitoring – kennt das Problem: Jedes System hat seine eigene Logik, seine eigene Terminologie, seine eigenen IDs. Was im ERP „Order" heißt, ist im MES ein „Job" und im SCADA-System ein „Batch". Was auf Ebene der Linienplanung eine „Linie" ist, nennt dasselbe System anderswo „Work Center" oder „Cell".

Ein Unified Data Model (UDM) löst genau dieses Problem. Es ist ein einheitliches, systemübergreifendes Datenmodell, das alle relevanten Produktionsobjekte konsistent beschreibt – unabhängig davon, aus welchem System die Daten ursprünglich stammen. Das Ergebnis: Daten werden einmal sauber modelliert und können danach in allen Anwendungen genutzt werden, ohne jedes Mal neue Mapping-Logik aufzubauen.

Warum ein Unified Data Model? Das Problem ohne gemeinsames Modell

In der Praxis entstehen ohne UDM drei Probleme, die direkt auf die Betriebswirtschaft einzahlen:

Widersprüchliche Kennzahlen: OEE wird für Werk A aus dem MES gezogen, für Werk B aus einem Excel-Export, für Werk C aus dem Historian. Die Ergebnisse sind nicht vergleichbar – nicht weil die Anlagen unterschiedlich sind, sondern weil die Datenbasis nicht konsistent ist. Strategische Entscheidungen auf Basis solcher Zahlen sind riskant.

Explodierender Integrationsaufwand: Jede neue Auswertung – Energieverbrauch je Auftrag, Traceability bis zur Seriennummer, Predictive-Maintenance-Modell – erfordert eigene Integrationslogik, eigene Mappings, eigene Tests. Bei vier Systemen und zehn Use Cases entsteht schnell ein kaum wartbares Netz aus Point-to-Point-Verbindungen.

Excel als Dauerlösung: Wenn kein gemeinsames Modell existiert, werden Lücken mit Tabellenkalkulationen überbrückt. Das ist kein Designfehler einzelner Teams, sondern eine systemische Konsequenz fehlender semantischer Klammer.

Ein Unified Data Model wirkt als diese Klammer: Es mappt ERP-Objekte, MES-Ereignisse und SCADA-Prozessdaten auf ein einziges, fachlich sauberes Modell.

Was enthält ein Unified Data Model in der Fertigung?

Ein UDM im Fertigungskontext ist fachlich orientiert, nicht systemorientiert. Es beschreibt, wie die reale Produktion aussieht – nicht, wie ein einzelnes System sie intern speichert. Typische Entitäten sind:

Organisation und Struktur: Enterprise, Site, Area, Line, Work Center, Machine, Asset. Diese Hierarchie bildet den räumlichen und organisatorischen Rahmen, in den alle anderen Daten eingeordnet werden.

Auftrags- und Produktwelt: Customer, Product, Variant, Bill of Materials, Routing, Production Order, Operation, Batch, Lot, Serial Number. Ohne diese Entitäten lassen sich Produktionsdaten nicht mit Geschäftsprozessen verknüpfen.

Ressourcen und Stammdaten: Material, Tooling, Equipment, Personnel, Shift, Calendar. Diese Daten bestimmen, unter welchen Bedingungen produziert wurde – und sind Voraussetzung für aussagekräftige Ursachenanalysen.

Prozess- und Eventdaten: Statusänderungen (Start, Stop, Rüsten, Störung), Zähler, Prozesswerte (Temperatur, Druck, Drehmoment), Qualitätsereignisse (OK/NOK, Prüfwerte), Wartungsereignisse. Diese Ebene spiegelt das wider, was auf dem Shopfloor tatsächlich passiert.

KPIs und Kennzahlen: OEE, Availability, Performance, Quality, First Pass Yield, Scrap, Rework, Durchsatz, Durchlaufzeit. Kennzahlen, die auf dem UDM basieren, sind automatisch über alle Werke, Linien und Produkte vergleichbar.

UDM vs. gemeinsames Datenformat: Wo liegt der Unterschied?

Ein verbreitetes Missverständnis: „Wir nutzen überall JSON – das ist doch ein einheitliches Format." Ein gemeinsames Datenformat ist notwendig, aber nicht ausreichend.

Ein Unified Data Model geht drei Schritte weiter:

Semantik statt nur Struktur: Es reicht nicht, Spaltennamen zu harmonisieren. Man muss klären, was ein „Order" in diesem Unternehmen exakt bedeutet – welche Felder er hat, welchen Status er annehmen kann, welche Beziehungen er zu anderen Entitäten hat. Zwei Systeme können beide JSON liefern und trotzdem vollständig unterschiedliche Konzepte unter „Order" verstehen.

Beziehungen und Hierarchien: Welche Maschine gehört zu welcher Linie? Welcher Auftrag erzeugt welche Seriennummern? Wie hängen Batch, Lot und Qualitätsergebnis zusammen? Diese Relationen sind es, die aus Rohdaten auswertbare Information machen.

Governance: Wer definiert, pflegt und ändert das Modell? Wie werden neue Entitäten oder Felder eingeführt, ohne bestehende Auswertungen zu brechen? Ohne Governance wird ein UDM schnell zum unkontrollierten Wildwuchs.

Rolle im Zusammenspiel von ERP, MES und SCADA

Die drei Systemebenen haben im UDM klar unterschiedliche Rollen:

ERP liefert das „obere Ende": Kunden, Produkte, Aufträge, Kosten, Liefertermine. Das UDM mappt diese Objekte auf die Produktionsrealität – ein ERP-Produktionsauftrag wird einer konkreten Linie, einem Work Center und einem Asset zugeordnet.

MES deckt die mittlere Ebene ab: Ausführung der Produktion, Work in Progress, OEE, Traceability, Qualitäts-Workflows. MES-Ereignisse – Starts, Stopps, Stillstände, NOK-Meldungen, Prüfergebnisse – werden als datierte Events im UDM abgelegt und bleiben so dauerhaft nachvollziehbar.

SCADA, Automatisierung und Historian liefern die unterste Ebene: Prozess- und Maschinensignale, Alarme, Kurven, Zustände. Diese Rohdaten werden über Asset, Operation und Auftrag im UDM kontextualisiert – erst dadurch lassen sich Prozesskurven einem bestimmten Teil, einer bestimmten Schicht oder einem bestimmten Kunden zuordnen.

Mit einem sauber implementierten UDM sind Fragen beantwortbar, die ohne gemeinsames Modell kaum zu beantworten sind: Welche Prozesskurven gehören zu den NOK-Teilen von Kunde X im Werk Y? Wie unterscheidet sich die OEE einer Produktfamilie über verschiedene Werke hinweg? Welche Linien sind reale Engpässe – nach Daten, nicht nach Bauchgefühl?

Architektur: Das UDM als zentraler Datenlayer

In einer modernen Digital-Factory-Architektur sitzt das Unified Data Model zwischen den Quellsystemen und den Analyse- und Reporting-Schichten:

Die Quellsysteme (ERP, MES, SCADA, Historian, CMMS, QMS) liefern Daten in ihren nativen Formaten. Eine Integrations- oder ETL-Schicht extrahiert, normalisiert und mappt diese Daten auf das UDM – entweder batch-basiert oder per Streaming. Der Unified Data Layer speichert die harmonisierten Daten, beispielsweise in einer Cloud-Datenbank, einem Lakehouse oder einer spezialisierten Plattform. Der Consumption Layer – Dashboards, KPI-Apps, Analytics-Modelle, Reporting-Tools – greift ausschließlich auf diesen einheitlichen Layer zu, nicht direkt auf jedes Quellsystem.

Der praktische Effekt: Neue Auswertungen bauen auf einem einmal definierten Modell auf. Kommt ein neues System hinzu, wird es einmalig an das UDM angebunden – nicht an jedes andere bereits vorhandene System einzeln.

Messbare Vorteile eines Unified Data Model

Konsistente Kennzahlen werksübergreifend: OEE, First Pass Yield, Scrap, Durchlaufzeit und Termintreue sind über Werke, Linien und Produkte hinweg vergleichbar – weil sie auf derselben Datenbasis berechnet werden.

Schnellere Umsetzung neuer Use Cases: Neue Reports, Dashboards oder Analytics-Modelle lassen sich schneller aufbauen, weil Datenstrukturen und Beziehungen bereits definiert sind. Die Frage „Was bedeutet eigentlich ein Auftrag in diesem Kontext?" ist bereits beantwortet.

Reduzierter Integrationsaufwand bei Systemwechseln: Wenn ein MES oder BI-Tool ausgetauscht wird, muss nur die Anbindung an das UDM neu gebaut werden – nicht die Integration zu jedem anderen System.

Gemeinsame Sprache zwischen IT, OT und Business: Alle Beteiligten arbeiten mit denselben Begriffen und Entitäten, statt über Systemtabellen und proprietäre IDs zu diskutieren. Das reduziert Missverständnisse und beschleunigt Projektarbeit.

Grundlage für datengetriebene Entscheidungen: Ohne UDM bleiben Daten fragmentiert und schwer vergleichbar. Mit UDM entsteht eine fachlich saubere, belastbare Sicht auf die gesamte Fabrik.

Häufige Fragen zum Unified Data Model

Ist ein Unified Data Model dasselbe wie ein Data Warehouse? Nein. Ein Data Warehouse ist eine technische Plattform zur Datenspeicherung. Das UDM ist das fachliche Modell, das definiert, welche Entitäten existieren, wie sie sich zueinander verhalten und was sie bedeuten. Ein UDM kann auf einem Data Warehouse, einem Lakehouse oder einer anderen Architektur umgesetzt werden.

Brauche ich ein UDM, wenn ich nur ein MES und ein ERP habe? Bei zwei Systemen ist der Aufwand noch überschaubar. Sobald Historian, Energiemonitoring, CMMS oder BI-Plattformen hinzukommen, wird ein UDM wirtschaftlich: Es verhindert das Entstehen eines unkontrollierten Netzes aus bilateralen Integrationen und verhindert KPI-Inkonsistenzen.

Ist ein Unified Data Model ein einmaliges Projekt? Nein, es ist ein lebendes Modell. Der pragmatische Ansatz: Mit den wichtigsten Entitäten starten – Site, Line, Machine, Order, Product, Kern-KPIs – und iterativ erweitern. Entscheidend ist dabei eine klare Governance, die regelt, wie Änderungen eingeführt werden.

Wer ist für das UDM verantwortlich – IT oder OT? In der Praxis liegt die Verantwortung meist in einem hybriden Team aus IT-Architekten, OT-Spezialisten und Business-Vertretern. Keiner der drei Bereiche kann ein sinnvolles UDM allein definieren: IT kennt die Systeme, OT kennt die Prozesse, Business kennt die Entscheidungsbedarfe.