In vielen Shopify-Plus-Projekten wirkt die ERP-Integration am Anfang wie eine relativ klare technische Aufgabe: Shopify braucht Produktdaten, Preise, Bestände, Kundendaten und Bestellungen, während das ERP viele dieser Informationen bereits enthält. Der naheliegende Gedanke ist deshalb, beide Systeme direkt miteinander zu verbinden.
In einfachen Setups kann das durchaus funktionieren, vor allem bei kleineren Shops, wenigen Märkten, überschaubaren Prozessen und stabilen Datenflüssen. In solchen Fällen ist eine direkte Integration manchmal der pragmatischste Weg, weil sie weniger Systeme, weniger Infrastruktur und weniger Projektumfang mit sich bringt.
In Enterprise-Shopify-Projekten ist die Situation jedoch oft eine andere, denn dort geht es nicht nur darum, Daten von A nach B zu bewegen. Es geht um unterschiedliche Verantwortlichkeiten, klare Systemgrenzen, Prozesslogik, Fehlerbehandlung, Skalierung, Wartbarkeit und die Frage, welches Team welchen Teil der Plattform langfristig besitzen kann.
Deshalb verbinden wir Shopify in komplexeren Projekten fast nie direkt mit dem ERP. Nicht, weil Middleware grundsätzlich besser ist, sondern weil eine direkte Integration oft nur auf dem Architekturdiagramm einfacher aussieht.
Das Missverständnis: Weniger Systeme bedeuten weniger Komplexität
Eine direkte Verbindung zwischen Shopify und ERP klingt zunächst vernünftig. Es gibt Shopify, es gibt das ERP, und dazwischen eine Schnittstelle. Das wirkt schlank und effizient.
In der Praxis entsteht Komplexität aber nicht nur durch die Anzahl der Systeme, sondern vor allem durch Geschäftslogik, Datenqualität, Prozessausnahmen und spätere Änderungen. Ein Setup mit nur zwei Systemen kann sehr schwer zu warten sein, wenn diese beiden Systeme ständig Annahmen über das jeweils andere System treffen müssen.
Ein typisches Beispiel ist die Preislogik im B2B-Commerce. Auf dem Papier braucht Shopify einfach den richtigen Preis für den richtigen Kunden, in der Realität hängen Preise aber oft von Kundengruppen, Verträgen, Regionen, Mindestmengen, Rabatten, Währungen, Lieferbedingungen oder internen Freigaben ab. Manche Informationen kommen aus dem ERP, manche aus dem CRM, manche aus manuellen Prozessen und manche aus historischen Ausnahmen, die über Jahre gewachsen sind.
Wenn Shopify direkt mit dem ERP verbunden ist, muss diese Logik irgendwo leben. Entweder übernimmt Shopify mehr Verantwortung, als für die Plattform sinnvoll ist, oder das ERP muss Commerce-Anforderungen erfüllen, für die es nicht gebaut wurde. Eine dritte Möglichkeit ist, dass die Integration selbst mit jeder neuen Regel komplexer wird, bis sie irgendwann nicht mehr nur eine Schnittstelle ist, sondern ein verstecktes Geschäftslogik-System ohne klare Eigentümerschaft.
Genau an diesem Punkt wird die scheinbar einfache Architektur schwierig.
Shopify und ERP haben unterschiedliche Rollen
Shopify ist in einem modernen Commerce-Setup normalerweise die Plattform für Storefront, Warenkorb, Checkout, Bestellungen, Kundeninteraktion, Promotions, Märkte und operative Commerce-Funktionen. Das ERP ist dagegen oft das führende System für Finanzdaten, Warenwirtschaft, Auftragsverarbeitung, Bestände, Rechnungen, Einkauf, Logistik oder Stammdaten.
Beide Systeme sind wichtig, aber sie lösen unterschiedliche Probleme. Ein ERP ist nicht automatisch eine gute Commerce-API, und Shopify ist nicht automatisch der richtige Ort für jede interne Geschäftsregel.
Die Probleme beginnen meistens dort, wo ein System Aufgaben übernehmen soll, die eigentlich zwischen den Systemen liegen. Dazu gehören zum Beispiel die Übersetzung zwischen internen Datenmodellen und Shopify-Datenmodellen, die Zusammenführung von Daten aus ERP, PIM, CRM, OMS oder anderen Systemen, die Berechnung oder Aufbereitung von Preisen und Verfügbarkeiten, die Behandlung von Fehlern, Timeouts und inkonsistenten Daten, das Caching von Daten, die nicht bei jedem Seitenaufruf live abgefragt werden sollten, sowie Monitoring und Nachvollziehbarkeit von Datenflüssen.
Das sind keine Randthemen, denn in vielen Enterprise-Projekten entscheiden genau diese Punkte darüber, ob ein System nach dem Launch stabil betrieben werden kann.
Die Integration ist selten das eigentliche Problem
Wenn Unternehmen über ERP-Integrationen sprechen, geht es oft zuerst um technische Fragen. Gibt es eine API? Welche Endpunkte brauchen wir? Wie werden Bestellungen übertragen? Wie oft werden Bestände aktualisiert? Welche Datenformate gibt es?
Diese Fragen sind wichtig, aber sie sind selten der schwierigste Teil. Schwieriger ist meistens die fachliche Klärung: Welche Daten sind führend, welche Daten dürfen in Shopify geändert werden, und was passiert, wenn ein Produkt im PIM aktiv ist, aber im ERP keinen gültigen Bestand hat? Welche Preise gelten für eingeloggte B2B-Kunden, wie gehen wir mit Märkten um, in denen andere Sortimente, Währungen oder Steuersätze gelten, und was passiert, wenn das ERP für zehn Minuten nicht erreichbar ist?
Eine direkte Integration zwingt beide Systeme oft sehr stark in Echtzeitprozesse. Das kann bei bestimmten Vorgängen sinnvoll sein, etwa bei einer kritischen Verfügbarkeitsprüfung vor dem Checkout, für viele andere Datenflüsse ist es aber robuster, mit klaren Synchronisationsprozessen, Zwischenspeichern, Wiederholungslogik und Monitoring zu arbeiten.
Das bedeutet nicht, dass alles asynchron sein sollte. Es bedeutet nur, dass jedes Datenproblem einzeln betrachtet werden muss, weil manche Informationen live sein müssen, andere einige Minuten alt sein dürfen, manche in Shopify gespeichert werden sollten und andere nur referenziert werden sollten. Diese Unterscheidung ist wichtiger als die pauschale Frage, ob eine Integration direkt oder indirekt ist.
Warum Middleware oft sinnvoll ist
Eine Middleware ist kein Selbstzweck, denn eine zusätzliche Schicht macht ein System nicht automatisch besser. Im Gegenteil: Sie kann auch unnötige Komplexität erzeugen, wenn sie nur eingeführt wird, weil Architekturdiagramme dadurch moderner aussehen.
In vielen Enterprise-Shopify-Projekten ist Middleware jedoch der Ort, an dem die eigentliche Übersetzungsarbeit passieren kann. Sie verbindet nicht nur Systeme, sondern schützt sie auch voreinander.
Eine gute Middleware kann Daten aus dem ERP in ein Shopify-taugliches Format bringen, ohne dass das ERP Shopify kennen muss. Sie kann Bestellungen aus Shopify anreichern, bevor sie ins ERP übertragen werden, Fehler abfangen, Wiederholungen steuern, Datenflüsse protokollieren und klare Verantwortlichkeiten schaffen. Genauso kann sie verhindern, dass jede neue Commerce-Anforderung direkt zu einer Änderung am ERP oder an der Storefront führt.
Das ist besonders wichtig, wenn mehrere Systeme beteiligt sind. In einem Enterprise-Setup kommen neben Shopify und ERP oft PIM, CRM, OMS, WMS, Analytics, Consent Management, Marktplätze oder interne Tools hinzu. Ohne eine vermittelnde Schicht entsteht schnell eine Landschaft aus Punkt-zu-Punkt-Verbindungen, in der jede neue Anforderung an mehreren Stellen eingebaut werden muss und jede Änderung an einem System Auswirkungen auf mehrere andere Systeme haben kann.
Middleware reduziert diese Komplexität nicht dadurch, dass sie verschwindet. Sie macht sie sichtbarer und besser steuerbar.
Ein Beispiel aus der Praxis: PGM
Ein konkretes Beispiel dafür ist unsere Arbeit für PGM. Dort haben wir eine Middleware zwischen einer Headless-Shopify-Architektur und dem ERP aufgebaut, weil die Anforderungen nicht sauber durch eine direkte Verbindung zwischen Storefront, Shopify und ERP lösbar gewesen wären.
Die Middleware übernimmt in diesem Setup mehrere Aufgaben gleichzeitig. Sie cached relevante Daten, bereitet sie für die Headless-Storefront auf und bildet Geschäftslogik ab, die nicht sinnvoll direkt im Frontend, im ERP oder in Shopify selbst liegen sollte. Dazu gehört zum Beispiel die Zuweisung kundenspezifischer Rabatte auf Shopify-Kataloge.
Genau solche Fälle zeigen, warum Middleware in Enterprise-Shopify-Projekten oft mehr ist als eine technische Zwischenschicht. Sie wird zum Ort, an dem Systeme entkoppelt, Daten vorbereitet und unternehmensspezifische Regeln kontrolliert abgebildet werden können. Für das Projekt bedeutet das nicht nur mehr Flexibilität in der Umsetzung, sondern auch eine Architektur, die langfristig besser wartbar bleibt.
Wo Geschäftslogik leben sollte
Eine der wichtigsten Architekturfragen in Shopify-Plus-Projekten lautet: Wo lebt die Geschäftslogik?
Diese Frage wird oft zu spät gestellt. Erst wird implementiert, dann stellt man fest, dass Preisregeln in mehreren Systemen auftauchen, Produktlogik teilweise im Theme steckt, B2B-Ausnahmen im ERP gepflegt werden, Kundengruppen im CRM liegen und bestimmte Sonderfälle direkt in einer Integration hardcodiert wurden.
Am Anfang funktioniert das manchmal, später wird es teuer. Wenn Geschäftslogik an mehreren Orten verteilt ist, wird jede Änderung riskanter, weil niemand mehr genau weiß, welches System für welche Entscheidung verantwortlich ist. Teams müssen bei jeder Anpassung mehrere Abhängigkeiten prüfen, Fehler lassen sich schwerer nachvollziehen, und neue Märkte, neue Kundengruppen oder neue Vertriebskanäle erhöhen die Komplexität weiter.
Deshalb versuchen wir in Enterprise-Shopify-Projekten früh zu klären, welche Logik in Shopify gehört, welche im ERP bleiben sollte und welche bewusst in eine Middleware oder einen Custom-App-Layer ausgelagert werden muss.
Shopify sollte Commerce-Prozesse möglichst nativ abbilden, wo das sinnvoll ist. Das betrifft zum Beispiel Produkte, Varianten, Märkte, Warenkorb, Checkout, Kundenkonten, Bestellungen und viele B2B-Funktionen. Das ERP sollte weiterhin dort führend bleiben, wo es fachlich führend ist, dazwischen braucht es aber oft eine Schicht, die Regeln übersetzt, Daten vorbereitet und Prozesse entkoppelt.
Die wichtigste Frage ist deshalb nicht, ob man etwas direkt integrieren kann. Die bessere Frage ist, ob das Team diese Entscheidung in zwei oder drei Jahren noch verstehen, ändern und betreiben kann.
Ein Beispiel: Bestände und Verfügbarkeit
Bestände wirken auf den ersten Blick einfach. Ein Produkt ist verfügbar oder nicht, Shopify zeigt den Bestand an, Kunden kaufen, und das ERP verarbeitet die Bestellung.
In der Praxis ist Verfügbarkeit jedoch oft komplizierter als ein einzelner Zahlenwert. Ein Unternehmen kann mehrere Lager haben, Bestände können für bestimmte Kundengruppen reserviert sein, manche Produkte werden auf Anfrage verkauft, manche Artikel sind nur in bestimmten Märkten verfügbar, und manche Bestände dürfen im Shop sichtbar sein, während andere nur intern genutzt werden. Im B2B-Bereich kommen zusätzlich oft Mindestmengen, Lieferfenster oder kundenindividuelle Sortimente hinzu.
Eine direkte Live-Abfrage an das ERP bei jedem relevanten Storefront- oder Checkout-Schritt klingt hier zunächst präzise, kann aber Performance-Probleme, Ausfallszenarien und harte Abhängigkeiten schaffen. Wenn das ERP langsam ist, wird der Shop langsam. Wenn das ERP nicht erreichbar ist, wird aus einer internen Systemstörung schnell ein Commerce-Problem. Und wenn sich die Verfügbarkeitslogik ändert, muss die Integration angepasst werden.
Eine Middleware kann hier helfen, unterschiedliche Verfügbarkeitsinformationen vorzubereiten, zu cachen, zu aktualisieren und für Shopify in einer Form bereitzustellen, die zum Commerce-Prozess passt. Kritische Prüfungen können weiterhin live stattfinden, aber nicht jede Entscheidung muss direkt an das ERP gekoppelt sein.
Das Ziel ist dabei nicht, Daten künstlich zu duplizieren, sondern die richtige Verfügbarkeit am richtigen Punkt im Prozess zu haben.
Ein Beispiel: B2B-Preise
B2B-Preise sind ein ähnliches Thema. Viele Unternehmen starten mit der Annahme, dass Shopify einfach Preise aus dem ERP anzeigen muss, doch die Schwierigkeit liegt selten im Anzeigen eines Preises. Schwieriger ist die Kombination aus Kundenzuordnung, Preislisten, Vertragslogik, Mengenstaffeln, Rabatten, Märkten und Checkout-Verhalten.
Wenn die Preislogik sehr einfach ist, können native Shopify-B2B-Funktionen, Preislisten und Markets bereits viel abdecken. Wenn die Preislogik stark unternehmensspezifisch ist, muss jedoch genauer entschieden werden, welche Regeln in Shopify gepflegt werden können und welche Regeln aus bestehenden Systemen kommen müssen.
Eine direkte ERP-Abfrage für jeden Preis kann technisch möglich sein, ist aber nicht immer sinnvoll. Sie kann die Storefront-Performance belasten, die Komplexität des Cachings erhöhen und sehr enge Abhängigkeiten zwischen Commerce und ERP schaffen.
Middleware kann Preise vorberechnen, synchronisieren oder bei bestimmten kritischen Momenten validieren. Außerdem kann sie transparenter machen, warum ein Kunde welchen Preis sieht. Das ist im B2B-Commerce oft wichtiger als die reine technische Verbindung, denn Vertrieb, Support und E-Commerce-Team müssen Preisentscheidungen nachvollziehen können. Sonst wird jede Abweichung zum Support-Fall.
Bei PGM haben wir genau in diesem Umfeld gearbeitet: Die Middleware zwischen Headless Shopify und ERP cached Daten und bildet unter anderem die Logik ab, mit der kundenspezifische Rabatte passenden Shopify-Katalogen zugewiesen werden. Das ist ein gutes Beispiel dafür, warum B2B-Preislogik häufig nicht einfach nur aus dem ERP kommt, sondern in eine Architektur eingebettet werden muss, die Shopify, Storefront und interne Systeme sauber miteinander verbindet.
Wann direkte ERP-Integrationen trotzdem sinnvoll sein können
Es wäre falsch zu sagen, dass direkte ERP-Integrationen grundsätzlich schlecht sind. In manchen Fällen sind sie genau richtig.
Eine direkte Integration kann sinnvoll sein, wenn die Prozesse überschaubar sind, das ERP stabile und moderne APIs bereitstellt, nur wenige Datenflüsse benötigt werden und die fachliche Logik klar in einem System liegt. Auch bei kleineren Shopify-Setups oder klar begrenzten Workflows kann eine direkte Verbindung die einfachste und wirtschaftlichste Lösung sein.
Manchmal ist auch eine bestehende iPaaS-Lösung ausreichend. Wenn Standardprozesse wie Produktimport, Bestandssynchronisation oder Bestellübertragung gut abgedeckt sind, muss nicht sofort individuelle Middleware gebaut werden. Gute Architektur bedeutet nicht, möglichst viel selbst zu entwickeln, sondern bewusst zu entscheiden, wo Standardlösungen reichen und wo die eigenen Geschäftsprozesse eine individuellere Schicht brauchen.
Der Fehler liegt also nicht in der direkten Integration selbst, sondern darin, sie als Standardantwort für jedes Enterprise-Setup zu betrachten.
Der langfristige Blick ist entscheidend
Viele Architekturentscheidungen wirken am Anfang wie Projektentscheidungen, werden nach dem Launch aber zu Betriebsentscheidungen.
Wer überwacht die Schnittstelle? Wer wird alarmiert, wenn Bestellungen nicht übertragen werden? Wie werden fehlgeschlagene Jobs erneut ausgeführt? Wer erklärt dem Kundenservice, warum ein Preis nicht stimmt? Wie kann das E-Commerce-Team ein neues Sortiment ausrollen, ohne jedes Mal die IT zu blockieren? Und was passiert, wenn das ERP in zwei Jahren ersetzt oder erweitert wird?
Diese Fragen sind nicht weniger wichtig als die initiale Implementierung. In Enterprise-Commerce-Projekten ist der Launch nicht das Ende der Komplexität, denn oft beginnt die eigentliche Bewährungsprobe danach: mehr Märkte, mehr Kundengruppen, neue Anforderungen, neue Systeme und neue interne Zuständigkeiten.
Eine direkte Integration kann für den ersten Launch schneller wirken, während eine sauber geschnittene Integrationsarchitektur für die nächsten Jahre günstiger sein kann. Das ist der eigentliche Tradeoff.
Unsere Sicht auf Shopify-Plus-Integrationen
Bei Especial betrachten wir Shopify-Plus-Integrationen meistens aus drei Perspektiven: Risiko, Ownership und langfristige Veränderbarkeit.
Risiko bedeutet, dass wir früh fragen, was passiert, wenn ein System langsam ist, falsche Daten liefert oder vorübergehend ausfällt. Ownership bedeutet, dass klar sein muss, welches Team welchen Teil des Systems versteht und besitzt. Veränderbarkeit bedeutet, dass ein Unternehmen neue Märkte, neue Prozesse, neue Kundengruppen oder neue Systeme ergänzen können sollte, ohne die gesamte Architektur neu zu bauen.
Aus dieser Sicht ist Middleware oft keine zusätzliche Komplexität, sondern eine Möglichkeit, Komplexität an die richtige Stelle zu verschieben. Sie macht nicht jedes Projekt einfacher, kann aber verhindern, dass Shopify, ERP, Storefront und interne Prozesse zu eng miteinander verkoppelt werden.
Das ist besonders wichtig für Unternehmen, die Shopify Plus nicht nur als Shop-System nutzen, sondern als Teil einer größeren Commerce-Landschaft. In solchen Projekten geht es nicht nur um Frontend, Checkout oder Datenübertragung, sondern darum, eine Plattform zu bauen, die mit dem Unternehmen weiter wachsen kann.
Fazit
Die Frage ist nicht, ob Shopify direkt mit dem ERP verbunden werden kann. In vielen Fällen kann es das.
Die bessere Frage ist, ob eine direkte Verbindung auch in zwei oder drei Jahren noch die richtige Entscheidung ist.
In einfachen Setups ist sie manchmal pragmatisch, in komplexeren Enterprise-Shopify-Projekten wird sie jedoch schnell zur engen Kopplung zwischen Systemen, Teams und Prozessen. Dann ist Middleware nicht nur eine technische Schicht, sondern ein Architekturwerkzeug. Sie hilft dabei, Geschäftslogik sauberer zu platzieren, Systeme zu entkoppeln, Fehler besser zu behandeln und spätere Änderungen realistischer zu machen.
Die beste Architektur ist nicht die mit den wenigsten Boxen im Diagramm, sondern die Architektur, die ein Unternehmen langfristig verstehen, betreiben und verändern kann.
