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.

23.10.1992

EDI: Ohne Edifact droht die Kleinstaaterei wie anno 1648

Was bedeutet konzeptioneller EDI-Einsatz für die Unternehmen und was wäre EDI ohne Edifact? Diesen beiden Fragen versucht Eberhard Franke* nachzugehen. Im Zeichen des EG-Binnenmarktes und grenzüberschreitender Kommunikation bleibt derjenige außen vor, der sich, so der Autor, dem Thema EDI ganz verschließt oder es versäumt, rechtzeitig entsprechende Maßgaben in sein IT-Gesamtkonzept einzubinden. Orientierung bietet hier die weltweit gültige Edifact-Normierung, die sich - trotz aller Handicaps und Sonderwege diverser Branchen - als alternativlos erwiesen hat. Daß die Verwendung von Edifact-Standards nicht nur ein Luftschloß, sondern bereits Realität ist, zeigt das Fallbeispiel Mercedes-Benz.

EDI hat seinen eigentlichen Ursprung in der Datenfernübertragung (DFÜ). Da dieser Terminus - gerade auch für angelsächsische Ohren - ein wenig plump klingt und zusätzlich schwer auszusprechen ist, wandte sich die englischsprachig orientierte DV-Welt schnell dem Begriff EDI (Electronical Data Interchange) zu. Unabhängig davon besteht jedoch ein nicht unerheblicher inhaltlicher Unterschied zwischen beiden Begriffen .

DFÜ bedeutet in der Regel Datenübertragung von einem entfernten Standort aus. Darunter versteht man im einfachsten Fall auch die Weitergabe erfaßter Bildschirmdaten über eine öffentliche Leitung in ein spezielles Anwendungsprogramm eines zentralen Computers. EDI hingegen grenzt die Datenübertragung weiter ein und beschreibt den Austausch strukturierter Daten beziehungsweise kompletter Nachrichten zwischen Computern auf unterschiedlichen Kommunikationswegen.

In dieser EDI-Definition fehlt mit Absicht der Zusatz "unternehmensübergreifend", jedenfalls dann, wenn vom Datenaustausch gesprochen wird. Grund dafür ist die Tatsache, daß es sich heute für Unternehmen mit mehreren, räumlich voneinander getrennten Standorten lohnt, auch intern Daten im Sinne von EDI auszutauschen. Eine weitere Leistung des EDI-Begriffes ist die Trennung zwischen strukturierten Daten und der Strukturierung von Daten.

Babylonische Sprachverwirrung

Dies führt häufig zu Verwirrungen- selbst bei Diskussionen zwischen Fachleuten. Versteht ein Experte unter EDI hauptsächlich technische Kommunikationskomponenten-zum Beispiel Übertragungsprotokolle-, legt sein Diskussionspartner möglicherweise viel größeren Wert auf das Verständnis der zu übertragenden Daten und die damit verbundenen Probleme. Beide verwenden aber den gleichen EDI-Begriff.

EDI wird in Deutschland schon seit fast 20 Jahren betrieben. Erste Anwendungen entstanden aufgrund nationaler, branchenspezifischer Anforderungen, die dann in der Folge als Standards-jeweils gültig für eine spezielle Branche- festgeschrieben wurden. Am weitesten verbreitet sind derzeit die Standards VDA (Automobilindustrie) und Sedas (Handel).

Nationale Standards stoßen jedoch im Geflecht internationaler Handels-und Produktionsbeziehungen sehr schnell an ihre Grenzen. Verschiedene Branchen bemühten sich daher, einen europäischen Standard zu schaffen, zum Beispiel "Odette" für die Automobilindustrie. Die bis dato letzte Stufe einer internationalen Normierung erklommen die Beteiligten 1987 mit der Verabschiedung des weltweit gültigen Datenaustausch-Standards Edifact (Electronic Data Interchange for Administration Commerce and Transport-ISO 9735). Dabei wurden zunächst die Syntaxregeln veröffentlicht, gefolgt von einigen gängigen Nachrichtenarten wie Rechnung und Bestellung. Gegenwärtig befinden sich mehr als 30 Nachrichtentypen in einem relativ "stabilen Entwicklungszustand", 40 bis 50 weitere in der Entwicklungsphase (sogenannter "Status 0").

Was bringt einem Unternehmen die Einführung von EDI? Die Bandbreite der Vorteile variiert von Unternehmen zu Unternehmen, vor allem aber die exakte Quantifizierung einzusparender Kosten- ein Sachverhalt, der immer wieder kontrovers diskutiert werden wird.

Kosteneinsparung und Leistungssteigerung lassen sich in erster Linie durch Parameter wie erhöhte Lieferbereitschaft und verringerte Reaktionszeit, verkürzte Angebotsstellung und eine frühzeitigere Rechnungsstellung erzielen. Hinzu kommen Faktoren wie die Reduktion von Porto-und Papierkosten sowie Erfassungsfehlern, eine Vereinfachung organisatorischer Abläufe und die mögliche Anbindung an Just-in-Time-Konzeptionen mit Vorteilen wie kürzeren Beschaffungszeiten, niedrigeren Lagerbeständen und geringerer Kapitalbindung.

Zusätzlich zu all diesen Argumenten gibt es jedoch noch mindestens einen weiteren wichtigen Grund, sich-vor allem auch vorab-mit dem Thema EDI zu befassen: Der immer stärker werdende Informationsbedarf der Kunden, die immer öfter den Austausch geschäftlicher Informationen auf elektronischem Wege wünschen oder sogar fordern. Trifft diese Forderung auf eine unvorbereitete DV, ist die dann herzustellende "EDI-Fähigkeit" des Unternehmens in der Regel mit immensen und auch teuren Anlaufschwierigkeiten zu bezahlen.

Politik der kleinen Schritte

Eine solche Situation ist für jedes Unternehmen vermeidbar, das sich frühzeitig mit dem Thema auseinandersetzt und die Anforderungen in ein IT-Gesamtkonzept einbindet (Stichwort: Strategische Zielsetzung). Die erfolgreiche EDI-Einführung gelingt

dann meist über eine Politik der kleinen Schritte, was unter anderem auch bewirkt, daß Rationalisierungspotentiale ohne den in der Regel schmerzhaften Anpassungsprozeß erschlossen werden können.

Angesichts der genannten Kostenvorteile bei Einführung und Nutzung von EDI ist jedoch auch der zu erwartende Aufwand einzukalkulieren. Kosten entstehen in erster Linie durch Investition in eine entsprechende Konverter- und Kommunikationssoftware

sowie deren Implementierung und Anpassung an bestehende Applikationen, die Neugestaltung der Aufbau-und Ablauforganisation, die Einführung zusätzlicher Datenschutz-und Sicherheitsmaßnahmen sowie durch Leitungs-und Übertragungsgebühren

Neben diesen direkt zuordbaren Faktoren sollten jedoch immer auch unternehmenspolitische Ansätze in die Planungen miteinbezogen werden. Dabei gilt es vor allem zwei Fragen zu klären: Begibt sich das Unternehmen in eine Abhängigkeit vom jeweiligen EDI-Partner und sind "Zwangsanpassungen" an organisatorische Abläufe bei diesem Partner denkbar ?

An dieser Stelle hilft vielleicht ein Blick in die Geschichte von EDI. Die Entwicklung im EDI-Markt ging zunächst von einseitig ausgerichteten, unabhängigen Informationsströmen zwischen den beteiligten Partnern aus. Exemplarisch ist die Bestellung, die vom Kunden an den Lieferanten gerichtet wird, woraufhin dieser nach erfolgter Lieferung die Rechnung ebenfalls auf elektronischem Wege dem Kunden zustellt. Beide kommerziellen Nachrichtentypen sind sich zwar inhaltlich und über die Bestellnummer zugeordnet, stellen aber im datentechnischen Sinne vollkommen eigenständige Informationstypen dar und repräsentieren spezielle Applikationen, die nicht miteinander kommunizieren können.

In einem weiteren Entwicklungsschritt wurden inhaltlich verbundene Informationen auch datentechnisch verknüpft. Als Beispiel seien hier die Abläufe innerhalb der Materialdisposition genannt. So differenziert etwa der VDA zwischen dem Lieferabruf

(VDA 4905), dem Feinabruf (VDA 4915) und dem produktionssynchronen Abruf (VDA 4916). Alle drei Nachrichtenarten enthalten inhaltlich gleiche Daten, die sich auch aufeinander beziehen können, der Unterschied liegt ausschließlich in der zeitlichen Nähe zum Produktionsprozeß. Die verbindlichen Abrufe erfolgen also produktionssynchron, wobei alle vorherigen Informationen lediglich einen optimierten Rahmen liefern, innerhalb dessen sich die tatsächlichen Lieferungen bewegen.

Als dritte Stufe des EDl-Entwicklungsprozesses ist derzeit die Einbeziehung von Nachrichten absehbar, die zu einer engen Verzahnung der Unternehmensprozesse mit Kunden und Lieferanten führen werden, zum Beispiel durch die Tatsache, daß Lieferanten durch eine Betelligung an Konstruktion und Entwicklung zunehmenden Einfluß auf das Endprodukt gewinnen. Schon allein der gesetzliche Zwang zur Produktdokumentation verpflichtet die Hersteller zu einer jederzeit abrufbaren Datenhaltung. Ähnliche Anforderungen wird der Kunde stellen, wenn er nicht sogar ebenfalls aktiv am Entwicklungs- und Konstruktionsprozeß beteiligt ist und auf einer schnellen und umfassenden Verfügbarkeit der Daten besteht.

Der elektronische Datenaustausch mit zulässiger Änderung von Dateninhalten "hüben wie drüben" wird in solchen Fällen zu einer unverzichtbaren Voraussetzung.

Das eben beschriebene Szenario ist bereits in vielen Bereichen der Status quo. So entschied man sich schon 1988 bei der Mercedes-Benz AG für die Verwendung des Edifact-Standards beim Austausch von Qualitätsdaten. Zunächst trat dort die Frage der

Realisierung eines Informationsaustausches innerhalb eines Standortes beziehungsweise einer Produktionsstätte auf, wo DV-Systeme verschiedener Hersteller miteinander kommunizieren können sollten.

In einem weiteren Schritt sollten standortübergreifend mehrere Produktionswerke den Austausch von Fehlerinformationen für Gleichteile praktizieren können. Ferner bestand die Anforderung, Erstmusterprüfungen nur noch einmal im Konzern durchführen

zu müssen. Letztlich sollte auch der Austausch komplexer Qualitätsinformationen mit Kunden beziehungsweise Lieferanten in Angriff genommen werden, um Transportzeiten und Postlaufwege entsprechend zu minimieren und die angestrebte Just-in-Time-Abwicklung

auch im Qualitätswesen zu etablieren.

Alle drei genannten Probleme waren durch den Einsatz von Edifact lösbar. Um möglichst frühzeitig entsprechende Erfahrungen mit dem Edifact-Standard zu sammeln, entschlossen sich die Verantwortlichen bei Mercedes-Benz, zunächst die Schnittstellen-Inhalte Prüfplan, Prüfauftrag, Prüfergebnis und Prüfbericht zu vereinheitlichen. Dabei wurde eine neuzuschaffende Verbindung zwischen zwei Anwendungssystemen im Automobilbereich des Konzerns zur Umsetzung ausgewählt.

"Papier-Schnittstelle" ließ sich automatisieren

Im Qualitätssicherungssystem für Kaufteile (IQ-KWE) wurden aufgrund von Wareneingangsinformationen und systemimmanenten Steuerungsinformationen Prüfaufträge gebildet. Die Prüfungen erfolgen nun entweder direkt am Wareneingang oder bei einem anderen Aufgabenträger, beispielsweise der örtlich entfernten Werkstoffprüfung, während bisher die Prüfinformationen dort über einen Bildschirm angewählt und auf Papier ausgedruckt wurden.

Mit diesem Papierbeleg wiederum führte der Prüfer die vorgeschriebenen Messungen durch und notierte die erhaltenen Ergebnisse auf dieser Unterlage. Diese bestehende "Papier-Schnittstelle" ließ sich nun durch eine Neukonzeption unter Verwendung der Edifact Quality Message automatisieren.

Weniger Aufwand für Neuimplementationen

Die Prüfauftragsdaten werden dabei aus der Datenbank selektiert und als Inhouse-File auf bereitet (vgl. Abbildung auf Seite 46). Anschließend wird ein Edifact-Konverter aufgerufen, der aus dem Inhouse-File die Edifact-Datei generiert, die über das debis-Netz an das Werkstoffprüfsystem übertragen wird. Dort erfolgt die Übertragung der Daten- wiederum in einem Konverter- auf Inhouse-Format, was eine Weiterverarbeitung innerhalb des Anwendungssystems in der Werkstoff-prüfung ermöglicht.

Nach den vorgeschriebenen Messungen, die zum Teil auch auf Meßautomaten geschehen, erfolgt die Zurückspielung der Prüfergebnisse über eine anders strukturierte Edifact-Schnittstelle in das Wareneingangssystem. Die Gesamt-Schnittstelle ist so konzipiert, daß beliebige unterlagerte Systeme angebunden werden können. Durch die einheitlich verwendete Edifact-Norm ist es dabei möglich, Aufwände für Neuimplementationen von Schnittstellen in erheblichem Umfang zu reduzieren.

In einem weiteren Projekt wurde versucht, ein komplexeres Anwendungsproblem im Zusammenhang mit Edifact zu lösen. Dabei handelt es sich um Qualitätsdaten, die zwischen mehreren Produktionsstätten innerhalb des Konzerns ausgetauscht werden. Eines

dieser Werke dient als zentrale Verteilstelle der Informationen, das für die Versorgung der angeschlossenen Werke mit Fehler- und Prüfinformationen verantwortlich ist (vgl. Abbildung 2).

Im Einklang mit den DlN-Empfehlungen

Sämtliche Informationen basieren auf der einheitlichen Quality Message in Edifact, auch wenn nur Teile aus dem Gesamtumfang der möglichen Struktur verwendet werden. Diese vorgenommene Subset-Bildung steht in Einklang mit den Empfehlungen zur Verwendung einzelner Edifact-Nachrichten (DIN-Empfehlungen) und ist ein Weg, um redundante Datenstrukturen bei Übertragungen zu vermeiden.

Innerhalb der bisher realisierten Projekte entstanden nach unseren Erfahrungen auch Aktivitäten, die über den üblichen Projektrahmen hinausgehen. Dies betrifft sowohl das Analysieren der zu verwendenden Edifact-Message als auch die Herauslösung und Bildung eines verwendbaren Subsets aus dem Gesamtumfang der Message. Gleiches gilt für die Auswahl, Implementierung und Programmierung eines geeigneten Konverters und die Auswahl und Nutzung eines spezifischen Netzdienstes wie Telefon, ISDN, Datex-P,

Mark III etc.

Alle zusätzlichen Aktivitäten binden dabei Kapazitäten und Ressourcen, die dem realisierten Nutzen gegenüberzustellen sind. Für das einzelne Unternehmen rechnet sich die Verwendung einer speziellen EDI-Schnittstelle in den seltensten Fällen. Dies ist auch in der Vergangenheit immer schon ein besonderes Merkmal innovativer Dienste und Techniken gewesen. Eine Alternative bieten hier fertige Anwendungssysteme, also Standardprodukte. Außer den angesprochenen Konverters und deren Weiterentwicklungen

sind für die Ouality Message keine Softwarelösungen am Markt erhältlich, die den Ansatz von EDI und Edifact verfolgen.

Um hier gangbare Wege aufzuzeigen, haben, ausgehend von der Initiative eines VDA-Arbeitskreises, mehrere Firmen in enger Zusammenarbeit den Austausch von Qualitätsdaten im Edifact-Format versucht. Nach zunächst intensiven theoretischen Arbeiten zur Übertragung von Prüfberichtsinformationen in die Quality Message war man auch bemüht, die gewonnenen Kenntnisse in Form eines Prototyps in die Praxis umzusetzen. Auf diese Weise entstand eine PC-Applikation, die von den beteiligten Firmen einem Praxistest unterworfen wurde. Der Nachweis der Realisierbarkeit gelang somit, obwohl die Komplexität und der Anspruch des ausgewählten Testumfeldes sich als außerordendtlich hoch herausstellten.

Der Dateninhalt von Prüfberichten-speziell von Erstmusterprüfberichten-zeichnet sich durch die gleichzeitige Darstellung von Kunden und Lieferantendaten aus. In der Praxis bedeutet dies, daß zunächst beispielsweise der Lieferant die ermittelten Prüfdaten in das "Dokument" einträgt. Anschließend hat der Abnehmer, beziehungsweise der Kunde die Möglichkeit, Ergänzungen vorzunehmen-natürlich in ein und dasselbe Dokument, das ihm vom Lieferanten via EDI übertragen worden ist. Der Abnehmer spielt die

Daten an den Lieferanten zurück, damit dieser wiederum dazu Stellung nehmen kann. Dieser Informationsprozeß kann sich beliebig oft wiederholen.

Wie vorhin beschrieben, wurde hier eine EDI-Anwendung der dritten Generation entwikkelt und getestet. Die üblichen Funktionen einer DV-Anwendung wie das Erfassen, Ändern und Löschen von Daten werden in diesem Falle durch Konvertierung beziehungsweise Aufruf der Kommunikation mit Lieferanten und Kunden ergänzt. Darüber hinaus sind die üblichen Verwaltungsfunktionen von Stammdaten und Systemdaten vorhanden.

Weitere teilweise schon einsetzbare Ausbaustufen sind:

- die Integration von Bilddaten (Video und Zeichnungen),

- die Berücksichtigung von Fremdsprachen (europäischer Binnenmarkt),

- die Anbindung an überlagerte CAQ-Systeme auf HOST-Rechnern,

- die Anbindung unterlagerter Prüfsysteme (Meßdaten über Edifact-Schnittstelle),

- die Auswertung der vorhandenen Qualitätsinformationen.

Nach der Euphorie nun kritische Stimmen

Die gesamte Anwendung ist unter der grafischen Benutzeroberfläche Windows 3.0 entwikkelt worden und hält sich damit alle Optionen offen, die mit der Weiterentwicklung von Windows verbunden sind. Die notwendige Kommunikations-Schnittstelle ist so

konzipiert

daß sowohl preiswerte Punkt-zu-Punkt-Verbindungen als auch aufwendigere Übertragungsprotokolle wie beispielsweise das Odette-File-Transfer-Protokoll Benutzt werden können.

Nachdem das Thema EDI und speziell Edifact in der Vergangenheit mit großer Euphorie

diskutiert und begleitet wurde, mehren sich-vor allem seit dem letzten Jahr-auch die kritischen Stimmen. Bemängelt wird dabei vor allem der Anspruch von Edifact, eine Weltnorm zu sein-dies insbesondere angesichts seiner mangelnden Durchsetzungsfähigkeit

in Branchen mit bereits etablierten EDI-Standards wie VDA und Sedas.

Eine derartige Betrachtungsweise ist jedoch sicher nicht fair, denn die Meßlatte sollte nicht so hoch gelegt werden, daß ein Neuling von vornherein keine Chancen hat. Immerhin hatte ein Standard wie VDA fast 20 Jahre Zeit, sich zu entwickeln und

zu etablieren. Die praktische Verwendbarkeit der Edifact-Norm wird sich-und das ist ihre Chance-in all den Bereichen zeigen, in denen es, wie im Qualitätswesen, bisher keinen Standard gegeben hat. Gelingt es darüber hinaus, mehrere Branchen gleichzeitig

zur Verwendung eines abgestimmten Edifact-Subsets zu bewegen, ist mehr erreicht, als mit allen bisher entwickelten Standards zusammen.

Im Bereich der Qualitätsinformationen ist diese Harmonisierung zwischen der Automobil und der Chemiebranche vollzogen worden. Prüfberichte werden bei aller Differenziertheit in beiden Branchen prinzipiell identischen Edifact-Strukturen zugeordnet. Zur Zeit wird versucht, diese Harmonisierung mit weiteren Branchen (Stahl, Elektronik, Luft-und Raumfahrt) und auf europäischer Ebene durchzusetzen. Die internationale Dimension gewinnt zudem durch die mögliche Förderung im Tedis-Programm der EG an Boden. Eine Entscheidung über die Bewerbungen mehrerer Firmen aus unterschiedlichen Branchen steht noch in diesem Jahr an.

Gibt es also eine echte Alternative zu Edifact, wenn es darum geht, die Vorteile von EDI nutzen zu können ? Die eindeutige Antwort kann hier nur nein lauten. Nirgendwo sind Aktivitäten zu erkennen, die mit dem Edifact-Standard in bezug auf Normungsfortschritt und Nutzung in der Praxis Schritt halten können. Es wäre mit mindestens fünf Jahren Entwicklungszeit für jeden neuen Ansatz zu rechnen, um den heutigen Stand der Edifact-Normierung zu erreichen. Die Konsequenz wäre also ein Rückschritt in eine Zeit ohne branchen-und länderübergreifende Normungsvorgaben für die EDI-Technologie. Dies würde letztlich der Kleinstaaterei nach dem Westfälischen Frieden von 1648 entsprechen: 39 Zollgrenzen, viele Währungen, Behinderung des freien Güteraustausches und damit verbunden, wirtschaftliche Rückständigkeit.