Modellierungsmethode zur Integration
zwischenbetrieblicher Informationsflüsse
Dissertation zur Erlangung des akademischen Grades
eines Doktors der Wirtschaftswissenschaften (Dr. rer. pol.)
der Universität-Gesamthochschule Paderborn
vorgelegt von
Thomas Steffen,
Minden
Paderborn, im Dezember 2001
Dekan: Prof. Dr. O. Rosenberg
Referent: Prof. Dr. J. Fischer
Korreferent: Prof. Dr. L. Nastansky
II
Inhaltsverzeichnis
Abkürzungsverzeichnis ......................................................................................................... VI
Abbildungsverzeichnis.............................................................................................................X
Tabellenverzeichnis ............................................................................................................ XIII
1 Einleitung............................................................................................................................1
1.1 Ausgangslage ................................................................................................................1
1.2 Ziel der Arbeit...............................................................................................................4
1.3 Vorgehensweise ............................................................................................................6
2 Grundlagen der Integration zwischenbetrieblicher Informationsflüsse ......................9
2.1 Fallbeispiele für eine Integration zwischenbetrieblicher Informationsflüsse ...............9
2.2 Formen der Integration zwischenbetrieblicher Informationsflüsse ............................13
2.3 Integration zwischenbetrieblicher Informationsflüsse als Zustand.............................22
2.4 Nutzeffekte einer Integration zwischenbetrieblicher Informationsflüsse ...................28
2.5 Integration zwischenbetrieblicher Informationsflüsse als Gestaltungsaufgabe ..........30
2.6 Ansätze zur Integration zwischenbetrieblicher Informationsflüsse ............................40
2.6.1 Klassisches EDI .....................................................................................................40
2.6.2 XML/EDI ...............................................................................................................49
2.6.3 Defizite vorhandener Integrationsansätze ..............................................................57
3 Anforderungen an eine Modellierungsmethode zur Integration zwischen-
betrieblicher Informationsflüsse ....................................................................................64
3.1 Grundlagen der Modellierung.....................................................................................64
3.1.1 Modelle und Modellierungsmethoden im Rahmen der Informationssystem-
gestaltung ...............................................................................................................64
3.1.2 Ontologiebasierte und referenzgestützte Modellierung .........................................72
3.2 Grundlegender Ansatz einer Modellierungsmethode zur Integration zwischen-
betrieblicher Informationsflüsse .................................................................................77
3.3 Inhaltliche Anforderungen ..........................................................................................80
3.3.1 Anforderungen zur Beschreibung von Strukturen und Abläufen zwischen-
betrieblicher Transaktionen und ihrer Informationsflüsse .....................................80
3.3.2 Anforderungen zum Ableiten und Darstellen von Nachrichtenstrukturen ............82
III
3.3.3 Anforderungen an die Unterstützung der fachlichen Aufgaben einer
Integration zwischenbetrieblicher Informationsflüsse ...........................................84
3.3.3.1 Tätigkeiten im Rahmen zwischenbetrieblicher Transaktionen.......................84
3.3.3.2 Anforderungen an die Unterstützung der syntaktischen und
semantischen Integration.................................................................................89
3.3.3.3 Anforderungen an die Unterstützung der pragmatischen Integration .............92
3.4 Formale Anforderungen..............................................................................................95
3.4.1 Übersicht der formalen Anforderungen .................................................................95
3.4.2 Allgemeine Anforderungen an die Modellierungsmethode...................................96
3.4.3 Formale Anforderungen an die Modellierungssprache..........................................98
3.4.4 Formale Anforderungen an die Vorgehensweise .................................................100
3.5 Vorhandene Modellierungsansätze zur Integration zwischenbetrieblicher
Informationsflüsse ....................................................................................................103
3.5.1 Überblick..............................................................................................................103
3.5.2 Kurze Beschreibung der Ansätze .........................................................................105
3.5.3 Zusammenfassende Bewertung............................................................................115
4 Modellierungsmethode für den verteilten Entwurf zwischenbetrieblicher
Informationsflüsse (MOVE) .........................................................................................117
4.1 MOVE im Überblick ................................................................................................117
4.1.1 MOVE als Teilergebnis des Forschungsprojektes MOVE ..................................117
4.1.2 Grundlegender Aufbau und Vorgehensweise ......................................................119
4.2 Materiellorientierter Entwurfsrahmen ......................................................................121
4.3 Referenzbibliothek....................................................................................................122
4.3.1 Anliegen und Inhalte der Referenzbibliothek ......................................................122
4.3.2 Ontologie..............................................................................................................124
4.3.3 Referenzklassen ...................................................................................................128
4.3.4 Nachrichtenbausteine ...........................................................................................130
4.4 Modellierungssprache...............................................................................................134
4.4.1 Das AllBuy-Szenario ...........................................................................................134
4.4.2 Transaktionsdiagramm.........................................................................................135
4.4.3 Interaktionsdiagramm ..........................................................................................138
4.4.4 Sequenzdiagramm................................................................................................142
4.4.5 Nachrichtendiagramm..........................................................................................145
IV
4.4.6 Regeldiagramm ....................................................................................................147
4.5 Vorgehensweise ........................................................................................................152
4.5.1 Makrovorgehen ....................................................................................................152
4.5.2 Mikrovorgehen.....................................................................................................153
4.5.3 Modellierungsschritte...........................................................................................154
5 Beispiel einer modellgestützten Integration mit MOVE ............................................162
5.1 Vorschläge zur Referenzbibliothek ..........................................................................162
5.1.1 Vorgehen und Einschränkungen ..........................................................................162
5.1.2 Vorschlag einer Ontologie ...................................................................................163
5.1.2.1 Entwurfselemente .........................................................................................163
5.1.2.2 Beschreibende Elemente ...............................................................................170
5.1.2.3 Semantische Regeln ......................................................................................176
5.1.3 Vorschläge für Referenzklassen...........................................................................178
5.1.4 Beispiele für Nachrichtenbausteine......................................................................180
5.2 Anwendung von MOVE ...........................................................................................180
5.2.1 Das AllBuy-Szenario ...........................................................................................181
5.2.2 Transaktionsdiagramme.......................................................................................182
5.2.3 Interaktionsdiagramme.........................................................................................187
5.2.4 Sequenzdiagramme ..............................................................................................190
5.2.5 Nachrichtendiagramme ........................................................................................192
5.2.6 Regeldiagramme ..................................................................................................198
5.3 Implementierung.......................................................................................................201
6 Bewertung und Ausblick...............................................................................................203
6.1 Bewertung der Modellierungsmethode zur Integration zwischenbetrieblicher
Informationsflüsse ....................................................................................................203
6.1.1 Bewertung zur Erfüllung der inhaltlichen Anforderungen ..................................203
6.1.2 Bewertung zur Erfüllung der formalen Anforderungen.......................................206
6.2 Ausblick....................................................................................................................207
Literaturverzeichnis .............................................................................................................210
V
A Anhang............................................................................................................................227
A.1 Zur Darstellung der Metamodelle in Kapitel 4 .........................................................227
A.2 Detaillierte Bewertung vorhandener Modellierungsansätze.....................................230
A.2.1 Inhaltliche Anforderungen ...................................................................................230
A.2.2 Formale Anforderungen .......................................................................................232
A.3 Berücksichtigte EANCOM-Nachrichtentypen .........................................................233
A.4 Attributtypen und Datenfelder ..................................................................................234
VI
Abkürzungsverzeichnis
agg. Aggregationsbeziehung
ARIS Architektur integrierter Informationssysteme
Art.-Nr. Artikelnummer
ASCII American Standard Code of Information Interchange
AT Aufgabenträger
ATM Asynchronous Transfer Mode
B2B business to business
bbn bundeseinheitliche Betriebsnummer
BMBF Bundesministerium für Bildung und Forschung
BOD Business Object Document
BSR Basic Semantic Register
BSU Basic Semantic Unit
CCG Centrale für Coorganisation
CEN/ISSS European Committee for Standardization/ Information Society Stan-dardization System
CIM Computer Integrated Manufacturing
cXML commerce XML
DEDIG Deutsche EDI Gesellschaft
DIN Deutsches Institut für Normung
DISA Data Interchange Standards Association
DSL Digital Subscriber Line
DTD Document Type Definition
DUNS Data Universal Numbering System
DV Datenverarbeitung
EAN Europäische Artikelnummer
EBCDIC Extended Binary-Coded Decimal Interchange Code
ebXML electronic business XML
ECR Efficient Consumer Response
EDI Electronic Data Interchange
EDIFACT Electronic Data Interchange for Administration, Commerce and Trans-port
EDV Elektronische Datenverarbeitung
EEMA European Electronic Messaging Association
VII
EHI Europäisches Handelsinstitut
EPK ereignisgesteuerte Prozesskette
ERM Entity-Relationship-Modell
ERP Enterprise Resource Planing
FTAM File Transfer, Access and Management
FTP File Transfer Protocol
GmbH Gesellschaft mit beschränkter Haftung
GoM Grundsätze ordnungsmäßiger Modellierung
GPS Global Positioning System
GSM Global System for Mobile Computing
GTIN Global Trade Item Number
HTML Hypertext Markup Language
HTTP Hypertext Transport Protocol
HTTPS Hypertext Transport Protocol Secure
ICE Information and Content Exchange
IEC International Electrotechnical Commission
ILN Internationale Lokationsnummer
inner. innerbetrieblich
IO Informationsobjekt
IOS Interorganisationssystem
IP Internet Protocol
ISDN Integrated Services Digital Network
ISO International Organization for Standardization
IT Informationstechnologie
kBit/s Kilobit pro Sekunde
KI Künstliche Intelligenz
Mbit/s Megabit pro Sekunde
MDE mobile Datenerfassung
MIG Message Implementation Guide
MOVE 1. Modellierung einer verteilten Architektur für die Entwicklung unternehmensübergreifender Informationssysteme und ihre Validierung im Handelsbereich
2. Modellierungsmethode für den verteilten Entwurf zwischenbetrieblicher Informationsflüsse
MWD Mehrwertdienst
VIII
NBü Normenausschuss Bürowesen
NVE Nummer der Versandeinheit
OAG Open Applications Group
OAGIS Open Applications Group Integration Specifications
OASIS Organization for the Advancement of Structured Information Standards
OFX Open Financial Exchange
OO-EDI Object-oriented EDI
OOT Object-oriented technology
oper. operativ
opt. optional
OSI Open Systems Interconnection
PIP Partner Interface Process
PLZ Postleitzahl
RMI Remote Method Invocation
RUP Rational Unified Process
SB Selbstbedienung
SCM Supply Chain Management
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
SOM Semantisches Objektmodell
strat. strategisch
TCP Transmission Control Protocol
TMWG Techniques and Methodologies Working Group
UML Unified Modeling Language
UMM UN/CEFACT Modelling Methodology
UMTS Universal Mobile Telecommunications System
UN/ CEFACT United Nations Centers for the Facilitation of Procedures and Practices for Administration, Commerce and Transport
UPC Universal Product Code
VAN Value Added Network
VPN Virtual Private Network
WAN Wide Area Network
WWW World Wide Web
xCBL XML-based Common Business Library
XML Extensible Markup Language
IX
zb. zwischenbetrieblich
ZBI zwischenbetriebliche Integration von Informationssystemen
X
Abbildungsverzeichnis
Abb. 1.1 Aufbau der Arbeit ........................................................................................................7
Abb. 2.1 Zwischenbetriebliches Basis- und Informationssystem .............................................16
Abb. 2.2 Arten von Informationsflussbeziehungen ..................................................................20
Abb. 2.3 Formen einer Integration zwischenbetrieblicher Informationsflüsse.........................21
Abb. 2.4 Semiotische Ebenen der Information .........................................................................24
Abb. 2.5 Inkompatibilitäten bei zwischenbetrieblichen Informationsflüssen...........................30
Abb. 2.6 Aufbau einer klassischen EDI-Lösung.......................................................................41
Abb. 3.1 Abbildungsorientierter Modellbegriff der Wirtschaftsinformatik .............................65
Abb. 3.2 Phasen der Modellkonstruktion .................................................................................67
Abb. 3.3 Semantisches Dreieck ................................................................................................74
Abb. 3.4 Grundlegender Ansatz der zu entwickelnden Modellierungsmethode ......................78
Abb. 3.5 Modellierungsbeispiel eines Open-EDI-Szenarios mit Petri-Netzen.......................106
Abb. 3.6 Beispiel eines Sequenzdiagramms im Rahmen von UMM .....................................107
Abb. 3.7 Beispiel eines Business Process Flow Diagram zu einem RosettaNet PIP..............109
Abb. 3.8 Beispiel einer betriebsübergreifenden Prozesskette mit FUNSOFT-Netzen ...........110
Abb. 3.9 Beispiel eines Prozessmodells nach dem Ansatz von HENKEL................................112
Abb. 3.10 Beispiel einer betriebsübergreifenden Prozesskette mit EPKs ..............................114
Abb. 4.1 Komponenten der MOVE-Modellierungssprache im Überblick .............................120
Abb. 4.2 Entwurfselemente von MOVE.................................................................................121
Abb. 4.3 Unterstützung des Modellierungsprozesses bei MOVE ..........................................123
Abb. 4.4 Metamodell zur Kontrolle der Terminologie ...........................................................125
Abb. 4.5 MOVE-Meta-Ontologie ...........................................................................................126
Abb. 4.6 Metamodell zu semantischen Regeln.......................................................................127
Abb. 4.7 Metamodell der Referenzklassen .............................................................................130
Abb. 4.8 Ableiten von Nachrichtenbausteinen aus Referenzklassendiagrammen..................132
Abb. 4.9 Metamodell zu Nachrichtenbausteinen....................................................................134
Abb. 4.10 Metamodell des Transaktionsdiagramms...............................................................136
Abb. 4.11 Beispiel eines Transaktionsdiagramms..................................................................138
Abb. 4.12 Metamodell des Interaktionsdiagramms ................................................................140
Abb. 4.13 Beispiel eines Interaktionsdiagramm .....................................................................142
Abb. 4.14 Metamodell der Sequenzdiagramme......................................................................143
XI
Abb. 4.15 Beispiel eines Sequenzdiagramms .........................................................................145
Abb. 4.16 Metamodell des Nachrichtendiagramms................................................................146
Abb. 4.17 Beispiel eines Nachrichtendiagramms ...................................................................147
Abb. 4.18 Metamodell zum Regeldiagramm..........................................................................150
Abb. 4.19 Beispiel eines Regeldiagramms .............................................................................151
Abb. 4.20 Makrovorgehen der Modellierungsmethode ..........................................................153
Abb. 4.21 Mikrovorgehen der Modellierungsmethode...........................................................153
Abb. 4.22 Mikrovorgehen am Beispiel des AllBuy-Transaktionsdiagramms ........................154
Abb. 4.23 Ableiten von Nachrichtenelementen ......................................................................159
Abb. 5.1 Vorschlag einer Klientenontologie ..........................................................................164
Abb. 5.2 Vorschlag einer Interaktionsontologie .....................................................................165
Abb. 5.3 Vorschlag einer Ontologie für Informationsobjekte ................................................167
Abb. 5.4 Vorschlag einer Ontologie für Leistungsobjekte .....................................................168
Abb. 5.5 Vorschlag einer Ontologie für Zahlungsobjekte ......................................................169
Abb. 5.6 Vorschlag einer Ontologie für Kanäle .....................................................................170
Abb. 5.7 Vorschlag einer Ontologie für Klientenrollen..........................................................172
Abb. 5.8 Vorschlag einer Ontologie für Objektrollen ............................................................173
Abb. 5.9 Vorschlag einer Attributontologie (Ausschnitt).......................................................176
Abb. 5.10 Referenzklassendiagramm für Klienten (Ausschnitt) ............................................179
Abb. 5.11 Referenzklassendiagramm für Objekte (Ausschnitt) .............................................179
Abb. 5.12 Aus dem Referenzklassendiagramm für Klienten abgeleitete semantische
Label ...............................................................................................................................180
Abb. 5.13 Transaktionsdiagramm zu Lagergeschäften im AllBuy-Szenario..........................184
Abb. 5.14 Transaktionsdiagramm zu Zentralstreckengeschäften im AllBuy-Szenario ..........186
Abb. 5.15 Transaktionsdiagramm zu Filialstreckengeschäften im AllBuy-Szenario .............186
Abb. 5.16 Interaktionsdiagramm Auftrag senden ...................................................................188
Abb. 5.17 Interaktionsdiagramm Waren abrufen ...................................................................188
Abb. 5.18 Interaktionsdiagramm Lieferung mitteilen .............................................................189
Abb. 5.19 Interaktionsdiagramm Wareneingang melden .......................................................189
Abb. 5.20 Interaktionsdiagramm Rechnung senden ...............................................................190
Abb. 5.21 Sequenzdiagramme zu den Sequenzen mit Rahmenauftrag ..................................192
Abb. 5.22 Sequenzdiagramm zur Sequenz mit Lieferplan .....................................................192
Abb. 5.23 Papierbasierter Lieferabruf aus dem AllBuy-Szenario ..........................................193
XII
Abb. 5.24 Nachrichtendiagramm zum Informationsobjekt Lieferabruf .................................195
Abb. 5.25 Nachrichtendiagramme zu den Informationsobjekten Rahmenauftrag und
Lieferplan........................................................................................................................195
Abb. 5.26 Nachrichtendiagramme zu den Informationsobjekten Einzel- und
Sammelrechnung.............................................................................................................195
Abb. 5.27 Nachrichtendefinition bei MOVE und EDIFACT .................................................198
Abb. 5.28 Regeldiagramm zum Beispiel auf Elementebene ..................................................200
Abb. 5.29 Regeldiagramme zu den Beispielen auf Nachrichten-, Transaktions- und
Geschäftsbeziehungsebene .............................................................................................201
Abb. 5.30 EDI-Implementierung mit Java (vereinfacht) ........................................................202
Abb. A.1 Verwendete Notation in den ERM der Metamodelle..............................................229
XIII
Tabellenverzeichnis
Tab. 2-1 Abgrenzung betrieblicher Informationssysteme.........................................................15
Tab. 2-2 Phasen zwischenbetrieblicher Transaktionen.............................................................19
Tab. 2-3 Zeitliche Ordnung zwischenbetrieblicher Informationsflüsse....................................19
Tab. 2-4 Informationsbegriff dieser Arbeit ...............................................................................25
Tab. 2-5 Integrationsebenen zwischenbetrieblicher Informationsflüsse...................................27
Tab. 2-6 Nutzeffekte einer Integration zwischenbetrieblicher Informationsflüsse...................29
Tab. 2-7 Netze für den zwischenbetrieblichen Informationsaustausch ....................................32
Tab. 2-8 Syntaktische Merkmale von Datenelementen ............................................................34
Tab. 2-9 Beispiele für Markt-, Geschäftsverkehrs- und Technikinformationen.......................34
Tab. 2-10 Unterschiedliche Datendefinitionen am Beispiel ‚Wechselkurs‘.............................36
Tab. 2-11 Zweck zwischenbetrieblicher Informationsflüsse aus Sendersicht ..........................37
Tab. 2-12 Zweck zwischenbetrieblicher Informationsflüsse aus Empfängersicht....................39
Tab. 2-13 Mehrwertdienste.......................................................................................................42
Tab. 2-14 EDI-Nachrichtenstandards........................................................................................44
Tab. 2-15 Beispiele für EDIFACT-Subsets ..............................................................................44
Tab. 2-16 Standardisierte Identifikationsnummern ..................................................................47
Tab. 2-17 Integrationsansatz des klassischen EDIs ..................................................................49
Tab. 2-18 Initiativen zur Standardisierung XML-basierter Nachrichten ..................................52
Tab. 2-19 Standardisierte Identifikationsnummern der RosettaNet-Initiative..........................54
Tab. 2-20 Pragmatische Integrationsansätze.............................................................................55
Tab. 2-21 Integrationsansatz des XML/EDIs............................................................................57
Tab. 2-22 Defizite vorhandener Integrationsansätze ................................................................62
Tab. 3-1 Verwendung des Modellbegriffs ................................................................................71
Tab. 3-2 Ansätze einer referenzgestützten Modellierung .........................................................76
Tab. 3-3 Anforderungen zur Beschreibung von Strukturen und Abläufen
zwischenbetrieblicher Transaktionen und ihrer Informationsflüsse .................................82
Tab. 3-4 Anforderungen zum Ableiten und Darstellen der Nachrichtenstrukturen..................83
Tab. 3-5 Nachrichtenfolge im AllBuy-Szenario .......................................................................84
Tab. 3-6 Tätigkeiten im AllBuy-Szenario.................................................................................87
Tab. 3-7 Aufgaben einer Integration zwischenbetrieblicher Informationsflüsse ......................88
Tab. 3-8 Beispiele für syntaktische Konvertierungen...............................................................90
XIV
Tab. 3-9 Beispiele für semantische Prüfungen .........................................................................90
Tab. 3-10 Merkmale semantischer Prüfregeln..........................................................................91
Tab. 3-11 Anforderungen zur syntaktischen und semantischen Integration .............................92
Tab. 3-12 Primärer und sekundärer Nachrichtentyp .................................................................93
Tab. 3-13 Dokumentierende bzw. kontrollierende Nachrichten...............................................93
Tab. 3-14 Automatisierbare Nachrichten..................................................................................94
Tab. 3-15 Anforderungen zur pragmatischen Integration.........................................................95
Tab. 3-16 Übersicht der formalen Anforderungen....................................................................96
Tab. 3-17 Allgemeine Anforderungen an die Modellierungsmethode .....................................98
Tab. 3-18 Formale Anforderungen an die Modellierungssprache ..........................................100
Tab. 3-19 Formale Anforderungen an die Vorgehensweise ...................................................103
Tab. 3-20 Übersicht vorhandener Modellierungsansätze .......................................................104
Tab. 3-21 Kurzbeschreibung vorhandener Modellierungsansätze..........................................105
Tab. 3-22 Umfang vorhandener Modellierungsansätze ..........................................................115
Tab. 3-23 Zusammenfassende Bewertung vorhandener Modellierungsansätze .....................116
Tab. 4-1 Materiellorientierter Entwurfsrahmen ......................................................................122
Tab. 4-2 Attributtypen und Datenfelder von Nachrichtenbausteinen .....................................133
Tab. 4-3 Notation des Transaktionsdiagramms ......................................................................137
Tab. 4-4 Notation des Interaktionsdiagramms........................................................................141
Tab. 4-5 Notation des Sequenzdiagramms .............................................................................144
Tab. 4-6 Notation des Nachrichtendiagramms .......................................................................146
Tab. 4-7 Aktionstypen.............................................................................................................148
Tab. 4-8 Notation des Regeldiagramms..................................................................................151
Tab. 4-9 Vorgehen zum Transaktionsdiagramm.....................................................................156
Tab. 4-10 Vorgehen zum Interaktionsdiagramm ....................................................................157
Tab. 4-11 Konfigurationstabelle zum AllBuy-Beispiel ..........................................................157
Tab. 4-12 Vorgehen zum Sequenzdiagramm..........................................................................158
Tab. 4-13 Vorgehen zum Nachrichtendiagramm....................................................................160
Tab. 4-14 Vorgehen zum Regeldiagramm..............................................................................161
Tab. 5-1 Ableitung der Informationsobjekt- und Interaktionstypen aus den EANCOM-
Nachrichtentypen ............................................................................................................166
Tab. 5-2 Ableitung der Rollen aus EANCOM........................................................................171
Tab. 5-3 Käufer- und Verkäuferrollen ....................................................................................171
XV
Tab. 5-4 Ableitung von Attributen aus EANCOM-Datenelementen (Beispiele) ...................175
Tab. 5-5 Beziehung zwischen Klientenrollen und Interaktionen............................................177
Tab. 5-6 Beziehung zwischen Interaktionen und Objektrollen...............................................177
Tab. 5-7 Beziehung zwischen Objekttypen und Objektrollen ................................................178
Tab. 5-8 Transaktionsmuster im AllBuy-Szenario .................................................................183
Tab. 5-9 Informationsinteraktionen bei Lagergeschäften im AllBuy-Szenario ......................184
Tab. 5-10 Ausführungen der Informationsinteraktionen bei Zentralstreckengeschäften
im AllBuy-Szenario ........................................................................................................187
Tab. 5-11 Konfigurationstabelle zu Zentralstreckengeschäften im AllBuy-Szenario ............191
Tab. 5-12 Zeitliche Ordnung der Interaktionen im AllBuy-Szenario .....................................191
Tab. 5-13 Nachrichtenelemente mit Bezug auf den gesamten Lieferabruf.............................194
Tab. 5-14 Nachrichtenelemente mit Bezug auf die einzelnen Lieferabrufpositionen.............194
Tab. 5-15 MOVE-Nachrichtenbausteine versus EDIFACT-Datenelemente ..........................197
Tab. 5-16 Beispiele für Integritätsregeln auf den verschiedenen Ebenen...............................199
Tab. 6-1 Diagrammkürzel und Verweis auf Metamodell .......................................................203
Tab. 6-2 Bewertung zu den Anforderungen zur Beschreibung von Strukturen und
Abläufen..........................................................................................................................204
Tab. 6-3 Bewertung zu den Anforderungen zum Ableiten und Festlegen von
Nachrichtenstrukturen.....................................................................................................205
Tab. 6-4 Bewertung zu den Anforderungen an die Unterstützung der fachlichen
Aufgaben.........................................................................................................................205
Tab. A-1 Notation der Komplexität ........................................................................................227
Tab. A-2 Legende zur Bewertung der vorhandenen Modellierungsansätze ...........................230
Tab. A-3 Bewertung der inhaltlichen Anforderungen (Teil I) ................................................230
Tab. A-4 Bewertung der inhaltlichen Anforderungen (Teil II)...............................................231
Tab. A-5 Bewertung der formalen Anforderungen.................................................................232
Tab. A-6 Berücksichtigte EANCOM-Nachrichtentypen ........................................................233
Tab. A-7 Attributtypen und Datenfelder.................................................................................234
1
1 Einleitung
1.1 Ausgangslage
Ausgelöst durch die Arbeiten von DAVENPORT, HAMMER u. a.1 stand seit Anfang der 90er
Jahre die Verbesserung und Reorganisation betriebsinterner Prozesse im zentralen Blickpunkt
von Betrieben. Unter dem Stichwort „Business Process Reengineering“ wurden die
innerbetrieblichen Prozesse in erheblichem Maße produktiver gestaltet.
Voraussetzung dafür war die Umgestaltung und Verbesserung der unterstützenden Informa-
tionssysteme.2 Während diese bislang aus vielen Teil- und Insellösungen bestanden,3 war man
nun bestrebt, integrierte Informationssysteme zu schaffen. Zum einen sollten durch ein solch
integriertes Informationssystem sämtliche Abläufe im Unternehmen von der Beschaffung über
die Produktion bis hin zum Vertrieb durchgängig, ganzheitlich und inhaltlich konsistent
unterstützt werden (horizontale Integration).4 Zum anderen sollte die Datenversorgung der
Planungs- und Kontrollsysteme aus den Administrations- und Dispositionssystemen heraus
erfolgen (vertikale Integration).5 In der Folge begann der Erfolg integrierter Standardsoftware,
wie beispielsweise der Enterprise Resource Planing Systeme (ERP-Systeme) SAP R/2 und
R/3, BaaN oder J.D.Edwards. In die gleiche Zeit fällt die Entstehung des CIM-Begriffs
(Computer Integrated Manufacturing) und die Verbreitung entsprechender Konzepte. Unter
CIM wird die organisatorische und dv-technische Verbindung aller Aufgaben der Pro-
duktionsplanung und -steuerung, der Konstruktion und Entwicklung, Arbeitsplanung, der
Fertigung, Qualitätssicherung und Instandhaltung verstanden.6
Die Bestrebungen nach integrierten Systemen stellte neue Anforderungen an die Gestaltung,
Entwicklung und Pflege von Informationssystemen. Unter anderem sind „einmal erfasste
Daten allen nachfolgenden Systemen ohne redundante Eingabe zur Verfügung zu stellen.
1 Vgl. Davenport, Short (Engineering 1990); Hammer (Work 1990); Davenport (Process 1993); Hammer, Champy (Re-engineering 1993) 2 Vgl. Davenport (Process 1993), S. 16ff. 3 Vgl. Becker (CIM 1991), S. 1; Scheer (Wirtschaftsinformatik 1994), S. 7; Ferstl, Sinz (Grundlagen 1998), S. 212 4 Vgl. Mertens u. a. (Grundzüge 1998), S. 47; Fischer (Informationswirtschaft 1999), S. 88 5 Vgl. Mertens u. a. (Grundzüge 1998), S. 47; Fischer (Informationswirtschaft 1999), S. 88 6 Vgl. Becker (CIM 1991), S. 1
2
Getrennte EDV-Systeme müssen zusammengeführt werden, für gleiche Aufgaben sollten
gleiche Unterstützungssysteme genutzt werden.“7
Als wichtiges Hilfsmittel und Werkzeug zur effektiven und effizienten Gestaltung von
betrieblichen Informationssystemen hat sich in dieser Zeit die Modellierung herausgebildet. In
Wissenschaft und Praxis entstanden zahlreiche umfassende Ansätze zur Modellierung
betrieblicher Informationssysteme. Insbesondere wurden Architekturen für den Entwurf
integrierter Informationssysteme entwickelt. Unter einer Architektur wird in diesem
Zusammenhang die Spezifikation und Dokumentation der Konstruktionsregeln und Elemente
sowie deren Beziehungen eines betrieblichen Informationssystems aus wirtschaftlichen,
organisatorischen, fachlichen und technischen Blickwinkeln verstanden, um die
ingenieurmäßige Realisierung durch Vorgabe von Methoden und Werkzeugen zu
unterstützen.8 Ziel einer solchen Architektur ist die methodisch gestützte Entwicklung von
Informationssystemen, bei der viele Personen in oft mehrjährigen Prozessen arbeitsteilig in
einer dynamischen Umwelt (Technologie, Anwendungsanforderungen) zusammenwirken.
Modelle und Modellierungsmethoden stellen dabei zentrale Elemente einer Architektur dar.9
Bei allen bisher genannten Ansätzen (Business Process Reengineering, CIM, Architekturen
integrierter Informationssysteme) endete die Betrachtung der Prozesse in der Regel an den
Grenzen der Betriebe. Dabei weisen gerade zwischenbetriebliche Leistungs-, Zahlungs- und
Informationsflüsse viele Schnittstellen und daher große Rationalisierungspotentiale auf.10 In
der Folge liegt in jüngster Zeit das Augenmerk auf der Gestaltung betriebsübergreifender
Geschäftsprozesse. Deren Verbesserung, wie sie beispielsweise mit Konzepten des Efficient
Consumer Response (ECR) oder des Supply Chain Managements (SCM) angestrebt werden,
erfordert eine erhöhte zwischenbetriebliche Kommunikation. Es müssen vermehrt
koordinierende und kontrollierende Informationen ausgetauscht werden. Präzise
Informationen sind die Voraussetzung für bedarfsgerechte Leistungs- und Zahlungsflüsse
zwischen Betrieben.11
7 Becker (CIM 1991), S. 2 8 Vgl. Krcmar (Bedeutung 1990), S. 395ff.; Sinz (Architektur 1997), S. 875; Fischer (Informationswirtschaft 1999), S. 53ff. 9 Vgl. Sinz (Architektur 1997), S. 875f. 10 Vgl. Fischer (MOVE 1999), S. 6 11 Vgl. Fischer (Informationskooperationen 1997), S. 7f.
3
Daher sind im Zuge der Verbesserung von betriebsübergreifenden Prozessen die
zwischenbetrieblichen Informationsflüsse effektiver und effizienter zu gestalten. Anzustreben
ist eine Integration zwischenbetrieblicher Informationsflüsse, d. h. ein elektronischer
Austausch sowie eine automatisierte Weiterverarbeitung von Informationen zwischen
Anwendungssystemen verschiedener Betriebe.
Das Nutzenpotenzial einer zwischenbetrieblichen Integration wurde in einer Reihe von
Untersuchungen nachgewiesen (vgl. Abschnitt 2.4). Doch haben sich Integrationsansätze in
der heutigen Form, wie der elektronische Austausch von Daten bzw. Electronic Data
Interchange (EDI), nicht in der Breite durchsetzen können, wie noch vor einigen Jahren
prophezeit wurde.12 Derzeitige EDI-Lösungen sind gekennzeichnet durch hohe Kosten und
lange Implementierungszeiten, die von vielen potenziellen Anwendern gescheut werden.
Neue Impulse für eine Integration zwischenbetrieblicher Informationsflüsse werden von der
Nutzung des Internets und insbesondere vom Einsatz der Extensible Markup Language
(XML) erwartet. Man geht beispielsweise bei einer XML/EDI-Lösung von einer einfachen
und kostengünstigen EDI-Implementierung aus, da sie auf offenen Standards und einer
verfügbaren Internettechnologie basiert. EDI soll somit auch für kleine und mittlere Betriebe
erschwinglich werden.13 Jedoch ist XML/EDI weit davon entfernt, eine etablierte Technologie
zu sein. Zur Zeit werden viele Konzepte und zum Teil widersprüchliche Ansätze entwickelt
und diskutiert.
Für eine effektive und effiziente zwischenbetriebliche Kommunikation auf elektronischem
Wege sind die Geschäftsprozesse und deren Informationsflüsse betriebsübergreifend zu ge-
stalten und aufeinander abzustimmen. Es muss festgelegt werden, wer mit wem wann und zu
welchem Zweck auf welche Weise miteinander kommuniziert. Bislang fehlen
Modellierungstechniken und -werkzeuge zur Komplexitätsbewältigung einer solchen
Gestaltungsaufgabe.14 Während für die Gestaltung innerbetrieblicher Informationssysteme der
Einsatz von Modellen mittlerweile selbstverständlich ist, ist eine modellgestützte Integration
zwischenbetrieblicher Informationsflüsse noch weitgehend unbekannt.
12 Vgl. Lamprecht (Datenaustausch 1998), S. 2ff.; Westarp u. a. (Status 1999), S. 1ff. 13 Vgl. Bryan (XML/EDI 1998), S. 2ff.; SIMAC (XML-Problem 1999), S. 2f. 14 Vgl. Hirschmann, Scheer (Konzeption 1994), S. 11; Müller-Zantop (Perspektiven 1998), S. 11; Schüppler (Informationsmodelle 1998), S. 3
4
1.2 Ziel der Arbeit
Das Ziel der vorliegenden Arbeit kann allgemein aus einer inhaltlichen und einer formalen
Perspektive sowie speziell aus Sicht des Forschungsprojektes MOVE beschrieben werden.
Inhaltlich geht es um die im vorhergehenden Abschnitt angedeuteten Probleme bei der
Etablierung von betriebsübergreifenden Integrationslösungen. Als eine wesentliche Ursache
wird dafür die fehlende fachkonzeptuelle Modellierung zwischenbetrieblicher
Informationsflüsse gesehen. Alternative Ansätze zu bisherigen EDI-Lösungen unterstützen
daher die
Gestaltung des zwischenbetrieblichen Datenaustausches eben durch eine solche Modellierung
(vgl. Abschnitt 3.5).
Darin übereinstimmend ist die vorliegende Arbeit unter der Prämisse entstanden, dass eine
fachkonzeptuelle Modellierung den Gestaltungsprozess zwischenbetrieblicher
Informationsflüsse entscheidend unterstützen und vereinfachen kann. Ziel der Arbeit ist daher,
eine Modellierungsmethode zur Integration zwischenbetrieblicher Informationsflüsse zu
erarbeiten und vorzustellen. Die Modellierungsmethode soll eine einfache, schnelle und
kostengünstige
Realisierung und Wartung von zwischenbetrieblichen Integrationslösungen ermöglichen. Im
Fokus der Betrachtung sollen hierbei nicht - wie bei vielen bisherigen Ansätzen - isoliert die
Datenformate einzelner Nachrichten stehen, sondern ganzheitlich die zwischenbetrieblichen
Transaktionen mit den beteiligten Akteuren und ihren Rollen, den Aktivitäten sowie die
auszutauschenden Leistungs-, Zahlungs- und Informationsobjekte.
Um das gesteckte Hauptziel der Arbeit erreichen zu können, sind einige Nebenziele zu
erfüllen. Dazu gehört es, die Probleme und Aufgaben, die im Rahmen einer Integration
zwischenbetrieblicher Informationsflüsse auftreten, zu benennen und in systematischer Weise
zu beschreiben. Ein weiteres Ziel besteht darin, die Anforderungen an die zu entwickelnde
Modellierungsmethode zu formulieren. Die genannten Nebenziele sind die
Grundvoraussetzungen dafür, das Ziel einer Modellierungsmethode zur Integration
zwischenbetrieblicher Informationsflüsse erreichen zu können.
Aus formaler Sicht berührt die vorliegende Arbeit den Umstand, dass die Modellierung
zwischenbetrieblicher Informationsflüsse und insbesondere deren modellbasierte Integration
bisher weitgehend unbehandelte Gebiete der Wirtschaftsinformatik darstellen. Vorhandene
5
Modellierungsmethoden sind in der Regel auf die Gestaltung innerbetrieblicher
Informationssysteme ausgerichtet. Bislang gibt es nur einige wenige Methoden, die speziell
für die Modellierung zwischenbetrieblicher Aspekte entwickelt worden sind (vgl. Abschnitt
3.5). Wie in der vorliegenden Arbeit noch gezeigt wird, können diese aber nicht alle
Anforderungen an eine Modellierungsmethode zur Integration zwischenbetrieblicher
Informationsflüsse erfüllen. Ziel der vorliegenden Arbeit ist es also, einen Beitrag dazu zu
leisten, die konstatierte Forschungslücke auf dem Gebiet der Modellierung
zwischenbetrieblicher Informationsflüsse zu schließen.
Die Aufgabenstellung der Arbeit hat sich aus dem vom BMBF geförderten Forschungsprojekt
„MOVE“ ergeben, an dem der Autor mitgewirkt hat. MOVE steht für „Modellierung einer
verteilten Architektur für die Entwicklung unternehmensübergreifender Informationssysteme
und ihre Validierung im Handelsbereich“. Bei MOVE handelt es sich um ein Verbundprojekt,
welches unter der wissenschaftlichen Federführung des Schwerpunktes Wirtschaftsinformatik
1 der Universität Paderborn (Prof. Dr. J. Fischer) gemeinsam von der BFK Gesellschaft für
angewandte Wirtschaftsinformatik mbH, Paderborn,15 der ICL Retail Systems GmbH,
Düsseldorf und dem Europäischen Handelsinstituts (EHI), Köln in den Jahren 1996 bis 1999
durchgeführt worden ist.
Ziel des Vorhabens ist es gewesen, eine spezifische Architektur für die zwischenbetriebliche
Integration von Informationssystemen (ZBI) der Industrie und des Handels zu entwickeln und
zu erproben. Diese Entwicklungsarchitektur sollte es ermöglichen, „die Geschäftsprozesse
zwischen Unternehmen der Industrie und des Groß- und Einzelhandels bis hin zum
Endverbraucher in verschiedenen Branchen zu analysieren, um die daraus resultierenden
Informationsprozesse und deren Systeme effektiv (hinsichtlich der Inhalte und Adressen) und
effizient (hinsichtlich der Zeit und Kosten) zu gestalten.“16
Um eine ganzheitliche Sicht auf eine zwischenbetriebliche Integration zu gewährleisten,
sollten in der MOVE-Architektur drei Schichten vorgesehen werden: die
betriebswirtschaftlich orientierte Branchenschicht, die auf den fachlichen Entwurf zielende
Systemschicht und die technisch ausgerichtete DV-Schicht. Für die Branchenschicht sollten
Werkzeuge wie ein Simulationsmodell oder ein Nutzwertmodell entwickelt werden, um die
strategische Analyse und Gestaltung bestimmter Konfigurationen eines zwischenbetrieblichen
15 mittlerweile Intermoves AG, Paderborn
6
Wertschöpfungsflusses zu unterstützen. Zur taktischen Gestaltung der erforderlichen
Informationsflüsse aus geschäftlicher, organisatorischer und technischer Sicht sollte eine
entsprechende Modellierungsmethode für die Systemschicht erarbeitet werden. Zielsetzung
der DV-Schicht war die Bereitstellung von Softwarekomponenten für eine rasche Generierung
und den Betrieb eines zwischenbetrieblichen Informationssystems.
Ziel der vorliegenden Arbeit ist aus Sicht des MOVE-Projektes, eine Modellierungsmethode
für die Systemschicht bereitzustellen. Aufgabe dieser Modellierungsmethode ist,
betriebswirtschaftlich sinnvolle und technisch mögliche zwischenbetriebliche
Informationssysteme in einem strukturierten Dialog zwischen Managern, Fach- und DV-
Personal durch eine adressatengerechte Terminologie definieren zu können.17
1.3 Vorgehensweise
In der Arbeit wird im wesentlichen eine deduktive Vorgehensweise gewählt. Nach einer
intensiven Analyse des Problembereichs der Integration zwischenbetrieblicher
Informationsflüsse werden die Ziele und Aufgaben der zu entwickelnden
Modellierungsmethode festgelegt. Ausgehend von diesen Zielen und Aufgaben lassen sich die
Anforderungen an die Modellierungsmethode ableiten. Diese ist derart zu gestalten, dass sie
die an sie gestellten Anforderungen möglichst vollständig erfüllt. Durch die praktische
Anwendung anhand eines Fallbeispiels soll dies überprüft werden.
In der Einleitung in Kapitel 1 werden zunächst Ausgangslage, Ziel und Vorgehen der Arbeit
in knapper Form dargestellt.
In Kapitel 2 wird der zentrale Gegenstand der Arbeit und auch der zu entwickelnden
Modellierungsmethode, die Integration zwischenbetrieblicher Informationsflüsse,
beschrieben. Ausgehend von einigen Fallbeispielen aus der praktischen Tätigkeit des Autors,
werden mögliche Formen und Ausprägungen einer Integration zwischenbetrieblicher
Informationsflüsse identifiziert. Anschließend wird die Integration zunächst als Zustand
betrachtet und erklärt. Dazu wird eine Abgrenzung der Begriffe Information,
Informationsfluss und Integration vorgenommen. Als Analyseinstrument dient in diesem
Grundlagenkapitel das semiotische Ebenenmodell. Danach werden kommunikative und
sprachliche Vorgänge auf den Ebenen Syntaktik, Semantik und Pragmatik betrachtet. Im
16 BFK u. a. (Modellierung 1995), S. 1
7
weiteren werden die mit einer Integration zwischenbetrieblicher Informationsflüsse
verbundenen Aufgaben und Probleme skizziert. Eine Integrationsansätze führt zu dem
Schluss, dass eine Modellierungsmethode zur Integration zwischenbetrieblicher
Informationsflüsse erforderlich ist.
In Kapitel 3 werden nach einer Abgrenzung der Begriffe Modell und Modellierungsmethode
die Ziele und Aufgaben der erforderlichen Modellierungsmethode festgelegt. Diese
orientieren sich an den in den vorangegangenen Kapiteln identifizierten Problemen und den
Defiziten vorhandener Integrationsansätze. Anschließend werden die Anforderungen an eine
Modellierungsmethode zur Integration zwischenbetrieblicher Informationsflüsse formuliert.
Sie ergeben sich aus den zuvor festgelegten Zielen und Aufgaben der Methode. Die
Anforderungen werden nach inhaltlichen und formalen Anforderungen differenziert. Kapitel 3
schließt mit einer Bewertung vorhandener Modellierungsansätze zur Integration
zwischenbetrieblicher Informationsflüsse und dem Fazit, dass bisher kein Ansatz die
Anforderungen in befriedigendem Maße erfüllen kann.
Kapitel 2
Anforderungen an die Modellierungsmethode
Kapitel 1
Kapitel 3
Ziele und Aufgaben der Modellierungsmethode
Kapitel 4
Fallbeispiele Grundlagen der Integration zwischenbetrieblicher Informationsflüsse Ansätze
Kapitel 6
Modelle Modellierungsmethoden
Bewertung, Ausblick
Kapitel 5
Praktische Anwendung
Entwurf der Modellierungsmethode
Ausgangslage, Ziel, Vorgehen
Abb. 1.1 Aufbau der Arbeit
Nach Maßgabe der in Kapitel 3 formulierten Anforderungen ist die Modellierungsmethode
MOVE entwickelt worden. Das Akronym MOVE wird dabei gegenüber dem
Forschungsprojekt MOVE umgedeutet und steht für „Modellierungsmethode für den
17 Vgl. BFK u. a. (Modellierung 1995), S. 14
8
verteilten Entwurf
zwischenbetrieblicher Informationsflüsse“. Sie wird in Kapitel 4 detailliert beschrieben. Nach
einer Übersicht zum Aufbau und Vorgehen erfolgt die Darstellung der einzelnen
Komponenten der Methode. Dazu zählen ein materiellorientierter Entwurfsrahmen, eine
Referenzbibliothek, eine Modellierungssprache sowie eine Vorgehensweise.
In Kapitel 5 wird anhand eines umfassenden Beispiels aus der Konsumgüterbranche die
Vorgehensweise und der Einsatz von MOVE dargestellt.
Auf der Grundlage der praktischen Anwendung der Methode wird in Kapitel 6 eine
Bewertung bezüglich der in Kapitel 3 gestellten Anforderungen vorgenommen. Die Arbeit
schließt mit einem Ausblick.
9
2 Grundlagen der Integration zwischenbetrieblicher Informations-flüsse
2.1 Fallbeispiele für eine Integration zwischenbetrieblicher Informationsflüsse
Nachfolgend werden fünf Fallbeispiele aus der Praxis für eine Integration
zwischenbetrieblicher Informationsflüsse beschrieben. Sie dienen dazu, den Gegenstand der
vorliegenden Arbeit exemplarisch zu umreißen. In den anschließenden Abschnitten erfolgt
eine begriffliche Abgrenzung und systematische Analyse des Untersuchungsgegenstandes.
Sämtliche Fallbeispiele beschreiben Integrationsprojekte, an denen der Autor im Rahmen
seiner beruflichen Tätigkeit bei der AMADEE AG, Minden18 direkt oder indirekt beteiligt
war. Beschrieben wird jeweils eine typische Aufgabenstellung für eine Integration
zwischenbetrieblicher Informationsflüsse.19 Das Spektrum der Fallbeispiele umfasst dabei
Integrationsprojekte aus verschiedenen Branchen unter Einbeziehung von manuellen
Benutzerinteraktionen (front office integration) bis hin zu Informationsflüssen zwischen
Anwendungssystemen ohne manuelle Eingriffe (back office integration).
In diesem Abschnitt werden bereits einige Fachbegriffe verwendet, die im weiteren Verlauf
der Arbeit noch erläutert werden.
Fallbeispiel 1 - Elektronische Auftragserfassung Lebensmittelgroßhandel
Im Mittelpunkt des ersten Fallbeispiels steht ein bedeutendes deutsches
Großhandelsunternehmen der Lebensmittelbranche. Gegenstand des Integrationsprojektes sind
Bestellungen, die gewerbliche Kunden an die Cash- & Carry-Märkte des
Großhandelsunternehmens richten.
Bislang erstellen die Kunden handschriftlich Listen mit den Bedarfsmengen der jeweiligen
Artikel, die sie nachbestellen möchten. Diese Listen geben sie telefonisch an den Cash- &
Carry-Markt durch oder übersenden sie per Fax. Im Cash- & Carry-Markt werden die
Bestellungen von Datentypistinnen im Warenwirtschaftssystem des
18 Die AMADEE AG, Minden ist ein Softwareunternehmen, welches Lösungen für die betriebsinterne und -übergreifende Integration von Informationsflüssen anbietet. 19 Auf eine ausführliche Darstellung der realisierten Lösungen wird verzichtet, da dies ohne detaillierte Erläuterungen zu einzelnen Produkten der AMADEE AG nicht möglich erscheint.
10
Großhandelsunternehmens erfasst. Aufgrund dieser Bestellungen werden
Auslieferungsaufträge vom System generiert.
Die bisherige Bestellabwicklung hat sich als sehr anfällig für Fehler erwiesen. Hauptgründe
sind der hohe Anteil manueller Tätigkeiten und die vielen Medienbrüche in diesem Ablauf.
Die Folge ist zum einen ein hoher Anteil fehlerhafter Lieferungen, zum anderen führt diese
Abwicklung aufgrund zahlreicher Rückfragen an den Kunden zu langen Bearbeitungszeiten
von bis zu drei Tagen zwischen Bestellvorgang und Auslieferung.
Der Bestellvorgang zwischen den gewerblichen Kunden und der Cash- & Carry-Märkte soll
nun wie folgt ablaufen. Die Erfassung der Bedarfsmengen soll mit Handscannern erfolgen.
Mit ihnen lassen sich die Barcodes der erforderlichen Artikel einlesen. Die aufgenommenen
Bestelldaten der mobilen Datenerfassungsgeräte (MDE-Geräte) sollen per
Datenfernübertragung an die Cash- & Carry-Märkte übertragen werden. Dort sind sie direkt
an das Warenwirtschaftssystem weiterzuleiten und automatisch weiterzuverarbeiten. Die
Kunden sollen per E-Mail eine Bestätigung über die korrekte Verbuchung ihrer Bestellung
erhalten. Die Abwicklung vom Bestellvorgang bis zur Auslieferung soll nicht länger als einen
Tag dauern.
Bei der beschriebenen Vorgehensweise ist sicherzustellen, dass keine Bestellung verloren geht
oder fehlerhaft bearbeitet wird. Dazu sind die Bestellungen einer syntaktischen und
semantischen Prüfung zu unterziehen. Unter anderem sind die Bestellungen vom Format der
MDE-Geräte in das Bestellformat des Warenwirtschaftssystems zu konvertieren.
Fallbeispiel 2 - Wartungsdienst
Im zweiten Fallbeispiel geht es um einen Betrieb, der einen 24h-Wartungsdienst (Reparaturen,
Wartungen, Pflege, etc.) für Tankstellenbetreiber anbietet und Störungen normalerweise
innerhalb von vier Stunden beseitigt. Jedoch möchte der Betrieb noch effizienter in der
Auftragsabwicklung sein, an der viele weitere Betriebe beteiligt sind. So wird in der Regel ein
Störfall von einem Tankstellenpächter telefonisch oder per Fax beim Wartungsdienstanbieter
gemeldet. Von dort wird der Auftrag an einen betriebseigenen oder selbstständigen Techniker
weitergeleitet. Die Techniker rechnen Ihre Leistung mit dem Wartungsdienstanbieter ab,
indem sie ein entsprechendes Auftrags- und Abrechnungsformular einreichen. Der
Wartungsdienstanbieter wiederum verschickt Rechnungen - je nach Fall - an den
Tankstellenpächter oder an die Mineralölgesellschaft.
11
Folgende Nachteile müssen bei diesem Ablauf in Kauf genommen werden. Die Mitarbeiter
beim Wartungsdienstanbieter sind nicht immer über den Einsatzort der Techniker und den
Status der Aufträge informiert. Im Störfall muss häufig in mehreren Telefongesprächen ein
freier Techniker gefunden werden. Bei Nachfragen der Auftraggeber kann keine direkte
Auskunft über den Auftrag gegeben werden. Durch die vielen Medienbrüche ist ein
erheblicher Zeitaufwand für die Datenerfassung erforderlich. Der Informationsaustausch in
diesem Prozess soll daher zukünftig elektronisch erfolgen.
In einem ersten Schritt soll die Störfall-Erfassung direkt über das Internet ermöglicht werden.
Dadurch sollen die Tankstellen und Mineralölgesellschaften künftig Störfälle selbst in das
System eingeben können. Im weiteren soll die Koordination der Techniker verbessert werden.
So sollen die Techniker zukünftig den Status ihrer laufenden Aufträge regelmäßig per SMS
bekannt geben. Zusätzlich wird zu jedem Techniker die Ausrüstung und das spezielle Know-
how festgehalten. Der Standort des Technikers wird über ein GPS-gesteuertes
Navigationssystem bestimmt. Wird ein Störfall gemeldet, können die Mitarbeiter beim
Wartungsdienstanbieter also auf einen Blick sehen, welcher Techniker aktuell verfügbar ist,
am schnellsten vor Ort sein kann und den betreffenden Störfall beheben kann. Für die
Abrechnung der Wartungsleistungen brauchen keine Daten neu erfasst werden und die
Rechnungsstellung kann so schneller erfolgen.
Fallbeispiel 3 - Elektronischer Datenaustausch per EDIFACT
Im dritten Fallbeispiel führt ein Hersteller von Gartenmöbelauflagen und Sonnenschirmen auf
Druck seiner Kunden den elektronischen Datenaustausch per EDIFACT ein. Zu den Kunden
des betroffenen Betriebes zählen große Handelsketten für Möbel und Baumärkte mit
angeschlossenen Gartencentern. Bislang erfolgte der Austausch von Geschäftsinformationen
(Aufträge, Auftragsbestätigungen, Rechnungen, etc.) per Fax oder Briefpost. Zunehmend
verlangen die Großkunden, die Dokumente elektronisch auszutauschen. Für einige Kunden
soll es in absehbarer Zeit Voraussetzung für die Vergabe von Aufträgen sein. Daher sah sich
der Möbelauflagen-Hersteller gezwungen, ebenfalls auf den elektronischen Austausch von
Daten umzustellen.
Nahezu sämtliche Kunden verwenden als Austauschformat EANCOM, ein Subset des
EDIFACT-Standards.20 Der Austausch erfolgt über das X.400-Netz. Um kein eigenes EDI-
20 Nähere Erläuterungen zu EDIFACT und seinen Subsets erfolgt in Abschnitt 2.6.1.
12
System aufbauen und betreiben zu müssen, möchte der Hersteller die Dienste eines EDI-
Clearingcenters nutzen. Dieses sorgt für die Konvertierung zwischen dem Format des internen
Anwendungssystems beim Möbelauflagen-Hersteller und dem EANCOM-Format sowie für
die Übertragung per X.400.
Fallbeispiel 4 - Anbindung eines Automobilherstellers an einen elektronischen Marktplatz
Fallbeispiel 4 betrifft die Anbindung eines ausländischen Tochterunternehmens eines großen
deutschen Automobilherstellers und einiger seiner Lieferanten an einen elektronischen
Marktplatz. Bei den Lieferanten handelt es sich um Hersteller von Artikeln, die nicht in die
Produktion beim Automobilhersteller einfließen (sogenannte C-Artikel). Darunter fallen
Artikel wie beispielsweise Arbeitskleidung, Büromaterial, Reinigungsartikel, etc. Für jeden
Artikel gibt es bislang eine kurze Liste alternativer Anbieter. In unregelmäßigen Abständen
holt der Einkäufer neue Angebote ein, um zu entscheiden, bei welchem Lieferant in den
nächsten Wochen bestellt werden soll. Die Übermittlung der Bestellungen selbst sowie
weiterer Geschäftsdokumente erfolgen per Fax oder Briefpost.
Beim bisherigen Einkaufsprozess ist es durchaus üblich, dass die Bestellungen nicht an den
günstigsten Anbieter gerichtet werden, da die Angebote ja nur in sporadischen Zeitabständen
verglichen werden. Daher birgt dieses Vorgehen ein hohes Einsparungspotenzial. Weitere
Kosten, die durch eine Automatisierung gesenkt werden könnten, entstehen durch die
papierzentrierte Abwicklung.
Aus den genannten Gründen hat sich der Automobilhersteller entschlossen, die Beschaffung
einiger Artikel über einen elektronischen Marktplatz abzuwickeln. Dabei werden die
Bestellungen direkt aus dem ERP-System an den Marktplatz gesendet, an dem ebenfalls die
Lieferanten elektronisch angebunden sind. Durch einen Auktionsmechanismus wird
automatisiert der günstigste Lieferant ermittelt, der den Zuschlag für die Auslieferung der
Bestellung erhält. Sämtlicher Dokumentenaustausch mit dem Marktplatz hat im xCBL-Format
zu erfolgen. Dieser wird allerdings von den betroffenen Anwendungssystemen der Lieferanten
und des Automobilherstellers nicht unterstützt. Zu den Integrationsaufgaben gehört daher aus
syntaktischer Sicht die Transformation der Geschäftsdokumente von und nach xCBL. Aus
semantischer Sicht besteht die Schwierigkeit, dass die Lieferanten ihre Artikel in einer
einheitlichen Weise beschreiben müssen, um vom Auktionsmechanismus, der vom Marktplatz
bereitgestellt wird, als alternative Produkte erkannt zu werden.
13
Fallbeispiel 5 - Integration von Händlern und Herstellern in der Automobilbranche
Das fünfte und letzte Fallbeispiel befasst sich mit der Integration von Informationsflüssen
zwischen Herstellern und Händlern in der Automobilbranche. Im vorliegenden Fall geht es
speziell um die Ersatzteilüberbestände einer bestimmten Automobilmarke. Bei
Ersatzteilüberbeständen handelt es sich um Ersatzteile, die im Lager vorrätig sind, aber nur
noch selten nachgefragt werden.
Bisher gab es keine Möglichkeit, zwischen den Autohändlern, Werkstätten,
Distributionszentren und Produktionsstätten des Herstellers übergreifende Informationen über
Ersatzteilüberbestände zu erhalten. Die Forderung nach einer hohen Lieferbereitschaft führt
zwangsläufig zu dem Problem hoher Überbestände an Ersatzteilen. Dadurch wird langfristig
notwendige Lagerfläche für Neuteile blockiert und zudem die Liquidität eingeschränkt. Bei
vielen Autohäusern sind rund 30 % des Ersatzteil-Lagervolumens Überbestände.
Um die Ersatzteilversorgung effizienter zu gestalten, haben die betroffenen Betriebe
beschlossen, eine zentrale Datenbank aufzubauen, die von allen Anwendungssystemen über
das Internet erreichbar sein soll. Über diese Datenbank kann leicht nach Ersatzteilen an
anderen Lagerstandorten recherchiert werden und gegebenenfalls von dort angefordert
werden. So soll das gesamte Lagervolumen an Ersatzteilen drastisch verkleinert werden
können.
Die Daten über Ersatzteilüberbestände sind automatisiert aus den jeweiligen Systemen der
betroffenen Unternehmen auszulesen und in der zentralen Datenbank bereitzustellen. So muss
z. B. erkannt werden, dass ein Ersatzteil seit zwölf Monaten nicht mehr benötigt wurde und
automatisch in die Datenbank übernommen wird. Neben der eigentlichen Bestandsdatenbank
soll eine Applikation auf dem Datenbankserver bereitgestellt werden, die für eine
elektronische Abwicklung der Ersatzteilbeschaffung einschließlich der zur
Ersatzteilversendung erforderlichen Logistikdienstleistung sorgt. Die zentrale Datenbank
nebst der erforderlichen Applikation soll von einem externen Dienstleistungsanbieter
betrieben werden.
2.2 Formen der Integration zwischenbetrieblicher Informationsflüsse
Nachdem einige exemplarische Aufgabenstellungen aus der Praxis angeführt worden sind,
sollen nun die verschiedenen Ausprägungen und Erscheinungsformen einer Integration
zwischenbetrieblicher Informationsflüsse systematisiert werden.
14
Ausgangspunkt der Untersuchung sind zunächst einzelne Betriebe und insbesondere deren
Informationssysteme. Der Begriff des Informationssystems wird in der Literatur vielfältig
verwendet.21 In einer ersten Begriffsbestimmung soll unter einem Informationssystem ein
System22 verstanden werden, das Informationen23 verarbeitet, d. h. erfasst, überträgt,
transformiert, speichert und bereitstellt.24 In dieser Arbeit werden Informationssysteme in
Wirtschaft und Verwaltung betrachtet, d. h. betriebliche Informationssysteme. Unter einem
Betrieb wird hier die kleinste Einheit verstanden, in der sich durch Zusammenfassung von
Menschen und
Sachen wirtschaftliche Handlungen25 vollziehen lassen.26 Betriebe können sowohl private als
auch öffentliche Unternehmungen und Haushalte, andere wirtschaftliche Institutionen wie
beispielsweise Zollbehörden oder Wirtschaftsverbände oder jeweils räumlich getrennte,
weitgehend autonome Teile davon sein.27
Eine begriffliche Präzisierung von betrieblichen Informationssystemen soll in Anlehnung an
FERSTL/SINZ28 erfolgen, die eine auf GROCHLA29 zurückzuführende Sichtweise einnehmen
(vgl. Tab. 2-1). Danach kann ein Betrieb in ein Basissystem und ein Informationssystem
unterteilt werden. Das Basissystem realisiert die eigentlichen Sachziele eines Betriebes, d. h.
es umfasst die Leistungserstellungsprozesse von Gütern. Beispiele dafür sind bei materiellen
Gütern die Beschaffung, die Produktion, die Lagerung und der Absatz, bei immateriellen
Gütern das Erbringen von Dienstleistungen. Aufgabe des Informationssystems ist die
Lenkung der betrieblichen Leistungserstellung, d. h. Planung, Steuerung und Kontrolle des
21 Eine Übersicht über einige Definitionen des Begriffs ‚Informationssystem‘ findet sich in Ferstl, Sinz (Grundlagen 1998), S. 8f. 22 Nach der allgemeinen Systemtheorie (als Begründer gilt BERTALANFFY; vgl. z. B. Bertalanffy (System 1968)) wird unter einem ‚System‘ ein sinnvoll in sich gegliedertes, geordnetes Ganzes gesehen, welches aus mehreren Elementen besteht, die miteinander in Beziehung stehen. Vgl. Bertalanffy (Vorläufer 1972), S. 18; Ferstl, Sinz (Grundlagen 1998), S. 11; Schütte (Grundsätze 1998), S. 37f. 23 Eine Definition des Begriffs ‚Information‘ erfolgt in Abschnitt 2.3 24 Vgl. Ferstl, Sinz (Grundlagen 1998), S. 1 25 Zum Begriff des wirtschaftlichen Handelns vgl. Zelewski (Grundlagen 1999), S. 11ff. 26 Vgl. Grochla (Betrieb 1993), Sp. 377f.; Zelewski (Grundlagen 1999), S. 20 27 Vgl. Kosiol (Unternehmung 1962), Sp. 5540ff.; Schmidt (Wirtschaftslehre 1969), S. 39ff.; Raffée (Grundprobleme 1995), S. 49ff.; Zelewski (Grundlagen 1999), S. 22ff. Die hier vorgenommene Verwendung des Betriebsbegriffs als Oberbegriff für Unternehmungen und Haushalte wird nicht von allen Autoren der Betriebswirtschaftslehre geteilt. Andere Auffassungen sehen die Unternehmung als Oberbegriff, Betrieb und Unternehmung als gleichgeordnete Begriffe oder als synonyme Bezeichnungen des gleichen Gegenstandes. Eine Übersicht und Diskussion der verschiedenen Begriffsauffassungen eines Betriebes findet sich beispielsweise in Grochla (Betrieb 1993), Sp. 376ff.; Raffée (Grundprobleme 1995), S. 49ff.; Wöhe (Einführung 1996), S. 2ff.; Zelewski (Grundlagen 1999), S. 20ff. 28 Zu den folgenden Ausführungen vgl. Ferstl, Sinz (Grundlagen 1998), S. 1ff. und S. 28ff. 29 Vgl. Grochla (Planung 1975), S. 12f.
15
Basissystems sowie die Erstellung von Dienstleistungen, sofern diese in Form von Informa-
tionen erbracht werden.30 Die Differenzierung nach maschinellen und personellen
Aufgabenträgern führt zur Unterscheidung zwischen einem automatisierten und einem nicht-
automatisierten Teil eines betrieblichen Informationssystems. Aufgabenträger des
automatisierten Teils sollen als Anwendungssysteme bezeichnet werden.31
Teilsystem Aufgabenträger (AT) Automatisiert Nicht automatisiert
Informations- system
AT: Anwendungs- systeme
AT: Manager, Sachbearbeiter
Basis- system
AT: Bearbeitungs-, Transportsysteme
AT: Werker
Tab. 2-1 Abgrenzung betrieblicher Informationssysteme32
Werden nicht mehr einzelne sondern mehrere Betriebe betrachtet, so lässt sich analog zur
innerbetrieblichen Betrachtungsweise wiederum ein Basis- und Informationssystem
unterscheiden.
Jeder Betrieb ist in betriebsübergreifende Wertschöpfungsflüsse eingebunden. Diese können
in primäre und sekundäre Wertschöpfungsflüsse unterschieden werden. Erstere umfassen die
Abfolge von Tätigkeiten mehrerer Betriebe, die direkt auf den Nutzen eines Endverbrauchers
gerichtet sind. Sie reichen von der Gewinnung des Rohmaterials über die Produktion von
Komponenten bis zum Vertrieb eines Fertigproduktes.33 So reicht beispielsweise der primäre
Wertschöpfungsfluss eines Computers von der Rohstoffbeschaffung, der Chip- und
Festplattenproduktion über die Montage und den Handel bis hin zum Endverbraucher. Im
primären Wertschöpfungsfluss wird die Nachfrage nach sekundären Produkten, wie
beispielsweise der Transport oder die Finanzierung von Roh-, Zwischen- oder
Fertigprodukten, erzeugt. Tätigkeiten in einem sekundären Wertschöpfungsfluss zielen nicht
direkt auf den Nutzen für den Endverbraucher.
Sowohl in einem primären als auch in einem sekundären Wertschöpfungsfluss erfolgen
Leistungsflüsse zwischen den beteiligten Betrieben. Darunter wird die Übertragung von
materiellen (z. B. Lieferung von Waren) oder immateriellen (z. B. Durchführung von Dienst-
30 Die von FERSTL/SINZ vorgenommene Berücksichtigung von Dienstleistungen, die auf Informationen beruhen (vgl. Ferstl, Sinz (Grundlagen 1998), S. 1f.), erfolgt bei GROCHLA nicht. 31 Vgl. Ferstl, Sinz (Grundlagen 1998), S. 5; Fischer (Informationswirtschaft 1999), Vorwort, S. III 32 Vgl. Ferstl, Sinz (Grundlagen 1998), S. 4
16
leistungen, Überlassung von Rechten) Realgütern verstanden. Als Gegenleistung erfolgen
Zahlungsflüsse, deren Gegenstand die Übertragung von Nominalgütern (z. B. Barzahlung,
Ausgleich einer Rechnung per Überweisung) ist.34 Leistungs- und Zahlungsflüsse bilden
zusammen mit den wertschöpferischen Tätigkeiten der einzelnen Betriebe, also mit den
innerbetrieblichen Basissystemen, das zwischenbetriebliche Basissystem.
Zwischenbetriebliche Leistungs- und Zahlungsflüsse werden von Informationsflüssen
begleitet und beeinflusst, d. h. sie werden von ihnen geplant, gesteuert und kontrolliert.35
Erfolgen Informationsflüsse zwischen Informationssystemen verschiedener Betriebe, so soll
von zwischenbetrieblichen Informationsflüssen gesprochen werden. Sie sind Hauptgegenstand
der vorliegenden Arbeit. Zusammen mit den innerbetrieblichen Informationssystemen bilden
sie ein zwischenbetriebliches Informationssystem.
Abb. 2.1 Zwischenbetriebliches Basis- und Informationssystem
Zahlungs- und Informationsflüsse existieren nicht per se, sondern besitzen immer einen Bezug
zu einem Leistungsfluss. Daher sollen ein Leistungsfluss und die zu ihm gehörigen Zahlungs-
und Informationsflüsse, die ihn planen, steuern und kontrollieren, gedanklich
33 Vgl. Alt, Cathomen (Handbuch 1995), S. 15 34 Im Grunde genommen handelt es sich sowohl bei der Übertragung von materiellen oder immateriellen Realgütern als auch bei der Übertragung von Nominalgütern um Leistungsflüsse. So spezialisieren FERSTL/SINZ Leistungsflüsse in Güter-, Zahlungs- und Dienstleistungsflüsse. Vgl. Ferstl, Sinz (Grundlagen 1998), S. 60. Allerdings ist für die weitere Analyse eine Differenzierung zwischen Güter- und Dienstleistungsflüssen nicht erforderlich. In Ermangelung eines geeigneteren Oberbegriffs werden sie daher als Leistungsflüsse bezeichnet und von Zahlungsflüssen unterschieden. Auch wenn diese Regelung aus sprachlogischer Sicht falsch ist, erscheint sie für die weitere Argumentationsdarstellung der Arbeit ökonomischer, als eine ständige Differenzierung von Gütern und Dienstleistungen. 35 Vgl. BFK u. a. (Modellierung 1995), S. 9; Alt, Cathomen (Handbuch 1995), S. 13
Informationen InformationenInform.
LeistungenLeist.
Zahlungen ZahlungenZahl.l
Zwischenbetriebliches Informationssystem
Zwischenbetriebliches Basissystem
Leistungen
Primäre Wertschöpfungskette Sekundäre
Wertschöpfungske
tten
Zulieferer-betrieb
Hersteller-betrieb
Handels-betrieb
Spediteur
Bank
Spediteur
Bank
Spediteur
Bank
Inner-betrieblichesInformations-
system
Inner-betrieblichesBasissystem
Inner-betrieblichesInformations-
system
Inner-betrieblichesInformations-
system
Inner-betrieblichesBasissystem
Inner-betrieblichesBasissystem
VorgelagerteWertschöpfungs-
stufen
NachgelagerteWertschöpfungs-stufen
17
zusammengefasst und als zwischenbetriebliche Transaktion bezeichnet werden.36 Es können
primäre und sekundäre Transaktionen unterschieden werden. Primäre Transaktionen treten im
Rahmen eines primären Wertschöpfungsflusses auf. Deren Leistungsflüsse bestehen also in
der Regel aus der Übertragung von materiellen Gütern wie Rohstoffe, Komponenten oder
Fertigprodukte. Für die Abwicklung von primären Transaktionen werden Transaktionen im
sekundären Wertschöpfungsfluss initiiert. Dazu gehören beispielsweise Transport- und
Finanzdienstleistungen.
An einer zwischenbetrieblichen Transaktion sind mindestens zwei, in der Regel aber mehrere
Betriebe beteiligt. Daraus ergeben sich verschiedene Transaktionsmuster. Darunter sollen
wiederkehrende und verallgemeinerbare Konstellationen bei der Abwicklung von
Transaktionen verstanden werden. Transaktionsmuster konstituieren sich durch die Anzahl
und Rollen der beteiligten Betriebe sowie die Strukturen der Leistungs-, Zahlungs- und
Informationsflüsse. In der Konsumgüterbranche können beispielsweise die
Transaktionsmuster Lager-, Strecken-, Zentralregulierungs-, Aktions- und
Dienstleistungsgeschäft unterschieden werden.37
Die einzelnen Tätigkeiten innerhalb des zwischenbetrieblichen Basissystems sind zeitlich und
sachlogisch miteinander verknüpft. Zur Erfüllung der betriebsübergreifenden Aufgaben ist es
notwendig, dass die beteiligten Betriebe ihre Aktivitäten durch Informationsflüsse abstimmen
und koordinieren. In einer solchen arbeitsteilig organisierten Wirtschaftsordnung spielen
zwischenbetriebliche Informationsflüsse eine wichtige Rolle. Ohne sie können keine
Leistungs- oder Zahlungsflüsse durchgeführt werden oder kommen erst gar nicht zustande.38
Nur der Austausch von Informationen ermöglicht eine Koordination von Leistungserstellungs-
und Allokationsprozessen.39 „Alles das, was [...] geteilt, gespalten oder weiter untergliedert -
36 Diese Auffassung des Transaktionsbegriffs deckt sich mit der Verwendung im Transaktionskostenansatz. Nach WILLLIAMSON, der als wichtigster Vertreter der ‚modernen‘ Form der Transaktionskostentheorie, die auf COASE zurückgeht (vgl. Coase (Nature 1937)), gilt, treten Transaktionen dann auf, „when a good or service is transferred across a technologically separable interface.“ Williamson (Institutions 1985) S. 1. Zur Transaktion gehört dabei der Prozess der Klärung und Vereinbarung des Leistungsaustausches. Vgl. Picot (Transaktionskostenansatz 1993), Sp. 4195. Damit sind die Überlegungen und Erkenntnisse der Transaktionskostentheorie auf den in dieser Arbeit verwendeten Transaktionsbegriff anwendbar. 37 Vgl. Petri (Integration 1990), S. 93ff.; Becker, Schütte (Handelsinformationssysteme 1996), S. 419ff. 38 Vgl. Picot (Organisation 1993), S. 147; Kilian u. a. (Data 1994), S. 28 39 Vgl. Picot, Maier (Information 1993), S. 39; Bode (Informationsbegriff 1997), S. 449
18
mit einem Wort: was aufgelöst worden ist, muß durch ein System von Information und
Kommunikation wieder verbunden werden.“40
Zur Analyse, in welcher Weise Informationsflüsse den Ablauf zwischenbetrieblicher
Transaktionen beeinflussen, soll ein Phasenmodell herangezogen werden, deren Ursprung auf
den Transaktionskostenansatz41 zurückzuführen ist. Grundannahme ist, dass sich
Handelspartner für einen Leistungsaustausch zunächst finden müssen und sodann die
Konditionen vereinbaren, bevor der Austausch durchgeführt werden kann.42 Danach werden
zwischenbetriebliche Transaktionen üblicherweise in drei Phasen unterteilt, die in der
Literatur unterschiedlich bezeichnet werden (vgl. Tab. 2-2). Im Rahmen dieser Arbeit wird in
Anlehnung an FERSTL/SINZ von der Anbahnungs-, Vereinbarungs- und Durchführungsphase
gesprochen. SCHMID und ZBORNIK unterscheiden dagegen fünf Phasen, da sie die ersten
beiden Phasen noch näher differenzieren. So unterteilen sie die Anbahnungsphase in eine
Marktinformationsbeschaffungsphase und der eigentlichen Markt- bzw. Handelspartnersuche.
Die Partnerinformationsbeschaffung sowie die Vertragsaushandlungsphase bzw. -
abschlussphase bilden bei ihnen die Vereinbarungsphase.
Quelle Phasenmodell Kirsch u. a. (Logistik 1973), S. 189-192
Anbahnung Vereinbarung Realisation
Hubmann (Elektronisierung 1989), S. 45ff.43
Orientierung Verhandlung bzw. Optimierung
Realisierung
Schmid (Kommunikations-modelle 1992), S. 78ff.
Markt-informa-tions-beschaf-fung
Marktpartnersuche Partner-informa-tions-beschaf-fung
Vertrags-aus-handlung
Transaktions-abwicklung
Zbornik (Märkte 1996), S. 138
Markt-informa-tions-beschaf-fung
Handelspartnersuche Partner-informa-tions-beschaf-fung
Vertrags-aus-handlung
Transaktions-abwicklung
40 Kortzfleisch (Information 1973), S. 551 41 Zum Transaktionskostenansatz vgl. Coase (Nature 1937); Williamson (Institutions 1985); Picot (Trans-aktionskostenansatz 1993) und die dort zitierte Literatur. 42 Vgl. Ferstl, Sinz (Grundlagen 1998), S. 61 43 HUBMANN bezieht seine Phasen ausschließlich auf die Beschaffung und nimmt somit eine auf die Nachfragerseite beschränkte Sichtweise ein.
19
Alt (Interorganisations-systeme 1997), S. 61
Information Vereinbarung Abwicklung
Ferstl, Sinz (Grundlagen 1998), S. 61f.
Anbahnung Vereinbarung Durchführung
Tab. 2-2 Phasen zwischenbetrieblicher Transaktionen
In der Anbahnungsphase holen die potentiellen Handelspartner Informationen über angebotene bzw. nachgefragte Güter ein und stellen Kontakte zu den Betrieben mit komplementären Interessen her.44 Dazu sind Informationen über die Nachfrage und das Angebot sowie über die Marktteilnehmer selbst für die nachfolgenden Phasen adäquat bereitzustellen.45 In der Vereinbarungsphase geht es um den rechtlich bindenden Vertragsabschluss über einen Leistungsaustausch. Dabei werden die Konditionen ausgehandelt und mit einem verbindlichen Auftrag abgeschlossen.46 Es folgt dessen Abwicklung in der Durchführungsphase, die im wesentlichen die Übertragung der im Auftrag spezifizierten Leistung und deren Bezahlung durch den Käufer sowie die Kontrolle über die Einhaltung der festgelegten Liefer- und Zahlungsbedingungen umfasst.47 Mit der Abwicklung ist in der Regel ein intensiver Informationsaustausch verbunden. Zur Aufrechterhaltung einer Geschäftsbeziehung können Informationsflüsse eingesetzt werden, die sich keiner Phase zuordnen lassen. Zu diesen phasenunabhängigen Informationsflüssen gehört beispielsweise der Austausch von Artikel- und Partnerstammdaten.
Zwischen der Phase einer zwischenbetrieblichen Transaktion und der zeitlichen Ordnung eines Informationsflusses in Bezug auf den Leistungs- bzw. Zahlungsfluss kann ein Zusammenhang festgestellt werden (vgl. Tab. 2-3). So sind Informationsflüsse der Anbahnungs- und Vereinbarungsphase dem eigentlich Leistungs- bzw. Zahlungsfluss naturgemäß vorgelagert. Dagegen treten in der Durchführungsphase sowohl vorgelagerte (z. B. Lieferavis) als auch begleitende (z. B. Lieferschein) und nachgelagerte (z. B. Rechnung) Informationsflüsse auf.
Phase Zeitliche Ordnung Anbahnung
Vereinbarung
Vorgelagert
Durchführung Begleitend Nachgelagert Tab. 2-3 Zeitliche Ordnung zwischenbetrieblicher Informationsflüsse
44 Vgl. Zbornik (Märkte 1996), S. 138f. 45 Vgl. Alt, Cathomen (Handbuch 1995), S. 14 46 Vgl. Zbornik (Märkte 1996), S. 139; Ferstl, Sinz (Grundlagen 1998), S. 61
20
Es leuchtet unmittelbar ein, dass durch eine reibungslose Gestaltung der Informationsflüsse
ein direkter Einfluss auf die Abwicklung der Leistungs- und Zahlungsflüsse genommen
werden kann. Dieses bewegt Betriebe dazu, ihre Informationssysteme zu koppeln bzw. die
zwischenbetrieblichen Informationsflüsse zu integrieren.48 Was unter gekoppelten
Informationssystemen bzw. integrierten zwischenbetrieblichen Informationsflüssen
verstanden wird, soll vorläufig anhand der Art der Informationsflussbeziehung und des
verwendeten Übertragungskanals festgemacht werden. Im nachfolgenden Abschnitt erfolgt
eine genauere Erläuterung des Begriffs.
Betrachtet man die als Sender und Empfänger an einem zwischenbetrieblichen
Informationsfluss beteiligten Aufgabenträger der innerbetrieblichen Informationssysteme
differenziert nach Personen bzw. Menschen und Anwendungssystemen, so ergeben sich vier
Arten von Informationsflussbeziehungen (vgl. Abb. 2.2):49
1. Informationsfluss von Mensch zu Mensch (z. B. telefonische Bestellung)
2. Informationsfluss von Mensch zu Anwendungssystem (z. B. Ausfüllen eines
Webformulars)
3. Informationsfluss von Anwendungssystem zu Mensch (z. B. Anzeigen einer Webseite)
4. Informationsfluss von Anwendungssystem zu Anwendungssystem (z. B. EDI-Nachricht)
Sender Empfänger
Mensch - Mensch
Anwendungssystem - Mensch
Mensch - Anwendungssystem
Anwendungssystem - Anwendungssystem
Abb. 2.2 Arten von Informationsflussbeziehungen
Von gekoppelten Informationssystemen bzw. einem integrierten zwischenbetrieblichen
Informationsfluss soll gesprochen werden, wenn die Informationen über einen elektronischen
Kanal versendet werden und mindestens ein Anwendungssystem als Sender oder Empfänger
47 Vgl. Alt, Cathomen (Handbuch 1995), S. 14 48 Vgl. Schissler u. a. (Unterstützung 2001), S. 1 49 Vgl. Kortzfleisch (Information 1973), S. 557; Scheckenbach (Geschäftsprozeßintegration 1997), S. 85
21
am Informationsfluss beteiligt ist. Bei Informationsflüssen zwischen Menschen handelt es sich
demnach nicht um integrierte Informationsflüsse.
Nach dem Kopplungsgrad können einseitig oder beidseitig gekoppelte Informationssysteme
unterschieden werden. Bei einseitig gekoppelten Systemen bzw. einseitig integrierten
Informationsflüssen ist nur ein Anwendungssystem an der Informationsflussbeziehung
beteiligt. Entweder werden Informationen von diesem Anwendungssystem beim Sender
automatisiert versendet oder beim Empfänger automatisiert weiterverarbeitet. Bei
Informationsflüssen
zwischen zwei Anwendungssystemen handelt es sich um beidseitig gekoppelte
Informationssysteme.
Die Integration zwischenbetrieblicher Informationsflüsse kann sowohl durch Betriebe in
einem primären als auch in einem sekundären Wertschöpfungsfluss erfolgen. Dabei können
die Informationssysteme zweier Betriebe direkt miteinander gekoppelt werden oder indirekt
über eine Vermittlungsstelle, wie beispielsweise über einen elektronischen Marktplatz oder
über einen Anbieter eines Mehrwertdienstes.50
Ausprägungen und Erscheinungsformen einer Integration zwischenbetrieblicher
Informationsflüsse können somit nach den Dimensionen Kopplungsgrad,
Wertschöpfungsfluss und Topologie charakterisiert und systematisiert werden (vgl. Abb. 2.3).
4
einseitig beidseitig Kopplungsgrad
primär
sekundär
Wertschöpfungsfluss
Topologie
direkt
indirekt5
3
2
1
Abb. 2.3 Formen einer Integration zwischenbetrieblicher Informationsflüsse
50 Nähere Erläuterungen zu Mehrwertdiensten erfolgen in Abschnitt 2.6.1
22
Nach ihrer Form lassen sich nun die eingangs beschriebenen Fallbeispiele wie folgt einordnen
(vgl. Abb. 2.3). Im Fallbeispiel 1 (Elektronische Auftragserfassung Lebensmittelgroßhandel)
handelt es sich um eine einseitige Integration zwischenbetrieblicher Informationsflüsse
zwischen Betrieben im primären Wertschöpfungsfluss. Die Kopplung des Informationsflusses
erfolgt dabei direkt. Ganz ähnlich sieht es im zweiten Fallbeispiel (Wartungsdienst) aus. Der
einzige Unterschied hinsichtlich der Form ist, dass hierbei Betriebe im sekundären
Wertschöpfungsfluss an der Integration der zwischenbetrieblichen Informationsflüsse beteiligt
sind. Dies ist ebenso im Fallbeispiel 4 (Anbindung eines Automobilherstellers an einen
elektronischen Marktplatz) der Fall. Allerdings handelt es sich hierbei um eine indirekte und
beidseitige Kopplung der Informationssysteme. Der elektronische Marktplatz übernimmt in
diesem Szenario die Rolle der elektronische Vermittlungsstelle, über die die Integration der
Informationsflüsse zwischen dem Automobilhersteller und seinen Lieferanten erfolgt.
Fallbeispiel 3 (Elektronischer Datenaustausch per EDIFACT) und Fallbeispiel 5 (Integration
von Händlern und Hersteller in der Automobilbranche) sind Beispiele für eine indirekte,
beidseitige Integration zwischen Betrieben in einem primären Wertschöpfungsfluss. Wie auch
im Fallbeispiel 4 werden elektronische Nachrichten ohne manuelle Eingriffe über eine
Vermittlungsstelle zwischen den Anwendungssystemen der beteiligten Betriebe ausgetauscht.
2.3 Integration zwischenbetrieblicher Informationsflüsse als Zustand
Die Integration zwischenbetrieblicher Informationsflüsse wurde in dieser Arbeit bislang recht
knapp als betriebsübergreifend gekoppelte Informationssysteme umschrieben. Eine begriff-
liche Präzisierung soll nun nachgeholt werden.
Der Begriff der Integration findet in unterschiedlichen wissenschaftlichen Disziplinen, wie
beispielsweise in der Mathematik, Philosophie, Soziologie oder Wirtschaftsinformatik,
Verwendung.51 Er wird im Allgemeinen als „Wiederherstellung eines Ganzen“,
„(Wieder)herstellung einer Einheit“ oder „Einbeziehung, Eingliederung in ein größeres
Ganzes“ verstanden.52 Aus dem Blickwinkel der Systemtheorie formuliert heißt Integration,
aus selbstständigen Systemen niederer Ordnung ein System höherer Ordnung zu bilden.53
Danach wird in dieser Arbeit aus Sicht eines Betriebes unter Integration die Eingliederung der
zwischenbetrieblichen Informationsflüsse in die betrieblichen Anwendungssysteme
51 Vgl. Petri (Integration 1990), S. 8 52 Vgl. Drosdowski u. a. (Duden 1990), S. 354. Vgl. ähnlich Bünting, Karatas (Wörterbuch 1996), S. 572
23
verstanden. Offen bleibt die Frage, unter welchen Umständen ein zwischenbetrieblicher
Informationsfluss als eingegliedert bzw. als integriert gilt. Nachfolgend soll beschrieben
werden, wodurch der Zustand einer Integration zwischenbetrieblicher Informationsflüsse
gekennzeichnet ist. Voraussetzung dafür ist zunächst die Klärung der Begriffe ‚Information‘
und ‚Informationsfluss‘.
Grundlage von Informationen sind Zeichen,54 womit hier aus semiotischer55 Sicht symbolische
Zeichen56 gemeint sind. Danach stellen symbolische Zeichen allgemeingültige und vereinbarte
Zeigehandlungen dar. Bei Zeigehandlungen besteht die Handlung57 darin, dass auf etwas
gezeigt wird. Sofern von einer einzelnen Zeigehandlung abstrahiert wird, wird von einem
Zeigehandlungsschema oder kurz Zeichen gesprochen.58 Nach einer bestimmten Regel
(Sprache) angeordnete Zeichen mit einer Bedeutung sollen als Daten59 bezeichnet werden.
Bedeutung erhalten die Daten durch die Zuordnung zu Gegenständen, Personen, Vorgängen
oder Zuständen der Real- oder Vorstellungswelt.60 Wenn Daten von einem Rezipienten
interpretiert werden und bei ihm eine Reaktion auslösen können, so handelt es sich um
Informationen.61 Bei „Vorliegen einer Information kann eine Handlungsabsicht initiiert
werden, muss aber nicht.“62 Voraussetzung für Informationen ist, dass der Betrachter von
53 Vgl. Fischer (Informationswirtschaft 1999), S. 86 54 Vgl. Lehner, Maier (Information 1994), S. 80 u. S. 90; Bode (Informationsbegriff 1997), S. 452; Schütte (Grundsätze 1998), S. 1f. 55 Zur Semiotik vgl. beispielsweise Rodi (Semiotik 1989) und die dort zitierte Literatur 56 In der Semiotik werden ikonische, indexikalische sowie symbolische Zeichen unterschieden. Ikonische Zeichen stehen in einer unmittelbar wahrnehmbaren Beziehung zur bezeichneten Sache (z. B. div. Verkehrsschilder). Indexikalische Zeichen sind dadurch charakterisiert, dass sie unmittelbar mit dem Bezeichnetem im Zusammenhang stehen (z. B. deutet Rauch auf Feuer, ein Fingerabdruck auf den Täter). Symbolische Zeichen sind unabhängig von einer ikonischen Ähnlichkeit und realem Bezug zu einer gegebenen Sache. Sie repräsentieren in beliebiger Setzung nach konventionellen Regeln dauernd eine bestimmte Gegenstandsart. Vgl. Rodi (Semiotik 1989), S. 297 57 Zum Begriff der Handlung und insbesondere der Zeigehandlung vgl. Lorenz (Handlung 1995), S. 33ff. 58 Vgl. Brekle (Semantik 1972), S. 44f.; Schütte (Grundsätze 1998), S. 1f. 59 Im Bereich der Informatik wird ausschließlich die Pluralform Daten verwendet; der Singular bleibt i. d. R. dem Tagesdatum vorbehalten. Vgl. Ferstl, Sinz (Grundlagen 1998), S. 126; Lehner, Maier (Information 1994), S. 30 60 Vgl. Heinrich, Lehner, Roithmayr (Informationstechnik 1990), S. 189; Lehner, Maier (Information 1994), S. 90; Picot, Reichwald, Wigand (Unternehmung 1996), S. 68 61 Vgl. Kortzfleisch (Information 1973), S. 551; Schütte (Grundsätze 1998), S. 2. Dieses Verständnis kommt der Auffassung nahe, Informationen als Interpretation von Daten zu verstehen. Vgl. König, Syben, Heinzl (Anmerkungen 1990), S. 48; Steinmüller (Informationstechnologie 1993), S. 354; Lehner, Maier (Information 1994), S. 85; Ferstl, Sinz (Grundlagen 1998), S. 126. Allerdings wird dabei nicht die Sichtweise geteilt, Informationen als Ergebnis bzw. Output eines Interpretationsprozesses, d. h. ein von den Daten zu unterscheidendes Artefakt (wie LEHNER/MAIER ), oder als den Prozess der Interpretation selbst (wie KÖNIG/SYBEN/HEINZL) zu sehen. 62 Lehner, Maier (Information 1994), S. 83
24
Zeichen diese versteht, d. h. ihre Bedeutung kennt, und dass sie seinen Kenntnisstand
ändern.63
Informationen lassen sich der pragmatischen64 Ebene der Semiotik65 zuordnen. Von Informa-
tionen kann nur gesprochen werden, wenn die Beziehung von Zeichen zu ihren Nutzern
betrachtet wird (vgl. Abb. 2.4).66 Konstituierend für Informationen sind ja gerade die
Interpretation und die möglichen Reaktionen ihres Rezipienten. Ob etwas Information
darstellt oder nicht, kann also nur im Situations- und Kontextbezug entschieden werden. Eine
zugeordnete Bedeutung allein ist dagegen keine hinreichende - aber notwendige - Bedingung,
um eine Zeichenkette zur Information werden zu lassen.67 Daten können auf der semantischen
Ebene eingeordnet werden.
Abb. 2.4 Semiotische Ebenen der Information
Zeichen und damit Daten und Informationen, manifestieren sich immer in einer bestimmten
Gestalt in einem materiellen Medium.68 Gleichwohl kann von Information nur im
Zusammenhang mit menschlichen Handlungen gesprochen werden.69 Nur für sich betrachtet,
kann nichts als Information gelten, bestenfalls als ‚potentielle Information‘.70 Träger von
Informationen ist aber letztendlich ein Medium und die darauf enthaltenen Zeichen.
63 Vgl. Kortzfleisch (Information 1973), S. 551 64 Seitens der Semiotik wird allgemein die Auffassung vertreten, dass sich die Pragmatik mit der Gesamtheit aller Beziehungen zwischen den Zeichen einer Sprache und den Zeichenbenutzern befasst. Vgl. Rodi (Semiotik 1989), S. 299; Lehner, Maier (Information 1994), S. 11; Zelewski (Bezugsrahmen 1995), Fußnote 74, S. 363 65 Zu den Untersuchungsebenen der Semiotik vgl. Stegmüller (Hauptströmungen 1975), S. 414f.; Rodi (Semiotik 1989), S. 298f.; Lehner, Maier (Information 1994), S. 10f. 66 Vgl. Heinrich, Lehner, Roithmayr (Informationstechnik 1990), S. 190; Steinmüller (Informationstechnologie 1993), S. 202 67 Vgl. Lehner, Maier (Information 1994), S. 10. Gegenteiliger Auffassung ist z. B. Fischer, der Informationen als Bedeutungsinhalt von Daten versteht. Vgl. Fischer (Datenmanagement 1992), S. 11 68 Vgl. Brekle (Semantik 1972), S. 48; Bode (Informationsbegriff 1997), S. 452 69 Vgl. Schütte (Grundsätze 1998), S. 3 70 Zum Begriff der ‚potentiellen Information‘ vgl. Picot, Reichwald (Informationswirtschaft 1991), S. 252; Schütte (Grundsätze 1998), S. 5
Pragmatik
Sprache
Semantik
Sprache
Syntaktik
Zeichen
Sprache
Daten
Bedeutung
RezipientInfor-mation
Bedeutung
25
Zeichen sind ein raumzeitliches Gebilde.71 Informationen können nicht für sich allein gesehen
werden, sondern immer nur im Kontext mit dem zu einem Zeitpunkt vorliegenden
Kenntnisstand des Rezipienten.72 Sie sind daher zeitpunktbezogen. Es wird davon
ausgegangen, dass bekannte Daten keine Reaktionen bei einem Rezipienten auslösen können.
Als Konsequenz wird von Informationen ein gewisser Neuheitsgrad gefordert.73
Informationen sind Daten, die unter einem spezifischen Aspekt betrachtet werden. Dem
Datenbegriff fehlt der Verwendungsbezug zu seinem Nutzer sowie eine gegebenenfalls
induzierte Handlungsrelation. Der gleiche Gegenstand einer Untersuchung kann daher sowohl
Daten als auch Information darstellen, je nachdem, welcher Zusammenhang betrachtet wird
(vgl. Abb. 2.4).74
In Tab. 2-4 wird der hier unterstellte Informationsbegriff zusammengefasst dargestellt.75
Kriterium76 Einordnung des unterstellten Informationsbegriffs Ebene der Semiotik Pragmatische Ebene Träger der Information Informationen sind an ein Medium gebunden Neuheitsgrad Informationen beinhalten einen Neuheitsgrad Zeitbezug Zeitpunktbezogen Information und Daten Information = Daten, die im Zusammenhang mit ihren Nutzern
betrachtet werden Tab. 2-4 Informationsbegriff dieser Arbeit
Die Übermittlung bzw. Übertragung von Daten über räumliche Entfernungen von einem
Sender zu einem oder mehreren Empfängern soll als Datenfluss bezeichnet werden.77 Es soll
71 Vgl. Seiffert (Einführung 1997), S. 192 72 Vgl. Picot, Maier (Information 1993), S. 33f. 73 Vgl. Picot, Maier (Information 1993), S. 34; Schütte (Grundsätze 1998), S. 2f. SCHÜTTE weist darauf hin, „daß aufgrund des zumindest wechselnden Zeitindexes innerhalb des Raum-Zeitindexes, in dem sich Handlungen bewegen, [...] de facto keine analogen Handlungssituationen geben [kann], so daß potentiell alles Neuigkeitscharakter hat.“ Vgl. Schütte (Grundsätze 1998), S. 3. WEIZSÄCKER kommt in einer gründlichen Analyse jedoch zu dem Schluß, dass jede Information neben ihrer Erstmaligkeit auch bestätigende, schon bekannte Elemente enthalten muss. Vgl. Weizsäcker (Erstmaligkeit 1974), S. 93ff. 74 Vgl. Picot, Reichwald (Informationswirtschaft 1991), S. 252 75 Obgleich ‚Information‘ zu den Schlüsselbegriffen der Wirtschaftsinformatik zählt, konnte bislang keine allgemein akzeptierte Definition dafür entwickelt werden. Vgl. Steinmüller (Informationstechnologie 1993), S. 190f.; Lehner, Maier (Information 1994), S. 1 u. S. 44; Schütte (Grundsätze 1998), S. 1. Dies erscheint nach Auffassung von BODE auch gar nicht möglich. Vgl. Bode (Informationsbegriff 1997), S. 454. Durch die tabellarische Übersicht wird das hier unterstellte Informationsverständnis gegenüber anderen Definitionen abgegrenzt. Auf eine explizite Gegenüberstellung mit anderen Informationsbegriffen, insbesondere der Betriebswirtschaftslehre und der Informatik, wird verzichtet. Verwiesen sei auf die ausführlichen Diskussionen des Informationsbegriffs in Steinmüller (Informationstechnologie 1993); Lehner, Maier (Information 1994); Bode (Informationsbegriff 1997) und auf die dort zitierte Literatur. 76 Zu den Kriterien vgl. Lehner, Maier (Information 1994), S. 76. Die ersten vier Kriterien werden auch von BODE für eine Typologie des Informationsbegriff verwendet. Er bezeichnet sie als Semiotik, Träger,
26
von einem Informationsfluss gesprochen werden, wenn diese Daten vom Empfänger
verstanden und interpretiert werden, so dass sie bei ihm eine Reaktion auslösen.78 Ein
Informationsfluss setzt damit die Übertragung und das Verstehen von Daten voraus.79 Nach
dem in dieser Arbeit propagierten Verständnis wird von Informationen gesprochen, wenn
Daten von einem Rezipienten interpretiert werden und bei ihm eine Reaktion auslösen
können. Dieser Interpretationsvorgang stellt eine kognitive Leistung dar, die nur von einem
Menschen erbracht werden kann.80 Allerdings wird die Auffassung vertreten, dass von
Menschen verfasste Interpretationsvorschriften für Daten in Form von Programmen in
Anwendungssystemen hinterlegt werden können.81 Damit können auch Anwendungssysteme
Rezipienten von Informationen respektive von Informationsflüssen sein.
Daten, die zum Zweck der Weitergabe von Informationen übertragen werden, werden als
Nachricht bezeichnet.82 Die reine Übertragung der einer Nachricht zugrundeliegenden Zeichen
soll als Kommunikation bezeichnet werden.83 Aufgrund der Einordnung von Informationen in
die pragmatische Ebene, müssen neben der Kommunikation die drei semiotischen Ebenen
Syntaktik, Semantik und Pragmatik berücksichtigt werden, um von einem Informationsfluss
sprechen zu können.84 In syntaktischer Hinsicht muss der Empfänger die Sprache des Senders
verstehen. Darüber hinaus muss Einigkeit im Hinblick auf die Bedeutung der übertragenen
Zeichen herrschen (semantische Ebene). Ist dies der Fall, liegt bereits ein Datenfluss vor.
Letztendlich muss in pragmatischer Hinsicht der Empfänger die Daten interpretieren, um
angemessen auf sie reagieren zu können. Nur dann liegt auch ein Informationsfluss vor.
Treffen die Bedingungen für einen Informationsfluss bei Beteiligung mindestens eines
Anwendungssystems als Sender oder Empfänger einer betriebsübergreifenden Übertragung
von Informationen zu, so soll von einem integrierten zwischenbetrieblichen Informationsfluss
Neuheitsgrad und Zeitbezogenheit. Vgl. Bode (Informationsbegriff 1997), S. 451ff. 77 Damit kann die einmalige, mehrmalige oder kontinuierliche Übertragung von Daten gemeint sein. 78 In der Literatur wird dafür auch häufig der Begriff ‚Kommunikation‘ verwendet. Vgl. Kortzfleisch (Information 1973), S. 552; Picot (Organisation 1993), S. 147; Steinmüller (Informationstechnologie 1993), S. 157 79 Vgl. Fischer (Kommunikationssysteme 2000), S. 14; bezogen auf den Kommunikationsbegriff, ebenso wie bei STEINMÜLLER, der vom zweiaktigen Vorgang der Übergabe und Aufnahme/Verarbeitung spricht. Vgl. Steinmüller (Informationstechnologie 1993), S. 157 80 Vgl. König, Syben, Heinzl (Anmerkungen 1990), S. 49 81 Vgl. Lehner, Maier (Information 1994), S. 87 82 Vgl. Lehner, Maier (Information 1994), S. 32 u. S. 94 83 In Anlehnung an den Kommunikationsbegriff von SHANNON/WEAVER, den Begründern der Kommunikationstheorie. Vgl. Shannon, Weaver (Theory 1949), S. 12f. 84 Vgl. Steinmüller (Informationstechnologie 1993), S. 208; Gebauer (Unterstützung 1996), S. 108f.; Picot,
27
gesprochen werden. In diesem Fall besteht also eine physische Verbindung zwischen dem
Übertragungskanal und den Hardwaresystemen, auf denen sich die beteiligten
Anwendungssysteme befinden. Über diese Verbindung findet eine - im technischen Sinne -
einwandfreie Kommunikation statt. Weiters können die elektronischen Nachrichten ohne
syntaktische und semantische Fehler automatisiert von den betrieblichen
Anwendungssystemen erzeugt (beim Sender) bzw. verarbeitet (beim Empfänger) werden.
Darüber hinaus erfolgt eine automatisierte Reaktion. Zusammenfassend ist das Ergebnis einer
beidseitigen Integration zwischenbetrieblicher Informationsflüsse demnach die automatisierte
Erstellung von Nachrichten durch die Anwendungssysteme des Senders, die fehlerfreie
Übertragung dieser Nachrichten über einen elektronischen Kanal (Zeichenfluss), die
fehlerfreie Übernahme in die Anwendungssysteme des Empfängers (Datenfluss) sowie die
automatisierte Weiterverarbeitung und gegebenenfalls Reaktion ohne menschliche
Intervention (Informationsfluss). Bei einer einseitigen Integration erfolgen entweder beim
Sender oder beim Empfänger manuelle Eingriffe in den Informationsfluss.
Semiotische Ebene Integrationsebene Integrationsgrad Technik Technische Integration Zeichenfluss Syntaktik Syntaktische Integration Semantik Semantische Integration
Datenfluss
Pragmatik Pragmatische Integration Informationsfluss Tab. 2-5 Integrationsebenen zwischenbetrieblicher Informationsflüsse
An dieser Stelle sei darauf hingewiesen, dass sich der hier dargelegte Begriff einer Integration
zwischenbetrieblicher Informationsflüsse von den in der Literatur häufig verwendeten
Begriffen der zwischenbetrieblichen Integration (ZBI) sowie der Interorganisationssysteme
(IOS) unterscheidet. Unter ZBI wird die Fortführung des Gedankens der innerbetrieblichen
Integration verstanden.85 Darunter fällt neben der Integration der zwischenbetrieblichen
Informationsflüsse nach dem hier vorliegenden Verständnis auch die betriebsübergreifende
Abstimmung von Funktionen und Daten der beteiligten Anwendungssysteme.86 Der
Kopplungs- bzw. Integrationsgrad ist bei einer ZBI demnach höher, als bei einer Integration
zwischenbetrieblicher Informationsflüsse. Unabhängig vom Integrationsgrad ist der IOS-
Reichwald, Wigand (Unternehmung 1996), S. 67 85 Zum Begriff der innerbetrieblichen Integration vgl. Jacob, Becker, Krcmar (Informationssysteme 1991); Mertens, Holzner (Gegenüberstellung 1992); Ferstl, Sinz (Grundlagen 1998), S. 211ff.; Fischer (Informationswirtschaft 1999), S. 93ff. 86 Vgl. Mertens (Integration 1985), S. 81; Fischer (Informationskooperationen 1997), S. 3. PETRI verwendet dafür den Begriff der ‚externen Integration‘. Vgl. Petri (Integration 1990), S. 12
28
Begriff zu betrachten. Mit IOS werden eigenständige (autonome) Anwendungssysteme zur
Unterstützung betriebsübergreifender Aufgaben bezeichnet.87 Beispiele dafür sind Reise-
Reservierungssysteme GALILEO oder AMADEUS.88 Im Gegensatz dazu werden bei einer
Integration zwischenbetrieblicher Informationsflüsse die vorhandenen, nicht-autonomen
Anwendungssysteme zur Unterstützung der jeweils innerbetrieblichen Aufgaben betrachtet,
die in der Regel keine speziellen Funktionen für betriebsübergreifende Aufgaben bereitstellen.
2.4 Nutzeffekte einer Integration zwischenbetrieblicher Informationsflüsse
Die Nutzeffekte einer Integration zwischenbetrieblicher Informationsflüsse wurden in zahl-
reichen Studien nachgewiesen.89 An dieser Stelle unterbleibt daher eine ausführliche
Herleitung und Begründung einzelner Nutzeffekte.
Grundsätzlich lassen sich operative von strategischen Nutzeffekten unterscheiden.90 Operative
Nutzeffekte resultieren aus der Substitution traditioneller Abläufe durch eine elektronische
Abwicklung, d. h. durch die Rationalisierung der Kommunikationsvorgänge.91 Strategische
Nutzeffekte ergeben sich aus der verbesserten Koordination zwischenbetrieblicher Trans-
aktionen sowie der möglichen Öffnung neuer Geschäftsfelder.92
Sowohl operative als auch strategische Nutzeffekte lassen sich zum einen danach einteilen, ob
sie sich auf die Abwicklung der internen Tätigkeiten oder der zwischenbetrieblichen Prozesse
auswirken.93 Zum anderen soll jeder Nutzeffekt einer der Kategorien Zeitvorteil, Kostenvorteil
und qualitativer Vorteil zugeordnet werden. Eine Sammlung beispielhafter Nutzeffekte, die in
der Literatur genannt werden, erfolgt in Tab. 2-6.
87 Vgl. Klein (Interorganisationssysteme 1996), S. 38ff.; Alt (Interorganisationssysteme 1997), S. 99; Scheckenbach (Geschäftsprozeßintegration 1997), S. 72. FISCHER verwendet dafür den Begriff ‚Inter-Enterprise Systems‘. Vgl. Fischer (Informationskooperationen 1997), S. 4; Fischer (Informationswirtschaft 1999), S. 159f. 88 Vgl. Fischer (Informationswirtschaft 1999), S. 160 89 Vgl. Benjamin, de Long, Morton (Data 1990); Petri (Integration 1990), S. 260ff.; Schumann (Abschätzung 1990); Sedran (Wettbewerbsvorteile 1991); Emmelhainz (EDI 1993); Miebach, Schneider (Untersuchung 1994); Neuburger (Data 1994); Linß (Nutzeffekte 1995) 90 Vgl. Schmoll (Handelsverkehr 1994), S. 40f.; Scheckenbach (Geschäftsprozeßintegration 1997), S. 24ff.; Westarp u. a. (Status 1999), S. 1ff. FISCHER unterscheidet analog zwischen Effizienz- und Effektivitätseffekten. Vgl. Fischer (Informationswirtschaft 1999), S. 158 91 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 24.; Fischer (Informationswirtschaft 1999), S. 153f. 92 Vgl. Fischer (Informationswirtschaft 1999), S. 154ff. 93 Vgl. Schumann (Abschätzung 1990), S. 314
29
Quelle Nutzeffekt oper./ strat.
inner./ zb. 1 2 3 4
Schnellere Informationsverfügbarkeit mit kürzeren Reaktionszeiten
oper. inner. X X
Beschleunigte Vorgänge durch direkte Datenübernahme
oper. inner. X X X X
Geringere Übertragungszeiten oper. zb. X X X Verkürzte Durchlaufzeiten oper. zb. X X 24stündige Erreichbarkeit oper. zb. X Schnellere Reaktion auf Markttrends strat. inner. X Reduktion der Wiederbeschaffungszeiten strat. inner.
Zeit-vorteile
Schnellere Marktinformationen strat. zb. X Geringere Lagerbestände, damit weniger Kapitalkosten
oper. inner. X X X
Vermeidung von Doppelarbeit bei der Datenerfassung
oper. inner. X X X
Geringere Bearbeitungskosten oper. inner. X X X Reduktion der Kosten für das Sammeln, Verteilen und Archivieren von Papierdokumenten
oper. inner. X X X
Vermeidung von Doppelarbeit durch Wegfall von Medienbrüchen
oper. zb. X
Reduzierung von Vorgängen oper. zb. X X X Reduzierung der Übertragungskosten oper. zb. X X Beschleunigung von Zahlungen oper. zb. X Höhere Absätze / Umsätze durch neue Leistungsangebote
strat. inner. X X
Vermeidung von Fehlmengen und Abschriften durch Steigerung der Planungs- und Dispositionsicherheit
strat. inner. X
Kosten-/ Ertrags-vorteile
Reduzierung von Transaktionskosten durch verkürzte Distributionskanäle
strat. zb. X
Fehlersenkung bei der Datenerfassung oper. inner. X X Vermeidung von Kommunikationsfehlern oper. zb. X X Aktuellere Daten oper. zb. X X Entlastung des Personals von monotonen Routinearbeiten
strat. inner. X
Bessere Kundenbindung strat. zb. X X X Neue Kooperationsformen möglich strat. zb. X X X
Qualitative Vorteile
Entwicklung neuer Marktformen möglich strat. zb. X X X Quellen: 1 - Schumann (Abschätzung 1990)
2 - Sedran (Wettbewerbsvorteile 1991) 3 - Petri (Integration 1990) 4 - Neuburger (Data 1994)
Tab. 2-6 Nutzeffekte einer Integration zwischenbetrieblicher Informationsflüsse
30
2.5 Integration zwischenbetrieblicher Informationsflüsse als
Gestaltungsaufgabe
Bislang wurde die Integration zwischenbetrieblicher Informationsflüsse in einer statischen
Sichtweise als Zustand betrachtet. Doch ein solcher Zustand integrierter Informationsflüsse ist
nicht per se gegeben. Hinderlich für einen problemlosen zwischenbetrieblichen
Informationsfluss ist vielmehr die Tatsache, dass sich „informationstechnologisch wie auch
organisatorisch [...] hierbei inkompatible Anwendungssysteme in den kooperierenden
Unternehmen gegenüber [stehen, T.S.]“.94 Dafür gibt es mehrere Gründe. Zum einen sind
aufgrund der Arbeitsteilung die unterschiedlichen Branchen und Wertschöpfungsstufen durch
spezifische Strukturen und Aufgaben gekennzeichnet. Die Folge ist eine heterogene
Landschaft von Anwendungssystemen. Zum anderen ist die Heterogenität Ausdruck
funktionierender Märkte für Hard- und Softwarekomponenten für betriebliche Anwendungen
und eines entsprechenden Innovationsdrucks.95 Für einen reibungslosen und effizienten
Informationsfluss gilt es, diese Inkompatibilitäten, die auf allen Integrationsebenen auftreten
können (vgl. Abb. 2.5), auszuräumen. Dieses ist das erklärte Ziel einer Integration
zwischenbetrieblicher Informationsflüsse. Sie wird in diesem Zusammenhang nicht als
beschreib- und beobachtbarer Zustand, sondern als Gestaltungsaufgabe verstanden.
Anw
endu
ngss
yste
m
SENDER
EMPÄNGER
Pragmatische Ebene
Semantische Ebene
Syntaktische Ebene
Anw
endu
ngss
yste
m
Bedeutung der Nachricht verstehen und angemessen reagieren
Bedeutung der Zeichenfolgen verstehen
Erkennen geordneter Zeichenfolgen
Beispiel für Inkompatibilitäten: Heterogene Aktions-/ Reaktionsmuster
Beispiele für Inkompatibilitäten: Heterogene Datendefinitionen, heterogeneIdentifikationsnummern, heterogene Codes
Beispiel für Inkompatibilitäten: Heterogene Zeichensätze, heterogene Datenformate
Technische Ebene
Physische Verbindung der Anwendungssysteme und Übertragen von Zeichen
Beispiele für Inkompatibilitäten: Heterogene Netze, heterogene Protokolle
Abb. 2.5 Inkompatibilitäten bei zwischenbetrieblichen Informationsflüssen
94 Scheckenbach (Geschäftsprozeßintegration 1997), S. 1. Vgl. ähnlich Schmoll (Handelsverkehr 1994), S. 27 95 Vgl. Fischer (MOVE 1999), S. 7
31
Um die im vorhergehenden Abschnitt beschriebenen Nutzeffekte einer Integration erreichen
zu können, müssen verschiedene Maßnahmen an bestehenden zwischenbetrieblichen
Kommunikationsbeziehungen und Informationsflüssen getroffen werden. Diese Maßnahmen
lassen sich jeweils den Integrationsebenen Technik, Syntaktik, Semantik und Pragmatik
zuordnen.
Technische Ebene
Auf Ebene der technischen Integration gilt es, die einwandfreie Übertragung von Zeichen
ohne Fehler im Sinne einer technischen Kommunikation nach SHANNON/WEAVER96 zu
gewährleisten.97 Es sind daher die ersten fünf Ebenen des ISO/OSI-Schichtenmodells98
abzudecken. Zu den Aufgaben gehört danach zum einen die kommunikationstechnische Ver-
knüpfung bzw. Kopplung der unterschiedlichen Anwendungssysteme.99 Es ist also ein
Übertragungsnetz für die zwischenbetriebliche Kommunikation auszuwählen und eine
physische Verbindung zwischen den Hardwaresystemen, auf denen sich die zu integrierenden
Anwendungssysteme befinden, herzustellen. Zum anderen sind die Übertragungsprotokolle
sowie Telekommunikationsdienste festzulegen.100
Für die Übertragung zwischenbetrieblicher Nachrichten können verschiedene Arten von
Netzen genutzt werden. Man spricht hierbei von Fernnetzen bzw. Wide Area Networks
(WANs).101 Zu den wichtigen WANs zählen Telefonnetze, Mobilfunknetze, ISDN,
96 Vgl. Shannon, Weaver (Grundlagen 1976), S. 16ff. 97 Die technische Integration bei HEILMANN umfasst dagegen neben dem „Wiederherstellen einer Einheit im Hardware- und Systemsoftwarebereich“ auch die Normierung des Datenaustausches und damit auch die syntaktische Ebene einer Integration. Vgl. Heilmann (Integration 1989), S. 49. In gänzlich anderem Sinne verwendet LEHNER den Begriff der technologischen Integration. Er fasst darunter „allgemeine Integrationskonzepte, die sich insbesondere auf die Produkttechnologie, Werkstofftechnologie, Konstruktionstechnologie und Produktionstechnologie beziehen.“ Vgl. Lehner (Integration 1994), S. 10 98 Das 1984 veröffentlichte ISO/OSI-Referenzmodell gliedert einen Kommunikationsprozess in sieben Schichten. Dabei entsteht eine horizontale Aufteilung in funktionaler Hinsicht: Schicht 1 - Bitübertragungsschicht (Physical Layer) Schicht 2 - Sicherungsschicht (Data Link Layer) Schicht 3 - Vermittlungsschicht (Network Layer) Schicht 4 - Transportschicht (Transport Layer) Schicht 5 - Kommunikationssteuerungssicht (Session layer) Schicht 6 - Darstellungsschicht (Presentation Layer) Schicht 7 - Anwendungsschicht (Application Layer) Vgl. Schmoll (Handelsverkehr 1994), S. 67ff.; Hansen (Wirtschaftsinformatik 1996), S. 1047ff. 99 Vgl. Krcmar (Integration 1991), S. 8. FISCHER verwendet hierfür den Begriff der Systemkopplung. Vgl. Fischer (Informationswirtschaft 1999), S. 90 100 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 74; dort bezogen auf die Kommunikationsebene einer zwischenbetrieblichen Integration 101 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 90; Fischer (Informationswirtschaft 1999), S. 174
32
Datex-M/ATM, Datex-P, Direktrufnetze102 sowie das Internet.103 Die häufig vorgenommene
Unterscheidung in öffentliche und private Netze104 ist nach der weitgehenden Auflösung des
Telekommunikationsmonopols in den Ländern der europäischen Gemeinschaft nicht mehr
sinnvoll. Die verschiedenen Netze unterscheiden sich durch eine Reihe von Kriterien, wie
beispielsweise das Übertragungsmedium, die verfügbare Bandbreite oder die Art der
Vermittlung (vgl. Tab. 2-7). Die Wahl des Netzes ist von mehreren Bestimmungsfaktoren
einer
zwischenbetrieblichen Integration, wie etwa dem Umfang, dem zeitlichen Anfall sowie der
Dringlichkeit der zu übertragenen Daten, abhängig.105
Netz Merkmal
Telefonnetz Mobilfunk-netz
ISDN Datex-M/ ATM
Datex-P Direktruf Internet
Über-tragungsmedium106
Terrestrisch Nicht terrestrisch
Terrestrisch Terrestrisch Terrestrisch Terres-trisch/ Nicht terrestrisch
Terrestrisch
Bandbreite Bis 56 kBit/s (Modem); Bis 1 Mbit/s (DSL107)
Bis 14 kBit (GSM); Bis 2 Mbit/s (UMTS)
Bis 1,92 Mbit/s
Mehrere hundert Mbit/s
64kBit/s Bis 1,92 Mbit/s
unterschiedlich
Ver-mittlungsart
Leitungsvermittlung
Leitungs- oder Paketvermittlung
Leitungsvermittlung
Paketvermittlung
Paketvermittlung
Leitungsvermittlung
Paketvermittlung
Tab. 2-7 Netze für den zwischenbetrieblichen Informationsaustausch
Zur Nutzung der Netze sind Dienste erforderlich, die den Datentransport steuern.
Grundsätzlich können Basisdienste und höhere bzw. problemorientierte Dienste unterschieden
werden.108 Basisdienste sind Telekommunikationsprotokolle, wie z. B. X.25. Sie decken die
transportorientierten Schichten 1 bis 3 des ISO/OSI-Modells ab. Zu den höheren Diensten
gehören Filetransfer (z. B. FTP, FTAM), E-Mail (z. B. SMTP) oder der Internetdienst WWW
(z. B. HTTP, HTTPS). Diese Dienste sind den Schichten 4 bis 7 des ISO/OSI-Modells
zuzuordnen.
102 Mittlerweile Datendirektverbindungen genannt. Vgl. Hansen (Wirtschaftsinformatik 1996), S. 1082f. 103 Vgl. Hansen (Wirtschaftsinformatik 1996), S. 1067ff. 104 Vgl. beispielsweise Hansen (Wirtschaftsinformatik 1996), S. 1023; Fischer (Informationswirtschaft 1999), S. 174 105 Näheres dazu: vgl. Hansen (Wirtschaftsinformatik 1996), S. 1027f.; Scheckenbach (Geschäftsprozeßintegration 1997), S. 91ff. 106 Unterschieden werden terrestrische (z. B. Kupfer- oder Glasfaserkabel) und nicht terrestrische (z. B. Richt- oder Satellitenfunk) Medien 107 DSL steht für Digital Subscriber Line 108 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 91
33
Die Frage der Zeichencodierung ist ebenfalls in die Ebene der technischen Integration
einzuordnen. Dabei geht es um die Darstellung und Zuordnung von Bitfolgen zu einzelnen
Zeichen. Für textuelle Zeichencodierungen gibt es internationale Standards. Zu den
wichtigsten Standards zählen ASCII, extended ASCII und EBCDIC.109
Werden vom Sender- und Empfängerbetrieb unterschiedliche Netze, Transportprotokolle oder
Zeichencodierungen verwendet, so müssen entsprechende technische Einrichtungen zur
Überbrückung dieser Inkompatibilitäten (z. B. Bridges, Router, Gateways, Switches)110
eingesetzt werden. Diese sollen sicherstellen, dass elektronische Zeichen zwischen den zu
integrierenden Anwendungssystemen fehlerfrei übertragen werden können.
Syntaktische Ebene
Auf der syntaktischen Ebene ist sicherzustellen, dass der Empfänger die übertragenen Zeichen
als korrekte Zeichenfolgen erkennt. Es ist also festzulegen, welche Zeichen verwendet werden
dürfen und welche Zeichen an welcher Stelle stehen. Eine solche Beschreibung der
syntaktischen Struktur einer Nachricht nennt man Nachrichtenschema.
Um beispielsweise das Schema einer textuellen Nachricht bestimmen zu können, wird diese
logisch in einzelne Datenelemente (Datenfelder) untergliedert. Zu jedem Datenelement kann
dessen Länge und Erfordernis sowie die Art der Zeichenfolge angegeben werden (vgl. Tab.
2-8). Die Datenelementlänge kann durch eine bestimmte Stellenanzahl von Zeichen fest
vorgegeben werden oder sie ist variabel. Im letzteren Fall müssen bestimmte Zeichen oder
Zeichenfolgen als Separatoren von Datenelementen eingesetzt werden. Bei der
Datenelementerfordernis sollen Muss- von Kann-Elementen unterschieden werden. Für die
syntaktische Richtigkeit einer Nachricht ist es zwingend erforderlich, dass die Muss-Elemente
vorhanden bzw. gefüllt sind. Kann-Elemente dürfen weggelassen oder nicht gefüllt werden.
Sie beeinträchtigen die syntaktische Korrektheit nicht. Nach Art der Zeichenfolge können
numerische, alphanumerische oder alphabetische Datenelemente unterschieden werden.111
Merkmal Ausprägungen Art der Zeichenfolge Numerisch Alphanumerisch Alphabetisch Datenelementlänge Fest Variabel Datenelementerfordernis Muss-Element Kann-Element
109 Vgl. Ferstl, Sinz (Grundlagen 1998), S. 235ff. 110 Näheres zu den Begriffen Bridges, Router, Gateways, Switches: vgl. Schürmann (Rechnerverbindungsstrukturen 1997), S. 289ff. 111 Vgl. Heinrich, Lehner, Roithmayr (Informationstechnik 1993), S. 189; Mertens u. a. (Grundzüge 1998), S. 57
34
Tab. 2-8 Syntaktische Merkmale von Datenelementen
Nutzen die beteiligten Anwendungssysteme verschiedene Schemata, so sind die Nachrichten
beim Sender oder Empfänger syntaktisch anzupassen bzw. zu konvertieren.
Semantische Ebene
Aufgabe der semantischen Integration ist es, ein gemeinsames Verständnis des Senders und
Empfängers über die inhaltliche Bedeutung von übertragenen Nachrichten und insbesondere
jedes einzelnen Datenelementes sicherzustellen.
Informationsflüsse planen, steuern und kontrollieren die Leistungs- und Zahlungsflüsse
zwischen Betrieben. Inhaltlich müssen sie sich damit auf Gegenstände und Geschehnisse der
realen Welt beziehen (Informationsbezug). Es soll unterschieden werden, ob sich ein
Informationsfluss überwiegend auf einen Leistungsfluss (z. B. Bestellung) oder einen
Zahlungsfluss (z. B. Rechnung) bezieht.112
Anbahnung Vereinbarung Durchführung Marktinfor-mationen
- Produktkatalog - Werbung - Informationen über
Unternehmen und Privatpersonen
- Bondaten - Absatzzahlen - Marktbericht
Geschäfts-verkehrs-informationen
- Anfrage - Ausschreibung
- Angebot - Bestellung - Auftragsbestätigung - Bestelländerung - Konditionen
- Lieferavis - Lieferschein - Rechnung - Zahlungsavis - Mahnung
Technik-informationen
- Ersatzteilkatalog - Zeichnung - Ausschreibungstext
- Produktspezifikation - Zeichnung
- Einbau-/ Montageanleitung
- Transport- u. Lagerinformation
Tab. 2-9 Beispiele für Markt-, Geschäftsverkehrs- und Technikinformationen
Nach dem Informationsfeld können Markt-, Geschäftsverkehrs- und Technikinformationen
unterschieden werden (vgl. Tab. 2-9).113 Marktinformationen geben Aufschluss über das
Leistungsangebot (z. B. Produktkatalog) und die Nachfragesituation auf dem Markt (z. B.
Verkaufszahlen, Absatzprognosen). Geschäftsverkehrsinformationen beziehen sich primär auf
den eigentlichen Leistungs- und Zahlungsfluss und liefern die erforderlichen Angaben zu
deren Initialisierung, Steuerung und Kontrolle. Die Abgrenzung zwischen Markt- und
112 Vgl. Szyperski, Klein (Informationslogistik 1993), S. 189
35
Geschäftsverkehrsinformationen ist nicht immer eindeutig und sicher abhängig von der Phase,
in der die Informationen verwendet werden.114 Technikinformationen beschreiben die
Technologie der Produkte und deren Nutzung. Dies geschieht z. B. in Form von
Konstruktionszeichnungen, Produktspezifikationen, Montageanleitungen oder
Qualitätsberichten.
Informationsbezug und Informationsfeld sagen etwas über die inhaltliche Bedeutung einer
Nachricht als Ganzes aus. Wichtig ist daneben die inhaltliche Bedeutung einzelner
Datenelemente. Dabei sind heterogene Datendefinitionen sowie heterogene
Identifikationssysteme und Codes zu berücksichtigen.
Das Problem heterogener Datendefinitionen besteht darin, dass im Regelfall Datenelemente in
den Anwendungssystemen des Senders und Empfängers unterschiedlich definiert werden. So
kann beispielsweise der Datenwert für einen Wechselkurs bezüglich der Zeitdimension, der
Berechnungsvorschrift, der Maßstabsdimension oder der Begriffsextension unterschiedlich
festgelegt sein (vgl. Tab. 2-10) und entsprechend vom Sender- und Empfängersystem
unterschiedlich interpretiert werden.
Definitionsmerkmale Mögliche Ausprägungen Zeitperiode • Tageskurs
• Monatsmittelkurs • Jahresmittelkurs
Zeitdimension
Zeitpunkt • 12.00 Uhr-Kurs • Börsenschluss-Kurs
Berechnungsvorschrift • Ungewichteter Durchschnittskurs • Gewichteter Durchschnittskurs
Maßstabsdimension • Je 1 Fremdwährungseinheit • je 100 Fremdwährungseinheiten • je 1000 Fremdwährungseinheiten
Inhalt • Geld- oder Briefkurs • Kassa- oder Terminkurs • Devisen- oder Sortenkurs
Ort • Frankfurter Börse • Londoner Börse
Begriffsextension
Umfang • Mit Bankspesen • Ohne Bankspesen
113 Vgl. Fischer (Informationskooperationen 1997), S. 5ff.; Fischer (Informationswirtschaft 1999), S. 162f. 114 Vgl. Abschnitt 2.2. FESTL/SINZ trennen nicht zwischen Markt- und Geschäftsverkehrsinformationen und sprechen zusammenfassend von ‚wirtschaftlichen‘ Informationen bzw. Attributen. Vgl. Ferstl, Sinz (Grundlagen 1998), S. 64
36
Tab. 2-10 Unterschiedliche Datendefinitionen am Beispiel ‚Wechselkurs‘115
Der Bezug zwischen realen Gegenständen und ihrer Repräsentation in Form von Daten wird
von Anwendungssystemen in der Regel durch die Vergabe von eindeutigen
Identifikationsnummern (z. B. für Artikel, Lager, Standorte, Kunden, Lieferanten, etc.)
hergestellt. Probleme bei der Integration zwischenbetrieblicher Informationsflüsse ergeben
sich durch die Verwendung heterogener Identifikationssysteme. Ähnlich sieht es bei der
Übertragung codierter Daten aus. Hierbei werden bestimmte Codes zur Darstellung von
betriebswirtschaftlichen Sachverhalten (z. B. Lieferbedingungen, Ländercodes,
Mengeneinheiten, etc.) verwendet. In der Regel werden von unterschiedlichen
Anwendungssystemen unterschiedliche Codes verwendet.
Aufgrund der angesprochenen Probleme sind eingehende Nachrichten, neben einer
syntaktischen Anpassung, einer Reihe von semantischen Prüfungen und Korrekturen zu
unterziehen, bevor sie in das Anwendungssystem beim Empfänger übernommen werden
können. Nur so kann eine semantische Integration gewährleistet werden.
Pragmatische Ebene
Die technische, syntaktische und semantische Integration stellen sicher, dass Nachrichten
elektronisch gesendet und in das Anwendungssystem des Empfängers aufgenommen werden
können. Aus den übersendeten Nachrichten leiten sich Handlungen und Reaktionen im
Rahmen einer zwischenbetrieblichen Transaktion ab. Eine Weiterverarbeitung der
Nachrichten in dem Sinne, dass die erforderlichen Handlungen und Reaktionen automatisiert
durchgeführt oder zumindest angestoßen werden, ist Aufgabe der pragmatischen Integration.
Wichtig ist die Klärung der Frage, zu welchen Zwecken Informationsflüsse eingesetzt werden.
Der Zweck kann dabei sowohl aus Sendersicht als auch aus Empfängersicht betrachtet
werden.
Zunächst wird untersucht, welche unterschiedlichen Absichten ein Sender von Informationen
verfolgt. Dazu wird das Phasenmodell für zwischenbetriebliche Transaktionen herangezogen.
In der Anbahnungsphase ist davon auszugehen, dass noch keine Geschäftsbeziehung zwischen
möglichen Handelspartnern besteht. In dieser Phase dienen Informationen dazu, eine solche
Leistungsbeziehung anzubahnen und aufzubauen. Diese Bemühungen können vom
Nachfrager ausgehen, der potentiellen Partnern seinen Bedarf bekannt gibt (z. B. durch
115 Beispiel entnommen aus Fischer (Datenmanagement 1992), S. 102
37
Anfragen, Ausschreibungen). Andererseits stellt der Anbieter Informationen über sein
Angebot bereit
(z. B. durch Werbung, Kataloge). Mit den Informationsflüssen wird in dieser Phase ein
anbahnender Zweck verfolgt.
Haben sich zwei Handelspartner gefunden oder besteht bereits eine Geschäftsbeziehung,
werden in der Vereinbarungsphase die Bedingungen des Leistungsaustausches ausgehandelt.
Die Informationsflüsse dienen der Initialisierung des Leistungsflusses, daher soll von
initialisierenden Informationsflüssen gesprochen werden.116
Nach Abschluss der Vereinbarungsphase haben sich die Handelspartner vertraglich auf einen Leistungsaustausch geeinigt. Die Informationsflüsse der Durchführungsphase dienen nun der organisatorischen und operativen Abwicklung des Leistungs- und Zahlungsaustausches. Hierbei werden zum einen die Leistungsflüsse hinsichtlich Zeit, Ort und Menge gezielt durch Informationen präzisiert und gesteuert (z. B. durch Abrufaufträge oder Lieferavise). Zum anderen veranlassen die Informationsflüsse Zahlungsflüsse und legen sie sowohl zeitlich als auch örtlich (z. B. durch Rechnungen) fest. Es sollen daher leistungssteuernde und zahlungssteuernde Informationsflüsse unterschieden werden. Durch dokumentierende Informationsflüsse, die die Leistungs- und Zahlungsflüsse begleiten, soll die Einhaltung der Vereinbarungen nachvollzogen werden können.117 Sie betreffen bestimmte Leistungs- oder Zahlungsflüsse, üben aber keinen unmittelbaren Einfluss auf sie aus (z. B. Lieferscheine). Sie können als ‚Meldungen‘ oder ‚Vollzugsinformationen‘ verstanden werden.118
Phase Phasenabhängig Phasenunabhängig Anbahnung Anbahnend
Vereinbarung Initialisierend
Durchführung Leistungssteuernd Zahlungssteuernd Dokumentierend
Allgemein
Informierend
Tab. 2-11 Zweck zwischenbetrieblicher Informationsflüsse aus Sendersicht119
116 SCHECKENBACH verwendet dafür den Begriff ‚geschäftsprozeßinitiierend‘. Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 204 117 Damit wird eine größere Differenzierung vorgenommen, als sie teilweise in der Literatur zu finden ist. So fasst KLEIN unter Informationen mit abwicklungs- bzw. transaktionsorientierten Zwecken jene Informationsflüsse, die den Leistungsfluss begleiten, koordinieren, d. h. steuern, sowie dokumentieren. Vgl. Klein (Stellenwert 1992), S. 202f. SCHECKENBACH spricht vom ‚geschäftsprozeßbeeinflussenden‘ und ‚geschäftsprozessbegleitenden‘ Charakter von Nachrichten. Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 204f. Diese Unterscheidung kann nicht nachvollzogen werden, da auch die Nachrichtentypen, die als Beispiele für einen geschäftsprozessbegleitenden Charakter genannt werden, wie z. B. Rechnung oder Zahlungsauftrag, koordinierend und steuernd auf die operative Abwicklung der Leistungs- und Zahlungsflüsse einwirken. 118 Vgl. Feierabend (Beitrag 1980), S. 58 119 SCHECKENBACH spricht vom ‚betriebswirtschaftlichen Charakter von Nachrichtentypen‘ und meint damit die
38
Allgemein informierende Informationsflüsse lassen sich nicht auf einen bestimmten
Leistungsaustausch beziehen. Sie unterstützen eine bestehende Geschäftsbeziehung durch die
Aktualisierung von Rahmendaten (z. B. Partnerstammdaten, Artikelstammdaten).120 Mitunter
werden sie als Service-Informationen bezeichnet.121
Auch zur Beantwortung der Frage, zu welchem Zweck ein Empfänger von Informationen
diese verwendet, soll das Phasenmodell für zwischenbetriebliche Transaktionen herangezogen
werden. In der Anbahnungsphase werden Informationen über Produkte, mögliche
Handelspartner und Mitbewerber gesammelt. Die Informationen werden ausgewertet und in
der Vereinbarungsphase werden Verhandlungen mit einem Handelspartner aufgenommen.
Schließlich wird über einen Vertragsabschluss entschieden. Die in diesen beiden Phasen
erhaltenen Informationen dienen also dazu, die Entscheidung über einen Leistungsaustausch
herbeizuführen und zu unterstützen. Dieses entspricht dem Informationsverständnis der
Entscheidungstheorie, die Information nach WITTMANN als zweckorientiertes Wissen122 in
einer konkreten Entscheidungssituation versteht.123 Es soll daher von
entscheidungsunterstützenden Informationsflüssen gesprochen werden.124
Der aus dem Abschluss der Vereinbarungsphase resultierende Auftrag sowie die während der
Durchführungsphase erhaltenen Informationen, die die Leistungs- und Zahlungsflüsse direkt
beeinflussen (z. B. Lieferabruf, Rechnung), werden zur Disposition der betrieblichen
Ressourcen beim Empfänger herangezogen. Es handelt sich dabei um disponierende
Informationsflüsse, die den Leistungs- bzw. Zahlungsflüssen vorgelagert sind.125
Die begleitenden und nachgelagerten Informationen der Leistungs- und Zahlungsflüsse
werden zur Überwachung über die Einhaltung der Vereinbarungen herangezogen und sollen
daher als kontrollierende Informationsflüsse bezeichnet werden.
wirtschaftliche Bedeutung von bestimmten Informationsflüssen innerhalb einer zwischenbetrieblichen Leistungsbeziehung. Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 203ff. Der betriebswirtschaftliche Charakter entspricht dem hier untersuchten Zweck von Informationsflüssen aus Sendersicht. 120 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 207 121 Vgl. Feierabend (Beitrag 1980), S. 58. KLEIN spricht im Zusammenhang von Zwecken der Informationen von einer Serviceorientierung. Vgl. Klein (Stellenwert 1992), S. 203f. 122 Vgl. Wittmann (Unternehmung 1959), S. 14 123 Vgl. Lehner, Maier (Information 1994), S. 22f. 124 KLEIN spricht im Zusammenhang von Zwecken der Informationen von einer Entscheidungsorientierung. Vgl. Klein (Stellenwert 1992), S. 203. Eine ähnliche Sichtweise wird eingenommen, wenn von Planungsinformationen gesprochen wird. Vgl. Feierabend (Beitrag 1980), S. 59 125 Vgl. Feierabend (Beitrag 1980), S. 58. Dort wird von ‚dispositiven Informationen‘ gesprochen.
39
Allgemein informierende Informationsflüsse ohne direkten Bezug auf einen bestimmten
Leistungsaustausch aktualisieren den Wissensstand des Empfängers über die Produkte und
Geschäftspartner.
Phase Phasenabhängig phasenunabhängig Anbahnung
Vereinbarung
Entscheidungsunterstützend
Allgemein Disponierend informierend
Durchführung Kontrollierend
Tab. 2-12 Zweck zwischenbetrieblicher Informationsflüsse aus Empfängersicht
In Anlehnung an SCHECKENBACH soll unabhängig von den Phasen einer
zwischenbetrieblichen Transaktion die Unterscheidung in primäre und sekundäre
Informationsflüsse vorgenommen werden.126 Der Sender von primären Informationsflüssen
erwartet eine unmittelbare Reaktion des Empfängers. Die Reaktion kann in Form eines
Informationsrückflusses (z. B. Angebot auf eine Anfrage) oder einer Leistung (z. B.
Warenlieferung auf eine Bestellung) erfolgen. Primäre Informationsflüsse beeinflussen direkt
den Ablauf einer zwischenbetrieblichen Transaktion. Sekundäre Informationsflüsse dagegen
nehmen keinen unmittelbaren Einfluss und dienen lediglich der Überwachung einer
Transaktion (z. B. Liefermeldung) oder sind transaktionsunabhängig (z. B. Stammdaten).
Aufgabe der pragmatischen Integration ist es, die zwischenbetrieblichen Aktions- und
Reaktionsmuster der beteiligten Anwendungssysteme festzulegen und aufeinander
abzustimmen. Der Geschäftsablauf oder ein bestimmter Zeitpunkt veranlassen ein
Sendersystem, eine Nachricht für einen bestimmten Zweck zu erzeugen und zu versenden
(Aktionsmuster). Auf einige Nachrichten wird eine unmittelbare Reaktion in Form eines
Informationsrückflusses erwartet. Diese Erwartung ist vom Empfängersystem zu erkennen
und durch eine angemessene Reaktion zu erfüllen (Reaktionsmuster).
Effektive und effiziente Gestaltung
Die Integration zwischenbetrieblicher Informationsflüsse wurde in diesem Abschnitt als
Gestaltungsaufgabe vorgestellt. Ihr Ziel sollte es sein, die zwischenbetrieblichen
Informationsflüsse effektiv und effizient zu gestalten. Effektiv heißt, dass Integrationslösungen
mit einem hohen Integrationsgrad erreicht werden sollen. Im Idealfall erfolgt eine vollständige
40
Integration sowohl auf der technischen, der syntaktischen, der semantischen als auch auf der
pragmatischen Ebene. Eine effiziente Gestaltung umfasst eine kostengünstige und schnelle
Integration zwischenbetrieblicher Informationsflüsse.
Ein Betrieb steht mit zahlreichen anderen Betrieben aus unterschiedlichen Branchen in einer
Geschäftsbeziehung.127 Daher ist bei der Gestaltung zwischenbetrieblicher Informationsflüsse
darauf zu achten, dass die angestrebten Integrationslösungen eine hohe Einsatzbreite
aufweisen und keine Speziallösungen für bestimmte zwischenbetriebliche Transaktionen oder
Informationsflüsse darstellen. Andernfalls müssten viele verschiedene Lösungen parallel
aufgebaut und gepflegt werden. Damit verbunden wären zeitaufwendige bilaterale
Absprachen, die hohe Kosten verursachen. Darüber hinaus sollten aus Gründen der Effizienz
Integrationslösungen mit einem simplen Aufbau und einer einfachen Implementierung
vorgesehen werden.
Die Integration zwischenbetrieblicher Informationsflüsse ist kein einmaliger Vorgang,
sondern ständigen geschäftlichen, organisatorischen und technischen Änderungen
unterworfen.128 Inhaltliche Anforderungen an die Informationsflüsse können sich ändern oder
neu hinzukommen (z. B. Herstellernachweis beim Fleischvertrieb). Es werden neue
Geschäftsbeziehungen zu Betrieben aufgebaut, andere Geschäftspartner fallen weg. Jedesmal
sind die Informationsflüsse erneut aufeinander abzustimmen und zu integrieren.
Integrationslösungen dürfen daher nicht auf langfristig bestehende Geschäftsbeziehungen
ausgerichtet sein, sondern müssen flexibel und schnell an veränderte Rahmenbedingungen
angepasst und erweitert werden können. Technologische Fortschritte bewirken häufige
Änderungen oder den Austausch vorhandener Anwendungssysteme sowie Teile von ihnen.
Anzustreben sind daher möglichst implementierungsunabhängige Integrationslösungen, die
entsprechend schnell an neue technologische Entwicklungen angepasst werden können.
2.6 Ansätze zur Integration zwischenbetrieblicher Informationsflüsse
2.6.1 Klassisches EDI
Seit mehr als zwei Jahrzehnten wird von Unternehmen und Behörden, gleich ob in einem
primären oder sekundären Wertschöpfungsfluss, der elektronische Austausch von Daten, der
126 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 203ff. Dort bezogen auf EDI-Nachrichtentypen. 127 Vgl. Petri (Integration 1990), S. 57; Fischer (Informationswirtschaft 1999), S. 152
41
hier als klassisches EDI bezeichnet werden soll, weltweit praktiziert. EDI steht für ‚Electronic
Data Interchange‘. Darunter wird der papierlose Austausch von strukturierten Geschäftsdaten,
wie Bestellungen, Rechnungen, etc., von Anwendungssystem zu Anwendungssystem über
einen elektronischen Kanal verstanden.129 Die Möglichkeit zur automatisierten Übernahme der
gesendeten Nachrichten in das Anwendungssystem beim Empfänger ohne menschliches
Eingreifen ist dabei ein wesentliches Kennzeichen. Der Form nach handelt es sich also
grundsätzlich um eine beidseitige Integration zwischenbetrieblicher Informationsflüsse.130
Beim klassischen EDI werden mittels eines Konverters die Daten des Senders in ein
(standardisiertes) Zwischenformat umgesetzt (konvertiert), an den Empfänger elektronisch
übertragen und dort umgekehrt vom Zwischenformat in dessen Inhouseformat konvertiert
(vgl. Abb. 2.6).
Empfängerbetrieb
Anwendungssystem
Inhouse-Format EDI-Konverter
EDI-Format
Anwendungssystem
Inhouse-FormatEDI-Konverter
Senderbetrieb
VAN
Abb. 2.6 Aufbau einer klassischen EDI-Lösung131
Technische Integration
Beim klassischen EDI wird sowohl die direkte als auch die indirekte Kopplung von
Anwendungssystemen praktiziert. In der EDI-Terminologie wird in der Regel von Point-to-
Point-Verbindungen und Store-and-Forward-Verbindungen132 gesprochen.133 Bei Point-to-
Point-Verbindungen kommunizieren die Teilnehmer zeitgleich (synchron) über eine direkte
Verbindung miteinander. Bei einer Store-and-Forward-Verbindung erfolgt die
Kommunikation über eine zwischengeschaltete Vermittlungsstelle, welche die Nachrichten
128 Vgl. Hirschmann (Gestaltung 1998), S. 42; Fischer (MOVE 1999), S. 6ff. 129 Vgl. beispielsweise Deutsch (Data 1993), S. 118; Fischer (Datenmodellierung 1993), S. 241; Schmoll (Handelsverkehr 1994), S. 15; Steffen (XML/EDI 2001), S. 1. Eine allgemein gültige Definition des Begriffes ‚EDI‘ liegt bislang nicht vor. Vgl. Schmoll (Handelsverkehr 1994), S. 15; Brehm (Management 1997), S. 3 130 Mit EDI-Kleinsystemen (vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 135ff.) und WebEDI (vgl. DEDIG (WebEDI 1999)) gibt es auch EDI-Formen, die eine einseitige Integration zwischenbetrieblicher Informationsflüsse darstellen. Sie sind allerdings nicht dem klassischen EDI zuzurechnen. 131 Vgl. Zbornik (Märkte 1996), S. 83 132 Auch ‚Mailbox-Kommunikation‘. Vgl. Fischer (Informationswirtschaft 1999), S. 176 133 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 96; Fischer (Informationswirtschaft 1999), S. 175f.
42
speichert, verteilt und möglicherweise inhaltliche Funktionen wahrnimmt.134 Damit wird ein
zeitversetztes (asynchrones) Senden und Empfangen zwischenbetrieblicher Nachrichten
möglich.
Im Rahmen von EDI werden grundsätzlich für beide Kopplungsformen sowohl Basisdienste
als auch höhere Dienste (vgl. Abschnitt 2.5) in Anspruch genommen. Über die Basis- und
höheren Dienste hinaus werden häufig im Falle einer indirekten Kopplung weitere Dienste,
sogenannte Mehrwertdienste (MWD) oder auch Value Added Networks (VANs), in Anspruch
genommen.135 Nach dem Umfang können netznahe und anwendungsorientierte
Mehrwertdienste unterschieden werden (vgl. Tab. 2-13).136
Netznahe MWD erweitern die Telekommunikationsdienste um besondere
Leistungsmerkmale, wie beispielsweise internationale Verfügbarkeit, Verschlüsselung von
Nachrichten oder eine besondere Art der Gebührenabrechnung. Zu den netznahen MWD
gehört auch die Bereitstellung eines Virtual Private Networks (VPN). Anwendungsorientierte
MWD gehen über die reine Übermittlung von Daten hinaus. Dabei soll weiter zwischen
generischen und spezifischen Diensten unterschieden werden.137 Generische MWD sind
standardisierbare Leistungsangebote, wie z. B. Mailing-Services. Spezifische MWD gehen
über die technische Ebene hinaus und besitzen einen unmittelbaren Lösungscharakter, wie
beispielsweise die Konvertierung von Nachrichtenformaten oder eine Sendungsverfolgung.
Mehrwertdienst Beispiele Netznah • Bereitstellung flexibler Übertragungskapazitäten
• Verschlüsselung • Art der Gebührenabrechnung • Bereitstellung eines Virtual Private Networks (VPN)
Generisch • Mailing (Puffern, Speichern, Verteilen von Nachrichten) • Carrier-Clearing (Umsetzung verschiedener
Telekommunikationsdienste und -protokolle
Anwendungs- orientiert
Spezifisch
• Daten-Clearing (Format-Konvertierung) • Sendungsverfolgung
Tab. 2-13 Mehrwertdienste
134 Vgl. Fischer (Informationswirtschaft 1999), S. 176 135 Vgl. Fischer (Informationswirtschaft 1999), S. 175 136 Vgl. Hansen (Wirtschaftsinformatik 1996), S. 318 137 Diese Gliederung der MWD entspricht zwar inhaltlich der von SCHECKENBACH vorgenommenen Unterscheidung, weicht aber begrifflich davon ab. Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 102ff.
43
Werden vom Sender- und Empfängerbetrieb unterschiedliche Netze oder Transportprotokolle
verwendet, so bieten Mehrwertdienste entsprechende Gateways zur Überbrückung und
kommunikationstechnischen Integration an.
Syntaktische Integration
Die Abstimmung über das Format bzw. die Syntax der auszutauschenden Nachrichten kann in
bilateralen Vereinbarungen zwischen den beteiligten Betrieben erfolgen. Dabei kann ein
starrer Aufbau mit festen Datei- und Datenelementlängen festgelegt werden. Tatsächlich
wurden in den EDI-Anfängen in den 60er Jahren solche proprietären Austauschformate, die
an den individuellen Informationsbedürfnissen der beteiligten Anwendungssysteme
ausgerichtet waren, vereinbart.138
Der große Nachteil bilateraler Vereinbarungen aus Sicht eines Betriebes ist, dass sie für jeden
Geschäftspartner, mit dem elektronisch kommuniziert werden soll, neu geschlossen werden
müssen. Da dies äußerst aufwendig und unpraktikabel ist, wurden Standards139 für
zwischenbetriebliche Geschäftsnachrichten entwickelt (vgl. Tab. 2-14).
Zunächst wurden von großen Firmen (z. B. VW, Siemens) betriebsbezogene Standards
eingeführt. Bereits in den 70er und 80er Jahren sind Verbände und
Unternehmenszusammenschlüsse dazu übergegangen, für die jeweilige Gruppe bzw. Branche
zumeist regional begrenzte Standards zu entwickeln. Beispiele dafür sind ODETTE
(Automobilindustrie, Europa) oder SEDAS (Konsumgüter, Deutschland). Danach wurden
branchenunabhängige Standards entwickelt. Als ein solcher Standard ist in Nordamerika
ANSI X12 am weitesten verbreitet. Seit Anfang der achtziger Jahre wurde EDIFACT
(Electronic Data Interchange for Administration, Commerce and Transport) mit dem Ziel
entwickelt, einen weltweit gültigen, branchenneutralen EDI-Standard zu schaffen, der
mittlerweile zunehmend Verbreitung findet.140
138 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 111f. 139 Eine begriffliche Differenzierung zwischen Normen, die von nationalen bzw. internationalen Gremien verabschiedet wurden, und von bestimmten Anwendergruppen definierten Standards, die eine weite Verbreitung aufweisen (‚Industriestandard‘, ‚Quasi-Standard‘), wird im folgenden nicht vorgenommen. 140 Eine Befragung im Jahre 1998 unter 130 Unternehmen in Deutschland und 76 Unternehmen in den USA, die jeweils EDI-Technologie einsetzen, ergab folgende Ergebnisse (vgl. Westarp u. a. (Status 1999)): EDIFACT ist der am weitesten verbreitetste EDI Standard in Deutschland. Nahezu 40 % der befragten Unternehmen setzen ihn ein. Andere Standards folgen mit einigem Abstand. Etwa 11 % nutzen VDA, 6 % nutzen SEDAS, 5 % nutzen SWIFT, 3 % nutzen ODETTE, nur 2 % nutzen ANSI X12, und etwa 1 % nutzen DAKOSY. Während in Europa die Vielfalt der genutzten Standards sehr hoch ist, findet man diese Heterogenität in den USA nicht vor. Der führende EDI Standard in den USA ist ANSI X12 mit einer Verbreitung von mehr als 48 %, gefolgt von
44
National International Branchenspezifisch • VDA (Automobilindustrie,
Deutschland) • SEDAS (Konsumgüter,
Deutschland) • DAKOSY (Transport,
Deutschland)
• ODETTE (Automobilindustrie, Europa)
• SWIFT (Banken) • EDIFACT-Subsets (div.
Branchen) Branchenübergreifend • TRADACOM (Handel,
Großbritannien) • ANSI X12 (USA)
• EDIFACT
Tab. 2-14 EDI-Nachrichtenstandards141
Der große Umfang von EDIFACT hat einzelne Branchen und Unternehmen dazu bewegt,
eigene Untermengen, sogenannte EDIFACT-Subsets, zu bilden (vgl. Tab. 2-15).142 Diese sind
zwar EDIFACT-konform, aber vom Umfang her auf die branchenspezifischen Belange
reduziert, d. h. sie berücksichtigen branchenspezifische Besonderheiten wie beispielsweise die
EAN-Nummerierung in der Konsumgüterbranche oder die Fortschrittszahlenlogik in der
Automobilindustrie.143
EDIFACT-Subset Branche EANCOM • Konsumgüter
• Bau- und Heimwerkerbedarf • Schmuck- und Uhren
EDIFICE • Elektroindustrie und -großhandel EDIFURN • Möbel EDITEX • Textil EDIBDB • Baustoffe CEFIC • Chemische Industrie Tab. 2-15 Beispiele für EDIFACT-Subsets
In den Spezifikationen der Standards wird das syntaktische Format für Nachrichten festgelegt.
Die frühen branchenspezifischen Standards wie SEDAS oder VDA sind durch starre
Nachrichtenstrukturen144 sowie feste Satz- und Feldlängen gekennzeichnet. Die verschiedenen
Nachrichtentypen werden durch einfache Verzeichnisse von Datenelementen beschrieben,
welche syntaktische Vorgaben (Zeichensatz, Feldlänge) zu jedem Datenelement enthalten.
Charakteristisch für ODETTE, ANSI X12 oder den international gültigen, branchenneutralen
EDIFACT mit 24 %. Nur zwei der befragten Unternehmen aus den USA nutzen SWIFT bzw. TRADACOMS. 141 Vgl. Zbornik (Märkte 1996), S. 84 142 Vgl. Deutsch (Data 1993), S. 120 143 Vgl. Deutsch (Data 1993), S. 118 144 Jedes Datenelement ist ein Muss-Element, d. h. in einer Nachricht müssen alle Datenelemente vorhanden sein
45
EDIFACT-Standard sind dagegen variable Strukturen hinsichtlich der Satz- und Feldlängen
sowie des Nachrichtenaufbaus. Dies soll am Beispiel EDIFACT kurz erläutert werden.
EDIFACT umfasst mehrere Verzeichnisse (directories), u. a.
• ein Verzeichnis für einzelne Datenelemente (Datenfelder) wie Bestellnummer, Name des
Bestellers, einzelne Daten zu einer Bestellung;
• ein Verzeichnis für Segmente, d. h. Zusammenfassungen der Datenelemente zu
wiederholbaren logischen Datengruppen wie beispielsweise Adressen, Artikelpositionen;
• ein Verzeichnis für Nachrichtentypen, d. h. Zusammenfassungen einzelner Datensegmente
zu Nachrichten wie z. B. einer Bestellung.
EDIFACT umfasst im weiteren syntaktische Regeln, nach denen sich Datenelemente zu
Segmenten und diese zu Nachrichten zusammenfügen lassen. Zum einen ist in den EDIFACT-
Syntaxregeln hinterlegt, welche Datenelemente in welchen Segmenten und Nachrichtentypen
enthalten sein dürfen. Dabei können Kann- und Muss-Elemente unterschieden werden. Zum
anderen wird für jedes Datenelement eine maximale Länge vorgegeben. Im weiteren arbeiten
die Regeln mit einem System verschiedener Trennzeichen, die einen variablen Aufbau einer
Nachricht zulassen. So werden die einzelnen Teile einer EDIFACT-Nachricht durch
verschiedene Trennzeichen voneinander getrennt. Ist in einer Nachricht für ein Kann-Element
kein Inhalt vorhanden, wird nur das Trennzeichen gesetzt. Ebenso müssen nicht die für die
Datenelemente maximal vorgesehenen Stellen gefüllt werden. Auf diese Weise ergeben sich
variable Feld- und Satzlängen und ein flexibler Aufbau für Nachrichten vom gleichen Typ.
Semantische Integration
Durch EDI-Standards können die syntaktischen Formate einer Nachricht und deren
Datenelemente präzise festgelegt werden. Schwierigkeiten bereitet jedoch der semantische
Inhalt. In der Regel werden mit EDI-Nachrichten nur die Daten selbst übertragen, nicht aber
deren Beschreibungen. Unklar ist also, wie die übertragenen Daten interpretiert werden sollen.
Dies sollte in den EDI-Standards festgelegt werden. Allerdings erfolgt die Spezifikation der
meisten Standards durch einfache Verzeichnisse von Datenelementen, bei denen häufig nur
die Bezeichnung einen Hinweis auf deren semantische Bedeutung gibt. Eine exakte Definition
und ausführliche Erläuterung unterbleibt in den meisten Fällen. Eine Ausnahme bildet dabei
der EDIFACT-Standard. Er erlaubt durch die Verwendung von Qualifier und Codes, die
und mit Daten gefüllt werden.
46
semantische Bedeutung bzw. Interpretationsvorschrift von Datenelementen in Nachrichten zu
übertragen.
Qualifier geben Datenelementen und unter Umständen ganzen Segmenten eine bestimmte
inhaltliche Bedeutung. Hierzu werden sie diesen voran- oder nachgestellt. So wird
beispielsweise aus dem Datenelement „Datum“ (Datenelement-Nr. 2001) durch ein
Datumsqualifier (Datenelement Nr. 2005) ein „Bestell-“, „Liefer-“ oder „Rechnungsdatum“.
Die möglichen Ausprägungen eines Qualifiers sind dabei im EDIFACT-Regelwerk hinterlegt.
Neben Qualifiern bieten standardisierte Codes die Möglichkeit, die semantische Interpretation
eines Datenelements innerhalb von EDIFACT-Nachrichten anzugeben. Der Wertebereich
eines Datenelementes kann entweder frei belegbar oder codiert sein. Bei codierten
Datenelementen ist der Wertebereich durch eine Liste der erlaubten Codes exakt
abgeschlossen. Bestandteil des EDIFACT-Regelwerkes ist ein Verzeichnis mit
standardisierten Codelisten (z. B. für Ländercodes, Transport- und Zahlungsbedingungen,
Mengeneinheiten, Währungen etc.).
Der durch Qualifier und standardisierte Codes erzielte Vorteil von EDIFACT wird durch
folgenden Umstand wieder aufgehoben. Ein bestimmtes Datenelement ist aus syntaktischer
Sicht an jeder Stelle einer EDIFACT-Nachricht gültig, ist aber aus semantischer Sicht nicht
überall sinnvoll (z. B. Rechnungsdatum in einer Bestellung). Die sinnvolle Verwendung von
Datenelementen wird in sogenannten Message Implementation Guides (MIG) festgehalten.
Welcher Qualifier oder Code in welcher Nachricht an welcher Stelle erlaubt ist, wird ebenfalls
in den MIG festgelegt. Für jeden Nachrichtentyp eines EDIFACT-Subsets gibt es einen
speziellen MIG. Unter Umständen legen einzelne Betriebe eigene MIG fest. Dies hat zur
Folge, dass bei Aufnahme einer elektronischen Geschäftsbeziehung grundsätzlich bilaterale
Vereinbarungen über die MIG erforderlich sind.
Um dem Problem heterogener Identifikationssysteme (vgl. Abschnitt 2.5) zu begegnen,
wurden im Rahmen des klassischen EDI von verschiedenen Normungsgremien standardisierte
Nummerierungssysteme zur Identifikation von Gütern (EAN, UPC), Versandeinheiten (NVE)
und Betrieben (bbn) bzw. Lokationen145 (ILN) entwickelt (vgl. Tab. 2-16). Die Vergabe von
145 „Unter Lokationen versteht man alles, was adressiert werden kann, beispielsweise Unternehmen, Abteilungen, Räume, Produktionsstätten, Regale, Lieferorte, EDI-Netzwerkadressen usw.“. Centrale für Coorganisation (EANCOM 1999)
47
EAN bzw. UPC erfolgt bislang nur für hinreichend bekannte und standardisierbare Güter.146
Zur eindeutigen Identifikation von nicht oder nur bedingt standardisierbaren Gütern ohne
bilaterale Absprachen eignet sich die EAN bzw. der UPC nicht.
Identifikationsnummer Kennzeichen Europäische Artikelnummer (EAN)
Europaweit gültige 13-stellige Nummer, davon • 2 Stellen Ländercode • 5 Stellen Herstellernummer (in Deutschland bbn) • 5 Stellen individuelle Artikelnummer des Herstellers • 1 Stelle Prüfziffer
Universal Product Code (UPC)
In Nordamerika gültige 12-stellige Nummer, davon • 5 Stellen Herstellernummer • 6 Stellen individuelle Artikelnummer des Herstellers • 1 Stelle Prüfziffer
Nummer der Versandeinheit (NVE)
Europaweit gültige 18-stellige Nummer, davon • 2 Stellen Anwendungskennziffer • 1 Stelle Verpackungskennzeichen • 5 Stellen BBN des Versenders • 9 Stellen Nr. der Versandeinheit • 1 Stelle Prüfziffer
Bundeseinheitliche Betriebsnummer (bbn)
Deutschlandweit gültige, 5-stellige Nummer
Internationale Lokationsnummer (ILN)
International gültige 13-stellige Nummer, davon • 12 Stellen Lokationsnummer • 1 Stelle Prüfziffer
Tab. 2-16 Standardisierte Identifikationsnummern147
Dem Problem der heterogenen Datendefinitionen (vgl. Abschnitt 2.5) widmete sich das Basic
Semantic Register (BSR) Projekt.148 Es wurde Mitte der 90er Jahre von mehreren Gruppen
unter der Leitung der ISO durchgeführt. Ziel war es, ein international gültiges Verzeichnis von
standardisierten, eindeutig spezifizierten Datenelementen aufzubauen. Das BSR soll für
folgende Zwecke verwendet werden:
• bei der Entwicklung von neuen Informationssystemen für die elektronische
Kommunikation zwischen Geschäftspartnern;
• zum Abgleich und als gemeinsame Basis für vorhandene EDI-Standards;
146 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 120 147 Erweiterte Fassung von Fischer (Informationswirtschaft 1999), S. 172 148 Vgl. ISO (Rules 1998)
48
• als Input für Standardisierungsbemühungen zur Integration zwischenbetrieblicher
Informationsflüsse wie beispielsweise Open-EDI.149
Das BSR verfolgt den Ansatz, Datenelemente, die im Zusammenhang eines
zwischenbetrieblichen Informationsaustausches relevant erscheinen, hinsichtlich ihrer
semantischen Inhalte zu standardisieren. Dabei wurden vorhandene EDI-Standards150 und
deren Datenelemente analysiert und semantisch präzisiert. Die drei wesentlichen Elemente des
BSR‘s sind
• semantic components, d. h. ein mehrsprachiges Kontrollvokabular zur Bildung von
Datenelementbezeichnungen,
• basic semantic units (BSUs), d. h. standardisierte, semantisch präzise bezeichnete
Datenelemente sowie
• bridges, d. h. Überführungsregeln zwischen BSUs im BSR und deren entsprechenden
Datenelemente in anderen Standards, wie z. B. EDIFACT oder ANSI X12.
Obwohl das BSR inzwischen als verabschiedete Norm vorliegt, sind dem Autor keine
Anwendungsfälle bekannt, in denen es im praktischen Einsatz ist.
Pragmatische Integration
In klassischen EDI-Standards finden pragmatische Integrationsaspekte bislang kaum
Berücksichtigung. Die Aktions- und Reaktionsmuster beruhen vielmehr auf allgemein
akzeptierten und verbindlichen Geschäftspraktiken oder müssen bilateral vereinbart werden.151
Pragmatische Erweiterungen erfuhr das klassische EDI allerdings durch Ansätze wie Open-
EDI und Object Oriented-EDI (OO-EDI).152 Im Zentrum stehen dort nicht mehr
syntaxorientierte Datenelementverzeichnisse, sondern fachkonzeptuelle Beschreibungen
zwischenbetrieblicher Transaktionen. „[...] that shifts the focus on EDI standards from the
interchange file to the information contained in the business process.“153 Hierbei werden
verschiedene Modellierungstechniken wie Petri-Netze (Open-EDI) oder UML-Diagramme
(OO-EDI) eingesetzt.154 Pragmatische EDI-Ansätze betrachten damit nicht mehr isoliert
einzelne Nachrichten, sondern Nachrichtenfolgen einer zwischenbetrieblichen Transaktion. Es
149 Nähere Erläuterungen zu Open-EDI erfolgt in Abschnitt 3.5.2 150 begonnen wurde mit UN/EDIFACT und ANSI X12 151 Vgl. Zbornik (Märkte 1996), S. 92f. 152 Näheres zu Open-EDI und OO-EDI in Abschnitt 3.5.2 153 TMWG (Guide 1998), S. 14
49
werden nicht nur die Nachrichtenformate für bestimmte geschäftliche Anwendungen
festgelegt, sondern auch die erforderlichen Aktions- und Reaktionsmuster.
Wesentlicher Bestandteil der pragmatischen Ansätze sind standardisierte Szenarios.155 Sie
definieren eine Gruppe logisch zusammengehöriger und abgestimmter Informationsflüsse
sowie deren Ablauf (z. B. für eine Katalogbestellung). Es ist genau festgelegt, welche
Nachricht als Antwort auf eine bestimmte eingehende Nachricht zu versenden ist. Beim Open-
EDI- und OO-EDI-Ansatz wird davon ausgegangen, dass zur Durchführung
zwischenbetrieblicher Transaktionen auf bilaterale Vereinbarungen ganz verzichtet werden
kann. Die beteiligten Geschäftspartner beziehen sich in ihren Nachrichten auf die
standardisierten Szenarien, die sowohl Inhalte als auch Abfolge der Informationsflüsse
festlegen.
Integrationsebene Maßnahmen und Hilfsmittel Standards Pragmatische Integration • Bilaterale Vereinbarungen
• Standardisierte Szenarien Open-EDI
Semantische Integration • Standardisierte Qualifier und Codes
• Message Implementation Guides
• Standardardisierte Identifikationssysteme
EAN, UPC, NVE, ILN, bbn, bbs
Syntaktische Integration • Standardisierte Nachrichtenformate
• Konvertersysteme
EDIFACT, ANSI X12, ODETTE, VDA, SEDAS
Technische Integration • Diverse Netze • VANs • MWD
X.400, X.435, FTAM, X.25
Tab. 2-17 Integrationsansatz des klassischen EDIs
2.6.2 XML/EDI
Klassisches EDI ist unter anderem dadurch gekennzeichnet, dass für die
Nachrichtenübertragung insbesondere value added networks (VANs) verwendet werden.156 In
den letzten Jahren hat sich daneben erstaunlich schnell das Internet für die elektronische
Abwicklung von
154 Eine ausführlichere Darstellung dazu erfolgt im Abschnitt 3.5.2 155 Vgl. ISO (Information 1997) 156 Vgl. Vollmer (Integration 2000), S. 2f.; Vollmer, Bartels (Market 2000), S. 1f.
50
zwischenbetrieblichen Transaktionen etabliert.157 Der Erfolg begründet sich in der weltweiten
Verfügbarkeit, den einfachen Zugangsmöglichkeiten - schon ein Browser genügt für den
ersten Einstieg - und den geringen Nutzungskosten. Die Möglichkeiten des Internets zur
Übertragung zwischenbetrieblicher Nachrichten blieben mit der Hypertext Markup Language
(HTML) zunächst jedoch beschränkt, da sie nur die Darstellung und nicht den Inhalt eines
Dokumentes beschreibt. Eine automatische Verarbeitung solcher Dokumente, wie sie beim
EDI gefordert wird, ist daher mit HTML nur sehr eingeschränkt möglich. Mit der Extensible
Markup Language (XML) besteht mittlerweile die Möglichkeit, nicht nur die eigentlichen
Nutzdaten zu übertragen, sondern auch deren inhaltliche Beschreibung in Form von Tags.
Somit werden Auswertungen über XML-Nachrichten und deren Verarbeitung durch
Programme ermöglicht. XML ist daher prädestiniert für den elektronischen Austausch
strukturierter Geschäftsnachrichten über das Internet. In diesem Zuge wurden XML-basierte
EDI-Lösungen geschaffen.158
Von XML-basierten EDI-Lösungen erhofft man sich einfache und kostengünstige EDI-
Implementierungen, da sie auf offenen Standards und einer verfügbaren Internettechnologie
basieren. EDI soll somit auch für kleine und mittlere Unternehmen erschwinglich werden.159
Hohe Einstiegskosten werden vermieden, da in der Regel Internetanschlüsse und -browser in
den Unternehmen bereits vorhanden sind. Aufgrund der weltweiten Verbreitung und
Popularität des Internets und zunehmend der XML wird auch eine kostengünstige
Entwicklung für XML Softwarewerkzeuge sowie die Verfügbarkeit von XML Know-how
erwartet.160
Technische Integration
Aus Sicht einer technischen Integration sind XML/EDI-Lösungen in gleicher Weise
aufgebaut, wie klassische EDI-Lösungen. Statt eines value added networks (VAN) wird
allerdings für die Nachrichtenübertragung in der Regel das Internet genutzt.161 Die Integration
kann dabei sowohl direkt als auch indirekt erfolgen.
Syntaktische Integration
157 Vgl. Vollmer, Bartels (Market 2000), S. 1ff. 158 Umfassende Übersichten dazu: vgl. Steffen (Internet-Quellen 2000); Steffen (XML/EDI 2001) 159 Vgl. Bryan (XML/EDI 1998), S. 2 160 Vgl. Schneider (Einführung 1998), S. 54 161 Vgl. Vollmer (Integration 2000), S. 4ff.
51
Bei XML/EDI-Nachrichten handelt es sich um zumeist standardisierte XML-Dokumente. Das
syntaktische Format kann durch Document Type Definitions (DTDs) oder XML-Schemata
beschrieben werden. Darin wird u. a. festgelegt, welche Datenelemente - bei XML-
Dokumenten spricht man von Tags - zwingend oder optional in einer XML-Nachricht
enthalten sind. Auch beim XML/EDI ergibt sich aus oben genannten Gründen162 die
Notwendigkeit zur Standardisierung. Es sind eine Fülle von Initiativen zur Standardisierung
von XML/EDI-Nachrichten unternommen worden.163 Diese lassen sich nach ihrer Herkunft
zwei verschiedenen Strömungen zuordnen.
Die erste Strömung bilden Unternehmen, deren Kompetenzbereich in der Internet- und
insbesondere der XML Technologie liegt und daher als XML community bezeichnet werden
sollen.164 Initiativen der XML community bemühen sich, unabhängig von vorhandenen EDI-
Formaten standardisierte XML Spezifikationen zu schaffen. Beispiele dafür sind xCBL,
cXML, OFX, ICE und OAGIS (vgl. Tab. 2-18). Diese Ansätze können bereits eine größere
Verbreitung und Unterstützung durch viele Softwaresysteme aufweisen.
Initiativen der zweiten Strömung entstammen der traditionellen EDI community und
versuchen, bestehende EDI-Standards oder die in ihnen enthaltene Semantik nach XML zu
überführen. Dazu gehören beispielsweise Arbeitsgruppen des United Nations Centers for the
Facilitation of Procedures and Practices for Administration, Commerce and Transport
(UN/CEFACT). UN/CEFACT ist ein für die Entwicklung von UN/EDIFACT verantwortliches
globales Normungsgremium. Im europäischen Raum arbeiten Arbeitsgruppen des CEN/ISSS
(European Committee for Standardization / Information Society Standardization System)
sowie der European Electronic Messaging Association (EEMA) intensiv an XML/EDI-
Konzepten. In den Vereinigten Staaten tut dies die für ANSI X12 zuständige Data
Interchange Standards Association (DISA). Auf nationaler Ebene hat der Normenausschuss
Bürowesen (NBü) des Deutschen Instituts für Normung (DIN) zusammen mit der Deutschen
EDI Gesellschaft (DEDIG) eine Initiative zur XML/EDI-Standardisierung gestartet.
162 Vermeidung von bilateralen Absprachen; vgl. Abschnitt 2.6.1) 163 Vgl. Steffen (Internet-Quellen 2000); Steffen (XML/EDI 2001) 164 Vgl. Campbell (XML/EDI 2000), S. 8
52
Herkunft Initiative Erläuterung xCBL - XML-based Common Business Library
Spezifikationen, die es ermöglichen, strukturierte Geschäftsdaten über das Internet auszutauschen, wie beispielsweise Produktdaten, Bestellaufträge, Rechnungen oder Lieferpläne. Damit deckt xCBL den Anwendungsbereich des klassischen EDIs ab.
cXML -commerce XML
Unterstützt Beschaffungsprozesse über das Internet. cXML besteht aus XML DTDs, die es ermöglichen, Daten aus Produktkatalogen über das Internet elektronisch abzufragen, auszutauschen und zu aktualisieren. Darüber hinaus werden Bestellvorgänge unterstützt.
OFX - Open Fi-nancial Exchange
Soll eine komplette Umgebung für den offenen Zahlungsverkehr und den Austausch von Finanzdaten über ungesicherte Netzwerke bereitstellen. Dazu gehört die transparente Einbettung von bestehenden Zahlungssystemen und die Steuerung des gesamten Zahlungsvorganges über das Internet zwischen Kreditinstituten, kleinen Unternehmen und Privatleuten.
ICE - Information and Content Exchange
Soll den erforderlichen Austausch unstrukturierter Daten im Rahmen einer unternehmensübergreifenden Kooperation unterstützen und vereinfachen.
XML community
OAGIS - Open Applications Group Integration Specifications
Spezifikationen für die Integration von betriebswirtschaftlichen Anwendungen. Sie beschreiben die Inhalte von geschäftlichen Dokumenten, den Business Objects Documents (BOD) und deren erforderlichen Verarbeitungsfunktionen.
Initiativen der UN/CEFACT
Untersuchung der Bedeutung und des Einflusses von XML auf EDI und insbesondere EDIFACT. Konzeptentwicklung eines globalen und zentralen XML/EDI-Repositories unter Federführung der UN/CEFACT. Dieses Repository soll standardisierte Tags enthalten, die aus den bisherigen Message Implementation Guides (MIGs) abgeleitet werden sollen.
Initiativen der CEN/ISSS
Durchführung mehrerer XML/EDI-Projekte. Forderung, statt eines globalen XML/EDI-Repositories eine Methode zu entwickeln, mit der die semantischen Inhalte von verschiedenen Repositories ausgetauscht und überführt werden können. Für die Umsetzung dieser Empfehlungen gründete die CEN/ISSS Mitte 1999 einen XML/EDI-Workshop.
UN/XML der EEMA
Empfehlung eines globales Repository von XML Tags auf der Basis von EDIFACT. Ein entsprechender Prototyp unter der Bezeichnung UN/XML ist durch eine Arbeitsgruppe bereits entwickelt worden.
Initiativen der DISA
Durchführung von X12/XML-Projekten. Dabei wurden die Datenelemente und Strukturen des Nachrichtenstandards ANSI X12 in XML überführt und in einem Repository bereitgestellt. Ein Prototyp demonstriert den Nachrichtenaustausch auf Basis des entwickelten Repositories.
EDI community
Initiative des DIN/DEDIG
Projekt zur Normung von XML/DTDs. Ein erster Normentwurf liegt vor. Statt Tags oder DTDs inhaltlich zu standardisieren, werden eindeutige Regeln, wie aus einer vorhandenen EDIFACT-Spezifikation eine XML DTD erstellt werden soll und Beispiele für deren Implementierung vorgegeben.
Ge-meinsame Initiative
ebXML - elec-tronic business XML
UN/CEFACT und OASIS
Tab. 2-18 Initiativen zur Standardisierung XML-basierter Nachrichten165
Bislang liefen die Standardisierungsbestrebungen beider Strömungen größtenteils isoliert
nebeneinander her. Inzwischen gibt es einen Trend zur Vernetzung der verschiedenen
Initiativen. Ausdruck dafür ist die ebXML Initiative, ein gemeinsames Projekt der
Organization for the Advancement of Structured Information Standards (OASIS), einem
165 Vgl. Steffen (XML/EDI 2001), S. 5ff.
53
bedeutenden Vertreter der XML community, und der UN/CEFACT. Ziel dieses Projektes ist
es, ein offenes, technisches Rahmenwerk zu schaffen, auf dessen Basis standardisierte XML
Dokumente für den Geschäftsdatenaustausch definiert werden sollen. Die Entwicklung der
eigentlichen Nachrichteninhalte ist nicht Gegenstand von ebXML. Das Ergebnis des Projektes
sind vielmehr Vorgaben und Regeln für die Standardisierungsgremien, die XML
Austauschformate und Geschäftsprozessmodelle erzeugen, sowie Softwarefirmen, die darauf
aufbauende Software entwickeln.166 Damit sollen in konsistenter und einheitlicher Weise
XML-basierte Lösungen für den elektronischen Austausch von Geschäftsdaten über das
Internet entstehen.
Die Entwicklungsgeschichte von XML/EDI-Standards nimmt einen ähnlichen Verlauf wie
beim klassischen EDI. Statt über 20 Jahre hinweg werden die Entwicklungsschritte allerdings
innerhalb von nur wenigen Jahren durchlaufen. Seit XML zur Verfügung steht, wird sie für
den elektronischen Austausch von Geschäftsdaten verwendet. Viele Unternehmen,
vornehmlich aus der XML community, definierten zunächst eigene XML Schemata. Einigen
gelang die Vermarktung ihrer proprietären XML Spezifikationen. In manchen Branchen
konnte man sich auf bestimmte XML/EDI-Spezifikationen einigen (z. B. RosettaNet in der
IT-Zuliefererindustrie). Dennoch laufen die Standardisierungsbestrebungen größtenteils
immer noch nebeneinander her.
Nachdem sie das Potential von XML erkannt hatten, haben die Normungsgremien und andere
Gruppen der EDI community in XML/EDI und in dessen Standardisierung ein neues
Aufgabenfeld entdeckt. Anliegen dieser Organisationen ist es, die klassischen EDI-Standards
durch eine Verbindung mit der XML Technologie für den elektronischen Austausch von
Geschäftsdaten über das Internet nutzbar zu machen.
Semantische Integration
XML bietet die Möglichkeit, die eigentlichen Datenwerte zur inhaltlichen Beschreibung mit
Tags auszuzeichnen. Diese stellen aber letztendlich nur eine Bezeichnung dar, die für einen
Menschen möglicherweise interpretierbar ist, für ein Anwendungssystem aber per se keine
Hilfe bei der inhaltlichen Interpretation bietet.167 Es Bedarf weiterhin einer dedizierten und
166 Vgl. Huemer (Business 2001), S. 27 167 Vgl. Huemer (Business 2001), S. 21
54
standardisierten Datendefinition. Hier bietet XML/EDI keinen Vorteil gegenüber den
klassischen EDI-Standards.
Ebenfalls offen bleibt nach wie vor das Problem der heterogenen Identifikationsnummern.
Um dieses zu lösen, müssen auch XML/EDI-Ansätze auf bestehende Identifikationsstandards
zurückgreifen oder eigene Standards festlegen. Einen Mittelweg geht hierbei die RosettaNet-
Initiative. Zur Identifikation von Produkten ist eine sogenannte Global Trade Item Number
(GTIN) vorgesehen. Diese entspricht im wesentlich dem in Nordamerika verbreiteten
Universal Product Code (UPC) oder der in Europa verbreiteten EAN-Nummer.168 Eine
zusätzliche Stelle gibt das Level der Verpackungseinheit an, d. h. ob es sich bei dem Produkt
beispielsweise um die kleinste Verkaufseinheit, ein Gebinde oder eine Versandeinheit handelt.
Zur Identifikation von Betrieben wird ein neunstelliger Global Company Identifier eines von
der RosettaNet-Initiative selbst erarbeiteten und propagierten Data Universal Numbering
Systems (D-U-N-S) verwendet.
Identifikationsnummer Kennzeichen Data Universal Numbering System - Global Company Identifier
International gültige 9-stellige Nummer
Global Trade Item Number (GTIN)
International gültige 14-stellige Nummer, davon • 1 Stelle Verpackungseinheitslevel • 12 Stellen für UPC (mit führender 0) oder EAN (jeweils
ohne Prüfziffer) • 1 Stelle Prüfziffer
Tab. 2-19 Standardisierte Identifikationsnummern der RosettaNet-Initiative
Pragmatische Integration
In pragmatischer Hinsicht weiter entwickelt, als die bisher genannten XML/EDI-
Nachrichtenstandards ist der Ansatz der OAGIS. Bereits seit 1995 entwickelt die Open
Applications Group (OAG), ein Industriekonsortium, Spezifikationen für die Integration von
betriebswirtschaftlichen Anwendungen, die sogenannten Open Applications Group Integration
Specifications (OAGIS). Der Schwerpunkt liegt auf der Integration innerbetrieblicher
Anwendungssysteme, doch die Spezifikationen gelten auch für den Austausch über wide area
networks (WANs) wie das Internet. Seit Januar 1999 werden die OAGIS auch in Form von
Document Type Definitions (DTDs) für den XML-basierten Austausch veröffentlicht. Mit den
OAGIS werden in Form von Business Objects Documents (BOD) nicht nur Inhalt und Format
55
von geschäftlichen Nachrichten standardisiert, sondern auch deren erforderliche
Verarbeitungsfunktionen.169 Damit erhält der Empfänger einer Nachricht zusätzlich zu den
eigentlichen Daten eine Mitteilung darüber, was er mit den Daten machen soll. Dies ist ein
erster Schritt hin zu einer pragmatischen Integration. Allerdings werden von den OAGIS nur
isoliert einzelne Geschäftsnachrichten und keine Nachrichtenfolgen betrachtet.
Es gibt andere Ansätze, die Probleme einer pragmatischen Integration weitreichender lösen
können. Sie legen den Ablauf einer Transaktion bzw. die erforderlichen Aktions- und Re-
aktionsmuster in Form von Regeln fest und unterstützen diese informationstechnisch. Diese
Ansätze können danach unterschieden werden, ob sie geschlossene, gemeinsame oder offene
Ablaufregeln vorsehen.170 Ausschlaggebend für diese Unterscheidung ist, an welcher Stelle die
Ablaufregeln einer zwischenbetrieblichen Transaktion hinterlegt wird (vgl. Tab. 2-20).
Pragmatischer Ansatz Ort der Ablaufregel Geschlossene Ablaufregeln Zentral, in einem Anwendungssystem Gemeinsame Ablaufregeln Zentral, in einem Standard Offene Ablaufregeln Dezentral, verteilt auf Anwendungssysteme/Agenten Tab. 2-20 Pragmatische Integrationsansätze
Bei Ansätzen mit geschlossenen Ablaufregeln gibt es einen Hauptbeteiligten, der die Regeln
in einem seiner Anwendungssysteme hinterlegt und verwaltet. Daneben gibt es eine oder
mehrere Nebenparteien, die in der zwischenbetrieblichen Transaktion eingebunden sind. Die
Nebenparteien haben allerdings weder eine Gesamtsicht auf die Transaktion, noch können sie
sie beeinflussen. Ihre Beteiligung beschränkt sich auf die Beantwortung von Anfragen durch
den Hauptbeteiligten.
Bei Ansätzen mit gemeinsamen Ablaufregeln werden die Regeln in einer Vereinbarung, die
alle Transaktionsbeteiligten zu akzeptieren haben, hinterlegt, d. h. sie wird standardisiert. Der
Transaktionsablauf ist damit von vornherein festgelegt. Die darin eingebundenen
Anwendungssysteme müssen hierbei den Standard unterstützen. Beispiel für einen solchen
Ansatz ist der Standard der RosettaNet-Initiative.171 Zentrales Element sind hierbei sogenannte
Partner Interface Processes (PIP). Jeder PIP legt die erforderlichen Nachrichten zur
Unterstützung bestimmter zwischenbetrieblicher Transaktionen sowie deren Abfolge fest. Die
168 Vgl. RosettaNet (GTIN 1999), S. 11ff. 169 Vgl. Open Applications Group (Software 1999), S. 5ff. 170 Zu geschlossenen und offenen Ablaufregeln vgl. Yee (Chaos 2000), S. 3f. Zu gemeinsamen Ablaufregeln vgl. Olsen (Overview 2000), S. 34
56
Definition solcher PIP erfolgt durch Prozessmodelle, bestehend aus UML-Klassen- und
Sequenzdiagrammen, sowie einem Implementation Guide. Wie in den Open-EDI-Szenarios
sind auch in den PIP die Antwortdokumente auf bestimmte Nachrichten fest vorgegeben. Im
Gegensatz zur Open-EDI-Initiative werden die RosettaNet-PIP bereits von vielen
Softwaresystemen
unterstützt.172
Während bei Ansätzen mit geschlossenen oder gemeinsamen Ablaufregeln zentrale Regeln
vorliegen - entweder in einem der beteiligten Anwendungssysteme oder in einem Standard -
arbeiten Ansätze mit offenen Ablaufregeln mit dezentralen Regeln. Hierbei ist der Trans-
aktionsablauf nicht von vornherein festgelegt, sondern flexibel. Er ergibt sich aus einer
situationsabhängigen Verhandlung zwischen den beteiligten Partnern. Beispiele dafür sind
agentenbasierte Ansätze.173 Unter Agenten werden in der Wirtschaftsinformatik autonome
Softwarekomponenten verstanden, die flexibel auf Ereignisse in ihrer Umgebung reagieren,
die autonome Entscheidungen treffen, und die mit anderen Agenten in zielgerichteter Weise
interagieren.174 Eine agentenbasierte zwischenbetriebliche Integration ist bisher nur für einige
wenige, sehr spezifische Anwendungsfelder prototypisch realisiert worden.175 Diese Ansätze
stellen bislang ausschließlich Forschungsarbeiten dar und finden in der Praxis noch keine
Verbreitung. Das E-business framework der XML/EDI-Group176 sieht ebenfalls den Einsatz
von Agenten vor.177
171 Eine nähere Erläuterung zur RosettaNet-Initiative erfolgt in Abschnitt 3.6.2. 172 So gibt es über 170 zertifizierte RosettaNet Solution Provider. Vgl. www.rosettanet.org; Stand vom 2001-12-13 173 Zur Agententechnologie vgl. Burkhard (Einführung 1998) und Weiß (Agenten 1998) sowie die jeweils dort angegebene Literatur. 174 Vgl. Burkhard (Einführung 1998), S. 6ff.; Müller (Kontrollarchitekturen 1998), S. 18 175 An dieser Stelle werden beispielhaft einige entsprechende Forschungsarbeiten ohne Anspruch auf Vollständigkeit aufgeführt. Die Unterstützung der Lager- und Transportlogistik durch teilintelligente Agenten wird beschrieben in Falk, Pieck, Mertens (Unterstützung 1993). Einen alternativen Ansatz für das gleiche Anwendungsfeld verfolgt FISCHER in Fischer (TeleTruck 1998). Intelligente Agenten für das Management virtueller Unternehmen behandelt Fischer u. a. (Agenten 1996). WILHELM beschreibt den Einsatz intelligenter Agenten zur Unterstützung der Auftragsabwicklung im Systemvertrieb. Vgl. Wilhelm (Unterstützung 1997) Agenten zur Prozesskoordinierung in Produktionsnetzwerken beschreibt ZELEWSKI in Zelewski (Märkte 1997). 176 Die im Juli 1997 gegründete XML/EDI-Group ist ein Zusammenschluss von Unternehmen und Einzelpersonen zur Förderung und Entwicklung von XML/EDI-Standards und –Produkten. 177 Vgl. Peat, Webber (XML/EDI 1997), S. 5
57
Integrationsebene Maßnahmen und Hilfsmittel Standards Pragmatische Integration • Bilaterale Vereinbarungen
• Standardisierte Szenarien RosettaNet: PIPs
Semantische Integration • Standardisierte Identifikationssysteme
• Standardisierte Tags
RosettaNet: GTIN, DUNS; ebXML
Syntaktische Integration • Standardisierte XML-Schemata und DTDs
cXML, xCBL, OFX, ICE, RosettaNet
Technische Integration • Internet TCP/IP, HTTP/HTTPS, FTP, SMTP
Tab. 2-21 Integrationsansatz des XML/EDIs
2.6.3 Defizite vorhandener Integrationsansätze
Ein Betrieb hat bei der Entscheidung für einen Integrationsansatz diesen aus zwei
Blickwinkeln zu betrachten und zu beurteilen. Aus statischer Sicht muss berücksichtigt
werden, wie effektiv der Lösungsansatz ist, d. h. welcher Integrationsgrad erreicht werden
kann. Aus dynamischer Sicht ist zu beurteilen, welchen Beitrag ein Integrationsansatz zur
Gestaltungsaufgabe der zwischenbetrieblichen Informationsflüsse leistet und wie effizient
dieser Beitrag geleistet werden kann. Vor dem Hintergrund dieser beiden Aspekte sollen in
diesem Abschnitt die zuvor beschriebenen Integrationsansätze des klassischen EDIs und des
XML/EDIs beurteilt werden.
Mangelnde Effektivität
Mangelnder Integrationsgrad
Die Anforderungen einer technischen Integration werden sowohl beim klassischen EDI als
auch beim XML/EDI vollständig erfüllt. Sie stellen in der Regel kein großes Problem dar, da
hierfür erprobte Technologien und Komponenten auf dem Markt vorhanden sind.178
Auch das Problem der syntaktischen Integration kann als hinreichend gelöst betrachtet
werden. Mit den zahlreichen, verfügbaren Nachrichtenstandards stehen gemeinsame
Syntaxregeln für den zwischenbetrieblichen Informationsfluss zur Verfügung. Für den
Abgleich mit den jeweiligen Inhousesystemen179 stehen entsprechende Konverter zur
Verfügung.
178 Vgl. Henkel (Gestaltung 1996), S. 14f.; Zbornik (Märkte 1996), S. 91; Fischer (Informationswirtschaft 1999), S. 167 179 Unter einem Inhousesystem wird aus Sicht eines bestimmten Betriebes ein Anwendungssystem verstanden, welches in diesem Betrieb eingesetzt wird. Dieser Begriff soll verwendet werden, wenn die Abgrenzung
58
Probleme bereitet dagegen die semantische Integration. Die in Form von einfachen
Verzeichnissen von Datenelementen publizierten Standardformate lassen unterschiedliche
Interpretationen der übermittelten Daten zu.180 Lösungen gibt es nur für Teilprobleme, wie
beispielsweise diverse Identifikationssysteme (EAN, UPC, ...). Es fehlen bislang
Möglichkeiten, die semantische Bedeutung von Datenelementen eindeutig festzulegen.
Für die pragmatische Integration existieren bislang keine vollständigen und befriedigenden
Lösungen.181 Hauptgrund sind die fehlenden Schnittstellen betrieblicher Anwendungssysteme
für eine zwischenbetriebliche Abwicklung von Transaktionen. Innerbetrieblich wird die
pragmatische Integration durch Vorgangssteuerungsmechanismen der Anwendungssysteme
oder durch separate Workflowsysteme operativ unterstützt. Dagegen ist die Verarbeitung
externer Ereignisse meist vollständig auf die Mensch-Anwendungssystem-Schnittstelle
ausgerichtet. Die von einer zwischenbetrieblichen pragmatischen Integration zu fordernde
automatische Weiterverarbeitung kann damit größtenteils nicht erfüllt werden.
Sowohl klassisches EDI als auch XML/EDI führen damit lediglich zu einer technischen sowie
syntaktischen Integration und in Teilen zu einer semantischen Integration. Eine pragmatische
Integration erfolgt nur bei sehr wenigen Ansätzen, die sich allerdings bislang nicht in der
Praxis durchsetzen konnten. So existiert derzeit kein Konvertersystem, welches beispielsweise
Open-EDI oder OO-EDI unterstützt.182. In der Regel werden nur einzelne Nachrichten
betrachtet und keine kompletten Transaktionen unterstützt. Nachrichtenübergreifende
Integritätsprüfungen finden in der Regel nicht statt.183
EDI- oder XML/EDI-Lösungen sind damit nicht sehr effektiv. Ohne eine semantische und
pragmatische Integration können die potenziellen strategischen Nutzeffekte einer Integration
(vgl. Abschnitt 2.4) schwerlich erreicht werden. Es werden lediglich operative Nutzeffekte
erzielt.
innerbetrieblicher Anwendungssysteme von Anwendungssystemen anderer Betriebe ('externe Systeme‘) betont werden soll. 180 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 118; Schüppler (Informationsmodelle 1998), S. 34f. 181 Zur folgenden Argumentation vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 55 182 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 124 183 Vgl. Stern (Kommunikation 1997), S. 101
59
Hohe Spezifität
Ältere branchenspezifische Standards sowie XML/EDI-Standards sind in der Regel nicht sehr
umfangreich und einfach strukturiert. Daher eignen sie sich auch nur für einen begrenzten
Einsatzbereich. Dies ist nicht effektiv, da so unter Umständen von einem Betrieb viele
verschiedene Integrationslösungen für die Geschäftspartner aus unterschiedlichen Branchen
aufgebaut und betrieben werden müssen.
Vielfalt der Standards
Ein weltweit gültiger, branchenneutraler Standard für den zwischenbetrieblichen Informa-
tionsaustausch hat sich weder für das klassische EDI noch für XML/EDI-Lösungen etabliert.
Zwar nimmt der Anteil von EDIFACT bei den eingesetzten EDI-Standards zu, kann jedoch
branchenspezifische Standards wie SEDAS oder VDA nicht vollständig verdrängen.184 Zudem
existieren mit den Subsets wiederum zahlreiche unterschiedliche Varianten zum EDIFACT-
Standard. Noch problematischer als beim klassischen EDI ist die Vielfalt der Standards bei
XML/EDI. Die Flexibilität als eine der großen Stärken von XML/EDI ist zugleich auch die
größte Schwäche. Denn jedes Unternehmen kann Tags, DTDs oder XML-Schemata nach
seinen Erfordernissen mit den jeweiligen Geschäftspartnern vereinbaren. Da XML/EDI eine
sehr junge Technologie ist, hat sich bislang noch kein bestimmtes XML/EDI-Format als
dominanter Standard durchsetzen können.
Die Folge der Standardvielfalt ist ein Auswahlproblem beim Aufbau einer
Integrationslösung.185 Das Auswahlproblem ist, gerade bei XML/EDI-Lösungen, mit einer
gewissen Investitionsunsicherheit belegt. Offene Fragen bei der Entscheidung für einen
Standard sind: Welchen Standard nutzen die Geschäftspartner heute und zukünftig? Welcher
Standard wird in welcher Branche eine hohe Verbreitung finden? Wird sich der ausgewählte
Standard durchsetzen können? Diese Unsicherheit kann Unternehmen davon abhalten, eine
Integration
zwischenbetrieblicher Informationsflüsse vorzunehmen.186 Hat man sich dennoch für eine
Integrationslösung entschieden, so ist aufgrund der Standardvielfalt die Wahrscheinlichkeit
gering, dass sämtliche Geschäftspartner den eigenen Standard unterstützen. Die Folge sind
zum einen wiederum nicht sehr effektive Integrationslösungen, da sie nur für einen begrenzten
184 Vgl. Schüppler (Informationsmodelle 1998), S. 33. Vgl. auch statistische Zahlen in Fußnote 140. 185 Vgl. Schüppler (Informationsmodelle 1998), S. 33 186 Vgl. Westarp u. a. (Status 1999), S. 3
60
Einsatzbereich geeignet sind. Anderseits führt die Standardvielfalt auch zu ineffizienten
Lösungen, da für nicht kompatible Standards zahlreiche Konvertierungsprozeduren
erforderlich sind, deren Implementierung oder Bereitstellung mit Kosten verbunden sind.
Mangelnde Effizienz
Komplizierter Aufbau
Standardisierungsbemühungen stehen immer im Zielkonflikt zwischen Allgemeingültigkeit
und Einfachheit bzw. geringer Komplexität. Branchenneutrale Formate wie EDIFACT oder
ANSI X12 weisen zwar einerseits eine hohe Allgemeingültigkeit auf, zeichnen sich aber
andererseits durch einen sehr umfangreichen und komplizierten Aufbau aus.
Dies „geht mit einem Verlust an individueller Transparenz und technischer Performance
einher.“187 Die Folge sind zeitaufwendige Implementierungen und lange Projektlaufzeiten.
Viele potenzielle Anwender scheuen diese langen Projektlaufzeiten und die damit
verbundenen hohen Kosten einer EDI-Implementierung. Fehlendes Know-how muss durch
externe Beratungsleistungen, die wiederum mit Kosten verbunden sind, ersetzt werden.
Bezüglich der Korrektheit und Sicherheit von Daten besteht an der Schnittstelle zwischen
Unternehmen eine hohe Sensibilität.188 Die flexible Schnittstelle Sachbearbeiter ist schwierig
zu ersetzen. Für eine automatisierte Weiterverarbeitung der ausgetauschten Nachrichten
müssen daher eine Vielzahl von Prüf- und Kontrollprozeduren implementiert werden.
Aufgrund der komplizierten EDI-Regelwerke sind diese mit einem hohen Aufwand und damit
hohen Kosten verbunden.
Technik- und Syntaxorientierung
Bei der Definition bisheriger Standards für klassisches EDI und XML/EDI wird nicht klar
zwischen Technik, Syntax, Semantik und Pragmatik getrennt. Der Fokus liegt dabei zumeist
auf der Festlegung der Syntax und der technischen Implementierung.189 Dies macht es schwer
bis unmöglich, bestehende Integrationslösungen auf neue und veränderte Technologien zu
übertragen.
187 Schüppler (Informationsmodelle 1998), S. 34 188 Vgl. Schüppler (Informationsmodelle 1998), S. 24 189 Vgl. Schüppler (Informationsmodelle 1998), S. 35
61
Aufwendige, bilaterale Absprachen
Vorhandene EDI-Standards (wie z. B. EDIFACT, SEDAS, ANSI X12) und im besonderen
XML/EDI-Standards lösen zwar die syntaktischen, nicht aber die semantischen Probleme
eines zwischenbetrieblichen Informationsaustausches. Die zumeist in Form von Feldkatalogen
publizierten Standardformate lassen unterschiedliche Interpretationen der übermittelten Daten
zu.190
Dies erfordert eine zeitaufwendige Verständigung zwischen den Partnern über die Bedeutung
der auszutauschenden Daten.191 Der auf der einen Seite gewonnene Vorteil der Präzisierung
durch Bilden von Subsets führt andererseits zu Inkompatibilitäten zwischen den
verschiedenen Branchen und Benutzergruppen. Diese müssen unter Umständen wiederum
durch bilaterale Absprachen ausgeräumt werden.
Mangelnde Flexibilität
Herkömmliche EDI-Standards sind zu starr auf lang bestehende und unveränderte
Geschäftsprozesse ausgelegt und brauchen bei deren Änderungen viel Zeit für eine
Anpassung. Dabei verändern sich zwischenbetriebliche Transaktionen häufig aufgrund
veränderter Verbraucherwünsche, staatlicher Vorschriften (z. B.
Verpackungsmittelverordnung, Herstellernachweis beim Fleischvertrieb), etc. Ein anderer
Aspekt ist, dass durch die vorgegebenen Strukturen der Standardformate weniger
Freiheitsgrade hinsichtlich einer Realisierung spezifischer, an der Schnittstelle zwischen
Unternehmen zum Ausdruck kommender Kernkompetenzen bestehen.192
Wartet man die Aufnahme von Änderungen in die Standardformate ab, so ergeben sich sehr
lange Projektlaufzeiten, die mit hohen Kosten verbunden sind. Die Alternative sind bilaterale
Anpassungen der Standardformate. Aber auch deren Implementierung und Wartung sind
aufwendig und mit Kosten verbunden.
Zusammenfassung und Fazit
Eine Integration zwischenbetrieblicher Informationsflüsse kann sowohl durch klassische EDI-
Ansätze als auch durch XML/EDI-Ansätze nicht befriedigend erreicht werden. Der Grund
sind mangelnde Effektivität und Effizienz bei der Gestaltung zwischenbetrieblicher
190 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 118; Schüppler (Informationsmodelle 1998), S. 34f. 191 Vgl. Zbornik (Märkte 1996), S. 92
62
Informationsflüsse. Daher haben sich Integrationsansätze wie klassisches EDI oder XML/EDI
trotz anerkannter und nachgewiesener Nutzenpotenziale (vgl. Abschnitt 2.4) nicht in der
Breite durchsetzen können, wie vor einigen Jahren prophezeit wurde.193 Nur 5 % aller
Betriebe, die von einem EDI-Einsatz profitieren würden, nutzen auch EDI.194 Gründe dieser
Zurückhaltung der Betriebe und damit der geringen Verbreitung vorhandener
Integrationsansätze sind eine Reihe schwerwiegender Defizite, die im vorhergehenden
Abschnitt erläutert wurden (vgl. Tab. 2-22).
Defizit Resultierende Hemmnisse EDI XML/EDI
Mangelnder Integra-tionsgrad
• Keine langen Transaktionen • Keine strategischen Nutzeffekte
Hohe Spezifität • Begrenzter Einsatzbereich • Geringerer Nutzen • Höherer Abstimmungsbedarf
Mangelnde Effektivität
Vielfalt der Standards • Investitionsunsicherheit • Zeitaufwendige Absprachen
Komplizierter Aufbau • Hohe Komplexität • Fehlendes Know-how • Aufwendige Implementierung • Lange Projektlaufzeiten
Technik- und Syntaxorientierung
• Teuer bei Umstellungen auf neue Technologien
Aufwendige, bilaterale Absprachen
• Zeitaufwendige Absprachen • Hoher Aufwand
Mangelnde Effizienz
Mangelnde Flexibilität • Viel Zeit für Anpassung, d. h. langwierige Standardisierung
• Keine Kernkompetenzen • Verlust an Individualität
Legende: Defizit trifft zu Defizit trifft weitgehend zu Defizit trifft nicht zu
Tab. 2-22 Defizite vorhandener Integrationsansätze
Die mangelnde Effektivität resultiert hauptsächlich aus dem Umstand, dass durch die
verfügbaren Standards allein kein hoher Integrationsgrad erreicht werden kann. Zu viele
Schwierigkeiten bereitet die eindeutige Festlegung semantischer und pragmatischer Aspekte.
Dieses muss durch zusätzliche langwierige bilaterale Vereinbarungen und aufwendige Prüf-
192 Vgl. Schüppler (Informationsmodelle 1998), S. 36 193 Vgl. Henkel (Gestaltung 1996), S. 10; Lamprecht (Datenaustausch 1998), S. 1f.; Westarp u. a. (Status 1999), S. 3 194 Schätzung nach Forrester Research. Vgl. Segev, Porra, Roldan (EDI 1997), S. 2
63
und Kontrollprozeduren bei der Implementierung kompensiert werden, welches die Effizienz
mindert.
Die Integration zwischenbetrieblicher Informationsflüsse ist eine Gestaltungsaufgabe, die
ganzheitlich die Ebenen der technischen, syntaktischen, semantischen und pragmatischen
Integration berücksichtigen muss. Bisherigen Integrationsansätzen wie klassisches EDI oder
XML/EDI mangelt es an Methoden und Techniken zur Unterstützung und Bewältigung einer
solchen Gestaltungsaufgabe.195
Während sich zur Gestaltung innerbetrieblicher Informationssysteme Methoden zur
Visualisierung und Modellierung von Funktionen, Daten und Informationsflüssen
durchgesetzt haben, wird bei der zwischenbetrieblichen Integration zumeist darauf
verzichtet.196 Dabei wird vom Autor in der fachkonzeptuellen Modellierung eine Möglichkeit
gesehen, die meisten der geschilderten Schwächen bestehender Integrationsansätze zu
beheben.197 In den nachfolgenden Kapiteln soll daher eine Modellierungsmethode zur
Integration zwischenbetrieblicher Informationsflüsse entwickelt werden.
195 Vgl. Hirschmann, Scheer (Konzeption 1994), S. 11; Müller-Zantop, S.: (Perspektiven 1998), S. 11; Schüppler (Informationsmodelle 1998), S. 35 196 Vgl. Schüppler (Informationsmodelle 1998), S. 35 197 Vgl. Henkel (Gestaltung 1996), S. 15
64
3 Anforderungen an eine Modellierungsmethode zur Integration zwischenbetrieblicher Informationsflüsse
3.1 Grundlagen der Modellierung
3.1.1 Modelle und Modellierungsmethoden im Rahmen der
Informationssystemgestaltung
Bislang gibt es kein einheitliches Verständnis vom Begriff des Modells zwischen der
Betriebswirtschaftslehre, der Informatik und der Wirtschaftsinformatik. Selbst innerhalb der
genannten Wissenschaftsdisziplinen wird der Modellbegriff in unterschiedlicher Weise
verwendet.198 Im wesentlichen gibt es drei Definitionsrichtungen: der formale Modellbegriff,
der abbildungsorientierte199 Modellbegriff und der konstruktionsorientierte200 Modellbegriff.
Nach der vor allem in der theoretischen Informatik und Mathematik herrschenden Sicht stellt
ein Modell vereinfacht ausgedrückt eine „Belegung eines Axiomensystems“ dar.201 Damit ist
eine Interpretation einer mathematischen Struktur gemeint, die „wahr“ ist für alle Axiome und
Ableitungsregeln dieser Struktur.202 Da dieses Modellverständnis keinen Bezug zur Realwelt
unterstellt, sondern nur im Zusammenhang mit strukturtheoretischen Ansätzen gebraucht
wird,203 wird es in dieser Arbeit nicht näher betrachtet und weiterverfolgt.
Sowohl in der Betriebswirtschaftslehre als auch in der Informatik und Wirtschaftsinformatik
ist der abbildungsorientierte Modellbegriff weit verbreitet. Hierbei wird ein Modell als
„adäquates Abbild der betrachteten Wirklichkeit“204 verstanden. Der Modellierer abstrahiert
198 Vgl. Herrmann (Planung 1992), S. 102; Schütte (Grundsätze 1998), S. 40 199 HERMANN spricht vom abbildungstheoretischen Modellverständnis. Vgl. Herrmann (Planung 1992), S. 103ff. 200 BRETZKE spricht vom konstruktivistischen Modellbegriff. Vgl. Bretzke (Problembezug 1980), S. 33ff. 201 Vgl. Wedekind u. a. (Modellierung 1998), S. 266 202 Vgl. Schütte (Grundsätze 1998), S. 52 203 Vgl. Wedekind u. a. (Modellierung 1998), S. 266 204 Kosiol (Modellanalyse 1961), S. 321. Vgl. weitere Definitionen: - Becker, Rosemann, Schütte (Grundsätze 1995), S. 435: „Ein Modell wird verstanden als ein immaterielles
Abbild der Realwelt für Zwecke eines Subjekts“. Vgl. ähnlich auch Rosemann (Komplexitätsmanagement 1996), S. 17
- Burkhardt (UML 1997), S. 4: „Ziel einer jeden Modellierung [...] ist das Widerspiegeln eines Ausschnittes aus der realen Welt durch eine gegebenfalls vereinfachte Repräsentation in Form eines Modells.“
- Ferstl, Sinz (Grundlagen 1998), S. 18: „In informaler Definition ist ein Modell ein System, das ein anderes System zielorientiert abbildet.“
- Fischer (Datenmanagement 1992), S. 77 (bezogen auf die Datenmodellierung): „Der Konstruktionsprozeß, [...] soll den relevanten Ausschnitt der realen, empirisch beobachtbaren Objektwelt mit einem systemanalytischen Vorgehen durchleuchten und in einem abstrakten Modell abbilden.“
65
dabei von Sachverhalten, die für seine jeweilige Fragestellung unwesentlich sind.205 Es wird
allerdings davon ausgegangen, dass ein Modell die Realwelt strukturerhaltend abbildet.206 Das
abbildungsorientierte Modellverständnis in der Wirtschaftsinformatik lässt sich anhand der
Begriffe Diskurswelt, Objektsystem, Abbildung und Modellsystem verdeutlichen207 (vgl.
Abb. 3.1). Die Diskurswelt stellt den Ausschnitt der Realwelt dar, der in einem Modell
abgebildet werden soll. Das Objektsystem repräsentiert die subjektive Interpretation der
gewählten Diskurswelt, die sich nach den jeweiligen subjektiven Modellierungszielen richtet.
Das Modellsystem ist wiederum ein subjektives Abbild des Objektsystems. Die Beziehung
zwischen Objekt- und Modellsystem kann durch eine Abbildungsrelation formuliert werden.
Für diese Abbildung wird häufig die Eigenschaft der Homomorphie oder gar der Isomorphie
gefordert.208
welt
ModellweltRealwelt
subjektive subjektiveModellierungsziele
Diskurs-Objektsystem
Prüfung
Modellsystem
Metamodell
SAbbildungsrelation
Interpretation
MSO
Konsistenz/Vollständigkeit
Struktur- undVerhaltenstreue
Abb. 3.1 Abbildungsorientierter Modellbegriff der Wirtschaftsinformatik209
Die Modellierung, d. h. das Erstellen von Modellen,210 stellt sich nach dem
abbildungsorientierten Modellverständnis als reine Reproduktion der Realwelt dar.211 An
- Mertins, Süssenguth, Jochem (Modellierungsmethoden 1994), S. 7: „Ein Modell ist ein System, das ein anderes, in Bezug auf das Modell reales System abbildet.“
205 Vgl. Kosiol (Modellanalyse 1961), S. 319 206 Vgl. Kosiol (Problemanalyse 1967), S. 6; Bretzke (Problembezug 1980), S. 29f.; Ferstl, Sinz (Grundlagen 1998), S. 18f.; Schütte (Grundsätze 1998), S. 53 207 Vgl. im folgenden Rosemann (Komplexitätsmanagement 1996), S. 17f.; Ferstl, Sinz (Grundlagen 1998), S. 4f. 208 Vgl. Kosiol (Modellanalyse 1961), S. 321; Bretzke (Problembezug 1980), S. 30; Mertins, Süssenguth, Jochem (Modellierungsmethoden 1994), S. 9; Rosemann (Komplexitätsmanagement 1996), S. 18 209 in Anlehnung an Rosemann (Komplexitätsmanagement 1996), S. 19 210 Vgl. Rosemann (Komplexitätsmanagement 1996), S. 18; Ferstl, Sinz (Grundlagen 1998), S. 117 211 Vgl. Bretzke (Problembezug 1980), S. 30
66
diesem Punkt setzt die Argumentation der Kritiker des abbildungsorientierten Modellbegriffs
an, der in dieser Arbeit gefolgt werden soll. Bereits „die Diskurswelt [stellt, T.S.] ein mentales
Modell einer als Realität empfundenen Situation des Individuums dar [...]. Die subjektive
Interpretation der Diskurswelt mit dem Ergebnis eines Objektsystems stellt dann ein weiteres
mentales Modell dar, [...]“.212 Die geforderte Ähnlichkeit zwischen dem Modell und der
Realwelt wäre demnach nur intersubjektiv überprüfbar, wenn man voraussetzte, dass ein freier
Zugang zu den Erscheinungen der Welt und ein objektives Wahrnehmen möglich wäre.213
Das geschilderte Argumentationsproblem entsteht beim konstruktionsorientierten Modell-
begriff nicht, da ein Ähnlichkeitsanspruch zwischen Realwelt und Modell von vornherein
nicht erhoben wird. Nach dem konstruktionsorientierten Modellverständnis stellen Modelle
die Konstruktion eines Problems, d. h. das Ergebnis von Strukturgebungsprozessen dar.214 Die
Modellierung wird als eine kreative, gestaltende Tätigkeit aufgefasst, gegenüber der passiv-
rezeptiven Nachbildung der Realwelt beim abbildungsorientierten Modellbegriff.215 Dem
konstruktionsorientierten Modellbegriff liegt die Annahme zugrunde, dass die Wirklichkeit
nur über die Erkenntnisleistung eines Subjekts wahrgenommen werden kann.216 Da dieser
Argumentation gefolgt werden soll, wird die Modelldefinition nach SCHÜTTE, einem Vertreter
des konstruktionsorientierten Modellbegriffs, übernommen: „Ein Modell ist das Ergebnis
einer Konstruktion eines Modellierers, der für Modellnutzer eine Repräsentation eines
Originals zu einer Zeit als relevant mit Hilfe einer Sprache deklariert.“217
Mit der Konstruktion eines Modellierers ist dessen konstruktive Erkenntnisleistung und der
Aufbau eines gedanklichen Modells gemeint. Dieses gedankliche Modell wird mittels einer
natürlich- und formalsprachlichen Formulierung expliziert. Die Modellierung erfolgt demnach
in den zwei Phasen Konzeptualisierung und Formalisierung, wobei die Konzeptualisierung in
die Teilphasen der mentalen und natürlichsprachlichen Modellkonstruktion unterteilt werden
212 Schütte (Grundsätze 1998), S. 54. Obwohl Vertreter des abbildungsorientierten Modellbegriffs, räumen auch FERSTL/SINZ ein: „Streng genommen bedingt bereits die Betrachtung eines Systems den Aufbau eines gedanklichen Modells.“. Ferstl, Sinz (Grundlagen 1998), S. 18 213 Vgl. Bretzke (Problembezug 1980), S. 30f.; Zelewski (Bezugsrahmen 1995), Fußnote 7, S. 24; Zelewski (Grundlagen 1999), S. 46. WEDEKIND U. A. bezeichnen das abbildungsorientierte Modellverständnis aus erkenntnistheoretischer Sicht als naiv-realistisches Modellverständnis. Vgl. Wedekind u. a. (Modellierung 1998), S. 266f. 214 Vgl. Schütte (Grundsätze 1998), S. 49 215 Vgl. Bretzke (Problembezug 1980), S. 32f. 216 Vgl. Zelewski (Grundlagen 1999), S. 46 217 Schütte (Grundsätze 1998), S. 59
67
kann (vgl. Abb. 3.2).218 In der Konzeptualisierungsphase bildet der Modellierer aufgrund
seiner Wahrnehmungen ein subjekt- und zweckabhängiges mentales (internes) Modell vom
betrachteten Realweltausschnitt. Geleitet wird der Modellierer dabei von bestimmten
Deutungsmustern, worunter hier die Art und Weise, die Dinge zu sehen, verstanden wird.219
„Deutungsmuster entscheiden nicht nur [...] darüber, was wahrgenommen wird, sondern auch
darüber, als was der Gegenstand der Wahrnehmung zu denken ist.“220 Die Wahl des
Deutungsmusters bestimmt die grundsätzliche Sichtweise auf den zu modellierenden
Gegenstand.
Unterschieden werden sollen materiell- und formalorientierte Deutungsmuster. Materiell-
orientierte Deutungsmuster orientieren sich an der Sprach- und Denkwelt der betrachteten
Anwendungsdomäne. Im Gegensatz dazu enthält ein formalorientiertes Deutungsmuster
abstrakte Elemente, wie etwa „Objekt“ oder „Klasse“ ohne sprachlichen und inhaltlichen
Bezug zum betrachteten Realweltausschnitt.
natürlich-sprachliches
Modell
formal-sprachliches
Modell
Original Internes Modell Externe Modelle
KonzeptualisierungFormalisierung
MentaleModellkonstruktion
NatürlichsprachlicheModellkonstruktion
internes(mentales)
Modell Trans-formation
Expli-kation
Konstruktion
Abb. 3.2 Phasen der Modellkonstruktion221
Das zunächst gebildete mentale Modell wird erst durch Explikation in einer natürlichsprach-
lichen Form kommunizierbar.222 Das natürlichsprachliche Modell223 wird in der
218 Vgl. Zelewski (Bezugsrahmen 1995), S. 15f.. Vgl. ähnlich FISCHER, der in Anlehnung an KOSIOL (vgl. Kosiol (Modellanalyse 1961), S. 320f.) die Stufen mentales, verbales und formales Modell unterscheidet. Vgl. Fischer (Ziele 1989), S. 217ff. 219 Vgl. Bretzke (Problembezug 1980), S. 42. FISCHER verwendet dafür den Begriff 'Konstruktionsweltsicht'. Vgl. Fischer (Datenmanagement 1992), S. 78ff. 220 Bretzke (Problembezug 1980), S. 42f. (Hervorhebungen im Original) 221 In Anlehnung an Schütte (Grundsätze 1998), S. 61 222 Vgl. Fischer (Ziele 1989), S. 213ff.; Zelewski, Schütte, Siedentopf (Ontologien 1999), S. 3f. „Zur Mitteilung
68
Formalisierungsphase mittels einer (formalen) Modellierungssprache in ein formales Modell
transformiert. Die idealisiert dargestellte strenge sequentielle Abfolge stellt sich in der
Modellierungspraxis wohl eher als iteratives Vorgehen mit Rückkopplungsschleifen zwischen
den einzelnen Phasen dar.224
Die Modellierung ist nach dem hier vertretenen Verständnis des konstruktionsorientierten
Modellbegriffs eine kreative, gestaltende Tätigkeit und damit keine leichte Aufgabe.
Erforderlich sind Modellierungsmethoden, die dem Modellierer ein begründetes, planmäßiges
Vorgehen nach festgelegten Regeln, die sich an den Modellierungszielen orientieren,
vorgeben. Der Entwurf einer solchen Modellierungsmethode zur Integration
zwischenbetrieblicher Informationsflüsse ist das erklärte Ziel dieser Arbeit.
Modellierungsmethoden225 im Rahmen der Informationssystemgestaltung bestehen aus einer
Modellierungssprache und einer Vorgehensweise.226 Zur Modellierungssprache gehört eine in
der Regel grafische Notation und die Beschreibung der Syntax dieser Notation. Letztere wird
in der Wirtschaftsinformatik üblicherweise als Metamodell bezeichnet.227 Dieser
Sprachkonvention wird hier gefolgt. Zur Beschreibung der Vorgehensweise228 gehören die
Modellierungsschritte sowie die Festlegung ihrer Abfolge und ihrer Ergebnisse.229 Ergebnisse
der einzelnen Modellierungsschritte sind Modelle oder Teile von Modellen, die als Input des
folgenden Schrittes dienen können. Idealerweise, aber nicht zwingend, wird eine
Modellierungsmethode durch ein computergestütztes Modellierungswerkzeug unterstützt.
Zur Systematisierung und Einordnung unterschiedlicher Modelltypen werden folgende
wichtige Klassifizierungsmerkmale von Modellen im Rahmen der
Informationssystemgestaltung und deren mögliche Ausprägungen, die für die vorliegende
an andere bedarf das Modell als Gedankengebilde des sinnfälligen Ausdrucks, der Symbolisierung.“ Kosiol (Modellanalyse 1961), S. 320 223 KOSIOL spricht auch vom verbalen Modell. Vgl. Kosiol (Modellanalyse 1961), S. 320 224 Vgl. Zelewski (Bezugsrahmen 1995), S. 16 225 Zum allgemeinen Methodenbegriff vgl. Fischer (Informationswirtschaft 1999), S. 203: „[Methoden] sind auf einen weiten Anwendungsbereich bezogen und dort begründete, planmäßig angewandte Vorgehensweisen zur Erreichung von definierten Zielen. Sie beschreiben den Anfangszustand, das Ziel und den Weg dahin.“ Vgl. ähnlich Balzert (Analysemodell 1997), S. 38; Zelewski (Grundlagen 1999), S. 34 226 Vgl. Heß, Scheer (Methodenvergleich 1992), S. 120; Mertins, Süssenguth, Jochem (Modellierungsmethoden 1994), S. 11; Bungert, Heß (Geschäftsprozeßmodellierung 1995), S. 52; Reinhold (UML 1997), S. 70 227 Vgl. Bach, Brecht, Österle (Marktstudie 1995), S. 16f.; Schütte (Grundsätze 1998), S. 68 228 Statt von einer Vorgehensweise wird teilweise auch von einem Vorgehensmodell gesprochen. Vgl. Bach, Brecht, Österle (Marktstudie 1995), S. 16; Fischer (Informationswirtschaft 1999), S. 208. Dieser Begriff wird abgelehnt, da der Modellbegriff anders als hier interpretiert wird. 229 Vgl. Bach, Brecht, Österle (Marktstudie 1995), S. 16. Dort wird der Begriff ‚Aktivitäten‘ statt
69
Arbeit von Bedeutung sind, näher erläutert: Aussagenstufe der Sprache, Abstraktionsgrad vom
Original, Nähe zur Informationstechnik, Geltungsanspruch, inhaltliche Individualität, Sicht
auf das Original sowie Zweck des Modells (vgl. Tab. 3-1).
Nach der Aussagenstufe der Sprache230 eines Modells kann unterschieden werden, ob es sich
um ein Objekt-, Meta- oder Meta-Metamodell handelt. Objektmodelle sind Modelle der
objektsprachlichen Ebene (Sprachstufe 1) und enthalten Aussagen über Dinge und
Sachverhalte des modellierten Anwendungsbereichs (Sprachstufe 0). Metamodelle dagegen
enthalten Aussagen über Objektmodelle und sind damit Modelle der metasprachlichen Ebene
(Sprachstufe 2). Modelle zur Spezifikation einer Modellierungssprache (s. o.) sind damit
spezielle Ausprägungen von Metamodellen. Aussagen über ein Metamodell können in einem
Meta-Metamodell festgehalten werden. Dies kann so fortgeführt werden.
Modelle können hinsichtlich des Abstraktionsgrads vom Original als Modelle auf
Ausprägungs-, Typ- oder Konstruktebene eingeordnet werden.231,232 Bei Modellen auf
Ausprägungsebene erhält jedes Element des Originals eine Repräsentation im Modell. Bei
Modellen der Typebene wird eine Menge von Elementen (des Originals) aufgrund von
Gemeinsamkeiten zu Typen zusammengefasst.233 Eine Kombination von Typen führt zu
Konstrukten.234 Modelle auf Ausprägungsebene werden beispielsweise bei Simulationen
eingesetzt.235 Im Rahmen Gestaltung von Informationssystemen werden in der Regel Modelle
auf Typebene betrachtet.
‚Modellierungsschritte‘ verwendet. 230 Vgl. Ortner (Repository 1999), S. 238ff. 231 Vgl. Fischer (Datenmanagement 1992), S. 80ff. FISCHER verwendet allerdings statt ‚Ausprägungsebene‘ den Begriff ‚Realebene‘, der hier aber aufgrund des konstruktionsorientierten Modellverständnisses abgelehnt wird. Statt von ‚Konstruktebene‘ spricht SCHÜTTE von „einer höheren Abstraktionsstufe als Modelle auf Typebene,“ auf der Cluster gebildet werden. Vgl. Schütte (Grundsätze 1998), S. 64 und S. 66f. 232 Die unter dem Kriterium Abstraktionsgrad oftmals vorgenommene Einteilung in Ausprägungs-, Typ-, Meta- und Meta-Metaebene (vgl. z. B. Rosemann (Komplexitätsmanagement 1996), S. 36ff.; Rundshagen (Konsistenzsicherung 1996), S. 62; Ferstl, Sinz (Grundlagen 1998), S. 121f.) wird nicht nachvollzogen, da hierbei ein Wechsel des betrachteten Originals erfolgt. Der modellierte Realweltausschnitt ist das Original eines Modells auf Ausprägungs- oder Typebene. Original eines Metamodells ist allerdings ein anderes Modell, also nicht der betrachtete Realweltausschnitt. Demnach kann also auch nicht von einem höheren Abstraktionsgrad bezüglich des ursprünglichen Originals gesprochen werden. 233 Vgl. Fischer (Datenmanagement 1992), S. 81; Scheer (Architektur 1992), S. 7; Rosemann (Komplexitätsmanagement 1996), S. 36; Schütte (Grundsätze 1998), S. 64 und S. 66. 234 Vgl. Fischer (Datenmanagement 1992), S. 81. Eine Verdichtung von Typen als Form der Hierarchisierung von Systemen wird von SCHÜTTE als ‚Cluster‘ bezeichnet. Vgl. Schütte (Grundsätze 1998), S. 67 235 Vgl. Rosemann (Komplexitätsmanagement 1996), S. 36
70
In Anlehnung an SCHEER sollen nach der Nähe zur Informationstechnik Fachkonzept-, DV-
Konzept- und Implementierungsmodelle unterschieden werden.236 Fachkonzeptmodelle - im
folgenden fachkonzeptuelle Modelle genannt237 - sind Ausgangspunkt für den Entwurf von
Informationssystemen. Sie sind durch betriebswirtschaftlich-organisatorische Inhalte
gekennzeichnet und sind unabhängig von bestimmten informationstechnischen Lösungen.
DV-Konzeptmodelle sind gegenüber fachkonzeptuellen Modellen um Anforderungen und
Restriktionen der DV-technischen Umsetzung angereichert. Allerdings werden auch in ihnen
noch keine Implementierungsdetails berücksichtigt. Dies geschieht erst in den
Implementierungsmodellen, mit denen eine konkrete DV-technische Umsetzung formuliert
wird.
Nach dem Geltungsanspruch können Ist- und Sollmodelle unterschieden werden.238 Istmodelle
geben den zum Zeitpunkt der Modellierung vom Modellierer interpretierten Zustand der
Realwelt wieder. Sollmodelle dagegen stellen Idealvorstellungen eines Modellierers dar und
eignen sich beispielsweise zur Spezifikation strategischer Zielsetzungen239 oder zur
Formulierung von Gestaltungsvorgaben.
Das Merkmal der inhaltlichen Individualität240 unterscheidet Modelle danach, ob sie für einen
bestimmten Einzelfall Gültigkeit besitzen oder für eine Klasse von Situationen. Bei ersteren
handelt es sich um Einzelfallmodelle. Die sonst übliche Bezeichnung als
unternehmensspezifische Modelle erscheint im Kontext zwischenbetrieblicher Modelle nicht
angebracht. Ein Modell für eine Klasse von Situationen soll als Referenzmodell bezeichnet
werden. Es zeichnet sich im Vergleich zu einem Einzelfallmodell durch einen höheren
Anspruch an Allgemeingültigkeit aus.241
Aus Gründen der Komplexitätsreduzierung und zur Vermeidung von Redundanzen können
unterschiedliche Sichten auf das Original gebildet werden.242 In Anlehnung an die System-
theorie werden grundsätzlich strukturorientierte und verhaltensorientierte Sichten
236 Zu den folgenden Ausführungen vgl. Scheer (ARIS 1998), S. 39ff. 237 Auch konzeptionelle, konzeptuelle oder semantische Modelle genannt. Vgl. Rosemann (Komplexitätsmanagement 1996), S. 29 238 Vgl. Rosemann (Komplexitätsmanagement 1996), S. 22; Schütte (Grundsätze 1998), S. 65 239 Vgl. Schütte (Grundsätze 1998), S. 66 240 Auch ‚inhaltliche Breite’. Vgl. Schütte (Grundsätze 1998), S. 66 241 Vgl. Rosemann (Komplexitätsmanagement 1996), S. 34 242 Vgl. Scheer (Architektur 1992), S. 13ff.; Picot, Maier (Ansätze 1994), S. 113; Rosemann (Komplexitätsmanagement 1996), S. 22; Sinz (Architektur 1997), S. 876f.; Schütte (Grundsätze 1998), S. 64; Fischer (Informationswirtschaft 1999), S. 61
71
unterschieden.243 Die Abgrenzung zwischen Struktur- und Verhaltenssicht ist allerdings nicht
immer eindeutig zu treffen. Aus Modellen der Verhaltenssicht sind auch Rückschlüsse auf die
Strukturen möglich und umgekehrt.244 Neben der Unterscheidung zwischen Struktur- und
Verhaltenssicht erfolgt von einigen Autoren eine differenziertere Einteilung von
Modellsichten,245 welche an dieser Stelle aber nicht vorgenommen werden soll.
Modelle werden in der Wirtschaftsinformatik zum Zweck der Analyse, des Entwurfs oder der
Dokumentation von Informationssystemen erstellt.246 Istmodelle beschreiben den „Status
Quo“ eines Informationssystems aus Sicht des Modellierers und dienen damit der Analyse.
Sollmodelle gehen darüber hinaus, indem durch die Veränderung eines bestehenden (Ist-
)Modells oder durch eine deduktive Modellierung Lösungsideen und Optionen für den
Entwurf des Informationssystems formuliert werden.247 Außerdem können Modelle zur
Dokumentation eines Informationssystems erstellt werden.
Merkmal Ausprägungen Aussagenstufe der Sprache
Objektmodell Metamodell Meta-Metamodell
Abstraktionsgrad vom Original
Ausprägungsebene Typebene Konstruktebene
Nähe zur Informationstechnik
Fachkonzept DV-Konzept Implementierung
Geltungsanspruch
Istmodell Sollmodell
Inhaltliche Individualität
Einzelfallmodell Referenzmodell
Sicht auf das Original
Struktursicht Verhaltenssicht
Zweck
Analyse Entwurf Dokumentation
Tab. 3-1 Verwendung des Modellbegriffs248
Modelle finden im Rahmen der vorliegenden Arbeit in dreierlei Form Verwendung (vgl.
Kapitel 4). Erstens erfolgt die Spezifikation der Modellierungssprache der zu entwickelnden
243 Vgl. Ferstl, Sinz (Ansatz 1995), S. 218; Schütte (Grundsätze 1998), S. 64 244 So ordnen zum Beispiel FERSTL/SINZ die Funktionssicht der Struktursicht zu, vgl. Ferstl, Sinz (Grundlagen 1998), S. 125), während SCHÜTTE die Funktionssicht als eine Verhaltenssicht einordnet, vgl. Schütte (Grundsätze 1998), S. 65 245 Vgl. Zachman (Framework 1987), S. 277ff.; Scheer (Architektur 1992), S. 13ff.; Ferstl, Sinz (Grundlagen 1998), S. 124f.; Fischer (Informationswirtschaft 1999), S. 61ff. 246 Vgl. Hars (Referenzdatenmodelle 1994), S. 29; Oberweis (Modellierung 1996), S. 19ff. 247 Vgl. Rosemann (Komplexitätsmanagement 1996), S. 19f.; Becker (Referenzmodellierung 1998), S. 1-2 248 Die grau schattierten Modellausprägungen finden in der vorliegenden Arbeit Verwendung.
72
Modellierungsmethode mit Hilfe von Modellen. Dazu werden Metamodelle auf Typebene
eingesetzt. Zum zweiten sind Referenzmodelle Bestandteile der Modellierungsmethode. Es
handelt sich dabei um objektsprachliche Sollmodelle aus einer Struktursicht auf Typ- und
Fachkonzeptebene. Drittens sind objektsprachliche Einzelfallmodelle das Ergebnis bei
Anwendung der Modellierungsmethode. Diese ebenfalls auf Typ- und Fachkonzeptebene zu
erstellenden Modelle sollen dem Entwurf zwischenbetrieblicher Informationsflüsse dienen.
Sie sind Sollmodelle sowohl für die Struktur- als auch Verhaltenssicht.
3.1.2 Ontologiebasierte und referenzgestützte Modellierung
Die meisten Modellierungsmethoden gehen von einer Singularität des Modellierers aus.249
Hierbei konstruiert eine einzige Person ein Modell aus seiner subjektiven Sicht. Diese Situa-
tion ist bei einer Integration zwischenbetrieblicher Informationsflüsse nicht gegeben.
Vielmehr sind eine Vielzahl von Personen aus verschiedenen Betrieben beteiligt. Nach dem
dargelegten Modellverständnis ist jedoch offensichtlich, dass Modellierer aus verschiedenen
Betrieben zu unterschiedlichen Modellen der gleichen, zwischenbetrieblichen Transaktionen
gelangen können. Dies ist bei einem modellbasierten Entwurf gemeinsamer
Informationsflüsse problematisch und nicht akzeptabel.
Probleme können aufgrund abweichender subjektiver Erfahrungen und unterschiedlichen
Wissensständen in allen Modellierungsphasen auftreten. Dazu gehören unterschiedliche
Konzeptualisierungen des gleichen Realweltausschnitts, das Verwenden unterschiedlicher
Terminologien mit Synonymen und Homonymen sowie die unterschiedliche Anwendung
einer Modellierungssprache. Damit diese Probleme nicht auftreten, ist sowohl die
Konzeptualisierungs- als auch die Formalisierungsphase durch geeignete methodische
Maßnahmen und Hilfsmittel zu unterstützen. Zu solchen Maßnahmen zählen Ansätze einer
ontologiebasierten und referenzgestützten Modellierung, welche daher nachfolgend vorgestellt
werden sollen. Während Ontologien die Konzeptualisierungsphase einer Modellierung
unterstützen, dienen Referenzmodelle vor allem der Unterstützung in der
Formalisierungsphase.
249 Vgl. Krcmar, Schwarzer (Unternehmensmodellierung 1994), S. 25
73
Ontologiebasierte Modellierung
Der Begriff ‚Ontologie‘ entstammt der Philosophie und bezeichnet ursprünglich die „Lehre
vom Sein, von den Ordnungs-, Begriffs- u. Wesensbestimmungen des Seienden“.250 Die
Ontologie weist eine lange Tradition auf, denn bereits Aristoteles hat sich in der Antike mit
ontologischen Fragestellungen beschäftigt.251
Im Zuge der Forschungen auf dem Gebiet der Künstlichen Intelligenz (KI), insbesondere der
Multi-Agenten-Systeme, wurde Mitte der achtziger Jahre des 20. Jahrhunderts das Interesse
an der Ontologie neu geweckt. Dies geschah vor allem im Zusammenhang mit der Frage-
stellung, „wie sich die ‚Weltwahrnehmungen‘ artifizieller Agenten formalsprachlich
beschreiben und [...] aufeinander abstimmen lassen.“252 Inzwischen wird die
Ontologiediskussion auch in der Wirtschaftsinformatik unter Themen wie
Wissensmanagement, Knowledge Sharing oder Referenzmodellierung geführt.
Mit der Übernahme des Ontologiebegriffs in die KI und Wirtschaftsinformatik geht ein
Bedeutungswandel einher. Ontologie wird nicht mehr im Singular als „die Lehre vom Sein“
gebraucht, sondern es wird in der Mehrzahl von Ontologien gesprochen. Der Ontologiebegriff
wird hier weit gefasst und meint, in Anlehnung an GRUBER, eine explizite Spezifikation einer
von mehreren Personen gemeinsam verwendeten Konzeptualisierung von Phänomenen der
Realwelt.253 Eine Ontologie besteht aus den wesentlichen Begriffen einer Domäne, ihrer
Definitionen sowie den Beziehungen zwischen den Begriffen.254 Damit wird Ontologie „nicht
mehr als ‚Wesensschau‘ des Seienden betrieben, sondern Ontologien werden von Akteuren
zweckrational gestaltet.“255
Zum Verständnis von Ontologien soll an dieser Stelle das von Ogden und Richards
vorgeschlagene256 und von vielen anderen Autoren übernommene semantische Dreieck257 zu
Begriffen angeführt werden (vgl. Abb. 3.3). Danach konstituiert sich ein Begriff aus den
Dimensionen Begriffsinhalt, Begriffsumfang und Begriffsbezeichnung. Die Grundidee ist, dass
250 Drosdowski u. a. (Duden 1990), S. 551 251 Vgl. Zelewski, Schütte, Siedentopf (Ontologien 1999), S. 1 252 Zelewski, Schütte, Siedentopf (Ontologien 1999), S. 2 253 Vgl. Gruber (Principles 1993), S. 1. Vgl. ähnlich Guarino (Matching 1997), S. 142; Berghoff, Drobnik (Aufbau 1999), S. 1; Frank, Schauer (Potentiale 1999), S. 7 254 Vgl. Uschold, Gruninger (Ontologies 1996), S. 5 255 Zelewski, Schütte, Siedentopf (Ontologien 1999), S. 2 256 Vgl. Ogden, Richards (Meaning 1969), S. 11 257 Vgl. u. a. Kroeber-Riel (Sprachkritik 1969), S. 26; Ortner (Aspekte 1983), S. 36; Dahlberg (Definitionstheorie 1985), Sp. 96ff.. Gelegentlich wird es auch als ‚semiotisches Dreieck’ bezeichnet.
74
materielle oder immaterielle Gegenstände bzw. Objekte der realen Welt, die gleiche
Merkmale und Eigenschaften aufweisen, zu Denkeinheiten (Konzeptualisierungen)
zusammengefasst werden. Die Gesamtheit der Merkmale, die einen Begriff von einem
anderen abgrenzt, ist der Begriffsinhalt (Intension).258 Die Begriffsbezeichnung als "sinnlich
wahrnehmbare Repräsentation von Begriffen"259 dient der sprachlichen Explikation eines
Begriffs. Geht man von der Bezeichnung eines Begriffs aus, so kann der Begriffsinhalt als
Bedeutung oder Sinn dieser Bezeichnung verstanden werden.260 Alle Gegenstände, die
sämtliche Merkmale eines Begriffs besitzen, fallen unter diesen Begriff und bilden den
Begriffsumfang (Extension).261 Je spezifischer der Begriffsinhalt definiert ist, desto geringer
ist der Begriffsumfang und umgekehrt, d. h. bei sinkender Anzahl von Begriffsmerkmalen
vergrößert sich die Menge der Gegenstände, die unter einen Begriff fallen.
Bedeutung/ Inhalt/ Intension
Bezeichnung/Zeichen
Gegenstand/Objekt/ Extension
Abb. 3.3 Semantisches Dreieck262
Nach diesem Verständnis sind Inhalte bzw. Intensionen von Begriffen - und nicht deren
Bezeichnungen - zentraler Gegenstand von Ontologien. Durch eine Ontologie werden die
Begriffe einer Domäne nach ihren Inhalten, d. h. Merkmalen und Eigenschaften, geordnet. Im
Rahmen einer zwischenbetrieblichen Modellierung kann durch eine Ontologie eine
Standardisierung auf fachkonzeptueller Ebene erfolgen. Durch sie sollen divergente
Begriffsverständnisse bzw. Konzeptualisierungen der betrieblichen und zwischenbetrieblichen
Realwelt durch
unterschiedliche Modellierer vermieden werden.263 In der Phase der natürlichsprachlichen
258 Vgl. o.V. (DIN2330 1979), S. 2 259 Vgl. o.V. (DIN2330 1979), S. 2 260 Vgl. Wüster (Einführung 1979), S. 7 261 Vgl. o.V. (DIN2330 1979), S. 2 262 Vgl. Brenner (Entwurf 1985), S. 59 263 Vgl. Frank, Schauer (Potentiale 1999), S. 7; Zelewski, Schütte, Siedentopf (Ontologien 1999), S. 4
75
Modellkonstruktion kann eine Ontologie die Verwendung einer einheitlichen Terminologie
für bestimmte Begriffe sicherstellen.
Nach dem Gegenstandsbereich können Top-level- bzw. Commonsense-, Domänen-,
Aufgaben- und Applikationsontologien unterschieden werden.264 Top-level- oder auch
Commonsense-Ontologien beschreiben sehr allgemeine Begriffe ohne konkreten Bezug zu
einem bestimmten Anwendungs- oder Fachgebiet. Sie enthalten somit „allgemeines
Weltwissen“ bzw. „selbstverständliches Hintergrundwissen“.265 Domänenontologien dagegen
werden für bestimmte Anwendungsbereiche entwickelt und enthalten die wesentlichen
Begriffe einer Domäne. Zur Spezifikation von allgemeinen Aufgabentypen, „die in
unterschiedlichen Anwendungsdomänen in jeweils ähnlicher Art auftreten und erfüllt werden
müssen (wie z. B. Diagnoseaufgaben, die sowohl in medizinischen als auch in technischen,
aber auch in betriebswirtschaftlichen Bereichen große Bedeutung besitzen)“, dienen
Aufgabenontologien.266 Schließlich enthalten Applikationsontologien Spezialisierungen
sowohl von bestimmten Domänen- als auch Aufgabenontologien. Sie entsprechen oftmals
Rollen, die Gegenstände einer Domäne bezüglich einer bestimmten Aktivität übernehmen,
wie beispielsweise „drehbar“, „zeichenbar“ oder „speicherbar“.267
Referenzgestützte Modellierung
Wie im Abschnitt 3.1.1 bereits erwähnt, werden Modelle für eine Klasse von
Anwendungsfällen als Referenzmodelle bezeichnet. Sie zeichnen sich im Vergleich zu
Einzelfallmodellen durch einen höheren Anspruch an Allgemeingültigkeit aus.268 Eine weitere
Anforderung an Referenzmodelle ist, sie in ein spezifisches Einzelfallmodell überführen zu
können (Anpassbarkeit).269 Referenzmodelle bilden damit Ausgangslösungen, aus denen sich
wirtschaftlich individuelle Modelle ableiten lassen.270 Sie können während der
Formalisierungsphase einer verteilten Modellierung zwischenbetrieblicher Informationsflüsse
264 Vgl. Guarino (Matching 1997), S. 144f.; Zelewski, Schütte, Siedentopf (Ontologien 1999), S. 7f. 265 Vgl. Zelewski, Schütte, Siedentopf (Ontologien 1999), S. 7 266 Vgl. Zelewski, Schütte, Siedentopf (Ontologien 1999), S. 7. Vgl. ähnlich Guarino (Matching 1997), S. 145 267 Vgl. Guarino (Matching 1997), S. 145 268 Vgl. Hars (Referenzdatenmodelle 1994), S. 15 269 Vgl. Hars (Referenzdatenmodelle 1994), S. 15; Nonnenmacher (Informationsmodellierung 1994), S. 24f.; Sinz (IS-Architekturen 1996), S. 5 270 Vgl. Becker u. a. (Referenz-Informationsmodellierung 2000), S. 90
76
das Risiko einer unterschiedlichen Anwendung von Modellierungskonstrukten durch
verschiedene Modellierer vermindern.271
Es gibt verschiedene Ansätze einer referenzgestützten Modellierung, die sich durch die Art
des Referenzmodells und durch den daraus resultierenden Vorgang der
Referenzmodellanwendung unterscheiden (vgl. Tab. 3-2).
Art des Referenzmodells Referenzmodellanwendung
Referenzbausteine Komposition
Generisch Konfiguration und Anpassung Komplettes
Referenzmodell Nicht-generisch Anpassung
Tab. 3-2 Ansätze einer referenzgestützten Modellierung
Nach Art des Referenzmodells können Referenzbausteine oder komplette Referenzmodelle
unterschieden werden. Unter Referenzbausteinen sollen einzelne Modellierungselemente oder
-konstrukte verstanden werden, die im Rahmen der Referenzmodellanwendung zu einem
Gesamtmodell zusammengesetzt werden.272 Im Gegensatz zu diesem kompositionellen Ansatz
steht die Bereitstellung nicht nur einzelner Modellierungselemente oder -konstrukte sondern
kompletter Referenzmodelle. Dabei können generische von nicht-generischen
Referenzmodellen unterschieden werden.273 Generische Referenzmodelle enthalten Varianten,
die bei der Adaption über explizit definierte Merkmale auswählbar sind.274 Der Vorgang der
Referenzmodellanwendung stellt sich bei dieser Art von Referenzmodellen als Konfiguration
und Anpassung dar. Bei der Konfiguration wird ein Referenzmodell zunächst automatisch
bzw. halbautomatisch auf die Bedürfnisse eines spezifischen Modellierungsproblems
angepasst, indem der Modellanwender die für ihn relevanten Merkmalsausprägungen
selektiert hat.275 In einem zweiten Schritt erfolgt eine manuelle Anpassung zur Überführung
des Referenzmodells in ein Einzelfallmodell. Nicht-generische Referenzmodelle enthalten
dagegen keine Varianten und können daher direkt als Einzelfallmodell übernommen und
angepasst werden.
271 Vgl. Schüppler (Informationsmodelle 1998), S. 168f. 272 Vgl. Becker u. a. (Referenz-Informationsmodellierung 2000), S. 91 273 Vgl. Sinz (IS-Architekturen 1996), S. 5 274 Vgl. Becker u. a. (Referenz-Informationsmodellierung 2000), S. 90 275 Vgl. Schütte (Grundsätze 1998), S. 316f.
77
3.2 Grundlegender Ansatz einer Modellierungsmethode zur Integration
zwischenbetrieblicher Informationsflüsse
In diesem Abschnitt soll der grundlegende Ansatz einer Modellierungsmethode zur Inte-
gration zwischenbetrieblicher Informationsflüsse, der in dieser Arbeit verfolgt wird,
vorgestellt werden. Die zu entwickelnde Modellierungsmethode soll Betriebe, die ihre
zwischenbetrieblichen Informationsflüsse integrieren möchten, bei der Gestaltung, d. h. der
Konzeption und dem Entwurf dieser Informationsflüsse unterstützen. Dabei sollen im
Wesentlichen zwei Ziele verfolgt werden. Erstens soll eine effektive und zweitens eine
effiziente Integration der zwischenbetrieblichen Informationsflüsse erreicht werden. Effektiv
heißt, dass ein hoher Integrationsgrad (vgl. Abschnitt 2.3) angestrebt wird. Die Effizienz
bezieht sich sowohl auf die für ein Integrationsvorhaben benötigte Zeit als auch auf die
Kosten. Beides soll möglichst niedrig gehalten werden. Die Modellierungsmethode soll die
betroffenen Betriebe also anleiten, ihre Informationsflüsse derart zu gestalten, dass eine
technische, syntaktische, semantische und pragmatische Integration auf wirtschaftliche Weise
erreicht wird. Aufgrund der Modellierung sollen Integrationslösungen so umgesetzt werden,
dass Nachrichten vom Anwendungssystem eines Senderbetriebes elektronisch versendet und
übertragen, fehlerfrei in das Anwendungssystems eines Empfängerbetriebes übernommen und
dort automatisiert weiterverarbeitet werden können.
Bei dem propagierten Ansatz (vgl. Abb. 3.4) wird zwischen einer Entwurfs- und einer
Betriebsphase unterschieden.
In der Entwurfsphase sollen die Abläufe und Informationsflüsse einer zwischenbetrieblichen
Transaktion als (Soll-)Modell konstruiert werden. Auf Basis der Modellierungsergebnisse
sollen im weiteren die erforderlichen Nachrichten in ihren Inhalten und Strukturen durch
Nachrichtenschemata beschrieben werden. Grundgedanke dieser modellgestützten Ableitung
der Nachrichtenstrukturen ist, dass sich zwischenbetriebliche Informationsflüsse auf
bestimmte Gegenstände und Geschehnisse der realen Geschäftswelt beziehen. Da diese zuvor
als Modell konstruiert wurden, kann folglich auch zwischen den Nachrichtenschemata und
dem Modell der zwischenbetrieblichen Transaktion ein Bezug hergestellt werden. Schließlich
sollen die fachlichen Aufgaben einer Integration zwischenbetrieblicher Informationsflüsse
unterstützt werden. Darunter fallen sämtliche Aspekte, die für eine syntaktische, semantische
und pragmatische Integration relevant sind. Sie sollen durch die zu entwickelnde
Modellierungsmethode beschrieben werden können. Wie die Untersuchung vorhandener
78
Integrationsansätze gezeigt hat (vgl. Abschnitt 2.6), sind die Aufgaben und die mit ihr
verbundenen Probleme einer technischen Integration weitgehend gelöst. Die technische
Integration bedarf daher keiner Unterstützung durch die Modellierungsmethode.
Entwurfs-phase
Betriebs-phase
Gro ßh ande ls-zen trale
AB C-Zent rale(Käuf er:
Auf tra gg eber,Re ch nu ngs-empf än ger,Za hl ungs-
sen de r)
2. ab rufe n ( D)
3. L ief eru ng mi ttei len (D)
4 . lie fer n ( D)
1. bea uf trag en (V )
5. fakturi ere n ( D)
6. W a ren ein gan g m el den (K )
Ein ze lhand el s-f ilia le
AB C-F ili ale(K äu fer:
Wa re nem pfä nger)
7. za hle n (D )
Industri e-unte rnehm enM olkerei(V erkä uf er)
(Ein zel handelsfi l iale)
A llBuy-Filiale
(Waren emp fän ger )
(I ndustr ie-unt erne h me n)
Großbäcker
(Au ftragneh me r,Wa rense nd er,
Rec hnungsste ller ,Z ahlun g sem pfänge r )
(Ku rzau ft rag)Lieferabruf Backwaren
(Lie ferab ruf )
Internet
B ackwaren abrufen(ab rufen )
(Lie fermeld ung)Lieferavis Backw aren
(Lie fe ra vis)
Internet
B ackwaren avisieren(Lie ferun g m itte ilen)
Modellentwurf Nachrichten-schemata
Großha nd els-ze nt ral e
A B C- Zentral e(K äu fe r:
Au ftragge be r,Rechnun gs -e mp fäng er ,Za hlu ng s-
se n der)
2 . a bru fen (D)
3 . Li efe run g m i tt eile n (D )
4. lief ern (D )
1 . b eau f tra ge n ( V)
5 . f akt uri e ren (D)
6 . W are ne ing ang m eld en (K)
Ei nzelh an dels-fil iale
A B C- F iliale(Käufe r:
Wa ren em p fän ge r)
7. z ah len (D)
In du st rie-u nt ern eh m en
M olke rei(V er kä ufe r)
(Ein zel handelsf il iale)
A llBuy-F iliale
(Waren emp fän ger )
(I ndustr ie-unt erne hme n )
Großbäcker
(Au ftragneh me r,W arens end er,
Re chnungsste ller ,Z ahlung sem pfäng e r)
(Ku rzau ft ra g)Lief erabruf Backwaren
(Liefera bruf )
Internet
B ackwaren abrufen(abrufen )
(Lie ferm eld ung )Lieferavis B ackwaren
(Lie fera vis)
Internet
B ackwaren avisieren(Lieferu ng mitte ilen)
ModellentwurfNachrichten-schemata
Empfängerbetrieb
Nachricht
Referenz-bausteine
Senderbetrieb
istInstanz
von
wirdinterpretiertdurch
abgeleitetaus
abgeleitetaus
basiert auf basiert auf
Abb. 3.4 Grundlegender Ansatz der zu entwickelnden Modellierungsmethode
In der Betriebsphase sollen Nachrichten gemäß dem Modellentwurf elektronisch zwischen
den Anwendungssystemen ausgetauscht werden. Vom Anwendungssystem des
Senderbetriebes wird eine Nachricht als Instanz eines bestimmten Nachrichtenschemas
versendet. Dabei ist das Nachrichtenschema zusammen mit der Nachricht zu versenden oder
zuvor dem
Empfänger bekanntzumachen. Nach einem Abgleich mit dem erwarteten Nachrichtenschema
soll die Nachricht schließlich vom Anwendungssystem des Empfängerbetriebes interpretiert
und automatisch verarbeitet werden.
Da eine gemeinsame, zentrale Modellierung, bei der die beteiligten Betriebe physisch an
einem Ort zusammensitzen, um ihre Transaktionen und zwischenbetrieblichen
Informationsflüsse zu entwerfen, zu zeitaufwendig und damit zu kostspielig ist, soll
stattdessen eine dezentrale, verteilte Modellierung vorgesehen werden. Hierbei erstellt jeder
Betrieb für sich ein Modell seiner zwischenbetrieblichen Transaktionen und spezifiziert vor
diesem Hintergrund die erforderlichen Nachrichtenschemata.
79
Es ist nach dem in Abschnitt 3.1.1 dargelegten Modellverständnis offensichtlich, dass
Modellierer aus verschiedenen Betrieben dabei zu unterschiedlichen Modellen gelangen
können. Damit dennoch zueinander kompatible Modelle entstehen und ein Empfänger
während der Betriebsphase gesendete Nachrichten richtig interpretieren kann, ist es
erforderlich, dass zur Definition der Nachrichtenschemata bzw. für die vorgelagerten
Modellentwürfe eine gemeinsame Basis vorhanden ist. Neben einer gemeinsamen
Modellierungssprache bzw. einem gemeinsamen Metamodell soll diese Basis aus einem
gemeinsamem Vorrat semantisch eindeutig definierter Modellierungselemente - sogenannter
Referenzbausteine - bestehen. Bei letzteren handelt es sich um standardisierte
Referenzbausteine auf fachkonzeptueller Ebene.
Im Rahmen des vorgestellten Ansatzes muss die zu entwickelnde Modellierungsmethode also
folgende Aufgaben erfüllen. Sie muss
1. die Strukturen und Abläufe zwischenbetrieblicher Transaktionen und ihrer
Informationsflüsse beschreiben können,
2. ein modellgestütztes Ableiten und Festlegen der erforderlichen Nachrichten bezüglich
ihrer Inhalte und Strukturen ermöglichen und
3. die fachlichen Aufgaben einer Integration zwischenbetrieblicher Informationsflüsse
unterstützen.
Die Modellierungsmethode soll als Gestaltungsinstrument für eine Integration
zwischenbetrieblicher Informationsflüsse dienen. Adressaten bzw. Anwender der Methode
sind daher Personen, die mit dem Aufbau von Integrationslösungen von einzelnen Betrieben
oder einer Gruppe von Betrieben beauftragt werden. Dieses können eigene Mitarbeiter der
auftraggebenden Betriebe oder unabhängige Berater sein, sofern sie über das Know-how der
Modellierungsmethode verfügen. Modelliert wird gemeinsam mit Vertretern der beteiligten
Betriebe, die nicht zwingend Kenntnisse der Modellierungsmethode benötigen. Bei den
Betriebsvertretern sollte es sich zum einen um die für die zwischenbetrieblichen
Transaktionen Verantwortlichen aus den Fachabteilungen handeln. Sie treten schließlich als
Absender oder Adressaten von geschäftlichen Nachrichten auf. Zum anderen sollten die für
die Schnittstellen der innerbetrieblichen Anwendungssysteme verantwortlichen Mitarbeiter
der IT-Abteilungen beteiligt werden, da sie die entworfenen Integrationslösungen
implementieren.
80
3.3 Inhaltliche Anforderungen
Die inhaltlichen Anforderungen an eine Modellierungsmethode zur Integration
zwischenbetrieblicher Informationsflüsse nach dem vorgestellten Ansatz können aus den im
vorhergehenden Abschnitt formulierten Zielen und Aufgaben abgeleitet werden.
3.3.1 Anforderungen zur Beschreibung von Strukturen und Abläufen
zwischenbetrieblicher Transaktionen und ihrer Informationsflüsse
Mit der zu entwickelnden Modellierungsmethode sollen die Strukturen und Abläufe
zwischenbetrieblicher Transaktionen und ihrer Informationsflüsse beschrieben werden
können. Dazu muss sie eine Antwort auf die „W-Fragen“ einer Analyse zwischenbetrieblicher
Transaktionen und Informationsflüsse geben können. Zu diesen „W-Fragen“, die
Ausgangspunkt einer jeden Analyse sind, gehören:
„Was?“ - die Frage nach den Gegenständen (Objekten) zwischenbetrieblicher Transaktionen
Es ist zu klären, welches die Gegenstände einer zwischenbetrieblichen Transaktion sind und
wie die Transaktion strukturiert ist. Es sind also die Leistungs-, Zahlungs- und
Informationsflüsse, aus denen sich eine Transaktion zusammensetzt, sowie die jeweiligen
Leistungs-,
Zahlungs- und Informationsobjekte zu beschreiben.
„Wer?“ - die Frage nach den Akteuren (Subjekten) zwischenbetrieblicher Transaktionen
Es ist zu klären, welche Akteure an einer zwischenbetrieblichen Transaktion beteiligt sind und
welche Rollen sie einnehmen. Zu jedem Leistungs-, Zahlungs- und Informationsfluss sind
Sender und Empfänger zu bestimmen.
„Wann?“ - die Frage nach der zeitlichen Struktur zwischenbetrieblicher Transaktionen
Es ist zu klären, wann und wie lange eine zwischenbetriebliche Transaktion, bzw. ein
Leistungs-, Zahlungs- oder Informationsfluss durchgeführt wird. Darüber hinaus sind die
zeitlichen Beziehungen zwischen den einzelnen Flüssen zu verdeutlichen.
„Wie?“ - die Frage nach Art und Weise sowie Mittel der Durchführung zwischenbetrieblicher
Transaktionen
Es ist zu klären, wie die Durchführung einer zwischenbetrieblichen Transaktion erfolgt. Dazu
gehört, festzuhalten, in welcher Reihenfolge Leistungs-, Zahlungs- und Informationsflüsse
durchgeführt und wie sie miteinander verknüpft werden. Wichtig ist auch die Darstellung
81
alternativer Abläufe und Varianten von zwischenbetrieblichen Transaktionen.276 Letztendlich
ist auch zu beschreiben, wer mit wem auf welche Art kommunizieren kann.277 Es ist also zu
beschreiben, wie Informationsflüsse realisiert werden sollen, d. h. mit welchen Kommunika-
tionsmedien die Nachrichten über welche Kanäle übertragen und wie die empfangenen Daten
weiterverarbeitet werden sollen.278
„Wozu?“ - die Frage nach dem Zweck zwischenbetrieblicher Informationsflüsse
Es ist zu klären, zu welchem Zweck zwischenbetriebliche Informationsflüsse durchgeführt
werden. Dazu ist darzustellen, wie die Informationsflüsse auf die Leistungs- und
Zahlungsflüsse Einfluss nehmen, d. h. ob sie sie planen, steuern oder kontrollieren.
Um all diese Fragestellungen beantworten zu können, muss die Modellierungssprache
bestimmte Modellierungselemente und -konstrukte anbieten (vgl. Tab. 3-3).
276 Vgl. Schüppler (Informationsmodelle 1998), S. 171 277 Vgl. Oberweis (Modellierung 1996), S. 32 278 Vgl. Henkel (Gestaltung 1996), S. 15
82
Fragestellung Anforderung Erforderliche Modellierungselemente/-konstrukte
Repräsentation der zwischenbetrieb-lichen Leistungs-, Zahlungs- und Informationsflüsse
• Leistungsflüsse • Zahlungsflüsse • Informationsflüsse
Repräsentation der Gegenstände zwischenbetrieblicher Flüsse
• Leistungsobjekte • Zahlungsobjekte • Informationsobjekte
Was? (Gegenstand)
Zusammenhang Flüsse-Objekte • Zuordnung Flüsse-Objekte Repräsentation der beteiligten Akteure mit ihren Rollen
• Akteure • Rollen • Zuordnung Akteur-Rolle-
Transaktion
Wer? (Akteure)
Darstellung, welcher Akteur an welchem Fluss mit welcher Rolle beteiligt ist
• Zuordnung Akteur-Rolle-Fluss
Wann? (Zeitliche Struktur)
Repräsentation des zeitlich-logischen Ablaufs einer zwischenbetrieblichen Transaktion
• Zeitliche Folge von Flüssen • Absolute und relative
Zeitangaben Repräsentation alternativer Abläufe • Alternative Verknüpfungen von
Flüssen (d. h. Darstellung von Ablaufvarianten)279
Wie? (Art und Hilfsmittel)
Repräsentation von Kommunikationskanälen und -medien
• Kanäle • Medien • Zuordnung Kanal-Medium-
Informationsobjekt-Informationsfluss
• Zuordnung Kanal-Akteur Wozu? (Zweck)
Zusammenhang Informationen zu Leistungen und Zahlungen
• Phasen von Transaktionen • Zweck von Informationsflüssen • Bezug von Informationsobjekten
Tab. 3-3 Anforderungen zur Beschreibung von Strukturen und Abläufen zwischenbetrieblicher Transaktionen und ihrer Informationsflüsse
3.3.2 Anforderungen zum Ableiten und Darstellen von Nachrichtenstrukturen
Mit der zu entwickelnden Modellierungsmethode sollen sämtliche für eine zwischenbetrieb-
liche Transaktion erforderlichen Nachrichten in ihren Inhalten und Strukturen beschrieben
werden können. Idealerweise sollten diese Strukturen aus den Modellen der
zwischenbetrieblichen Transaktionen und ihrer Informationsflüsse abgeleitet werden können.
An die Modellierungssprache der Methode sind also Anforderungen bezüglich der Ableitung
sowie der Darstellung von Nachrichtenstrukturen zu stellen (vgl. Tab. 3-4).
83
Nachrichten steuern, planen und kontrollieren zwischenbetriebliche Transaktionen. Damit
müssen sie sich auf bestimmte Gegenstände und Geschehnisse der realen Welt beziehen.
Diese reale Welt wird nach dem im Abschnitt 3.2 dargelegten Ansatz zunächst als Modell
konstruiert. Auf Basis dieses Modells sollen nun im weiteren die Nachrichteninhalte
abgeleitet und festgelegt werden. Dazu muss der zu beobachtende Bezug zwischen den
Nachrichten und den Gegenständen bzw. Geschehnissen der realen Welt auch in den
Modellen repräsentiert werden. Mit anderen Worten: die Modellierungselemente zur
Repräsentation einer zwischenbetrieblichen Transaktion und den Informationsflüssen müssen
mit den Modellierungselementen zur Darstellung der Nachrichtenstrukturen in Beziehung
gebracht werden können.
Nachrichten zwischenbetrieblicher Transaktionen können typischerweise in einen Kopf-,
Positions- und Summenteil untergliedert werden. Mitunter erfolgt eine weitere Unterteilung
von Positionsdaten in Positionseinteilungen. Jeder Teil einer Nachricht besteht aus mehreren
Angaben, sogenannten Datenelementen. Die Zuordnung eines Datenelementes zu einem
Nachrichtenteil zeigt, ob es für die ganze Nachricht gilt oder ob es positionsspezifisch ist.
Eine solche hierarchische Struktur auf Datenelementebene muss von der zu entwickelnden
Modellierungssprache dargestellt werden können.
Fragestellung Anforderung Erforderliche Modellierungselemente/-konstrukte
Ableiten der Nachrichtenstruktur
Zusammenhang zwischen Modellierungselementen zur Repräsentation einer zwischenbetrieblichen Transaktion und Modellierungselementen zur Darstellung der Nachrichtenstruktur
• Integrierte Modelle zu Trans-aktionen, zu Informationsflüssen und zu den Nachrichten mit ihren Datenelementen
Darstellen der Nachrichtenstruktur
Repräsentation von Informations-objekten (Nachrichten) und ihren inhaltlichen Strukturen
• Hierarchisch strukturierte Informationsobjekte
• Datenelemente • Zuordnung Datenelement-
Informationsobjekt Tab. 3-4 Anforderungen zum Ableiten und Darstellen der Nachrichtenstrukturen
279 Vgl. Schüppler (Informationsmodelle 1998), S. 171
84
3.3.3 Anforderungen an die Unterstützung der fachlichen Aufgaben einer Integration
zwischenbetrieblicher Informationsflüsse
Die zu entwickelnde Modellierungsmethode soll die fachlichen Aufgaben, d. h. sowohl die
syntaktische und semantische als auch die pragmatische Integration zwischenbetrieblicher
Informationsflüsse unterstützen. Dazu soll geklärt werden, welche fachlichen Aufgaben eine
Integration im einzelnen umfasst. Es sollen die - zunächst noch nicht automatisierten -
Tätigkeiten, die im Rahmen zwischenbetrieblicher Transaktionen durchgeführt werden,
anhand eines kleinen Szenarios analysiert werden. Diese Analyse dient als Grundlage für die
Kategorienbildung von fachlichen Aufgaben im Rahmen einer Integration
zwischenbetrieblicher Informationsflüsse.
3.3.3.1 Tätigkeiten im Rahmen zwischenbetrieblicher Transaktionen
Es wird von einem Lebensmittelhandelsbetrieb, der AllBuy GmbH, ausgegangen.280 Die
AllBuy GmbH bezieht ihre Brot- und Backwaren von einer industriellen Großbäckerei. Dabei
erfolgt einmal jährlich ein Rahmenauftrag der AllBuy-Zentrale an die Großbäckerei, in dem
Absatzmengen, Preise sowie Liefer- und Zahlungsbedingungen festgelegt werden. Die
Lieferabrufe erfolgen direkt durch die AllBuy-Filialen, die wiederum direkt von der
Großbäckerei beliefert werden (Streckengeschäft). Nach erfolgter Lieferung wird eine
Rechnung an die AllBuy-Zentrale gesendet, die die Regulierung der Zahlung übernimmt. Tab.
3-5 zeigt eine typische Nachrichtenfolge in diesem Szenario.
Nachricht (bzw. Lieferung) Sender Empfänger Kanal 1. Rahmenauftrag AllBuy-Zentrale Großbäckerei Briefpost 2. Lieferabruf AllBuy-Filiale Großbäckerei Telefax 3. Lieferung Großbäckerei AllBuy-Filiale LKW 4. Lieferschein Großbäckerei AllBuy-Filiale LKW 5. Wareneingangsmeldung AllBuy-Filiale AllBuy-Zentrale Telefax 6. Rechnung Großbäckerei AllBuy-Zentrale Briefpost 7. Scheck AllBuy-Zentrale Großbäckerei Briefpost
Tab. 3-5 Nachrichtenfolge im AllBuy-Szenario
280 Das Anwendungsszenario der AllBuy GmbH wurde bereits während des Forschungsprojektes MOVE zur Validierung und Veranschaulichung der Projektergebnisse entwickelt (vgl. BFK u. a. (Modellierung 1999), S. 8ff.; Hluchy u. a. (Analyse 1999), S. 129ff.). Es basiert auf Interviews, die in Zusammenarbeit mit dem Europäischen Handelsinstitut (EHI) in Handelsunternehmen durchgeführt worden sind. Beim Fallbeispiel AllBuy handelt es sich also um ein realitätsnahes, im Detail jedoch fiktives Szenario.
85
Im folgenden sollen die Informationsflüsse im AllBuy-Szenario analysiert werden.
Unberücksichtigt bleiben dagegen die Leistungs- und Zahlungsflüsse. Es wird untersucht,
welche Tätigkeiten von den Sachbearbeitern im Rahmen des papierbasierten
Datenaustausches an den Schnittstellen der Betriebe durchgeführt werden müssen (vgl. Tab.
3-6).
86
Nachricht Verarbeitungsrichtung
Tätigkeit Erläuterung
Initiieren des Rahmenauftrages
• In direkten Gesprächen wird eine Einigung über Absatz-mengen, Preise sowie Liefer- und Zahlungsbedingungen erzielt. Von der AllBuy-Zentrale wird ein entsprechender Rahmenauftrag erstellt. Er dient als rechtliche Grundlage für die weitere Geschäfts-beziehung.
Ausgangsverarbeitung in der AllBuy-Zentrale
Übermitteln des Rahmenauftrages
• Der Rahmenauftrag wird per Briefpost an die Groß-bäckerei übermittelt.
Annehmen des Rahmenauftrages
• Ist der Rahmenauftrag für die Großbäckerei bestimmt?
Prüfen und Korrigieren des Rahmenauftrages
• Angaben vollständig? Ggf. Ergänzen fehlender Angaben.
• Anpassen von Nummerierungen und Bezeichnungen an interne Anforderungen (z. B. Art.-Nr, Codes für Liefer- bzw. Zahlungsbedingungen, etc.)
• Betriebswirtschaftlich zulässige Werte? • Stimmen die Angaben mit dem Verhandlungsergebnis
überein?
Eingangsverarbeitung bei der Großbäckerei
Rahmenauftrag syntaktisch anpassen
• Ergänzter und korrigierter Rahmenauftrag wird syntaktisch angepasst und dv-mäßig erfasst.
Rahmenauftrag
Ausgangsverarbeitung bei der Großbäckerei
Reagieren auf Rahmenauftrag
• Ggf. Rückfragen bzgl. unzulässiger Werte • Ggf. Widerspruch erheben (falls Werte im Widerspruch
zu Verhandlungsergebnis) Initiieren des Lieferabrufs
• Die Disposition in einer AllBuy-Filiale ergibt einen Bedarf von 25 Rosinenbroten. Der zuständige Mitarbeiter füllt daher ein entsprechendes Lieferabrufformular mit Bezug zum Rahmenauftrag aus ...
Übermitteln des Lieferabrufs
• ... und übermittelt ihn per Fax an die Großbäckerei.
Ausgangsverarbeitung in der AllBuy-Filiale
Auf Reaktion warten • AllBuy-Filiale erwartet eine Lieferung über 25 Rosinenbrote.
Annehmen des Lieferabrufs
• Ist der Lieferabruf für die Großbäckerei bestimmt?
Prüfen und Korrigieren des Lieferabrufs
• Gibt es einen Rahmenauftrag zum Lieferabruf? • Angaben vollständig? Ggf. Ergänzen fehlender
Angaben. • Anpassen von Nummerierungen und Bezeichnungen an
interne Anforderungen (z. B. Art.-Nr, Codes für Liefer- bzw. Zahlungsbedingungen, etc.)
• Betriebswirtschaftlich zulässige Werte vorhanden? • Stimmen die Werte mit den Stammdaten überein (z. B.
Preise)? • Sind die Daten konsistent zum Rahmenauftrag?
Eingangs-verarbeitung bei der Großbäckerei
Lieferabruf syntaktisch anpassen
• Ergänzter und korrigierter Lieferabruf wird syntaktisch angepasst und dv-mäßig erfasst.
Lieferabruf
Ausgangsverarbeitung bei der Großbäckerei
Reagieren auf Lieferabruf
• Ggf. Rückfragen bzgl. unzulässiger Werte • Ggf. Widerspruch erheben (falls Werte im Widerspruch
zu Rahmenauftrag) • Produzieren der geforderten 25 Rosinenbrote • Liefern der 25 Rosinenbrote
Lieferschein Initiieren des Lieferscheins
• 25 Rosinenbrote werden produziert und per Auslieferungs-LKW zur AllBuy-Filiale geliefert.
• Daten des Lieferscheins resultieren zum Teil aus der Bestellung (z. B. Artikelnr., Lieferabrufnr., ...)
Ausgangsverarbeitung in der Großbäckerei
Übermitteln des Lieferscheins
• Lieferschein wird zusammen mit der Lieferung an die AllBuy-Filiale übergeben.
87
Nachricht Verarbeitungsrichtung
Tätigkeit Erläuterung
Lieferschein Annehmen des Lieferscheins
• Ist die Liefermeldung für die AllBuy-Filiale bestimmt?
Eingangsverarbeitung bei der AllBuy-Filiale Prüfen und
Korrigieren des Lieferscheins
• Gibt es einen Wareneingang zum Lieferschein? • Gibt es einen Lieferabruf zum Lieferschein? • Angaben vollständig? Ggf. Ergänzen fehlender
Angaben. • Stimmen die Angaben mit dem (physischem)
Wareneingang überein? • Sind die Daten konsistent zum Lieferabruf? • Sind die Toleranzgrenzen für eine Über- oder
Unterlieferung eingehalten worden? Ausgangsverarbeitun
g bei der AllBuy-Filiale
Reagieren auf Lieferschein
• Ggf. Korrekturmeldung • Ggf. Mängelrüge wg. Über- oder Unterlieferung • Wareneingangsmeldung an AllBuy-Zentrale per Fax
übermitteln Initiieren der WE-Meldung
• Eine Kopie des ergänzten und korrigierten Lieferscheins ...
Ausgangsverarbeitung in der AllBuy-Filiale Übermitteln der
WE-Meldung • ... wird per Fax an die AllBuy-Zentrale übermittelt.
Annehmen der WE-Meldung
• Ist die Wareneingangsmeldung für die AllBuy-Filiale bestimmt?
Prüfen und Korrigieren der WE-Meldung
• Gibt es einen Lieferabruf zur Wareneingangsmeldung?
Wareneingangsmeldung (WE-Meldung)
Eingangsverarbeitung bei der AllBuy-Zentrale
WE-Meldung syntaktisch anpassen
• Wareneingang wird syntaktisch angepasst und dv-mäßig erfasst.
Initiieren der Rechnung
• 25 Rosinenbrote sind geliefert worden. • Daten der Rechnung resultieren aus dem Lieferschein.
Übermitteln der Rechnung
• Rechnung wird am Tag des Versands an die AllBuy-Zentrale per Briefpost übersendet.
Ausgangsverarbeitung bei der Großbäckerei
Auf Reaktion warten • Zahlung erwartet. Annehmen der Rechnung
• Ist die Rechnung für die AllBuy-Filiale bestimmt?
Prüfen und Korrigieren der Rechnung
• Gibt es einen Lieferschein bzw. eine Wareneingangsmeldung zur Rechnung?
• Angaben vollständig? Ggf. Ergänzen fehlender Angaben.
• Anpassen von Nummerierungen und Bezeichnungen an interne Anforderungen (z. B. Art.-Nr, Codes für Liefer- bzw. Zahlungsbedingungen, etc.).
• Sind die Daten innerhalb der Rechnung konsistent (z. B. Summe der Rechungspositionen = Rechnungsgesamtsumme)?
• Betriebswirtschaftlich zulässige Werte vorhanden? • Stimmen die Werte mit den Stammdaten überein (z. B.
Preise, Währung)? • Sind die Daten konsistent zur Wareneingangsmeldung?
Eingangsverarbeitung bei der AllBuy- Zentrale
Rechnung syntaktisch anpassen
• Ergänzte und korrigierte Rechnung wird syntaktisch angepasst und dv-mäßig erfasst.
Rechnung
Ausgangsverarbeitung bei der AllBuy-Zentrale
Reagieren auf Rechnung
• Ggf. Widerspruch erheben. • Bezahlen der Rechnung
Tab. 3-6 Tätigkeiten im AllBuy-Szenario
88
Betrachtet man die Ergebnisse der Szenarioanalyse, so lässt sich feststellen, dass unabhängig
vom Nachrichtentyp immer ähnliche Tätigkeiten durchgeführt werden müssen. Sie lassen sich
daher verallgemeinern und den verschiedenen Integrationsebenen zuordnen (vgl. Tab. 2-5).
Tätigkeit Integrationsaufgabe Integrationsebene Annehmen/ Übermitteln Kommunikation steuern Technische Integration Syntaktisch anpassen Syntaktische Konvertierung
vornehmen Syntaktische Integration
Prüfen und Korrigieren Semantische Prüfung durchführen Semantische Integration Initiieren/ Reagieren Aktions- und Reaktionsmechanismen
bereitstellen Pragmatische Integration
Tab. 3-7 Aufgaben einer Integration zwischenbetrieblicher Informationsflüsse
Bei einem automatisierten Informationsaustausch sind Verarbeitungsschritte durchzuführen,
die den manuellen Tätigkeiten entsprechen. Daher können aus den verallgemeinerten
Tätigkeiten die für eine Integration zwischenbetrieblicher Informationsflüsse erforderlichen
Aufgaben abgeleitet werden.
Annehmen und Übermitteln
Ankommende Nachrichten müssen angenommen, auf richtige Adressierung überprüft und an
den zuständigen Empfänger weitergereicht werden. Ausgehende Nachrichten sind an den
vorgesehenen Empfänger zu adressieren und zu übermitteln. Diese Aufgaben sorgen für eine
reibungslose technische Übertragung von Nachrichten und sind unabhängig von deren fach-
lichen Inhalten. Damit sind sie Gegenstand der technischen und nicht der fachlichen Inte-
gration. Die technische Integration stellt in der Regel kein großes Problem dar, da auf dem
Markt erprobte Komponenten vorhanden sind.281
Syntaktisch anpassen
Bevor ankommende Nachrichten vom Inhousesystem weiterverarbeitet werden können,
müssen sie zunächst erfasst werden. Dazu sind gegebenenfalls die in den Nachrichten
verwendeten Datenformate syntaktisch in ein für das eigene Anwendungssystem
verständliches Format anzupassen bzw. zu konvertieren.
Prüfen und Korrigieren
Neben der syntaktischen Anpassung müssen eingehende Nachrichten einer Reihe von
Prüfungen und Korrekturen unterzogen werden, bevor sie in das Inhousesystem übernommen
281 Vgl. Henkel (Gestaltung 1996), S. 14f.; Fischer (Informationswirtschaft 1999), S. 167
89
werden können. Die Weiterverarbeitung von Nachrichten erfordert, dass das Inhousesystem
nur zulässige und in sich konsistente Datenwerte aufnimmt. Dies gilt insbesondere für den
automatisierten Datenaustausch. Im Rahmen der Integration zwischenbetrieblicher
Informationsflüsse sind also semantische Prüfungen der Nachrichten erforderlich.
Initiieren/ Reagieren
Der Geschäftsablauf oder ein bestimmter Zeitpunkt veranlassen einen Sender, eine Nachricht
zu erzeugen und zu versenden. Für den automatisierten Datenaustausch sind dafür sogenannte
Aktions- und Reaktionsmechanismen vorzusehen. Auf einige Nachrichten erwartet der Sender
eine unmittelbare Reaktion in Form eines Informationsrückflusses (z. B. auf eine Anfrage)
oder in Form einer Leistung (z. B. Warenlieferung nach Bestellung). Aufgabe von
Reaktionsmechanismen beim automatisierten Datenaustausch ist es, diese
Reaktionserwartungen zu erfüllen. Das Bereitstellen von Aktions- und
Reaktionsmechanismen gehört zu den fachlichen Aufgaben einer pragmatischen Integration.
3.3.3.2 Anforderungen an die Unterstützung der syntaktischen und semantischen
Integration
Die syntaktische und semantische Integration umfasst die Aufgabe, ankommende Nachrichten
so für das Inhousesystem vorzubereiten, dass eine automatisierte Weiterverarbeitung möglich
wird. Es ist also sowohl ein syntaktischer als auch ein semantischer Abgleich zwischen dem
gesendeten Quellformat als auch dem erwarteten Zielformat einer Nachricht erforderlich.
Dabei muss gewährleistet sein, dass trotz möglicherweise inkompatibler Datenmodelle der
kommunizierenden Anwendungssysteme die Semantik der übertragenen Daten erhalten
bleibt.282 Daher sind die Nachrichten hinsichtlich des Inhalts in ihrer semantischen Integrität
zu prüfen.283 Die Aufgaben der syntaktischen Konvertierung und der semantischen Prüfung
sind eng miteinander verknüpft.
Zur syntaktischen Konvertierung gehört das Konvertieren von Darstellungsformaten, das
Ergänzen fehlender Werte sowie die Umsetzung von codierten Daten (vgl. Tab. 3-8).
282 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 69 283 Vgl. Fischer (Datenmodellierung 1993), S. 243
90
Konvertierungsaufgaben Beispiele Darstellungsformate konvertieren
• Konvertieren einer Datumsangabe von 12.09.99 nach 1999/09/12.
Ergänzen fehlender Werte • Ein fehlender Mehrwertsteuersatz wird aus dem Brutto- und Nettobetrag errechnet.
Codierte Daten umsetzen • Ein vom Sender verwendeter Ländercode „DE“ für „Deutschland“ wird in dem vom Empfänger verwendeten Code „GER“ umgesetzt.
Tab. 3-8 Beispiele für syntaktische Konvertierungen
Die semantische Prüfung einer Nachricht findet auf mehreren Ebenen statt. Zunächst erfolgt
eine Plausibilisierung jedes einzelnen Datenelementes. Es wird überprüft, ob die
betriebswirtschaftlich zulässigen Wertebereiche eingehalten werden. Dazu gehört
beispielsweise auch das Umsetzen heterogener Identifikationssysteme. Anschließend erfolgt
eine Plausibilisierung auf Nachrichtenebene. Dabei gilt es sicherzustellen, dass die Daten
innerhalb einer Nachricht konsistent zueinander sind (z. B. muss eine Rechnungssumme mit
der Summe der einzelnen Rechungspositionen übereinstimmen). Bei der Plausibilisierung auf
Transaktionsebene wird die nachrichtenübergreifende Konsistenz der Daten innerhalb einer
Transaktion überprüft. Beispielsweise sollten die fakturierten Mengen mit den gelieferten
Mengen übereinstimmen. In einer abschließenden Plausibilisierung auf
Geschäftsbeziehungsebene werden außergewöhnliche Nachrichteninhalte (z. B. eine für den
betreffenden Partner ungewöhnlich hohe Bestellmenge) oder Umstände, die gar nicht die
eigentliche Transaktion betreffen (z. B. Liquiditätsschwierigkeiten eines Partners) geprüft.
Semantische Prüfungen Beispiele Plausibilisierung auf Datenelementebene
• Es dürfen nur zulässige Mehrwertsteuersätze verwendet werden.
• Es dürfen nur gültige Artikelnummern verwendet werden. Plausibilisierung auf Nachrichtenebene
• Die Rechnungssumme muss mit der Summe der einzelnen Rechnungspositionen übereinstimmen.
• Die Postleitzahl muss zum angegebenen Ort passen. Plausibilisierung auf Transaktionsebene
• Die in den Rechnungspositionen angegebenen Mengen müssen mit den Mengen im Lieferschein übereinstimmen.
• Die Preise der Rechnung müssen mit den im Rahmenvertrag vereinbarten Preisen übereinstimmen.
Plausibilisierung auf Geschäftsbeziehungsebene
• Es soll eine Warnung erfolgen, wenn der Geschäftspartner eine ungewöhnlich hohe Menge an Artikeln bestellt.
• Die Bestellung eines Partners mit Liquiditätsschwierigkeiten soll abgelehnt werden.
Tab. 3-9 Beispiele für semantische Prüfungen
91
Die semantischen Prüfregeln lassen sich nach folgenden Merkmalen klassifizieren (vgl.
Tab. 3-10):
• Zuordnungsebene
Eine semantische Prüfung erfolgt entweder auf der Ebene eines einzelnen Datenelementes,
einer Nachricht, der gesamten Transaktion oder der Geschäftsbeziehung.
• Prüfbasis
Zur Auswertung einer Prüfregel werden entweder nur Angaben, die auch in der zu
prüfenden Nachricht enthalten sind (nachrichtenintern), Angaben aus den bereits
ausgetauschten Nachrichten einer Transaktion (transaktionsintern) oder aber Angaben aus
anderen Quellen (extern), wie z. B. der betroffenen Anwendungssysteme, herangezogen.
• Spezifität
Prüfregeln werden spezifisch für einen bestimmten Geschäftspartner formuliert
(partnerabhängig) oder unabhängig davon (partnerunabhängig).
Merkmal Ausprägungen Zuordnungsebene Datenelement Nachricht Transaktion GeschäftsbeziehungPrüfbasis Nachrichtenintern Transaktionsintern Extern Spezifität Partnerabhängig Partnerunabhängig Tab. 3-10 Merkmale semantischer Prüfregeln
Um eine syntaktische und semantische Integration unterstützen zu können, müssen bestimmte
Modellierungselemente und -konstrukte im Metamodell der zu entwickelnden
Modellierungssprache bereitgestellt werden. Die Anforderungen können aus den zuvor
beschriebenen Aufgaben abgeleitet werden.
92
Aufgabe Anforderung Erforderliche Modellierungselemente/-konstrukte
Syntaktische Konvertierung
Darstellungsformate konvertieren; Ergänzen fehlender Werte; codierte Daten umsetzen
• Angaben zum syntaktischen Format eines Datenelements
Plausibilisierung auf Datenelement-/ Nachrichtenebene
• Regeln284 • Verknüpfung Datenelement-
Regeln Plausibilisierung auf Transaktionsebene
• Regeln • Verknüpfung Datenelement-
Regeln • Zuordnung Informationsobjekt-
Transaktion
Semantische Prüfung
Plausibilisierung auf Geschäftsbeziehungsebene
• Regeln • Verknüpfung Datenelement-
Regeln Tab. 3-11 Anforderungen zur syntaktischen und semantischen Integration
3.3.3.3 Anforderungen an die Unterstützung der pragmatischen Integration
Aufgabe der pragmatischen Integration ist es, die interne Vorgangsbearbeitung mit den
zwischenbetrieblichen Abläufen so zu verknüpfen, dass ein reibungsloser Informationsfluss
stattfinden kann. Die Verknüpfung muss in beide Verarbeitungsrichtungen vollzogen werden,
d. h. sowohl für die Eingangs- als auch für die Ausgangsverarbeitung von Nachrichten.
Eingehende Nachrichten sind, nachdem sie syntaktisch konvertiert und semantisch überprüft
worden sind, auf ihre pragmatische Bedeutung hin zu untersuchen, um angemessen auf sie
reagieren zu können. Dies erfolgt durch die Bereitstellung von entsprechenden
Reaktionsmechanismen. Dagegen sind Aktionsmechanismen für die Ausgangsverarbeitung
von Nachrichten vorzusehen. Sie legen fest, wann und an welche Partner Nachrichten zu
versenden sind.
Reaktionsmechanismen können erst dann festgelegt werden, wenn die pragmatische
Bedeutung einer eingehenden Nachricht überprüft wurde. Zu unterscheiden sind dabei primäre
und sekundäre Nachrichtentypen (vgl. Abschnitt 2.5). Primäre Nachrichten führen zwingend
zu einer Reaktion des Empfängers, während auf sekundäre Nachrichten keine Antwort
erwartet wird.
93
Nachrichtentyp Erläuterung Primärer Nachrichtentyp Sender erwartet Reaktion des Empfängers. Empfänger reagiert in
Form eines • Informationsflusses (z. B. Angebot auf eine Anfrage), • Leistungsflusses (z. B. Warenlieferung auf eine Bestellung)
oder • Zahlungsflusses (z. B. Zahlung auf eine Rechnung).
Sekundärer Nachrichtentyp
Sender erwartet keine Reaktion. Keine Aktion beim Empfänger, lediglich Übernahme der unterstützenden Nachrichten, d. h. • Kontrollinformationen (z. B. Bestätigungen) oder • Basisinformationen (z. B. Stammdatenaustausch).
Tab. 3-12 Primärer und sekundärer Nachrichtentyp285
Erwartet der Sender eine Antwort auf seine Nachricht, so sollte diese - wenn möglich -
automatisiert erstellt und gesendet werden. Möglich ist es immer dann, wenn sich der
Nachrichteninhalt nach einer fehlerfreien Plausibilitätsprüfung eindeutig aus den zuvor
eingegangenen Nachrichten ableiten oder direkt übernehmen läßt. Dies ist in der Regel bei
dokumentierenden Nachrichten der Fall, die zum Zweck der Kontrolle von Transaktionen
verwendet werden (vgl. Tab. 3-13).
Zweck aus Sender-/ Empfängersicht
Beschreibung Beispiele
Dokumentierende/ Kontrollierende Nachricht
• Beziehen sich auf eine bestehende, bereits ausgehandelte Geschäftsbeziehung
• Bestätigung zuvor ausgetauschter Nachrichten
• Bestellbestätigung • Zollantwort
Tab. 3-13 Dokumentierende bzw. kontrollierende Nachrichten
In jedem Fall, d. h. sowohl bei primären als auch bei sekundären Nachrichten, sind die
Nachrichteninhalte nach der syntaktischen Konvertierung und semantischen Überprüfung an
die anwendungsinterne Vorgangsbearbeitung zu übergeben. In Abhängigkeit der
pragmatischen Auswertung wird die erforderliche Funktion des internen Anwendungssystems
aufgerufen.
Für die Ausgangsverarbeitung können ähnliche Überlegungen angestellt werden. Wenn sich
sowohl der Inhalt als auch der Zeitpunkt der Erstellung bzw. des Versandes einer Nachricht
eindeutig auf Basis formaler Regeln ableiten lassen, so besteht die Möglichkeit der
284 In der Literatur wird dafür häufig der Begriff ‚Business Rules‘ verwendet. Vgl. Oberweis (Modellierung 1996), S. 32; Herbst (Business 1997) 285 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 202
94
Automation. Gemeint ist das interventionslose Erzeugen und Weiterleiten von elektronischen
Nachrichten an die Geschäftspartner. Gute Voraussetzungen hierzu bieten Nachrichten mit
dokumentierendem oder allgemein informierendem sowie einige Nachrichten mit leistungs-
oder zahlungssteuerndem Charakter (vgl. Tab. 3-14).
Zweck aus Sendersicht
Erläuterung Beispiele
Dokumentierende Nachricht
• Beziehen sich auf eine bestehende, bereits ausgehandelte Geschäftsbeziehung
• Aufgabe ist es, dem Partner den aktuellen Abwicklungsstand und die erfolgten Flüsse anzuzeigen
• Lieferavis • Zahlungsavis
Allgemein informierende Nachricht
• Beziehen sich nicht auf eine bestimmte Transaktion
• Erleichtern längerfristige Geschäftsbeziehungen durch die Aktualisierung von Rahmendaten
• Austausch von Partnerstammdaten
• Kataloge und Preislisten
• Austausch von Artikelstammdaten
Leistungs- oder zahlungssteuernde Nachricht
• Sind Gegenstand einer bestehenden Leistungsbeziehung
• Inhalt lässt sich i. d. R. aus verfügbaren Rahmendaten ableiten
• Zeitpunkt aus Stand der Geschäftsabwicklung ableitbar
• Rechnung • Lieferabruf
Tab. 3-14 Automatisierbare Nachrichten
Die Initiierung einer Nachrichtenversendung kann zeitgesteuert, manuell, durch ein Ereignis
des Inhousesystems oder durch eine eingehende Nachricht erfolgen. Im letzteren Fall handelt
es sich um einen Reaktionsmechanismus, der bereits zuvor beschrieben wurde. Bei einer
zeitgesteuerten Versendung wird eine absolute Uhrzeit festgelegt. Zu den weiteren
Möglichkeiten gehört die Auslösung durch eine manuelle Aktion eines Anwenders oder aber
durch einen Trigger des Inhousesystems, d. h. durch ein bestimmtes Ereignis im
Anwendungssystem (z. B. das Unterschreiten eines Schwellenwertes, das Löschen/Anlegen
eines Objektes, etc.).
Tab. 3-15 zeigt die aus den Aufgaben zur pragmatischen Integration abgeleiteten
Anforderungen an die Modellierungssprache.
95
Fragestellung/ Aufgabe
Anforderung Erforderliche Modellierungselemente/ -konstrukte
Allgemeine Anforderungen der pragmatischen Integration • Reihenfolgebeziehungen von Flüssen
• Nebenläufigkeit von Flüssen
286 • Zeitliche Angaben zu
Ausführungen von Flüssen in absoluter und relativer Form287
Interpretation und pragmatisches Auswerten von Nachrichten
• Rollen von Informationsobjekten
• Zweck von Informationsobjekten
Anstoß von Funktionen interner Anwendungssysteme
• Ereignisse • Anwendungssysteme • Funktionen • Zuordnung
Anwendungssystem-Funktion • Zuordnung Fluss-Ereignis-
Funktion
Reaktionsmechanismen
Anstoß weiterer Flüsse • Verknüpfung von Flüssen über Regeln
Zeitgesteuerte Initiierung von Flüssen
• (Zeit-)Ereignisse • Zuordnung Fluss-Ereignis
Intern getriggerte Initiierung von Flüssen
• Funktionen (interner Anwendungssysteme)
• Ereignisse (Trigger) • Zuordnung Fluss-Ereignis-
Funktion
Aktionsmechanismen
Manuelle Initiierung von Flüssen • Ereignisse (manuelles Ereignis)
• Zuordnung Fluss-Ereignis Tab. 3-15 Anforderungen zur pragmatischen Integration
3.4 Formale Anforderungen
3.4.1 Übersicht der formalen Anforderungen
Neben inhaltlichen Anforderungen sind an die zu entwickelnde Modellierungsmethode auch
formale Anforderungen zu stellen. Sie sollen die Qualität und Handhabbarkeit der
286 Vgl. Oberweis (Modellierung 1996), S. 32 287 Vgl. Henkel (Gestaltung 1996), S. 152; Schüppler (Informationsmodelle 1998), S. 171
96
Modellierungsmethode sichern. Die im folgenden gestellten formalen Anforderungen
orientieren sich im wesentlichen an den Grundsätzen ordnungsmäßiger Modellierung
(GoM).288 Das Ziel der GoM ist es, Modellierungskonventionen vorzugeben, die eine
qualitätsgerechte und vergleichbare Modellerstellung erlauben.289
Einige GoM kommen bereits beim Entwurf einer Modellierungssprache, also bei der
Neukonstruktion eines Metamodells zur Anwendung. Andere GoM lassen sich erst bei einem
gegebenen Metamodell anwenden, beziehen sich also auf den Vorgang der Modellierung. Die
formalen Anforderungen an die zu entwickelnde Modellierungsmethode sollen daher in
formale Anforderungen an die Modellierungssprache und formale Anforderungen an die
Vorgehensweise unterschieden werden. Daneben existieren allgemeine Anforderungen, die
unabhängig von der Existenz eines Metamodells sind (vgl. Tab. 3-16).
Allgemeine Anforderungen (unabhängig vom Metamodell)
Anforderungen an die Modellierungssprache (betreffen Konstruktion des Metamodells)
Anforderungen an die Vorgehensweise (betreffen Anwendung des Metamodells)
• Vollständigkeit der Modellierungsmethode
• Implementierungsunab-hängigkeit
• Hohe Einsatzbreite • Hohe Einsatztiefe
• Sprachadäquanz (Spracheignung)
• Systematischer Aufbau • Klarheit
• Konstruktionsadäquanz • Sprachadäquanz
(Sprachrichtigkeit) • Vergleichbarkeit • Klarheit • Wirtschaftlichkeit
Tab. 3-16 Übersicht der formalen Anforderungen
3.4.2 Allgemeine Anforderungen an die Modellierungsmethode
Die nachfolgend beschriebenen allgemeinen Anforderungen geben den Rahmen für den
Entwurf einer Modellierungsmethode zur Integration zwischenbetrieblicher
Informationsflüsse nach dem in Abschnitt 3.2 dargelegten Ansatz vor (vgl. Tab. 3-17).
288 Ein erster Ansatz der GoM wurde von BECKER/ROSEMANN/SCHÜTTE entwickelt. Vgl. Becker, Rosemann, Schütte (Grundsätze 1995); Becker, Schütte (Handelsinformationssysteme 1996), S. 65-70; Rosemann (Komplexitätsmanagement 1996), S. 85-104. Eine Reformulierung der GoM wurde von SCHÜTTE vorgenommen (vgl. Schütte (Grundsätze 1998)), um die im ersten Ansatz „vorhandenen Theoriedefizite zu eliminieren und die praktische Anwendbarkeit zu fördern“ (Schütte (Grundsätze 1998), Fußnote 3, S. 111). SCHÜTTE selbst bezeichnet seinen zweiten Ansatz als ‚neue Grundsätze ordnungsmäßiger Modellierung‘ und verwendet zur Unterscheidung der beiden Ansätze die Bezeichnungen GoM I und GoM II. Vgl. Schütte (Grundsätze 1998), S. 111ff. Diese Unterscheidung wird in dieser Arbeit nicht getroffen. Da der Argumentation von SCHÜTTE im wesentlich gefolgt wird, beziehen sich Aussagen zu den GoM, sofern nicht anders angegeben, grundsätzlich auf die GoM II. 289 Vgl. Schüppler (Informationsmodelle 1998), S. 132; Schütte (Grundsätze 1998), S. 111f.
97
Die zu entwickelnde Modellierungsmethode sollte vollständig sein, d. h. alle Komponenten
beinhalten, aus denen eine Modellierungsmethode im Rahmen einer
Informationssystemgestaltung besteht. Dazu gehören (vgl. Abschnitt 3.1.1) ...
• ... ein Metamodell, welches in eindeutiger Weise die Syntax der verwendeten
Modellierungssprache festlegt. Dies ist Voraussetzung für eine korrekte Anwendung der
Sprache und für eine mögliche rechnergestützte Überprüfung der syntaktischen Richtigkeit
von Modellen (vgl. Abschnitt 3.4.4).290
• ... eine grafische Notation zur anschaulichen Visualisierung.291 Sie dient als Grundlage der
analytischen und konzeptionellen Gestaltungsarbeiten.292
• ... eine fest definierte Vorgehensweise. Sie gibt dem Modellierer ein begründetes,
planmäßiges Vorgehen nach festgelegten Regeln („Modeling Rules“)293 und mit
definierten
Zwischenergebnissen vor.
• ... optional eine Werkzeugunterstützung.294 Durch ein rechnergestütztes Vorgehen kann die
Effizienz des Modellierungsprozesses erheblich verbessert werden.295
Um offen und unabhängig von zukünftigen Entwicklungen der Informationstechnologie zu
sein, sollte die Modellierungsmethode implementierungsunabhängig sein. Dazu gehört zum
einen die Unabhängigkeit von bestimmten Nachrichtenstandards296 (z. B. EDIFACT,
XML/EDI-Standards) und zum anderen die Unabhängigkeit von bestimmten
Programmiersprachen.297
Durch Integrationsprojekte können sowohl primäre als auch sekundäre
Wertschöpfungspartner miteinander verbunden werden. Die Modellierungsmethode sollte
daher für eine hohe Einsatzbreite konzipiert werden. Infolge dessen sollten sich in den
Modellierungselementen und -konstrukten der Methode keine branchen- oder gar
290 Vgl. Cribbs, Moon, Roe (Evaluation 1992), S. 66; Oberweis (Modellierung 1996), S. 33; Frank, Prasse (Standardisierung 1997), S. 3 291 Vgl. Oberweis (Modellierung 1996), S. 33; Schüppler (Informationsmodelle 1998), S. 171 292 Vgl. Henkel (Gestaltung 1996), S. 150 293 Cribbs, Moon, Roe (Evaluation 1992), S. 66 294 Vgl. Cribbs, Moon, Roe (Evaluation 1992), S. 66; Oberweis (Modellierung 1996), S. 34 295 Vgl. Mertins, Süssenguth, Jochem (Modellierungsmethoden 1994), S. 20 296 Vgl. Oberweis (Modellierung 1996), S. 32f. 297 Vgl. Cribbs, Moon, Roe (Evaluation 1992), S. 66; Oberweis (Modellierung 1996), S. 33
98
betriebsspezifischen Eigenheiten
widerspiegeln. Stattdessen ist eine branchenunabhängige Einsatzfähigkeit anzustreben.
Es ist eine hohe Einsatztiefe der Modellierungsmethode anzustreben. Sie sollte sich daher
nicht auf bestimmte zwischenbetriebliche Transaktionen (z. B. Beschaffung, Logistik,
Zahlung) oder Transaktionsphasen (Anbahnung, Vereinbarung, Durchführung) beschränken,
sondern universell einsetzbar sein.
Anforderungen Konsequenz Vollständigkeit der Modellierungsmethode
• Existenz eines Metamodells • Bereitstellen einer grafischen Notation • Bereitstellen einer Vorgehensweise • Werkzeugunterstützung
Implementierungsunabhängigkeit
• Unabhängig von Nachrichtenformaten • Unabhängig von Programmiersprachen
Hohe Einsatzbreite • Branchenunabhängige Modellierung Hohe Einsatztiefe • Universeller Einsatz, d. h. keine Spezialisierung auf
bestimmte Transaktionen Tab. 3-17 Allgemeine Anforderungen an die Modellierungsmethode
3.4.3 Formale Anforderungen an die Modellierungssprache
Der Grundsatz der Sprachadäquanz umfasst die Spracheignung und Richtigkeit der
Sprachanwendung einer Modellierungssprache.298 Die Sprachrichtigkeit kann nur bei einem
gegebenen Metamodell überprüft werden und wird daher als Anforderung an die
Vorgehensweise formuliert (vgl. Abschnitt 3.4.4). Die Spracheignung muss dagegen bereits
bei der Konstruktion einer Modellierungssprache berücksichtigt werden und zielt auf deren
semantische Mächtigkeit.299 Damit ist die Angemessenheit der Modellierungssprache in Bezug
auf deren Ziele und Aufgaben gemeint.300 Für die Modellierungssprache der zu entwickelnden
Modellierungsmethode bedeutet dies, dass sie sämtliche Aspekte, die bei einer Integration
zwischenbetrieblicher Informationsflüsse relevant sind, darstellen können soll.301 Dieses ist
298 Vgl. Schütte (Grundsätze 1998), S. 114 299 Vgl. Frank, Prasse (Standardisierung 1997), S. 2. Verwendet wird dafür auch der Begriff ‚Ausdrucksmächtigkeit‘. Vgl. Zelewski (Bezugsrahmen 1995), S. 36; Oberweis (Modellierung 1996), S. 31. CRIBBS/MOON/ROE nennen dies ‚complete coverage‘ einer Modellierungssprache. Vgl. Cribbs, Moon, Roe (Evaluation 1992), S. 66 300 Vgl. Frank, Prasse (Standardisierung 1997), S. 2; Schütte (Grundsätze 1998), S. 114 301 Vgl. ähnlich Schüppler (Informationsmodelle 1998), S. 134f.: „ [...] führt zu der Forderung nach einer umfassenden Sprache, die eine Möglichkeit zur Modellierung von IOS ermöglicht. Bestehende Sprachen [...] ermöglichen zwar die Modellierung bestimmter Sichten, die Spracheignung für die Modellierung überbetrieblicher Sachverhalte ist hingegen als unzureichend zu bezeichnen.“
99
genau dann gewährleistet, wenn die in Abschnitt 3.3 formulierten inhaltlichen Anforderungen
an das Metamodell erfüllt werden.
Eine Modellierungsmethode sollte unterschiedliche Sichten auf den Modellierungsgegenstand
unterstützen.302 Zum einen sind Sichten vorzusehen, die die Struktur des zu modellierenden
Systems beschreiben, zum anderen sind Verhaltenssichten bereitzustellen.303 Der Grundsatz
des systematischen Aufbaus verlangt eine Konsistenz der verschiedenen Sichten.304 Die
Konsistenz ist durch ein integriertes, sichtenübergreifendes Metamodell sicherzustellen.305
Der Grundsatz der Klarheit zielt auf die Anschaulichkeit und Verständlichkeit eines
Modells.306 Diese lassen sich allerdings kaum in objektiver Weise beurteilen und sind
abhängig vom subjektiven Empfinden der Modellnutzer.307 Dennoch lassen sich einige
Anforderungen formulieren, die eine intersubjektive Klarheit fördern können. Dazu gehört die
Forderung, möglichst wenige und einfache Darstellungsmittel für die Notation zu
verwenden.308 Die Notation ist dann einfach, wenn bekannte und weit verbreitete Symbole für
bestimmte Modellierungselemente und -konstrukte verwendet werden.309 Eine einfach
gestaltete Notation kann problemlos für eine handschriftliche Modellierung ohne
Zuhilfenahme computergestützter Werkzeuge verwendet werden.310
Eine weitere Maßnahme zur Förderung der Klarheit ist die Hierarchisierung (Dekomposition)
von Modellen.311 Damit bleibt ein Modell auf verschiedenen Abstraktionsstufen
verständlich.312
302 Vgl. Cribbs, Moon, Roe (Evaluation 1992), S. 66; Oberweis (Modellierung 1996), S. 33 303 Vgl. Grund, Jähnig (Modell 1994), S. 50; Henkel (Gestaltung 1996), S. 155f.; Balzert (Analysemodell 1997), S. 39 304 Vgl. Schüppler (Informationsmodelle 1998), S. 136; Schütte (Grundsätze 1998), S. 130 305 Vgl. Becker, Rosemann, Schütte (Grundsätze 1995), S. 439; Schütte (Grundsätze 1998), S. 130f. FRANK/PRASSE bezeichnen die Anforderung nach einem systematischen Aufbau daher auch als ‚Integration‘. Vgl. Frank, Prasse (Standardisierung 1997), S. 2 306 Vgl. Schütte (Grundsätze 1998), S. 131. Der Grundsatz der Klarheit entspricht der von FRANK/PRASSE gestellten Anforderung nach Anschaulichkeit/Verständlichkeit bezüglich einer Sprache zur konzeptuellen Modellierung von Informationssystemen. Vgl. Frank, Prasse (Standardisierung 1997), S. 2 307 Vgl. Becker, Rosemann, Schütte (Grundsätze 1995), S. 438; Frank, Prasse (Standardisierung 1997), S. 2; Schüppler (Informationsmodelle 1998), S. 135 308 Vgl. Cribbs, Moon, Roe (Evaluation 1992), S. 65; Schüppler (Informationsmodelle 1998), S. 135. Ähnlich KELLER/POPP im Zusammenhang der Geschäftsprozessmodellierung: „Gute Modelle müssen dafür sorgen, daß neben den Symbolen eine einfache Sprache zur Verfügung steht, damit auch der ungeübte ‚Geschäftsprozeßgestalter‘ schnell in der Lage ist, neue Geschäftsprozesse nachvollziehen zu können.“ Keller, Popp (Gestaltung 1995), S. 47f. 309 Vgl. Frank, Prasse (Standardisierung 1997), S. 2 310 Vgl. Cribbs, Moon, Roe (Evaluation 1992), S. 65 311 Vgl. Cribbs, Moon, Roe (Evaluation 1992), S. 66; Oberweis (Modellierung 1996), S. 34; Frank, Prasse
100
Der Grundsatz der Klarheit sollte auch bei der Wahl des Deutungsmusters beachtet werden.
FRANK/PRASSE fordern von einer anschaulichen und verständlichen Modellierungssprache die
Verwendung von Deutungsmustern, die sich an der Sprach- und Denkwelt der betrachteten
Anwendungsdomäne orientieren.313 Sie wurden weiter oben (vgl. Abschnitt 3.1.1) als
materiellorientierte Deutungsmuster bezeichnet. Für die zu entwickelnde
Modellierungsmethode sollte daher ein materiellorientiertes Deutungsmuster gewählt werden,
welches sich an der Sprach- und Denkwelt zwischenbetrieblicher Transaktionen orientiert.
Anforderung Konsequenz Sprachadäquanz (Spracheignung)
• Inhaltliche Anforderungen an das Metamodell müssen erfüllt werden
Systematischer Aufbau • Unterschiedliche Sichten für Struktur und Verhalten vorsehen • Existenz eines integrierten, sichtenübergreifenden
Metamodells Klarheit • Wenige einfache, d. h. bekannte und verbreitete
Darstellungsmittel für die Notation verwenden • Per Hand zeichenbare Notation • Möglichkeit zur Hierarchisierung (Dekomposition) von
Modellen • Materiellorientiertes Deutungsmuster
Tab. 3-18 Formale Anforderungen an die Modellierungssprache
3.4.4 Formale Anforderungen an die Vorgehensweise
Der Grundsatz der Konstruktionsadäquanz fordert eine „problemangemessene
Nachvollziehbarkeit der Modellkonstruktion.“314 Aufgrund des konstruktiven
Modellverständnisses scheidet der Abgleich zwischen Modell und Realwelt als Bewertungs-
und Qualitätsmaßstab aus. Stattdessen wird von SCHÜTTE „als Bewertungskriterium für
Modelle der Konsens der am Modellbildungsprozeß [...] beteiligten Subjekte
vorgeschlagen.“315 Da die Modellierer bei einem verteilten Entwurf nicht physisch an einem
Ort zusammensitzen, um ihre Transaktionen zu planen und abzustimmen, muss der Konsens
durch andere Maßnahmen erreicht werden. Dazu kann ein durch Ontologien unterstütztes
Vorgehen gehören. Sie stellen standardisierte Konzeptualisierungen auf Fachkonzeptebene für
(Standardisierung 1997), S. 2; Schüppler (Informationsmodelle 1998), S. 135 u. S. 171; Schütte (Grundsätze 1998), S. 131 312 Vgl. Grund, Jähnig (Modell 1994), S. 50; Schütte (Grundsätze 1998), S. 131 313 Vgl. Frank, Prasse (Standardisierung 1997), S. 2. Vgl. ähnlich Cribbs, Moon, Roe (Evaluation 1992), S. 65 314 Schütte (Grundsätze 1998), S. 113 315 Schütte (Grundsätze 1998), S. 119f.
101
den verteilten Entwurf bereit. Durch Ontologien wird der Prozess der Einigung und
Konsensbildung quasi vorweggenommen.
Der Grundsatz der Sprachadäquanz im Sinne der Sprachrichtigkeit fordert die korrekte
Anwendung einer Modellierungssprache. Diese Forderung macht nur Sinn, wenn der
Modellierungssprache ein Metamodell zugrunde liegt. Die Sprachrichtigkeit eines Modells ist
dann gegeben, wenn das Modell vollständig und konsistent zum Metamodell ist.316 Die
Sprachrichtigkeit wird gefördert, wenn das Vorgehen der Modellierungsmethode schrittweise
und detailliert in Form einer Checkliste beschrieben wird.317
Der Grundsatz der Vergleichbarkeit zielt nach dem GoM-Ansatz auf den semantischen
Vergleich zweier Modelle ab.318 Ein solcher Modellvergleich geht davon aus, dass
(mindestens) zwei Modelle mit unterschiedlich zugrundeliegenden Metamodellen vorliegen,
die integriert werden sollen. Im Rahmen dieser Arbeit wird jedoch davon ausgegangen, dass
bei der verteilten, zwischenbetrieblichen Modellierung dieselbe Modellierungsmethode zum
Einsatz kommt. Der Grundsatz der Vergleichbarkeit wird hier daher anders interpretiert. Er
soll sicherstellen, dass ein und derselbe Sachverhalt von verschiedenen Modellierern nach
Möglichkeit gleich dargestellt wird. Probleme können dabei aufgrund abweichender
subjektiver Erfahrungen und unterschiedlichen Wissensständen in allen Modellierungsphasen
auftreten. Dazu gehören unterschiedliche Konzeptualisierungen des gleichen
Realweltausschnitts, das Verwenden unterschiedlicher Terminologien mit Synonymen und
Homonymen319 sowie der unterschiedliche Gebrauch der Modellierungssprache. Damit diese
Probleme nicht auftreten, ist sowohl die Konzeptualisierungs- als auch die
Formalisierungsphase durch geeignete methodische Maßnahmen und Hilfsmittel zu
unterstützen. Dazu gehört zum einen eine ontologiebasierte Modellierung. Sie könnte die
terminologischen Konflikte während der natürlichsprachlichen Formulierung lösen. Zum
anderen gehört dazu ein referenzgestütztes Vorgehen, welches Modellierungselemente
bereitstellt, die fachkonzeptuell standardisiert worden sind.
316 Vgl. Schütte (Grundsätze 1998), S. 126 317 BALZERT fordert daher den ‚Handbuchcharakter der Methodenbeschreibung‘. Vgl. Balzert (Analysemodell 1997), S. 39 318 Vgl. Schütte (Grundsätze 1998), S. 133 319 Eine ausführliche Erörterung terminologischer Konflikte und ihrer Ursachen erfolgt in Nederstigt (Konzeption 1996), S. 11ff.
102
Der Grundsatz der Klarheit wurde bereits bei den Anforderungen an die
Modellierungssprache erläutert. Aber nicht nur bei der Konstruktion einer
Modellierungssprache sollten Maßnahmen zur Förderung der Klarheit vorgesehen werden,
sondern auch bei der Vorgehensweise einer Modellierungsmethode. Probleme ergeben sich,
wenn die Anordnung der Symbole beliebig vom Modellierer bestimmbar ist. Die damit
gewonnenen Freiheitsgrade führen dazu, dass von verschiedenen Personen erstellte Modelle
in ihrer Anordnung stark differieren, schwer lesbar sind und ein inhaltlicher Vergleich nur
schwer durchführbar ist.320 Daher sind Regeln für die Layoutgestaltung von Modellen
anzugeben, die die Lesbarkeit und damit die Klarheit sowie Vergleichbarkeit von Modellen
erhöhen.321
Bei der Modellerstellung und der Modellwartung sind die ökonomischen Prinzipien
einzuhalten.322 Dieses fordert der Grundsatz der Wirtschaftlichkeit.323 Er ist konfliktionär zu
den bisher genannten Grundsätzen. Während letztere „Anforderungen an die Ausgestaltung
von Modellen und des Modellierungsprozesses postulieren, begrenzt der Grundsatz der
Wirtschaftlichkeit Umfang und Ausgestaltung von Modellierungsmaßnahmen, indem die
Forderung nach einem adäquaten Quotienten zwischen Nutzen und Kosten formuliert wird.“324
Eine Operationalisierung dieses Grundsatzes ist allerdings schwierig, da bislang die Theorie
einer spezifischen Modellierungskosten- und Modellierungsleistungsrechnung fehlt.325 Es
können allenfalls Annahmen über nutzbringende und kostenreduzierende Maßnahmen
getroffen werden. So ist anzunehmen, dass die Einhaltung der zuvor genannten
Anforderungen den Modellierungsnutzen im Rahmen einer Integration zwischenbetrieblicher
Informationsflüsse steigern kann. Ebenso erscheint es sinnvoll, die Kosten der Modellierung
beispielsweise durch ein ontologiebasiertes und referenzgestütztes Vorgehen zu reduzieren.326
Wie bereits erwähnt, kann durch den Einsatz von Referenzmodellen die zeit- und
kostenintensive Konsensbildung bei einer verteilten Modellierung vermieden werden.
320 Vgl. Keller, Popp (Gestaltung 1995), S. 47f. 321 Vgl. Becker, Rosemann, Schütte (Grundsätze 1995), S. 438 322 Vgl. Schüppler (Informationsmodelle 1998), S. 138 323 Vgl. Becker, Rosemann, Schütte (Grundsätze 1995), S. 438; Schütte (Grundsätze 1998), S. 127ff. 324 Schüppler (Informationsmodelle 1998), S. 138 325 Vgl. Becker, Rosemann, Schütte (Grundsätze 1995), S. 438 326 Vgl. Hars (Referenzdatenmodelle 1994), S. 32f.; Becker, Schütte (Handelsinformationssysteme 1996), S. 27f.; Schüppler (Informationsmodelle 1998), S. 138
103
Anforderung Konsequenz Konstruktionsadäquanz • Ontologiebasiertes Vorgehen (standardisierte Fachkonzepte) Sprachadäquanz (Sprachrichtigkeit)
• Existenz eines Metamodells • Checklistenform der Vorgehensweise
Vergleichbarkeit • Ontologiebasiertes Vorgehen (standardisierte Bezeichnungen) • Referenzgestütztes Vorgehen
Klarheit • Regeln für die Layoutgestaltung Wirtschaftlichkeit • Ontologiebasiertes Vorgehen
• Referenzgestütztes Vorgehen Tab. 3-19 Formale Anforderungen an die Vorgehensweise
3.5 Vorhandene Modellierungsansätze zur Integration zwischenbetrieblicher
Informationsflüsse
3.5.1 Überblick
Es existieren bereits einige wenige Modellierungsansätze zur Integration zwischenbetrieb-
licher Informationsflüsse. Sie sollen anhand der in den vorhergehenden Abschnitten
formulierten Anforderungen untersucht und bewertet werden. In die Untersuchung werden nur
diejenigen Ansätze einbezogen, die folgende Voraussetzungen erfüllen:
• Es existiert eine Modellierungssprache in Form einer grafischen Notation und/oder eines
Metamodells.
• Explizites Ziel ist die Gestaltung der zwischenbetrieblichen Informationsflüsse. Ansätze,
die ursprünglich für innerbetriebliche Systeme entwickelt wurden und die im Nachhinein
um zwischenbetriebliche Aspekte ergänzt wurden oder die sich grundsätzlich auch für
zwischenbetriebliche Szenarien eignen, werden nicht betrachtet.
• Die Beschreibung der Methode ist veröffentlicht worden und frei zugänglich. Damit
scheiden Methoden aus, die z. B. in kommerziellen Produkten implementiert worden sind
oder in der Praxis von großen Betrieben und insbesondere Beratungsunternehmen
eingesetzt werden.
104
Vom Autor wurden sechs Modellierungsansätze identifiziert und berücksichtigt, die diese
Voraussetzungen erfüllen: Open-EDI, UN/CEFACT Modelling Methodology (UMM),
RosettaNet, FUNSOFT-Netze, Ansatz von Henkel und Ansatz von Schüppler (vgl. Tab.
3-20).
Kürzel Ansatz Autor(en) Quelle(n) Open-EDI Open-edi reference model ISO/IEC327 • Bons u. a. (Trade 1994)
• ISO (Information 1997) UMM UN/CEFACT Modelling
Methodology TMWG der UN/CEFACT328
• TMWG (Guide 1998) • TMWG (UN/CEFACT
2001) RosettaNet RosettaNet Initiative RosettaNet-
Konsortium • RosettaNet (UML 1999) • RosettaNet (RosettaNet
1999) • RosettaNet (Purchase
2001) FUNSOFT FUNSOFT-Netze V. Gruhn u. a. • Deiters, Gruhn, Striemer
(Geschäftsprozeßmangement 1995)
• Gruhn, Kampmann (Modellierung 1996)
• Gruhn (Datenaustausch 1997)
Henkel Gestaltungsmethodik für elektronische Datenkommunikationssysteme in Logistiknetzen
S. Henkel • Henkel (Gestaltung 1996)
Schüppler Informationsmodelle für Interorganisationssysteme
D. Schüppler • Schüppler (Informationsmodelle 1998)
Tab. 3-20 Übersicht vorhandener Modellierungsansätze
327 International Organization for Standardization/International Electrotechnical Commission 328 Techniques and Methodologies Working Group des United Nations Centers for the Facilitation of Procedures and Practices for Administration, Commerce and Transport. UN/CEFACT ist das für die Entwicklung von UN/EDIFACT verantwortliche Normungsgremium der UNO.
105
3.5.2 Kurze Beschreibung der Ansätze
Im vorliegenden Abschnitt sollen die vorhandenen Modellierungsansätze zur Integration
zwischenbetrieblicher Informationsflüsse kurz beschrieben werden. Tab. 3-21 liefert dazu eine
zusammenfassende Übersicht.
Open-EDI UMM RosettaNet FUNSOFT Henkel Herkunft Normung Normung Praxis Forschung/ Praxis Forschung Wann 1989-1996 Seit 1997 Seit 1998 Seit 1992 1995 Veröffentlicht als ISO Norm 14662 Arbeitsberichte Industriestandard Diverse Fach-
aufsätze Dissertation
Einsatzfeld Universell Universell IT-Branche u. a. Bau- und Wohnungswirtschaft
Logistiknetze
Eingesetzte Modellierungstechnik
• Rollendiagramme • Sequenzdiagramme• Petri-Netze
• UML-Diagramme329 (Use case-, Klassen-, Collaborations-, Aktivitäts- und Sequenzdiagramme)
• UML-Diagramme (Klassen, Collaborations-, Aktivitäts- und Sequenzdiagramme)
• Petri-Netze • Entity-Relation
ship-Diagramme • Organigramme
• SOM (ObjeAufgabensystInteraktionsd
• Eigenes Pro• Nachrichte
Tab. 3-21 Kurzbeschreibung vorhandener Modellierungsansätze
Open-EDI
Bereits 1989 wurde die Open-EDI-Initiative von Vertretern nationaler und internationaler
Normungsgremien ins Leben gerufen. Sie hatte zum Ziel, den elektronischen Austausch
zwischen Betrieben unter Anwendung von Standards zu fördern. Dabei stand schon damals
die fachkonzeptuelle, implementierungsunabhängige Gestaltung von zwischenbetrieblichen
Abläufen im Mittelpunkt.330 Insbesondere wurde die Notwendigkeit von grafischen
Beschreibungsmöglichkeiten für betriebsübergreifende Prozesse gesehen. Das Open-EDI
reference model wurde schließlich 1997 als ISO- und IEC-Norm verabschiedet.331
Kern des Open-EDI reference models sind standardisierte Szenarien, die einen
zwischenbetrieblichen Informationsaustausch beschreiben. Wesentliche
Modellierungskonstrukte dieser Szenarien sind Rollen, Informationspakete („information
bundles“) und sogenannte Szenario-Attribute, die Aussagen über die Beziehungen zwischen
329 Zur UML vgl. Booch, Rumbaugh, Jacobson (Modeling 1999) 330 Vgl. Schüppler (Informationsmodelle 1998), S. 170 331 Vgl. ISO (Information 1997)
106
den Modellierungskonstrukten wiedergeben.332 Für die grafische Beschreibung der Szenarien
wird keine bestimmte Modellierungstechnik vorgeschrieben. Im Open-EDI reference model
werden lediglich Modellierungsbeispiele angeführt, wie ein Rollendiagramm, ein
Informationsflussdiagramm (welches UML-Sequenzdiagrammen ähnelt) sowie mehrere auf
Petri-Netzen basierende Ablaufdiagramme (vgl. Abb. 3.5).333
Open-EDI kann nicht als Modellierungsmethode betrachtet werden, da weder eine Notation
noch ein Vorgehen vorgegeben wird. Als einzige Komponente ist ein Metamodell vorhanden,
welches allerdings von der semantischen Mächtigkeit her recht beschränkt ist. Daher kann
Open-EDI von allen untersuchten Ansätzen die Anforderungen an eine
Modellierungsmethode zur Integration zwischenbetrieblicher Informationsflüsse am
wenigsten erfüllen.
Abb. 3.5 Modellierungsbeispiel eines Open-EDI-Szenarios mit Petri-Netzen334
UN/CEFACT Modelling Methodology (UMM)
332 Vgl. ISO (Information 1997), S. 14ff. 333 Zur Verwendung von Petri-Netzen im Rahmen von Open-EDI vgl. Bons u. a. (Trade 1994) 334 ISO (Information 1997), S. 34
107
Als Fortführung des Open-EDI-Ansatzes erarbeitete die TMWG der CEFACT einen
Reference Guide unter dem Titel „The Next Generation of UN/EDIFACT - an Open-EDI
approach using UML models & OOT“.335 Auslöser zu dieser Initiative war die Tatsache, dass
der UN/EDIFACT-Standard sich nicht in der Breite hat durchsetzen können, wie man es sich
bei seiner Entwicklung erhofft hatte. In der fachkonzeptuellen Modellierung
zwischenbetrieblicher Prozesse wurde ein Weg gesehen, die Situation zu verbessern. „The
approach is to model the entire business function, i.e., the activity being performed, and not to
focus on the information structure that might be contained in an interchange message.“336
Inzwischen wurden die Konzepte des 1998 erschienen Reference Guides zur UN/CEFACT
Modelling Methodology (UMM) weiterentwickelt.337 Sie wird beispielsweise im Rahmen der
ebXML-Initiative verwendet.
Abb. 3.6 Beispiel eines Sequenzdiagramms im Rahmen von UMM338
Während im ursprünglichen Open-EDI die Wahl der Modellierungstechnik und des
-vorgehens weitgehend offen war, ist im Rahmen von UMM eine ausführliche
Modellierungssprache unter Anwendung objektorientierter Prinzipien erarbeitet worden.
Dabei sind eine Reihe von UML-Diagrammen vorgesehen. Zum Einsatz kommen Use Case-,
Klassen-, Aktivitäts-, Sequenz- (vgl. Abb. 3.6) und Collaborations-Diagramme. Die
335 Vgl. TMWG (Guide 1998) 336 TMWG (Guide 1998), S. 6 337 Vgl. TMWG (UN/CEFACT 2001) 338 TMWG (Guide 1998), S. A-4
108
Vorgehensweise von UMM orientiert sich am Rational Unified Process (RUP), d. h. an den
von den Urhebern der UML vorgeschlagenen Entwicklungsschritten.339
RosettaNet-Initiative
RosettaNet ist eine Initiative von ursprünglich etwa vierzig führenden Unternehmen der IT-
Branche. Sie haben sich 1998 zusammengeschlossen, „to adopt and deploy open and common
business interfaces, enabling small and large buyers and sellers of computer technology to do
electronic business more effeciently“.340 Mittlerweile sind mehr als 350 Unternehmen an der
Initiative beteiligt. Die erarbeiteten Standards konnten sich erstaunlich schnell etablieren und
inzwischen gibt es eine Reihe von kommerziellen Anwendungssystemen, die die RosettaNet-
Standards unterstützen.
Im Rahmen der Initiative wurde ein Ebenenmodell für die elektronische Abwicklung von
Geschäftsprozessen entworfen. Kern dieses Modells sind sogenannte Partner Interface
Processes (PIPs). Jeder PIP besteht aus XML Dokumenten, die auf DTDs eines
Implementation Frameworks basieren, in dem die erforderlichen Transaktionen und
Nachrichten, d. h. das Protokoll eines bestimmten Prozesses festgelegt sind. PIPs werden
durch mehrere UML-Diagramme auf verschiedenen Abstraktionsniveaus spezifiziert.
Aktivitätsdiagramme, im RosettaNet-Ansatz Business Process Flow Diagramme genannt (vgl.
Abb. 3.7), veranschaulichen den zwischenbetrieblichen Informations- und Kontrollfluss aus
fachkonzeptueller Sicht. Die erforderlichen Softwarekomponenten und deren Zusammenspiel
werden in Collaborations- (RosettaNet: „Network Component Design“) und
Sequenzdiagrammen (RosettaNet: „Business Transaction Dialog Specification“) dargestellt.
Klassendiagramme werden zur Spezifikation der für einen PIP erforderlichen
Geschäftsdokumente verwendet, wobei die notwendigen Datenelemente in einem data
dictionary bereitgestellt werden. Es enthält Attribute zur technischen Spezifikationen von
Produkten sowie zur Beschreibung der beteiligten Betriebe und der Geschäftsabläufe.
RosettaNet bietet sowohl ein Metamodell als auch eine Notation, die viele Anforderungen an
eine Methode zur Integration zwischenbetrieblicher Informationsflüsse erfüllen können.
Besondere Stärken liegen hierbei in der Unterstützung der pragmatischen Integration. Für eine
339 Vgl. Kruchten (Rational 1998); Oestereich (Softwareentwicklung 2001), S. 20f. 340 RosettaNet (RosettaNet 1999), S. 1
109
vollständige Modellierungsmethode fehlt die Bereitstellung einer expliziten Vorgehensweise
sowie die inhaltliche Unterstützung der syntaktischen und semantischen Integration.
Abb. 3.7 Beispiel eines Business Process Flow Diagram zu einem RosettaNet PIP341
FUNSOFT-Netze
In einer Reihe von wissenschaftlichen Beiträgen zwischen 1995 und 1997 haben GRUHN u. a.
den Ansatz der FUNSOFT-Netze beschrieben.342 Seit 1992 finden FUNSOFT-Netze
Anwendung auf Geschäftsprozesse aus verschiedenen Bereichen, insbesondere auf
betriebsübergreifende Prozesse in der Bau- und Wohnungswirtschaft. Der FUNSOFT-Ansatz
ist mit dem Ziel entwickelt worden, das Vorgehen eines integrierten
Geschäftsprozessmanagements zu unterstützen. Dieses umfasst die Phasen Modellierung,
Modellanalyse, Durchführungsunterstützung und Postevaluierung.343 Der Ansatz wird durch
ein kommerzielles Geschäftsprozessmanagementtool unterstützt.
„Im FUNSOFT-Netz-Ansatz bestehen Geschäftsprozeßmodelle aus einer Beschreibung der zu
unterstützenden Abläufe, aus der Beschreibung der in den Abläufen zu erzeugenden und zu
verarbeitenden Informationen und aus der Beschreibung des organisatorischen Kontexts, in
dem der Geschäftsprozeß durchzuführen ist.“344 Die Darstellung der Abläufe, die den Kern des
341 Vgl. RosettaNet (Purchase 2001), S. 7 342 Vgl. Deiters, Gruhn, Striemer (Geschäftsprozeßmangement 1995); Gruhn, Kampmann (Modellierung 1996); Gruhn (Datenaustausch 1997) 343 Vgl. Deiters, Gruhn, Striemer (Geschäftsprozeßmangement 1995), S. 460 344 Gruhn (Datenaustausch 1997), S. 227
110
Ansatzes ausmachen, basieren auf Petri-Netzen.345 Transitionen repräsentieren dabei
Aktivitäten in einem Prozess, während Stellen Objekt- und Dokumentenspeicher darstellen.
Die Objekt- und Dokumenttypen selbst werden mit Hilfe erweiterter Entity-Relationship-
Modelle beschrieben. Organigramme und Rollendefinitionen beschreiben den
organisatorischen Kontext.
Aus den veröffentlichten und hier zitierten Aufsätzen zum FUNSOFT-Netz-Ansatz geht
allerdings nicht genau hervor, welche Methodenkomponenten tatsächlich vorliegen. So wird
in einem Aufsatz lediglich der Ausschnitt eines Metamodells vorgestellt.346 Die Existenz einer
Vorgehensweise erscheint wahrscheinlich, da der Ansatz kommerziell eingesetzt wird. In den
Aufsätzen wird sie allerdings nicht beschrieben. Inhaltlich und formal kann der FUNSOFT-
Ansatz die aufgestellten Anforderungen insgesamt nur in Teilen erfüllen.
Abb. 3.8 Beispiel einer betriebsübergreifenden Prozesskette mit FUNSOFT-Netzen347
Ansatz von Henkel
1995 veröffentlichte HENKEL seine Dissertation mit dem Titel „Gestaltung elektronischer
Datenkommunikationssysteme in Logistiknetzen“.348 Sein Ziel war unter anderem die „Ent-
345 zu Petri-Netzen vgl. beispielsweise Ferstl, Sinz (Grundlagen 1998), S. 19ff. 346 Vgl. Deiters, Gruhn, Striemer (Geschäftsprozeßmangement 1995), S. 463 347 Gruhn (Datenaustausch 1997), S. 227
111
wicklung einer systematischen Gestaltungsmethodik für die ganzheitliche Planung EDI-
gestützter Kommunikationssysteme in Logistiknetzen und für die erfolgreiche Bewältigung
der EDIFACT- und der Systemintegrationsschwelle.“349 Der Ansatz von HENKEL richtet sich
an Projektgruppen, die mit der Entwicklung und Einführung von EDI-Systemen beauftragt
sind. Das methodische und modellgestützte Vorgehen soll eine transparente Darstellung der
Projektergebnisse ermöglichen. Damit wird eine gemeinsame Diskussions- und
Gestaltungsgrundlage für die Projektmitglieder, projektexternen Entscheidungsträger und
auch für die Mitarbeiter betroffener Fachabteilungen geschaffen. Sie ist Voraussetzung für
eine effiziente und effektive Projektdurchführung.
HENKELs Ansatz sieht den Einsatz mehrerer Diagrammtypen vor. Einige davon entstammen
der von FERSTL/SINZ entwickelten SOM-Methodik350, an dessen Vorgehensmodell sich
Henkel stark anlehnt. So zeigt das Objektsystem die hierarchische Organisationsstruktur der
an einer zwischenbetrieblichen Transaktion beteiligten betrieblichen Akteure. Im
Aufgabensystem werden deren Aufgaben an den Schnittstellen der betroffenen Betriebe
detailliert aufgeführt. Die statische Struktur der Leistungs-, Zahlungs- und
Informationsflussbeziehungen
ohne Zeitbezug verdeutlicht das Interaktionsmodell. Zur Darstellung der zeitlichen
Reihenfolge der Prozessschritte, d. h. des Ablaufs einer Transaktion, setzt HENKEL einen
eigenen Diagrammtyp, das sogenannte Prozessmodell ein (vgl. Abb. 3.9). Für die
Beschreibung der auszutauschenden Geschäftsdokumente sind Nachrichtenstruktogramme
vorgesehen, wie sie in Forschungs- und EDI-Implementierungsprojekten sowie in
Standardisierungsprojekten zur Definition von UN/EDIFACT-Subsets eingesetzt werden.
Da HENKEL lediglich eine Notation vorstellt und seine Vorgehensweise nicht explizit als
solche präsentiert, kann nicht von einer vollständigen Modellierungsmethode gesprochen
werden. Gut abgedeckt sind die Anforderungen zur Modellierung von Nachrichtenstrukturen
sowie zur Unterstützung der pragmatischen Integration. Vernachlässigt werden allerdings die
Aspekte der syntaktischen und semantischen Integration.
348 Vgl. Henkel (Gestaltung 1996) 349 Henkel (Gestaltung 1996), S. 16f. 350 SOM - Semantisches Objektmodell. Vgl. Ferstl, Sinz (Grundlagen 1998), S. 176ff.
112
Abb. 3.9 Beispiel eines Prozessmodells nach dem Ansatz von HENKEL351
Ansatz von Schüppler
Die von SCHÜPPLER 1998 vorgelegte Dissertation trägt den Titel „Informationsmodelle für
Interorganisationssysteme - ein Metamodell für die Beziehung zwischen Industrie und
Handel“.352 Neben der „Beschreibung der Anforderungen, die an eine Methode zur Erklärung
und Gestaltung überbetrieblicher Informationssysteme zu richten sind,“353 war die
Entwicklung eines entsprechenden Regelsystems in Form eines Metadatenmodells das
erklärte Ziel von SCHÜPPLER. Seine Arbeit richtet sich an Mitarbeiter der Bereiche Strategie,
Informationstechnik und Organisation, die mit der Gestaltung überbetrieblicher Prozesse
beauftragt sind.
Wie Open-EDI, so schreibt auch SCHÜPPLER keine bestimmte grafische Modellierungstechnik
für seinen Ansatz vor. Der Anwender ist prinzipiell frei in der Wahl der Notation und
Diagrammtypen. Stattdessen stellt SCHÜPPLER ein umfassendes Metamodell vor, das mehrere
Sichten und Perspektiven auf zwischenbetriebliche Transaktionen unterstützt. In Anlehnung
an die ARIS-Architektur354 werden dabei die Daten-, Organisations- und Funktionssicht sowie
351 Henkel (Gestaltung 1996), S. 195 352 Vgl. Schüppler (Informationsmodelle 1998) 353 Vgl. Schüppler (Informationsmodelle 1998), S. 7 354 ARIS - Architektur integrierter Informationssysteme. Vgl. Scheer (Wirtschaftsinformatik 1994), S. 10ff.
113
eine integrierende Sicht unterschieden. Letztere bildet einen Schwerpunkt bei der
Berücksichtigung in SCHÜPPLERs Metamodell. Für die integrierende Beschreibungssicht wird
der Einsatz von EPKs355 empfohlen und beschrieben.
Von allen untersuchten Ansätzen kann das Metamodell von Schüppler die Anforderungen
inhaltlich am weitgehendsten erfüllen. Lediglich bei der Unterstützung der syntaktischen und
semantischen Integration sind Abstriche zu machen. Zu einer vollwertigen
Modellierungsmethode fehlt allerdings die Festlegung einer Notation sowie einer
Vorgehensweise.
355 EPK- Ereignisgesteuerte Prozesskette. Vgl. Scheer (ARIS-Modellierungsmethoden 1998), S. 125ff.
114
Abb. 3.10 Beispiel einer betriebsübergreifenden Prozesskette mit EPKs356
356 Schüppler (Informationsmodelle 1998), S. 163
115
3.5.3 Zusammenfassende Bewertung
Wie Tab. 3-22 zeigt, umfasst keiner der untersuchten Ansätze sämtliche Komponenten einer
Modellierungsmethode, d. h. Metamodell, Notation, Vorgehensweise sowie
Werkzeugunterstützung. Im Vordergrund steht zumeist die Bereitstellung einer
Modellierungssprache, teilweise basierend auf einem Metamodell. Zwei Ansätze dagegen
beschränken sich auf die Vorgabe eines Metamodells ohne Festlegung auf eine bestimmte
Notation (Open-EDI, Schüppler). Nur die UMM beschreibt explizit eine definierte
Vorgehensweise. FUNSOFT ist der einzige Ansatz mit einer Werkzeugunterstützung.
Normung Praxis Wissenschaft
Open-EDI
UMM RosettaNet
Funsoft
Henkel
Schüppler
Metamodell - Notation Vorgehensweise - Werkzeugunterstützung Legende: vorhanden teilweise vorhanden nicht vorhanden - nicht feststellbar
Tab. 3-22 Umfang vorhandener Modellierungsansätze
Mit Ausnahme des Ansatzes von Schüppler werden von keinem Ansatz die Anforderungen
zur Beschreibung von Strukturen und Abläufen vollständig abgedeckt. Die Anforderungen zu
den Nachrichtenstrukturen und zur Unterstützung der pragmatischen Integration werden von
vielen, aber nicht allen Ansätzen erfüllt (vgl. Tab. 3-23). Schwächen bestehen durchweg bei
den Aspekten der syntaktischen und semantischen Integration. Während sämtliche Ansätze
die allgemeinen Anforderungen erfüllen, können die formalen Anforderungen zur
Modellierungssprache und zur Vorgehensweise nur teilweise oder gar nicht erfüllt werden.
116
Wie die Untersuchung zeigt, kann keiner der vorhandenen Ansätze die Anforderungen an eine
Modellierungsmethode zur Integration zwischenbetrieblicher Informationsflüsse in
befriedigendem Maße erfüllen. Daher wird in den folgenden beiden Kapiteln eine eigene
Modellierungsmethode zur Integration zwischenbetrieblicher Informationsflüsse entwickelt
und beschrieben.
Normung Praxis Wissenschaft
Open-EDI
UMM RosettaNet
Funsoft
Henkel
Schüppler
Beschreibung von Strukturen und Abläufen
Nachrichtenstrukturen Syntaktische und semantische Inte-gration
Inhaltliche Anforder-ungen
Fachliche Aufgaben einer Integration
Pragmatische Integration
Allgemeine Anforderungen Modellierungssprache
Formale Anforderungen Vorgehensweise
Legende: Anforderung größtenteils erfüllt Anforderung teilweise erfüllt Anforderung nicht erfüllt
Tab. 3-23 Zusammenfassende Bewertung vorhandener Modellierungsansätze357
357 Eine ausführliche Einzelbewertung eines jeden Ansatzes zu jeder Anforderung ist im Anhang dargestellt.
117
4 Modellierungsmethode für den verteilten Entwurf zwischen-betrieblicher Informationsflüsse (MOVE)
4.1 MOVE im Überblick
4.1.1 MOVE als Teilergebnis des Forschungsprojektes MOVE
Wie in der Einleitung bereits erwähnt, sind wesentliche Teile und Konzepte dieser Arbeit im
Rahmen des Forschungsprojektes MOVE358 entstanden. Übergreifendes Projektziel war es,
eine Architektur zu schaffen, mit der Transaktionen zwischen Betrieben der Industrie und des
Groß- und Einzelhandels bis hin zum Endverbraucher in verschiedenen Branchen analysiert
werden können, um die daraus resultierenden Informationsflüsse effektiv (hinsichtlich der
Inhalte und Adressaten) und effizient (hinsichtlich der Zeit und Kosten) zu gestalten.359
Im Ergebnis sieht die MOVE-Architektur ein stufen- bzw. schichtenweises Vorgehen für den
Entwurf zwischenbetrieblicher Informationssysteme vor. Unterschieden werden eine
Branchen-, eine System- und eine DV-Schicht. Auf der Branchenschicht wird eine
geschäftliche Perspektive auf die betriebswirtschaftlichen Strukturen und korrespondierenden
Informationsflüsse einer Branche eingenommen. Es wurden Werkzeuge (Nutzwertmodell,
Simulationsmodell) zur Analyse und wirtschaftlichen Bewertung verschiedener
Gestaltungsalternativen für zwischenbetriebliche Transaktionen prototypisch entwickelt. Eine
fachliche Sicht wird von den Werkzeugen (Modellierungsmethode und entsprechendes
Entwurfsinstrument) der Systemschicht geboten. Ausgehend von der Branchenschicht werden
auf der Systemschicht
zwischenbetriebliche Transaktionen in ihren einzelnen Komponenten detailliert als fachliche
Modelle konstruiert. Insbesondere werden Inhalte und Abläufe der Informationsflüsse
festgelegt. Auf Basis der Modelle der Branchen- und Systemschicht können die für ein
zwischenbetriebliches Informationssystem erforderlichen Softwareobjekte generiert und in ein
Framework, welches für die DV-Schicht entwickelt wurde, eingebettet werden.
Die nachfolgend beschriebenen Prinzipien sind charakteristisch für die MOVE-Architektur.360
358 MOVE steht im ursprünglichen Forschungsprojekt für „Modellierung einer verteilten Architektur für die Entwicklung unternehmensübergreifender Informationssysteme und ihre Validierung im Handelsbereich“ 359 Vgl. BFK u. a. (Modellierung 1995), S. 1 360 Vgl. zu den nachfolgenden Ausführungen Fischer (MOVE 1999), S. 14ff.
118
Autonomes Prinzip (outside-in view)
In der MOVE-Architektur werden die existierenden Strukturen der innerbetrieblichen
Informationssysteme als nicht unmittelbar veränderbar akzeptiert. Die erforderlichen
Harmonisierungen für eine Integration unternehmensübergreifender Informationsflüsse
werden an spezielle Komponenten eines zwischenbetrieblichen Informationssystems delegiert,
mit deren Hilfe die innerbetrieblichen Systeme als "gekapselte Systeme" beschrieben werden.
Das
zwischenbetriebliche Informationssystem wird also so konzipiert, dass es autonom gegenüber
den innerbetrieblichen Systemen agieren kann (outside-in view).
Flussorientiertes Prinzip
Als Modellierungsmetapher konkurrieren bei zwischenbetrieblichen Informationssystemen
das Netz und der Fluss.361 Netzwerke werden als Organisationsform zwischen Markt und
Hierarchie gesehen, bei denen selbstständige Unternehmen flexibel zusammenwirken, um
wenig spezifische Leistungen auszutauschen.362 In MOVE wird spezifischer der Fluss
zwischen wertschöpfenden Aktivitäten zugrunde gelegt, um das übergreifende wirtschaftliche
Ziel (Wertschöpfung), die Koordinations- und Konfigurationsaufgaben (Separierung der
wertschöpfenden Aktivitäten, Arbeitsteilung und Austauschbarkeit der Geschäftspartner)
zwischenbetrieblicher Transaktionen sowie die zentrale Rolle der Informationsflüsse
herauszustellen.363 Letztere sollen durch MOVE in ihren Inhalten und Abläufen für den
gesamten Fluss konfiguriert werden.
Materiellorientiertes Prinzip
Grundlegend für die MOVE-Architektur ist ein materiellorientierter Entwurfsrahmen. Der
Entwurfsrahmen enthält vier Entwurfselemente (Klient, Interaktion, Objekt, Kanal), die durch
weitere beschreibende Elemente (Attribute, Rollen) ergänzt werden (vgl. Tab. 4-1). Er heißt
materiellorientiert, da die Entwurfselemente des MOVE-Rahmens - im Gegensatz zu ab-
strakten Entwurfselementen anderer Modellierungssprachen wie beispielsweise Entity,
Relationship, Klasse oder Objekt364 - der Sprach- und Denkwelt zwischenbetrieblicher Trans-
aktionen entstammen. Im Abschnitt 4.2 wird der Entwurfsrahmen ausführlicher erläutert.
361 Vgl. Fischer (MOVE 1999), S. 11 362 Vgl. Picot (Organisationsstrukturen 1993), S. 58f. 363 Vgl. Porter (Wettbewerbsvorteile 1992), S. 62; Blecker (Unternehmung 1999), S. 107 364 Hier im Sinne der Objektorientierung der Softwaretechnologie gemeint. Vgl. beispielsweise Balzert
119
„Tintenklecks“-Prinzip
In MOVE werden innerbetriebliche, notwendigerweise heterogene Systeme in ein gleich-
rangiges, autonomes zwischenbetriebliches Informationssystem partiell nur soweit integriert,
wie es für effiziente und effektive Transaktionen erforderlich ist. Zunächst notwendigerweise
entstehende Insellösungen sind in einem meist mehrjährigen Prozess zu integrieren
(„Tintenklecks“–Ansatz). Das MOVE-Vorgehensmodell unterstützt ein entsprechendes
Prototyping, in dem aus wirtschaftlicher und technischer Sicht schrittweise ein integriertes
zwischenbetriebliches Informationssystem entsteht.
Die Modellierungsmethode zur Integration zwischenbetrieblicher Informationsflüsse, die im
weiteren Verlauf dieses Kapitels vorgestellt wird, basiert im Wesentlichen auf den für die
Systemschicht der MOVE-Architektur erarbeiteten Konzepten und Ergebnissen.365 Neben den
im Kapitel 3 aufgestellten Anforderungen waren daher die MOVE-Prinzipien entwurfsleitend
für die Modellierungsmethode. Sie wurde im Rahmen der vorliegenden Arbeit theoretisch
fundiert sowie konzeptionell verfeinert und ergänzt. Aufgrund der dadurch neu gewonnenen
Erkenntnisse haben sich Abweichungen gegenüber den ursprünglichen Konzepten und
Ergebnissen des MOVE-Projektes ergeben.
4.1.2 Grundlegender Aufbau und Vorgehensweise
Zur Gestaltung einer zwischenbetrieblichen Integration ist die Methode „MOVE“ entwickelt
worden. Hierbei wird das Akronym MOVE gegenüber der ursprünglichen Bedeutung im
Forschungsprojekt MOVE umgedeutet und steht für Modellierungsmethode für den verteilten
Entwurf zwischenbetrieblicher Informationsflüsse. Es wird der im Abschnitt 3.2 dargelegte
Ansatz unter Beachtung der zuvor beschriebenen MOVE-Prinzipien verfolgt. Danach ist der
Grundgedanke von MOVE, dass sich zwischenbetriebliche Informationsflüsse auf bestimmte
Gegenstände und Geschehnisse der realen Geschäftswelt beziehen. Diese reale Welt soll
zunächst von den Betrieben, d. h. den Sendern und Empfängern zwischenbetrieblicher
Informationsflüsse als Modell rekonstruiert werden. Auf Basis der Modellierungsergebnisse
sollen im Weiteren die erforderlichen Geschäftsnachrichten in ihren Inhalten, Strukturen und
Abläufen festgelegt werden. MOVE sieht einen verteilten Entwurf vor, bei dem jeder Betrieb
(Lehrbuch 1999) 365 Vgl. Steffen (Design 1999); Steffen (Modellierung 2000)
120
ein Modell seiner zwischenbetrieblichen Transaktionen erstellt und vor diesem Hintergrund
seine Nachrichten spezifiziert.
Die Modellierungssprache von MOVE besteht aus fünf Diagrammtypen (vgl. Abb. 4.1), zu
denen es jeweils eine fest definierte Vorgehensweise gibt. MOVE verfolgt aus der Makrosicht
ein Top-down-Vorgehen, bei dem der Detaillierungsgrad der Modelle ständig zunimmt. Auf
jeder Detaillierungsebene gibt es Diagramme zur Modellierung der Struktur- und
Verhaltenssicht. Zunächst werden auf der obersten Ebene in einem Transaktionsdiagramm
sämtliche an einer zwischenbetrieblichen Transaktion beteiligten Betriebe mit ihren Rollen
sowie die auftretenden Interaktionen aufgeführt. Jede Interaktion ist durch ein
Interaktionsdiagramm detaillierter zu beschreiben. Die alternativen Abläufe und
Gestaltungsmöglichkeiten einer Transaktion werden durch Sequenzdiagramme dargestellt.
Auf der untersten Ebene werden schließlich die auszutauschenden Nachrichten mittels
Nachrichtendiagrammen spezifiziert. Regeldiagramme beschreiben erforderlichen Integritäts-
und Prüfregeln.
Ein verteilter Entwurf erfordert entgegen der bislang üblichen syntaxorientierten
Standardisierung von Nachrichtenformaten (vgl. Kapitel 2) eine Standardisierung der
verwendeten Konstruktionselemente auf fachkonzeptueller Ebene. Daher wird zur
Unterstützung des Modellierungsprozesses ein materiellorientierter Entwurfsrahmen sowie
eine Referenzbibliothek vorgesehen. Der durch die MOVE-Architektur vorgegebene
materiellorientierte Entwurfsrahmen bildet die Grundlage sämtlicher Diagrammtypen. Die
Referenzbibliothek enthält eine Ontologie für die Modellierung zwischenbetrieblicher
Transaktionen, Referenzklassen sowie Nachrichtenbausteine.
Regeldiagramm
Referenzen
Transaktionsdiagramm
Struktursicht Verhaltenssicht
Materiellorientierter Entwurfsrahmen
Interaktionsdiagramm
Sequenz-diagramm
Referenz-bibliothek(Ontologie,Referenz-klassen,
Nachrichten-bausteine)Nachrichtendiagramm
Abb. 4.1 Komponenten der MOVE-Modellierungssprache im Überblick
121
4.2 Materiellorientierter Entwurfsrahmen
Grundlegend für MOVE ist ein materiellorientierter Entwurfsrahmen, der durch die MOVE-
Architektur vorgegeben worden ist. Er orientiert sich an den Leistungs-, Zahlungs- und
Informationsflüssen, die im Rahmen zwischenbetrieblicher Transaktionen zwischen Unter-
nehmen und Haushalten ausgetauscht werden. Aus einem einfachen Sender-Empfänger-
Modell zwischenbetrieblicher Flüsse ergeben sich die vier Entwurfselemente Klient, Inter-
aktion, Objekt und Kanal (vgl. Abb. 4.2). Der Entwurfsrahmen ist Basis für die zentralen
Modellierungskonzepte der Referenzbibliothek sowie der einzelnen Diagrammtypen. Er
enthält die genannten vier Entwurfselemente, die durch weitere beschreibende Elemente
ergänzt werden (vgl. Tab. 4-1).
Kanal
Klient(Sender)
Klient(Empfänger)
Objekt
Interaktion
Abb. 4.2 Entwurfselemente von MOVE
Betriebe sind die agierenden Einheiten (Akteure, Subjekte) einer zwischenbetrieblichen
Transaktion. Sie treten als Sender und Empfänger von Leistungen, Zahlungen und Informa-
tionen auf. Im Entwurfsrahmen werden sie als Klienten bezeichnet. Die Übertragung von
Leistungen, Zahlungen oder Informationen eines Klienten zu einem oder mehreren anderen
Klienten wird als Interaktion bezeichnet. Interaktionen werden durch ein Objekt und einen
Kanal näher bestimmt. Das Objekt366 ist Gegenstand von Interaktionen, d. h. es handelt sich
um eine Leistung, eine Zahlung oder eine Information. Zur Realisierung einer Interaktion ist
ein Kanal erforderlich, auf dem das Objekt übertragen wird.
Die Entwurfselemente werden durch beschreibende Elemente, die Attribute und Rollen, näher
charakterisiert. Attribute stellen die im Rahmen zwischenbetrieblicher Transaktionen
relevanten und bedeutsamen Eigenschaften der Entwurfselemente dar. Zwischenbetriebliche
Transaktionen laufen nach gewissen Regeln ab, die durch rechtliche Vorgaben und
kaufmännische Gepflogenheiten bestimmt werden. Nach diesen Regeln übernehmen Klienten
366 Soweit nicht gesondert vermerkt, wird nachfolgend der Begriff ‚Objekt‘ nicht im objektorientierten Sinn der Softwaretechnologie gebraucht (vgl. beispielsweise Balzert (Lehrbuch 1999)), sondern bezeichnet ein Entwurfselement im MOVE-Entwurfsrahmen.
122
und Objekte eine bestimmte Funktion bzw. Rolle. Durch die Zuordnung einer Rolle kann
diese Funktion in einer Transaktion beschrieben werden. Interaktionen und Kanäle treten per
se nur in einem bestimmten Kontext auf. Ihnen wird daher keine Rolle zugewiesen.
Entwurfselemente Klient Interaktion Objekt Kanal Kurzbeschreibung • An
zwischenbetrieblicher Transaktion beteiligter Betrieb
• Sender und/oder Empfänger von Leistungen, Zahlungen und/oder Informationen
• Veranlasst und reagiert auf Interaktionen
• Übertragung einer Leistung, Zahlung oder Information über einen Kanal zwischen Betrieben im Rahmen einer Transaktion
• Leistung, Zahlung oder Information
• Wird zwischen Betrieben übertragen
• Ist Gegen-stand367 von Interaktionen
• Verbindung zwischen Betrieben zur Übertragung von Leistungen, Zahlungen und/oder Informationen
• Bildet zulässigen Weg für Interaktionen
Beispiele • Industriebetrieb • Handelsbetrieb • Bank • Privater Haushalt
• Liefern • Überweisen • Beauftragen
• Produkt • Zahlungsmittel • Nachricht
• Transportweg • Kommunika-
tionsweg
Beschreibende Elemente
• Attribut • Rolle
• Attribut • Attribut • Rolle
• Attribut
Tab. 4-1 Materiellorientierter Entwurfsrahmen368
4.3 Referenzbibliothek
4.3.1 Anliegen und Inhalte der Referenzbibliothek
MOVE sieht verschiedene Maßnahmen zur Unterstützung des Modellierungsprozesses vor,
um die im Abschnitt 3.1.2 angesprochenen Probleme eines verteilten Entwurfs zu vermeiden.
So wird vorgeschlagen, auf der Grundlage des vorgestellten Entwurfsrahmens eine
Referenzbibliothek aufzubauen. Diese sollte aus einer Ontologie für die Modellierung
zwischenbetrieblicher Transaktionen, aus Referenzklassen und aus Nachrichtenbausteinen
bestehen. Eine solche Referenzbibliothek kann zusammen mit dem Entwurfsrahmen die
verschiedenen
(Mikro-)Phasen einer verteilten, dezentralen Modellierung unterstützen (vgl. Abb. 4.3).
367 Damit sind sowohl materielle (z. B. Warenpaket, papierbasierte Bestellung) als auch immaterielle (z. B. elek-tronische Bestellung) Gegenstände gemeint. 368 Vgl. Fischer (MOVE 1999), S. 13. Mit der HARVEY-Architektur hat FISCHER einen ähnlichen Entwurfs-rahmen für den Entwurf innerbetrieblicher Informationssysteme entwickelt. Vgl. Fischer (Informationswirtschaft 1999), S. 239ff.
123
Der MOVE-Entwurfsrahmen dient zur Unterstützung der mentalen Modellkonstruktion
während der Konzeptualisierungsphase. Er stellt für alle an einem verteilten
Modellierungsprozess beteiligten Personen ein gemeinsames, standardisiertes Deutungsmuster
dar.369 Die Wahl des Deutungsmusters bestimmt die grundsätzliche Sichtweise auf den zu
modellierenden Gegenstand. Bei einer verteilten Modellierung ist die Verwendung eines
einheitlichen Deutungsmusters unerlässlich.
Originalnatürlich-
sprachlichesModell
formal-sprachliches
ModellTrans-formation
Internes(mentales)
Modell Expli-kationKonstruktion
KonzeptualisierungFormalisierung
MentaleModellkonstruktion
NatürlichsprachlicheModellkonstruktion
Entwurfs-rahmen
OntologieReferenz-
-bibliothek
Referenzklassenund Nachrichten-
bausteine
Modellierungs-phase
Modellierungs-unterstützung
Modellierungs-handlung
Abb. 4.3 Unterstützung des Modellierungsprozesses bei MOVE
Die Resultate der Konzeptualisierung können als begriffliche Strukturierung der Realitäts-
erfahrungen aufgefasst werden.370 Eine Ontologie für die Modellierung zwischenbetrieblicher
Transaktionen soll die Verwendung einer einheitlichen Terminologie bei der
natürlichsprachlichen Modellkonstruktion sicherstellen. Sie sollte daher die zur Beschreibung
zwischenbetrieblicher Transaktionen wesentlichen Begriffe, ihre Definitionen sowie die
Beziehungen zwischen den Begriffen enthalten.
Neben der Ontologie sollen in der Referenzbibliothek standardisierte Referenzklassen für die
Entwurfselemente sowie Nachrichtenbausteine zur Spezifikation von Nachrichten
bereitgestellt werden. Sie dienen der Unterstützung der grafischen Modellierung während der
Formalisierungsphase.
369 Vgl. Abschnitt 3.1.1: Unter einem Deutungsmuster wird hier die Art und Weise, die Dinge zu sehen, verstanden. „Deutungsmuster entscheiden nicht nur [...] darüber, was wahrgenommen wird, sondern auch darüber, als was der Gegenstand der Wahrnehmung zu denken ist.“ Bretzke (Problembezug 1980), S. 42f. (Hervorhebungen im Original) 370 Vgl. Zelewski, Schütte, Siedentopf (Ontologien 1999), S. 3
124
4.3.2 Ontologie
Zur Kontrolle der Terminologie während der Modellierungsphase der natürlichsprachlichen
Formulierung ist eine Ontologie zu erarbeiten. Dabei soll es sich um eine domänenspezifische
Ontologie handeln, die die für die Modellierung zwischenbetrieblicher Transaktionen
wesentlichen Begriffe und deren Zusammenhänge wiedergibt. Das Metamodell dieser
Ontologie lässt sich in drei Teilmodelle gliedern: Teilmodell Terminologie, Teilmodell Meta-
Ontologie und Teilmodell Semantische Regeln.
Terminologie
Wesentliche Aufgabe der Ontologie ist es, bei einem verteilten Entwurf die einheitliche
Verwendung von Begriffen sicherzustellen. Daher ist jedem Begriff der Ontologie - im
Metamodell als ontologische Klasse bezeichnet (vgl. Abb. 4.4) - eine standardisierte
Vorzugsbezeichnung zuzuweisen. Daneben sollen einer ontologischen Klasse noch weitere
(synonyme) Bezeichnungen unter Angabe der Begriffswelt,371 aus der sie stammen,
zuordenbar sein. Eine ontologische Klasse wird somit durch mehrere Bezeichnungen
repräsentiert. Dadurch wird es den an einem verteilten Entwurf beteiligten Modellierern
ermöglicht, die gewohnte, habitualisierte Terminologie ihrer Begriffswelten
wiederzufinden.372
Begriffe stehen in vielfältiger Weise mit anderen Begriffen in Beziehung. Grundsätzlich
werden hierarchische (gerichtete) und nicht-hierarchische (ungerichtete) Beziehungen
zwischen Begriffen unterschieden.373 Bei den hierarchischen Beziehungen unterscheidet man
zwei Hauptformen: die Generalisierungs-/Spezialisierungsbeziehung374 und die Aggregations-
beziehung.375 Wichtigste Vertreter der nicht-hierarchischen Beziehungen sind die
Ähnlichkeitsbeziehung und die Assoziationsbeziehung. Daneben existieren eine Reihe
weiterer Beziehungstypen, wie beispielsweise die Nachfolgebeziehung (Vorgänger -
371 Zum Begriff 'Begriffswelt' vgl. Nederstigt (Konzeption 1996), S. 35f. 372 Vgl. Schüppler (Informationsmodelle 1998), S. 191 373 Vgl. Normenausschuss Terminologie (DIN2331 1980), S. 2 374 In der Literatur finden sich auch andere Bezeichnungen für diese Art der hierarchischen Beziehung, z. B. Subordination (vgl. Ortner (Aspekte 1983), S. 91ff.), Abstraktionsbeziehung, logische Beziehung oder gene-rische Beziehung (vgl. Normenausschuss Terminologie (DIN2331 1980), S. 2). 375 Oder auch Bestandsbeziehung, partitive Beziehung, Ganzes-Teil-Beziehung. Vgl. Normenausschuss Terminologie (DIN2331 1980), S. 2. ORTNER verwendet den Begriff ‚Partizipation‘. Vgl. Ortner (Aspekte 1983), S. 101f.
125
Nachfolger), die Kausalbeziehung (Ursache - Wirkung) und die Transmissionsbeziehung
(Sender - Empfänger).376
In der Ontologie für die Modellierung zwischenbetrieblicher Transaktionen sollen zur
Kontrolle der Terminologie lediglich Generalisierungs-/Spezialisierungsbeziehungen und
Aggregationsbeziehungen zwischen ontologischen Klassen berücksichtigt werden. Unter einer
Generalisierungs-/Spezialisierungsbeziehung wird eine "hierarchische Relation zwischen zwei
Begriffen [verstanden; T.S.], von denen der untergeordnete Begriff (Unterbegriff) alle
Merkmale des übergeordneten Begriffs (Oberbegriff) besitzt und zusätzlich mindestens ein
weiteres (...) Merkmal."377 Dagegen kennzeichnet eine Aggregationsbeziehung eine
"hierarchische Relation zwischen zwei Begriffen, von denen der übergeordnete (...) Begriff
(Verbandsbegriff) einem Ganzen entspricht und der untergeordnete (...) Begriff (Teilbegriff)
einen der Bestandteile dieses Ganzen repräsentiert."378
OntologischeKlasse
wird re-präsentiert
durchBezeichnung
1
BezeichnungVorzugsbezeichnung
verwendetBegriffswelt cm
Definitionwird
festgelegtdurch
1
Generalisierung/Spezialisierung
Aggregation
cmcm
D,T
m
1
D,T
c
BezeichnungSynonym
1
steht inBeziehung
zu
übergeordnet
untergeordnet
Abb. 4.4 Metamodell zur Kontrolle der Terminologie
Meta-Ontologie
Bei der Entwicklung einer Ontologie, die im Rahmen von MOVE eingesetzt werden soll, sind
gewisse Vorgaben zu beachten. Diese werden durch eine Meta-Ontologie beschrieben.379 In
der MOVE-Meta-Ontologie spiegelt sich der in Abschnitt 4.2 erläuterte Entwurfsrahmen
wider. So sind die Phänomene der betrachteten Realwelt, d. h. der zwischenbetrieblichen
Transaktionen, zu unterscheiden nach den Entwurfselementen Klient, Objekt, Interaktion und
Kanal. Fällt ein Gegenstand nicht unter diese Kategorien, so handelt es sich um ein
376 Vgl. Normenausschuss Terminologie (DIN2331 1980), S. 3 377 Normenausschuss Bibliotheks- und Dokumentationswesen (DIN1463 1987), S. 5. Vgl. auch Abschnitt 3.1.2 378 Normenausschuss Bibliotheks- und Dokumentationswesen (DIN1463 1987), S. 5 379 zum Begriff der Meta-Ontologie vgl. Berghoff, Drobnik (Aufbau 1999), S. 4
126
beschreibendes Element, d. h. um eine Rolle oder ein Attribut (vgl. Abb. 4.5).
Charakteristisch für den MOVE-Ansatz ist weiterhin, zwischenbetriebliche Transaktionen in
Leistungs-, Zahlungs- und Informationsflüsse zu gliedern. Daher ist eine entsprechende
Spezialisierung von Interaktionen und Objekten in der MOVE-Meta-Ontologie vorgenommen
worden. Bei Rollen ist zwischen Objekt- und Klientenrollen zu unterscheiden.
Ontol. KlasseEntwurfselement
Klient
Ontol. KlasseEntwurfselement
Interaktion
Ontol. KlasseEntwurfselement
Objekt
Ontol. KlasseEntwurfselement
Kanal
Ontol. KlasseBeschr. Element
Rolle
Ontol. KlasseBeschr. Element
Attribut
Ontol. KlasseEntwurfselement
Ontol. KlasseBeschr. Element
OntologischeKlasse
Ontol. KlasseBeschr. Element
RolleObjektrolle
Ontol. KlasseBeschr. Element
RolleKlientenrolle
D,TD,T
D,T
D,TOntol. Klasse
EntwurfselementInteraktion
LeistungsinteraktionD,T
D,T
Ontol. KlasseEntwurfselement
InteraktionInformationsinteraktion
Ontol. KlasseEntwurfselement
InteraktionZahlungsinteraktion
Ontol. KlasseEntwurfselement
ObjektLeistungsobjekt
Ontol. KlasseEntwurfselement
ObjektInformationsobjekt
Ontol. KlasseEntwurfselement
ObjektZahlungsobjekt
Abb. 4.5 MOVE-Meta-Ontologie
Semantische Regeln
Nach der hier verwendeten Definition einer Ontologie besteht diese aus den wesentlichen
Begriffen einer Domäne sowie den Beziehungen zwischen den Begriffen (vgl. Abschnitt
4.3.1). Neben den im Teilmodell Terminologie festgehaltenen hierarchischen Beziehungen
sollen semantische Regeln in der Ontologie abgelegt werden. Semantische Regeln sind nicht-
hierarchische Beziehungen zwischen Ontologieeinträgen, die ein bestimmtes, generalisiertes
Wissen über die betrachtete Realwelt repräsentieren.380 Die Regeln sollen dazu dienen, die
Kombinationsmöglichkeiten der MOVE-Konstruktionselemente in der Modellierungsphase
betriebswirtschaftlich sinnvoll einzuschränken.
380 Vgl. Czap, Grimm (CASE-Tool 1996), S. 33
127
Ontol. KlasseEntwurfselement
Klient
Ontol. KlasseEntwurfselement
Interaktion
Ontol. KlasseEntwurfselement
Objekt
Ontol. KlasseEntwurfselement
Kanal
Ontol. KlasseBeschr. Element
Rolle
Ontol. KlasseBeschr. Element
Attribut
Ontol. KlasseBeschr. Element
RolleObjektrolle
Ontol. KlasseBeschr. Element
RolleKlientenrolle
D,T
kannausfüllen
sieht vor
cm
cm
cm
cm
kann beteiligtsein an
als Sender
kann beteiligtsein an
als Empfänger
D,T
kannbeteiligtsein an
Abb. 4.6 Metamodell zu semantischen Regeln
Nachfolgende Typen von Regeln sind in der MOVE-Ontologie vorgesehen.
<Klientenrolle> <kann beteiligt sein an> <Interaktion>
Die Akteure zwischenbetrieblicher Transaktionen lassen sich durch verschiedene Rollen
beschreiben. Diese Rollen können von unterschiedlichen Klienten ausgefüllt werden (näheres
dazu im Abschnitt 5.1.2.2). Im Rahmen ihrer Rollen übernehmen Klienten eine bestimmte
Aufgabe oder Funktion in einer Transaktion, die eine Beteiligung als Sender oder Empfänger
an bestimmten Interaktionen vorsieht und an anderen ausschließt. Diese Zusammenhänge
sollen in der Regel <Klientenrolle> <kann beteiligt sein an> <Interaktion> festgehalten
werden. So ist beispielsweise bei einem Streckengeschäft der Auftraggeber als Sender an der
Interaktion beauftragen beteiligt, aber weder als Sender noch Empfänger an der Interaktion
liefern.
<Interaktion> <sieht vor> <Objektrolle>
Für den Gegenstand von bestimmten Interaktionen sind nur jeweils bestimmte Objektrollen
vorgesehen. Die für eine Interaktion zulässigen Objektrollen werden durch die Regel
<Interaktion> <sieht vor> <Objektrolle> festgelegt. Zum Beispiel erfordert die Interaktion
beauftragen ein Objekt mit der Rolle Auftrag, während ein Objekt mit der Rolle Rechnung
dafür nicht zugelassen wird.
<Objekt> <kann ausfüllen> <Objektrolle>
Ähnlich wie Klientenrollen für Klienten bestimmen Objektrollen die Aufgabe oder Funktion
eines Objektes in einer zwischenbetrieblichen Transaktion. Eine bestimmte ontologische
Klasse eines Objektes, d. h. ein Objekttyp, kann verschiedene Objektrollen ausfüllen.
128
Beispielsweise kann ein Informationsobjekt vom Typ Bestellung die Rolle eines
Rahmenauftrags, eines Eilauftrags oder eines Abrufauftrags einnehmen. Andererseits kann
eine bestimmte Objektrolle mehreren Objekttypen zugeordnet werden (z. B. Objektrolle
Rechnung zu den Objekttypen (Einzel-)Rechnung und Sammelrechnung). Dies wird durch die
Regel <Objekt> <kann ausfüllen> <Objektrolle> festgelegt.
4.3.3 Referenzklassen
In der Referenzbibliothek sind für die Entwurfselemente Klient, Interaktion, Objekt und Kanal
Referenzklassen bereitzustellen. Es sind keine konkreten Ausprägungen für Klienten etc. zu
betrachten, sondern jeweils Typen bzw. Klassen, die sich durch Abstraktion aus einer Gruppe
gleichartiger realer Gegenstände oder Sachverhalte ergibt.381 „Der Begriff ‚Referenz‘ stammt
aus dem Lateinischen und bedeutet Empfehlung, Verweis.“382 Referenzklassen stellen somit
im Rahmen von MOVE verbindliche Empfehlungen dar; es handelt sich um standardisierte
Klassen. Sie dienen zur Unterstützung der grafischen Modellierung während der
Formalisierungsphase einer verteilten Modellierung. Mit ihnen soll sichergestellt werden, dass
verschiedene Betriebe Klassen nicht unterschiedlich modellieren, z. B. durch unterschiedliche
Attributzuordnung. Die Referenzklassen sind in vier Klassendiagrammen bereitzustellen: es
ist jeweils ein Klassendiagramm für Klienten, Interaktionen, Objekte und Kanäle zu erstellen.
In den Klassendiagrammen können die Konstruktionsoperatoren Attributzuordnung, Aggre-
gation, Generalisierung und Vererbung Anwendung finden.
Ausgangspunkt zur Bildung von Referenzklassen sind die Klassen der Ontologie. Zwischen
einer ontologischen Entwurfselementklasse und einer Referenzklasse soll eine 1:1-Beziehung
bestehen, so dass im Metamodell kein eigener Entitytyp für Referenzklassen vorgesehen wird.
Basis eines Klassendiagramms für ein bestimmtes Entwurfselement ist damit zunächst die
Generalisierungs-/Spezialisierungshierarchie des jeweiligen Ontologieausschnitts.
Beispielsweise ist die Klientenontologie Ausgangspunkt des Referenzklassendiagramms für
Klienten.
Darüber hinaus sind den Referenzklassen Attribute oder Attributgruppen zuzuordnen, die sie
näher beschreiben. Interpretiert man die Ontologie als hierarchischen Baum, so ergeben sich
Attributgruppen aus den Baumknoten der Attributontologie. Beispiele dafür sind Anschrift,
381 Zum Klassenbegriff und zur Klassenbildung vgl. Fischer (Datenmanagement 1992), S. 80ff. und 94ff. 382 Hars (Referenzdatenmodelle 1994), S. 12
129
Bankverbindung oder Preisangabe. Die Attribute dagegen resultieren aus den Blättern der
Attributontologie. Jede Attributzuordnung ist durch einen Attributtyp zu kennzeichnen. Dabei
handelt es sich um einen betriebswirtschaftlich orientierten Attributtyp,383 der weder abhängig
von einem bestimmten Datentyp384 (wie z. B. Integer, Character) noch abhängig vom
Zeichenfolgetyp385 (wie z. B. numerisch, alphanumerisch) ist. Die im Rahmen von MOVE
vorgesehen Attributtypen werden in Tab. 4-2 aufgeführt.
Aus einem Eintrag der Attributontologie können unter Umständen mehrere Attribute einer
Referenzklasse gebildet werden. So kann beispielsweise das Attribut Land (als Element einer
Anschrift) in ausgeschriebener Form (Attributtyp Bezeichnung) oder in codierter Form
vorliegen (Attributtyp Code).
Sind zwei ontologische Klassen bzw. Referenzklassen über eine Generalisierungs-/
Spezialisierungsbeziehung miteinander verbunden, so werden sämtliche Attribute sowie
Aggregationsbeziehungen der Superklasse an die Subklasse vererbt.386
Als Beschreibungssprache der Klassendiagramme dient die Notation für UML-
Klassendiagramme387 (vgl. Abb. 4.8, Abb. 5.10 und Abb. 5.11).
383 BRENNER/LIESER/ÖSTERLE verwenden hierfür den Begriff ‚betriebswirtschaftlicher Typus‘. Vgl. Brenner, Lieser, Österle (Datenintegration 1988), S. 307 384 Zum Begriff ‚Datentyp‘ vgl. Ferstl, Sinz (Grundlagen 1998), S. 290 385 Zu Zeichenfolgetypen vgl. Abschnitt 2.5 386 Zum Konzept der Vererbung vgl. Coad, Yourdon (Analysis 1991), S. 15; Vetter (Objektmodellierung 1995), S. 67ff.; Ferstl, Sinz (Grundlagen 1998), S. 296f. 387 Vgl. Booch, Rumbaugh, Jacobson (Modeling 1999); Oestereich (Softwareentwicklung 2001), S. 209ff.
130
istzugeordnet
Attributtyp
OntologischeKlasse
Ontol. KlasseEntwurfselement
Klient
Ontol. KlasseEntwurfselement
Interaktion
Ontol. KlasseEntwurfselement
Objekt
Ontol. KlasseEntwurfselement
Kanal
D,T
Ontol. KlasseEntwurfselement
(=Referenzklasse)D,T
istzugeordnet
cm
cm
Ontol. KlasseBeschr. Element
typisiertesAttribut
cm m
Generalisierung/Spezialisierung
Aggregation
cm
cm
D,T
steht inBeziehung
zu
übergeordnet
untergeordnet
Ontol. KlasseBeschr. Element
Rolle
Ontol. KlasseBeschr. Element
Attribut
D,T
istzugeordnet
cm
cm
m
cm
Abb. 4.7 Metamodell der Referenzklassen388
4.3.4 Nachrichtenbausteine
Nachrichtenbausteine - oder kurz Bausteine - stellen im Rahmen von MOVE atomare
Elemente einer Nachricht bzw. eines Informationsobjektes dar, die sich - in semantischer
Hinsicht - nicht weiter zerlegen lassen. In der Referenzbibliothek ist für die Spezifikation von
Informationsobjekten mittels Nachrichtendiagrammen (vgl. Abschnitt 4.4.5) ein Katalog von
standardisierten Bausteinen bereitzustellen. Nachrichtenbausteine bestehen aus einem
semantischen Label sowie aus Datenfeldern. Durch das semantische Label soll die Bedeutung
eines Nachrichtenbausteins möglichst eindeutig beschrieben werden. Die Datenfelder
enthalten zur Laufzeit die eigentlichen Nutzdaten einer Nachricht.
Nachrichtenbausteine werden wie folgt aus den Referenzklassendiagrammen sowie der
Rollen- und Attributontologie abgeleitet:
388 Der Entitytyp „Ontologische Klasse/Beschreibendes Element/Attribut“ repräsentiert sowohl Attributgruppen als Attribute.
131
Jedes Attribut einer Entwurfselementklasse oder einer Attributgruppe dient als Basis für einen
Nachrichtenbaustein (z. B. das Attribut StraßeHausnummer der Attributgruppe Anschrift im
Referenzklassendiagramm für Klienten; vgl. Abb. 4.8). Das semantische Label setzt sich aus
mehreren Teilen zusammen. Zunächst wird die Bezeichnung des Attributs, von dem der
Baustein abgeleitet wird, übernommen und durch die Bezeichnung des Attributtyps ergänzt.
Ein Doppelpunkt dient als Trennzeichen zwischen Attribut- und Attributtypbezeichnung (z. B.
StraßeHausnummer:Bezeichnung). Der Name der Klasse, aus der das Attribut stammt, wird
der Attributbezeichnung vorangestellt. Als Trennzeichen wird hierbei ein Punkt verwendet
(z. B. Anschrift.StraßeHausnummer:Bezeichnung). Ist die bislang betrachtete Klasse eine
Attributgruppe und über eine Aggregationsbeziehung einer anderen Attributgruppe
zugeordnet, so wird deren Bezeichnung wiederum dem bisher gebildeten semantischen Label
vorangestellt usw. Stößt man auf eine Attributgruppe, zu der es Spezialisierungen gibt, so
werden mehrere Label gebildet. Dabei wird jedem Label der Name der (Super-)Attributgruppe
und - getrennt durch einen Bindestrich - der Name der Spezialisierung vorangestellt. Danach
erfolgt wie zuvor beschrieben die Rückverfolgung der Aggregationsbeziehungen. Diese endet,
sobald man an einer Entwurfselementklasse angelangt ist. Je nachdem, um welche
Entwurfselementklasse es sich handelt, sind vier Fälle zu unterscheiden.
Im Falle von Klienten wird die Bezeichnung der Entwurfselementklasse nicht hinzugefügt.
Stattdessen wird das bislang gebildete Label mit den Bezeichnungen aller Klientenrollen
kombiniert (z. B. Leistungsempfänger, Warensender, Auftraggeber, usw. statt Klient), da ein
Klient einer beliebigen Klientenklasse prinzipiell jede Klientenrolle übernehmen kann.389 Auf
diese Weise werden aus einem Attribut mehrere Nachrichtenbausteine abgeleitet. Als
Trennzeichen zwischen den Rollenbezeichnungen und dem bereits gebildeten semantischen
Label dient ebenfalls ein Punkt (z. B. Leistungsempfänger.Anschrift.StraßeHausnummer:
Bezeichnung).
389 Es gibt keine einschränkende semantische Regel in der Ontologie, die nur bestimmte Klientenrollen für bestimmte Kliententypen vorsieht.
132
Anschrift
-StraßeHausnummer : Bezeichnung-Straßencode : Code-Postfachnummer : Nummer-Postleitzahl : Nummer-Ort : Bezeichnung-Ort : Code-Land : Bezeichnung-Land : Code-Gebäudenummer : Nummer-Gebäudebezeichnung : Bezeichnung
Klient
+Name : Bezeichnung-ID_KF : ID-ID_VK : ID-ID_RS : ID-ID_RE : ID-ID_AG : ID
Bankverbindung
-Kreditinstitut : Bezeichnung-Bankleitzahl : Code-Kontonummer : ID
Unternehmen
Kontaktangaben
-Name der Kontaktperson : Bezeichnung-Faxnummer : Nummer-Internet-Adresse : Nummer-Telefonnummer : Nummer-Telexnummer : Nummer-X.400-Adresse : Nummer
Verkaufsabteilung
Abteilung
-Identifizierung : ID-Name : Bezeichnung
Einkaufsabteilung
Buchhaltung
IndustrieunternehmenEinzelhandelsfiliale
Versandstelle
-Ladestelle : Bezeichnung
Grosshandelszentrale
Haushalt
Privater Haushalt
-Telefonnummer : Nummer
Entwurfselementklassen Attributgruppen
Abb. 4.8 Ableiten von Nachrichtenbausteinen aus Referenzklassendiagrammen
Ähnliches gilt im Falle einer Objektklasse. Hierbei wird allerdings das bislang gebildete Label
nur mit den Objektrollen kombiniert, die für die betreffende Objektklasse über die seman-
tische Beziehung <kann ausfüllen> in der Ontologie vorgesehen sind.
Bei Interaktionen und Kanälen wird anders verfahren. Die Entwurfselementklasse, an der man
nach der oben beschriebenen Vorgehensweise angelangt ist, wird als Wurzel des Teilbaumes
mit den von ihr ausgehenden Spezialisierungen interpretiert. Das bisher gebildete Label wird
nun mit sämtlichen Bezeichnungen in den Blättern dieses Teilbaums kombiniert.
Die nach dem beschriebenen Verfahren gebildeten Nachrichtenbausteine sind über ihre
semantischen Label eindeutig bestimmt.
In einer konkreten Ausprägung einer Nachricht können Bausteine aus mehreren Datenfeldern
zusammengesetzt sein. So besteht beispielsweise ein Baustein vom Attributtyp Zeitpunkt aus
den Datenfeldern Jahr, Monat, Tag, Stunde, Minute, Sekunde und Zeitzone. Tab. 4-2 zeigt die
jeweiligen Datenfelder der Attributtypen mit möglichen390 Datentypen.
390 Die hier aufgeführten Datentypen sind als Vorschlag zu verstehen.
133
Attributtyp Datenfeld Datentyp Jahr Integer[4] Monat Integer[2] Tag Integer[2] Stunde Integer[2] Minute Integer[2] Sekunde Integer[2]
Zeitpunkt
Zeitzone String Wert LongInteger Dezimalstellen Integer[1] Vorzeichen Boolean
Betrag
Währung String Wert LongInteger DezimalstellenWert Integer[1] Vorzeichen Boolean Währung String Preisbasis LongInteger DezimalstellenPreisbasis Integer[1]
Preis
WährungPreisbasis String Wert LongInteger Dezimalstellen Integer[1] Vorzeichen Boolean
Menge
Mengeneinheit String Codeliste String Code Codeeintrag String IdAngabe String ID Verwalter String
Bezeichnung String Nummer String Text String Tab. 4-2 Attributtypen und Datenfelder von Nachrichtenbausteinen391
391 In der Literatur finden sich ähnliche Kategorisierungen. So unterscheiden BRENNER/LIESER/ÖSTERLE nach dem betriebswirtschaftlichen Typus in Beschreibung, Betrag, Code, Nummer, Einheit, Menge, Name, Verhältnis und Zeitangabe. Vgl. Brenner, Lieser, Österle (Datenintegration 1988), S. 306. Die Representation Classes der Basic Semantics Register-Initiative umfassen Date, Time, DateAndTime, Amount, Quantity, Code, Name, Identi-fier, Number, Text, Rate, Percent, Value und Indicator. Vgl. ISO (Rules 1998), S. 38. Die Foundation Classes des OO-EDI-Ansatzes sind String, Code List, Code Entry, Identifier List, Identifier, Name, Description, Date, Quantity, Unit of Measure und Sequential Number. Vgl. TMWG (Guide 1998), S. 78
134
Attributtyp
OntologischeKlasse
Ontol. KlasseEntwurfselement
Klient
Ontol. KlasseEntwurfselement
Interaktion
Ontol. KlasseEntwurfselement
Objekt
Ontol. KlasseEntwurfselement
Kanal
Ontol. KlasseBeschr. Element
Attribut
D,T
Ontol. KlasseEntwurfselementD,T
cm
cm
D,P
Ontol. KlasseBeschr. Element
typisiertesAttribut
cm
m
cm m
Datenfeldbesteht aus
m
1
Nachrichten-baustein
istzugeordnet
istzugeordnet
daraus wirdabgeleitet
daraus wirdabgeleitetm
m
1
Ontol. KlasseBeschr. Element
Rollecm daraus wird
abgeleitet
c
1
Generalisierung/Spezialisierung
Aggregation
cm
cm
D,T
steht inBeziehung
zu
übergeordnet
untergeordnet
istzugeordnet
cm
Abb. 4.9 Metamodell zu Nachrichtenbausteinen
4.4 Modellierungssprache
4.4.1 Das AllBuy-Szenario
Das Anwendungsbeispiel der AllBuy GmbH, welches bereits im Abschnitt 3.3.3 zur Analyse
der fachlichen Aufgaben einer Integration vorgestellt worden ist, soll ebenso zur Illustration
der Modellierungssprache von MOVE herangezogen werden. Zunächst erfolgt dazu im
vorliegenden Kapitel eine kleine Erweiterung des Szenarios, während im Kapitel 5 das
AllBuy-Beispiel in aller Ausführlichkeit unter Anwendung von MOVE dargestellt wird.
Zur AllBuy GmbH gehören etwa 200 Einzelhandelsfilialen verschiedener Größen. Die
meisten ihrer Waren bezieht die AllBuy GmbH direkt von den Herstellern nach drei
verschiedenen Transaktionsmustern (vgl. Abschnitt 5.2.1), wobei nachfolgend nur
Filialstreckengeschäfte betrachtet werden sollen.392 Dabei erfolgt einmal jährlich ein
392 Der Begriff ‚Filialstreckengeschäft‘ sowie die weiteren Transaktionsmuster werden in Kapitel 5 näher
135
Rahmenauftrag der AllBuy-Zentrale an die Hersteller, in dem Absatzmengen, Preise sowie
Liefer- und Zahlungsbedingungen festgelegt werden. Die Lieferabrufe erfolgen direkt durch
die AllBuy-Filialen, die wiederum direkt von den Herstellern beliefert werden
(Filialstreckengeschäft). Die AllBuy-Filialen informieren die Zentrale durch
Wareneingangsmeldungen über die tatsächlich gelieferten Warenmengen. Die Regulierung
der Zahlungen übernimmt die AllBuy-Zentrale. Für die Lieferabrufe erfolgen entweder
Einzelrechnungen oder wöchentliche Sammelrechnungen.
Der bislang papierzentrierte Austausch von Informationen soll zukünftig weitgehend
elektronisch erfolgen. Dafür sind die zwischenbetrieblichen Transaktionen in ihren Strukturen
und Inhalten zu entwerfen. Der Einsatz von MOVE wird aus Sicht der AllBuy GmbH
beschrieben.
4.4.2 Transaktionsdiagramm
Das Transaktionsdiagramm gibt einen Überblick über sämtliche an einer zwischenbetrieb-
lichen Transaktion beteiligten Klienten sowie die auftretenden Interaktionen. Gemäß dem
Verständnis einer zwischenbetrieblichen Transaktion wird also eine Leistungsinteraktion mit
allen zugehörigen Zahlungs- und Informationsinteraktionen, die sich auf diese
Leistungsinteraktion beziehen und sie planen, steuern sowie kontrollieren, dargestellt.
Konstruktionselemente eines Transaktionsdiagramms sind Klienten und Interaktionen. Jeder
Klient sowie jede Interaktion sind einer ontologischen Klasse aus der Referenzbibliothek
zugeordnet. Für jeden Klienten sind die Rollen zu bestimmen, die er in der zugrundeliegenden
Transaktion übernimmt. An jeder Interaktion sind genau zwei Klienten beteiligt. Dagegen ist
ein Klient in der Regel an mehreren verschiedenen Interaktionen beteiligt. Interaktionen
werden nach Leistungs-, Zahlungs- und Informationsinteraktionen unterschieden.
Interaktionen sind entweder zwingend oder optional für die Abwicklung einer Transaktion. Es
wird unterstellt, dass zwischenbetriebliche Transaktionen in den Phasen Anbahnung,
Vereinbarung und Durchführung abgewickelt werden (vgl. Abschnitt 2.2). Jede Interaktion
lässt sich demnach einer dieser Phasen zuordnen. Informationsinteraktionen zwischen
Klienten finden nicht per se statt, sondern wirken in unterschiedlicher Weise auf Leistungs-
oder Zahlungsinteraktionen und dienen bestimmten Zwecken. Für jede
erläutert.
136
Informationsinteraktion ist die Angabe des Zwecks sowohl aus Sender-, als auch aus
Empfängersicht obligatorisch (vgl. Abschnitt 2.5).
Interaktion
Transaktion
Klient
ist beteiligtan
istzugeordnet
istzugeordnet
InteraktionLeistungsinter.D,T
InteraktionZahlungsinter.
InteraktionInformationsinter.
cm 1
cm 1
Transaktions-phase
Zweck
istzugeordnetcm
1
istzugeordnetcmD,T Zweck
Sendersicht
ZweckEmpfängersicht
istzugeordnetcm
m (2,2)
mist beteiligtancm wird über-
nommen m
D,T Transaktionprimär
Transaktionsekundär
1
m
m
m
1
1
Ontol. KlasseEntwurfselement
Klient
Ontol. KlasseEntwurfselement
Interaktion
Ontol. KlasseBeschr. Komponente
RolleKlientenrolle
bestehtaus
D,T besteht auszwingend
besteht ausoptional
Abb. 4.10 Metamodell des Transaktionsdiagramms
Als Symbole werden im Transaktionsdiagramm Rechtecke (für Klienten) und Linien mit
Pfeilspitzen (für Interaktionen) verwendet (vgl. Tab. 4-3). Die Linienarten geben die
verschiedenen Interaktionstypen wieder. Gestrichelte Linien repräsentieren
Informationsinteraktionen. Während Zahlungsinteraktionen durch dünn durchgezogene Linien
dargestellt werden, sind für Leistungsinteraktionen fett durchgezogene Linien zu verwenden.
Aus der Beschriftung der Klienten können die zugeordneten Rollen sowie die ontologischen
Klasse entnommen werden. Die Bezeichnung von Interaktionen besteht aus einem
Phasenkürzel, der Szenariobezeichnung sowie - in Klammern - der zugeordneten
ontologischen Klasse.
137
Konstruktionselement Symbol Beschriftung Klient
• Oben, links, kursiv: ontologische Klasse
• Mitte, zentriert: Szenariobezeichnung • Unterhalb der Szenariobezeichnung:
Rollenkürzel Interaktion Leistungsinteraktion:
Zahlungsinteraktion:
Informationsinteraktion:
• Oberhalb oder neben Interaktionspfeil: Phasenkürzel (A|V|D) + Szenariobezeichnung + in Klammern: ontologische Klasse
• Bei optionalen Interaktionen: Unterhalb der Interaktionsbezeichnung: „opt.“
Tab. 4-3 Notation des Transaktionsdiagramms
Abb. 4.11 zeigt das Transaktionsdiagramm für das AllBuy-Szenario. Folgende Informationen
lassen sich aus diesem Diagramm ablesen:
An der Transaktion sind drei Klienten beteiligt: die AllBuy-Zentrale und -Filiale sowie ein
Hersteller. Dabei handelt es sich bei der AllBuy-Zentrale um eine Großhandelszentrale, bei
der AllBuy-Filiale um eine Einzelhandelsfiliale und beim Hersteller um ein
Industrieunternehmen. Außerdem sind aus dem Transaktionsdiagramm die Rollen ersichtlich,
die die beteiligten Klienten im AllBuy-Szenario übernehmen. So übernimmt der Hersteller die
Rolle des Verkäufers mit den sämtlichen Unterrollen Auftragnehmer (AN), Warensender
(WS), Rechnungsteller (RS) und Zahlungsempfänger (ZE). Die Rollen des Käufers
(Auftraggeber (AG), Leistungsempfänger (LE), Rechnungsempfänger (RE),
Zahlungssender(ZS)) sind auf die AllBuy-Zentrale sowie auf die Filialen aufgeteilt.
Neben den Klienten zeigt das Transaktionsdiagramm, dass sieben verschiedene Interaktionen
in dem AllBuy-Szenario auftreten können. In der Vereinbarungsphase erfolgt die Beauf-
tragung des Herstellers durch die AllBuy-Zentrale. Die Waren werden in der
Durchführungsphase direkt von der AllBuy-Filiale beim Hersteller abgerufen (Leistungen
anfordern). Die Durchführungsphase besteht im weiteren aus einer Leistungsinteraktion
(Waren liefern), drei Informationsinteraktionen (Lieferung mitteilen, Wareneingang melden,
Rechnung senden) sowie einer Zahlungsinteraktion (Waren bezahlen). Die jeweils
zugeordneten ontologischen Klassen sind ebenfalls aus dem Transaktionsdiagramm
ersichtlich.
138
AllBuy-Filiale
Einzelhandelsfiliale
LE
AllBuy-Zentrale
Großhandelszentrale
AGREZS
HerstellerANRSLSZE
Industrieunternehmen
D: Waren abrufen (Leistungen anfordern)
V: Auftrag senden (beauftragen)
D: Rechnung senden (Zahlung anfordern)
D: Waren bezahlen (zahlen)
D: Waren liefern (liefern)
D: Lieferung mitteilen (Leistungen avisieren)
D: Wareneingang melden(Leistungen dokumentieren)
Abb. 4.11 Beispiel eines Transaktionsdiagramms
4.4.3 Interaktionsdiagramm
Zu jeder Interaktion im Transaktionsdiagramm ist ein Interaktionsdiagramm zu erstellen.
Dabei können mögliche Alternativen zur Durchführung einer Interaktion dargestellt werden.
Die Alternativen bestehen zum einen in der Wahl unterschiedlicher Kanäle zur Realisierung
der Interaktion. Zum anderen können verschiedene Objekttypen, d. h. Objekte, die
verschiedenen ontologischen Klassen zugeordnet sind, Gegenstand der Interaktion sein.
Ebenso können
alternative Objektrollen in Betracht kommen, wobei die Wahl der Objektrolle durch den
Interaktionstyp (d. h. durch die der Interaktion zugeordneten ontologischen Klasse)
eingeschränkt ist. Interaktionen können in zwei Detaillierungsstufen beschrieben werden.
Dabei ist die zweite Detaillierungsstufe nur für Informationsinteraktionen vorgesehen. Sie ist
auch nur dann auszuführen, wenn der modellierende Betrieb an der Informationsinteraktion
beteiligt ist.
Konstruktionselemente der ersten Detaillierungsstufe eines Interaktionsdiagramms sind
Klienten, Interaktionen, Objekte und Kanäle. Die zu beschreibende Interaktion sowie die
daran beteiligten Klienten mit ihren Rollen werden aus dem Transaktionsdiagramm
übernommen. Im weiteren werden mehrere Durchführungsalternativen dargestellt. Diese
bestehen jeweils aus einer Kombination der Konstruktionselemente Kanal und Objekt.
139
Ersteres repräsentiert den Kanal, über den die Interaktion realisiert wird, und das zweite den
Gegenstand der Interaktion. Diesem ist eine bestimmte Objektrolle bezüglich der
zwischenbetrieblichen Transaktion zuzuweisen. Die Auswahl der Rolle ist durch den
Interaktionstyp über eine entsprechende
semantische Beziehung in der Ontologie (vgl. Abschnitt 4.3.2) eingeschränkt. Wie Klienten
und Interaktionen im Transaktionsdiagramm, so sind auch die Kanäle und Objekte im Inter-
aktionsdiagramm jeweils einer ontologischen Klasse der Referenzbibliothek zugeordnet.
Ist eine Informationsinteraktion darzustellen, an der der modellierende Betrieb beteiligt ist, so
werden als weitere Konstruktionselemente Funktionen, Ereignisse und Anwendungssysteme
im Interaktionsdiagramm verwendet. Mit ihnen werden die Zusammenhänge des
zwischenbetrieblichen Informationsflusses und der beteiligten Anwendungssysteme
dargestellt. Das Informationsobjekt wird einerseits beim Sender durch eine bestimmte
Funktion erzeugt und als Output versendet. Andererseits wird sie beim Empfänger von einer
bestimmten Funktion als Input übernommen und verarbeitet. Die Funktionen werden jeweils
von bestimmten Anwendungssystemen bereitgestellt, die bei den Klienten eingesetzt werden.
Interaktionen sowie die Funktionen beim Empfänger können manuell, zeitgesteuert oder
durch einen Trigger ausgelöst werden (vgl. Abschnitt 3.3.3.3). Trigger einer Interaktion
können Funktionen des Inhousesystems beim Senderklienten sein, während Interaktionen
selbst Trigger für Funktionen des Empfängersystems darstellen können. Die zeitgesteuerte
Auslösung von Interaktionen erfolgt nach Regeln wie beispielsweise „täglich um 7:00 Uhr“
oder „jeden Tag, stündlich zwischen 8:00 Uhr und 18:00 Uhr“.
140
Klient
ObjektLeistungsobjektD,T
ObjektZahlungsobjekt
ObjektInformationsobjekt
Objekt
istzugeordnetcm
m
1
1
istzugeordnetcm 1Ontol. Klasse
EntwurfselementObjekt
Ontol. KlasseBeschr. Element
RolleObjektrolle
Interaktion
InteraktionLeistungsinter.D,T
InteraktionZahlungsinter.
InteraktionInformationsinter.
Ontol. KlasseEntwurfselement
KanalKanalist
zugeordnetcm 1
wirdrealisiert
über
m
cm
Anwendungs-system Funktionbietet
wirdbetrieben
von
cm
cm 1
m (2,2)
cm
erzeugt/verarbeitet m
hat zumGegenstand
EreignismanuellD,T
Ereigniszeitgesteuert
Ereignisgetriggert
c wird über-nommen 1
Ontol. KlasseBeschr. Element
RolleKlientenrolle
ist beteiligtan
m (2,2)
m
Ereignis
wirdausgelöst
durch
wirdausgelöst
durch
erzeugt
erzeugt
1
c
c
cc
c
c
c
istzugeordnet
istzugeordnet
cm 1
cm 1
Ontol. KlasseEntwurfselement
Klient
Ontol. KlasseEntwurfselement
Interaktion
Abb. 4.12 Metamodell des Interaktionsdiagramms
Für Klienten und Interaktionen wird im Interaktionsdiagramm die gleiche Notation
verwendet, wie im Transaktionsdiagramm. Klienten werden also durch Rechtecke dargestellt,
wobei der Senderklient stets links und der Empfängerklient stets rechts im Diagramm
angeordnet wird. Die Rechtecke werden je nach Interaktionstyp durch eine gestrichelte, dünn
durchgezogene oder fett durchgezogene Linie, die die Interaktion repräsentiert, miteinander
verbunden. Die Beschriftung von Klienten und Interaktionen erfolgt ebenso, wie im
Transaktionsdiagramm. Dabei wird die für die jeweilige Interaktion treffende Klientenrolle
fett markiert. Der Kanal wird durch einen Blockpfeil dargestellt und mit der zugeordneten
ontologischen Klasse beschriftet. Ovale, die zentriert über den Kanal angeordnet werden,
symbolisieren die Objekte. Durch ein Piktogramm innerhalb der Objekte können Leistungs-,
Zahlungs- und Informationsobjekte auf einen Blick unterschieden werden (vgl. Tab. 4-4).
Abgerundete Rechtecke repräsentieren die Funktionen der Anwendungssysteme. Diese
wiederum werden durch Rechtecke innerhalb der Klientenrechtecke dargestellt, die jeweils
eine Funktion einrahmen. Ereignisse werden durch Kreise symbolisiert, in denen sich je nach
Ereignisart verschiedenen Piktogramme befinden.
141
Konstruktionselement Symbol Beschriftung Klient • Oben, links, kursiv: ontologische
Klasse • Mitte, zentriert: Szenariobezeichnung • Unterhalb der Szenariobezeichnung:
Rollenkürzel Interaktion Leistungsinteraktion:
Zahlungsinteraktion:
Informationsinteraktion:
• Oberhalb oder neben Interaktionspfeil: Phasenkürzel (A|V|D); Szenariobezeichnung; in Klammern, kursiv: ontologische Klasse
• Bei optionalen Interaktionen: Unterhalb der Interaktionsbezeichnung: „opt.“
Kanal
• Im Pfeil, zentriert: Ontologische Klasse
Objekt Leistungsobjekt:
Zahlungsobjekt:
Informationsobjekt:
• Innerhalb, linksbündig, erste Zeile, kursiv: ontologische Klasse
• Innerhalb, linksbündig, zweite Zeile: Rollenbezeichnung
Funktion
• Mitte, zentriert: Funktionsbezeichnung
Ereignis Manuelle Auslösung:
Zeitgesteuert:
Getriggert:
• Bei manuell und getriggert: <keine Beschriftung>
• Bei zeitgesteuert: rechts, linksbündig: Zeitregel
Anwendungssystem
• Oben, links: Anwendungssystembezeichnung
< Trennlinie zwischen den Alternativen >
• (bei mehreren Alternativen) Mitte, zentriert: „Alternative“ + Nummer der Alternative
Tab. 4-4 Notation des Interaktionsdiagramms
Aus dem Beispiel für ein Interaktionsdiagramm (vgl. Abb. 4.13) geht hervor, dass für die
Interaktion Waren abrufen keine alternativen Ausführungen vorgesehen sind. Grundsätzlich
werden also Informationsobjekte vom Typ Lieferabruf mit der Rolle Lieferabruf über das
142
Internet an die Hersteller versendet, um Waren abzurufen. Da es sich um eine
Informationsinteraktion handelt und die AllBuy GmbH als modellierendes Unternehmen
daran beteiligt ist, wird der Zusammenhang zum innerbetrieblichen Anwendungssystem
beschrieben. Aus dem Diagramm geht hervor, dass in den AllBuy-Filialen das
Warenwirtschaftssystem WaWi eingesetzt wird. Durch dessen Funktion Lieferabruf anlegen
werden die Lieferabrufe erzeugt. Die Übersendung an die Hersteller erfolgt zeitgesteuert
wochentags jeweils um 8:30 Uhr.
IndustrieunternehmenEinzelhandelsfiliale
AllBuy-FilialeLE
HerstellerANRSLSZE
D: Waren abrufen (Leistungen anfordern)
InternetLieferabrufanlegen
LieferabrufLieferabrufWaWi
Mo.-Fr., täglich,8:30 Uhr
Abb. 4.13 Beispiel eines Interaktionsdiagramm
4.4.4 Sequenzdiagramm
Während Transaktions- und Interaktionsdiagramme eine statische Sicht auf
zwischenbetriebliche Transaktionen wiedergeben, werden mit Sequenzdiagrammen
dynamische Aspekte betrachtet. Sie zeigen den zeitlichen Ablauf einer Transaktion. Dabei ist
für jede mögliche Interaktionsfolge - im folgenden auch Szenario genannt - ein eigenes
Sequenzdiagramm zu erstellen. Bei der Beschreibung der Vorgehensweise zum
Sequenzdiagramm wird näher darauf eingegangen, wie die möglichen Interaktionsfolgen
ermittelt werden (vgl. Abschnitt 4.5.3).
Wie im Transaktionsdiagramm, so werden auch im Sequenzdiagramm Klienten und Inter-
aktionen als Konstruktionselemente verwendet. Ebenso wird dargestellt, welcher Klient an
welcher Interaktion beteiligt ist. Allerdings wird eine Notation und Anordnung der
Konstruktionselemente gewählt, die eine dynamische Sicht auf die Transaktion wiedergibt. Zu
jeder Interaktion wird angegeben, mit welcher folgenden Interaktion sie verknüpft ist.
Außerdem lassen sich einfache Verknüpfungsregeln angeben. So kann eine zeitliche
Abhängigkeit
zwischen der Beendigung einer Interaktion und dem Auslösen der folgenden Interaktion
143
dokumentiert werden. Entweder wird eine Mindest- oder Maximaldauer zwischen zwei
Interaktionen angegeben oder eine Interaktion löst direkt eine folgende Interaktion aus. Im
Gegensatz zum Transaktionsdiagramm wird eine Interaktion in Abhängigkeit eines
bestimmten Informationsobjekts dargestellt. Daher sind verschiedene Sequenzdiagramme
vorzusehen, wenn zur Durchführung einer Interaktion mehrere alternative Objekte verwendet
werden können.
Klient
ist beteiligtan
m (2,2)
m
Interaktion
InteraktionLeistungsinter.D,T
InteraktionZahlungsinter.
InteraktionInformationsinter.
Objekt
m
1
istzugeordnetcm 1
Ontol. KlasseBeschr. Element
RolleObjektrolle
cmcm
istzugeordnetcm 1
Ontol. KlasseEntwurfselement
Objekt
hat zumGegenstand
folgt auf
folgt aufdirektD,T
folgt aufzeitlich abhängig
Abb. 4.14 Metamodell der Sequenzdiagramme
Klienten werden im Sequenzdiagramm durch waagerecht verlaufende Linien repräsentiert.
Einerseits gehen von diesen Interaktionen aus und andererseits enden sie daran. Die
Klientenlinien stellen insbesondere Synchronisationslinien für nebenläufige Interaktionen dar.
Interaktionen werden wie zuvor in Transaktions- und Interaktionsdiagramm durch Linien
repräsentiert. Sie verlaufen allerdings im Sequenzdiagramm grundsätzlich senkrecht zwischen
den Klientenlinien. Zu zwei Interaktionen können optional Interaktionsverknüpfungen, sym-
bolisiert durch Kreise, mit einfachen Regeln zur zeitlichen Abhängigkeit (Mindestdauer,
Maximaldauer, direkte Verknüpfung) angelegt werden. Somit gibt ein Sequenzdiagramm von
oben nach unten gelesen den zeitlichen Verlauf einer Interaktionsfolge wieder. Aus ihm sind
die einem Leistungsfluss vorgelagerten, begleitenden sowie nachgelagerten Informationsflüsse
direkt ersichtlich.
144
Konstruktionselement Symbol Beschriftung Klient • Vor der Linie, rechtsbündig: Szenario-
bezeichnung Interaktion Leistungsinteraktion:
Zahlungsinteraktion:
Informationsinteraktion:
• Rechts neben Interaktionspfeil: Szenariobezeichnung; in Klammern: Objekttyp + „/“ + Objektrolle
Interaktionsverknüpfung zeitliche Abhängigkeit:
direkte Verknüpfung:
• Zeitliche Abhängigkeit: zentriert: „min“ + Zeitangabe oder „max“ + Zeitangabe
• direkte Verknüpfung: <keine Beschriftung>
Tab. 4-5 Notation des Sequenzdiagramms
Das in Abb. 4.15 gezeigte Sequenzdiagramm zeigt ein mögliches Ablaufszenario im AllBuy-
Fallbeispiel. Hierbei erfolgt zunächst die Beauftragung durch einen Rahmenauftrag und der
Abruf der Waren durch einen entsprechenden Lieferabruf. Die Waren werden vom Hersteller
spätestens 24 Stunden nach dem Abruf durch die Vorabsendung eines Lieferscheins avisiert.
Das Lieferavis soll mindestens sechs Stunden vor der Lieferung vorliegen. Parallel zur Lie-
ferung wird vom Hersteller eine Rechnung versendet. Nach Ankunft der Waren bei der
AllBuy-Filiale erfolgt innerhalb einer Stunde eine Wareneingangsmeldung zur AllBuy-
Zentrale. Erst wenn diese vorliegt, wird die Rechnung zur Lieferung - spätestens nach 30
Tagen - bezahlt. Der zeitliche Ablauf ist aus dem Sequenzdiagramm ablesbar.
145
Hersteller
AllBuy-Filiale
Waren liefern(Konsumgüter/Leistung)
Rechnung senden(Einzelrechnung/Rechnung)
AllBuy-Zentrale
Wareneingang melden(Warenlieferschein/Wareneingangsmeldung)
Hersteller
Waren bezahlen(Scheck/Zahlung)
begleitend
nachgelagert
AllBuy-Zentrale
Hersteller
AllBuy-Filiale
Auftrag senden(Bestellung/Rahmenauftrag)
Lieferung mitteilen(Warenlieferschein/Lieferavis)
AllBuy-Filiale
Hersteller
Waren abrufen(Lieferabruf/Lieferabruf)
vorgelagert
max24h
min6h
max1h
max30T.
Abb. 4.15 Beispiel eines Sequenzdiagramms
4.4.5 Nachrichtendiagramm
Inhalte und Strukturen von Informationsobjekten werden in Nachrichtendiagrammen
beschrieben. Für jedes Informationsobjekt ist ein eigenes Nachrichtendiagramm vorzusehen.
Konstruktionselemente eines solchen Diagramms sind Nachrichtenelemente und
Nachrichtencontainer. Die Struktur eines Informationsobjektes wird durch hierarchisch
geschachtelte Nachrichtencontainer repräsentiert. Nachrichtencontainer enthalten auf jeder
Ebene mehrere Nachrichtenelemente. Letztere stellen atomare Elemente eines
Geschäftsdokumentes dar, die sich in semantischer Hinsicht nicht weiter zerlegen lassen.393
Jedes Nachrichtenelement ist genau einem Nachrichtenbaustein aus der Referenzbibliothek
zuzuordnen. Für die Auswahl des Nachrichtenbausteins sind bestimmte Regeln zu beachten,
die in Abschnitt 4.5.3 erläutert werden. Für jedes Nachrichtenelement wird festgelegt, ob es
sich um ein zwingend notwendiges („Muss-Element“) oder um ein optionales Element
(„Kann-Element“) handelt. Außerdem ist festzulegen, ob das Nachrichtenelement als
Identifizierung, d. h. als Schlüssel für den Nachrichtencontainer, in dem es enthalten ist,
fungiert oder nicht.
393 Vgl. Abschnitt 4.3.4
146
wirdrepräsen-tiert durch
cm Nachrichten-container
enthält
Nachrichten-baustein
1
c
1
cm
m
D,T
Objekt
ObjektLeistungsobjekt
ObjektZahlungsobjekt
ObjektInformationsobjekt enthält
D,T enthältzwingend
enthältoptional
ist abgeleitetaus
Nachrichten-element
c
1
D,T ist Schlüssel
ist Nicht-Schlüssel
Abb. 4.16 Metamodell des Nachrichtendiagramms
Die Struktur einer Nachricht wird im Nachrichtendiagramm durch eine hierarchische
Baumstruktur abgebildet. Die Knoten in dem Baum stellen Nachrichtencontainer dar,
während Nachrichtenelemente die Blätter des Baumes sind. Die Bezeichnung der
Nachrichtencontainer werden durch Rechtecke eingerahmt. Nachrichtenelemente werden
durch einen Punkt und eine Astverbindung zu einem Knoten repräsentiert. Die Darstellungsart
des Punktes verdeutlicht die Art des Nachrichtenelementes. Ein ausgefüllter Punkt stellt ein
Muss-Element dar, während ein nicht ausgefüllter Punkt ein Kann-Element bedeutet.
Schlüsselelemente sind grundsätzlich Muss-Elemente und werden von einem umrandeten
gefüllten Punkt repräsentiert.
Konstruktionselement Symbol Beschriftung Nachrichtencontainer • Innerhalb, linksbündig: Bezeichnung
des Nachrichtencontainers Nachrichtenelement Schlüssel:
Muss-Element:
Kann-Element:
• Rechts neben dem Symbol: Bezeichnung des Nachrichtenelements
Tab. 4-6 Notation des Nachrichtendiagramms
Abb. 4.17 zeigt beispielhaft das Nachrichtendiagramm für eine Einzelrechnung im AllBuy-
Szenario. Dieser gliedert sich in einen Kopfteil (Nachrichtencontainer Rechnung) und einen
Positionsteil (Nachrichtencontainer Rechnungsposition). Der Kopfteil enthält acht Muss-
Elemente, wobei der Nachrichtenbaustein Rechnung.ID_RS:ID als Schlüssel fungiert.
147
Schlüssel der Rechnungspositionen ist der Nachrichtenbaustein
Rechnungsposition.Positionsnummer:Nummer. Daneben gibt es im Positionsteil drei weitere
Muss-Elemente und ein Kann-Element.
RechnungRechnung.Erstellt:ZeitpunktRechnung.ID_RS:IDRechnungsempfänger.Name:BezeichnungRechnungssteller.Name:BezeichnungLeistungsempfänger.Name:BezeichnungRechnungsempfänger.ID_RS:IDRechnungssteller.ID_RE:IDLeistungsempfänger.ID_AG:IDLieferavis.Erstellt:ZeitpunktLieferavis.ID_WS:IDRechnung.Summenangaben.GesamtOhneMWSt:BetragRechnung.Summenangaben.GesamtMitMWSt:BetragRechnung.Summenangaben.MWStVoll:BetragRechnung.Summenangaben.MWStSatzVoll:Rate
RechnungspositionRechnungsposition.Positionsnummer:NummerLieferung.Artikel.ID_VK:IDLieferung.Artikel.Name:BezeichnungLieferung.Artikel.MengeGeliefert:MengeLieferung.Artikel.Preisangaben.OhneMWSt:PreisRechnungsposition.PositionsbetragOhneMWSt:Betrag
Abb. 4.17 Beispiel eines Nachrichtendiagramms
4.4.6 Regeldiagramm
Nachrichtenelementen eines Nachrichtendiagramms können Regeldiagramme hinterlegt
werden. Sie dienen zur Spezifikation von Prüf- bzw. Integritätsregeln, die die Integrität von
Nachrichten sicherstellen sollen. Allerdings ist dies aus Sicht eines modellierenden
Unternehmens nur für eingehende Informationsobjekte erforderlich. Ausgehende
Informationsobjekte werden schließlich durch die eigenen Anwendungssysteme erzeugt und
brauchen daher nicht auf Integrität überprüft zu werden.
Bevor Regeln für Nachrichtenelemente modelliert werden können, sind Transaktions-,
Interaktions-, Sequenz- sowie Nachrichtendiagramme für eine zwischenbetriebliche
Transaktion vollständig zu erstellen.
Einem Nachrichtenelement können mehrere Regeln zugeordnet werden. Es lassen sich Inte-
gritätsregeln auf Element-, Nachrichten-, Transaktions- oder Geschäftsbeziehungsebene
unterscheiden (vgl. Abschnitt 3.3.3.2). Auf Elementebene wird isoliert der Datenwert eines
Nachrichtenelementes auf Zulässigkeit überprüft. Auf Nachrichtenebene wird die Integrität
und Konsistenz eines Nachrichtenelementes innerhalb einer Nachricht zu anderen
Nachrichtenelementen überprüft. Durch Prüfen der Transaktionsintegrität
148
(Transaktionsebene) wird sichergestellt, dass die Datenwerte der logisch zusammengehörigen
Nachrichten einer Transaktion konsistent zueinander sind. Auf der Ebene einer
Geschäftsbeziehung werden außergewöhnliche Nachrichteninhalte (z. B. eine für den
betreffenden Partner ungewöhnlich hohe Bestellmenge) oder Umstände, die gar nicht die
eigentliche Nachricht oder Transaktion betreffen (z. B. Liquiditätsschwierigkeiten eines
Partners) geprüft. Von der Zuordnungsebene hängt ab, wie viele Datenwerte in die
Überprüfung einbezogen werden können und in welchem Kontext die Überprüfung stattfindet.
Konstruktionselemente eines Regeldiagramms sind Startelement, Aktionen und drei
verschiedene Arten von Kontrollflusskanten. Eine Regel besteht grundsätzlich aus einem
Startelement sowie einer Folge von Aktionen, die in beliebiger Reihenfolge über
Kontrollflusskanten miteinander verknüpft werden können. Ausgangspunkt einer Regel ist
immer das Startelement. Besondere Beachtung finden Prüfaktionen, da sie über „True“- und
„False“-Kontrollflusskanten mit nachfolgenden Aktionen verknüpft werden. Alle anderen
Aktionen werden über „Sequenz“-Kontrollflusskanten miteinander verknüpft.
Regeln lassen sich in einzelne Aktionen zerlegen. Dabei können wiederkehrende Aktionen
identifiziert werden, die immer wieder in Regeln vorkommen. Sie führen zu Aktionstypen, die
im folgenden kurz erläutert werden (vgl. Tab. 4-7).
Aktionstyp Ausprägungen Prüfen Prüfen auf
Mengenzugehörigkeit Prüfen auf Existenz
Abgleichen zweier Werte
Zusammengesetzte Prüfungen
Ermitteln Aus ankommender Nachricht
Aus bereits ausgetauschten Nachrichten
Aus Partnerprofil
Aus Inhousesystem
Eigene-IDs zu Fremd-IDs
Zuordnen Nachrichten zueinander Positionen zu Nachrichten
Positionen zueinander
Zuweisen Wert übernehmen Ersetzen vorhandener Werte
Ergänzen fehlender Werte
Status melden und beenden
Fehler melden Warnen Erfolg melden
Tab. 4-7 Aktionstypen
149
Aktionstyp Prüfen394
Prüfbedingungen können nach elementaren und zusammengesetzten Bedingungen
unterschieden werden. Elementare Bedingungen müssen atomar, d. h. sie dürfen nicht in
weitere Teilbedingungen unterteilbar sein. Zusammengesetzte Prüfbedingungen entstehen
durch die Anwendung der booleschen Operatoren UND und ODER auf andere (elementare
oder zusammengesetzte) Bedingungen. Zu den atomaren Prüfbedingungen zählen die Abfrage
auf eine Mengenzugehörigkeit (z. B. „Auftragsposition.Positionsnummer:Nummer IN
{1,2,5,9}“), die Existenzüberprüfung referenzierter Datenwerte (z. B. existiert Kunde zu
Auftrag) und Prädikate. Letztere enthalten Vergleiche von Werten von Nachrichtenelementen
mit anderen Nachrichtenelementen oder (externen) Konstanten.
Aktionstyp Ermitteln
Zur Prüfung eines Nachrichtenelementes werden häufig andere Werte herangezogen, die
zuvor erst ermittelt werden müssen. Dabei kann es sich um Werte von anderen
Nachrichtenelementen der gerade zu prüfenden Nachricht handeln oder um Werte von
Nachrichtenelementen bereits ausgetauschter Nachrichten derselben Transaktion. Unter
Umständen werden auch externe Werte aus dem Partnerprofil für den zwischenbetrieblichen
Informationsaustausch oder Daten aus dem Inhousesystem herangezogen. Ein Spezialfall stellt
die Zuordnung von Eigen- zu Fremd-IDs dar. Im Normalfall verwenden die Geschäftspartner
unterschiedliche Nummerierungssysteme und Codierungen für Artikelnummern,
Zahlungsbedingungen, Partner etc. (vgl. Abschnitt 2.5). Daher ist es notwendig, die vom
Partner verwendete ID in das eigene System zu übersetzen. Voraussetzung dafür ist die
Verwaltung der entsprechenden Fremd-IDs.
Aktionstyp Zuordnen
Erfolgt eine nachrichtenübergreifende Prüfung eines Nachrichtenelementes, so müssen die
Nachrichteninstanzen einer Transaktion einander zugeordnet werden (z. B. Bestellung zum
Lieferschein). Im einfachen Fall besteht zwischen zwei Nachrichten eine 1:1-Beziehung. In
der Regel ist das allerdings nicht der Fall, so dass die Position einer Nachricht anderen
Nachrichten (z. B. Bestellposition zu Rahmenauftrag) oder wiederum den Positionen anderer
Nachrichten (z. B. Lieferscheinposition zu Bestellposition) zugeordnet werden müssen.
Aktionstyp Zuweisen
394 In Anlehnung an die Klassifikation von Bedingungstypen in Herbst, Knolmayer (Ansätze 1995), S. 152
150
Im Rahmen von Integritätsregeln sollten vorhandene fehlerhafte Werte, wenn möglich, durch
korrekte Werte ersetzt werden. Fehlende Werte von Nachrichtenelementen können
möglicherweise ergänzt werden.
Aktionstyp Status melden
Integritätsprüfungen werden durch Statusmeldungen beendet. Mögliche Statusmeldungen sind
Erfolg, Warnung oder Fehler. Nicht erfolgreiche Berechnungen oder Prüfungen führen zu
Fehlermeldungen. Im Falle von Warnungen wird allerdings die Verarbeitung der Nachricht
fortgesetzt. Im anderen Falle erfolgt ein Abbruch der Weiterverarbeitung.
Aktion ist verknüpftmit
ist verknüpft mitTRUE
ist verknüpft mitFALSE
ist verknüpftmit
Nachrichten-element Regelcm 1
besteht aus
m
1
D,TD,T
AktionErmitteln
AktionZuordnen
AktionZuweisen
AktionStatus melden
wird geprüft
D,Twird geprüftauf Element-
ebene
wird geprüftauf Nach-
richtenebene
wird geprüftauf Trans-
aktionsebene
besteht aus Startelement1 1
AktionPrüfen
ist verknüpft mitSequenz
c
1
cmcm
wird geprüftauf Geschäfts-
bezeihungsebene
Abb. 4.18 Metamodell zum Regeldiagramm
Im Regeldiagramm werden drei verschiedene Symbole, nämlich Rauten, abgerundete
Rechtecke und ein ausgefüllter Kreis mit Pfeil, verwendet, die über Verbindungskanten
miteinander verknüpft werden. Rauten stellen Prüfaktionen dar, während andere Aktionen
durch die abgerundeten Rechtecke repräsentiert werden. Der Kreis mit Pfeil stellt das
Startelement einer Regel dar. Die aus einer Raute bzw. Prüfaktion führenden
Verbindungskanten erhalten die Beschriftung „TRUE“ und „FALSE“, da das weitere
Vorgehen von dem Prüfergebnis abhängt. Dabei sollte die „TRUE“-Kante stets links von der
„FALSE“-Kante verlaufen. Verbindungskanten, die von anderen Aktionen ausgehen, erhalten
ebenso wie das Startelement keine Beschriftung. Die Elemente im Diagramm sind so
anzuordnen, dass der Kontrollfluss von oben nach unten lesbar ist.
Konstruktionselement Symbol Beschriftung
151
Startelement
• <keine Beschriftung>
Aktion vom Aktionstyp Prüfen
• Innerhalb: Formulierung der Prüfbedingung
Aktion • Innerhalb: Bezeichnung der Aktion
Verbindungskante Sequenz
• <keine Beschriftung>
Verbindungskante Alternative „TRUE“
TRUE
• „TRUE“
Verbindungskante Alternative „FALSE“
FALSE
• „FALSE“
Tab. 4-8 Notation des Regeldiagramms
Abb. 4.19 zeigt beispielhaft das Regeldiagramm zur Überprüfung des Nachrichtenelementes Rechnung.Summenangaben.MWStVoll:Betrag. Die Überprüfung des Mehrwertsteuerbetrages erfolgt dabei auf Elementebene. Zunächst wird geprüft, ob überhaupt ein Wert vorhanden ist. Falls nicht, so wird der Mehrwertsteuerbetrag aus der Angabe zum Mehrwertsteuersatz und dem Nettogesamtbetrag der Rechnung errechnet und dem Nachrichtenelement Rechnung.Summenangaben._ MWStVoll:Betrag als Wert zugewiesen. Falls in der eingehenden Rechnung bereits ein Mehrwertsteuerbetrag angegeben wird, ist zu überprüfen, ob dieser korrekt ist. Dazu wird wiederum der Mehrwertsteuerbetrag aus der Angabe zum Mehrwertsteuersatz und dem Nettogesamtbetrag der Rechnung errechnet und mit dem vorgegebenen Wert verglichen. Sind beide Werte gleich, so ist der Betrag korrekt, andernfalls liegt ein fehlerhafter Betrag vor.
PrüfenRechnung.Summenangaben._
MWStVoll:Betrag <> NULL FALSETRUE
Ermittelnx := Rechnung.Summenangaben.GesamtOhneMWSt:Betrag
* Rechnung.Summenangaben.MWStSatzVoll:Rate
Prüfenx = Rechnung.Summenangaben._
MWStVoll:Betrag ?
Status meldenAbbruch: Betrag fehlerhaft !
Status meldenErfolg: Betrag korrekt !
FALSETRUE
Ermittelnx := Rechnung.Summenangaben.GesamtOhneMWSt:Betrag
* Rechnung.Summenangaben.MWStSatzVoll:Rate
ZuweisenRechnung.Summenangaben.MWStVoll:Betrag:= x
Status meldenErfolg: Fehlenden Betrag ergänzt !
Abb. 4.19 Beispiel eines Regeldiagramms
152
4.5 Vorgehensweise
4.5.1 Makrovorgehen
MOVE sieht aus einer Makrosicht eine Top-Down-Vorgehensweise in sieben Schritten vor
(vgl. Abb. 4.20). Der Detaillierungsgrad der Modellierungsergebnisse nimmt dabei von
Schritt zu Schritt zu.
In einem ersten Schritt sind die verschiedenen Transaktionen zu bestimmten, die modelliert
werden sollen. Für jede zu modellierende Transaktion ist in einem zweiten Schritt ein
Transaktionsdiagramm zu erstellen. Es zeigt aus statischer Sicht sämtliche beteiligten
Klienten sowie die auftretenden Interaktionen.
Jede Interaktion ist im dritten Schritt durch ein Interaktionsdiagramm im Detail zu
beschreiben. Dazu gehört zum einen der Gegenstand der Interaktion, das Objekt, sowie der
Kanal, über den die Interaktion realisiert wird. Zum anderen werden auch die betroffenen
Anwendungssysteme der Klienten beschrieben. Diese Beschreibung umfasst die sendenden
und empfangenden Funktionen dieser Anwendungssysteme. In einem Interaktionsdiagramm
können unterschiedliche Ausführungsalternativen dargestellt werden.
Im vierten Schritt geht es darum, die alternativ möglichen Interaktionsfolgen zu ermitteln. Für
jede mögliche Interaktionsfolge ist im fünften Schritt ein Sequenzdiagramm vorzusehen. In
ihm wird die zeitliche Abfolge einer Transaktion dargestellt.
Mit den bisher erstellten Diagrammen wurden die zwischenbetrieblichen Leistungs-,
Zahlungs- und Informationsflüsse einer Transaktion als Modell konstruiert. Sie bilden die
Grundlage für die Bestimmung der erforderlichen Nachrichtenstrukturen. Diese können im
sechsten Schritt für jedes Informationsobjekt durch ein Nachrichtendiagramm spezifiziert
werden. Jedem Nachrichtenelement in einem Nachrichtendiagramm können in einem
abschließenden siebten Schritt eine oder mehrere Integritätsregeln hinterlegt werden.
153
Regeldiagrammeerstellen
Struktursicht Verhaltenssicht
Sequenz-diagramme
erstellen
1. Transaktionenbestimmen
Transaktionsdiagrammeerstellen2.
BestimmeInteraktionsfolgen4.
5.
7.
3. Interaktionsdiagrammeerstellen
6. Nachrichtendiagrammeerstellen
Abb. 4.20 Makrovorgehen der Modellierungsmethode
4.5.2 Mikrovorgehen
Auf allen Detaillierungsebenen wird prinzipiell das gleiche Vorgehen angewendet (vgl. Abb.
4.21). Zunächst wird der zu modellierende Gegenstand des betrachteten Realitätsausschnitts
in eine Kategorie des Entwurfsrahmens eingeordnet. Nun gilt es, einen sprachlichen Ausdruck
für dieses Konstruktionselement zu finden. Dazu ist aus der Ontologie ein passender Eintrag
herauszusuchen. Die Bezeichnung und Definition eines Ontologieeintrags sowie die
Beziehungen zu anderen Ontologieeinträgen dienen dabei als Entscheidungshilfen für den
Modellierer bei der Suche nach einem geeigneten Ausdruck. Da die Ontologie eng mit den
Referenzklassen verknüpft ist (vgl. Abschnitte 4.3.2 und 4.3.3), ist durch die Auswahl des
Ontologieeintrags die für die grafische Modellierung erforderliche Referenzklasse bzw. der
erforderliche Nachrichtenbaustein festgelegt. In dieser Weise wird das Modell der jeweiligen
Detaillierungsebene sukzessive durch weitere Konstruktionselemente ergänzt.
Referenzklasse bzw.Nachrichtenbaustein der
Referenzbibliothek entnehmen
Eintrag aus derOntologie wählen
Betrachteten Gegenstand nachEntwurfsrahmen kategorisieren
Näc
hste
s M
odel
lieru
ngse
lem
ent
NatürlichsprachlicheModellkonstruktion
FormalsprachlicheModellkonstruktion
MentaleModellkonstruktion
Abb. 4.21 Mikrovorgehen der Modellierungsmethode
154
Das beschriebene Vorgehen soll anhand der Modellierung von AllBuy-Filialen bei der
Erstellung des Transaktionsdiagramms zum AllBuy-Szenario erläutert werden. Wie in der
Realwelt zu beobachten ist, sind die Filialen der AllBuy GmbH an den zwischenbetrieblichen
Transaktionen mit den Herstellern beteiligt. Sie sind daher in das Transaktionsdiagramm
aufzunehmen. Dabei sind sie zunächst in eine Kategorie des Entwurfrahmens einzuordnen
(vgl. Abb. 4.22, Schritt 1). Offensichtlich handelt es sich bei den Filialen um Klienten. Nun ist
ein passender Eintrag aus der Ontologie auszuwählen. Ausgehend von der Klasse „Klient“
sucht man in der Ontologie395 soweit nach Spezialisierungen, bis ein treffender Eintrag
gefunden wurde (vgl. Abb. 4.22, Schritt 2). In dem Beispiel wird der Eintrag
„Einzelhandelsfiliale“ identifiziert und ausgewählt. Dieser entspricht der Referenzklasse
„Einzelhandelsfiliale“, die für die grafische Modellierung verwendet werden kann (vgl. Abb.
4.22, Schritt 3).
nachEntwurfsrahmenkategorisieren
1. Eintragaus Ontologie
wählen
2.Referenzklasse
bzw. Nachrichten-baustein entnehmen
3.
AllBuy-Zentrale
D: Leistungenanfordern
D: Leistungen avisieren
D: liefern
V: beauftragen
D: Zahlung anfordern
D: Leistungen dokumentieren AllBuy-Filiale
D: zahlen
Hersteller
Klient EinzelhandelsfilialeName:BezeichnungID_VK:IDAnschrift.Postleitzahl:NummerAnschrift.Ort:BezeichnungKontaktangaben.Telefon:NummerBankverbindung.Bankleitzahl:CodeBankverbindung.Kontonummer:ID...
Einzelhandelsfiliale
Abb. 4.22 Mikrovorgehen am Beispiel des AllBuy-Transaktionsdiagramms
4.5.3 Modellierungsschritte
Vorgehensweise zum Transaktionsdiagramm
Transaktionsdiagrammen können primäre oder sekundäre Leistungsinteraktionen zugrunde
liegen. 396 Zunächst sollen die primären Leistungsflüsse eines Unternehmens analysiert
werden. Für Leistungsinteraktionen, die nach demselben Muster ablaufen, ist ein
Transaktionsdiagramm zu erstellen. Ausgangspunkt des Diagramms ist die
395 Einen Vorschlag für eine Klientenontologie zeigt Abb. 5.1 in Abschnitt 5.1.2.1 396 Vgl. Definition einer zwischenbetrieblichen Transaktion in Abschnitt 2.2: „Leistungsinteraktion mit allen zugehörigen Zahlungs- und Informationsinteraktionen“.
155
Leistungsinteraktion selbst. Danach können die beiden beteiligten Klienten mit ihren Rollen
als Leistungssender und Leistungsempfänger ermittelt werden. Im dritten Schritt sind zu jeder
Leistungsinteraktion ein oder mehrere Zahlungsinteraktionen zu ermitteln. Gegebenenfalls
werden dadurch weitere Klienten, die nicht am Leistungsfluss, wohl aber am Zahlungsfluss
beteiligt sind, identifiziert. Im weiteren sind die Rollen im Zahlungsfluss, d. h.
Zahlungssender und -empfänger sowie gegebenenfalls Bank des Käufers bzw. Verkäufers zu
bestimmen. Anschließend sind in einem vierten Schritt zu jeder Leistungsinteraktion die
vorgelagerten, begleitenden sowie nachgelagerten Informationsinteraktionen zu
identifizieren.397 Zu den Zahlungsinteraktionen lassen sich zahlungsbegleitende
Informationsinteraktionen ermitteln. Als Analysehilfe zur Identifizierung der
Informationsinteraktionen dient dabei das Phasenschema für zwischenbetriebliche
Transaktionen. Für jeden identifizierten Informationsfluss ist neben der Phase der Zweck aus
Sendersicht zu bestimmen. Möglicherweise ist das Transaktionsdiagramm um weitere
Klienten zu ergänzen, die lediglich am Informationsfluss, nicht aber am Leistungs- oder
Zahlungsfluss teilnehmen. Zur Vervollständigung sind die Rollen zu bestimmen, die die am
Informationsfluss beteiligten Klienten einnehmen.
Nachdem Transaktionsdiagramme für die primären Transaktionen erstellt worden sind,
können aus ihnen jeweils sekundäre Transaktionen abgeleitet werden. Zur Abwicklung der
primären Transaktionen werden von den beteiligten Klienten Leistungen im sekundären
Wertschöpfungsfluss (z. B. Transportleistungen, Versicherungsleistungen,
Finanzdienstleistungen, etc. ) nachgefragt. Nach den bereits beschriebenen Schritten sind
Transaktionsdiagramme für die sekundären Transaktionen zu erstellen.
1. Identifizieren von Transaktionsmustern im primären Leistungsfluss
Für jedes Transaktionsmuster:
2. Analyse des Leistungsflusses:
a) Identifizieren der Leistungsinteraktion
b) Identifizieren der beteiligten Klienten
c) Bestimmen der Klientenrollen im Leistungsfluss
397 Damit verbunden ist die Auffassung, dass der Informationsfluss den Leistungsfluss plant, steuert und kontrolliert (vgl. BFK u. a. (Modellierung 1995), S. 9).
156
3. Analyse des Zahlungsflusses:
a) Identifizieren der Zahlungsinteraktionen
b) Identifizieren der beteiligten Klienten
c) Bestimmen der Klientenrollen im Zahlungsfluss
4. Analyse der Informationsflüsse:
a) Identifizieren der Informationsinteraktionen
b) Bestimmen der Phase und des Zwecks einer Informationsinteraktion
c) Identifizieren der beteiligten Klienten
d) Bestimmen der Klientenrollen im Informationsfluss
5. Ableiten sekundärer Transaktionen, danach ggf. weiter bei 2.
Tab. 4-9 Vorgehen zum Transaktionsdiagramm
Vorgehensweise zum Interaktionsdiagramm
Zu jeder Interaktion in einem Transaktionsdiagramm ist ein Interaktionsdiagramm zu
erstellen. Dazu werden zunächst die an der Interaktion beteiligten Klienten sowie die
Interaktion selbst aus dem Transaktionsdiagramm übernommen. Danach sind die alternativen
Ausführungen der Interaktion darzustellen. Eine Ausführung besteht immer aus einer
Kombination eines Objekts mit zugeordneter ontologischer Klasse (Objekttyp) und
Objektrolle sowie einem Kanal. Im Falle von Informationsinteraktionen gehört zur
Spezifikation einer Interaktionsausführung zusätzlich die Angabe eines sendenden bzw.
empfangenden Anwendungssystems, welches eine Funktion zum Erzeugen bzw. Verarbeiten
des Informationsobjektes bereitstellt. Zusätzlich ist die Art des Auslöse-Ereignisses (manuell,
zeitgesteuert, getriggert) für die Interaktion oder die Empfangsfunktion anzugeben.
Für jede Interaktion in einem Transaktionsdiagramm:
1. Übernehmen der Klienten und der Interaktion aus dem Transaktionsdiagramm
2. Alternative Ausführungen der darzustellenden Interaktion analysieren, d. h. jeweils:
a) Identifizieren des Objektes
b) Bestimmen der Objektrolle
c) Bestimmen des Kanals
157
Im Fall von Informationsinteraktionen:
d) Bestimmen des sendenden bzw. empfangenden Anwendungssystems
e) Bestimmen der erzeugenden bzw. verarbeitenden Funktion des Anwendungssystems
f) Bestimmen des Auslöse-Ereignisses der Interaktion oder der Empfangsfunktion
Tab. 4-10 Vorgehen zum Interaktionsdiagramm
Vorgehensweise zum Sequenzdiagramm
In einem Sequenzdiagramm wird eine mögliche Ablauffolge von Interaktionen zur
Durchführung einer Transaktion dargestellt. Durch die alternative Gestaltung von
Interaktionen kann es zu einer Transaktion durchaus mehrere Sequenzdiagramme geben.
Bevor diese erstellt werden können, sind die möglichen Kombinationen verschiedener
Interaktionsausführungen festzulegen. Dafür wird eine spezielle Konfigurationstabelle398
vorgeschlagen (vgl. Tab. 4-11).
Gültige Szenarien Interaktion Objekt (Typ/ Rolle) 1 2 3
Bestellung/ Rahmenauftrag X X - Auftrag senden Bestellung/ Lieferplanvereinbarung - - X
Waren abrufen Lieferabruf/ Lieferabruf X X - Einzelrechnung/ Rechnung - X X Rechnung senden Sammelrechnung/ Rechnung X - -
Tab. 4-11 Konfigurationstabelle zum AllBuy-Beispiel399
In die erste Spalte dieser Tabelle werden sämtliche Interaktionen aufgeführt, zu denen es
alternative oder optionale Durchführungsvarianten gibt. In der zweiten Spalte werden diese
Varianten eingetragen, die sich anhand der verwendeten Objekte unterscheiden lassen. Zu
jedem Objekt ist dessen Typ, d. h. die zugeordnete ontologische Klasse, und die Objektrolle
anzugeben. In den weiteren Spalten werden die gültigen Kombinationen eingetragen. Durch
ein Kreuz wird in diesen Spalten angegeben, ob die betreffende Variante in einem Szenario
vorkommt. Auf diese Weise werden die verschiedenen möglichen Szenarien ermittelt.
Anschließend sind die Interaktionen eines Szenarios, welches im Sequenzdiagramm
dargestellt werden soll, in zeitlicher Hinsicht zu ordnen. Nacheinander ist nun jede Interaktion
in das Sequenzdiagramm aufzunehmen. Dabei sind zunächst jeweils die Sender- und
Empfängerklienten zu ermitteln und als Synchronisationslinien, zwischen denen die
398 In Anlehnung an Schlitt (Variantenmanagement 1997), S. 48
158
Interaktionen verlaufen, in das Diagramm zu übernehmen. Sodann ist die Rolle des Objektes
zu ermitteln. Bevor die Interaktion in das Sequenzdiagramm eingezeichnet werden kann, ist
zu entscheiden, ob sie parallel oder sequentiell zu bereits vorhergehenden Interaktionen
ausgeführt wird. Während die Interaktionen senkrecht verlaufen, sind die Klientenlinien
waagerecht im Sequenzdiagramm anzuordnen. Auf diese Weise entsteht eine
Interaktionsfolge, die von oben nach unten gelesen den zeitlichen Verlauf einer Transaktion
wiedergibt. Gegebenenfalls ist eine Interaktionsverknüpfung mit einer zeitlichen Regel
anzugeben.
1. Definieren der möglichen Sequenzen durch Konfigurationstabellen
Für jede Sequenz:
2. Interaktionen zeitlich ordnen
3. Interaktionen in das Sequenzdiagramm übernehmen
a) Ermitteln des Sender- und Empfängerklienten
b) Ermitteln des Objektes bzw. der Objektrolle
c) Identifizieren, ob parallele oder sequentielle Ausführung zur vorhergehenden
Interaktionen erfolgt.
d) Ggf. Angabe einer expliziten Interaktionsverknüpfung mit zeitlicher Regel
(Mindest-, Maximaldauer, direkte Auslösung)
Tab. 4-12 Vorgehen zum Sequenzdiagramm
Vorgehensweise zum Nachrichtendiagramm
Die Inhalte und Strukturen von Informationsobjekten werden mit Nachrichtendiagrammen
spezifiziert. Grundidee ist dabei, dass sich Informationsobjekte inhaltlich auf bestimmte
Gegenstände und Ereignisse der zwischenbetrieblichen Realwelt beziehen. Diese betriebliche
Realwelt liegt nun als Modellkonstruktion in Form von Transaktions-, Interaktions- und
Sequenzdiagrammen vor. Folglich lassen sich einzelne Elemente der Informationsobjekte, d.
h. die Nachrichtenelemente, auf Elemente der bisher erstellten Diagramme beziehen bzw. aus
ihnen ableiten.
Im einzelnen wird wie folgt vorgegangen. Zunächst ist die Nachrichtenstruktur des zu
beschreibenden Informationsobjektes zu analysieren. Es sind also Kopf- und Positionsdaten
sowie gegebenenfalls Positionseinteilungen zu identifizieren und in Form hierarchisch
399 Nähere Erläuterungen zum Beispiel erfolgen im Abschnitt 5.2.4
159
strukturierter Nachrichtencontainer im Nachrichtendiagramm abzubilden. Jeder
Nachrichtencontainer erhält dabei einen Verweis auf eine entsprechende Referenzklasse für
Informationsobjekte.
Anschrift
-StraßeHausnummer : Bezeichnung-Straßencode : Code-Postfachnummer : Nummer-Postleitzahl : Nummer-Ort : Bezeichnung-Ort : Code-Land : Bezeichnung-Land : Code-Gebäudenummer : Nummer-Gebäudebezeichnung : Bezeichnung
Einzelhandelsfiliale
+Name : Bezeichnung-ID_KF : ID-ID_VK : ID-ID_RS : ID-ID_RE : ID-ID_AG : ID
Bankverbindung
-Kreditinstitut : Bezeichnung-Bankleitzahl : Code-Kontonummer : ID
Kontaktangaben
-Name der Kontaktperson : Bezeichnung-Faxnummer : Nummer-Internet-Adresse : Nummer-Telefonnummer : Nummer-Telexnummer : Nummer-X.400-Adresse : Nummer
Verkaufsabteilung
Abteilung
-Identifizierung : ID-Name : Bezeichnung
Einkaufsabteilung
Buchhaltung
Versandstelle
-Ladestelle : Bezeichnung
AllBuy-Filiale
AllBuy-Zentrale
Hersteller
Referenzklasse:Einzelhandels-
filiale
Atomares Element: Paderborner Str.
Nachrichtenbaustein:Warenempfänger.Anschrift.StraßeHausnummer:Bezeichnung
Rolle:Warenempfänger
Attributkategorie:Bezeichnung
Abb. 4.23 Ableiten von Nachrichtenelementen
Anschließend werden in einem zweiten Schritt die Inhalte des Informationsobjekts bestimmt.
Dazu sind zunächst die atomaren Elemente zu bestimmen. Für jedes atomare Element ist ein
entsprechendes Nachrichtenelement im Nachrichtendiagramm vorzusehen, welches wiederum
aus bestimmten Nachrichtenbausteinen der Referenzbibliothek abgeleitet werden kann. Die
Ableitung erfolgt nach festgelegten Regeln, die nachfolgend anhand des Lieferabrufbeispiels
aus dem AllBuy-Szenario (vgl. Abb. 4.13) erläutert werden. Zunächst ist das zu beschreibende
atomare Element des Informationsobjektes in eine durch die Ontologie vorgegebene
Attributkategorie einzuordnen. So fällt z. B. das atomare Element „Paderborner Str.“ in die
Kategorie Bezeichnung. Danach ist zu überlegen, welchem Konstruktionselement im
Interaktionsdiagramm das atomare Element zugeordnet werden kann. Im gewählten Beispiel
ist „Paderborner Str.“ eine Eigenschaft der AllBuy-Filiale.
Wie im Abschnitt 4.4 beschrieben, ist jedes Konstruktionselement eines Transaktions- oder
Interaktionsdiagramms einer Klasse in der Referenzbibliothek zugeordnet. Über die
Verknüpfung der AllBuy-Filiale mit der Referenzklasse Einzelhandelsfiliale kann das
160
gesuchte Attribut aus der Kategorie Bezeichnung, nämlich
Anschrift.StraßeHausnummer:Bezeichnung, aus dem Referenzklassendiagramm für Klienten
ermittelt werden (vgl. Abb. 4.23). Die Rolle der AllBuy-Filiale bestimmt die vollständige
Bezeichnung des gesuchten Nachrichtenbausteins und damit des Nachrichtenelementes:
Warenempfänger.Anschrift.StraßeHausnummer:Bezeichnung. Nach der erläuterten
Vorgehensweise können die erforderlichen Nachrichtenelemente eines Informationsobjekts
gefunden werden.
1. Analyse der Nachrichtenstruktur eines Informationsobjektes:
a) Identifizieren der Nachrichtencontainer
b) Bestimmen der hierarchischen Struktur
2. Analyse der Nachrichteninhalte eines Informationsobjektes, d. h. für jedes
Nachrichtenelement:
a) Bestimmen des Konstruktionselementes, welches durch das Nachrichtenelement
beschrieben wird
b) Suchen nach dem passenden Attribut des bestimmten Konstruktionselementes
c) Ableiten des gesuchten Nachrichtenbausteins bzw. Nachrichtenelementes
d) Nachrichtenelement einem Nachrichtencontainer zuordnen
Tab. 4-13 Vorgehen zum Nachrichtendiagramm
Vorgehensweise zum Regeldiagramm
Folgendes Vorgehen ist beim Erstellen von Regeldiagrammen zur Spezifikation von
Integritätsregeln anzuwenden. Zunächst ist die eigentliche, zentrale Integritätsbedingung zu
identifizieren, die den Wert des zu prüfenden Nachrichtenelementes festlegt. Unter
Umständen kann diese Bedingung aber nicht unmittelbar geprüft werden, da einige Werte
dafür fehlen und erst ermittelt werden müssen. Daher sind in einem zweiten Schritt die
erforderlichen Vorbereitungsschritte zu identifizieren. Sodann sind die alternativen Aktionen
bei positivem und negativem Ergebnis der zentralen Prüfbedingung zu bestimmen. In beiden
Pfaden sind gegebenenfalls weitere Prüfbedingungen erforderlich. In diesen Fällen wird
jeweils wieder mit Schritt 2, d. h. mit den Vorbereitungsaktionen der entsprechenden
Prüfbedingung begonnen.
161
1. Identifizieren der zentralen Prüfbedingung
2. Identifizieren der erforderlichen Vorbereitungsschritte
3. Bestimmen der alternativen Aktionen bei positivem und negativem Ergebnis der zentralen
Prüfbedingung
4. Bestimmen der weiteren erforderlichen Prüfungen. Ggf. weiter bei 2.
Tab. 4-14 Vorgehen zum Regeldiagramm
162
5 Beispiel einer modellgestützten Integration mit MOVE
5.1 Vorschläge zur Referenzbibliothek
5.1.1 Vorgehen und Einschränkungen
Grundvoraussetzung für den Einsatz von MOVE ist die Existenz einer Referenzbibliothek.
Daher ist im Rahmen dieser Arbeit beispielhaft eine Referenzbibliothek mit einer Ontologie,
mit Referenzklassen und mit Nachrichtenbausteinen entwickelt worden. Entsprechend dem
AllBuy-Beispiel, anhand dessen das MOVE-Vorgehen in diesem Kapitel ausführlich
veranschaulicht werden soll, ist sie als Vorschlag für den Einsatz in der Konsumgüterbranche
zu verstehen.
Die Inhalte der vorgeschlagenen Referenzbibliothek sind zum einen in Zusammenarbeit mit
dem Europäischen Handelsinstitut (EHI, Köln) im Rahmen des Forschungsprojektes MOVE
auf der Basis von Interviews in Handelsunternehmen erarbeitet worden. Zum anderen sind sie
aus dem in der Konsumgüterbranche etablierten EDIFACT-Subset EANCOM abgeleitet
worden.400 Mit diesem Vorgehen konnte das in EDIFACT/EANCOM enthaltene und über
Jahrzehnte aufgebaute Know-how zwischenbetrieblicher Transaktionen in der
Konsumgüterbranche genutzt werden.
Da der Vorschlag zur Referenzbibliothek im wesentlichen der Veranschaulichung und
Illustration von MOVE dient, beschränkt sich der inhaltliche Umfang auf bestimmte Trans-
aktionen der Konsumgüterbranche. So soll in dieser Arbeit von Import- und Exportprozessen
abgesehen werden. Interaktionen zu Zollämtern und Ausfuhrbehörden, die bei
grenzüberschreitenden Leistungsbeziehungen zu beachten wären, werden damit ausgegrenzt.
Im Weiteren sollen nur Interaktionen berücksichtigt werden, an denen mindestens ein Klient
im primären Wertschöpfungsfluss beteiligt ist. Damit werden Austauschbeziehungen im
Interbankenverkehr sowie zwischen Spediteuren, Frachtführern und Agenten ausgeschlossen.
Ebenso werden Interaktionen mit öffentlichen Unternehmungen oder Haushalten (Sozialver-
sicherungen, Finanzämtern, etc.) nicht berücksichtigt.
400 Dabei wurde auf die Version EANCOM® '97 zurückgegriffen. Im Anhang befindet sich eine Aufstellung der berücksichtigten Nachrichtentypen.
163
5.1.2 Vorschlag einer Ontologie
5.1.2.1 Entwurfselemente
Vorgabe für die Entwicklung einer Ontologie für den Einsatz im Rahmen von MOVE ist die
Meta-Ontologie (vgl. Abb. 4.5). Ausgehend von der Unterteilung in die Entwurfselemente
Klient, Interaktion, Objekt und Kanal sowie in die beschreibenden Elemente Rolle und
Attribut erfolgt der Aufbau einer Generalisierungs-/Spezialisierungshierarchie nach
ontologischen Gesichtspunkten für jedes dieser Elemente.
Ontologie für Klienten
Wertschöpfungsketten in der Konsumgüterbranche bestehen in der Regel aus fünf Stufen:401
Rohstofflieferanten, Herstellerunternehmen, Großhandels- und Einzelhandelsunternehmen
sowie Endverbraucher. Dabei handelt es sich bei den Herstellern in der Mehrzahl um
Industrieunternehmen. Deren Zulieferer sind entweder ebenfalls Industrieunternehmen oder
Gewinnungsunternehmen. Daneben sind noch Dienstleistungsunternehmen (Speditionen,
Banken, Versicherungen, etc.) sowie staatliche Stellen an Wertschöpfungsketten in der
Konsumgüterbranche beteiligt.402 Eine ontologische Gliederung der genannten Unternehmen
bzw. Klienten wird in Abb. 5.1 vorgeschlagen.
401 Vgl. Petri (Integration 1990), S. 57 402 Vgl. Petri (Integration 1990), S. 57ff.
164
Klient Unternehmen Privates Unternehmen
Sachleistungsunternehmen Gewinnungsunternehmen Verarbeitungsunternehmen Industrieunternehmen
Handwerksbetrieb Entsorgungsunternehmen Dienstleistungsunternehmen Handelsunternehmen Großhandelsunternehmen (agg.) Großhandelszentrale (agg.) Einzelhandelsfiliale Einzelhandelsunternehmen Transportunternehmen Bankunternehmen Versicherungsunternehmen Sonstiges Dienstleistungsunternehmen
Öffentliche Unternehmen Sachleistungsunternehmen Versorgungsunternehmen Entsorgungsunternehmen Dienstleistungsunternehmen Finanzdienstleistungsunternehmen Sicherungsdienstleistungsunternehmen
Haushalt Privater Haushalt Ursprünglicher Haushalt Abgeleiteter Haushalt Öffentlicher Haushalt Finanzamt Zollbehörde
Abb. 5.1 Vorschlag einer Klientenontologie403
Ontologie für Interaktionen
Unter einer Interaktionen im Rahmen zwischenbetrieblicher Transaktionen wird die
Übertragung einer Leistung, Zahlung oder Information verstanden.404 Erstes Kriterium zur
Gliederung von Interaktionen ist daher der Gegenstand der Interaktion bzw. der Flusstyp.
Diese Unterscheidung nach Leistungs-, Zahlungs- und Informationsinteraktionen wird bereits
in der
MOVE-Meta-Ontologie vorgegeben. Aufgrund des zahlreichen Auftretens von verschiedenen
Informationsinteraktionen in Transaktionen werden diese weiter untergliedert. Als sinnvolles
Unterscheidungskriterium erscheint das Merkmal „Zweck aus Sendersicht“405, da es die
Bedeutung eines Informationsflusses im Rahmen einer zwischenbetrieblichen Transaktion
beschreibt. Im EDIFACT- bzw. EANCOM-Standard geht die Bedeutung bzw. der Zweck
eines Informationsflusses aus dem Nachrichtentyp hervor. Eine weitere Verfeinerung von
403 in Anlehnung an Schneider u. a. (Betriebswirtschaftslehre 1987), S. 19; Zelewski (Grundlagen 1999), S. 22ff. 404 Vgl. Abschnitt 2.2 405 Das Merkmal „Zweck aus Sendersicht“ wurde bereits im Kapitel 2 im Rahmen der pragmatischen Ebene der Integration von Informationsflüssen erläutert.
165
Interaktionstypen wird daher aus den 42 Nachrichtentypen des Subsets EANCOM abgeleitet
(vgl. Tab. 5-1). Der Vorschlag einer Interaktionsontologie ist in Abb. 5.2 dargestellt.
interagieren informieren anbahnen
anfragen anbieten initialisieren
beauftragen bestätigen dokumentieren
Leistungen dokumentieren
Zahlungen dokumentieren Nachrichten dokumentieren
Leistungen steuern
Leistungen anfordern Leistungen avisieren Leistungen anweisen Leistungen reklamieren Zahlungen steuern
Zahlungen anfordern Zahlungen avisieren
Zahlungen anweisen Zahlungen reklamieren allgemein informieren
Leistungen erbringen
liefern
Dienstleistungen durchführen
zahlen
Abb. 5.2 Vorschlag einer Interaktionsontologie
Ontologie für Objekte
In der MOVE-Meta-Ontologie wird bereits die Unterscheidung zwischen Leistungs-,
Zahlungs- und Informationsobjekten vorgegeben. Eine weitergehende Differenzierung
verschiedener Informationsobjekte erfolgt im EANCOM-Standard - wie bereits im
vorangegangenen Abschnitt erwähnt - durch die Unterscheidung verschiedener
Nachrichtentypen. Die EANCOM-Nachrichtentypen bestimmen Inhalt und Struktur einer
Nachricht und werden daher für den Aufbau des Ontologieausschnitts für Informationsobjekte
herangezogen (vgl.
Tab. 5-1).
Dabei wird die Liste der Nachrichtentypen, ausgehend von der ontologischen Klasse
Informationsobjekt, hierarchisch strukturiert. Erstes Gliederungskriterium für die
Strukturierung ist die Transaktionsphase, in der Informationsobjekte eingesetzt werden
(Anbahnung, Vereinbarung oder Durchführung sowie phasenunabhängig).
166
Informationsobjekte der Durchführungsphase werden aufgrund ihrer großen Zahl weiter nach
dem Zweck aus Sendersicht406 unterteilt (dokumentierend, leistungssteuernd oder
zahlungssteuernd).
Zweck
EANCOM-Nachrichtentyp
Abgeleiteter (Informations-) Objekttyp
Abgeleiteter Interaktionstyp
Anbahnen REQOTE Request for quote Anfrage Anfragen PRICAT Price/sales catalogue Preisliste/Katalog QUOTES Quotes Angebot
Anbieten
Initialisieren ORDERS Purchase order message Bestellung ORDCHG Purchase order change Bestelländerung IFTMIN Instruction message Transport/Speditionsauftrag IFTMBF Firm booking message Buchung/Reservierung
Beauftragen
ORDRSP Purchase order response Bestellbestätigung IFTMBC Booking confirmation message Buchungs-/Reservierungsbestätigung
Bestätigen
Dokumentieren OSTENQ Order status enquiry Bestellstatusanfrage OSTRPT Order status report Bestellstatusbericht RECADV Receiving advice Warenlieferschein QALITY Quality data message Qualitätsbericht IFTMAN Arrival notice message Ankunftsmeldung IFCSUM Consolidation summary message Speditions- und
Sammelladungsnachricht IFTSTA Multimodal status report Multimodaler Statusbereicht
Leistungen dokumentieren
BANSTA Banking status Bank-Status-Nachricht CREMUL Multiple credit advice Multiple Gutschriftsanzeige DEBADV Debit advice Belastungsanzeige DEBMUL Multiple debit advice Multiple Belastungsanzeige REMADV Remittance advice Zahlungsmeldung
Zahlungen dokumentieren
CONTRL Syntax and service report Syntax- und Servicereport Nachrichten dokum. Leistungen steuern DELFOR Delivery schedule Lieferabruf Leistungen anfordern DESADV Despatch advice Lieferavis RETANN Announcement of return Rücksendungsavis
Leistungen avisieren
HANMOV Handling and movement Ladungs-/Güterumschlag und Transport
INSDES Instruction to despatch Versandanweisung RETINS Instruction for return Rücksendungsanweisung
Leistungen anweisen
Leistungen reklamieren
Zahlungen steuern INVOIC Invoice Einzelrechnung Sammelrechnung
Zahlungen anfordern
Zahlungsavis Zahlungen avisieren PAYMUL Multiple payment order Multipler Zahlungsauftrag DIRDEB Direct debit Lastschrift FINCAN Financial cancellation message Zahlungsstornierung
Zahlungen anweisen
COMDIS Commercial dispute message Rechnungsreklamation Zahlungen reklamieren
GENRAL General purpose message Allgemeine Nachricht INVRPT Inventory report Bestandsbericht MSCONS Metered services consumption
report Bericht ü. verbrauchsabh. Dienstleist.
PARTIN Party information Partnerstammdaten PRODAT Product data message Produktstammdaten PROINQ Product inquiry message Produktdatenanfrage SLSFCT Sales forcast Verkaufsprognose SLSRPT Sales data report Verkaufsdatenbericht COACSU Commercial account summary Geschäftskontoauszug FINSTA Financial statement Bankkontoauszug
Allgemein informieren
TAXCON Tax control Steuernachweis
Allgemein informieren
Tab. 5-1 Ableitung der Informationsobjekt- und Interaktionstypen aus den EANCOM-Nachrichtentypen
406 Die Merkmale „Transaktionsphase“ und „Zweck aus Sendersicht“ wurden bereits im Kapitel 2 im Rahmen der pragmatischen Ebene der Integration von Informationsflüssen erläutert.
167
Neben der hierarchischen Gliederung erfolgt auch eine Berücksichtigung von Ag-gregationsstrukturen. Allen Informationsobjekten gemein ist die Aufteilung in Kopf- und Positionsdaten. Mitunter werden Positionen weiter unterteilt. Diese Struktur wird in der Ontologie übernommen. Abb. 5.3 zeigt den Ontologieausschnitt für Informationsobjekte. Informationsobjekt (IO) (agg.) IO-Kopf (agg.) IO-Positionen (agg.) Positionseinteilung IO der Anbahnungsphase Anfrage Preisliste/Katalog Angebot IO der Vereinbarungsphase Bestellung Bestellbestätigung Bestelländerung Transport-/Speditionsauftrag Buchung/Reservierung Buchungs-/Reservierungsbestätigung IO der Durchführungsphase dokumentierendes IO Leistungen dokumentierend Bestellstatusanfrage Bestellstatusbericht Warenlieferschein Qualitätsbericht Ankunftsmeldung Speditions und Sammelladungsnachricht Multimodaler Statusbericht Zahlungen dokumentierend Bank-Status-Nachricht Multiple Gutschriftsanzeige Belastungsanzeige Multiple Belastungsanzeige Zahlungsmeldung Nachrichten dokumentierend Syntax- und Servicereport leistungssteuerndes IO Lieferabruf Lieferavis Rücksendungsavis Ladungs-/Güterumschlag und -transport Versandanweisung Rücksendungsanweisung zahlungssteuerndes IO Einzelrechnung Sammelrechnung Zahlungsavis Multipler Zahlungsauftrag Lastschrift Zahlungsstornierung Rechnungsreklamation phasenunabhängiges IO Allgemeine Nachricht Bestandsbericht Bericht über verbrauchsabhängige Dienstleistungen Partnerstammdaten Produktstammdaten Produktdatenanfrage Verkaufsprognose Geschäftskontoauszug Bankkontoauszug Steuernachweis
Abb. 5.3 Vorschlag einer Ontologie für Informationsobjekte407
407 (agg.) steht für eine Aggregationsbeziehung
168
Der Aufbau einer Ontologie für Leistungsobjekte gestaltet sich aufgrund der Fülle von
verschiedenartigen Leistungen als schwierig. Eine allgemeingültige Ontologie zu erarbeiten
erscheint daher nicht möglich, vielmehr ist der Ontologieumfang auf die in einer Branche
vorkommenden Leistungsobjekte zu beschränken. So wird im Rahmen dieser Arbeit eine auf
die Konsumgüterbranche beschränkte Ontologie für Leistungsobjekte vorgeschlagen, die sich
darüber hinaus auf den Lebensmittelbereich konzentriert.
Leistungsobjekt Dienstleistungsobjekt Warenlieferung (agg.) Transporteinheit (agg.) Transporthilfsmittel (agg.) Packstück (agg.) Verpackung (agg.) Artikel Lebensmittelartikel Frischwarenartikel Fleisch, Wurst, Geflügel, Fisch Obst und Gemüse Brot und Backwaren Molkereiprodukt Nahrungs- und Genussartikel Tiefkühlkost/Eis Konserven Getränke/Genussmittel Trockensortimentsartikel Nonfood-Artikel Wasch-, Putz- und Reinigungsmittel Körperpflege und Kosmetik/Papiere Pflanzen und Tier Oberbekleidung Textilien Schuhe und Lederwaren Haushalts-/Geschenkartikel
Abb. 5.4 Vorschlag einer Ontologie für Leistungsobjekte
Das Leistungsobjekt von Transaktionen in der Konsumgüterbranche besteht in der Regel aus
mehreren Einzelkomponenten.408 So besteht eine Warenlieferung aus einer oder mehreren
Transporteinheiten. Diese wiederum bestehen aus einem Transporthilfsmittel, wie etwa einer
Palette, einer Gitterbox oder ähnlichen, und den Packstücken. Bestandteile eines Packstücks
ist die Verpackung (z. B. Karton) und letztendlich ein oder mehrere Artikel, die den eigent-
lichen Gegenstand einer Transaktion darstellen. Wie bereits erwähnt, erfolgt an dieser Stelle
eine Beschränkung auf Lebensmittelartikel. Bei der weiteren Spezialisierung von
Lebensmittelartikeln soll der Einteilung des EuroHandelsinstituts (EHI) gefolgt werden.409
Danach werden zunächst die Sortimentsgruppen Frischwaren-, Nahrungs- und Genuß- sowie
408 Zu den folgenden Ausführungen vgl. Scheer (Wirtschaftsinformatik 1994), S. 458ff.; Jünemann, Schmidt (Materialflußsysteme 1999), S. 11ff. 409 Vgl. EuroHandelsinstitut e.V. (Handel 1996), S. 223ff.
169
Nonfood-Artikel unterschieden. Wie der Abb. 5.4 entnommen werden kann, werden diese
Sortimentsgruppen weiter nach Warengruppen gegliedert.
Eine für die Konsumgüterbranche relevante Ontologie für Zahlungsobjekte lässt sich
unmittelbar aus dem EANCOM Datenelement ‚4461 - Zahlungsmittel, codiert‘ ableiten (vgl.
Abb. 5.5).
Zahlungsobjekt Barzahlung Münzen/Banknoten (10) Scheck Verrechnungsscheck (20) Bankscheck (23) Zertifizierter Scheck (25) Inlandsscheck (26) Kreditkarte (11E) Geldwertkarte (12E) Unbarzahlung Überweisung/Lastschrift Gutschriftübermittlung (30) Lastschriftübermittlung (31 und 15E) Zahlung an Bankkonto (42) Zahlung durch Postgiro (50) Zahlung über Bankgiro (14E) Buchung Gutschriftsbuchung (15) Lastschriftbuchung (16) Ausgleichsbuchung (97) Wechsel Bankwechsel (21) Wechsel, vom Gläubiger auf Schuldner gezogen (70) Wechsel, vom Gläubiger auf Bank gezogen (74) Schuldschein (60)
Abb. 5.5 Vorschlag einer Ontologie für Zahlungsobjekte410
Ontologie für Kanäle
Kanäle könnten danach gegliedert werden, ob sie zur Realisierung von Informations-,
Leistungs- oder Zahlungsinteraktionen dienen. Dies ist problematisch, da sich viele Kanäle für
mehrere Interaktionsarten eignen. So können beispielsweise per Auslieferungs-LKW sowohl
die Leistung als auch die Zahlung und jeweils die begleitenden Informationsobjekte
übertragen werden. Daher wird eine andere Gliederung für die Kanalontologie gewählt. Es
sollen physische (Transportwege) und elektronische (Kommunikationswege) Kanäle
unterschieden werden. Diese Unterteilung und die weitere Differenzierung können aus den
EANCOM Datenelementen ‚8067 - Transportart, codiert‘ und ‚3155 - Kommunikationsweg/-
dienst‚ Qualifier‘ abgeleitet werden (vgl. Abb. 5.6). Die Ausprägungen des EANCOM
Datenelementes ‚4435 - Zahlungsweg‘ können aus den genannten Gründen teilweise den phy-
sischen Kanälen und teilweise den elektronischen Kanälen zugeordnet werden.
410 in Klammern Code des EANCOM Datenelementes ‚4461 - Zahlungsmittel‚ codiert‘
170
Kanal Physischer Kanal (Transportweg) Seetransport (8067/10) Bahntransport (8067/20) Straßentransport (8067/30) Lufttransport (8067/40) Transport über Binnengewässer (8067/80) Per Post Normale Post (8067/50, 4435/1) Luftpost (4435/2) Einschreiben (4435/11) Per Botendienst (8067/100) Direkter Kanal (face to face, 4435/9) Elektronischer Kanal (Kommunikationsweg) Telefon (3155/TE) Telefax (3155/FX) Telex (3155/TL, 4435/4) Telegramm (3155/CA, 4435/3) Electronic Mail (3155/EM) X.400 (3155/XF) Internet (3155/WWW) EDI/VAN (3155/EI) VPN
Abb. 5.6 Vorschlag einer Ontologie für Kanäle411
5.1.2.2 Beschreibende Elemente
Rollen
Bei zwischenbetrieblicher Transaktionen ist es häufig der Fall, dass ein und derselbe Klient in
unterschiedlichen Szenarien auftritt. So ist ein Klient in der Regel an mehreren zwischen-
betrieblichen Transaktionen beteiligt und übernimmt dort jeweils eine andere Funktion. Zum
Beispiel tritt der Hersteller im AllBuy-Szenario gegenüber der AllBuy-Filiale als Warensender
auf. Aus Sicht der AllBuy-Zentrale ist er dagegen Auftragnehmer, Rechnungsteller und
Zahlungsempfänger. Um diese Aspekte modellieren zu können, ist im MOVE-
Entwurfsrahmen für Klienten und Objekte das Konzept der Rolle eingeführt worden. Wie für
die Entwurfselemente so erfolgt auch für die Rollen eine Hierarchiebildung innerhalb der
Ontologie.
Klientenrollen
Im EANCOM-Handbuch der CCG412 werden zur Beschreibung des Verwendungszwecks der
Nachrichtentypen folgende Rollen von Klienten genannt: Käufer, Lieferant,
Logistikdienstleister, Transporteur, Bank des Käufers und Bank des Lieferanten. Die
Codeliste „3035 Beteiligter, Qualifier“, von der im EANCOM-Standard etwa hundert
411 in Klammern Code der EANCOM Datenelemente ‚3155 - Kommunikationsweg/-dienst‚ Qualifier‘, ‚4435 - Zahlungsweg‘ und ‚8067 - Transportart, codiert‘ 412 Vgl. Centrale für Coorganisation (EANCOM 1999)
171
Einträge verwendet werden, liefert weitere Hinweise auf mögliche Klientenrollen (vgl. Tab.
5-2).
Einträge in EANCOM Codeliste 3035 Abgeleitete MOVE-Rollen EANCOM-Handbuch Code Bezeichnung Kürz. Bezeichnung AB Buyer's agent/ representative HK Handelsvertreter des Käufers Käufer BY Buyer KF Käufer CA Carrier FF Frachtführer CN Consignee LE Leistungsempfänger CPE Central payment service ZR Zentralregulierer CZ Consignor LS Leistungssender Transporteur FW Freight forwarder SP Spediteur II Issuer of invoice RS Rechnungsteller IN Insurer VE Versicherer IV Invoicee RE Rechnungsempfänger Logistikdienstleister LSP Logistic service provider LD Logistikdienstleister MF Manufacturer of goods HE Hersteller OB Ordered by AG Auftraggeber Bank des Käufers PB Paying financial institution BK Bank des Käufers PE Payee ZE Zahlungsempfänger PR Payer ZS Zahlungssender Bank des Lieferanten RH Seller's financial institution BV Bank des Verkäufers Lieferant SE/SU Seller/Supplier VK Verkäufer SR Supplier's agent HV Handelsvertreter des Verkäufers UD Ultimate customer EV Endverbraucher WS Wholesaler GH Großhändler
Tab. 5-2 Ableitung der Rollen aus EANCOM
Eine Gliederung der Rollen ergibt sich aus folgenden Überlegungen. Klientenrollen sind
abhängig von der Betrachtungsebene, d. h. sie können auf der Ebene einer gesamten Wert-
schöpfungskette oder auf der Ebene einer zwischenbetrieblichen Transaktion betrachtet
werden. Auf beiden Ebenen sollen Klientenrollen aus Sicht des Leistungsflusses betrachtet
werden. Die Rollen des Käufers und Verkäufers können nach der Beteiligung am
Informations-, Leistungs- oder Zahlungsfluss weiter differenziert werden (vgl. Tab. 5-3).
Fluss Käuferrolle Verkäuferrolle im Informationsfluss im leistungssteuernden
Informationsfluss Auftraggeber
Auftragnehmer
im zahlungssteuernden Informationsfluss
Rechnungsempfänger
Rechnungsteller
im Leistungsfluss Leistungsempfänger
Leistungssender
im Zahlungsfluss
Zahlungssender Zahlungsempfänger
Tab. 5-3 Käufer- und Verkäuferrollen
172
Daraus ergibt sich der in Abb. 5.7 dargestellte Vorschlag einer Ontologie für Klientenrollen.
Rolle Klientenrolle Rolle auf Ebene der Wertschöpfungskette Zulieferer Hersteller Großhandel Einzelhandel Endverbraucher Logistikdienstleister Zentralregulierer Rolle auf Ebene der zwischenbetrieblichen Transaktion Käufer (agg.) Auftraggeber (agg.) Rechnungsempfänger (agg.) Leistungsempfänger (agg.) Zahlungssender Verkäufer (agg.) Auftragnehmer (agg.) Rechnungsteller (agg.) Leistungssender (agg.) Zahlungsempfänger Spediteur Bank des Käufers Bank des Verkäufers Handelsvertreter des Käufers Handelsvertreter des Verkäufers Versicherer
Abb. 5.7 Vorschlag einer Ontologie für Klientenrollen
Objektrollen
Ebenso wie Klienten, so können auch Objekte kontextabhängige Rollen einnehmen. So kann
ein Formular mit einer Artikelaufstellung sowohl als Anfrage, Bestellung oder Lieferschein
dienen. Objektrollen werden zunächst nach der Verwendung im Leistungs-, Zahlungs- oder
Informationsfluss unterteilt.
Rollen von Informationsobjekten können aus der EDIFACT Codeliste 1001 „Dokumenten-/
Nachrichtenname“ abgeleitet werden. Im EANCOM-Subset werden etwa 130 Einträge
verwendet, die für den Aufbau der Objektrollenontologie hierarchisch zu strukturieren sind.
Rollen geben Aufschluss über den Verwendungszweck eines Informationsobjektes und damit
über die erforderliche Verarbeitungsstrategie an den Inhousesystemschnittstellen.413 Daher
werden die Kriterien Transaktionsphase sowie Zweck aus Sendersicht zur Strukturierung der
Rollen herangezogen. Da eine vollständige Darstellung der Rollenontologie zu umfangreich
wäre, werden in Abb. 5.8 nur für Bestell- und Rechnungsrollen beispielhaft die Blätter der
Ontologie angegeben.
413 Vgl. Scheckenbach (Geschäftsprozeßintegration 1997), S. 203
173
Rolle Objektrolle Informationsobjektrolle anbahnend Anfrage Preisliste/Katalog Angebot initialisierend Bestelländerung Bestellung Bestellung (normal) (220) Rahmenauftrag (221) Eilauftrag (224) Abrufauftrag (226) Vom Hersteller erstellte Bestellung (22E) Dauerauftrag (23B) Lieferplan (41E, 42E) Cross Docking-Auftrag (50E) Bestellbestätigung dokumentierend Bestellstatusanfrage Bestellstatusbericht Wareneingangsmeldung Qualitätsbericht Speditions- und Sammelladungsnachricht Multimodaler Statusbericht Bank-Status-Nachricht Syntax- und Servicereport leistungssteuernd Lieferabruf Buchung/Reservierung Buchungs-/Reservierungsbestätigung Lieferavis Rücksendungsavis Ladungs-/Güterumschlag und -transport Transport-/Speditionsauftrag Versandanweisung Rücksendungsanweisung Ankunftsmeldung zahlungssteuernd Rechnung Rechnungsdatenblatt (130) Proforma-Rechnung (325) Handelsrechnung (380) Korrigierte Rechnung (384) Konsolidierte Rechnung (385) Vorauszahlungsrechnung (386) Selbst ausgestellte Rechnung (389) Delkredere Rechnung (390) Inkasso Rechnung (393) Zahlungsavis Multipler Zahlungsauftrag Lastschrift Zahlungsstornierung Rechnungsreklamation Multiple Gutschriftsanzeige Belastungsanzeige Multiple Belastungsanzeige Zahlungsmeldung Allgemein informierend Bestandsbericht Bericht über verbrauchsabhängige Dienstleistungen Partnerstammdaten Produktstammdaten Produktdatenanfrage Verkaufsprognose Verkaufsdatenbericht Geschäftskontoauszug Bankkontoauszug Steuernachweis Rolle eines Leistungsobjekts Lieferung Dienstleistung Rolle eines Zahlungsobjekts Zahlung
Abb. 5.8 Vorschlag einer Ontologie für Objektrollen414
414 Zahlen in Klammern: Kennziffer des Eintrags in der EDIFACT-Codeliste 1001 „Dokumenten-/ Nachrichtenname“.
174
Attribute
Gegenstände, die nicht in die Kategorien der Entwurfselemente oder in die Kategorie Rolle
fallen, sind Attribute. Attribute stellen die im Rahmen zwischenbetrieblicher
Informationsflüsse relevanten und bedeutsamen Eigenschaften der Entwurfselemente dar und
sind Grundlage für die auszutauschenden Nachrichten.415 Attribute findet man in EANCOM in
Form von etwa 330 Datenelementen wieder. Wegen der großen Zahl werden nur einige
Beispiele für die Ableitung von Attributen aus den EANCOM-Datenelementen aufgeführt
(vgl. Tab. 5-4). Aufgrund des generischen Ansatzes von EDIFACT bzw. EANCOM (vgl.
Abschnitt 5.2.5) werden Attribute häufig aus einer Kombination eines Datenfeldes mit einem
Qualifier abgeleitet.
Für den Aufbau einer Attributontologie gilt es, die Liste der abgeleiteten Attribute in
geeigneter Weise zu strukturieren. Dazu wird der Vorschlag von FISCHER aufgegriffen, der
betriebswirtschaftliche, operative Attribute wie folgt gliedert:416
• Identifizierende/ beschreibende Attribute
• Leistungsverkehrsbestimmende Attribute
• Zahlungsverkehrsbestimmende Attribute
• Steuerrechtliche Attribute
Leistungsverkehrsbestimmende und zahlungsverkehrsbestimmende Attribute können dabei
noch zu geschäftsverkehrsbestimmenden Attributen zusammengefasst werden. Orientierung
für die zweite Gliederungsebene der Attributontologie geben die EANCOM-Datensegmente.
Abb. 5.9 zeigt einen Ausschnitt der vorgeschlagenen Attributontologie.
415 vgl. Abschnitt 4.2 416 Vgl. Fischer (Datenmanagement 1992), S. 103f.
175
EANCOM Datenelement MOVE-Attribut 3036 Name des Beteiligten 3432 Name des Kreditinstituts
Name
7140 Produkt-/Leistungsnummer 7143/EN Produktnummer, codiert; „EN“=EAN
EAN-Artikelnummer
3039 Identifikation des Beteiligten 3055/9 Verantwortliche Stelle für die Codepflege, codiert; „9“=EAN
ILN
Bei Klienten: 3039 Identifikation des Beteiligten 3055/9 Verantwortliche Stelle für die Codepflege, codiert;
„92“=Vergeben vom Käufer oder seinem Agenten Bei Leistungsobjekten: 7140 Produkt-/Leistungsnummer 7143/BP Produkt-/Leistungsnummer, Art, codiert; „BP“=Artikelnummer
des Käufers
ID_KF (ID, vom Käufer vergeben)
Bei Klienten: 3039 Identifikation des Beteiligten oder 3055/9 Verantwortliche Stelle für die Codepflege, codiert; „91“=
Vergeben vom Lieferanten oder seinem Agenten Bei Leistungsobjekten: 7140 Produkt-/Leistungsnummer 7143/SA Produkt-/Leistungsnummer, Art, codiert; „SA“=Artikelnummer
des Lieferanten
ID_VK (ID, vom Verkäufer vergeben)
1082 Positionsnummer Positionsnummer 7008 Produkt-/Leistungsbeschreibung
7077/F Produkt-/Leistungsbeschreibung, Art, codiert; „F“=Freiform
Freiformbeschreibung
3042 Straße und Hausnummer StraßeHausnummer 3251 Postleitzahl Postleitzahl 3164 Ort Ort 2380 Datum/Uhrzeit/Zeitspanne 2005/2 Datum/Uhrzeit/Zeitspanne, Qualifier; „2“=Lieferdatum,
gefordert 2380 Datum/Uhrzeit/Zeitspanne 2005/10 Datum/Uhrzeit/Zeitspanne, Qualifier; „10“=Versanddatum,
gefordert 2380 Datum/Uhrzeit/Zeitspanne 2005/203 Datum/Uhrzeit/Zeitspanne, Qualifier; „203“=Ausführungsdatum,
gefordert
Gefordert (Zeitpunkt)
2380 Datum/Uhrzeit/Zeitspanne 2005/137 Datum/Uhrzeit/Zeitspanne, Qualifier; „137“=Dokumentendatum
Erstellt (Zeitpunkt)
6060 Menge 6063/21 Menge, Qualifier; „21“=Bestellmenge
MengeGefordert
5118 Preis 5387/AAB Preisart, Qualifier; „AAB“=Preis inklusive Steuer
PreisMitMwSt
5118 Preis 5387/NTP Preisart, Qualifier; „NTP“=Nettopreis
PreisOhneMwSt
Tab. 5-4 Ableitung von Attributen aus EANCOM-Datenelementen (Beispiele)
176
Attribut Identifizierendes Attribut Natürliche Identifizierung Name Künstliche Identifizierung ILN (International Location Number) EAN (EAN eines Leistungsobjektes) ID_KF (vom Käufer vergebene Identifizierung) ID_VK (vom Verkäufer vergebene Identifizierung) ID_AG (vom Auftraggeber vergebene Identifizierung) Nummerierung Positionsnummer Beschreibendes Attribut Freiformbeschreibung InformationAllgemein (Allgemeine Information zu einem Dokument) Geschäftsverkehrsbestimmendes Attribut Ortsangabe (LOC) Anschrift (NAD) (agg.) StraßeHausnummer (agg.) Postleitzahl (agg.) Postfachnummer (agg.) Ort (agg.) Land AnlieferungsAnschrift PostalischeAnschrift Zeitangabe (DTM) Dauer Zeitpunkt Gefordert (Geforderter Zeitpunkt einer Interaktion) Erstellt (Erstellzeitpunkt eines Dokumentes) Leistungsverkehrsbestimmendes Attribut Größe Mengenangabe (QTY) MengeGefordert Zahlungsverkehrsbestimmendes Attribut Wertangabe (PAI, PAT) Betrag (MOA) Preisangaben (PRI) (agg.) PreisInklMwSt (agg.) PreisExklMwSt VKanKF-Preis Label-Preis Währungsangabe (CUX) Referenzwährung (Angabe der Referenzwährung) Steuerrechtliches Attribut (TAX)
Abb. 5.9 Vorschlag einer Attributontologie (Ausschnitt)417
5.1.2.3 Semantische Regeln
Die im Rahmen von MOVE vorgesehene Ontologie enthält drei verschiedene Kategorien von
semantischen Regeln:
1. <Klientenrolle> <kann beteiligt sein an> <Interaktion>
2. <Interaktion> <sieht vor> <Objektrolle>
3. <Objekt> <kann ausfüllen> <Objektrolle>
Für jede Kategorie sollen nachfolgend einige Beispiele aus der vorgeschlagenen Ontologie
aufgeführt werden.418
177
Mit semantischen Regeln der ersten Kategorie kann über die Klientenrolle festgelegt werden,
an welchen Interaktionen ein Klient beteiligt sein darf. Die wird beispielhaft in Tab. 5-5
verdeutlicht.
Klientenrolle Erlaubte Interaktionen (beteiligt als Sender)
Erlaubte Interaktionen (beteiligt als Empfänger)
Auftraggeber • Anfragen • Beauftragen • Auftrag ändern • Abrufen • Buchen
• Anbieten • Auftrag bestätigen • Auftragsänderung bestätigen • Lieferung avisieren
Leistungsempfänger • Abrufen • Lieferung avisieren • Ankunft melden • Lieferung melden • Liefern
Tab. 5-5 Beziehung zwischen Klientenrollen und Interaktionen
Über die Regel der Kategorie <Interaktion> <sieht vor> <Objektrolle> können die für eine
Interaktion infrage kommenden Objektrollen eingeschränkt werden. Beispiele dafür sind aus
Tab. 5-6 ersichtlich.
Interaktion Vorgesehene Objektrollen Werben • Produktkatalog
• Werbung • Klientenbeschreibung
Anfragen • Anfrage • Ausschreibungstext
Abrufen • Lieferabruf Tab. 5-6 Beziehung zwischen Interaktionen und Objektrollen
Schließlich kann mit semantischen Regeln der dritten Kategorie festgelegt werden, welche
Objekttypen welche Objektrollen übernehmen können. Tab. 5-7 zeigt dies beispielhaft für die
Objekttypen Bestellung und Rechnung.
417 in Klammern: Bezeichnung der EANCOM-Datensegmente 418 Eine vollständige Darstellung wäre zu umfangreich.
178
Objekttyp Mögliche Objektrollen Bestellung • Bestellung (normal)
• Rahmenauftrag • Eilauftrag • Abrufauftrag • Vom Hersteller erstellte Bestellung • Dauerauftrag • Cross Docking-Auftrag
Rechnung • Rechnungsdatenblatt • Proforma-Rechnung • Handelsrechnung • Korrigierte Rechnung • Konsolidierte Rechnung • Vorauszahlungsrechnung • Selbst ausgestellte Rechnung • Delkredere Rechnung • Inkasso Rechnung
Tab. 5-7 Beziehung zwischen Objekttypen und Objektrollen
5.1.3 Vorschläge für Referenzklassen
Die im vorhergehenden Abschnitt vorgestellten ontologischen Klassen bilden den
Ausgangspunkt für die Vorschläge von Referenzklassen. Hierbei erfolgt eine Zuordnung von
Attributen und Attributgruppen zu den ontologischen Klassen.
Um die Darstellung übersichtlich zu halten, werden in Abb. 5.10 und Abb. 5.11 exemplarisch
nur Ausschnitte der Referenzklassendiagramme für Klienten und Objekte, die im Rahmen
dieser Arbeit erarbeitet worden sind, gezeigt. Sie enthalten im Wesentlichen die Referenz-
klassen, die in den Beispielen im weiteren Verlauf dieses Kapitels verwendet werden.
Die linke Hälfte der Abb. 5.10 zeigt einen Ausschnitt der bereits zuvor vorgestellten Klientenontologie. Sie ist mit der Generalisierungs-/Spezialisierungshierarchie der Referenz-klassen für Klienten identisch. In der rechten Hälfte sind die zugeordneten Attributgruppen abgebildet. Welchen Entwurfselementklassen sie zugeordnet werden, ist abhängig von den in der Realität beobachtbaren Gegebenheiten. So ist zu beobachten, dass grundsätzlich zu allen Klienten eine Bankverbindung sowie eine Anschrift angegeben werden kann. Dagegen sind Kontaktangaben wie Telefax-, Telexnummer oder X.400-Adresse nur für Unternehmen sinnvoll. In dieser Form gelten sie nicht für jeden (privaten) Haushalt. Die Attributgruppe Abteilung mit ihren exemplarischen Spezialisierungen Verkaufsabteilung, Buchhaltung, Einkaufsabteilung und Versandstelle wird der Referenzklasse Industrieunternehmen zugeordnet, da die vorgenommene Unterteilung nur für diesen Unternehmenstyp sinnvoll erscheint.
179
Anschrift
-StraßeHausnummer : Bezeichnung-Postfachnummer : Nummer-Postleitzahl : Nummer-Ort : Bezeichnung-Ort : Code-Land : Bezeichnung-Land : Code
Klient
-Name : Bezeichnung-ID_KF : ID-ID_VK : ID-ID_RS : ID-ID_RE : ID-ID_AG : ID
Bankverbindung
-Kreditinstitut : Bezeichnung-Bankleitzahl : Code-Kontonummer : ID
Privates Unternehmen Kontaktangaben
-Name der Kontaktperson : Bezeichnung-Faxnummer : Nummer-Internet-Adresse : Nummer-Telefonnummer : Nummer-Telexnummer : Nummer-X.400-Adresse : Nummer
Verkaufsabteilung
Abteilung
-Identifizierung : ID-Name : Bezeichnung
Einkaufsabteilung
Buchhaltung
Industrieunternehmen
Einzelhandelsfiliale
Versandstelle
-Ladestelle : Bezeichnung
Grosshandelszentrale
Entwurfselementklassen Attributgruppen
Dienstleistungsunternehmen Sachleistungsunternehmen
Handelsunternehmen
Großhandelsunternehmen
Verarbeitungsunternehmen
Unternehmen
-ILN : ID
Abb. 5.10 Referenzklassendiagramm für Klienten (Ausschnitt)
Entwurfselementklassen Attributgruppen
Informationsobjekt
-Erstellt : Zeitpunkt-ID_LE : ID-ID_AG : ID-ID_WS : ID
IO-Kopf
IO-Position
-Positionsnummer : Nummer-PositionsbetragOhneMwSt : Betrag
IO-Positionseinteilung
-Positionsnummer : Nummer
IO der Anbahnungsphase IO der Vereinbarungsphase IO der Durchführungsphase phasenunabhängiges IO
Bestellung
-GültigAb : Zeitpunkt-GültigBis : Zeitpunkt
Warenlieferschein
Dokumentierendes IO leistungssteuerndes IO zahlungssteuerndes IO
Leistungen dokumentieren Lieferabruf Einzelrechnung
Summenangaben
-GesamtOhneMwSt : Betrag-GesamtMitMwSt : Betrag-MwStVoll : Betrag-MwStVoll : Rate
Objekt
Leistungsobjekt
Transporteinheit
Artikel
-EAN-Artikelnummer : ID-ID_KF : ID-ID_VK : ID-Name : Bezeichnung-MengeGefordert : Menge-MengeRahmenauftrag : Menge-PreisOhneMwSt : Preis-PreisMitMwSt : Preis-Freiformbeschreibung : Text
Barzahlung Warenlieferung
Verrechnungsscheck Packstück
Zahlungsobjekt
Scheck
Abb. 5.11 Referenzklassendiagramm für Objekte (Ausschnitt)
Einigen Entwurfselementklassen und Attributgruppen werden Attribute zugeordnet. Attribute
werden soweit wie möglich „oben“ in der Generalisierungs-/Spezialisierungshiearchie
180
angeordnet. Dabei sollen sie stets Gültigkeit für sämtliche Spezialisierungen haben, da sie an
diese vererbt werden.
5.1.4 Beispiele für Nachrichtenbausteine
Aus der Ontologie und den Referenzklassen lassen sich Nachrichtenbausteine ableiten. Sie
sind vollständig durch sie festgelegt. Im Abschnitt 4.3.4 wird die Vorschrift zur Bildung von
Nachrichtenbausteinen erläutert. Danach ist ein jedes Attribut in einem
Referenzklassendiagramm Ausgangspunkt eines semantischen Labels für einen
Nachrichtenbaustein. Durch Kombination mit der Rollenontologie - abhängig vom
Entwurfselementtyp Klient, Interaktion, Objekt oder Kanal - entstehen Nachrichtenbausteine.
Klient.Name:Bezeichnung Klient.ID_KF:ID Klient.ID_VK:ID Klient.ID_RS:ID Klient.ID_RE:ID Klient.ID_AG:ID Klient.Bankverbindung.Kreditinstitut:Bezeichnung Klient.Bankverbindung.Bankleitzahl:Code Klient.Bankverbindung.Kontonummer:ID Unternehmen.ILN:ID Privates Unternehmen.Anschrift.StraßeHausnummer:Bezeichnung Privates Unternehmen.Anschrift.Straßencode:Code Privates Unternehmen.Anschrift.Postfachnummer:Nummer Privates Unternehmen.Anschrift.Postleitzahl:Nummer Privates Unternehmen.Anschrift.Ort:Bezeichnung Privates Unternehmen.Anschrift.Ort:Code Privates Unternehmen.Anschrift.Land:Bezeichnung Privates Unternehmen.Anschrift.Land:Code Privates Unternehmen.Anschrift.Gebäudenummer:Nummer Privates Unternehmen.Anschrift.Gebäudebezeichnung:Bezeichnung Privates Unternehmen.Kontaktangaben.Name_der_Kontaktperson:Bezeichnung Privates Unternehmen.Kontaktangaben.Faxnummer:Nummer Privates Unternehmen.Kontaktangaben.Internet-Adresse:Nummer Privates Unternehmen.Kontaktangaben.Telefonnummer:Nummer Privates Unternehmen.Kontaktangaben.Telexnummer:Nummer Privates Unternehmen.Kontaktangaben.X400-Adresse:Nummer Industrieunternehmen.Abteilung-Versandstelle.Ladestelle:Bezeichnung (die folgenden Label ebenso für Abteilung-Buchhaltung, Abteilung-Einkaufsabteilung, Abteilung-Versandstelle) Industrieunternehmen.Abteilung-Verkaufsabteilung.Identifizierung:ID Industrieunternehmen.Abteilung-Verkaufsabteilung.Name:Bezeichnung Industrieunternehmen.Abteilung-Verkaufsabteilung.Kontaktangaben. Name_der_Kontaktperson:Bezeichnung Industrieunternehmen.Abteilung-Verkaufsabteilung.Kontaktangaben.Faxnummer:Nummer Industrieunternehmen.Abteilung-Verkaufsabteilung.Kontaktangaben.Internet-Adresse:Nummer Industrieunternehmen.Abteilung-Verkaufsabteilung.Kontaktangaben.Telefonnummer:Nummer Industrieunternehmen.Abteilung-Verkaufsabteilung.Kontaktangaben.Telexnummer:Nummer
Abb. 5.12 Aus dem Referenzklassendiagramm für Klienten abgeleitete semantische Label
Aus dem in Abb. 5.10 gezeigten Referenzklassendiagramm für Klienten ergeben sich die in
Abb. 5.12 aufgeführten semantischen Label. Aus jedem Label werden Nachrichtenbausteine
ermittelt, indem die vorstehende Klienten-Referenzklasse durch sämtliche Klientenrollen
181
ersetzt wird. Beispielsweise werden aus dem Label Klient.Name:Bezeichnung die
Nachrichtenbausteine Käufer.Name:Bezeichnung, Verkäufer.Name:Bezeichnung,
Auftraggeber.Name:Bezeichnung, Auftragnehmer.Name:Bezeichnung, etc. gebildet.
5.2 Anwendung von MOVE
5.2.1 Das AllBuy-Szenario
Der praktische Einsatz der in Kapitel 4 vorgestellten Modellierungsmethode MOVE soll im
vorliegenden Kapitel anhand eines umfassenden Fallbeispiels veranschaulicht werden. Dazu
wird auf das bereits in den vorhergehenden Kapiteln herangezogene AllBuy-Szenario (vgl.
Abschnitte 3.3.3.1 und 4.4.1) zurückgegriffen. Während bisher nur einzelne Aspekte am
AllBuy-Beispiel erläutert worden sind, soll nun umfassend die modellgestützte Integration
zwischenbetrieblicher Informationsflüsse am Fallbeispiel veranschaulicht werden.
Das AllBuy-Szenario basiert auf den eingangs dieses Kapitels erwähnten Interviews, die in
Zusammenarbeit mit dem Europäischen Handelsinstitut (EHI) in Handelsunternehmen
durchgeführt worden sind.
Die Situation des Lebensmittelhandelsbetriebes AllBuy stellt sich wie folgt dar: Die AllBuy
GmbH ist im Kölner Raum ansässig und besitzt etwa 200 Filialen in drei Größenklassen
(Supermarkt, Verbrauchermarkt, SB-Warenhaus). Die Wertschöpfungskette verläuft von
Zulieferungsbetrieben über Hersteller zur Zentrale der AllBuy GmbH und von dort oder direkt
in die AllBuy-Filialen. Der Ablauf der Transaktionen wird in den nachfolgenden Abschnitten
detailliert erläutert. Seit Monaten erleidet die AllBuy GmbH Umsatz- und Ertragseinbrüche.
Es wird angenommen, dass im Vorfeld Problemfelder identifiziert wurden, die es zu unter-
suchen gilt:
• Ungenaue, fehlende, langsame Kommunikation zwischen den Betrieben.
• Die Konkurrenz reagiert flexibler auf die Kunden, sie „kennt ihre Kunden besser“.
• Mangelhafte Logistik: Über- und Unterbestände treten häufig in den AllBuy-Filialen auf.
Der abverkaufsnahen Belieferung der Filialen und damit der Kunden kommt eine hohe
Bedeutung zu. Mögliche Lösungsansätze können wie folgt skizziert werden:
• Logistik reorganisieren, z. B. eine Belieferung der Kunden direkt vor die Haustür;
• Andere bzw. mehr Informationen in der Wertschöpfungskette austauschen (z. B.
Abverkaufsinformationen);
182
• Neue Kanäle verwenden, z. B. elektronische Abwicklung und Integration der zwischen-
betrieblichen Informationsflüsse
Auf eine Vertiefung der verschiedenen Lösungsalternativen soll im Weiteren verzichtet
werden. Es wird unterstellt, dass mit Hilfe des im Rahmen des Forschungsprojektes MOVE
erarbeiteten Simulations- und Nutzwertmodells (vgl. Abschnitt 4.1.1) die Integration der
zwischenbetrieblichen Informationsflüsse als geeignetste Maßnahme identifiziert wurde. Der
bislang papierzentrierte Austausch von Informationen im Wertschöpfungsfluss soll nun
weitgehend elektronisch erfolgen. In den nachfolgenden Abschnitten wird erläutert, wie die
zwischenbetrieblichen Informationsflüsse mit der Modellierungsmethode MOVE entworfen
werden. Da dies aus Sicht des AllBuy-Unternehmens geschieht, erfolgt zwangsläufig eine
Beschränkung auf den Ausschnitt der Wertschöpfungskette, an dem die AllBuy GmbH
beteiligt ist.
5.2.2 Transaktionsdiagramme
Schritt 1 - Identifizieren von Transaktionsmustern
Die Transaktionen der AllBuy GmbH werden nach drei verschiedenen Mustern abgewickelt
(vgl. Tab. 5-8). Den größten Anteil haben Lagergeschäfte (etwa 65 % des Sortimentes), bei
der die AllBuy-Zentrale beim Hersteller bestellt und die Ware an das Zentrallager geliefert
wird. Von dort erfolgt die Verteilung auf die Filialen. Nach diesem Muster werden die
Sortimentsbereiche Obst und Gemüse, Fisch, Fleisch sowie ein Großteil des
Trockensortiments abgewickelt. Die restlichen Transaktionen laufen nach dem Muster des
Streckengeschäfts ab, wobei sich die Varianten Zentralstrecke und Filialstrecke unterscheiden
lassen. Im ersten Fall werden die Waren weiterhin von der Zentrale beim Hersteller bestellt
(durch Rahmenaufträge und Lieferabrufe oder durch Lieferpläne), aber direkt an die Filialen
geliefert. Dies trifft für die Sortimentsbereiche Brot- und Backwaren, Molkereiprodukte und
Mehrweggetränke zu. Im Fall der Filialstrecke ordern die Filialen grundsätzlich per
Lieferabruf direkt beim Hersteller und werden von diesem auch direkt beliefert. Nach diesem
Muster werden Gewürze, Textilien, Tonträger und Kleinhaushaltsartikel abgewickelt.
183
Transaktionsmuster Sortiment Anteil Lagergeschäft Zentrale bestellt beim Hersteller,
Hersteller liefert an Zentrale • Obst + Gemüse • Fisch • Fleisch • Trockensortiment
65 %
Zentralstrecken- geschäft
Zentrale bestellt beim Hersteller, Hersteller liefert an Filiale
• Brot/Backwaren • Molkereiprodukte • Mehrweggetränke
20 %
Filialstrecken- geschäft
Filiale bestellt beim Hersteller, Hersteller liefert an Filiale
• Gewürze • Textilien • Tonträger • Kleinhaushaltswa
ren
15 %
Tab. 5-8 Transaktionsmuster im AllBuy-Szenario
Für jedes Transaktionsmuster - Lagergeschäft, Zentralstrecke, Filialstrecke - ist ein eigenes
Diagramm vorzusehen. Nachfolgende Modellierungsschritte sind daher für alle drei Trans-
aktionsdiagramme durchzuführen.
Lagergeschäfte im AllBuy-Szenario
Schritt 2 - Analyse des Leistungsflusses (Lagergeschäft)
Der Leistungsfluss erfolgt vom Hersteller (Rolle Leistungssender) zur AllBuy-Zentrale (Rolle
Leistungsempfänger). Da es sich um materielle Leistungen in Form von Waren handelt, wird
der Interaktion die ontologische Klasse liefern zugeordnet. Bei den Herstellern bzw.
Lieferanten kann es sich um Großhandelsunternehmen (Obst und Gemüse, Fisch),
Schlachthöfe (Fleisch) oder industrielle Fertigungsunternehmen (Trockensortiment) handeln.
Daher wird dem Hersteller die übergeordnete ontologische Klasse bzw. Referenzklasse
Privates Unternehmen zugeordnet. Bei der AllBuy-Zentrale handelt es sich um eine
Großhandelszentrale.
Schritt 3 - Analyse des Zahlungsflusses (Lagergeschäft)
Der Zahlungsfluss erfolgt von der AllBuy-Zentrale (Rolle Zahlungssender) zum Hersteller
(Rolle Zahlungsempfänger). Zahlungsinteraktionen erhalten grundsätzlich eine Zuordnung zur
ontologischen Klasse zahlen.
Schritt 4 - Analyse der Informationsflüsse (Lagergeschäft)
In der Vereinbarungsphase erfolgt die Beauftragung des Herstellers (Rolle Auftragnehmer) durch die AllBuy-Zentrale (Rolle Auftraggeber) über Rahmenaufträge oder Einzelbestel-
184
lungen. Es handelt sich um eine initialisierende Interaktion, die der ontologischen Klasse beauftragen zuzuordnen ist. Im Falle von Rahmenaufträgen werden die Waren letztendlich durch leistungssteuernde Lieferabrufe zu bestimmten Terminen angefordert (ontologische Klasse Leistungen anfordern). Nicht immer, aber in vielen Fällen avisiert der Hersteller die Warenlieferung durch eine Liefermitteilung. Hierbei handelt es sich ebenfalls um eine leistungssteuernde Interaktion, die der ontologischen Klasse Leistung avisieren zuzuordnen ist. Durch Rechnungen vom Hersteller (Rolle Rechnungsteller) werden Zahlungen von der AllBuy-Zentrale (Rolle Rechnungsempfänger) angefordert. Diese zahlungssteuernde Inter-aktion ist daher der ontologischen Klasse Zahlungen anfordern zuzuordnen.
Informationsinteraktion Ontologische Klasse
Phase Zweck
Auftrag senden Beauftragen Vereinbarung Initialisierend Waren abrufen Leistungen
anfordern Durchführung Leistungssteuernd
Lieferung mitteilen Leistungen avisieren Durchführung Leistungssteuernd Rechnung senden Zahlungen anfordern Durchführung Zahlungssteuernd Tab. 5-9 Informationsinteraktionen bei Lagergeschäften im AllBuy-Szenario
Die Analyse des Leistungs-, Zahlungs- und Informationsflusses ergab, dass nur zwei Klienten,
nämlich die AllBuy-Zentrale und der Hersteller, an der Transaktion beteiligt sind. Ihre Rollen
können daher in aggregierter Form als Käufer (KF) und Verkäufer (VK) dargestellt werden.
Schritt 5 - Ableiten sekundärer Transaktionen (Lagergeschäft) Die Waren werden bei einem Lagergeschäft grundsätzlich durch eigene LKW der Hersteller oder durch Speditionen, die vom Hersteller beauftragt werden, befördert. Somit sind aus Sicht der AllBuy GmbH keine weiteren sekundären Transaktionen erforderlich.
Das aus den erläuterten Modellierungsschritten resultierende Transaktionsdiagramm zeigt
Abb. 5.13.
AllBuy-ZentraleKF
HerstellerVK
V: Auftrag senden (beauftragen)
D: Rechnung senden (Zahlung anfordern)
D: Waren bezahlen (zahlen)
D: Waren liefern (liefern)
D: Lieferung mitteilen (Leistungen avisieren)
D: Waren abrufen (Leistungen anfordern)opt.
Privates UnternehmenGroßhandelszentrale
opt.
Abb. 5.13 Transaktionsdiagramm zu Lagergeschäften im AllBuy-Szenario
185
Zentralstreckengeschäfte im AllBuy-Szenario419
Schritt 2 - Analyse des Leistungsflusses (Zentralstreckengeschäft)
Im Gegensatz zum Lagergeschäft erfolgt die Warenlieferung beim Zentralstreckengeschäft
vom Hersteller (Rolle Leistungssender) direkt an die AllBuy-Filialen (Rolle Leistungs-
empfänger). Bei den Waren handelt es sich ausschließlich um industrielle Produkte, so dass
die Hersteller im Transaktionsdiagramm zu Zentralstreckengeschäften der ontologischen
Klasse Industrieunternehmen zugeordnet werden können. Bei den AllBuy-Filialen handelt es
sich um Einzelhandelsfilialen; sie werden der entsprechenden ontologischen Klasse
zugeordnet.
Schritt 3 - Analyse des Zahlungsflusses (Zentralstreckengeschäft)
Der Zahlungsfluss erfolgt wie zuvor bei Lagergeschäften von der AllBuy-Zentrale (Rolle
Zahlungssender) zum Hersteller (Rolle Zahlungsempfänger).
Schritt 4 - Analyse der Informationsflüsse (Zentralstreckengeschäft)
Prinzipiell tauchen die gleichen Informationsinteraktionen wie beim Lagergeschäft auf, mit
dem Unterschied, dass grundsätzlich Liefermitteilungen an die AllBuy-Filialen gerichtet
werden. Zusätzlich erfolgt eine Wareneingangsmeldung von den AllBuy-Filialen an die
AllBuy-Zentrale über die tatsächlich gelieferten Waren. Diese dokumentierende Interaktion
lässt sich der ontologischen Klasse Leistungen dokumentieren zuordnen.
Schritt 5 - Ableiten sekundärer Transaktionen (Zentralstreckengeschäft)
Auch beim Zentralstreckengeschäft fallen keine weiteren sekundären Transaktionen an.
Abb. 5.14 zeigt das resultierende Transaktionsdiagramm zu Zentralstreckengeschäften im
AllBuy-Szenario.
419 Die Erläuterung der Zuordnung zu ontologischen Klassen erfolgt nur dann, wenn sie sich vom Lagergeschäft unterscheidet.
186
AllBuy-Filiale
Einzelhandelsfiliale
LE
AllBuy-Zentrale
Großhandelszentrale
AGREZS
HerstellerANRSLSZE
Industrieunternehmen
D: Waren abrufen (Leistungen anfordern)opt.
V: Auftrag senden (beauftragen)
D: Rechnung senden (Zahlung anfordern)
D: Waren bezahlen (zahlen)
D: Waren liefern (liefern)
D: Lieferung mitteilen (Leistungen avisieren)
D: Wareneingang melden(Leistungen dokumentieren)
Abb. 5.14 Transaktionsdiagramm zu Zentralstreckengeschäften im AllBuy-Szenario
Filialstreckengeschäfte im AllBuy-Szenario
Schritte 2 bis 5 (Filialstreckengeschäft)
Der einzige Unterschied zwischen dem Filialstreckengeschäft und dem
Zentralstreckengeschäft besteht darin, dass die Waren direkt von den AllBuy-Filialen beim
Hersteller abgerufen werden. Die Beauftragung erfolgt dabei grundsätzlich durch
Rahmenaufträge und nicht durch Lieferpläne von der AllBuy-Zentrale an den Hersteller. Das
Transaktionsdiagramm für Filialstreckengeschäfte zeigt Abb. 5.15.
AllBuy-Filiale
Einzelhandelsfiliale
LE
AllBuy-Zentrale
Großhandelszentrale
AGREZS
HerstellerANRSLSZE
Industrieunternehmen
D: Waren abrufen (Leistungen anfordern)
V: Auftrag senden (beauftragen)
D: Rechnung senden (Zahlung anfordern)
D: Waren bezahlen (zahlen)
D: Waren liefern (liefern)
D: Lieferung mitteilen (Leistungen avisieren)
D: Wareneingang melden(Leistungen dokumentieren)
Abb. 5.15 Transaktionsdiagramm zu Filialstreckengeschäften im AllBuy-Szenario
187
5.2.3 Interaktionsdiagramme
Im nächsten Schritt ist zu jeder Interaktion in einem Transaktionsdiagramm ein
Interaktionsdiagramm zu erstellen. Dieses wird im weiteren Verlauf des Kapitels am Beispiel
der Zentralstreckengeschäfte für die auftretenden Informationsinteraktionen ausgeführt.
Schritt 1 - Übernehmen der Klienten und der Interaktion aus dem Transaktionsdiagramm
Das Transaktionsdiagramm zu den Zentralstreckengeschäften enthält fünf
Informationsinteraktionen. In jedes zugehörige Interaktionsdiagramm werden zunächst die
beteiligten Klienten, d. h. die AllBuy-Zentrale oder -Filiale und der Hersteller, sowie die
Interaktion selbst übernommen. Die für eine bestimmte Interaktion zutreffende Klientenrolle
wird im entsprechenden Interaktionsdiagramm fett dargestellt. Beispielsweise handelt die
AllBuy-Zentrale bei der Interaktion Auftrag senden als Auftraggeber und der Hersteller als
Auftragnehmer.
Schritt 2 - Alternative Ausführungen der darzustellenden Interaktion analysieren
Für jede Interaktion sind die alternativ möglichen Objekttypen, d. h. die einem
Informationsobjekt zugeordneten ontologischen Klassen und die Objektrollen zu bestimmen.
Zu jeder Variante ist im weiteren der Kanal, das sendende bzw. empfangende
Anwendungssystem, die erzeugende bzw. verarbeitende Funktion dieses Anwendungssystem
sowie das Auslöse-Ereignis festzulegen. Für die Analyse der alternativen Ausführungen eignet
sich eine Tabellenform, wie sie in Tab. 5-10 dargestellt ist.
Interaktion Objekttyp Objektrolle Kanal AWS Funktion Ereignis Bestellung Rahmenauftrag Internet WaWi Bestellung anlegen Manuell Auftrag
senden Bestellung Lieferplan Internet WaWi Bestellung anlegen Getriggert Waren abrufen
Lieferabruf Lieferabruf Internet WaWi Lieferabruf anlegen Zeitgesteuert
Lieferung mitteilen
Warenlieferschein Lieferavis Internet WaWi Eingangslieferschein anlegen
Getriggert
Wareneingang melden
Warenlieferschein Wareneingangsmeldung VPN WaWi Eingangslieferschein anlegen bzw. Wareneingansmeldung anlegen
Getriggert
Einzelrechnung Rechnung EDI/VAN WaWi Rechnung anlegen Getriggert Rechnung senden Sammelrechnung Rechnung EDI/VAN WaWi Rechnung anlegen Getriggert
Tab. 5-10 Ausführungen der Informationsinteraktionen bei Zentralstreckengeschäften im AllBuy-Szenario
Für die Interaktion Auftrag senden können Informationsobjekte vom Typ Bestellung
eingesetzt werden, die die Rolle eines Rahmenauftrages oder eines Lieferplans einnehmen
(vgl. Abb. 5.16). In beiden Fällen werden die Informationsobjekte über das Internet gesendet.
Sowohl in den AllBuy-Filialen als auch in der Zentrale wird das von der AllBuy GmbH
188
eigenentwickelte Warenwirtschaftssystem WaWi eingesetzt, dessen Funktion Bestellung
anlegen die Informationsobjekte erzeugt. Während der Versand von Rahmenaufträgen
manuell veranlasst wird, erfolgt der Versand von Lieferplänen getriggert durch das WaWi-
System, sobald ein Lieferplan angelegt worden ist.
IndustrieunternehmenGroßhandelszentrale
AllBuy-ZentraleAGREZS
HerstellerANRSLSZE
V: Auftrag senden (beauftragen)
Variante 1
InternetBestellunganlegen
BestellungRahmenauftragWaWi
Variante 2
InternetBestellunganlegen
BestellungLieferplanWaWi
Abb. 5.16 Interaktionsdiagramm Auftrag senden
Erfolgt die Beauftragung des Herstellers durch einen Rahmenauftrag, so ist in diesen Fällen
die Interaktion Waren abrufen vorzusehen (vgl. Abb. 5.17). Hierfür wird ein Informations-
objekt vom Typ Lieferabruf mit gleichnamiger Rolle eingesetzt. Es wird von der Funktion
Lieferabruf anlegen des WaWi-Systems erzeugt. Die im Laufe eines Tages angelegten
Lieferabrufe werden gesammelt und an Wochentagen jeweils um 18:00 Uhr automatisiert an
die Hersteller versendet.
IndustrieunternehmenGroßhandelszentrale
AllBuy-ZentraleAGREZS
HerstellerANRSLSZE
D: Waren abrufen (Leistungen anfordern)
opt.
InternetLieferabrufanlegen
LieferabrufLieferabrufWaWi
Mo.-Fr., täglich,18:00 Uhr
Abb. 5.17 Interaktionsdiagramm Waren abrufen
189
Hersteller avisieren eine Warenlieferung bei den Filialen. Dieses erfolgt durch die vorab
Sendung des Warenlieferscheins (Objekttyp), der damit die Rolle eines Lieferavis übernimmt
(vgl. Abb. 5.18). Sobald ein Lieferavis ankommt, wird es automatisiert vom WaWi-System
von der Funktion Eingangslieferschein anlegen verarbeitet.
Industrieunternehmen Einzelhandelsfiliale
AllBuy-FilialeLE
HerstellerANRSLSZE
D: Lieferung mitteilen (Leistungen avisieren)
Internet
Waren-lieferscheinLieferavis
WaWiEingangs-
lieferscheinanlegen
Abb. 5.18 Interaktionsdiagramm Lieferung mitteilen
Zwischen AllBuy-Filiale und AllBuy-Zentrale erfolgt die Interaktion Wareneingang melden.
Hierbei wird ein Warenlieferschein (Objekttyp) über die tatsächlich vom Hersteller gelieferten
Waren übermittelt, der damit die Rolle einer Wareneingangsmeldung übernimmt (vgl.
Abb. 5.19). Ausgangspunkt ist die Funktion Wareneingangsmeldung anlegen des WaWi-
Systems in den AllBuy-Filialen. Verarbeitet werden die Nachrichten von der Funktion
Eingangslieferschein anlegen im WaWi-System der Zentrale.
GroßhandelszentraleEinzelhandelsfiliale
AllBuy-FilialeLE
AllBuy-ZentraleAGREZS
D: Wareneingang melden(Leistungen dokumentieren)
WarenlieferscheinWareneingangs-meldung
WaWi WaWi
VPNWE-meldunganlegen
Eingangs-lieferschein
anlegen
Abb. 5.19 Interaktionsdiagramm Wareneingang melden
Die Interaktion Rechnung senden kann nach zwei verschiedenen Varianten durchgeführt
werden (vgl. Abb. 5.20). Die beiden Varianten unterscheiden sich im Objekttyp des
eingesetzten Informationsobjekts (Einzel- oder Sammelrechnung). Objektrolle ist in beiden
Fällen
190
Rechnung. Rechnungen werden automatisiert vom WaWi-System der AllBuy-Zentrale
aufgenommen und dort von der Funktion Rechnung anlegen vor der Weiterverarbeitung
gespeichert.
Industrieunternehmen Großhandelszentrale
AllBuy-ZentraleAGREZS
HerstellerANRSLSZE
D: Rechnung senden (Zahlungen anfordern)
Variante 1
VAN
EinzelrechnungRechnung WaWi
Rechnunganlegen
Variante 2
VAN
Sammel-rechnungRechnung
WaWi
Rechnunganlegen
Abb. 5.20 Interaktionsdiagramm Rechnung senden
5.2.4 Sequenzdiagramme
Nachdem sämtliche Interaktionsdiagramme erstellt worden sind, können die möglichen zeit-
lichen Abläufe einer Transaktion durch Sequenzdiagramme veranschaulicht werden. Auch
dies soll am Transaktionsmuster des Zentralstreckengeschäfts erläutert werden.
Schritt 1 - Definieren der möglichen Sequenzen durch Protokolle
Im ersten Schritt sind die möglichen Ablaufsequenzen durch Ausfüllen einer speziellen
Konfigurationstabelle, die bereits in Abschnitt 4.5.3 vorgestellt wurde, zu definieren. In dieser
Tabelle sind alle Interaktionen aufzuführen, die Varianten in der Ausführung zulassen oder
die optional durchgeführt werden. Dies trifft im Fall der Zentralstreckengeschäfte auf die
Interaktionen Auftrag senden, Waren abrufen sowie Rechnung senden zu. Jede Variante ist
durch den Typ und die Rolle des eingesetzten Objektes gekennzeichnet. Mögliche Sequenzen
werden durch die Kombination der verschiedenen Varianten ermittelt. In die
Konfigurationstabelle sind allerdings nur gültige Kombinationen aufzunehmen.
Im Beispiel sind drei unterschiedliche Sequenzen möglich (vgl. Tab. 4-11). In den ersten
beiden Fällen ist ein Rahmenauftrag vorgesehen. Der Anstoß der Warenlieferung erfolgt dann
jeweils durch Lieferabrufe. Bei sporadischen Abrufen erfolgt die Abrechnung über
191
Einzelrechnungen, während für häufige, mitunter tägliche Abrufe vom Hersteller eine
Sammelrechnung ausgestellt wird. Im Falle der Beauftragung durch Lieferpläne erfolgt
grundsätzlich die Abrechnung über Einzelrechnungen je Lieferung.
Gültige Sequenzen Interaktion Objekt (Typ/Rolle) 1 2 3
Bestellung/ Rahmenauftrag X X - Auftrag senden Bestellung/ Lieferplan - - X
Waren abrufen Lieferabruf/ Lieferabruf X X - Einzelrechnung/ Rechnung - X X Rechnung senden Sammelrechnung/ Rechnung X - -
Tab. 5-11 Konfigurationstabelle zu Zentralstreckengeschäften im AllBuy-Szenario
Schritt 2 - Interaktionen zeitlich ordnen
Bei umfangreichen Sequenzen sollte eine Ordnung nach vorgelagerten, begleitenden und
nachgelagerten Interaktionen bezüglich der zugrunde liegenden Leistungsinteraktion erfolgen.
Obwohl dies im vorliegenden Beispiel nicht erforderlich erscheint, zeigt Tab. 5-12
beispielhaft, wie eine solche Tabelle aussehen könnte. Sie gilt in diesem Fall für alle
Sequenzen.
Zeitliche Ordnung Interaktion Vorgelagert Auftrag senden
Waren abrufen Lieferung mitteilen
Begleitend <Waren liefern> Rechnung senden
Nachgelagert Wareneingang melden Waren bezahlen
Tab. 5-12 Zeitliche Ordnung der Interaktionen im AllBuy-Szenario
Schritt 3 - Interaktionen in das Sequenzdiagramm übernehmen
Gemäß ihrer zeitlichen Folge sind die Interaktionen in das Sequenzdiagramm zu übertragen.
Gegebenenfalls sind Verknüpfungsregeln zwischen zwei Interaktionen anzugeben. So soll
innerhalb von 24 Stunden nach Eingang eines Lieferabrufes beim Hersteller eine Antwort in
Form eines Lieferavis erfolgen. Die Lieferavise sollen wiederum mindestens sechs Stunden
vor der Lieferung eintreffen, damit entsprechende Vorbereitungen in den Filialen getroffen
werden können. Wareneingangsmeldungen haben innerhalb einer Stunde nach Eintreffen der
Lieferung von der Filiale an die Zentrale zu erfolgen. Rechnungen sind innerhalb von 30
Tagen zu zahlen. Für die Sequenzen mit Rahmenauftrag ergeben sich daraus prinzipiell die
192
gleichen Diagramme (vgl. Abb. 5.21), die sich lediglich durch den Objekttyp bei der
Interaktion Rechnung senden unterscheiden.
AllBuy-Zentrale
Hersteller
AllBuy-Zentrale
Hersteller
AllBuy-Filiale
Auftrag senden(Bestellung/Rahmenauftrag)
Waren abrufen(Lieferabruf/Lieferabruf)
Lieferung mitteilen(Warenlieferschein/Lieferavis)
Waren liefern(Konsumgüter/Leistung)
Rechnung senden(Sammelrechnung/Rechnung)
AllBuy-Zentrale
Wareneingang melden(Warenlieferschein/Wareneingangsmeldung)
Hersteller
Waren bezahlen(Scheck/Zahlung)
vorgelagert
begleitend
nachgelagert
AllBuy-Filiale
Herstellermax24h
min6h
max1h
max30T.
Hersteller
AllBuy-Filiale
Waren liefern(Konsumgüter/Leistung)
Rechnung senden(Einzelrechnung/Rechnung)
AllBuy-Zentrale
Wareneingang melden(Warenlieferschein/Wareneingangsmeldung)
Hersteller
Waren bezahlen(Scheck/Zahlung)
begleitend
nachgelagert
AllBuy-Zentrale
Hersteller
AllBuy-Zentrale
Auftrag senden(Bestellung/Rahmenauftrag)
Lieferung mitteilen(Warenlieferschein/Lieferavis)
AllBuy-Filiale
Hersteller
Waren abrufen(Lieferabruf/Lieferabruf)
vorgelagert
max24h
min6h
max1h
max30T.
Abb. 5.21 Sequenzdiagramme zu den Sequenzen mit Rahmenauftrag
Das Diagramm zur Sequenz mit Lieferplan sieht etwas anders aus, da hierbei kein Warenabruf
erfolgt. Es ist in Abb. 5.22 dargestellt.
AllBuy-Zentrale
Hersteller
AllBuy-Filiale
Auftrag senden(Bestellung/Lieferplan)
Lieferung mitteilen(Warenlieferschein/Lieferavis)
Waren liefern(Konsumgüter/Leistung)
Rechnung senden(Einzelrechnung/Rechnung)
AllBuy-Zentrale
Wareneingang melden(Warenlieferschein/Wareneingangsmeldung)
Hersteller
Waren bezahlen(Scheck/Zahlung)
vorgelagert
begleitend
nachgelagert
Hersteller
AllBuy-Filiale
max24h
min6h
max1h
max30T.
Abb. 5.22 Sequenzdiagramm zur Sequenz mit Lieferplan
5.2.5 Nachrichtendiagramme
Mit den bislang erstellten Diagrammen wurden die zwischenbetrieblichen Transaktionen der
AllBuy GmbH als Modell konstruiert. Darauf aufbauend erfolgt nun die Modellierung der
Nachrichtenstrukturen. Dies soll für die Ausgangsverarbeitung von Nachrichten anhand der
Informationsobjekte Rahmenauftrag, Lieferplan und Lieferabruf sowie für die
Eingangsverarbeitung anhand der Informationsobjekte Einzel- und Sammelrechnung
verdeutlicht werden.
193
Schritt 1 - Analyse der Nachrichtenstruktur eines Informationsobjektes
Die Nachrichtenstruktur eines Informationsobjekts kann grundsätzlich in einen Kopfteil und
einen Positionsteil gegliedert werden. In einigen Fällen ist eine Positionseinteilung
erforderlich. Im vorliegenden Beispiel werden in einem Rahmenauftrag die Preis- und
Mengenbedingungen für mehrere Artikel festgelegt. Die Festlegung erfolgt für einen einzigen,
längerfristigen Zeitraum, der für alle Artikel gleich ist. Daher sind keine Positionseinteilungen
erforderlich. Ebenso gliedern sich die Lieferabrufe lediglich in einen Kopf- und einen
Positionsteil. Anders verhält es sich beim Lieferplan. Mit einem Lieferplan können die
Lieferterminwünsche für mehrere Artikel festgelegt werden. Zu einem Artikel können dabei
mehrere
Liefertermine angegeben werden. Damit gliedert sich ein Lieferplan in Lieferplankopf,
Lieferplanposition und Lieferplanpositionseinteilung.
Schritt 2 - Analyse der Nachrichteninhalte eines Informationsobjektes
Am Beispiel des Lieferabrufs soll dieser Schritt ausführlich erläutert werden. Abb. 5.23 zeigt
einen papierbasierten Lieferabruf aus dem AllBuy-Szenario.
Kd.-Nr. 4711
Lieferadresse: Filiale AllBuy Köln-Kalk Paderborner Str. 110 50102 Köln
Abrufdatum: 12.09.97 Abruf-Nr. 32542
Betr. Rahmenvertrag-Nr. 1707 v. 16.05.97 Liefertermin 14.09.97
Pos 1 2 3
Art.-Nr. 1312 1414 2001
Artikelbezeichnung Aufbackbrötchen, 6er-Pack Brötchen, normal, rund, 40 g Rosinenbrot, 750 g
Menge20
2005
Abb. 5.23 Papierbasierter Lieferabruf aus dem AllBuy-Szenario
Atomare Elemente des abgebildeten Lieferabrufs sind z. B. „Abrufdatum 12.09.97“,
„Rahmenvertrag-Nr. 1707“ oder „Paderborner Str. 110“. Die Bezeichnungen der dazu
passenden Nachrichtenbausteine können wie folgt aus der Referenzbibliothek entnommen
werden: für jedes atomare Element ist zu überlegen, welchem Modellierungselement im
194
Interaktionsdiagramm es zugeordnet werden kann. So ist z. B. „Paderborner Str.“ eine
Eigenschaft der AllBuy-Filiale.
Über die Verknüpfung mit der Referenzklasse Einzelhandelsfiliale wird das entsprechende
Attribut Anschrift.StraßeHausnummer:Bezeichnung ermittelt. Die Rolle der AllBuy-Filiale
bestimmt die vollständige Bezeichnung des gesuchten Nachrichtenbausteins:
Leistungsempfänger.Anschrift.StraßeHausnummer:Bezeichnung. Der Nachrichtenbaustein
wird als Nachrichtenelement im Nachrichtendiagramm übernommen. Nach der erläuterten
Vorgehensweise können zur Beschreibung des Lieferabrufs die weiteren erforderlichen
Nachrichtenbausteine gefunden werden.
Einige Nachrichtenelemente beziehen sich auf den gesamten Abruf, während andere Elemente
die Abrufpositionen betreffen (vgl. Tab. 5-13 und Tab. 5-14). Während es zu den zuerst
genannten Elementen im vorliegenden Lieferabruf nur eine Ausprägung gibt (z. B. „12.09.97“
für das Nachrichtenelement Lieferabruf.Erstellt:Zeitpunkt), existieren zu den letzteren
Elementen mehrere Ausprägungen (z. B. „20“, „200“ und „5“ für das Nachrichtenelement
Lieferung.Artikel.MengeGefordert:Menge). Um Gültigkeitsbereiche von
Nachrichtenelementen festlegen zu können, werden die Nachrichtencontainer verwendet. Sie
verdeutlichen die hierarchische Struktur eines Informationsobjektes. Im Beispiel des
Lieferabrufs ist der Nachrichtencontainer Lieferabrufposition zu verwenden.
Nachrichtencontainer können neben Elementen wiederum weitere Nachrichtencontainer
enthalten.
Nachrichtenelement Ausprägung Name des Bestellers Filiale AllBuy Köln-Kalk Bestelldatum 12.09.97 Gefordertes Lieferdatum 14.09.97 ... ... Tab. 5-13 Nachrichtenelemente mit Bezug auf den gesamten Lieferabruf
Nachrichtenelement Ausprägung Lieferabrufposition 1 2 3 Artikelnummer 1312 1414 2001 Artikelbezeichnung Aufbackbrötchen,
6er Brötchen, normal, ... Rosinenbrot, 750 g
Bestellmenge 20 200 5 Tab. 5-14 Nachrichtenelemente mit Bezug auf die einzelnen Lieferabrufpositionen
195
Das vollständige Nachrichtendiagramm des Lieferabrufs zeigt Abb. 5.25. Auf die gleiche Weise lassen sich die Nachrichtenstrukturen für die Informationsobjekte Rahmenauftrag und Lieferplan (vgl. Abb. 5.25) sowie Einzel- und Sammelrechnung (vgl. Abb. 5.26) ableiten und beschreiben.
LieferabrufLieferabruf.Erstellt:ZeitpunktLieferabruf.ID_LE:IDLeistungsempfänger.Name:BezeichnungLeistungsempfänger.Anschrift.StraßeHausnummer:BezeichnungLeistungsempfänger.Anschrift.Postleitzahl:NummerLeistungsempfänger.Anschrift.Ort:BezeichnungLeistungsempfänger.ID_VK:IDRahmenauftrag.ID_AG:IDRahmenauftrag.Erstellt:ZeitpunktLiefern.Gefordert:Zeitpunkt
LieferabrufpositionLieferabrufposition.Positionsnummer:NummerLieferung.Artikel.ID_VK:IDLieferung.Artikel.Name:BezeichnungLieferung.Artikel.MengeGefordert:Menge
Abb. 5.24 Nachrichtendiagramm zum Informationsobjekt Lieferabruf
RahmenauftragRahmenauftrag.ID_AG:IDRahmenauftrag.Erstellt:ZeitpunktRahmenauftrag.GültigAb:ZeitpunktRahmenauftrag.GültigBis:ZeitpunktAuftraggeber.ID_VK:IDAuftragnehmer.ID_KF:ID
RahmenauftragspositionRahmenauftragposition.Positionsnummer:NummerLieferung.Artikel.ID_VK:IDLieferung.Artikel.PreisNettoVK_KF:PreisLieferung.Artikel.MengeRahmenauftrag:Menge
Lieferplan
Lieferplanposition
Lieferplanpositionseinteilung
Lieferplan.Erstellt:ZeitpunktLieferplan.ID_AG:IDAuftraggeber.ID_VK:IDAuftragnehmer.ID_KF:IDLeistungsempfänger.ID_VK:ID
Lieferplanposition.Positionsnummer:NummerLieferung.Artikel.ID_VK:IDLieferung.Artikel.Name:Bezeichnung
Lieferplanpositionseinteilung.Positionsnummer:NummerLieferung.Artikel.MengeGefordert:MengeLiefern.Gefordert:Zeitpunkt
Abb. 5.25 Nachrichtendiagramme zu den Informationsobjekten Rahmenauftrag und Lieferplan
RechnungRechnung.Erstellt:ZeitpunktRechnung.ID_RS:IDRechnungsempfänger.Name:BezeichnungRechnungssteller.Name:BezeichnungLeistungsempfänger.Name:BezeichnungRechnungsempfänger.ID_RS:IDRechnungssteller.ID_RE:IDLeistungsempfänger.ID_AG:IDLieferavis.Erstellt:ZeitpunktLieferavis.ID_WS:IDRechnung.Summenangaben.GesamtOhneMWSt:BetragRechnung.Summenangaben.GesamtMitMWSt:BetragRechnung.Summenangaben.MWStVoll:BetragRechnung.Summenangaben.MWStSatzVoll:Rate
RechnungspositionRechnungsposition.Positionsnummer:NummerLieferung.Artikel.ID_VK:IDLieferung.Artikel.Name:BezeichnungLieferung.Artikel.MengeGeliefert:MengeLieferung.Artikel.Preisangaben.OhneMWSt:Preis
RechnungRechnung.Erstellt:ZeitpunktRechnung.ID_RS:IDRechnungsempfänger.Name:BezeichnungRechnungssteller.Name:BezeichnungLeistungsempfänger.Name:BezeichnungRechnungsempfänger.ID_RS:IDRechnungssteller.ID_RE:IDLeistungsempfänger.ID_AG:IDRechnung.Summenangaben.GesamtOhneMWSt:BetragRechnung.Summenangaben.GesamtMitMWSt:BetragRechnung.Summenangaben.MWStVoll:BetragRechnung.Summenangaben.MWStSatzVoll:Rate
RechnungspositionRechnungsposition.Positionsnummer:NummerLieferavis.ID_WS:IDLieferavis.Erstellt:ZeitpunktRechnungsposition.PositionsbetragOhneMWSt:Betrag
RechnungsunterpositionRechnungsunterposition.Positionsnummer:NummerLieferung.Artikel.ID_VK:IDLieferung.Artikel.Name:BezeichnungLieferung.Artikel.MengeGeliefert:MengeLieferung.Artikel.Preisangaben.OhneMWSt:PreisRechnungsunterposition.PositionsbetragOhneMWSt:Betrag
Abb. 5.26 Nachrichtendiagramme zu den Informationsobjekten Einzel- und Sammelrechnung
196
Exkurs
Ein Vergleich des Papierdokument aus Abb. 5.23 mit dem Nachrichtendiagramm zum
Lieferabruf (Abb. 5.24) führt zu der Feststellung, das zehn Elementen des Belegkopfes und
vier Elementen des Positionsteils genau zehn bzw. vier Nachrichtenelemente im
Nachrichtendiagramm gegenüberstehen. Hier liegt ein deutlicher Unterschied zum Ansatz der
EDIFACT-Vorschrift. Ein einzelnes Element in der ursprünglichen Nachricht entspricht nach
der Überführung in das EDIFACT-Format in der Regel mehr als einem Datenelement. Der
Exkurs soll den grundsätzlichen Unterschied zwischen der vorgestellten Methode zur
Spezifikation von Nachrichten mittels Nachrichtenbausteinen bzw. -elementen und der
UN/EDIFACT-Vorgehensweise verdeutlichen.
Bei der Bildung von atomaren Elementen können zwei Prinzipien unterschieden werden:
entweder erhalten sie eine spezifische, kasuistische Bedeutung oder eine generische, noch zu
qualifizierende Bedeutung.420 Elemente, die speziell für ein bestimmtes Objekt oder eine
Objekteigenschaft der Realwelt definiert worden sind, haben eine spezifische, kasuistische
Bedeutung. Dies gilt für die bei MOVE verwendeten Nachrichtenbausteine, wie z. B.
Rechnung.Erstellt:Zeitpunkt oder Käufer.Name:Bezeichnung. Die meisten Elemente des
EDIFACT-Standards - dort Datenelemente genannt - haben dagegen eine generische
Bedeutung. Die für einen Anwendungsfall kasuistische Bedeutung erhält ein solches
Datenelement erst durch weitere Datenelemente, sogenannte Qualifier. So bekommt das
Datenelement Name des Geschäftspartners421 erst durch das Datenelement Geschäftspartner-
Qualifier422 seine spezifische Bedeutung, z. B. als Name des Käufers, Name des Spediteurs,
Name des Leistungsempfängers etc. (vgl. erste Zeile in Tab. 5-15).423 Die letzte Zeile in Tab.
5-15 zeigt ein Beispiel, bei dem die Bedeutung des Nachrichtenbausteins Käufer.Einkaufs-
abteilung.Kontaktangabe:Telefon:Nummer auf vier Datenelemente des EDIFACT-Nach-
richtentyps ORDERS verteilt ist.424 Weitere Beispiele sind ebenfalls der Tab. 5-15 zu
entnehmen.
420 Vgl. Henkel (Gestaltung 1996), S. 102ff. 421 EDIFACT data element 3036 - „Party Name“ 422 EDIFACT data element 3035 - „Party Qualifier“ 423 Vgl. Henkel (Gestaltung 1996), S. 102 424 In Anlehnung an Steel (Case 1995), S. 7f.
197
Datenelement MOVE-Nachrichtenbaustein EDIFACT-Datenelemente Name des Auftraggebers
Auftraggeber.Name: Bezeichnung
• NAD+3035/„BY“ • NAD+C080:3036
Straße des Auftraggebers
Auftraggeber. Anschrift. StraßeHausnummer:Bezeichnung
• NAD+3035/„BY“ • NAD+C059:3042
Kundennummer des Auftraggebers bei seinem Lieferanten
Auftraggeber.ID_AN:ID • RFF+C056:1153/„CR“ • RFF+C056:1154
Artikelnummer des Lieferanten
Lieferung.Artikel.ID_AN:ID • PIA+4347/„5“ • PIA+C212:7140 • PIA+C212:7143/„SA“
Telefonnummer der Einkaufs-abteilung des Käufers
Käufer.Einkaufsabteilung. Kontaktangabe:Telefon:Nummer
• NAD+3035/“BY“ • NAD+CTA+3139/“OC“ • NAD+CTA+COM+C076:3135/“TE“ • NAD+CTA+COM+C076:3148
Tab. 5-15 MOVE-Nachrichtenbausteine versus EDIFACT-Datenelemente
Elemente mit kasuistischer Bedeutung sind einfacher zu verstehen und führen bei der
Konvertierung einer Nachricht von einem Format in ein anderes zu einfachen
Umsetzungsregeln. Jedes Element der eingehenden Nachricht entspricht in der Regel genau
einem Element der Inhouseschnittstelle, und dies gilt umgekehrt auch für ausgehende
Nachrichten. Der Nachteil generischer Semantik ist, dass die Bedeutung nicht durch ein
einziges, sondern durch mindestens zwei Elemente abgebildet wird. Eine eindeutige
Interpretation kann nur in Abhängigkeit des Qualifierwertes erfolgen. Dies bedeutet für die
Sende- und Empfangsfunktionen, dass die Zuordnung zwischen internem und externem
Datenformat nicht mehr durch einfache ‘Move-Befehle’ oder Zuweisungen, sondern
fallabhängig durch ‘Case-Anweisungen’ realisiert werden muss.425 Dies ist ein Grund, warum
EDIFACT-Lösungen als ‘zu kompliziert’ beurteilt werden.
Der Vorteil der generischen Definition von Elementen ist allerdings, dass die Anzahl der
benötigten Elemente auch bei Ausweitung des Anwendungsbereiches überschaubar bleibt.
Angenommen, es werden zur Beschreibung eines Klienten sechs Attribute bzw. Elemente
benötigt: Identifizierungsnummer, Name, Straße, PLZ, Ort, Land. Mit jeder neuen
Anwendung muß ein neuer Klient adressiert werden können, z. B. Käufer, Versicherer,
Spediteur, Bank des Käufers, etc. Bei Einsatz spezifischer Regeln müssen mit jeder neuen
425 Vgl. Henkel (Gestaltung 1996), S. 104
198
Anwendung jeweils sechs neue Elemente definiert werden. Verwendet man generische
Regeln, so reichen insgesamt sieben Elemente aus: sechs beschreibende (entsprechend den
Attributen) und ein qualifizierendes Element. Letzteres bestimmt die einzelne
Objekttypausprägung, z. B. Käufer, Versicherer, etc. Lediglich der Wertebereich für die
Belegung dieses Elementes ist mit jeder neuen Anwendung zu ergänzen.426
Der vorgestellt MOVE-Ansatz nutzt die Vorteile beider Prinzipien. Für die Beschreibung von
Informationsobjekten werden kasuistische Nachrichtenbausteine mit dem Vorzug der
einfachen Verarbeitungsregeln verwendet. Die Nachrichtenbausteine werden allerdings aus
vorgelagerten Modellen unter Anwendung generischer Konzepte abgeleitet. Das
„Ausrechnen“ der Semantik erfolgt damit bereits vor der Definition der
Nachrichtenstrukturen. EDIFACT fehlt diese vorgelagerte Modellierung (vgl. Abb. 5.27).
Modellbasierte Definition(generische Konzepte)
“ausgerechnete”Semantik
kasuistischeNachrichtenelemente
kasuistischeNachrichtenelemente
Referenz-klassendiagramme +
InteraktionsdiagrammeNachrichten-
bausteineNachrichten-diagramme Informationsobjekt
+
generische Datenelemente generische Datenelemente
Subset-Definition Nachricht
MOVE-Ansatz
EDIFACT
Modellierung Nachrichtendefinition
Abb. 5.27 Nachrichtendefinition bei MOVE und EDIFACT
5.2.6 Regeldiagramme
Regeldiagramme dienen zur Spezifikation von Integritätsprüfungen für Nachrichtenelemente
eines Informationsobjektes. Die Prüfungen können auf mehreren Ebenen durchgeführt
werden: Element-, Nachrichten-, Transaktions- oder Geschäftsbeziehungsebene (vgl.
Abschnitt 3.3.3.2). Beispiele für solche Integritätsprüfungen und entsprechende
426 Vgl. Henkel (Gestaltung 1996), S. 103f.
199
Regeldiagramme sollen für einige Nachrichtenelemente einer Einzelrechnung aus dem
AllBuy-Szenario gezeigt werden (vgl. Tab. 5-16).
Nachrichtenelement Ebene Beispiel Rechnung.Summenangaben._ MwStVoll:Betrag
Element Überprüfen, ob gültiger MwSt-Betrag angegeben wurde; ggf. fehlenden Betrag aus MwSt-Satz und Nettobetrag errechnen.
Rechnung.Summenangaben._ GesamtOhneMwSt:Betrag und Rechnung.Summenangaben._ GesamtMitMwSt:Betrag
Nachricht Überprüfen, ob Rechnungssummen mit Summe der Rechnungspositionen übereinstimmt.
Lieferung.Artikel._ MengeGeliefert:Menge
Transaktion Überprüfen, ob berechnete Menge mit gelieferter Menge übereinstimmt.
Rechnung.Summenangaben._ GesamtMitMwSt:Betrag
Geschäfts-beziehung
Überprüfen, ob die Rechnungssumme außergewöhnlich hoch ist.
Tab. 5-16 Beispiele für Integritätsregeln auf den verschiedenen Ebenen
Zunächst soll das Nachrichtenelement Rechnung.Summenangaben.MwStVoll:Betrag auf
Elementebene überprüft werden.
Schritt 1 - Identifizieren der zentralen Prüfbedingung
Es ist zu überprüfen, ob überhaupt ein Wert für das Nachrichtenelement angegeben worden
ist.
Schritt 2 - Identifizieren der erforderlichen Vorbereitungsschritte
Für diese Überprüfung sind keine Vorbereitungsschritte erforderlich. Es wird einfach der Wert
des Nachrichtenelementes abgefragt.
Schritt 3 - Bestimmen der alternativen Aktionen bei positiven und negativen Ergebnis der
zentralen Prüfbedingung
Ist ein Mehrwertsteuerbetrag angegeben worden, so ist eine weitere Prüfung erforderlich.
Näheres dazu unter Schritt 4. Ist kein Wert vorhanden, so soll der fehlende Betrag aus dem
Mehrwertsteuersatz und dem Nettobetrag errechnet werden.
Schritt 4 - Bestimmen der weiteren erforderlichen Prüfungen. Ggf. weiter bei 2.
Wurde ein Mehrwertsteuerbetrag angegeben, so ist zu überprüfen, ob dieser korrekt ist. Der
angegebenen Betrag ist also mit dem korrekten Betrag zu vergleichen.
Schritt 2 (2. Iteration) - Identifizieren der erforderlichen Vorbereitungsschritte
Um diesen Vergleich durchführen zu können, ist zunächst der korrekte Betrag zu ermitteln. Er
kann aus dem Nettobetrag und dem Mehrwertsteuersatz errechnet werden.
200
Schritt 3 - Bestimmen der alternativen Aktionen bei positiven und negativen Ergebnis der
zentralen Prüfbedingung (2. Iteration)
Sind die beiden Mehrwertsteuerbeträge gleich, so ist der Überprüfung des Nachrichten-
elementes erfolgreich abzuschließen, andernfalls ist eine Fehlermeldung auszugeben.
Das Regeldiagramm zum erläuterten Beispiel zeigt Abb. 5.28.
PrüfenRechnung.Summenangaben._
MWStVoll:Betrag <> NULL FALSETRUE
Ermittelnx := Rechnung.Summenangaben.GesamtOhneMWSt:Betrag
* Rechnung.Summenangaben.MWStSatzVoll:Rate
Prüfenx = Rechnung.Summenangaben._
MWStVoll:Betrag ?
Status meldenAbbruch: Betrag fehlerhaft !
Status meldenErfolg: Betrag korrekt !
FALSETRUE
Ermittelnx := Rechnung.Summenangaben.GesamtOhneMWSt:Betrag
* Rechnung.Summenangaben.MWStSatzVoll:Rate
ZuweisenRechnung.Summenangaben.MWStVoll:Betrag:= x
Status meldenErfolg: Fehlenden Betrag ergänzt !
Abb. 5.28 Regeldiagramm zum Beispiel auf Elementebene
201
Auf ähnliche Weise lassen sich nach den angegebenen Schritten die Regeldiagramme für die
anderen Prüfbeispiele erstellen (vgl. Abb. 5.29).
Nachrichtenebene:
PrüfenErmittelte Summe der Positionen= Rechnung.Summenangaben._
GesamtOhneMWSt:Betrag ? FALSETRUE
Ermitteln:Summe über alle Rechnungspositionen von
Rechnungsposition.PositionsbetragOhneMWSt:Betrag
Status meldenAbbruch: Fehlerhafte Summe !
Status meldenErfolg: Summe korrekt !
Transaktionsebene:
PrüfenLieferung.Artikel.MengeGeliefert
(Rechnungsposition) =Lieferung.Artikel.MengeGeliefert
(Wareneingangsposition)? FALSETRUE
Zuordnen:Rechnungsposition zu Wareneingangsposition
Status meldenWarnung: Abweichende Menge !
Status meldenErfolg: Menge korrekt !
Geschäftsbeziehungsebene:
PrüfenRechnung.Summenangaben.GesamtMitMwSt:Betrag > 1,2 * x ?
FALSETRUE
Ermitteln:x = Durchschnittlicher Gesamtrechnungsbetrag der
letzten zwei Jahre
Status meldenErfolg: Rechnungsbetrag in
gewöhnlicher Höhe !
Status meldenWarnung: Rechnungsbetrag
ungewöhnlich hoch !
Abb. 5.29 Regeldiagramme zu den Beispielen auf Nachrichten-, Transaktions- und Geschäftsbeziehungsebene
5.3 Implementierung
In diesem Abschnitt soll eine mögliche Verwendung der mit MOVE erstellten Modelle in der
Implementierungsphase exemplarisch aufgezeigt werden.
Die Modellierung zwischenbetrieblicher Transaktionen und ihrer Informationsflüsse nach
MOVE erfolgt auf fachkonzeptueller Ebene und lässt mehrere Alternativen für die
Implementierung zu. So sind neben dem Einsatz traditioneller EDI-Technologien und -
Standardformate auch internetbasierte Lösungen unter Nutzung neuerer Technologien wie
XML oder Java denkbar. Für die dezentrale Modellierung ergeben sich daraus keine
prinzipiellen Unterschiede.
202
Im folgenden wird eine Implementierungsalternative vorgestellt (vgl. Abb. 5.30), die im
mehrfach erwähnten Forschungsprojekt MOVE entwickelt und prototypisch umgesetzt
worden ist.427
Entwurfs-phase
Betriebs-phase
Gro ßh ande ls-zen trale
AB C-Zent rale(Käuf er:
Auf tra gg eber,Re ch nu ngs-empf än ger,Za hl ungs-
sen de r)
2. ab rufe n ( D)
3. L ief eru ng mi ttei len (D)
4 . lie fer n ( D)
1. bea uf trag en (V )
5. fakturi ere n ( D)
6. W a ren ein gan g m el den (K )
Ein ze lhand el s-f ilia le
AB C-F ili ale(K äu fer:
Wa re nem pfä nger)
7. za hle n (D )
Industri e-unte rnehm en
M olkerei(V erkä uf er)
(Ein zel handelsfi l iale)
A llBuy-Filiale
(Waren emp fän ger )
(I ndustr ie-unt erne h me n)
Großbäcker
(Au ftragneh me r,Wa rense nd er,
Rec hnungsste ller ,Z ahlun g sem pfänge r )
(Ku rzau ft rag)Lieferabruf Backwaren
(Lie ferab ruf )
Internet
B ackwaren abrufen(ab rufen )
(Lie fermeld ung)Lieferavis Backw aren
(Lie fe ra vis)
Internet
B ackwaren avisieren(Lie ferun g m itte ilen)
Modellentwurf Nachrichten-diagramm
Großha nd els-ze nt ral e
A B C- Zentral e(K äu fe r:
Au ftragge be r,Rechnun gs -e mp fäng er ,Za hlu ng s-
se n der)
2 . a bru fen (D)
3 . Li efe run g m i tt eile n (D )
4. lief ern (D )
1 . b eau f tra ge n ( V)
5 . f akt uri e ren (D)
6 . W are ne ing ang m eld en (K)
Ei nzelh an dels-fil iale
A B C- F iliale(Käufe r:
Wa ren em p fän ge r)
7. z ah len (D)
In du st rie-u nt ern eh m en
M olke rei(V er kä ufe r)
(Ein zel handelsf il iale)
A llBuy-F iliale
(Waren emp fän ger )
(I ndustr ie-unt erne hme n )
Großbäcker
(Au ftragneh me r,W arens end er,
Re chnungsste ller ,Z ahlung sem pfäng e r)
(Ku rzau ft ra g)Lief erabruf Backwaren
(Liefera bruf )
Internet
B ackwaren abrufen(abrufen )
(Lie ferm eld ung )Lieferavis B ackwaren
(Lie fera vis)
Internet
B ackwaren avisieren(Lieferu ng mitte ilen)
ModellentwurfNachrichten-diagramm
Empfängerbetrieb
Informations-objekt (gesendet)
Referenz-bibliothek
Senderbetrieb
Softwaregenerator erzeugt Softwaregenerator erzeugt
abgeleitetaus
abgeleitetaus
basiert auf basiert auf
Java-Klasse Java-Klasse
instantiiert instantiiert
Informations-objekt (erwartet)
Abb. 5.30 EDI-Implementierung mit Java (vereinfacht)
Bei dieser Lösung spezifiziert - gemäß dem in Abschnitt 3.2 vorgestellten Ansatz - der Sender
in der Entwurfsphase die zu übertragenen Nachrichten auf Grundlage zuvor erstellter Modelle
mit einem Nachrichtendiagramm. In der gleichen Weise modelliert der Empfänger die von
seinem Inhousesystem erwarteten Nachrichtenstrukturen. Sender und Empfänger greifen dabei
auf dieselbe Referenzbibliothek zu. Ein Softwaregenerator erzeugt Javaklassen auf Basis der
Nachrichtendiagramme. Bei einer konkreten Interaktion während der Betriebsphase wird die
Javaklasse vom Sender instantiiert und mit Daten gefüllt. Die Übertragung zum Empfänger
erfolgt durch Remote-Method-Invocation (RMI). Beim Empfänger wird das passende
Informationsobjekt aktiviert und entnimmt die Werte aus den Nachrichtenelementen des
eingegangenen Informationsobjekts. Die Werte werden durch Integritätsregeln des
Empfängerobjektes überprüft. Danach erfolgt die Konvertierung in das Format des
Inhousesystems.
427 Vgl. Dresing, Rulle (Framework 1999)
203
6 Bewertung und Ausblick
6.1 Bewertung der Modellierungsmethode zur Integration zwischenbetrieb-
licher Informationsflüsse
Mit der Vorstellung einer Modellierungsmethode zur Integration zwischenbetrieblicher
Informationsflüsse ist die vorliegende Arbeit dem konstruktiven Teil der
Wirtschaftsinformatik zuzurechnen. „Im konstruktiven Teil der Wirtschaftsinformatik, also
beispielsweise beim Entwurf neuer Modellierungssprachen, ist eine Falsifikation im Sinne
POPPERs gar nicht möglich. Hier ließe sich allenfalls untersuchen, ob gewisse in der Realität
festzustellende Anforderungen berücksichtigt worden sind.“428 Daher erfolgt die Bewertung
durch einen Abgleich der in Kapitel 3 aufgestellten Anforderungen mit den durch MOVE
bereitgestellten Konzepten und Modellierungsmöglichkeiten. Entsprechend der Gliederung
der Anforderungen wird die Erfüllung der inhaltlichen und der formalen Anforderungen
getrennt bewertet.
6.1.1 Bewertung zur Erfüllung der inhaltlichen Anforderungen
Zur übersichtlichen Darstellung wird zur Bewertung eine Tabellenform gewählt, bei der die
Anforderungen aus Kapitel 3 in den Zeilen aufgeführt werden und aus den Spalten zu
entnehmen ist, durch welchen Diagrammtyp bzw. welches Metamodell die jeweilige An-
forderung erfüllt wird. Dabei werden die in Tab. 6-1 angegebenen Kürzel für die einzelnen
Diagrammtypen von MOVE verwendet.
Kürzel Diagrammtyp Metamodell TD Transaktionsdiagramm Abb. 4.10, S. 136 ID Interaktionsdiagramm Abb. 4.12, S. 140 SD Sequenzdiagramm Abb. 4.14, S. 143 ND Nachrichtendiagramm Abb. 4.16, S. 146 RD Regeldiagramm Abb. 4.18, S. 150
Tab. 6-1 Diagrammkürzel und Verweis auf Metamodell
428 Frank (Verwendung 1999), S. 148
204
Anforderungen zur Beschreibung von Strukturen und Abläufen zwischenbetrieblicher
Transaktionen und ihrer Informationsflüsse
Ein Blick auf Tab. 6-2 zeigt deutlich, dass die Strukturen und Abläufe zwischenbetrieblicher
Transaktionen und ihrer Informationsflüsse vollständig durch Transaktions-, Interaktions- und
Sequenzdiagramme abgebildet werden können. Das Transaktionsdiagramm liefert zunächst
einen Überblick über eine Transaktion und gibt Antworten auf die Fragen „Was?“ und
„Wer?“. Detaillierte Aussagen zu einzelnen Leistungs-, Zahlungs- und insbesondere
Informationsflüssen sind den Interaktionsdiagrammen zu entnehmen. Sie liefern Antworten
auf nahezu sämtliche Analysefragen. Während Transaktions- und Interaktionsdiagramme
Betrachtungen aus einer statischen Perspektive vornehmen, dienen Sequenzdiagramme zur
Veranschaulichung des dynamischen Ablaufs.
Anforderung TD ID SD ND RD Leistungs-, Zahlungs-, Informationsflüsse X X X
Leistungs-, Zahlungs-, Informationsobjekte X X (X) Was? (Gegenstand)
Zuordnung Flüsse-Objekte X X
Akteure X X X
Rollen X X
Zuordnung Akteur-Rolle-Transaktion X X
Wer? (Akteure)
Zuordnung Akteur-Rolle-Fluss X X
Zeitliche Folge von Flüssen X Wann? (Zeitliche Struktur) Absolute und relative Zeitangaben (X) X
Alternative Verknüpfungen von Flüssen, Ablaufvarianten
X X
Kanäle X
Medien X
Zuordnung Kanal-Medium-Informationsobjekt-Informationsfluss
X
Wie? (Art und Hilfsmittel)
Zuordnung Kanal-Akteur X
Phasen von Transaktionen X X (X)
Zweck von Informationsflüssen (X) Wozu? (Zweck)
Bezug von Informationsobjekten (X)
Tab. 6-2 Bewertung zu den Anforderungen zur Beschreibung von Strukturen und Abläufen
Anforderungen zum Ableiten und Festlegen von Nachrichtenstrukturen
Sämtliche Diagrammtypen der Modellierungsmethode MOVE lassen sich zu einem
gemeinsamen, großen Metamodell der MOVE-Methode integrieren. Dies wird deutlich, wenn
man die Metamodelle der verschiedenen Diagrammtypen miteinander vergleicht. Sie sind
vollständig konsistent zueinander. Modellierungselemente, die in mehreren Diagrammtypen
vorkommen, werden in gleicher Weise modelliert. Dies ist die Voraussetzung, um
Nachrichtenstrukturen modellgestützt ableiten zu können. Die Festlegung der
205
Nachrichtenstruktur selbst erfolgt durch die Nachrichtendiagramme. Sie können die
entsprechenden Anforderungen vollständig abdecken (vgl. Tab. 6-3).
Anforderung TD ID SD ND RD
Ableiten der Nachrichtenstruktur
Integrierte Modelle zu Transaktionen, zu Informationsflüssen und zu den Nachrichten mit ihren Datenelementen
X X X X X
Hierarchisch strukturierte Informationsobjekte X
Datenelemente X Festlegen der Nachrichtenstruktur
Zuordnung Datenelement-Informationsobjekt X
Tab. 6-3 Bewertung zu den Anforderungen zum Ableiten und Festlegen von Nachrichtenstrukturen
Anforderungen an die Unterstützung der fachlichen Aufgaben einer Integration
zwischenbetrieblicher Informationsflüsse
Die Anforderungen zur Unterstützung der fachlichen Aufgaben einer Integration können
durch die Kombination nahezu sämtlicher Diagrammtypen, mit Ausnahme der
Transaktionsdiagramme, erfüllt werden (vgl. Tab. 6-4). Während Nachrichten- und
Regeldiagramme zur Unterstützung der syntaktischen und semantischen Integration
heranzuziehen sind, decken Interaktions- und Sequenzdiagramme die Erfordernisse der
pragmatischen Integration ab.
Anforderung TD ID SD ND RD
Syntaktische Konvertierung
Angaben zum syntaktischen Format eines Datenelementes
X
Regeln X
Verknüpfung Datenelement-Regeln (X) (X) Semantische Prüfung
Zuordnung Informationsobjekt-Transaktion X X
Reihenfolgebeziehungen von Flüssen X Allgemeine Anforderungen der pragmatischen Integration
Nebenläufigkeit von Flüssen X
Rollen von Informationsobjekten X X
Zweck von Informationsobjekten (X)
Ereignisse X (X)
Anwendungssysteme X
Funktionen X
Zuordnung Anwendungssystem-Funktion X
Zuordnung Fluss-Ereignis-Funktion X (X)
Verknüpfung von Flüssen über Regeln X
Aktions-/ Reaktionsmechanismen
Zuordnung Fluss-Ereignis X (X)
Tab. 6-4 Bewertung zu den Anforderungen an die Unterstützung der fachlichen Aufgaben
Zusammenfassend lässt sich feststellen, dass sämtliche inhaltlichen Anforderungen durch die
von MOVE zur Verfügung gestellten Diagrammtypen erfüllt werden.
206
6.1.2 Bewertung zur Erfüllung der formalen Anforderungen
Allgemeine Anforderungen
In Kapitel 4 wurde eine grafische Notation sowie eine Vorgehensweise für MOVE vorgestellt.
Weiterhin wurde MOVE durch ein Metamodell spezifiziert. Bis auf eine Werkzeugunter-
stützung umfasst MOVE damit sämtliche Komponenten einer vollständigen
Modellierungsmethode.
MOVE ist unabhängig von bestimmten Nachrichtenstandards, Programmiersprachen oder
Kommunikationstechnologien. Die Konstruktion der zwischenbetrieblichen Transaktionen
und ihrer Informationsflüsse sowie die Spezifikation der Nachrichten erfolgen auf fach-
konzeptueller Ebene. Die Modelle sind unabhängig von der Syntax der tatsächlich
verwendeten Austauschformate, von den gewählten Übertragungssystemen und von den
vorhandenen Anwendungssystemen. MOVE kann sowohl beim Verwenden traditioneller
EDI-Technologien und Standardformate als auch bei internetbasierten Lösungen unter
Nutzung neuerer Technologien wie XML oder Java zum Entwurf der zwischenbetrieblichen
Informationsflüsse eingesetzt werden.
Die MOVE-Methode ist branchenneutral und nicht auf bestimmte Transaktionen (z. B.
Beschaffung, Logistik, Zahlung) beschränkt. Sie kann in nahezu sämtlichen Betrieben
eingesetzt werden. Sie weist daher eine hohe Einsatzbreite und -tiefe auf. Gleichwohl
empfiehlt sich der Aufbau branchenspezifischer Referenzbibliotheken für einen effektiven
Einsatz von MOVE.
Anforderungen an die Modellierungssprache
Im vorhergehenden Abschnitt wurde gezeigt, dass MOVE sämtliche inhaltlichen Anfor-
derungen an eine Modellierungsmethode zur Integration zwischenbetrieblicher
Informationsflüsse erfüllen kann. Damit kann der Modellierungssprache von MOVE auch
eine Sprachadäquanz im Sinne einer Spracheignung zugesprochen werden.
Wie Abb. 4.1 zeigt, weist MOVE einen systematischen Aufbau auf. Es gibt Diagramme zur
Modellierung der Strukturen aus einer statischen Sicht sowie des Verhaltens aus einer
dynamischen Sicht. Die Konsistenz der Sichten wird durch ein integriertes Metamodell
sichergestellt. Die Vorgehensweise von MOVE sieht eine geordnete Abfolge von
Modellierungsschritten nach dem Top-Down-Prinzip vor.
207
Die Anforderung der Klarheit wird bei MOVE durch mehrere Umstände erfüllt. Für die
MOVE-Notation werden einfache Darstellungsmittel verwendet, die sich weitgehend per
Hand zeichnen lassen. Außerdem sind für die einzelnen Modellierungselemente möglichst
solche Symbole gewählt worden, die bereits von anderen Modellierungssprachen für
dieselben Modellierungselemente verwendet werden. Zu den weiteren Maßnahmen zur
Förderung der Klarheit gehört der materiellorientierte Entwurfsrahmen (=materiellorientiertes
Deutungsmuster) sowie die Möglichkeit zur Hierarchisierung (Dekomposition) von Modellen.
So kann jeder Interaktion in einem Transaktionsdiagramm ein eigenes Interaktionsdiagramm
zugeordnet werden. Jedem Informationsobjekt in einem Interaktionsdiagramm kann wiederum
ein Nachrichtendiagramm zugeordnet werden. Letztendlich können einem Datenelement eines
Nachrichtendiagramms mehrere Regeldiagramme zugeordnet sein.
Anforderungen an die Vorgehensweise
Das referenzgestützte und insbesondere ontologiebasierte Vorgehen von MOVE erfüllt die
Forderungen nach Konstruktionsadäquanz, Vergleichbarkeit und Wirtschaftlichkeit.
Die detaillierten Modellierungsanweisungen der Vorgehensweise von MOVE kommen der
Forderung der Sprachadäquanz im Sinne der Sprachrichtigkeit nach. MOVE-Anwender
werden durch die Vorgehensweise derart geleitet, dass sie die Modellierungssprache korrekt
anwenden. Mitunter werden auch Regeln zur Layoutgestaltung der Modelle vorgegeben, die
die Klarheit der Modellierungsergebnisse fördern.
6.2 Ausblick
Wie im vorhergehenden Abschnitt gezeigt wurde, kann die im Rahmen dieser Arbeit ent-
wickelte Methode MOVE nahezu sämtliche Anforderungen an eine Modellierungsmethode
zur Integration zwischenbetrieblicher Informationsflüsse erfüllen. Offener Punkt für einen
effektiven Einsatz ist sicher die Bereitstellung eines computergestützten Werkzeuges. Im
Forschungsprojekt MOVE ist bereits ein solches Entwurfswerkzeug für die Modellierungs-
methode (zum damaligen Entwicklungsstand) prototypisch entwickelt worden.429 Dieser
Prototyp könnte als Werkzeugunterstützung für die Modellierungsmethode MOVE dienen.
Aufgrund der inzwischen durch die vorliegende Arbeit vorgenommen konzeptionellen
429 Vgl. Steffen (Design 1999)
208
Änderungen und Weiterentwicklungen von MOVE ist dieser Prototyp entsprechend zu
erweitern und anzupassen.
Die Handhabbarkeit und Nützlichkeit der Modellierungsmethode MOVE lässt sich
letztendlich nur durch einen umfangreichen Einsatz in der Praxis zeigen. Ein solcher
Praxistest in einem für eine aussagekräftige Evaluierung angemessenen Umfang war im
Rahmen des vorliegenden Dissertationsprojektes leider nicht möglich und wäre ein
folgerichtiger Schritt für weitere Forschungsarbeiten. In einem solchen Evaluierungsprojekt
könnte auch die Prämisse der vorliegenden Arbeit, dass eine fachkonzeptuelle Modellierung
den Gestaltungsprozess zwischenbetrieblicher Informationsflüsse entscheidend unterstützen
und vereinfachen kann, überprüft werden. Dies ist nicht nur vor dem Hintergrund des
Einsatzes von MOVE interessant, sondern auch von übergreifender Relevanz. Denn aktuelle
Entwicklungen in Forschung und Praxis folgen ebenfalls der hier unterstellten Prämisse. So
gibt es kaum einen neuen Ansatz zur Integration zwischenbetrieblicher Informationsflüsse,
der ohne eine fachkonzeptuelle Modellierung auskommt. Beispiele dafür sind die RosettaNet-
Initiative sowie die ebXML-Initiative der UN/CEFACT und der OASIS (vgl. Abschnitt 2.6.2).
Wichtige Voraussetzung eines verteilten Entwurfes und der Integration zwischenbetrieblicher
Informationsflüsse nach dem MOVE-Ansatz ist die Verwendung einer gemeinsamen
Referenzbibliothek. Hierfür ist ein geeignetes Organisationskonzept zu entwickeln. Unter
anderem ist zu klären, wer am Aufbau der Referenzbibliothek beteiligt ist, wie sie
bereitgestellt, gepflegt, ergänzt und genutzt wird. Hier zeigen aktuelle Entwicklungen aus der
Praxis Möglichkeiten auf, wie eine solche allgemein zugängliche Referenzbibliothek
organisiert und realisiert werden kann. So ist im Rahmen der RosettaNet-Initiative bereits eine
Referenzbibliothek („PIP directory“) im produktiven Einsatz. Für dessen Aufbau und Pflege
gibt es einen fest definierten Ablauf.430 Der ebXML-Ansatz sieht ebenfalls den Einsatz einer
Referenzbibliothek („ebXML Registry“) vor und hat dafür ein entsprechendes
Organisationskonzept entworfen.431
Ähnlich wie bei den Verzeichnissen bisheriger Nachrichtenstandards besteht auch bei diesen
Referenzbibliotheken nach wie vor die Schwierigkeit, Fachkonzepte so dar- und
bereitzustellen, dass sie von allen Nutzern in semantischer Hinsicht gleich interpretiert
werden. In dieser Arbeit wurde daher ein ontologiebasierter Ansatz gewählt. Dabei werden
430 Vgl. RosettaNet (Implementation 2001)
209
nicht nur isoliert einzelne Fachkonzepte betrachtet, sondern auch ihre ontologischen
Beziehungen zueinander. Problematisch hierbei ist, dass sich alle am verteilten Entwurf
beteiligten Personen auf eine Sprache zur Repräsentation und auf die Ausprägung einer
Ontologie selbst einigen müssen. Es ist allerdings nicht zu erwarten, dass es gelingen wird,
eine weltweit universelle Ontologie zu entwickeln, die sämtlichen Anforderungen in den
verschiedensten Regionen und Branchen genügt. Eine große Herausforderung im Hinblick auf
einen globalen und branchenübergreifenden Geschäftsverkehr ist es daher, verschiedene
Ontologien und Repräsentationssprachen für Ontologien miteinander zu vernetzen.432 Für
diese Aufgabe sind noch erhebliche Forschungsarbeiten zu leisten. Sie sind Voraussetzung
dafür, dass die Vision einer modellbasierten Integration zwischenbetrieblicher
Informationsflüsse ohne vorherige, bilaterale Absprachen zur Wirklichkeit werden kann.
Danach können Betriebe jeder Größe von jedem Ort aus mit jedem anderen Betrieb
Geschäftspartnerschaften aufnehmen und Nachrichten auf
elektronischen Wege zwischen ihren Anwendungssystemen austauschen, ohne zuvor lang-
wierige Absprachen treffen zu müssen.
431 Vgl. ebXML Registry Project Team (Registry 2001) 432 Vgl. Berners-Lee, Hendler, Lassila (Web 2001), S. 5f.
210
Literaturverzeichnis
Alt (Interorganisationssysteme 1997) Alt, R.: Interorganisationssysteme in der Logistik. Diss.; Hochschule St. Gallen 1997.
Alt, Cathomen (Handbuch 1995) Alt, R.; Cathomen, I.: Handbuch Interorganisationssysteme: Anwendungen für die Waren- und Finanzlogistik. Braunschweig u. a. 1995.
Bach, Brecht, Österle (Marktstudie 1995) Bach, V.; Brecht, L.; Österle, H.: Marktstudie Software Tools für das Business Process Redesign. Baden Baden 1995.
Balzert (Analysemodell 1997) Balzert, H.: Wie erstellt man ein objektorientiertes Analysemodell. In: Informatik-Spektrum 20 (1997) 1; S. 38-47.
Balzert (Lehrbuch 1999) Balzert, H.: Lehrbuch der Objektmodellierung: Analyse und Entwurf. Heidelberg, Berlin 1999.
Becker u. a. (Referenz-Informationsmodellierung 2000) Becker, J.; Holten, R.; Knackstedt, R.; Schütte, R.: Referenz-Informationsmodellierung. In: Bodendorf, F.; Grauer, M. (Hrsg.): Verbundtagung Wirtschaftsinformatik 2000. Aachen 2000; S. 86-109.
Becker (CIM 1991) Becker, J.: CIM-Integrationsmodell. Die EDV-gestützte Verbindung betrieblicher Bereiche. Berlin u. a. 1991.
Becker (Referenzmodellierung 1998) Becker, J.: Referenzmodellierung und Grundsätze ordnungsmäßiger Modellierung. In: Becker, J. (Hrsg.): Referenzmodellierung '98 - Anwendungsfelder in Theorie und Praxis. Aachen 1998; S. 1.1 - 1.7.
Becker, Rosemann, Schütte (Grundsätze 1995) Becker, J.; Rosemann, M.; Schütte, R.: Grundsätze ordnungsmäßiger Modellierung. In: Wirtschaftsinformatik 37 (1995) 5; S. 435-445.
Becker, Schütte (Handelsinformationssysteme 1996) Becker, J.; Schütte, R.: Handelsinformationssysteme. Berlin u. a. 1996; S. 419-425.
Benjamin, de Long, Morton (Data 1990) Benjamin, I.; de Long, W.; Morton, S.: Electronic Data Interchange: How Much Com-petitive Advantage?. In: Long Range Planning 23 (1990) 1; S. 29-40.
Berghoff, Drobnik (Aufbau 1999) Berghoff, J.; Drobnik, O.: Aufbau und Erweiterung domänenspezifischer Ontologien am Beispiel einer CSCW-Ontologie. Kurzbeitrag auf der Tagung Wirtschaftsinformatik und Wissenschaftstheorie '99 - Verteilte Theoriebildung. Frankfurt am Main, Oktober 1999. www.witrans.uni-frankfurt.de/forschungsbericht/f15/p423/ p1316.htm, 1999, Abruf am 1999-09-29.
211
Berners-Lee, Hendler, Lassila (Web 2001) Berners-Lee, T.; Hendler, J.; Lassila, O.: The Semantic Web. http://www.scientificamerican.com/2001/0501issue/0501berners-lee.html; 2001-05; Abruf am 2001-12-18
Bertalanffy (System 1968) Bertalanffy, L.: General System Theory - Foundations, Development, Applications. New York 1968.
Bertalanffy (Vorläufer 1972) Bertalanffy, L.: Vorläufer und Begründer der Systemtheorie. In: Kurzrock, R. (Hrsg.): Systemtheorie. Berlin 1972; S. 17-28.
BFK u. a. (Modellierung 1995) BFK, EHI, ICL, Winfo1: Modellierung einer verteilten Architektur für die Entwicklung unternehmensübergreifender Informationssysteme und ihre Validierung im Handelsbereich. Antrag zum BMBF-Forschungsprojekt 01 IS 602 D (MOVE). Universität-Gesamthochschule Paderborn 1995.
BFK u. a. (Modellierung 1999) BFK, EHI, ICL, Winfo1: Modellierung einer verteilten Architektur für die Entwicklung unternehmensübergreifender Informationssysteme und ihre Validierung im Handelsbereich. Schlussbericht zum BMBF-Forschungsprojekt 01 IS 602 D (MOVE). Universität-Gesamthochschule Paderborn 1999.
Blecker (Unternehmung 1999) Blecker, T.: Unternehmung ohne Grenzen – Konzepte, Strategien und Gestaltungs-empfehlungen für das Strategische Management. Wiesbaden 1999.
Bode (Informationsbegriff 1997) Bode, J.: Der Informationsbegriff in der Betriebswirtschaftslehre. In: Schmalenbachs Zeitschrift für betriebswirtschaftliche Forschung 49 (1997) 5; S. 449-468.
Bons (Trade 1997) Bons, R.: Designing trustworthy trade procedures for open eletronic commerce - a methodology for the automated analysis of interorganisational controls. Diss.; Rotterdam 1997.
Booch, Rumbaugh, Jacobson (Modeling 1999) Booch, G.; Rumbaugh, J.; Jacobson, I.: The Unified Modeling Language User Guide. Reading, Mass. 1999.
Brehm (Management 1997) Brehm, B.: Strategisches Management von Electronic Data Interchange (EDI). Göttingen 1997.
Brekle (Semantik 1972) Brekle, H.: Semantik. München 1972.
Brenner (Entwurf 1985) Brenner, W.: Entwurf betrieblicher Datenelemente: Ein Weg zur Integration von Informationssystemen. Diss.; Hochschule St. Gallen 1985.
212
Brenner, Lieser, Österle (Datenintegration 1988) Brenner, W.; Lieser, K.; Österle, H.: Datenintegration über Datenklassifikation. In: Angewandte Informatik (1988) 7; S. 302-309.
Bretzke (Problembezug 1980) Bretzke, W.: Der Problembezug von Entscheidungsmodellen. Tübingen 1980.
Bryan (XML/EDI 1998) Bryan, M.: European XML/EDI Pilot Project - Terms of Reference. http://www.cenorm.be/isss/workshop/ec/xmledi/Documents_98/xml005.html, 1998-06-05, Abruf am 1999-05-14.
Bünting, Karatas (Wörterbuch 1996) Bünting, K.; Karatas, R. (Hrsg.): Deutsches Wörterbuch. Chur 1996.
Bungert, Heß (Geschäftsprozeßmodellierung 1995) Bungert, W.; Heß, H.: Objektorientierte Geschäftsprozeßmodellierung. In: Information Management (1995) 1; S. 53-63.
Burkhard (Einführung 1998) Burkhard, H.: Einführung in die Agententechnologie. In: Informationstechnik und technische Informatik 40 (1998) 4; S. 6-11.
Burkhardt (UML 1997) Burkhardt, R.: UML-Unified Modeling Language: Objektorientierte Modellierung für die Praxis. Bonn 1997.
Campbell (XML/EDI 2000) Campbell, S.: XML/EDI - Recommendations for the Standardization in the field of XML for electronic data interchange. http://forum.afnor.fr/afnor/WORK/AFNOR/ GPN2/XMLEDI/PUBLIC/DOC/2000/042.doc, 2000-03-28, Abruf am 2000-07-13.
Centrale für Coorganisation (EANCOM 1999) Centrale für Coorganisation, C.: EANCOM®-Handbuch. CD-ROM. Köln 1999.
Chen (Entity-Relationship 1976) Chen, P.: The Entity-Relationship Model - Toward a Unified View of Data. In: ACM Transaction on Database Systems 1 (1976) 1; S. 9-36.
Coad, Yourdon (Analysis 1991) Coad, P.; Yourdon, E.: Object-oriented Analysis. 2. Aufl.; Englewood Cliffs u. a. 1991.
Coase (Nature 1937) Coase, R.: The Nature of Firm. In: Economica 4 (1937) 11; S. 386-405.
Cribbs, Moon, Roe (Evaluation 1992) Cribbs, J.; Moon, S.; Roe, C.: An Evaluation of Object-Oriented Analysis and Design Methodologies. Raleigh 1992.
Czap, Grimm (CASE-Tool 1996) Czap, H.; Grimm, C.: CBSE: Ein fallbasiertes CASE-Tool zur Entwicklung kundenspezifischer Anwendungssysteme. In: Wirtschaftsinformatik 38 (1996) 1; S. 32-38.
213
Dahlberg (Definitionstheorie 1985) Dahlberg, I.: Begriffs- und Definitionstheorie in ihrem Zusammenhang. In: Dutz, K.D. (Hrsg.): Studien zur Klassifikation, Systematik und Terminologie. Münster 1985; S. 93-110.
Davenport (Process 1993) Davenport, T.: Process Innovation - Reengineering Work through Information Techno-logy. Boston 1993.
Davenport, Short (Engineering 1990) Davenport, T.; Short, J.: The New Industrial Engineering: Information Technology and Business Process Redesign. In: Sloan Management Review. 1990; S. 11-27.
DEDIG (WebEDI 1999) Deutsche EDI-Gesellschaft (DEDIG) (Hrsg.): WebEDI - EDI für kleine und mittelständische Unternehmen. Berlin 1999.
Deiters, Gruhn, Striemer (Geschäftsprozeßmangement 1995) Deiters, W.; Gruhn, V.; Striemer, R.: Der FUNSOFT-Ansatz zum integrierten Geschäftsprozeßmangement. In: Wirtschaftsinformatik 37 (1995) 5; S. 459-466.
Deutsch (Data 1993) Deutsch, M.: Electronic Data Interchange setzt sich durch: Brückenschlag. In: iX (1993) 10; S. 116-122.
Dresing, Rulle (Framework 1999) Dresing, H.; Rulle, A.: Ein Framework für das modellgestützte Generieren von Softwareobjekten in MOVE. In: Fischer, J.; Kern, U. (Hrsg.): Objektorientierte Modelle und Werkzeuge für unternehmensübergreifende Informationssysteme im Rahmen des Electronic Commerce. Köln 1999; S. 183-222.
Drosdowski u. a. (Duden 1990) Drosdowski, G.; Müller, W.; Scholze-Stubenrecht, W.; Wermke, M. (Hrsg.): Duden Fremdwörterbuch. 5. Aufl.; Mannheim, Wien, Zürich 1990.
ebXML Registry Project Team: (Registry 2001) ebXML Registry Services Specification v1.0. http://www.ebxml.org/specs/ebRS.doc, 2001-05-10, Abruf am 2001-12-13.
Emmelhainz (EDI 1993) Emmelhainz, M.: EDI: A Total Management Guide. 2. Aufl.; New York 1993.
EuroHandelsinstitut e.V. (Handel 1996) EuroHandelsinstitut e.V.: Handel aktuell '96. Köln 1996.
Falk, Pieck, Mertens (Unterstützung 1993) Falk, J.; Pieck, S.; Mertens, P.: Unterstützung der Lager- und Transportlogistik durch Teilintelligente Agenten. In: Information Management (1993) 2; S. 26-31.
Feierabend (Beitrag 1980) Feierabend, R.: Beitrag zur Abstimmung und Gestaltung unternehmensübergreifender logistischer Schnittstellen. Bremen 1980.
Ferstl, Sinz (Ansatz 1995) Ferstl, O.; Sinz, E.: Der Ansatz des Semantischen Objektmodells (SOM) zur Model-lierung von Geschäftsprozessen. In: Wirtschaftsinformatik 37 (1995) 3; S. 209-220.
214
Ferstl, Sinz (Grundlagen 1998) Ferstl, O.; Sinz, E.: Grundlagen der Wirtschaftsinformatik; Band 1. 3. Aufl.; München, Wien 1998.
Fischer u. a. (Agenten 1996) Fischer, K.; Heimig, I.; Kocian, C.; Müller, J.: Intelligente Agenten für das Management Virtueller Unternehmen. In: Information Management (1996) 1; S. 38-45.
Fischer (Datenmanagement 1992) Fischer, J.: Datenmanagement: Datenbanken und betriebliche Datenmodellierung. München, Wien 1992.
Fischer (Datenmodellierung 1993) Fischer, J.: Unternehmensübergreifende Datenmodellierung - der nächste folgerichtige Schritt der zwischenbetrieblichen Datenverarbeitung. In: Wirtschaftsinformatik 35 (1993) 3; S. 241-254.
Fischer (Informationskooperationen 1997) Fischer, J.: Zwischenbetriebliche Informationskooperationen - Wettbewerbsfaktor für mittelständische Unternehmen. In: Dangelmaier, W. u. a. (Hrsg.): Kommunikations-management in verteilten Unternehmen. Düsseldorf 1997; S. 1-20.
Fischer (Informationswirtschaft 1999) Fischer, J.: Informationswirtschaft: Anwendungsmanagement. München, Wien 1999.
Fischer (Kommunikationssysteme 2000) Fischer, J.: Betriebliche Kommunikationssysteme und Kommunikationsmanagement. Skript zur gleichnamigen Vorlesung im Sommersemester 2000. Universität Paderborn 2000.
Fischer (MOVE 1999) Fischer, J.: MOVE als Architektur für zwischenbetriebliche Informationssysteme. In: Fischer, J.; Kern, U. (Hrsg.): Objektorientierte Modelle und Werkzeuge für unternehmensübergreifende Informationssysteme im Rahmen des Electronic Commerce. Köln 1999; S. 5-31.
Fischer (TeleTruck 1998) Fischer, K.: TeleTruck: Ein Online-Dispositionssystem für Speditionen. In: Informa-tionstechnik und technische Informatik 40 (1998) 4; S. 30-33.
Fischer (Ziele 1989) Fischer, J.: Qualitative Ziele in der Unternehmensplanung. Berlin 1989.
Frank (Verwendung 1999) Frank, U.: Zur Verwendung formaler Sprachen in der Wirtschaftsinformatik: Notwendiges Merkmal eines wissenschaftlichen Anspruchs oder Ausdruck eines übertriebenen Szientismus?. In: Becker, J. u. a. (Hrsg.): Wirtschaftsinformatik und Wissenschaftstheorie. Wiesbaden 1999; S. 127-158.
Frank, Prasse (Standardisierung 1997) Frank, U.; Prasse, M.: Zur Standardisierung objektorientierter Modellierungssprachen: Eine kritische Betrachtung des State of the Art am Beispiel der Unified Modeling Language. In: Informationssystem Architekturen. Rundbrief des GI-Fachausschusses 5.2. 4 (1997) 1; S. 1-5.
215
Frank, Schauer (Potentiale 1999) Frank, U.; Schauer, H.: Potentiale und Herausforderungen des Wissensmanagements aus der Sicht der Wirtschaftsinformatik. In: Tagungsband Workshop "Wissen - Wissenschaftstheorie - Wissensmanagement" der Kommission Wissenschaftstheorie, 18.6.-19.6.1999. Freie Universität Berlin http://www.wiwiss.fu-berlin.de/w3/w3schrey/ KOMWIS/Beitraege/frankschauer.htm, 1999, Abruf 2000-04-18
Gebauer (Unterstützung 1996) Gebauer, J.: Informationstechnische Unterstützung von Transaktionen. Wiesbaden 1996.
Grochla (Betrieb 1993) Grochla, E.: Betrieb, Betriebswirtschaft und Unternehmung. In: Wittmann, W. (Hrsg.): Handwörterbuch der Betriebswirtschaft. Teilbd. 1. A-H. 5. Aufl.; Stuttgart 1993; S. 374-390.
Grochla (Planung 1975) Grochla, E.: Betriebliche Planung und Informationssysteme. Reinbek bei Hamburg 1975.
Gruber (Principles 1993) Gruber, T.: Toward Principles for the Design of Ontologies Used for Knowledge Shar-ing. Stanford Knowledge Systems Laboratory Report KSL-93-04. http://ksl-web.stanford.edu/KSL_Abstracts/KSL-93-04.html, 1993-08-23, Abruf am 1999-11-19.
Gruhn (Datenaustausch 1997) Gruhn, V.: Elektronischer Datenaustausch in zwischenbetrieblichen Geschäftsprozessen. In: Wirtschaftsinformatik 39 (1997) 3; S. 225-230.
Gruhn, Kampmann (Modellierung 1996) Gruhn, V.; Kampmann, M.: Modellierung unternehmensübergreifender Geschäftsprozesse mit FUNSOFT-Netzen. In: Wirtschaftsinformatik 38 (1996) 4; S. 383-390.
Grund, Jähnig (Modell 1994) Grund, K.; Jähnig, F.: Modell zur Analyse und Simulation von Geschäftsprozessen. In: Management & Computer 2 (1994) 1; S. 49-56.
Guarino (Matching 1997) Guarino, N.: Semantic Matching: Formal Ontological Distinctions Used for Information Organisation, Extraction, and Integration. In: Pazienza, M.T. (Hrsg.): Information Ex-traction: A Multidisciplinary Approach to an Emerging Information Technology. Berlin u. a. 1997; S. 139-170.
Hammer (Work 1990) Hammer, M.: Reengineering Work: Don't Automate, Obliterate. In: Harvard Business Review 68 (1990) 4; S. 104-112.
Hammer, Champy (Re-engineering 1993) Hammer, M.; Champy, J.: Re-engineering the Corporation - A Manifesto for Business Revolution. 1993.
216
Hansen (Wirtschaftsinformatik 1996) Hansen, H.: Wirtschaftsinformatik I. 7. Aufl.; Stuttgart 1996.
Hars (Referenzdatenmodelle 1994) Hars, A.: Referenzdatenmodelle: Grundlagen effizienter Datenmodellierung. Wiesbaden 1994.
Heilmann (Integration 1989) Heilmann, H.: Integration: Ein zentraler Begriff der Wirtschaftsinformatik im Wandel der Zeit. In: Handbuch der modernen Datenverarbeitung 26 (1989) 150; S. 46-58.
Heinrich, Lehner, Roithmayr (Informationstechnik 1990) Heinrich, L.; Lehner, F.; Roithmayr, F.: Informations- und Kommunikationstechnik für Betriebswirte und Wirtschaftsinformatiker. 2. Aufl.; München, Wien 1990.
Henkel (Gestaltung 1996) Henkel, S.: Gestaltung elektronischer Datenkommunikationssysteme in Logistiknetzen. Frankfurt a.M. 1996.
Herbst (Business 1997) Herbst, H.: Business Rule-Oriented Conceptual Modeling. Heidelberg 1997.
Herbst, Knolmayer (Ansätze 1995) Herbst, H.; Knolmayer, G.: Ansätze zur Klassifikation von Geschäftsregeln. In: Wirtschaftsinformatik 37 (1995) 2; S. 149-159.
Herrmann (Planung 1992) Herrmann, H.: Modellgestützte Planung in Unternehmen. Wiesbaden 1992.
Heß, Scheer (Methodenvergleich 1992) Heß, H.; Scheer, A.: Methodenvergleich zum objektorientierten Design von Softwaresystemen. In: Handbuch der modernen Datenverarbeitung 29 (1992) 165; S. 117-137.
Hirschmann (Gestaltung 1998) Hirschmann, P.: Kooperative Gestaltung unternehmensübergreifender Geschäftsprozesse. Wiesbaden 1998.
Hirschmann, Scheer (Konzeption 1994) Hirschmann, P.; Scheer, A.: Konzeption einer DV-Unterstützung für das überbetrieb-liche Prozeßmanagement. In: Scheer, A.-W. (Hrsg.): Veröffentlichungen des Instituts für Wirtschaftsinformatik (IWi). Heft 113. Saarbrücken 1994.
Hluchy u. a. (Analyse 1999) Hluchy, R.; Hoos, J.; Pauls, M.; Walter, F.: Analyse zwischenbetrieblicher Geschäftsprozesse mit Hilfe der Simulationstechnik. In: Fischer, J.; Kern, U. (Hrsg.): Objektorientierte Modelle und Werkzeuge für unternehmensübergreifende Informationssysteme im Rahmen des Electronic Commerce. Köln 1999; S. 121-152.
Hubmann (Elektronisierung 1989) Hubmann, H.: Elektronisierung von Beschaffungsmärkten und Beschaffungshierarchien. München 1989.
Huemer (Business 2001) Huemer, C.: Electronic Business XML. In: Turowski, K.; Fellner, K.J. (Hrsg.): XML in der betrieblichen Praxis: Standards, Möglichkeiten, Praxisbeispiele. Heidelberg 2001; S. 13-28.
217
ISO (Information 1997) International Organization for Standardization (ISO): Information Technologies - Open-edi reference model. ISO/IEC Standard 14662. http://www.harbinger.com/resource/ klaus/open-edi/model/oerm.htm, 1997-08-29, Abruf am 1999-01-29.
ISO (Rules 1998) International Organization for Standardization (ISO): Basic Semantics Register (BSR): Rules, Guidelines and Methodology. Draft - March 1998. http://www.iso.ch/BSR/index.htm, 1998-03-20, Abruf am 1998-07-23.
Jacob, Becker, Krcmar (Informationssysteme 1991) Jacob, H.; Becker, J.; Krcmar, H. (Hrsg.): Integrierte Informationssysteme. Schriften zur Unternehmensführung. Band 44. Wiesbaden 1991.
Jünemann, Schmidt (Materialflußsysteme 1999) Jünemann, R.; Schmidt, T.: Materialflußsysteme - Systemtechnische Grundlagen. 2. Aufl.; Berlin u. a. 1999.
Keller, Popp (Gestaltung 1995) Keller, G.; Popp, K.: Gestaltung von Geschäftsprozessen als betriebliche Aufgabe. In: Mangement & Computer 3 (1995) 1; S. 43-52.
Kilian u. a. (Data 1994) Kilian, W.; Picot, A.; Neuburger, R.; Niggl, J.; Scholten, K.; Seiler, W.: Electronic Data Interchange (EDI). Baden Baden 1994.
Kirsch u. a. (Logistik 1973) Kirsch, W.; Bamberger, I.; Gabele, E.; Klein, H.: Betriebswirtschaftliche Logistik. Wiesbaden 1973.
Klein (Interorganisationssysteme 1996) Klein, S.: Interorganisationssysteme und Unternehmensnetzwerke. Wiesbaden 1996.
Klein (Stellenwert 1992) Klein, S.: Der Stellenwert von Electronic Data Interchange in der Informationslogistik. In: Stroetmann, K. A. (Hrsg.): Informationslogistik - Managementkonzepte, Fallbeispiele und Anwendererfahrungen bei Informationsprozessen. Frankfurt 1992; S. 195-223.
König, Syben, Heinzl (Anmerkungen 1990) König, W.; Syben, P.; Heinzl, A.: Anmerkungen zum Informationsbegriff. In: Hochschulnachrichten aus der Wissenschaftlichen Hochschule für Unternehmensführung Koblenz. 19901; S. 48-49.
Kortzfleisch (Information 1973) Kortzfleisch, H.: Information und Kommunikation in der industriellen Unternehmung. In: Zeitschrift für Betriebswirtschaft 43 (1973) 8; S. 549-560.
Kosiol (Modellanalyse 1961) Kosiol, E.: Modellanalyse als Grundlage unternehmerischer Entscheidungen. In: Zeitschrift für handelswissenschaftliche Forschung 13 (1961) ; S. 318-334.
Kosiol (Problemanalyse 1967) Kosiol, E.: Modelltheoretische Problemanalyse und Unternehmerentscheidung. Frankfurt 1967.
218
Kosiol (Unternehmung 1962) Kosiol, E.: Unternehmung. In: Seischab, H.; Schwantag, K. (Hrsg.): Handwörterbuch der Betriebswirtschaft. Bd. 4. 3. Aufl.; Stuttgart 1962; S. 5540-5545.
Krcmar (Bedeutung 1990) Krcmar, H.: Bedeutung und Ziele von Informationssystem-Architekturen. In: Wirtschaftsinformatik 32 (1990) 5; S. 395-402.
Krcmar (Integration 1991) Krcmar, H.: Integration in der Wirtschaftsinformatik - Aspekte und Tendenzen. In: Becker, J.; Jacob, H.; Krcmar, H. (Hrsg.): Integrierte Informationssysteme. Schriften zur Unternehmensführung. Band 44. Wiesbaden 1991; S. 3-18.
Krcmar, Schwarzer (Unternehmensmodellierung 1994) Krcmar, H.; Schwarzer, B.: Prozeßorientierte Unternehmensmodellierung - Gründe, Anforderungen an Werkzeuge und Folgen für die Organisation. In: Scheer, A.-W. (Hrsg.): Prozeßorientierte Unternehmensmodellierung. Schriften zur Unternehmensführung. Band 53. Wiesbaden 1994; S. 13-34.
Kroeber-Riel (Sprachkritik 1969) Kroeber-Riel, W.: Wissenschaftstheoretische Sprachkritik in der Betriebswirtschafts-lehre. Berlin 1969.
Kruchten (Rational 1998) Kruchten, P.: The Rational Unified Process: An Introductioni. Longman 1998.
Lamprecht (Datenaustausch 1998) Lamprecht, A.: Elektronischer Datenaustausch (EDI) in Verbundgruppen. Wiesbaden 1998.
Lehner (Integration 1994) Lehner, F.: Integration und Integrationsmodelle. WHU Koblenz, Lehrstuhl für Wirtschaftsinformatik. Forschungsbericht Nr. 17. Koblenz 1994.
Lehner, Maier (Information 1994) Lehner, F.; Maier, R.: Information in der Betriebswirtschaftslehre, Informatik und Wirtschaftsinformatik. WHU Koblenz, Lehrstuhl für Wirtschaftsinformatik. Forschungsbericht Nr. 11. Koblenz 1994.
Linß (Nutzeffekte 1995) Linß, H.: Integrationsabhängige Nutzeffekte der Informationsverarbeitung. Wiesbaden 1995.
Lorenz (Handlung 1995) Lorenz, K.: Handlung. In: Mittelstraß, J. (Hrsg.): Enzyklopädie Philosophie und Wissenschaftstheorie. Band 2. Stuttgart, Weimar 1995; S. 33-37.
Mehrtens (Vertriebsprozesse 2000) Mehrtens, M.: Konsumentenorientierte, interaktive Vertriebsprozesse in der Sanitärbranche: unterstütz durch die Integration von elektronischer Kommunikation und Multimedia. Berlin 2000.
Mertens u. a. (Grundzüge 1998) Mertens, P.; Bodendorf, F.; König, W.; Picot, A.; Schumann, M.: Grundzüge der Wirtschaftsinformatik. 5. Aufl.; Berlin u. a. 1998.
219
Mertens (Integration 1985) Mertens, P.: Zwischenbetriebliche Integration der EDV. In: Informatik-Spektrum 8 (1985) 2; S. 81-90.
Mertens, Holzner (Gegenüberstellung 1992) Mertens, P.; Holzner, J.: Eine Gegenüberstellung von Integrationsansätzen in der Wirtschaftsinformatik. In: Wirtschaftsinformatik 34 (1992) 1; S. 5-25.
Mertins, Süssenguth, Jochem (Modellierungsmethoden 1994) Mertins, K.; Süssenguth, W.; Jochem, R.: Modellierungsmethoden für die rechnerinte-grierten Produktionsprozesse: Unternehmensmodellierung, Software-Entwurf, Schnittstellendefinitonen, Simulation. München, Wien 1994.
Miebach, Schneider (Untersuchung 1994) Miebach, T.; Schneider, W.: Untersuchung zur Evaluierung des spezifischen Nutzens vorn EDIFACT auf Basis eines EDI-Implementationsmodells. In: Wirtschaftsinformatik 36 (1994) 6; S. 557-569.
Müller-Zantop (Perspektiven 1998) Müller-Zantop, S.: Neue Perspektiven für Logistiksysteme. In: Computer Woche Extra (1998) 1; S. 10-13.
Müller (Kontrollarchitekturen 1998) Müller, J.: Kontrollarchitekturen für autonome kooperierende Agenten. In: Informa-tionstechnik und technische Informatik 40 (1998) 4; S. 18-22.
Nederstigt (Konzeption 1996) Nederstigt, T.: Konzeption und prototypische Entwicklung eines Dictionaries zur Administration einer Unternehmensterminologie im Rahmen einer SAP R/3-Einführung. Universität Paderborn 1996.
Neuburger (Data 1994) Neuburger, R.: Electronic Data Interchange. Wiesbaden 1994.
Nonnenmacher (Informationsmodellierung 1994)Nonnenmacher, G.: Informationsmodel-lierung unter Nutzung von Referenzmodellen. Frankfurt a.M. 1994.
Normenausschuss Bibliotheks- und Dokumentationswesen (DIN1463 1987) Normenausschuss Bibliotheks- und Dokumentationswesen (NABD) im DIN Deutsches Institut für Normung e.V.: DIN 1463 Teil 1 - Erstellung und Weiterentwicklung von Thesauri - Einsprachige Thesauri. Berlin, Wien, Zürich 1987.
Normenausschuss Terminologie (DIN2331 1980) Normenausschuss Terminologie (NAT) im DIN Deutsches Institut für Normung e.V.: DIN 2331 - Begriffssysteme und ihre Darstellung. Berlin, Wien, Zürich 1980.
Oberweis (Modellierung 1996) Oberweis, A.: Modellierung und Ausführung von Workflows mit Petri-Netzen. Stuttgart 1996.
Oestereich (Softwareentwicklung 2001) Oestereich, B.: Objektorientierte Softwareentwicklung: Analyse und Design mit der Unified modeling language. 5. Aufl.; München, Wien 2001.
Ogden, Richards (Meaning 1969) Ogden, C.; Richards, I.: The Meaning of Meaning. 10. Aufl.; London 1969.
220
Olsen (Overview 2000) Olsen, G.: An Overview of B2B Integration. In: EAI Journal (2000) 5; S. 28-36.
Open Applications Group (Software 1999) Open Applications Group, G.: Component Software Integration. White Paper. ftp://ftp.openapplications.org/openapplications.org/whtpaper.zip, 1999-02, Abruf am 1999-06-16.
Ortner (Aspekte 1983) Ortner, E.: Aspekte einer Konstruktionssprache für den Datenbankentwurf. Darmstadt 1983.
Ortner (Repository 1999) Ortner, E.: Repository Systems. Teil 1: Mehrstufigkeit und Entwicklungsumgebung. In: Informatik-Spektrum 22 (1999) 4; S. 235-251.
o.v. (DIN2330 1979) o.V.: DIN 2330 - Begriffe und Benennungen. Berlin, Wien, Zürich 1979.
Peat, Webber (XML/EDI 1997) Peat, B.; Webber, D.: Introducing XML/EDI - the E-business framework. http://www.geocities.com/WallStreet/Floor/5815/start.htm, 1997, Abruf am 1998-04-23.
Petri (Integration 1990) Petri, C.: Externe Integration der Datenverarbeitung. Berlin u. a. 1990.
Picot (Organisation 1993) Picot, A.: Organisation. In: Bitz, M.; Dellmann, K.; Domsch, M.; Egner, H. (Hrsg.): Vahlens Kompendium der Betriebswirtschaftslehre. Band 2. 3. Aufl.; München 1993; S. 101-174.
Picot (Organisationsstrukturen 1993) Picot, A.: Organisationsstrukturen der Wirtschaft und ihre Anforderungen an die Informations- und Kommunikationstechnik. In: Scheer, A.-W. (Hrsg.): Handbuch des Informationsmanagements: Aufgaben, Konzepte, Praxislösungen. Wiesbaden 1993; S. 49-68.
Picot (Transaktionskostenansatz 1993) Picot, A.: Transaktionskostenansatz. In: Wittmann, W.; Kern, W.; Köhler, R.; Küpper, H.-U.; Wysocki, K. (Hrsg.): Handwörterbuch der Betriebswirtschaft. Teilband 3. R-Z. 5. Aufl.; Stuttgart 1993; S. 4194-4204.
Picot, Maier (Ansätze 1994) Picot, A.; Maier, M.: Ansätze der Informationsmodellierung und ihre betriebswirtschaftliche Bedeutung. In: Schmalenbachs Zeitschrift für betriebswirtschaftliche Forschung 46 (1994) 2; S. 107-126.
Picot, Maier (Information 1993) Picot, A.; Maier, M.: Information als Wettbewerbsfaktor. In: Informationsmanagement. SzU - Schriften zur Unternehmensführung. Bd. 49. Wiesbaden 1993.
Picot, Reichwald (Informationswirtschaft 1991) Picot, A.; Reichwald, R.: Informationswirtschaft. In: Heinen, E. (Hrsg.): Industriebetriebslehre - Entscheidungen im Industriebetrieb. 9. Aufl.; Wiesbaden 1991; S. 241-393.
221
Picot, Reichwald, Wigand (Unternehmung 1996) Picot, A.; Reichwald, R.; Wigand, R.: Die grenzenlose Unternehmung. 2. Aufl.; Wies-baden 1996.
Porter (Advantage 1985) Porter, M.: Competitive Advantage. New York 1985.
Porter (Wettbewerbsvorteile 1992)Porter, M.: Wettbewerbsvorteile: Spitzenleistungen er-reichen und behaupten. 3. Aufl.; Frankfurt/Main 1992.
Raffée (Grundprobleme 1995) Raffée, H.: Grundprobleme der Betriebswirtschaftslehre. 9. Aufl.; Göttingen 1995.
Reinhold (UML 1997) Reinhold, M.: Die UML und das standardisierte Prozeßmodell "V-Modell '97": Warum reicht eine Modellierungssprache alleine nicht aus. In: OBJEKTspektrum (1997) 5; S. 70-76.
Rodi (Semiotik 1989) Rodi, F.: Semiotik. In: Seiffert, H.; Radnitzky, G. (Hrsg.): Handlexikon zur Wissenschaftstheorie. München 1989; S. 296-302.
Rosemann (Komplexitätsmanagement 1996) Rosemann, M.: Komplexitätsmanagement in Prozeßmodellen. Methodenspezifische Gestaltungsempfehlungen für die Informationsmodellierung. Wiesbaden 1996.
RosettaNet (GTIN 1999) RosettaNet (Hrsg.): GTIN (Global Trade Item Number) - Implementation Guide for the Electronic Component an IT Supply Chain. http://www.rosettanet.org, 1999-08-16, Abruf am 2001-03-24.
RosettaNet (Implementation 2001) RosettaNet (Hrsg.): Implementation Methodology. www.rosettanet.org, 2001, Abruf am 2001-12-14.
RosettaNet (Purchase 2001) RosettaNet (Hrsg.): PIP3A4: Request Purchase Order. Release 2.0. www.rosettanet.org, 2001-12-07, Abruf am 2001-12-18.
RosettaNet (RosettaNet 1999) RosettaNet (Hrsg.): RosettaNet Messaging. www.rosettanet.org/press/rosettanetmessaging.html, 1999-12-01, Abruf am 2000-07-13.
RosettaNet (UML 1999) RosettaNet (Hrsg.): UML Extension for e-Business - Partner Interface Process Model-ling. Version: 0.5 Draft. http://www.rosettanet.org/RosettaNet/Doc/0/ H0SDJ61V5JA131130304UQ4J39/metamodel.zip, 1999-07-09, Abruf am 2001-01-24.
Rundshagen (Konsistenzsicherung 1996) Rundshagen, M.: Computergestützte Konsistenzsicherung in der objektorientierten Systemanalyse. Heidelberg 1996.
Scheckenbach (Geschäftsprozeßintegration 1997) Scheckenbach, R.: Semantische Geschäftsprozeßintegration - Einbindung zwischenbetrieblicher Geschäftsprozesse in betriebliche Anwendungssysteme. Wiesbaden 1997.
222
Scheer (Architektur 1992) Scheer, A.: Architektur integrierter Informationssysteme: Grundlagen der Unter-nehmensmodellierung. 2. Aufl.; Berlin u. a. 1992.
Scheer (ARIS-Modellierungsmethoden 1998) Scheer, A.: ARIS-Modellierungsmethoden, Metamodelle, Anwendungen. 3. Aufl.; Berlin u. a. 1998.
Scheer (ARIS 1998) Scheer, A.: ARIS - vom Geschäftsprozeß zum Anwendungssystem. 3. Aufl.; Berlin u. a. 1998.
Scheer (Wirtschaftsinformatik 1994) Scheer, A.: Wirtschaftsinformatik - Referenzmodelle für industrielle Geschäftsprozesse. 4. Aufl.; Berlin u. a. 1994.
Schissler u. a. (Unterstützung 2001) Schissler, M.; Mantel, S.; Ferstl, O.; Sinz, E.: Unterstützung von Kopplungsarchitekturen durch SAP R/3. Bayerischer Forschungsverbund Wirtschaftsinformatik, FORWIN-Bericht Nr. FWN-2001-008. Bamberg u. a. 2001.
Schlageter, Stucky (Datenbanksysteme 1983) Schlageter, G.; Stucky, W.: Datenbanksysteme: Konzepte und Modelle. 2. Aufl.; Stuttgart 1983.
Schlitt (Variantenmanagement 1997) Schlitt, M.: Variantenmanagement in transaktions- und objektorientierten Geschäftsprozeßmodellen. In: Informationssystem Architekturen 4 (1997) 1; S. 46-50.
Schmid (Kommunikationsmodelle 1992) Schmid, M.: Kommunikationsmodelle für Elektronische Märkte und mögliche Infrastrukturen zu deren Realisierung. Diss.; Hochschule St. Gallen 1992.
Schmidt (Wirtschaftslehre 1969) Schmidt, R.: Wirtschaftslehre der Unternehmung. Stuttgart 1969.
Schmoll (Handelsverkehr 1994) Schmoll, T.: Handelsverkehr, elektronisch, weltweit: Nachrichtenaustausch mit EDI/EDIFACT. Haar bei München 1994.
Schneider u. a. (Betriebswirtschaftslehre 1987) Schneider, P.; Zindel, M.; Lötzerich, R.; Münscher, W.: Betriebswirtschaftslehre für Industriekaufleute. 3. Aufl.; Darmstadt 1987.
Schneider (Einführung 1998) Schneider, T.: Einführung in XML - Teil 2: Die Praxis. In: edi-change (1998) 4; S. 53-54.
Schüppler (Informationsmodelle 1998)Schüppler, D.: Informationsmodelle für überbetrieb-liche Prozesse. Frankfurt a.M. 1998.
Schürmann (Rechnerverbindungsstrukturen 1997) Schürmann, B.: Rechnerverbindungsstrukturen. Braunschweig u. a. 1997.
Schütte (Grundsätze 1998) Schütte, R.: Grundsätze ordnungsmäßiger Referenzmodellierung. Wiesbaden 1998.
223
Schumann (Abschätzung 1990) Schumann, M.: Abschätzung von Nutzeffekten zwischenbetrieblicher Informationsverarbeitung. In: Wirtschaftsinformatik 32 (1990) 4; S. 307-319.
Sedran (Wettbewerbsvorteile 1991) Sedran, T.: Wettbewerbsvorteile durch EDI?. In: Information Management (1991) 2; S. 16-21.
Segev, Porra, Roldan (EDI 1997) Segev, A.; Porra, J.; Roldan, M.: Internet-Based EDI Strategy. Working Paper 97-WP-1021. http://haas.berkeley.edu/~citm/wp-1021.pdf, 1997, Abruf am .
Seiffert (Einführung 1997) Seiffert, H.: Einführung in die Wissenschaftstheorie. 4. Wörterbuch der wissenschaftstheoretischen Terminologie. München 1997.
Seubert u. a. (Datenmodellierung 1994) Seubert, M.; Schäfer, T.; Schorr, M.; Wagner, J.: Praxisorientierte Datenmodellierung mit der SAP-SERM-Methode. In: Ges. f. Informatik (Hrsg.): Entwicklungsmethoden für Informationssysteme und deren Anwendung. EMISA-Forum. Karlsruhe 19942.
Shannon, Weaver (Grundlagen 1976) Shannon, C.; Weaver, W.: Mathematische Grundlagen der Informationstheorie. München, Wien 1976.
SIMAC (XML-Problem 1999) SIMAC - Ad hoc Working Group on Simpl-EDI and Forms and Web based EDI: XML-Problem Statement. http://www.unece.org/trade/untdid/download/99cp13.pdf, 1999-03-04, Abruf am 1999-06-10.
Sinz (Architektur 1997) Sinz, E.: Architektur von Informationssystemen. In: Rechenberg, P.; Pomberger, G. (Hrsg.): Handbuch der Informatik. München, Wien 1997; S. 875-887.
Sinz (IS-Architekturen 1996) Sinz, E.: IS-Architekturen: Aktuelle Anforderungen und Entwicklungen. In: Informa-tionssystem Architekturen 3 (1996) 1; S. 1-5.
Smith, Smith (Database 1977) Smith, J.; Smith, D.: Database abstractions: aggregation and generalization. In: ACM Transaction on Database Systems 2 (1977) 2; S. 105-133.
Steel (Case 1995) Steel, K.: The Case for Next Generation EDI. ftp://turiel.cs.mu.oz.au/pub/edi/nextgen.doc, 1995-06-21, Abruf am 1998-01-29.
Steel (Guide 1997) Steel, K.: The BEACON User's Guide: Open Standards for Business Systems. ftp://turiel.cs.mu.oz.au/pub/edi/beaug1.doc, 1997-08-07, Abruf am 1998-03-04.
Steffen (Design 1999) Steffen, T.: Design zwischenbetrieblicher Prozesse. In: Fischer, J.; Kern, U. (Hrsg.): Objektorientierte Modelle und Werkzeuge für unternehmensübergreifende Informa-tionssysteme im Rahmen des Electronic Commerce. Köln 1999; S. 153-181.
224
Steffen (Internet-Quellen 2000) Steffen, T.: Internet-Quellen zu XML/EDI. In: Wirtschaftsinformatik 42 (2000) 1; S. 78-86.
Steffen (Modellierung 2000) Steffen, T.: Dezentrale Modellierung im Rahmen von EDI. In: Ebert, J.; Frank, U. (Hrsg.): Modelle und Modellierungsmethoden in Informatik und Wirtschaftsinformatik: Beiträge des Workshops 'Modellierung 2000'. St. Goar, 5.-7. April. Koblenz 2000; S. 41-54.
Steffen (XML/EDI 2001) Steffen, T.: XML/EDI Standardisierung: Ein Überblick. In: Turowski, K.; Fellner, K.J. (Hrsg.): XML in der betrieblichen Praxis: Standards, Möglichkeiten, Praxisbeispiele. Heidelberg 2001; S. 1-12.
Stegmüller (Hauptströmungen 1975) Stegmüller, W.: Hauptströmungen der Gegenwartsphilosophie - Eine kritische Ein-führung. Band 1. 5. Aufl.; Stuttgart 1975.
Steinmüller (Informationstechnologie 1993)Steinmüller, W.: Informationstechnologie und Gesellschaft: Einführung in die Angewandte Informatik. Darmstadt 1993.
Stern (Kommunikation 1997) Stern, A.: Verteilte Kommunikation. In: iX (1997) 3; S. 100-107.
Szyperski, Klein (Informationslogistik 1993) Szyperski, N.; Klein, S.: Informationslogistik und virtuelle Organisation. In: Die Betriebswirtschaft 53 (1993) 2; S. 187-208.
TMWG (Guide 1998) Techniques and Methodologies Working Group (TMWG): Reference Guide - The Next Generation of UN/EDIFACT (Revision 12). http://www.harbinger.com/resource/klaus/ tmwg/tm010.pdf, 1998-07-07, Abruf am 1998-08-27.
TMWG (UN/CEFACT 2001) Techniques and Methodologies Working Group (TMWG): UN/CEFACT Modelling Methodology. http://www.ebxml.org/project_teams/jdt/resources/ TMWG_N090R9.1.zip, 2001-04-04, Abruf am 2001-09-16.
Uschold, Gruninger (Ontologies 1996) Uschold, M.; Gruninger, M.: Ontologies: Principles, Methods and Applications. Tech-nical Report AIAI-TR-191. ftp://ftp.aiai.ed.ac.uk/pub/documents/1996/96-ker-intro-ontologies.ps.gz, 1996-02, Abruf am 1999-10-24.
Vetter (Objektmodellierung 1995) Vetter, M.: Objektmodellierung. Stuttgart 1995.
Vollmer (Integration 2000)Vollmer, K.: B2B Integration Options, Part 1: Evaluationg E-Channel Alternatives. http://www.gigaweb.com/Content_PDF/Pa/out/RPA-122000-00046.pdf, 2000-12-27, Abruf am 2001-08-27.
Vollmer, Bartels (Market 2000) Vollmer, K.; Bartels, A.: Market Overview: B2B E-Commerce and the Rise of Multiple Electronic Channels. http://www.gigaweb.com/Content_PDF/Pa/out/RPA-122000-00002.pdf, 2000-12-01, Abruf am 2001-08-27.
225
Wedekind u. a. (Modellierung 1998) Wedekind, H.; Görz, G.; Kötter, R.; Inhetveen, R.: Modellierung, Simulation, Visualisierung: Zu aktuellen Aufgaben der Informatik. In: Informatik-Spektrum 21 (1998) 5; S. 265-272.
Weiß (Agenten 1998) Weiß, G.: Agenten, Multiagentensysteme und Verteilte Künstliche Intelligenz - Eine einführende Literaturübersicht. In: Informationstechnik und technische Informatik 40 (1998) 4; S. 40-42.
Weizsäcker (Erstmaligkeit 1974) Weizsäcker, E.: Erstmaligkeit und Bestätigung als Komponenten der pragmatischen Information. In: Weizsäcker, E.v. (Hrsg.): Offene Systeme 1 - Beiträge zur Zeitstruktur von Information, Entropie und Evolution. 1974; S. 82-113.
Westarp u. a. (Status 1999) Westarp, F.; Weitzel, T.; Buxmann, P.; König, W.: The Status Quo And The Future Of EDI - Results Of An Empirical Study. http://caladan.wiwi.uni-frankfurt.de/westarp/ publ/webedi/WebEDI.htm, 1999, Abruf am 1999-07-23.
Wilhelm (Unterstützung 1997) Wilhelm, T.: Unterstützung der Auftragsabwicklung durch intelligente Agenten. In: Wirtschaftsinformatik (1997) 2; S. 161-169.
Williamson (Institutions 1985) Williamson, O.: The Economic Institutions of Capitalism: Firms, Markets, Relational Contracting. New York u. a. 1985.
Wittmann (Unternehmung 1959) Wittmann, W.: Unternehmung und unvollkommene Information. Köln, Opladen 1959.
Wöhe (Einführung 1996) Wöhe, G.: Einführung in die Allgemeine Betriebswirtschaftslehre. 19. Aufl.; München 1996.
Wüster (Einführung 1979) Wüster, E.: Einführung in die Allgemeine Terminologielehre und Terminologische Lexikographie. Wien 1979.
Yee (Chaos 2000) Yee, A.: Order Out of Chaos: Unterstanding B2B Integration Patterns. http://b2b.ebizq.net/ebiz_integration/yee_1.htm, 2000-11-01, Abruf am 2001-01-12.
Zachman (Framework 1987) Zachman, J.: A framework for information systems architecture. In: IBM Systems Jour-nal 26 (1987) 3; S. 277-293.
Zbornik (Märkte 1996) Zbornik, S.: Elektronische Märkte, elektronische Hierarchien, elektronische Netzwerke: Koordination des wirtschaftlichen Leistungsaustausches durch Mehrwertdienste auf der Basis von EDI und offenen Kommunikationssystemen. Konstanz 1996.
226
Zelewski (Bezugsrahmen 1995) Zelewski, S.: Petrinetzbasierte Modellierung komplexer Produktionsysteme. Band 2: Bezugsrahmen. Arbeitsbericht Nr. 6 des Instituts für Produktionswirtschaft und Industrielle Informationswirtschaft. Leipzig 1995.
Zelewski (Grundlagen 1999) Zelewski, S.: Grundlagen. In: Corsten, H.; Reiß, M. (Hrsg.): Betriebswirtschaftslehre. 3. Aufl.; München, Wien 1999; S. 1-126.
Zelewski (Märkte 1997) Zelewski, S.: Elektronische Märkte zur Prozeßkoordinierung in Produktionsnetzwerken. In: Wirtschaftsinformatik (1997) 3; S. 231-243.
Zelewski, Schütte, Siedentopf (Ontologien 1999) Zelewski, S.; Schütte, R.; Siedentopf, J.: Ontologien zur Strukturierung von Domänenwissen – Ein Annäherungsversuch aus betriebswirtschaftlicher Perspektive. http://www.wiwiss.fu-berlin.de/w3/w3schrey/KOMWIS/Beitraege/zelewski.htm, 1999, Abruf am 1999-10-24.
Zwicky (Entdecken 1989) Zwicky, F.: Entdecken, Erfinden, Forschen im morphologischen Weltbild. 2. Aufl.; München, Zürich 1989.
227
A Anhang
A.1 Zur Darstellung der Metamodelle in Kapitel 4
Die Modellierungssprache von MOVE wird in Kapitel 4 anhand von Metamodellen
spezifiziert. Die Darstellung dieser Metamodelle erfolgt mit einer speziellen Variante eines
Entity-Relationship-Modells (ERM).433 Die Grundelemente eines ERM, so wie es von CHEN
vorgeschlagen wurde,434 sind Entitytypen sowie Relationshiptypen. Unter Entitytypen werden
gleichartige Entities, d. h. Objekte (Gegenstände, Dinge) der realen oder gedanklichen Welt
zusammengefasst. Relationships (Beziehungen) sind Verknüpfungen von zwei oder mehreren
Entities. Gleichartige Relationships werden zu Relationshiptypen verallgemeinert. Sie halten
fest, in welcher semantischen Beziehung die Entitytypen zueinander stehen.
Die Komplexität435 eines Relationshiptyps gibt an, in welchem Verhältnis die Entities der
beteiligten Entitytypen zueinander in Beziehung stehen. In den verschiedenen Varianten von
ERM werden unterschiedliche Notationen für die Komplexität verwendet. In dieser Arbeit
wird die (1,c,m)-Notation in der Form, wie sie SCHLAGETER/STUCKY vorgeschlagen haben,436
verwendet. Die (1,c,m)-Notation ist eine verkürzte Schreibweise für die (min,max)-Notation.
Bei dieser Art der Notation wird angegeben, an wievielen Beziehungen eines
Relationshiptypen ein bestimmtes Entity eines zugeordneten Entitytypen minimal und
maximal beteiligt sein kann. Als Wertebereiche gelten für die (1,c,m)-Notation min = 0 oder
1 und max = 1 oder * (* bedeutet: beliebig viele)437 (vgl. Tab. A-1).
Anzahl der Beziehungen (min,max)-Notation (1,c,m)-Notation genau 1 (1,1) 1
maximal 1 (0,1) c(hoice) minimal 1; maximal beliebig (1,*) m(ultiple) minimal 0; maximal beliebig (0,*) cm
Tab. A-1 Notation der Komplexität
433 Ein Metamodell enthält die Konstruktionselemente der zu beschreibenden Modellierungssprache und ihre zulässigen Beziehungen untereinander. Da dies mit einem ERM darstellbar ist, sind ERM grundsätzlich zur Darstellung von Metamodellen geeignet. Vgl. Scheer (Architektur 1992), S. 19 434 Vgl. Chen (Entity-Relationship 1976) 435 Der Begriff ‚Komplexität‘ wird verwendet in Schlageter, Stucky (Datenbanksysteme 1983), S. 50ff.; Fischer (Datenmanagement 1992), S. 98; Ferstl, Sinz (Grundlagen 1998), S. 128. In der Literatur wird mitunter auch der Begriff ‚Kardinalität‘ verwendet. Vgl. beispielsweise Scheer (Wirtschaftsinformatik 1994), S. 41; Schütte (Grundsätze 1998), S. 94f. 436 Vgl. Schlageter, Stucky (Datenbanksysteme 1983), S. 50f. 437 Vgl. Schlageter, Stucky (Datenbanksysteme 1983), S. 51
228
Neben den Grundelementen werden in den ERM der Metamodelle die
Konstruktionsoperatoren438 Generalisierung bzw. Spezialisierung und Aggregation verwendet.
„Bei der Generalisierung werden Objekte als Subtypen unter einem Supertyp
zusammengefasst (Teilmengen zu Obermengen) bzw. aus einer Obermenge werden
Teilmengen abgeleitet (Spezialisierung) und es wird ein entsprechender Gattungsbegriff
zugewiesen.“439 Spezialisierungen können danach unterschieden werden, ob dabei disjunkte
oder nicht-disjunkte Teilmengen gebildet werden440 sowie ob eine totale oder eine partielle
Spezialisierung vorgenommen wird. Bei einer disjunkten Spezialisierung wird jedes Objekt
eines Supertypen zu genau einem Objekt eines Subtypen spezialisiert.441 Bei nicht-disjunkten
Teilmengen kann ein Objekt des Supertyps mehreren Subtypen zugeordnet werden. Wenn
jedes Objekt eines Supertypen zu einem Objekt eines Subtypen spezialisiert wird, so handelt
es sich um eine totale Spezialisierung, andernfalls um eine partielle.442
Die Zusammenfassung unterschiedlicher Entitytypen zu einem neuen Typ wird als
Aggregation bezeichnet.443 Relationshiptypen können als solche Aggregationen aufgefasst
werden, da sie in diesem Sinn die mit ihnen verbundenen Entitytypen zusammenfassen. Sie
können allerdings auch auf einer höheren Ebene als Entitytypen aufgefasst werden und damit
selbst wieder Ausgangspunkt für weitere Relationships sein.444 Die Uminterpretation solcher
Relationshiptypen in Entitytypen wird grafisch durch eine mit einem Rechteck umrandete
Raute dargestellt.445 Die weiteren grafischen Elemente der verwendeten ERM-Variante
werden zusammenfassend in Abb. A.1 dargestellt.
438 Zum Begriff der ‚Konstruktionsoperatoren‘ vgl. Fischer (Datenmanagement 1992), S. 125ff. 439 Fischer (Datenmanagement 1992), S. 126. Zur Generalisierung bzw. Spezialisierung vgl. auch Smith, Smith (Database 1977), S. 107ff. 440 Vgl. Fischer (Datenmanagement 1992), S. 127; Scheer (Wirtschaftsinformatik 1994), S. 37. FERSTL/SINZ sprechen im Falle einer disjunkten Generalisierung von einer Generalisierungshierarchie, im Falle einer nicht-disjunkten Generalisierung von einer Subtypenhierarchie. Vgl. Ferstl, Sinz (Grundlagen 1998), S. 138 441 Schütte (Grundsätze 1998), S. 97 442 Vgl. Schütte (Grundsätze 1998), S. 97 443 Vgl. Smith, Smith (Database 1977), S. 107ff. 444 Vgl. Scheer (Wirtschaftsinformatik 1994), S. 38 445 Vgl. Scheer (Wirtschaftsinformatik 1994), S. 38f.
229
Entitytyp Relationshiptyp
Aggregation D/N,T/P Generalisierung/Spezialisierung
D disjunkte SpezialisierungenN nicht-disjunkte Spezialisierungen
T totale SpezialisierungenP partielle Spezialisierungen
Abb. A.1 Verwendete Notation in den ERM der Metamodelle
Zur besseren Lesbarkeit der Metamodelle erfolgt die Anordnung der grafischen Elemente
nach folgenden Regeln:
Kanten führen nur von rechts aus einem Entitytypen heraus und nach links hinein. Die Entity-
und Relationshiptypen werden derart plaziert, dass der Grad an Existenzabhängigkeit von
links nach rechts zunimmt.446 Ein Entitytyp ist von einem Relationshiptyp (einseitig, total)
existenzabhängig, wenn der min-Wert der Komplexität 1 beträgt.447 In diesem Fall wird der
Entitytyp rechts vom Relationshiptyp angeordnet, andernfalls links. Spezialisierungen werden
grundsätzlich rechts unterhalb des Supertyps angeordnet.448 Dabei wird jeweils die
Bezeichnung des Supertyps übernommen und in einer weiteren Zeile die Bezeichnung des
spezialisierten Subtyps hinzugefügt.
446 Diese Regel wird in den strukturierten Varianten des ERM (SERM, SAP-SERM) verfolgt. Vgl. Seubert u. a. (Datenmodellierung 1994), S. 73; Ferstl, Sinz (Grundlagen 1998), S. 141ff. 447 Vgl. Ferstl, Sinz (Grundlagen 1998), S. 143 448 Dort, wo es zweckmäßig erscheint, wird auf die Einhaltung dieser Regel verzichtet.
230
A.2 Detaillierte Bewertung vorhandener Modellierungsansätze
Anforderung im wesentlichen erfüllt
Anforderung teilweise erfüllt
Anforderung nicht erfüllt
- Nicht feststellbar
Tab. A-2 Legende zur Bewertung der vorhandenen Modellierungsansätze
A.2.1 Inhaltliche Anforderungen
Normung Praxis Wissenschaft
Anforderung Open-EDI
UMM RosettaNet
Funsoft
Henkel
Schüppler
MOVE
Leistungs-, Zahlungs-, Informationsflüsse
Leistungs-, Zahlungs-, Informationsobjekte
Was? (Gegenstand)
Zuordnung Flüsse-Objekte
Akteure -
Rollen
Zuordnung Akteur-Rolle-Transaktion -
Wer? (Akteure)
Zuordnung Akteur-Rolle-Fluss -
Zeitliche Folge von Flüssen
Wann? (Zeitliche Struktur)
Absolute und relative Zeitangaben - -
Alternative Ver-knüpfungen von Flüssen (Ablaufvarianten)
Kanäle
Medien
Zuordnung Kanal-Medium-Informationsobjekt-Informationsfluss
Wie? (Art und Hilfsmittel)
Zuordnung Kanal-Akteur
Phasen von Trans-aktionen
Zweck von Informationsflüssen
Beschreibung von Strukturen und Abläufen
Wozu? (Zweck)
Bezug von Informationsobjekten
Tab. A-3 Bewertung der inhaltlichen Anforderungen (Teil I)
231
Normung Praxis Wissenschaft
Anforderung Open-EDI
UMM RosettaNet
Funsoft
Henkel
Schüppler
MOVE
Ableiten der Nachrichtenstruktur
Integrierte Modelle zu Transaktionen, zu Informationsflüssen und zu Nachrichtenstrukturen
Hierarchisch strukturierte Informationsobjekte
Datenelemente
Nachrichtenstrukturen
Festlegen der Nachrichten-struktur
Zuordnung Datenelement-Informationsobjekt
Syntaktische Konvertierung
Syntaktische Angaben zu Datenelementen
-
Regeln -
Verknüpfung Datenelement-Regeln
Fachliche Aufgaben einer Integration - Unterstützung der syntaktischen und semantischen Integration
Semantische Prüfung
Zuordnung Informationsobjekt-Transaktion
Reihenfolge-beziehungen von Flüssen
Allgemeine Anforderungen der pragmatischen Integration Nebenläufigkeit von
Flüssen
Rollen von Informationsobjekten
Zweck von Informationsobjekten
Ereignisse
Anwendungssysteme
Funktionen
Zuordnung Anwendungssystem-Funktion
Zuordnung Fluss-Ereignis-Funktion
Verknüpfung von Flüssen über Regeln -
Fachliche Aufgaben einer Integration - Unterstützung der pragmatischen Integration Aktions-/
Reaktions-mechanismen
Zuordnung Fluss-Ereignis
Tab. A-4 Bewertung der inhaltlichen Anforderungen (Teil II)
232
A.2.2 Formale Anforderungen
Normung Praxis Wissenschaft
Open-EDI
UMM RosettaNet
Funsoft
Henkel
Schüppler
MOVE
Metamodell -
Grafische Notation
Vorgehensweise -
Vollständigkeit der Modellierungs-methode
Werkzeugunterstützung -
Unabhängig von Nachrichtenformaten
Implementierungs-unabhängigkeit
Unabhängig von Programmiersprachen
Hohe Einsatzbreite branchenunabhängig
Allgemeine Anforderungen
Hohe Einsatztiefe Keine Beschränkung auf spezielle Trans-aktionen
Sprachadäquanz (Spracheignung)
Inhaltliche Anfor-derungen erfüllt
Unterschiedliche Sichten für Struktur und Verhalten
Systematischer Aufbau
Integriertes, sichten-übergreifendes Metamodell
-
Einfache Darstellungsmittel -
Per Hand zeichenbar -
Hierarchisierung von Modellen
Modellierungssprache
Klarheit
Materiellorientiertes Deutungsmuster
Konstruktions-adäquanz
Referenzgestütztes Vorgehen (standardisierte Fachkonzepte)
-
Sprachadäquanz (Sprachrichtigkeit)
Checklistenform der Vorgehensweise
Ontologiebasiertes Vorgehen
Vergleichbarkeit
Referenzgestütztes Vorgehen (standardisierte Bezeichnungen)
-
Klarheit Regeln zur Layoutgestaltung -
Vorgehensweise
Wirtschaftlichkeit Referenzgestütztes Vorgehen -
Tab. A-5 Bewertung der formalen Anforderungen
233
A.3 Berücksichtigte EANCOM-Nachrichtentypen
Beteiligte Klienten EANCOM- Nachrichtentyp (-->)
EANCOM - Nachrichtentyp (<--)
Käufer - Verkäufer • QUOTES (Angebot) • ORDRSP (Bestellantwort)• DESADV
(Liefermeldung) • INVOIC (Rechnung) • COACSU
(Geschäftskontoauszug)
• REQOTE (Anfrage) • ORDERS (Bestellung) • ORDCHG
(Bestelländerung) • DELFOR (Lieferplan/
Lieferabruf)
Hersteller/Handel - Bank • PAYMUL (Multipler Zahlungsauftrag)
• CREMUL (Multiple Gutschriftsanzeige)
• DEBADV (Belastungs-anzeige)
Warensender - Spediteur449 • IFTMIN (Transport-/ Speditionsauftrag)
• IFTSTA (Multimodaler Statusbericht)
Leistungsempfänger - Spediteur450
• IFTMAN (Ankunftsmeldung/ Empfangsbestätigung)
• (Übergabeschein)
Tab. A-6 Berücksichtigte EANCOM-Nachrichtentypen
449 Vgl. Henkel (Gestaltung 1996), S. 173 450 Vgl. Henkel (Gestaltung 1996), S. 173
234
A.4 Attributtypen und Datenfelder
Attributtyp Datenfeld Datentyp OAGIS-Segment BSR-Property Class
Zeitpunkt DateTime Date / Time / DateAndTime
Jahr Integer[4] Year - Monat Integer[2] Month - Tag Integer[2] Day - Stunde Integer[2] Hour - Minute Integer[2] Minute - Sekunde Integer[2] Second - Zeitzone String TimeZone - Betrag Amount Amount Wert LongInteger Value - Dezimalstellen Integer[1] NumOfDec - Vorzeichen Boolean Sign - Währung String Currency - Preis OperAmt Amount Wert LongInteger Value - DezimalstellenWert Integer[1] NumOfDec - Vorzeichen Boolean Sign - Währung String Currency - Preisbasis LongInteger UOMValue - DezimalstellenPreisbasi
s Integer[1] UOMNumDec -
WährungPreisbasis String UOM (Unit of Measure)
-
Menge Quantity Quantity Wert LongInteger Value - Dezimalstellen Integer[1] NumOfDec - Vorzeichen Boolean Sign - Mengeneinheit String UOM - Code - Code Codeliste String - - Codeeintrag String - - Bezeichnung String - Name ID - Identifier IdAngabe String Verwalter String Nummer String Number Text String - Text - - Rate - - Percent - - Value - - Indicator
Tab. A-7 Attributtypen und Datenfelder