B2B-E-Commerce-Architektur: vom Kundenvertrag bis zur Buchung

1. Ein führendes System je Datendomäne

Die Frage, welches System insgesamt führend ist, bringt wenig. Entscheidend ist, dass jede Datendomäne genau eine fachliche Autorität hat. Organisation, Produkt, Preis, Bestand, Kredit, Bestellung, Lieferung und Rechnung können dabei durchaus in verschiedenen Systemen liegen.

Dokumentieren Sie neben der Quelle auch, über welche Wege geschrieben werden darf, wie oft aktualisiert wird und wie Konflikte aufgelöst werden. Eine replizierte Commerce-Datenbank ermöglicht schnelle Lesezugriffe, bleibt aber eine Kopie. Änderungen müssen an das führende System zurückgehen oder über einen ausdrücklich definierten Prozess übernommen werden.

2. Organisationen, Konten und Rollen modellieren

Der Benutzer ist nicht der Kunde. Kunde ist in der Regel eine Organisation mit Standorten, Kostenstellen, Lieferadressen, Verträgen und mehreren Benutzern. Ein Benutzer kann mehreren Organisationen angehören oder im Auftrag einer anderen handeln. Datenmodell und Berechtigungskonzept müssen diese Beziehungen ausdrücklich abbilden.

Rollen wie Einkäufer, Genehmiger, Administrator und Buchhaltung sind ein Ausgangspunkt, aber noch keine fertige Berechtigungsmatrix. Prüfen Sie jede Aktion gegen Ressource und Organisationskontext: bestellen, Budget einsehen, Nutzer einladen, Adresse ändern, Rechnung herunterladen, Retoure anstoßen oder im Namen eines anderen Benutzers handeln.

• Organisation, Standort, Benutzer und Mitgliedschaft als getrennte Entitäten führen.
• Rollen in konkrete Berechtigungen übersetzen; eine Rolle in der Oberfläche ist keine Sicherheitsgrenze.
• Freigabelimits und Vier-Augen-Regeln versioniert und revisionssicher speichern.
• Einladung, Offboarding und Domainwechsel als Sicherheitsprozesse behandeln.
• Impersonation durch den Support zeitlich begrenzen, begründen lassen und vollständig protokollieren.
• Die Mandantentrennung mit negativen Berechtigungstests absichern.

3. Vertragspreise nachvollziehbar berechnen

Ein B2B-Preis ergibt sich aus dem Kontext: Organisation, Vertrag, Artikel, Menge, Einheit, Währung, Lieferland, Kanal, Datum, Steuerstatus und gegebenenfalls eine Promotion. Der Preisservice sollte deshalb nicht nur einen Betrag zurückgeben, sondern auch nachvollziehbar machen, welche Regel angewendet wurde und wie lange der Preis gilt.

Lassen Sie das Frontend nicht mehrere Preislisten nach eigenem Ermessen zusammenführen. Legen Sie Prioritäten und Ausschlüsse fest. Der Warenkorb speichert einen Preis-Snapshot mit Herkunft; vor der Bestellung wird der Preis neu berechnet oder nach einer dokumentierten Regel festgeschrieben.

• Die Preisantwort enthält Währung, Steuerbezug, Einheit, Gültigkeit und Rule-ID.
• Mengenstaffeln beziehen sich eindeutig auf die Verkaufs- oder die Basiseinheit.
• Gerundet wird an einer festgelegten Stelle und nicht in jedem Client erneut.
• Manuelle Preisfreigaben ändern keinen Vertrag ohne Audit Trail.
• Die Bestellposition speichert den akzeptierten Preis mitsamt Kontext.

4. Verfügbarkeit ist mehr als Lagerbestand

B2B-Kunden wollen meist wissen, was zugesagt werden kann (Available-to-Promise): Welche Menge lässt sich zu welchem Termin an welchen Ort liefern? Der physische Bestand allein lässt Reservierungen, bereits zugesagte Mengen, Beschaffung, Produktionszeiten, Verpackungseinheiten und Standortregeln außer Acht.

Formulieren Sie die Aussage in der Oberfläche präzise. „Sofort verfügbar“, „voraussichtlich lieferbar“ und „unverbindlich anfragen“ sind drei verschiedene Versprechen. Sind die Daten veraltet, muss das System Zeitpunkt und Unsicherheit berücksichtigen, statt eine exakte Zahl vorzutäuschen.

5. Erst den Auftragslebenszyklus klären, dann den Happy Path

Eine Bestellung durchläuft fachliche Zustände und keine beliebige Statusliste. Der Weg beginnt beim Entwurf oder Angebot und führt über Freigabe, Annahme, Kreditprüfung, Reservierung, Übergabe ans ERP, Teillieferung und Rechnung bis zu Storno und Retoure.

Die Status in Commerce und ERP decken sich selten. Arbeiten Sie mit einer ausdrücklichen Übersetzung und speichern Sie die externen Statuswerte zur Diagnose mit. Jeder Zustandswechsel braucht einen Auslöser, Vorbedingungen, einen Zeitstempel und einen Akteur. Korrigiert wird über neue Übergänge und nicht durch stilles Überschreiben.

• Änderungen nach dem Einreichen als fachliche Operation mit Berechtigungsprüfung modellieren.
• Teilmengen, Teillieferungen und Teilstornos auf Positionsebene unterstützen oder ausdrücklich ausschließen.
• Den Status für den Kunden aus den internen Zuständen ableiten, ohne ihn zu beschönigen.
• Jeder Zustand hat erlaubte Folgeschritte und einen verantwortlichen Dienst.

6. ERP, PIM, OMS und Commerce sauber abgrenzen

ERP, PIM und OMS sind keine austauschbaren Integrationsendpunkte. Das PIM pflegt Produktinformationen, das ERP führt kaufmännische Stamm- und Belegdaten, das OMS steuert Aufträge und Fulfillment, und das Commerce-System verantwortet die digitale Kaufinteraktion und die Commerce-Regeln. Wie die Aufgaben im Einzelfall verteilt werden, hängt davon ab, was die vorhandenen Systeme leisten.

Vermeiden Sie eine bidirektionale Synchronisation für dasselbe Feld, denn sie führt zu Schleifen und Konflikten. Wenn zwei Systeme ein Feld ändern müssen, brauchen Sie fachlich getrennte Felder, einen Freigabeprozess oder eine klare Zuständigkeit für das Zusammenführen.

7. Echtzeit nur dort, wo die Entscheidung sie braucht

Synchrone Abfragen sind sinnvoll, wenn die aktuelle Antwort eine unmittelbare Entscheidung des Nutzers bestimmt und es einen definierten Fallback gibt. Asynchrone Verarbeitung eignet sich für Verteilung, Entkopplung und Prozesse, die Verzögerung vertragen. Wer Echtzeit pauschal fordert, reicht jede ERP-Störung direkt an den Kunden weiter.

Legen Sie pro Datenfluss ein Freshness Budget fest: Wie alt darf eine Information sein, bevor sie ausgeblendet, gekennzeichnet oder synchron neu geprüft wird? Cache und Replikation sind fachliche Entscheidungen, weil sie bestimmen, welches Versprechen der Kunde zu sehen bekommt.

• Für jeden synchronen Aufruf Timeout, Retry, Circuit Breaker und Fallback festlegen.
• Event-Schema, Annahmen zur Reihenfolge und Aufbewahrungsdauer dokumentieren.
• Keine globale Reihenfolge voraussetzen, wenn die Technik sie nicht garantiert.
• Die Aktualität der Daten im Monitoring sichtbar machen, zusätzlich zur API-Verfügbarkeit.

8. Idempotenz und Reconciliation einbauen

In verteilten Systemen kommen Nachrichten mehrfach, verspätet oder in anderer Reihenfolge an. Nach einem Netzwerk-Timeout ist offen, ob eine Operation ausgeführt wurde. Idempotenz heißt: Wird dieselbe fachliche Absicht wiederholt, entsteht kein zweites Ergebnis. Dafür braucht jede Operation einen stabilen Schlüssel und eine gespeicherte Verarbeitungshistorie.

Idempotenz verhindert nicht jede Abweichung. Bei der Reconciliation werden Soll- und Ist-Zustände zwischen den Systemen regelmäßig verglichen, und daraus entstehen Fälle, die sich gezielt korrigieren lassen. Dieser Abgleich ist eine dauerhafte Funktion für Operations und kein einmaliges Migrationsskript.

• Den Idempotency Key aus der fachlichen Operation ableiten und über alle Wiederholungen beibehalten.
• Die Nutzdaten zum Schlüssel prüfen; derselbe Schlüssel mit anderem Inhalt ist ein Fehler.
• Inbox- oder Deduplizierungsstatus atomar zusammen mit der Verarbeitung speichern.
• Das Outbox-Muster nutzen, wenn Datenänderung und Event-Veröffentlichung konsistent gekoppelt sein müssen.
• Reconciliation für Bestellungen, Zahlungen, Reservierungen und Rechnungen regelmäßig einplanen.
• Abweichungen mit Kategorie, Verantwortlichem, Alter und sicherer Korrekturmaßnahme anzeigen.

9. Fehlerfälle als fachliche Zustände behandeln

Ein technischer Fehler wird zum geschäftlichen Problem, sobald unklar ist, ob Auftrag, Zahlung oder Reservierung existieren. Modellieren Sie unbekannte Ausgänge deshalb ausdrücklich. Automatische Wiederholungen sind nur sicher, wenn die Zieloperation idempotent ist und sich der Fehler als vorübergehend einstufen lässt.

Eine Dead-Letter-Queue ist kein Endzustand. Sie braucht Alarmierung, Kontext, Regeln für das erneute Einspielen und einen Verantwortlichen. Wer Nachrichten ungeprüft erneut einspielt, wendet unter Umständen veraltete Preis-, Bestands- oder Statusereignisse ein zweites Mal an.

10. B2B-Sicherheit: Mandanten, Rollen und sensible Konditionen

B2B-Daten sind nicht per se weniger sensibel als Verbraucherdaten. Vertragspreise, Einkaufsvolumen, offene Posten und Lieferadressen können geschäftskritisch sein. Jede Abfrage muss den Organisationskontext durchsetzen. Ein Filter im Frontend oder nachträgliches Ausblenden genügt nicht.

Setzen Sie auf eine zentrale Identität, starke Authentisierung für privilegierte Rollen und kurze, überprüfbare Berechtigungswege. Zugriffe zwischen Diensten brauchen eigene Identitäten, minimale Scopes und regelmäßige Rotation. Exportdateien und Support-Werkzeuge gehören in dasselbe Bedrohungsmodell wie die APIs.

• Mandantenübergreifende Objektzugriffe automatisiert mit Negativtests prüfen.
• MFA für Organisationsadmins, Support und interne Backoffice-Rollen verpflichtend machen.
• Zugriffe auf Preise, Kreditlimits und Rechnungen protokollieren.
• CSV- und Excel-Exporte gegen Formula Injection und unkontrollierte Weitergabe absichern.
• Webhooks signieren, Replay-Fenster prüfen und Secrets rotieren.
• Löschung, Sperrung und Offboarding in allen replizierten Systemen durchführen.

11. Observability entlang des Auftrags

Die wichtigste Größe für die Beobachtung ist die fachliche Korrelation: Organisation, Warenkorb, Bestellung, externe ERP-Nummer, Zahlung und Lieferung müssen sich miteinander verknüpfen lassen, ohne dass sensible Inhalte in jedes Log kopiert werden. OpenTelemetry bietet dafür ein herstellerneutrales Modell für Traces, Metriken und Logs.

Messen Sie neben Latenz und Fehlerquote auch die fachlichen Warteschlangen: nicht exportierte Bestellungen, Orders ohne Bestätigung aus dem ERP, veraltete Preise, blockierte Freigaben und nicht zugeordnete Zahlungen. An diesen Kennzahlen erkennen Sie Umsatz- und Betriebsrisiken früher als an CPU- oder Speicherwerten.

12. Rollout in Stufen, geordnet nach Risiko

Teilen Sie den Rollout nicht nur nach Traffic auf, sondern auch nach fachlicher Komplexität. Ein Pilot mit wenigen kooperativen Organisationen, klaren Preisregeln und begrenztem Sortiment liefert verwertbare Erkenntnisse. Ein Pilot, der alle Sonderfälle auf einmal enthält, beweist wenig und bindet Operations.

Führen Sie zuerst die lesenden Funktionen ein, dann Warenkorb und Angebot, anschließend die Bestellannahme und zuletzt komplexe Freigabe-, Kredit- oder Fulfillment-Szenarien. Liefert gerade ein komplexer Prozess den größten Nutzen, können Sie die Reihenfolge ändern. Dieser Prozess muss dann allerdings als vertikaler Slice vollständig getestet werden.

• Baseline und Erfolgskriterien je Kohorte festlegen.
• Organisationen mit klar definiertem Vertrag, Sortiment und Ansprechpartner im Support auswählen.
• ERP-Buchungen zunächst parallel validieren, ohne doppelte Aufträge zu erzeugen.
• Feature Flags auf Organisationsebene mit Kill Switch einsetzen.
• Abweichungen täglich mit Vertrieb, Operations, Finance und Support durchgehen.
• Die nächste Stufe erst freigeben, wenn die Kriterien für Daten, Prozesse und Betrieb erfüllt sind.
• Manuelle Übergangsprozesse mit Kapazitätsgrenze und Enddatum versehen.

13. Abnahmecheckliste für B2B-Commerce

Die Abnahme sollte mit realistischen Verträgen, Rollen und Fehlerfällen stattfinden. Ein erfolgreicher Checkout in der Demo belegt weder Datenkonsistenz noch Betriebsfähigkeit.

• Jede kritische Datendomäne hat ein führendes System, einen Verantwortlichen, ein Freshness Budget und eine Konfliktregel.
• Organisationen, Standorte, Mitgliedschaften und Rollen sind getrennt modelliert.
• Mandantenübergreifende Zugriffe sind serverseitig unterbunden und mit Negativtests geprüft.
• Vertragspreise sind mit Regel, Einheit, Währung, Steuerkontext und Gültigkeit reproduzierbar.
• Verfügbarkeitsaussagen entsprechen der tatsächlichen ATP- und Reservierungslogik.
• Auftragszustände, Übergänge und Systemverantwortung sind dokumentiert.
• Teilmengen, Teillieferungen, Stornos und Änderungen sind unterstützt oder ausdrücklich ausgeschlossen.
• Synchrone und asynchrone Datenflüsse haben Regeln für Timeout, Retry und Fallback.
• Order Export, Payment und Webhooks sind idempotent.
• Die Reconciliation erkennt verlorene, doppelte und widersprüchliche Zustände.
• Der Support kann Fehlerfälle ohne direkten Datenbankzugriff bearbeiten.
• Traces und Korrelation verbinden Commerce-ID, ERP-ID und Zahlungsreferenz.
• Rollout-Kriterien, Rückfallweg und das Ende manueller Übergangslösungen sind beschlossen.