Ein B2B-Onlineshop und das ERP-System sind selten zwei voneinander unabhängige Systeme. Preise, Kundenkonditionen, Bestände, Aufträge und Lieferinformationen entstehen meist nicht im Shop, werden dort aber benötigt. Gleichzeitig erzeugt der Onlineshop neue Bestellungen und Kundendaten, die zurück in die internen Prozesse fließen müssen. Entscheidend ist deshalb nicht, möglichst viele Daten zwischen beiden Systemen auszutauschen. Entscheidend ist, welches System für welche Information verantwortlich ist und wann eine Synchronisation tatsächlich notwendig wird.
Im B2C lassen sich viele Prozesse relativ standardisiert abbilden. Ein Produkt besitzt einen Verkaufspreis, der Bestand gilt für alle Kunden und nach der Bestellung beginnt ein weitgehend einheitlicher Fulfillment-Prozess. Im B2B sieht das häufig anders aus. Kunden erhalten individuelle Preise, Rabatte oder Sortimente. Zahlungsbedingungen unterscheiden sich und Bestellungen müssen möglicherweise bestimmten Debitoren, Kostenstellen oder Lieferadressen zugeordnet werden.
Damit wird das ERP zu einem zentralen Bestandteil des digitalen Vertriebs. Dort liegen bereits viele Informationen, die der Onlineshop benötigt, um einen Geschäftskunden korrekt zu bedienen. Gleichzeitig darf das Shopsystem nicht zum zweiten ERP ausgebaut werden. Werden dieselben Geschäftsregeln an mehreren Stellen gepflegt, entstehen schnell widersprüchliche Daten und unnötiger Wartungsaufwand.
Genau deshalb sollte die Integration bereits bei der Konzeption einer E-Commerce-Plattform mitgedacht werden. Die wichtigste Frage lautet nicht, welche Schnittstelle technisch möglich ist. Zuerst muss geklärt werden, wo eine Information entsteht, welches System sie verändern darf und welche anderen Systeme sie lediglich konsumieren.
Bei einer ERP-Shop-Integration entsteht schnell die Vorstellung, beide Systeme müssten permanent denselben Datenbestand besitzen. In der Praxis ist das weder notwendig noch sinnvoll.
Ein ERP verwaltet beispielsweise Materialnummern, Bestände, Einkaufspreise, Buchungsinformationen und Kundenstammdaten. Ein Shopsystem benötigt davon nur den Teil, der für digitale Verkaufsprozesse relevant ist. Gleichzeitig enthält ein Shop Informationen, die im ERP möglicherweise überhaupt keine Funktion haben, etwa Navigationsstrukturen, SEO-Inhalte oder Seitenelemente.
Eine sinnvolle Systemarchitektur trennt deshalb drei Kategorien:
Diese Abgrenzung klingt zunächst einfach, wird aber in Projekten schnell komplex. Besonders dann, wenn über Jahre individuelle Logiken im ERP entstanden sind oder zusätzliche Systeme wie PIM, CRM und Middleware beteiligt sind. Schon die Anforderungen im B2B-E-Commerce unterscheiden sich deutlich von einfachen B2C-Prozessen. Entsprechend reicht es nicht aus, eine allgemeine Standardschnittstelle einzurichten und anschließend davon auszugehen, dass alle relevanten Prozesse abgedeckt sind.
Artikelnummern, grundlegende Bezeichnungen, Einheiten, Verpackungsgrößen und andere kaufmännisch relevante Produktinformationen werden häufig im ERP angelegt. Diese Daten bilden die Grundlage dafür, dass ein Produkt im Shop eindeutig identifiziert und später korrekt bestellt werden kann.
Die Herausforderung entsteht dann, wenn kaufmännische Stammdaten mit vertrieblichen Produktinformationen vermischt werden. Ein ERP kann problemlos verwalten, dass ein Artikel unter einer bestimmten Nummer geführt und in einer bestimmten Einheit verkauft wird. Für eine gute Produktdarstellung benötigt der Shop jedoch häufig wesentlich mehr: ausführliche Beschreibungen, technische Merkmale, Dokumente, Bilder, Videos, Übersetzungen und Filterattribute.
Diese Informationen direkt im ERP zu verwalten, ist bei kleinen Sortimenten möglicherweise noch praktikabel. Mit wachsendem Sortiment, mehreren Vertriebskanälen oder vielen technischen Attributen wird es zunehmend unübersichtlich. Dann sollte geprüft werden, ob ein PIM als zusätzliche Datenquelle notwendig ist. Ein strukturiertes Produktdatenmanagement im E-Commerce verhindert, dass dieselben Informationen in ERP, Shop, Excel-Dateien und weiteren Systemen parallel gepflegt werden.
Für die Schnittstellenarchitektur bedeutet das: Das ERP bleibt beispielsweise führend für Artikelnummer, Verkaufseinheit und kaufmännischen Status. Das PIM liefert angereicherte Produktinformationen. Der Shop führt diese Daten für den Kunden zusammen.
Die Preislogik gehört zu den Bereichen, in denen B2B-Projekte besonders schnell komplex werden. Während im B2C meist ein allgemein gültiger Preis angezeigt wird, können im B2B kundenspezifische Konditionen, Staffelpreise, Aktionspreise, Rahmenverträge oder individuell vereinbarte Rabatte zusammenkommen.
In vielen Unternehmen liegt diese Logik bereits im ERP. Dort ist hinterlegt, welcher Kunde zu welcher Konditionsgruppe gehört und welche Preise für bestimmte Produkte gelten. Werden diese Regeln zusätzlich im Shopsystem nachgebaut, existieren zwei Stellen, an denen Preislogiken gepflegt und verändert werden können.
Das erhöht nicht nur den Aufwand. Es entsteht auch ein konkretes Geschäftsrisiko. Ändert der Vertrieb eine Kondition im ERP, muss dieselbe Änderung zuverlässig im Shop ankommen. Passiert das nicht, sieht der Kunde online möglicherweise einen anderen Preis als bei einer Bestellung über den Innendienst.
Deshalb sollte früh entschieden werden, wie die Preisermittlung technisch erfolgt. Preise können regelmäßig aus dem ERP an den Shop übertragen werden. Alternativ kann der Shop Preise bei Bedarf direkt aus dem ERP oder einer zwischengeschalteten Preis-Engine abrufen. Welcher Ansatz passt, hängt von Datenmenge, Geschwindigkeit, Komplexität der Preislogik und technischer Infrastruktur ab.
Wichtiger als die konkrete Technologie ist die organisatorische Regel: Es darf nur eine führende Preislogik geben.
Auch Kundendaten bewegen sich in beide Richtungen. Bestehende Geschäftskunden sind meist bereits als Debitor im ERP angelegt. Dort befinden sich Rechnungsadressen, Lieferadressen, Zahlungsbedingungen, Kundennummern oder Vertriebszuordnungen. Diese Informationen benötigt der Shop spätestens nach dem Login.
Gleichzeitig entstehen im Onlineshop neue Daten. Kunden legen zusätzliche Benutzer an, ändern Ansprechpartner oder beantragen einen Zugang. Bei manchen Geschäftsmodellen können sich Interessenten sogar vollständig digital registrieren und anschließend als Neukunden angelegt werden.
Hier reicht eine rein technische Synchronisation nicht aus. Es muss geklärt werden, welche Änderungen ein Shop-Nutzer selbst durchführen darf und welche Daten intern freigegeben werden müssen.
Eine neue Lieferadresse könnte beispielsweise sofort im Shop gespeichert werden, aber erst nach Prüfung als offizielle Adresse ins ERP gelangen. Ähnliches gilt für Firmenname, Rechnungsanschrift oder steuerlich relevante Informationen. Werden solche Änderungen ungeprüft synchronisiert, kann eine komfortable Self-Service-Funktion plötzlich Stammdaten verändern, die auch für Buchhaltung und Auftragsbearbeitung genutzt werden.
Die Datenhoheit sollte deshalb für jedes relevante Feld definiert werden. Nicht jede Information muss automatisch in beide Richtungen überschrieben werden.
Kaum eine Information beeinflusst die Kaufentscheidung so unmittelbar wie die Verfügbarkeit eines Produkts. Gleichzeitig gehört der Lagerbestand zu den Daten, die sich besonders häufig verändern.
Wird der Bestand nur einmal täglich aus dem ERP übertragen, kann der im Shop angezeigte Wert bereits kurz danach veraltet sein. Ob das problematisch ist, hängt stark vom Geschäftsmodell ab. Bei Produkten mit hohen Beständen und niedriger Umschlagshäufigkeit kann eine zeitversetzte Synchronisation vollkommen ausreichend sein. Bei knappen oder schnell verkauften Artikeln kann dieselbe Architektur zu Fehlbestellungen führen.
Dabei muss nicht zwingend der exakte Lagerbestand angezeigt werden. Für viele B2B-Shops reicht eine Information wie „sofort verfügbar“, „verfügbar in fünf Werktagen“ oder „Liefertermin auf Anfrage“. Entscheidend ist, dass die zugrunde liegende Aussage verlässlich ist.
Zusätzlich muss definiert werden, welcher Bestand überhaupt relevant ist. Unternehmen mit mehreren Lagern, Niederlassungen oder internationalen Gesellschaften können nicht einfach einen einzigen Gesamtbestand ausspielen. Der Shop muss wissen, welcher Standort einen bestimmten Kunden beliefert und welche Mengen tatsächlich für den digitalen Vertrieb verfügbar sind.
Die notwendige Synchronisationsfrequenz sollte deshalb nicht pauschal für alle Daten festgelegt werden. Preise können andere Aktualisierungsintervalle benötigen als Verfügbarkeiten, Produktbeschreibungen oder Kundenstammdaten.
Während viele Informationen vom ERP in Richtung Shop laufen, bewegt sich die Bestellung in die entgegengesetzte Richtung. Sobald ein Kunde online bestellt, muss daraus ein Datensatz entstehen, der im ERP möglichst ohne manuelle Nachbearbeitung weiterverarbeitet werden kann.
Dazu gehört deutlich mehr als eine Liste der gekauften Artikel. Je nach Prozess müssen unter anderem folgende Informationen übermittelt werden:
Je stärker der digitale Vertrieb wachsen soll, desto problematischer wird jede manuelle Zwischenstufe. Wenn Onlinebestellungen zunächst per E-Mail beim Innendienst ankommen und dort erneut in das ERP eingegeben werden, wurde der Bestellprozess lediglich digital begonnen. Der eigentliche interne Aufwand bleibt bestehen.
Bei der Auswahl einer passenden B2B-Commerce-Lösung sollte deshalb nicht nur geprüft werden, welche Funktionen der Kunde im Frontend sieht. Ebenso relevant ist, wie sauber Bestellungen und Geschäftsprozesse mit der bestehenden ERP-Landschaft verbunden werden können.
Mit der Übertragung der Bestellung ist die Integration nicht abgeschlossen. Aus Kundensicht beginnt jetzt ein mindestens ebenso wichtiger Teil des Prozesses.
Nach der Bestellung möchte der Einkäufer wissen, ob der Auftrag verarbeitet wurde, wann geliefert wird und ob Rechnungen oder andere Dokumente verfügbar sind. Diese Informationen entstehen normalerweise nicht im Shop. Sie werden während der Auftragsbearbeitung im ERP oder in angeschlossenen Logistik- und Dokumentensystemen erzeugt.
Wer einen echten Self-Service-Bereich anbieten möchte, muss diese Daten wieder in den Shop oder das Kundenportal zurückführen. Dadurch können Kunden viele Standardanfragen selbst erledigen, ohne beim Vertriebsinnendienst nach dem Auftragsstatus oder einer Rechnung fragen zu müssen.
Gerade an dieser Stelle zeigt sich der Unterschied zwischen einem reinen Bestellformular und einer umfassenden digitalen Vertriebsplattform. Ein leistungsfähiger B2B-Shop begleitet den Kunden nicht nur bis zum Absenden der Bestellung, sondern bildet auch relevante Informationen nach dem Kauf ab.
In Integrationsprojekten fällt schnell die Forderung, sämtliche Informationen müssten in Echtzeit synchronisiert werden. Technisch ist das heute in vielen Bereichen möglich. Wirtschaftlich und fachlich ist es aber nicht automatisch sinnvoll.
Ein geänderter Produkttext muss selten innerhalb weniger Sekunden im Shop erscheinen. Bei Lagerbeständen oder kundenindividuellen Preisen kann eine schnelle Aktualisierung dagegen entscheidend sein. Die Anforderungen sollten deshalb pro Datenart definiert werden.
Grundsätzlich lassen sich drei Abstufungen unterscheiden:
Echtzeit oder nahezu Echtzeit: geeignet für Informationen, deren Veraltung unmittelbar zu falschen Bestellungen oder Preisen führen kann.
Regelmäßige Synchronisation: sinnvoll für Daten, die aktuell sein müssen, sich aber nicht permanent ändern.
Ereignisbezogene Übertragung: geeignet für Vorgänge, die durch eine konkrete Aktion ausgelöst werden, beispielsweise eine neue Bestellung oder eine Kundenregistrierung.
Damit lässt sich die Integrationsarchitektur wesentlich gezielter planen. Ein System, das jede Änderung sofort an alle beteiligten Anwendungen verteilt, ist nicht automatisch besser. Es kann unnötige technische Komplexität erzeugen, ohne einen entsprechenden Geschäftswert zu schaffen.
Viele Probleme in ERP-Shop-Projekten entstehen nicht durch fehlende Schnittstellen, sondern durch fehlende Verantwortlichkeiten. Wenn dieselbe Information an mehreren Stellen verändert werden kann, wird früher oder später unklar, welcher Datenbestand korrekt ist.
Vor der technischen Umsetzung sollte deshalb eine Datenmatrix entstehen. Für jede relevante Datenart wird festgelegt:
Diese Festlegung schafft gleichzeitig eine Grundlage für die Schnittstellenentwicklung. Entwickler müssen nicht während der Implementierung entscheiden, welches System im Zweifel Vorrang hat. Fachbereiche wissen, wo Daten gepflegt werden müssen. Und spätere Erweiterungen lassen sich leichter einordnen.
Die Verbindung zwischen B2B-Onlineshop und ERP ist keine reine Schnittstellenaufgabe. Bevor Daten übertragen werden, muss geklärt sein, welches System für welche Information verantwortlich ist und welchen Zweck die Synchronisation erfüllt.
Artikelstammdaten, Preise, Kundenkonditionen und Bestände kommen häufig aus dem ERP. Bestellungen fließen vom Shop zurück in die kaufmännischen Prozesse. Auftragsstatus, Lieferinformationen und Belege müssen anschließend wieder für den Kunden verfügbar gemacht werden. Zusätzliche Systeme wie PIM oder CRM erweitern diese Architektur und sollten jeweils dort eingesetzt werden, wo sie tatsächlich eine eigene fachliche Aufgabe übernehmen.
Nicht jede Information muss dabei in Echtzeit verfügbar sein und nicht jeder Datenbestand gehört in beide Systeme. Eine saubere Architektur reduziert doppelte Datenpflege, manuelle Übertragungen und widersprüchliche Informationen.
Die entscheidende Vorarbeit besteht deshalb darin, Datenflüsse und Verantwortlichkeiten zu dokumentieren, bevor die eigentliche Schnittstelle entwickelt wird. Erst wenn klar ist, welches System die führende Quelle für welche Daten ist, kann aus ERP und Onlineshop ein durchgängiger digitaler Vertriebsprozess entstehen.
Jenny Bocksberger verantwortet bei steireif das Partnermanagement und sorgt dafür, dass aus Kontakten echte, funktionierende Zusammenarbeit entsteht. Sie verbindet Struktur mit Gespür für Menschen und baut belastbare Partnerschaften auf, hält Fäden zusammen und stellt sicher, dass beide Seiten wissen, woran sie sind.
Partnermanagement
Alexander Steireif GmbH
