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

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

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

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

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

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

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

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

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

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

XML in der betrieblichen Praxis

XML in der betrieblichen Praxis Klaus Turowski, Klement J. Fellner (Hrsg.) XML in der betrieblichen Praxis Standards, Möglichkeiten, Praxisbeispiele Ги dpunkt.verlag Inhaltsverzeichnis 1 XML/EDI-Standardisierung: Ein Überblick 1 1.1

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

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

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

Welcome to PHOENIX CONTACT

Welcome to PHOENIX CONTACT Welcome to PHOENIX CONTACT Electronic Data Interchange (EDI) Überblick Begriffsdefinition: EDI Elektronischer Datenaustausch, englisch Electronic Data Interchange (EDI), bezeichnet als Sammelbegriff alle

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

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

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

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

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

Orientierte Modellierung mit der Unified Modeling Language

Orientierte Modellierung mit der Unified Modeling Language UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?

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

Geschäftsprozesse: Modellierung und Analyse

Geschäftsprozesse: Modellierung und Analyse Geschäftsprozesse: Modellierung und Analyse 1. Ausgangssituation 2. Begriffe 3. Modellierungsmethoden 4. Modellarten 5. Vorgehensprinzipien 6. Analyse 7. Werkzeuge Begriffe: Methoden, Verfahren, Notationen,...

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

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

Software-Engineering im Aris-Konzept als Ansatz der Integration der IT-Landschaft von Unternehmen

Software-Engineering im Aris-Konzept als Ansatz der Integration der IT-Landschaft von Unternehmen Software-Engineering im Aris-Konzept als Ansatz der Integration der IT-Landschaft von Unternehmen Martin Plümicke 25. Oktober 2002 1 These: IT im Unternehmen ist mehr als nur die Analyse von Geschäftsprozessen.

Mehr

Die ERP-Lösung für die Automotive-Branche

Die ERP-Lösung für die Automotive-Branche Die ERP-Lösung für die Automotive-Branche OXAION DIE LÖSUNG FÜR DIE ZULIEFERER DER AUTOMOBILINDUSTRIE Absolute Liefertreue und höchste Flexibilität: Das sind die Hauptanforderungen an die Automobilzulieferer.

Mehr

Einkaufskatalogsystem

Einkaufskatalogsystem Einkaufskatalogsystem Titel des Lernmoduls: Einkaufskatalogsystem Themengebiet: New Economy Gliederungspunkt im Curriculum: 2.2.1.3.5 Zum Inhalt: Dieses Modul befasst sich mit elektronischen Einkaufskatalogen

Mehr

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com Use Cases REQEDIT CLIENT Mai 2014 Übersicht 1. Einführung Anforderungsmanagement 2. Einführung Anforderungsmanagementtools und Austauschformate 3. Warum ReqEdit? 4. Use Cases - kleinere und mittlere Unternehmen

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

Fundamentals of Software Engineering 1

Fundamentals of Software Engineering 1 Folie a: Name Fundamentals of Software Engineering 1 Grundlagen der Programmentwurfstechnik 1 Sommersemester 2012 Dr.-Ing. Stefan Werner Fakultät für Ingenieurwissenschaften Folie 1 Inhaltsverzeichnis

Mehr

Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses

Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses Gunter Grieser, Simon Spielmann, Guido Schuh, Boris Kötting, Ralf Leonhard AGENDA Das Projekt Unser

Mehr

BPMN. Suzana Milovanovic

BPMN. Suzana Milovanovic BPMN Suzana Milovanovic 2 Übersicht Klärung von Begriffen, Abkürzungen Was ist BPMN? Business Process Diagram (BPD) Beispielprozess Entwicklung von BPMN BPMN in der Literatur 3 Grundlegende Begriffe Business

Mehr

Implementation-Guideline EANCOM ORDERS D.96A. Version 1.0. Versandhaus Walz GmbH

Implementation-Guideline EANCOM ORDERS D.96A. Version 1.0. Versandhaus Walz GmbH Implementation-Guideline EANCOM ORDERS D.96A Version 1.0 Versandhaus Walz GmbH Steinstrasse 28 88339 Bad Waldsee EDI-Implementation-Guideline EANCOM ORDERS D.96A - 2 - Änderungshistorie: - 10.07.2014:

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

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/)

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Enterprise Continuum Wiederverwendung von Unternehmensarchitekturen Modul

Mehr

PARITY.ERP EDI. Integriertes EDI-Softwaresystem AUSGANGSSITUATION PARITY LÖSUNG

PARITY.ERP EDI. Integriertes EDI-Softwaresystem AUSGANGSSITUATION PARITY LÖSUNG PARITY.ERP EDI Integriertes EDI-Softwaresystem AUSGANGSSITUATION BESSER INTEGRIERT EDI (Electronic Data Interchange) ist ein ERP nahes Softwaresystem. Muss es separat zugekauft werden, entsteht ein hoher

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) Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Energieversorgung Filstal GmbH & Co. KG Großeislinger

Mehr

7. Analyse-Phase: Datenmodellierung Software Engineering

7. Analyse-Phase: Datenmodellierung Software Engineering 7. Analyse-Phase: Datenmodellierung Software Engineering Hochschule Darmstadt Haardtring 100 D-64295 Darmstadt Prof. Dr. Bernhard Humm Hochschule Darmstadt, 20. November 2006 Einordnung in den Kontext

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

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

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

Mehr

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014 Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme 11. November 2014 Überblick Was ist die Unified Modeling Language (UML)? die Standardmodellierungssprache für Softwaresysteme

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) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen Gemeindewerke Niefern-Öschelbronn

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

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

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

VR-NetWorld-Software 4.4 (und folgende Versionen)

VR-NetWorld-Software 4.4 (und folgende Versionen) VR-NetWorld-Software 4.4 (und folgende Versionen) Mit der folgenden Anleitung erhalten Sie eine Beschreibung der wesentlichen SEPA-Funktionen in der VR-NetWorld Software. Insbesondere wird auf die Voraussetzungen

Mehr

Serviceorientierte Vorgehensmodelle

Serviceorientierte Vorgehensmodelle Serviceorientierte Vorgehensmodelle Überblick, Klassifikation und Vergleich: Ein Paper von Oliver Thomas, Katrina Leyking und Michael Scheid Der Hype um Serviceorientierte Architekturen ist der Wahrnehmung

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen und, Ludwigshafener Straße 4, 65929 Frankfurt am Main - im Folgenden die Parteien genannt - 1 Zielsetzung und Geltungsbereich 1.1 Die

Mehr

XML Pre- XML Systeme

XML Pre- XML Systeme XML Pre- XML Systeme Abdelmounaim Ramadane Seminar Grundlagen und Anwendungen von XML Universität Dortmund SS 03 Veranstalter: Lars Hildebrand, Thomas Wilke 1 Vortragsüberblick 1. Wirtschaftliche Bedeutung

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: Stadtwerken Fröndenberg

Mehr

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

Anlage 3: Rahmenvertrag über den elektronischen Datenaustausch (EDI) Anlage 3: Rahmenvertrag über den elektronischen Datenaustausch (EDI) Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen:...... und Emmericher Straße 11-29 46485

Mehr

Effektive Architekturdokumentation mit arc42

Effektive Architekturdokumentation mit arc42 01 Whitepaper: Technologie > Architekturdokumentation Cofinpro die Experten für Kredit und Wertpapier Effektive Architekturdokumentation mit arc42 Inhalt 1 Software-Architektur mit arc42 2 2 arc42 2 3

Mehr

SOA und Prozessmanagement: Herausforderung und aktuelle Arbeiten

SOA und Prozessmanagement: Herausforderung und aktuelle Arbeiten SOA Prozessmanagement: Herausforderung aktuelle Arbeiten Projekt-Kurzvorstellung beim Gründungstreffen des EMISA-Arbeitskreises Entwicklung agiler, prozessorientierter Informationssysteme Reiner Siebert,

Mehr

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Andreas Lux 16.03.2010 Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Warum unterschiedliche Sprachen? Nicht alle Probleme eignen sich, um mit Standardsprachen beschrieben

Mehr

Alireza Salemi, Timo Albert. SGML-basierte Datenaustauschformate. Referenten:

Alireza Salemi, Timo Albert. SGML-basierte Datenaustauschformate. Referenten: SGML-basierte Datenaustauschformate Referenten: Alireza Salemi Timo Albert Gliederung Einleitung XML - Kurzeinführung Web Service-Technologien XML-basierte Austauschformate Spezifische Markup-Languages

Mehr

1. Einleitung. 1.1. Ausgangssituation

1. Einleitung. 1.1. Ausgangssituation 1. Einleitung In der vorliegenden Arbeit wird untersucht, welche Faktoren den erfolgreichen Ausgang eines Supply-Chain-Projektes zwischen zwei Projektpartnern beeinflussen. Dazu werden zum einen mögliche

Mehr

EDI-Rahmenvertrag. Zwischen. im folgenden - Lieferant - genannt. und

EDI-Rahmenvertrag. Zwischen. im folgenden - Lieferant - genannt. und EDI-Rahmenvertrag Zwischen im folgenden - Lieferant - genannt und Pfalzwerke Netzgesellschaft mbh Kurfürstenstrasse 29 67061 Ludwigshafen im folgenden - Netzbetreiber - genannt Seite 2 des EDI-Rahmenvertrages

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

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: Zwickauer Energieversorgung

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 Konstanz GmbH

Mehr

Neue Produkte 2010. Ploetz + Zeller GmbH Truderinger Straße 13 81677 München Tel: +49 (89) 890 635-0 www.p-und-z.de

Neue Produkte 2010. Ploetz + Zeller GmbH Truderinger Straße 13 81677 München Tel: +49 (89) 890 635-0 www.p-und-z.de Neue Produkte 2010 Ploetz + Zeller GmbH Truderinger Straße 13 81677 München Tel: +49 (89) 890 635-0 Ploetz + Zeller GmbH. Symbio ist eine eingetragene Marke der Ploetz + Zeller GmbH. Alle anderen Marken

Mehr

Die nächste Revolution in der modelgetriebenen Entwicklung?

Die nächste Revolution in der modelgetriebenen Entwicklung? Die nächste Revolution in der modelgetriebenen Entwicklung? Me Johannes Kleiber Software Engineer bei FMC Johannes.Kleiber@fmc-ag.com Themen Überblick Window Workflow Foundation Workflows modellieren WF

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

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

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

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 ELE Verteilnetz 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

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

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

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

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Lieferant Straße Hausnummer PLZ Ort Handelsregister und Cofely Deutschland GmbH Geschäftsbereich Energy Services Gletschersteinstraße

Mehr

Modellierung von Geschäftsprozessen (MGP / GPM) Thematische Einführung

Modellierung von Geschäftsprozessen (MGP / GPM) Thematische Einführung FHTW Berlin FB4, Wirtschaftsmathematik Modellierung von Geschäftsprozessen (MGP / GPM) Thematische Einführung Dr. Irina Stobbe STeam Service Software Sustainability Organisatorisches Thema - Überblick

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Energie- und Wasserversorgung Hamm GmbH, Südring 1/3, 59065 Hamm und XXX -nachfolgend "die Parteien" genannt.- Seite 1 von 6 1 Zielsetzung

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: Lieferant: und Netzbetreiber:

Mehr

Stadtwerke Homburg GmbH Lessingstraße 3 66424 Homburg

Stadtwerke Homburg GmbH Lessingstraße 3 66424 Homburg Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Homburg GmbH

Mehr

Prozessorientierte Integration von Anwendungssystemen WS 2015 FWP-Fach für Bachelor Wirtschaftsinformatik

Prozessorientierte Integration von Anwendungssystemen WS 2015 FWP-Fach für Bachelor Wirtschaftsinformatik Prozessorientierte Integration von Anwendungssystemen WS 2015 FWP-Fach für Bachelor Wirtschaftsinformatik Prof. Dr. Torsten Zimmer, Hochschule München Motivation für Integrationsplattformen Nach einer

Mehr

XML-basierte Standards für den Datenaustausch in der Logistikkette

XML-basierte Standards für den Datenaustausch in der Logistikkette XML und Electronic Data Interchange (EDI) EDIFACT-XML ein kleines Beispiel - Strukturierung von Daten Datensatz 347,M50,L Datensatz mit Pseudocode-ML strukturiert 347

Mehr

E-Supplier. Information für Lieferanten der Siemens AG zum Austausch von Nachrichten via EDI. https://webedi.siemens.de/web4bis

E-Supplier. Information für Lieferanten der Siemens AG zum Austausch von Nachrichten via EDI. https://webedi.siemens.de/web4bis E-Supplier Information für Lieferanten der Siemens AG zum Austausch von Nachrichten via EDI https://webedi.siemens.de/web4bis Inhaltsverzeichnis EDI mit Siemens... 3 Unterstützte Nachrichtenarten und Prozesse...

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

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

Mehr

Objektorientierte Systementwicklung mit der Unified Modeling Language (UML) Vorgehensmodelle für die objektorientierte Systementwicklung

Objektorientierte Systementwicklung mit der Unified Modeling Language (UML) Vorgehensmodelle für die objektorientierte Systementwicklung Objektorientierte Systementwicklung mit der Unified Modeling Language (UML) (Dr. Markus Nüttgens, Dipl.-Hdl. Michael Hoffmann, Dipl.-Inform. Thomas Feld, Institut für Wirtschaftsinformatik (IWi), Universität

Mehr

EINKAUF PRODUKTION VERKAUF

EINKAUF PRODUKTION VERKAUF 1.2.Prozessaufbereitung Prozessabläufe und betriebliche Problemstellungen Betrieblicher Prozess: inhaltliche und logische Folge von Funktionen zur Erzeugung von Produkt oder Dienstleistung Verknüpfung

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 Vilshofen GmbH

Mehr

Design by Contract zur semantischen Beschreibung von Web Services

Design by Contract zur semantischen Beschreibung von Web Services Design by Contract zur semantischen Beschreibung von Web Services Gregor Engels 1, Marc Lohmann 1, Stefan Sauer 2 1 Institut für Informatik, 2 Software Quality Lab (s-lab) Universität Paderborn, 33095

Mehr

Einführung in die Programmierung mit Java. Hörsaalübung

Einführung in die Programmierung mit Java. Hörsaalübung Einführung in die Programmierung mit Java Hörsaalübung Folie 1 Grundlagen der Objektorientierung Seit Anfang der Neunzigerjahre Standardmethode der Softwareentwicklung. Die OOP Objektorientierte Programmierung

Mehr

Anlage 1b zum Lieferantenrahmenvertrag (Strom) Vereinbarung über den elektronischen Datenaustausch (EDI)

Anlage 1b zum Lieferantenrahmenvertrag (Strom) Vereinbarung über den elektronischen Datenaustausch (EDI) Anlage 1b zum Lieferantenrahmenvertrag (Strom) Vereinbarung über den elektronischen Datenaustausch (EDI) Artikel 1 Zielsetzung und Geltungsbereich 1) Die "EDI-Vereinbarung", nachfolgend "die Vereinbarung"

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