In gewachsenen Fertigungsbetrieben laufen ERP, MES und die Sensorik auf der Maschinenebene wie drei getrennte Betriebe unter einem Dach. Auftragsdaten liegen im ERP, Fertigungsaufträge und Qualitätsdaten im MES, Maschinenzustände in einer SPS oder einem IoT-Gateway – und dazwischen klaffen Lücken, die sich mit Excel-Listen, manuellen Übertragungen oder Bauchgefühl überbrücken lassen. Das Ergebnis sind Verzögerungen bei der Auswertung, lückenhafte Rückverfolgbarkeit und Entscheidungen auf Basis veralteter Zahlen. Die Auflösung dieser Silos ist kein reines IT-Projekt, sondern eine Frage der Architektur, der Priorisierung und der Bereitschaft, nicht alles gleichzeitig anzufassen.
Warum ERP, MES und IoT aneinander vorbeireden
Die drei Systemebenen sind historisch für unterschiedliche Zwecke entstanden und wurden selten mit dem Ziel gebaut, miteinander zu kommunizieren. Das ERP bildet kaufmännische und logistische Prozesse ab und denkt in Aufträgen, Stücklisten und Stammdaten. Das MES steuert den Shopfloor, verwaltet Chargen, Schichten und Qualitätsmeldungen. Die IoT- und SPS-Ebene liefert rohe Maschinen- und Sensordaten deutlich häufiger als ERP oder MES. Jede Ebene kann von unterschiedlichen Herstellern, zu unterschiedlichen Zeitpunkten und mit unterschiedlichen Standards eingeführt worden sein – teilweise sogar pro Linie oder Werk unterschiedlich. Wer heute versucht, diese Systeme nachträglich zu verbinden, stößt selten auf ein rein technisches Problem, sondern auf über Jahre gewachsene Insellösungen, die einzeln funktionieren, aber nie als Ganzes gedacht wurden.
Drei Systeme, drei Zeitskalen, drei Wahrheiten
Neben der reinen Schnittstellenfrage gibt es ein semantisches Problem: Ein „Auftrag“ im ERP ist nicht dasselbe wie ein „Fertigungsauftrag“ im MES, und ein „Stillstand“ bedeutet für eine Maschine etwas anderes als für eine Produktionslinie in der Betriebswirtschaft. Ohne ein gemeinsames Verständnis dieser Begriffe führt jede Integration zu Fehlinterpretationen, selbst wenn die technische Verbindung fehlerfrei funktioniert. Hinzu kommt die unterschiedliche Taktung: In vielen Implementierungen werden ERP-Daten in Tages- oder Wochenzyklen aktualisiert, MES-Daten schichtweise und Maschinendaten deutlich häufiger – zwingend ist das nicht, sondern eine Frage der jeweiligen Konfiguration. Eine Integrationsarchitektur muss diese unterschiedlichen Zeitskalen bewusst zusammenführen, statt sie durch starre Punkt-zu-Punkt-Anbindungen künstlich zu synchronisieren.
Strategien für die Industrie 4.0 Datenintegration ohne Produktionsstillstand
Alle Systeme gleichzeitig umzubauen, erhöht in Integrationsprojekten der Fertigung das Risiko unnötig. Der gleiche Grundsatz, der bereits für die Modernisierung gewachsener IT-Landschaften ohne Big Bang gilt, lässt sich auf die Fertigungsintegration übertragen: Modul für Modul, mit klaren Rückfallebenen. Ein Vorgehen, das die Abhängigkeiten schrittweise sichtbar macht:
- Mit einem klar abgegrenzten Pilotbereich starten – eine Linie oder ein Werk, nicht der gesamte Standort
- Bestehende Standards nutzen, wo sie bereits vorhanden sind (OPC UA, MQTT), statt proprietäre Zusatzprotokolle einzuführen
- Integration zunächst lesend aufbauen – keine Rückschreibevorgänge in produktive ERP- oder MES-Systeme in der ersten Phase
- Bestehende Meldewege parallel weiterlaufen lassen, bis die neuen Datenpfade nachweislich zuverlässig sind
- Erst nach stabilem Betrieb auf weitere Linien oder Standorte ausrollen
Referenzarchitektur: eine Datenschicht statt Punkt-zu-Punkt-Verbindungen
Punkt-zu-Punkt-Verbindungen zwischen ERP, MES und einzelnen Maschinen skalieren schlecht: Im ungünstigsten Fall einer vollständigen Vermaschtung steigt die Anzahl der Verbindungen mit jedem neuen System quadratisch, und jede Änderung an einer Schnittstelle riskiert, mehrere andere zu brechen. Tragfähiger ist eine vermittelnde Datenschicht, über die Systeme Ereignisse veröffentlichen und andere Systeme sie bei Bedarf konsumieren, ohne direkt voneinander abhängig zu sein. Technologien wie Apache Kafka eignen sich für diesen Zweck, sind aber kein Selbstzweck: Wo keine Echtzeitreaktion erforderlich ist, reicht eine klassische, zeitgesteuerte Batch-Synchronisation aus. Die Entscheidung zwischen Streaming und Batch sollte am tatsächlichen Anwendungsfall hängen: Eine Maschinenüberwachung mit Alarmfunktion braucht Echtzeit, eine tägliche OEE-Auswertung meist nicht. Historische Auswertungen gehören zudem in einen separaten Data Hub oder Data Lake, der von der operativen Kopplung getrennt ist – so bleibt der laufende Betrieb unberührt, wenn Analysten oder Data Scientists auf große Datenmengen zugreifen.
Was Integration nicht löst: Governance und Verantwortlichkeiten
Eine technisch saubere Integration löst nicht automatisch die Frage, wer für die Qualität der Daten verantwortlich ist. Wenn Stammdaten im ERP fehlerhaft gepflegt werden oder ein Sensor systematisch falsche Werte liefert, verbreitet sich dieser Fehler nun schneller und weiter als zuvor – die Silo-Auflösung macht Datenqualitätsprobleme sichtbarer, nicht kleiner. Wichtig ist deshalb, Zuständigkeiten zwischen IT, OT und Fachbereich vor der technischen Umsetzung zu klären: Wer korrigiert Stammdaten, wer validiert Sensorwerte, wer entscheidet über Änderungen an Datenmodellen?
Eine Datenintegration ist immer nur so belastbar wie das schwächste Glied in der Verantwortungskette – nicht wie die schnellste Schnittstelle.
Der nächste Schritt
Statt mit einer vollständigen Architekturplanung zu beginnen, lohnt sich der umgekehrte Weg: einen konkreten, begrenzten Anwendungsfall definieren – etwa die automatisierte OEE-Berechnung für eine Linie oder die lückenlose Rückverfolgbarkeit einer Charge – und ausgehend davon festlegen, welche Datenflüsse dafür tatsächlich notwendig sind. Das begrenzt Risiko und Aufwand und liefert schnell einen belastbaren Nachweis, ob der gewählte Integrationsansatz trägt, bevor er auf weitere Linien oder Werke übertragen wird. Wer die Datenschicht dabei nicht isoliert, sondern als Grundlage für weiterführende Auswertungen plant, findet dazu Anknüpfungspunkte im Bereich Data Engineering.
Häufige Fragen
Nur dann, wenn ein System keine dokumentierte Schnittstelle bietet oder der Hersteller den Support eingestellt hat. Ansonsten setzt die Integration auf den bestehenden Systemen auf und greift deren Daten über vorhandene Schnittstellen ab. Diese Entscheidung sollte unabhängig vom Integrationsprojekt fallen.
OPC UA bringt ein eigenes Informationsmodell mit und beschreibt Maschinendaten semantisch. MQTT ist ein schlankes Transportprotokoll ohne Datenmodell und eignet sich, wenn viele Geräte mit wenig Rechenleistung Daten an eine zentrale Stelle melden. Beide Protokolle schließen sich nicht aus: Sie lassen sich kombinieren, etwa wenn ressourcenarme Sensorik ihre Werte per MQTT an ein Gateway sendet, das die Daten anschließend mit semantischem Kontext über OPC UA weiterreicht.
Eine seriöse Zeitangabe ist ohne konkretes Scoping nicht möglich: Wie lange ein Pilotprojekt dauert, hängt vom Reifegrad der vorhandenen Schnittstellen und davon ab, wie schnell Zuständigkeiten für Datenmodelle geklärt sind. Diese Abstimmung entscheidet über die Dauer stärker als die technische Anbindung selbst.
Nicht auf eine vollständige Bereinigung warten. Sinnvoller ist, den Pilotbereich so zu wählen, dass die dort benötigten Stammdaten überschaubar bleiben, und die Bereinigung auf diesen Ausschnitt zu begrenzen. Die Integration macht bestehende Fehler sichtbarer – unangenehm, aber der schnellste Weg zu belastbaren Daten.
Transparenzhinweis: Bei der Erstellung dieses Beitrags wurde generative KI unterstützend eingesetzt. Inhalt, Faktenprüfung und finale Redaktion erfolgten durch Ancud
