Ein neuer Onlineshop löst kein Excel-Chaos, wenn Artikelpreise weiterhin per Hand gepflegt werden, Lagerbestände erst am Abend abgeglichen sind und Aufträge zwischen drei Postfächern hängen bleiben. Dieses Praxisbeispiel erfolgreiche Systemintegration zeigt, wie ein mittelständisches Handelsunternehmen seine Systemlandschaft so ordnet, dass Shop, ERP und Lager miteinander arbeiten - statt dass Mitarbeitende die Lücken dazwischen schließen.
Es geht dabei nicht um ein spektakuläres Technikprojekt. Der entscheidende Fortschritt entsteht im Alltag: Ein Artikel wird einmal angelegt. Ein Bestand ist verlässlich sichtbar. Eine Bestellung landet ohne Umwege dort, wo sie verarbeitet werden muss. Und der Go-Live wird nicht zum Risiko, weil die kritischen Sonderfälle vorher geklärt wurden.
Die Ausgangslage: Ein Shop neben dem eigentlichen Geschäft
Das Unternehmen in diesem anonymisierten, aber realitätsnahen Beispiel verkauft technische Produkte an gewerbliche Kunden und Privatkunden. Der bestehende Shop war über Jahre gewachsen. Das ERP verwaltete Artikel, Einkauf, Rechnungen und Teile der Kundenstammdaten. Im Lager lief eine separate Lösung für Kommissionierung und Versand. Dazu kamen Tabellen für Sonderpreise, Produktfreigaben und einzelne Vertriebsvereinbarungen.
Jedes System erfüllte für sich einen Zweck. Zusammen verursachten sie Reibung. Neue Artikel wurden mehrfach angelegt. Preisänderungen mussten an verschiedenen Stellen kontrolliert werden. Der Vertrieb fragte regelmäßig nach, ob ein Produkt tatsächlich lieferbar sei. Wenn eine Bestellung im Shop nicht korrekt ins ERP übertragen wurde, begann die Fehlersuche zwischen E-Commerce, Buchhaltung und Lager.
Der Wunsch nach einem Relaunch war deshalb verständlich. Nur: Ein schöneres Frontend hätte das Kernproblem nicht gelöst. Die Frage lautete nicht zuerst: Welches Theme soll der Shop bekommen? Sie lautete: Welche Daten sind führend, welche Informationen dürfen in welche Richtung fließen und wer ist verantwortlich, wenn ein Prozess aus dem Takt gerät?
Praxisbeispiel: Erfolgreiche Systemintegration beginnt vor der Schnittstelle
Für die Umsetzung wurde Shopware 6 als Verkaufskanal mit einem Odoo-ERP verbunden. Das Lager blieb zunächst als spezialisierte Lösung bestehen. Das ist ein wichtiger Punkt: Erfolgreiche Systemintegration bedeutet nicht automatisch, jedes vorhandene System abzulösen. Wenn eine Anwendung ihren Zweck zuverlässig erfüllt und sauber angebunden werden kann, ist eine Integration oft wirtschaftlicher und risikoärmer als eine Komplettmigration.
Am Anfang stand deshalb keine Programmierung, sondern eine gemeinsame Prozessaufnahme. Fachbereiche, Vertrieb, Lager, Buchhaltung und E-Commerce beschrieben nicht nur den Soll-Prozess, sondern auch die Ausnahmen. Gerade sie entscheiden über die Qualität einer Integration. Was passiert bei Teillieferungen? Wie werden kundenspezifische Preise behandelt? Darf ein Artikel verkauft werden, wenn Nachschub bereits bestellt, aber noch nicht eingebucht ist? Und wie geht das Team mit Retouren um, die im Shop gemeldet, aber im Lager geprüft werden?
Diese Fragen wirken kleinteilig. Werden sie übersprungen, tauchen sie spätestens nach dem Launch als Tickets, manuelle Korrekturen und unzufriedene Kunden wieder auf.
Klare Datenhoheit statt Synchronisation in alle Richtungen
Im Projekt wurde für jede Datenart ein führendes System festgelegt. Das ERP verantwortete Artikelstammdaten, Einkaufspreise, Steuerlogik und Kundenkonditionen. Shopware 6 erhielt die verkaufsrelevanten Produktinformationen, Kategorien, Medien und redaktionellen Inhalte. Das Lager war maßgeblich für physische Bestände und Versandstatus.
Das klingt selbstverständlich, ist in gewachsenen Landschaften aber oft nicht sauber geregelt. Ohne Datenhoheit entsteht ein Kreislauf aus gegenseitigen Überschreibungen. Eine Produktbezeichnung wird im Shop geändert, im ERP zurückgespielt und beim nächsten Import erneut ersetzt. Oder ein Bestand erscheint im Shop als verfügbar, obwohl er im Lager bereits für einen anderen Auftrag reserviert wurde.
Die Lösung war kein Datenabgleich nach dem Prinzip „alles mit allem“. Stattdessen wurden definierte Ereignisse übertragen: Artikeländerungen aus dem ERP, Bestands- und Versandmeldungen aus dem Lager, Bestellungen aus Shopware in das ERP sowie ausgewählte Kundeninformationen in beide Richtungen. Redaktionelle Shoptexte blieben bewusst im Shop. So behielt das Marketing Handlungsspielraum, ohne die kaufmännischen Stammdaten zu gefährden.
Die Schnittstelle muss mit Fehlern rechnen
Eine Schnittstelle ist nicht deshalb gut, weil sie Daten übertragen kann. Sie muss auch nachvollziehbar reagieren, wenn Daten fehlen, ein Zielsystem vorübergehend nicht erreichbar ist oder ein Auftrag fachlich nicht verarbeitet werden darf.
Im Praxisbeispiel wurden Übertragungen deshalb protokolliert und mit eindeutigen Status versehen. Fehlgeschlagene Vorgänge wurden nicht still verworfen, sondern in einer kontrollierbaren Warteschlange abgelegt. Das zuständige Team konnte erkennen, welcher Auftrag betroffen war, warum er angehalten wurde und ob nach einer Korrektur ein erneuter Lauf sinnvoll ist.
Das verhindert keine Fehler vollständig. Es verhindert aber, dass sie unbemerkt bleiben. Für den Betrieb ist das wichtiger als eine auf dem Papier perfekte Architektur. Ein System muss auch an einem Montagmorgen verständlich sein, wenn ein Kunde auf seine Bestellung wartet.
Der Projektablauf: Erst Sicherheit schaffen, dann Tempo aufnehmen
Die technische Umsetzung erfolgte schrittweise. Zunächst wurden Testdaten über die geplanten Schnittstellen ausgetauscht. Danach folgten typische Bestellungen, Sonderpreise, rabattierte Warenkörbe, Teillieferungen und Stornierungen. Erst als diese Fälle nachvollziehbar durchliefen, wurden größere Datenmengen und reale Prozesszeiten getestet.
Besonders hilfreich war ein gemeinsamer Abnahmekatalog. Er übersetzte technische Anforderungen in prüfbare Geschäftsvorfälle: Ein B2B-Kunde meldet sich an, sieht seine vereinbarten Preise, bestellt mehrere Artikel, erhält eine Teillieferung und später die korrekte Rechnung. So konnten Fachabteilung und Entwicklung über denselben Vorgang sprechen, statt sich hinter Begriffen wie API, Mapping oder Webhook zu verlieren.
Vor dem Go-Live wurde außerdem entschieden, welche Daten migriert werden mussten und welche im Altsystem verbleiben durften. Nicht jede Historie gehört zwangsläufig in eine neue Plattform. Alte, unvollständige oder nicht mehr relevante Datensätze erhöhen Aufwand und Fehlerrisiko. Für Kunden war ein Zugriff auf Bestellhistorien sinnvoll, für veraltete Entwürfe oder doppelte Produktdatensätze dagegen nicht.
Der Umstieg selbst wurde in ein klar begrenztes Zeitfenster gelegt. Währenddessen gab es feste Ansprechpartner, eine Rückfalloption und definierte Kontrollen für Bestellungen, Zahlungen, Bestände und E-Mails. Go-Live ohne Schweißperlen heißt nicht, dass niemand aufmerksam sein muss. Es heißt, dass Verantwortlichkeiten, Prüfungen und Reaktionswege vorher feststehen.
Woran sich der Nutzen tatsächlich messen lässt
Nach einer Systemintegration sollte nicht allein zählen, ob die Schnittstelle technisch läuft. Entscheidend ist, ob sich die tägliche Arbeit verbessert. Im beschriebenen Fall beobachtete das Unternehmen über die ersten Wochen insbesondere vier Kennzahlen:
- Wie viele Artikel- und Preisänderungen noch manuell in mehreren Systemen gepflegt werden mussten.
- Wie viele Bestellungen wegen fehlender oder fehlerhafter Daten nachbearbeitet wurden.
- Wie stark Bestandsabweichungen und Rückfragen zur Lieferfähigkeit zurückgingen.
- Wie viel Zeit zwischen Bestellung, ERP-Übergabe, Versand und Kundeninformation verging.
Diese Kennzahlen machen Fortschritt sichtbar, ohne falsche Präzision vorzutäuschen. Ein Unternehmen mit vielen Variantenartikeln hat andere Engpässe als ein Händler mit wenigen, aber stark individualisierten B2B-Aufträgen. Deshalb gehören Ziele und Messwerte in die Konzeptphase - nicht als nachträgliche Erfolgsfolie.
Was sich nicht standardisieren lässt
Eine erfolgreiche Integration folgt klaren Prinzipien, aber sie ist nie vollständig von der Stange. Bei einem einfachen Sortiment kann eine direkte Anbindung von Shop und ERP ausreichend sein. Bei komplexen Kundenverträgen, mehreren Lagern, Marktplätzen oder regulierten Daten braucht es häufig zusätzliche Prüfungen, Middleware oder bewusst getrennte Prozesse.
Auch Echtzeit ist nicht immer die beste Antwort. Bestände müssen oft zeitnah aktualisiert werden. Für bestimmte Produkttexte oder interne Auswertungen kann ein geplanter Abgleich dagegen sinnvoller sein, weil er Systeme entlastet und Fehler leichter kontrollierbar macht. Die richtige Entscheidung hängt von Geschäftsrisiko, Datenvolumen und Prozessgeschwindigkeit ab.
Für Inter Medien Networks liegt der Kern deshalb nicht in möglichst vielen Schnittstellen. Er liegt in einem belastbaren Gesamtbild aus Geschäftsablauf, Datenmodell, Nutzeroberfläche und Betrieb. Ein System statt zehn Insellösungen bedeutet nicht weniger Fachlichkeit. Es bedeutet, dass Fachlichkeit an der richtigen Stelle abgebildet wird.
Wenn Sie vor einem Shop-Relaunch, einer ERP-Einführung oder der Ablösung manueller Listen stehen, beginnen Sie mit einem ehrlichen Blick auf den ersten Auftrag des Tages: Wo wird heute kopiert, nachgefragt oder korrigiert? Genau dort liegt meist der sinnvollste Ansatz für eine Integration, die nicht nur startet, sondern langfristig trägt.