Objektorientierte Modellierung zwischenbetrieblicher Prozesse
Objektorientierte Modellierung zwischenbetrieblicher Prozesse
Objektorientierte Modellierung zwischenbetrieblicher Prozesse
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>Objektorientierte</strong> <strong>Modellierung</strong><br />
<strong>zwischenbetrieblicher</strong> <strong>Prozesse</strong><br />
Dipl.-Wirt. Inform. Thomas Steffen<br />
Prof. Dr. Joachim Fischer<br />
Universität-Gesamthochschule Paderborn, Schwerpunkt Wirtschaftsinformatik 1<br />
Warburger Str. 100, 33098 Paderborn<br />
e-mail:{steffen | fischer}@wior.wiwi.uni-paderborn.de<br />
Zusammenfassung<br />
Im Zuge der Bemühungen um die Verbesserung unternehmensübergreifender Geschäftsprozesse gewinnt der elektronische<br />
Austausch von Daten oder Electronic Data Interchange (EDI) an Bedeutung. Jedoch konnte sich EDI in seiner<br />
heutigen Form aus einer Reihe von Gründen, die im vorliegenden Beitrag genannt werden, bislang nicht entscheidend<br />
durchsetzen. Es wird daher vorgeschlagen, die Planung und Gestaltung des unternehmensübergreifenden Informationsaustausches<br />
durch eine <strong>Modellierung</strong> <strong>zwischenbetrieblicher</strong> <strong>Prozesse</strong> zu unterstützen. Ein entsprechender Ansatz wird<br />
vorgestellt, der auf einem objektorientierten Bezugsrahmen basiert. Er sieht drei Detaillierungsebenen (Prozess-,<br />
Interaktions- und Informationsstrukturdiagramme) sowie eine Referenzbibliothek für die <strong>Modellierung</strong> vor. Vor dem<br />
Hintergrund der <strong>Modellierung</strong>sergebnisse werden die auszutauschenden Nachrichten spezifiziert. Dabei werden neben<br />
den rein statischen Datenstrukturen auch die für die automatische Weiterverarbeitung notwendigen Methoden zur<br />
Integritätsprüfung und Konvertierung berücksichtigt. Es wird dargelegt, welches Nutzenpotential eine solche<br />
<strong>Modellierung</strong> <strong>zwischenbetrieblicher</strong> <strong>Prozesse</strong> beinhaltet.<br />
1 Ausgangslage und Zielsetzung<br />
Die Verbesserung von unternehmensübergreifenden Wertschöpfungsketten, wie sie mit Konzepten<br />
des Efficient Consumer Response (ECR) oder Supply Chain Managements (SCM) angestrebt<br />
werden, erfordern eine erhöhte zwischenbetriebliche Kommunikation. Es müssen vermehrt informierende<br />
und koordinierende Geschäftsdaten ausgetauscht werden. Der elektronische Austausch<br />
von Daten oder Electronic Data Interchange (EDI) gewinnt in diesem Rahmen an Bedeutung und ist<br />
ein wesentlicher Bestandteil von ECR- sowie SCM-Projekten [FiSt98] / [Hage96]. Doch EDI in<br />
seiner heutigen Form konnte sich bislang nicht durchsetzen, da viele potentielle Anwender die<br />
langen Projektlaufzeiten einer EDI-Implementierung scheuen. Folgende Gründe werden für die<br />
mangelnde Verbreitung des EDI-Einsatzes gesehen:
Semantische Probleme<br />
Vorhandene EDI-Standards (wie z.B. EDIFACT, SEDAS, ANSI X12) lösen zwar die syntaktischen,<br />
nicht aber die semantischen Probleme eines zwischenbetrieblichen Informationsaustausches. Die<br />
zumeist in Form von Feldkatalogen publizierten Standardformate lassen unterschiedliche Interpretationen<br />
der übermittelten Daten zu [Sche97] / [Schü98]. Der Vorteil der Präzisierung durch<br />
Bilden von Subsets führt andererseits zu Inkompatibilitäten zwischen verschiedenen Branchen und<br />
Benutzergruppen. Dies erfordert eine zeitaufwendige Verständigung zwischen den Marktpartnern<br />
über die Bedeutung der auszutauschenden Daten.<br />
Mangelnde Flexibilität der EDI-Standards<br />
Herkömmliche EDI-Standards sind zu starr auf lang bestehende und unveränderte Geschäftsprozesse<br />
ausgelegt und brauchen bei deren Änderungen viel Zeit für eine Anpassung. Dabei verändern<br />
sich zwischenbetriebliche <strong>Prozesse</strong> häufig aufgrund veränderter Verbraucherwünsche,<br />
staatlicher Vorschriften etc.. Ein anderer Aspekt ist, dass durch die vorgegebenen Strukturen der<br />
Standardformate geringere Freiheitsgrade hinsichtlich einer Realisierung spezifischer, an der<br />
Schnittstelle zwischen Unternehmen zum Ausdruck kommender Kernkompetenzen bestehen<br />
[Schü98].<br />
Hoher Integrationsaufwand<br />
Bezüglich der Korrektheit und Sicherheit von Daten besteht an der Schnittstelle zwischen Unternehmen<br />
eine hohe Sensibilität [Schü98]. Für eine automatisierte Weiterverarbeitung der ausgetauschten<br />
Nachrichten müssen daher eine Vielzahl von Prüf- und Kontrollprozeduren implementiert<br />
werden. Der komplexe Aufbau der EDI-Regelwerke erfordert weitere umständliche<br />
Konvertierungsprozeduren. Nachteilig für die semantische Integration <strong>zwischenbetrieblicher</strong><br />
Nachrichten ist weiterhin, dass vorhandene EDI-Konverter in der Regel nur einzelne Nachrichten<br />
verarbeiten und keine langen Transaktionen unterstützen. Nachrichtenübergreifende Integritätsprüfungen<br />
finden in der Regel nicht statt [Ster97].<br />
Mangelnde Transparenz und fehlende Werkzeuge<br />
Für eine effektive und effiziente zwischenbetriebliche Kommunikation auf elektronischem Wege<br />
sind die Geschäftsprozesse und deren Informationsflüsse unternehmensübergreifend zu gestalten<br />
und aufeinander abzustimmen. Es muss festgelegt werden, wer mit wem wann und zu welchem<br />
Zweck miteinander kommuniziert. Die Planung und Gestaltung der zwischenbetrieblichen<br />
Informationsflüsse ist kein einmaliges Projekt, sondern ständigen geschäftlichen, organisatorischen<br />
und technischen Änderungen unterworfen [Fisc99a]. Unternehmen verlassen einen Informations-
verbund, neue Partner kommen hinzu. Der schnelle technologische Fortschritt bewirkt einen<br />
häufigen Austausch vorhandener DV-Komponenten. Jedesmal sind die Geschäftsprozesse sowie<br />
Informationssysteme erneut aufeinander abzustimmen. Es fehlen bislang Techniken und Werkzeuge<br />
zur Komplexitätsbewältigung einer solchen Planungs- und Gestaltungsaufgabe [HiSc94] / [Müll98]<br />
/ [Schü98].<br />
Im vorliegenden Beitrag soll dargelegt werden, wie eine objektorientierte <strong>Modellierung</strong> <strong>zwischenbetrieblicher</strong><br />
<strong>Prozesse</strong> den unternehmensübergreifenden Informationsaustausch unterstützen und zur<br />
Lösung der angesprochenen Probleme beitragen kann. Der <strong>Modellierung</strong>sansatz ist im Rahmen des<br />
BMBF-Verbundprojektes „MOVE - <strong>Modellierung</strong> einer Verteilten Architektur für die Entwicklung<br />
unternehmensübergreifender Informationssysteme und ihre Validierung im Handelsbereich“<br />
[MOVE95] / [FiKe+98] entwickelt worden.<br />
2 Der <strong>Modellierung</strong>sansatz im Überblick<br />
2.1 Aufbau<br />
Grundgedanke des Ansatzes ist es, dass sich zwischenbetriebliche Nachrichten auf bestimmte<br />
Gegenstände und Objekte der realen Welt beziehen. Diese reale Welt wird zunächst mit Hilfe des<br />
<strong>Modellierung</strong>sansatzes rekonstruiert. Im weiteren werden die Nachrichteninhalte auf Basis der<br />
<strong>Modellierung</strong>sergebnisse festgelegt.<br />
Input<br />
Z.B. geschäftsprozessorientierte Simulation<br />
analysierte und bewertete<br />
Prozessstrukturen<br />
Referenzklassen,<br />
Rollen<br />
Informationsbausteine<br />
1.<br />
2.<br />
Prozessdiagramme<br />
Interaktionsdiagramme<br />
3.<br />
Informationssstrukturdiagramme<br />
Modellbibliothek<br />
Referenzbibliothek<br />
<strong>Modellierung</strong>sergebnisse<br />
Prototyp: <strong>Objektorientierte</strong>s Entwurfsinstrument<br />
Output<br />
abgestimmte Nachrichtenstrukturen für einen<br />
zwischenbetrieblichen Prozess<br />
Abbildung 1: Vorgehen des <strong>Modellierung</strong>sansatzes
Der Ansatz verfolgt ein Top-down-Vorgehen, das für die Beschreibung <strong>zwischenbetrieblicher</strong><br />
<strong>Prozesse</strong> drei Detaillierungsebenen vorsieht (vgl. Abbildung 1). Zunächst werden in einem Prozessdiagramm<br />
sämtliche beteiligten Unternehmen sowie die Interaktionen eines zwischenbetrieblichen<br />
<strong>Prozesse</strong>s aufgeführt. Ausgangspunkt einer effektiven und effizienten Prozessgestaltung kann z.B.<br />
eine vorgelagerte geschäftsprozessorientierte Simulation sein, wie sie im Rahmen des erwähnten<br />
Forschungsprojekts entwickelt worden ist [HlHo99]. Die Geschäftsbeziehungen jeweils zweier<br />
Unternehmen werden durch Interaktionsdiagramme detaillierter beschrieben. Ziel des Ansatzes ist<br />
letztendlich die Spezifikation der auszutauschenden Nachrichten mittels Informationsstrukturdiagrammen,<br />
in denen nicht nur die Informationselemente festgelegt werden, sondern auch die<br />
erforderlichen Integritätsmethoden. Der betriebswirtschaftliche Kontext, in dem die Nachrichten<br />
verwendet werden, wird dabei durch die Diagramme der beiden höheren Ebenen festgelegt.<br />
Grundlage der <strong>Modellierung</strong> sind Referenzklassen, Rollen sowie Informationsbausteine, die in einer<br />
Referenzbibliothek bereitgestellt werden. Die <strong>Modellierung</strong>sergebnisse werden in einer Modellbibliothek<br />
abgelegt. Der Ansatz wird durchgehend durch ein objektorientiertes Entwurfsinstrument,<br />
welches prototypisch implementiert worden ist, unterstützt.<br />
2.2 <strong>Objektorientierte</strong>r Bezugsrahmen<br />
Generell steht für die <strong>Modellierung</strong> ein struktur- oder objektorientiertes Vorgehen zur Auswahl<br />
[Fisc99a] / [Fisc99b]. In der industriellen Praxis sind die strukturierten Methoden etabliert und weit<br />
verbreitet [Stei97] / [Quib94]. Allerdings gilt das Interesse der Forschung heute eher den<br />
objektorientierten Ansätzen. Ihnen wird „aufgrund der Durchgängigkeit zwischen Real- und<br />
Systemwelt und aufgrund der Kapselung zu autonomen [...] Komponenten die größere Eleganz<br />
zuerkannt“ [Fisc99b] / [Stei97]. Für die <strong>Modellierung</strong> <strong>zwischenbetrieblicher</strong> <strong>Prozesse</strong> ist daher der<br />
in Abbildung 2 dargestellte objektorientierte Bezugsrahmen entwickelt worden. Gemäß dem<br />
Objektansatz wird eine Sichtweise verfolgt, der die Gegenstände der Realität als Ganzheit aus<br />
Materie und Informationen sowie aus zugehörigen Methoden versteht, die gegenüber der Umwelt<br />
gekapselt sind [MOVE95]. Die Betrachtung von zwischenbetrieblichen <strong>Prozesse</strong>n führt zu den<br />
Entwurfselementen Klient, Interaktion, Objekt und Kanal. Unternehmen, Haushalte sowie staatliche<br />
und wirtschaftliche Institutionen - im Bezugsrahmen als Klienten bezeichnet - tauschen Leistungs-,<br />
Zahlungs- und Informationsobjekte untereinander aus. Die Übertragung von Leistungen, Zahlungen<br />
oder Informationen eines Klienten zu einem oder mehreren anderen Klienten wird als Interaktion<br />
bezeichnet. Sie werden durch den Gegenstand der Interaktion, das Objekt und den zur Realisierung<br />
notwendigen Kanal näher bestimmt.
Entwurfselemente<br />
Klient Objekt Interaktion Kanal<br />
Struktur Statische Elemente Dynamische Elemente<br />
Verhalten Aktiv Passiv Aktiv Passiv<br />
Beschreibende<br />
Komponenten<br />
• Attribute<br />
• Rollen<br />
• Attribute<br />
• Methoden<br />
• Attribute<br />
(Methoden)<br />
Strukturkomponenten<br />
Kurzbeschreibung<br />
Beispiele<br />
Notation<br />
• Attribute<br />
• Rollen<br />
• Methoden<br />
Stellen Regeln auf<br />
und veranlassen<br />
Interaktionen<br />
• Industrieunternehmen<br />
• Handelsunternehmen<br />
• Handwerker<br />
• Banken<br />
• (Methoden)<br />
• Generalisieren / Spezialisieren (is a)<br />
• Gruppieren (is member of)<br />
• Verknüpfen (is part of)<br />
sind Gegenstand<br />
von Interaktionen<br />
• Produkte<br />
• Zahlungsmittel<br />
• Nachrichten<br />
Austausch von<br />
Leistungen, Geld<br />
oder Informationen<br />
• Liefern<br />
• Überweisen<br />
• Beauftragen<br />
Informationen<br />
Zahlungen<br />
Leistungen<br />
bilden zulässige<br />
Wege für Interaktionen<br />
• Transportwege<br />
• Vertriebskanäle<br />
• Kommunikationswege<br />
bzw.<br />
Abbildung 2: <strong>Objektorientierte</strong>r Bezugsrahmen (vgl. [Fisc99a])<br />
3 Referenzen für die <strong>Modellierung</strong><br />
Die zu erstellenden Diagramme sollen zur Transparenz und zum Verständnis der zwischenbetrieblichen<br />
<strong>Prozesse</strong> beitragen und bilden insbesondere die Grundlage des zwischenbetrieblichen<br />
Informationsaustausches. Daher ist es wichtig, dass die Marktpartner dieselben Sprachmittel zur<br />
Beschreibung der <strong>Prozesse</strong> und Nachrichten verwenden. Aus diesem Grund dürfen die Entwurfselemente<br />
Klient, Interaktion, Objekt und Kanal nicht frei modelliert werden, sondern sollten aus<br />
einem standardisierten und von allen beteiligten Unternehmen akzeptierten Verzeichnis stammen.<br />
Ein solches Verzeichnis wurde im Rahmen des erwähnten Forschungsprojekts in Form einer<br />
Referenzbibliothek aufgebaut (vgl. Abbildung 3). Dazu wurden die materialen, d.h. geschäftsprozessrelevanten<br />
Eigenschaften der Entwurfselemente in der zugrundegelegten Geschäftswelt<br />
untersucht. Diese exemplarisch für die Lebensmittelbranche durchgeführte statische, strukturorientierte<br />
Analyse führte zu Referenzklassen, die in Klassendiagrammen beschrieben werden. Die<br />
dynamische, prozessorientierte Betrachtung führte zu einem Katalog der Rollen, die die Entwurfs-
elemente im Rahmen <strong>zwischenbetrieblicher</strong> <strong>Prozesse</strong> ausüben können. Im weiteren werden in der<br />
Referenzbibliothek Informationsbausteine der Dimensionen Markt-, Technik- und Geschäftsverkehrsinformationen<br />
bereitgestellt. Diese Bausteine können aus den Referenzklassen und Rollen<br />
abgeleitet werden.<br />
<strong>Objektorientierte</strong><br />
Entwurfselemente für<br />
Branche präzisieren<br />
statisch,<br />
strukturorientiert<br />
dynamisch,<br />
prozessorientiert<br />
Referenzbibliothek<br />
Nachrichtenformate<br />
(z.B. EANCOM)<br />
prozessorientiert<br />
analysieren und<br />
semantisch präzisieren<br />
in den Dimensionen:<br />
• Geschäftsverkehr<br />
• Markt<br />
•Technik<br />
Referenzklassen<br />
Attribute<br />
ableiten<br />
Rollen<br />
Informationsbausteine<br />
Abbildung 3: Konstruktion der Referenzbibliothek<br />
3.1 Referenzklassen<br />
Aus Sichtweise des objektorientierten Bezugsrahmens stellen die Entwurfselemente Klient, Interaktion,<br />
Objekt und Kanal jeweils Klassen dar. In der Referenzbibliothek werden Referenzklassen in<br />
vier Klassendiagrammen bereitgestellt: es gibt jeweils ein Klassendiagramm für Klienten, Interaktionen,<br />
Objekte und Kanäle. In den Klassendiagrammen werden die objektorientierten Konzepte<br />
Attributzuordnung, Aggregation, Generalisierung und Vererbung nach betriebswirtschaftlichen<br />
Kriterien der betrachteten Geschäftswelt angewendet. Als Beschreibungssprache der Klassendiagramme<br />
dient die Notation für UML-Klassendiagramme [Rati97].<br />
Bestandteil eines Klassendiagramms ist zunächst einmal eine Generalisierungs-/Spezialisierungshierarchie,<br />
ausgehend von einer allgemeinen, abstrakten Klasse des jeweiligen Entwurfselementes<br />
(Klient, Interaktion, Objekt oder Kanal). Durch eine Generalisierungs-Spezialisierungsbeziehung<br />
werden Klassen als Subklassen (z.B. Handelsunternehmen, Transportunternehmen, Banken,<br />
Versicherungen) unter einer Superklasse (z.B. Dienstleistungsunternehmen) zusammengefasst<br />
[Fisc92] / [CoYo91]. Die Klassen, die Element dieser Generalisierungs-/Spezialisierungshierarchie<br />
sind, sollen als Grundklassen bezeichnet werden.<br />
Grundklassen werden durch Attribute näher beschrieben. Diese können durch eine geschäfts-
prozessorientierte Analyse aus den atomaren Informationselementen vorhandener Nachrichtenformate<br />
(wie z.B. EANCOM) abgeleitet und sollten semantisch präzisiert werden. Sie stellen damit<br />
die im Rahmen <strong>zwischenbetrieblicher</strong> Informationsprozesse relevanten und bedeutsamen Eigenschaften<br />
der Entwurfselemente dar und sind Grundlage für die auszutauschenden Informationselemente<br />
zwischen den Klienten (vgl. Abschnitt 4.4). Jedem Attribut ist eine eindeutige und<br />
betriebswirtschaftlich unmissverständliche Bezeichnung zugeordnet.<br />
Mehrere Attribute, deren Zusammenfassung eine semantisch sinnvolle Einheit darstellt, bilden<br />
eigene Klassen, die als Attributklassen bezeichnet werden sollen. Beispiele für solche Attributklassen<br />
sind Anschrift, Bankverbindung, Preisangabe. Diese Attributklassen können über<br />
Aggregationsbeziehungen [CoYo91] den Grundklassen oder weiteren Attributklassen zugeordnet<br />
werden. Ebenso wie Grundklassen können auch Attributklassen generalisiert bzw. spezialisiert<br />
werden.<br />
Sind zwei Klassen (Grund- oder Attributklassen) über eine Generalisierungs-<br />
/Spezialisierungsbeziehung miteinander verbunden, so werden sämtliche Attribute sowie<br />
Aggregationsbeziehungen der Superklasse an die Subklasse vererbt.<br />
Unter Anwendung der beschriebenen objektorientierten Konzepte wurde je Entwurfselement ein<br />
Referenzklassendiagramm erstellt. Die folgende Abbildung zeigt einen Ausschnitt des Klassendiagramms<br />
für Klienten (vgl. Abbildung 4).<br />
Klient<br />
+Name : Name<br />
-ID, vom Käufer vergeben : Identifizierung<br />
-ID, vom Verkäufer vergeben : Identifizierung<br />
Wirtschaftliche Institution<br />
Einzelperson<br />
-Telefonnummer : Nummer<br />
-Geburtsdatum : Zeitangabe<br />
-Kundennummer : Identifizierung<br />
Einzelhandelsfiliale<br />
Grosshandelszentrale<br />
Unternehmen<br />
Industrieunternehmen<br />
Bankverbindung<br />
-Kreditinstitutsbezeichnung : Name<br />
-Bankleitzahl : Code<br />
-Kontonummer : Identifizierung<br />
Kontaktangaben<br />
-Name der Kontaktperson : Name<br />
-Faxnummer : Nummer<br />
-Internet-Adresse : Nummer<br />
-Telefonnummer : Nummer<br />
-Telexnummer : Nummer<br />
-X.400-Adresse : Nummer<br />
Abteilung<br />
-Identifizierung : Identifizierung<br />
-Name : Name<br />
Anschrift<br />
-Straßenbezeichnung : Name<br />
-Straßencode : Code<br />
-Postfachnummer : Identifizierung<br />
-Postleitzahl : Code<br />
-Ortsbezeichnung : Name<br />
-Ortscode : Code<br />
-Ortsteilbezeichnung : Name<br />
-Ortsteilcode : Code<br />
-Region : Name<br />
-Länderbezeichnung : Name<br />
-Ländercode : Code<br />
-Landesteilbezeichnung : Name<br />
-Landesteilcode : Code<br />
-Gebäudenummer : Identifizierung<br />
-Gebäudebezeichnung : Name<br />
Verkaufsabteilung<br />
Buchhaltung<br />
Einkaufsabteilung<br />
Versandstelle<br />
-Ladestelle : Bezeichnung<br />
Abbildung 4: Referenzklassendiagramm für Klienten (Ausschnitt)
3.2 Rollen<br />
Zwischenbetriebliche <strong>Prozesse</strong> laufen nach gewissen Regeln ab, die durch rechtliche Vorgaben und<br />
kaufmännische Gepflogenheiten bestimmt werden. Jeder Klient, jedes Objekt, jede Interaktion<br />
sowie jeder Kanal übernimmt nach diesen Regeln eine bestimmte Funktion bzw. Rolle in einem<br />
Prozess. Die Entwurfselemente Klient und Objekt können unabhängig von einem bestimmten<br />
Prozess betrachtet werden. Durch die Zuordnung einer Rolle kann deren Funktion oder Aufgabe in<br />
einem bestimmten Kontext festgelegt werden. Interaktionen und Kanäle sind dynamische Entwurfselemente<br />
und werden somit per se nur in einem bestimmten Anwendungskontext verwendet. Ihnen<br />
braucht daher keine Rolle zugewiesen werden.<br />
Klientenrollen<br />
Klientenrollen werden aus Sicht der Leistungsinteraktion betrachtet, die einem zwischenbetrieblichen<br />
Prozess zugrunde liegt. Unter einem zwischenbetrieblichen Prozess wird also eine<br />
Leistungsinteraktion mit allen zugehörigen Zahlungs- und Informationsinteraktionen verstanden, die<br />
sich auf diese Leistungsinteraktion beziehen und sie planen, steuern sowie kontrollieren. Die<br />
folgende Abbildung zeigt einen Ausschnitt aus dem Rollenkatalog für Klienten:<br />
Rollen der an der Leistungsinteraktion<br />
direkt beteiligten Klienten<br />
• Käufer<br />
• Verkäufer<br />
Rollen der an der Leistungsinteraktion<br />
indirekt beteiligten Klienten<br />
• Versandspediteur<br />
• Empfangsspediteur<br />
• Bank des Käufers/Verkäufers<br />
• Handelsvertreter des Käufers/Verkäufers<br />
Abbildung 5: Klientenrollen<br />
Die Rollen des Käufers und Verkäufers können nach der Beteiligung am Informations-, Leistungsoder<br />
Zahlungsfluss weiter differenziert werden:<br />
Fluss Käuferrolle Verkäuferrolle<br />
Im Informationsfluss<br />
im leistungssteuernden Auftraggeber<br />
Auftragnehmer<br />
Informationsfluss<br />
im zahlungssteuernden Rechnungsempfänger Rechnungssteller<br />
Informationsfluss<br />
Im Leistungsfluss Warenempfänger Warensender<br />
Im Zahlungsfluss Zahlungssender Zahlungsempfänger<br />
Abbildung 6: Käufer- und Verkäuferrollen
Objektrollen<br />
Ebenso wie Klienten, so können auch Objekte kontextabhängige Rollen einnehmen. So kann ein<br />
Formular mit einer Artikelaufstellung sowohl als Anfrage, Bestellung oder Lieferschein dienen. Die<br />
Rolle eines Objektes gibt somit Aufschluss über dessen Verwendungszweck. Im Rahmen des<br />
elektronischen Datenaustausches kann die Rolle eines Informationsobjektes u.a. zur Zuordnung der<br />
entsprechenden Inhouseschnittstelle dienen. So ist z.B. ein ankommendes Informationsobjekt mit<br />
der Rolle „Auftrag“ als Auftrag im Inhousesystem weiterzuverarbeiten.<br />
Die Rollen werden zunächst nach der Verwendung im Leistungs-, Zahlungs- oder Informationsfluss<br />
unterteilt. Rollen von Informationsobjekten werden weiterhin nach der Prozessphase, in der diese<br />
eingesetzt werden, unterschieden. Dabei wird unterstellt, dass zwischenbetriebliche <strong>Prozesse</strong> in den<br />
Phasen Anbahnung, Vereinbarung, Durchführung und Kontrolle abgewickelt werden [Kosi69] /<br />
[FeSi94]. Weiteres Gliederungskriterium für (Informations-)Objektrollen sind die mit ihnen übertragenen<br />
Informationen. So können sie Markt-, Technik- oder Geschäftsverkehrsinformationen<br />
enthalten. Marktinformationen stellen Informationen über das Marktangebot oder die Marktnachfrage<br />
eines Klienten dar. Technikinformationen beschreiben die Technologie der Produkte und<br />
deren Nutzung. Geschäftsverkehrsinformationen dienen der Initialisierung, Steuerung und Kontrolle<br />
von Zahlungs- und Leistungsflüssen [Fisc99b]. Abbildung 7 zeigt exemplarisch einige Rollen für<br />
Informationsobjekte.<br />
Phase Informationsfeld Objektrolle<br />
Anbahnung Marktinformation Produktkatalog<br />
Werbung<br />
Geschäftsverkehrsinformation Anfrage<br />
Angebot<br />
Technikinformation<br />
Ersatzteilkatalog<br />
Vereinbarung Geschäftsverkehrsinformation Bestellung<br />
Rahmenauftrag<br />
Bestelländerung<br />
Technikinformation<br />
Produktspezifikation<br />
Durchführung Marktinformation Abverkaufsdaten<br />
... ... ...<br />
Abbildung 7: Rollen von Informationsobjekten (Ausschnitt)<br />
3.3 Informationsbausteine<br />
Informationsbausteine stellen atomare Informationselemente einer Nachricht bzw. eines Informationsobjektes<br />
dar, die sich nicht weiter zerlegen lassen. In der Referenzbibliothek wird für die<br />
<strong>Modellierung</strong> von Informationsstrukturdiagrammen (vgl. Abschnitt 4.4) ein Katalog von standardi-
sierten Informationsbausteinen bereitgestellt. Die Informationsbausteine werden dabei wie folgt aus<br />
den Klassendiagrammen und Rollenkatalogen abgeleitet:<br />
Jedes Attribut einer Referenzklasse (Grund- oder Attributklasse) kann als Basis für einen Informationsbaustein<br />
dienen (z.B. das Attribut Straßenbezeichnung der Attributklasse Anschrift; vgl.<br />
Abbildung 4). Die Bezeichnung eines Informationsbausteins setzt sich aus mehreren Teilen<br />
zusammen. Zunächst wird die Bezeichnung des Attributs, von dem der Baustein abgeleitet wird,<br />
übernommen (z.B. Straßenbezeichnung). Der Name der Klasse, aus der das Attribut stammt, wird<br />
der Attributbezeichnung vorangestellt. Als Trennzeichen wird ein Punkt verwendet (z.B.<br />
Anschrift.Straßenbezeichnung). Ist die Klasse über eine Aggregationsbeziehung Teil einer anderen<br />
Klasse, so wird deren Bezeichnung wiederum der bisher gebildeten Bezeichnung des Informationsbausteins<br />
vorangestellt, usw.. Im Falle von Grundklassen werden statt der Klassenbezeichnung<br />
sämtliche möglichen Rollenbezeichnungen verwendet (z.B. Warenempfänger, Warensender,<br />
Auftraggeber, usw. statt Einzelhandelsfiliale). Als Trennzeichen zwischen zwei Klassen- bzw.<br />
Rollenbezeichnungen dient ebenfalls ein Punkt (z.B. Warenempfänger.Anschrift.Straßenbezeichnung).<br />
Die so gebildeten Informationsbausteine sind über ihre Bezeichnungen eindeutig<br />
bestimmt.<br />
4 Vorgehen des <strong>Modellierung</strong>sansatzes<br />
4.1 Das AllBuy-Szenario<br />
Zur Illustration des <strong>Modellierung</strong>sansatzes soll ein Anwendungsbeispiel dienen: Es wird von einem<br />
Lebensmittelhandelsunternehmen, der AllBuy GmbH, ausgegangen. Zur AllBuy GmbH gehören<br />
etwa 200 Einzelhandelsfilialen verschiedener Größen. Die AllBuy GmbH bezieht ihre Brot- und<br />
Backwaren von einer industriellen Großbäckerei. Dabei erfolgt einmal jährlich ein Rahmenauftrag<br />
der AllBuy-Zentrale an die Großbäckerei, in dem Absatzmengen, Preise sowie Liefer- und<br />
Zahlungsbedingungen festgelegt werden. Die Lieferabrufe erfolgen direkt durch die AllBuy-<br />
Filialen, die wiederum direkt von der Großbäckerei beliefert werden (Streckengeschäft). Die<br />
Regulierung der Zahlungen übernimmt die AllBuy-Zentrale. Die Großbäckerei wird durch einen<br />
industriellen Backmischungshersteller beliefert. Der Verkauf der Brot- und Backwaren an die Endverbraucher<br />
erfolgt an Brottheken in den AllBuy-Filialen.<br />
Der bislang papierzentrierte Austausch von Informationen im Wertschöpfungsfluss soll nun weitgehend<br />
elektronisch erfolgen. Dafür sind die zwischenbetrieblichen <strong>Prozesse</strong> in ihren Strukturen<br />
und Inhalten zu entwerfen.
4.2 Prozessdiagramm<br />
Ausgangspunkt der <strong>Modellierung</strong> sind Prozessdiagramme für jede Stufe eines betrachteten Wertschöpfungsflusses.<br />
Ein Prozessdiagramm zeigt sämtliche an einem zwischenbetrieblichen Prozess<br />
beteiligten Klienten sowie die auftretenden Interaktionen. Jede Interaktion lässt sich der<br />
Anbahnungs-, Vereinbarungs-, Durchführungs- oder Kontrollphase zuordnen. Informationsinteraktionen<br />
zwischen Klienten finden nicht per se statt, sondern wirken in unterschiedlicher Weise auf<br />
Leistungs- oder Zahlungsinteraktionen und dienen bestimmten Zwecken (z.B. initiierend,<br />
leistungssteuernd, kontrollierend (vgl. [Sche97])). Beim Erstellen eines Prozessdiagramms ist für<br />
jede Interaktion die Zuordnung der Phase sowie, im Falle von Informationsinteraktionen, zusätzlich<br />
die Angabe des Zwecks obligatorisch. So kann leicht festgestellt werden, ob ein <strong>zwischenbetrieblicher</strong><br />
Prozess vollständig modelliert worden ist. Ebenso lassen sich auf diese Weise, z.B. im<br />
Rahmen einer Ist-<strong>Modellierung</strong> und -analyse, überflüssige oder fehlende Interaktionen<br />
identifizieren.<br />
Einzelhandelsfiliale<br />
AllBuy-<br />
Filiale<br />
(Käufer:<br />
Warenempfänger)<br />
2. abrufen (D)<br />
3. Lieferung mitteilen (D)<br />
4. liefern (D)<br />
Industrieunternehmen<br />
Großbäckerei<br />
(Verkäufer)<br />
6. Wareneingang<br />
melden (K)<br />
Grosshandelszentrale<br />
AllBuy-<br />
Zentrale<br />
(Käufer:<br />
Auftraggeber,<br />
Rechnungsempfänger,<br />
Zahlungssender)<br />
1. beauftragen (V)<br />
5. fakturieren (D)<br />
7. zahlen (D)<br />
Legende:<br />
Klient<br />
Informationsinteraktion<br />
Leistungsinteraktion<br />
Zahlungsinteraktion<br />
Abbildung 8: Prozessdiagramm des AllBuy-Szenarios<br />
Beim Erstellen eines Prozessdiagramms erhält jeder Klient sowie jede Interaktion einen Verweis auf<br />
eine Referenzklasse aus der Referenzbibliothek. Zum Beispiel sind die Klienten AllBuy-Filiale,<br />
AllBuy-Zentrale und Großbäckerei aus dem Prozessdiagramm des AllBuy-Szenarios (vgl.<br />
Abbildung 8) mit den entsprechenden Referenzklassen Einzelhandelsfiliale, Großhandelszentrale<br />
sowie Industrieunternehmen verknüpft. Durch die zugeordnete Referenzklasse werden die Attribute<br />
eines Entwurfselementes festgelegt. Im weiteren sind aus dem Rollenkatalog die Rollen<br />
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<br />
mit sämtlichen Unterrollen Auftragnehmer, Warensender, Rechnungssteller und<br />
Zahlungsempfänger. Die Rollen des Käufers (Auftraggeber, Warenempfänger,<br />
Rechnungsempfänger, Zahlungssender) sind auf die AllBuy-Zentrale sowie auf die Filialen<br />
aufgeteilt.<br />
4.3 Interaktionsdiagramm<br />
Jede in einem Prozessdiagramm abgebildete Geschäftsbeziehung ist durch ein Interaktionsdiagramm<br />
hinsichtlich der alternativ möglichen Objekte und Kanäle sowie der strukturellen und<br />
verhaltensmäßigen Eigenschaften aller verwendeten Entwurfsklassen zu detaillieren. Eine<br />
Geschäftsbeziehung zwischen zwei Klienten besteht genau dann, wenn mindestens eine Interaktion<br />
zwischen ihnen stattfindet. Abbildung 9 zeigt beispielhaft das Interaktionsdiagramm für die<br />
Geschäftsbeziehung zwischen den AllBuy-Filialen und der Großbäckerei.<br />
Abbildung 9: Interaktionsdiagramm AllBuy-Filiale - Großbäcker<br />
Beschreibungselemente eines Interaktionsdiagramms sind Klienten, Objekte, Interaktionen und<br />
Kanäle. Die Klienten und Interaktionen werden aus dem Prozessdiagramm übernommen. Für jede<br />
Interaktion wird das Objekt, welches Gegenstand der Interaktion ist, und der Kanal, durch den die<br />
Interaktion realisiert wird, näher spezifiziert. So wird aus dem gezeigten Beispiel u.a. ersichtlich,<br />
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<br />
wird zusätzlich, in Abhängigkeit der jeweiligen Interaktion, eine Rolle zugewiesen.<br />
4.4 Informationsstrukturdiagramm<br />
Für jedes Informationsobjekt ist ein Informationsstrukturdiagramm vorgesehen. Dieses beschreibt<br />
den Aufbau und Inhalt eines Informationsobjektes. Die zuvor erläuterten Prozess- und Interaktionsdiagramme<br />
bilden dabei die Basis für Informationsstrukturdiagramme und legen den betriebswirtschaftlichen<br />
Kontext für die Verwendung und Spezifikation von Informationsobjekten fest. Die<br />
nachfolgenden Erläuterungen zum Informationsstrukturdiagramm sollen anhand eines Beispiels<br />
erläutert werden. Abbildung 10 zeigt einen Lieferabruf, wie er bislang zwischen den AllBuy-<br />
Filialen und der Großbäckerei verwendet wird.<br />
Filiale AllBuy Köln-Kalk<br />
Paderborner Str. 110<br />
50102 Köln<br />
Kd.-Nr. 4711<br />
Datum der Bestellung: 12.09.97<br />
Betr. Rahmenvertrag-Nr. 1707 v. 16.05.97<br />
Liefertermin 14.09.97<br />
Art.-Nr.<br />
1312<br />
1414<br />
2001<br />
Artikelbezeichnung<br />
Aufbackbrötchen, 6er-Pack<br />
Brötchen, normal, rund, 40g<br />
Rosinenbrot, 750g<br />
Menge<br />
20<br />
200<br />
5<br />
Abbildung 10: Beispiel eines Lieferabrufs<br />
Spezifizieren der Informationsstruktur<br />
Zunächst ist die Informationsstruktur zu bestimmen. Informationsbausteine repräsentieren die<br />
atomaren Informationselemente einer Nachricht bzw. eines Informationsobjektes, die sich<br />
semantisch sinnvoll nicht weiter zerlegen lassen. Atomare Informationselemente des abgebildeten<br />
Lieferabrufs sind z.B. „Bestelldatum 12.09.97“, „Rahmenvertrag-Nr. 1707“ oder „Paderborner<br />
Str.“. Die Bezeichnungen der dazu passenden Informationsbausteine aus der Referenzbibliothek<br />
können wie folgt gefunden werden: für jedes atomare Informationselement ist zu überlegen,<br />
welchem <strong>Modellierung</strong>selement im Interaktionsdiagramm es zugeordnet werden kann. So ist z.B.<br />
„Paderborner Str.“ eine Eigenschaft der AllBuy-Filiale. Über die Verknüpfung mit der<br />
Referenzklasse Einzelhandelsfiliale wird das entsprechende Attribut Anschrift.Straßenbezeichnung<br />
ermittelt. Die Rolle der AllBuy-Filiale bestimmt die vollständige Bezeichnung des gesuchten<br />
Informationsbausteins: Warenempfänger.Anschrift.Straßenbezeichnung (vgl. Abbildung 11). Nach<br />
der erläuterten Vorgehensweise können zur Beschreibung des Lieferabrufs aus Abbildung 10 die
weiteren erforderlichen Informationsbausteine gefunden werden.<br />
Einige Bausteine beziehen sich auf den gesamten Abruf, während andere Bausteine die Abrufpositionen<br />
betreffen. Während es zu den erst genannten Bausteinen in der vorliegenden Abrufbestellung<br />
nur eine Ausprägung gibt (z.B. „12.09.97“ für den Informationsbaustein<br />
Lieferabruf.Erstelldatum), existieren zu den letzteren Bausteinen mehrere Ausprägungen (z.B. „20“,<br />
„200“ und „5“ für den Informationsbaustein Lieferung.Artikel.Bestellmenge). Um Gültigkeitsbereiche<br />
von Informationsbausteinen festlegen zu können, werden sogenannte Informationscontainer<br />
verwendet. Sie verdeutlichen die hierarchische Struktur eines Informationsobjektes. Im<br />
Beispiel des Lieferabrufs ist der Informationscontainer Lieferabrufposition zu verwenden. Informationscontainer<br />
können neben Bausteinen wiederum weitere Informationscontainer enthalten.<br />
Die vollständige Informationsstruktur des Lieferabrufs zeigt Abbildung 11. Ein Vergleich mit dem<br />
Papierdokument aus Abbildung 10 führt zu der Feststellung, das neun Informationselementen des<br />
Belegkopfes und drei Elementen des Positionsteils genau neun bzw. drei Informationsbausteinen im<br />
Informationsstrukturdiagramm gegenüberstehen. Hier liegt ein deutlicher Unterschied zum Ansatz<br />
der EDIFACT-Vorschrift. Ein einzelnes Informationselement in der ursprünglichen Nachricht<br />
entspricht in der Regel mehr als einem Datenelement nach der Überführung in das EDIFACT-<br />
Format.<br />
Rolle: Warenempfänger<br />
Attribut: Einzelhandelsfiliale.Anschrift:Straßenbezeichnung<br />
• Lieferabruf:Erstelldatum<br />
• Warenempfänger:Name<br />
Lieferabruf<br />
• Warenempfänger.Anschrift:Straßenbezeichnung<br />
• Warenempfänger.Anschrift:Ortscode<br />
• Warenempfänger.Anschrift:Ortsname<br />
• Warenempfänger.vom Verkäufer vergebene Nummer<br />
• Rahmenauftrag:Nummer<br />
• Rahmenauftrag:Erstelldatum<br />
• Liefern.Geforderter Liefertermin: Datum<br />
Lieferabrufposition<br />
• Lieferung.Artikel:vom Verkäufer vergebene Nummer<br />
• Lieferung. Artikel:Bezeichnung<br />
• Lieferung.Artikel:Bestellmenge<br />
Legende: • Informationsbaustein Informationscontainer<br />
Abbildung 11: Informationsstrukturdiagramm des Lieferabrufs Backwaren<br />
Spezifizieren der Methoden<br />
Nachdem die Informationsstruktur bestimmt worden ist, lassen sich Integritätsmethoden für das<br />
Informationsobjekt spezifizieren. Sie sollen die Integrität der übertragenen Daten sichern und<br />
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<br />
Kategorien von Integritätsmethoden (vgl. auch [Sche97]):<br />
Methodenkategorie<br />
Prüfen auf konsistente<br />
Nachrichtenfolge<br />
Prüfen auf konsistente<br />
Nachrichten<br />
Prüfen auf Plausibilität<br />
Ergänzen fehlender<br />
Werte<br />
Umsetzen von<br />
codierten Daten<br />
Konvertieren von<br />
Datenformaten<br />
Beispiel (bezogen auf eine Sammelrechnung im AllBuy-Szenario)<br />
• Die Mengen der Rechnungspositionen müssen mit den Lieferscheinmengen<br />
übereinstimmen<br />
• Die Preise der Rechnung müssen mit den Preisen des Rahmenvertrags<br />
übereinstimmen<br />
• Die Rechnungssumme muss mit der Summe der Rechnungspositionen<br />
übereinstimmen<br />
• Die Postleitzahl muss mit dem Ort übereinstimmen<br />
• Es dürfen nur zulässige Mehrwertsteuersätze verwendet werden<br />
• Es dürfen nur gültige Artikelnummern verwendet werden<br />
• Nettobetrag fehlt (kann aus MwSt-Satz und Bruttobetrag berechnet<br />
werden)<br />
• Währungsangabe fehlt (kann durch Konstante aus Partnerstammsatz<br />
ersetzt werden, z.B. „DM“)<br />
• Verwendeter Code 07 für MwSt-Satz 7% wird in dem vom Partner<br />
verwendeten Code 02 umgesetzt.<br />
• Konvertieren des Rechnungsdatums von 12.09.1997 in 97/09/12<br />
Abbildung 12: Kategorien von Integritätsmethoden<br />
Jedem Informationsbaustein eines Informationsstrukturdiagramms und jedem Informationsobjekt<br />
lassen sich mehrere Integritätsmethoden der verschiedenen Kategorien zuordnen (vgl. Abbildung<br />
13). Die Spezifikation der Methoden erfolgt nach dem Event-Condition-Action-Modell (E-C-A)<br />
[HeKn95] / [DrRu99].<br />
Lieferabruf<br />
• Lieferabruf:Erstelldatum<br />
• Warenempfänger:Name<br />
•<br />
• Rahmenauftrag:Nummer<br />
• Rahmenauftrag:Erstelldatum<br />
•<br />
Lieferabrufposition<br />
•<br />
•<br />
Methodenkategorien<br />
Prüfen auf konsistente Nachrichtenfolgen<br />
(z.B. paßt das Datum zur Nummer)<br />
Prüfen auf konsistente Nachrichten<br />
Prüfen auf Plausibilität<br />
(z.B. Datum in der Zukunft unzulässig)<br />
Ergänzen fehlender Werte<br />
(z.B. aus Original-Rahmenauftrag)<br />
Umsetzen von codierten Daten<br />
Rahmenauftrag<br />
•<br />
• Rahmenauftrag:Nummer<br />
• Rahmenauftrag:Erstelldatum<br />
•<br />
Konvertieren von Datenformaten<br />
z.B. von “jj-mm-tt” nach “tt-mm-jj”<br />
Abbildung 13: Spezifizieren von Methoden
5 Nutzen<br />
Die modellbasierte Planung und Gestaltung des zwischenbetrieblichen Informationsaustausches<br />
bietet - unabhängig von der gewählten Implementierung oder vom verwendeten Standardformat -<br />
eine Reihe von Vorteilen gegenüber einer EDI-Lösung ohne vorausgehende <strong>Modellierung</strong>:<br />
Semantisch präzise Nachrichten<br />
Statt durch einen syntaxorientierten Feldkatalog werden mit dem <strong>Modellierung</strong>sansatz die Informationselemente<br />
<strong>zwischenbetrieblicher</strong> Nachrichten vor dem Hintergrund einer geschäftsprozessorientierten<br />
<strong>Modellierung</strong> in ihrer Semantik eindeutig bestimmt. Dadurch kann die Verständigung<br />
zwischen den Marktpartnern über die Bedeutung der auszutauschenden Nachrichten enorm<br />
beschleunigt werden.<br />
Vereinfachte Integration<br />
Neben den rein statischen Datenstrukturen werden bei der <strong>Modellierung</strong> auch die Methoden zur<br />
Verarbeitung der Nachrichten berücksichtigt. Die Einbettung der Informationsobjekte in ein<br />
zwischenbetriebliches Gesamtmodell ermöglicht es, auch nachrichtenübergreifende Zusammenhänge<br />
zwischen den einzelnen Informationselementen oder den Nachrichten selbst abzubilden.<br />
Damit wird der Entwurf und die Implementierung der für die Inhousesystem-Anbindung notwendigen<br />
Prüf- und Konvertierungsprozeduren effektiv unterstützt und vereinfacht.<br />
Unterstützung des zwischenbetrieblichen Projektmanagements<br />
Eine zwischenbetriebliche <strong>Modellierung</strong> trägt erheblich zur Transparenz und zum Verständnis der<br />
unternehmensübergreifenden <strong>Prozesse</strong> bei. Die <strong>Modellierung</strong>sergebnisse verbessern den Dialog<br />
zwischen den Verantwortlichen in den Fach- und DV-Abteilungen der beteiligten Marktpartner<br />
eines zwischenbetrieblichen Projektes und können somit die Projektlaufzeit verkürzen.<br />
Nutzen für die Standardisierung<br />
Eine <strong>Modellierung</strong> <strong>zwischenbetrieblicher</strong> <strong>Prozesse</strong> kann auch zu einer verbesserten Standardisierungsarbeit<br />
beitragen [TMWG98a]. Statt die syntaktischen Formate einzelner Datenfelder zu<br />
standardisieren, sollte durch die <strong>Modellierung</strong> eine Vereinbarung auf fachkonzeptueller Ebene<br />
erfolgen. Gegenüber dem Vorschlag der Techniques and Methodologies Working Group der<br />
CEFACT, dem Gremium für die Pflege und Weiterentwicklung des EDIFACT-Standards, die<br />
universale <strong>Modellierung</strong>ssprache UML zu verwenden [TMWG98b], wird in diesem Beitrag ein<br />
Ansatz vorgestellt, der eigens für die <strong>Modellierung</strong> <strong>zwischenbetrieblicher</strong> <strong>Prozesse</strong> entwickelt<br />
worden ist.<br />
Implementierungsunabhängigkeit
Die <strong>Modellierung</strong> <strong>zwischenbetrieblicher</strong> <strong>Prozesse</strong> erfolgt auf konzeptueller Ebene. Dies lässt<br />
mehrere Alternativen für die Implementierung zu. So können auch beim Einsatz traditioneller EDI-<br />
Technologien und Standardformaten die o.g. Vorteile erzielt werden. Denkbar sind aber auch internetbasierte<br />
Lösungen unter Nutzung neuerer Technologien wie XML oder Java.<br />
Im Folgenden wird eine Implementierungsalternative vorgestellt (vgl. Abbildung 14), die im<br />
eingangs erwähnten Forschungsprojekt entwickelt und erprobt worden ist [DrRu99]. Bei dieser<br />
Lösung spezifiziert der Sender die zu übertragenen Nachrichten mit einem<br />
Informationsstrukturdiagramm. In der gleichen Weise modelliert der Empfänger die entsprechende<br />
Schnittstelle seines Inhousesystems. Sender und Empfänger greifen dabei auf dieselbe<br />
Referenzbibliothek zurück. Ein Softwaregenerator erzeugt Javaklassen auf Basis der<br />
Informationsstrukturdiagramme. In einem konkreten Szenario wird die Javaklasse vom Sender<br />
instantiiert und mit Daten gefüllt. Die Übertragung zum Empfänger erfolgt durch Remote-Method-<br />
Invocation (RMI). Beim Empfänger wird das passende Schnittstellenobjekt aktiviert und entnimmt<br />
die Werte aus dem eingegangenem Informationsobjekt. Die Werte werden durch die<br />
Integritätsmethoden des Schnittstellenobjektes überprüft. Danach erfolgt die Konvertierung in das<br />
Format des Inhousesystems.<br />
Sender<br />
Empfänger<br />
Informationsstrukturdiagramm<br />
Referenzbibliothek<br />
Informationsstrukturdiagramm<br />
Softwaregenerator erzeugt<br />
Softwaregenerator erzeugt<br />
Java-Klasse<br />
Java-Klasse<br />
instantiiert<br />
instantiiert<br />
Informationsobjekt<br />
Bestellung<br />
Übertragen<br />
(z.B. durch RMI)<br />
Schnittstellenobjekt<br />
Bestellung<br />
konvertieren<br />
Integrität<br />
prüfen<br />
Inhouse-<br />
Format<br />
(z.B. SAP)<br />
Abbildung 14: EDI-Implementierung mit Java (vereinfacht)<br />
Die skizzierte Implementierung bietet neben den oben beschriebenen Vorteilen noch weiterreichende<br />
Vorzüge. So können die Informationsobjekte flexibel gestaltet und an die Erfordernisse<br />
der jeweiligen Geschäftsprozesse angepaßt werden, da sie nicht an ein festes Format gebunden sind.<br />
Im Mittelpunkt steht nicht mehr die Struktur einer Nachricht, sondern deren notwendigen Informationselemente.<br />
Diese sind sehr einfach aufgebaut; dementsprechend einfach können auch die Prüfund<br />
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<br />
den Softwaregenerator können die <strong>Modellierung</strong>sergebnisse direkt für die Implementierung nutzbar<br />
gemacht werden.<br />
6 Zusammenfassung und Ausblick<br />
Es wurde ein Ansatz zur <strong>Modellierung</strong> <strong>zwischenbetrieblicher</strong> <strong>Prozesse</strong> beschrieben und das<br />
Nutzenpotential für die Planung und Gestaltung des unternehmensübergreifenden Nachrichtenaustausches<br />
dargelegt. Zentrale Konzepte des Ansatzes sind<br />
• die <strong>Modellierung</strong> (modellbasiert),<br />
• die Objektorientierung (objektorientiert)<br />
• und die Betrachtung von einzelnen Informationsbausteinen statt kompletter Nachrichtenstrukturen<br />
(Bausteinansatz).<br />
Abbildung 15 gibt einen Überblick über Gemeinsamkeiten und Unterschiede gegenüber anderen<br />
aktuellen Ansätzen zur Integration von Informationssystemen bezüglich der genannten Punkte.
Ansatz Gemeinsamkeit Unterschied<br />
Open EDI<br />
• modellbasiert • nicht objektorientiert<br />
[ISO95]<br />
• kein Bausteinansatz<br />
Basic Semantic Register<br />
• Bausteinansatz • Nicht objektorientiert<br />
[ISO98]<br />
• nicht modellbasiert<br />
BEACON - Business Engineering • Bausteinansatz • (noch) nicht<br />
Architecture Construction Nexus [Stee97] • Objektorientiert modellbasiert<br />
Next Generation of UN/EDIFACT • modellbasiert • kein Bausteinansatz<br />
[TMWG98a]<br />
• objektorientiert<br />
OAGIS - Open Applications Group • Bausteinansatz • Nicht objektorientiert<br />
Integration Specification [OAG98]<br />
• nicht modellbasiert<br />
Abbildung 15: Gemeinsamkeiten und Unterschiede zu anderen Ansätzen<br />
Ziel ist es, den Ansatz um die Konzepte Ereignisse und betriebswirtschaftliche Regeln zu erweitern.<br />
Danach senden und empfangen Klientenobjekte zeitgesteuert oder nach definierten Regeln<br />
Informationsobjekte. Interaktionsobjekte überwachen und steuern andere Interaktionen. Zum Beispiel<br />
ist es denkbar, dass nach einer erfolgten Fakturierung der Zahlungseingang durch entsprechende<br />
Softwareobjekte überwacht wird und diese gegebenenfalls eine Mahnung auslösen.<br />
Wichtige Voraussetzung der <strong>Modellierung</strong> <strong>zwischenbetrieblicher</strong> <strong>Prozesse</strong> in der dargestellten<br />
Weise ist die Verwendung einer gemeinsamen Referenzbibliothek. Hierfür ist ein geeignetes<br />
Organisationskonzept zu entwickeln. Unter anderem ist zu klären, wer am Aufbau der<br />
Referenzbibliothek beteiligt ist, wie sie gewartet und ergänzt wird.<br />
Der vorgestellte Ansatz könnte wertvolle Anregungen für den aktuell diskutierten Datenaustausch<br />
auf Basis der Extensible Markup Language (XML) liefern. Insbesondere erscheint er kompatibel mit<br />
den Vorstellungen eines globalen XML/EDI-Repositories [Rama99] oder des Basic Semantic<br />
Registers der ISO [ISO98] und könnte dessen methodische und fachkonzeptuelle Grundlage bilden.<br />
Sollte sich die Standardisierung von Informationsbausteinen durchsetzen, so kann die <strong>Modellierung</strong><br />
<strong>zwischenbetrieblicher</strong> <strong>Prozesse</strong> dazu beitragen, dass die Vision eines automatisierten Informationsaustausches<br />
ohne bilaterale Absprachen zur Realität wird. Die Unternehmen modellieren dann ihre<br />
Schnittstellen in der vorgeschlagenen Weise mittels Informationsstrukturdiagrammen und veröffentlichen<br />
sie im Internet. Mögliche Marktpartner übersenden Informationsobjekte mit den geforderten<br />
Informationsbausteinen.
7 Literatur<br />
[CoYo91] Coad, P.; Yourdon, E.: Object-Oriented Analysis; 2. Aufl.; Englewood Cliffs 1991<br />
[DrRu99] Dresing, H.; Rulle, A.: Ein Framework für das modellgestützte Generieren von<br />
Softwareobjekten in MOVE; in: <strong>Objektorientierte</strong> Modelle und Werkzeuge für<br />
unternehmensübergreifende Informationssysteme im Rahmen des Electronic<br />
Commerce, Köln 1999<br />
[FeSi94] Ferstl, O.K.; Sinz, E.J.: Grundlagen der Wirtschaftsinformatik; 2. Aufl.; München,<br />
Wien 1994<br />
[FiKe+98] Fischer, J.; Kern, U.; Hammer, G.; Rulle, A.; Städler, M.; Steffen, Th.: Verbundprojekt<br />
MOVE - <strong>Modellierung</strong> einer Verteilten Architektur für die Entwicklung<br />
unternehmensübergreifender Informationssysteme und ihre Validierung im Handelsbereich;<br />
Statusband Softwaretechnologie des BMBF; Berlin 1998<br />
[Fisc92] Fischer, J.: Datenmanagement: Datenbanken und betriebliche Datenmodellierung;<br />
München, Wien 1992<br />
[Fisc99a] Fischer, J.: MOVE als Architektur für zwischenbetriebliche Informationssysteme; in:<br />
<strong>Objektorientierte</strong> Modelle und Werkzeuge für unternehmensübergreifende<br />
Informationssysteme im Rahmen des Electronic Commerce, Köln 1999<br />
[Fisc99b] Fischer, J.: Informationswirtschaft: Anwendungsmanagement; München, Wien 1999<br />
[FiSt98] Fischer, J.; Städler, M.: Efficient Consumer Response und zwischenbetriebliche<br />
Integration; in: Hippner, H.; Meyer, M.; Wilde, K.D. (Hrsg.): Computer-Based<br />
Marketing - Das Handbuch zur Marketinginformatik, Wiesbaden 1998, S. 349-356<br />
[Hage96] Hagen, K.: Efficient Consumer Response (ECR) - ein neuer Weg in der Kooperation<br />
zwischen Industrie und Handel; in: Pfohl, H.-Chr. (Hrsg.): Integrative Instrumente<br />
der Logistik; Berlin 1996; S. 86-96<br />
[HeKn95] Herbst, H.; Knolmayer, G.: Ansätze zur Klassifikation von Geschäftsregeln; in:<br />
Wirtschaftsinformatik; Bd. 37; 2/1995; S. 149-159<br />
[HiSc94] Hirschmann, P.; Scheer, A.-W.: Konzeption einer DV-Unterstützung für das<br />
überbetriebliche Prozeßmanagement; in: Scheer, A.-W. (Hrsg.): Veröffentlichungen<br />
des Instituts für Wirtschaftsinformatik (IWi). Heft 113; Saarbrücken 1994<br />
[HlHo99] Hluchy, R.; Hoos, J.: Analyse <strong>zwischenbetrieblicher</strong> Geschäftsprozesse mit Hilfe der<br />
Simulationstechnik; in: <strong>Objektorientierte</strong> Modelle und Werkzeuge für<br />
unternehmensübergreifende Informationssysteme im Rahmen des Electronic<br />
Commerce, Köln 1999<br />
[ISO95] International Organization for Standardization (Hrsg.): Information Technology -<br />
Open edi reference model. http://www.harbinger.com/resource/klaus/openedi/model/oerm.htm,<br />
1995, Abruf am 1999-01-29.<br />
[ISO98] International Organization for Standardization (Hrsg.): Basic Semantic Register<br />
(BSR). http://www.iso.ch/BSR/index.htm, Abruf am 1998-07-23.<br />
[Kosi69] Kosiol, E.: Die Unternehmung als wirtschaftliches Aktionszentrum, Reinbek bei<br />
Hamburg 1969
[MOVE95] BFK, EHI, ICL, Winfo1: <strong>Modellierung</strong> einer Verteilten Architektur für die Entwicklung<br />
unternehmensübergreifender Informationssysteme und ihre Validierung im<br />
Handelsbereich, Antrag zum BMBF-Forschungsprojekt 01 IS 602 D (MOVE);<br />
Paderborn 1995<br />
[Müll98] Müller-Zantop, S.: Neue Perspektiven für Logistiksysteme; in: Computerwoche;<br />
1/1998; S. 10-13<br />
[OAG98] Open Applications Group (Hrsg.): Open Applications Group Integration<br />
Specification (OAGIS) Release 6.1, 1999; http://www.openapplications.org/_vti_bin/<br />
shtml.exe/oagis/loadform.htm; Abruf am 1999-01-29.<br />
[Quib94] Quibeldey-Cirkel, K.: Das Objekt-Paradigma in der Informatik. Stuttgart 1994<br />
[Rama99] Raman, D.: Setting up a UN Repository for XML/EDI;<br />
http://www.cenorm.be/isss/workshop/ec/xmledi/Documents_99/xml004_99.htm;<br />
Abruf am 1999-02-26.<br />
[Rati97] Rational (Hrsg.): UML Notation Guide - Version 1.1.<br />
http://www.rational.com/uml/html/notation/index.html, 1997-09-01, Abruf am 1998-<br />
07-23.<br />
[Sche97] Scheckenbach, R.: Semantische Geschäftsprozessintegration - Einbindung<br />
<strong>zwischenbetrieblicher</strong> Geschäftsprozesse in betriebliche Anwendungssysteme; Diss.;<br />
Universität Würzburg 1997<br />
[Schü98] Schüppler, D.: Informationsmodelle für überbetriebliche <strong>Prozesse</strong>; Frankfurt a.M.<br />
1998<br />
[Stee97] Steel, K.: The BEACON User's Guide. ftp://turiel.cs.mu.oz.au/pub/edi/beaug1.doc,<br />
1997-08-07, Abruf am 1998-07-23.<br />
[Stei97] Stein, W.: <strong>Objektorientierte</strong> Analysemethoden: Vergleich, Bewertung, Auswahl; 2.<br />
Aufl.; Heidelberg, Berlin, Oxford 1997<br />
[Ster97] Stern, A.: Verteilte Kommunikation; in: iX; 3/1997; S. 100-107<br />
[TMWG98a] Techniques and Methodologies Working Group (Hrsg.): Reference Guide - The Next<br />
Generation of UN/EDIFACT (Revision 12). http://www.harbinger.com/resource/<br />
klaus/tmwg/tm010.pdf, 1998-07-07, Abruf am 1998-08-27.<br />
[TMWG98b] Techniques and Methodologies Working Group (Hrsg.): Explanation of TMWG<br />
Decision to use Unified Modeling Language (UML) for business process and<br />
information modeling. http://www.harbinger.com/resource/klaus/tmwg/tm065.pdf,<br />
1998-09-03, Abruf am 1998-11-27.