ERP-Integration in der Fertigung: SAP, Dynamics und Navision an den Shopfloor anbinden

Jeder Hersteller, der ERP und Shopfloor-Systeme parallel betreibt, stößt irgendwann auf dieselbe Diskrepanz. Das ERP zeigt einen Auftrag als abgeschlossen; die Fertigung weiß, dass zwei Paletten nachgearbeitet wurden. Das ERP zeigt Material in Standardmenge verbraucht; der tatsächliche Verbrauch enthielt Ausschuss, den niemand gebucht hat. Keines der Systeme lügt. Sie beschreiben verschiedene Momente — das ERP beschreibt den Plan und seine finanziellen Folgen, der Shopfloor beschreibt die physische Realität — und Integration ist die Disziplin, beide Beschreibungen in Übereinstimmung zu halten.

Die erste Entwurfsentscheidung ist die Richtung der Datenhoheit, und sie falsch zu treffen ist die häufigste Ursache für Integrationsprojekte, die nie stabil werden. Stammdaten — Kunden, Lieferanten, Materialien, Stücklisten, Arbeitspläne, Preise — gehören ins ERP und fließen nach unten. Ausführungsdaten — tatsächliche Start- und Endzeiten, gefertigte Mengen, Ausschuss, Stillstandsgründe, Maschinenzustände, Personalzuordnungen, realer Materialverbrauch — entstehen in der Fertigung und fließen nach oben. Wenn beide Systeme dasselbe Objekt bearbeiten dürfen, haben Sie keine Integration, sondern einen wiederkehrenden Streit mit Synchronisationsplan.

Der Fluss nach unten ist meist die einfachere Hälfte. Im ERP freigegebene Fertigungsaufträge erscheinen im MES mit Arbeitsgängen, Arbeitsplänen und Materiallisten. Änderungen am Artikelstamm werden weitergereicht. Kunden- und Lieferdaten erreichen die Systeme, die sie brauchen. Die praktische Hauptschwierigkeit ist die Granularität: Ein ERP-Fertigungsauftrag entspricht häufig mehreren Shopfloor-Arbeitsgängen an verschiedenen Arbeitsplätzen, und das Mapping zwischen ERP-Struktur und ausführbarer Struktur muss bewusst definiert und nicht stillschweigend angenommen werden.

Der Fluss nach oben ist der wertvolle und zugleich schwierigere Teil. Rückmeldungen — die Meldungen, dass dieser Arbeitsgang diese Menge produziert, dieses Material verbraucht, so lange gedauert und so viel Ausschuss erzeugt hat — steuern die Bestands-, Kalkulations- und Kapazitätszahlen des ERP. Wenn sie automatisch aus Maschinen und Bedienterminals erfasst werden statt am Schichtende aus dem Gedächtnis eingetippt, hören die ERP-Zahlen auf, Näherungen zu sein. Die Kalkulation verbessert sich sofort, weil Ist-Zeiten an die Stelle von Vorgabezeiten treten.

Die verfügbaren Integrationsmuster unterscheiden sich vor allem in Latenz und Kopplung. Dateibasierter Austausch ist einfach, überall unterstützt und unvermeidlich stapelorientiert. Direkter Datenbankzugriff ist schnell und fragil und bricht bei Herstellerupdates auf schwer vorhersehbare Weise. REST- und SOAP-Schnittstellen — SAP über IDoc, BAPI oder OData; Dynamics 365 und Business Central über ihre veröffentlichten APIs — sind der moderne Standard und versionieren deutlich verträglicher. Message Queues bringen zusätzliche Robustheit für hochfrequente Ereignisse, denn die Fertigung produziert weiter Daten, ob das ERP verfügbar ist oder nicht.

Dieser letzte Punkt verdient Nachdruck, weil sich hier fragile Integrationen zeigen. Die Produktion hält nicht an, wenn das ERP anhält. Ist Ihre Integration synchron und das ERP wegen geplanter Wartung nicht erreichbar, steht entweder die Fertigung oder die Daten gehen verloren. Ein gepuffertes, warteschlangenbasiertes Design lässt das MES weiter erfassen und den Rückstand nachliefern, sobald die Verbindung zurück ist — und in einer Fabrik im Mehrschichtbetrieb ist das kein Randfall, sondern monatliche Realität.

Lokale und regionale ERP-Systeme verkomplizieren das Bild auf spezifische Weise. Globale Suiten haben dokumentierte Schnittstellen und große Integrationsökosysteme. Regionale Produkte — Panteon, Logo, Nebim und ihre Entsprechungen in anderen Märkten — sind bei mittelständischen Herstellern weit verbreitet, oft tief angepasst und verfügen selten über einen fertigen MES-Konnektor. Das ist kein Grund, ein funktionierendes ERP zu ersetzen. Es ist ein Grund, die Integrationsschicht als vollwertigen Projektbestandteil zu behandeln statt als angenommene Nebensache.

Der Abgleich ist der Teil, der aus Projektplänen herausfällt und dann die ersten drei Betriebsmonate frisst. Nachrichten schlagen fehl. Eine Rückmeldung wird abgewiesen, weil ein Material gesperrt war. Ein Fertigungsauftrag wird im ERP gelöscht, nachdem die Fertigung ihn bereits begonnen hat. Jede Integration braucht eine einsehbare Warteschlange, einen Wiederholmechanismus, einen Fehlerzustand, der einen Menschen alarmiert, und einen regelmäßigen Abgleichbericht, der belegt, dass Fertigungsaufzeichnungen und ERP-Bestand weiterhin übereinstimmen. Integrationen ohne diese Elemente scheitern nicht laut; sie driften still, was schlimmer ist.

Der Zuschnitt, der den Kontakt mit der Realität übersteht: mit einem Auftragstyp auf einer Linie beginnen, den vollständigen Kreislauf von der ERP-Freigabe über die Shopfloor-Ausführung bis zur Rückmeldung ins ERP nachweisen — und erst dann ausweiten. Big-Bang-Integrationen über alle Werke und Auftragstypen zugleich scheitern auf äußerst schwer diagnostizierbare Weise, denn wenn alles neu ist, taugt nichts als Referenz.