Kostengünstige B2B Integration auf Basis des ebXML Frameworks

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1. Einleitung
1.1 eBusiness im Wandel
1.2 Ziel und Aufbau dieser Arbeit

2. Probleme bei der Integration im klassischen EDI/EAI
2.1 Electronic Data Interchange
2.1.1 Potential ist vorhanden
2.1.2 EDI Standards und Prozesse
2.1.2.1 EDI Standards
2.1.2.3 Konvertierungsprozess
2.1.2.4 Kommunikationsprozess
2.1.3 Von der Punkt – zu Punkt Verbindungen zu Clearing Centern
2.1.4 Erhebliche Kosten verhindern den Durchbruch von EDI
2.2 Enterprise Applikation Integration
2.2.1 Informationsgewinnung und- Verarbeitung als Wettbewerbsvorteil
2.2.2 Integrationsbedarf am Beispiel eines e - Marketplaces
2.2.3 Ebenen der Integration
2.2.4 Aufbau und Funktionsweise klassischer EAI Werkzeuge
2.2.4.1 Prozessplanungsebene
2.2.4.2 Datentransport und Datentransformation
2.2.4.3 Integrationsarchitekturen
2.2.5 Kostenbetrachtung - Integration Broker schaffen nur bedingt Abhilfe
2.2.5.1 Entwicklungskosten für Schnittstellen
2.2.5.2 Total Cost of Ownership (TOC)
2.2.5.3 Opportunitätskosten
2.2.6 Risiken von EAI - Projekten

3. Über Webservices zu ebXML
3.1 Integration durch Webservices
3.1.1 XML
3.1.2 Interoperabilität durch SOAP Protokoll
3.1.3 Auffinden eines Webservice mit Hilfe von UDDI
3.1.4 Beschreibung von Webservices durch WSDL
3.2 Stärken und Schwächen der Webservices Architektur
3.2.1 Sicherheit
3.2.2 Transaktionen
3.2.3 Unterstützung der Geschäftsprozesse
3.2.4 Semantische Heterogenität
3.3 ebXML soll die Lücken der Webservice Architektur schließen

4. Das ebXML Konzept
4.1 Überblick
4.2 ebXML Szenario
4.3 ebXML Komponenten
4.3.1 ebXML Business Process
4.3.2 ebXML Message Service
4.3.3 ebXML Core Component Specification
4.3.4 ebXML Handelspartnerprofile
4.3.5 ebXML Registry/Repository

5. Effektive Umsetzung von ebXML
5.1 Einbeziehung bereits vorhandener und etablierter Standards
5.1.1 RosettaNet
5.1.2 cXML
5.1.3 OAGIS
5.1.4 Harmonisierung der Standards
5.1.5 Zusammenfassung
5.2 Verbreitung des Standards
5.3 Unterstützung der großen Softwarehersteller
5.4 Kostenlose Open Source Implementierungen
5.5 Konformität und Interoperabilität der Implementierungen

6 ebXML fähige Partner - Software
6.1 SAP Exchange Infrastruktur
6.1.1 Konzept und Architektur
6.1.1.1 Integration Repository
6.1.1.2 Integration Directory
6.1.1.3 Adapter
6.1.3 Mapping
6.1.4 Modellierung
6.1.5 Prozessdurchführung
6.2 XECO
6.2.1 Konzept und Architektur
6.2.2 Modellierung
6.2.3 Prozessdurchführung
6.2.4 Administration
6.2.5 Zusammenfassung

7. Fazit

Literaturverzeichnis

Anhang

Eidesstattliche Erklärung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Beispiel eines Geschäftsprozesses

Abbildung 2: Einordnung der EDI Regeln

Abbildung 3: EDI Kommunikationsmöglichkeiten

Abbildung 4: Integrationsbedarf einer Electronic Commerce Lösung

Abbildung 5: Aufbau eines klassischen EAI – Werkzeugs

Abbildung 6: Spaghetti Integration

Abbildung 7: Grobarchitektur Integration Broker

Abbildung 8: Beispiel für die Anwendung von Webservices

Abbildung 9: Rollen der Webservice – Standards

Abbildung 10: Struktur eines WSDL – Dokuments

Abbildung 11: ebXML Beispielszenario

Abbildung 12: ebXML Business Process – Realisierung von Geschäftsprozessen

Abbildung 13: Aufbau einer ebXML Nachricht

Abbildung 14: Erstellen und Implementieren von Core Components in einem Geschäftsprozess

Abbildung 15: Elemente des Integration Repositoryund Directory Abbildung 16: Mapping – Formen der Exchange Infrastruktur

Tabellenverzeichnis

Tabelle 1: Einsparungseffekte durch die Nutzung von EDI

Tabelle 2: Übersicht gängiger EDI Standards

Tabelle 3: Vorteile standardisierter EDI Übertragungen über Clearing Center

Tabelle 4: Dreistufige Integrationsmatrix

Tabelle 5: Entwicklungskosten je Schnittstelle mit und ohne Integration Broker

Tabelle 6: Risiken und Einflussfaktoren auf die Kosten einer Integrationslösung

Tabelle 7: UDDI Taxanomie: White-, Greenand Yellow Pages

Tabelle 8: Stärken und Schwächen von Webservices

Tabelle 9: Sicherheitsrelevante Anforderungen an Webservices

Tabelle 10: Rahmenbedingungen für Transaktionen zwischen Webservices

Tabelle 11: ebXML Lösungsansatz für die Schwächen der Webservice Architektur

Tabelle 12: Anforderungen an das ebXML Projekt

Tabelle 13: ebXML Konzepte

Tabelle 14: ebXML Erweiterungen zum SOAP Header

Tabelle 15: ebXML Erweiterungen zum SOAP Body

Tabelle 16: Übersicht RosettaNet

Tabelle 17: Übersicht cXML

Tabelle 18: Übersicht OAGIS

Tabelle 19: Aufgaben der Integration Engine

Tabelle 20: Komponenten des XI Integration Repository

Tabelle 21: Komponenten des XI Integration Directory

1. Einleitung

1.1 eBusiness im Wandel

“ We´re ever deeply enshared in a world wide web. Forests of techspeak, “ information superhighway” , ”global village”, “Infobahn”, litter conversation. Offline, you´re off-line, standing still as the

information age hurls past. The moral of the age is: “Go online, there`s gold in those nets.

You never know what you might catch.“”

L. C. Rees (1998)^[1]

Dieses Zitat ist symptomatisch für die Aufbruchstimmung im gesamten E- Business Bereich Ende der neunziger Jahre. Im Grunde war man sich in allen Unternehmen über alle Branchen hinweg einig, seine Geschäfte so schnell wie möglich online zu erledigen. Von einem absoluten „muss“ war hier die Rede, um in Zukunft noch konkurrenzfähig zu sein. Laut einer Studie von Forrester Research sollte der Bereich des B2B - Geschäftes bis zum Jahr 2003 ein Umsatzvolumen von 1,3 Billionen US-Dollar erreicht haben.^[2]

Doch mit der gleich rasanten Geschwindigkeit, mit der das Thema E- Business auf den Schreibtisch jedes verantwortlichen Vorstandes oder Managers gelangte, kehrte dann auch die allgemeine Ernüchterung ein. Einzig die Marktforscher der Gartner Group haben entgegen anders lautenden Prognosen bereits 1999 vorausgesagt, dass sich das E-Business anders entwickeln werde als von vielen prophezeit: Dem Höhenflug im Frühjahr 2000 werde der steile Absturz folgen. Gartner lag richtig.^[3] Die derzeitige Phase im E-Business bezeichnen die Gartner- Forscher als „die Talsohle der Ernüchterung“. Erst in sechs Jahren, also etwa ab 2008, kann man mit elektronisch abgewickelten Geschäften durchweg Gewinne realisieren, so die Prophezeiung.

Nichts desto Trotz, oder gerade deshalb stellt sich im Aufbau einer funktionierenden E-Business Landschaft und damit auch der Integration verschiedenster Systeme die große Herausforderung für die Zukunft.

Wenn man die Strukturen einzelner Unternehmen genauer betrachtet, wird man in vielen Fällen feststellen, das eine Vielzahl unterschiedlicher Systeme, Anwendungen und Datenquellen eingesetzt werden, die alle auf unterschiedlicher Weise miteinander kommunizieren. Durch die Vielzahl der verschiedenen, oft schlecht dokumentierten Kommunikationsverbindungen, stellt sich eine Anpassung an den betroffenen Systemen äußerst schwierig dar. Neue Probleme entstehen, wenn z.B. durch Firmenzukäufe oder Unternehmenszusammenschlüsse eine ganze Reihe neuer Systeme integriert werden müssen^[4].

Erforderlich ist neben der eigentlichen Übertragung der auszutauschenden Daten also eine Lösung des Problems der Heterogenität zu integrierender Anwendungen. Mittel -und langfristiges Ziel muss es daher sein, in diesem Bereich eine weitgehende Standardisierung zu erreichen.^[5]

Durch die Verbreitung des Internets und den dazugehörigen Technologien existieren nun neue Möglichkeiten, die im klassischen EDI^[6] /EAI^[7] nicht vorgesehen waren. Dabei zeigt sich immer deutlicher die grundlegende Rolle der Extensible Markup Language (XML) als universelles Datenformat für das Web. Als XML Anfang 1998 vom W3C^[8] verabschiedet wurde, sahen viele in ihr den neuen Hoffnungsträger im Bereich der Darstellung und Ü- bertragung von Daten über das Internet. Ziel von XML war es mit einer möglichst einfachen Struktur die Kommunikation zwischen verschiedenen Systemen und Plattformen zu realisieren und somit Implementierungskosten und langwierige Anpassungsprozesse zu vermeiden. Das Potential in XML reicht jedoch viel weiter als zunächst angenommen und verspricht in einer standardisierten Form in Zukunft die Interaktion zwischen verschiedenen Anwendungssystemen und auch den B2B Markt zu revolutionieren. Als vielversprechender Indikator zum Gelingen dieses Projekts kann die hohe Beteiligung großer Teile der Industrie, teilweise beobachtend, aber auch aktiv mitarbeitend verstanden werden.^[9]

Allerdings besteht häufig Unsicherheit über den tatsächlichen Nutzen und vor allem das „Wie“. Es fehlen Antworten auf die Fragen, was wichtige Akteure, was wichtige Technologien sind und wie XML basierte Architekturen aussehen können bzw. wessen Standards sie gehorchen sollten.^[10]

Auch sogenannte Webservices sind in aller Munde, wenn es um die unternehmensübergreifende Kommunikation geht, aber auch in der unternehmensinternen Integration sollen sie eine Rolle spielen. Doch die Webservice Architektur kann diese Aufgabe in ihrer jetzigen Struktur nur bedingt erfüllen:

Der aktuellen Studie „2002 Hype Cycle“ der Gartner Group folgend gehö- ren Web Services zu den künstlich hochgejubelten und in übertriebener Form in der Verkaufsförderung dargestellten Entwicklungen. So befänden sich die Internet gestützten Dienstleistungen, die bis vor kurzem noch als das Thema mit großartigen Wachstumsaussichten beschrieben wurde, im Sturzflug ins Tal der Desillusionen. Sie werden, so die Einschätzung von Gartner, frühestens in zwei bis fünf Jahren einsatzbereit sein.^[11]

Diverse Initiativen, darunter auch ebXML^[12], sind angetreten, dieser Prognose entgegen zu wirken und die Lücken der Webservice Architektur zu schließen.

Entscheidend für die Zukunftsperspektive wird vor allem auch die Flexibilität des entstehenden Standards als Integrationslösung sein. Nur wenn die Konzeption eine Erweiterbarkeit auf neue Begebenheiten im Geschäftsfeld des E-Business erlaubt und das Zusammenspiel von Systemen unterschiedlichster Art dauerhaft sicherstellt , wird sie sich in der Breite durchsetzen. Wenn die Wirtschaft, und hier im besonderen die finanziell schlechter ausgestatteten Kleinund mittelständischen Unternehmen den langfristigen Nutzen einer solchen Lösung erkennen, werden Investitionshemmnisse abgebaut, die Kostensituation wird transparenter und die Unternehmenskalkulation dadurch wesentlich erleichtert.

1.2 Ziel und Aufbau dieser Arbeit

Integration ist eines der Schwerpunktthemen heutiger IT Landschaften in modernen Unternehmen. Nach dem klassischen EDI wurde mit EAI der nächste Versuch einer allumfassenden Systemintegration gestartet, sowohl im unternehmensinternen Bereich, wie auch unternehmensübergreifend. Ziel ist es die Integrationskosten zu reduzieren und somit vor allem auch Kleinund Mittelständische Unternehmen mit einzubeziehen. Webservices sollen hier einen entscheidenden Fortschritt machen.

Die entscheidenden Fragen, die es zu klären gilt sind: was sind eigentlich die Kostentreiber derartiger Projekte und wie kann man sie entscheidend reduzieren? Wie muss eine Lösung aussehen, die aufwandsarm umgesetzt werden kann? Was bietet der aktuelle Softwaremarkt für Lösungen?

Am Anfang dieser Ausführung wird auf die Integrationsprobleme im Zusammenhang mit dem klassischem EDI eingegangen. Es wird aufgezeigt warum diese Technologie den Erwartungen bis zum heutigen Tage nicht gerecht werden konnte und wo weiterhin Handlungsbedarf besteht, um den einstmalig so fortschrittlichen Ansatz zu einer allgemeingültigen und vor allem zukunftsorientierten Lösung weiter zu entwickeln. Es wir auf die Enterprise Applikation Integration als Verbesserung des klassischen EDI eingegangen und aufgezeigt, wo ihre Schwächen liegen, bzw. was die Kosten bei EAI Projekten in die Höhe treibt.

Es wird auf Webservices als potentielle Integrationshelfer eingegangen. Es werden Ihre Schwächen herausgearbeitet und aufgezeigt, warum sie in ihrer aktuellen Form nicht in der Lage sind als komplette Lösung zu fungieren. Es wird mit ebXML ein neuer Ansatz dargestellt, um diesem Misstand entgegen zu wirken.

Es wird ein Überblick über den Stand der Technik, sowie den Bestandteilen und Komponenten des ebXML Frameworks und seiner Funktionsweise gezeigt.

Anschließend werden Voraussetzungen beschrieben, um eine effektive Umsetzung des ebXML Konzepts zu erreichen.

Es werden Softwarelösungen mit Unterstützung der ebXML – Spezifikationen vorgestellt.

In einem abschließenden Fazit werden die Zukunftsperspektiven von ebXML beurteilt.

2. Probleme bei der Integration im klassischen EDI/EAI

2.1 Electronic Data Interchange

Die Anfänge von EDI liegen schon weit zurück. Bereits seit Ende der sechziger Jahre nutzen Unternehmen diese Technologien zum elektronischen Austausch strukturierter Geschäftsdokumente. Als Pionier gilt hier das Laces – Kommunikationssystem für Cargo Informationen am Londoner Flughafen Heathrow. Auch der MAN Konzern bedient sich seit mehr als vierzig Jahren dieser damals höchst innovativen Form der Kommunikation, allerdings anfänglich nur zum unternehmensinternen Datenaustausch.^[13]

2.1.1 Potential ist vorhanden

Die Einsparungspotentiale und der enorme Nutzen von EDI kann leicht nachvollzogen werden, wenn man den gesamten Ablauf eines Geschäftsprozesses mit einem Handelspartner betrachtet. (siehe Abbildung 1) Angefangen bei der direkten Kommunikation mit dem Partner ( Anfrage, Angebot, Bestellung, Bestätigung, Bezahlung) bis hin zur unternehmensinternen Weiterverarbeitung (Buchhaltung, Produktion, Versand) durchläuft ein Auftrag eine Vielzahl von Stellen und muss in den einzelnen Systemen erfasst werden. EDI ermöglicht nun die Automatisierung durch direkte Kommunikation der Systeme der einzelnen Geschäftspartner miteinander. Tabelle 1 fasst die Vorteile zusammen, die durch die medienbruchlose Weiterverarbeitung der Daten mittels EDI realisiert werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Beispiel eines Geschäftsprozesses, eigene Darstellung

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Einsparungseffekte durch die Nutzung von EDI

Es wird von branchenunabhängigen Kosteneinsparungen von 5 – 6% des Umsatzes bzw. einer Reduktion der Bruttoselbstkosten für Geschäftsdokumente in der Größenordnung von 10 :1 gesprochen. Ein weiterer Vorteil stellt sich darin dar, den Kunden einen weitaus besseren Service bieten zu können.^[14]

Wesentliche Verbesserungen, um die anfangs noch proprietären EDI Ü- bertragungen geschäftstauglicher zu machen, wurden jedoch erst durch die Einführung von Standards und die zunehmende Loslösung von den klassischen Point – to – Point Verbindungen erreicht.

2.1.2 EDI Standards und Prozesse

Da EDI-Nachrichten automatisch verarbeitet werden sollen, muss auf allgemein anerkannte Strukturen und Standards Rücksicht genommen werden. Einerseits ist die Darstellung und Reihenfolge der Datenelemente

(Syntax) festzulegen, also wie eine Nachricht aus Segmenten (z. B. Adresse, Preis), die sich aus mehreren Datenelementen (z.B. Zahl, Zeichenfolge) zusammensetzen, aufgebaut ist. Andererseits ist festzulegen, welche Bedeutung die einzelnen Datenelemente bzw. Segmente haben (Semantik).

Zusätzlich muss definiert werden, wie diese Daten in Nachrichten verpackt werden, die über Kommunikationsnetzwerke übertragen werden können. Diese Vereinbarungen werden in Standards zusammengefasst, die neben den allgemeinen Regeln zur Bildung von Nachrichten eine Liste der derzeit gültigen Nachrichten (Verzeichnis) enthalten.

Bei den EDI-Standards unterscheidet man nach bilateralen, multilateralen und Industrie-Standards, sowie nach echten Standards, die von Normenorganisationen registriert und verwaltet werden. Industrie-Standards haben sich aufgrund von fehlenden EDI-Normen zu Beginn der 80er Jahre (auf Initiative von großen Unternehmen) in der Praxis durchgesetzt.^{[15] [16]}

2.1.2.1 EDI Standards

Der erste, offiziell von einer Normen-Organisation registrierte, EDI- Standard war der ANSI X.12 des amerikanischen Normeninstitutes. Die offizielle Registrierung des weltweit anerkannten EDI-Standards UN/EDIFACT erfolgte von der Internationalen Normungsorganisation (ISO) erst im Jahr 1987.

UN/EDIFACT ist nicht auf eine bestimmte Branche, einen Industriezweig oder ein nationales Umfeld festgelegt und wird derzeit vor allem in Europa angewandt, wobei die anderen Kontinente immer mehr zu UN/EDIFACT übergehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Einordnung der EDI Normen, Quelle StratEDI

Der Standard enthält die Syntax (vergleichbar einer Grammatik einer Sprache, wobei EDIFACT dann der Sprache entspricht), die Datenelemente als die Informationsgrundsteine, die Segmente als vordefinierte Sätze funktionell zusammenhängender Datenelemente zur Abdeckung einer geschäftlichen Funktion (z. B. Adresse, Preisinformation) und die Strukturen von Nachrichten zur Abdeckung von Geschäftsfunktionen (z. B. Bestellung, Rechnung). Die Regeln und die Informationskomponenten des Standards mit der notwendigen Dokumentation zur Anwendung des Standards werden in Verzeichnissen/Directories jeweils zweimal jährlich von der UN/ECE veröffentlicht. Bei den meisten Standards, gleichgültig ob sie unternehmensspezifisch, branchenspezifisch oder regional begrenzt sind, kann eine schrittweise Migration an den weltweit gültigen branchenübergreifenden Standard UN/EDIFACT erwartet werden (siehe Abbildung 2).^[17]

Tabelle 2 zeigt eine Übersicht der aktuell gängigsten EDI Standards.

Abbildung in dieser Leseprobe nicht enthalten^[18]

Tabelle 2: Übersicht gängiger EDI Standards

2.1.2.2 Das Problem der Subsets

EDI-Nachrichten sind allgemein definiert worden, um in allen Branchen verwendet werden zu können. Innerhalb einer EDIFACT - Nachricht können Komponenten (Segmente, Datenelemente, Schlüssel) auch optional sein. Das führt dazu, dass für verschiedene Branchen sogenannte Subsets (Untermengen von Nachrichten) definiert werden, was die branchenunabhängige Verwendung von EDI wiederum erschwert. (z. B. die Chemiebranche verwendet bestimmte Segmente und Schlüssel, die für die Konsumgüterbranche keine Bedeutung haben; die Konsumgüterbranche verwendet dafür aber andere Segmente und Schlüssel, die für die Chemiebranche unbrauchbar sind). Solche Subsets sind für bestimmte Branchen durch internationale EDI-Anwendergruppen auf Basis von EDIFACT- Nachrichten entwickelt worden.

Zur Zeit gibt es ca. 30 solcher PEG's^[19] (die bekanntesten: CEFIC für die chemische Branche, EANCOM für die Konsumgüterindustrie, EDIFICE für die Elektronikund Computerindustrie, EDIBUILD für das Bauwesen, EMEDI für den Gesundheitsbereich, ODETTE für die Automobilindustrie).^[20]

Der Vorteil der Einrichtung bzw. Verwendung von Subsets gegenüber EDIFACT liegt in der einfacheren Handhabung, da nur ein begrenzter, für die Branche notwendiger Teil von EDIFACT gepflegt und übermittelt werden muss. Als nachteilig für den EDI-Anwender erweist sich jedoch, dass verschiedene Subsets nicht kompatibel zueinander sind.^[21]

Dies führt oft zu Schwierigkeiten bei Anwendern, die gefordert sind, bspw. sowohl SEDAS- als auch EANCOM -Nachrichten auszutauschen. Welcher Standard für ein Unternehmen geeignet ist, hängt vor allem von der Branche ab, in der das Unternehmen tätig ist^[22]

So ernüchternd es klingt, aber oft stellt sich diese Entscheidung für den EDI-Anwender gar nicht. Marktstarke Geschäftspartner wie die großen Handelsketten geben in der Regel den Lieferanten das Austauschformat vor. Positiv zu beurteilen ist die generelle Tendenz der EDI- Großanwender, sich von branchenweiten oder lediglich national austauschbaren Formaten wie SEDAS oder VDA allmählich zu verabschieden^[23]

Grundsätzlich lässt sich der EDI Datenaustausch als Ganzes in zwei unterschiedliche Prozesse unterteilen, den Konvertierungsprozess und den Kommunikationsprozess.

2.1.2.3 Konvertierungsprozess

Um die aus einem Warenwirtschaftsoder Finanzbuchhaltungssystem in einem Inhouse - Format zur Verfügung gestellten Daten in die EDIFACT- Norm übersetzen zu können, bedarf es eines Konverters. Dieser Konverter ist Teil des EDI-Systems, das sowohl die Kommunikation als auch die Konvertierung der Daten vollautomatisch abwickelt. Damit die in der EDIFACT- Norm übertragenen Daten von der Applikation des EDI - Partners automatisch verarbeitet werden können, muss auf der Seite des EDI-Partners ebenfalls ein EDI-System eingesetzt werden, welches die Übersetzung der Daten aus der EDIFACT- Norm in ein für seine Anwendung verarbeitbares Inhouse - Format übernimmt. Die Möglichkeit der automatischen Weiterverarbeitung der aus dem EDIFACT - Format konvertierten Daten in ein zuvor eindeutig definiertes Flatfile^[24] ermöglicht den Datenimport in betriebswirtschaftliche Applikationen. Verschiedene Applikationen verfügen zumeist über Standardschnittstellen für den EDI- Datenaustausch, die für die Konvertierung im EDI-System gemäß den Anforderungen des einzelnen Kunden gefüllt werden können.^[25]

2.1.2.4 Kommunikationsprozess

Beim EDI-Kommunikationsprozess lassen sich prinzipiell zwei verschiedene Formen unterscheiden, die in der Praxis zur Anwendung kommen. Bei der ersten Alternative der Kommunikation wird eine direkte Verbindung (Punkt zu Punkt) zwischen Sender und Empfänger aufgebaut. Gerade bei der Übertragung von zeitkritischen Daten für die Justin - Time- Belieferung wird diese Art der Kommunikation praktiziert, weshalb sie in der Automobilindustrie weit verbreitet ist. Die zweite Möglichkeit der Kommunikation entkoppelt Sendeund Empfangsvorgang durch die Verwendung einer Mailbox (Store – and – Foreward ).^[26]

2.1.3 Von der Punkt – zu Punkt Verbindungen zu Clearing Centern

Der kürzeste Kommunikationsweg zwischen zwei Systemen ist die direkte Punkt zu Punkt Verbindung über eine Telefonoder Datenleitung. Neben dem Effekt, dass damit ein Zutritt in den Rechner des Geschäftspartners zustande kommt - was nicht immer erwünscht ist - ist es auch nicht realistisch anzunehmen, dass man zu hundert, zweihundert oder mehr Geschäftspartnern derartige Verbindungen auf Wählverbindungsbasis wirtschaftlich betreiben kann.( siehe auch Kapitel 2.2.3). Abbildung 3 zeigt die verschiedenen Kommunikationsmöglichkeiten beim elektronischen Datenaustausch.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: EDI Kommunikationsmöglichkeiten; Quelle stratEDI

Um die direkten Verbindungen zu entkoppeln bedient man sich bei der zweiten Lösung elektronischer Postämter, welche den Datentransport und auch eventuelle Zwischenspeicherungen vornehmen. Wichtig für den Anwender ist das Faktum, unabhängig von der Einsatzbereitschaft des Rechners beim Partner die Übermittlung der Daten vornehmen zu können und den Empfang vom elektronischen Postamt bestätigt zu bekommen. Anbieter von derartigen Diensten nennt man Value Added Network Services (VANS) oder Clearing - Center.

Abbildung in dieser Leseprobe nicht enthalten^[27]

Tabelle 3: Vorteile standardisierter EDI Übertragungen über Clearing Center

Dabei handelt es sich um Dienstleistungen der Telekommunikation, welche über die bloße Datenübertragung hinausgehen, wie das Zwischenspeichern der Daten, Protokollieren aller Vorgänge, automatisches Wiederholen im Fehlerfall, oder das Vorhandensein einer Auskunftsund Unterstützungsfunktion (Help Desk), die idealerweise 24 Stunden pro Tag verfügbar ist.

Tabelle 3 verdeutlicht noch einmal die wesentlichen Vorteile der standardisierten EDI Übertragungen über Clearing Center bzw. VANS.^[28]

2.1.4 Erhebliche Kosten verhindern den Durchbruch von EDI

Trotz dieser schlagenden Argumente (Kostenreduzierung, Mehrfacheingaben, Erfassungsfehler, etc.) hat EDI bis heute den erwarteten Durchbruch nicht geschafft. Nur ein geringer Prozentsatz der Unternehmen, für die der Einsatz von Vorteil wäre, nutzen tatsächlich EDI. Gründe dafür finden sich in den erheblichen Setup –und Betriebskosten, die bisher vor allem die KMU^[29] nicht zu tragen bereit sind. Das Existieren unterschiedlicher Standards, welche in der Regel nicht zueinander kompatibel sind, stellt eine weitere Hürde für kleinere Unternehmen dar, sich für eine Lösung zu entscheiden So ist bis jetzt die Nutzung von EDI vornehmlich grossen Konzernen vorbehalten, da sie trotz hoher Implementierungs- –und Integrationskosten durch ihr immenses Transaktionsvolumen Einsparungen realisieren können. Nach einer Studie nutzen 52% der deutschen und 75% der amerikanischen Grossunternehmen EDI. Deutsche Grossunternehmen wickeln danach mit 21% ihrer Lieferanten ihre Geschäfte über EDI ab und erwirtschaften damit 38% ihrer Umsätze. Ein wesentlicher Grund für die hohen Kosten von EDI – Lösungen sind aufwendige Anpassungen an die jeweils verwendeten Standards der Kommunikationspartner bzw. der eigenen Systeme (Mapping). Zudem sind EDI Konverter-Tools sehr teuer und nicht unbedingt für jede gewünschte Plattform zu haben, wodurch zusätzliche Kosten entstehen. Eine Folge hiervon ist, dass viele Kleinund Mittelständische Unternehmen, die EDI häufig nur auf Druck der grossen Geschäftspartner eingeführt haben, stark unter der zusätzlichen finanziellen Belastung leiden und ein weiteres Hemmnis für „EDI willige“ Unternehmen darstellen. Mit der schnell anwachsenden Entwicklung des Internets und neuer Technologien kann hier nun Abhilfe geschaffen werden, nicht zuletzt weil ein nicht zu verachtender Anteil der Kosten in der Vergangenheit gerade durch die Übermittlung der Nachrichten über VANS entstanden ist. So zahlte ein Unternehmen mit ca. 25.000 EDI Nachrichten Mitte der neunziger Jahre zwischen 14.000,- und 25.000,- US Dollar pro Monat an seinen VAN Provider. Mit der Nutzung des Internet als Übertragungsmedium können diese Kosten stark reduziert werden. Für die gleiche Anzahl von Nachrichten würden über das Internet nur ca. 1900,- US Dollar an Kommunikationskosten anfallen. In der aktuellen Struktur, mit mehreren verschiedenen Standards und Plattformen muss im Prinzip die Verbindung zu jedem einzelnen Partner kostenintensiv und individuell angepasst, konfiguriert, abgestimmt und gepflegt werden, entweder in Eigenregie oder aber durch Outsourcing an einen VAN Provider. Erst wenn es einen allgemeingültigen Standard gibt , der flexibel und nicht auf einzelne Parteien ausgerichtet, sondern Kommunikation mit nahezu allen teilnehmenden Handelspartnern ermöglicht, werden kleinere Firmen in der Lage sein, in entsprechende Systeme oder Technologien zu investieren und diese dann auch gewinnbringend für sich einzusetzen.^[30]

Ein Schema für die Kostenberechnung einer EDI – Lösung befindet sich im Anhang dieser Arbeit.

2.2 Enterprise Applikation Integration

Bis Anfang der neunziger Jahre herrschten noch „Insellösungen“ auf den Landkarten betrieblicher Anwendungssysteme vor, also Softwareprodukte, die nur isoliert in einem Aufgabenbereich eingesetzt werden konnten. Seit dem fand nach und nach eine verstärkte Integration der Softwareprodukte statt, die zur sogenannten integrierten Informationsverarbeitung und zu entsprechenden Softwareprodukten wie dem R/3 System der SAP AG führte. Die Integration wurde im Wesentlichen durch Datenbanksysteme mit zentralem Datenmanagement erreicht, auf denen alle Anwendungssysteme aufsetzten Man spricht deshalb auch von Datenintegration. Durch eine darauf aufbauende Funktionsintegration können aggregierte und abgeleitete Daten automatisch fortgeschrieben werden. Durch den Einsatz des Internets nimmt die Integration zu und gleichzeitig neue Formen an, da durch die Softwareprodukte ebenfalls unternehmensübergreifende Geschäftsprozesse unterstütz werden müssen. Hier gerät die Datenintegration an ihre Grenzen, da mehrere Unternehmen meist nicht auf ein gemeinsames Datenbanksystem aufsetzen. Die Funktionsintegration erfährt eine starke Herausforderung, da Datenbestände verteilter Unternehmen zumindest in Teilbereichen konsistent gehalten werden müssen.^[31]

Der Traum einer allumfassenden integrierten Softwarelösung für alle Bereiche der betrieblichen Informationsverarbeitung ist jedoch geplatzt. Selbst Anbieter wie SAP gelingt es trotz größter Anstrengungen nicht, die stetig zunehmenden Anforderungen an die Informationsverarbeitung in einer Produktfamilie befriedigend und integrativ umzusetzen.

2.2.1 Informationsgewinnung und- Verarbeitung als Wettbewerbsvorteil

Nach der ERP^[32] Einführung werden immer mehr strategische Applikationen implementiert:

- Customer Relationship Management - Systeme (CRM) zum Pflegen von Kundenbeziehungen und sammeln von Marketing Daten.
- Knowledge Management - Systeme (KM) zur Verwertung und Bewahrung von unternehmensinternem Wissen
- Business Intelligence (BI) Lösungen zum Aufspüren verdeckter Zusammenhänge
- Supply Chain Management – Systeme (SCM) zur Abstimmung der Teilnehmer einer Lieferkette
- Senkung der Lagerkosten
- Senkung der Produktionskosten
- Erhöhung der Kundenzufriedenheit durch kürzere Lieferzeiten und individuelle Fertigung
- e-Procurement und virtuelle Marktplätze zur Senkung der Beschaffungskosten
- Online Shops zur Senkung der Vertriebskosten

Doch gerade bei diesen Lösungen zeigt sich sofort, dass Wettbewerbsvorteile nur dann erzielbar sind, wenn die Geschäftsprozesse nicht an den jeweiligen Grenzen der Software halt machen, sondern applikationsübergreifend durchgeführt werden. Die verschiedenen Rationalisierungsund Verbesserungswellen in den Fertigungsbereichen führen nach dem eher technischen Wettbewerb über Produkteigenschaften und Preisen nun zum organisatorischen Wettbewerb über die Abwicklung der Geschäftsprozesse.

[...]

---

^[1] vgl. Weitzel/Harder/Buxmann, Electronic Business und EDI mit XML (2001), dpunkt Verlag, S.1

^[2] vgl. Weitzel/Harder/Buxmann, Electronic Business und EDI mit XML (2001), dpunkt Verlag, S.1

^[3] vgl., Siegfried Grass, Neue Techniken Top oder Flop, Wirtschaftswoche Heute 2002, http://www.wiwo.de/wiwowwwangebot/fn/ww/SH/0/sfn/buildww/cn/cn_artikel/id/62478!160498/ layout/58327/depot/0/

^[4] vgl. Gunjan Samtani, Dimple Sadhwani Easier Enterprise Application Integration?, http: //www.webservicesarchitect.com/content/articles/samtani01.asp

^[5] vgl., Günter Stuhec, Einheitlich Kommunizieren, . SAP Info Nr.95

^[6] Electronic Data Interchange

^[7] Enterprise Applikation Integration

^[8] World Wide Web Consortium

^[9] vgl. Weitzel/Harder/Buxmann, Electronic Business und EDI mit XML (2001), dpunkt Verlag S.2

^[10] vgl. Weitzel/Harder/Buxmann, Electronic Business und EDI mit XML (2001), dpunkt Verlag S.1

^[11] vgl., Siegfried Grass, Neue Techniken Top oder Flop, Wirtschaftswoche Heute 2002, http://www.wiwo.de/wiwowwwangebot/fn/ww/SH/0/sfn/buildww/cn/cn_artikel/id/62478!160498/ layout/58327/depot/0/

^[12] Electronic Business XML

^[13] vgl. Weitzel/Harder/Buxmann, Electronic Business und EDI mit XML (2001), dpunkt Verlag S.6

^[14] vgl. Weitzel/Harder/Buxmann, Electronic Business und EDI mit XML (2001), dpunkt Verlag S.6-8

^[15] vgl. stratEDI, Gesellschaft für Kommunikationskonzepte und –Lösungen mbH, Normen und Standards, http://www.ecin.de/edi/technologie/index-2.html

^[16] vgl. EDI Business Austria, EDI Standards, http://www.edi.at/kapitel2.htm

^[17] vgl. Edi Business Austria, Edi Standards, http://www.edi.at/kapitel2.htm,

^[18] Europäische Artikel Nummerierung

^[19] Paneuropäische EDI-Anwender Gruppen

^[20] vgl. EDI Business Austria, Anwendungsgruppen und Subsets, http://www.edi.at/kapitel2.htm,

^[21] Bei näherer Betrachtung der EDIFACT-Subsets ist festzustellen, dass es sich bspw. bei VDA und SEDAS um keine EDIFACT-Subsets gemäß obiger Definition handelt, sondern um branchenweit fest definierte Austauschformate, die jedoch nicht in die für EDIFACT übliche Trennzeichensyntax konvertiert werden. Daher erfordert der Austausch von SEDAS- und VDA- Nachrichten keine Konvertierung im üblichen Sinn.

^[22] vgl. stratEDI, Gesellschaft für Kommunikationskonzepte und –Lösungen mbH, Normen und Standards, http://www.ecin.de/edi/technologie/index-2.html

^[23] vgl. stratEDI, Gesellschaft für Kommunikationskonzepte und –Lösungen mbH, Normen und Standards, http://www.ecin.de/edi/technologie/index-2.html

^[24] Inhouse - Format der empfangenden Anwendung

^[25] vgl.stratEDI, Edi technologie, http://www.ecin.de/edi/index.html

^[26] vgl.stratEDI, Edi Technologie, http://www.ecin.de/edi/index.html

^[27] United Nations Economic Commission for Europe

^[28] vgl. EDI Business Austria, Kommunikationsmethoden, http://www.edi.at/kapitel2.htm

^[29] Kleinund mittelständische Unternehmen

^[30] vgl. Weitzel/Harder/Buxmann, Electronic Business und EDI mit XML (2001), dpunkt Verlag S.6-8

^[31] vgl. Appelrath/Ritter, R/3 Einführung – Methoden und Werkzeuge (2000), Springer Verlag, S.5

^[32] Enterprise Resource Planing