Aufgrund hoher Einstiegsinvestitionen stehen insbesondere kleine und mittlere Unternehmen dem Datenaustausch via EDI noch überwiegend skeptisch gegenüber. Einen kostengünstigen Königsweg verspricht einmal mehr die Kombination von EDI und XML.
Internetbasierte B2B-Anwendungen im Bereich des elektronischen Datenaustausches
Nach wie vor stehen insbesondere kleine und mittlere Unternehmen dem strukturierten Geschäftsdatenaustausch via EDI aufgrund der relativ hohen Einstiegsinvestitionen überwiegend skeptisch und ablehnend gegenüber. Die oftmals einzige Motivation sich an bestehende EDI-Netzwerke anzubinden, resultiert dabei aus der Sorge, wichtige Handelsbeziehungen zu Großunternehmen und bedeutenden Geschäftspartnern andernfalls leichtfertig aufs Spiel zu setzen. Vor allem die Anbieter von internetbasierten B2B-Anwendungen für den elektronischen Geschäftsverkehr – wie etwa cc-top – beschäftigen sich daher bereits seit längerem intensiv mit der Entwicklung kostengünstiger und funktionaler Alternativen. Als ein möglicher Königsweg gilt dabei die Teilnahme an EDI unter Verwendung von XML.
Mit diesen, auf das Internet und modernen Browsern basierenden Anwendungen, ist es jetzt möglich, auch kleinere Geschäftspartner in die EDI-Netzwerke großer Unternehmen einzubinden, ohne dass diese hierbei Investitionen für Hard- und Software tätigen müssen. Auf einem Internet-Server loggen sich die kleinen Geschäftspartner ein und mittels Bildschirmmasken können eingegangene Nachrichten angezeigt, bearbeitet, ausgedruckt, archiviert und gelöscht werden. Ein entscheidender Vorteil gegenüber bisherigen, sogenannten „Web-EDI“-Lösungen besteht in der Möglichkeit, Daten sowohl importieren als auch exportieren zu können. Außerdem ist es möglich, in einer einzigen Anwendung Nachrichten mehrerer Kommunikationspartner zu visualisieren und diese parallel zu bearbeiten. Neben dem Datenformat XML können die Daten grundsätzlich in beliebigen Inhouse-Formaten zur Verfügung gestellt werden, was den Anwendungsbereich derartiger Lösungen sehr weit öffnet.
Alternativ erscheint ein solcher Lösungsansatz auch als Angebot im Rahmen eines „Application Service Providing“ denkbar: So nutzt der Kunde hierbei die vom Provider angebotene Dienstleistung auf der Basis pauschaler oder nutzungsabhängiger Entgelte (pay-per-use). Damit wäre eine vollständige Nutzung der Dienste bis hin zum vollautomatischen Betrieb gegeben, während der komplette Umfang des EDI Dienstleistungspakets „outhouse“ läge.
Vorteile auch für EDI-Promotoren
Eine Problematik vieler Großunternehmen liegt beim heutigen EDI häufig darin, dass das Prinzip „Geben und Nehmen“ nur selten praktiziert werden kann. Der Versand der Daten an die Partner funktioniert zwar relativ unproblematisch; jedoch gestaltet es sich insbesondere für kleine Partner, ohne echte EDI-Integration in deren Inhouse-Anwendungen, als äußerst schwierig, die empfangenen Nachrichten auch entsprechend zu beantworten (z.B. ein Lieferavis oder eine Rechnung zu einer Bestellung).
Beim XML-basiertem Web-EDI hat der mittelständische Anwender jedoch die Möglichkeit, mittels sogenannter „Turnaround“-Funktionalitäten vergleichsweise einfach korrespondierende Antwortnachrichten zu erzeugen. Somit besteht die Chance, dass der Einsatz solcher Lösungen perspektivisch zu einem Ausbau klassischer EDI-Nutzung bis hin zu einer kompletten Abbildung der Wertschöpfungskette führt. Und für die heutigen EDI-Anwender ergibt sich hieraus der Vorteil, die Anbindung weiterer Partner sehr zügig vornehmen zu können. Weil sich beim Großunternehmen die Schnittstelle nicht ändert (es werden nach wie vor EDI-Daten empfangen und versandt), genügt eine einzige Datenschnittstelle, um (theoretisch) alle Partner elektronisch zu verknüpfen. Als Adressat muss lediglich die Kommunikations-Adresse des Dienstleisters angegeben werden, der alle weiteren Aktivitäten mit den Geschäftspartnern koordiniert. Investitionen in Hard- oder Software entfallen komplett und es muss außerdem kein zusätzliches Know-how aufgebaut werden.
Nachfolgend demonstrieren wir anhand zweier praktischer Anwendungsbeispiele, worin vor diesem Hintergrund die wesentlichen Unterschiede zwischen EDIFACT-Norm und Web-EDI liegen.
Ausgangssituation
Der Lieferant A wird von einem wichtigen Kunden zum elektronischen Austausch von Bestelldaten (EANCOM-ORDERS) aufgefordert. Zur Sicherstellung einer termingerechten Anlieferung erwartet der Kunde im Rücklauf ein Lieferavis (EANCOM-DESADV). Der Kunde nutzt zur Datenübertragung den Telebox-400-Service der Telekom AG. Die Applikation (Auftragsabwicklung) des Lieferanten verfügt über Dateiexport- und Datei-importschnittstellen. Der Lieferant nutzt zur Datenübertragung einen gängigen Email-Client (z.B. Lotus-Notes oder Microsoft-Outlook).
Einrichtung
Im Rahmen der Registrierung auf dem Server teilt der Lieferant mit, mit welchem Kunden welcher Nachrichtentyp ausgetauscht werden soll. Darüber hinaus stellt er dem Dienstleister via Email eine Dokumentation seiner Export- und Importschnittstellen sowie seine Email-Adresse zur Verfügung.
Der Dienstleister informiert den Kunden über die geplante Austauschbeziehung, teilt dem Kunden die X.400-Adresse des Servers mit und erstellt die Konvertierungstabellen. Der Lieferant erhält die Email-Adresse des Servers.
Betrieb: Auftragsdaten
Der Kunde übermittelt die Auftragsdaten im EANCOM-Format automatisch an die vom Dienstleister genannte X.400-Adresse. Der Server liest die X.400-Mailbox aus, leitet die EANCOM-Daten an den Konverter weiter, konvertiert die Daten in das Format der Import-Schnittstelle des Lieferanten und übermittelt die Inhouse-Datei mit den Bestelldaten an die Email-Adresse des Lieferanten.
Der Lieferant liest wiederum von Zeit zu Zeit manuell (ggf. nach entsprechender Benachrichtigung) seine Mailbox aus und transferiert die Bestelldaten auf seinen Ziel-rechner, auf welchem eine Importroutine die Daten dem Anwendungsprogramm übergibt.
Betrieb: Lieferavisdaten
Das Anwendungsprogramm des Lieferanten stellt die Lieferavis-Daten in Form einer Export-Datei zur Verfügung. Diese Datei wird mittels Lotus-Notes vom Lieferanten an die Email-Adresse des Servers übertragen.
Der Server liest automatisch die Mailbox aus, leitet die Inhouse-Daten an den Konverter weiter, konvertiert die Daten in das EANCOM-DESADV-Format des Kunden und übermittelt die EANCOM-Datei an die X.400-Adresse des Kunden.
Anwendungsbeispiel 2: Web-EDI – Automatisierter Datenaustausch mit menschlicher Intervention
Ausgangssituation
Auch der Lieferant B wird von seinem Kunden zum elektronischen Austausch von Bestelldaten (EANCOM-ORDERS) aufgefordert. Die Applikation (Auftragsabwicklung) des Lieferanten B verfügt allerdings nicht über Dateiexport- und Datei-importschnittstellen. Der Lieferant verfügt aber über einen Internet-Zugang und einen XML-fähigen Browser. Er kann dann zum Datenaustausch eine Web-EDI-Funktionalität des Servers nutzen.
Einrichtung
Im Rahmen der Registrierung auf dem Server teilt der Lieferant mit, mit welchem Kunden welcher Nachrichtentyp ausgetauscht werden soll. Der Dienstleister informiert den Kunden über die geplante Austauschbeziehung und teilt dem Kunden die X.400-Adresse des Servers mit.
Betrieb: Auftragsdaten
Der Kunde übermittelt die Auftragsdaten im EANCOM-Format an die genannte X.400-Adresse. Der Server liest die X.400-Mailbox aus, leitet die EANCOM-Daten an den Konverter weiter, konvertiert die Daten in das XML-Format und stellt die einzelnen Aufträge als XML-Files in den Eingangskorb des Lieferanten.
Der Lieferant meldet sich am Server an, wählt den Eingangskorb und stellt sich via Browser die Auftragsdaten dar, welche bei Bedarf gedruckt werden können.
Betrieb: Lieferavisdaten
Mit Hilfe der Turn-around-Funktion wird ein Auftrag zu einem Lieferavis, in welches der Lieferant die tatsächliche Liefermenge und das tatsächliche Lieferdatum erfasst. Nach Freigabe der Liefermeldung werden die Daten nach EANCOM-DESADV konvertiert und in die X.400-Mailbox des Kunden übermittelt.
