ID 6911
Kuhlmey, Ole: Kostengünstige B2B-Integration auf der Basis des ebXML- Frameworks.
Hamburg: Diplomica GmbH, 2003
Zugl.: Pforzheim, Fachhochschule, Diplomarbeit, 2003
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2003
Printed in Germany
Inhaltsverzeichnis
Inhaltsverzeichnis
Inhaltsverzeichnis ...I
Abkürzungsverzeichnis ... IV
Abbildungsverzeichnis ... VII
Tabellenverzeichnis ... VIII
1.
Einleitung ...1
1.1 eBusiness im Wandel ...1
1.2 Ziel und Aufbau dieser Arbeit ...4
2.
Probleme bei der Integration im klassischen EDI/EAI...6
2.1 Electronic Data Interchange ...6
2.1.1
Potential ist vorhanden ...6
2.1.2
EDI Standards und Prozesse ...8
2.1.2.1
EDI Standards...9
2.1.2.3
Konvertierungsprozess ...13
2.1.2.4
Kommunikationsprozess...14
2.1.3
Von der Punkt zu Punkt Verbindungen zu Clearing
Centern ...14
2.1.4
Erhebliche Kosten verhindern den Durchbruch von EDI .16
2.2 Enterprise Applikation Integration...18
2.2.1
Informationsgewinnung und- Verarbeitung als
Wettbewerbsvorteil...19
2.2.2
Integrationsbedarf am Beispiel eines e - Marketplaces ...20
2.2.3
Ebenen der Integration ...21
2.2.4
Aufbau und Funktionsweise klassischer EAI Werkzeuge 23
2.2.4.1
Prozessplanungsebene ...24
2.2.4.2
Datentransport und Datentransformation...25
2.2.4.3
Integrationsarchitekturen ...25
2.2.5
Kostenbetrachtung - Integration Broker schaffen nur
bedingt Abhilfe ...27
I
Inhaltsverzeichnis
2.2.5.1
Entwicklungskosten für Schnittstellen ...27
2.2.5.2
Total Cost of Ownership (TOC)...32
2.2.5.3
Opportunitätskosten...32
2.2.6
Risiken von EAI - Projekten...33
3.
Über Webservices zu ebXML...36
3.1 Integration durch Webservices ...36
3.1.1
XML ...39
3.1.2
Interoperabilität durch SOAP Protokoll ...40
3.1.3
Auffinden eines Webservice mit Hilfe von UDDI...41
3.1.4
Beschreibung von Webservices durch WSDL ...43
3.2 Stärken und Schwächen der Webservices Architektur ...44
3.2.1
Sicherheit ...46
3.2.2
Transaktionen...47
3.2.3
Unterstützung der Geschäftsprozesse ...49
3.2.4
Semantische Heterogenität ...50
3.3 ebXML soll die Lücken der Webservice Architektur schließen ...50
4.
Das ebXML Konzept ...52
4.1 Überblick ...52
4.2 ebXML Szenario ...53
4.3 ebXML Komponenten...55
4.3.1
ebXML Business Process...55
4.3.2
ebXML Message Service...57
4.3.3
ebXML Core Component Specification...61
4.3.4
ebXML Handelspartnerprofile...62
4.3.5
ebXML Registry/Repository...63
5.
Effektive Umsetzung von ebXML ...65
5.1 Einbeziehung bereits vorhandener und etablierter Standards...67
5.1.1
RosettaNet ...67
5.1.2
cXML ...68
5.1.3
OAGIS ...69
5.1.4
Harmonisierung der Standards...70
5.1.5
Zusammenfassung ...73
5.2 Verbreitung des Standards...74
II
Inhaltsverzeichnis
5.3 Unterstützung der großen Softwarehersteller...75
5.4 Kostenlose Open Source Implementierungen ...75
5.5 Konformität und Interoperabilität der Implementierungen...76
6
ebXML fähige Partner - Software ...78
6.1 SAP Exchange Infrastruktur ...78
6.1.1
Konzept und Architektur ...78
6.1.1.1
Integration Repository...79
6.1.1.2
Integration Directory...80
6.1.1.3
Adapter ...81
6.1.3
Mapping...81
6.1.4
Modellierung...82
6.1.5
Prozessdurchführung ...83
6.2 XECO ...84
6.2.1
Konzept und Architektur ...84
6.2.2
Modellierung...86
6.2.3
Prozessdurchführung ...86
6.2.4
Administration...87
6.2.5
Zusammenfassung ...87
7.
Fazit ...89
Literaturverzeichnis ... A
Anhang ... E
III
Abkürzungsverzeichnis
Abkürzungsverzeichnis
ACID
Atomar,
Consistent,
Isolated,
Durable
CRM
Customer
Relationship
Management
BASDA
Business Application Software Developers As-
sociation
BI
Business
Intelligence
BMEcat
Deutscher Online Katalog Standard
BOD
Business
Object
Document
BPSS
Business
Process
Specification
Schema
B2B
Business
to
Business
B2C
Business
to
Consumer
CORBA IDL
Corba Interface Definition Language
DCOM
Distributet Component Object Model
DTD
Doc
Type
Definition
CPA
Collaboration
Partner
Agreement
CPP
Collaboration
Partner
Profile
CRM
Customer
Relationship
Management
cXML
Commerce Extensible Markup Language
DCOM
Distributed Component Object Model
DTD
Document
Type
Definition
EAI
Enterprise
Applikation
Integration
ebXML Electronic
Business
XML
EDI
Electronic
Data
Interchange
ERP
Enterprise
Resource
Planning
HTML
Hyper
Text
Markup
Language
HTTP
Hyper
Text
Transfer
Protocol
HTTPS
Hyper Text Transfer Protocol Secure
IIOP
Internet
Inter-ORB
Protocol
IT
Information
Technologie
KM
Knowledge
Management
KMU
Klein-
und
mittelständische
Unternehmen
LDAP
Lightweight
Directory
Access
Protocol
NIST
National Institut of Standards and Technologie
IV
Abkürzungsverzeichnis
OAGIS
Open Applications Group Integration Specifica-
tion
OASIS
Organisation for the Advancements of Struc-
tured Information Standards
PEG
Paneuropäische EDI Anwender Gruppen
PIP
Partner
Interface
Processes
RMI
Remote
Method
Invocation
SAML
Security
Assertions
Markup
Language
SCM
Supply
Chain
Management
SGML
Standard
Generalized
Markup
Language
SMTP
Simple
Mail
Transfer
Protocol
SOAP
Simple
Object
Access
Protocol
TOC
Total
Cost
of
Ownership
TPA
Trading Partner Agreement
UBL
Unified Business Language
UDDI
Universal Descrtiption, Discovery and Integra-
tion
UID Universal
Identifier
UN/CEFACT
United Nations Center for Trade Facilitation and
Electronic Business
UN/ECE
United Nations Economic Commission for
Europe
UN/EDIFACT
United Nations Electronic Data Interchange For
Administration, Commerce and Transport
URI
Universal
Resource
Identifier
URL
Universal
Resource
Locator
VAN
Value
Added
Networks
WSFL
Webservice
Flow
Language
WSDL
Webservice
Description
Language
WWW
World
Wide
Web
XAML
Transaction
Authority
Markup
Language
xCBL
XML
Common
Business
Library
XKMS
XML
Key
Management
Specification
V
Abkürzungsverzeichnis
XLANG
Web Services for Business Process Design
XML
Extensible
Markup
Language
XMLcat XML
Library
Katalog
VI
Abbildungsverzeichnis
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 Ge-
schäftsprozessen
Abbildung 13:
Aufbau einer ebXML Nachricht
Abbildung 14:
Erstellen und Implementieren von Core Components
in einem Geschäftsprozess
Abbildung 15:
Elemente des Integration Repository- und Directory
Abbildung 16:
Mapping Formen der Exchange Infrastruktur
VII
Tabellenverzeichnis
Tabellenverzeichnis
Tabelle 1:
Einsparungseffekte durch die Nutzung von EDI
Tabelle 2:
Übersicht gängiger EDI Standards
Tabelle 3:
Vorteile standardisierter EDI Übertragungen über Cle-
aring Center
Tabelle 4:
Dreistufige Integrationsmatrix
Tabelle 5:
Entwicklungskosten je Schnittstelle mit und ohne In-
tegration Broker
Tabelle 6:
Risiken und Einflussfaktoren auf die Kosten einer In-
tegrationslösung
Tabelle 7:
UDDI Taxanomie: White-, Green- and 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 Web-
service 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
VIII
Einleitung
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 Stu-
die 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 lau-
tenden 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,
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/
1
Einleitung
kann man mit elektronisch abgewickelten Geschäften durchweg Gewinne
realisieren, so die Prophezeiung.
Nichts desto Trotz, oder gerade deshalb stellt sich im Aufbau einer funkti-
onierenden E-Business Landschaft und damit auch der Integration ver-
schiedenster 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 Sys-
teme, Anwendungen und Datenquellen eingesetzt werden, die alle auf
unterschiedlicher Weise miteinander kommunizieren. Durch die Vielzahl
der verschiedenen, oft schlecht dokumentierten Kommunikationsverbin-
dungen, 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 vor-
gesehen 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
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
2
Einleitung
Systemen und Plattformen zu realisieren und somit Implementierungskos-
ten 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 verschie-
denen Anwendungssystemen und auch den B2B Markt zu revolutionie-
ren. 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 Architektu-
ren aussehen können bzw. wessen Standards sie gehorchen sollten.
10
Auch sogenannte Webservices sind in aller Munde, wenn es um die un-
ternehmensübergreifende Kommunikation geht, aber auch in der unter-
nehmensinternen Integration sollen sie eine Rolle spielen. Doch die Web-
service Architektur kann diese Aufgabe in ihrer jetzigen Struktur nur be-
dingt 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 Prog-
nose entgegen zu wirken und die Lücken der Webservice Architektur zu
schließen.
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
3
Einleitung
Entscheidend für die Zukunftsperspektive wird vor allem auch die Flexibili-
tä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 unter-
schiedlichster Art dauerhaft sicherstellt , wird sie sich in der Breite durch-
setzen. Wenn die Wirtschaft, und hier im besonderen die finanziell
schlechter ausgestatteten Klein- und mittelständischen Unternehmen den
langfristigen Nutzen einer solchen Lösung erkennen, werden Investitions-
hemmnisse abgebaut, die Kostensituation wird transparenter und die Un-
ternehmenskalkulation 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, so-
wohl im unternehmensinternen Bereich, wie auch unternehmensübergrei-
fend. Ziel ist es die Integrationskosten zu reduzieren und somit vor allem
auch Klein- und Mittelständische Unternehmen mit einzubeziehen. Web-
services 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 umge-
setzt werden kann? Was bietet der aktuelle Softwaremarkt für Lösungen?
Am Anfang dieser Ausführung wird auf die Integrationsprobleme im Zu-
sammenhang 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
4
Einleitung
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 Bestandtei-
len 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 Spezifikatio-
nen vorgestellt.
In einem abschließenden Fazit werden die Zukunftsperspektiven von
ebXML beurteilt.
5
Probleme bei der Integration im klassischen EDI/EAI
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 elektroni-
schen Austausch strukturierter Geschäftsdokumente. Als Pionier gilt hier
das Laces Kommunikationssystem für Cargo Informationen am Londo-
ner Flughafen Heathrow. Auch der MAN Konzern bedient sich seit mehr
als vierzig Jahren dieser damals höchst innovativen Form der Kommunika-
tion, allerdings anfänglich nur zum unternehmensinternen Datenaus-
tausch.
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äfts-
prozesses mit einem Handelspartner betrachtet. (siehe Abbildung 1) An-
gefangen bei der direkten Kommunikation mit dem Partner ( Anfrage, An-
gebot, Bestellung, Bestätigung, Bezahlung) bis hin zur unternehmensin-
ternen 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.
13
vgl. Weitzel/Harder/Buxmann, Electronic Business und EDI mit XML (2001), dpunkt Verlag
S.6
6
Probleme bei der Integration im klassischen EDI/EAI
Erfassung der
Bestellung im ERP-
System
Bestellung
3
Buchung des
Warenausgangs
Erstellung der
Rechnung
Erstellung der
Exportpapiere/
Versendung der Ware
6
ERP-System
Erstellung der
Lieferung im ERP-
System
ERP-System
5
4
Auftragsbestä-
tigung
Speditionsauftrag
Rechnung
Lieferschein/
Kommi-Beleg
ERP-System
ERP-System
Ausfuhrbe-
scheinigung
7
Erstellung des
Angebots
2
Angebot
ERP-System
Abnahme der Ware
durch den Kunden
Anfrage durch den
Kunden
Anfrage
1
ERP-System
Bezahlung der Ware/
Buchung des
Geldeingangs
8
9
ERP-System
1.
Anfrage durch den
Kunden schriftlich,
telefonisch oder per
E-mail.
2.
Auf Grundlage der
Anfrage wird ein An-
gebot erstellt und an
den Kunden gesen-
det.
3.
Die Bestellung wird
auf Übereinstimmung
mit dem Angebot ge-
prüft und im ERP-
System erfasst. Eine
unterschriebene Auf-
tragsbestätigung wird
an den Kunden ge-
sendet.
4.
Die Lieferung wird
unter Bezugnahme
auf den Auftrag im
ERP-System erfasst.
Nach Erstellung der
Lieferung wird ein
Lieferschein bzw. ein
Kommissionierungs-
beleg erstellt.
5. Der
Warenausgang
wird gebucht.
6.
Die Rechnung wird
über das ERP-
System erstellt und
an den Kunden ge-
sendet.
7. Speditionsauftrag
und Ausfuhrbeschei-
nigung werden er-
stellt und dem beauf-
tragten Spediteur ü-
bergeben.
8.
Die Ware wird durch
den Kunden abge-
nommen.
9.
Der Kunde bezahlt
die Rechnung, der
Geldeingang wird
gebucht.
Abbildung 1:
Beispiel eines Geschäftsprozesses, eigene Darstellung
7
Probleme bei der Integration im klassischen EDI/EAI
Einsparungseffekte durch die Nutzung von EDI
·
Verringerung der Durchlaufzeiten
·
Vermeidung von Erfassungsfehlern
·
Senkung der allgemeinen Kommunikationskosten
·
Beschleunigung des Informationsflusses
Flexibilität
Wettbewerbsvorteile
·
Durch Automatisierung und Koordination von Geschäftsprozessen
wird eine Just in Time Produktion möglich:
Reduzierung der Lagerhaltungskosten
Reduzierung der Kapitalbindung
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äftsdo-
kumente 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 all-
gemein anerkannte Strukturen und Standards Rücksicht genommen wer-
den. Einerseits ist die Darstellung und Reihenfolge der Datenelemente
8
Probleme bei der Integration im klassischen EDI/EAI
(Syntax) festzulegen, also wie eine Nachricht aus Segmenten (z. B. Ad-
resse, Preis), die sich aus mehreren Datenelementen (z.B. Zahl, Zeichen-
folge) zusammensetzen, aufgebaut ist. Andererseits ist festzulegen, wel-
che Bedeutung die einzelnen Datenelemente bzw. Segmente haben (Se-
mantik).
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 der-
zeit gültigen Nachrichten (Verzeichnis) enthalten.
Bei den EDI-Standards unterscheidet man nach bilateralen, multilateralen
und Industrie-Standards, sowie nach echten Standards, die von Normen-
organisationen registriert und verwaltet werden. Industrie-Standards ha-
ben 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.
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
9
Probleme bei der Integration im klassischen EDI/EAI
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 Datenelemen-
te als die Informationsgrundsteine, die Segmente als vordefinierte Sätze
funktionell zusammenhängender Datenelemente zur Abdeckung einer ge-
schäftlichen Funktion (z. B. Adresse, Preisinformation) und die Strukturen
von Nachrichten zur Abdeckung von Geschäftsfunktionen (z. B. Bestel-
lung, Rechnung). Die Regeln und die Informationskomponenten des Stan-
dards 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 un-
ternehmensspezifisch, branchenspezifisch oder regional begrenzt sind,
kann eine schrittweise Migration an den weltweit gültigen branchenüber-
greifenden Standard UN/EDIFACT erwartet werden (siehe Abbildung 2).
17
10
Probleme bei der Integration im klassischen EDI/EAI
Tabelle 2 zeigt eine Übersicht der aktuell gängigsten EDI Standards.
Standards
UN/EDIFACT
(United Nation Electronic Data Interchange for
Administration Commerce and Transport)
Weltweit anerkannter und eingesetzter
EDI-Standard, der aus den Standards
ANSI X.12 und GTDI von der UN/ECE
(Wirtschaftskommission der Vereinten
Nationen für Europa) entwickelt wurde
und im Jahre 1987 von der ISO (Internati-
onal Organisation for Standardisation)
unter ISO 9735 anerkannt und publiziert
wurde.
ANSI X.12
(American National Standards Institute, X.12)
Datenaustausch Standard in Nordamerika
und beinhaltet Syntax, Datenelemente
und Nachrichtenstrukturen und findet in
vielen Branchen Verwendung. Der X.12
Standard war neben einem in Großbritan-
nien entwickeltem Standard GTDI (Guide-
lines for Trade Data Interchange) die Ba-
sis für UN/EDIFACT.
Unterstandards (Subsets)
ODETTE
(Organisation for Data Exchange by Tele
Transmission in Europe)
Wird in der europäischen Automobilbran-
che verwendet und baut auf der Syntax
von EDIFACT auf
SEDAS
(Standardregelung Einheitlicher Datenaus-
tauschsysteme im Handel)
wurde in den 80er Jahren in Deutschland
für die Konsumgüterindustrie entwickelt
und wird heute hauptsächlich in Deutsch-
land und Österreich eingesetzt
TRADACOMS
(Trading Data Communications Standard)
Standard, der am häufigsten in Großbri-
tannien eingesetzt ist (ca. 65%) und ba-
siert auf dem GTDI
VDA
(Verband der Automobilindustrie, Deutsch-
land)
Wird wie ODETTE auch in der
Automobilindustrie verwendet.
EANCOM
Beim Einsatz vom EANCOM-Subset
werden sowohl die Partner als auch
die Waren durch eine 13-stellige
EAN
18
-Nummer weltweit eindeutig
identifiziert.
Tabelle 2:
Übersicht gängiger EDI Standards
17
vgl. Edi Business Austria, Edi Standards, http://www.edi.at/kapitel2.htm,
18
Europäische Artikel Nummerierung
11
Probleme bei der Integration im klassischen EDI/EAI
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ön-
nen Komponenten (Segmente, Datenelemente, Schlüssel) auch optional
sein. Das führt dazu, dass für verschiedene Branchen sogenannte Sub-
sets (Untermengen von Nachrichten) definiert werden, was die branchen-
unabhängige Verwendung von EDI wiederum erschwert. (z. B. die Che-
miebranche 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 Che-
miebranche unbrauchbar sind). Solche Subsets sind für bestimmte Bran-
chen 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 Elektronik- und Computerindustrie, EDIBUILD für das Bauwesen,
EMEDI für den Gesundheitsbereich, ODETTE für die Automobilindust-
rie).
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 wer-
den 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
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 bran-
chenweit fest definierte Austauschformate, die jedoch nicht in die für EDIFACT übliche Trenn-
zeichensyntax konvertiert werden. Daher erfordert der Austausch von SEDAS- und VDA-
Nachrichten keine Konvertierung im üblichen Sinn.
12
Probleme bei der Integration im klassischen EDI/EAI
Standard für ein Unternehmen geeignet ist, hängt vor allem von der Bran-
che 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 aus-
tauschbaren Formaten wie SEDAS oder VDA allmählich zu verabschie-
den
23
Grundsätzlich lässt sich der EDI Datenaustausch als Ganzes in zwei un-
terschiedliche Prozesse unterteilen, den Konvertierungsprozess und den
Kommunikationsprozess.
2.1.2.3 Konvertierungsprozess
Um die aus einem Warenwirtschafts- oder Finanzbuchhaltungssystem in
einem Inhouse - Format zur Verfügung gestellten Daten in die EDIFACT-
Norm übersetzen zu können, bedarf es eines Konverters. Dieser Konver-
ter 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 Anwen-
dung verarbeitbares Inhouse - Format übernimmt. Die Möglichkeit der au-
tomatischen Weiterverarbeitung der aus dem EDIFACT - Format konver-
tierten Daten in ein zuvor eindeutig definiertes Flatfile
24
ermöglicht den
Datenimport in betriebswirtschaftliche Applikationen. Verschiedene Appli-
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
13
Probleme bei der Integration im klassischen EDI/EAI
kationen verfügen zumeist über Standardschnittstellen für den EDI-
Datenaustausch, die für die Konvertierung im EDI-System gemäß den An-
forderungen des einzelnen Kunden gefüllt werden können.
25
2.1.2.4 Kommunikationsprozess
Beim EDI-Kommunikationsprozess lassen sich prinzipiell zwei verschiede-
ne 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 Just- in - Time- Beliefe-
rung wird diese Art der Kommunikation praktiziert, weshalb sie in der Au-
tomobilindustrie weit verbreitet ist. Die zweite Möglichkeit der Kommunika-
tion entkoppelt Sende- und Empfangsvorgang durch die Verwendung ei-
ner 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 Telefon- oder 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 realis-
tisch anzunehmen, dass man zu hundert, zweihundert oder mehr Ge-
schäftspartnern derartige Verbindungen auf Wählverbindungsbasis wirt-
schaftlich betreiben kann.( siehe auch Kapitel 2.2.3). Abbildung 3 zeigt die
verschiedenen Kommunikationsmöglichkeiten beim elektronischen Daten-
austausch.
25
vgl.stratEDI, Edi technologie, http://www.ecin.de/edi/index.html
26
vgl.stratEDI, Edi Technologie, http://www.ecin.de/edi/index.html
14
Probleme bei der Integration im klassischen EDI/EAI
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 An-
wender 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 Servi-
ces (VANS) oder Clearing - Center.
Vorteile des UN/EDIFACT Standards
·
ISO zertifiziert
·
weltweite Gültigkeit
·
Branchenunabhängigkeit
·
einheitliche Struktur (Semantik, Syntax)
·
Reduzierung des Organisationsaufwandes
o
keine speziellen Vereinbarungen zwischen Unternehmen not-
wendig
o
Reduzierung des Transformationsaufwandes
o
Reduzierung von Schnittstellen
o
Standardschnittstellen in Applikationen
·
Veröffentlichung von Dokumentationen zur Anwendung des Stan-
dards durch die UN/ECE
27
Problem: verschiedene Subsets
27
United Nations Economic Commission for Europe
15
Ende der Leseprobe aus 114 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2003, Kostengünstige B2B-Integration auf der Basis des ebXML- Frameworks., Hamburg, Bedey Media GmbH, https://www.diplom.de/document/222250
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare