Website oder Shop an ERP und CRM anbinden

Welche Daten sollen wohin?

Ein fiktiver Zulieferer betreibt eine Website mit Anfrageformular und Händlerbereich sowie einen Onlineshop. Anfragen werden von Hand ins CRM übertragen, Preislisten regelmäßig aus dem ERP exportiert und hochgeladen. Künftig sollen diese Schritte automatisch laufen und auch Shopbestellungen im ERP ankommen.

Für die Planung lohnt es sich, jeden dieser Abläufe einzeln zu betrachten. Drei Fragen helfen dabei:

1. Welche Daten werden wo gepflegt? Beispielsweise liefert das ERP Preise und Bestände, während Produktbeschreibungen auf der Website entstehen. Es muss feststehen, welches System bei abweichenden Werten maßgeblich ist. Sonst kann ein Abgleich die Arbeit Ihrer Mitarbeiter überschreiben.
2. Wie aktuell müssen die Daten sein? Für einen selten geänderten Katalog kann der Stand vom Vorabend reichen. Bei knappen Lagerbeständen kann schon eine kurze Verzögerung zu Bestellungen führen, die Sie nicht mehr erfüllen können.
3. Was soll bei einem Ausfall passieren? Eine Anfrage lässt sich speichern und später ins CRM übertragen. Wer gerade einen Vertragspreis im Händlerbereich aufruft, braucht dagegen sofort eine Antwort oder einen verständlichen Hinweis.

Anschließend werden die Datenzugänge geprüft. Eine API ist eine Schnittstelle, über die Programme Daten abrufen oder übergeben können. Fehlt eine passende API, kommen möglicherweise automatische Exporte und Importe infrage. Entscheidend ist, ob der Zugang die benötigten Daten und Aktionen unterstützt und für Ihre Nutzung freigegeben ist.

Auch die Zuordnung muss stimmen: Ein Kunde kann im Shop und im ERP unterschiedliche Kundennummern haben. Die Anbindung braucht eine eindeutige Verbindung zwischen diesen Kennungen, damit Bestellungen beim richtigen Kunden landen.

Fertige Anbindung oder eigene Entwicklung?

Zuerst lohnt sich die Prüfung vorhandener Lösungen. Reichen diese nicht aus, lässt sich die Anbindung im Website- oder Shopsystem ergänzen oder als eigener Dienst betreiben.

Einen fertigen Connector nutzen

Ein Connector ist ein vorgefertigter Baustein, der zwei Systeme verbindet. Eine Integrationsplattform bietet mehrere solcher Bausteine, aus denen sich Abläufe zusammensetzen lassen. Beides kann Entwicklungsarbeit sparen, wenn Ihre Systeme und der gewünschte Ablauf bereits unterstützt werden.

Prüfen Sie das an einem vollständigen Beispiel: Überträgt der Connector bei einer Bestellung auch kundenspezifische Preise, Lieferadressen und spätere Stornierungen? Lassen sich eigene Felder ergänzen? Funktioniert das mit den Versionen, die Sie einsetzen?

Zum Vergleich gehören neben dem Kauf- oder Abopreis auch Einrichtung und Anpassungen. Eine Übersicht der Auswahlkriterien bietet die Seite zur Schnittstellenentwicklung.

Das Website- oder Shopsystem erweitern

Eine individuelle Erweiterung läuft innerhalb Ihres bestehenden Systems, etwa als WordPress-Plugin, TYPO3-Extension oder Magento-Modul. Das passt häufig zu überschaubaren Aufgaben wie der Übernahme von Formulareingaben oder einem regelmäßigen Produktimport.

Die Erweiterung nutzt die vorhandene technische Umgebung und wird zusammen mit dieser betreut. Lange Importe können den Server belasten, auf dem auch die Website läuft. Wenn mehrere Anwendungen dieselben Daten benötigen, kann es sinnvoller sein, den Austausch separat zu betreiben.

Auch ein fertiger Connector kann als Plugin installiert werden. „Fertig oder individuell“ beschreibt also die Herkunft der Lösung; „Plugin oder eigener Dienst“ beschreibt, wo sie läuft.

Einen eigenen Dienst zwischen die Systeme setzen

Ein eigener Dienst übernimmt den Datenaustausch außerhalb der Website. Er kann beispielsweise dieselben ERP-Daten für Shop, Website und Kundenportal aufbereiten oder aufwendige Preisregeln ausführen. Solche vermittelnde Software wird häufig als Middleware bezeichnet.

Ein einfacher Dienst übersetzt nur Felder und Formate zwischen zwei Schnittstellen. Dafür ist auch der Begriff Adapter gebräuchlich. Ein umfangreicherer Dienst kann zusätzlich Verarbeitungsschritte steuern und deren Status festhalten.

Der Vorteil ist die getrennte Weiterentwicklung: Ein Umbau der Website muss nicht die gesamte Anbindung betreffen. Dafür braucht der Dienst eine eigene Betriebsumgebung, Überwachung und Wartung. Für einen einzelnen, einfachen Datenfluss kann dieser Aufwand zu groß sein.

Wie und wann werden Daten übertragen?

Ein Plugin, ein Connector oder ein eigener Dienst kann unterschiedliche Übertragungsverfahren nutzen. Innerhalb derselben Anbindung lassen sie sich kombinieren.

Regelmäßig im Hintergrund abgleichen

Ein geplanter Abgleich eignet sich für Daten, die etwas älter sein dürfen, etwa Katalogtexte oder allgemeine Preislisten. Er kann eine API nutzen oder Dateien einlesen, die das ERP regelmäßig bereitstellt. Die gebündelte Verarbeitung mehrerer Datensätze heißt auch Batch-Verarbeitung. Ob sie täglich oder alle paar Minuten läuft, hängt von Datenmenge und Systemen ab.

Bei Dateien müssen Format und Übergabe eindeutig vereinbart sein: Wann ist der Export vollständig? Wie werden Preise und Artikelnummern gelesen? Woran erkennt der Import gelöschte Artikel? Ein fehlender Artikel darf nur dann als gelöscht gelten, wenn der Export nachweislich den vollständigen Bestand enthält.

Die Zeitsteuerung sollte unabhängig von Websitebesuchen laufen. Bei WordPress wird WP-Cron standardmäßig durch Seitenaufrufe angestoßen; bei wenig Besuch können Aufgaben verspätet starten. Die Dokumentation beschreibt deshalb auch die Ausführung über die Zeitsteuerung des Servers.

Nach einem Ereignis übertragen und Ausfälle überbrücken

Eine neue Bestellung oder Formulareingabe kann die Übertragung unmittelbar auslösen. Manche Systeme melden solche Ereignisse per Webhook, also durch eine automatische Nachricht an eine vereinbarte Adresse. WooCommerce unterstützt dafür unter anderem Bestellereignisse.

Damit eine vorübergehende ERP- oder CRM-Störung die Übergabe nicht verhindert, kann die Anbindung den Vorgang zunächst dauerhaft in einer Warteschlange speichern. Die Verarbeitung versucht die Übertragung später erneut. Während des Ausfalls bleiben die Daten im Zielsystem allerdings unvollständig; die Warteschlange überbrückt die Wartezeit.

Wiederholungen müssen sicher sein: Hat das ERP eine Bestellung schon angelegt, aber die Antwort geht verloren, darf der nächste Versuch keinen zweiten Auftrag erzeugen. Dafür braucht der Vorgang eine eindeutige Kennung, anhand derer das Zielsystem eine Wiederholung erkennt. Dieses Prinzip heißt Idempotenz und wird in der AWS Builders’ Library erläutert.

Eine Warteschlange allein garantiert noch keine zuverlässige Übergabe. Aufbewahrungsdauer und Wiederholungsversuche müssen zur erwarteten Ausfallzeit passen. Dauerhaft fehlerhafte Vorgänge brauchen eine gesonderte Ablage und eine Meldung an die zuständige Person. Eine solche Fehlerablage muss eingerichtet werden, wie etwa die Symfony-Dokumentation zur Behandlung fehlgeschlagener Nachrichten zeigt.

Daten beim Aufruf abrufen

Wenn ein Kunde im Händlerbereich seinen Vertragspreis oder den Status eines Auftrags sehen möchte, kann die Website die Daten beim Aufruf anfordern. Das ist sinnvoll, wenn ein zuvor gespeicherter Stand für diesen Zweck zu alt wäre.

Dazwischen steht eine Schnittstelle auf dem Server, die Anmeldung und Zugriffsrechte prüft. Sie liefert nur die Daten des berechtigten Kunden; Zugangsdaten zum ERP bleiben auf dem Server.

Dieser Weg hängt von der Antwortzeit des ERP ab. Ein kurzer Zwischenspeicher, auch Cache genannt, kann die Zahl der Abrufe reduzieren, sofern die erlaubte Aktualität das zulässt. Kundenspezifische Daten müssen dabei getrennt bleiben: Der Vertragspreis eines Händlers darf niemals in einer für alle Besucher gespeicherten Seite landen.

Für eine ausbleibende Antwort braucht die Website eine festgelegte Reaktion. Sie kann beispielsweise den letzten bekannten Stand mit Zeitangabe anzeigen oder darauf hinweisen, dass der Preis gerade nicht verfügbar ist. Welche Variante zulässig ist, hängt vom jeweiligen Geschäftsablauf ab.

Beispiel: Bestände für 8.000 Artikel aktuell halten

Dass eine Schnittstelle vorhanden ist, sagt noch nichts darüber aus, wie schnell sie die nötigen Daten liefern kann. Das zeigt eine fiktive Rechnung: Ein Shop führt 8.000 Artikel. Die Bestände sollen höchstens 15 Minuten alt sein. Angenommen, das ERP erlaubt 100 Abrufe pro Minute und liefert pro Abruf den Bestand eines Artikels.

Ein vollständiger Abgleich benötigt dann allein für die Abrufe rund 80 Minuten. Das Ziel ist damit nicht erreichbar, unabhängig davon, welche Software den Abgleich ausführt.

Ändern sich in 15 Minuten nur 300 Bestände, wären für deren Einzelabrufe rechnerisch 3 Minuten nötig. Dafür muss die Schnittstelle geänderte Artikel gezielt liefern oder Änderungen melden können. Auch Sammelabfragen für mehrere Artikel können helfen, sofern das ERP sie unterstützt.

Für die zugesagten 15 Minuten zählt die gesamte Zeit von der Änderung im ERP bis zur Anzeige im Shop. Wartezeiten bis zum nächsten Abgleich, zusätzliche Abfragen und die Verarbeitung müssen also mitgerechnet werden. Ein Start alle 15 Minuten genügt dafür nicht. Solche Grenzen sollten vor der Umsetzung mit realistischen Datenmengen geprüft werden.

So lassen sich die Verfahren kombinieren

Beim Zulieferer vom Anfang könnte die Aufteilung so aussehen:

Ob diese Abläufe ein vorhandener Connector, eine Erweiterung oder ein eigener Dienst übernimmt, wird anschließend anhand der benötigten Funktionen entschieden. Es muss nicht für jeden Ablauf eine eigene Anwendung entstehen.

Umsetzung und Betreuung vereinbaren

Vor dem Start sollten Ihre Agentur, der ERP- oder CRM-Betreuer und der Entwickler der Anbindung ihre Zuständigkeiten abstimmen. Dazu gehören die Darstellung auf der Website, die Zugänge zu den Systemen und die Bearbeitung von Störungen. Vereinbaren Sie auch, wer nach Updates prüft, ob der Austausch weiterhin funktioniert.

Zur Abnahme gehört ein vollständiger Durchlauf mit typischen Geschäftsvorgängen. Dabei sollten auch ein Ausfall des Zielsystems, eine doppelte Übertragung und fehlerhafte Daten erprobt werden. Entscheidend ist, ob Ihr Team erkennt, was angekommen ist und wo jemand eingreifen muss.

Ich entwickle die Anbindung und stimme die Übergabe der Daten mit Ihrer Agentur oder Ihrem Team ab. Wie diese Zusammenarbeit aussehen kann, beschreibt die Seite CRM- und ERP-Anbindung für Website und Shop.

Quellen und Einordnung

Die verlinkten Dokumentationen von WordPress, WooCommerce, AWS und Symfony erläutern einzelne technische Verfahren. Die Auswahlkriterien und Beispielabläufe sind eine fachliche Einordnung. Quellen geprüft am 14. Oktober 2026.