ERP-Integration im B2B-Shop: Welche Daten in Echtzeit laufen sollten und wo asynchrone Synchronisation besser ist

Eine ERP-Integration im B2B-Shop ist für viele Hersteller, technische Händler und Mittelständler der Punkt, an dem aus einem digitalen Verkaufskanal ein belastbarer Vertriebsprozess werden soll. Genau hier entsteht aber oft ein Denkfehler: Alles müsse in Echtzeit laufen, sonst sei die Integration nicht professionell genug.

In der Praxis stimmt eher das Gegenteil. Nicht jede Information sollte live zwischen Shop, Kundenportal und ERP ausgetauscht werden. Manche Daten brauchen Echtzeit, andere funktionieren als eventbasierte oder regelmäßige Synchronisation robuster, günstiger und betrieblich sauberer. Entscheidend ist nicht maximale Live-Kommunikation, sondern die richtige fachliche Priorität pro Datenart.

1. Warum “alles in Echtzeit” in B2B-Projekten oft die falsche Zielsetzung ist

Viele ERP-nahe Shopprojekte starten mit einer technischen Wunschliste:

• Bestände live anzeigen
• Preise live berechnen
• Auftragsstatus live aktualisieren
• Belege sofort verfügbar machen
• Kundendaten in beide Richtungen synchron halten
• Außendienst, Innendienst und Kunde auf denselben Stand bringen

Das klingt nachvollziehbar. Problematisch wird es, wenn diese Liste ungefiltert in Architektur übersetzt wird.

Dann hängt plötzlich jede Produktseite, jeder Login und jeder Warenkorb an ERP-Antwortzeiten, Freigabelogik und Altsystem-Schnittstellen. Das Ergebnis ist oft kein moderner B2B-Shop, sondern ein fragiles Frontend mit vielen Timeout-Risiken.

Gerade im Mittelstand ist deshalb die wichtigere Frage: Welche Informationen müssen für den Nutzer in diesem Moment wirklich live sein und welche dürfen mit definierter Verzögerung synchronisiert werden, ohne fachlich falsch zu werden?

Shopify beschreibt B2B sehr klar mit custom catalogs, pricing und automatic inventory sync auf einer Plattform. Shopware betont bei seinen B2B Components die API-first Anbindung an ERP-Systeme und die Automatisierung von Geschäftsprozessen. Beide Richtungen zeigen dasselbe Muster: B2B-Fähigkeit entsteht nicht nur durch APIs, sondern durch eine saubere Aufteilung von Prozessverantwortung.

2. Die Grundregel: Nicht nach Systemen, sondern nach Entscheidungen denken

Viele Teams planen Integrationen aus der Sicht ihrer Systeme.

• Was kann das ERP?
• Was kann der Shop?
• Welche API ist vorhanden?

Für die Architektur ist eine andere Sicht hilfreicher: Welche geschäftliche Entscheidung wird mit dieser Information ausgelöst?

Denn genau daran hängt, ob Echtzeit nötig ist.

Daten mit unmittelbarer Kaufentscheidung

Diese Daten beeinflussen, ob der Nutzer überhaupt bestellen kann oder ob die Bestellung fachlich korrekt wäre.

Typische Beispiele:

• aktueller Preis
• Verfügbarkeit eines knappen Artikels
• Freigabestatus
• erlaubte Bestellmenge
• kundenspezifisches Sortiment

Hier ist Echtzeit oder eine sehr enge Ereignissynchronisation oft sinnvoll.

Daten mit Informations- oder Servicecharakter

Diese Daten sind wichtig, lösen aber nicht in jeder Sekunde eine neue Kaufentscheidung aus.

Typische Beispiele:

• ältere Belege
• Bestellhistorie
• Artikelstammdaten ohne häufige Änderungen
• Ansprechpartner
• Standarddokumente

Hier reicht oft eine asynchrone Synchronisation oder ein gecachter Datenstand.

Genau diese Unterscheidung fehlt in vielen Projekten. Dann wird technische Komplexität aufgebaut, obwohl fachlich nur ein kleiner Teil der Daten wirklich live sein muss.

3. Welche Daten im B2B-Shop typischerweise in Echtzeit sinnvoll sind

Nicht jeder B2B-Shop braucht dieselbe Tiefe. Für Industrie, technische Sortimente und bestandskritische Nachbestellung gibt es aber einige typische Kandidaten.

1. Verfügbarkeiten bei knappen oder dispositiven Artikeln

Wenn Kunden nach Lagerbestand, Lieferfähigkeit oder kurzfristiger Verfügbarkeit bestellen, kann ein alter Datenstand teuer werden.

Das gilt besonders bei:

• Ersatzteilen
• projektbezogenen Nachbestellungen
• kundenspezifisch reservierten Beständen
• Artikeln mit schwankender Verfügbarkeit
• Sortimenten mit enger Produktions- oder Beschaffungslage

Hier ist eine Live-Abfrage oder zumindest eine sehr eng getaktete Synchronisation oft sinnvoll. Wichtig ist aber die fachliche Form der Anzeige. Nicht jedes ERP kann oder sollte öffentlich den exakten Bestand ausspielen. Häufig ist es besser, belastbare Verfügbarkeitsstufen zu zeigen, zum Beispiel “sofort verfügbar”, “kurzfristig lieferbar” oder “auf Anfrage”.

2. Kundenspezifische Preise, wenn sie situativ berechnet werden

Wenn Preislogik im ERP oder einem angebundenen Pricing-System geführt wird und von Kunde, Standort, Staffel, Vertragslogik oder Währung abhängt, sollte der Shop beim Preis keine eigene Wahrheit erfinden.

Echtzeit ist besonders dann sinnvoll, wenn:

• Preise kurzfristig schwanken
• Konditionen vertragsbezogen gepflegt werden
• Zahlungsbedingungen Einfluss auf den Vorgang haben
• Freigaben oder Angebotslogik am Preis hängen
• mehrere Rollen für denselben Kunden unterschiedliche Berechtigungen haben

Wenn Preise dagegen stabil sind und zum Beispiel täglich oder stündlich aktualisiert werden, reicht oft eine asynchrone Übergabe. Für die Plattformseite beschreibt Shopify kundenspezifische Kataloge und Pricing als B2B-Kernfunktion. In der Praxis bleibt trotzdem die Frage offen, wo diese Daten fachlich führend sind.

3. Freigabestatus, Sperren und kaufrelevante Berechtigungen

Wenn ein Kunde bestellen will, darf der Shop bei kaufrelevanten Regeln nicht auf einem veralteten Stand sein.

Dazu gehören häufig:

• gesperrte Kundenkonten
• deaktivierte Standorte
• Rollen und Rechte
• Bestelllimits
• Zahlungsbedingungen, die einen Checkout verhindern
• Freigabepflicht für bestimmte Nutzer oder Warenkörbe

Adobe Commerce arbeitet bei B2B mit Company Accounts. Die Doku zeigt auch, dass Nutzer in blockierten Unternehmen zwar auf den Katalog zugreifen können, aber nicht einkaufen dürfen. Genau solche Zustände müssen im Bestellmoment verlässlich aktuell sein.

4. Auftragsauslösung und Rückmeldung an das ERP

Der Übergang von Bestellung zu Auftrag ist einer der kritischsten Momente der ERP-Integration.

Wichtig ist hier nicht nur die Übertragung, sondern auch die verlässliche Rückmeldung:

• Bestellung angenommen
• Auftrag angelegt
• Fehler bei der Übergabe
• Prüfung erforderlich
• Referenznummer erzeugt

Dieser Schritt sollte eventbasiert und transaktionssicher gedacht werden. Ob die Antwort technisch synchron oder asynchron erfolgt, ist zweitrangig. Entscheidend ist, dass keine Bestellung still verloren geht.

4. Welche Daten besser asynchron oder gecacht laufen

Der Reflex “live ist besser” führt besonders hier oft zu unnötiger Last.

1. Produktstammdaten und technische Merkmale

Bei vielen B2B-Sortimenten kommen Produkttexte, Attribute, Medien, Zeichnungen, Datenblätter und Klassifizierungen aus ERP, PIM oder ergänzenden Systemen. Diese Daten ändern sich meist nicht im Sekundentakt.

Deshalb ist eine asynchrone Synchronisation oft die bessere Wahl.

Vorteile:

• stabilere Shop-Performance
• bessere Such- und Filterindizierung
• kontrollierbare Datenqualität
• weniger Abhängigkeit von ERP-Antwortzeiten
• sauberere QA vor Veröffentlichung

Wenn genau diese Produktdaten im Projekt bereits der Engpass sind, passt dazu auch unser Beitrag PIM im E-Commerce: Wann Produktdaten nicht mehr ins Shopsystem gehören.

2. Bestellhistorie und Belege

Für Bestandskunden sind Bestellhistorie, Rechnungen und Lieferscheine extrem wertvoll. Sie müssen aber nicht für jede Seitenansicht live aus dem ERP gezogen werden.

Besser sind oft:

• nächtliche oder mehrmals tägliche Synchronisation historischer Daten
• eventbasierte Aktualisierung bei neuen Belegen
• gezieltes Nachladen nur bei Detailaufruf
• lokale Speicherung von Metadaten plus Dokumentabruf bei Bedarf

So bleibt das Portal schnell, ohne den Servicewert zu verlieren. Genau dieser Self-Service-Gedanke spielt auch in unserem Beitrag B2B-Kundenportal für Bestandskunden eine zentrale Rolle.

3. Kundenstammdaten ohne unmittelbare Bestellwirkung

Nicht jede Änderung an Telefonnummern, Ansprechpartnern oder internen Zuordnungen muss sofort jeden Shop-Request beeinflussen.

Hier funktionieren oft robuste Muster besser:

• führender Datensatz im ERP oder CRM
• eventbasierte Synchronisation bei Änderungen
• definierte Felder für den Shop
• klare Trennung zwischen vertrieblichen und kaufrelevanten Daten

4. Reorder-Logik, Listen und häufig bestellte Artikel

Adobe beschreibt Requisition Lists als Möglichkeit, häufig bestellte Produkte direkt aus einer Liste in den Warenkorb zu übernehmen. Solche Funktionen sind für B2B extrem wertvoll.

Die Liste selbst muss dafür nicht permanent live aus dem ERP aufgebaut werden. Häufig reicht es, die Listenstruktur im Shop oder Portal zu halten und erst bei Preis- oder Verfügbarkeitsprüfung wieder gegen führende Systeme zu validieren.

5. Ein praxistaugliches Modell für ERP-Integration im B2B-Shop

Für viele Mittelstandsprojekte ist dieses Vier-Zonen-Modell deutlich hilfreicher als die pauschale Forderung nach Echtzeit.

Zone A: Immer live oder ereignisnah

Diese Daten beeinflussen unmittelbar, ob ein Vorgang zulässig und korrekt ist.

Typisch:

• kaufrelevante Preise
• Verfügbarkeitsstatus knapper Artikel
• Sperren und Freigaben
• Abschluss einer Bestellung

Zone B: Regelmäßig synchronisiert

Diese Daten ändern sich, aber nicht in jeder Session.

Typisch:

• Produktstammdaten
• Standardpreise ohne tagesaktuelle Schwankung
• Sortimentzuordnungen
• Kundenstammdaten ohne direkte Checkout-Wirkung

Zone C: Eventbasiert aktualisiert

Hier ist eine Änderung wichtig, aber sie muss nur beim Ereignis weitergereicht werden.

Typisch:

• neuer Beleg verfügbar
• Auftrag freigegeben
• Status geändert
• Kunde gesperrt oder entsperrt
• neuer Ansprechpartner angelegt

Zone D: Nur bei Bedarf nachgeladen

Diese Daten sind relevant, aber nicht für jede Seitenansicht.

Typisch:

• PDF-Belege
• tiefe Auftragsdetails
• lang zurückliegende Bestellungen
• umfangreiche Dokumente

Dieses Modell hält das Frontend schneller und die Integration kontrollierbarer.

6. Wo ERP-Integrationen im B2B-Alltag am häufigsten scheitern

Die größten Probleme liegen selten in fehlenden APIs. Odoo dokumentiert seine externe JSON-2 API sehr offen. Shopware betont API-first für ERP-Anbindungen. Das zeigt: Die technische Anschlussfähigkeit ist heute oft vorhanden.

Die eigentlichen Probleme sind meist fachlich.

1. Das ERP wird wie ein Website-Backend missverstanden

Ein ERP ist nicht automatisch dafür gebaut, jede Shop-Seite in Millisekunden zu bedienen. Wenn Produktlisten, Suche, Navigation und Nutzeroberfläche ständig live ans ERP delegiert werden, leidet meist zuerst die Nutzererfahrung.

2. Es gibt keine klare Systemführerschaft

Wenn der Shop Preise anders kennt als das ERP, das CRM andere Kundenstrukturen pflegt und der Außendienst mit Excel-Sonderlisten arbeitet, hilft auch die beste API nicht.

3. Fehlerwege sind nicht geplant

Was passiert, wenn das ERP gerade nicht antwortet?

• darf bestellt werden?
• wird ein Preis gecacht verwendet?
• gibt es eine Warteschlange?
• wird ein Auftrag später erneut zugestellt?
• wer sieht den Fehler?

Wenn diese Fragen offen bleiben, entsteht kein belastbarer Prozess.

4. Fachbereiche erwarten denselben Live-Grad für alles

Vertrieb will aktuelle Preise, Service will Belege, Einkauf will Verfügbarkeit, IT will Stabilität. Ohne Priorisierung wird daraus schnell ein Integrationsmonster.

7. Welche Architektur für Industrie und Mittelstand oft besser funktioniert

Ein pragmatischer B2B-Shop mit ERP-Integration trennt Nutzererlebnis und Systemführerschaft sauber.

Der Shop oder das Kundenportal verantwortet typischerweise

• schnelle Suche, Navigation und Produktdarstellung
• Firmenkonten, Rollen und Nutzerführung
• Bestelllisten, Reorder, Schnellbestellung
• Statusdarstellung auf Basis definierter Datenfeeds
• klare Fehler- und Fallback-Kommunikation

Das ERP verantwortet typischerweise

• führende Auftragsdaten
• kaufrelevante Verfügbarkeitslogik
• Debitoren- und Konditionslogik
• Belegentstehung
• operative Abwicklung

Dazwischen braucht es oft eine Integrationsschicht

Gerade bei mehreren Systemen ist eine Zwischenlogik oft sinnvoll, damit nicht das Frontend jedes ERP-Detail direkt verstehen muss. Wenn genau diese Ebene relevant wird, lohnt sich auch unser Beitrag API-first statt Plugin-Chaos und für komplexere Frontend-Orchestrierung zusätzlich Backend for Frontend für Unternehmenswebsite und Shop.

8. Ein realistischer Fragenkatalog vor der Umsetzung

Bevor Sie ERP und Shop enger koppeln, helfen meist diese acht Fragen mehr als jede Demo:

1. Welche Daten beeinflussen unmittelbar die Kaufentscheidung und brauchen deshalb Echtzeit?
2. Welche Daten dürfen fachlich korrekt um 15 Minuten, eine Stunde oder einen Tag verzögert sein?
3. Wo sind Preise, Verfügbarkeit und Kundenberechtigungen wirklich führend?
4. Welche Informationen braucht der Kunde ständig und welche nur im Detailfall?
5. Was passiert, wenn das ERP gerade nicht erreichbar ist?
6. Welche Daten können eventbasiert statt permanent live übertragen werden?
7. Welche manuellen Rückfragen im Innen- und Außendienst sollen durch das Portal konkret entfallen?
8. Wie werden Fehler sichtbar, nachverfolgt und erneut verarbeitet?

Gerade wenn Außendienst, Innendienst und Kunde auf denselben Prozess zugreifen sollen, ergänzt auch unser Beitrag B2B-Shop mit Außendienst und Innendienst diese Perspektive.

Fazit

Eine ERP-Integration im B2B-Shop wird dann stark, wenn sie nicht maximal live, sondern fachlich sauber priorisiert ist. Preise, kaufrelevante Verfügbarkeiten, Sperren und die Auftragsauslösung brauchen oft Echtzeit oder sehr enge Ereignislogik. Produktstammdaten, Belege, Historien und viele Serviceinformationen laufen dagegen häufig robuster über Synchronisation, Caching und gezieltes Nachladen.

Für Industrieunternehmen, technische Hersteller und mittelständische Vertriebsorganisationen liegt der Hebel deshalb nicht in möglichst vielen Live-Requests, sondern in weniger Medienbrüchen, klaren Zuständigkeiten und einer Architektur, die im Alltag stabil bleibt.

Wenn Sie gerade prüfen, wie Shop, Kundenportal und ERP sinnvoll zusammenspielen sollen, ist meist zuerst unsere Seite Webseiten & Shops sinnvoll. Wenn bereits konkrete Anforderungen aus Vertrieb, E-Commerce oder IT auf dem Tisch liegen, ist oft auch direkt unser Kontaktformular der beste nächste Schritt.

Quellen

• Shopify: B2B Commerce Platform
• Shopware: B2B Components
• Adobe Commerce Docs: Manage company accounts
• Adobe Commerce Docs: Requisition lists
• Odoo Documentation: External JSON-2 API