Die Osram GmbH, drittgrößter Lampenhersteller der Welt, hat 1984 im Bereich Logistik mit der EDI-Realisierung begonnen. Das Unternehmen tauscht heute Handelsdaten auf Basis der Standards "Sedas" und "VDA" mit seinen Kunden aus. Norbert Schweichler* beschreibt in diesem Beitrag die Entwicklung der EDI-Implementation bei Osram und gibt einen Ausblick auf den papierlosen Datenaustausch der Zukunft, auf Edifact.
Die Osram GmbH wickelt jährlich rund 1,4 Millionen Bestellpositionen ab. Die Zahl der Lieferschein- und Rechnungspositionen ist etwa gleich groß. Hinter einer Position können sich dabei sowohl einzelne Lampen als auch mehrere Paletten eines Typs verbergen.
Osram begann bereits in den siebziger Jahren damit, die Rationalisierungspotentiale in der Logistik systematisch zu nutzen. So führte der Lampenhersteller schon damals ein umfassendes Warenwirtschaftssystem (WWS) ein.
Auftragsbearbeitung, Disposition und Bestandsführung wurden weitgehend zentralisiert und automatisiert sowie die Bestände für Fertigerzeugnisse bei gleichbleibend hoher Lieferbereitschaft systematisch reduziert. Alle Warenlieferungen an Kunden im Inland sowie an ausländische Gesellschaften werden heute über zwei Lieferzentren realisiert, die in räumlicher Nähe zu den inländischen Werken in Augsburg und Berlin lokalisiert sind. Regionalläger oder Läger beim Spediteur betreibt Osram nicht mehr.
Zeitspanne bis zum Auftragseingang verkürzen
Der Einsatz einer zentralen DV, an die alle Werke, Verkaufsbüros und Lieferzentren angeschlossen sind, sowie moderner Techniken in den Lieferzentren führten zu einer erheblichen Verkürzung der Durchlaufzeit eines Kundenauftrags vom Auftragseingang bis zur Auslieferung der Ware. Dabei versteht Osram unter "normaler Auftragsabwicklung" die schnellstmögliche Bereitstellung beim Kunden. Das heißt, für einen heute im inländischen Verkaufsbüro eingegangenen Auftrag müssen morgen in einem Lieferzentrum die notwendigen Lieferpapiere erzeugt, muß die Ware kommissioniert und einem Spediteur übergeben werden. Der kurzen Abwicklungsdauer bei Osram stehen jedoch zum Teil Zeiträume von bis zu einer Woche von der Bedarfsfeststellung beim Kunden bis zum Auftragseingang in einem Osram-Verkaufsbüro entgegen.
Auffällig ist dabei, daß bei Kunden mit funktionierendem Warenwirtschaftssystemen diese Zeitspannen häufig länger ausfallen als bei Kunden ohne DV-System. Der Grund: Händler, ohne WWS melden ihren neuen Bedarf bereits an, wenn die vorletzte oder letzte Lampe verkauft ist.
Der Kunde mit WWS dagegen druckt ein Bestellpapier und schickte es per Post an unser Verkaufsbüro.
Gerade bei diesen Kunden, die ihren Bedarf maschinell über ein WWS oder über ein Produktionsplanungs- und -steuerungssystem ableiten, läßt sich die Zeitspanne von der Bedarfsfeststellung bis zum Auftragseingang bei Osram durch EDI erheblich verkürzen. Die dadurch gewonnene Zeit kann die Logistik nutzen, um den Kunden auf kostenoptimierten Abwicklungswegen zufriedenzustellen.
1984 wurde bei Osram im Bereich Logistik ein Projekt zur Realisierung des beleglosen Datenaustausches mit Kunden gestartet.
Dabei dachte man zunächst nur an den beleglosen Auftragseingang. In weiteren Schritten sollte die beleglose Übermittlung von Liefer- und Transportdaten sowie von Rechnungen folgen.
Den Planern war klar, daß die Bedeutung Osrams als Lieferant beim Kunden nicht ausreicht, um ein selbstentwickeltes Datenaustauschsystem (DAS) durchzusetzen. Weil damals Edifact noch nicht existierte, suchten die Verantwortlichen nach Standardlösungen, die eine möglichst große Verbreitung für die Zukunft versprachen. 1984 und 1985 gab es für unseren Kundenkreis nur ein praktikables System für Datenaustausch per DFÜ, nämlich EDI nach den Regeln des Verbandes der Automobilindustrie e.V. (VDA).
Nachdem die Automobilhersteller wichtige Abnehmer mit einem relativ hohen Umsatzanteil für Osram sind, gingen die Überlegungen zunächst in Richtung VDA. Dabei stand der technische Anschluß - die Frage nach dem DFÜ-Monitor - im Vordergrund.
Eine Norm hatte sich in diesem Fall aber noch nicht durchgesetzt, einige Softwarehäuser boten jedoch Lösungen zur Überbrückung der Unterschiede an.
Nachdem in der VDA-Welt jeder Autohersteller mit jedem Lieferanten Datenaustausch betreibt und keiner die Einhaltung der VDA-Regeln überprüft, haben die meisten Hersteller noch besondere Regeln für einzelne Datenfelder erfunden. In der Praxis heißt das, daß nahezu für jeden Hersteller eine Sonderlösung für die vollmaschinelle Weiterverarbeitung der Daten realisiert werden muß.
Sedas ging erheblich weiter als VDA-Regeln
Neben den VDA-Regeln zeichnete sich Anfang 1985 mit Sedas (Standardregelungen einheitlicher Datenaustauschsysteme) aber die Realisierung eines Standards für den Bestellverkehr zwischen Handel und Industrie ab. Die "Centrale für Coorganisation" (CCG) entwickelte mit Sedas eine Norm, die erheblich weiter ging als bei den VDA-Regeln .
Sedas liefert nicht nur einen logischen Datenansatz, sondern fixiert auch das Datennetz und gibt ebenso die zu verwenden den Nummernsysteme BBN (Bundeseinheitliche Betriebnummer) für die Partner- und Anschriftenidentifikation sowie EAN (europäische Artikelnummer) für die Artikelidentifikation vor.
Als Datennetz wurde das Mark-III-Netz von General Electric Informations Service (Geisco) ausgewählt und von diesem Anbieter auch ein Clearing-System für die Datenverteilung - der Sedas- Daten-Service (SDS) - realisiert. Durch SDS wurde der potentielle Kreis der Sedas-Anwender innerhalb der Osram-Kundschaft erheblich größer als der Kreis der VDA-Anwender.
Eine einzige Verbindung mit der Clearing-Stelle
Nachdem für die Wirtschaftlichkeit eines Systems ausschließlich die Anzahl der über das WWS abwickelbaren Vorgänge relevant ist, bot sich die Realisierung des multilateralen Datenaustausches über SDS geradezu an. Mit einer einzigen Verbindung zu dieser Clearing-Stelle erhält Osram die Daten von allen angeschlossenen Kunden. Umgekehrt erreicht der Kunde mit einer einzigen Verbindung alle Lieferanten. Dadurch wird die Frage nach dem Umsatz, den man mit einem Kunden macht, oder die Frage nach den Positionen, die für einen Kunden abgewickelt werden, für den beleglosen Datenaustausch (EDI) völlig nebensächlich. Jeder Kunde oder jeder Lieferant, der seinen Datenaustausch über SDS abwickelt, erhöht die Wirtschaftlichkeit des Systems.
Mit dem Datennetz erübrigte sich eine spezielle Lösung für verschiedene DFÜ-Monitore. Aber auch die logischen Probleme mit den Datenformaten sind bei Sedas gelöst. Die Festlegung auf die Nummernsysteme BBN und EAN einerseits und die neutrale Clearing-Funktion andererseits ermöglichen die Überprüfung der Sedas-Regeln. Dadurch werden die Interpretationsspielräume stark eingeschränkt - es besteht also der Zwang, den Standard einzuhalten. Die zunächst negativ erscheinenden starken Einschränkungen des Sedas-Systems bringen für den Datenempfänger jedoch erhebliche Vorteile, gerade weil er sich auf die Daten verlassen kann. Sonderlösungen für die vollautomatische Weiterverarbeitung sind nicht mehr erforderlich.
Ende 1985 startete der Echtbetrieb für den Sedas-Bestellverkehr mit Osram als Pilotanwender. Heute nehmen mittlerweile rund 80 Firmen an diesem Verfahren teil. Inzwischen empfängt Osram außerdem auch beleglose Lieferabrufe gemäß der VDA-Regel 4905 von praktisch allen Automobilherstellern und einigen großen Zulieferern.
Sowohl die Sedas-Bestellungen als auch die VDA-Lieferabrufe werden im Unternehmen maschinell verarbeitet, das heißt, sie fließen ohne zusätzlichen manuellen Eingriff in unseren Auftragsbestand ein.
Multilateraler Austausch für VDA-Anwendungen
In der Praxis hat sich für Kunden, die zum Handel im weitesten Sinne gehören, das Sedas-System als besser erwiesen Industriekunden, egal aus welcher Branche, fahren dagegen in der Regel mit dem VDA-System besser. Generell kann man sagen, daß sich Lieferabrufe nach VDA-Regel immer dann empfehlen, wenn der Bedarf des Kunden aus einem Produktionsplanungs- und -steuerungssystem abgeleitet wird. Der Sedas-Bestellverkehr ist dagegen von Vorteil, wenn der Bedarf von einem Warenwirtschaftssystem ermittelt wird.
Der Vorzug des multilateralen Datenaustausches ist inzwischen übrigens auch für die VDA-Anwendungen nutzbar, zum Beispiel mit dem System Discus, das im Prinzip analog zu SDS funktioniert.
Die Frage nach dem richtigen System für EDI muß natürlich jeder Anwender für sich selbst beantworten, weil es das für Jeden geeignete Universalsystem nicht gibt. Wichtig ist die Analyse des eigenen Unternehmens im Marktumfeld, denn der beste Datenaustausch funktioniert nicht ohne die Partner. Daran wird auch Edifact nichts ändern.
Edifact - soviel sei vorweggenommen - wird die Systemauswahl nicht vereinfachen, weil die etablierten Standardlösungen als Subsets in Edifact weiterleben. Dabei dürfen zwar alle Systeme einheitliche Syntaxregeln haben und den Edifact-Vorschriften weitgehend genügen, aber es wird erhebliche Unterschiede in den verwendeten Segmenten und Datenelementen geben.
Verschiedene Einheiten erzeugen Problemfelder
Alle EDI-Anwender haben bei der Realisierung mit den gleichen Problemen zu kämpfen. Die Schwierigkeiten liegen nicht, wie so oft diskutiert, im technischen Bereich. Die Kommunikation zwischen verschiedenen Rechnern ist heute ohne weiteres lösbar. Außerdem bietet der Markt unterdessen entsprechende Softwarepakete an, und verschiedene Netzwerkbetreiber offerieren mehr oder weniger umfassende EDI-Dienstleistungen. Die eigentlichen Probleme stecken im betriebwirtschaftlichen und organisatorischen Bereich, obwohl die Datensätze praktisch genormt sind.
Ein Beispiel aus der Praxis: Die Sedas-Datensätze basieren wie gesagt auf den genormten Nummernsystemen EAN und BBN. Die EAN gab es bei Osram schon seit einigen Jahren als Strichcode auf den Verpackungen. Sie war auch in den Artikelstammdaten von Osram gespeichert. Für den Sedas-Bestellverkehr mußte die EAN auch als Kriterium für den Zugriff auf unseren Artikelstamm definiert werden, wozu Programmänderungen erforderlich waren.
Im VDA-System gibt es die Festschreibung auf eine Artikelnummer nicht. Hier stellt VDA die Lieferantenartikelnummer und die Kundenartikelnummer gleichwertig nebeneinander. Praxis ist, daß die meisten Absender von Lieferabrufen nur ihre eigene Artikelansprache vorgeben. Die Artikelnummer des Lieferanten fehlt jedoch. Damit mußte Osram die Umsetzung aller Kundenartikelnummern der angeschlossenen Hersteller in unseren Artikelcodes realisieren .
Aber zurück zum Sedas-Bestellverkehr und zur EAN. Die Kunden müssen die vom Lieferanten festgelegten EAN zu ihren Artikelnummern hinzufügen. Dafür hat Osram Hilfsmittel bereitgestellt. Anfangs genügten in der Regel Listen, später wurden auch entsprechende Datenträger angeboten. Die Realisierung des beleglosen Bestellverkehrs zieht also fast notwendigerweise den beleglosen Stammdatenaustausch nach sich. Übrigens: Die EAN wird im Zusammenhang mit EDI als Nummer benötigt, nicht als Strichcode.
Mengeneinheiten sind bei EAN ein Problem
Ein weiteres Problem im Zusammenhang mit der EAN sind die Mengeneinheiten. Die Sedas-Regel heißt, daß sich die in der Position angegebene Menge auf die durch die EAN definierte Einheit bezieht. Bisher haben auch gut organisierte Kunden bei Osram zum Beispiel zehn Einzellampen (Angabe: zehn Stück als Bestellmenge) mit dem Zusatz "Zehner-Packung" im Text bestellt. In einer Sedas-Bestellung hätten diese Kunden nur noch eine solche Lampe mit der EAN dieser Zehner-Packung bestellen dürfen.
Auch das Problem der Mengeneinheiten läßt sich auf alle anderen Datenaustauschsysteme und auf alle Einsatzbereiche des beleglosen Datenaustausches übertragen. Probleme entstehen immer dann, wenn es von einem Produkt verschiedene Einheiten gibt oder der Kunde eine andere Einheit als Standardeinheit nutzt als der Lieferant.
Ein besonderes Problem bei EDI sind außerdem Texte. In jedem Datenaustauschsystem - auch bei Edifact und dessen Subsets - besteht die Möglichkeit, frei formatierte Texte zu übertragen .
Für Planer: EDI ist nicht Electronic Mail
Diese Texte können aber nicht maschinell verarbeitet werden, sondern müssen von Menschen gelesen und geprüft werden. Damit wird die maschinelle Kette vom DV-System des Bestellers zum DV-System des Lieferanten unterbrochen. Kein Lieferant kann es sich leisten übermittelte Texte einfach zu übergehen. Grund: Wurden zum Beispiel im Text Sonderrabatte vom Besteller vorgeschrieben und reagiert der Lieferant nicht auf diese möglicherweise falsche Vorschrift, gelten die Sonderrabatte als anerkannt Planer sollten sich also darüber im klaren sein, daß EDI nicht Electronic Mail ist.
Ähnlich wie mit Texten verhält es sich - zumindest im Bestellverkehr - mit Preisen. Im Sedas-System ist die Angabe von Einkaufspreisen in Bestellpositionen möglich, die der Lieferant prüfen muß. Bei Abweichungen zu den bei ihm festgelegten Preisen müßte er widersprechen. Tut er dies nicht, akzeptiert er die vorgeschriebenen Preise. Dabei sind Preise Stammdaten und sollten als solche feststehen. Liegen klare Absprachen vor, kann auch bei Sonderkonditionen auf Preisangaben in der Bestellposition verzichtet werden.
20 Prozent der Aufträge werden mit EDI umgesetzt
Osram praktiziert EDI mit Kunden seit nahezu sechs Jahren. Dabei haben sich die im Vorfeld eingebrachten Leistungen längst ausgezahlt, nur geringfügige Probleme und Fehler sind in der Praxis aufgetreten. Heute gehen immerhin rund 20 Prozent aller Auftragseingänge beleglos bei Osram ein, das heißt, sie können ohne manuellen Eingriff direkt in unseren Auftragsbestand umgesetzt werden.
Die angeschlossenen Kunden übertragen dabei 70 bis 100 Prozent ihrer Positionen beleglos. Voraussetzung dafür sind klare Absprachen. Jedes Datenaustauschsystem läßt den Anwendern Interpretationsspielräume. Wichtig ist aber, daß die Datenaustauschpartner diese Spielräume auf gleiche Weise nutzen.
Edifact: Zauberformel für viele Interessenten
Edifact ist für viele am Datenaustausch Interessierte die Zauberformel, von der sie sich weltweiten Datenaustausch mit beliebigen Partnern, unabhängig von der Branche, versprechen. Gängige Systeme wie zum Beispiel VDA oder Sedas nicht zu realisieren, weil man auf Edifact wartet, ist in vielen Fällen aber auch der Vorwand, hinter dem viele Unternehmen ihre organisatorischen Unzulänglichkeiten verbergen. Anders jedenfalls ist das Zögern, EDI zu installieren, nicht zu erklären, obwohl Edifact eigentlich schon existiert.
In den realisierten Edifact-Anwendungen fällt allerdings auf, daß ein Edifact-Teilnehmer meistens nur mit wenigen Partnern - in der Regel sogar nur mit einem - korrespondiert. Wo liegt das Problem? Die Edifact-Standardnachrichten wurden so gestaltet, daß sie tatsächlich in fast allen Branchen anwendbar sind. So können zum Beispiel mit der Standardnachricht Rechnung, Miet-, Leasing-, Handels- und Zollrechnungen etc. abgewickelt werden. Um das zu ermöglichen, sieht die Standardrechnung sehr viele Kann-Elemente vor. Die Edifact-Syntax erlaubt es, nicht benötigte Kann-Elemente nach Belieben wegzulassen .
Die Edifact-Standardnachrichten bieten daher zwar sehr große Spielräume für den Anwender, die nationalen Besonderheiten, die zusätzlich bei der Normierung von Edifact-Nachrichten eingeflossen sind, und die riesigen Qualifizierungsverzeichnisse sind jedoch dazu angetan, daß zwei Partner, die eine Edifact-Standardnachricht austauschen wollen, sich zunächst nicht verstehen. Also müssen sie sich auch bei Edifact darauf verständigen, welche Datensegmente, Datenelemente oder Qualifier sie untereinander anwenden wollen. Wenn sich aber zwei andere Partner, die gegebenenfalls sogar der gleichen Branche angehören und das gleiche Edifact-Problem haben, auf andere Segmente verständigen, entstehen auch unter Edifact für einen Geschäftsvorfall zwei verschiedene, individuelle Lösungen.
Dabei können beide Lösungen absolut Edifact-gerecht sein. Die Vorschriften der Standardnachricht werden eingehalten. Wollen aber alle vier Partner untereinander Datenaustausch betreiben, müssen wenigstens zwei ihre Systeme umprogrammieren .
Subsets wie Edifice, Odette, Cefic und Eancom
Dieses Edifact-Problem wurde inzwischen erkannt. Die Lösung streben die Verbände und Normierungsinstitute durch die Edifact-Subsets an, die sie unter Namen wie Edifice, Odette, Cefic oder Eancom veröffentlichen.
Im Prinzip sind dies auch wieder Branchenlösungen, aber mit Edifact-Zuschnitt.
Für Edifact spricht, daß es eine weltweite Norm ist, das heißt, die Branchenlösungen werden international. Das vereinfacht für grenzüberschreitend operierende Unternehmen die EDI-Realisierung erheblich. Darüber hinaus werden durch Edifact Syntax und Schnittstellenstruktur für alle Subsets vereinheitlicht und damit die Unterschiede zwischen den Systemen kleiner. Die Entwicklung der Edifact-Subsets hat für Anwender bereits installierter EDI-Systeme zur Folge, daß sie irgendwann Änderungen in ihren Programmen vornehmen müssen, wenn die Edifact-Subsets eingeführt werden.
Wer aber ein nicht auf Edifact-beruhendes Datenaustauschsystem heute realisieren will, sollte sich nicht scheuen, dies zu tun, und kann einer späteren Umstellung auf Edifact-Subsets gelassen entgegensehen.
Er löst nämlich schon heute die organisatorischen Probleme, die bei einer Umstellung zwangsläufig auftreten. Die Realisierung von Edifact oder den entsprechende Subsets kann in der Regel mit Konvertern relativ problemlos vollzogen werden. Bei multilateralem Datenaustausch analog dem SDS könnte die Konvertierung sogar an zentraler Stelle erfolgen.