Manchmal liegt der Engpass hinter dem Verkaufskanal

Bei einem Leuchtenhersteller, den wir begleiten, erfüllte Shopify seine Rolle als Verkaufskanal und das vorhandene ERP wurde für Versand und Abrechnung genutzt. Der Engpass begann nach der Bestellung.

Die Produktion wurde über ein selbst gebautes Dashboard und viel manuelles Wissen gesteuert. Belastbare Bestände, geführte Fertigungsschritte und eine einfache Nutzerführung fehlten. Gleichzeitig arbeitet das Unternehmen saisonal mit vielen neuen Kräften.

Der Produktionsprozess musste Mitarbeitenden an jeder Station zeigen, was als Nächstes zu tun ist, und neue Kolleginnen und Kollegen schnell arbeitsfähig machen.

Eine weitere Schnittstelle hätte daran nichts geändert. Zuerst musste der Produktionsprozess funktionieren.

Welche Integrationsarchitektur passt?

Direkte Anbindung

Passt, wenn: ein stabiler Datenfluss automatisiert werden soll und wenige Ausnahmen auftreten.

Wird kritisch, wenn: mehrere Prozesse, Systeme und Sonderfälle über dieselbe Verbindung laufen sollen.

Shopify als Hub

Passt, wenn: Shopify den operativen Prozess führt und Aufträge aus allen Kanälen ähnlich verarbeitet werden.

Wird kritisch, wenn: Einkauf, B2B, FBA, mehrere Bestandsbereiche und eine detaillierte Warenbewertung an Bedeutung gewinnen.

Marketplace-Middleware

Passt, wenn: Listings, Preise und das Onboarding vieler Marktplätze einen eigenen operativen Bereich bilden.

Wird kritisch, wenn: eine weitere Datendrehscheibe ohne eindeutige Verantwortung entsteht.

ERP-zentrierte oder hybride Architektur

Passt, wenn: Verkauf, Einkauf, Bestand, Fulfillment und Finance eng zusammenhängen.

Wird kritisch, wenn: das Projekt unnötig wächst oder funktionierende Speziallösungen ohne konkreten Grund ersetzt werden.

Wählt die kleinste Architektur, die Auftrag, Ware, Zahlung und Retoure ohne dauerhafte manuelle Brücken abbildet.

So leitet ihr die Architektur aus dem Prozess ab

In unseren Discovery-Gesprächen starten wir mit einem echten Auftrag und verfolgen ihn vom Verkauf bis zur finanziellen Bewertung.

1. Den realen Ablauf verfolgen

Wo entstehen Produkt, Preis und Auftrag? Woher kommt die verfügbare Menge? Wer übernimmt Fulfillment, Rechnung und Zahlung?

Dabei zählt der tatsächlich gelebte Prozess – nicht die Beschreibung aus einem alten Projektplan.

2. Normale Abweichungen testen

Spielt eine Auftragsänderung, Teillieferung, Stornierung, Retoure, beschädigte Ware und abweichende Rechnung durch.

Ein Prozess, der von unveränderten Standardaufträgen abhängt, wird im Tagesgeschäft schnell manuell.

3. Systemverantwortung festlegen und Finance einbeziehen

Für Produktdaten, Bestand, Auftrag, Zahlung und Warenwert braucht es jeweils ein führendes System. Gleichzeitig muss feststehen, wie Erlöse, Gebühren, Erstattungen und Wareneinsatz einem Kanal zugeordnet werden.

Finance erst kurz vor dem Go-live einzubeziehen, produziert fast immer zusätzliche Abstimmungen.

4. Den ersten Scope begrenzen

Erst jetzt lässt sich entscheiden, ob eine einzelne Schnittstelle genügt oder ob der Prozess einen Hub, eine Middleware, ein ERP oder ein hybrides Modell braucht.

Der erste Scope muss den gewählten End-to-End-Prozess tragen. Er muss nicht jede Funktion enthalten, die das Unternehmen später einmal benötigen könnte.

Self-Check: Sind eure Verkaufskanäle integriert?

• Kommen Bestellungen zentral an, müssen danach aber regelmäßig geprüft, ergänzt oder neu angelegt werden?

• Bricht der Prozess, sobald ein Kunde seine Bestellung ändert?

• Zeigen Shop, Marktplatz, Lager und ERP unterschiedliche Bestände?

• Fehlen nach der Übergabe an 3PL oder FBA Status- und Bestandsrückflüsse?

• Muss der Kundenservice mehrere Systeme öffnen, um einen Auftrag zu verstehen?

• Werden Stornierungen, Teillieferungen oder Retouren außerhalb des Standardprozesses bearbeitet?

• Verbinden Excel, Slack, E-Mail oder manuelle Exporte dauerhaft eure Kernsysteme?

• Kann Finance Umsatz, Gebühren, Retouren und Wareneinsatz je Kanal zuordnen?

Mehrere Ja-Antworten sind ein guter Grund, den Prozess einmal vom Auftrag bis zur Buchung zu verfolgen.

Das Ergebnis kann eine fehlende Schnittstelle, eine unklare Verantwortung oder eine inkonsistente Datenlogik sein. Es kann auch zeigen, dass die Systemlandschaft nicht mehr zum Betriebsmodell passt. Ein neues ERP ist eine mögliche Antwort – nicht der Standard.

Fazit: Die eigentliche Integration beginnt nach dem Bestellimport

Ein Verkaufskanal ist integriert, wenn Auftrag, Ware, Zahlung und Retoure als zusammenhängender Vorgang durch das Unternehmen laufen.

Wie viele Systeme daran beteiligt sind, spielt eine untergeordnete Rolle. Eine direkte Schnittstelle kann ausreichen. Bei mehreren Fulfillment-Modellen, Bestandsbereichen und Zahlungsströmen kann ein ERP als operative Zentrale sinnvoll werden.

Die beste Architektur ist die kleinste, die den tatsächlichen Prozess operativ ermöglicht.

Ein weiterer Kanal sollte mehr Geschäft bringen – nicht eine zusätzliche Excel-Liste, mehr Kontrollarbeit und neue Sonderregeln.

Im Discovery Assessment verfolgen wir einen echten Auftrag durch eure Systeme: vom Verkauf über Warenbewegung und Fulfillment bis zu Finance. Danach wisst ihr, wo der Prozess bricht, welches System führen muss und was ihr wirklich verändern müsst.

Häufige Fragen zur Multichannel-Integration

Was ist eine Multichannel-Integration im E-Commerce?

Eine Multichannel-Integration verbindet die Verkaufskanäle mit den dahinterliegenden Waren- und Finanzprozessen. Neben Produktdaten, Preisen, Beständen und Bestellungen gehören dazu Fulfillment, Retouren, Zahlungen und Warenbewertung.

Wann reicht eine direkte Schnittstelle?

Eine direkte Schnittstelle funktioniert häufig bei einem stabilen Prozess mit wenigen Ausnahmen. Treffen mehrere Fulfillment-Wege, Bestandsbereiche oder Zahlungsströme aufeinander, wird meist eine übergreifende Prozessführung benötigt.

Was ist der Unterschied zwischen Multichannel und Omnichannel?

Multichannel beschreibt den Verkauf über mehrere Kanäle. Omnichannel legt zusätzlich Wert auf eine konsistente Kundenerfahrung über alle Kontaktpunkte. Beide Ansätze benötigen funktionierende Daten- und Prozessflüsse zwischen den beteiligten Systemen.

Welches System sollte die verbindliche Datenquelle sein?

Das hängt von der Information ab. Shop oder PIM können Produktinhalte führen, während das ERP Bestände, Warenbewegungen und finanzielle Bewertung verantwortet. Für jede Information braucht es eine festgelegte Quelle und eine Regel für Konflikte.

Wo sollte ein Integrationsprojekt beginnen?

Bei einem echten Auftrag. Verfolgt ihn über Fulfillment, Änderungen und Retouren bis zu Zahlung und Warenbewertung. Die Brüche in diesem Ablauf zeigen, welche Integration tatsächlich gebraucht wird.