Müller Workflow-based Integration

Grundlagen, Technologien, Management
2005
ISBN: 978-3-540-26872-7
Verlag: Springer Berlin Heidelberg
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 238 Seiten

Reihe: Xpert.press

Das Buch bietet einen umfassenden Überblick zu standardisierten Methoden der Prozess-Modellierung auf der Basis einer für viele Branchen typischen Applikationsumgebung. Der Autor stellt effektive Architekturen zur optimalen Implementation der modellierten Prozesse vor, beschreibt Management-Techniken zur Organisation von Workflow-Projekten und erläutert etablierte Tools zur Unterstützung betrieblicher Prozess-Integration. Das Buch wendet sich vornehmlich an Entscheider, aber auch an Entwickler, die einen fundierten Einstieg in die Grundlagen, Technologien und Management-Techniken der Workflow-based Integration sowie der Enterprise Application Integration suchen.

Geschrieben für:
Entscheider in der IT-Branche, Entwickler betrieblicher Workflow-Modelle

Schlagworte:
Client-Server-Technologie
EAI Prozessintegration
Prozessmodellierung
Workflow

Autoren/Hrsg.

Müller, Joachim

Inhaltsverzeichnis

1;Vorwort;7
2;Inhaltsverzeichnis;9
3;Einleitung;12
4;Überblick;16
5;Vorgezogenes Fazit;17
6;1 Workflow;18
6.1;1.1 Was ist ein Geschäftsprozess?;18
6.2;1.2 Was ist ein Workflow?;19
6.3;1.3 Was ist Workflow Management?;21
6.4;1.4 Workflow vs. Geschäftsprozess;25
6.5;1.4.1 Historie der Workflow-Management-Systeme;25
6.6;1.5 WfMC (Workflow Management Coalition);28
6.6.1;1.5.1 Workflow Reference Model;28
6.6.2;1.5.2 Metamodell eines Workflows;31
6.7;1.6 Softwarearchitektur einer workflow-basierten Lösung;32
6.8;1.7 Warum Workflow einführen?;35
6.8.1;1.7.1 Aktuelle Situation in den Unternehmen;35
6.8.2;1.7.2 Vorteile von workflow-basierten Lösungen;36
6.8.3;1.7.3 Prozesseigenschaften für den Einsatz eines WfMS;38
6.9;1.8 Der Workflow-Regelkreis;39
6.10;1.9 Kommentar;41
6.10.1;1.9.1 Prozessdefinition;42
6.10.2;1.9.2 Architektur;43
6.10.3;1.9.3 WfMC;44
7;2 Enterprise Application Integration (EAI);46
7.1;2.1 Begriffserklärung;46
7.1.1;2.1.1 Formen von EAI;47
7.1.2;2.1.2 Integrationsarten;49
7.2;2.2 Entwicklung von EAI;53
7.2.1;2.2.1 Innerhalb der Unternehmen;53
7.2.2;2.2.2 Zu anderen Unternehmen;55
7.3;2.3 Eigenschaften eines Integrationsservers;55
7.4;2.4 EAI-Architekturen;62
7.4.1;2.4.1 Point-to-Point;63
7.4.2;2.4.2 Hub & Spoke;64
7.4.3;2.4.3 Bus-oriented;64
7.4.4;2.4.4 Distributed Objects;65
7.5;2.5 Middleware;66
7.6;2.6 Kommentar;67
8;3 Software-Architekturen;70
8.1;3.1 Software-Architekturarten;75
8.1.1;3.1.1 Zwei-Schichten-Architektur;75
8.1.2;3.1.2 Drei-Schichten-Architektur;75
8.1.3;3.1.3 Vier-Schichten-Architektur;76
8.2;3.2 Java 2 Enterprise Edition (J2EE);77
8.3;3.3 Weitere objektorientierte Architekturen;81
8.3.1;3.3.1 Verteilte Anwendungen mit CORBA;82
8.3.2;3.3.2 Verteilte Anwendungen mit Microsoft .NET;86
8.4;3.4 Kommentar;88
9;4 Prozessmodellierung;90
9.1;4.1 Modellierungsmethoden;97
9.1.1;4.1.1 Petrinetze;98
9.1.2;4.1.2 Ereignisgesteuerte Prozessketten (EPK);105
9.1.3;4.1.3 Unified Modeling Language (UML);110
9.1.4;4.1.4 Gegenüberstellung;123
9.2;4.2 Kommentar;124
10;5 Workflow-based Integration (WfbI);126
10.1;5.1 Modellierungsansatz;126
10.2;5.2 Technischer Ansatz;128
10.2.1;5.2.1 Variante 1;129
10.2.2;5.2.2 Variante 2;130
10.2.3;5.2.3 Client-Varianten;133
10.2.4;5.2.4 Authentifizierung und Autorisierung;135
10.3;5.3 Kommentar;136
11;6 Workflow-Projekte;138
11.1;6.1 Einleitung;138
11.2;6.2 Projektablauf/Vorgehensmodell;138
11.2.1;6.2.1 Initial;141
11.2.2;6.2.2 Analyse der bestehenden Prozesse;143
11.2.3;6.2.3 Projektziel bestimmen;144
11.2.4;6.2.4 Prozess modellieren;146
11.2.5;6.2.5 Feinmodellierung und technische Konzeption;150
11.2.6;6.2.6 Geschäftsprozess implementieren;159
11.2.7;6.2.7 Test des Geschäftsprozesses;160
11.2.8;6.2.8 Geschäftsprozess freigeben;161
11.2.9;6.2.9 Laufzeitdaten erfassen;161
11.2.10;6.2.10 Auswerten der Laufzeitdaten und Redesign des Prozesses;162
11.3;6.3 Projektorganisation und Projektrollen;163
12;7 Ausblick;168
12.1;7.1 Web Services;168
12.1.1;7.1.1 Definierte Rollen;169
12.1.2;7.1.2 Technik;169
12.1.3;7.1.3 Web Services in Verbindung mit Workflow;170
12.1.4;7.1.4 Kommentar;172
12.2;7.2 Open-Source;173
12.2.1;7.2.1 Was ist Open-Source?;173
12.2.2;7.2.2 Lizenzmodelle;174
12.2.3;7.2.3 Open-Source in Verbindung mit Workflow;175
12.2.4;7.2.4 Kommentar;177
13;8 Werkzeuge;178
13.1;8.1 Workflow-Management-Systeme;178
13.1.1;8.1.1 CARNOT;179
13.1.2;8.1.2 e-Work;187
13.1.3;8.1.3 EasyFlow;194
13.2;8.2 Auswahlkriterien für ein WfMS;201
13.3;8.3 Eigenentwicklung eines WfMS;206
13.4;8.4 Modellierungswerkzeuge;209
13.4.1;8.4.1 ADONIS;209
13.4.2;8.4.2 ARIS;210
13.5;8.5 Kommentar;211
14;9 Template;214
14.1;9.1 Projektziele bestimmen;214
14.2;9.2 Prozesslandkarte erstellen;216
14.3;9.3 Erfolgsfaktoren ermitteln;217
14.4;9.4 Prozesse bewerten;218
14.5;9.5 Projektbeteiligte ermitteln;219
14.6;9.6 Prozesse bewerten und priorisieren;220
14.7;9.7 Mengengerüst erfassen;222
14.8;9.8 Ressourcen erfassen;223
14.9;9.9 Verbesserungspotential bewerten;224
14.10;9.10 Teilprojekte identifizieren;225
14.11;9.11 Prozessschnittstellen aufnehmen;226
14.12;9.12 Identifizierte Anwendungen;228
15;10 Anhang;228
15.1;10.1 ARIS-Konzept;230
15.1.1;10.1.1 Phasen des HOBE;230
15.1.2;10.1.2 ARIS-Haus;231
15.1.3;10.1.3 Objekte in ARIS;232
15.1.4;10.1.4 Sichten in ARIS;232
15.2;10.2 WfMC-Dokumenten-Index;233
16;Glossar;236
17;Literaturverzeichnis;244
18;Stichwortverzeichnis;248

Leseproben

6 Workflow-Projekte (S. 127-128)

6.1 Einleitung
Dieses Kapitel beschreibt eine Vorgehensweise für ein Integrationsprojekt in Verbindung mit einem Workflow (Workflow-Projekt) und die dafür benötigten Rollen der Projektbeteiligten. Es wird darauf hingewiesen, dass es sich hierbei um eine ideale Darstellung handelt und diese für den Praxisgebrauch an das jeweilige Unternehmen und Umfeld angepasst werden muss. Entscheidenden Einfluss auf den Umfang eines Projektes hat die Unternehmensgröße und die vorhandene ITInfrastruktur des Unternehmens. Sind Applikationen und/oder Produkte bereits strategisch gesetzt, so beeinflussen diese Randbedingungen den Aufwand für das Projekt erheblich. Außerdem haben solche zuvor getroffenen Entscheidungen einen wichtigen Einfluss auf eventuelle Evaluierungen von weiteren Teillösungen für die technische Unterstützung von Geschäftsprozessen. Es wird in diesem Kapitel aber nicht auf grundlegende Aspekte von IT-Projekten wie z.B. eine Risikoanalyse oder Fallback-Strategien eingegangen, da eine detaillierte Beschreibung derselben den Rahmen dieses Buches sprengen würde. Allerdings werden diese wichtigen Projektbestandteile häufig nicht ausreichend berücksichtigt. Dies zeigt sich in vielen IT-Projekten, in denen z.B. Risikoanalysen zu selten durchgeführt werden. Dadurch kommt es zu unvorhergesehenen Problemen, die vermieden oder zumindest verringert werden könnten.

6.2 Projektablauf/Vorgehensmodell
In den vorangegangenen Kapiteln wurden die unterschiedlichen Ausgangssituationen für ein Workflow-Projekt erwähnt. Es gilt nun, diese auf die im Unternehmen tatsächlich vorhandenen Strukturen abzubilden. Durch solch eine „Standortbestimmung" kann die Firmenleitung bzw. der Abteilungsleiter den fachlich richtigen Projektstart bestimmen und so die ersten Schritte für das Projekt definieren. Das Ergebnis einer solchen Standortbestimmung kann sein, dass erst die Geschäftsprozesse global dokumentiert und darauf folgend (Teil-)Geschäftsprozesse modelliert und realisiert werden. In dem folgenden Kapitel wird eine Vorgehensweise vorgestellt, deren Struktur es ermöglicht, ein Workflow-Projekt effektiv durchzuführen. Zu Beginn muss jedoch definiert werden, was unter der Projektlaufzeit verstanden wird. Nach der Meinung des Autors wird in bzw. vor einem Projekt die globale Sichtweise eines Projektes zu wenig berücksichtigt.

Es kommt immer wieder vor, dass verzögerte Projekte gestoppt werden und das Ergebnis einer Prüfung (Review) dann zeigt, dass die Ursache für den schlechten Zustand des Projektes die begrenzte Sicht auf das Projektumfeld war. Ein Resultat eines solchen Reviews ist oft, dass kein Informationsaustausch und/oder keine Abstimmungen mit laufenden „Nachbarprojekten" stattgefunden hat. Es ist daher wichtig, dass das eigene Projekt fest in die bestehende System- und Projektlandschaft integriert wird. Workflow-Projekte haben hier einen entscheidenden Vorteil. Sie werden in der Regel von einer Fachabteilung ins Leben gerufen, so dass zumindest bei den fachlichen Anforderungen von einer Absprache innerhalb der Abteilung ausgegangen werden kann6. Somit muss man sich hauptsächlich bezüglich der technischen Realisierung mit anderen Projekten absprechen.

Eine Ausnahme bilden hier die Prozesse in den IT-Abteilungen. Fachabteilungen positionieren und starten ein Workflow-Projekt. Eine Fachabteilung ist somit der Auftraggeber und muss die Randbedingungen wie Budget und Anforderungen festlegen. Der Auftraggeber muss sich im Klaren darüber sein, was die Projektlaufzeit für ihn darstellt und welche Aufgaben auf ihn und die Projektbeteiligten zukommen. Die Projektlaufzeit beginnt mit einem fertig formulierten Projektauftrag und endet – im Falle eines Workflow-Projektes –, wenn der Prozess oder die eingeführte Lösung nicht mehr verwendet wird.

Demnach gehört zur Projektlaufzeit auch der Betrieb und die sich daraus ergebende Wartung eines Prozesses und der unterstützenden Systeme. Ist die Realisierung des Prozesses abgeschlossen und die ITLösung in Betrieb genommen worden, so wird das Projekt aus der Projektorganisation in die Linienorganisation überführt und die Wartung des Prozesses wird in der Abteilung durchgeführt, der der Prozessverantwortliche bzw. Auftraggeber zugeordnet ist. Dies schließt nicht aus, dass bei Erweiterungen wieder andere Abteilungen, insbesondere der IT-Bereich, involviert werden.