Geschäftsprozessanalyse (eBook)

Vorwort zur dritten Auflage 5
Vorwort zur zweiten Auflage 6
Vorwort zur ersten Auflage (gekürzt) 8
Inhaltsverzeichnis 10
1 Einleitung 17
1.1 Immer mehr, immer tiefer 17
1.2 Modelle 18
1.3 Aufbau der Arbeit 18
2 Geschäftsprozesse 21
2.1 Definitionen und Begriffe 21
2.2 Kernprozesse 27
2.3 Eigenschaften und Komponenten 30
2.4 Geschäftsprozesse über Unternehmensgrenzen 32
2.5 Ziele der Geschäftsprozessmodellierung 33
2.6 Business Process Reengineering 34
2.7 Prozessorientierung 35
2.8 Unschärfen 38
2.9 Beispiele – Angebotserstellung und Auftragsabwicklung 40
2.10 Das ARIS-Konzept 43
3 Betriebswirtschaftliche Standardsoftware / ERP-Software 49
3.1 Definition und Abgrenzung 49
3.2 Begleiterscheinungen 56
3.3 Überwindung der „Lücke“ 62
3.4 Einführung 64
3.5 Leidensdruck - Warum überhaupt ? 69
3.6 Perspektiven 71
4 Ereignisgesteuerte Prozessketten -Grundlagen 75
4.1 Einführung 75
4.2 Elemente 76
4.2.1 Funktionen 76
4.2.2 Ereignisse 78
4.2.3 Organisationseinheiten 79
4.2.4 Informationsobjekte 80
4.2.5 Operatoren und Kontrollfluss 82
4.3 Aufbau 83
4.3.1 Funktionen 84
4.3.2 Varianten 96
4.3.3 Zusammenfassung der Syntaxregeln 96
4.3.4 Zusätzliche Operatoren 97
4.4 Verknüpfungsbeispiele 97
4.4.1 Ereignisverknüpfung mit auslösenden Ereignissen 99
4.4.2 Ereignisverknüpfung mit erzeugten Ereignissen 105
4.4.3 Funktionsverknüpfung mit auslösenden Ereignissen 110
4.4.4 Funktionsverknüpfung mit erzeugten Ereignissen 116
4.5 Mehrere Operatoren im Kreis 121
4.6 Zusammenführen des Kontrollflusses 122
4.7 Aufteilung großer Geschäftsprozesse 126
4.8 Erste Beispiele 129
5 Ereignisgesteuerte Prozessketten -Vertiefung 141
5.1 Rückschleifen 141
5.2 Repetitive Handlungen 146
5.3 Warten 147
5.4 Einfügen der zeitlichen Dimension 151
5.5 Keine falschen Schlussereignisse 152
5.6 Genauigkeit erhöhen 154
6 Beispiele 159
6.1 Kundenanfrage und Angebotserstellung 160
6.2 Auftragsabwicklung 180
6.3 Angebotserstellung im Anlagenbau 226
6.4 Vorbereitung Auftragsabwicklung 234
7 Ereignisgesteuerte Prozessketten bewältigen 245
7.1 Situationen und ihre Bewältigung 245
7.1.1 Aufeinanderwirken von Funktionen 245
7.1.2 Ebenen – Detaillierungsgrad - Kapselung 247
7.1.3 Leerzweige 248
7.1.4 Optionale Ereignisse 249
7.1.5 Komplexitätsbewältigung - Vervielfachung vs.Schlankheit 251
7.1.6 Struktur vs. Daten 255
7.1.7 Intern/Extern und Warten 256
7.2 Einschätzung der „Methode EPK“ 257
7.2.1 Grenzen der Prozessorientierung 257
7.2.2 Gefahren der Prozessorientierung 258
7.2.3 Möglichkeiten und Grenzen von EPKs 259
8 Beispiel für eine Unternehmensmodellierung 263
8.1 Das Konzept und die Elemente 263
8.2 Ereignisgesteuerte Prozessketten 268
8.2.1 Basis-EPKs 268
8.2.2 Szenarien 280
8.2.3 Wertschöpfungsketten 290
8.3 Informationsstrukturen 296
8.3.1 Grundkonzept 296
8.3.2 SAP-SERM 298
8.3.3 Konkrete Beispiele mit Erläuterungen 310
8.3.4 Business Objekte 318
9 Objektorientierte Modellierung -Grundlagen 325
9.1 Einleitung 325
9.1.1 Objektorientierung 325
9.1.2 Geschäftsprozesse – ja/nein 326
9.1.3 Grundkonzepte - Berührung Realwelt und Modell 326
9.1.4 Struktur und Verhalten in Abbildungen 328
9.2 Modellierung von Strukturen 328
9.2.1 Statische Aspekte I – Objekte und Objektklassen 328
9.2.2 Statische Aspekte II - Objekte in Beziehung setzen 341
9.2.3 Dynamische Aspekte 360
10 Objektorientierte Modellierung von Verhalten und Abläufen 365
10.1 Einführung 365
10.2 Verhalten 367
10.2.1 Starke Verknüpfung von Objekten und Verhalten 368
10.2.2 Executing und Emergent Behavior 369
10.3 Konstrukte für die Verhaltensmodellierung 370
10.4 Basiskonzepte für die Verhaltensmodellierung 371
10.4.1 Token 371
10.4.2 Classifier 373
11 Aktionen 377
11.1 Definition 377
11.2 Grafische Darstellung 378
11.3 Aktionen im Kontrollfluss 379
11.4 Pins an Aktionen 380
11.5 Start einer Aktion 381
11.6 Primitive Actions 381
11.7 Aktionen und Variable 382
11.8 Subordinate Units – zusammengefasste Aktionen 382
11.9 Hinweise zur Metamodellierung 383
11.10 Zusammenfassung 383
11.11 Aggregation - in Geschäftsprozessen und Systemen 383
12 Aktivitäten 387
12.1 Einleitung 387
12.2 Definition 387
12.3 Einführendes Beispiel 389
12.4 Überblick - Knoten und Kanten in Aktivitätsdiagrammen 390
12.5 Aktivitätsknoten 391
12.5.1 Aktionsknoten 391
12.5.2 Objektknoten 391
12.6 Aktivitätskanten 394
12.6.1 Kanten für den Kontrollfluss 394
12.6.2 Kanten für den Objektfluss - Objektflusskanten 396
12.6.3 Objektflüsse und Pins 397
12.6.4 Abgrenzung zwischen den Kantenarten 405
12.7 Strukturierte Aktivitätsknoten 406
12.8 Kontrollknoten 408
12.8.1 DecisionNode 409
12.8.2 Merge Node 410
12.8.3 ForkNode 412
12.8.4 JoinNode 413
12.8.5 Startknoten 416
12.8.6 Schlussknoten - ActivityFinal und FlowFinal 417
12.9 Aufruf von Aktivitäten 421
12.10 Aktivitäten aufteilen – Träger zuordnen 421
12.11 Die zeitliche Dimension und die Ereignisse 424
12.12 Kontrollfluss vertieft 428
12.12.1 Verhalten von Aktionen 428
12.12.2 Das streaming-Konzept 430
12.12.3 Mehrfach aktiv? 430
12.12.4 Beziehungen zwischen Flüssen 431
12.12.5 Token 431
12.13 Metamodellierung - Aktivitäten als Klassen 433
12.14 Beispiele 433
12.14.1 Fehlerbehandlung 434
12.14.2 Lagerentnahme 435
12.14.3 Personaleinstellung 435
12.14.4 Auftragsbearbeitung 436
12.14.5 Design Part und Provide Required Part 438
12.14.6 Problembehandlung 440
12.14.7 Auslagenerstattung 441
12.14.8 Vorschlagswesen 442
13 Sequenzen, Sequenzdiagramme 445
13.1 Einführung 445
13.2 Grundstruktur 446
13.3 Einführendes Beispiel 447
13.4 Grundbegriffe 448
13.5 Lifelines 450
13.6 Nachrichten zwischen Lifelines 450
13.7 Strukturieren durch CombinedFragments 452
13.8 Gates und InteractionFragments 457
13.9 ExecutionOccurence 458
13.10 Interaktionen 459
13.11 InteractionConstraint 464
13.12 InteractionOccurrence 464
13.13 InteractionOperand 466
13.14 StateInvariant 467
13.15 Stop 467
13.16 Beispiele zu Sequenzdiagrammen 467
14 Anwendungsfälle 471
14.1 Definition 471
14.2 Einführendes Beispiel 473
14.3 Anwendungsfälle 473
14.3.1 Extend-Beziehung 475
14.3.2 Include - Beziehung 477
14.4 Akteure 477
14.5 Beispiel 478
14.6 Einschätzung 479
15 Zustandsautomaten 485
15.1 Einleitung 485
15.2 Einführende Beispiele 487
15.3 Zustände 488
15.3.1 Definition 488
15.3.2 Zustände in Zustandsautomaten 489
15.3.3 Pseudozustände 491
15.3.4 Transitionen zu Zuständen 497
15.3.5 Zustandsautomaten im Zustand 498
15.3.6 Die Semantik von Zuständen 503
15.3.7 Grafische Darstellung von Zuständen 508
15.4 Transitionen 512
15.5 Ereignisraum und Ereignisverarbeitung 514
15.6 Protokollzustandsautomaten 515
15.7 Zustandsautomaten und Prozessmodellierung 517
16 Gesamteinschätzung 519
16.1 Kontrollflusskonzept 519
16.2 Verhaltensbegriff 520
16.3 Wohltuend abgehoben 521
17 Glossar 523
18 Index 527
19 Literatur 545

9 Objektorientierte Modellierung - Grundlagen (S. 309-311)

9.1 Einleitung

9.1.1 Objektorientierung

Vielleicht die wichtigste Neuerung in der Informatik der letzten 20 Jahre war und ist die Hinwendung zur Objektorientierung. Sie ist im Bereich der Programmiersprachen mittlerweile fest etabliert und steht in der Systemanalyse vor dem Durchbruch89. Noch nicht ganz so weit ist die Entwicklung bei Datenbanksystemen. Hier ist zwar in der Theorie alles vorbereitet und es existieren erste auch kommerziell verfügbare Datenbanksysteme, der große Durchbruch lässt allerdings auf sich warten. Objektorientierung Objektorientierung bedeutet eine neue Art und Weise, mit der in der Informatik Realweltphänomene wahrgenommen werden. In der Systemanalyse und Programmierung die der zu programmierenden Anwendung. Im Bereich der Datenbanken der so genannte Weltausschnitt, der zur Modellierung ansteht.

Der objektorientierte Ansatz ist also ein Modellierungsansatz, ein Werkzeug zur adäquaten Beschreibung eines Anwendungsbereichs. Für die Anwendungsentwicklung als Systemanalyse und Systemdesign, für Datenbanken als Datenmodell. Diese Modelle dienen dann der konkreten Programmierung bzw. der Einrichtung der Datenbank. Das Ergebnis der Modellierungsbemühungen wird Objektmodell genannt. Es wird in dieser Arbeit zu prüfen sein, ob die objektorientierte Theorie auch Modelle von Geschäftsprozessen liefern kann. Damit kann die Frage, die den nächsten Kapiteln zugrundeliegt, auch so formuliert werden: Ist der objektorientierte Ansatz geeignet, Unternehmen in ihrer ganzen Komplexität zu modellieren, also nicht nur bezüglich der Datenstrukturen, sondern auch bezüglich der Geschäftsprozesse und anderer Eigenschaften? Dynamisch vs. statisch Von besonderem Interesse (generell und für die hier diskutierten Probleme) ist der objektorientierte Ansatz deshalb, weil er dazu führt, dass die Trennung zwischen dynamischen und statischen Aspekten eines Anwendungsbereichs zumindest teilweise aufgehoben wird. In dieser Arbeit ist dies von besonderer Bedeutung, weil Geschäftsprozesse in Unternehmen dynamische Aspekte geradezu verkörpern.

9.1.2 Geschäftsprozesse – ja/nein

Die meisten Autoren, die im Zusammenhang mit der UML veröffentlichen, konzentrieren sich auf Fragen der Systemanalyse und des Systemdesigns. Dabei werden dann Fragen des objektorientierten Datenbankdesigns auch mitbetrachtet. Fragen der Prozessmodellierung werden nur stiefmütterlich betrachtet, trotz des Anspruches der UML, vgl. unten. Meist wurden und werden Prozesse mit Systemverhalten gleichgesetzt, was natürlich falsch ist. Inzwischen hat sich dies, zumindest bei einigen Autoren, geändert. Es wurde erkannt, dass es „über" dem Systemverhalten noch die Geschäftsprozesse gibt und dass diese eine besondere Behandlung verdienen.

Ein Grund dafür ist, dass Geschäftsprozesse auch Abläufe betreffen die, mit den Worten von Martin/Odell, nicht softwarebezogen sind [Martin und Odell 1999, S. 27], die also nicht durch Software unterstützt werden. Odell/ Martin bejahen die Eignung des objektorientierten Ansatzes dafür, weisen aber auch darauf hin, dass die Objektorientierung eigentlich aus dem Bedürfnis entstand, einen einfacheren Weg zur Simulation von Systemen zu finden. Trotzdem schimmert in ihren Ausführungen die Überlegung durch, dass Geschäftsprozesse, auch solche mit Abschnitten, die nicht durch Software unterstützt werden, Systeme sind.

9.1.3 Grundkonzepte - Berührung Realwelt und Modell

Berührung mit der Realwelt Modellierungssprachen haben per Definition einen Gegenstand, den sie modellieren und sie dienen immer einem bestimmten Ziel. In dem hier betrachteten Kontext werden Systeme (typischerweise) oder Geschäftsprozesse in Unternehmen (dem Anspruch nach) modelliert mit dem Ziel, Teile ihrer Funktionalität durch Programme zu realisieren bzw. zu unterstützen. Beispiele für zu modellierende Systeme sind ein Geldautomat oder eine Web-Plattform, Beispiele für Geschäftsprozesse z.B. eine Angebotserstellung oder eine Auftragsabwicklung.