Dass nicht alles Gold ist, was glaenzt, ist im Zusammenhang mit dem EDI-Hoffnungstraeger Edifact eine nicht erst seit gestern bekannte Tatsache (siehe auch Schwerpunkt ab Seite 41). Jens Miebach* beschreibt anhand eines Pilotprojektes der Nuernberger Steuerberatungs-Dienstleistungsorganisation Datev sowie der Universitaet Erlangen-Nuernberg, wie Edifact in Sachen Finanzbuchhaltung manchen Geschaeftsprozess optimieren kann, aufgrund des Subset-Wirrwarrs Anwendern jedoch immer noch eine Menge Knueppel zwischen die Beine wirft.
An den Einsatz von Edifact knuepften sich anfangs hohe Erwartungen, zumindest schienen mit der Veroeffentlichung der 1987er Norm die Unzulaenglichkeiten eines branchenuebergreifenden elektronischen Austausches von Geschaeftsdaten auf Basis der bis dahin vorherrschenden Branchenstandards wie VDA oder Sedas ueberwunden. Prophezeiten in der Anfangseuphorie Brancheninsider Edifact jaehrliche Zuwachsraten von bis zu 50 Prozent, haben sich mit bislang weniger als 1000 geschaetzten EDI- (inklusive Edifact- )Anwendungen in Deutschland die Erwartungen bis zum heutigen Tage jedoch nicht erfuellt.
Edifact zehrt an seinem Hoffnungsvorsprung
Fragt man nach den Gruenden, liegen diese nicht zuletzt in der Norm Edifact selbst begruendet. Die gegenwaertig vorherrschende Vielfalt von Subsets erleichtert es jedenfalls branchenuebergreifend taetigen Unternehmen nicht gerade, ihre Geschaeftsdaten in einer oekonomisch vertretbaren Weise auszutauschen. Damit zehrt Edifact jedoch den "Hoffnungsvorsprung" auf, der gerade fuer den Einsatz dieser Norm sprechen sollte.
Der Nutzen des elektronischen Datenaustausches ist jedoch ebenso einsichtig wie unstrittig. Immer mehr Unternehmen moechten auf die Eingabedatenerfassung verzichten, Papierberge abbauen und Geschaeftsprozesse automatisieren. Im Vergleich zu den Kommunikationsinseln, die auf proprietaeren und branchenspezifischen Formaten beruhen, stellt Edifact ein international gueltiges Data-Dictionary zur Verfuegung, in dem als Obermenge alle Branchenbelange vereint sind. Dadurch sollte eigentlich jeder mit jedem in der Lage sein, auf Basis der gleichen Daten zu kommunizieren.
Der eigentliche Zweck von Normen ist zwar bekannt, aber nicht immer hinreichend bewusst. Bohrt man beispielsweise mit einem Bohrer genormter Spezifikation ein Loch in die Wand, besteht die Gewaehr, dass die entsprechende Schraube mit dem entsprechenden Duebel passt. Fuer den Handwerker ist es bedeutsam, dass die Komponenten aufeinander abgestimmt sind. Zum Beispiel sollten die Schrauben in die Duebel passen, selbst wenn sie von unterschiedlichen Herstellern stammen. Aus einem anderen Blickwinkel ist es fuer einen Schraubenhersteller entscheidend, dass seine Produkte "kompatibel" zu anderen Duebeln sind.
Analog koennte man sich dies bei auch Edifact vorstellen: Die Anwender tauschen Daten auf Basis eines Edifact-Subsets (entspricht der Spezifikation des Duebels beziehungsweise der Schraube) aus und haben die Gewaehr, dass sie sich verarbeiten lassen. Fuer einen Softwarehersteller ist es entscheidend, auf Edifact-Datenspezifikationen zurueckgreifen zu koennen, um entsprechende Anwendungsprogramme zu erstellen. Anders formuliert: Die Kraft einer Norm wie Edifact erweist sich vor allem dann, wenn Drittunternehmen auf die Daten anderer zugreifen und diese verarbeiten wollen.
Eines dieser typischen Drittunternehmen zur Verarbeitung von Daten anderer ist die Genossenschaft des steuerberatenden Berufsstandes (Datev) mit der "Querschnittsfunktion" Rechnungswesen. Hinsichtlich des Edifact-Einsatzes besitzt die Datev eine differenzierte, vom reinen bilateralen EDI-Betrieb abweichende Aufgabenstellung. Einerseits betreibt sie Edifact seit Jahren problemlos quasi in eigener Sache zur Automatisierung zwischenbetrieblicher Vorgaenge. So nimmt die Datev seit der ersten Stunde am Projekt "ELFE" (Elektronische Fernmelderechnung der Telekom) teil oder bestellt "papierlos" Papier von einem Hersteller. Andererseits ist es eines der Hauptanliegen in Nuernberg, entsprechend der Querschnittsfunktion des Rechnungswesens Informationen aus Edifact-Nachrichten fuer Zwecke zu verarbeiten, fuer die die Nachrichten nicht unmittelbar konzipiert wurden.
Die Verarbeitung solcher Querschnittsdaten aus Edifact-Nachrichten stellt hoehere Anforderungen an die Uebertragungssprache Edifact als die im Extremfall bilateral zwischen zwei Partnern abgesprochenen Edifact-Subsets. Die Norm muss hier also eindeutig, das heisst, ohne "Freiheitsgrade" fuer die Anwender sein - wenn nicht der Verarbeitungsaufwand (in Form von Abfangprogrammen) eine letztlich verhindernde Funktion ausueben soll. Die Probleme eines Drittverarbeiters von Rechnungsdaten fuer die Buchhaltung moegen also im Einzelfall uebertrieben erscheinen, dennoch oder gerade deswegen eignen sie sich fuer eine Beschreibung der Schwierigkeiten im bilateralen Austausch von Geschaefts-daten.
Eine zukuenftige betriebliche Anwendung im Bereich Buchfuehrung, bei der das Edifact-Format seine normativen Faehigkeiten unter Beweis stellen koennte, stellt das Projekt "Buchungssatzgenerator" (BSG) dar. Bislang geben viele, vorwiegend kleine und mittlere Unternehmen Belege in Papierform (Rechnungen, Zahlungsanweisungen etc.) an den Steuerberater weiter, der diese entsprechend verbucht. Verbreitet sich nun Edifact im Wirtschaftsverkehr weiter, waere es durchaus denkbar, dass diese Daten auf elektronischem Wege uebermittelt werden. Der BSG koennte dann in der jeweiligen Kanzlei ohne Papierausdruck von den Edifact-Belegen (teil-) automatisch Buchungssaetze fuer die Finanzbuchfuehrung (FIBU) ableiten. Ferner liessen sich Eingabeaufwendungen reduzieren sowie Eingabefehler minimieren mit der Konsequenz, dass Steuerberater und Mandanten von der Routinearbeit "Buchen" entlastet wuerden.
In Zusammenarbeit der Datev mit der Universitaet Erlangen-Nuernberg entstand nun der Prototyp eines solchen BSGs fuer die (teil- )automatische Verbuchung von Edifact-Rechnungen. Dieser muss in der Lage sein, Edifact als ganzes Regelwerk (anstatt der bei einem bilateralen Datenaustausch ueblichen Subsets) einheitlich und eindeutig zu verarbeiten. Das heisst, der BSG braucht die von den Anwendern bilateral definierten Interchange-Agreements nicht zu kennen, was bei der Vielzahl der von den Mandanten betriebenen Subsets auch nahezu unmoeglich waere. Mit anderen Worten: EDI ohne Absprache, wobei ein hypothetisches Ergebnis in Form eines Programmes fuer rund 34 000 Steuerberater mit etwa 1,9 Millionen Mandanten denkbar waere, das Individualloesungen und spezifische Schnittstellenvereinbarungen obsolet macht.
Der BSG ist als "Black Box" zu verstehen, die als Input die von Unternehmen inhaltlich geprueften und zur Verbuchung freigegebenen elektronischen Belege einliest und die entsprechenden Buchungssatzvorschlaege fuer die Fibu als Output liefert. Der BSG ist fuer diesen Einsatzzweck weitgehend autonom gestaltet, da sich in dem in der Regel heterogenen Softwareumfeld der Unternehmen keine spezifischen Schnittstellen (beispielsweise zu Materialwirtschafts- oder Produktionsplanungssystemen) voraussetzen beziehungsweise unterstuetzen lassen.
Zwei Module fuer zwei wesentliche Ziele
Das Projekt verfolgte im wesentlichen zwei Ziele: Zum einen sollte untersucht werden, ob und wie eine Verarbeitung des gesamten Edifact-Rahmenwerkes moeglich ist. Zum anderen galt es, die Chancen fuer eine teilautomatische Verbuchung auszuloten. Der BSG gliedert sich in zwei Module, die miteinander verbunden sind: Das sogenannte "EIPS" (Edifact Identifikations- und Pruefsystem) ermittelt in einem ersten Schritt die relevanten Edifact- Informationen aus der Rechnungsnachricht. Hierzu uebernehmen konverteraehnliche Tools ausgekluegelte Identifikations-, Berechnungs-, Vergleich- und Anpassungsaufgaben. Daten, die in jeder Edifact-Rechnung enthalten sind, werden dabei den entsprechenden Feldern des Buchungssatzes zugewiesen (beispielsweise Umsatz, Datum, Faelligkeit, Skonto, Belegnummer).
In einem zweiten Schritt ermittelt "Kontex" Kontenvorschlaege. Dabei ist davon auszugehen, dass die relevanten Informationen nicht in den zu verbuchenden Edifact-Nachrichten enthalten, sondern aus anderen Quellen zu beziehen sind. Zum Einsatz kommen hier Techniken aus dem Bereich der kuenstlichen Intelligenz - insbesondere dem fallbasierten Schliessen (CBR = Case-Based Reasoning). Dabei vergleicht der BSG Faelle der Vergangenheit, die in einer Fallbasis abgelegt sind, hinsichtlich ihrer Aehnlichkeit und gibt Buchungsvorschlaege (gegebenenfalls mit dem Grad ihres wahrscheinlichen Zutreffens) aus.
Die Erfahrungen bei der Konzeption des BSGs auf Basis des Edifact- Directories 91.1 muten im Prinzip kurios an. So entspricht eine Edifact-Rechnung nicht zwangslaeufig den gesetzlichen Anforderungen, unter anderem muessen beispielsweise nicht alle in Deutschland gesetzlich vorgeschriebenen Bestandteile (n 14 Abs. 2 Satz 1 UStG) zwingend in einer Edifact-Rechnung angegeben sein. Ueben Subset-Entwickler alle Auslassungsoptionen des Edifact- Regelwerkes aus, so besteht die Rechnung fast nur aus einem Umsatzbetrag. Nach der Edifact-Syntax ist aber auch eine Rechnung ohne Angabe der Umsatzsteuer moeglich.
Darueber hinaus bedingt die Verarbeitung des gesamten Edifact- Regelwerkes umfangreiche, von der technischen Umsetzung kaum zu bewaeltigende Berechnungs- und Konsistenzpruefungen. So koennen beispielsweise gleiche Informationen an unterschiedlichen Stellen einer Rechnung verschluesselt sein und sich gegenseitig ueberschreiben beziehungsweise ergaenzen. Hier ist unter anderem an die Betragspruefung unterschiedlicher Einzelpositionen mit jeweiligen Zu- und Abschlaegen sowie Mehrwertsteuersaetzen im Bezug zum Summenbetrag zu denken. Eine aehnliches Szenario stellt sich bei den annaehernd 20 Verschluesselungsmoeglichkeiten, die den Kommunikationspartner identifizieren beziehungsweise den 15 moeglichen Optionen, um das Datum zu spezifizieren, dar.
Freiheiten von Edifact erzeugen hohen Aufwand
Aufgrund der vielfaeltigen "Freiheitsgrade" von Edifact gestaltet sich also die Verarbeitung zumindest in Spezialfaellen als sehr aufwendig, wenn nicht gar als kontraproduktiv - trotz des in Fachkreisen und auch in der Literatur vielfach beschriebenen problemloesenden Charakters von Edifact. Eine Komplettloesung Edifact gibt es jedenfalls bis dato auf dem Markt nicht zu kaufen. Vielmehr sind in den meisten Faellen Aufbau- und Ablauforganisation im Unternehmen zu aendern beziehungsweise an die elektronischen Geschaeftsprozesse anzupassen. Mancher Anwender sah sich bei der Implementierung nicht mehr in der Lage, einen Verbesserungseffekt durch Edifact fuer sich zu erzielen, sondern eher in der Rolle, die Probleme der Norm Edifact quasi stellvertretend loesen zu muessen.
Ist diese Huerde genommen, stoesst der Anwender spaetestens dann auf das esoterische Feld der Normen. Dabei ist nur eines von vielen Problemen die Tatsache, dass der Edifact-Normungsprozess oft zu lange dauert und von vielen Beteiligten beziehungsweise Betroffenen als zu unuebersichtlich und in der Regel nicht beeinflussbar betrachtet wird. Viele Nachrichtentypen oder deren Bestandteile (Codes) sind in der bisherigen Norm noch nicht verfuegbar. Dadurch lassen sich betriebliche Geschaeftsdaten nicht immer verschluesseln beziehungsweise versenden. Schnell konstruierte Eigenentwicklungen treffen hier oft die Anwenderbelange exakter - und, die Ergebnisse sind schneller verfuegbar. Zum Vergleich: Die Aenderung einer Nachricht bei VDA dauert sechs Wochen, bei Odette sechs Monate und bei Edifact zwei Jahre.
Hinzu kommt, dass die Vielzahl unterschiedlicher Edifact- Directories und -Subsets hohe Kosten verursacht. Dabei haben Untersuchungen ergeben, dass die groessten Unterschiede zwischen einigen Subsets ueberwiegend in uneinheitlichen Verschluesselungen liegen. Anders formuliert: Durch eine restriktivere Normung waeren Aufwendungen dieser Art vermeidbar. Zusaetzlich sind Rahmenbedingungen im Bereich der Legislative, wie etwa die gesetzliche Anerkennung von EDI-Nachrichten, noch weitgehend ungeklaert; jedenfalls unterliegen bei gerichtlichen Auseinandersetzungen EDI-Nachrichten immer noch der sogenannten freien richterlichen Beweiswuerdigung (Augenscheinbeweis).
Nicht zuletzt erscheint auch die gesamte "Normungsmaschinerie" mit der Vielzahl unterschiedlich verantwortlicher Instanzen und deren Ergebnisse fuer den einzelnen Anwender nicht mehr nachvollziehbar. Man braucht hier etwa nur an die Menge von Directories mit ihren unterschiedlichen Normen zu denken, die auf absehbare Zeit inkompatibel bleiben werden. Gleiches gilt fuer Syntaxaenderungen, die eine Modifikation aller in der Wirtschaft bereits eingesetzten Anwendungen betreffen.Verfahren zur Behandlung von Change-Requests oder Abstimmprozeduren erscheinen selbst Insidern nicht selten unschluessig.
Eine Vereinheitlichung tut also not. Erfahrungen mit der branchenuebergreifenden und internationalen Verarbeitung von Edifact-Nachrichten zeigen, dass sich Edifact - entgegen aller Marketingfloskeln - mit seiner gegenwaertigen Subsetvielfalt in vielen Faellen immer noch als branchenbezogene Inselloesung darstellt. Nicht zuletzt anhand des BSG-Projektes offenbarten Defizite von Edifact, die an dessen normativer Kraft zweifeln lassen. Die Anwender stehen daher vor einer kuriosen Situation: Relevante Untersuchungen zeigen zum einen, dass sich Edifact im Vergleich zu Branchenstandards oder proprietaeren Formaten erst bei mehreren Anbindungen rechnet. Dem stehen die eben beschriebenen Defizite gegenueber, die eine Verbreitung nicht gerade foerdern. Nur eine einheitliche Norm, inklusive vereinheitlichter Subsets, koennte diesem Malus Abhilfe schaffen.
* Jens T. Miebach ist Mitarbeiter in der Abteilung Grundsatzstrategien der DATEV eG, Nuernberg, sowie wissenschaftlicher Mitarbeiter im Bereich Wirtschaftsinformatik I der Universitaet Erlangen-Nuernberg.