Ein funktionierender Online-Shop braucht den Draht zu deinem ERP-System. Ohne diese Verbindung passieren die klassischen Dinge: Produkte werden doppelt verkauft, Lagerbestände stimmen nicht, Rechnungen fehlen, Zahlungsdaten gehen verloren. Das Problem: Viele ERP-Systeme sind 15 Jahre alt, wurden nicht für E-Commerce gebaut und spielen einfach nicht mit deinem Shop zusammen.
Martins Perspektive: ERP-Integration ist Teil der täglichen Geschäftsarbeit für dasistweb. Nicht immer schmerzlos, aber Standard. SAP, Dynamics, Sage: Wir kennen die Schmerzen und die Lösungen. Das Wichtigste: ERP-Integration ist 70% Prozessdesign, 30% Technik. Wer das übersieht, scheitert.
Wie du diese Integration angehst, welche Architektur-Entscheidungen es gibt und was die Fallstricke sind, zeigen wir dir hier.
Inhalt
- Warum ERP-Integration entscheidend ist
- Typische Datenflüsse: Was muss synchronisiert werden?
- SAP Business One und S4HANA anbinden
- Microsoft Dynamics 365 Integration
- Sage ERP Anbindung
- Middleware vs Direktintegration: Welche Architektur passt?
- Echtzeit vs Batch-Synchronisation
- Häufige Fehler bei der Integration
- Kosten realistisch einschätzen
- KI in der Middleware: Datenmapping und Fehler-Heilung
- Best Practices für erfolgreiche Integration
Warum ERP-Integration entscheidend ist
Dein Shop ist eine Fassade. Der echte Motor sind die Prozesse dahinter: Bestellungen aufnehmen, Lagerbestände reduzieren, Rechnungen schreiben, Zahlungen abgleichen, Kundendaten in die CRM-Systeme spielen. Das alles passiert in deinem ERP. Der Shop ohne ERP ist eine tote Datei.
Wie du die Integration angehst, entscheidet über drei kritische Dinge: Fehlerquoten, Kundenerlebnis und operative Kosten. Ein Shop der manuell mit dem ERP abgeglichen werden muss, kostet dich schnell mehrere hundert bis über tausend Euro pro Monat an reiner Bürokratie. Das ist kein skalierbarer Betrieb, das ist Hamsterrad.
Eine solide Integration bedeutet:
- Bestellungen landen automatisch im ERP
- Lagerbestände sind in Echtzeit synchron
- Kundeninformationen fließen in beide Richtungen
- Rechnungsprozesse sind automatisiert
- Zahlungen werden abgerechnet ohne Umschweife
Das ist kein optionales Kann. Das ist die Grundlage für jeden professionellen Online-Shop. Alles andere ist ein Provisorium.
Typische Datenflüsse: Was muss synchronisiert werden?
Nicht alle Daten sind gleich wichtig. Es gibt vier Kernflüsse die jedes System abdecken muss:
Bestellungen und Aufträge: Die Order kommt vom Shop ins ERP mit allen Positionen, Kundendaten, Lieferadresse, Bezahlmethode und Bemerkungen. Das ERP pickt die Order aus dem Backlog, lagert sie, erstellt eine Liefernotiz und eine Rechnung. Die Rechnung geht zurück an den Shop und wird dem Kunden zugesendet. Der Status (offen, verpackt, versandt, etc.) wird synchronisiert damit der Kunde in seinem Konto immer weiß wo die Order steht.
Lagerbestände: Der kritischste Fluss. Jedes Mal wenn im ERP eine Menge reduziert wird (weil die Order verpackt wird), muss das sofort in den Shop zurück. Gleichzeitig muss der Shop wissen welche Menge verfügbar ist. Das ist der meistverursachte Fehler: Ein Shop der Overselling zulässt, weil die Bestände nicht synchron sind.
Produktdaten und Preise: Preisänderungen, neue Varianten, Kategorien, Beschreibungen. Das sollte vom Shop aus definiert oder vom ERP aus, aber definitiv nicht an beiden Stellen. Wenn du ein PIM hast (und du solltest eins haben), dann sitzt die Wahrheit dort. PIM spielt zu Shop und ERP, nicht umgekehrt.
Kundendaten und Zahlungen: Kundenadressen, Kontaktdaten, Bonität, offene Rechnungen. Im B2B ist das kritisch: Ein Kunde der im ERP keinen aktiven Vertrag hat, sollte auch im Shop nicht bestellen können. Zahlungen werden synchronisiert damit der Abgleich automatisiert ist.
Ein gutes Integrations-Konzept priorisiert diese Flüsse. Bestellungen und Lagerbestände zuerst. Produktdaten dann. Alles andere sekundär.
SAP Business One und S4HANA anbinden
SAP ist der Elefant im Raum. Das System kann fast alles, spricht aber eine Sprache die der Rest der Welt nicht versteht.
SAP Business One ist die kleinere Variante, oft in mittelständischen Unternehmen zu Hause. Die Anbindung ist relativ unkompliziert: SAP One hat eine DI API (Diapi) und seit neuerem ein REST-API. Du kannst Order via API anlegen, Bestandsbestände auslesen, Kunden updaten. Das ist nicht elegant, aber es funktioniert. Der Haken: SAP One skaliert nicht elegant. Irgendwann wird das System zum Engpass.
SAP S4HANA ist das nächste Level. Das ist der Rolls Royce der ERP-Systeme. Die Anbindung läuft über OData oder die CloudFoundry API. S4HANA hat echte moderne APIs, kann REST sprechen, unterstützt Events (wenn eine Order erstellt wird, kann das System das sofort wissen). Das ist ein Cloud-System, nicht ein Monolith.
Der Reality Check: Eine SAP-Anbindung mit Middleware kostet nicht weniger als 15.000+ EUR Einmalkosten, plus laufende Kosten für die Middleware-Lizenz und Betrieb. Das ist nicht für kleine Shops. Das ist Enterprise.
Unsere Erfahrung: SAP-Anbindungen funktionieren am besten wenn es ein dediziertes Team im ERP gibt das die Prozesse dort versteht und die Integration aktiv unterstützt. Wenn das nicht der Fall ist, wird das ein Kampf.
Microsoft Dynamics 365 Integration
Microsoft hat bei Dynamics eine ganz andere Strategie als SAP. Dynamics 365 ist Cloud-first und API-first gebaut. Das macht die Anbindung deutlich einfacher.
Dynamics hat drei Produkte die relevant sind:
Dynamics 365 Business Central ist für kleinere bis mittlere Unternehmen. Vollständig in der Cloud, REST-API von Haus aus, Power Automate für Workflows. Du kannst Bestellungen via API anlegen, Lagerbestände auslesen, Kundendaten synchronisieren. Die Anbindung an einen Shop ist hier relativ schmerzlos möglich.
Dynamics 365 Supply Chain Management ist für größere Player. Hier geht es um komplexe Lieferketten, Nachfrageplanung, Lagerverwaltung auf mehrere Standorte. Die Integration ist mächtiger, aber auch komplexer.
Dynamics 365 Commerce ist Microsoft's Versuch einen integrierten Commerce-Ansatz anzubieten. Das ist kein Shopify oder Shopware Konkurrenz, sondern eher eine Add-on zu Supply Chain Management für größere Retail-Netzwerke.
Microsoft's großer Vorteil: Die gesamte Azure-Infrastruktur, Power Automate für Low-Code-Prozesse, gute REST-APIs. Wenn du auf Microsoft-Stack setzt (Teams, Power BI, Azure), ist Dynamics die natürliche Wahl.
Dynamics 365 Business Central ist in der Regel günstiger in der Lizenzierung als SAP-Lösungen (aktuelle Preise direkt beim Anbieter anfragen). Die Anbindung an einen externen Shop kannst du mit Power Automate oder benutzerdefinierten Flows bauen. Immer noch Enterprise-Denken, aber zugänglicher.
Sage ERP Anbindung
Sage ist der unterschätzte Player. Das System ist bei Handwerkern, kleinen Produktionsbetrieben und mittelständischen Handel sehr verbreitet, aber im E-Commerce-Umfeld wenig präsent.
Sage 100 (ehemals Sage Office Line) ist der Klassiker in Deutschland. Das ist ein on-premise System, etwas in die Jahre gekommen, aber stabil. Die Anbindung läuft über Datenbank-Direktzugriff oder über CSV/XML-Export-Import-Prozesse. Das ist nicht elegant, aber für kleinere Volumen ausreichend.
Sage Intacct ist die Cloud-Variante. Das System ist reiner auf Buchhaltung und Finanzmanagement fokussiert, weniger auf Logistik. Für die Anbindung an einen Shop brauchst du also noch ein separates Lagerverwaltungssystem.
Sage X3 ist für größere Unternehmen konzipiert. Das System hat bessere APIs und ist moderner aufgebaut als Sage 100. Die Integration an einen Shop ist machbar, aber nicht trivial.
Sage-Anbindungen sind oft günstiger als SAP, aber auch weniger elegant. Viele Sage-Nutzer fahren mit Batch-Synchronisationen (tägliche oder stündliche CSV-Uploads) statt Echtzeit-APIs. Das funktioniert, hat aber Grenzen bei wachsenden Bestellvolumina.
Middleware vs Direktintegration: Welche Architektur passt?
Das ist die entscheidende Frage. Baue ich die Integration direkt zwischen Shop und ERP, oder setze ich eine Middleware dazwischen?
Direktintegration bedeutet: Der Shop spricht direkt mit dem ERP via API. Vorteil: Keine zusätzliche Komplexität, weniger Systeme im Spiel. Nachteil: Wenn das ERP-API sich ändert oder langsam wird, leidet der Shop direkt darunter. Auch wird es schnell messy wenn du mehrere Quellsysteme hast (Shop, Marketplace, stationäre Filialen).
Middleware (auch iPaaS = Integration Platform as a Service) bedeutet: Eine separate Plattform sitzt zwischen Shop und ERP und orchestriert die Kommunikation. Die wichtigsten Spieler sind:
- Alumio: Moderner, flexibel, auf API-Integration fokussiert. Gutes Interface, gute Dokumentation. Zum aktuellen Zeitpunkt ab einem mittleren dreistelligen Betrag monatlich je nach Volumen.
- Celigo: Ähnliches Konzept wie Alumio, auch mit starkem Fokus auf automatisierte Prozesse. Vergleichbare Preisklasse.
- MuleSoft: Das High-End-Angebot. MuleSoft ist bei großen Enterprise-Implementierungen zu Hause. Deutlich teurer, dafür bekommst du ein Support-Team und eine Enterprise-Plattform.
Middleware hat Vorteile: Sie puffert ab wenn Systeme ausfallen, sie normalisiert Datenformate, sie erlaubt dir mehrere Quellsysteme zu orchestrieren, und sie hat ein Audit-Trail. Nachteil: Zusätzliche Komplexität, zusätzliche Kosten, zusätzliches System das überwacht und gewartet werden muss.
Unsere Empfehlung: Unter 100 Bestellungen pro Tag spricht nichts gegen eine schlanke Direktintegration. Ab 300+ Bestellungen pro Tag oder wenn du mehrere Quellsysteme hast, wird Middleware attraktiv. Für SAP ist eine Middleware quasi notwendig, weil SAP-APIs weniger zuverlässig sind als moderne Cloud-Systeme. Unsere E-Commerce Beratung hilft dir, die richtige Architektur zu wählen.
Echtzeit vs Batch-Synchronisation
Das ist eine Architektur-Entscheidung die oft unterschätzt wird.
Echtzeit bedeutet: Wenn eine Order im Shop eingehen, fliesst sie sofort ins ERP. Wenn Lagerbestände im ERP sinken, sind sie sofort im Shop aktualisiert. Das ist technisch anspruchsvoll, weil beide Systeme schnell und zuverlässig sein müssen. Wenn die Netzwerkverbindung zwischen Shop und ERP bricht, muss das System das handhaben ohne Daten zu verlieren.
Batch bedeutet: Die Synchronisation läuft zeitgesteuert. Jede Stunde, jede Nacht, oder alle zwei Stunden. Orders werden gebündelt übertragen, Bestandsbestände werden synchronisiert. Das ist robuster, aber verzögerter.
Was ist besser? Das kommt auf dein Geschäftsmodell an:
- Echtzeit brauchst du wenn: Du viele gleichzeitige Käufer hast (Overselling wäre ein Desaster), wenn du B2B mit Limit-Logik hast, oder wenn Kunden sofort nach der Bestellung Daten vom Shop abrufen (Rechnungen, Tracking).
- Batch reicht wenn: Du 50-100 Bestellungen pro Tag hast und kannst mit einer Stunde Verzögerung leben, wenn Overselling selten ist und einfach korrigiert wird, oder wenn dein ERP eh nur tagsüber läuft.
Hybrid ist oft der Weg: Kritische Flüsse (Bestellungen, Lagerbestände) in Echtzeit. Weniger kritische Flüsse (Kundendaten, Produktdaten) im Batch.
Die technische Herausforderung bei Echtzeit: Was passiert wenn die Synchronisation fehlschlägt? Retry-Logik, Dead-Letter-Queues, Fehlerbenachrichtigungen. Das alles muss mitgebaut sein.
Häufige Fehler bei der Integration
Wir sehen in unseren Projekten immer wieder die gleichen Fehler:
1. Keine Daten-Wahrheit definieren. Das Projekt startet ohne zu klären: Sitzt die Wahrheit im Shop oder im ERP? Wenn in beiden Systemen Änderungen erlaubt sind, entstehen Konflikte. Beispiel: Die Lagerbestände. Wer ist die Wahrheit? Das ERP, weil das die Lagerung verwaltet. Oder der Shop, weil der sieht welche Kundenbestellungen reinkommen? Das muss geklärt sein, bevor die Integration startet.
2. Fehlerbehandlung nicht durchdacht. Was passiert wenn die Order ins ERP kommt, aber die ERP-Response nicht zurück zum Shop kommt? Oder wenn der Shop eine Order ablehnt (weil Zahlung fehlgeschlagen), das ERP das aber nicht mitbekommen hat? Diese Edge Cases müssen definiert sein.
3. Zu viele Felder synchronisieren. Anfänger versuchen alle 200 Felder aus dem ERP in den Shop zu schieben. Das macht alles kompliziert. Eigentlich sind es 15-20 Felder pro Bestellung die wirklich zählen. Alles andere ist Mehraufwand.
4. Keine Monitoring. Die Integration läuft, aber keiner schaut drauf ob sie korrekt läuft. Erst wenn Beschwerden vom Kunden kommen, merkt man dass Orders nicht mehr synchronisieren. Jede Integration braucht ein Monitoring-Dashboard: Wieviele Orders wurden synchronisiert, wie viele sind fehlgeschlagen, wie lange dauerte die Synchronisation.
5. Zu optimistisch auf das ERP-API bauen. ERP-APIs sind oft nicht produktionsreif. Sie sind langsam, geben kryptische Fehlermeldungen, oder haben undefiniertes Verhalten bei Fehlern. Wenn du auf ein SAP-API baust, dann mit der Erwartung dass es alle paar Wochen merkwürdig wird.
6. Schulung vergessen. Die Integration läuft und die Prozesse sind unklar. Wer darf Orders stornieren, wer darf Preise ändern, wer meldet Fehler? Wenn das nicht klar ist, wird dein Team schnell frustriert.
Kosten realistisch einschätzen
Das ist das Thema bei dem sich alle am meisten täuschen.
Eine ERP-Integration gibt es nicht zum Festpreis. Es gibt zu viele Variablen. Aber wir können Bandbreiten nennen:
Szenario 1: Kleine Integration, modernes Cloud-ERP
- Shop + Microsoft Dynamics 365 Business Central
- Bestellungen, Lagerbestände, Kundendaten
- Echtzeit-Synchronisation
- Kosten: ab 8.000 EUR Einmalkosten. Monatlich: ab 200 EUR Betrieb und Monitoring.
Szenario 2: Mittlere Integration, SAP oder Sage
- Shop + SAP Business One oder Sage 100
- Bestellungen, Lagerbestände, Kundendaten, Preissynchronisation
- Batch + teilweise Echtzeit
- Middleware erforderlich
- Kosten: ab 20.000+ EUR Einmalkosten. Monatlich: ab 1.000+ EUR (Middleware + Betrieb).
Szenario 3: Große Integration, Enterprise ERP
- Shop + SAP S4HANA oder Dynamics 365 Supply Chain
- Mehrere Märkte, Mehrlagersysteme
- Complex Business Rules
- Middleware notwendig
- Dediziertes Integrations-Team
- Kosten: ab 50.000+ EUR Einmalkosten. Monatlich: ab 3.000+ EUR.
Diese Kosten enthalten:
- Analyse und Design (15-25% der Kosten)
- Implementierung (50-60%)
- Testing (10-15%)
- Middleware-Lizenzen und Hosting
- Training und Dokumentation
Was nicht enthalten: Externe Berater, laufende Optimierungen, oder Prozess-Redesign im ERP selbst.
Der Reality Check: Viele Unternehmen unterschätzen die laufenden Kosten. Die Implementierung ist eine Einmalzahlung. Aber die Middleware, der Betrieb, die Überwachung, die Anpassungen wenn sich deine Prozesse ändern, das sind kontinuierliche Kosten. Ein gut umgesetztes System kann sich über 3-5 Jahre über Fehlerreduktion und Automationen rechnen. Ein schlecht umgesetztes wird dein Team zum Wahnsinn treiben.
KI in der Middleware: Datenmapping und Fehler-Heilung
Klassische ERP-Integrationen stecken seit Jahren an denselben zwei Stellen fest: Mapping-Regeln pflegen und Fehler behandeln wenn doch mal eine unerwartete Eingabe kommt. Beides frisst Entwickler-Zeit. Genau dort setzt KI in der Middleware heute praktisch an - nicht als Marketing-Overlay, sondern als pragmatischer Helfer in bestehenden n8n-, Alumio- oder Celigo-Flows.
Datenmapping automatisieren. Jeder kennt das: Das ERP liefert ein Feld "LAND_ISO", der Shop erwartet "country_code". Dazwischen sitzen 200 Zeilen Transformations-Code. Mit einem LLM-Schritt in der Middleware lässt sich die Grundstruktur eines Mappings aus Beispieldaten ableiten. Der Entwickler prüft und fixt, statt alles von Hand zu tippen. Neue Felder vom Lieferanten? Der Prompt bekommt ein paar Samples und schlägt die Transformation vor. Das ersetzt keine Reviews, halbiert aber den Zeitaufwand für banalen Mapping-Code.
Fehlertolerantes Verarbeiten. ERP-APIs geben gerne kryptische Fehler zurück. "Order rejected: invalid code 47". In klassischen Integrationen landen solche Fälle in einer Dead-Letter-Queue, jemand muss sie manuell anschauen. Mit einem Claude- oder GPT-Schritt, der Fehler plus Kontext analysiert, lassen sich bekannte Muster automatisch klassifizieren: "Mehrwertsteuer-Problem", "Kunde gesperrt", "Artikelnummer veraltet". Der Flow entscheidet dann, ob er retryt, einen Alt-Wert einsetzt oder eskaliert. Für die 5%-Fehlerrate, die jede ERP-Anbindung hat, ist das ein echter Hebel.
EDI-Bestellungen aus PDF oder Freitext. Viele Mittelständler bekommen Bestellungen noch per E-Mail als PDF-Anhang oder strukturierten Mail-Text. Claude liest die Bestellung, extrahiert Artikelnummern, Mengen, Lieferadresse und schreibt sie strukturiert in den Bestell-Flow. Das erspart Innendienst-Tippen und bringt klassische B2B-Kanäle ins digitale Fließband.
n8n als Integrations-Zentrale. Für mittelgroße Projekte setzen wir n8n mit KI-Knoten zunehmend als Middleware ein - schlanker als SAP-PI, flexibler als reine iPaaS-Lösungen. Preislisten-Synchronisation aus dem ERP, Produktdaten-Anreicherung per LLM, Versandbestätigungen per Mail-Generator. Das kippt die alte "Middleware ist Enterprise" -Regel für alles unterhalb der echten SAP-S4-Liga.
Grenzen im Kopf behalten. Ein LLM im kritischen Bestell-Pfad ohne Validierung ist fahrlässig. Die Modelle halluzinieren Felder, die der Kunde nie bestellt hat. Jeder KI-Schritt in der Middleware braucht eine Schema-Validierung dahinter und klare Fehlerfenster. Sensible Stamm- und Preisdaten gehören zudem nicht ungefiltert in fremde Cloud-APIs. Wer das ernst nimmt, braucht entweder europäische Hoster mit AVV oder ein selbst gehostetes Modell.
Wie wir das für Kunden konkret aufbauen, steht auf der Leistungsseite KI-Implementierung. Zum Thema Shop-Prozesse komplett automatisieren passt Automatisierung im Online-Shop.
Best Practices für erfolgreiche Integration
Was funktioniert, haben wir in jahrelanger Projekterfahrung gelernt:
1. Starte mit den wichtigsten Datenflüssen. Nicht versuchen alles auf einmal zu integrieren. Zuerst: Bestellungen und Lagerbestände. Alles andere danach.
2. Definiere die Daten-Wahrheit. Für jeden kritischen Datensatz: Wo sitzt die Wahrheit? Wer darf ändern? Das muss dokumentiert sein.
3. Baue robuste Fehlerbehandlung. Was bei manuellem Prozess OK ist (Mails schreiben, anrufen) ist in der Integration nicht OK. Du brauchst automatische Retries, Fehler-Queues und Notifications.
4. Implementiere Monitoring von Tag 1. Nicht erst nach Go-live. Ein Dashboard das zeigt: Order-Volumen, Fehlerrate, Synchronisations-Latenz. Das ist dein frühes Warnsystem.
5. Teste mit echten Datenvolumina. Testumgebungen mit 100 Orders sind sinnlos. Teste mit 10.000 Orders und schaue wie das System läuft.
6. Dokumentiere die Prozesse, nicht die Technologie. Dein Team muss verstehen: Wenn die Synchronisation ausfällt, was mache ich? Nicht wie das System intern funktioniert, sondern wie ich als Operator damit umgehe.
7. Baue Redundanz ein. Wenn die Integration kaputt ist, kann der Shop trotzdem Bestellungen annehmen? Kann das ERP weiterhin Rechnungen schreiben? Dein System muss nicht perfekt sein, aber es darf nicht komplett kaputtgehen wenn ein Teil ausfällt.
8. Plane 3-6 Monate für eine solide Integration. Nicht weniger. Das ist nicht pessimistisch, das ist realistisch. Analyse, Design, Implementierung, Testing, Training, Go-live. Parallel dazu machen Dinge kaputt, die niemand erwartet hat.
Fazit: Integration ist nicht Technik, sondern Prozessdesign
Eine ERP Integration im E-Commerce ist 30% Technik und 70% Prozessverständnis. Die beste Architektur nützt nix wenn die Prozesse im ERP selbst nicht passen. Und die beste Middleware nützt nix wenn dein Team nicht weiß wie sie damit umgeht.
Worauf du achten solltest:
- Definiere deine kritischen Datenflüsse und starte dort.
- Wähle die Architektur (Direktintegration oder Middleware) basierend auf Skalierung, nicht auf Kosten.
- Baue nicht auf "spricht mit dem API." Baue auf "funktioniert auch wenn etwas kaputt geht".
- Rechne mit 3-6 Monaten Implementierung und mit kontinuierlichen Betriebskosten.
- Monitoring ist nicht optional. Das ist dein Sicherheitsnetz.
Die Unternehmen die ihre ERP-Integrations gut hinbekommen, haben einen riesigen Vorteil: Keine manuellen Abstimmungen, keine Fehler, keine Überstunden für dein Team. Das zahlt sich aus.