Klärung der Grundlagen:

Anfrage: In der Anfrage, egal ob vom Unternehmen selbst oder von einem Kunden/Lieferanten initiiert, muss klar werden, welche Daten in welcher Form auf welchem Übertragungsweg erwartet werden. Nehmen wir als Beispiel eine elektronische Rechnung im Format EDIFACT INVOIC, die per AS2 gesendet werden soll.

Quelle: Um gewünschtes Datenformat herzustellen, muss zunächst bekannt sein, wo sich die notwendigen Rechnungsinformationen im eigenen Unternehmen befinden. In der Regel wird dies eine Datenbank sein, im IBM i-Umfeld vermutlich DB2. Zudem muss geprüft werden, ob möglicherweise schon eine Lösung für die Kommunikation intern vorhanden ist. Bleiben wir beim Beispiel: Die Rechnungsinformationen stehen in der DB2, für das Übertragungsprotokoll AS2 soll eine neue EDI-Standardlösung eingesetzt werden.

Ziel: Entweder das Unternehmen selbst oder der Kunde/Lieferant wird vorgeben, welches Datenformat erwartet wird, in unserem Beispiel EDIFACT INVOIC. Hierzu muss es noch Details geben wie Version/Verzeichnis/Subset, die in einer entsprechenden Guideline dokumentiert sein sollten. Beispieldateien des Zielformats sind ebenfalls hilfreich. Für den Kommunikationsteil müssen die entsprechenden Parameter ausgetauscht werden. (IP/Port/Zertifikate, wenn wir bei AS2 als Beispiel bleiben.) Für andere Kommunikationsprotokolle gilt dies analog.

Umsetzung/Implementierung:

Mapping/Übersetzung/Konvertierung: Datenquelle und Zielstruktur sind nun bekannt. Folglich kann entweder eigenprogrammiert oder mittels einer Standardsoftware (empfohlen) mit der Übersetzung der Daten begonnen werden. Moderne EDI-Konverter wie i‑effect^® bringen zu diesem Zweck intuitive und grafische Mapping-Tools mit. Mithilfe des Datenmappings wird quasi ein „Routenplaner“ für die Daten erstellt, um sie von Quelle zum Ziel zu überführen. Am Ende steht dann die gewünschte Datei, hier EDIFACT INVOIC, im Filesystem zur Verfügung.

Übertragung/Kommunikation: Die Kommunikationsparameter sind nun bekannt. Das Kommunikationssystem, z. B. i‑effect^®, kann nun idealerweise geführt und übersichtlich mit den notwendigen Informationen gefüllt und die Kommunikation so eingerichtet werden. Die Datei wird jetzt aus dem Filesystem entnommen und an den Empfänger übertragen.

Automatisierung: An dieser Stelle ist der einmalige EDI-Prozess bereits abgeschlossen. In den allerwenigsten Fällen werden aber einmalig Daten übertragen, vielmehr soll dies regelmäßig geschehen. Grundsätzlich kann eine automatisierte Steuerung zeit- oder event-basiert sein, z. B. sollen Daten immer zu einem bestimmten Zeitpunkt am Abend gesendet werden oder eben immer dann, wenn eine Datei in einem bestimmten Verzeichnis erzeugt wird.

Überwachung/Monitoring: Der EDI-Prozess ist nun eingerichtet. Anschließend wird dieser überwacht werden wollen. Moderne EDI-Lösungen bringen an dieser Stelle geeignete Interfaces mit i‑effect^® z. B. nutzt mit WebControl eine browserbasierte Monitoring-Plattform. Hier können Datenein- und -ausgang sowie die Konvertierungsprozesse in verschiedenen Detailgraden nicht nur überwacht werden, sondern zusätzlich ist diese Schnittstelle auch dafür geeignet, um Prozesse einzurichten, Stammdatenpflege vorzunehmen und in einem eventuellen Fehlerfall natürlich Lösungen anzubieten.

Welche Anwendungsbereiche bzw. Abteilungen profitieren von einer EDI-Infrastruktur am meisten?

Konzentriert auf den externen Datenaustausch, gewöhnlich ein Belegaustausch wie Bestellung, Liefermeldung oder Rechnung, wird dies sicherlich im Speziellen der Vertrieb respektive Einkauf oder die Finanzbuchhaltung sein. Im Grunde profitiert aber das gesamte Unternehmen, wenn man den Blick etwas weitet. So können natürlich auch Lager, Logistik, Produktion und nicht zuletzt die IT-Abteilung selbst die Vorteile einer modernen EDI-Software genießen, entweder durch den Einsatz und Austausch geeigneter Standard-Nachrichtenarten wie ORDERS, DESADV oder INVOIC, um nur einige Gängige zu nennen, oder durch die Anwendung einer EDI-Software als EAI-Tool, um zwischen verschiedenen internen Softwarelösungen zu vermitteln. Schlussendlich kann eine EDI-Software die zentrale Datendrehscheibe für entsprechende Unternehmensdaten sein.

Welche Formate sollte eine EDI-Lösung beherrschen?

Eine vollumfängliche Software sollte auf alle gängigen Datenformate eine Antwort haben. Im Mindesten könnte man sich aber auf die weit verbreiteten Formate EDIFACT und XML, hier z. B. UBL oder openTRANS, aber im Grunde auch XRechnung und ZUGFeRD, beschränken. Jedoch kommen auch individuelle, nicht standardisierte oder ältere Datenformate zum Einsatz wie z. B. CSV, Flatfiles oder Tradacoms. i‑effect^® beispielsweise ist modular aufgebaut, sodass mit dieser Lösung immer zielgerichtet auf den jeweiligen Anwendungsfall und Kundenwunsch reagiert werden kann.