E-Commerce und ERP – die Herausforderungen im Zusammenwirken
Das Zusammenwirken von E-Commerce und ERP birgt in der Praxis häufig große Herausforderungen, die nachfolgend anhand verschiedener Prozesse verdeutlicht werden. Vom Orderprozess bis zum Finanzfluss sind die Eigenheiten im E-Commerce für viele ERP-Systeme schwierig abzubilden. Durch eine klare Zuordnung der Anforderungen auf die Zielsysteme und einem modular flexiblen Systemaufbau lassen sich elementare Probleme im E-Commerce nachhaltig lösen.
Das Thema E-Commerce sollte grundsätzlich nicht isoliert auf den Onlineshop zentriert betrachtet werden, da sich zahlreiche Prozesse über verschiedene Systeme und Schnittstellen bewegen. Bei systemübergreifenden Abläufen wird deutlich, welche Daten an bestimmten Stellen notwendig sind und wo Verbindungslücken existieren.
Datenanreicherungsprozess/Datenfluss
Der Datenfluss umfasst mehrere Bereiche. Einer der wichtigsten betrifft die Artikeldaten (Stammdaten) im E-Commerce. Aus dem ERP kommen zumeist nur Basis-Stammdaten wie Artikelnummer, EAN, Artikelname, Preis, MWST-Code, Bestand. Für E-Commerce ist das jedoch nicht ausreichend. In einem Erweiterungsprozess müssen die Artikeldaten, im E-Commerce „Content“ genannt, angereichert werden. Meist kommen die erweiterten Daten aus verschiedenen Quellen, da die Informationen und Attribute nicht in einem zentralen System vorhanden sind. Für Unternehmen ist an dieser Stelle ein PIM (Product Information Management)-System sinnvoll. Es zeigt sich allerdings in der
E-Commerce-Praxis, dass die Daten noch nicht für E-Commerce ausreichend sind. Weitere Informationskriterien für die Artikel sind z. B. Katalog, Kategorie, Bilder, Artikel-Attribute, technische Daten, Zubehör, Cross-Selling, Google Shopping Informationen (Taxonomie), Label für Google Ads (zur Topseller-Steuerung).
Orderprozess
Ausgangspunkt ist der Warenkorb im Onlineshop; über weitere Aktivitäten wie Verfügbarkeitsprüfung oder Risk- und Zahlungsartenprüfung wird der Orderprozess mit Daten angereichert. Diese stammen aus unterschiedlichen Systemen. Der Prozessablauf macht deutlich, dass neben dem ERP-Prozess parallel einige Aktivitäten wie z. B. Payment-Capture oder die Tracking-ID generiert und übertragen werden müssen. Dies sind Bereiche, die außerhalb vom Onlineshop laufen und angesteuert werden müssen, um final als fertige Bestellung den Status „versendet“ im Shop zu setzen.
Warenfluss
Im E-Commerce gibt es verschiedene Arten, wie die Ware zum Kunden gelangt. Daher empfiehlt es sich, diesen Prozess genauer zu beleuchten. Daraus abgeleitet sind verschiedene Systeme und Daten notwendig, um dies bestmöglich abzubilden.
Wird die Ware extern von einem Fulfillment-Dienstleister verwaltet, muss über die prozessuale Abwicklung und Übergabe von Daten intensiver nachgedacht werden. Das Zeitfenster beträgt häufig nur ein paar Stunden, in denen die Ware versandfertig gemacht werden muss. Daraus ergibt sich die Anforderung, einen effizienten Prozess über alle Beteiligten zu designen, der später in allen Systemen transparent nachvollzogen werden kann und final im Onlineshop mit Versandstatus und Tracking-ID ankommt.
Eine weitere Besonderheit ist der Order-Split, der eine höhere Professionalisierung von Logistik und Informationsmanagement erfordert. Die Bestellung wird in mehrere Teillieferungen gesplittet, um dem Kunden bei Lieferverzögerung einiger Artikel aus der Bestellung das ausgelobte Lieferzeitfenster zu gewährleisten.
Beim Streckengeschäft kann die Komplexität noch gesteigert werden. Hier werden die Artikel von externen Partnern separat verschickt, da meist bei Sondersortimenten eine eigene Lagerhaltung kaufmännisch nicht sinnvoll erscheint.
Sollten nun alle oben dargestellten Varianten kombiniert vorkommen, bedeutet dies maximale Komplexität im Prozess- und Informations-Handling für alle Beteiligten. Im E-Commerce müssen diese Prozesse sehr gut durchgeplant werden, da aufgrund des hohen Transaktionsvolumens manuelle Eingriffe zu aufwendig und fehlerintensiv sind.
Bild 1: Orderprozess.
Finanzfluss
Durch zahlreiche Zahlungsarten wie Paypal, Sofortüberweisung oder Kreditkarte kommt für Unternehmen, die meist im Endkundengeschäft noch nicht tätig waren, eine ganz neue Erfahrung hinzu. Im ERP-System sind diese Zahlungsarten nicht etabliert und z. B. Paypal hat die Besonderheit, dass bei der Auszahlung pro Bestellsumme bereits die Paypal-Provision abgezogen wird. Dies stellt das ERP-System spätestens beim Ausziffern der Debitoren-OPOS vor eine Herausforderung. Anschließend hat die Fibu eine weitere Schwierigkeit, da die Auszahlung als Sammelbetrag bei Paypal angefordert werden muss und die krummen Beträge (abzüglich Provision) buchhalterisch korrekt verarbeitet werden müssen. Zahlungsrückbuchungen durch Kulanzgutschriften oder Teil-Retouren erhöhen den Zusatzaufwand.
Das ERP-System hat noch eine weitere Problematik: Paypal prozessiert auf Basis des Unique-Key: E-Mail Adresse. Das wird häufig dann ein Problem, wenn Unternehmen aufgrund des eher kleinen E-Commerce-Anteils am Gesamtumsatz die Daten nur als Saldo-Daten täglich ins ERP-System auf den Kunden „online“ entsorgt werden, um das Einzel-Order-Datenvolumen nicht komplett im ERP-System halten zu müssen. In diesem kumulativen Datensatz sind die einzelnen E-Mail-Adressen der Kunden nicht enthalten, was das oben dargestellte Paypal-Mapping-Problem zusätzlich verursacht. Um diese Probleme zu lösen, werden 3rd-Party Tools eingesetzt, die Daten veredeln, bevor diese ins ERP-System gelangen.
Verkauf über Amazon Marktplatz
Für das ERP-System ist der Verkauf über Amazon Marktplatz bereits eine Herausforderung. Die Unterschiede zwischen den möglichen Versandarten FBA (Lieferung durch die Amazon Logistik) und FBM (Lieferung durch den Seller/Verkäufer) fordern eine Etablierung von zwei separaten Prozessen. Die FBA-Bestellungen dürfen selbst nicht verschickt werden, sind aber mit Erlös zu buchen. In der 14-tägigen Amazon-Abrechnung für den Verkäufer sind beide Versandarten kumuliert enthalten (FBA und FBM). Hinzu kommt, dass der Ausschüttungsbetrag gekürzt wurde, um die Amazon-Provision (in der Regel 15 %) und Gebühren und ein Einbehalt von Kunden, die per Rechnung bei Amazon bezahlen. In der ERP-Finanzbuchhaltung sind somit diese speziellen Prozesse ausreichend abzubilden.
Analyse der Anforderungen und Aufgabentrennung
Die Anforderungen werden strukturiert nach Themenbereich gesammelt und priorisiert. Hierbei ist darauf zu achten, bereits eine grobe Zuordnung zu den Funktionsbereichen durchzuführen. Nicht alle E-Commerce-Themen werden funktional vom Onlineshop-System bedient, sondern von weiteren Systemen oder 3rd-Party Tools. Für eine spätere Auswahl der Systeme ist die Kategorisierung elementar. Auch gehört das Mengengerüst (Anzahl der Artikel (SKU), Anzahl der Bestellungen etc.) zur Analyse. Anhand dessen lassen sich die verschiedenen Systeme und Architekturen besser bewerten.
Sonderthema: B2B
Besondere Anforderungen stellt das B2B-Geschäft im E-Commerce dar. Im Gegensatz zum B2C-Geschäft haben die Business-Kunden meist eigene Konditionsvereinbarungen, die im ERP-System hinterlegt sind und bei den Bestellungen Anwendung finden. Eine Preisabfrage und spezielle Konditionen stellt eine besondere Herausforderung bei der Echtzeit-Preisfindung beim Onlineshop dar. Auch der Zugriff auf beschränkte Sortimente je nach Händlerstatus schafft zusätzliche Komplexität.
Schnittstellen
Bei der Aufnahme sind die Schnittstellen zu notwendigen Systemen ein wichtiges Auswahlkriterium, um eine reibungslose Inbetriebnahme zu gewährleisten. Schnittstellen zum ERP-System, PIM, PSP (Payment-Service-Provider), 3rd-Party Tools oder Marktplätze wie Amazon sind wichtig und unterscheiden sich von System zu System. Bei der Auswahl der Onlineshops trennt sich hier die Spreu vom Weizen und wirkt direkt auf eine kurze Inbetriebnahmedauer.
Modularisierte Systemlandschaft
Die Orchestrierung der Systeme nach ihren originären Funktionsbereichen führt zu einer idealtypischen Systemlandschaft im E-Commerce-Kontext. Im Kontra-Fall werden die Systeme so stark angepasst, dass sie die Releasefähigkeit von ERP-System oder Onlineshop gefährden. Ein wesentlich besserer Ansatz ist es, die Anforderungen zu sammeln und clustern, die nicht durch das ERP-System oder Onlineshop unterstützt werden. Als Brückenlösung lässt sich ein Middleware-System aufbauen, um diese Spezialaufgaben zu lösen. Besonders bei großen ERP-Anwendungen, die wenig Flexibilität und Schnittstellenoffenzeit bieten, kann das ein guter Lösungsansatz sein.
Bild 2: Systemlandschaft-Skizze.
Die Middleware-Systeme sind in der Regel webbasiert und somit schnell und flexibel anzupassen. Durch ihre offene Architektur lassen sich solche Systeme sehr flexibel per Schnittstelle in jeglicher Form anbinden. Ebenso ist es möglich, Daten zu konvertieren/transformieren, um beispielsweise für den Weitertransport in die E-Commerce-Schicht eine optimale Datenanbindung zu gewährleisten. Die Auslagerung dieser Prozesse und Datenversorgung auf die Middleware entspannt die Komplexität bei den restlichen IT-Komponenten und schafft eine neue Flexibilität im Systemcluster.
Je nach Middleware-Lösung verfügen diese über zahlreiche Standardschnittstellen zu ERP, Onlineshop, Payment und 3rd-Party Tools, Marktplätzen und können strategisch als Data-Hub zentral platziert werden. Durch konfigurierte Prozesse, die per Regelwerk zeitgesteuert ablaufen, lassen sich diverse Betriebsmodelle flexibler zwischen ERP und Onlineshop darstellen. Beispielsweise können Bestände dynamisch für Verkaufskanäle gesteuert werden. Wenn mehrere Onlineshops und mehrere Marktplätze betrieben werden, greifen alle Kanäle auf den selbigen physischen Bestand zurück. Bei geringer Verfügbarkeit muss die Middleware auf Basis definierter Regelwerke entscheiden, welcher Verkaufskanal bei diesem Artikel die höchste Rohmarge erzielt und weist in Folge mehr Bestand diesem Kanal zu. Andere Verkaufskanäle werden entsprechend bestandsmäßig reduziert oder gehen temporär aus dem Angebot. Diese Prozesse gehören nicht zum Repertoire von ERP-Systemen oder Onlineshops und sollten auf Middleware-Systeme zum Beispiel als Speziallösung ausgelagert werden.
Ein weiterer Vorteil von Middleware-Lösungen ist es, als Data-Hub zu fungieren. Wie eine Art Mehrfachsteckdose können mehrere Onlineshops oder diverse Systeme angedockt werden, um z. B. im Rahmen der Internationalisierung alle notwendigen Datenverbindungen zum Austausch aus der „Steckdose“ zur Verfügung zu stellen. Die Logik-Schicht wird somit stärker in die Middleware als Daten-Drehscheibe gelegt, um die Prozesse in alle Richtungen zu spielen. Das entlastet das ERP-System von Komplexität und schont zudem die ERP-Performance. Ein häufiger Kardinalfehler ist es, Requests aus dem Onlineshop ungepuffert mittels Direktabfrage auf das ERP-System (z. B. bei Preisabfragen oder Bestandsabfragen) zuzulassen. Das Hochfrequenz-Onlineshop-System bringt dadurch das ERP-System zwangsläufig in Performance-Probleme. Dies lässt sich einfacher lösen, wenn in definierten Versorgungsintervallen (Full- und Inkrementell) das ERP-System die Middleware versorgt und alle hochfrequenten Abfragen vom Onlineshop in Richtung Middleware gehen.
Durch diese Systemarchitektur lassen sich durchaus unterschiedliche Shopsysteme im Mischbetrieb fahren, da die Middleware als zentraler Data-Hub alles verwaltet. Es lässt sich sogar auf Streckenlieferanten erweitern, da über Regelwerke definiert wird, ob das Eigenlager oder Fulfillment-Dienstleister (externe Logistik) ausrechend Bestand haben oder auf einen Streckenlieferanten geroutet werden soll. Dies macht auch im internationalen Kontext mit Mehrlagerstandorten durchaus Sinn.
Einen weiteren Vorteil hat dieser Lösungsansatz. Dadurch, dass der Aufbau modular erfolgt, lassen sich später einzelne Komponenten leicht austauschen oder auf Micro-Services umstellen, ohne das Gesamtkonstrukt mit viel Aufwand komplett umzubauen.
Fazit
Eine modular-flexible Systemlandschaft ist für E-Commerce ein Erfolgsfaktor, da sich Onlineshop-Systeme, 3rd-Party Tools und Schnittstellen in kürzeren Zyklen verändern und neue Anforderungen realisiert werden müssen, als dies im ERP-Bereich stattfindet. So bleibt die ERP-Schicht weitestgehend von diesen Einflüssen unberührt und bietet eine agile Reaktionsschicht.
Dipl.-Betriebswirt (FH) Alexander Riezler ist Senior Consultant und Geschäftsführer der QUANT Consulting, die Unternehmen bei ERP, E-Commerce und Digitalisierungsprojekten unterstützt. Der Autor ist seit über 24 Jahren in diesem Bereich tätig und hat in zahlreichen Projekten für Mittelstand bis Großunternehmen beraten.
Alexander Riezler
QUANT Consulting GmbH
87435 Kempten
E-Mail: kontakt@quant-consulting.de
www.quant-consulting.de
2016
Meilenstein 1
2017
Meilenstein 2
2017
2018
Meilenstein 3