Objektorientierte Modellierung zwischenbetrieblicher Prozesse

Größe: px
Ab Seite anzeigen:

Download "Objektorientierte Modellierung zwischenbetrieblicher Prozesse"

Transkript

1 Objektorientierte Modellierung zwischenbetrieblicher Prozesse Dipl.-Wirt. Inform. Thomas Steffen Prof. Dr. Joachim Fischer Universität-Gesamthochschule Paderborn, Schwerpunkt Wirtschaftsinformatik 1 Warburger Str. 100, Paderborn {steffen 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:

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

3 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 Prozessdiagramme Interaktionsdiagramme 3. Informationssstrukturdiagramme Modellbibliothek Referenzbibliothek Modellierungsergebnisse Prototyp: Objektorientiertes Entwurfsinstrument Output abgestimmte Nachrichtenstrukturen für einen zwischenbetrieblichen Prozess Abbildung 1: Vorgehen des Modellierungsansatzes

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

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

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

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

8 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

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

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

11 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

12 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

13 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 Köln Kd.-Nr Datum der Bestellung: Betr. Rahmenvertrag-Nr v Liefertermin Art.-Nr Artikelbezeichnung Aufbackbrötchen, 6er-Pack Brötchen, normal, rund, 40g Rosinenbrot, 750g Menge 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 , Rahmenvertrag-Nr 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

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

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

16 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

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

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

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

20 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 [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 [HeKn95] Herbst, H.; Knolmayer, G.: Ansätze zur Klassifikation von Geschäftsregeln; in: Wirtschaftsinformatik; Bd. 37; 2/1995; S [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 , Abruf am [ISO98] International Organization for Standardization (Hrsg.): Basic Semantic Register (BSR). Abruf am [Kosi69] Kosiol, E.: Die Unternehmung als wirtschaftliches Aktionszentrum, Reinbek bei Hamburg 1969

Ansatz einer modellbasierten Integration zwischenbetrieblicher Geschäftsprozesse und deren Informationsflüsse

Ansatz einer modellbasierten Integration zwischenbetrieblicher Geschäftsprozesse und deren Informationsflüsse Ansatz einer modellbasierten Integration zwischenbetrieblicher Geschäftsprozesse und deren Informationsflüsse Dipl.-Wirt. Inform. Thomas Steffen Prof. Dr. Joachim Fischer Universität-Gesamthochschule Paderborn,

Mehr

Workshop 3. Excel, EDIFACT, ebxml- Was ist state. of the art und wo liegt die Zukunft. 16. September 2002

Workshop 3. Excel, EDIFACT, ebxml- Was ist state. of the art und wo liegt die Zukunft. 16. September 2002 Workshop 3 Excel, EDIFACT, ebxml- Was ist state of the art und wo liegt die Zukunft 16. September 2002 Dipl. Kfm. power2e energy solutions GmbH Wendenstraße 4 20097 Hamburg Telefon (040) 80.80.65.9 0 info@power2e.de

Mehr

EDI/XML Datentransaktionen über System- und Unternehmensgrenzen. Referent: Jan Freitag

EDI/XML Datentransaktionen über System- und Unternehmensgrenzen. Referent: Jan Freitag EDI/XML Datentransaktionen über System- und Unternehmensgrenzen Referent: Jan Freitag Warum EDI? Internet bedeutender Wirtschaftsfaktor Nur wenige Unternehmen steuern Geschäftsprozesse über das Internet

Mehr

EDI CONNECT. für Microsoft Dynamics NAV. Auf einen Blick:

EDI CONNECT. für Microsoft Dynamics NAV. Auf einen Blick: Seite 1 PROTAKT Speziallösung EDI Connect Auf einen Blick: EDI CONNECT für Microsoft Dynamics NAV Elektronischer Datenaustausch ganz effizient und einfach über Ihr Microsoft Dynamics NAV System. Vollständige

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 378 Umsetzung ausgewählter Supply-Chain-Operations-Reference-Metriken durch das

Mehr

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel. EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG

Mehr

Informationsmanagement Übungsstunde 6

Informationsmanagement Übungsstunde 6 Informationsmanagement Übungsstunde 6 Univ.-Prof. Dr.-Ing. Wolfgang Maass Lehrstuhl für Betriebswirtschaftslehre, insb. Wirtschaftsinformatik im Dienstleistungsbereich (Information and Service Systems

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: EVI Energieversorgung Hildesheim

Mehr

Weniger Kosten, mehr Möglichkeiten. Electronic Data Interchange (EDI): Optimierung von Geschäftsprozessen durch beleglosen Datenaustausch

Weniger Kosten, mehr Möglichkeiten. Electronic Data Interchange (EDI): Optimierung von Geschäftsprozessen durch beleglosen Datenaustausch Weniger Kosten, mehr Möglichkeiten Electronic Data Interchange (EDI): Optimierung von Geschäftsprozessen durch beleglosen Datenaustausch Schneller, transparenter, kostengünstiger EDI Was ist EDI und was

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 350

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 350 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 350 Ein konzeptioneller Business-Intelligence-Ansatz zur Gestaltung von Geschäftsprozessen

Mehr

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7 Berichte aus der Medizinischen Informatik und Bioinformatik Günther Schadow Krankenhauskommunikation mit HL7 Analyse, Implementation und Anwendungeines Protokollstandards für medizinische Datenkommunikation

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) Hinweis: Vorliegende EDI-Vereinbarung basiert auf der BDEW Mustervereinbarung über den elektronischen Datenaustausch. Artikel 1 Zielsetzung und

Mehr

Toolgestützte Prozessdokumentation. Prozessorientiertes E-Government, 28.10.2005 Joel Meir, jmeir@csc.com, +41 31 998 46 46

Toolgestützte Prozessdokumentation. Prozessorientiertes E-Government, 28.10.2005 Joel Meir, jmeir@csc.com, +41 31 998 46 46 Toolgestützte Prozessdokumentation Prozessorientiertes E-Government, 28.10.2005 Joel Meir, jmeir@csc.com, +41 31 998 46 46 Wir bieten unseren Kunden End-to-End Lösungen an Consulting Systems Integration

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) Zwischen dem Netzbetreiber Strom und Gas Netze BW GmbH Schelmenwasenstr. 15, 70567 Stuttgart und dem Lieferanten / dem Transportkunden: Name:.

Mehr

Vereinbarung über den elektronischen Datenaustausch

Vereinbarung über den elektronischen Datenaustausch Vereinbarung über den elektronischen Datenaustausch RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Heidelberg Netze GmbH

Mehr

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage.

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage. Integration mit Die Integration der AristaFlow Business Process Management Suite (BPM) mit dem Enterprise Information Management System FILERO (EIMS) bildet die optimale Basis für flexible Optimierung

Mehr

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen.

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. 181 In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. Wir beginnen mit dem Startup-Unternehmen Seals GmbH aus Frankfurt,

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Kaltenkirchen

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Energieversorgung Marienberg

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: und Stadtwerke Bad Salzuflen

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) Zwischen Stadtwerke Merseburg GmbH Große Ritterstraße 9 06217 Merseburg VDEW-Nr.: 9900964000008 (nachfolgend Netzbetreiber genannt) und Name Straße

Mehr

Mustervereinbarung über den elektronischen Datenaustausch (EDI)

Mustervereinbarung über den elektronischen Datenaustausch (EDI) Mustervereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Waldkirch

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: und Stadtwerke Marburg GmbH,

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Anlage c zum Netznutzungsvertrag Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Stadtwerke Heilbad Heiligenstadt GmbH Schlachthofstraße 8 37308 Heilbad Heiligenstadt und nachfolgend

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Transportkunde und Energieversorgung

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI) Gas

Vereinbarung über den elektronischen Datenaustausch (EDI) Gas Vereinbarung über den elektronischen Datenaustausch (EDI) Gas RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Netzbetreiber Stadtwerke

Mehr

Mustervereinbarung über den elektronischen Datenaustausch (EDI)

Mustervereinbarung über den elektronischen Datenaustausch (EDI) Mustervereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Energie Calw GmbH

Mehr

Lieferantenrahmenvertrag Gas Anlage 3 Mustervereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN

Lieferantenrahmenvertrag Gas Anlage 3 Mustervereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen wird getroffen von und zwischen: NEW Schwalm-Nette Netz GmbH Rektoratstraße 18 41747 Viersen 9870115400002 und «Lieferant» «Straße» «PLZ»

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Kraftwerk Köhlgartenwiese GmbH Tegernauer Ortsstraße 9 79692 Kleines Wiesental und - nachfolgend die Vertragspartner genannt Seite 1 von

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen zwischen: Greizer Energienetze GmbH Mollbergstr. 20 07973 Greiz (Verteilnetzbetreiber)

Mehr

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

Quality Point München Datenqualität

Quality Point München Datenqualität Quality Point München Datenqualität Paul, wie ist denn Eure Datenqualität? Nachdem ich bei der letzten Gehaltszahlung mit Frau... angeredet wurde, bin ich mir nicht mehr so sicher. Autor: W. Ulbrich IT&More

Mehr

Vereinbarung über den elektronischen Datenaustausch. EDI-Rahmenvertrag

Vereinbarung über den elektronischen Datenaustausch. EDI-Rahmenvertrag Vereinbarung über den elektronischen Datenaustausch EDI-Rahmenvertrag zwischen den Stadtwerken Esslingen am Neckar GmbH & Co. KG in 73728 Esslingen am Neckar, Fleischmannstraße 50 - im Folgenden "Netzbetreiber"

Mehr

eine Aufgabe vorliegt, zu deren Lösung die Zusammenarbeit mehrerer Bereiche erforderlich

eine Aufgabe vorliegt, zu deren Lösung die Zusammenarbeit mehrerer Bereiche erforderlich chnittstellenorientierte Gestaltung von ntwicklungskooperationen chnittstellenmanagement chnittstellen entstehen durch das Zusammenwirken verschiedener organisatorischer inheiten in einem arbeitsteiligen

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI) Strom

Vereinbarung über den elektronischen Datenaustausch (EDI) Strom Ergänzung zum Lieferantenrahmenvertrag Strom Vereinbarung über den elektronischen Datenaustausch (EDI) Strom RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI) (Stand: 20110101)

Vereinbarung über den elektronischen Datenaustausch (EDI) (Stand: 20110101) Vereinbarung über den elektronischen Datenaustausch (EDI) (Stand: 20110101) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: und Energie

Mehr

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6.

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6. 6. Modellierung von Informationssystemen Spezialseminar Matr. FS 2000 1/10 Volker Dobrowolny FIN- ITI Quellen: Oscar Pastor, Jaime Gomez, Emilio Insfran, Vicente Pelechano The OO-Method approach for information

Mehr

RECHTLICHE BESTIMMUNGEN

RECHTLICHE BESTIMMUNGEN Seite 1 von 5 Anlage 4 zum Netznutzungsvertrag (Erdgas) EDI-Rahmenvereinbarung RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen zwischen: Alliander Netz

Mehr

Sonstiges Wahlfach Wirtschaftsinformatik

Sonstiges Wahlfach Wirtschaftsinformatik Sonstiges Wahlfach Wirtschaftsinformatik Anhang Nr. 48: Wirtschaftsinformatik Das Fach ist bestanden, wenn 24 Leistungspunkte erworben wurden. Veranstaltungsform SWS Turnus Leistungspunkte Prüfungsform

Mehr

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML) Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Vorlesung Programmieren

Vorlesung Programmieren Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Geschäftsprozesse: Modellierung und Analyse

Geschäftsprozesse: Modellierung und Analyse Geschäftsprozesse: Modellierung und Analyse. Ausgangssituation 2. Begriffe 3. Modellierungsmethoden 4. Modellarten 5. orgehensprinzipien 6. Analyse 7. Werkzeuge Seite Klassische Unternehmensmodelle Unternehmensmodell:

Mehr

RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen:

RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Anlage 3: Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Strom- und Gasversorgung

Mehr

Anlage 3: EDI-Rahmenvertrag

Anlage 3: EDI-Rahmenvertrag Anlage 3: EDI-Rahmenvertrag Rechtliche Bestimmungen Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: TaunaGas Oberursel (Taunus) GmbH Oberurseler Str. 55-57

Mehr

SÜC Energie und H 2 O GmbH Anlage 2

SÜC Energie und H 2 O GmbH Anlage 2 Anlage 2 Vereinbarung über den elektronischen Datenaustausch (EDI Vereinbarung) zwischen, vertreten durch,, und SÜC Energie und H 2 O GmbH (SÜC), vertreten durch den Geschäftsführer Götz-Ulrich Luttenberger,

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen Gemeindewerke Niefern-Öschelbronn

Mehr

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2 EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0 EDV Kurs 13/2 Inhaltsverzeichnis 1 Objekte... 1 2 Klassen... 3 2.1 Beziehungen zwischen Klassen... 4 2.1.1 Vererbung... 4 2.1.2

Mehr

Vorschau. Leitfaden zur Umsetzung von CPFR im deutschsprachigen Wirtschaftsraum. Supply Chain Management. Effiziente Prozesse im Fokus

Vorschau. Leitfaden zur Umsetzung von CPFR im deutschsprachigen Wirtschaftsraum. Supply Chain Management. Effiziente Prozesse im Fokus Kapitel 2 Supply Chain Management Effiziente Prozesse im Fokus im deutschsprachigen Wirtschaftsraum Inhaltsverzeichnis 2 im deutschsprachigen Wirtschaftsraum Kapitel/Abschnitt Seite 2.1 Einführung... 4

Mehr

Datenbankmodelle 1. Das Entity-Relationship-Modell

Datenbankmodelle 1. Das Entity-Relationship-Modell Datenbankmodelle 1 Das Entity-Relationship-Modell Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle ER Modell - 2 Was kann modelliert werden?

Mehr

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5 Das Management von Informations- Systemen im Wandel Die Informations-Technologie (IT) war lange Zeit ausschließlich ein Hilfsmittel, um Arbeitsabläufe zu vereinfachen und Personal einzusparen. Sie hat

Mehr

Modellierung von Arbeitsprozessen

Modellierung von Arbeitsprozessen Informatik II: Modellierung Prof. Dr. Martin Glinz Kapitel 9 Modellierung von Arbeitsprozessen Universität Zürich Institut für Informatik Inhalt 9.1 Grundlagen 9.2 Ereignisgesteuerte Prozessketten (EPK)

Mehr

EDI. Elektronischer Datenaustausch

EDI. Elektronischer Datenaustausch EDI Elektronischer Datenaustausch 1 Inhalt EDI Was ist das? EDI Ihre Vorteile EDI Einbindung und Einsparung EDI Ihre Ansprechpartner 2 EDI Was ist das? 3 Definitionen EDI (Electronic Data Interchange)

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

Vereinbarung über den Elektronischen Datenaustausch (EDI)

Vereinbarung über den Elektronischen Datenaustausch (EDI) Vereinbarung über den Elektronischen Datenaustausch (EDI) zwischen und Energie- und Wasserversorgung Bruchsal GmbH Schnabel-Henning-Straße 1a 76646 Bruchsal im Folgenden Parteien genannt EDI Stand 10.2009

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Bamberg Energie-

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

EDI / Ein Überblick. EDI / Was ist das? Ihre Vorteile. Einsparpotentiale. Ansprechpartner. Hansgrohe. All rights reserved.

EDI / Ein Überblick. EDI / Was ist das? Ihre Vorteile. Einsparpotentiale. Ansprechpartner. Hansgrohe. All rights reserved. EDI / Ein Überblick EDI / Was ist das? Ihre Vorteile Einsparpotentiale Ansprechpartner EDI / Was ist das? EDI (Electronic Data Interchange) EDI ist die elektronische Abwicklung von Geschäftsprozessen von

Mehr

Definition der Schnittstelle zur Übertragung der. gemäß Deponieselbstüberwachungsverordnung NRW

Definition der Schnittstelle zur Übertragung der. gemäß Deponieselbstüberwachungsverordnung NRW Jahresberichte gemäß Deponieselbstüberwachungsverordnung NRW Inhaltsverzeichnis... 1 Historie der Änderungen... 2 Einleitung... 2 Rückblick... 2 Auswirkungen der neuen Verordnung... 2 Auslieferung... 2

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: und Energieversorgung Pirna

Mehr

Enterprise Architecture Management (EAM)

Enterprise Architecture Management (EAM) your IT in line with your Business Enterprise Architecture Management (EAM) Unternehmensziele im Mittelpunkt der Informationstechnologie 2015 SYRACOM AG Part of Consileon Group Motivation für EAM In vielen

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Bexbach GmbH

Mehr

Qualifizierung zum Business Analyst

Qualifizierung zum Business Analyst Qualifizierung zum Business Analyst Brückenbauer für Business- und IT-Organisation Informationsveranstaltung 34. Meeting der Local Group Hamburg Des PMI Frankfurt Chapter e. V. Dr. Bernhard Schröer Partner

Mehr

Ordentliche Geschäftsprozessmodellierung (GPM) nutzt auch Ihrer IT-Infrastruktur. (Was hat GPM mit IT zu tun?) Antonius J.M.

Ordentliche Geschäftsprozessmodellierung (GPM) nutzt auch Ihrer IT-Infrastruktur. (Was hat GPM mit IT zu tun?) Antonius J.M. Ordentliche Geschäftsprozessmodellierung (GPM) nutzt auch Ihrer IT-Infrastruktur (Was hat GPM mit IT zu tun?) Antonius J.M. van Hoof Fachrichtung Informationstechnik GPM-Workshop 07.07.2006 Inhalt Kernpunkte

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Empfehlung für die technische Kommunikation von Produktänderungen im GDSN

Empfehlung für die technische Kommunikation von Produktänderungen im GDSN 1 Germany Empfehlung für die technische Kommunikation von Produktänderungen im GDSN Version 1.0 Stand Mai 2014 I I I Global Standards. Make Business Efficient. Zielsetzung des Dokuments Ziel der vorliegenden

Mehr

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

Anlage 3: Mustervereinbarung über den elektronischen Datenaustausch (EDI)

Anlage 3: Mustervereinbarung über den elektronischen Datenaustausch (EDI) Anlage 3: Mustervereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den wird getroffen von und zwischen: Gasversorgung Pforzheim Land GmbH, Sandweg 22,

Mehr

your IT in line with your Business Geschäftsprozessmanagement (GPM)

your IT in line with your Business Geschäftsprozessmanagement (GPM) your IT in line with your Business Geschäftsprozessmanagement (GPM) Transparenz schaffen und Unternehmensziele effizient erreichen Transparente Prozesse für mehr Entscheidungssicherheit Konsequente Ausrichtung

Mehr

Prozesskette Funktionsdaten und Funktionsmodelle

Prozesskette Funktionsdaten und Funktionsmodelle Prozesskette Funktionsdaten und Funktionsmodelle Stuttgart, 11. Februar 2015 D. Ruschmeier 2/15 Wesentliche Eingangsparameter für die funktional-basierten Berechnungsverfahren sind: Anforderungs-, Modellbeschreibungen

Mehr

E-Business Seminar SS 2005

E-Business Seminar SS 2005 E-Business Seminar SS 2005 Beschreibung von Interorganisationalen Informationssystemen (IOIS) und Industriestrukturen Vorgetragen von Martin Leenders Bearbeiteter Text: Contours of diffusion of electronic

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI) (Gas)

Vereinbarung über den elektronischen Datenaustausch (EDI) (Gas) Steinmühlstr 26 61352 Bad Homburg v. d. Höhe Telefon 06172 4013-0 Telefax 06172 489442 http://www.stadtwerke-bad-homburg.de gasnetzzugang@sw.bad-homburg.de Amtsgericht Bad Homburg v.d.h., HRA 3300 Steuer-Nr.

Mehr

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle 1 Das Entity-Relationship-Modell Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle Prof. Dr.

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Kulmbach, Schützenstraße

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) Rechtliche Bestimmungen Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stromversorgung Zerbst GmbH

Mehr

Software-Engineering

Software-Engineering FH Wedel Prof. Dr. Sebastian Iwanowski SWE2 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 2: Grundbegriffe und Prinzipien FH Wedel Prof. Dr. Sebastian Iwanowski SWE2 Folie 2 Grundbegriffe

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) Zwischen und Lieferant Straße, Hausnummer PLZ, Ort Stadtwerke Strausberg GmbH Kastanienallee 38 15344 Strausberg nachstehend gemeinsam Parteien

Mehr

Standards und Standardisierungsgremien

Standards und Standardisierungsgremien Standards und Standardisierungsgremien Begriffe Norm und Standard synonym Organisationen z.b. ISO: International Standards Organization DIN: Deutsches Institut für Normung e.v. ANSI: American National

Mehr

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Modellierungstechniken im Softwaredesign Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Was ist Modellierung? Modell = Ein Modell ist eine Repräsentation eines Systems von Objekten,

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

EINFÜHRUNG 06.06.2013 IOZ AG 1

EINFÜHRUNG 06.06.2013 IOZ AG 1 BPMN BPMN2.0 EINFÜHRUNG 06.06.2013 IOZ AG 1 EINFÜHRUNG GESCHÄFTSPROZESSMODELLIERUNG Was ist Geschäftsprozessmodellierung? Darstellung von geschäftlichen Abläufen und deren Interaktion Was wird inhaltlich

Mehr

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur UML-Klassendiagramme als Werkzeug im Unterricht Blitzlicht? In welcher Programmiersprache(n) unterrichten Sie?? In welchem Umfang unterrichten Sie Objektorientierung??

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Mainfranken Netze GmbH Haugerring 6 97070 Würzburg und - nachfolgend die Vertragspartner genannt Stand 16.04.2015 Seite 1 von 5 1. Zielsetzung

Mehr

BPMN vs. EPK & Co. oder auf was es wirklich ankommt

BPMN vs. EPK & Co. oder auf was es wirklich ankommt BPMN vs. EPK & Co. oder auf was es wirklich ankommt Sebastian Adam, Norman Riegel 15. Mai 2012, St. Augustin Die Fraunhofer-Gesellschaft e.v. Benannt nach: Rolle der FraunhoferGesellschaft: Größe: Forschungsvolumen:

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Connect-Veranstaltung 24. Juni 2003 Eröffnungsvortrag

Connect-Veranstaltung 24. Juni 2003 Eröffnungsvortrag Titel Connect-Veranstaltung 24. Juni 2003 Eröffnungsvortrag e-logistics goes Collaborative Business Prof. Dr. Jürgen Treffert Fachleiter Wirtschaftsinformatik / BA-Lörrach Leiter STZ IT-BusinessConsulting

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: ZVO Energie GmbH und...

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Stromnetz Berlin GmbH Puschkinallee 52 12435 Berlin und nachfolgend die Vertragspartner genannt 2016 1 Zielsetzung und Geltungsbereich

Mehr

Aufgaben und Lösungshinweise zum Lehrbuch

Aufgaben und Lösungshinweise zum Lehrbuch Aufgaben und Lösungshinweise zum Lehrbuch UVK Verlagsgesellschaft mbh 204 Aufgaben zu Kapitel 4 Aufgabe : (Grundlagen von IT-Services) Nennen Sie vier Kriterien, die für die Gebrauchstauglichkeit eines

Mehr

Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei Lieferanten

Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei Lieferanten Handelsplatz Köln.de Leitfaden zur Projektplanung bei en Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei en Autor: Christoph Winkelhage Status: Version 1.0 Datum:

Mehr

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen. Schleswiger Stadtwerke GmbH. Werkstraße 1. 24837 Schleswig.

Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen. Schleswiger Stadtwerke GmbH. Werkstraße 1. 24837 Schleswig. Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Schleswiger Stadtwerke GmbH Werkstraße 1 24837 Schleswig und (im Folgenden Parteien genannt) Artikel 1 Zielsetzung und Geltungsbereich

Mehr

Edi-Rahmenvertrag. Stadtwerke Goch GmbH Klever Str. 26-28 47574 Goch. Lieferant Straße Hausnr. PLZ Ort

Edi-Rahmenvertrag. Stadtwerke Goch GmbH Klever Str. 26-28 47574 Goch. Lieferant Straße Hausnr. PLZ Ort Seite 1 von 5 Edi-Rahmenvertrag Zwischen Und Klever Str. 26-28 47574 Goch Lieferant Straße Hausnr. PLZ Ort wird folgender Rahmenvertrag über den elektronischen Nachrichtenaustausch geschlossen: Artikel

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Weinheim GmbH

Mehr