Warum Sie komplexe ERP-Abläufe nicht im Shop nachbauen sollten
Es ist Montagmorgen, 9:15 Uhr. Ihr B2B-Shop-Projekt läuft seit vier Monaten. Die Agentur präsentiert stolz: “Wir haben jetzt auch die kundenspezifischen Preisregeln im Shop implementiert. Und nächste Woche bauen wir den Genehmigungsworkflow nach." Sie nicken zustimmend. Schließlich funktioniert das alles bereits im ERP – warum sollte es im Shop anders sein?
Zwölf Monate später sitzen Sie im Krisenmeeting. Der Shop zeigt andere Preise als das ERP. Genehmigungen laufen doppelt. Jedes ERP-Update bricht Shop-Funktionen. Die Wartungskosten haben sich verdreifacht. Und Ihr Budget für "strategische Projekte" fließt jetzt in "Synchronisations-Hotfixes".
Dieser Artikel zeigt Ihnen, warum die scheinbar pragmatische Entscheidung, die ERP-Logik im Onlineshop nachzubauen, regelmäßig in technische Schulden mündet – und wie die richtige B2B-Shop-Architektur aussieht.
ERP-Logik im Shop bezeichnet die Praxis, komplexe Geschäftsprozesse und Regelwerke, die im ERP-System verwaltet werden, im B2B-Shop zu replizieren. Dazu gehören Preisberechnungen, Genehmigungsworkflows, Budgetprüfungen, Verfügbarkeitslogik und kundenspezifische Geschäftsregeln. Das Ergebnis: Zwei Systeme verwalten dieselben Daten und Prozesse, was zu Inkonsistenzen, erhöhtem Wartungsaufwand und deutlich höheren Total Cost of Ownership führt.
Warum viele B2B-Unternehmen die ERP-Logik im Shop nachbauen – und warum das ein Fehler ist
Die Versuchung ist groß und die Argumente klingen überzeugend:
"Unser Shop-System soll unabhängig vom ERP funktionieren."
"Die API-Calls zum ERP wären zu langsam."
"Wir wollen schnelle Entwicklungszyklen ohne ERP-Abhängigkeiten."
In der Praxis sieht das typische Szenario so aus:
Ein mittelständischer Hersteller führt einen B2B-Shop ein. Die Shop-Plattform bietet umfangreiche Business-Rule-Engines (bspw. den Flow Builder von Shopware).
Der Implementierungspartner schlägt vor: "Wir können Ihre Preislogik auch im Shop abbilden – dann müssen wir nicht bei jeder Preisabfrage ans ERP." Das klingt pragmatisch, performant und nach weniger Komplexität.
In der Praxis ist jedoch häufig das Gegenteil der Fall: Sie schaffen nicht weniger Komplexität. Sie verdoppeln sie.
Die trügerische Logik der "Shop-Autonomie"
Das Grundproblem liegt in einem fundamentalen Missverständnis darüber, was ein B2B-Shop ist und was er sein sollte. Ein B2B-Shop ist kein eigenständiges Business-System. Er ist überwiegend ein Frontend-Layer – eine Benutzeroberfläche für Geschäftsprozesse, deren Wahrheit im ERP liegt.
Wenn Sie Geschäftslogik im Shop nachbauen, kreieren Sie zwei konkurrierende Wahrheiten:
Das ERP sagt: "Kunde A hat ein Budget von 50.000€, bereits 35.000€ verbraucht"
Der Shop sagt: "Kunde A hat ein Budget von 50.000€, bereits 38.000€ verbraucht"
Welches System hat recht? Beide basieren auf derselben ursprünglichen Regel, aber jedes System hat eigene Transaktionen verarbeitet, eigene Rundungen vorgenommen, eigene Zeitstempel gesetzt.
Drei typische ERP-Abläufe, die im B2B-Shop nachgebaut werden
Schauen wir uns konkret an, welche Geschäftslogik typischerweise dupliziert wird – und warum das jeweils problematisch ist.
1. Kundenspezifische Preislogik und Konditionen
Der B2B-Onlineshop muss in der Lage sein, die folgenden typischen preisbestimmenden Faktoren für Produkte korrekt zu berücksichtigen und darzustellen:
Kundenindividuelle Vertragspreise mit Gültigkeitszeiträumen
Staffelpreise basierend auf Abnahmemenge
Kundenindividuelle Rabatte und Sonderkonditionen
Komplexe Frachtkosten z.B. Paket- und Speditionsversand
Mindestbestellmengen und Verpackungseinheiten
Die Preislogik ist jedoch selten statisch. Dies führt zu Millionen möglicher Preiskombinationen, beeinflusst durch:
Rohstoffpreis-Indexierungen (monatlich oder quartalsweise)
Vertragsverhandlungen und Sonderfreigaben
Saisonale Aktionen und Kampagnen
Währungsschwankungen bei internationalen Kunden
2. Verfügbarkeits- und Bestandsprüfungen
Bestandsdaten sind die volatilsten Daten in vielen Unternehmen. Sie ändern sich bei jedem Wareneingang, jedem Versand, jeder Produktion, jeder Reservierung. Selbst bei stündlicher Synchronisation vom ERP zum Shop können die Shop-Daten zum Zeitpunkt der Anzeige bereits veraltet sein.
Folgende Prozesse sind somit im Shop zu berücksichtigen:
Lagerbestände und reservierte Mengen
Lieferzeitberechnungen basierend auf Lagerort
ATP (Available-to-Promise) Logik
Mindestbestellmengen und MOQs
Alternative Artikel bei Nichtverfügbarkeit
3. Kundenspezifische Kataloge und Sortimente
B2B-Kund:innen haben oft Vereinbarungen, welche Artikel sie beziehen dürfen oder sollen. Diese Vereinbarungen sind Vertragsbestandteile, die im ERP dokumentiert und verwaltet werden.
Hinzu kommt, dass bei geringem Digitalisierungsgrad des Vertriebs solche Informationen manuell, z.B. in Excel vorgehalten werden.
Folgende Bausteine spielen hier eine Rolle:
Individuelle Artikelfreigaben pro Kunde
Kundenspezifische Artikelnummern (Customer Part Numbers)
Bevorzugte Lieferanten und Marken
Ausgeschlossene Produktgruppen
Ersatzartikel-Mappings
Warum es in der Praxis scheitert:
Besonders problematisch: Neue Artikel werden im ERP angelegt und für bestimmte Kund:innen freigegeben. Wenn der Shop eine eigene Freigabelogik hat, müssen neue Artikel dort manuell nachgepflegt werden. In der Praxis: Das passiert verspätet oder gar nicht.
Die richtige B2B-Shop-Architektur: Onlineshop als Frontend, ERP als Single Source of Truth
Wie sieht die Alternative aus? Folgen Sie grundsätzlich dem Prinzip:
Der Shop ist das Frontend, das ERP ist die Single Source of Truth für alle Geschäftslogik.
Hierbei ist es wichtig zu betonen, dass eine harte Abgrenzung beider Systeme in der Praxis nicht existiert. Es kommt wie immer auf den Einzelfall an.
Zur Orientierung bietet sich das folgende Modell der Verantwortlichkeiten an:
Das Verantwortlichkeits-Modell
Was gehört in den Shop:
Produktpräsentation und Content Management
Suchfunktionalität und Navigation
Warenkorb und Bezahlprozess
Kundenkonto
Standard (Listen-) preise
User Experience und Customer Journey
Marketing-Funktionen (Banner, Kampagnen, Empfehlungen)
Was MUSS im ERP bleiben:
Kundenindividuelle Preisberechnung und Konditionen
Genehmigungsworkflows und Budgets
Bestandsdaten und Verfügbarkeiten
Kundenstammdaten und Berechtigungen
Auftragserstellung und -verarbeitung
Rechnungsstellung und Payment
Die goldene Regel: Wenn etwas im ERP eine Transaktion erzeugt, Stammdaten ändert oder Geschäftslogik ausführt – gehört es ins ERP, nicht in den Shop.
Wie funktioniert das in der Praxis?
In der Praxis wird diese Trennung sinnvollerweise abgestuft umgesetzt. Bestimmte Preistypen werden durch eine Schnittstelle vom ERP an den Shop übermittelt, also gespiegelt.
Hierfür sprechen einige Gründe:
Ein offen zugänglicher Shop, der auch als Marketing-Instrument genutzt wird, funktioniert besser, wenn zumindest Listenpreise zur Orientierung dargestellt werden.
Auch benötigt es bspw. für die Teilnahme an der Google Produktsuche (Google Merchant Center) einen Preis, der dorthin übergeben und auf der Website dargestellt wird.
Für viele Warengruppen und Zielgruppen lässt sich durchaus ein fester Preispunkt ermitteln. Somit ließe sich eine hybride Preisfindung im Shop etablieren. Für Standardprodukte gelten einfache Preise, die mit dem ERP synchron gehalten werden. Für komplexe Produkte wie konfigurierbare Produkte (CPQ) wird der Preis zur Laufzeit aus dem ERP ermittelt.
Das ERP bleibt das führende System und spielt (vorberechnete) Preise an den Shop. Je nach Geschäftsmodell ist hier typischerweise ein nächtlicher Prozess ausreichend und wird idealerweise als Delta-Datenabgleich durchgeführt.
Diese Vorberechnung ist in den meisten Fällen möglich für die Preistypen: UVP, Standard Listenpreis und oftmals auch Preise auf Ebene der Kundengruppen.
Bei kundenindividuellen Preisen kommt es auf den Einzelfall an – hier können schnell einige Millionen Preispunkte entstehen. Dies lässt sich erfahrungsgemäß dann abbilden, wenn die Komplexität sich auf produktbezogene Mengenstaffeln ohne weitere Einflüsse beschränkt.
Das Shopsystem bietet hier die Möglichkeit, Preispunkte auf Ebene des Kundenkontos (Accounts) zu hinterlegen.
Kompliziert wird es immer dann, wenn Preise sich insgesamt auf Warenkorb-Ebene aus diversen Faktoren ergeben:
Konditionstechnik mit Zugriffsfolgen und Konditionstabellen
Formelbasierte Berechnungen in Konditionsarten
Prozentuale Faktoren auf Basiswerte
Frachtzuschläge gewichts- oder entfernungsabhängig
Staffelkonditionen nach Menge oder Wert
Kopplungen zwischen Konditionsarten (z.B. Rabatt vom Rabatt)
Solche dynamischen Berechnungen sollten Sie unter keinen Umständen im Shop nachbauen und stattdessen auf eine Echtzeitabfrage aus dem ERP setzen.
Dies kann sinnvoll an zwei Stellen im Shop umgesetzt werden und muss durch ein verständliches User-Interface möglichst komfortabel für Ihre Nutzer:innen umgesetzt werden: Produktseite und Warenkorb.
Nutzer:in öffnet Produktseite oder Warenkorb.
Shop fragt das ERP in Echtzeit an: "Was kostet Artikel X für Kunde Y?" – auf der Produktseite für den kundenspezifischen Artikelpreis, im Warenkorb für die vollständige Kalkulation inklusive Mengen- und frachtrelevanter Faktoren.
ERP berechnet den Preis nach aktuellen Regeln – im Warenkorb inklusive aller Zu-/Abschläge und frachtrelevanten Parameter.
Shop zeigt Preis bzw. die Gesamtkalkulation inklusive der Frachtkosten und etwaigen Zu- und Abschläge an.
Diese Preisanfrage verbinden Sie idealerweise direkt mit einer vollständigen Darstellung des Lieferzeitpunkts.
Ihre Integrationsarchitektur sollte sein:
Die Middleware ist der Schlüssel: Sie übersetzt zwischen Shop-APIs und ERP-APIs, handhabt Fehler intelligent und kann selektiv cachen – aber sie repliziert keine Business-Logik.
Shop vs. ERP Verantwortlichkeiten
| Funktion | Im Shop | “Live” aus dem ERP | Begründung |
| Produktdaten |
Ja | Nein | |
| Produktdarstellung |
Ja | Nein | UI/UX ist Shop-Domäne |
| Preisberechnung |
Nein | Ja |
Je nach Preismodell kann es hier sinnvoll sein, mehrschichtig vorzugehen. Die Faustregel ist: Einfache Preise kommen aus dem ERP, können jedoch synchronisiert werden. Komplexe Preisberechnungen dürfen nicht im Shop nachgebaut werden, sondern müssen live durch das ERP berechnet werden. |
| Suchfunktion |
Ja | Nein | Performance, UX-Feature |
| Bestandsabfrage |
Nein | Ja | Volatile Daten, transaktionsrelevant |
| Warenkorb-UI |
Ja | Nein | Temporäre Session-Daten |
| Auftragserstellung |
Nein | Ja | Geschäftsvorfall, rechtlich relevant |
| Genehmigungsworkflow | Nein | Ja | Business Rules, Compliance |
| Produktempfehlungen | Ja | Nein | ML/AI, kein Transaktionsbezug |
| Kundenstammdaten | Nein | Ja | Master Data, DSGVO-relevant – Graubereich – Shops benötigen aus technischen Gründen einen Sync. Dennoch sollte auch hier möglichst ein Echtzeit-Layer via ERP-Abfrage vorliegen. |
| Zahlungsabwicklung | Teils | Ja | Shop: Gateway, ERP: Verbuchen Wird bei Online Payments i.V.m. überschaubaren Transaktionszahlen in der Praxis oft pragmatischer gelöst – Bestellungen gehen mit erfolgreicher Bezahlung an das ERP. |
| Artikel-Filter | Ja | Nein | UX-Feature, Performance |
| Budget-Checks | Nein | Ja |
Business Rule, Compliance |
Die Gegenargumente adressieren: "Ja, aber..."
Wer über saubere Systemarchitektur mittel ERP-API spricht, hört schnell ein „Ja, aber…“. Genau diesen Einwänden widmen wir uns jetzt – und zeigen, weshalb sie in der Praxis selten standhalten.
Einwand 1: "Unser ERP ist alt und hat keine modernen APIs."
Das ist ein ERP-Problem, kein Shop-Problem. Und es wird nicht besser, wenn Sie die Logik duplizieren – im Gegenteil, es wird schlimmer.
Folgende Optionen bieten sich:
Middleware-Layer: Bauen Sie eine API-Schicht vor das ERP.
Modernisierung priorisieren: Wenn Ihr ERP keine APIs kann, ist das ein strategisches Problem, das gelöst werden muss.
Hybrid-Ansatz: Kritische Transaktionsdaten via API, unkritische Katalogdaten via Batch-Sync.
Einwand 2: "Die ERP-API ist zu langsam für Real-Time-Abfragen."
Dann ist die ERP-API schlecht gemacht und muss optimiert werden.
Typische Ursachen:
Synchrone DB-Calls pro Request: Lösbar durch Batch-Endpoints
Keine Indizierung: Lösbar durch DB-Optimierung
Übertragung unnötiger Daten: Lösbar durch gezieltes API-Design
Eine gut gemachte ERP-API sollte Preis- und Verfügbarkeitsabfragen in unter 300 ms liefern. Wenn das nicht der Fall ist, investieren Sie in API-Performance, nicht in Duplikation.
Temporäres Caching (5-15 Minuten) ist akzeptabel. Duplikation ist es nicht.
Einwand 3: "Das ERP-System wechselt bald – dann wollen wir den Shop nicht anfassen müssen."
Dieser Einwand klingt logisch, ist aber kontraproduktiv.
Wenn Sie die ERP-Logik im Shop nachbauen, müssen Sie den Shop genauso stark anpassen wie bei sauberer API-Integration – nur dass Sie jetzt auch noch die Geschäftslogik migrieren müssen, nicht nur die Schnittstelle.
Bei API-Integration: Ändern Sie die Integration-Layer (Middleware), der Shop bleibt unberührt. Bei duplizierter Logik: Ändern Sie Integration UND Geschäftslogik im Shop.
Das Argument kehrt sich um: API-Integration macht ERP-Wechsel einfacher, nicht schwerer.
Häufig gestellte Fragen
ERP-Logik im Shop zu replizieren führt zu systematischer Daten-Duplikation, erhöhtem Wartungsaufwand und Inkonsistenzen zwischen Systemen. Der Shop sollte als Frontend-Layer fungieren, während das ERP die Single Source of Truth für alle Geschäftslogik bleibt. Duplikation verursacht erhebliche Mehrkosten.
In den Shop gehören UI/UX-Funktionen: Produktpräsentation, Suche, Warenkorb-Management, Marketing-Features. Im ERP müssen alle Transaktions- und Geschäftsdaten bleiben: Preisberechnung, Genehmigungsworkflows, Bestandsdaten, Kundenstammdaten, Auftragserstellung. Die Faustregel: Wenn es Auswirkungen auf Rechnung, Lieferung oder Compliance hat, gehört es ins ERP.
Nutzen Sie eine API-First-Architektur: Der Shop fragt Geschäftsdaten in Echtzeit über APIs beim ERP ab, statt sie lokal zu speichern und zu berechnen. Eine Middleware-Schicht zwischen Shop und ERP handhabt Transformation, Error Handling und selektives Caching. Kritische Daten wie Preise werden direkt vom ERP abgefragt, nur unkritische Katalogdaten können gecacht werden.
Moderne ERP-APIs liefern Preis- und Verfügbarkeitsabfragen in 18 bis 450 ms – das liegt im für Nutzer:innen akzeptablen Bereich unter 1 Sekunde. Für Performance-kritische Bereiche können Sie intelligentes Caching mit kurzen TTLs (5 – 15 Minuten) einsetzen und den Cache bei ERP-Änderungen aktiv invalidieren. Die Alternative – veraltete Daten durch Duplikation – ist schlimmer als eine minimal höhere Latenz. Weiterhin kann die ERP-Abfrage auf Bereiche wie die Warenkorb-Anzeige und den Checkout begrenzt werden. Auch asynchrone Anfragen an das ERP oder erst durch eine spezifische Nutzeraktion (Button “jetzt Lieferbarkeit anzeigen") können Abhilfe schaffen und sind im B2B-Kontext durchaus (noch) akzeptiert.
Die vier häufigsten Bereiche sind: 1. Kundenspezifische Preislogik und Rabatte, 2. Genehmigungsworkflows und Budget-Controls, 3. Verfügbarkeits- und Bestandsprüfungen, 4. Kundenspezifische Kataloge und Sortimente. Alle diese Bereiche sind hochdynamisch und ändern sich regelmäßig im ERP, was bei Duplikation zu ständigen Synchronisationsproblemen führt.
Initial erscheint es einfacher, Logik im Shop zu bauen, weil man keine ERP-APIs anfassen muss. Langfristig kehrt sich das um: API-Integration erfordert einmalig Investition in Schnittstellen, danach läuft es wartungsarm. Duplizierte Logik verursacht kontinuierliche Kosten durch Synchronisation, Inkonsistenz-Handling und doppelte Pflege bei jeder Änderung.
Drei Optionen: 1. Bauen Sie einen Middleware-Layer vor das ERP, der moderne REST/GraphQL-APIs bereitstellt, 2. Priorisieren Sie ERP-Modernisierung – fehlende APIs sind ein strategisches Problem, 3. Nutzen Sie einen Hybrid-Ansatz mit kritischen Daten via API und unkritischen Daten via Batch-Sync. Was Sie nicht tun sollten: Das API-Problem durch Duplikation im Shop "lösen".
Sicher cachbar: 1. Produktbeschreibungen, Bilder, technische Daten (TTL: 24 Stunden), 2. Kategorie-Strukturen und Navigation (TTL: 12 Stunden), 3. Marketing-Content und Banner (TTL: 1 Stunde).
Kritisch cachbar: Preise (TTL: 5-15 Minuten mit aktiver Invalidierung bei Änderung).
Niemals cachen: Bestandsdaten (zu volatil), Genehmigungsstatus (Compliance-Risiko), Budgets (Inkonsistenz-Risiko).
Fazit: Architektur-Entscheidungen haben langfristige Konsequenzen
Die Entscheidung, ERP-Logik im Shop nachzubauen, erscheint in Projektmeetings oft pragmatisch: "Wir können das Feature schneller liefern." "Wir sind unabhängiger vom ERP-Team." "Die Performance wird besser."
Alle diese Argumente stimmen – kurzfristig. Langfristig haben Sie ein System, das schwieriger zu warten, teurer zu betreiben und riskanter zu ändern ist.
Die Frage ist nicht: "Können wir das im Shop bauen?" Die richtige Frage ist: "Sollten wir das im Shop bauen?"
Und die Antwort lautet in vielen Fällen: Nein.
Der Shop ist Ihr digitales Schaufenster, Ihre User Experience, Ihr Marketing-Kanal. Lassen Sie ihn das sein. Und lassen Sie Ihr ERP das sein, wofür es gebaut wurde: Die verlässliche, konsistente, geprüfte Quelle für Geschäftsprozesse und Transaktionsdaten.
Drei konkrete nächste Schritte:
Audit durchführen: Dokumentieren Sie in den nächsten 2 Wochen, welche Geschäftslogik aktuell in Ihrem Shop existiert. Wo gibt es Duplikation zum ERP?
Quick Win identifizieren: Welches duplizierte Element verursacht aktuell die meisten Probleme UND wäre am einfachsten zu migrieren? Starten Sie dort.
API-Strategie definieren: Setzen Sie sich mit Ihrem ERP-Team zusammen und definieren Sie, welche APIs das ERP bereitstellen sollte. Priorisieren Sie nach Geschäftswert, nicht nach technischer Einfachheit.
Die richtige Shop-Architektur zahlt sich nicht sofort aus – aber sie zahlt sich jeden Tag aus, über Jahre hinweg. Das ist der Unterschied zwischen technischen Schulden und technischen Assets.
Ihr starker Partner für E-Commerce
Profitieren Sie von unserer Expertise für Ihr Projekt durch einen ganzheitlichen Blick, ein erfahrenes Team von IT-Consultants und Lösungen für Ihre individuellen Anforderungen.
