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 im Betrieb sind und nun als Einheit zusammenarbeiten müssen. Unser Leitfaden zur Integration von Unternehmenssystemen erläutert die allgemeinen Grundsätze: Dateneigentümerschaft, Integrationsmuster und den Entwurf für Fehlerfälle. Diese Seite wendet sie auf das Commerce-Dreieck an – Fluss für Fluss – und schließt mit einer Topologiewahl und einem Rollout-Plan.

In diesem Leitfaden

• Drei Systeme, fünf Flüsse
• Die Referenzarchitektur
• Gestaltung der fünf Flüsse
• B2B-Regeln, die das Design verändern
• Topologien: Alternativen und Auswahlkriterien
• KI in der Integrationsschicht
• Ein Rollout-Plan
• Praxisbeispiele aus der Netbase-Lieferung
• Was an Liefernachweisen vorliegt und was nicht
• 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, Bestände, Preise, Aufträge zur Auftragsabwicklung und die Buchhaltung. Das CRM verwaltet Konten, Kontakte, Angebote und den Serviceverlauf. Darum herum befinden sich ein Zahlungsanbieter, ein Lager oder Spediteur sowie häufig ein Produktinformationssystem.

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

Füllen Sie diese Tabelle für Ihre eigene Landschaft aus, bevor Sie ein Werkzeug wählen. Beanspruchen zwei Systeme dieselbe Zeile, entscheidet das Unternehmen über den Eigentümer – nicht der Integrator. Der Pillar-Leitfaden erläutert, warum ein Eigentümer pro Datensatz wichtig ist; der Rest dieser Seite behandelt, was jeder Fluss benötigt, sobald der Eigentümer feststeht.

Die Referenzarchitektur

Ein dauerhaftes Design hat dieselben Schichten, unabhängig davon, welches Produkt sie umsetzt.

• Ein Adapter pro System. Jeder Shop, jedes ERP oder CRM erhält seinen 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 einfließt. Wird das ERP ausgetauscht, ändert sich nur sein Adapter.
• Ein gemeinsames Datenmodell. Adapter übersetzen in ein kanonisches Modell von Produkt, Kunde, Auftrag 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.
• Eine Identifier-Querverweis-Tabelle. Eine kleine Tabelle ordnet den Schlüssel jedes Datensatzes in jedem System zu: die Auftragsnummer des Shops, die Verkaufsauftrags-ID des ERP und die Opportunity des CRM. Nichts wird per Name oder E-Mail abgeglichen.
• Dauerhafte Ereignisse. Eine Änderung wird in derselben Datenbanktransaktion erfasst, die sie vornimmt, und dann veröffentlicht – das Transactional-Outbox-Muster –, damit ein Absturz nicht dazu führen kann, dass das ERP aktualisiert, der Shop aber nicht informiert wird.
• Orchestrierung für mehrstufige Flüsse. Order-to-Cash berührt vier Systeme; eine Komponente besitzt die Sequenz und ihre Kompensationen, sodass die Schritte nicht über Webhooks verstreut sind.
• Monitoring und Abgleich. Jeder Fluss hat ein Dashboard, einen Alert und einen täglichen Vergleich von Anzahl 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 Pillar-Leitfaden beschrieben und gelten unverändert.

Gestaltung der fünf Flüsse

Katalog und Preise. Übertragen Sie Änderungen vom Eigentümer als Ereignisse und führen Sie einen nächtlichen vollständigen Abgleich durch, denn ein verpasstes Ereignis bei einem Preis ist schlimmer 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.

Bestand. Übermitteln Sie Verfügbarkeit, nicht den Rohbestand: Lagerbestand minus Reservierungen minus Sicherheitsbestand, pro Kanal. Reservieren Sie Bestand bei Auftragsanlage und geben Sie ihn bei Stornierung frei, damit zwei Kanäle nicht dieselbe letzte Einheit zweimal verkaufen können.

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

Aufträge und Status. Der Shop besitzt einen Auftrag bis zur Zahlungsautorisierung; danach besitzt das ERP die Auftragsabwicklung, und Status, Versand und Tracking fließen zurück. Ein Auftrag trägt einen Idempotenz-Schlüssel aus dem Shop, da RFC 9110 POST als nicht idempotent definiert und ein wiederholter Erstellungsvorgang nicht zu einem zweiten Verkaufsauftrag 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 eingezogene Zahlungen täglich gegen Rechnungen ab und erlauben Sie Erstattungen nur über das ERP oder seine API.

B2B-Regeln, die das Design verändern

Der Verkauf an Unternehmen bringt Regeln mit sich, die ein Verbrauchershop nie kennt, und jede entscheidet, wo die Logik liegt:

• Kundenspezifische Preislisten und Vertragspreise bleiben im ERP oder CRM und werden pro Konto abgerufen, nicht als Tausende von Produktvarianten kopiert.
• Kreditlimits und Zahlungskonditionen werden beim Checkout gegen das ERP geprüft; ein Auftrag über dem Limit wartet auf Genehmigung, anstatt zu scheitern.
• Angebote entstehen im CRM und werden ohne erneute Dateneingabe in einen Auftrag umgewandelt, wobei die Angebotsreferenz auf dem ERP-Auftrag erhalten bleibt.
• Bestellungen und Genehmigungen der Käuferseite werden beim Auftrag gespeichert, damit die Rechnung dem entspricht, was das Finanzteam des Käufers erwartet.

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 beginnen mit Konnectoren und wechseln zu einem Hub, wenn Fehler-Handling und Übersicht an ihre Grenzen stoßen; ein Integrations-Hub ist die selbst betriebene Version dieses Schritts. Multi-Vendor-Shops fügen Auszahlungen an Verkäufer und Lieferantenkataloge hinzu, behandelt in Marketplace-Plattformarchitektur. Steht ein Shopwechsel bevor, klären Sie das zuerst mit dem Leitfaden für individuelle E-Commerce-Plattformen.

Praxisbeispiele aus der Netbase-Lieferung

• Reward-Shop-Plattform (Kunde nicht genannt). Für ein Loyalty-Unternehmen mit Sitz in Dubai verband Netbase eine headless Magento 2-Multi-Store-Plattform mit der Points-Middleware, dem Bestellservice und dem Produktkatalog des Kunden. Die Systeme des Kunden besitzen Punkte und Aufträge; Webhooks übertragen Änderungen, und eine geplante Synchronisation dient als Failover. Siehe den Reward-Shop-Bericht.
• 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 Mieter bereits nutzen. Siehe den Cloud-ERP-Bericht.
• Cloodo Workspace. Eine Business Division von Netbase, deren Arbeitsplatz CRM, HRM, Cloud-ERP und KI-Module in einem Produkt vereint, sodass Datensätze in einem System leben, statt synchronisiert zu werden. Siehe den Cloodo-Bericht.

Netbase hat auch Kundenshops über API-Synchronisation von Katalogen, Beständen, Aufträgen und Kunden mit deren ERP verbunden; diese Kunden werden nicht genannt.

Was an Liefernachweisen vorliegt und was nicht

• Was vorliegt. Die oben genannten Berichte beschreiben Umfang und Design: welche Systeme verbunden wurden, welches System welche Daten besitzt und wie Änderungen übertragen werden. Die produktisierten Module von Netbase umfassen ein CRM und eine B2B-Sales-Engine, ein Workflow-Automatisierungs-Toolkit und Smart ERP Light; zu den ausgelieferten Plattformen gehören WooCommerce, Magento 2, Laravel und headless Commerce.
• Was nicht vorliegt. Keiner dieser Berichte veröffentlicht die Dauer einer Integration, das Nachrichtenvolumen, die Fehlerquote oder ein geschäftliches Ergebnis, und keiner wird hier als Nachweis einer Kennzahl angeboten. Die ERP-Integrationskunden werden nicht genannt.

Grenzen dieses Leitfadens

• Die Flusstabelle ist ein Standard für B2C- und B2B-Commerce; Marktplätze, Abonnements und Fertigung bringen eigene Flüsse mit.
• Die Muster sind aus ihren öffentlichen Beschreibungen zitiert; ihre Anwendung macht eine Integration nicht ohne Tests gegen echte Daten korrekt.
• Sicherheitspraktiken wie Least-Privilege-Schlüssel, TLS bei der Übertragung, AES im Ruhezustand und MFA für den Administratorzugang reduzieren Risiken; sie sind keine Garantie.

Nächster Schritt

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

Verwandte Leistungen und Lösungen