Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

28.06.1991 - 

Auf offene Kommunikationssysteme wie X.400 kann nicht verzichtet werden

Internationale Standards sind auch bei EDI das A und O

Die Vision vom offenen elektronischen Handelsdatenaustausch (EDI) ist eines der aktuellen Themen in der DV-Welt. Es wird viel über die strategischen Vorteile und die erreichbaren Kostenreduzierungen durch den Einsatz von EDI geschrieben. Ob derartige Vorteile sich aber tatsächlich erreichen lassen, hängt stark von Entscheidungen vor und während der Einführungsphase ab. Jakob Karszt* behandelt im folgenden Beitrag technische wie organisatorische Fragen bei EDI-Projekten und zeigt die wesentlichen Entscheidungen auf.

Die Vision vom offenen EDI besagt, daß alle Geschäftsdokumente in kürzester Zeit weltweit über alle Organisationen und Geschäftsvorgänge hinweg elektronisch "verständlich", das heißt ohne manuellen Eingriff, ausgetauscht und, was genauso wichtig ist, auch weiterverarbeitet werden können. In der Praxis sind wir heute jedoch noch ein ganzes Stück von der Realisierung dieser Vision entfernt.

Transportbranche und

Banken noch unabhängig

Wer heute ein EDI-Projekt beginnt, wird sich zunächst die Lösung bestimmter Teilaufgaben zum Ziel setzen. Konkrete Projektziele im Bereich Handel sind die Kostenreduzierung durch Verfügbarkeit eines schnellen, einheitlichen Austausches von Produktkatalogen, Bestellungen, Lieferbarkeitsinformationen und Rechnungen. Dabei bleiben meist im ersten Schritt die sogenannten Unterstützungsdienste für Transport (Lieferbelege) und Bank (Zahlungsanweisungen) außer Betracht. Die Transportbranche oder die Banken beschäftigen sich wiederum mit der Normierung von Nachrichten und dem Aufbau entsprechender Netzdienste. Die Einführung von EDI mit diesen "Unterstützungsdiensten" geschieht gegenwärtig noch meist unabhängig vom branchenspezifischen EDI-Dienst.

Wer heute ein branchenspezifisches EDI-Projekt beginnt, sollte sich an den internationale Standards zur Austauschformatdefinition und zur Kommunikation orientieren. Leider hat sich in manchen Branchen immer noch nicht die Einsicht durchgesetzt, daß man nur Teil eines größeren Verbundes für den Datenaustausch ist. Man kreiert immer noch neue EDI-Lösungen mit nicht-standardisierten Formatbeschreibungen und Kommunikationsverfahren.

Das Argument der Edifact-Gegner, der Aufwand für die Beschäftigung mit Normierungsgremien sei unnötig hoch und Edifact-Nachrichten wären wegen ihrer branchenübergreifenden Zielsetzung "überladen", zeugt von einer kurzsichtigen Denkweise. Schließlich können die Erfahrungen anderer auch nützlich sein. Über offene und international akzeptierte Kommunikationsverfahren wie X.400 wird zusätzlich gewährleistet, daß jeder den anderen erreicht.

EDI-Standards ermöglichen den Einsatz von Hard- und Softwareprodukten unterschiedlicher Hersteller sowie Services verschiedener Netz- oder VANS-Anbieter. Daß dies den Interessen von etablierten, geschlossenen EDI-Diensten zuwider läuft, ändert nichts an der Tatsache, daß der Druck des Marktes in Richtung offene Systeme enorm hoch ist.

In technischer Hinsicht liegen die Probleme bei EDI in der Integration der Anwendungen im Unternehmen. Diese Einbindung soll über die EDI-Software und Netzdienste erreicht werden, wobei die vorhandenen Anwendungen (Warenwirtschaftssysteme, Bestell, ZahIungs-, Rechnungsschreibungsprogramme) in verschiedenen Unternehmen auf unterschiedlichen DV-Umgebungen zusammengeführt werden.

Vor der Einführung von EDI muß geklärt sein, welche Auswirkungen ein offenes Kommunikationssystem auf das Unternehmen hat, welche strategischen (eigenes Angebotsspektrum, Stellung im Markt), taktischen (Beschleunigung der Auftragsabwicklung) und operationalen (Kostenreduzierung) Resultate erwartet werden. Je nach Bewertung dieser Faktoren sind die unternehmensspezifischen Ziele für das unternehmensübergreifende EDI-Projekt zu definieren.

Wenn wir von einer Branchenlösung ausgehen, so muß auf Branchenebene eine unternehmensübergreifende Organisation etabliert werden (Ausschuß von Verbänden, Normungsausschüsse), die sich um eine einheitliche Lösung kümmert. Die Aufgaben, die eine solche Organisation übernimmt, sind von Branche zu Branche unterschiedlich. Die Definition der Nachrichtentypen und Austauschformate ist jedoch das Mindeste, was hier geschehen muß. Wenn sich die Verbandsmitglieder einig sind, kann das zur Gründung einer eigenen Gesellschaft führen, die die Realisierung und den Betrieb eines branchenspezifischen EDI-Dienstes übernimmt. Aktuelles Beispiel ist die Phonobranche mit Phononet.

Interessenvertretungen der Kleinen und Mittleren

Da die Vorteile von EDI wegen des größeren Rationalisierungspotentials vor allem bei großen oder marktstarken Unternehmen zum Tragen kommen, ergreifen diese häufig die Initiative, um sich strategische Wettbewerbsvorteile und Kosteneinsparungen zu sichern. Die mittleren und vor allem kleinen Unternehmen sind aber genauso betroffen. Sie versuchen, über eigene Interessenvertretungen Einfluß zu nehmen, um nicht von den Großen vor vollendete Tatsachen gestellt zu werden.

Als Initiatoren und Projektträger von EDI-Projekten treten Einzelunternehmen, Unternehmenskooperationen, im Handel etwa Einkaufsringe oder Verbandsunternehmen, aber auch Softwarehäuser und VANS-Anbieter auf. Zuschüsse für die Projektdurchführung können sowohl von der EG als auch vom Bund beantragt werden.

Während der Projektdefinitionsphase für das unternehmensübergreifende Projekt müssen die genauen Ziele, die Rahmenbedingungen und die Aufgabenverteilung unter den Projektbeteiligten festgelegt werden.

Was die Ziele betrifft, so sollte klar definiert werden, welche Art von Partnern bis zu welchem Zeitpunkt am EDI-Dienst teilnehmen sollen, welche vorhandenen Austauschverfahren und -formate bereits existieren, welche abgelöst oder integriert werden sollen. Hier liegen oft die größten Hindernisse auf dem Weg zum offenen EDI, da Bestehendes, das in einem begrenzten Umfeld funktioniert, nur schwer abzulösen ist. In verschiedenen Branchen wird aber auch sichtbar, daß durchaus Migrationswege beschritten werden können.

Zunächst ist zu klären, welche Nachrichtentypen unterstützt werden sollen. Damit wird deutlich, welche Anwendungen bei den Teilnehmern betroffen sind. Gerade bei kleinen Unternehmen, die noch kein DV-Equipment besitzen, müssen derartige Anwendungen zur Verfügung gestellt werden, um überhaupt EDI zu ermöglichen. Die gängigste Lösung für die Anbindung von Anwendungen ist heute die File-Schnittstelle zwischen EDI-Software und Anwendungssoftware, jedoch wird in zunehmendem Maß der Einsatz direkter Datenbankanbindungen oder Prozeß-Kommunikationsschnittstellen ins Auge gefaßt.

Eine der wesentlichen Aufgaben ist die Definition des Inhalts und Aufbaus der Nachrichtentypen. Hier können erhebliche Differenzen zwischen den Beteiligten entstehen. Selbst wenn in Edifact bereits Vorschläge vorhanden sind, muß man mit Änderungen der internen und externen Normierungsausschüssen während und nach der Projektdurchführung rechnen, solange eine Nachricht noch nicht abschließend "normiert" ist.

Subset-Änderungen im Wirkbetrieb sind jedoch innerhalb des Projektes zu berücksichtigen, da oft nicht garantiert werden kann, daß alle Beteiligten mit der gleichen Normversion arbeiten. Diese Aufgabe des "Angleichs" müssen dann die EDI-Software und die Applikationsanbindung übernehmen.

Grundfunktion der EDI-Software ist die Konvertierung von und nach Edifact. Häufig geht man allerdings weiter und betrachtet die Software als zentrale Instanz für den externen Datenaustausch. Damit gehören auch Funktionen wie Partnerverwaltung, Routing, ereignis- oder zeitintervallgesteuerte Mailbox-Abfrage, Edifact-Tabellen und Versionsverwaltung, Archivierung und Retrieval der Nachrichten sowie Datenschutz- und Sicherheitsfunktionen (wie automatischer Wiederanlauf Zugangskontrolle, Verschlüsselung, Komprimierung) zu deren Aufgaben. Hier ist ein hoher Abstimmungsgrad mit den verwendeten Netzdiensten erforderlich.

Eine zentrale Frage in allen EDI-Projekten ist die Verfügbarkeit eines leistungsfähigen, sicheren und kostengünstigen Netzdienstes. Je nach Datenvolumen und Teilnehmerprofilen kommen Lösungen wie Punkt-zu-Punkt-Verbindungen auf Filetransfer-Ebene oder zentrale Vefmittlungsdienste auf Mailbox-Ebene zum Tragen. Es ist dringend anzuraten, daß standardisierte Funktionen nach OSI auf möglichst hohem Level zumindest integrierbar sind (FTAM, X.400).

Eine Entscheidung, die nicht auf derartigen Standards beruht, kann zur Abhängigkeit von einem bestimmten Netzdienst-Anbieter führen. Die Analyse der VANS-Anbieter hinsichtlich Technik (Netzzugang, 24stündige Verfügbarkeit, Ubermittlungsgeschwindigkeit) und Kosten lohnt sich, da zum Teil erhebliche Unterschiede in Preis und Leistung zu Tage treten.

Während der Entwurfsphase können auf EDI spezialisierte Unternehmensberatungen und Softwarehäuser wertvolle Analyse- und Konzeptionsarbeit in Fragen zu VANS-Auswahl, Edifact-Abbildungen und Gesamtkonzeption leisten. Spätestens bei der Realisierung müssen ohnehin EDI-Softwarespezialisten hinzugezogen werden, sei es als Integratoren zur Anbindung der Anwendungen oder zu Erstellung beziehungsweise Lieferung von Produkten (EDI-Software). Einige Softwarehäuser oder VANS-Anbieter offerieren inzwischen auch die Realisierung von Gesamtlösungen.

EDI bei Bibliotheken und im Buchhandel

Viele Jahre war EDI in der DV-Szene eher ein Schlagwort als Praxisrealität. Das hat sich inzwischen geändert. Beispiel dafür ist ein Projekt für den elektronischen Datenaustausch zwischen Buchhandel und Bibliotheken, bei dem nach internationalen Standards vorgegangen wurde. Schon vor Projektende zeigte das große Interesse der gesamten Branche, daß eine Durchsetzung und Akzeptanz bei den potentiellen Teilnehmern zu erwarten ist.

Ausgangspunkt: Die großen Bibliotheken setzen unterschiedliche, herstellerspezifische elektronische Bestellsysteme einiger großer Lieferanten aus ganz Europa ein, die jedoch nicht in hausinterne Anwendungen integriert sind. Über diese Systeme sind jedoch nicht alle Bestellungen abzuwickeln. Ein Großteil wird also auf herkömmlichen Weg manuell bearbeitet. Auf Buchhandelsseite können sich aber ebenfalls nur wenige Anbieter erlauben, eigene Bestellsysteme bei den Bibliotheken zu installieren. Es bestand also auf beiden Seiten ein großes Interesse, Bestellungen nach einem einheitlichen standardisierten Verfahren zu übermitteln, so daß sie auch in den eigenen Anwendungen weiterverarbeitet werden können.

Die Projektleitung lag bei der Deutschen Bibliothek, die Durchführung übernahm die Stadt- und Universitätsbibliothek Frankfurt. Teilnehmer sind bis heute mehrere größere Buchhandlungen. Für die Software-Entwicklung zeichnete die Inovis GmbH & Co. in Karlsruhe verantwortlich. Ziel des Projekts war es, ein offenes System zu schaffen, das mehr Wettbewerb und Markttransparenz erlaubt sowie alle Anbieter und Abnehmer, große wie kleine, in den Abwicklungsprozeß einbezieht. Als Edifact-Nachrichtentypen wurde ein Subset-Vorschlag für Angebot, Bestellung, Bestellbestätigung und Rechnung erarbeitet. Die Einbeziehung des Angebots erhöht das Dienstleistungsangebot der Buchhandlungen. Bestellung und Bestellbestätigung dienen vor allem Rationalisierungszwecken .

In der EDI-Serversoftware "Bosi", die unter Unix und DOS zur Verfügung steht, wurden diese Nachrichtentypen implementiert. Bosi ermöglicht die einfache Anbindung an hausinterne Erwerbungssysteme der Bibliothek sowie an die Angebots-, Bestell- und Fakturiersoftware in Buchhandlungen.

Eigenes "elektronisches

Postamt" möglich

Die Kommunikation wird auf Basis von X.400 abgewickelt. Größeren Teilnehmern ist es möglich, ein eigenes "elektronisches Postamt" (Message Transfer Agent) zu führen. Eine preisgünstigere Variante, bei der lediglich die Zugangssoftware (User Agent) mit Modem zu einem zentralen X.400-Postamt (X.400-Version von 1988) beim Teilnehmer installiert wird, ist ebenfalls verfügbar. Hier wird gegenwärtig der Telebox-400-Dienst der Telekom genutzt. Wichtig ist, daß damit alle an X.400 angeschlossenen Unternehmen weltweit erreichbar sind. Die Kommunikation läßt sich aber auch über die anbieterspezifischen schon bestehenden Wege realisieren . Es wurden bereits Formatumsetzungen in die branchenspezifischen Formate des Buchhandels zur Weiterleitung der Bestellungen an Großhändler und Verlage implementiert. Hier findet also die Integration herkömmlicher EDI-Systeme statt. Insgesamt sind vier X.400-Systeme auf Anlagen unterschiedlicher Hersteller zum Einsatz gekommen. Das Interesse an dieser EDI-Lösung ist groß. Auf europäischer Ebene haben weitere Bibliotheken und Buchhandlungen die Arbeiten zur Teilnahme an diesem offenen EDI-System aufgenommen. Erfahrungen mit unterschiedlichen X.400-Produkten und Edifact-Programmen aus dem Jahre 1990 zeigen, daß sowohl im Standardisierungsbereich als auch im Bereich Offenheit noch einiges zu tun bleibt, um die Integration in heterogene Umgebungen zu erleichtern. Jedoch ist heute die "Probephase" endgültig vorbei, und die Vorteile von Produkten, die offene Standards berücksichtigen, können tatsächlich genutzt werden.