Der häufigste Schmerz in Unternehmen mit 15-30 Mitarbeitern und eigenem Onlineshop sieht so aus: Zweimal täglich exportiert ein Lagermitarbeiter die Bestände aus dem ERP in eine CSV-Datei, jemand anderes lädt sie in den Shop hoch, und in der Zwischenzeit verkauft der Shop die letzten Einheiten einer Ware, die physisch längst weg ist. Der Kunde wartet eine Woche, bekommt eine „Entschuldigungs"-Mail, macht einen Chargeback und kommt nie wieder.
Das Problem liegt weder im Shop noch im ERP. Das Problem ist, dass beide Systeme in unterschiedlichen Realitäten leben und sich nur dann gegenseitig informieren, wenn jemand Zeit findet. In der Praxis bedeutet das eine Verzögerung von 4-8 Stunden zwischen Verkauf und Bestandsaktualisierung — und in diesem Zeitfenster passieren die meisten Katastrophen.
Die gute Nachricht: 2026 brauchst du dafür weder einen Enterprise-ESB noch ein Halbjahresprojekt. Du brauchst drei Dinge: die Entscheidung, was die Quelle der Wahrheit ist, drei verdrahtete Datenströme und einen Notfallplan, wenn etwas ausfällt.
Drei Ströme, die in beide Richtungen fließen müssen
Jede sinnvolle Shop ↔ ERP-Synchronisation läuft auf drei Ströme hinaus. Der Rest ist Dekoration.
Strom 1: Bestände — vom ERP in den Shop. Die Quelle der Wahrheit ist das ERP, weil dort die Stückzahlen tatsächlich runtergehen — bei Warenausgängen, B2B-Verkäufen, Rücksendungen an Lieferanten. Der Shop muss von jeder Änderung in Sekunden erfahren, nicht in Stunden.
Strom 2: Bestellungen — vom Shop ins ERP. Wenn der Kunde auf „Kaufen" klickt, muss im ERP ein Beleg entstehen (Auftrag oder direkt Warenausgang), damit die Buchhaltung fakturieren kann und das Lager etwas zum Packen hat. Sonst hast du zwei parallele Welten: Quittungen im Shop und Rechnungen im ERP, die zum Monatsende nicht zusammenpassen.
Strom 3: Produktstammdaten — vom ERP in den Shop. Ein neues Produkt, eine Preisänderung, eine Beschreibungsänderung — alles beginnt im ERP und landet im Shop. Warum nicht umgekehrt? Weil Buchhaltung, Kassen und B2B-Verkauf am ERP hängen. Der Onlineshop ist ein Kanal, nicht das Zentrum der Welt.
Polling oder Webhooks — und spielt das eine Rolle
Eine klassische Integration fragt den Shop alle 15 Minuten nach neuen Bestellungen und das ERP nach Bestandsänderungen ab. Funktioniert, hat aber zwei Schwächen: Latenz und Last. Bei 5 Bestellungen pro Tag ist Polling in Ordnung. Bei 200 Bestellungen pro Tag wird Polling entweder ungenau sein oder beide Systeme in die Knie zwingen.
Webhooks lösen das: Der Shop schickt selbst „neue Bestellung", das ERP (oder eine Middleware darüber) schickt „SKU X hat sich geändert". Daten fließen in dem Moment, in dem sie sich ändern. In der Praxis senden die meisten polnischen ERPs (Comarch Optima, enova365, Subiekt GT) nativ keine Webhooks, also übernimmt diese Rolle eine Middleware — eine kleine Anwendung, die dazwischen sitzt.
So eine Middleware sind typisch ein paar hundert Zeilen .NET oder Node.js, gehostet auf einem kleinen VPS. Das ist kein Drei-Quartals-Projekt. Das ist ein Projekt für 4-8 Wochen, inklusive Tests und Produktiv-Rollout.
Konkretes Beispiel: 15-Personen-Kosmetikhersteller
In einem unserer Projekte verkaufte ein 15-Personen-Hersteller von Naturkosmetik parallel über einen Shoper-Shop (B2C) und über Comarch Optima an den Großhandel (B2B). Dieselbe SKU konnte im Shop als „12 verfügbar" angezeigt werden, während der Großhandel gerade eine Rechnung über 20 Stück aus demselben Lager schrieb.
Die Mechanik war diese: Zweimal täglich exportierte der Lagermitarbeiter die Bestände in CSV, lud sie ins Shoper-Backend hoch, und in der Zwischenzeit lief die Welt weiter. Im Schnitt endeten 14 Bestellungen pro Monat mit einer „Entschuldigung, ausverkauft"-Mail. Kunden riefen wütend an, die Google-Bewertungen rutschten ab, der Kundenservice verbrannte 6-8 Stunden pro Woche mit Schadensbegrenzung.
Wir haben eine .NET-Middleware gebaut, die Shoper-Webhooks abhört (neue Bestellung → Reservierung in Optima) und Optima im 60-Sekunden-Takt nach Bestandsänderungen fragt (Push in den Shop per API). Rollout: 5 Wochen, Kosten unter 30.000 PLN. Nach dem ersten vollen Monat sank die Zahl der Stornos wegen „nicht vorrätig" von 14 auf 1 — und der eine war ein Inventurfehler, kein Integrationsbug. Der Lagermitarbeiter gewann 8 Stunden pro Woche zurück, die vorher in Exporte und Entschuldigungs-Mails geflossen waren.
Stolperfallen, die dich im ersten Quartal erwischen
Varianten und Größen. Der Shop sieht oft „Herrenhemd XL" als ein Produkt, das ERP behandelt es als separate SKU. Ohne konsequentes Varianten-Mapping läuft die Bestandssynchronisation in der zweiten Woche auseinander, und niemand weiß, wo der Fehler liegt.
Retouren. Der Kunde schickt ein Paket zurück. Im Shop springt der Bestellstatus auf „retourniert", aber im ERP setzt niemand automatisch die Ware zurück auf Lager. Du musst das einplanen — entweder automatische Gutschriften oder die bewusste Entscheidung, dass das Lager das manuell macht (mit Checkliste).
Mehrere Lager. Wenn du aus drei Standorten versendest, muss der Shop die Summe der Bestände zeigen, aber Reservierungen müssen auf ein konkretes Lager gehen. Das ist nicht trivial — und die häufigste Ursache für „komische" Fehler nach dem ersten Monat.
Aktionspreise. Eine Aktion im Shop sollte nicht als Basispreis ins ERP zurückschreiben. Du musst entscheiden, wo der Basispreis lebt und wo die Promo-Regeln liegen, und diese beiden Ebenen nicht vermischen.
Middleware-Ausfall. Ein durchschnittlicher VPS läuft zu 99,9% der Zeit — das sind etwa 8 Stunden Ausfall pro Jahr. Du brauchst eine Event-Warteschlange (RabbitMQ, Redis, was auch immer) und einen vernünftigen „spiele alles nach, was vorbeigeflogen ist, wenn der Server wieder läuft"-Mechanismus. Sonst verlierst du am Ausfalltag einfach Daten.
Was du diesen Montag tun solltest
Bevor du überhaupt mit einem Integrator sprichst, mach drei Dinge:
- Zähle, wie viele Bestellungen im letzten Monat wegen „nicht vorrätig" storniert wurden. Multipliziere mit der durchschnittlichen Marge und mit 12. Das ist dein jährlicher Verlust durch fehlende Synchronisation.
- Miss, wie viele Stunden pro Woche dein Team mit manuellen Exporten und Imports zwischen Shop und ERP verbringt. Multipliziere mit dem Stundensatz und mit 50. Das sind die zweiten Kosten.
- Frage deinen ERP-Anbieter (Comarch, Insert, Soneta), ob er einen fertigen Konnektor zu deinem Shop hat und was er genau abdeckt. In den meisten Fällen deckt der „fertige Konnektor" 70-80% der Anforderungen ab, und es bleiben 2-3 Lücken, die per Middleware zu schließen sind.
Wenn du nach diesen drei Schritten siehst, dass du jährlich mehrere Tausend Euro und eine Vollzeitstelle für CSV-Schieberei verlierst — das ist ein Projekt, das sich in einem Quartal amortisiert. Die meisten Firmen, die mit diesem Problem zu uns kommen, zögern nicht, weil sie den Sinn nicht sehen, sondern weil sie nicht wissen, mit welchem konkreten Schritt sie anfangen sollen.
Shop-ERP-Synchronisation ist kein IT-Projekt. Es ist der Weg, um Kunden nicht mehr aus einem dummen Grund zu verlieren.