Datenaustausch mit dem externen Lager

Produzenten wollen ihre Produkte weltweit verkaufen und gleichzeitig von überall Rohstoffe oder Komponenten beziehen. Dabei greifen Unternehmen auch auf externe Logistikdienstleister mit Schwerpunkt auf Transport und Lagerung zurück. Die Verwaltung solcher ‚externen‘ Lager erfolgt in der Regel im IT-System des Auftraggebers. Auf Basis dieser Daten läuft die überregionale Distribution ab, wird der Bestand bestimmt und Warenversandaufträge an das betreffende Lager versendet. Entsprechend muss die IT-Infrastruktur des Dienstleisters an die Systeme des anweisenden Unternehmens angebunden werden.

Bild: hartung consult

Aufgrund der Komplexität der Distributionsanforderungen führen Logistikdienstleistern oder ‚3rd Party Logistics‘ (3PL) für produzierende Unternehmen neben Transport und Lagerung oft auch weitere Aufgaben wie Zollabfertigung oder Frachtweiterleitung durch. Manchmal nehmen sie auch Bestellungen auf und bearbeiten Aufträge, führen die Endmontage von Produkten durch, verpacken und etikettieren die Waren oder übernehmen die Abwickelung von Retouren und Reparaturen. Der 3PL als externes Warenlager muss entsprechend an das Warenlager- beziehungsweise Enterprise Resource Planning System (ERP) des anweisenden Unternehmens angebunden werden. Diese müssen an das 3PL-System Warenversandaufträge versenden, Rückmeldungen etwa zu Seriennummern der Waren empfangen und den Bestand bei Warenaus- und -eingang auf Seiten des Lagerverwaltungssystems aktuell halten.

Wenn der 3PL-Anbieter auch als Distributor agiert, gilt es zusätzlich die Materialdaten bei Änderungen oder Ergänzungen zu aktualisieren. Das unternehmensseitige Lagerverwaltungssystem und das Verwaltungssystems des Dienstleisters sind jedoch zwei unabhängige Softwaresysteme. Auch wenn es sich dabei um identische ERP-Lösungen handelt, sind diese mit hoher Wahrscheinlichkeit unterschiedlich konfiguriert. Um den Austausch der Daten zwischen Unternehmen und Dienstleistern unabhängig von der verwendeten Software und Konfiguration zu gestatten, bedarf es einer einheitlichen Datenaustauschstruktur. Neben den aus dem SAP-Umfeld bekannten Intermediate Document-Datenstrukturen (IDoc) hat sich dafür der branchenübergreifender Edifact-Standard für den Datenaustausch oder ‚Electronic Data Interchange‘ (EDI) etabliert. Der weltweit eingesetzte EDI Standard beschreibt eine Fülle von sogenannten EDI-Transaktionen, etwa die Auftragsübermittlung einer Warenlieferung

Autausch über Standard-Formate

Berichte und Nachrichten aus Bestellungen, Rechnungen, Lieferavis und weitere Dokumente können so aus IT-Datenbanken generiert und auf elektronischem Weg an den Geschäftspartner versendet werden. Für den Datenaustausch mit einem 3PL sind insbesondere die EDI-Transaktionen 846 – Inventory Advice, 940 – Warehouse Shipping Order, 944 – Warehouse Stock Transfer Receipt Advice und 945 – Warehouse Shipping Advice zu nennen. Über sie kann der Warenbestand erfasst und aktualisiert werden, und Versandaufträge mit Warenaus- und -eingangsbuchung erfolgen. Die Auswahl der konkret zu verwendenden EDI-Transaktionen ist im Rahmen einer technischen Spezifikation zu bestimmen. Für den Einsatz in der Kommunikation mit großen Unternehmen bietet sich dabei aufgrund des häufigen Einsatzes von Lagerverwaltungssystemen mit SAP-Schnittstellen IDoc als Datenstruktur für den Informationsaustausch an. Ein IDoc besteht aus einer Kopfzeile, mehreren zusammenhängenden Datensegmenten und Statussätzen.

IDocs eignen sich oftmals auch für die Datenübermittlung für EDI-Transaktionen, da sie sich im SAP über Standardfunktionen erzeugen und importieren lassen. Die zu übermittelnden Daten müssen jedoch selektiert werden, um festzulegen, welche Informationen von welchem System übernommen werden. Dazu ist eine gründliche Analyse und Abstimmung zwischen den Geschäftspartnern erforderlich. In Verbindung mit einem Datenkonvertierungs System kann dann die IDoc-Struktur in das EDI-Format konvertiert und an den Partner übermittelt werden. Für die Auswahl des IDoc-Typs zu den EDI-Transaktionen gibt es inoffizielle Empfehlungen; wichtig ist jedoch, dass die Daten und Übermittlungsstrukturen in den EDI-Transaktionen definiert werden.

Herausforderung Spezifikation

Die Herausforderung besteht also in der Bestimmung der Daten für die jeweilige EDI-Transaktion. Dazu bedarf es insgesamt folgender Projektschritte:

  1. Funktionelle Spezifikation: Welche Daten müssen wann kommuniziert werden, welche Szenarien sind zu berücksichtigen
  2. Technischen Spezifikation: Welche Ein- und Ausgabeformate bzw. -strukturen sind geeignet, welche Schnittstellen sind zu verwenden, wann muss wann was ausgeführt werden
  3. Implementierung und Verifikationstests

Die Bestimmung der funktionellen Spezifikation verlangt nicht nur ein tiefes Fachwissen von Lagerverwaltungssystem, EDI und 3PL-Prozessen, sondern vor allem die Kommunikation mit Experten aus den beteiligten Bereichen, wie Verkauf und Lagerverwaltung. Nur dieser interdisziplinäre Austausch ermöglicht es die Spezifikation möglichst lückenlos zu schließen und so eine hinreichende Spezifikation für die Implementierung zu erlangen. In vielen 3PL-Anbindungsprojekten wird der interdisziplinäre Austausch gescheut, unzureichend behandelt, oder nicht vom Berater begleitet. Dies führt oftmals dazu, dass die nicht erfassten Spezifikationen zu Problemen in der Produktivphase und damit verbundenen kostspieligen Nacharbeiten führen.