Modellierungsmethode zur Integration zwischenbetrieblicher...

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


system


system



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


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


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


(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


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


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.


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.


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


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


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



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


Interaktion


Objekt


Kanal

Ontol. KlasseBeschr. Element

Rolle


Attribut



OntologischeKlasse


RolleObjektrolle


RolleKlientenrolle

D,TD,T

D,T

D,TOntol. Klasse

EntwurfselementInteraktion

LeistungsinteraktionD,T

D,T


InteraktionInformationsinteraktion


InteraktionZahlungsinteraktion


ObjektLeistungsobjekt


ObjektInformationsobjekt


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


Klient


Interaktion


Objekt


Kanal


Rolle


Attribut


RolleObjektrolle


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


Klient


Interaktion


Objekt


Kanal

D,T


(=Referenzklasse)D,T

istzugeordnet

cm

cm


typisiertesAttribut

cm m


Aggregation

cm

cm

D,T

steht inBeziehung

zu

übergeordnet

untergeordnet


Rolle


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


Klient


Interaktion


Objekt


Kanal


Attribut

D,T

Ontol. KlasseEntwurfselementD,T

cm

cm

D,P


typisiertesAttribut

cm

m

cm m

Datenfeldbesteht aus

m

1

Nachrichten-baustein

istzugeordnet

istzugeordnet

daraus wirdabgeleitet

daraus wirdabgeleitetm

m

1


Rollecm daraus wird

abgeleitet

c

1


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


Klient


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


ObjektInformationsobjekt

Objekt

istzugeordnetcm

m

1

1

istzugeordnetcm 1Ontol. Klasse

EntwurfselementObjekt


RolleObjektrolle

Interaktion





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


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


Klient


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:



• 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


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




Objekt

m

1

istzugeordnetcm 1


RolleObjektrolle

cmcm

istzugeordnetcm 1


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:



• 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


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



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


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


FormalsprachlicheModellkonstruktion


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


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


+Name : Bezeichnung-ID_KF : ID-ID_VK : ID-ID_RS : ID-ID_RE : ID-ID_AG : ID

Bankverbindung


Kontaktangaben


Verkaufsabteilung

Abteilung


Einkaufsabteilung

Buchhaltung

Versandstelle


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


Privates Unternehmen Kontaktangaben


Verkaufsabteilung

Abteilung


Einkaufsabteilung

Buchhaltung



Versandstelle


Grosshandelszentrale


Dienstleistungsunternehmen Sachleistungsunternehmen

Handelsunternehmen

Großhandelsunternehmen

Verarbeitungsunternehmen

Unternehmen

-ILN : ID

Abb. 5.10 Referenzklassendiagramm für Klienten (Ausschnitt)


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






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


LE

AllBuy-Zentrale


AGREZS

HerstellerANRSLSZE


D: Waren abrufen (Leistungen anfordern)opt.







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


LE

AllBuy-Zentrale


AGREZS

HerstellerANRSLSZE









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


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


HerstellerANRSLSZE


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


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



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


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





Rechnung senden(Sammelrechnung/Rechnung)

AllBuy-Zentrale


Hersteller


vorgelagert

begleitend

nachgelagert

AllBuy-Filiale

Herstellermax24h

min6h

max1h

max30T.

Hersteller

AllBuy-Filiale



AllBuy-Zentrale


Hersteller


begleitend

nachgelagert

AllBuy-Zentrale

Hersteller

AllBuy-Zentrale



AllBuy-Filiale

Hersteller


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)




AllBuy-Zentrale


Hersteller


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



Prüfenx = Rechnung.Summenangaben._

MWStVoll:Betrag ?

Status meldenAbbruch: Betrag fehlerhaft !

Status meldenErfolg: Betrag korrekt !

FALSETRUE



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


(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


(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


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


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


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


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.

http://www.scientificamerican.com/2001/0501issue/0501berners-lee.html

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


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


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


Anforderung Open-EDI

UMM RosettaNet

Funsoft

Henkel

Schüppler

MOVE


Integrierte Modelle zu Transaktionen, zu Informationsflüssen und zu Nachrichtenstrukturen

Hierarchisch strukturierte Informationsobjekte

Datenelemente

Nachrichtenstrukturen

Festlegen der Nachrichten-struktur

Zuordnung Datenelement-Informationsobjekt


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


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

Modellierungsmethode zur Integration zwischenbetrieblicher...

Documents

Transcript of Modellierungsmethode zur Integration zwischenbetrieblicher...