Ein Artikel im Shop, drei Preise im ERP, ein abweichender Lagerbestand im Marktplatzkonto - und am Ende klärt der Vertrieb die Bestellung per Telefon. Genau solche Situationen entstehen, wenn Unternehmen ERP Shop Schnittstellen planen, ohne die tatsächlichen Abläufe vorher sauber zu prüfen. Die Schnittstelle ist dann zwar technisch vorhanden, löst aber das eigentliche Problem nicht: Daten werden doppelt gepflegt, Ausnahmen landen in Excel und Mitarbeitende verlieren Vertrauen in die Systeme.
Für mittelständische Handelsunternehmen geht es deshalb nicht zuerst um die Frage, ob REST, SOAP, CSV oder ein Middleware-System eingesetzt wird. Entscheidend ist, welche Daten wann in welchem System führend sind und was passieren muss, wenn ein Prozess nicht nach Plan läuft. Eine gut geplante Integration schafft einen verlässlichen Arbeitsablauf zwischen Shop, ERP, Lager, Versand und Kundenservice. Eine schlecht geplante Integration verlagert Fehler nur schneller von einem System ins nächste.
ERP-Shop-Schnittstellen planen beginnt beim Prozess
Das ERP ist in vielen Unternehmen die kaufmännische und operative Quelle der Wahrheit. Hier liegen Artikelstammdaten, Preise, Kundenkonditionen, Bestände, Aufträge, Rechnungen und Lieferinformationen. Der Onlineshop ist dagegen der Verkaufskanal, der diese Informationen verständlich, schnell und überzeugend für Kunden bereitstellt. Beide Systeme haben unterschiedliche Aufgaben. Sie müssen nicht identisch sein.
Dieser Unterschied wird häufig unterschätzt. Ein ERP-Artikel kann beispielsweise mehrere Varianten, komplexe Verpackungseinheiten oder interne Buchungsinformationen enthalten. Im Shop braucht derselbe Artikel passende Bilder, verständliche Texte, Filterwerte, Cross-Selling und je nach Kundengruppe andere Preise. Wer einfach alle Felder in beide Richtungen synchronisiert, produziert unnötige Abhängigkeiten und später schwer nachvollziehbare Fehler.
Am Anfang steht daher eine Prozessaufnahme mit den beteiligten Bereichen. Einkauf, Vertrieb, Lager, Buchhaltung, E-Commerce und Kundenservice sehen oft jeweils nur ihren Teil. Erst im gemeinsamen Blick wird sichtbar, wo Daten entstehen, wer sie prüft und wo heute manuelle Korrekturen nötig sind. Das ist keine theoretische Vorarbeit. Sie entscheidet darüber, ob die Schnittstelle im Alltag entlastet oder neue Tickets erzeugt.
Führende Systeme klar festlegen
Für jeden Datentyp sollte es genau eine klare Regel geben: Welches System darf Daten anlegen und ändern, welches übernimmt sie nur? Bei Produktgrunddaten ist das häufig das ERP. Bei Shoptexten, Medien und Kategorien ist meist der Shop führend. Kunden können sich im Shop registrieren, während das ERP die Debitorennummer und Zahlungsfreigabe verwaltet. Bei B2B-Projekten kommen individuelle Preislisten, Freigabeprozesse und Sortimentseinschränkungen hinzu.
Besonders kritisch sind Bestände und Preise. Ein Bestand, der nur stündlich übertragen wird, kann bei stark nachgefragten Artikeln zu Überverkäufen führen. Eine Synchronisation im Minutentakt verursacht wiederum Last und ist nicht in jedem Szenario notwendig. Hier gilt: Die passende Aktualität richtet sich nach Geschäft und Risiko. Ersatzteile mit geringem Bestellvolumen vertragen andere Regeln als Aktionsware oder medizinische Verbrauchsprodukte.
Welche Daten wirklich übertragen werden müssen
Eine Schnittstellenplanung wird belastbar, wenn sie nicht bei allgemeinen Begriffen wie „Artikelabgleich“ stehen bleibt. Stattdessen werden Datenobjekte, Felder, Auslöser und Rückmeldungen konkret beschrieben. Ein Artikelimport etwa braucht nicht nur Artikelnummer und Preis. Er braucht Regeln für Varianten, Einheiten, Steuersätze, Lieferzeiten, Sperrkennzeichen und die Behandlung ausgelaufener Produkte.
Bei Bestellungen geht es ebenso um mehr als die Übertragung eines Warenkorbs. Das ERP muss erkennen, welcher Kunde bestellt hat, welche Liefer- und Rechnungsadresse gilt, welche Zahlungsart gewählt wurde und ob eine Bestellung geprüft werden soll. Der Shop wiederum benötigt Rückmeldungen zum Auftrag: Wurde er angenommen, teilweise geliefert, storniert oder versendet? Erst dann können Kunden im Konto verlässlich sehen, was mit ihrer Bestellung passiert.
Eine fachliche Schnittstellenspezifikation sollte mindestens folgende Fragen beantworten:
- Welche Datenobjekte werden übertragen und welche Felder sind Pflicht?
- Welches System ist führend, und in welche Richtung fließen Änderungen?
- Was löst einen Transfer aus: Echtzeit, Zeitplan oder manuelle Freigabe?
- Wie werden neue, geänderte, gesperrte und gelöschte Datensätze behandelt?
- Was passiert bei fehlenden Daten, Übertragungsfehlern oder widersprüchlichen Angaben?
Diese Details wirken zunächst kleinteilig. Sie verhindern jedoch, dass Entwickler Annahmen treffen müssen, die später nicht zum Prozess passen. Ein sauberer Sonderfall ist günstiger als eine tägliche manuelle Notlösung.
Echtzeit ist nicht immer die beste Antwort
Viele Ausschreibungen enthalten die Forderung nach einer Echtzeit-Schnittstelle. Das klingt nach modernem E-Commerce, ist aber nicht automatisch sinnvoll. Echtzeit erhöht Komplexität, Anforderungen an Verfügbarkeit und die Zahl möglicher Fehlerbilder. Fällt ein beteiligtes System aus, muss geklärt sein, ob Bestellungen zwischengespeichert, erneut übertragen oder bewusst angehalten werden.
Für Bestände kann ein ereignisbasierter Abgleich sinnvoll sein, wenn wenige Stück Differenz bereits wirtschaftlich relevant sind. Produkttexte und Bilder dürfen dagegen oft nachts oder nach einer redaktionellen Freigabe synchronisiert werden. Preise benötigen je nach Geschäftsmodell einen anderen Takt: B2C-Aktionspreise können zeitgesteuert wechseln, während B2B-Konditionen bei der Anmeldung oder beim Checkout geprüft werden sollten.
Wichtig ist nicht das Etikett „Echtzeit“, sondern ein nachvollziehbares Serviceziel. Wie aktuell müssen Daten sein? Welche Verzögerung ist akzeptabel? Wer wird informiert, wenn ein Import ausbleibt? Diese Fragen gehören in die Planung und später in den Betrieb.
Fehlerfälle gehören vor den Go-Live
Eine Integration ist erst dann praxistauglich, wenn sie auch bei unvollständigen Daten und technischen Störungen kontrolliert reagiert. Ein fehlendes Produktbild darf den Artikellauf nicht blockieren. Eine fehlende Steuerklasse oder doppelte Artikelnummer kann dagegen ein Grund sein, den betreffenden Datensatz zurückzuweisen. Solche Regeln müssen fachlich entschieden werden, nicht erst im Fehlerprotokoll nach dem Launch.
Genauso wichtig sind Protokollierung und Wiederholbarkeit. Verantwortliche müssen erkennen können, welcher Datensatz wann übertragen wurde, warum er fehlgeschlagen ist und ob eine Korrektur erfolgreich erneut verarbeitet wurde. Ohne diese Transparenz beginnt die Fehlersuche mit Screenshots, E-Mails und Vermutungen. Mit klaren Statusmeldungen kann der Fachbereich viele Probleme selbst einordnen, bevor daraus ein dringender Entwicklungseinsatz wird.
Auch Testdaten verdienen Aufmerksamkeit. Ein Testsystem mit drei Musterartikeln zeigt selten, wie sich Zehntausende Varianten, Staffelpreise oder historische Kundenadressen verhalten. Gute Tests bilden reale Datenmengen und kritische Sonderfälle ab: Teillieferungen, Retouren, abgelehnte Zahlungen, gesperrte Kunden, Preisänderungen während des Checkouts und parallele Bestellungen auf den letzten Lagerbestand.
Architektur: Direktanbindung oder Middleware?
Eine direkte Verbindung zwischen Shop und ERP kann sinnvoll sein, wenn die Systemlandschaft überschaubar ist und die Abläufe klar definiert sind. Sie reduziert einen zusätzlichen Baustein und damit zunächst auch Abstimmungsaufwand. Bei einem Shopware-6-Shop und einem Odoo-ERP lässt sich so häufig eine gut wartbare Lösung aufbauen, sofern Schnittstellen und Verantwortlichkeiten sauber dokumentiert sind.
Wächst die Landschaft um Marktplätze, CRM, PIM, Versanddienstleister, Zahlungsanbieter oder mehrere Shops, kann eine Middleware die bessere Wahl sein. Sie bündelt Übersetzungen zwischen Datenformaten, steuert Wiederholungen und entkoppelt Systeme teilweise voneinander. Der Vorteil hat seinen Preis: Ein weiteres System muss betrieben, überwacht und fachlich verstanden werden. Middleware ist kein Selbstzweck, sondern eine Entscheidung für Komplexität, die sich bei mehreren Integrationen lohnen kann.
Unabhängig von der Architektur braucht jedes Projekt eine klare Antwort auf die Betriebsfrage. Wer aktualisiert Schnittstellen nach ERP- oder Shop-Releases? Wer überwacht fehlgeschlagene Jobs außerhalb der Geschäftszeiten? Wie werden Zugangsdaten geschützt und erneuert? Inter Medien Networks plant diese Themen nicht als Nachtrag, weil eine Schnittstelle erst im laufenden Betrieb ihren Wert beweist.
Planung in Etappen statt großer Schalter
Ein Go-Live muss nicht bedeuten, dass jede denkbare Automatisierung am ersten Tag fertig sein muss. Häufig ist es klüger, zuerst die geschäftskritischen Prozesse stabil umzusetzen: Artikel, Preise, Bestände, Bestellungen und Versandstatus. Erweiterungen wie komplexe Bundles, Produktkonfiguratoren, Retourenautomatisierung oder länderspezifische Logiken folgen, wenn der Kern verlässlich läuft.
Das ist kein Verzicht auf Anspruch, sondern kontrolliertes Risikomanagement. Voraussetzung ist, dass die Zielarchitektur von Beginn an darauf vorbereitet wird. Wer eine Übergangslösung baut, sollte genau wissen, welche manuellen Schritte vorübergehend bleiben, wer sie verantwortet und bis wann sie abgelöst werden.
Bevor die erste API angebunden wird, lohnt ein Blick auf den Montagmorgen im Betrieb: Welche Informationen brauchen Lager, Kundenservice und Buchhaltung, damit sie ohne Excel-Listen, Rückfragen und Schweißperlen arbeiten können? Wenn die Schnittstellenplanung diese Frage beantwortet, wird aus einer technischen Verbindung ein System, das den Handel tatsächlich leichter macht.