Workflow-based Integration (eBook)

Grundlagen, Technologien, Management

Joachim Müller (Autor)

eBook Download: PDF

2005 | 2005
XII, 238 Seiten
Springer Berlin (Verlag)
9783540268727 (ISBN)

Infos

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

Inhalt

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

Textauszug

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.

Produkt-Details

• Erscheint lt. Verlag: 5.9.2005
• Reihe/Serie: Xpert.press
• Reihe/Serie: Xpert.press
• Zusatzinfo: XII, 238 S.
• Verlagsort: Berlin
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik
• Themenwelt: Wirtschaft ► Betriebswirtschaft / Management ► Planung / Organisation
• Schlagworte: Architektur • Client-Server-Technologie • EAI • Enterprise Application Integration • Implementierung • Modellierung • Organisation • Projektmanagement • Prozessintegration • Prozessmodellierung • Workflow
• ISBN-13: 9783540268727 / 9783540268727