Altsysteme anbinden statt ablösen

Das Missverständnis

Wenn Daten aus der Fertigung nicht im ERP ankommen, lautet die erste Diagnose fast immer: „Unser ERP ist zu alt.“ Daraus folgt ein Ablöseprojekt — sechsstellig, ein bis zwei Jahre Laufzeit, mit erheblichem Risiko für den laufenden Betrieb.

In vielen Fällen ist die Diagnose falsch. Das ERP erfüllt seine eigentliche Aufgabe meist gut: Aufträge, Bestände und Buchhaltung laufen seit Jahren stabil. Was fehlt, ist nicht ein neues System, sondern eine Verbindung zwischen dem, was in der Fertigung passiert, und dem, was das ERP weiß.

Woran man den Unterschied erkennt

Das ERP ist wirklich das Problem, wenn:

• fachliche Anforderungen nicht abbildbar sind, etwa neue Geschäftsmodelle oder Chargenrückverfolgung
• der Hersteller den Support eingestellt hat und keine Sicherheitsupdates mehr liefert
• die Datenstruktur den Prozess so verzerrt, dass Auswertungen grundsätzlich unbrauchbar sind

Nur die Anbindung fehlt, wenn:

• Zahlen manuell aus einem System ins andere übertragen werden
• Rückmeldungen aus der Fertigung verspätet oder gar nicht ankommen
• Auswertungen in Excel entstehen, weil die Daten dort zusammengeführt werden müssen
• die Fachbereiche mit dem ERP zufrieden sind, aber Nebensysteme betreiben

Der zweite Fall ist der häufigere — und deutlich günstiger zu lösen.

Warum Punkt-zu-Punkt-Verbindungen scheitern

Der erste Impuls ist, Anlage und ERP direkt zu verbinden. Bei einer Anlage funktioniert das. Bei fünf Anlagen und drei Zielsystemen entstehen fünfzehn Einzelverbindungen, jede mit eigenem Format und eigener Fehlerbehandlung. Ändert sich ein System, müssen alle angefassten Verbindungen nachgezogen werden.

Diese Struktur wächst quadratisch und wird ab einer gewissen Größe unwartbar. Sie ist der eigentliche Grund, warum Integrationsprojekte im Mittelstand scheitern — nicht die Technik der Einzelverbindung.

Das Muster: eine Datendrehscheibe

Statt jedes System mit jedem zu verbinden, kommunizieren alle Systeme mit einer zentralen Stelle. Diese kennt die Formate, übersetzt zwischen ihnen, protokolliert jeden Vorgang und puffert bei Ausfällen.

Der Aufwand pro zusätzlichem System bleibt dadurch konstant. Und jedes einzelne System — auch das ERP — kann später ausgetauscht werden, ohne dass alle anderen betroffen sind.

Welche Daten dabei fließen

In der Fertigung gibt es dafür zwei unterschiedliche Übergänge. Sie sehen auf den ersten Blick ähnlich aus, verhalten sich aber grundverschieden — und genau diese Unterscheidung entscheidet später über die Architektur:

Übergang 1 — zwischen ERP und Fertigungssteuerung. Hier trifft die kaufmännische Planung auf die Werkstatt. Getaktet in Minuten bis Stunden; fällt die Verbindung kurz aus, wird nachgeholt.

Richtung	Inhalt
Zur Fertigung hin	Aufträge, Stücklisten, Prüfvorgaben, Termine
Zum ERP zurück	Rückmeldungen, Mengen, Zeiten — die Betriebsdatenerfassung (BDE)

Übergang 2 — zwischen Software und Anlage. Hier trifft Software auf Maschine. Getaktet in Sekunden bis Millisekunden; hier darf nichts verloren gehen, weil sich ein Messwert nicht nachträglich erzeugen lässt.

Richtung	Inhalt
Zur Anlage hin	Rezepte, Parameter, Freigaben
Von der Anlage zurück	Messwerte, Zustände, Störungen — die Maschinendatenerfassung (MDE)

Warum das praktisch wichtig ist: Der obere Übergang verzeiht Verzögerungen, der untere nicht. Wer beide gleich behandelt, baut entweder eine unnötig aufwendige ERP-Anbindung oder — der häufigere und teurere Fehler — eine Anlagenanbindung, die unter Last Daten verliert. Eine Datendrehscheibe bedient beide Übergänge, aber mit unterschiedlichen Regeln für Pufferung, Wiederholung und Fehlerbehandlung.

Aus der Praxis: Ein Elektronikfertiger mit rund 1.000 Mitarbeitern betrieb ein ERP auf veraltetem Techstack, das sich weder ablösen noch modernisieren ließ. Statt einer Ablösung entstand eine modulare Datendrehscheibe zwischen den Produktionsanlagen mit Omron-Steuerungen und dem Altsystem. Auftragslenkung, BDE, MDE und Qualitätsdaten fließen seither automatisch. Das ERP blieb unverändert im Betrieb.

Wenn es keine Schnittstelle gibt

Ältere Systeme haben oft keine dokumentierte API. Das schließt eine Anbindung nicht aus — es verschiebt nur die Frage, an welcher Stelle man ansetzt:

• Direkter Datenbankzugriff, lesend meist unproblematisch, schreibend nur nach sorgfältiger Prüfung der Konsistenzregeln
• Dateibasierter Austausch über definierte Verzeichnisse — unelegant, aber robust und von praktisch jedem System unterstützt
• Auswertung vorhandener Ausgaben wie Druckdatenströme oder Exportdateien, wenn kein anderer Weg besteht
• Zwischendatenbank, in die beide Seiten schreiben, ohne einander zu kennen

Welcher Weg der richtige ist, entscheidet sich an Ihrem konkreten System — und daran, wie viel Änderungsrisiko Sie tragen wollen.

Der pragmatische Einstieg

Beginnen Sie mit einer Datenstrecke, nicht mit dem Gesamtbild. Nehmen Sie die, die heute die meiste manuelle Arbeit verursacht. Ist diese Strecke produktiv und stabil, ist das Muster bewiesen und jede weitere folgt demselben Schema.

Ein Startprojekt über vier Wochen liefert genau das: einen lauffähigen Prototyp an einer realen Datenstrecke. Danach wissen Sie belastbar, ob der Weg trägt — ohne dass ein Ablöseprojekt beschlossen werden musste.