EDI mit Kundenshop-Systemen

Getreu dem Vorbild Amazon entdecken marktbestimmende Handelspartner zunehmend den Endkunden als Zielgruppe zur Erschließung neuer Umsatzfelder. 

Bei der Anbindung als Lieferant an die Bestellplattform eines Handelskunden geht es jedoch längst nicht mehr alleine um die bloße Verarbeitung von Bestellungen, die über einen Onlineshop generiert werden, sondern um eine möglichst ganzheitliche Integration aller verfügbaren Daten und Prozesse.

Eine konsistente Datenbasis über alle Geschäftsprozesse hinweg stellt wichtige Informationen rund um die angebotenen Produkte zur Verfügung und ermöglicht somit eine nahtlose Abwicklung der Bestellungen im Onlineshop. Durch die Verknüpfung des Onlineshops mit ERP- und CRM-Systemen werden die Prozesse vereinfacht und Fehler vermieden. Die Integration vom Kunden betriebener Onlineshops in bestehende IT-Infrastrukturen wird somit zunehmend zu einem wichtigen Erfolgsfaktor im digitalen Vertrieb.

Moderne OnlineOrder-Plattformen großer Handelskonzerne dienen mittlerweile als multidimensionale Vertriebsplattform, auf der Nutzer/Lieferanten sowohl vor- als auch nachgelagerte Prozesse für die Interaktion mit dem Endkunden eigenständig vornehmen. Auf Plattformebene geht es oftmals um vielschichtige Anforderungen, die zu einem großen Teil über herkömmliche EDI-Prozesse abgebildet werden können, für die Umsetzung einer Vielzahl von Mechanismen ist der reine EDI-Datenaustausch allerdings nicht ausreichend.

Für Lieferanten gilt es, bei der Anbindung umfangreiche Prozessanforderungen zu berücksichtigen, die aus den jeweiligen Vertragswerken nicht immer auf den ersten Blick klar ersichtlich sind.

Generell folgt der Ansatz auf Kundenseite einem klaren Modell:

Bei all diesen Szenarien handelt es sich fast immer um eine Kopie des Amazon-Modells. Aus Sicht des Lieferanten ergeben sich jedoch eine Vielzahl an kunden- und plattformspezifischen Anforderungen, die einer genauen Analyse bedürfen um daraus eine nachhaltige Implementierungs-Strategie ableiten zu können, die für den Lieferanten die Integration unterschiedlicher Plattformkonstrukte ermöglicht.

Aktuelle Projekte unserer Kunden zeigen, dass sich die unterschiedlichen Anforderungen von Endkunden Shop-Systemen oder Vertriebsplattformen in zwei grundsätzliche Kategorien gliedern lassen: dateibasierte Anbindungen und Anbindungsformen, die auf Basis einer heterogenen API-Definition basieren.

Obwohl es Ansätze gibt, API-Integrationen – z.B. via REST/JSON API – zu standardisieren, sind diese Anbindungen momentan noch anwendungsspezifisch, d.h. je nach verwendeter Plattform-Software variieren die zu integrierenden APIs. Ähnlich den unterschiedlichen EDI-Formaten weisen auch die jeweiligen Shop-spezifischen API-Dokumentationen unterschiedliche zugrunde liegende Integrations-Technologien auf. Für den Lieferanten bedeutet dies nicht unerhebliche Aufwände, da die proprietären APIs je Plattform nicht problemlos durch Standard-ERPs zu integrieren sind. Da sich das „Amazon Modell“ kundenseitig stetig steigender Beliebtheit erfreut, stellt sich die Frage, ob sich der hiermit verbundene Integrationsaufwand auch für solche Kunden lohnt, deren Geschäft noch nicht durch hohe Umsatzzahlen gekennzeichnet ist.

So hat sich für die Anbindung von API-basierten Online-Plattformen mittlerweile eine eigenständige IT-Industrie entwickelt, die als eine Art vorgelagertes ERP-System die auf unterschiedlichen API-Technologien basierenden Plattformen integriert (z.B. Tradebyte usw.). Diese AddOns übernehmen dabei die z.T. dialogbasierten Anwendungsszenarien und überführen die generierten Belege via Schnittstelle an das jeweilig im Einsatz befindliche ERP-System. Der Nachteil einer solchen Vorgehensweise besteht neben den kaufmännischen Aspekten darin, dass nicht alle Anbieter auch alle Plattformen unterstützen. Nicht weniger schwer wiegt die Tatsache, dass durch eine solche Vorgehensweise die firmeneigene Warenwirtschaft als „führende Instanz“ praktisch ausgehebelt wird und sich das Unternehmen somit in die Abhängigkeit eines weiteren zu betreibenden ERP-Systems begibt.

Die Softzoll Technologie ermöglicht die Integration multipler API´s durch ein eigenes anforderungsspezifisches Modul.

An dieser Stelle muss klar differenziert werden: für die Anbindung von ERP-Systemen ist eine API-Integration durchaus sinnvoll, da sie für den Anwender erhebliche Vorteile mit sich bringt. Diese nach innen gerichtete API-Integration führt sich allerdings selbst ad absurdum, sobald eine hohe Anzahl kundenspezifischer Online-ORDER-Plattformen auf Basis dieser heterogenen Technologie integriert werden. Nachhaltig ausgerichtete Vertriebsplattformen haben daher den Weg einer dateibasierten Integration der Lieferanten vorgesehen. 

Der Vorteil dieser Vorgehensweise besteht darin, dass auf Basis der im Standard der ERP-Systeme verfügbaren Schnittstellen die Anbindung jeder kundenspezifischen Vertriebsplattform so einfach wie die Anbindung eines zusätzlichen (EDI-) Partners realisiert werden kann. Für ein ERP-System, das bereits Kundenbestellungen in EDIFACT-, XML- und anderen Formaten verarbeitet, muss lediglich eine neue Partnerverbindung eingerichtet werden, um Bestelldaten aus den jeweiligen kundenspezifischen Plattformen zu empfangen.

Im Gegensatz zu API-basierenden Anbindungsmöglichkeiten wird hier auf eine dateibasierende Integration gesetzt. Intelligente Plattformen nutzen eine Anbindung via EDIFACT, XML, oder ASCII/TXT-Formaten, da diese Formate bereits bei einer Vielzahl von Lieferanten für die Kundenintegration im Einsatz sind. Für den Bereich der Artikelstammdaten bieten sich XML-basierende Formate an, die eine Übermittlung oder Referenzierung von Bildinformationen ebenso erlauben wie eine freiere Gestaltung der Klassifizierungs-Hierarchien, was beispielsweise bei EDIFACT-Formaten nicht der Fall ist.

Der primäre Vorteil dateibasierter Anbindung besteht in der Möglichkeit der ERP-seitigen Abbildung globaler Geschäftsprozesse. Gemeinsam mit der EDI-Technologie von Softzoll wird so eine prozessbezogene Konsolidierung der ERP-bürtigen Inhalte ermöglicht (syntaktisch & semantisch); das jeweilige Austauschformat der Daten ist hierbei unerheblich.

Aus strategischer Sicht sollte ein modernes EDI-System in der Lage sein, je Geschäftsprozess einen Datenpool zu generieren, dessen Quellen multi-applikationsfähig sind; gleichzeitig muss der generierte Output der genutzten EDI-Software sowohl die jeweiligen Anforderungen des ERP-Systems als auch die Voraussetzungen der kundenspezifischen Online-Plattform erfüllen.

Die Übermittlung von Stammdaten ist einer der ältesten Prozesse im EDI-Datenverkehr; die Hinterlegung der Stammdaten des Lieferanten im ERP-System des Kunden stellt die Grundlage moderner EDI-Interaktionen dar. Ausgehend von den Anfängen des Stammdatenaustausch in Form des SINFOS Datenpools – der zu Beginn noch mit proprietären ASCII-Formaten befüllt wurde – hat sich dieser Bereich mittlerweile zu einem eigenständigen Zweig innerhalb der EDI-Datenaustausche entwickelt. Dabei muss unterschieden werden zwischen der Übertragung reiner Artikelinformationen und der Bereitstellung aufbereiteter Stammdaten in Form von katalogspezifischen Strukturen.

Die Übermittlung von Artikelstammdaten in ihrer originären Form ist ein klassischer EDI-Prozess. Das UN/EDIFACT-Gremium bietet mit dem Nachrichtentyp PRICAT (= Price and Sales Catalogue) einen eigenständigen Nachrichtentyp. Im Grunde genommen bildet dieser EDIFACT-Nachrichtentyp die Grundlage eines darauffolgenden EDI-Dreiklangs des klassischen Handelswesens wie Bestellung (ORDERS), Lieferschein (DESADV) und Rechnung (INVOIC). Nachteil dieses Nachrichtentyps ist, dass die Menge an Informationen, die zur Beschreibung eines Artikels dient, erhebliche Größenordnungen annehmen kann. Aus diesem Grund hat dieser Nachrichtentyp keine weitflächige Verbreitung finden können, da die ERP-Systeme der Lieferanten oft nicht in der Lage sind, den von Kundenseite gewünschten Umfang an Artikelinformationen abzubilden. Hinzu kommt, dass z.B.in der Möbelindustrie eine Variantenvielfalt entsteht, in der ein Artikel (z.B. „Küche“) potenziell millionenfache Ausprägungen annehmen kann, die mit einer herkömmlichen Artikelbeschreibung nicht mehr zu umfassen ist. Ansätze mit produkt- bzw. branchenspezifischen Konfiguratoren haben sich bis dato nicht wirklich durchsetzen können.

Davon abzugrenzen ist die geforderte Bereitstellung von Artikeln des Lieferanten in einer Struktur, die außer den reinen Artikelinformationen auch der Artikeldarstellung bzw. der Hierarchisierung der OnlineOrder-Plattform Rechnung trägt. Auf technischer Ebene handelt es sich dabei überwiegend um XML-Strukturen, die bereits für den Import in das jeweilige Katalogsystem des Kunden aufbereitet werden müssen. Dabei sind die „reinen“ Artikelinformationen lediglich die Basis für weiterführende Anforderungen. Je nach Ausprägung der Ziel-Vertriebsplattform müssen nicht nur partnerspezifische XML-Strukturen implementiert werden, sondern die Anforderungen erweitern sich um zwei Aspekte, die im Vorfeld einer detaillierten Analyse zu unterziehen sind.

Damit der Endkunde in dem jeweilig angesteuerten OnlineOrder-System des Kunden zeitgemäße Funktionen wie Stichwortsuche und aussagekräftige Artikeldarstellungen erhalten kann, nutzen diese Vertriebsplattformen als Basis Stammdatenkataloge, die zunächst in die verschiedenen Systeme importiert werden müssen.

Diese Katalogstrukturen stellen im Kern zwei Anforderungen, die im Vorfeld der digitalisierten Übermittlung realisiert werden müssen:

Allein die Vorarbeiten zur Integration lieferantenbürtiger Daten können also bereits erhebliche Dimensionen annehmen. Vor Vertragsunterzeichnung sollten diese Aspekte daher bedacht, geplant und bepreist sein. Insbesondere die Klassifizierung von Artikeln ist für den klassischen EDI-Datenaustausch ohne Belang und sollte durch die dedizierte Verwendung einer möglichst vielseitigen Katalogmanagement-Software unterstützt werden. Die Übersendung der klassifizierten Artikelinformationen durch das EDI-Subsystem spielt in diesem Zusammenhang dann eine eher untergeordnete Rolle.