Objektorientierte Modellierung zwischenbetrieblicher Prozesse

Objektorientierte Modellierung
zwischenbetrieblicher Prozesse
Dipl.-Wirt. Inform. Thomas Steffen
Prof. Dr. Joachim Fischer
Universität-Gesamthochschule Paderborn, Schwerpunkt Wirtschaftsinformatik 1
Warburger Str. 100, 33098 Paderborn
e-mail:{steffen | fischer}@wior.wiwi.uni-paderborn.de
Zusammenfassung
Im Zuge der Bemühungen um die Verbesserung unternehmensübergreifender Geschäftsprozesse gewinnt der elektronische
Austausch von Daten oder Electronic Data Interchange (EDI) an Bedeutung. Jedoch konnte sich EDI in seiner
heutigen Form aus einer Reihe von Gründen, die im vorliegenden Beitrag genannt werden, bislang nicht entscheidend
durchsetzen. Es wird daher vorgeschlagen, die Planung und Gestaltung des unternehmensübergreifenden Informationsaustausches
durch eine Modellierung zwischenbetrieblicher Prozesse zu unterstützen. Ein entsprechender Ansatz wird
vorgestellt, der auf einem objektorientierten Bezugsrahmen basiert. Er sieht drei Detaillierungsebenen (Prozess-,
Interaktions- und Informationsstrukturdiagramme) sowie eine Referenzbibliothek für die Modellierung vor. Vor dem
Hintergrund der Modellierungsergebnisse werden die auszutauschenden Nachrichten spezifiziert. Dabei werden neben
den rein statischen Datenstrukturen auch die für die automatische Weiterverarbeitung notwendigen Methoden zur
Integritätsprüfung und Konvertierung berücksichtigt. Es wird dargelegt, welches Nutzenpotential eine solche
Modellierung zwischenbetrieblicher Prozesse beinhaltet.
1 Ausgangslage und Zielsetzung
Die Verbesserung von unternehmensübergreifenden Wertschöpfungsketten, wie sie mit Konzepten
des Efficient Consumer Response (ECR) oder Supply Chain Managements (SCM) angestrebt
werden, erfordern eine erhöhte zwischenbetriebliche Kommunikation. Es müssen vermehrt informierende
und koordinierende Geschäftsdaten ausgetauscht werden. Der elektronische Austausch
von Daten oder Electronic Data Interchange (EDI) gewinnt in diesem Rahmen an Bedeutung und ist
ein wesentlicher Bestandteil von ECR- sowie SCM-Projekten [FiSt98] / [Hage96]. Doch EDI in
seiner heutigen Form konnte sich bislang nicht durchsetzen, da viele potentielle Anwender die
langen Projektlaufzeiten einer EDI-Implementierung scheuen. Folgende Gründe werden für die
mangelnde Verbreitung des EDI-Einsatzes gesehen:

Semantische Probleme
Vorhandene EDI-Standards (wie z.B. EDIFACT, SEDAS, ANSI X12) 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 [Sche97] / [Schü98]. Der Vorteil der Präzisierung durch
Bilden von Subsets führt andererseits zu Inkompatibilitäten zwischen verschiedenen Branchen und
Benutzergruppen. Dies erfordert eine zeitaufwendige Verständigung zwischen den Marktpartnern
über die Bedeutung der auszutauschenden Daten.
Mangelnde Flexibilität der EDI-Standards
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 Prozesse häufig aufgrund veränderter Verbraucherwünsche,
staatlicher Vorschriften etc.. Ein anderer Aspekt ist, dass durch die vorgegebenen Strukturen der
Standardformate geringere Freiheitsgrade hinsichtlich einer Realisierung spezifischer, an der
Schnittstelle zwischen Unternehmen zum Ausdruck kommender Kernkompetenzen bestehen
[Schü98].
Hoher Integrationsaufwand
Bezüglich der Korrektheit und Sicherheit von Daten besteht an der Schnittstelle zwischen Unternehmen
eine hohe Sensibilität [Schü98]. Für eine automatisierte Weiterverarbeitung der ausgetauschten
Nachrichten müssen daher eine Vielzahl von Prüf- und Kontrollprozeduren implementiert
werden. Der komplexe Aufbau der EDI-Regelwerke erfordert weitere umständliche
Konvertierungsprozeduren. Nachteilig für die semantische Integration zwischenbetrieblicher
Nachrichten ist weiterhin, dass vorhandene EDI-Konverter in der Regel nur einzelne Nachrichten
verarbeiten und keine langen Transaktionen unterstützen. Nachrichtenübergreifende Integritätsprüfungen
finden in der Regel nicht statt [Ster97].
Mangelnde Transparenz und fehlende Werkzeuge
Für eine effektive und effiziente zwischenbetriebliche Kommunikation auf elektronischem Wege
sind die Geschäftsprozesse und deren Informationsflüsse unternehmensübergreifend zu gestalten
und aufeinander abzustimmen. Es muss festgelegt werden, wer mit wem wann und zu welchem
Zweck miteinander kommuniziert. Die Planung und Gestaltung der zwischenbetrieblichen
Informationsflüsse ist kein einmaliges Projekt, sondern ständigen geschäftlichen, organisatorischen
und technischen Änderungen unterworfen [Fisc99a]. Unternehmen verlassen einen Informations-

verbund, neue Partner kommen hinzu. Der schnelle technologische Fortschritt bewirkt einen
häufigen Austausch vorhandener DV-Komponenten. Jedesmal sind die Geschäftsprozesse sowie
Informationssysteme erneut aufeinander abzustimmen. Es fehlen bislang Techniken und Werkzeuge
zur Komplexitätsbewältigung einer solchen Planungs- und Gestaltungsaufgabe [HiSc94] / [Müll98]
/ [Schü98].
Im vorliegenden Beitrag soll dargelegt werden, wie eine objektorientierte Modellierung zwischenbetrieblicher
Prozesse den unternehmensübergreifenden Informationsaustausch unterstützen und zur
Lösung der angesprochenen Probleme beitragen kann. Der Modellierungsansatz ist im Rahmen des
BMBF-Verbundprojektes „MOVE - Modellierung einer Verteilten Architektur für die Entwicklung
unternehmensübergreifender Informationssysteme und ihre Validierung im Handelsbereich“
[MOVE95] / [FiKe+98] entwickelt worden.
2 Der Modellierungsansatz im Überblick
2.1 Aufbau
Grundgedanke des Ansatzes ist es, dass sich zwischenbetriebliche Nachrichten auf bestimmte
Gegenstände und Objekte der realen Welt beziehen. Diese reale Welt wird zunächst mit Hilfe des
Modellierungsansatzes rekonstruiert. Im weiteren werden die Nachrichteninhalte auf Basis der
Modellierungsergebnisse festgelegt.
Input
Z.B. geschäftsprozessorientierte Simulation
analysierte und bewertete
Prozessstrukturen
Referenzklassen,
Rollen
Informationsbausteine
1.
2.
Prozessdiagramme
Interaktionsdiagramme
3.
Informationssstrukturdiagramme
Modellbibliothek
Referenzbibliothek
Modellierungsergebnisse
Prototyp: Objektorientiertes Entwurfsinstrument
Output
abgestimmte Nachrichtenstrukturen für einen
zwischenbetrieblichen Prozess
Abbildung 1: Vorgehen des Modellierungsansatzes

Der Ansatz verfolgt ein Top-down-Vorgehen, das für die Beschreibung zwischenbetrieblicher
Prozesse drei Detaillierungsebenen vorsieht (vgl. Abbildung 1). Zunächst werden in einem Prozessdiagramm
sämtliche beteiligten Unternehmen sowie die Interaktionen eines zwischenbetrieblichen
Prozesses aufgeführt. Ausgangspunkt einer effektiven und effizienten Prozessgestaltung kann z.B.
eine vorgelagerte geschäftsprozessorientierte Simulation sein, wie sie im Rahmen des erwähnten
Forschungsprojekts entwickelt worden ist [HlHo99]. Die Geschäftsbeziehungen jeweils zweier
Unternehmen werden durch Interaktionsdiagramme detaillierter beschrieben. Ziel des Ansatzes ist
letztendlich die Spezifikation der auszutauschenden Nachrichten mittels Informationsstrukturdiagrammen,
in denen nicht nur die Informationselemente festgelegt werden, sondern auch die
erforderlichen Integritätsmethoden. Der betriebswirtschaftliche Kontext, in dem die Nachrichten
verwendet werden, wird dabei durch die Diagramme der beiden höheren Ebenen festgelegt.
Grundlage der Modellierung sind Referenzklassen, Rollen sowie Informationsbausteine, die in einer
Referenzbibliothek bereitgestellt werden. Die Modellierungsergebnisse werden in einer Modellbibliothek
abgelegt. Der Ansatz wird durchgehend durch ein objektorientiertes Entwurfsinstrument,
welches prototypisch implementiert worden ist, unterstützt.
2.2 Objektorientierter Bezugsrahmen
Generell steht für die Modellierung ein struktur- oder objektorientiertes Vorgehen zur Auswahl
[Fisc99a] / [Fisc99b]. In der industriellen Praxis sind die strukturierten Methoden etabliert und weit
verbreitet [Stei97] / [Quib94]. Allerdings gilt das Interesse der Forschung heute eher den
objektorientierten Ansätzen. Ihnen wird „aufgrund der Durchgängigkeit zwischen Real- und
Systemwelt und aufgrund der Kapselung zu autonomen [...] Komponenten die größere Eleganz
zuerkannt“ [Fisc99b] / [Stei97]. Für die Modellierung zwischenbetrieblicher Prozesse ist daher der
in Abbildung 2 dargestellte objektorientierte Bezugsrahmen entwickelt worden. Gemäß dem
Objektansatz wird eine Sichtweise verfolgt, der die Gegenstände der Realität als Ganzheit aus
Materie und Informationen sowie aus zugehörigen Methoden versteht, die gegenüber der Umwelt
gekapselt sind [MOVE95]. Die Betrachtung von zwischenbetrieblichen Prozessen führt zu den
Entwurfselementen Klient, Interaktion, Objekt und Kanal. Unternehmen, Haushalte sowie staatliche
und wirtschaftliche Institutionen - im Bezugsrahmen als Klienten bezeichnet - tauschen Leistungs-,
Zahlungs- und Informationsobjekte untereinander aus. Die Übertragung von Leistungen, Zahlungen
oder Informationen eines Klienten zu einem oder mehreren anderen Klienten wird als Interaktion
bezeichnet. Sie werden durch den Gegenstand der Interaktion, das Objekt und den zur Realisierung
notwendigen Kanal näher bestimmt.

Entwurfselemente
Klient Objekt Interaktion Kanal
Struktur Statische Elemente Dynamische Elemente
Verhalten Aktiv Passiv Aktiv Passiv
Beschreibende
Komponenten
• Attribute
• Rollen
• Attribute
• Methoden
• Attribute
(Methoden)
Strukturkomponenten
Kurzbeschreibung
Beispiele
Notation
• Attribute
• Rollen
• Methoden
Stellen Regeln auf
und veranlassen
Interaktionen
• Industrieunternehmen
• Handelsunternehmen
• Handwerker
• Banken
• (Methoden)
• Generalisieren / Spezialisieren (is a)
• Gruppieren (is member of)
• Verknüpfen (is part of)
sind Gegenstand
von Interaktionen
• Produkte
• Zahlungsmittel
• Nachrichten
Austausch von
Leistungen, Geld
oder Informationen
• Liefern
• Überweisen
• Beauftragen
Informationen
Zahlungen
Leistungen
bilden zulässige
Wege für Interaktionen
• Transportwege
• Vertriebskanäle
• Kommunikationswege
bzw.
Abbildung 2: Objektorientierter Bezugsrahmen (vgl. [Fisc99a])
3 Referenzen für die Modellierung
Die zu erstellenden Diagramme sollen zur Transparenz und zum Verständnis der zwischenbetrieblichen
Prozesse beitragen und bilden insbesondere die Grundlage des zwischenbetrieblichen
Informationsaustausches. Daher ist es wichtig, dass die Marktpartner dieselben Sprachmittel zur
Beschreibung der Prozesse und Nachrichten verwenden. Aus diesem Grund dürfen die Entwurfselemente
Klient, Interaktion, Objekt und Kanal nicht frei modelliert werden, sondern sollten aus
einem standardisierten und von allen beteiligten Unternehmen akzeptierten Verzeichnis stammen.
Ein solches Verzeichnis wurde im Rahmen des erwähnten Forschungsprojekts in Form einer
Referenzbibliothek aufgebaut (vgl. Abbildung 3). Dazu wurden die materialen, d.h. geschäftsprozessrelevanten
Eigenschaften der Entwurfselemente in der zugrundegelegten Geschäftswelt
untersucht. Diese exemplarisch für die Lebensmittelbranche durchgeführte statische, strukturorientierte
Analyse führte zu Referenzklassen, die in Klassendiagrammen beschrieben werden. Die
dynamische, prozessorientierte Betrachtung führte zu einem Katalog der Rollen, die die Entwurfs-

elemente im Rahmen zwischenbetrieblicher Prozesse ausüben können. Im weiteren werden in der
Referenzbibliothek Informationsbausteine der Dimensionen Markt-, Technik- und Geschäftsverkehrsinformationen
bereitgestellt. Diese Bausteine können aus den Referenzklassen und Rollen
abgeleitet werden.
Objektorientierte
Entwurfselemente für
Branche präzisieren
statisch,
strukturorientiert
dynamisch,
prozessorientiert
Referenzbibliothek
Nachrichtenformate
(z.B. EANCOM)
prozessorientiert
analysieren und
semantisch präzisieren
in den Dimensionen:
• Geschäftsverkehr
• Markt
•Technik
Referenzklassen
Attribute
ableiten
Rollen
Informationsbausteine
Abbildung 3: Konstruktion der Referenzbibliothek
3.1 Referenzklassen
Aus Sichtweise des objektorientierten Bezugsrahmens stellen die Entwurfselemente Klient, Interaktion,
Objekt und Kanal jeweils Klassen dar. In der Referenzbibliothek werden Referenzklassen in
vier Klassendiagrammen bereitgestellt: es gibt jeweils ein Klassendiagramm für Klienten, Interaktionen,
Objekte und Kanäle. In den Klassendiagrammen werden die objektorientierten Konzepte
Attributzuordnung, Aggregation, Generalisierung und Vererbung nach betriebswirtschaftlichen
Kriterien der betrachteten Geschäftswelt angewendet. Als Beschreibungssprache der Klassendiagramme
dient die Notation für UML-Klassendiagramme [Rati97].
Bestandteil eines Klassendiagramms ist zunächst einmal eine Generalisierungs-/Spezialisierungshierarchie,
ausgehend von einer allgemeinen, abstrakten Klasse des jeweiligen Entwurfselementes
(Klient, Interaktion, Objekt oder Kanal). Durch eine Generalisierungs-Spezialisierungsbeziehung
werden Klassen als Subklassen (z.B. Handelsunternehmen, Transportunternehmen, Banken,
Versicherungen) unter einer Superklasse (z.B. Dienstleistungsunternehmen) zusammengefasst
[Fisc92] / [CoYo91]. Die Klassen, die Element dieser Generalisierungs-/Spezialisierungshierarchie
sind, sollen als Grundklassen bezeichnet werden.
Grundklassen werden durch Attribute näher beschrieben. Diese können durch eine geschäfts-

prozessorientierte Analyse aus den atomaren Informationselementen vorhandener Nachrichtenformate
(wie z.B. EANCOM) abgeleitet und sollten semantisch präzisiert werden. Sie stellen damit
die im Rahmen zwischenbetrieblicher Informationsprozesse relevanten und bedeutsamen Eigenschaften
der Entwurfselemente dar und sind Grundlage für die auszutauschenden Informationselemente
zwischen den Klienten (vgl. Abschnitt 4.4). Jedem Attribut ist eine eindeutige und
betriebswirtschaftlich unmissverständliche Bezeichnung zugeordnet.
Mehrere Attribute, deren Zusammenfassung eine semantisch sinnvolle Einheit darstellt, bilden
eigene Klassen, die als Attributklassen bezeichnet werden sollen. Beispiele für solche Attributklassen
sind Anschrift, Bankverbindung, Preisangabe. Diese Attributklassen können über
Aggregationsbeziehungen [CoYo91] den Grundklassen oder weiteren Attributklassen zugeordnet
werden. Ebenso wie Grundklassen können auch Attributklassen generalisiert bzw. spezialisiert
werden.
Sind zwei Klassen (Grund- oder Attributklassen) über eine Generalisierungs-
/Spezialisierungsbeziehung miteinander verbunden, so werden sämtliche Attribute sowie
Aggregationsbeziehungen der Superklasse an die Subklasse vererbt.
Unter Anwendung der beschriebenen objektorientierten Konzepte wurde je Entwurfselement ein
Referenzklassendiagramm erstellt. Die folgende Abbildung zeigt einen Ausschnitt des Klassendiagramms
für Klienten (vgl. Abbildung 4).
Klient
+Name : Name
-ID, vom Käufer vergeben : Identifizierung
-ID, vom Verkäufer vergeben : Identifizierung
Wirtschaftliche Institution
Einzelperson
-Telefonnummer : Nummer
-Geburtsdatum : Zeitangabe
-Kundennummer : Identifizierung
Einzelhandelsfiliale
Grosshandelszentrale
Unternehmen
Industrieunternehmen
Bankverbindung
-Kreditinstitutsbezeichnung : Name
-Bankleitzahl : Code
-Kontonummer : Identifizierung
Kontaktangaben
-Name der Kontaktperson : Name
-Faxnummer : Nummer
-Internet-Adresse : Nummer
-Telefonnummer : Nummer
-Telexnummer : Nummer
-X.400-Adresse : Nummer
Abteilung
-Identifizierung : Identifizierung
-Name : Name
Anschrift
-Straßenbezeichnung : Name
-Straßencode : Code
-Postfachnummer : Identifizierung
-Postleitzahl : Code
-Ortsbezeichnung : Name
-Ortscode : Code
-Ortsteilbezeichnung : Name
-Ortsteilcode : Code
-Region : Name
-Länderbezeichnung : Name
-Ländercode : Code
-Landesteilbezeichnung : Name
-Landesteilcode : Code
-Gebäudenummer : Identifizierung
-Gebäudebezeichnung : Name
Verkaufsabteilung
Buchhaltung
Einkaufsabteilung
Versandstelle
-Ladestelle : Bezeichnung
Abbildung 4: Referenzklassendiagramm für Klienten (Ausschnitt)

3.2 Rollen
Zwischenbetriebliche Prozesse laufen nach gewissen Regeln ab, die durch rechtliche Vorgaben und
kaufmännische Gepflogenheiten bestimmt werden. Jeder Klient, jedes Objekt, jede Interaktion
sowie jeder Kanal übernimmt nach diesen Regeln eine bestimmte Funktion bzw. Rolle in einem
Prozess. Die Entwurfselemente Klient und Objekt können unabhängig von einem bestimmten
Prozess betrachtet werden. Durch die Zuordnung einer Rolle kann deren Funktion oder Aufgabe in
einem bestimmten Kontext festgelegt werden. Interaktionen und Kanäle sind dynamische Entwurfselemente
und werden somit per se nur in einem bestimmten Anwendungskontext verwendet. Ihnen
braucht daher keine Rolle zugewiesen werden.
Klientenrollen
Klientenrollen werden aus Sicht der Leistungsinteraktion betrachtet, die einem zwischenbetrieblichen
Prozess zugrunde liegt. Unter einem zwischenbetrieblichen Prozess wird also eine
Leistungsinteraktion mit allen zugehörigen Zahlungs- und Informationsinteraktionen verstanden, die
sich auf diese Leistungsinteraktion beziehen und sie planen, steuern sowie kontrollieren. Die
folgende Abbildung zeigt einen Ausschnitt aus dem Rollenkatalog für Klienten:
Rollen der an der Leistungsinteraktion
direkt beteiligten Klienten
• Käufer
• Verkäufer
Rollen der an der Leistungsinteraktion
indirekt beteiligten Klienten
• Versandspediteur
• Empfangsspediteur
• Bank des Käufers/Verkäufers
• Handelsvertreter des Käufers/Verkäufers
Abbildung 5: Klientenrollen
Die Rollen des Käufers und Verkäufers können nach der Beteiligung am Informations-, Leistungsoder
Zahlungsfluss weiter differenziert werden:
Fluss Käuferrolle Verkäuferrolle
Im Informationsfluss
im leistungssteuernden Auftraggeber
Auftragnehmer
Informationsfluss
im zahlungssteuernden Rechnungsempfänger Rechnungssteller
Informationsfluss
Im Leistungsfluss Warenempfänger Warensender
Im Zahlungsfluss Zahlungssender Zahlungsempfänger
Abbildung 6: Käufer- und Verkäuferrollen

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. Die
Rolle eines Objektes gibt somit Aufschluss über dessen Verwendungszweck. Im Rahmen des
elektronischen Datenaustausches kann die Rolle eines Informationsobjektes u.a. zur Zuordnung der
entsprechenden Inhouseschnittstelle dienen. So ist z.B. ein ankommendes Informationsobjekt mit
der Rolle „Auftrag“ als Auftrag im Inhousesystem weiterzuverarbeiten.
Die Rollen werden zunächst nach der Verwendung im Leistungs-, Zahlungs- oder Informationsfluss
unterteilt. Rollen von Informationsobjekten werden weiterhin nach der Prozessphase, in der diese
eingesetzt werden, unterschieden. Dabei wird unterstellt, dass zwischenbetriebliche Prozesse in den
Phasen Anbahnung, Vereinbarung, Durchführung und Kontrolle abgewickelt werden [Kosi69] /
[FeSi94]. Weiteres Gliederungskriterium für (Informations-)Objektrollen sind die mit ihnen übertragenen
Informationen. So können sie Markt-, Technik- oder Geschäftsverkehrsinformationen
enthalten. Marktinformationen stellen Informationen über das Marktangebot oder die Marktnachfrage
eines Klienten dar. Technikinformationen beschreiben die Technologie der Produkte und
deren Nutzung. Geschäftsverkehrsinformationen dienen der Initialisierung, Steuerung und Kontrolle
von Zahlungs- und Leistungsflüssen [Fisc99b]. Abbildung 7 zeigt exemplarisch einige Rollen für
Informationsobjekte.
Phase Informationsfeld Objektrolle
Anbahnung Marktinformation Produktkatalog
Werbung
Geschäftsverkehrsinformation Anfrage
Angebot
Technikinformation
Ersatzteilkatalog
Vereinbarung Geschäftsverkehrsinformation Bestellung
Rahmenauftrag
Bestelländerung
Technikinformation
Produktspezifikation
Durchführung Marktinformation Abverkaufsdaten
... ... ...
Abbildung 7: Rollen von Informationsobjekten (Ausschnitt)
3.3 Informationsbausteine
Informationsbausteine stellen atomare Informationselemente einer Nachricht bzw. eines Informationsobjektes
dar, die sich nicht weiter zerlegen lassen. In der Referenzbibliothek wird für die
Modellierung von Informationsstrukturdiagrammen (vgl. Abschnitt 4.4) ein Katalog von standardi-

sierten Informationsbausteinen bereitgestellt. Die Informationsbausteine werden dabei wie folgt aus
den Klassendiagrammen und Rollenkatalogen abgeleitet:
Jedes Attribut einer Referenzklasse (Grund- oder Attributklasse) kann als Basis für einen Informationsbaustein
dienen (z.B. das Attribut Straßenbezeichnung der Attributklasse Anschrift; vgl.
Abbildung 4). Die Bezeichnung eines Informationsbausteins setzt sich aus mehreren Teilen
zusammen. Zunächst wird die Bezeichnung des Attributs, von dem der Baustein abgeleitet wird,
übernommen (z.B. Straßenbezeichnung). Der Name der Klasse, aus der das Attribut stammt, wird
der Attributbezeichnung vorangestellt. Als Trennzeichen wird ein Punkt verwendet (z.B.
Anschrift.Straßenbezeichnung). Ist die Klasse über eine Aggregationsbeziehung Teil einer anderen
Klasse, so wird deren Bezeichnung wiederum der bisher gebildeten Bezeichnung des Informationsbausteins
vorangestellt, usw.. Im Falle von Grundklassen werden statt der Klassenbezeichnung
sämtliche möglichen Rollenbezeichnungen verwendet (z.B. Warenempfänger, Warensender,
Auftraggeber, usw. statt Einzelhandelsfiliale). Als Trennzeichen zwischen zwei Klassen- bzw.
Rollenbezeichnungen dient ebenfalls ein Punkt (z.B. Warenempfänger.Anschrift.Straßenbezeichnung).
Die so gebildeten Informationsbausteine sind über ihre Bezeichnungen eindeutig
bestimmt.
4 Vorgehen des Modellierungsansatzes
4.1 Das AllBuy-Szenario
Zur Illustration des Modellierungsansatzes soll ein Anwendungsbeispiel dienen: Es wird von einem
Lebensmittelhandelsunternehmen, der AllBuy GmbH, ausgegangen. Zur AllBuy GmbH gehören
etwa 200 Einzelhandelsfilialen verschiedener Größen. 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). Die
Regulierung der Zahlungen übernimmt die AllBuy-Zentrale. Die Großbäckerei wird durch einen
industriellen Backmischungshersteller beliefert. Der Verkauf der Brot- und Backwaren an die Endverbraucher
erfolgt an Brottheken in den AllBuy-Filialen.
Der bislang papierzentrierte Austausch von Informationen im Wertschöpfungsfluss soll nun weitgehend
elektronisch erfolgen. Dafür sind die zwischenbetrieblichen Prozesse in ihren Strukturen
und Inhalten zu entwerfen.

4.2 Prozessdiagramm
Ausgangspunkt der Modellierung sind Prozessdiagramme für jede Stufe eines betrachteten Wertschöpfungsflusses.
Ein Prozessdiagramm zeigt sämtliche an einem zwischenbetrieblichen Prozess
beteiligten Klienten sowie die auftretenden Interaktionen. Jede Interaktion lässt sich der
Anbahnungs-, Vereinbarungs-, Durchführungs- oder Kontrollphase zuordnen. Informationsinteraktionen
zwischen Klienten finden nicht per se statt, sondern wirken in unterschiedlicher Weise auf
Leistungs- oder Zahlungsinteraktionen und dienen bestimmten Zwecken (z.B. initiierend,
leistungssteuernd, kontrollierend (vgl. [Sche97])). Beim Erstellen eines Prozessdiagramms ist für
jede Interaktion die Zuordnung der Phase sowie, im Falle von Informationsinteraktionen, zusätzlich
die Angabe des Zwecks obligatorisch. So kann leicht festgestellt werden, ob ein zwischenbetrieblicher
Prozess vollständig modelliert worden ist. Ebenso lassen sich auf diese Weise, z.B. im
Rahmen einer Ist-Modellierung und -analyse, überflüssige oder fehlende Interaktionen
identifizieren.
Einzelhandelsfiliale
AllBuy-
Filiale
(Käufer:
Warenempfänger)
2. abrufen (D)
3. Lieferung mitteilen (D)
4. liefern (D)
Industrieunternehmen
Großbäckerei
(Verkäufer)
6. Wareneingang
melden (K)
Grosshandelszentrale
AllBuy-
Zentrale
(Käufer:
Auftraggeber,
Rechnungsempfänger,
Zahlungssender)
1. beauftragen (V)
5. fakturieren (D)
7. zahlen (D)
Legende:
Klient
Informationsinteraktion
Leistungsinteraktion
Zahlungsinteraktion
Abbildung 8: Prozessdiagramm des AllBuy-Szenarios
Beim Erstellen eines Prozessdiagramms erhält jeder Klient sowie jede Interaktion einen Verweis auf
eine Referenzklasse aus der Referenzbibliothek. Zum Beispiel sind die Klienten AllBuy-Filiale,
AllBuy-Zentrale und Großbäckerei aus dem Prozessdiagramm des AllBuy-Szenarios (vgl.
Abbildung 8) mit den entsprechenden Referenzklassen Einzelhandelsfiliale, Großhandelszentrale
sowie Industrieunternehmen verknüpft. Durch die zugeordnete Referenzklasse werden die Attribute
eines Entwurfselementes festgelegt. Im weiteren sind aus dem Rollenkatalog die Rollen
auszuwählen und zuzuordnen, die die Klienten im betrachteten Prozess übernehmen. Im Prozess

zwischen der Großbäckerei und der AllBuy GmbH übernimmt die Großbäckerei die Rolle des Verkäufers
mit sämtlichen Unterrollen Auftragnehmer, Warensender, Rechnungssteller und
Zahlungsempfänger. Die Rollen des Käufers (Auftraggeber, Warenempfänger,
Rechnungsempfänger, Zahlungssender) sind auf die AllBuy-Zentrale sowie auf die Filialen
aufgeteilt.
4.3 Interaktionsdiagramm
Jede in einem Prozessdiagramm abgebildete Geschäftsbeziehung ist durch ein Interaktionsdiagramm
hinsichtlich der alternativ möglichen Objekte und Kanäle sowie der strukturellen und
verhaltensmäßigen Eigenschaften aller verwendeten Entwurfsklassen zu detaillieren. Eine
Geschäftsbeziehung zwischen zwei Klienten besteht genau dann, wenn mindestens eine Interaktion
zwischen ihnen stattfindet. Abbildung 9 zeigt beispielhaft das Interaktionsdiagramm für die
Geschäftsbeziehung zwischen den AllBuy-Filialen und der Großbäckerei.
Abbildung 9: Interaktionsdiagramm AllBuy-Filiale - Großbäcker
Beschreibungselemente eines Interaktionsdiagramms sind Klienten, Objekte, Interaktionen und
Kanäle. Die Klienten und Interaktionen werden aus dem Prozessdiagramm übernommen. Für jede
Interaktion wird das Objekt, welches Gegenstand der Interaktion ist, und der Kanal, durch den die
Interaktion realisiert wird, näher spezifiziert. So wird aus dem gezeigten Beispiel u.a. ersichtlich,
dass die AllBuy-Filialen Lieferabrufe an die Großbäckerei über das Internet senden. Auch Objekte

und Kanäle erhalten einen Verweis auf eine Referenzklasse aus der Referenzbibliothek. Objekten
wird zusätzlich, in Abhängigkeit der jeweiligen Interaktion, eine Rolle zugewiesen.
4.4 Informationsstrukturdiagramm
Für jedes Informationsobjekt ist ein Informationsstrukturdiagramm vorgesehen. Dieses beschreibt
den Aufbau und Inhalt eines Informationsobjektes. Die zuvor erläuterten Prozess- und Interaktionsdiagramme
bilden dabei die Basis für Informationsstrukturdiagramme und legen den betriebswirtschaftlichen
Kontext für die Verwendung und Spezifikation von Informationsobjekten fest. Die
nachfolgenden Erläuterungen zum Informationsstrukturdiagramm sollen anhand eines Beispiels
erläutert werden. Abbildung 10 zeigt einen Lieferabruf, wie er bislang zwischen den AllBuy-
Filialen und der Großbäckerei verwendet wird.
Filiale AllBuy Köln-Kalk
Paderborner Str. 110
50102 Köln
Kd.-Nr. 4711
Datum der Bestellung: 12.09.97
Betr. Rahmenvertrag-Nr. 1707 v. 16.05.97
Liefertermin 14.09.97
Art.-Nr.
1312
1414
2001
Artikelbezeichnung
Aufbackbrötchen, 6er-Pack
Brötchen, normal, rund, 40g
Rosinenbrot, 750g
Menge
20
200
5
Abbildung 10: Beispiel eines Lieferabrufs
Spezifizieren der Informationsstruktur
Zunächst ist die Informationsstruktur zu bestimmen. Informationsbausteine repräsentieren die
atomaren Informationselemente einer Nachricht bzw. eines Informationsobjektes, die sich
semantisch sinnvoll nicht weiter zerlegen lassen. Atomare Informationselemente des abgebildeten
Lieferabrufs sind z.B. „Bestelldatum 12.09.97“, „Rahmenvertrag-Nr. 1707“ oder „Paderborner
Str.“. Die Bezeichnungen der dazu passenden Informationsbausteine aus der Referenzbibliothek
können wie folgt gefunden werden: für jedes atomare Informationselement ist zu überlegen,
welchem Modellierungselement im 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ßenbezeichnung
ermittelt. Die Rolle der AllBuy-Filiale bestimmt die vollständige Bezeichnung des gesuchten
Informationsbausteins: Warenempfänger.Anschrift.Straßenbezeichnung (vgl. Abbildung 11). Nach
der erläuterten Vorgehensweise können zur Beschreibung des Lieferabrufs aus Abbildung 10 die

weiteren erforderlichen Informationsbausteine gefunden werden.
Einige Bausteine beziehen sich auf den gesamten Abruf, während andere Bausteine die Abrufpositionen
betreffen. Während es zu den erst genannten Bausteinen in der vorliegenden Abrufbestellung
nur eine Ausprägung gibt (z.B. „12.09.97“ für den Informationsbaustein
Lieferabruf.Erstelldatum), existieren zu den letzteren Bausteinen mehrere Ausprägungen (z.B. „20“,
„200“ und „5“ für den Informationsbaustein Lieferung.Artikel.Bestellmenge). Um Gültigkeitsbereiche
von Informationsbausteinen festlegen zu können, werden sogenannte Informationscontainer
verwendet. Sie verdeutlichen die hierarchische Struktur eines Informationsobjektes. Im
Beispiel des Lieferabrufs ist der Informationscontainer Lieferabrufposition zu verwenden. Informationscontainer
können neben Bausteinen wiederum weitere Informationscontainer enthalten.
Die vollständige Informationsstruktur des Lieferabrufs zeigt Abbildung 11. Ein Vergleich mit dem
Papierdokument aus Abbildung 10 führt zu der Feststellung, das neun Informationselementen des
Belegkopfes und drei Elementen des Positionsteils genau neun bzw. drei Informationsbausteinen im
Informationsstrukturdiagramm gegenüberstehen. Hier liegt ein deutlicher Unterschied zum Ansatz
der EDIFACT-Vorschrift. Ein einzelnes Informationselement in der ursprünglichen Nachricht
entspricht in der Regel mehr als einem Datenelement nach der Überführung in das EDIFACT-
Format.
Rolle: Warenempfänger
Attribut: Einzelhandelsfiliale.Anschrift:Straßenbezeichnung
• Lieferabruf:Erstelldatum
• Warenempfänger:Name
Lieferabruf
• Warenempfänger.Anschrift:Straßenbezeichnung
• Warenempfänger.Anschrift:Ortscode
• Warenempfänger.Anschrift:Ortsname
• Warenempfänger.vom Verkäufer vergebene Nummer
• Rahmenauftrag:Nummer
• Rahmenauftrag:Erstelldatum
• Liefern.Geforderter Liefertermin: Datum
Lieferabrufposition
• Lieferung.Artikel:vom Verkäufer vergebene Nummer
• Lieferung. Artikel:Bezeichnung
• Lieferung.Artikel:Bestellmenge
Legende: • Informationsbaustein Informationscontainer
Abbildung 11: Informationsstrukturdiagramm des Lieferabrufs Backwaren
Spezifizieren der Methoden
Nachdem die Informationsstruktur bestimmt worden ist, lassen sich Integritätsmethoden für das
Informationsobjekt spezifizieren. Sie sollen die Integrität der übertragenen Daten sichern und
dadurch die automatische Weiterverarbeitung durch die Inhousesysteme ermöglichen. Eine Analyse

der Tätigkeiten und Prüfungen bei der Eingangsverarbeitung von Nachrichten führte zu folgenden
Kategorien von Integritätsmethoden (vgl. auch [Sche97]):
Methodenkategorie
Prüfen auf konsistente
Nachrichtenfolge
Prüfen auf konsistente
Nachrichten
Prüfen auf Plausibilität
Ergänzen fehlender
Werte
Umsetzen von
codierten Daten
Konvertieren von
Datenformaten
Beispiel (bezogen auf eine Sammelrechnung im AllBuy-Szenario)
• Die Mengen der Rechnungspositionen müssen mit den Lieferscheinmengen
übereinstimmen
• Die Preise der Rechnung müssen mit den Preisen des Rahmenvertrags
übereinstimmen
• Die Rechnungssumme muss mit der Summe der Rechnungspositionen
übereinstimmen
• Die Postleitzahl muss mit dem Ort übereinstimmen
• Es dürfen nur zulässige Mehrwertsteuersätze verwendet werden
• Es dürfen nur gültige Artikelnummern verwendet werden
• Nettobetrag fehlt (kann aus MwSt-Satz und Bruttobetrag berechnet
werden)
• Währungsangabe fehlt (kann durch Konstante aus Partnerstammsatz
ersetzt werden, z.B. „DM“)
• Verwendeter Code 07 für MwSt-Satz 7% wird in dem vom Partner
verwendeten Code 02 umgesetzt.
• Konvertieren des Rechnungsdatums von 12.09.1997 in 97/09/12
Abbildung 12: Kategorien von Integritätsmethoden
Jedem Informationsbaustein eines Informationsstrukturdiagramms und jedem Informationsobjekt
lassen sich mehrere Integritätsmethoden der verschiedenen Kategorien zuordnen (vgl. Abbildung
13). Die Spezifikation der Methoden erfolgt nach dem Event-Condition-Action-Modell (E-C-A)
[HeKn95] / [DrRu99].
Lieferabruf
• Lieferabruf:Erstelldatum
• Warenempfänger:Name
•
• Rahmenauftrag:Nummer
• Rahmenauftrag:Erstelldatum
•
Lieferabrufposition
•
•
Methodenkategorien
Prüfen auf konsistente Nachrichtenfolgen
(z.B. paßt das Datum zur Nummer)
Prüfen auf konsistente Nachrichten
Prüfen auf Plausibilität
(z.B. Datum in der Zukunft unzulässig)
Ergänzen fehlender Werte
(z.B. aus Original-Rahmenauftrag)
Umsetzen von codierten Daten
Rahmenauftrag
•
• Rahmenauftrag:Nummer
• Rahmenauftrag:Erstelldatum
•
Konvertieren von Datenformaten
z.B. von “jj-mm-tt” nach “tt-mm-jj”
Abbildung 13: Spezifizieren von Methoden

5 Nutzen
Die modellbasierte Planung und Gestaltung des zwischenbetrieblichen Informationsaustausches
bietet - unabhängig von der gewählten Implementierung oder vom verwendeten Standardformat -
eine Reihe von Vorteilen gegenüber einer EDI-Lösung ohne vorausgehende Modellierung:
Semantisch präzise Nachrichten
Statt durch einen syntaxorientierten Feldkatalog werden mit dem Modellierungsansatz die Informationselemente
zwischenbetrieblicher Nachrichten vor dem Hintergrund einer geschäftsprozessorientierten
Modellierung in ihrer Semantik eindeutig bestimmt. Dadurch kann die Verständigung
zwischen den Marktpartnern über die Bedeutung der auszutauschenden Nachrichten enorm
beschleunigt werden.
Vereinfachte Integration
Neben den rein statischen Datenstrukturen werden bei der Modellierung auch die Methoden zur
Verarbeitung der Nachrichten berücksichtigt. Die Einbettung der Informationsobjekte in ein
zwischenbetriebliches Gesamtmodell ermöglicht es, auch nachrichtenübergreifende Zusammenhänge
zwischen den einzelnen Informationselementen oder den Nachrichten selbst abzubilden.
Damit wird der Entwurf und die Implementierung der für die Inhousesystem-Anbindung notwendigen
Prüf- und Konvertierungsprozeduren effektiv unterstützt und vereinfacht.
Unterstützung des zwischenbetrieblichen Projektmanagements
Eine zwischenbetriebliche Modellierung trägt erheblich zur Transparenz und zum Verständnis der
unternehmensübergreifenden Prozesse bei. Die Modellierungsergebnisse verbessern den Dialog
zwischen den Verantwortlichen in den Fach- und DV-Abteilungen der beteiligten Marktpartner
eines zwischenbetrieblichen Projektes und können somit die Projektlaufzeit verkürzen.
Nutzen für die Standardisierung
Eine Modellierung zwischenbetrieblicher Prozesse kann auch zu einer verbesserten Standardisierungsarbeit
beitragen [TMWG98a]. Statt die syntaktischen Formate einzelner Datenfelder zu
standardisieren, sollte durch die Modellierung eine Vereinbarung auf fachkonzeptueller Ebene
erfolgen. Gegenüber dem Vorschlag der Techniques and Methodologies Working Group der
CEFACT, dem Gremium für die Pflege und Weiterentwicklung des EDIFACT-Standards, die
universale Modellierungssprache UML zu verwenden [TMWG98b], wird in diesem Beitrag ein
Ansatz vorgestellt, der eigens für die Modellierung zwischenbetrieblicher Prozesse entwickelt
worden ist.
Implementierungsunabhängigkeit

Die Modellierung zwischenbetrieblicher Prozesse erfolgt auf konzeptueller Ebene. Dies lässt
mehrere Alternativen für die Implementierung zu. So können auch beim Einsatz traditioneller EDI-
Technologien und Standardformaten die o.g. Vorteile erzielt werden. Denkbar sind aber auch internetbasierte
Lösungen unter Nutzung neuerer Technologien wie XML oder Java.
Im Folgenden wird eine Implementierungsalternative vorgestellt (vgl. Abbildung 14), die im
eingangs erwähnten Forschungsprojekt entwickelt und erprobt worden ist [DrRu99]. Bei dieser
Lösung spezifiziert der Sender die zu übertragenen Nachrichten mit einem
Informationsstrukturdiagramm. In der gleichen Weise modelliert der Empfänger die entsprechende
Schnittstelle seines Inhousesystems. Sender und Empfänger greifen dabei auf dieselbe
Referenzbibliothek zurück. Ein Softwaregenerator erzeugt Javaklassen auf Basis der
Informationsstrukturdiagramme. In einem konkreten Szenario 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 Schnittstellenobjekt aktiviert und entnimmt
die Werte aus dem eingegangenem Informationsobjekt. Die Werte werden durch die
Integritätsmethoden des Schnittstellenobjektes überprüft. Danach erfolgt die Konvertierung in das
Format des Inhousesystems.
Sender
Empfänger
Informationsstrukturdiagramm
Referenzbibliothek
Informationsstrukturdiagramm
Softwaregenerator erzeugt
Softwaregenerator erzeugt
Java-Klasse
Java-Klasse
instantiiert
instantiiert
Informationsobjekt
Bestellung
Übertragen
(z.B. durch RMI)
Schnittstellenobjekt
Bestellung
konvertieren
Integrität
prüfen
Inhouse-
Format
(z.B. SAP)
Abbildung 14: EDI-Implementierung mit Java (vereinfacht)
Die skizzierte Implementierung bietet neben den oben beschriebenen Vorteilen noch weiterreichende
Vorzüge. So können die Informationsobjekte flexibel gestaltet und an die Erfordernisse
der jeweiligen Geschäftsprozesse angepaßt werden, da sie nicht an ein festes Format gebunden sind.
Im Mittelpunkt steht nicht mehr die Struktur einer Nachricht, sondern deren notwendigen Informationselemente.
Diese sind sehr einfach aufgebaut; dementsprechend einfach können auch die Prüfund
Konvertierungsprozeduren gestaltet werden. Die Verwendung von Java erlaubt neben der Über-

tragung von textuellen Daten auch weitere Datentypen wie z.B. Bilder oder Zeichnungen. Durch
den Softwaregenerator können die Modellierungsergebnisse direkt für die Implementierung nutzbar
gemacht werden.
6 Zusammenfassung und Ausblick
Es wurde ein Ansatz zur Modellierung zwischenbetrieblicher Prozesse beschrieben und das
Nutzenpotential für die Planung und Gestaltung des unternehmensübergreifenden Nachrichtenaustausches
dargelegt. Zentrale Konzepte des Ansatzes sind
• die Modellierung (modellbasiert),
• die Objektorientierung (objektorientiert)
• und die Betrachtung von einzelnen Informationsbausteinen statt kompletter Nachrichtenstrukturen
(Bausteinansatz).
Abbildung 15 gibt einen Überblick über Gemeinsamkeiten und Unterschiede gegenüber anderen
aktuellen Ansätzen zur Integration von Informationssystemen bezüglich der genannten Punkte.

Ansatz Gemeinsamkeit Unterschied
Open EDI
• modellbasiert • nicht objektorientiert
[ISO95]
• kein Bausteinansatz
Basic Semantic Register
• Bausteinansatz • Nicht objektorientiert
[ISO98]
• nicht modellbasiert
BEACON - Business Engineering • Bausteinansatz • (noch) nicht
Architecture Construction Nexus [Stee97] • Objektorientiert modellbasiert
Next Generation of UN/EDIFACT • modellbasiert • kein Bausteinansatz
[TMWG98a]
• objektorientiert
OAGIS - Open Applications Group • Bausteinansatz • Nicht objektorientiert
Integration Specification [OAG98]
• nicht modellbasiert
Abbildung 15: Gemeinsamkeiten und Unterschiede zu anderen Ansätzen
Ziel ist es, den Ansatz um die Konzepte Ereignisse und betriebswirtschaftliche Regeln zu erweitern.
Danach senden und empfangen Klientenobjekte zeitgesteuert oder nach definierten Regeln
Informationsobjekte. Interaktionsobjekte überwachen und steuern andere Interaktionen. Zum Beispiel
ist es denkbar, dass nach einer erfolgten Fakturierung der Zahlungseingang durch entsprechende
Softwareobjekte überwacht wird und diese gegebenenfalls eine Mahnung auslösen.
Wichtige Voraussetzung der Modellierung zwischenbetrieblicher Prozesse in der dargestellten
Weise 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 gewartet und ergänzt wird.
Der vorgestellte Ansatz könnte wertvolle Anregungen für den aktuell diskutierten Datenaustausch
auf Basis der Extensible Markup Language (XML) liefern. Insbesondere erscheint er kompatibel mit
den Vorstellungen eines globalen XML/EDI-Repositories [Rama99] oder des Basic Semantic
Registers der ISO [ISO98] und könnte dessen methodische und fachkonzeptuelle Grundlage bilden.
Sollte sich die Standardisierung von Informationsbausteinen durchsetzen, so kann die Modellierung
zwischenbetrieblicher Prozesse dazu beitragen, dass die Vision eines automatisierten Informationsaustausches
ohne bilaterale Absprachen zur Realität wird. Die Unternehmen modellieren dann ihre
Schnittstellen in der vorgeschlagenen Weise mittels Informationsstrukturdiagrammen und veröffentlichen
sie im Internet. Mögliche Marktpartner übersenden Informationsobjekte mit den geforderten
Informationsbausteinen.

7 Literatur
[CoYo91] Coad, P.; Yourdon, E.: Object-Oriented Analysis; 2. Aufl.; Englewood Cliffs 1991
[DrRu99] Dresing, H.; Rulle, A.: Ein Framework für das modellgestützte Generieren von
Softwareobjekten in MOVE; in: Objektorientierte Modelle und Werkzeuge für
unternehmensübergreifende Informationssysteme im Rahmen des Electronic
Commerce, Köln 1999
[FeSi94] Ferstl, O.K.; Sinz, E.J.: Grundlagen der Wirtschaftsinformatik; 2. Aufl.; München,
Wien 1994
[FiKe+98] Fischer, J.; Kern, U.; Hammer, G.; Rulle, A.; Städler, M.; Steffen, Th.: Verbundprojekt
MOVE - Modellierung einer Verteilten Architektur für die Entwicklung
unternehmensübergreifender Informationssysteme und ihre Validierung im Handelsbereich;
Statusband Softwaretechnologie des BMBF; Berlin 1998
[Fisc92] Fischer, J.: Datenmanagement: Datenbanken und betriebliche Datenmodellierung;
München, Wien 1992
[Fisc99a] Fischer, J.: MOVE als Architektur für zwischenbetriebliche Informationssysteme; in:
Objektorientierte Modelle und Werkzeuge für unternehmensübergreifende
Informationssysteme im Rahmen des Electronic Commerce, Köln 1999
[Fisc99b] Fischer, J.: Informationswirtschaft: Anwendungsmanagement; München, Wien 1999
[FiSt98] Fischer, J.; Städler, M.: Efficient Consumer Response und zwischenbetriebliche
Integration; in: Hippner, H.; Meyer, M.; Wilde, K.D. (Hrsg.): Computer-Based
Marketing - Das Handbuch zur Marketinginformatik, Wiesbaden 1998, S. 349-356
[Hage96] Hagen, K.: Efficient Consumer Response (ECR) - ein neuer Weg in der Kooperation
zwischen Industrie und Handel; in: Pfohl, H.-Chr. (Hrsg.): Integrative Instrumente
der Logistik; Berlin 1996; S. 86-96
[HeKn95] Herbst, H.; Knolmayer, G.: Ansätze zur Klassifikation von Geschäftsregeln; in:
Wirtschaftsinformatik; Bd. 37; 2/1995; S. 149-159
[HiSc94] Hirschmann, P.; Scheer, A.-W.: Konzeption einer DV-Unterstützung für das
überbetriebliche Prozeßmanagement; in: Scheer, A.-W. (Hrsg.): Veröffentlichungen
des Instituts für Wirtschaftsinformatik (IWi). Heft 113; Saarbrücken 1994
[HlHo99] Hluchy, R.; Hoos, J.: Analyse zwischenbetrieblicher Geschäftsprozesse mit Hilfe der
Simulationstechnik; in: Objektorientierte Modelle und Werkzeuge für
unternehmensübergreifende Informationssysteme im Rahmen des Electronic
Commerce, Köln 1999
[ISO95] International Organization for Standardization (Hrsg.): Information Technology -
Open edi reference model. http://www.harbinger.com/resource/klaus/openedi/model/oerm.htm,
1995, Abruf am 1999-01-29.
[ISO98] International Organization for Standardization (Hrsg.): Basic Semantic Register
(BSR). http://www.iso.ch/BSR/index.htm, Abruf am 1998-07-23.
[Kosi69] Kosiol, E.: Die Unternehmung als wirtschaftliches Aktionszentrum, Reinbek bei
Hamburg 1969

[MOVE95] 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);
Paderborn 1995
[Müll98] Müller-Zantop, S.: Neue Perspektiven für Logistiksysteme; in: Computerwoche;
1/1998; S. 10-13
[OAG98] Open Applications Group (Hrsg.): Open Applications Group Integration
Specification (OAGIS) Release 6.1, 1999; http://www.openapplications.org/_vti_bin/
shtml.exe/oagis/loadform.htm; Abruf am 1999-01-29.
[Quib94] Quibeldey-Cirkel, K.: Das Objekt-Paradigma in der Informatik. Stuttgart 1994
[Rama99] Raman, D.: Setting up a UN Repository for XML/EDI;
http://www.cenorm.be/isss/workshop/ec/xmledi/Documents_99/xml004_99.htm;
Abruf am 1999-02-26.
[Rati97] Rational (Hrsg.): UML Notation Guide - Version 1.1.
http://www.rational.com/uml/html/notation/index.html, 1997-09-01, Abruf am 1998-
07-23.
[Sche97] Scheckenbach, R.: Semantische Geschäftsprozessintegration - Einbindung
zwischenbetrieblicher Geschäftsprozesse in betriebliche Anwendungssysteme; Diss.;
Universität Würzburg 1997
[Schü98] Schüppler, D.: Informationsmodelle für überbetriebliche Prozesse; Frankfurt a.M.
1998
[Stee97] Steel, K.: The BEACON User's Guide. ftp://turiel.cs.mu.oz.au/pub/edi/beaug1.doc,
1997-08-07, Abruf am 1998-07-23.
[Stei97] Stein, W.: Objektorientierte Analysemethoden: Vergleich, Bewertung, Auswahl; 2.
Aufl.; Heidelberg, Berlin, Oxford 1997
[Ster97] Stern, A.: Verteilte Kommunikation; in: iX; 3/1997; S. 100-107
[TMWG98a] Techniques and Methodologies Working Group (Hrsg.): 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.
[TMWG98b] Techniques and Methodologies Working Group (Hrsg.): Explanation of TMWG
Decision to use Unified Modeling Language (UML) for business process and
information modeling. http://www.harbinger.com/resource/klaus/tmwg/tm065.pdf,
1998-09-03, Abruf am 1998-11-27.