Lade Inhalt...

Entwurf und Realisierung eines datenbankgestützten Workflow-Management-Systems für ein Intranet

Diplomarbeit 1997 185 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

Inhaltsverzeichnis

Abkürzungsverzeichnis

Tabellen- und Abkürzungsverzeichnis

1 EINLEITUNG

2 WORKFLOW-MANAGEMENT SYSTEME
2.1 EINSATZVORAUSSETZUNGEN
2.2 MODELLIERUNG VON WORKFLOW-MANAGEMENT SYSTEMEN
2.2.1 Aktivitätenbezogene Aspekte
2.2.2 Aktorenbezogene Aspekte
2.2.3 Abhängigkeitsbezogene Aspekte
2.2.4 Kausaler Aspekt
2.3 ARCHITEKTUR EINES WORKFLOW-MANAGEMENT SYSTEMS
2.3.1 Der Workflow Enactment Service
2.3.2 Process Definition Tools
2.3.3 Workflow Client Functions
2.3.4 Eingebundene Applikationen
2.3.5 System Administration

3 DIE TCP/IP-PROTOKOLLFAMILIE
3.1 KONZEPT UND ARCHITEKTUR
3.2 DAS INTERNET PROTOCOL (IP)
3.3 DIE PROTOKOLLE DER TRANSPORTSCHICHT
3.4 HYPERTEXT TRANSFER PROTOCOL

4 ENTWURF UND REALISIERUNG DES PROTOTYPEN
4.1 PROBLEMANALYSE
4.1.1 Untersuchung des Ist-Zustandes
4.1.2 Entwicklung eines Soll-Konzepts
4.2 ANFORDERUNGSDEFINITION
4.2.1 Modellierung des Workflow-Management Systems
4.2.2 Entwicklung eines Datenflußdiagramms
4.2.3 Beschreibung der Datenspeicher
4.3 SYSTEMIMPLEMENTIERUNG
4.3.1 Hard- und Softwarekomponenten
4.3.2 Die Komponenten des Workflow-Management Systems
4.3.3 Die Implementierung in HTML und SQL
4.4 KRITISCHE BETRACHTUNG UND WEITERENTWICKLUNG

Anhang

Anhang

Anhang

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

TABELLEN- UND ABBILDUNGSVERZEICHNIS

Abbildung 1: Schwachstellen der Büroarbeit

Abbildung 2: Merkmale eines WfMS

Abbildung 3: Struktur des Grundmodells

Abbildung 4: Das Referenzmodell - Komponenten und Schnittstellen

Abbildung 5: Der Austausch von Workflow-Definitionen

Abbildung 6: Die Schnittstelle der Client Application

Abbildung 7: Invoked Application Interface

Abbildung 8: Systemadministrations- und Monitoringschnittstelle

Abbildung 9: Die drei Schichten des Internetkonzepts

Abbildung 10: Die Ansicht des Benutzers auf das Internet

Abbildung 11: Die Unterteilung der IP-Adressen in Klassen

Abbildung 12: Das Format eines IP-Datagrammes

Abbildung 13: Das Schichtprinzip des TCP/IP

Abbildung 14: Aufbau einer TCP-Verbindung

Abbildung 15: Das Format eines TCP-Segmentes

Abbildung 16: Die Tätigkeiten des Innendienstes im Vertrieb

Abbildung 17: Bearbeitung der Bestellungen

Abbildung 18: Der geforderte Ablauf des Prozesses "Bearbeitung der Bestellungen"

Abbildung 19: Grob-DFD des EDV-Systems

Abbildung 20: DFD "Verwaltung der Stammdaten"

Abbildung 21: DFD des "X-Stamm verwalten"

Abbildung 22: DFD des Prozesses "Bearbeitung der Bestellungen"

Abbildung 23: DFD des Prozesses "Lieferauskunft, Monitoring"

Abbildung 24: Der physikalische Aufbau des EDV-Systems

Abbildung 25: Hierarchische Darstellung der HTML-Dokumente

Abbildung 26: Überblick über den Systementwurf des WfMS

Abbildung 27: Der Prozeß "Prüfung und Erfassung"

Abbildung 28: Der Prozeß "Lagerbestand prüfen"

Abbildung 29: Der Prozeß "Kreditlimit prüfen"

Abbildung 30: Der Prozeß "Rechnung / Lieferschein drucken"

Tabelle 1: Typisierung von Büroaufgaben

Tabelle 2: Beziehungen zwischen Stellen- und Aufgabentypen

Tabelle 3: Die Felder der HTTP-Header

Tabelle 4: Zugriffsrechte auf die Stammdaten

Tabelle 5: Die Auswahl an Kontrollmöglichkeiten

1 Einleitung

In dieser Arbeit werden zwei aktuelle Technologien miteinander verknüpft, um ein betriebswirtschaftliches Problem zu lösen. Die Schwachstellen der Büroarbeit bilden das Problem. Die Tech- niken, deren Einsatzmöglichkeiten vorgestellt werden sollen, sind Workflow-Management Systeme (WfMS) und die Internet- Technologie.

Das Besondere eines WfMS ist, daß dieses EDV-System geeignet sein kann, ausgewählte Abläufe eines Betriebes zu beschleunigen und die Qualität deren Ausführung deutlich zu erhöhen. Intranet und Internet-Technologie sind Begriffe, die z.Zt. nicht nur im Brennpunkt der Informatik stehen. Das Internet mit all seinen Entwicklungsmöglichkeiten beeinflußt viele Bereiche des Privat- und Berufslebens.

Das primäre Ziel, das in dieser Arbeit angestrebt wird, ist der Auf- bau eines WfMS in einem Beispielunternehmen. Dieses WfMS greift auf die Datenbank des Unternehmens zurück. Das Besonde- re ist, daß nicht nur die Prozesse des WfMS über ein Intranet ab- laufen, sondern bereits die Erstellung und Pflege der notwendigen Unternehmensdaten.

Das weiterreichende Ziel ist es, am Beispiel dieses Modells die Möglichkeiten aufzuzeigen, wie die Arbeitsabläufe in landes- oder gar weltweit tätigen Unternehmen verändert werden können. Die Nutzung eines Intranets kann für ein lokal tätiges Unternehmen von Vorteil sein, die stetig wachsenden Kommunikationsmöglich- keiten des globalen Internets sind für Unternehmen, die internatio- nal präsent sind, jedoch von strategischer Bedeutung.

Um die Einsatzmöglichkeiten eines WfMS überblicken zu können, muß zunächst erläutert werden, was ein WfMS ist, welche Vo- raussetzungen für einen erfolgreichen Einsatz notwendig sind und aus welchen Teilkomponenten es besteht. Das ist das Thema des folgenden Abschnittes.

Der dritte Abschnitt erläutert den technischen Hintergrund des Intranets bzw. Internets, wobei deutlich wird, warum diese Technologie derzeit so erfolgreich ist und weltweit in verstärktem Maße eingesetzt wird.

Der letzte und umfangreichste Abschnitt enthält den Entwurf des kompletten EDV-Systems, wobei der Entwurf des WfMS stärker gewichtet wird. Die Erfahrungen bzw. Programmbausteine, die aus der Realisierung der Stammdatenverwaltung stammen, sind eine gute Grundlage für die Realisierung und für das Verständnis des WfMS.

Als Anhang sind dieser Arbeit drei Teile zugefügt:

1) Die vier Datenspeicher sind in Anhang 1 grafisch beschrieben. Die Darstellungen sollen die verbale Erläuterung aus Abschnitt 4.2.3 ergänzen.
2) eine Beschreibung des in der Arbeit verwendeten „Internet Database Connectors“ von Microsoft und
3) die Quellcodes des Prototypen mit jeweils einer Grafik. Diese Grafiken zeigen, wie die HTML-Dokumente beim Aufruf durch einen Web-Browser aussehen können.

Als praktischer Bestandteil dieser Diplomarbeit gilt der Prototyp, der auf den Ideen des zweiten, der Technik des dritten und den Entwürfen des vierten Abschnitts beruht. Er soll veranschaulichen, wie eine Intranet-Lösung konzipiert und realisiert wird.

Um die Einführung einer neuen Technologie rechtfertigen zu kön- nen, müssen Probleme identifiziert werden, die nur von der neuen Technik behoben werden können. Bei der Implementierung eines WfMS wird das Ziel verfolgt, die Schwachstellen der Büroarbeit zu beheben.

In allen Bereichen eines Betriebes ist es ein dauerhaftes Ziel, die Effizienz zu steigern. Effizienzsteigerungen können auf unter- schiedliche Weise erreicht werden: Verbesserung der Produktqua-lität1, Verminderung der Durchlaufzeiten oder höhere Auslastung der Produktionsfaktoren.

Diese Anstrengungen werden in den Produktionsbereichen der Unternehmen seit Beginn der industriellen Fertigung vorangetrieben. Im Verwaltungsbereich, der überwiegend aus Büroarbeitsplätzen besteht, sind die Möglichkeiten zur Effizienzsteigerung jedoch bei weitem noch nicht ausgeschöpft, denn die Arbeitsprozesse in der Verwaltung können komplexer sein als die der Massenfertigung, siehe Abschnitt 2.1.

Die Abbildung 1 zeigt die Schwachstellen der Büroarbeit ohne jeg- liche Prozeßsteuerung - wie diese auch immer realisiert sein soll- te.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Schwachstellen der Büroarbeit

Quelle: Reichwald, R. (1990), S. 76.

1. Dem einzelnen Mitarbeiter, nicht nur auf unterster Ebene, ist oft nicht bewußt, welchen Beitrag seine eigene Tätigkeit oder die seiner organisatorischen Einheit zum Unternehmenserfolg beiträgt. Gründe können sowohl das persönliche Desinteresse als auch eine schlechte Integration2 sein. Gerade dieses Man- ko ist eine Ursache für Demotivation bis hin zur sogenannten „inneren Kündigung.

2. Wiederkehrende geistige Rüstzeiten enstehen durch wieder- holtes Wechseln eines Mitarbeiters zwischen verschiedenen Tätigkeiten, die sowohl unterschiedliche Fähigkeiten als auch Kenntnisse3 erfordern. Die Ursache ist in der Aufbau- oder auch in der Ablauforganisation4 des Unternehmens zu suchen. Diese „Fehlallokation“ eines Mitarbeiters kann diverse Folgen auslösen: Wie im Produktionsbereich kann sich die Durchlauf- zeit erhöhen, die Qualität des Arbeitsergebnisses kann sich vermindern, trotz der hohen Auslastung des Mitarbeiters ist sein Output relativ gering.

3. Falls ein Mitarbeiter bei der Verrichtung seines Beitrages zur Gesamttätigkeit Informationen von vor- bzw. nachgelagerten Stellen oder auch eine Genehmigung einer höheren Instanz benötigt, muß er diese Partner entweder persönlich aufsuchen oder telefonisch erreichen. Aus einer Reihe von Gründen ist es möglich, daß der Gesprächspartner nicht erreichbar ist. Die fehlende Information führt nun dazu, daß der Mitarbeiter seine Funktion nicht vollständig ausführen kann. Je nach Dauer der Abwesenheit der Gegenstelle kann diese Nichterreichbarkeit zu äußerst langen Durchlaufzeiten führen.

4. Doppelarbeit kann bei schlechter Organisation der Differenzie-rung und Integration der Aufgaben sehr häufig auftreten. Der Informationsfluß eines Unternehmens kann so mangelhaft or-ganisiert sein, daß jeder Mitarbeiter bei der Verrichtung seiner Tätigkeit selbst die relevanten Daten erfassen muß, um diese zu verarbeiten. Diese Doppelarbeit kann daher resultieren, daß Informationen zwar jedermann frei zugänglich sind, es müssen jedoch zusätzliche Anstrengungen gemacht werden, um diese Daten im richtigen Augenblick zur Verfügung zu haben5. Hier ist offensichtlich, daß sich zum einen die Durchlaufzeiten erhö- hen und zum zweiten die Ressourcen höher als notwendig be- lastet werden.

5. Medienbrüche treten m. E. in Büros häufig auf. Die Ursachen sind vielfältig. Informationen gelangen in unterschiedlicher Form in das Unternehmen (Brief, Fax oder elektronischer Form) und es existiert keine einheitliche Bearbeitungsmethode, was dazu führt, daß Informationen nach Trägermedien ge- trennt aufbewahrt und transportiert werden. Außerdem kann nicht an jedem Arbeitsplatz jede Form von Medien verarbeitet werden, so daß Informationen den Träger erneut wechseln. Dieses Manko wirkt sich besonders auf die Durchlaufzeiten im Büro aus und kann ebenfalls die Qualität der Arbeit vermin- dern.

6. Das Problem der uneinheitlichen Informationsbasis hängt u.a. mit dem Wechsel der Medien zusammen, da ursprünglich glei- che Informationen auf unterschiedlichen Medien unterschied- lich verändert werden können. Eine andere Ursache kann eine unkontrollierte Datenhaltung sein6. In erster Linie wirkt sich ei- ne inkonsistente Datenhaltung auf die Qualität des Outputs aus.

7. Zeitaufwendige Übertragungswege sind auch im sogenannten Informationszeitalter mit schnellen Kommunikationswegen kei- ne Seltenheit. Wie bereits erläutert, steht nicht jede Information in elektronischer Form zur Verfügung, so daß diese mit der Hauspost oder mit der Deutschen Bundespost befördert wer- den muß. Zu den im Vergleich zur elektronischen Datenüber- tragung hohen Transportdauer muß hinzu addiert werden, daß Informationen in Papierform einige Zeit in „Posteingangskörb- chen“ verweilen.

Sollte es mit Hilfe eines EDV-Systems möglich sein, alle oder auch nur einzelne Schwachstellen zu beheben oder abzumildern, wäre der Einsatz dieses Systems in Erwägung zu ziehen.

2 Workflow-Management Systeme

In diesem Abschnitt soll gezeigt werden, unter welchen Voraus- setzungen ein WfMS geeignet ist, Büroarbeit effizienter werden zu lassen. Anschließend wird erläutert, welche Aspekte bei der Mo- dellierung, d.h. bei der Planung, zu beachten sind. Um die Syste- marchitektur eines WfMS vorzustellen, wird im Abschnitt 2.3 das Referenzmodell der Workflow Management Coaltion (WfMC) er- läutert.

Der Begriff „Workflow-Management System“ hat sich auch im deutschen Sprachgebrauch durchgesetzt. Parallel dazu wird auch der Ausdruck „Vorgangsbearbeitungssystem“ benutzt.

Die WfMC definiert ein WfMS als „a system that completly defines, manages and executes workflows through the execution of soft- ware whose order of execution is driven by a computer represen- tation of the workflow logic“7.

Besonders wichtig für das Verstehen dieser Definition ist der Be- griff „workflow“, den die WfMC als „the computerised facilitation or automation of a process, in whole or in part“8 definiert. Im weiteren Text wird unterschieden zwischen (Arbeits-)Vorgängen, die in der realen Arbeitswelt existieren und Workflows, die das maschinen- lesbare und systemgesteuerte Abbild eines realen Vorganges dar- stellen.

2.1 Einsatzvoraussetzungen

Wenn WfMS in der Lage sind, die aufgeführten Schwachstellen der Büroarbeit zu beseitigen oder abzumildern, warum werden sie nicht grundsätzlich in den Büros eingesetzt? Abgesehen von der Neuartigkeit der WfMS gibt es Einsatzbedingungen, die beachtet werden müssen.

Zunächst wird die Büroarbeit begrifflich eingegrenzt. Eine ab- schließende Aufzählung ist unmöglich, wenn man sich vor Augen führt, daß der Ort der Bürotätigkeiten „die Unternehmensverwal- tung, Unternehmen der Dienstleistungsbranche, der öffentlichen Administration und überwiegend die Betriebe des Handels“9 sind. Damit wird der Unterschied zum Produktionsbereich deutlich, der - wenn vorhanden10 - den Kern der betrieblichen Leistungserstel- lung bildet.

Nicht nur der Standort der Büroarbeit ist uneinheitlich, auch die Funktionen, die dort ausgeführt werden, sind es11:

1. Die meisten Büros bearbeiten mehrere Vorgänge parallel. Hogg, Nierstrasz und Tsichritzis erwähnen Studien, die „thousands of different procedures“ gezählt haben.
2. Die Vorgänge haben viele Ausnahmen, Hogg, Nierstrasz und Tsichritzis stellen fest, daß „the whole office function seems li- ke an exception-handling activity“.
3. Während der Bürotätigkeit werden viele Einzelentscheidungen getroffen. Sie benötigen Wissen und Erfahrung, deren Handzesses oder eines Teilprozesses.“ Der Begriff „Prozeß“ entspricht dem in dieser Arbeit benutzten Begriff „Arbeitsvorgang“. habung über die Kapazität eines Computersystems hinaus- geht.
4. Arbeitsabläufe innerhalb eines Büros werden von dem dort eingesetzten Personal am besten verstanden. Bei einer Analy- se der Tätigkeiten erscheint die Benennung der Prozesse mög- lich, es besteht jedoch die Gefahr, daß deren Wert des Unter- nehmensziels von außen nicht erkannt wird.

Einen geeigneten Typisierungsansatz stellen Picot und Reichwald vor12, siehe Tabelle 1:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Typisierung von Büroaufgaben

Quelle: Picot, A. und Reichwald, R. (1987).

Picot und Reichwald unterscheiden drei Aufgabentypen, die durch vier Merkmalsausprägungen, Komplexität / Planbarkeit, Informati- onsbedarf, Kooperationspartner und Lösungsweg, charakterisiert werden.

- Aufgabentyp 1: Dieser Typ ist dadurch charakterisiert, daß die Problemstellung sehr komplex und schlecht planbar ist. Der In- formationsbedarf ist - zumindest zu Beginn - nicht zu bestim- men. Die Kooperationspartner sind teilweise noch unbekannt und wechseln im Verlauf der Aufgabenerfüllung Der Lösungs- weg ist aufgrund der Neuartigkeit der Aufgabe nicht bekannt. Ein Beispiel für diesen Aufgabentypen ist der Entwurf und die Implementierung eines EDV-Systems. Picot und Reichwald bezeichnen ihn als einzelfall-orientiert und nicht formalisierbar.
- Aufgabentyp 2: Typ 2 nimmt eine Zwischenstellung ein; Die Probleme sind weniger komplex und besser planbar im Ver- gleich zu Typ 1. Der Informationsbedarf ist teilweise bekannt, es sind jedoch auch Probleme denkbar, deren Informationsbe- darf unbestimmt ist. Die Kooperationspartner wechseln mit den Problemen. Die Kenntnis des Lösungsweges ist problemab- hängig. Die Beschaffung von einzelnen, weniger komplizierten Investitionsgütern ist ein Beispiel für Aufgabentyp 2. Die Auto- ren nennen diesen Typen „sachbezogener Fall“.
- Aufgabentyp 3: Typ 3 wird als Routinefall bezeichnet. Folglich ist die Problembearbeitung aufgrund der niedrigen Komplexität, des bekannten Informationsbedarfes und der gleichbleibenden Kooperationspartner leicht zu planen. Der Lösungsweg ist ebenfalls festgelegt. Ein Beispiel ist die Bearbeitung von Kun- denbestellungen in einem (Groß-) Handelsunternehmen, wie sie dem Beispiel in Abschnitt 4 zugrunde liegt. Zu beachten ist, daß eine Aufgabe mit niedriger Komplexität ein organisatorisch differenzierter Teil einer komplexen Gesamtaufgabe sein kann.

Ordnet man diesen Aufgaben typische Aufgabenträger zu13, entsteht folgendes Bild:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Beziehungen zwischen Stellen- und Aufgabentypen

Quelle: Reichwald, R. (1990), S. 71.

Dem Aufgabentyp 1 wird der Stellentyp „Führungskraft“ zugeord- net, hier wie bei den anderen Typen fallen - wenn auch weniger prägnant - andere Aufgabentypen an. Die Fachkräfte sind mit der Bewältigung von Aufgaben des Typs 2 beschäftigt und Sachbear- beiter befassen sich überwiegend mit Routineaufgaben. Den Un- terstützungskräften ist kein eigener Aufgabentyp zugeordnet.

Will man den verschiedenen Aufgabenträgern bei der Erfüllung ihrer Aufgaben ein EDV-System zur Seite stellen, so kann unmög- lich ein System alle Aufgabentypen unterstützen. Software, die bei der Lösung einzelfall-orientierter Aufgaben assistieren soll, muß flexibel sein, muß viel Freiraum für Anpassungen lassen und sollte schnell erlernbar sein, denn für Produktschulungen bleibt den Auf- gabenträgern (Führungskräfte) meist wenig Zeit. Für diese Aufga- bentypen werden sogenannte Groupware-Produkte entwickelt.

Ganz andere Ansprüche stellen die Routineaufgaben. Aufgrund der in Tabelle 1 aufgeführten Merkmale ist es möglich, die Aufga- ben aufzuteilen (Differenzierung) und auf die einzelnen Stellen nach Zeit- und Wissensressourcen zu verteilen. Jeder Stellenin- haber bearbeitet die ihm zugewiesene Teilaufgabe, die aus ein- zelnen, gleichartigen Vorgängen besteht. „Ein Vorgang besteht aus einer Folge von Tätigkeiten und dem Laufweg des Vorgangs über mehrere Arbeitsplätze. Aufgrund einrichtbarer Entscheidun- gen können auch Verzweigungen (alternative und nebenläufige Bearbeitungswege) realisiert werden. Eine Tätigkeit umfaßt die Arbeitsschritte, die zusammengehören und kontinuierlich ... ablau- fen“14. Aufgaben, die diesem Routinefall entsprechen, werden als stark strukturierte Aufgaben bezeichnet. Der Grad der Strukturiert- heit von Aufgaben wird vom Ausmaß der Entscheidungskompe-tenzen bestimmt; Besteht keine Möglichkeit den Ablauf eigenstän-dig zu modifizieren, ist der Vorgang stark strukturiert15.

Für die computergestützte Bearbeitung stark strukturierter Aufga- ben eignen sich WfMS. Da jedoch in der Praxis auch Routineauf- gaben häufig ihrer veränderten Umgebung angepaßt werden müssen, wird von WfMS gefordert, daß sie über eine gewisse Fle- xibilität verfügen.

2.2 Modellierung von Workflow-Management Systemen

Die Modellierung eines WfMS ist eine umfangreiche und komplexe Tätigkeit, die dadurch erschwert wird, daß ein WfMS auch nach Abschluß der Implementierung noch erweiterbar und modifizierbar sein muß. Da in einem WfMS ein Teil der Arbeitsabläufe einer o- der mehrerer Abteilungen abgebildet werden soll, ist es notwen- dig, nach Möglichkeit alle Abläufe zu analysieren. Daher wird häu- fig die Forderung erhoben16, die Abläufe des Unternehmens zu analysieren und gemäß den Ideen des Business Process Reengi- neering (BPR)17 zu gestalten, bevor ein WfMS eingesetzt wird. Diese Forderung ist m.E. sinnvoll, denn der Erfolg eines WfMS ist nur bei einer zweckmäßigen18 Gestaltung der Aufbau- und Ablau- forganisation gewährleistet. Es muß auch beachtet werden, daß die Implementierung eines WfMS den Status Quo der Organisati- on „zementieren“ kann.

In diesem Abschnitt wird eine Methode zur Modellierung von WfMS vorgestellt. Sie ist Teil eines vielzitierten Aufsatzes von Jablonski19.

Theoretische Grundlage bildet die Koordinierungstheorie. Arbeit, die von verschiedenen Personen und Applikationen ausgeführt wird, muß kordiniert werden. Soll diese „Arbeit“ (im Sinne von Vorgang) in einem WfMS abgebildet werden, so sind folgende Konstituenten der Koordination zu beachten:

- „ Ziele als Grund und Ursache allen Handelns
- Aktoren als Subjekte, die Handlungen ausführen
- Aktivitäten als die ausgeführten bzw. auszuführenden Hand- lungen
- Abhängigkeiten, die im Rahmen einer Zusammenarbeit korre- lierter Aktivitäten zu berücksichtigen sind (z.B. Abarbeitungs- reihenfolge, Inanspruchnahme gleicher Aktoren für verschie- dene Tätigkeiten)“20.

Die Modellierung wird begonnen, indem die Ziele der zu analysie- renden Vorgänge definiert werden. Eine „Dekomposition der Ziele“ zerlegt das grundlegende Ziel in Teilziele, die sich durch bestimm- te Aktivitäten realisieren lassen. Diese Aktivitäten sind folglich zielorientiert zu entwerfen. Den Aktivitäten werden konkrete Akto- ren (Mitarbeiter, Maschinen, Applikationen) zugeordnet. Dabei sind die Abhängigkeiten zu beachten, die zwischen den zur Verfü- gung stehenden Ressourcen (= einzelne Aktoren aller Art) beste- hen.

Jablonski leitet folgende essentielle Erkenntnis ab: „Workflows (als das ausführbare Abbild von Geschäftsvorgängen) werden nicht ausschließlich durch Aktivitäten modelliert, sondern Aspekte wie Ziele, Aktoren und Abhängigkeiten müssen auch erfaßt werden.“21

2.2.1 Aktivitätenbezogene Aspekte

Dieser erste Aspekt beschreibt die Inhalte der Workflows. Ein Topworkflow ist ein komplexer Workflow, der aus endlich vielen Subworkflows besteht. Ein Workflow kann sowohl aus Prozessen, Prozeßelementen als auch Prozeßschritten bestehen. Die elemen- taren Subworkflows referenzieren stets eine Applikation22.

Jablonski faßt die Definition für Applikationen bewußt weitläufig: Applikationen können sowohl die eingesetzten Programme als auch Handlungen, die nicht von EDV-Systemen unterstützt wer- den (Telefongespräch, Aktennotiz), sein. Handelt es sich bei der referenzierten Applikation um Software, muß diese über eine spe- zielle Schnittstelle23 (Hülle, Wrapper) angesprochen werden.

Zur Verdeutlichung wird in diesem und im Abschnitt 2.3 das von Jablonski gewählte Beispiel der Reisekostenabrechnung darge- stellt. In diesem Topworkflow gibt es die Subworkflows „Beantra- gen“, „Genehmigen“, „Bearbeiten“ (durch die Reise- oder Finanz- abteilung), „Auszahlen“ und „Ablegen“. Als Applikationen werden genannt ein Reisekostenabrechnungssystem, ein Buchungssys- tem und ein Archivsystem.

2.2.2 Aktorenbezogene Aspekte

Nachdem die Workflows definiert worden sind, muß festgelegt werden, wer welchen Workflow ausführt. Jablonski nennt zwei Teilaspekte: Die Zuordnung von Aktoren zu Workflows auf der einen Seite und die Benachrichtigung der Aktoren und deren Syn- chronisation.

Wie im vorangegangenen Abschnitt dargelegt, können Aktoren menschliche und maschinelle Aktivitätsträger sein.

Die Objekttypen der menschlichen Aktoren sind „Angestellter“, „Gruppe“ und „Abteilung“. Diese Basisentitäten korrelieren mitei- nander durch die Relationstypen „ist Vorgesetzter von“, „berichtet an“, „ist Untereinheit von“ und „gehört zu Bereich“. Auf diese Wei- se kann die Aufbauorganisation des Unternehmens abgebildet werden. Ein spezieller Begriff für das WfM-Gebiet ist die Res- source; Jablonski beschreibt sie als elementare Komponente einer Organisation, die einen Workflow selbstständig ausführen kann.

Um die Zuordnung Aktor <-> Workflow nicht zu statisch zu model- lieren, muß ein Rollenkonzept eingeführt werden. Jablonski: „Eine Rolle wird durch eine Menge von Fähigkeiten / Kompetenzen be- schrieben, die alle Ressourcen aufweisen, die eine solche Rolle spielen können.“24 Auf diese Weise wird von konkreten Aktoren abstrahiert, so daß bei einer Änderung der Kompetenz oder der Fähigkeiten eines Mitarbeiters nicht die gesamte Zuordnung Aktor <-> Workflow angepaßt werden muß. Statt dessen muß lediglich die Zuordnung Aktor <-> Rolle verändert werden.

Dieses Rollenkonzept reicht Jablonski nicht für eine praxisnahe Modellierung aus. Es ist nicht wünschenswert, daß jeder Aktor, der eine spezielle Rolle spielt, jede damit verbundene Applikation ausführen darf. Um auch innerhalb einer Organisation Unterschei- dungsmöglichkeiten beizubehalten, werden organisationsbezoge- ne Rollen eingeführt. Jeder Rolle werden organisationsspezifische Prädikate beigefügt, die sich auf die konkrete Unternehmensorga- nisation beziehen, siehe nachfolgendes Beispiel.

Zusätzlich fordert Jablonski die Modellierung von organisatorischen Zuordnungsstrategien.

Zurück zum Beispiel: Bert und Frank sind zwei Objekte. Das Ob- jekt Bert ist vom Objekttyp „Angestellter“ und Frank „Manager“. Das bedeutet, es bestehen die Relationstypen „ist Vorgesetzter von“ und beide „gehören zum Bereich“ Vertrieb. Wenn Bert nun eine Reise genehmigen lassen möchte, so wendet er sich an Frank, seinen Vorgesetzten. Ändert sich jedoch die Hierarchie, so muß gewährleistet sein, daß immer noch Bert’s Vorgesetzter die Reise genehmigt und nicht Frank, der eine ganz andere Rolle ein- genommen haben kann. Dieses Rollenkonzept muß um organisa- tionsbezogene Prädikate ergänzt werden. So wird sichergestellt, daß der Reiseantrag vom WfMS nicht einem beliebigen Manager zur Genehmigung vorgelegt wird, sondern dem Manager der Vertriebsabteilung. Die von Jablonski geforderte organisatorische Zuordnungsstrategie soll darüber hinaus Grenzfälle beachten: Falls Frank einen eigenen Reiseantrag genehmigen lassen möchte, so darf nicht der Vorgesetzte der Vertriebsabteilung (= Frank) dies tun, sondern nur der Vorgesetzte des Vertriebsleiters.

Im laufenden System übernimmt die Komponente „Rollenauflö- sung“ (Role Model Data) die Zuordnung von Workflows zu Rollen und Aktoren.

Der zweite Teilaspekt ist die Benachrichtigung der Aktoren über aktuelle Workflows und die Synchronisation der Aktoren.

1) Wie wird ein Aktor über anstehende Arbeit unterrichtet? Dies bezeichnet Jablonski als Notifikation. Sie kann durch eine proprietären Dienst des WfMS-Produktes oder durch bereits vorhandene Dienste wie E-Mail realisiert werden.
2) Wie synchronisieren sich Aktoren untereinander? Diese Syn- chronisation muß gewährleisten, daß konkrete Workflows nur von einem aus einer Menge von mehreren möglichen Aktoren bearbeitet werden. In dem Beispiel kann es möglich sein, daß verschiedene Sachbearbeiter der Reisestelle den Antrag bear- beiten können. Hat jedoch einer mit der Bearbeitung begon- nen, so muß verhindert werden, daß ein zweiter ebenfalls die- sen Antrag bearbeitet. In anderen Fällen ist es denkbar, daß mehrere Subworkflows parallel25 bearbeitet werden können, auch dies muß durch das WfMS steuerbar sein.
3) Wie verwaltet ein Aktor auszuführende Arbeit? Dieses Teil- problem wird durch die Verwaltung von Arbeitslisten (Worklists) gelöst. Diese Worklists können ebenfalls Teil des WfMS- Produktes sein oder durch andere Produkte ersetzt werden.

2.2.3 Abhängigkeitsbezogene Aspekte

Diesen Aspekt teilt Jablonski in die drei Bereiche Ablaufkontrolle, Datenfluß und Historie.

1) Die Ablaufkontrolle steuert das Ablaufverhalten der Workflows. Es werden präskriptive und deskriptive Varianten unterschieden. Die erste gibt die Reihenfolge der Ausführung vor, die andere schlägt einige gleichartige Reihenfolgen vor. Es gibt drei Grundkonstrukte der präskriptiven Ablaufkontrolle: a) Die serielle mit vorgeschriebener Reihenfolge, b) die alter- native mit wenn-dann-Verzweigung und c) die parallele Aus- führung, wenn dies aus logischen Gründen notwendig ist. Die deskriptive Kontrolle wird aus den beiden grundsätzlichen Bedingungen der Zeit- und Existenzbedingungen gebildet.

2) Bei der Modellierung eines WfMS ist zwischen Kontrolldaten und den restlichen Nutzdaten zu unterscheiden26. Nutzdaten beziehen sich auf den Inhalt27 eines Prozesses. Sie sind unab- hängig von der Existenz eines WfMS. Die Kontrolldaten wer- den beim Einsatz eines WfMS dazu benötigt, Informationen über den Ablauf und die weiteren Zuordnungen zu erhalten, siehe Abschnitt 4.3 Systemimplementierung. Sinn eines WfMS ist es, Kontrolldaten anzulegen und auszuwerten, die Verwal- tung und Bearbeitung der gesamten Nutzdaten geschieht hauptsächlich durch Datenbanksysteme und auf diesen operie- renden Applikationen.

3) Um Zuverlässigkeit zu gewährleisten, muß ein WfMS alle Pro- zesse protokollieren. Auf diese Weise können Fehler aufge- spürt und Statistiken erstellt werden.

2.2.4 Kausaler Aspekt

Ein weitgehend unbeachteter Aspekt ist das Einbeziehen der Kau- salität der Workflows. Es muß gewährleistet sein, daß alle Sub- workflows eines konkreten Topworkflows terminiert und zurückge- setzt werden, sobald dieser seinen Sinn verliert. Beispiel: Der Mit- arbeiter, der einen Reiseantrag stellt, zieht diesen zurück. In die- sem Moment muß sichergestellt werden, daß alle Folgeprozesse (Genehmigung, Bearbeiten und Auszahlen) terminiert werden.

2.3 Architektur eines Workflow-Management Systems

In diesem Abschnitt wird das Referenzmodell der WfMC28 vorge- stellt. Aufgrund der Zielstellung der WfMC29 ist diese Architektur an existierenden WfMS ausgerichtet30. Ziel der WfMC ist, neben der Durchsetzung der WfMS-Technologie am IT-Markt, die Ausar- beitung von Standards und allgemeingültigen Schnittstellen zwi- schen verschiedenen WfMS und die Einbindung weiterer Applika- tionen. Das Referenzmodell soll ein typisches WfMS darstellen, wobei die einzelnen Funktionen abstrakt genug dargestellt wer- den, um verschiedenartige Realisierungen zu umfassen. In dem Dokument „The Workflow Reference Model“ wird stets betont, daß WfMS-Produkte dem Referenzmodell nicht entsprechen müssen, um dennoch als solche bezeichnet zu werden. Es wird jedoch ge- fordert, an den aufgeführten Schnittstellen internationale Stan- dards einzuhalten.

Abbildung 2 zeigt die typischen Merkmale eines WfMS:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Merkmale eines WfMS

Quelle: Workflow Management Coalition (1994).

Auf diesem Abstraktionsniveau hat ein WfMS folgende Merkmale:

- Während der Entwurfsphase werden Funktionen benutzt, die Vorgänge definieren und Workflows modellieren.
- Kontrollfunktionen werden während der Laufzeit ausgeführt. Sie steuern die einzelnen Workflows und starten die notwendi- gen Aktivitäten.
- Es erfolgen Interaktionen zwischen dem Kern des WfMS, dem Workflow Enactment Service (WES), auf der einen Seite und menschlichen Benutzern und Applikationen auf der anderen Seite.

Die Komponenten des Grundmodells (Generic WfMS) zeigt Abbil- dung 3. Es werden drei Arten von Komponenten unterschieden:

- Software-Komponenten (dunkle Flächen) stellen verschiedene Funktionen innerhalb des WfMS zur Verfügung.
- Verschiedene Arten von Kontrolldaten und Daten der Prozeß- definitionen (weiße Flächen), die von den Software- Komponenten genutzt werden.
- Applikationen und deren Datenbänke (hellgraue Flächen). Die- se gehören nicht zum WfMS-Produkt, sondern werden durch dieses aufgerufen und gelten als Teil des WfMS.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Struktur des Grundmodells

Quelle: Workflow Management Coaltion (1994).

Bevor detailliert auf die einzelnen Komponenten eingegangen wird, soll zunächst das Zusammenspiel der einzelnen Komponenten anhand der Grafik erläutert werden.

Mit Hilfe des Process Definition Tools wird eine Beschreibung der Arbeitsvorgänge in maschinenlesbarer Form erstellt. Die Process Definition enthält die Abbildung der realen Vorgänge und bildet sie als Workflows ab, die der WES während der Ausführung interpre- tieren kann.

Falls ein Rollenkonzept (vgl. Abschnitt 2.2.2) vorgesehen ist, so verweist die Process Definition auf die dort hinterlegte Struktur. Der WES als der Kern des WfMS enthält hauptsächlich die soge- nannte WFM Engine (WFE). Es ist zu beachten, daß die WfMC die Möglichkeit vorsieht, mehrere Engines von einem oder sogar unterschiedlichen Herstellern einzubeziehen. Die WFE interpretiert den Inhalt der Process Definition. Die Information, welcher Mitarbeiter über einen auszuführenden Workflow informiert wird, kann aus der Process Definition oder aus „Organisation / Role Model Data“ stammen. Wird die Interaktion eines Mitarbeiters benötigt, plaziert die WFE die Informationen des entsprechenden Workflows in der Worklist des Mitarbeiters31.

Während der Ausführung erstellt die WFE Kontrolldaten (Workflow Control Data), die das System zur Steuerung benötigt und auf die der Supervisor zugreifen kann.

Die WFE benutzt prozeßspezifische Daten (Workflow Relevant Data), um zu erkennen, in welchem Status sich ein spezieller (Sub-) Workflow befindet und welche Aktivitäten folgen müssen.

Applikationen werden nach der Art ihres Aufrufes unterschieden:

- Direct Invocation: Die Applikationen werden von der WFE ge- startet, erhalten die „Workflow Relevant Data“, greifen auf eigene Datenquellen (Workflow Application Data) zurück und werden von der WFE terminiert.
- Indirect Invocation: Dem User wird mitgeteilt, daß er einen Subworkflow interaktiv bearbeiten muß. Es besteht die Mög- lichkeit, daß die notwendige Applikation bereits vom Worklist Handler gestartet wird oder daß der User bei Bedarf dies ei- genmächtig tut.

Die nachfolgende Abbildung 3 zeigt die Komponenten des Referenzmodells. Der Grund für diese Darstellung liegt in der Zielstellung der WfMC: Es sollen Schnittstellen identifiziert und eine internationale Standardisierung erreicht werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Das Referenzmodell - Komponenten und Schnittstellen

Quelle: Workflow Management Coaltion (1994)

Die Komponenten werden in den folgenden Abschnitten erläutert.

2.3.1 Der Workflow Enactment Service

Der WES kann aus einer oder mehreren WFEs bestehen. Zweck des WES ist es, Workflows oder Teile der Workflows (Subworkflows) zu erzeugen, zu steuern und auszuführen. Applikationen aller Art kommunizieren mit dem WES über die WAPI32.

Applikationen als Teil der Vorgangsbearbeitung werden über zwei Schnittstellen (Interface 2 und 3) angesprochen:

1) Das Client Application Interface liegt zwischen WES und dem Worklist Handler. Die Applikationen werden hier entweder durch den Worklist Handler oder durch den Benutzer selbst gestartet (Indirect Invocation).
2) Wird ein Subworkflow ausgeführt, der keine menschliche Inter- aktion benötigt, so wird das Invoked Application Interface ge- wählt (Direct Invocation).

Den Kern des WES bildet eine oder mehrere WFEs. Per Definition ist sie eine Software, die die Ausführung eines Workflows steuert.

Typische Funktionen sind

- Die Interpretation der Process Defintion,
- die Kontrolle der Prozesse: Starten, Ausführen, Warteschleife und Terminierung.
- Steuern zwischen einzelnen Aktivitäten innerhalb eines Pro- zesses, z.B. sequentielle oder parallele Bearbeitung, Überwa- chung von Terminen.
- An- und Abmelden einzelner Benutzer.
- Identifizierung von notwendigen Benutzereingriffen und dessen Benachrichtigung über die Schnittstelle. D.h., es wird ein neuer Vorgang in die jeweilige Worklist gestellt.
- Erstellung der „Workflow Relevant Data“ sowie der „Workflow Control Data“. Übermittlung der notwendigen Daten an die Be- nutzer und Applikationen.
- Starten von externen Applikationen.
- Ausführen von Verwaltungsfunktionen.

Im Modell der WfMC werden drei verschiedene Typen von Daten unterschieden:

1) Workflow Control Data: Durch diese Daten kann die WFE den Status der einzelnen Workflows überwachen und steuern. Es ist grundsätzlich nicht vorgesehen, diese Daten anderen Kom- ponenten, von den Administrationswerkzeugen abgesehen, zugänglich zu machen.
2) Workflow Relevant Data: Sie werden von einem WfMS benutzt, um den Zustand konkreter Workflows darzustellen. Sie sind Teil der Daten, die im Zugriff der Applikationen stehen und werden diesen bei Bedarf übermittelt.
3) Workflow Application Data: Dies sind Daten, die jeweils von den einzelnen Applikationen erstellt und verwaltet werden. Der WES hat keinen Zugriff auf diese Daten. Es kann dennoch notwendig sein, daß der WES für die Übermittlung der Daten innerhalb des WfMS zuständig bleibt.

Die drei Komponenten Worklist Handler, Invoked Applications und WFE tauschen „Workflow Relevant Data“ und „Workflow Application Data“ untereinander aus. Ein signifikantes Merkmal zur Unterscheidung verschiedener WfMS-Produkte ist die Art des Datenaustausches33 (data interchange).

Besteht direkter Datenaustausch (direct interchange), so werden die Daten bezüglich der einzelnen Subworkflows zwischen Appli- kationen / Benutzern direkt ausgetauscht. Typischerweise wird dieser direkte Austausch durch E-Mail realisiert. In anderen WfMS benutzen die einzelnen Komponenten gemeinsame Zugriffspfade (shared objects). Auf diese Weise wird der Datenaustausch indi- rekt realisiert. Denkbar ist eine Realisierung über Datenbanken. Es müssen gemeinsame Datenformate und übereinstimmende Zugriffswege definiert werden.

Der indirekte Datenaustausch ist dem direkten vorzuziehen, da die Stati aller Workflows zentral kontrolliert werden können. In einem E-Mail-gestützten WfMS befinden sich die Statusinformationen im Workflow selbst (als Teil der E-Mail), daß bedeutet, die „Stati wandern“ von einem E-Mail-Client zum anderen.

Der Prototyp dieser Arbeit ist ein datenbankgestütztes WfMS.

2.3.2 Process Definition Tools

Diese Softwarewerkzeuge werden während der Planungsphase (build time) benutzt, um die relevante Aufbau- und Ablauforganisation zu analysieren, zu beschreiben und in einer für den WES lesbaren Form zu speichern.

Es gibt eigenständige Werkzeuge, deren Output von unterschied- lichen WESs ausgewertet werden kann34. Es existieren aber auch WfMSe, die ein Process Definition Tool beinhalten. Im letzteren Fall muß die Schnittstelle nicht öffentlich bekannt sein.

Abbildung 5 zeigt das Zusammenarbeiten zwischen Process Defi- nition Tool und WES:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Der Austausch von Workflow-Definitionen

Quelle: Workflow Management Coaltion (1994).

2.3.3 Workflow Client Functions

Der Mitarbeiter hat über den Worklist Handler Zugang zum WfMS. Von diese Softwarekomponente wird er über Aktivitäten informiert, die seine Interaktion benötigen. Anstelle eines Mitarbeiters kann auch eine Gruppe von Mitarbeitern, die alle den gleichen Aufga- benbereich haben, benachrichtigt werden. In diesem Fall muß der WES dafür Sorge tragen, daß der Workflow nur einmal ausgeführt wird35.

Je nach Ausgestaltung der Software kann der Benutzer eine von mehreren Aktivitäten auswählen oder der Worklist Handler gibt ihm einen Workflow (z.B. den dringendsten) vor.

Ähnlich kann die Realisierung der eingebundenen Applikationen sein36. Entweder startet der Worklist Handler die Applikation oder der Benutzer übernimmt dies. Bei den Applikationen handelt es sich meist um Textverarbeitung oder Tabellenkalkulation. Abbil- dung 6 zeigt Austausch über die entsprechende Schnittstelle:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Die Schnittstelle der Client Application

Quelle: Workflow Management Coalition (1994).

2.3.4 Eingebundene Applikationen

Wie in Abbildung 3 zu erkennen ist, werden einige Applikationen vom WES ohne Benutzereingriff gestartet. Eine Vereinheitlichung der Schnittstelle zwischen Applikation und WES ist das Ziel der WfMC, denn kein WfMS-Produkt wird in der Lage sein, alle existie- renden Applikationen zu starten und ihnen die notwendigen Daten im korrekten Format zur Verfügung zu stellen. Da diese Problema- tik in der Informatik bekannt ist, existieren bereits einige Schnitt- stellen. Abbildung 7 zeigt zwei grundsätzliche Varianten:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Invoked Application Interface

Quelle: Workflow Management Coaltion (1994).

Die Kommunikation zwischen WES und Applikation kann über ei- nen sogenannten Application Agent ablaufen. Der Agent ist in der Lage, Programmaufrufe und -terminierungen sowie Datenaus- tausch in beiden Richtungen durchzuführen. Dieser Agent ist bei der anderen Variante nicht notwendig: Eine „workflow-enabled Application“ ist in der Lage, die Kommandos direkt zu interpretie- ren.

2.3.5 System Administration

Die Schnittstelle 5 der WfMC legt fest, wie ein Administrationswerkzeug einen oder mehrere WESs administrieren und beobachten (Monitoring) kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Systemadministrations- und Monitoringschnittstelle

Quelle: Workflow Management Coaltion (1994)

Diese Softwarekomponente muß in der Lage sein

- die einzelnen Benutzer und Arbeitsgruppen zu verwalten,
- ein - eventuell vorhandenes - Rollenkonzept zu administrieren,
- die Bearbeitung der einzelnen Workflows nachvollziehen zu können (Auditing),
- die benutzten Ressourcen (Datenbanken, CPU, Speicherkapa- zität etc.) zu überwachen,
- Prozeßsteuerung (Veränderung der Process Definition, Verän- derung des Status aller oder einzelner Workflows, Terminie- rung einzelner Workflows) durchzuführen und
- Prozeßbeobachtung (Suche eines spezifischen Workflows und Ermittlung seines Zustandes) zu gewährleisten.

Einen großen Raum in der Beschreibung des Referenzmodells der WfMC nimmt die Interoperabilität (die Zusammenarbeit) zwischen WfMSen unterschiedlicher Hersteller ein. Aus Gründen der Vereinfachung wurde auf diesen Teil nicht weiter eingegangen.

Übersichten über WfMS-Produkte finden sich z.B. in Götzer, K.G. (1995) und Karl, R. / Deiters, W. (1996).

3 Die TCP/IP-Protokollfamilie

Das Kapitel 3 enthält eine Beschreibung37 der Funktionsweise des Internets, so wie es von dem erstellten Prototypen genutzt wird. Das Neuartige des vorgestellten Prototypen ist, daß er nicht nur in einem TCP/IP-Netzwerk arbeitet, sondern daß er das HTTP- Protokoll38, besser bekannt als das World Wide Web (WWW), nutzt39. Das Internet läßt sich als mehrere, miteinander verbunde- ne Netzwerke definieren. Über diese Verbindungen kann grund- sätzlich jeder Host40 mit jedem anderen Host in jedem beliebigen Netzwerk kommunizieren.

Seit einiger Zeit sind zwei weitere Begriffe sehr beliebt geworden: Intranet und Extranet. Ein Intranet besteht aus einem oder mehre- ren Netzwerken, die auf der Grundlage von TCP/IP arbeiten, je- doch auf Hosts innerhalb einer Organisation begrenzt sind. Es bestehen keine Kommunikationswege nach außen. Extranets werden als Intranets definiert, die zusätzlich begrenzten und kon- trollierten Zugang zum Internet haben. Diese Trennung kann m. E. in der Praxis nicht aufrecht erhalten werden, da viele Unterneh- men bestrebt sind, ein Intranet aufzubauen und gleichzeitig ver- stärkt mit externen Kommunikationspartnern zu kommunizieren. Zu beachten ist auch, daß es technisch möglich ist, interne Daten- ströme durch das Internet zu leiten, um räumlich weit von einander entfernte Organisationseinheiten zu verbinden. Im weiteren wird der Begriff „Internet“ definitionsgemäß benutzt, während ein „In- tranet“ ein TCP/IP-Netzwerk ist, das die internen Rechner verbin- det und Kommunikation mit externen Hosts ermöglicht.

TCP/IP ist ein Netzwerkprotokoll, also eine international gültige Definition, die beschreibt, wie Rechner miteinander kommunizie- ren können. Anhand dieser Definition können prinzipiell gleichartig funktionierende Kommunikationsprogramme auf beliebige Weise programmiert werden. TCP/IP wird als eine Protokollfamilie oder Protokollsuite bezeichnet. Damit soll zum Ausdruck gebracht wer- den, daß es sich um eine Sammlung verschiedener, zusammenhängender Protokolle um das Transmission Control Protocol (TCP) und das Internet Protocol (IP) handelt. Da es sich um eine sogenannte „open systems interconnection“ handelt, kann jeder das Wissen aus TCP/IP verwenden, ohne durch die Nutzung Eigentumsrechte zu verletzen.

Die Gründe - neben der kostenlosen Verfügbarkeit - für den Erfolg dieser Protokollsuite sind folgende41:

- Bei der Nutzung von TCP/IP ist man von der zugrunde liegen- den Netzwerktechnik unabhängig. Es kann sowohl über Hoch- geschwindigkeits-LANs als auch über Langstreckennetze kommuniziert werden, ohne daß dies den Rechnern transpa- rent gemacht wird (Network Technology Independence).
- Jeder Host, der über TCP/IP kommunizieren kann, ist in der Lage, mit jedem beliebigen Host Verbindung aufzunehmen. Grundlegende Voraussetzung ist, daß die Netzwerke mittel- oder unmittelbar verbunden sind (Universal Interconnection).
- TCP/IP sieht vor, daß Sender und Empfänger sich gegenseitig Empfangsbestätigungen senden können (End-to-End Acknow- ledgement).
- Es existieren zahlreiche Standards für Kommunikationspro- gramme, die auf TCP/IP aufbauen (Application Protocol Stan- dards, z.B. electronic mail, WWW oder file transfer).

Die folgenden Abschnitte stellen das Konzept des TCP/IPs (Ab- schnitt 3.1), die Funktionsweisen des IP (Abschnitt 3.2), die Proto- kolle der Transportschicht (Abschnitt 3.3) und das HTTP (Ab- schnitt 3.4) vor.

Im Abschnitt 2.3.1 wurde erläutert, daß WfMSe, die direct inter- change betreiben, häufig über E-Mails kommunizieren. Das den E- Mails zugrunde liegende Protokoll ist das Simple Mail Transfer Protocol (SMTP). Da dieser Prototyp mit einer Datenbank als shared object realisiert wurde, wird auf die Beschreibung des SMTP verzichtet42.

3.1 Konzept und Architektur

Es existieren zwei grundlegende Möglichkeiten, Kommunikation über ein Netzwerk zu ermöglichen43. Die erste ist das kurzfristige Schalten von festen Verbindungen, so wie dies im Telefonnetz geschieht (circuit-switched). Vorteil ist, daß eine geschaltete Ver- bindung für die gesamte Dauer der Kommunikation mit einer fes- ten Bandbreite (i. S. von Kapazität) zur Verfügung steht. Ein gro- ßer Nachteil sind die Kosten; eine geschaltete Telefonverbindung kostet Gebühren, auch wenn nicht gesprochen wird.

Die zweite Möglichkeit wird üblicherweise zur Kommunikation zwischen Rechnern verwendet (packet-switched). Bei dieser Kommunikation werden die übermittelten Dateien in kleine „Pakete“ zerteilt, die alle einen sogenannten Header beinhalten. In diesem Header steht u.a. die Zieladresse der Datei. Am Ziel angekommen, setzt die Kommunikationssoftware die Datei korrekt zusammen. Vorteile dieser Variante sind die geringen Kosten und der größere Datendurchsatz, denn es sind weniger Leitungen nötig, um mehr Rechner kommunizieren zu lassen.

Das „Internetworking Concept“ ist so ausgearbeitet, daß es mög- lichst flexibel und stabil ist. Aus diesem Grund besteht die Kom- munikationssoftware nicht aus einem Programm, sondern aus mehreren, miteinander kooperierenden „Softwareschichten“:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Die drei Schichten des Internetkonzepts

Quelle: Comer, D.E. (1995), S. 90.

Vorteil dieser Schichtung ist, daß die Software, die unmittelbar mit der Hardware zusammenarbeitet, nicht ausgetauscht werden muß, wenn „höher liegende“ Software, wie z.B. Web Client oder E- Mail-Client, verändert wird. Umgekehrt können diese Applikationen unverändert bleiben, wenn die Hardware (Netzwerkkarte, Kabelverbindung etc.) ausgewechselt wird.

Durch diese Schichtenbildung werden die Netzwerke für die Appli- kationen und die Benutzer transparent. Für sie entsteht der Ein- druck, daß Internet wäre ein großes Netzwerk, siehe Ab-bildung 9:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Die Ansicht des Benutzers auf das Internet

Quelle: Comer, D.E. (1995), S. 55.

Dem Benutzer bleibt der physikalische Aufbau des Internets ver- borgen. Für ihn stellt sich das Internet als ein weitreichendes Netzwerk dar. Es ist jedoch unmöglich, alle Hosts mit einem Netzwerk zu verbinden. Die einzelnen Netzwerke sind durch Ga- teways44 verbunden. Gateways sind Rechner, die in der Lage sind, die Datenpakete so durch die einzelnen Netze zu leiten, daß sie ihr Ziel erreichen, auch wenn dies vom Sender durch mehrere andere Netze getrennt ist.

[...]


1 Der Begriff „Produkt“ umfaßt hier Güter und Dienstleistungen.

2 Zum Zusammenhang zwischen Arbeitsteilung (Differenzierung) und Arbeitsvereinigung (Integration) vgl. Schreyögg, G. (1990), S. 25 - 99.

3 „Kenntnisse“ sind hier als erlerntes Wissen und vorgangsbezogenes Datenmaterial zu verstehen.

4 Zur Trennung von Aufbau- und Ablauforganisation vgl. Nordsieck, F. (1972).

5 Beispiel: Jeder Mitarbeiter eines Finanzamtes, der an einem konkreten Fall mitarbeitet, muß selbst die notwendigen Akten aus dem Archiv holen - und kann diese Informationen den anderen Sachbearbeitern nicht mitteilen.

6 Beispiel: Die Mitarbeiter speichern Daten auf ihren eigenen PCs.

7 Workflow Management Coaltion (1994). Übersetzung durch den Verfasser: Ein WfMS ist „ein System, daß Arbeitsvorgänge vollständig definiert, steuert und diese durch Applikationen ausführen läßt. Die Reihenfolge der Applikationen wird durch eine maschinenlesbare Form der Arbeitsvorgänge (Aufbau- und Ablauforganisation) gesteuert.“

8 Ebenda. Übersetzung durch den Verfasser: Ein Workflow ist „die computergestützte Vereinfachung (im Sinne von Erleichterung) oder Automatisierung eines ganzen Pro-

9 Reichwald, R (1990), S. 67.

10 Siehe Dienstleistungs- und Handelsunternehmen.

11 Hogg, J., Nierstrasz, O.M. und Tsichritzis, D. (1985), S. 137f.

12 Picot, A. und Reichwald, R. (1987).

13 Vgl. Szyperski et al. (1982), zitiert nach Reichwald, R. (1990), S. 69.

14 Hansen, H. R. (1992), S. 858.

15 Reichwald, R. (1990), S. 69.

16 Siehe Jablonski, S. (1995), S. 13. Siehe auch Koch, O. und Zielke, F. (1996), S. 35f.

17 Siehe Hammer, M. (1993), das als eines der Standardwerke in diesem Bereich gilt.

18 „Zweckmäßig“ bedeutet hier, daß die Unternehmensorganisation strikt auf das Unternehmensziel ausgerichtet ist und möglicherweise unnötige oder umständliche Vorgänge eliminiert bzw. verbessert worden sind. Dieser Zustand ist z.B. nach einer Unternehmens-Reorganisation erreicht.

19 Jablonski, S. (1995) S. 13 - 24.

20 Ebenda S. 14.

21 Ebenda S. 14f.

22 Durch diese Referenzierung wird deutlich, daß die Aufgabe des WfMS „nur“ in der Steuerung i.w.S. besteht. Die eigentliche Bearbeitung des Vorgangs führt ein Aktor (also Mitarbeiter oder Softwareapplikation) aus.

23 Im Referenzmodell der WfMC wird diese Hülle als „Workflow Application Programming Interface, WAPI, bezeichnet, siehe Abschnitt 2.3.

24 Jablonski, S. (1995), S. 17.

25 Mehr zu den Abhängigkeiten im folgenden Abschnitt 2.2.3.

26 Siehe Abschnitt 2.3.2.

27 Z.B. der Name des Antragstellers, Kostenstelle, Reiseziel und -datum.

28 Vgl. Workflow Management Coaltion (1994).

29 Mehr zur WfMC siehe Sauter, C. und Morger, O. (1996).

30 Im Gegensatz zum Referenzmodell Jablonskis, das auf seiner theoretischen Herleitung aufbaut.

31 Jeder Mitarbeiter bzw. jede Gruppe von „homogenen“ Usern hat eine eigene Work- list.

32 Voraussetzung ist, daß die Applikationen den Standards der WfMC entsprechen.

33 Vgl. auch Götzer, K.G. (1995), S. 74f.

34 Das ARIS-Toolset der IDS Prof. Scheer GmbH, Saarbrücken kann als Standardprodukt dieser Werkzeuge bezeichnet werden.

35 Vgl. Abschnitt 2.2.2.

36 Gemeint ist hier die Indirect Invocation.

37 Siehe Comer, D.E. (1995) und Stevens, W.R. (1994).

38 HTTP steht für Hypertext Transfer Protocol, siehe Abschnitt 3.4.

39 Nicht jedes TCP/IP-Netzwerk ist ein Intranet oder sogar ein Teil des Internets.

40 Alle Rechner, die Zugang zu einem Netzwerk haben, werden verallgemeinernd als „Host“ bezeichnet, um alle gängigen Rechnertypen zu beschreiben.

41 Vgl. Comer, D.E. (1995), S. 5f.

42 Zu SMTP siehe Comer, D.E. (1995), S. 433 - 446 und Stevens, W.R. (1994), S. 389 - 440.

43 Vgl. Comer, D.E. (1995), S. 49 - 51.

Details

Seiten
185
Jahr
1997
ISBN (eBook)
9783656998563
ISBN (Buch)
9783867461658
Dateigröße
3 MB
Sprache
Deutsch
Katalognummer
v185258
Institution / Hochschule
FernUniversität Hagen
Note
1.7
Schlagworte
entwurf realisierung workflow-management-systems intranet

Autor

Zurück

Titel: Entwurf und Realisierung eines datenbankgestützten Workflow-Management-Systems für ein Intranet