ERP-, CRM- und E-Commerce-Integrationsarchitektur: ein flussorientiertes Design

Dieser Leitfaden richtet sich an CTOs, IT-Manager und E-Commerce-Verantwortliche, deren Shop, ERP und CRM bereits laufen und nun als Einheit funktionieren müssen. Unser Leitfaden zur Enterprise-Systemintegration erläutert die allgemeinen Prinzipien: Record-Ownership, Integrationsmuster und fehlertolerantes Design. Diese Seite wendet sie auf das Commerce-Dreieck an – Fluss für Fluss – und schließt mit einer Topologiewahl und einem Rollout-Plan.

Inhalt dieses Leitfadens

• Drei Systeme, fünf Flüsse
• Die Referenzarchitektur
• Die fünf Flüsse entwerfen
• Welche B2B-Regeln verändern das Design?
• Topologien: Alternativen und Auswahlkriterien
• KI in der Integrationsschicht
• Ein Rollout-Plan
• Praxisbeispiele aus der Netbase-Lieferung
• Welcher Liefernachweis existiert, und welcher nicht?
• Was sind die Grenzen dieses Leitfadens?
• Häufig gestellte Fragen
• Nächster Schritt

Drei Systeme, fünf Flüsse

Die meisten Commerce-Landschaften haben dieselben drei Systeme im Mittelpunkt. Der Shop verkauft und nimmt Zahlungen entgegen. Das ERP verwaltet Produkte, Lagerbestände, Preise, Bestellungen für die Fulfillment-Abwicklung und die Buchhaltung. Das CRM verwaltet Accounts, Kontakte, Angebote und den Service-Verlauf. Dazu kommen ein Zahlungsanbieter, ein Lager oder Spediteur sowie häufig ein Produktinformationssystem.

Fast alle Integrationsarbeiten in diesem Dreieck lassen sich auf fünf Flüsse reduzieren:

Füllen Sie diese Tabelle für Ihre eigene Landschaft aus, bevor Sie sich für ein Tool entscheiden. Wenn zwei Systeme dieselbe Zeile beanspruchen, legt das Unternehmen den Eigentümer fest – nicht der Integrator. Der Grundlagenleitfaden erklärt, warum ein Eigentümer pro Datensatz wichtig ist; der Rest dieser Seite erläutert, was jeder Fluss benötigt, sobald der Eigentümer feststeht.

Die Referenzarchitektur

Ein dauerhaftes Design hat unabhängig vom eingesetzten Produkt dieselben Schichten.

• Ein Adapter je System. Jeder Shop, jedes ERP oder CRM erhält einen eigenen Adapter, der die API und das Datenmodell dieses Systems spricht. Microsofts Architecture Center beschreibt dies als Anti-Corruption Layer: eine Übersetzungsschicht, die verhindert, dass die Semantik eines Systems in ein anderes einsickert. Wenn das ERP ausgetauscht wird, ändert sich nur dessen Adapter.
• Ein gemeinsames Datenmodell. Adapter übersetzen in ein kanonisches Modell für Produkt, Kunde, Bestellung und Rechnung – nicht ineinander. Der Enterprise Integration Patterns-Katalog erklärt warum: Mit einem gemeinsamen Format benötigt jedes neue System nur ein Übersetzungspaar statt eines pro Partner.
• Ein Identifier-Querverzeichnis. Eine kleine Tabelle bildet den Schlüssel jedes Datensatzes in jedem System ab: die Bestellnummer des Shops, die Vertriebsauftragsnummer des ERP und die Opportunity-ID des CRM. Nichts wird per Name oder E-Mail-Adresse abgeglichen.
• Dauerhafte Events. Eine Änderung wird in derselben Datenbanktransaktion aufgezeichnet, die sie vornimmt, und dann veröffentlicht – das Transactional-Outbox-Muster – so dass ein Absturz das ERP nicht aktualisiert und den Shop uninformiert lassen kann.
• Orchestrierung für mehrstufige Flüsse. Order-to-Cash berührt vier Systeme; eine Komponente besitzt die Abfolge und ihre Kompensationen, damit die Schritte nicht über Webhooks verstreut sind.
• Monitoring und Abstimmung. Jeder Fluss hat ein Dashboard, einen Alert und einen täglichen Abgleich von Mengen und Summen zwischen Eigentümer und Kopien.

Die Fehlerregeln für jede Schicht – idempotente Schreibvorgänge, Wiederholungsversuche mit Backoff und eine Dead-Letter-Queue – sind im Grundlagenleitfaden beschrieben und gelten unverändert.

Die fünf Flüsse entwerfen

Katalog und Preise. Übermitteln Sie Änderungen vom Eigentümer als Events und führen Sie nächtlich einen vollständigen Vergleich durch, da ein verpasstes Event bei einem Preis schlimmer ist als ein verspätetes. Veröffentlichen Sie einen Preis mit seinen Gültigkeitsdaten, damit der Shop nie einen Preis anzeigt, den das ERP nicht berechnen wird.

Lager. Übermitteln Sie Verfügbarkeit, nicht den Rohbestand: verfügbar minus reserviert minus Sicherheitsbestand, je Kanal. Reservieren Sie Bestand bei der Bestellerstellung und geben Sie ihn bei Stornierung frei, damit zwei Kanäle nicht die letzte Einheit zweimal verkaufen können.

Kunden und Accounts. Im B2B-Bereich besitzt das CRM üblicherweise den Account und seine Kontakte, und das ERP besitzt die Kreditkonditionen. Der Shop erhält beides, und ein neuer Web-Kunde wird zuerst beim Eigentümer angelegt und dann kopiert, damit eine Person nie zu drei Datensätzen wird.

Bestellungen und Status. Der Shop besitzt eine Bestellung bis zur Zahlungsautorisierung; ab diesem Zeitpunkt besitzt das ERP die Fulfillment-Abwicklung, und Status, Versand und Tracking fließen zurück. Eine Bestellung trägt einen Idempotency-Key des Shops, da RFC 9110 POST als nicht idempotent definiert und ein erneuter Erstellungsversuch nicht zu einem zweiten Vertriebsauftrag werden darf.

Zahlungen, Rechnungen und Erstattungen. Der Zahlungsanbieter besitzt die Transaktion; das ERP besitzt die Rechnung und die Gutschrift; das CRM zeigt beides dem Account-Team. Gleichen Sie erfasste Zahlungen täglich gegen Rechnungen ab, und lassen Sie Erstattungen nur vom ERP oder über dessen API starten.

Welche B2B-Regeln verändern das Design?

Der Verkauf an Unternehmen fügt Regeln hinzu, denen ein B2C-Shop nie begegnet, und jede davon entscheidet, wo die Logik lebt:

• Kundenspezifische Preislisten und Vertragspreise verbleiben im ERP oder CRM und werden je Account abgerufen, nicht als Tausende von Produktvarianten kopiert.
• Kreditlimits und Zahlungskonditionen werden beim Checkout gegen das ERP geprüft; eine Bestellung über dem Limit wartet auf Freigabe, anstatt zu scheitern.
• Angebote entstehen im CRM und werden ohne erneute Dateneingabe in eine Bestellung umgewandelt, wobei die Angebotsreferenz auf dem ERP-Auftrag erhalten bleibt.
• Bestellungen und Freigaben auf Käuferseite werden mit der Bestellung gespeichert, damit die Rechnung den Erwartungen des Finanzteams des Käufers entspricht.

Topologien: Alternativen und Auswahlkriterien

Vier Kriterien entscheiden: wie standardisiert Ihre Daten und Regeln sind, wie viele Systeme und Flüsse Sie in zwei Jahren erwarten, wer die Logik besitzen und ändern muss, und wer sie nachts betreibt. Viele Landschaften starten mit Konnektoren und wechseln zu einem Hub, wenn Fehlerbehandlung und Transparenz nicht mehr ausreichen; ein Integration Hub ist die selbst betriebene Version dieses Schritts. Multi-Vendor-Shops fügen Auszahlungen an Verkäufer und Vendor-Kataloge hinzu, was in der Marketplace-Plattformarchitektur behandelt wird. Wenn der Shop selbst kurz vor einer Ablösung steht, klären Sie das zuerst mit dem Custom-E-Commerce-Plattform-Leitfaden.

Praxisbeispiele aus der Netbase-Lieferung

• Reward-Shop-Plattform (Kunde nicht genannt). Für ein in Dubai ansässiges Loyalty-Unternehmen hat Netbase eine headless Magento 2-Multi-Store-Plattform mit der Punkte-Middleware, dem Bestellservice und dem Produktkatalog des Kunden verbunden. Die Systeme des Kunden besitzen Punkte und Bestellungen; Webhooks übertragen Änderungen, und eine geplante Synchronisierung ist der Failover. Siehe den Reward-Shop-Datensatz.
• Cloud-ERP für einen US-Kunden (nicht genannt). Als Offshore-Entwicklungspartner und Managing Partner seit 2020 baut Netbase ein mandantenfähiges Cloud-ERP, dessen erste Phase CRM- und API-Integrationen zu den Systemen umfasst, die Mandanten bereits nutzen. Siehe den Cloud-ERP-Datensatz.
• Cloodo Workspace. Eine Netbase Business Division, deren Arbeitsplattform CRM, HRM, Cloud-ERP und KI-Module in einem Produkt vereint, damit Datensätze in einem System liegen statt synchronisiert zu werden. Siehe den Cloodo-Datensatz.

Netbase hat außerdem Kunden-Shops per API-Synchronisierung von Katalogen, Lagerbeständen, Bestellungen und Kunden mit ihrem ERP verbunden; diese Kunden werden nicht genannt.

Welcher Liefernachweis existiert, und welcher nicht?

• Was existiert. Die oben genannten Datensätze beschreiben Umfang und Design: welche Systeme verbunden wurden, welches System welche Daten besitzt und wie Änderungen übertragen werden. Zu den produktisierten Modulen von Netbase gehören ein CRM und eine B2B-Sales-Engine, ein Workflow-Automatisierungs-Toolkit und Smart ERP Light; die realisierten Plattformen umfassen WooCommerce, Magento 2, Laravel und headless Commerce.
• Was nicht existiert. Keiner dieser Datensätze veröffentlicht Laufzeit, Nachrichtenvolumen, Fehlerrate oder Geschäftsergebnis einer Integration, und keiner wird hier als Beleg für eine Kennzahl angeführt. Die ERP-Integrationskunden werden nicht genannt.

Was sind die Grenzen dieses Leitfadens?

• Die Flusstabelle ist ein Standard für B2C- und B2B-Commerce; Marktplätze, Abonnements und Fertigung fügen eigene Flüsse hinzu.
• Die Muster sind aus ihren öffentlichen Beschreibungen zitiert; ihre Anwendung macht eine Integration ohne Tests gegen echte Daten nicht automatisch korrekt.
• Sicherheitspraktiken wie Least-Privilege-Keys, TLS im Transit und AES im Ruhezustand sowie MFA für Administratorzugänge reduzieren Risiken; sie sind keine Garantie.

Nächster Schritt

Teilen Sie uns Ihren Shop, Ihr ERP und Ihr CRM mit, welche Flüsse am häufigsten scheitern und eventuelle Fristen, und wir vereinbaren einen Solution-Review, um Eigentümer, Flüsse und eine Topologie zu kartieren. Sie können auch Systems- und API-Integration, ERP- und CRM-Entwicklung oder weitere Netbase JSC-Insights ansehen.

Verwandte Leistungen und Lösungen