Industrie, Handel und Administration werden immer stärker von der Computertechnologie und deren Anwendungen beeinflußt. Obgleich bei der Entwicklung von Applikationen, Systemen und Verfahren Freiräume bestehen, geht die Tendenz in Richtung Normierung. Ein Beispiel ist der ISO-Standard 9345 Edifact, mit dem sich Heiko Mehnen in diesem Artikel befaßt.
Nach den ersten Jahren der Einführung und Life-Anwendung zeigt sich, daß es richtig war, gerade auf dem Sektor des automatisierten Datenaustausches, international als EDI bezeichnet, den Standardisierungsaspekt zu berücksichtigen und durchzusetzen. Es zeigt sich auch, daß es sich bei Edifact um einen der bedeutendsten Standards in der Geschichte der internationalen Normierung handelt. Die Gründe:
- alle Staaten beschäftigen sich damit,
- alle Branchen sind davon betroffen,
- ein Heer von Fachleuten ist mit der koordinierten Einführung in aller Welt befaßt.
Doch wie sieht nun die Erfahrung aus, hat sich Edifact bewährt oder muß eventuell schon etwas geändert werden? Im großen und ganzen kann man diese Frage positiv beantworten. Sicher wird es irgendwann in der Zukunft eine auf der Basis der gemachten Erfahrungen verbesserte Syntax geben, doch dies wird voraussichtlich noch eine ganze Zeit dauern. Wir haben dabei noch eine Menge zu lernen, denn es hat sich gezeigt, daß der Weg der Einführung von Edifact ein schwieriger und für manche auch noch ein sehr mühsamer Weg war und ist.
Nachdem nun jedoch seit dem Beginn der ersten Life-Anwendungen Edifact bei, vielen Unternehmen in aller Weit zur Routineanwendung gehört, ist es möglich geworden, über Erfahrungen in der Einführung, der Anwendung im betrieblichen Alltag sowie über abgeschlossene, laufende oder sich in Vorbereitung befindliche Pilotprojekte in aller Welt zu berichten.
Aus diesem Grunde soll hier auf die verschiedenen Softwarelösungen zur Anwendung des Standards, die verwendeten Messages, Fragen der Ausbildung und Beratung auf die Notwendigkeit von Datenbanken, die Datenbank- und Messagepflege, Wartung und Service sowie auch kurz auf die verwendeten Telekommunikations-Dienste und Protokolle eingegangen werden.
Entsprechend der Situation innerhalb der Betriebe sowie der jeweiligen Anforderung existieren Softwarelösungen für die unterschiedlichsten Hardware-Betriebssysteme, vor über den Mini bis hin zu den verschiedenen Mainframe-Systemen. Hierbei haben sich aufgrund industrieller und administrativer Forderungen drei prinzipiell unterschiedliche Softwaregrundtypen herauskristallisiert:
- Software, die ausschließlich für die PC-Anwendung vorgesehen ist,
- Software, die für die PC- als auch für die Mainframe-Anwendung entwickelt wurde,
- Software, die sowohl nur für einen bestimmten Hardware-Mainframe-Type entwickelt wurde.
Die größte Vielfalt an Anwendungslösungen der unterschiedlichsten Anbieter zeigen natürlich die PC-Entwicklungen der erstgenannten Kategorie. Aber auch hier liegen noch eine Reihe unterschiedlichster Entwicklungskonzepte zugrunde.
Zum einen gibt es Lösungen, bei denen die Gesamtfunktionalität in das Gesamtpaket integriert ist, zum anderen Lösungen, wo zusätzliche Funktionen in Modulbauweise mit einer Kernsoftware, die nur die Syntax realisiert, verbunden werden. Bei den Ergebnissen der Software mit Gesamtfunktionalität kann man wiederum unterscheiden in:
- Software, die nur der Standardaufgabe, der Konvertierung nicht standardgerechter Strukturen in die Standardstruktur, dient. Hierbei spricht man auch häufig von "flexibler Standardsoftware", da man damit sowohl unterschiedliche Nachrichten als auch unterschiedliche Inhouse-Strukturen verwenden kann;
- Software, die nur der Anwendung einer einzigen Nachricht gilt, hierbei jedoch häufig eine umfangreichere Nachverarbeitung auf die jeweilige Nachricht bezogen bietet. Bei derartiger Software handelt es sich um sogenannte "hardcoded" Lösungen mit fest vorgegebener Inhouse-Struktur, die dann der jeweilig nachgeschalteten Auswertung und Weiterverarbeitung dient;
- und schließlich Software, die gar kein Inhouse-System mehr benötigt, also eine Eingabemöglichkeit für die jeweiligen Nachrichteninformationen bieten muß. Man spricht in diesem Fall auch von "Stand-alone-Systemen". Es handelt sich dabei um Software, die dort zum Einsatz kommt, wo man seine Daten direkt über den Bildschirm eines PCs eingeben kann und sie dann als Standardmessage einem Partner zukommen läßt. Derartige Software-Entwicklungen bieten häufig eine Reihe unterschiedlicher Standardmessages zur Anwendung an.
Interessant ist, daß nicht immer die großen Firmen, die Konzerne, obgleich sie eine Vielzahl von Mainframe-Systemen verwenden, die Mainframe-Lösung bei EDI auch anwenden. Da EDI ein Bindeglied beziehungsweise ein System für die Verbindung nach außen ist, wird hier häufig ein PC verwendet.
Selbstverständlich haben die vielen am Markt angebotenen Lösungen auch ein ziemlich unterschiedliches Leistungsverhalten. Zum Teil hängen bestimmte Leistungen vom Entwicklungskonzept ab. Wird viel Funktionalität und Prüfungsverhalten integriert, wird die sogenannte Performance ungünstig beeinflußt. Ist weniger Funktionalität integriert, ist die Performance gut, man muß jedoch zusätzliche Funktionen durch hinzugefügte Zusatzmodule realisieren. Weiterhin stört eine umfangreiche integrierte Funktionalität die Anpassung an unterschiedliche Rechnersysteme.
Den Beweis dafür hat kürzlich eine von einer Universität durchgeführte Untersuchung erbracht, bei der aufgrund der eben angeführten Sachverhalte zum Beispiel Performance-Unterschiede gemessen wurden, die man gar nicht mehr prozentual vergleichen kann. Sie lagen bei einer vorgegebenen Menge von Daten zwischen vier Minuten und über sieben Stunden. Eine Analyse von Software auf diesem Gebiet ist also mit großer Vorsicht zu betrachten. Da bei der Software-Entwicklung unterschiedliche Konzepte zugrunde liegen können, kann es leicht passieren, daß bei einer solchen Untersuchung Äpfel mit Birnen verglichen werden.
Eine ähnliche Situation wie bei der PC-Software besteht bei den Mainframes. Auch hier gibt es sowohl dedizierte Lösungen für einen bestimmten Rechnertyp, häufig vom jeweiligen Hardwarehersteller selbst entwickelt, als auch Standardlösungen mit modularen Zusatzpaketen. Der Vorteil von Standardlösungen mit zusätzlichen Funktionsmodulen liegt darin, daß durch die Zusammenstellung passender Module häufig eine für den Kunden maßgeschneiderte Lösung zusammengestellt werden kann.
Mittlerweile ist also eine Vielfalt an Systemen entstanden, die den Kunden die Auswahl schwer macht. Eines zeigt sich dabei immer wieder: Der Preis ist auf jeden Fall nicht Maßstab für die zu erbringende Leistung beziehungsweise die Qualität eines Produktes. Eine ganz bedeutende Rolle spielt zusätzlich außer der jeweiligen Softwareleistung auch die Betreuung, das Training, die Wartung und häufig auch die kundengerechte Installation. Edifact-Software oder das diese Software vertreibende Softwarehaus sollten gerade unter diesen Gesichtspunkten bewertet werden. Hier gibt es auch "schwarze Schafe" und sogenannte "Trittbrettfahrer".
Diese letzten Bemerkungen machen deutlich, daß es notwendig wird, eine Software-Prüfstelle einzurichten, eine Einrichtung, die ein Zertifikat erteilen kann, wobei es sicher schwierig wird, das Prüfspektrum für Edifact-Software festzulegen, insbesondere dann wenn man eventuell Zusatzfunktionen oder Funktionsbausteine berücksichtigen will.
Aufgrund der internationalen Zusammenhänge und Verbreitung ist beabsichtigt, daß sich die EG-Kommission dieser Sache annimmt. Der Kommission ist diese Forderung schon seit langem bekannt, doch hat sie beziehungsweise die dafür zuständige Stelle aufgrund interner Querelen auf diesem Sektor bisher nichts unternommen. Wenn die EG-Kommission weiter versagt, wird sich eine andere Institution dieser Sache annehmen. Erste Anzeichen dafür sind schon zu erkennen.
Die Mitarbeiter des Edifact-Boards in Brüssel sowie die der Message-Design-Gruppen kennen das Spektrum an Nachrichten, das derzeit in den verschiedenen Branchen genutzt wird, sich in Entwicklung befindet oder noch vorgesehen ist. Es sind mittlerweile fast hundert Nachrichten bekannt, die auch größtenteils in Brüssel beim dortigen Edifact-Board zur Registrierung gemeldet wurden.
Prinzipiell kann man fünf Nachrichtenarten unterscheiden:
- die echten UNSMs, das heißt die von der UNO empfohlenen Nachrichten, die international abgestimmt sind und einen offiziellen Entwicklungsgang mit bestimmten Stadien, offiziell als Status bezeichnet, durchlaufen haben;
- Nachrichten, die auf den echten UNSMs basieren, sich jedoch auf ein vereinbartes Maß an Informationsinhalt beschränken. Hier spricht man von sogenannten Subsets. Zu dieser Nachrichtenart gehören auch Nachrichten, die wohl auf den UNSMs basieren jedoch anwendungsbezogene Änderungen aufweisen;
- Nachrichten, die nur zur Anwendung innerhalb einer bestimmten Branche vorgesehen sind. Hierbei kann es sein, daß diese Nachrichten entweder nur innerhalb der Branche veröffentlicht werden oder ebenfalls aufgrund ihrer Bedeutung und internationalen Charakters UNSMs werden sollen;
- Nachrichten, die innerhalb eines Unternehmens oder einer Unternehmensgruppe intern verwendet werden, eine eigene Struktur aufweisen und die Edifact-Syntax nur als Mittel für eine standardisierte komprimierte Dateistruktur verwenden, wobei jedoch die zusätzliche Verwendung von Standardmessages für die Auswahl des Edifact-Standards maßgebend ist;
- Nachrichten, die auf Standardnachrichten anderer EDI-Systeme basieren wie VDA, Sedas, Iata, Swift etc. Bei derartigen Nachrichten kann zum Beispiel die Edifact-Syntax als Bindeglied beziehungsweise Hilfsstruktur zwischen Inhouse-System und verwandtem Standard dienen, wobei sich als automatischer Vorteil ergibt, daß sowohl ein fremdes Standardsystem als auch Edifact verwendet werden kann.
Die genannte Vielzahl an schon verabschiedeten, sich in der Entwicklung befindlichen und geplanten Nachrichten zeigt, daß sich viele unterschiedliche Branchen mit Edifact befassen. jede Standardnachricht, die man unter Zuhilfenahme eines Formulars zusammenstellt und übermittelt, kann für Edifact verwendet werden. Dies läßt die nahezu unbegrenzte Einsatzmöglichkeit dieses Standards erkennen.
Datenbanken und Nachrichtenpflege
Jedem, der sich ein wenig mit Edifact befaßt hat, ist bekannt, daß eine Nachricht aus einer Reihe von Bausteinen besteht. Zu ihnen gehören die Datenelemente, Codes und Segmente. Diese Bausteine sind zum großen Teil ebenfalls standardisiert und in Verzeichnissen und Datenbanken aufgenommen worden, die dann den Nachrichten-Entwicklern als Basis für ihre Entwicklungen dienen. Die Konzeption von Nachrichten an verschiedenen Orten und in verschiedenen Branchen hat gezeigt, wie nützlich und notwendig derartige Verzeichnisse sind. Eines ist bei Nutzung der Verzeichnisse jedoch zu beachten: Die standardisierten Bausteine dürfen nicht verändert werden!
Leider jedoch haben viele Nachrichten-Entwicklungsgruppen in der ersten Euphorie, endlich einen Standard für EDI auch für ihre Branche zu haben, wenig Disziplin gewahrt und diese Bausteine doch moduliert. Dabei entsteht so lange kein Schaden, wie man in seinem eigenen Bereich bleibt und alle in diesem Bereich dieselbe unmodifizierte Nachricht nutzen. Geht man aus diesem Bereich heraus, was ja auch Sinn von Edifact ist, dann gibt es jedoch Probleme.
Hierzu ein Beispiel:
In jeder Edifact-Message werden sogenannte User-Segmente verwendet. Ein typisches Beispiel aus der Praxis ist das LIN-Segment zur Aussage von Eigenschaften, Menge und Preis eines Produktes, für das zum Beispiel eine Rechnung erstellt werden soll.
Selbstverständlich haben Automobilteile andere Eigenschaften beziehungsweise Verrechnungseinheiten als Textilien und diese wiederum andere als die Produkte, die eine Ölgesellschaft abrechnet.
Die verschiedenen Nachrichten-Entwicklungsgruppen haben nun derartige Segmente nach eigenem Gutdünken geändert, was dazu führte, daß es für ein und dasselbe Segment mit einem Mal mehrere Ausprägungen gab.
Dies ist wie gesagt kein Beinbruch, solange man in der eigenen Branche bleibt. Nur muß ein derartiges Segment dann eine andere Bezeichnung, in der Fachsprache einen anderen TAG, erhalten. Da dies nicht erfolgte, wurde in einer Gewaltaktion eine Aktion "Saubermann" durchgeführt.
Sicher muß man bei einer so. genannten Bereinigungsaktion auch vorsichtig sein und das Fachwissen der Branchenexperten berücksichtigen. Ein Speditionsunternehmen hat zum Beispiel bei gleichem Segmentsachverhalt einen anderen Informationsbedarf als der Zoll oder das bestellende Unternehmen.
Bereinigungsaktionen wird es daher immer geben, wahrscheinlich nicht in der umfangreichen Form wie das letzte Mal, jedoch sicherlich in bestimmten vereinbarten Abständen. Natürlich ändern sich damit auch die Verzeichnisse und Datenbankinhalte. Nachrichten-Entwickler sollten sich daher immer auf die neuesten Ausgaben beziehen. Datenbanken für Edifact-Bausteine, aber auch Nachrichten sind an verschiedenen Stellen eingerichtet, beim DIN die sogenannte "DIN-Datenbank", in Brüssel die "Cebis"-Datenbank, eine Datenbank bei der UNECE in Genf sowie einige Datenbanken außerhalb Europas. Manche dieser Datenbanken bieten fertige Message-Definitionen zur Übernahme in die jeweiligen Softwarepakete, ein Angebot, das solche Edifact-Anwender nutzen sollten, deren Softwarepaket nicht automatisch diesen Service beinhaltet.
Als einer der "Noch"-Schwachpunkte innerhalb der EDI-Einführung kann man die Situation bei der Protokollauswahl und der Wahl des richtigen Postdienstes ansehen. Hier gibt es noch zu viele Auswahlmöglichkeiten und vor allem leider keinen für alle einheitlichen Standard wie Edifact.
Störend wirkt sich auch die unterschiedliche Situation in der technischen Entwicklung der Übertragungsmedien und -Techniken aus. So ist Osteuropa in bezug auf technische Entwicklung und Einsatzmöglichkeiten von EDI weit zurück. In den USA streiten sich viele private Telefongesellschaften um den Markt.
In Westeuropa sieht die Situation noch am günstigsten aus. Hier sind die verschiedenen "Posthoheiten" in den einzelnen Staaten mit ihrer zum Teil sehr restriktiven Politik jedoch noch ein Störfaktor. Durch Verständnis für EDI, insbesondere der Forderungen durch und für Edifact, ändert sich diese Situation jedoch derzeit. Beispielgebend kann man die Deutsche Bundespost mit ihrer Generaldirektion Telekom nennen, die die Zeichen der Zeit erkannt hat und national wie international auf die Edifact-Entwicklung setzt.
Bezüglich der Dienste-Situation kann man sagen, daß sich weltweit die X.25-Netzanwendung durchsetzen wird. Bei den Protokollen wird das X.400-Protokoll in Zukunft zu den maßgebenden Standards gehören, wobei zu sagen ist, daß auf dem PC-Sektor dieses Protokoll wegen seiner "Mächtigkeit" und dem Preis wohl nicht so schnell zum Zuge kommen wird. Hier wird sich ein Protokoll durchsetzen, nennen wir es in Anlehnung an das X.400-Edifact-Protokoll "Pedi" "P-Edifact", das schon vorhandene Protokollentwicklungen für die Edifact-Anwendung wie das OFTP für die Automobilindustrie mit abdeckt.
Ebenfalls geeignet und für Edifact erfolgreich auf PC-Basis getestet ist das Teletex-Protokoll. Es ist ein Protokoll, das schon Edifact-Parameter besitzt und in verschiedenen Postdiensten innerhalb X.21, X.25 oder auf der Wählleitung Verwendung finden kann. Zum Dienste- und Protokoll-Übergang sowie für die Durchführung gewisser Serviceleistungen wie zum Beispiel Message-Verteilungen wird man sich jedoch weiterhin der bekannten VANS wie Geis, IBM-IE oder auch der Telebox der Telekom bedienen.
Ausblick: Wie anfangs gesagt, wird Edifact schon an vielen Orten der Welt im Life-Betrieb genutzt. Manche Branchen fangen momentan mit ersten Tests an, andere bekunden die Absicht, Pilotprojekte durchfuhren zu wollen. Noch ist alles aufgrund der genannten Unterschiede und Probleme etwas "holperig" und zum Teil "unausgegoren", eine Situation, die man mit etwas besserer Organisation und vor allem Information verändern muß und kann.
Außerdem wird es auf der Basis gemachter Erfahrungen auch neue Generationen von Softwarelösungen geben, die ebenfalls vieles Verleichtern werden. Als beispielhaft hierfür wäre zum Beispiel die bildschirmorientierte Edifact-Anwendung zu nennen, die man schon als ein Teil einer nächsten Softwaregeneration bezeichnen könnte. An all dem Genannten wird in den verschiedenen an der Entwicklung beteiligten Institutionen gearbeitet. Der Effekt der Standardisierung wird dabei immer im Vordergrund stehen.
Heiko Mehnen ist Geschäftsführer der Gesellschaft für Logistik und Informations-Systeme mbH in München.