Momentan befindet sich die EDI-Gemeinschaft in einer Art Aufbruchstimmung. Der bisher vor allem für den nationalen und brancheninternen Datenaustausch genutzte Standard entwickelt sich zunehmend zur Kommunikationshilfe in einem internationalen, branchenübergreifenden Beziehungsgeflecht.
Die Entwicklung übergreifender Standards wie Edifact und die Verfügbarkeit von Netzdiensten schafft Abhilfe, was die bislang dringendsten Probleme Standardisierung und Kommunikation betrifft. Mittlerweile wird EDI nicht mehr nur im Rahmen von langfristigen Partnerschaften und für einige wenige Geschäftsbeziehungen eingesetzt. Die steigende Zahl der involvierten Partner macht den Austausch komplexer. Aus diesem Grund werden Lösungen benötigt, die die Vorlaufzeiten und Kosten für die Etablierung und Aufrechterhaltung von EDI-Partnerschaften reduzieren. Die Kommunikationsplattform muß außerdem einfach zu bedienen sein und problemlos funktionieren.
Projekte, die über mächtigere Konverter und verifizierte Geschäftsbeziehungsmodelle zu einer flexibleren Inhouse- Integration von EDI führen sollen, befinden sich noch im Entwicklungsstadium. Der umfassendste Ansatz dafür ist zweifellos Open-EDI. Im Gegensatz zu bisherigen Standardisierungen werden hierbei nicht nur wie bisher üblich Geschäftsformulare, sondern ganze Geschäftstransaktionen abgebildet.
Der Standardisierungsprozeß ist weitaus komplexer als bei Edifact. Unter anderem müssen APIs und Geschäftsmodelle standardisiert werden. Umfassende und frei verfügbare Kommunikationsverbindungen werden benötigt. Aufgrund seiner weiten Verbreitung und der problemlosen Zugangsmöglichkeiten scheint das Internet die ideale Plattform darzustellen. Bislang sind die damit verbundenen Sicherheitsprobleme allerdings noch nicht allgemein gelöst.
Bei Edifact existieren bereits Nachrichtendefinitionen für die meisten Geschäftstransaktionen. Durch Weglassen optionaler Segmente und Datenelemente können Firmen beziehungsweise Branchen die standardisierten Nachrichten entsprechend den benötigten Funktionen maßschneidern.
Dadurch, daß viele Datenelemente jedoch nicht auf eine einzige Bedeutung festgelegt sind, ist mit Edifact ein oft erheblicher Abstimmungsaufwand erforderlich.
Während bei Edifact nur Nachrichtentypen und deren Aufbau (die Syntax) angegeben sind, will man mit Open-EDI neue Wege gehen. Dort werden Standardgeschäftsprozesse (Szenarien) modelliert, das heißt, es wird für jede Geschäftstransaktion der mögliche Ablauf festgelegt. Diese Modelle enthalten dann analog zum Edifact- Prinzip vorgeschriebene Nachrichten, die zur Ausführung einer Transaktion zwingend notwendig sind, sowie optionale weitere Messages. Somit können die Standardmodelle wie bei den Edifact- Nachrichten an die firmeneigenen Bedürfnisse angepaßt werden.
Die definierte allgemeine Beschreibung für einen Geschäftsvorfall wird als generisches Open-EDI-Szenario bezeichnet. Die an rechtliche, branchenspezifische und weitere Anforderungen angepaßten Szenarien werden als spezifische Szenarien tituliert und sind in etwa mit den Nachrichten-Subsets von Edifact vergleichbar.
Um eine automatische Absprache von DV-Systemen zweier Firmen zu ermöglichen, muß für alle auszutauschenden Nachrichten, Segmente und Datenelemente eine einheitliche Semantik eindeutig festgelegt sein, so daß die Bedeutung der Nachrichten zweifelsfrei verstanden wird. Bei Messages, die für ganz bestimmte Zwecke entwickelt wurden wie zum Beispiel die im Automobilbereich verwendeten VDA- Nachrichten, ist dies näherungsweise der Fall.
Zwei Rechnersysteme können sich auf der Basis von Geschäftsprozeßmodellen und den jeweiligen unterstützten Funktionalitäten (Rollenverhalten) untereinander auf eine gemeinsame Basis zur Durchführung einer vorher festgelegten Geschäftstransaktion einigen und, sofern von beiden Firmen die jeweils erforderlichen Funktionen zur Verfügung gestellt werden, auch die zu verwendenden Nachrichten und Daten absprechen. Man kann sich diesen Vorgang ungefähr so vorstellen, wie sich Modems oder auch Faxgeräte untereinander auf einen gemeinsamen Standard einigen, der von beiden verstanden und unterstützt wird. Bei Modems wären dies etwa die zu verwendende Fehlerkorrektur, die Übertragungsgeschwindigkeit und der Übertragungsstandard.
Auf der Basis der festgelegten Geschäftsprozeßmodelle sind in den Firmen die externen Schnittstellen zu modellieren und auch interne Abhängigkeiten darzustellen. Dieser Prozeß wird ganz oder teilweise bereits bei der Einführung von EDI mittels Edifact oder anderer Nachrichtenstandards notwendig. Unterbleibt er, ergeben sich aufgrund des EDI-Einsatzes nur geringe Vorteile für das Unternehmen, wenn nicht sogar Nachteile entstehen. Open-EDI bietet den Vorteil, daß die Analyse für jede Firma nur ein einziges Mal durchgeführt werden muß und nicht für jeden Geschäftspartner erneut notwendig wird.
Das beschriebene Vorgehen entspricht der geschäftsorientierten Sicht (Business Operational View - BOV) von Open-EDI. Zusätzlich existiert noch eine funktionale Sicht (Functional Service View - FSV), die sich auf die technischen Aspekte des Datenaustausches bezieht. Darunter fallen zum Beispiel die Auswahl des zu verwendenden Übertragungsverfahrens und der darauf aufsetzenden Dienste, also etwa der bei X.400 und X.435 bereitgestellten Services für die Verschlüsselung sicherheitskritischer Daten, das Auditing und die Einhaltung zugesicherter Antwortzeiten.
Nehmen wir als konkretes Beispiel eine Bestellung. Die Inhouse- Software des Bestellers schickt eine Anfrage betreffs des Aufbaus einer EDI-Verbindung an die Open-EDI-Software des potentiellen Auftragnehmers. Diese besteht aus einzelnen Modulen, den sogenannten Open-EDI-Support-Entities (OESEs), die nach ihren Funktionen gruppiert sind. Zwei der Schlüsselmodule, die in jedem Open-EDI-System implementiert sein müssen, sind der Role Trader (RT) und der Role Interpreter (RI). Sie übernehmen die weiteren Absprachen zwischen den EDI-Teilnehmern und steuern nachfolgend auch den eigentlichen Nachrichtenaustausch.
Ist die EDI-Verbindung aufgebaut, geht eine Bestellungsanfrage von der Anwendung des Bestellers an das RT-Modul der Open-EDI-Software des Auftragnehmers. Dieses Modul kann aufgrund des vorgegebenen spezifischen Szenarios für Bestellungen feststellen, welche weiteren Rollen für die Abwicklung noch benötigt werden.
Unter anderem wird an das RT-Modul des Adressaten die Aufforderung geschickt, innerhalb des Bestellungsszenarios die Rolle des Lieferanten zu übernehmen. Die angesprochene Open-EDI-Software kann sich dann bei der Inhouse-Software erkundigen, ob Bestellungen anzunehmen sind, und etwa bei bestehendem Zahlungsverzug eine ablehnende Nachricht zurückschicken. Wird der Anfrage Folge geleistet, findet zwischen der Open-EDI-Software der beiden Firmen eine Abstimmung statt, welche Nachrichteninhalte in welcher Reihenfolge auszutauschen sind. Dabei wird auch geklärt, ob einer der Teilnehmer optionale Nachrichten benötigt und ob der Partner diese auch generieren kann.
Funktionalität steht noch in den Sternen
Hierbei greifen die RT-Module der Geschäftspartner auf Informationen zurück, die in den Geschäftsprozeßmodellen der jeweiligen Firmen enthalten sind. Eventuell stellen die Module fest, daß noch Absprachen mit anderen Geschäftspartnern notwendig sind.
Bevor nun der eigentliche Austausch von Daten vorgenommen werden kann, werden zwischen je zwei Partnern noch das Datenformat und die zu verwendenden Kommunikationsprotokolle vereinbart. Dies können beispielsweise Edifact- oder VDA-Nachrichten sein, die dann über X.435, Internet oder andere Kommunikationsdienste ausgetauscht werden, mit oder ohne weitere Dienste wie Auditing oder Verschlüsselung.
Die Hauptarbeit während des eigentlichen Datenaustausches leistet das RI-Modul, das ereignisgesteuert und auf der Grundlage der jeweiligen Szenarios die notwendigen Rollenverhalten und Einzelaktionen in Gang setzt, steuert und überwacht.
Außer dem RT und dem RI sind noch viele weitere OESEs möglich. Beispielsweise können derzeitige Konverterlösungen, erweitert um die notwendigen standardisierten Open-EDI-Schnittstellen zu Inhouse-Anwendungen, anderen OESEs und der Kommunikationsebene, ebenfalls verwendet werden, um eine möglichst einfache Migration zu Open-EDI zu gewährleisten.
Da sich Open-EDI noch in der Entwicklung befindet, lassen sich derzeit keine endgültigen Schlüsse hinsichtlich der Einsatzfähigkeit ziehen. Besonders auf dem Gebiet der Modellierung von Geschäftsprozessen unter den Aspekten globale Vorhaltung, individuelle Anpassungsfähigkeit und automatisierte Modellabstimmung sind noch Probleme ungelöst. Grundsätzlich entspricht der Ansatz aber den zu erwartenden Anforderungen an den EDI-Einsatz: reduzierte Partnerabsprachen und flexibler teilautomatischer Ablauf.
Angeklickt
Mit der zunehmenden Verbreitung des Electronic Data Interchange (EDI) werden auch die Beziehungsgeflechte zwischen den kommunizierenden Unternehmen immer komplexer. Aus diesem Grund werden Lösungen benötigt, die Vorlaufzeiten und Kosten für die Etablierung sowie Aufrechterhaltung von EDI-Konglomeraten reduzieren. Die Normierer arbeiten deshalb an Open-EDI, mit dem Standardgeschäftsprozesse modelliert werden sollen. Im Klartext heißt das, den Ablauf von sämtlichen denkbaren Transaktionsszenarien mit allen dabei auszutauschenden Nachrichten im voraus festzulegen.
*Holger Kopp und Gregor Schwake sind Mitarbeiter der pm Consulting GmbH in Heilbronn.