Neben X.400 gilt die Weltnorm ISO 9735 Edifact als eine der zukunftsträchtigsten potentiellen VANS-Angebote auf dem Sektor der anwendungsnahen Dienstleistungen. Heiko Mehnen faßt in einem Überblick den derzeitigen Status des Standards zusammen und beschreibt die bisherigen Edifact-Erfahrungen.

Das überaus starke Interesse an der neuen Weltnorm ISO 9735 Edifact und die derzeit immensen Aktivitäten im Zusammenhang mit dieser Norm, weisen darauf hin, daß fast alle Bereiche der Wirtschaft schon sehr lange auf solch eine Norm gewartet haben, eine Norm, mit der es nun endlich möglich ist, den einheitlichen elektronischen Datenaustausch Realität werden zu lassen.

Leider reicht jedoch eine Norm wie Edifact, die nur die Struktur der per Telekommunikation zu übertragenden Dateien festlegt, allein nicht aus. Eine solche Norm ist nur anwendbar, wenn dafür zusätzlich verschiedene Voraussetzungen erfüllt werden, die derzeit von einem gewaltigen Team von Akteuren in der ganzen Welt erarbeitet werden.

Hierzu gehören:

1. die Entwicklung von Software zur Realisierung der syntaktischen Forderung für die Umsetzung interner Datenstrukturen in den Edifact-Standards;

2. das Erarbeiten definierter, wenn möglich international abgestimmter Nachrichten, wie zum Beispiel Bestellung, Rechnung, Lieferschein etc.;

3. die Entwicklung von Verzeichnissen (Directories) und Datenbanken für die Bausteine der Nachrichten wie Datenelemente, Segmente und die Nachrichten selbst;

4. Protokolle und Telekommunikationsmodule zur Übermittlung der in standardisierten Übermittlungsdateien enthaltenen Nachrichten.

Die Akzeptanz des Standards hängt dabei, wie wir haben feststellen können, im wesentlichen von zweien der genannten Voraussetzungen ab; von geeigneter Konvertierungssoftware und von den Nachrichten (Messages).

Die Entwicklung der Norm wurde parallel durch Softwareentwicklungen begleitet, wobei die Realisierbarkeit der Syntaxregeln softwaretechnisch getestet wurde. Aus diesem Grundlage mit Veröffentlichung des Edifact-Standards auch gleichzeitig Software zu dessen Anwendung vor. Eine der wichstigsten Voraussetzungen war also gleich zu Beginn der Normenveröffentlichung erfüllt, nämlich verwendbare Software.

Der Hauptschwachpunkt lag im Fehlen passender Nachrichten. Diese Voraussetzung, das Entwickeln von Nachrichten, war weitaus schwieriger zu erfüllen und vor allem zeitaufwendiger, lautete doch die Zielsetzung, gleich international abgestimmte Nachrichten sowohl branchenübergreifend als auch branchenneutral zu erhalten.

Obgleich die Entwicklung von Nachrichten zeitaufwendig ist, erklärten sich gleich zu Beginn dieser Arbeit, gedrängt durch den Bedarf der Wirtschaft, sehr viele Fachleute zu übernehmen. Heute ist weltweit ein Heer von Fachleuten dabei, Nachrichten zu entwickeln und alle weiteren Voraussetzungen zur effizienten Anwendung von Edifact zu schaffen. Die Prüfungsstellen für Nachrichten, wie zum Beispiel das Gremium für "Technical Assessment"

in Brüssel, verantwortlich für die Entwicklung in den EG- und EFTA-Staaten, werden derzeit überschüttet von Vorschlägen und Anträgen zu neuen oder zu prüfenden Nachrichten.

Da zu Anfang nur eine Nachricht zur Verfügung stand, nämlich die "Commercial Invoice", die allgemeine Rechnung, entschlossen sich viele Unternehmen, da sie nicht länger warten wollten, sei es intern oder in Benutzerkreisen, eigene Nachrichten zu entwickeln und anzuwenden. Es gibt eine ganze Reihe hervorragend auf dieser laufender Edifact Anwendungen auf dieser Basis.

Ein solches Vorgehen hat zwei Vorteile, man kann erstens schon unmittelbar beginnen und ist zweitens in der Lage, verabschiedete Edifact-Messages, da die Software schon implementiert ist, sofort anwenden beziehungsweise übernehmen zu können.

Andere Unternehmen wiederum wollten warten, bis eine gewisse Mindestanzahl empfohlener Nachrichten vorliegen würde. Eine dritte Gruppe, bestehend aus den Skeptikern, wollte erst einmal den Markt beobachten und sehen, ob andere damit auf die Nase fallen.

Eine interessante Feststellung bei der Akzeptanzfrage war, daß bei vielen Unternehmen der Entscheidungsprozeß von der ersten Kontaktaufnahme bis zum Schritt, Edifact einzufahren etwa ein Jahr dauerte. Nach der Entscheidung mußte es jedoch immer sehr schnell gehen.

Bei Veröffentlichung der Edifact-Norm war also sogenannte Basissoftware vorhanden, eine Software, die eine wesentliche Mindestvoraussetzung erfüllte: die syntaxkonforme Umsetzung von Dateien. Zusätzlich waren und sind weitere Programmteile, die nicht syntaxbezogen sind, sondern mehr mit den internen Abläufen und dem verwendeten Übertragungsprotokoll zu tun haben, zu entwickeln beziehungsweise einzusetzen.

Entsprechend der Grundforderung der Norm muß diese auf allen Computersystemen, unabhängig vom Betriebssystem, realisierbar und vom verwendeten Übertragungsprotokoll unabhängig sein.

Forderungen an die Software-Programme

Es entstanden Programme für die unterschiedlichsten Rechnertypen, für PCs, Minis und Mainframes, wobei aufgrund der verschiedenen Betriebssysteme und dem Verbreitungsgrad bestimmter Programmiersprachen in Industrie und Handel unterschiedliche Programmiersprachen wie Pascal, Cobol und C zur Anwendung kommen. Natürlich werden dabei zuerst Anpassungen an die verbreitetsten Rechnertypen und Betriebssysteme durchgeführt.

An die Software selbst wurden und werden in erster Linie folgende Forderungen gestellt:

1. leichte Einbindung in vorhandene Abläufe,

2. gute Performance (Schnelligkeit),

3. Durchführung von Syntax- und Fehlerkontrollen,

4. leichte und problemlose Nachrichtenimplementierung (Entwicklung, Änderung, Prüfung, Erfassung),

5. Nachrichten-Unabhängigkeit (Flexibilität) und nicht zuletzt

6. einfache Bedienbarkeit sowie ein guter Service (Schulung, Informationsdienst, Hotline etc.).

Dies sind nur die wesentlichsten Forderungen. Man kann natürlich im Zusammenhang mit der Verbindung zu den internen Abläufen noch eine Reihe weiterer Kriterien erfüllen, was bereits auch in zunehmendem Maße verlangt wird. Beispielsweise stellte sich heraus, daß zu Beginn der Arbeit mit den Softwareprogrammen in der Testphase einige zusätzliche Werkzeuge für Prüfzwecke und die manuelle Bearbeitung nützlich sind. Wurden derartige Programme erst nur beim Softwarehersteller verwendet, so stehen sie nun auch den Kunden zu Testzwecken zur Verfügung.

Bei Einführung von Edifact in den Unternehmen zeigte sich, daß für Message-Design und Softwareanwendung eine Schulung dringend zu empfehlen ist. Softwarehäuser mit Edifact-Software bieten daher eine entsprechende Schulung an, die in einigen Fällen bei Kauf der Software sogar kostenlos ist.

Nicht alle Variationen können getestet werden

Bei der Inanspruchnahme der Hotline konnte eine interessante Feststellung gemacht werden, unter der Softwarehäuser bei Einführung einer neuen Software generell zu leiden haben: Es ist die Schuldzuweisung, wenn etwas nicht funktioniert; wenn es klemmt, ist zuallererst immer die Software schuld. Sollte es so sein, würde es bedeuten, daß eine fehlerhafte Software ausgeliefert worden wäre, was in den meisten Fällen nicht der Fall ist. Zugegeben, eine neue Software, die zusätzlich auch noch ein neues Verfahren realisiert,

kann und wird Kinderkrankheiten aufweisen. Man kann nicht alle Variationen der Anwendung testen, insbesondere nicht bei Edifact mit den wirklich enormen Möglichkeiten vielseitiger Anwendung.

.Aufgetretene Fehler und Probleme hatten im wesentlichen folgende Hauptursachen:

- Flüchtigkeitsfehler bei der Definition und Eingabe der Message-Struktur 80 Prozent

- Fehlinterpretation der Syntaxregeln und der Message-Design-Guidelines 10 Prozent

- Fehlverhalten der Konvertersoftware durch falsche Protokollanbindung 5 Prozent

- Bildung nicht syntaxkonformer Zeichen in der Edifact-Datei durch das

Übertragungsprotokoll oder sonstige angeschlossene Programme 3 Prozent

- Die restlichen Fehler entfielen auf verschiedene Faktoren wie auch die erwähnten

Kinderkrankheiten zu Beginn der Softwareanwendung 2 Prozent

Die festgestellten Fehler, insbesondere die Flüchtigkeitsfehler, gaben wiederum Hinweise, welche Fehlerkontrollen schon während der Eingabe der Message-Definitionen gemacht werden können.

Zu den möglichen Verbesserungen gehören aber auch Vereinfachungen in der Anwendung wie zum Beispiel die Übernahme fertiger Nachrichtendefinitionen auf dem Telekommunikationsweg oder die automatische Kontrolle von empfangenen Edifact-Dateien mit automatischer Rückmeldung von Fehlern. Derartige Vereinfachungen oder Verbesserungen hängen jedoch wiederum von internationalen Vereinbarungen ab, da ja Softwareprodukte verschiedener Hersteller gleichermaßen damit arbeiten müssen.

In den Kreisen der Verantwortlichen in der Edifact-Entwicklung hat man dies erkannt und man arbeitet daran. Beispiele hierzu sind die Entwicklung einer Message- Definition-Message und die Control-Message zur automatischen Fehlerrückmeldung. Zu beiden Message-Typen liegen verschiedene Vorschläge auf dem Tisch.

Blick in die Zukunft

Was die weitere Entwicklung betrifft, wird sie auf dem Softwaresektor sowie auf der Anwenderseite folgendermaßen aussehen:

1. Es werden in Zukunft sicherlich mehr Unternehmen als bisher, Computerhersteller wie Softwarehäuser, Softwareprodukte zur Edifact-Anwendung anbieten.

2. Der Markt wird daher zu einem mehr optimierten und abgerundeten Edifact-Programmangebot übergehen, was bedeutet, daß Funktionen des Vorprocessing und des Nachprocessing soweit möglich integriert beziehungsweise adoptiert werden.

3. Man wird Protokollanwendungen, wie zum Beispiel solche mit X.400 oder Teletex, integrieren oder sie adaptieren.

4. Da die großen Industrieunternehmen, von denen die meisten schon Edifact haben, auch mit den kleinen Unternehmen, mit denen sie geschäftlich zusammenarbeiten, Edifact-Anwendungen betreiben wollen, wird es für diese Zwecke bildschirmorientierte Lösungen geben. Es handelt sich dabei um Software für Unternehmen, die keine umfangreiche Inhaus-Verarbeitung haben oder die ihre derzeitige nicht ändern wollen. Die gewünschte Nachricht wird als Bildschirmmaske dargestellt, die Daten manuell eingetragen und nach erfolgter Eintragung das Ergebnis als Edifact-Datei einem Partner per Telekommunikation zugeschickt.

5. Durch die zunehmende Verwendung von Edifact auch in staatlichen Institutionen wie zum Beispiel der Deutschen Bundespost oder im Zollwesen, bei den Banken und Versicherungen, ja sogar im Tourismus, wird es in kurzer Zeit zu einer gewaltigen Zunahme von Edifact-Anwendungen in der ganzen Welt kommen. Es wird für Unternehmen, die konkurrenzfähig bleiben wollen, eine "conditio sine qua non" sein, diesen neuen Standard zu nutzen.

Nachdem die Anwendung von Edifact vielerorts bestens funktioniert, wird nun der Schwerpunkt im Ausbau und in der Optimierung liegen. Hierbei werden auch organisatorische Aspekte bei der Programmentwicklung zu berücksichtigen sein. Einen großen Vorteil bei dieser Entwicklung werden dann insbesondere die Unternehmen haben, die schon in der Anwendung der Edifact-Norm haben Erfahrung sammeln können.

Hinweise zur Vermeidung von Fehlern bei der Edifact-Einführung und -Anwendung:

- Eine gründliche Vorbereitung für die Arbeiten zum Message-Design und für die Inhaus-Adaption ist durchzufahren.

- Die Struktur der Inhaus-Dateien und Datensätze sowie die entsprechende Struktur der Message auf der Edifact-Seite aufzeichnen und einander gegenüberstellen.

- Kurze Messages bilden mit nicht zu komplizierten Abläufen und Verschachtelungen.

- Falls eine große, komplizierte Message realisiert werden soll, erst einmal mit einer gekürzten Fassung oder einer kleineren Message Erfahrung sammeln.

- Die entsprechende Fachdokumentation wie die Design-Guidelines, die Softwaredokumentation und die in Frage kommende Message-Definition, falls verfügbar, genau studieren.

- Alle Eingaben sehr exakt und gründlich durchfuhren und mehrmals auf Flüchtigkeitsfehler untersuchen.

- Bei Mainframe-Anwendungen erst einmal einen "Trockentest" auf einem PC durchfuhren.