-----------------------------------------------------------------------
Aus infortis ag wird movento Schweiz AG...
Sie werden automatisch auf www.movento.com umgeleitet...
Sollte die Umleitung nicht klappen klicken Sie bitte -> hier <-.
-----------------------------------------------------------------------
| EDI, XML und die Vorurteile gegenüber einer ausgereiften Technologie |
|---|
| | Glauben Sie nicht alles was Sie hören!
In den letzten Jahren hat das Thema Systemintegration sehr stark an Bedeutung gewonnen. Begriffe wie EAI (Enterprise Application Integration) und XML (Extensable Markup Language) sind in aller Munde.
In diesen Diskussionen über EAI und XML wird von den so genannten „alten“ Ansätzen wie EDI (Electronic Data Interchange) teilweise ein sehr schlechtes Bild gezeichnet. Ich werde Ihnen nachfolgend die gröbsten Vorurteile gegen EDI aufzeigen. Sie werden sehen, dass EDI lange nicht so schlecht ist wie sein Ruf.
Zum besseren Verständnis der weiteren Ausführungen in diesem Bericht müssen wir uns erst noch mit den folgenden Definitionen beschäftigen.
Was sind EDI-Standards?
EDI-Standards sind unter anderem EDIFACT, ANSI X.12, ODETTE, RosettaNet , etc. Diese Standards unterscheiden sich je nach Einsatzgebiet durch spezielle Anforderungen der Geschäftssegmente, geographische (länderspezifische) Ausprägungen, unterschiedlichen Nachrichtenumfang, etc. Für viele dieser Standards werden oft zusätzliche industriespezifische Unterdefinitionen (so genannte Subsets) definiert. Ein Beispiel ist hier die Automobilindustrie, die über eigene Subsets verfügt.
Alle Standards werden von Standardisierungsgremien verwaltet. Sie sind verantwortlich für Umfang und Ausbau dieser Definitionen. So ist zBsp EDIFACT, auch als UN/EDIFACT bekannt, ein von den Vereinten Nationen (UN) herausgegebener Standard mit definierten Regeln, anhand derer die einzelnen EDIFACT-Nachrichten zu erstellen sind. Diese Regeln beschreiben den Aufbau und die Form der Inhalte der jeweiligen Nachricht. Eine Nachricht kann ein Auftrag, eine Faktura, ein Lieferavis, etc. sein. Die EDI-Nachrichten entsprechen im Normalfall verschiedenen Geschäftsdokumenten. Es gibt aber auch einige technische Nachrichten, um die Kommunikation zwischen den Systemen zu kontrollieren.
Es ist hilfreich zu wissen, was ein EDI-Standard überhaupt beinhaltet. Das sind:
- eine EDI-Syntax
Die EDI-Syntax beinhaltet die Sprachelemente und den Aufbau der verschiedenen Nachrichten.
- ein Nachrichtentypverzeichnis
Dieses Verzeichnis definiert die verschiedenen Nachrichten, sprich Geschäftsdokumente, für welche in einem EDI-Standard Definitionen vorhanden sind. Nicht jede Nachricht ist in jedem EDI-Standard verfügbar.
- ein Datenelementverzeichnis
Dieses Verzeichnis beinhaltet alle Daten, die in einer bestimmten Nachricht übermittelt werden können.
- semantische Definitionen
Hier werden die Abläufe von Geschäftsprozessen festgelegt. So wird zBsp definiert, wie und in welchem Zeitraum ein Partner auf einen eingehenden Kundenauftrag reagieren sollte. Es gibt nur wenige EDI-Standards, die sich mit semantischen Definitionen beschäftigen. Es sind dies vor allem die industriespezifischen Standards. Hier werden neben der Definition von industriespezifischen Datenanforderungen gleichzeitig auch die industrietypischen Prozesse behandelt. Ein Beispiel hierfür ist RosettaNet.
Ein EDI-Standard enthält also Definitionen, um Daten in vorgegebenen Strukturen zwischen verschiedenen Geschäftspartnern auszutauschen. Der EDI-Standard dient dabei als gemeinsame Sprache zwischen den Geschäftspartnern. Dies wird dadurch erreicht, dass die beiden EDI-Subsysteme die gleiche Sprache sprechen. Ein EDI-Subsystem kann gleichzeitig auch mehr als eine Sprache sprechen.
Und was ist XML?
Diesen Begriff haben Sie sicher auch schon oft gehört. XML ist im Gegensatz zu einem EDI-Standard (EDIFACT, etc.) eine vollständige Datenmodellierungssprache, eine so genannte Metasprache. XML ist eine plattformunabhängige Sprachdefinitionen, welche über sich selbst definiert wird. XML scheint momentan einer der erfolgsversprechendsten Ansätze für die Zukunft zu sein. Denn als "Metasprache" ermöglicht es eine Vielzahl von Anwendungen, deren volle Bedeutung erst in Zukunft deutlich werden wird.
XML bietet als Metasprache einerseits eine Vielzahl von Anwendungen, von der Definition von Formaten bis hin zu komplexen Übersetzungen von Dateninhalten. Auf der anderen Seite ist XML aber auch bloss ein Datenstring, der neben „einfachen“ Daten auch Bilder und Validierungsinformationen (als DTD = Data Type Definition) beinhalten kann. Die konkreten Daten werden in einem XML-Dialekt übermittelt. Dialekte sind zBsp xCBL, ebXML, etc.
Trotz dieser Anwendungsvielfalt kann XML aber auch „nur“ zur Übertragung von Daten eingesetzt werden. Im Gegensatz dazu ist bei den klassischen EDI-Standards die Übertragung von Daten das einzige Hauptanwendungsgebiet. XML kann also auch nur als zusätzlicher EDI-Standard betrachtet werden was bedeutet, dass wir die Daten in einem XML-Format und nicht in einem sonstigen EDI-Format übertragen. Dabei verwenden wir dieselben Technologien wie beim „klassischen“ EDI. Gleichzeitig können die Geschäftspartner bei der Verarbeitung der Daten aber alle Vorteile nutzen, die XML Ihnen zusätzlich bietet.
Einer dieser Vorteile ist die Entkopplung von Daten und Anwendung, indem orthographische, syntaktische und inhaltliche Validierungen nicht mehr auf der Anwendungsebene implementiert werden müssen, sondern bereits quasi auf Daten- bzw. Datei-Ebene durchgeführt werden können.
Am Beispiel Konsistenzprüfung sieht das wie folgt aus. Bei einem klassischen EDI-Standard werden diese Prüfungen in der jeweiligen Anwendung durchgeführt. Bei XML kann dies bereits in der Datei selbst, d.h. ohne Hilfe der entsprechenden Anwendung erfolgen. Als Metasprache können hier Regeln für diese Prüfungen auch wieder als XML hinterlegt werden und an die entsprechenden XML-Meldungen angebunden werden. Über XML-Standardwerkzeuge können diese Prüfungen anschliessend ausgeführt werden.
Die Vorurteile im Einzelnen
Nach den allgemeinen Erklärungen zu EDI-Standards und XML hier nun die Vorurteile im Einzelnen:
- EDI ist veraltet!
EDI wird heute oft gleichgesetzt mit veralteter Technik, die in modernen Systemlandschaften nicht mehr eingesetzt werden sollte. EDI hat vielfach den Ruf, sehr aufwendig, teuer und unflexibel zu sein. Weiter sind die Daten im EDI-Format für den Menschen schwer lesbar. Eine Ausnahme bilden die EDI-Spezialisten, die sich jeden Tag mit diesen Meldungen beschäftigen.
Dabei heisst EDI nur, dass Partnersysteme auf elektronischem Weg Daten miteinander austauschen und diese beim Empfänger idealerweise automatisch weiterverarbeitet werden (auch menschliche Schnittstellen sind hier leider keine Seltenheit). In welcher Form die Daten übermittelt werden, spielt für den generellen Einsatz von EDI keine Rolle und ist beim Entscheid für oder gegen EDI sekundär. Erst im konkreten Projekt wird den Anforderungen oder der Unternehmensstrategie entsprechend der passende EDI-Standard gewählt. Da die Daten automatisch weiterverarbeitet werden spielt die Lesbarkeit der EDI-Meldung sowieso keine Rolle.
- EDI ist zu teuer!
EDI wird häufig als sehr aufwendig und sehr (zu) teuer bezeichnet, XML dagegen als „einfache“ Lösung aller Probleme. Wie wir aus Punkt 1 wissen, kann EDI mit einem klassischen EDI-Standard oder auch mit XML ausgeführt werden. Es ist wichtig zu verstehen, an welcher Stelle die Kosten beim EDI-Einsatz liegen.
Also nochmals: nicht EDI ist teuer, sondern der falsche Einsatz von EDI!
Sie brauchen als erstes die technischen Voraussetzungen, um EDI-Nachrichten zu versenden. Auf dem Markt gibt es bereits für wenige Tausend Franken entsprechende Systeme zu kaufen. Und diese System-Kosten dürfen Sie nicht auf nur eine EDI-Nachricht abwälzen. Die Investitionskosten für EDI lohnen sich erst, wenn Sie auch ein entsprechendes Nachrichtenvolumen mit verschiedenen Geschäftspartnern austauschen werden. Weiter müssen diese EDI-Nachrichten zu einer entsprechenden Entlastung der Mitarbeiter in Ihrem Unternehmen führen.
Ist dies nicht der Fall, dann wird Ihr EDI-Projekt logischerweise als „zu teuer“ und „nicht sinnvoll“ in die Firmengeschichte eingehen. Sie sehen also, schon beim Entscheid für EDI ist es wichtig, den entsprechenden Nutzen aufzeigen zu können. Und dieser erste Schritt wird gemacht, bevor Sie sich überhaupt für eine spezielle Technik oder einen spezifischen EDI-Standard entschieden haben.
Neben den Kosten für die Infrastruktur fallen bei jeder neuen Nachricht zusätzliche Kosten an. Diese verteilen sich auf die folgenden Bereiche:
- Abstimmung der Nachricht mit Ihrem EDI-Geschäftspartner (auch bekannt als Mapping-Definition): Hier wird festgelegt, welche Daten zwischen den Partnern ausgetauscht werden sollen. Diese Daten werden dann den verschiedenen Feldern in der EDI-Nachricht zugeordnet (die Definition einer Meldung enthält standardmässig mehrere tausend Felder). Der Sender muss wissen, wo er die Daten aus seinem System hernehmen kann um die notwendigen Felder zu füllen. Der Empfänger muss wissen, wo er diese Felder in seinem System abspeichern wird.
Der Aufwand für diesen Schritt wird meist unterschätzt. Denn oft braucht es zusätzliche firmeninterne Abklärungen mit den einzelnen Fachabteilungen.
- Realisierung der Meldung im eigenen System:
Jeder Geschäftspartner führt bei sich die entsprechenden Entwicklungsarbeiten durch um die Nachricht zu erstellen.
- Versand von Testmeldungen:
Nach Abschluss der Entwicklungsarbeiten tauschen die Geschäftspartner erste Meldungen miteinander aus mit dem Ziel, die Meldungen automatisch verarbeiten zu können.
Ich vergleiche dies oft mit dem Bau eines Tunnels. Der Tunnel wird gleichzeitig von beiden Seiten her in den Berg getrieben mit dem Ziel, dass sich die beiden Röhren in der Mitte des Berges zu einem durchgängigen Tunnel verbinden. Nicht alle Tunnelbauer haben dieses Ziel auf Anhieb erreicht ...
Je nach Qualität von Design und Entwicklungsarbeit sind anschliessend grössere oder kleinere Anpassungen an der EDI-Nachricht vorzunehmen.
- Zum Abschluss wird die EDI-Nachricht in den Produktivbetrieb übernommen.
Den oben beschriebenen Aufwand haben Sie in jedem EDI-Projekt, egal ob der EDI-Standard ein klassischer Standard (EDIFACT, ANSI X.12, etc.) oder aber der „neue“ XML-Standard ist.
- EDI ist gleich XML!
Es ist wichtig zu verstehen, dass XML ein EDI-Standard sein kann. XML als Metasprache bietet aber zusätzliche Anwendungsmöglichkeiten, die weit über den klassischen EDI-Ansatz hinausgehen.
Legt man das Hauptgewicht auf die erweiterten Anwendungsmöglichkeiten von XML, dann tritt EDI natürlich in den Hintergrund. Dann werden aber auch die Daten nicht mehr über die klassischen EDI-Kommunikationswege übertragen, sondern es werden vermehrt die Vorteile von Internet und Email ausgeschöpft. Damit sprechen wir dann auch nicht mehr von EDI.
Sie sehen, je nach Einsatzgebiet ist EDI nicht der richtige Ansatz. EDI ist nur sinnvoll, wenn es eingesetzt wird wofür es definiert wurde. Nämlich Daten (idealerweise handelt es sich um sehr grosse Datenvolumen) auf elektronischem Weg in vordefinierten Strukturen zwischen Computern zweier Geschäftspartner auszutauschen.
- EDI muss durch XML abgelöst werden!
Korrekt ist, dass sich EDI und XML ergänzen. Sie können beide Technologien nebeneinander einsetzen, indem Sie XML als EDI-Standard nutzen. Die Unternehmen werden mit Sicherheit keine altbewährten EDI-Lösungen ersetzen, bloss weil diese Lösungen gemäss Aussagen von „Spezialisten“ nicht mehr dem neusten Stand entsprechen.
Wenn Sie den Behauptungen dieser „Spezialisten“ aber Glauben schenken, dann müssen Sie in Ihrem Unternehmen alle EDI-Schnittstellen durch XML ablösen. Bevor Sie das tun, stellen Sie sich bitte noch die folgenden Fragen: Spielt es eine Rolle, welcher Standard bei einer EDI-Übertragung eingesetzt wird? Gibt es nur einen richtigen Standard für EDI, nämlich XML?
Hier die Antworten: NEIN und NEIN. Denn die Wahl eines EDI-Standards richtet sich nach Einsatzgebiet und Lösungsschwerpunkt. Die nachfolgenden Betrachtungen zeigen Ihnen, welche Punkte in der realen Welt den Ausschlag für den Einsatz eines bestimmten EDI-Standards geben können.
- Bestehende EDI-Standards der Geschäftspartner:
Je nach Flexibilität der Geschäftspartner kommt vielfach nur ein EDI-Standard in Frage. Meist bestimmt der „stärkere“ Geschäftspartner den Standard. Als Lieferant muss man sich oft seinem Kunden anpassen, aber das gehört in der heutigen Zeit zu einem guten Kundenservice. Somit kann auch der Einsatz des vom Kunden gewünschten EDI-Standards als Teil des Kundenservice und der Kundenfreundlichkeit betrachtet werden. Sehr verbreitet ist diese Konstellation bei Zulieferern der Automobilindustrie.
- Anzahl der Meldungen, die zwischen den Geschäftspartnern übermittelt werden:
Falls eine grosse Anzahl Meldungen versendet wird, die alle auf die gleiche Weise automatisch verarbeitet werden, spielen Datenmenge und damit Geschwindigkeit und Übertragungskosten verstärkt eine wichtige Rolle.
XML-Nachrichten sind in der Regel wesentlich grösser als entsprechende Nachrichten in einem anderen EDI-Format. Dies auch darum, weil EDI-Nachrichten speziell für den EDI-Einsatz optimiert wurden. XML dagegen muss verschiedensten Anforderungen gerecht werden und beinhaltet deshalb zusätzliche Steuer- und Kontrolldaten, zBsp zur Verarbeitung der Daten mittels XML-Standardwerkzeug. Da XML nicht speziell für den EDI-Einsatz entwickelt wurde ist es für diesen Bereich auch nicht optimiert. Je nach Inhalt kann die XML-Nachricht bis zu 5-mal grösser sein als eine vergleichbare EDIFACT-Meldung. Es ist klar, dass sich dadurch auch die Übertragungskosten je nach gewähltem Medium stark ändern können.
Abbildung 1 - Vergleich einer Meldung in UN/EDIFACT und derselben Meldung in XML
- Anforderungen an verschiedene Verarbeitungsmöglichkeiten der EDI-Nachricht:
Wird eine Meldung nur über den EDI-Standardkanal verarbeitet, dann reichen die klassischen EDI-Übertragungsstandards völlig aus. Will man aber die vielfältigen XML-Möglichkeiten nutzen, dann werden auch die Daten in einem XML-Format benötigt.
- Verfügbare Nachrichten innerhalb eines Übertragungsstandards:
Nicht alle Nachrichtentypen (Auftrag, etc.) sind in allen Übertragungsstandards vorhanden Es kann sein, dass eine Meldung nur in einem klassischen EDI-Standard existiert, nicht aber als XML-Meldung. Natürlich kann die fehlende Meldung als XML-Nachricht zwischen den beiden Geschäftspartnern neu entwickelt werden. Doch stellt sich hier dann relativ schnell einmal die Kosten/Nutzen-Frage einer solchen Eigenentwicklung.
- Art der EDI-Nachricht (Einsatzgebiet):
ZBsp in der Automobilindustrie hat EDI eine langjährige Tradition. Wenn Sie als Zulieferer mit einem Automobilhersteller eine EDI-Kommunikation aufbauen wollen, dann werden Sie sich mit ziemlicher Sicherheit an dessen Standard halten müssen, sprich klassischer EDI-Übertragungsstandard.
- Die Verarbeitung bei XML ist real time, bei EDI aber nicht!
Oft wird angenommen, dass der Benutzer die Daten dank XML in Echtzeit zur Verfügung hat. Wann die Daten für den Anwender verfügbar sind hat nichts mit dem Datenformat zu tun. Das Design des Systems und die Art der Datenübertragung steuern den Verarbeitungszeitpunkt und damit die Verfügbarkeit der Daten für den Benutzer. Je schneller die Daten verfügbar sein müssen, desto aufwendiger und damit auch teurer ist eine entsprechende Systemlösung.
Die Schlussfolgerung aus diesem Bericht
Das Gebiet EDI und XML ist sehr umfangreich, es wurden schon viele Bücher dazu verfasst. Zur vertieften Einarbeitung in diese Gebiete finden Sie auf dem Markt und auf dem Internet eine Fülle von guter Literatur.
Das Ziel dieses Berichtes ist es, die herrschenden Missverständnisse zwischen EDI und XML aus der Welt zu schaffen. EDI und XML schliessen sich nicht aus, sie konkurrenzieren sich auch nicht, sondern sie bilden eine sinnvolle Ergänzung zueinander. Richtig eingesetzt werden Sie die jeweiligen Stärken der beiden Technologien zu Ihrem eigenen Vorteil nutzen können.
Mit dem neu aufgebauten Verständnis sind Sie in der Lage, beim Thema EDI und XML entscheidend mitzuwirken indem Sie auf Vor- und Nachteile, Stärken und Schwächen der verschiedenen Ansätze hinweisen können. |
Wollen Sie mehr zu diesem Thema erfahren?
Wenn Sie Interesse an weiteren interessanten Themen haben, dann ist der infortis PowerLetter genau das richtige für Sie. Abonnieren Sie deshalb noch heute den Gratis-PowerLetter:
PowerLetter abonnieren.
Anregungen und Kritik zum Artikel sind erwünscht.
Bernhard Troger
Mitglied der Geschäftsleitung
Leiter Entwicklung & Finanzen
|
|
