Industrial MachineryLuxury, Fashion & ApparelChemicals & MaterialsAutomotiveAPI IntegrationCustom Software DevelopmentIndustry 4.0

Mehr als EDI: Die Integrationsarbeit, die Hersteller wirklich brauchen, um ERP, WMS und PLM zu verbinden

EDI-Netzwerke setzen voraus, dass ERP, WMS und PLM bereits miteinander sprechen. Bei den meisten Herstellern ist das nicht der Fall. Das ist die Integrationsarbeit, die zuerst passieren muss.

Foto: Google Gemini · AI-generated

Alle paar Monate verspricht ein neues multi-enterprise Netzwerk, Hersteller über standardisierte EDI-Transaktionen mit Lieferanten, Lagern und Kunden zu verbinden. Das Versprechen klingt überzeugend: einmal ans Netzwerk andocken, und ERP, WMS und TMS sprechen plötzlich mit allen anderen. Für Hersteller mit einem hohen Volumen standardisierter Handelsbeziehungen ist dieser Nutzen real.

Bei den meisten Herstellern, mit denen wir arbeiten — in der industriellen Fertigung, in Luxury & Fashion, in der Chemieindustrie und in der Automobilbranche —, liegt der eigentliche Engpass jedoch eine Ebene tiefer, noch bevor sich überhaupt eine EDI-Transaktion lohnt: Die eigenen internen Systeme sprechen noch nicht zuverlässig miteinander.

Der Engpass liegt vor dem Netzwerk

EDI-Netzwerke setzen auf beiden Seiten einen kohärenten Systemstack voraus — ein ERP, ein WMS, ein TMS, alle bereit, standardisierte Dokumente zu senden und zu empfangen. Mittelständische Hersteller starten selten von dieser Position aus. Das Warenwirtschaftssystem eines Bekleidungsherstellers teilt sich kein Produktkennungsschema mit der Plattform, die den Verkauf trackt. Ein Netzwerk aus Verkaufskiosken hat keine native Verbindung zum SAP-Backend, das im Hintergrund jede Transaktion verbucht. Das ERP eines Einkaufsteams beherrscht Finanzen und Bestand zuverlässig, hat aber überhaupt keinen Beschaffungsworkflow.

Nichts davon ist ein EDI-Problem. Es ist ein Integrationsproblem — und es muss gelöst sein, bevor eine Netzwerkanbindung oder überhaupt ein externer Datenaustausch auf beiden Seiten belastbare Daten liefert.

Heterogenität ist der Normalfall, nicht die Ausnahme

Spricht man mit genug Herstellern, zeigt sich ein Muster: Das ERP wurde für die Finanzabteilung ausgewählt, das WMS für den spezifischen Workflow des Lagerteams (oder eigens dafür gebaut), und das PLM-Tool — sofern es überhaupt eines gibt — kam Jahre später dazu, oft nach einer Übernahme. Keines dieser Systeme wurde mit Blick auf die anderen ausgewählt. Jedes ist für sich genommen korrekt und von den übrigen getrennt.

Das zeigt sich je nach Branche unterschiedlich. In der Bekleidungs- und Modeherstellung sind es Abweichungen bei SKUs und Varianten — dasselbe Produkt wird in Bestand, Vertrieb und Fulfillment unter unterschiedlichen Kennungen, Größen und Farben geführt. In der industriellen Fertigung ist es ein ERP, das nie ein Beschaffungs- oder Lieferantenmanagement-Modul hatte, weshalb die Beschaffung stattdessen über Excel-Tabellen läuft. In der Chemieindustrie sind es im Feld erfasste Compliance-Daten, die mit lückenlosem Audit-Trail in ein System of Record gelangen müssen. In Lieferketten der Automobilindustrie zeigt sich dasselbe Grundmuster bei Stücklisten- und PLM-Daten, die über mehrere Zulieferstufen hinweg sauber in ERP und WMS einfließen müssen. Unterschiedliche Branchen, dasselbe zugrunde liegende Problem: heterogene Systeme, die nie füreinander gebaut wurden.

Wie das in der Praxis aussieht

Wir haben diese Integrationsschicht als individuelle Software gebaut, nicht als Abonnement für das Netzwerk eines Drittanbieters — weil die tatsächliche Lücke in jedem Fall so spezifisch war, dass ein generischer Konnektor sie nicht geschlossen hätte. Ein Einkaufsportal hat das bestehende Sage-100-ERP eines Herstellers um einen maßgeschneiderten Beschaffungsworkflow für ein globales Lieferantennetzwerk erweitert — Bestellstatus, Versandupdates und Lieferdaten fließen automatisch ins ERP zurück, ganz ohne erneute manuelle Erfassung. Eine Supply-Chain-Intelligence-Plattform sitzt für einen Bekleidungshersteller zwischen Zoho Inventory und Sellerboard, löst SKU- und Variantenabweichungen auf und liefert dem Management eine einzige, abgeglichene Sicht auf Bestand und Profitabilität, die keines der beiden Systeme allein liefern konnte. Eine Mobile Kiosk App für einen Schmuckhersteller verbindet sich über 500+ Verkaufsstellen in Europa mit einer bestehenden SAP-Middleware-Schicht, ohne das Backend anzufassen. Eine Besucher-Compliance-App integriert sich über eine eigens gebaute Middleware in das bestehende Besuchermanagementsystem eines Herstellers über mehrere Standorte hinweg. ReportSync synchronisiert im Feld erfasste Berichte über einen sicheren Tunnel in ein CRM — mit Protokollierung und Wiederholungsversuch, damit zwischen Datenerfassung und System of Record nichts verloren geht.

Erst wenn die eigenen Systeme bereit sind, lohnt sich das Netzwerk

Das ist kein Argument gegen EDI-Netzwerke oder multi-enterprise Plattformen — für die standardisierten, hochvolumigen Handelsbeziehungen, für die sie gebaut sind, rechtfertigen sie ihre Kosten. Es ist ein Argument für die richtige Reihenfolge. Bevor man sich nach einer Netzwerkschicht umsieht, lohnt sich die Prüfung, ob das eigene ERP, WMS und PLM überhaupt saubere, gemappte, abgeglichene Daten liefern können. Ist die Antwort Nein, ist das das Projekt, das zuerst laufen muss — und das ist Integrations- und individuelle Softwarearbeit, kein Abonnement.

Hersteller, die diese Reihenfolge richtig angehen, haben am Ende Systeme, die sich intern gegenseitig vertrauen, bevor sie überhaupt dem System eines externen Partners vertrauen müssen. Das ist das schwierigere Problem — und das, das es wert ist, richtig gelöst zu werden. Sagen Sie uns, was verbunden werden muss — wir sagen Ihnen ehrlich, wie viel davon Integrationsarbeit ist.