ERP-Integration im E-Commerce

Es ist das klassische Szenario: Der neue Onlineshop ist live, das Frontend glänzt, die Marketing-Kampagnen laufen an. Doch im Hintergrund knirscht es. Bestellungen bleiben hängen, Bestände im Shop stimmen nicht mit dem Lager überein, und der Kundenservice ertrinkt in Anfragen zu „Wo ist mein Paket?“.

Die Zahlen sind ernüchternd: Laut Gartner verfehlen 70% aller ERP-Projekte ihre ursprünglichen Ziele. Noch alarmierender: Bei 63% der Unternehmen explodieren die IT-Kosten durch nachträgliche Reparaturen an einer schlecht geplanten Architektur.

Der Unterschied zwischen einem skalierbaren E-Commerce-Setup und einem operativen Albtraum liegt selten an der Software selbst. Es liegt an der Planung der Schnittstellen und Datenflüsse zwischen den Systemen.

Bevor die erste Zeile Code geschrieben wird, muss das „Warum“ geklärt sein. Viele Projekte starten direkt mit der technischen Umsetzung („Wir müssen SAP an Shopify anbinden“) und vergessen die betriebswirtschaftliche Realität.

Die Falle der „As-Is“ vs. „To-Be“ Prozesse

Ein häufiger Fehler: Schlechte analoge Prozesse werden 1:1 digitalisiert. Eine Integration ist der perfekte Zeitpunkt, um alte Zöpfe abzuschneiden.

Kritische Fragen

• Muss der Auftrag sofort ins ERP, oder reicht ein Sammel-Export alle 15 Minuten?
• Brauchen wir die 20 Jahre alten Kundendaten im neuen Shop, oder starten wir „frisch“?
• Welche Produktdaten ändern sich täglich, welche bleiben monatelang stabil?

Stakeholder-Management ist kein Buzzword

Eine ERP-Integration ist kein reines IT-Projekt. Diese Teams müssen eingebunden werden:

• Logistik
  Weiß, wie Retouren physisch ablaufen.
• Buchhaltung
  Kennt die Anforderungen an Rechnungsnummernkreise und DATEV-Exporte
• Marketing
  Braucht spezifische Produktdaten für Filter im Shop.
• Datenschutz
  Prüft DSGVO-Konformität bei Kundendaten-Sync

Praxis-Tipp: Plane 20-30% der gesamten Projektzeit nur für die Anforderungsphase ein. Jeder hier investierte Tag spart später eine Woche „Bugfixing“ im Live-Betrieb.

Hier entscheidet sich die Skalierbarkeit eures Unternehmens. Der häufigste Fehler: Mehrere Systeme glauben, die „Wahrheit“ zu kennen. Das Resultat ist Datenchaos.

Die goldene Regel: Single Source of Truth

Jedes Datenobjekt darf nur ein führendes System haben.

Die Middleware-Frage: Wann lohnt sie sich?

Punkt-zu-Punkt-Integration:

• Geeignet für 2-3 Systeme
• Kostengünstig
• Schnell implementiert
• Problem: Wird bei wachsender Komplexität unwartbar

Middleware (iPaaS/ESB):

• Geeignet ab 4+ Systemen
• Entkopplung: ERP-Wechsel betrifft Shop nicht
• Zentrale Fehlerbehandlung
• Kosten: Höhere Initialinvestition, aber langfristig wartbarer

Unsere Empfehlung: Für die meisten mittelständischen E-Commerce-Projekte zahlt sich Middleware aus, sobald mehr als Shop + ERP im Spiel sind (z.B. zusätzlich PIM, Marktplätze, WMS).

Nicht alle Daten sind gleich wichtig. Konzentrieret euch auf die „Lebensadern“ des E-Commerce.

1. Bestands-Synchronisation

Das Problem: Wenn das ERP 10 Minuten braucht, um Bestände zu berechnen, verkaufst du Ware, die du nicht hast.

• Nachts: Vollabgleich aller Bestände
• Tagsüber: Event-basierte Updates für Schnelldreher
• Sicherheitspuffer: Shop zeigt 10% weniger an als ERP meldet

2. Preis-Synchronisation

Herausforderung: Preise sind oft kundenindividuell (Staffelpreise, Verträge).

Architektur-Optionen:

• Standard B2C: Preise nachts synchronisieren, Shop nutzt lokale DB
• B2B: Live-API-Abfrage bei jedem Seitenaufruf
• Hybrid: Standardpreise cachen, individuelle Preise live abfragen

3. Auftrags-Übermittlung

Der kritischste Moment: Zwischen „Bestellung abschicken“ und „Im ERP angekommen“ darf nichts verloren gehen.

Muss-Kriterien:

• Transactional Outbox Pattern: Auftrag wird atomar in Shop-DB + Queue geschrieben
• Retry-Logik: Bei Fehler nach 1, 5, 15, 60 Min. erneut versuchen
• Idempotenz: Doppelt gesendete Aufträge werden vom ERP erkannt und ignoriert

„Shit in, Shit out.“

Wenn ihr schlechte Daten in ein neues, automatisiertes System kippt, automatisiert ihr nur das Chaos.

Eure Checkliste:

• Dublettenprüfung
  Habt ihr „Müller GmbH“ dreimal im ERP? Bereinigt das vor dem Sync.
• Mapping-Tabellen
  Heißt die Zahlungsart im Shop „PayPal_Express“ und im ERP „PAYPAL_E“? Diese Mappings müssen dokumentiert sein.
• Pflichtfelder
  Der Shop verlangt vielleicht keine Hausnummer, das ERP aber zwingend. Definiert Fallbacks oder verschärfe die Checkout-Validierung.
• DSGVO-Konformität
  Welche personenbezogenen Daten werden synchronisiert?
  Gibt es eine Rechtsgrundlage (Art. 6 DSGVO)?
  Wie funktioniert die Löschung (bidirektional)?

Praxis-Tipp: Plane 20% Zeitpuffer für Datenbereinigung ein. Bei schlechter Datenqualität können es auch 40% werden.

Der Standardablauf ist einfach zu programmieren. Die Qualität einer Integration zeigt sich bei Edge-Cases oder wenn etwas schiefgeht.

Was passiert, wenn das ERP wegen Wartung offline ist, während ein Kunde bestellt?

Muss-Kriterien für Enterprise-Integrationen

1. Exponential Backoff
Wenn die API nicht antwortet, versucht es nach 1 Min., dann nach 5, dann nach 15, dann nach 60 Min. erneut. Nicht alle 10 Sekunden – das überlastet das System zusätzlich.

2. Dead Letter Queues
Nachrichten, die permanent fehlschlagen (z.B. wegen Datenfehlern), dürfen das System nicht verstopfen. Sie werden in eine gesonderte Liste verschoben, wo ein Admin sie manuell prüft.

3. Idempotenz
Wenn der Shop eine Bestellung versehentlich zweimal sendet (z.B. wegen Netzwerkproblemen), darf das ERP sie nur einmal anlegen. Eindeutige Transaktions-IDs sind Pflicht.

4. Circuit Breaker
Bei zu vielen Fehlern hintereinander (z.B. ERP komplett down) werden weitere Anfragen automatisch blockiert, statt das System weiter zu belasten.

5. Graceful Degradation
Lieber eingeschränkt funktionieren als komplett ausfallen. Beispiel: Wenn die Bestands-API down ist, zeigt der Shop „Verfügbarkeit auf Anfrage“ statt komplett offline zu gehen.

Ein Integrations-Dashboard ist keine „nette Spielerei“, sondern eure Versicherung. Ihr müsst Probleme erkennen, bevor der Kunde beim Support anruft.

Was ihr überwachen müsst

Business KPIs:

• Overselling-Quote (Stornos wegen fehlendem Lagerbestand)
• Diskrepanz zwischen Shop-Umsatz und ERP-Umsatz
• Anzahl manueller Korrekturen pro Tag

Technische KPIs:

• Fehlerrate pro Schnittstelle (Ziel: < 0,1%)
• Durchschnittliche Latenz bei Sync (Zeit bis Daten ankommen)
• Queue-Größe (stauen sich Aufträge an?)

Alerting-Strategie: Nicht jeder Alert ist gleich wichtig. Definiert klare Eskalationsstufen:

• P0 Critical: Bestellungen kommen nicht im ERP an → sofort wecken
• P1 High: Bestände nicht synchron → innerhalb 1h reagieren
• P2 Medium: Einzelne Sync-Fehler → am nächsten Arbeitstag
• P3 Low: Datenqualitäts-Warnings → wöchentlich prüfen

Tool-Tipp: Grafana + Prometheus für technisches Monitoring, Datadog für Gesamtübersicht

Alles an einem Tag umzustellen ist mutig – aber meistens riskant.

Der sicherere Weg: Rollout in Phasen

Phase 1: Dark Launch (Woche 1)
Integration läuft parallel zum Altsystem, ohne Auswirkung auf Kunden. Ergebnisse werden verglichen.

Phase 2: Canary Release (Woche 2)
5% des Traffics über neues System. Monitoring intensiviert.

Phase 3: Ramping (Woche 3-4)
Schrittweise Steigerung auf 25%, dann 75%, dann 100%.

Phase 4: Full Rollout (Woche 5+)
Altsystem wird abgeschaltet – aber Rollback-Plan bleibt für 4 Wochen aktiv.

Last-Tests sind Pflicht

Viele ERP-Schnittstellen brechen nicht wegen Komplexität zusammen, sondern wegen der Menge an Anfragen pro Sekunde.

Test-Szenarien:

• Normaler Tag: 100 Bestellungen/h
• Black Friday: 1.000 Bestellungen/h
• Stress-Test: 5.000 Bestellungen/h (System muss stabil bleiben)

Tool-Tipp: k6, JMeter oder Gatling für Last-Tests

Realistische Erwartungen

Kostentreiber

• Datenmigrationsaufwand (+30% bei schlechter Datenqualität)
• Custom-Entwicklungen für spezielle Geschäftslogik
• Middleware-Lizenzen (10.000 – 100.000 €/Jahr)

Eine ERP-Integration ist das offene Herz einer E-Commerce-Operation. Sie entscheidet darüber, ob ihr manuell Excel-Listen hin- und herschieben müsst oder ob euer Business automatisiert skaliert.

Die 7 Erfolgsfaktoren auf einen Blick

• 30% der Zeit in Anforderungen investieren – nicht in Code
• Single Source of Truth definieren – für jedes Datenobjekt
• Middleware ab 4+ Systemen – langfristig günstiger
• Fehlerhandling ab Tag 1 – Retry, Idempotenz, DLQs
• Datenqualität vor Migration – Dubletten bereinigen
• Monitoring aufsetzen – bevor Kunden sich beschweren
• Phasenweiser Rollout – Risiko minimieren

Die gute Nachricht: Erfolg ist planbar. Wer Zeit in Architektur, Datenhygiene und Fehlerhandling investiert, baut nicht nur eine „Schnittstelle“, sondern ein Fundament für das Wachstum der nächsten Jahre.