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.07.1993

Offene Kommunikationswelt ist stufenweise aufzubauen Divergierende Subsets erfordern Abstimmung des Message-Inhaltes

Am Electronic Data Interchange (EDI) fuehrt in der Finanzwelt schon laengst kein Weg mehr vorbei. Allerdings haben sich in den vergangenen Jahren bei der EDI-Anwendung im Finanzwesen unterschiedliche De-facto-Standards etabliert, die einen Bruch zwischen den einzelnen Normen und Medien erzeugen und dadurch Zeitverzoegerungen und einen erheblichen Aufwand an Mitteln verursachen. Georg Scheint*, Siegfried Kiontke* und Rolf Prantl* beschreiben in diesem Beitrag unter anderem die Migration zu Edifact an einem Fallbeispiel aus der Finanzwelt.

EDI kann grundsaetzlich in den Bereich des Gueterkreislaufes (Angebots-, Auftrags- und Versandphase) und zum anderen in den des Geldkreislaufes (Zahlungsphase) eingeteilt werden. Diese beiden Bereiche werden als Commercial- beziehungsweise Financial-EDI bezeichnet.

Der Nachrichtenstandard Edifact ist der einzige Standard, der weltweit die Beduerfnisse beider Kreislaeufe in integrierter Form darstellt. Allein der Zeitbedarf (seit 1987) zur Entwicklung der bisher bekannten Nachrichtentypen macht deutlich, welch gewaltiger Aufwand fuer eine solche Standardisierungsmassnahme erforderlich war, bis eine einheitliche Regelung fuer alle Branchen und alle Laender getroffen wurde.

So wie heute kein Unternehmen ohne Telefon oder Telefax auskommt, wird schon bald die Faehigkeit, an diesem standardisierten Informationsaustausch teilzunehmen, ein wesentlicher Wettbewerbsfaktor sein, um in einem europaeischen oder gar weltweiten Markt den Anforderungen standzuhalten und mit kurzen Reaktionszeiten permanente Praesenz zu zeigen.

Die wesentlichste Herausforderung ist hierbei die technische Umsetzung dieses Nachrichtenstandards in betriebliche Daten und Ablaeufe. Am Beispiel des Financial-EDI sei die Problematik verdeutlicht.

Im Finance-Bereich werden heute bereits in grossem Umfang EDI- Anwendungen verwendet, so zum Beispiel im Kunde-Bank-Sektor alle Anwendungen, die mittels der Standards "DTA" und "DTAZV" die elektronische Uebermittlung von Zahlungsauftraegen erlauben, sowie im internationalen Bankenwesen mittels Swift.

Der dabei auftretende Bruch zwischen den einzelnen Normen und Medien verursacht einen erheblichen Mittelaufwand sowie Zeitverzoegerungen. Abbildung 1 gibt einen Ueberblick ueber die Umsetzungsvorgaenge bezueglich der einzelnen Medien und Normen.

In einem unter Einsatz von Edifact integrierten Informationskreislauf treten weder Medienbrueche noch Normenkonflikte auf. Die Datenverarbeitung und -weitergabe kann unmittelbar erfolgen. Dies soll mit den nachfolgenden Edifact- Nachrichtentypen verdeutlicht werden:

Die in Abbildung 2 verwendete "Invoic" dient als elektronische

Grundlage zur Erstellung der Zahlungsanweisung "Payord", die Gutschrift beziehungsweise Belastung erfolgt dann jeweils mit den Nachrichtentypen "Debadv" beziehungsweise "Creadv", die Verrechnung unter den Banken mittels einem sogenannten "Finpay".

Alle verwendeten Nachrichtentypen verfuegen ueber viele gleiche Dateninhalte und nur einzelne, geschaeftsvorfallspezifische Auspraegungen sind hierbei unterschiedlich. Somit ist es fuer keinen der Beteiligten notwendig, mit unterschiedlichen Normen oder Medien zu arbeiten.

Um nun ein solches Szenario DV-technisch realisieren zu koennen, bedarf es eines gewissen Aufwandes, abhaengig von der jeweiligen Organisation. Zum einen muessen die einzelnen eingehenden Nachrichten empfangen, technisch behandelt, interpretiert, archiviert, geprueft und an die einzelnen, bereits bestehenden Fachapplikationen weitergeleitet werden. Zum anderen sind die einzelnen Dateninhalte dann fachlich zu verifizieren und passend zur vorhandenen Inhouse-Landschaft zu transformieren.

Nach der Verarbeitung der Daten sind die Inhouse-Daten dann technisch so zu konvertieren, dass sie dem Standard und somit auch den Anforderungen des naechsten Empfaengers entsprechen. Diese Verarbeitungsschritte muessen in eine technische und branchenunabhaengige Ebene und in eine fachliche und somit branchenabhaengige Ebene unterteilt werden.

Um den EDI-Einsatz zu beschleunigen, werden flexible EDI- Softwareprodukte mit offenen Schnittstellen fuer die Anbindung in den Branchenanwendungen angeboten, die eine einfache und wirtschaftliche Einfuehrung von EDI in den unterschiedlichen Unternehmen ermoeglichen.

Je nach Anforderung kann aus dem vorhandenen Sedi-Produktspektrum der SNI die fuer das Unternehmen benoetigte EDI-Software ausgesucht werden. Das Angebot reicht von Konverter-Produkten sowie schluesselfertigen PC-Paketen bis hin zu Komplettloesungen fuer Klein-, Mittel- und Grossbetriebe

Mittelstandsunternehmen verfuegen oft ueber mittlere DV-Systeme und PCs. Da aber das EDI-Spezial-Know-how meist nicht ausreichend vorhanden ist, wird eine flexibel aufgebaute Kopplungssoftware fuer bestehende betriebswirtschaftliche Applikationen angeboten.

Waehrend es sich bei einem Konverter lediglich um einen Formatumsetzer handelt, weist der Integrationsbaustein zusaetzliche EDI-Funktionen auf. Er ist in der Lage, alle verwaltungstechnischen und EDI-spezifischen Aufgaben zu uebernehmen. Dies sind beispielsweise die automatische Ablaufsteuerung, interne und externe Kommunikationsanbindung, Archivierungsfunktionen und Partnerprofilverwaltung. Die betriebswirtschaftlichen Aufgaben werden von der jeweiligen ueber Schnittstellen angebundenen branchenspezifischen Anwendung realisiert.

Grossunternehmen verfuegen meist ueber eigene DV-Abteilungen mit angeschlossenem Rechenzentrum und Grossrechnern, mittleren Systemen und PCs. Hier ist es notwendig, zum Beispiel im Bankenbereich, dass weitere Dienstleistungen zur Verfuegung gestellt werden.

Erfahrungsbericht aus einem Edifact-Projekt

Bei der Einfuehrung von Edifact in einer europaeischen Grossbank konnten in den letzten Jahren Erfahrungen bezueglich der Vorgehensweise und kritischen Faktoren fuer ein solches Projekt gewonnen werden.

Es wurde ein erheblicher Aufwand dafuer betrieben, die zukuenftigen Einsatzmoeglichkeiten von Edifact und moegliche, daraus resultierende neue Geschaeftsfelder und Wettbewerbsvorteile zu analysieren. Die Ergebnisse mussten es dem Top-Management ermoeglichen, sich eindeutig fuer oder gegen den Einsatz von Edifact im eigenen Unternehmen zu entscheiden. Dabei wurde auch deutlich, dass der Erfolg von einer interdisziplinaeren Besetzung, das heisst Fachleuten aus unterschiedlichen Branchen (Kommunikation, Edifact, Fachbereiche), abhing.

Edifact im Endausbau bedingt, dass jeder mit jedem kommunizieren kann, sowohl auf technischer als auch auf fachlicher Ebene. Die Erfahrung hat jedoch gezeigt, dass es sinnvoll ist, diese offene Kommunikationswelt stufenweise auszubauen. Im ersten Projektschritt wurde mit einzelnen Partnerunternehmen eine Vereinbarung bezueglich des Einsatzes der Kommunikationssoftware sowie der zu verwendenden Nachrichtentypen, Nachrichtenversionen und deren Inhalte getroffen. Die hierbei auftretenden Schwierigkeiten lagen vor allem im Abstimmen der einzelnen File- Transfer-Verbindungen (FTAM) sowie bei der Definition der Nachrichteninhalte. Generell waren auch Vereinbarungen bezueglich der Einsatzzeiten und Haftungsbestimmungen notwendig.

Da die internationalen Kommunikationsstandards (zum Beispiel FTAM) Optionen und keine Implementierungsregeln beinhalten, mussten die FTAM-Produkte verschiedener Hersteller aneinander angepasst werden (Interworking-Test). Die Erfahrung zeigt wiederum, dass es hier sinnvoll ist, die Kommunikations-Spezialisten der einzelnen Softwarehersteller in die Installations- und Integrationsphase der Kommunikationssoftware einzubeziehen.

Aehnlich wie bei einer Sprache basieren die Edifact-Regeln auf dem zu verwendenden Wortschatz (Datenelemente) und der Grammatik (Syntax). Auf dieser Grundlage werden laufend neue Nachrichten fuer die Branchen erzeugt. Da eine Message eine Uebermenge aller tatsaechlichen Auspraegungen dieser Nachricht (zum Beispiel "Rechnung") darstellt, werden fuer einzelne Branchen wieder Untermengen - sogenannte Subsets - definiert. Daraus resultiert, dass Abstimmgespraeche notwendig sind, um einheitliche Definitionen bezueglich Nachrichteninhalten zu bekommen.

Basierend auf dem Mustervertrag aus dem Tedis-Projekt der EG, der mehr eine Verfahrensrichtlinie fuer den Vertragsentwurf als einen Vertrag darstellt, wurde unter Mitarbeit der Rechtsabteilungen der beteiligten Firmen ein Vertragsentwurf vorgenommen, der die multilateralen Beziehungen bezueglich der technischen Abwicklung und Haftungsfragen regelt.

Ein unternehmensweiter Einsatz von Edifact im gesamten Unternehmen in einem Schritt gleicht einer Revolution im Staat und unterliegt auch den gleichen Risiken. Im beschriebenen Projekt wurde aus diesem Grunde ein Nachrichtenzyklus aus dem gesamten Nachrichtenverkehr isoliert.

Projektziel war, diesen Nachrichtenfluss mittels Edifact darzustellen. Es handelte sich dabei um den Weg vom Zahlungsauftrag ueber die Kontobuchung zur Gutschrift- beziehungsweise Belastungsanzeige (Edifact-Terminologie: von der Payord ueber die Buchung zur Creadv und Debadv). Dieser Nachrichtenzyklus bedingt mindestens drei beteiligte Parteien (Auftraggeber, Beguenstigter und Kreditinstitut). Bei Verwendung unterschiedlicher Banken fuer Auftraggeber und Empfaenger ist in der Regel eine groessere Anzahl beteiligter Parteien notwendig. Hierbei muessen die einzelnen Nachrichtentypen und die Daten der bestehenden Inhouse-Systeme verbunden werden. Es handelte sich um folgende Zuordnungen, die unter technischen und fachlichen Gesichtspunkten zu analysieren waren:

Payord zu Inhouse-Datenstrukturen, Inhouse-Ergebnisse und Payord- Daten zu Debadv-Inhouse-Ergebnissen sowie Payord-Daten zu Creadv.

Ein Problem besonderer Art kam zum Vorschein, als von der Annahme ausgegangen wurde, dass der Empfaenger einer Gutschriftanzeige nicht die gleiche Nachrichtenversion beherrscht wie der Sender des Zahlungsauftrages. Hier musste auf Veraenderungen bezueglich der einzelnen Feldformate, Segmentaufbauten etc. eingegangen werden. Der Ansatz, dieses Problem mittels Subsets (in der Regel innerhalb einer Branche) zu loesen, findet seine Grenzen beim internationalen beziehungsweise branchenuebergreifenden Einsatz.

Eine weitere Variante dieses Problems ist, dass selbst in der klassischen Dreiecksbeziehung nicht jeder Teilnehmer (zum Beispiel der Beguenstigte) Edifact-faehig ist. Fuer beide Problemfelder galt es Loesungen zu finden und zu realisieren. Diese Schwierigkeiten koennen auch in Zukunft ueberall dort auftauchen, wo ein Dritter als Dienstleistungsunternehmen zwischen zwei Marktteilnehmern auftritt. Schon allein deshalb ist der Einsatz von Edifact- Spezialisten innerhalb des Projektteams ganz entscheidend fuer den Erfolg.

Es ist kein Geschaeftsvorfall denkbar, dessen Datenvolumen zu gross fuer Edifact waere. In diesem Sinne uebertrifft Edifact alles bisher Dagewesene. Der permanent fortschreitende Standardisierungsprozess ermoeglicht darueber hinaus die Bewaeltigung von immer mehr Geschaeftsvorfaellen. Im vorliegenden Projekt waren es speziell die moeglichen Auspraegungen, die zu einem sehr grossen Aenderungs- beziehungsweise Erneuerungsaufwand in den nachgeordneten operativen Inhouse-Systemen sowie auch zu organisatorischen Aenderungen gefuehrt haetten.

Durch den interdisziplinaeren Einsatz von fachkompetenten Mitarbeitern und Edifact-Spezialisten ist es gelungen, die einzelnen Faelle zu lokalisieren und abzugrenzen und dadurch zu verhindern, dass grosse organisatorische Aenderungen notwendig wurden. Erst dann war es moeglich, eine Integration von Edifact und bestehenden Systemen vorzunehmen und dabei dennoch die Flexibilitaet zu erhalten, um auf weitere Auspraegungen dann einzugehen, wenn Markterfordernisse und Weiterentwicklungen der operativen Systeme dies erfordern beziehungsweise ermoeglichen.

*Siegfried Kiontke ist EDI-Berater bei der Atlas Kommunikationsberatungs Gesellschaft mbH, Muenchen. Rolf Prantl ist Geschaeftsfuehrer des Beratungsunternehmens der ISD Projektmanagement GmbH, Landshut, und Georg Scheint Produkt- Manager fuer die Sedi-Produkte bei der Siemens-Nixdorf Informationssysteme AG, Muenchen.

DTA ; Datentraeger-Austauschformat

DTAZV ; Datentraeger-Austauschformat fuer den Zahlungsverkehr Ausland

Invoic ; Rechnung

Payord ; Zahlungsauftrag

Debadv ; Belastungsanzeige

Creadv ; Gutschriftanzeige

Finpay ; Zahlungsauftrag zwischen den Banken

Abb. 1: Umsetzung unterschiedlicher EDI-Normen ueber verschiedene Medien

Abb. 2: Datenverarbeitung im Finanzwesen mit Edifact- Nachrichtentypen