ERP WMS Marketplace Integration sollte nicht nach der Zahl verfügbarer Konnektoren entschieden werden. Wer mit mehreren Kanälen, Lagerregeln und Ausnahmen arbeitet, kauft mit einer zu simplen Lösung oft nur spätere Betriebsprobleme ein. Die richtige Entscheidung ist meist die, die Bestände, Aufträge und Fehlerpfade auch dann beherrschbar hält, wenn ein zweites Lager, ein neuer Marktplatz oder mehr Sonderfälle dazukommen. Genau daran trennt sich günstige Anbindung von tragfähiger Architektur.
1. Direkte Kopplung oder Integrationsschicht: Wo die Entscheidung kippt
Eine direkte Verbindung zwischen ERP, WMS und Marktplatz kann funktionieren. Aber nur in einem engen Korridor: ein Lager, wenige Prozessvarianten, stabile Stammdaten, geringe Änderungsrate. In so einem Setup ist zusätzliche Integrationslogik oft wirklich Ballast.
Sobald ein zweiter Verkaufskanal, ein weiteres Lager oder kanalabhängige Regeln dazukommen, steigt vor allem die Folgekomplexität in Mapping, Monitoring und Fehlerbehandlung. Felder müssen je Kanal anders übersetzt werden, Statuskonflikte werden schwerer nachvollziehbar und Ausnahmen landen nicht mehr an einer Stelle, sondern verteilt in ERP, WMS und Marktplatzlogik. Genau dort werden vermeintlich einfache Konnektoren teuer, obwohl sie im Einkauf harmlos aussehen.
Aus Projekten mit Handels- und Fulfillment-Prozessen bleibt ein Muster ziemlich konstant: Nicht die Zahl der Systeme ist das Problem, sondern die Zahl der Ausnahmen pro Auftrag. Wer fast nur Standardabläufe hat, kommt mit wenig Technik weit. Wer Reservierungen, Teillieferungen, Bundles oder manuelle Eingriffe sauber abbilden muss, braucht eine Integrationsschicht oder eine gezielte Orchestrierung.
Martin Fowler beschreibt solche Architekturentscheidungen seit Jahren treffend: Komplexität verschwindet nicht, sie wandert. Bei ERP-WMS-Schnittstellen landet sie entweder in einer bewusst gebauten Integrationsschicht oder unkontrolliert im ERP, in Lagerprozessen, in Marktplatzregeln und am Ende beim Support.
Für die Auswahl reicht deshalb eine einfache Trennung. Direkte Kopplung passt bei einem klar begrenzten Setup mit wenig Veränderung. Middleware oder iPaaS ist sinnvoll, wenn mehrere Standardprozesse sauber entkoppelt werden sollen. Individuelle Orchestrierung wird vernünftig, sobald Bestandslogik, Reservierungen oder Ausnahmefälle geschäftskritisch sind und nicht mehr in generischen Mappings leben sollten.
Eine unbequeme Marktbeobachtung: Viele Anbieter verkaufen Konnektoren, obwohl Käufer eigentlich Betriebsstabilität brauchen. Im Vertrieb wirkt eine lange Integrationsliste stark. Im Alltag zählen eher Idempotenz, Versionierung, Retry-Regeln und nachvollziehbare Fehlerpfade. Wer diese Punkte nicht prüft, kauft oft nur eine hübsch verpackte Punkt-zu-Punkt-Landschaft.
Darum ist ein Punkt für die Kaufentscheidung zentral: Wer im wachsenden Marktplatzgeschäft nur nach vorhandenen Konnektoren einkauft, kauft oft das falsche Produkt. Das ist kein technischer Purismus. Es ist eine direkte Reaktion auf Systeme, die Daten transportieren, aber keine belastbare Betriebslogik tragen.
Wenn Sie Integrationen und APIs bewerten, sollte nicht die Zahl der Anschlüsse dominieren, sondern die Frage, ob sich Fehler unter Last kontrolliert erkennen und beheben lassen.
Middleware ist oft die richtige Zwischenstufe. Sie entkoppelt Systeme, standardisiert Datentransport und beschleunigt Rollouts. Das gilt vor allem dann, wenn ERP und WMS solide APIs haben und der Marktplatz überwiegend standardisierte Ereignisse wie Bestellung, Versand und Bestand liefert.
Schwierig wird es, wenn Middleware fachliche Entscheidungen simulieren soll, für die sie nie gedacht war. Ein Beispiel: verkaufsfähiger Bestand hängt von Reservierungen, Qualitätsprüfung, Nachschubfenstern und kanalabhängigen Puffern ab. Wer solche Regeln in einem generischen Mapping-Editor nachbaut, baut keine robuste Architektur, sondern eine schwer wartbare Schattenlogik.
Die Schwelle ist erreicht, sobald Fachbereiche Regeln nicht mehr erklären können, ohne auf drei Systeme und zwei Workarounds zu zeigen. Dann geht es nicht mehr um Datentransport, sondern um Prozessführung. Genau dort kippt die Entscheidung in Richtung Orchestrierung oder gezielte Individualentwicklung.
2. Welche Datenobjekte kritisch sind und welches System führen muss
Die meisten Integrationsprobleme sind keine API-Probleme. Sie entstehen, weil mehrere Systeme denselben Wert ändern dürfen. Ohne klare Systemführerschaft wird jede Abweichung zur Diskussion zwischen E-Commerce, Lager und ERP-Team.
Für viele Handelsprozesse ist diese Aufteilung pragmatisch und belastbar: ERP führt Artikelstammdaten, Preise, Steuern, kaufmännische Auftragslogik und Rechnungsstatus. WMS führt physischen Bestand, Reservierungen, Lagerbewegungen, Pick, Pack und Versandereignisse. Der Marktplatz liefert Bestellungen, kanalbezogene Anforderungen und Rückmeldungen zu Versand oder Listing-Status.
Abweichungen sind möglich. Sie müssen nur bewusst entschieden werden. Wenn ein Marktplatz bestimmte Attribute oder Preisaktionen vorgibt, braucht es eine feste Regel: Bleibt diese Information im Kanal oder wird sie ins ERP zurückgeschrieben? Mischmodelle ohne klare Grenze erzeugen fast immer manuelle Nacharbeit.
Vier Datenobjekte entscheiden darüber, ob die Integration ruhig läuft oder täglich Reibung erzeugt.
Bestand ist nicht nur eine Zahl. Relevant sind mindestens physischer Bestand, reservierter Bestand und verkaufsfähiger Bestand. Wer nur Mengen kopiert, baut Überverkäufe fast zwangsläufig ein. In der Amazon Selling Partner API wird die Aktualität von Bestands- und Versandmeldungen deshalb nicht als Komfortfunktion behandelt, sondern als betriebliche Pflicht.
Dazu kommt die Entscheidung über Pufferlogik. Manche Händler ziehen pauschal Sicherheitsbestände ab, andere arbeiten mit kanalabhängigen Puffern oder Zeitfenstern. Beides kann funktionieren. Gefährlich wird es, wenn Puffer im Marktplatz, im ERP und im WMS gleichzeitig existieren. Dann sinkt nicht nur die Transparenz, sondern auch die Steuerbarkeit bei Engpässen.
Aufträge müssen idempotent verarbeitet werden. Das heißt: Trifft dieselbe Nachricht mehrfach ein, darf daraus kein doppelter Auftrag entstehen. Fehlt diese Logik, ist das kein Detail, sondern ein Ausschlusskriterium bei der Auswahl von Middleware oder Integrationspartner.
Ebenso wichtig ist die Statusübersetzung. Ein Marktplatz kennt oft andere Zustände als ERP oder WMS. Wenn aus einem kanalbezogenen Status vorschnell ein interner Prozessstatus wird, entstehen Fehlinterpretationen. Ein Auftrag kann kaufmännisch bestätigt sein, ohne logistisch freigegeben zu sein. Diese Trennung muss im Modell sichtbar bleiben.
Versandstatus wirken direkt auf Kundenerlebnis, Supportaufwand und je nach Kanal auch auf operative Kennzahlen. Wenn Tracking-Informationen verspätet oder unvollständig ankommen, ist das nicht nur ein technischer Fehler, sondern ein Prozessfehler mit sichtbaren Folgen.
Hier gilt eine harte Regel: Versand darf erst gemeldet werden, wenn die Sendung physisch oder durch den Carrier bestätigt erzeugt wurde. Alles andere produziert Reklamationen. Gerade bei hohem Volumen ist ein zu früher Status schlimmer als ein leicht verspäteter, weil Support und Plattformmetriken darauf reagieren.
Storno und Retoure sind der Bereich, in dem viele Integrationen brechen, die in Demos sauber aussehen. Teilstorno, Teillieferung, Adresskorrektur und Wiedereinlagerung müssen fachlich modelliert sein, bevor sie technisch verbunden werden. Das typische Fehlmuster ist schnell beschrieben: Der Standardauftrag läuft durch, aber eine manuelle Änderung im ERP landet nicht sauber zurück im Marktplatz. Ab dann beginnt tägliche Nacharbeit.
Retouren sind zusätzlich heikel, weil kaufmännischer und physischer Prozess auseinanderlaufen können. Ware kann im Lager eintreffen, aber noch nicht wieder verkaufsfähig sein. Wenn das System diese Zwischenzustände nicht kennt, wird Bestand zu früh freigegeben oder Gutschrift zu spät ausgelöst. Beides kostet Marge oder Vertrauen.
Ein konkretes Beispiel aus dem Handel: In einem mittelgroßen Setup mit zwei Lagern und mehreren tausend Bestellungen pro Woche war nicht der Datentransport das Problem, sondern die Rückmeldung von Teilstornos und Reservierungen. Der Rollout stockte nicht an der API, sondern an der Frage, welche Bestandsart an den Marktplatz gehen durfte und wer manuelle Korrekturen freigibt. Genau dort geht Zeit verloren, nicht beim Anlegen der Verbindung.
Wenn zusätzlich interne Tools oder Portale im Einsatz sind, sollte die Integrationslogik nicht still in Oberflächen wandern. Sonst wird aus einer ERP-WMS-Schnittstelle ein Sammelsurium aus versteckten Regeln in Admin-Masken und Hilfsanwendungen. Wer in diesem Umfeld Webanwendungen entwickelt oder erweitern lässt, sollte Geschäftslogik bewusst zentral halten.
3. Welche Entscheidungslogik vor dem Projektstart feststehen muss
Viele Integrationsprojekte scheitern nicht an Technik, sondern an fehlenden Vorentscheidungen. Teams starten mit APIs, bevor sie Betriebsregeln geklärt haben. Das ist ungefähr so sinnvoll wie ein Lagerlayout zu bauen, bevor feststeht, welche Ware dort bewegt wird.
Vor dem Start müssen einige Punkte verbindlich entschieden sein: die Systemführerschaft je Datenobjekt, die fachlich relevanten Ereignisse, die geschäftskritischen Ausnahmen wie Teilstorno, Split-Shipment, Bundle-Auflösung oder Ersatzartikel, die akzeptable Latenz und die Frage, wer im Konfliktfall tatsächlich entscheidet.
Gerade die Latenzfrage wird oft falsch behandelt. Nicht jeder Prozess braucht Echtzeit. Preisänderungen oder bestimmte Stammdaten können in Intervallen laufen. Bestand bei schnell drehenden Artikeln oder knappen Mengen dagegen oft nicht. Wer alles in Echtzeit bauen will, erhöht Kosten und Störanfälligkeit. Wer Echtzeit dort vermeidet, wo sie geschäftskritisch ist, spart am falschen Ende.
Ein weiterer Punkt wird in Einkaufsrunden regelmäßig unterschätzt: Die spätere Betriebsverantwortung muss vor Vertragsabschluss geklärt sein, nicht nach dem Go-live. Wenn unklar bleibt, ob Fachbereich, internes IT-Team oder externer Partner Fehler priorisiert und freigibt, zieht sich jede Störung unnötig. Technisch ist das oft lösbar. Organisatorisch wird es teuer.
In der Praxis trennt genau diese Vorarbeit brauchbare Projekte von teuren Fehlstarts. Wenn ein Anbieter schon in der Auswahlphase nicht sauber benennen kann, wie Dubletten behandelt, Fehler erneut angestoßen und Verantwortlichkeiten im Tagesgeschäft geregelt werden, ist das kein kleiner Mangel. Es ist ein Warnsignal für spätere Reibung.
