Die angebotene EDI-Software hält offenbar noch nicht, was sie verspricht. Eine von der EG-Kommission initiierte Studie hat jedenfalls eine Menge Kritikpunkte der User an der EDI-Anwendungssoftware ans Tageslicht gebracht. Herbert Thomas* faßt die Ergebnisse der Studie zusammen.

Ende 1990 führte das niederländische Marktforschungsunternehmen Bakkenist (NL) im Auftrag der EG-Kommission eine Analyse der auf dem europäischen Markt verfügbaren EDI-Softwareprodukte durch. Die daraus abgeleitete Forderung nach einer Verbesserung der Software im allgemeinen bedeutet nicht, daß ein negatives Urteil über die vorhandenen Produkte gesprochen werden soll. Die Produkte haben aber, so die Studie, in einigen Funktionen nicht die Qualität, die die Anwender erwarten.

Die Forderungen der Anwender

In der Untersuchung wurden 70 EDI-Softwareprodukte und die Anforderungen der EDI-Anwender an diese Software analysiert. Obwohl nicht alle am Markt angebotenen Produkte in der Analyse berücksichtigt werden konnten, stellt sie eine gute Bestandsaufnahme des Marktes und Übersicht der Benutzeranforderungen dar.

Generell kommt die Studie zu dem Ergebnis, daß sich EDI als Schlüsseltechnologie im Geschäftsverkehr noch in einer frühen Implementierungsphase befindet. Beleg dafür ist das geringe Nachrichtenvolumen und die noch kleine Anzahl von EDI-Datenaustausch-Partnern, gemessen am vorhandenen Potential von mehreren 100 000 möglichen Anwendern.

Die im folgenden aufgeführten Hauptforderungen aus Sicht der Anwender lauten:

- Verbesserung der Benutzerfreundlichkeit, der Maintenance von Inhouse-File-Tabellen sowie der Sicherheitskontrollen in bezug auf den Zugang und die Authentication von eingehenden Nachrichten,

- Modifizierung der Mechanismen bei Updates von Edifact-Nachrichtentabellen,

- mehr Flexibilität und Unabhängigkeit in der Edifact-Struktur bei Produkten, die mit Flat Files arbeiten,

- flexible Verarbeitung der Nachrichtenversionen in Software und Produktion,

- Automatisches Abhandeln der Konvertierung von Codes und Qualifier in der Software,

- Option der Mehrfachkommunikation mit VANs, X.400 und direkten Verbindungen,

- Höhere Integration durch die Funktion des vollen Nachrichten-Audit-Trail als Zusatz des chronologischen Log Files,

- Funktion des bedienerlosen (automatischen) Betriebs,

- gängige Standardanwendungspakete (wie zum Beispiel SAP) sollten EDI-Fähigkeit besitzen und auch jeden EDI-Standard abhandeln können.

Die im Zuge der Studie durchgeführten Interviews ergaben, daß es häufig an den notwendigen Ressourcen fehlt, um EDI in die Anwendungen und Verfahren zu integrieren. Dieses Problem steht im Zusammenhang mit dem oft fehlenden Commitment des Top-Managements in Unternehmen.

Abgeleitet aus den Ergebnissen der Studie, ist noch zu bemerken, daß die Entwicklung von Guidelines zur Integration von EDI-Software mit den Inhouse-Anwendungen und die Integration der EDI-Software mit den Standard-Softwarepaketen stärker vorangetrieben werden sollte. Hier sind besonders die an der Entwicklung beteiligten Organisationen, EDI-Anwenderinitiativen und die Unternehmen selbst gefordert. Bei den Hauptfunktionen der EDI-Software wird zwischen Input/Output, Konvertierung, externe und interne Kommunikation sowie Management unterschieden.

Input: Grundsätzlich verwenden die Produkte sogenannte Flat Files als Input für die Konvertierung. Einige Produkte bieten auch die "Date-Entry-Funktion" als Eingabemöglichkeit von Dateninformationen von Dokumenten (zum Beispiel Rechnung und Bestellung), die dann elektronisch an den Partner im Edifact-Format übertragen werden können. Der Begriff "EDI" ist in diesem Fall jedoch nicht zulässig, da die Erstellung der Informationen noch manuell erfolgt.

Bei den Erfassungsmöglichkeiten unterscheidet man zwei Arten der Eingabe:

- Erfassung der Dateninformationen über Bildschirmmasken, die der Reihenfolge der Struktur der Edifact-Nachrichtensegmente entsprechen,

- Erfassung der Dateninformationen über funktionale Eingabe-Bildschirme inklusive der Beschreibung der Datenelemente; die Software fügt die entsprechende Qualifier hinzu und unterstützt damit menügesteuerte Code-Selektionen.

Output: Die Output-Funktion beschränkt sich hauptsächlich auf das Drucken der Nachrichten Dabei unterscheidet man grundsätzlich:

- Drucken von Nachrichten mit selbstgewählten Formaten,

- Drucken von "nur" vorformatierten Nachrichten beziehungsweise von Formaten in der Edifact-Struktur.

Konvertierung: Hier wird in zwei Richtungen differenziert:

- vom Inhouse-Format in das Edifact-Format, "Construction" genannt,

- vom Edifact-Format zum Inhouse-Format, mit der Fachbezeichnung "Conversion" .

Diese Funktionen werden von allen Produkten durchgeführt. Es stellt sich dabei die Frage nach der Flexibilität von Konvertern. Bei der Implementierung von Produkten hat sich gezeigt, daß je mehr Flexibilität ein Konverter in bezug auf das Inhouse-Format vorsieht, um so weniger Änderungen an bestehenden Anwendungen vorgenommen werden müssen.

Bei der Konvertierung existieren ebenfalls zwei Formen:

- die syntaktische Konvertierung und

- die semantische Konvertierung.

Unter syntaktischer Konvertierung wird die Umsetzung der individuellen Datenformate in die Edifact-normengerechte Syntax-Formate entsprechend den Edifact-Nachrichtenstrukturen verstanden. Dabei sollte das Erstellen der Edifact-Servicesegmente ebenso enthalten sein wie die Kontrollsummen und die Referenzen. Die Reihenfolge der Datensätze, die in der Regel von den Konvertoren gefordert werden, spielt hierbei eine wichtige Rolle. Bei vielen Produkten verlangen die Konverter, daß die Sequenz der Inhouse-Datensätze der logischen Reihenfolge der Edifact-Nachrichtensegmente entspricht.

Fehlerbehandlung ist unterschiedlich ausgeprägt

Oft ist die Reihenfolge der Datensätze in den Inhouse-Datenbeständen nicht entsprechend der Reihenfolge der Edifact-Segmente angeordnet. Konvertoren, die die vorgegebene Reihenfolge der Datensätze der Inhouse-Datenbestände verarbeiten können, haben einen großen Vorteil gegenüber den anderen Konvertoren, da sie kein zusätzliches Programm benötigen, um die Sequenz zu ändern. Ähnliche Probleme treten auf, wenn die Datensätze aus unterschiedlichen Inhouse-Dateien stammen und in ein Edifact-Segment umzusetzen sind.

Die semantische Konvertierung beinhaltet die korrekte Verarbeitung von Qualifiern, von Maßeinheiten, der Groß- und Kleinschreibung, der Ausrichtung auf die richtige Datenlänge und die Code-Konvertierung von Anwendungs-Codes in internationale Edifact-Codes (über Tabellen) und umgekehrt.

Die richtige Verarbeitung von Qualifiern stellt insofern ein Problem dar, da in der Regel bei Inhouse-Dateien keine sogenannten "Generic Data" mit Qualifiern vorhanden sind. Die Festlegung der entsprechenden Qualifier bei der Erzeugung von Edifact-Segmenten sollte vom Konverter, abhängig vom Typ der Inhouse-Satzart und des Inhalts der Daten, vorgenommen werden.

Die Fehlerbehandlung besitzen alle Produkte, jedoch ist ihre Ausprägung unterschiedlich. Einige Produkte weisen die spezifische fehlerhafte Nachricht zurück, nur wenige bieten die Möglichkeit der Fehlerkorrektur. Einige Konvertoren weisen beim Auftreten des ersten Fehlers die ganze Datei oder sogar den ganzen Datenaustausch zurück. Die Fehler werden in der Regel protokolliert und können auf dem Bildschirm angezeigt und/oder über einen Drucker aufgelistet werden.

Interne Kommunikation: Sie verbindet die Inhouse-Anwendung mit der Konverter-Software. Die Software sollte eine Unterstützung geben, um das automatische Routing zu und von verschiedenen Anwendungen (eventuell auch auf unterschiedlicher Hardware) in Abhängigkeit von den verschiedenen Nachrichten, die in einem Datenaustausch vorkommen können, durchzuführen.

Allgemein gesehen, produziert eine interne Anwendung einen Inhouse-File mit einer oder mehreren Nachrichten im Inhouse-Format. Die interne Kommunikation sorgt dafür daß der File zur Konvertierung und zur weiteren Verarbeitung bereitgestellt wird. Die empfangenen Nachrichten werden an fixer Stelle abgelegt und, falls erforderlich, in mehrere Files gesplittet, den verschiedenen Inhouse-Anwendungen zur Verfügung gestellt.

Externe Kommunikation: Die externe Kommunikation ist das Interface zwischen der Software und den verschiedenen Kommunikationsmöglichkeiten, wie Punkt-zu-Punkt-Verbindungen, Mehrwertdienste, Mailbox-Systeme und Message-Handling-Systeme (zum Beispiel X.400, FTAM).

Das Interface sollte dafür Sorge tragen, daß die benötigten Informationen den Kommunikationsprotokollen der verschiedenen Kommunikationsmöglichkeiten zur Verfügung gestellt werden. Management-Funktionen:

Ein Hauptmerkmal der Management-Funktionen einer EDI-Software ist die Möglichkeit des unbeaufsichtigten Produktionsbetriebes. Dazu zählen die gesamte Ablaufsteuerung sowie das Erstellen von Log-Files, Error- und Status-Reports. Einige Produkte bieten dabei zusätzlich die Möglichkeit der interaktiven Partnerverwaltung einschließlich der zu verwendenden Nachrichten und Subsets sowie für die Telekommunikation die entsprechenden Netzwerk-Anwendungsprofile.

Grundsätzlich lassen sich die EDI-Softwareprodukte laut Studie in drei Kategorien einordnen:

EDI-Konverter: Die Konverter haben als Hauptfunktion die Construction und die Translation. Die Abwicklung erfolgt in der Regel über Tabellen, und zwar vom Inhouse-Format (Construction) in das Edifact Format und umgekehrt vom Edifact-Format ins Inhouse-Format (Translation). Im allgemeinen erstellen die Produkte bei Fehlern entsprechende Error-Files.

Einige Produkte können Inhouse-Files verarbeiten, die eine eigene Struktur erlauben. Meist verwenden die Produkte bei der Inhouse-Anwendung aber einen Flat File, der die Inhouse-Datensätze in der Reihenfolge und Struktur der gewünschten Edifact-Nachrichten enthält.

Gateways: Gateway-Software unterstützt die Routing-Funktion und die Interface-Funktion zu und von den Inhouse-Anwendungen und zur externen Kommunikation. Eine Gateway-Software benutzt maßgeschneiderte Routinen zum Up- und Downloading zu den Anwendungen. Das Gateway unterstützt ebenso eine Anzahl von Kommunikations-Interfaces und Softwareprodukten und generiert automatisch das sogenannte Acknowledgement.

Unbeaufsichtigter Betrieb ist ein Hauptmerkmal von Gateways, das heißt die Fähigkeit zum Produzieren von Log Files, Status Reports und Audit Trails. Selbstverständlich ist ein manuell gesteuerter Ablauf ebenso durchführbar.

EDI-Workstation: EDI-Workstations sind im weitesten Sinne Gateways mit einer Dateneingabe-Funktion .

Sie haben den Vorteil, daß unerfahrene Benutzer oder noch nicht mit entsprechender DV-Hardware ausgestattete Nutzer hiermit Nachrichten eingeben und verarbeiten können. Ein Nachteil ist aber, daß in der Regel keine Verbindungen zu Anwendungen gegeben sind. Die Benutzerfreundlichkeit bei diesem Typ von Software spielt dabei eine ganz besonders wichtige Rolle.

Die manuelle Eingabe von Nachrichten ist im eigentlichen Sinne kein EDI, aber manchmal stellt die Möglichkeit der Dateneingabe eine provisorische Lösung dar, die die ersten Schritte zu einer komplexen EDI-Lösung erleichtert. Bei der Untersuchung der Produktfunktionen kam die Studie zu den folgenden Ergebnissen:

Input/Output: 39 Produkte der 70 untersuchten verfügen über die Möglichkeit der Dateneingabe. Die meisten basieren auf einer PC-Lösung. Einige sind reine Workstation- Produkte, die über keine Kommunikationsanbindungen verfügen. Andere Produkte sind spezielle Workstations, die für eine bestimmte Anwendung oder Gruppe entwickelt wurden und nur über einen limitierten Nachrichtenumfang verfügen. Die Nachrichten werden nach der Eingabe unvollständig gespeichert, um sie dann später weiterzuverarbeiten .

Nur 27 Produkte unterstützen die Nutzung eines sogenannten "MASTERS", um eine Nachricht zu erstellen. Die Kopierfunktion von empfangenen Nachrichten, die versendet werden sollen, ist nur bei 19 Softwareprodukten vorhanden. Einige wenige haben insofern eine Unterstützung der "MASTER"-Funktion, indem die Reaktivierung von archivierten Nachrichten möglich ist. Die Prüfroutinen der eingehenden Nachrichten sind bei allen Produkten vorhanden und als gut zu bezeichnen .

47 Produkte unterstützen die Nachrichten Druckfunktion in Edifact- und/oder Inhouse-Formaten. 49 verfügen über Logprints. Viele Produkte nehmen für sich in Anspruch, über benutzergerechte Druckformate zu verfügen, haben aber häufig nur wenige Parameter für Druckformate.

Konvertierung: Die Konverter in den EDI-Produkten handeln meistens die Standards GTDI, ANSI.X12 und/oder Edifact ab. Die meisten der angebotenen Produkte benutzen für die Ein- und Ausgabe von Inhouse-Formaten sogenannte Flat Files, die eine einfache meist in der Edifact-Struktur oder Reihenfolge der Edifact-Segmente sequentielle Datei darstellen. Wenige unterstützen ein Anwendungsprogramm-Interface, das der Applikation erlaubt, die Routine, die die Nachricht bildet, abzurufen.

Viele Produkte werben für sich, nur wenige Restriktionen in Sachen Satz- und Segmentfolge von Inhouse-Dateien zu haben. In der Regel trifft dies aber nicht zu, weil die meisten Konverter als Inhouse-Format Edifact-Segmente in den Flat Files haben.

Gruppierungs- und Split-Funktionen beinhalten 60 Prozent der Produkte. Einige bilden die erforderlichen Service-Segmente, Referenz- und Kontrollnummern. 40 Produkte fügen die Qualifier bei der Erstellung der Edifact-Nachrichten hinzu, 42 unterdrücken die 8 Qualifier beim Erstellen des Inhouse-Formats (nach dem Empfang). Die Konvertierung von eigenen Codes in internationale Edifact-Codes und umgekehrt gewährleisten 50 Produkte. Nur wenige bieten die Umwandlung von EBCDIC-Zeichen und ASCII sowie umgekehrt.

Kommunikation: Konvertoren verfügen über keine Kommunikationsmöglichkeiten. Deshalb ist für eine Workstation nur die externe Kommunikation vorgesehen. Die Gateways beinhalten interne, aber auch externe Kommunikationsmöglichkeiten. Die externe Kommunikation basiert zu 80 Prozent auf X.25. Eine X.400-Kommunikationsschnittstelle war bei den Produkten nicht vorhanden. 14 Anbieter planten in den nächsten sechs Monaten die X.400-Kommunikationsschnittstelle

- mittlerweile müßte sie also zur Verfügung stehen.

50 Produkte unterstützen die Schnittstelle zu einem VAN, 41 Interfaces zu mehreren VANs. 44 Produkte realisierten eine Direktverbindung. Die am häufigsten verwendeten VANS sind GEIS, IBM, INS, PTTs, AT&T/ ISTEL. Zur internen beziehungsweise externen Kommunikation werden Standardmodule verwendet, wie zum Beispiel Procmp, Kermit, Decnet, SNA oder von VANs gelieferte Module, die in die Produkte integriert sind.

Management: 80 Prozent aller Produkte können selbst installiert werden. Manche liefern auch die Edifact-Tabellen und Standardnachrichten zur Selbstinstallation. Die Maintenance der Tabellen kann selbst durchgeführt werden Netzwerk-Manager erhalten Änderungen der Partner und Netzwerkprofile über die installierten Netzwerkmodule.

Stand-alone-Konverter besitzen keine Help-Screens. Inhaltsspezifische Help-Screens bieten 41 Produkte an, 29 Produkte haben die Möglichkeit, die Screens selbst zu gestalten. Bei 60 Prozent der Produkte sind die Screens und die Dokumentation der Software in der Muttersprache der Anwender.

Die Sicherheitsaspekte der Kommunikation werden eher stiefmütterlich behandelt. 44 Produkte verfügen über eine Zugangskontrolle, nur ein Prozent unterstützt "Badge Readers". 27 Produkte kontrollieren die eingehenden Nachrichten auf ihre Echtheit. 19 Produkte machen einen Check von eingehenden Acknowledgements, sechs verfügen über Encryption-Mechanismen. 25 Prozent der Anbieter wollen ihrer Software diese Funktion hinzufügen.

Um die Systemsicherheit der angebotenen Software ist es dagegen besser bestellt: 45 Produkte unterstützen Fehler-Recovery, 37 automatisches Backup und 26 automatischen Restart.

Allerding bietet nur ein Produkt die Möglichkeit, Reports von Fehlern zu erstellen. Dagegen ist die Rückweisung der Nachrichten oder Segmente im Fehlerfall bei allen Erzeugnissen der Normalfall Sie verfügen auch fast alle über Log Files und Statusangaben. Log Files der Nachrichten bieten dagegen nur zwei Drittel der Softwarepakete an.

52 aller Produkte realisieren den unbeaufsichtigten Betrieb, einige davon auch den unbeaufsichtigten Betrieb von einer Batch Verarbeitung, zumindest für eine bestimmte Zeit. Keines der Erzeugnisse realisiert je doch den dauernden parametergesteuerten unbeaufsichtigten Betrieb, bei dem der Status der Konvertierung und der Kommunikation zyklisch verarbeitet wird. Zwei Produkte verfügen über ein API (Application Program Interface).

Preise: Die Preise schwanken, so das Ergebnis der Studie, sehr stark, egal in welchem Hardwarebereich. Reine Konvertoren sind in einer Preisspanne zwischen 1500 und 4000 Mark auf PC-Basis erhältlich. Konvertoren auf Mainframe Basis liegen zwischen 6000 und 10 000 Mark. Die Stand-alone-Kommunikation kostet je Modul zwischen 350 und 500 Mark.

Data Entry-Software auf PC Basis wird zwischen 2000 und 3000 Mark angeboten. Gateway-Software auf PC-Basis ist je nach Komfort und Umfang zwischen 5000 und 15 000 Mark zu haben. Volle Workstation Software auf PC-Basis beläuft sich auf 7000 bis 15 000 Mark.

Bei der Performance pendeln die Werte zwischen 0,12 KB/s bis 8 KB/s Der Durchschnittswert liegt bei 2,7 KB/s. Die Lieferanten stammen aus allen europäischen Ländern, wobei aus Südeuropa nur wenige Lieferanten auf dem Markt sind.

Abschließend noch ein Wort zur Vorgehensweise der Softwarehersteller. Viele Hersteller berücksichtigen erst mit der Zeit die Anforderungen der Anwender und ergänzen nach und nach ihre schon vorhandenen Produkte. Einige Softwarehersteller designen ihre Produkte nach den Wünschen bestimmter Kundengruppen. Generell läßt sich feststellen, daß die Hersteller viel Arbeit und viele Funktionen in den sogenannten Kern der Software (Konverter) investieren, aber zuwenig in die umliegenden Funktionen, die Qualität, Flexibilität und Benutzerfreundlichkeit der Produkte ausmachen.