Wo das vermeintliche Integrationsproblem ganz woanders liegt

Nicht jeder Bruch, der an einem Verkaufskanal sichtbar wird, ist ein Kanalproblem.

Bei einem Leuchtenhersteller, den wir begleiten, funktionierte Shopify als Verkaufskanal grundsätzlich. Auch das vorhandene ERP wurde für Versand und Abrechnung genutzt. Der eigentliche Engpass begann nach der Bestellung.

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

Die entscheidende Aufgabe war, den Produktionsprozess so zu strukturieren, dass Mitarbeitende an jeder Station sehen, was als Nächstes zu tun ist, und neue Kolleginnen und Kollegen schnell arbeitsfähig werden.

Das Beispiel zeigt die falsche Reihenfolge vieler Integrationsprojekte: Erst wird über Schnittstellen gesprochen, obwohl noch nicht geklärt ist, welcher Prozess überhaupt stabilisiert werden muss.

Welche Integrationsarchitektur wann sinnvoll ist

Keines dieser Modelle ist grundsätzlich überlegen. Die wichtige Frage lautet: Was ist die kleinste Architektur, die den vollständigen relevanten Prozess verlässlich ermöglicht?

So leitet ihr die passende Architektur ab

Ich schaue in Discovery-Gesprächen deshalb nie zuerst auf die Schnittstellenliste. Wir nehmen einen echten Auftrag und verfolgen ihn vom Verkauf bis zur finanziellen Bewertung.

1. Den realen Ablauf aufnehmen

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

2. Die normalen Ausnahmefälle durchspielen

Auftragsänderung, Teillieferung, Stornierung, Retoure, beschädigte Ware, abweichende Rechnung. Eine Architektur, die nur den Happy Path beherrscht, ist nicht belastbar.

3. Systemverantwortung festlegen

Für Produktdaten, Bestand, Auftrag, Zahlung und Warenwert braucht es jeweils eine verbindliche Quelle. Nicht zwangsläufig dasselbe System – aber eine klare Entscheidung.

4. Finance früh einbeziehen

Wie werden Erlös, Gebühren, Erstattung und Wareneinsatz einem Kanal zugeordnet? Welche Informationen müssen im Monatsabschluss vorliegen?

5. Den kleinsten sinnvollen Scope bauen

Erst jetzt wird entschieden, ob eine einzelne Schnittstelle genügt oder ob Hub, Middleware, ERP oder ein hybrides Modell nötig sind. Der erste Scope sollte den relevanten End-to-End-Prozess tragen, nicht jede denkbare Funktion enthalten.

Self-Check: Sind eure Verkaufskanäle wirklich integriert?

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

• Funktioniert der Prozess nur, solange kein Kunde seine Bestellung ändert?

• Unterscheiden sich Bestandszahlen zwischen Shop, Marktplatz, Lager und ERP?

• Fehlen nach der Übergabe an Lager, 3PL oder FBA verlässliche Status- und Bestandsrückflüsse?

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

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

• Dienen Excel, Slack, E-Mail oder manuelle Exporte als dauerhafte Brücke zwischen Kernsystemen?

• Ist unklar, welches System für Produkt, Bestand, Auftrag, Zahlung oder Warenwert führend ist?

• Kann Finance Umsatz, Gebühren, Retouren und Wareneinsatz nicht verlässlich je Kanal zusammenführen?

• Erzeugt ein neuer Verkaufskanal dauerhaft zusätzliche manuelle Arbeit oder neue Sonderregeln?

Wenn ihr mehrere Fragen mit Ja beantwortet, lohnt sich ein Blick auf den vollständigen Prozess. Das Ergebnis muss nicht automatisch ein neues ERP oder ein großes Transformationsprojekt sein. Manchmal reicht eine saubere Schnittstelle. Manchmal müssen Verantwortlichkeiten oder Datenlogiken geklärt werden. Und manchmal ist die bestehende Architektur tatsächlich aus dem Betriebsmodell herausgewachsen.

Fazit: Die Integration endet nicht beim Bestellimport

Verkaufskanäle sind nicht integriert, nur weil Daten zwischen ihnen übertragen werden.

Sie sind integriert, wenn jeder Verkauf als zusammenhängender Vorgang nachvollziehbar bleibt: mit eindeutigen Produktdaten, verlässlicher Verfügbarkeit, einem ausführbaren Auftrag, vollständigen Fulfillment-Rückflüssen, sauber verarbeiteten Retouren und einer belastbaren finanziellen Bewertung.

Die richtige Architektur kann sehr einfach sein. Sie kann auch mehrere spezialisierte Systeme und ein ERP verbinden. Entscheidend ist nicht, wie modern das Architekturdiagramm aussieht.

Entscheidend ist, ob ein weiterer Kanal mehr Geschäft bringt, ohne dass die Organisation den Prozess jedes Mal neu zusammenbauen muss.

Wenn ihr nicht sicher seid, wo es in eurem Setup tatsächlich bricht, ist der sinnvollste nächste Schritt kein vorschneller Toolvergleich. In unserem Discovery Assessment verfolgen wir gemeinsam einen realen Auftrag vom Verkauf bis zu Warenabgang und Finance. Wir machen manuelle Übergaben, fehlende Rückflüsse und unklare Systemverantwortung sichtbar und leiten daraus eine Zielarchitektur und den kleinsten sinnvollen Umsetzungsscope ab.

Häufige Fragen zur Multichannel-Integration

Was gehört zu einer Multichannel-Integration im E-Commerce?

Eine vollständige Multichannel-Integration verbindet Produktdaten, Preise, Bestände, Bestellungen und Statusinformationen über mehrere Verkaufskanäle. Für einen durchgängigen Betrieb müssen außerdem Fulfillment, Retouren, Zahlungen, Warenbewegungen und Finance berücksichtigt werden.

Woran erkennt man eine unvollständige Multichannel-Integration?

Bestellungen werden zwar übertragen, danach müssen Mitarbeitende aber Statuswerte nachpflegen, Bestände abgleichen, Retouren manuell zuordnen oder Finanzdaten aus mehreren Systemen konsolidieren.

Wann reicht eine einfache Schnittstelle?

Eine einfache Schnittstelle reicht, wenn sie einen klar definierten und stabilen Prozess automatisiert, wenige Ausnahmen bestehen und die beteiligten Systeme eindeutige Rollen haben. Sie muss nicht möglichst viele Aufgaben übernehmen, sondern den relevanten Datenfluss zuverlässig abdecken.

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. Operativ benötigen beide Ansätze verlässliche Daten- und Prozessflüsse zwischen den beteiligten Systemen.

Welches System sollte in einer Multichannel-Architektur führend 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. Entscheidend ist, dass für jede relevante Information eine verbindliche Quelle festgelegt ist.

Welche Rolle spielt das Fulfillment-Modell?

Eigenes Lager, 3PL und FBA erzeugen unterschiedliche Verantwortlichkeiten und Datenflüsse. Deshalb bestimmt das Fulfillment-Modell häufig stärker über die passende Architektur als die reine Zahl der Verkaufskanäle.

Warum muss Finance früh berücksichtigt werden?

Ohne die Verbindung von Erlösen, Gebühren, Retouren und Warenwerten bleibt die tatsächliche Profitabilität eines Kanals unklar. Werden Finance-Anforderungen erst am Ende betrachtet, entstehen häufig manuelle Abstimmungen und langsame Monatsabschlüsse.

Muss ein ERP alle beteiligten Systeme ersetzen?

Nein. Ein ERP kann die operative und finanzielle Prozessführung übernehmen, während Shopify, PIM, Marktplatzsoftware oder andere Speziallösungen klare Aufgaben behalten. Entscheidend sind eindeutige Verantwortlichkeiten und verlässliche Übergaben.