Geschaftsprozessanalyse: Ereignisgesteuerte Prozessketten und objektorientierte Geschaftsprozessmodellierung fur Betriebswirtschaftliche Standardsoftware (German Edition)

Geschäftsprozessanalyse Ereignisgesteuerte Prozessketten und objektorientierte Geschäftsprozessmodellierung für Betriebswirtschaftliche Standardsoftware

Josef Staud

Geschäftsprozessanalyse Ereignisgesteuerte Prozessketten und objektorientierte Geschäftsprozessmodellierung für Betriebswirtschaftliche Standardsoftware Dritte Auflage

Mit 335 Abbildungen

123

Professor Dr. Josef Staud Hauptstr. 76 88379 Unterwaldhausen www.staud.info

Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISBN-10 3-540-24510-3 3. Aufl. Springer Berlin Heidelberg New York ISBN-13 978-3-540-24510-0 3. Aufl. Springer Berlin Heidelberg New York ISBN 3-540-41461-4 2. Aufl. Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2006 Printed in Germany Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz: Druckfertige Daten des Autors Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: de’blik, Berlin SPIN 11384274 42/3100/YL – 5 4 3 2 1 0 – Gedruckt auf säurefreiem Papier

Vorwort zur dritten Auflage

Die wichtigste Änderung gegenüber der zweiten Auflage ist die völlige Neugestaltung der Texte zur objektorientierten Modellierung von Verhalten bzw. von Geschäftsprozessen. Aus einem Kapitel wurden acht, in denen die einschlägigen Elemente der objektorientierten Theorie sehr detailliert dargestellt und bezüglich ihrer Tauglichkeit für die Geschäftsprozessmodellierung hinterfragt werden. Der Grund dafür ist zum einen die gestiegene Bedeutung der objektorientierten Theorieelemente für die Unternehmensmodellierung im allgemeinen und die Geschäftsprozessmodellierung im besonderen. Zum anderen zeigt sich, dass die vorliegende Literatur zur objektorientierten Theorie zwar auf das Software Engineering sehr gut vorbereitet, aber nur wenig zur Antwort auf die Fragen beiträgt, ob und falls ja, wie, Geschäftsprozesse mit diesem objektorientierten Ansatz modelliert werden können. Auch nicht in den Grundlagen. Einige Autoren zeigen hier sogar ein sehr eingeschränktes Verständnis von Geschäftsprozessen. Deshalb wird hier in den Kapiteln 10 – 17 der Vorschlag der UMLAutoren (Version 2.0) in vollem Umfang und grundsätzlich dargestellt, wobei aber in jedem Kapitel gleich auch die hier interessierende Frage gestellt wird: Ist das jeweilige Konzept für die Modellierung von Geschäftsprozessen geeignet? Diese Kapitel wollen aber noch mehr. Sie sind so gestaltet, dass sie auch den Zugang zur Originalquelle, zu den Texten der UML-Autoren, erleichtern. Vgl. dazu die Anmerkungen vor Kapitel 9. Alle übrigen Kapitel wurden durchgesehen, Fehler werden beseitigt und Ergänzungen eingefügt. Das Kapitel mit der Unternehmensmodellierung der SAP wurde als eindrucksvolles Beispiel dafür, wie eine konkrete Unternehmensmodellierung aussehen kann, im Buch belassen, obwohl es nicht mehr dem aktuellen Stand entspricht. Weitere Informationen zur Thematik des Buches werden auf meinen Web-Seiten platziert: www.staud.info.

Objektorientierte Modellierung von Verhalten

Geschäftsprozessmodellierung mit der UML?

Web-Seiten

VI

Vorwort

Vorwort zur zweiten Auflage

Prozessorientierung

Methode EPK

Von Intra zu Inter

Was ist verändert?

Die Diskussion um Geschäftsprozesse, ihre Modellierung und theoretischen Grundlagen hat seit Erscheinen der ersten Auflage noch an Intensität zugenommen. Dies überrascht nicht angesichts der Durchsetzungskraft des Prozessgedankens. Nicht nur bei der Wahrnehmung der Unternehmensrealität - diese geht heute ganz selbstverständlich von Geschäftsprozessen aus - sondern auch bei der Erstellung integrierter Software. Praktisch jedebs Software, die in irgendeiner Weise mit den Abläufen in Unternehmen zu tun hat, ist heute auch prozessorientiert. Die „Methode EPK" hat weitere Akzeptanz erfahren. Sie ist längst von einer Technik zur Beschreibung von Software zu einer Technik der IstAnalysen, des Business Process Reengineering geworden. In allen Bereichen, auch außerhalb von Industrie und Dienstleistungen. Überall, wo Geschäftsprozesse analysiert werden müssen, sei es wegen der Einführung Betriebswirtschaftlicher Standardsoftware, wegen Geschäftsprozessoptimierungsbedarf oder wegen einer ISO-Zertifizierung. Und vielleicht erleben wir ja noch, dass die Vertreter der objektorientierten Systemanalyse in einigen Jahren noch deutlicher erkennen, dass Ereignisgesteuerte Prozessketten eine hervorragende Ergänzung ihres Instrumentariums sind, dass damit die Systemumwelt umfassend erfasst werden kann. Der Vormarsch des Internet ging unaufhaltsam weiter. Von einem Kommunikationsmedium wurde es zu einem umfassenden virtuellen Marktplatz und - natürlich - zu einem Kulturmedium, zu einem Medium gesellschaftlicher Interaktion. Dabei zeigen aktuelle Zahlen (April 2001), dass im Bereich des B2B (Business to Business) deutlich mehr Umsätze gemacht werden, als in den anderen (z.B. B2C). Wie erwartet, erweist sich die durch das Internet verbesserte Abwicklung von Geschäftsprozessen über Unternehmensgrenzen hinweg als Erfolgsfaktor und die dafür erstellte Software als umsatzträchtig. Der Bedarf an Geschäftsprozessanalysen hat damit noch zugenommen. Jetzt geht es verstärkt um die Geschäftsprozesse zwischen Unternehmen. Die Folgerung allerdings, die ausgesprochen oder unausgesprochen viele ziehen, dadurch würde das Thema Optimierung der internen Geschäftsprozesse weniger wichtig, ist falsch. Gegenüber der ersten Auflage wurden alle Kapitel überarbeitet, die Texte und die Grafiken. Das einführende Kapitel zu Ereignisgesteuerten Prozessketten wurde umgestellt, sodass es hoffentlich den Zugang zu die-

Vorwort

VII

ser Beschreibungsmethode noch mehr vereinfacht. Außerdem wurden weitere Beispiele zu Ereignisgesteuerten Prozessketten integriert. Neu aufgenommen wurde ein Kapitel zur objektorientierte Geschäftsprozessmodellierung mit der UML (mit einer Einführung in den objektorientierten Ansatz). Es soll deutlich machen, wie weit die Urheber der UML ihrem Anspruch, auch Geschäftsprozesse zu modellieren, bereits nachkommen.

Geschäftsprozessmodellierung mit der UML

VIII

Vorwort

Vorwort zur ersten Auflage (gekürzt)

DV-Durchdringung

Unternehmensmodellierung

Die immer weiter und tiefer gehende Durchdringung unserer Unternehmen und sonstigen Organisationen mit Informationstechnologien ist das prägende Merkmal unserer Zeit. Vielleicht wird diese Entwicklung den zurückblickenden Historikern eines Tages viel wichtiger erscheinen als vieles, was uns heute beschäftigt. Der arbeitende Mensch wird zunehmend von einem im Rahmen der gesetzten Regeln autonom handelnden Individuum zum Partner einer die Abläufe kontrollierenden Software. Die Herrschaft der Mechanisierung (vgl. >Giedion 1982@) hat die Büros erreicht. Basis dieser Entwicklung ist die schon lange bekannte Tatsache, dass auch in den Büros die meisten Tätigkeiten Abschnitte standardisierter Abläufe sind und dass die Datenverarbeitung inzwischen so weit ist, diese standardisierten Abläufe (im weiteren werden sie Geschäftsprozesse genannt) umfassend nachzubilden. Gründe für diese Entwicklung gibt es viele. Der wichtigste ist, dass heutige Datenverarbeitungsanlagen nun mal wesentlich schneller Informationen speichern, verwalten und weitergeben können als Menschen, dass dies wesentlicher Bestandteil von Geschäftsprozessen ist und sich somit ein riesiges Einsparpotenzial auftut. Dabei ist das, was wir heute erleben, nur ein Zwischenschritt. Endpunkt dieser Entwicklung wird ein Zustand sein, der die Personalkosten in den Büros zu einem ebenso marginalen Posten werden lässt wie in der Produktion. Wer, wie der Verfasser, diese Entwicklung in einigen Unternehmen schon seit mehr als 25 Jahren beobachtet, muss aber auch von der bisherigen Entwicklung beeindruckt sein, denn wir haben heute bereits einen Stand erreicht, bei dem es nicht mehr um die weitere Ausdehnung geht (es sind bereits alle Bereiche durchdrungen), sondern um die Vertiefung der DV-Durchdringung, darum, die Geschäftsprozesse immer detaillierter mithilfe von Informationstechnologien abzuwickeln. Eine solche umfassende DV-Durchdringung kann nur erfolgen, wenn vorher eine ausreichend formale1 Fassung der Strukturen und Abläufe in den Unternehmen erfolgt, sprich, wenn die Unternehmensrealität in all ih1

Für diesen Text wird die Unterscheidung von formal und formell benötigt. Formal im Sinne von formaler Sprache (hier: Beschreibung der Strukturen und Abläufe in einem Unternehmen mit einem entsprechenden abstrahierenden Beschreibungsinstrument), formell im Sinne von offiziell, als Gegensatz von informell (hier: die vorgesehenen, den Regeln und Vorschriften entsprechenden Strukturen und Abläufe in Unternehmen).

Vorwort

IX

ren formellen Aspekten modelliert wird. Dieses zentrale Thema der Praxis (der Gestaltung der Informationstechnologien) hat eine ebenso große Bedeutung für die Theoriediskussion in der Wirtschaftsinformatik und ist mittlerweile in vielen Aspekten auch schon intensiv diskutiert2. Dieses Buch hat zwei Schwerpunkte, die aus diesem Bereich der Unternehmensmodellierung stammen. Da ist zum einen die intensive Auseinandersetzung mit Ereignisgesteuerten Prozessketten. Sie werden in diesem Buch als Instrument zur Beschreibung von Geschäftsprozessen ernst genommen und gründlich hinterfragt. Der zweite Schwerpunkt ist ein Blick auf die derzeitigen Techniken zur Modellierung der Unternehmensrealität, wie sie für Betriebswirtschaftliche Standardsoftware notwendig ist. Beide Schwerpunkte werden praxisorientiert und ohne unnötigen formalen Ballast dargestellt. Dem Verfasser halfen hier zahlreiche Kontakte zur unternehmerischen Praxis und die Möglichkeit, Modellierungsprozesse in Unternehmen zu begleiten. Damit wurde es möglich, eine semi-formale Methode wie die Ereignisgesteuerten Prozessketten quasi empirisch zu erkunden mit der Fragestellung „Wie wird diese Methode in der Praxis eingesetzt, welche Probleme gibt es dabei?“ Das Buch soll zum einen all denen Hilfestellung geben, die mit der Einführung und Nutzung Betriebswirtschaftlicher Standardsoftware befasst sind. Zum anderen soll es zu einem tieferen Verständnis einer Entwicklung beitragen, die unser aller Leben prägt und noch viel mehr prägen wird.

2

Zentral in den Arbeiten von Scheer zu einem Gesamtkonzept integrierter unternehmensweiter Informationssysteme, dem ARIS-Konzept (vgl. >Scheer 1997@, >Scheer 1998a@, >Scheer 1998b@ sowie Abschnitt 2.5), aber auch in Arbeiten, deren Schwerpunkt im Bereich des Business Engineering liegt (vgl. Abschnitt 2.2).

Schwerpunkte

Inhaltsverzeichnis

1

2

EINLEITUNG

1

1.1 1.2 1.3

1 2 2

GESCHÄFTSPROZESSE 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10

3

Definitionen und Begriffe Kernprozesse Eigenschaften und Komponenten Geschäftsprozesse über Unternehmensgrenzen Ziele der Geschäftsprozessmodellierung Business Process Reengineering Prozessorientierung Unschärfen Beispiele – Angebotserstellung und Auftragsabwicklung Das ARIS-Konzept

5 5 11 14 16 17 18 19 22 24 27

BETRIEBSWIRTSCHAFTLICHE STANDARDSOFTWARE / ERP-SOFTWARE 33 3.1 3.2 3.3 3.4 3.5 3.6

4

Immer mehr, immer tiefer Modelle Aufbau der Arbeit

Definition und Abgrenzung Begleiterscheinungen Überwindung der „Lücke“ Einführung Leidensdruck - Warum überhaupt ? Perspektiven

EREIGNISGESTEUERTE PROZESSKETTEN GRUNDLAGEN 4.1 4.2

Einführung Elemente 4.2.1 Funktionen 4.2.2 Ereignisse 4.2.3 Organisationseinheiten 4.2.4 Informationsobjekte 4.2.5 Operatoren und Kontrollfluss

33 40 46 48 53 55 59 59 60 60 62 63 64 66

XII

Inhaltsverzeichnis

4.3

4.4

4.5 4.6 4.7 4.8 5

6

7

Aufbau 67 4.3.1 Funktionen 68 4.3.2 Varianten 80 4.3.3 Zusammenfassung der Syntaxregeln 80 4.3.4 Zusätzliche Operatoren 81 Verknüpfungsbeispiele 81 4.4.1 Ereignisverknüpfung mit auslösenden Ereignissen 83 4.4.2 Ereignisverknüpfung mit erzeugten Ereignissen 89 4.4.3 Funktionsverknüpfung mit auslösenden Ereignissen 94 4.4.4 Funktionsverknüpfung mit erzeugten Ereignissen 100 Mehrere Operatoren im Kreis 105 Zusammenführen des Kontrollflusses 106 Aufteilung großer Geschäftsprozesse 110 Erste Beispiele 113

EREIGNISGESTEUERTE PROZESSKETTEN VERTIEFUNG

125

5.1 5.2 5.3 5.4 5.5 5.6

125 130 131 135 136 138

Rückschleifen Repetitive Handlungen Warten Einfügen der zeitlichen Dimension Keine falschen Schlussereignisse Genauigkeit erhöhen

BEISPIELE

143

6.1 6.2 6.3 6.4

Kundenanfrage und Angebotserstellung Auftragsabwicklung Angebotserstellung im Anlagenbau Vorbereitung Auftragsabwicklung

144 164 210 218

EREIGNISGESTEUERTE PROZESSKETTEN BEWÄLTIGEN

229

7.1

7.2

Situationen und ihre Bewältigung 7.1.1 Aufeinanderwirken von Funktionen 7.1.2 Ebenen – Detaillierungsgrad - Kapselung 7.1.3 Leerzweige 7.1.4 Optionale Ereignisse 7.1.5 Komplexitätsbewältigung - Vervielfachung vs. Schlankheit 7.1.6 Struktur vs. Daten 7.1.7 Intern/Extern und Warten Einschätzung der „Methode EPK“ 7.2.1 Grenzen der Prozessorientierung 7.2.2 Gefahren der Prozessorientierung 7.2.3 Möglichkeiten und Grenzen von EPKs

229 229 231 232 233 235 239 240 241 241 242 243

Inhaltsverzeichnis

8

BEISPIEL FÜR EINE UNTERNEHMENSMODELLIERUNG 8.1 8.2

8.3

9

Das Konzept und die Elemente Ereignisgesteuerte Prozessketten 8.2.1 Basis-EPKs 8.2.2 Szenarien 8.2.3 Wertschöpfungsketten Informationsstrukturen 8.3.1 Grundkonzept 8.3.2 SAP-SERM 8.3.3 Konkrete Beispiele mit Erläuterungen 8.3.4 Business Objekte

OBJEKTORIENTIERTE MODELLIERUNG - GRUNDLAGEN 9.1

9.2

Einleitung 9.1.1 Objektorientierung 9.1.2 Geschäftsprozesse – ja/nein 9.1.3 Grundkonzepte - Berührung Realwelt und Modell 9.1.4 Struktur und Verhalten in Abbildungen Modellierung von Strukturen 9.2.1 Statische Aspekte I – Objekte und Objektklassen 9.2.2 Statische Aspekte II - Objekte in Beziehung setzen 9.2.3 Dynamische Aspekte

10 OBJEKTORIENTIERTE MODELLIERUNG VON VERHALTEN UND ABLÄUFEN 10.1 Einführung 10.2 Verhalten 10.2.1 Starke Verknüpfung von Objekten und Verhalten 10.2.2 Executing und Emergent Behavior 10.3 Konstrukte für die Verhaltensmodellierung 10.4 Basiskonzepte für die Verhaltensmodellierung 10.4.1 Token 10.4.2 Classifier 11 AKTIONEN 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 11.9

Definition Grafische Darstellung Aktionen im Kontrollfluss Pins an Aktionen Start einer Aktion Primitive Actions Aktionen und Variable Subordinate Units – zusammengefasste Aktionen Hinweise zur Metamodellierung

XIII

247 247 252 252 264 274 280 280 282 294 302 309 309 309 310 310 312 312 312 325 344 349 349 351 352 353 354 355 355 357 361 361 362 363 364 365 365 366 366 367

XIV

Inhaltsverzeichnis

11.10 Zusammenfassung 11.11 Aggregation - in Geschäftsprozessen und Systemen 12 AKTIVITÄTEN 12.1 12.2 12.3 12.4 12.5

Einleitung Definition Einführendes Beispiel Überblick - Knoten und Kanten in Aktivitätsdiagrammen Aktivitätsknoten 12.5.1 Aktionsknoten 12.5.2 Objektknoten 12.6 Aktivitätskanten 12.6.1 Kanten für den Kontrollfluss 12.6.2 Kanten für den Objektfluss - Objektflusskanten 12.6.3 Objektflüsse und Pins 12.6.4 Abgrenzung zwischen den Kantenarten 12.7 Strukturierte Aktivitätsknoten 12.8 Kontrollknoten 12.8.1 DecisionNode 12.8.2 Merge Node 12.8.3 ForkNode 12.8.4 JoinNode 12.8.5 Startknoten 12.8.6 Schlussknoten - ActivityFinal und FlowFinal 12.9 Aufruf von Aktivitäten 12.10 Aktivitäten aufteilen – Träger zuordnen 12.11 Die zeitliche Dimension und die Ereignisse 12.12 Kontrollfluss vertieft 12.12.1 Verhalten von Aktionen 12.12.2 Das streaming-Konzept 12.12.3 Mehrfach aktiv? 12.12.4 Beziehungen zwischen Flüssen 12.12.5 Token 12.13 Metamodellierung - Aktivitäten als Klassen 12.14 Beispiele 12.14.1 Fehlerbehandlung 12.14.2 Lagerentnahme 12.14.3 Personaleinstellung 12.14.4 Auftragsbearbeitung 12.14.5 Design Part und Provide Required Part 12.14.6 Problembehandlung 12.14.7 Auslagenerstattung 12.14.8 Vorschlagswesen

367 367 371 371 371 373 374 375 375 375 378 378 380 381 389 390 392 393 394 396 397 400 401 405 405 408 412 412 414 414 415 415 417 417 418 419 419 420 422 424 425 426

Inhaltsverzeichnis

13 SEQUENZEN, SEQUENZDIAGRAMME 13.1 13.2 13.3 13.4 13.5 13.6 13.7 13.8 13.9 13.10 13.11 13.12 13.13 13.14 13.15 13.16

Einführung Grundstruktur Einführendes Beispiel Grundbegriffe Lifelines Nachrichten zwischen Lifelines Strukturieren durch CombinedFragments Gates und InteractionFragments ExecutionOccurence Interaktionen InteractionConstraint InteractionOccurrence InteractionOperand StateInvariant Stop Beispiele zu Sequenzdiagrammen

14 ANWENDUNGSFÄLLE 14.1 Definition 14.2 Einführendes Beispiel 14.3 Anwendungsfälle 14.3.1 Extend-Beziehung 14.3.2 Include - Beziehung 14.4 Akteure 14.5 Beispiel 14.6 Einschätzung 15 ZUSTANDSAUTOMATEN 15.1 Einleitung 15.2 Einführende Beispiele 15.3 Zustände 15.3.1 Definition 15.3.2 Zustände in Zustandsautomaten 15.3.3 Pseudozustände 15.3.4 Transitionen zu Zuständen 15.3.5 Zustandsautomaten im Zustand 15.3.6 Die Semantik von Zuständen 15.3.7 Grafische Darstellung von Zuständen 15.4 Transitionen 15.5 Ereignisraum und Ereignisverarbeitung 15.6 Protokollzustandsautomaten 15.7 Zustandsautomaten und Prozessmodellierung

XV

429 429 430 431 432 434 434 436 441 442 443 448 448 450 451 451 451 455 455 457 457 459 461 461 462 463 469 469 471 472 472 473 475 481 482 487 492 496 498 499 501

XVI

Inhaltsverzeichnis

16 GESAMTEINSCHÄTZUNG 16.1 Kontrollflusskonzept 16.2 Verhaltensbegriff 16.3 Wohltuend abgehoben

503 503 504 505

17 GLOSSAR

507

18 INDEX

511

19 LITERATUR

529

Abkürzungsverzeichnis

AE AV B2B B2C BPR CIS DV EDV EE eEPK EPK ER ERM

Auslösende Ereignisse Abteilung Arbeitsvorbereitung Business to Business Business to Customer Business Process Reengineering Computergestütztes Informationssystem Datenverarbeitung Elektronische Datenverarbeitung Erzeugte Ereignisse erweiterte Ereignisgesteuerte Prozesskette (einfache) Ereignisgesteuerte Prozesskette Entity Relationship Entity Relationship – Modell bzw. Entity Relationship – Modellierung GP Geschäftsprozess IS Informationssystem ODER Logischer Operator ODER OMG Object Management Group PC Personal Computer PPS Produktionsplanungssystem QM Kurzbezeichnung für das Modul Qualitätsmanagement in SAP R/3 SAP-SERM SAP Strukturiertes Entity Relationship – Modell bzw. SAP Strukturierte Entity Relationship - Modellierung SD Kurzbezeichnung für das Modul Vertrieb (Sales and Distribution) in SAP R/3 SERM Strukturiertes Entity Relationship – Modell bzw. Strukturierte Entity Relationship – Modellierung UML Unified Modeling Language UND Logischer Operator UND VKD Vorgangskettendiagramm vs. versus (gegen) WSK Wertschöpfungsketten XODER Logischer Operator exklusives ODER

1 Einleitung

1.1

Immer mehr, immer tiefer

Wir haben es alle bemerkt, die einen gezwungenermaßen, die anderen leidvoll, andere vielleicht auch lustvoll: die Durchdringung der Unternehmen mit Informationstechnologien hat in den letzten 30 Jahren ständig zugenommen und in den letzten Jahren eine neue Qualität erreicht. Schon lange erfolgte in unseren Unternehmen und darüber hinaus in Organisationen aller Art der Schritt von den Informationssystemen, die es bei organisiertem gemeinsamem Handeln immer geben muss, zu den Computergestützten Informationssystemen. Selten hat jedoch eine Neuerung so viele Umwälzungen mit sich gebracht, wie die, die wir Betriebswirtschaftliche Standardsoftware, ERPSoftware, Unternehmensweite Komplettlösung oder auch einfach Standardlösung nennen. Eine preiswerte „Software von der Stange“, die viele Unternehmen auf einen höheren Stand der Informationstechnologie hebt oder ihnen zumindest die immensen Kosten des Weiterbetreibens der alten Programme erspart. Dieses Phänomen ist schon erstaunlich, soll doch diese Software idealtypisch einen großen Teil der Unternehmensaktivitäten in immer höherer Detaillierung abdecken und geht sie doch implizit davon aus, dass es eine Software für die Strukturen und Abläufe in vielen verschiedenen Unternehmen geben kann. Sie ist also Standardsoftware (vgl. Kapitel 3) und sie deckt das ab, was im Folgenden, etwas ungenau, als betriebswirtschaftlicher oder auch kaufmännischer Bereich eines Unternehmens bezeichnet wird (vgl. hierzu Abschnitt 3.1 „Genauere Abgrenzung“), weshalb sie Betriebswirtschaftliche Standardsoftware (BSSW) genannt wird. Zurück zu dem Anspruch dieser Software, für viele (wenn nicht alle) Unternehmen geeignet zu sein. Er bleibt erstaunlich, denn betrachten wir, über eine größere Zahl von Unternehmen hinweg, einen bestimmten betriebswirtschaftlichen Anwendungsbereich, z.B. die Finanzbuchhaltung, die Auftragsabwicklung, die Kontaktbearbeitung oder das Personalwesen, stellen wir fest, dass er in den einzelnen Unternehmen natürlich sehr unterschiedlich gestaltet ist. Dies gilt selbst für Bereiche wie die Finanzbuchhaltung, die durch Vorschriften, gesetzliche Regelungen und die betriebswirtschaftliche Theorie vorgeprägt sind, viel mehr aber für Gebiete wie Materialwirtschaft, Produktionsplanung, usw., die durch das Produkt,

Von IS zu CIS

Eine für Alles? Eine für Alle?

Namensgebung

Vielfalt vs. „Einfalt“

2

1 Einleitung

den Produktionsprozess, die jeweilige Firmenkultur und andere Dinge geprägt und daher sehr unterschiedlich sind.

1.2 Modellierung für Komplexitätsreduzierung

Modellierung für Programmierung

Es gibt zwei Gründe für die Modellbildung, für die Wahrnehmung der Unternehmensrealität über modellhafte Vorstellungen3. Der erste liegt in der immer mehr gestiegenen Komplexität der Unternehmensrealität. Diese führte dazu, dass sie gar nicht mehr beherrschbar ist ohne systematische Wahrnehmung, ohne Durchdringung mit einem Wahrnehmungswerkzeug. Der zweite entsteht durch die Notwendigkeit der Softwareerstellung. Software basiert immer auf einem Modell der Realität, auf verschiedenen Ebenen. D.h., vor der Programmierung ist die Modellierungsarbeit zu leisten. Angefangen bei der elementaren Systemanalyse für die eingesetzten Systeme über die Geschäftsprozessmodellierung bis hin zur Unternehmensmodellierung, wo das Unternehmen als Ganzes (mit seiner Umwelt) ins Auge gefasst wird. Modellierung bedeutet immer Abstraktion, d.h. Konzentration auf das, was zum jeweiligen Zeitpunkt als wesentlich erachtet wird. Insofern ist (natürlich) die Modellierung der Unternehmensrealität zeitbezogen. Derzeit sieht dies so aus, dass Geschäftsprozesse im Mittelpunkt dieser Anstrengungen stehen, ergänzt um das eingeführte ältere Instrumentarium.

1.3 Kapitel 2: Geschäftsprozesse

Kapitel 3: Betriebswirtschaftliche Standardsoftware

Modelle

Aufbau der Arbeit

In Kapitel 2 wird das Konzept der Geschäftsprozesse (business processes) diskutiert. Mit ihm werden die betrieblichen Abläufe formal beschrieben. Damit ist dann nicht nur die Analyse der Geschäftsprozesse eines Unternehmens möglich, sondern auch der direkte Vergleich der in der Software realisierten Abläufe mit den realen betrieblichen. In diesem Kapitel wird auch kurz die wichtigste theoretische Grundsteinlegung für Integrierte Informationssysteme diskutiert, das ARISKonzept von Scheer. Es zeigt den Rahmen auf, in dem sich diese Diskussion heute, in der Nachfolge der vorwiegend organisationstheoretischen Diskussionen (beispielhaft: >Mertens 1995@, >Mertens und Griese 1993@) bewegt. Die softwaretechnische Äußerung dieses Phänomens, Betriebswirtschaftliche Standardsoftware, wird in Kapitel 3 definiert und diskutiert. Sie baut auf dem Geschäftsprozessgedanken auf, ist also in vollem Umfang prozessorientiert und beruht auf einem Unternehmensmodell, das im Kern von Geschäftsprozessen ausgeht. 3

Der dritte sei hier nicht thematisiert. Er betrifft die grundsätzliche Struktur der menschlichen Wahrnehmung, die ohne Modellbildung im elementaren Sinn gar nicht auskommt.

1.3 Aufbau der Arbeit

3

In den Kapiteln 4 bis 7 werden erweiterte Ereignisgesteuerte Prozessketten (EPK) intensiv diskutiert und hinterfragt. Zuerst wird in zwei Kapiteln eine Einführung gegeben, danach werden zwei ausführliche aus der Praxis stammende Beispiele vorgestellt. Abgeschlossen wird dieser Teil des Buches mit einer Betrachtung spezieller Modellierungssituationen und einem Kapitel, das eine Einschätzung dieser Methode und seiner Grundlagen gibt. Grundsätzlich ist der Verfasser davon überzeugt, dass diese Modellierungstechnik eine zentrale Rolle bei der Modellierung der Unternehmensstrukturen und –abläufe einnehmen wird. Dass sie dies partiell bereits heute tut, zeigt Kapital 8, wo das SAPKonzept für die Unternehmensmodellierung vorgestellt wird. Dabei werden alle Modellierungsobjekte dieses Ansatzes kurz vorgestellt. Vertieft wird auf die SAP-Notation für EPKs eingegangen und auf die spezifische Art der Datenmodellierung, die SAP verwendet. Glücklicherweise verändern sich Modellierungsmethoden nicht ganz so schnell wie Modellierungskonzepte. So ist zwar das in diesem Kapitel vorgestellte Modellierungskonzept verändert, zumindest wird es so den Kunden nicht mehr offeriert, die Methoden sind es aber nicht, so dass sich die Betrachtung weiterhin lohnt. In den folgenden Kapiteln wird die objektorientierte Theorie vorgestellt. Zuerst die Grundlagen, die der Modellierung der statischen Aspekte eines Anwendungsbereichs dienen. Dann in mehreren Kapiteln die Konstrukte und Konzepte, die von der objektorientierten Theorie (in der Ausprägung der UML) für die Modellierung der dynamischen Aspekte (Verhalten, Prozesse) angeboten werden. Bei diesen wird dann jeweils gefragt, ob sie tatsächlich auch für die Geschäftsprozessmodellierung geeignet sind.

EPK-Kapitel

SAP-Kapitel

Objektorientierte Geschäftsprozessmodellierung

2 Geschäftsprozesse

2.1

Definitionen und Begriffe

Geschäftsprozesse sind die zusammenhängenden Folgen von Tätigkeiten, die in Unternehmen zur Erreichung der Unternehmens- bzw. Organisationsziele erledigt werden. Diese einführende und noch unpräzise Definition wird gleich genauer gefasst. Schon immer wurden, wenn es um Effizienzsteigerung bzw. Einsparungen ging, die in den Unternehmen zu leistenden Tätigkeiten, Aufgaben und Arbeitsabläufe untersucht. Nicht zuletzt beruhen die klassischen Ansätze zur Strukturierung der Unternehmensrealität in der Organisationslehre, die zu den Konzepten der (Æ)Aufbau- und (Æ)Ablauforganisation4 geführt haben, auch darauf. Im Vordergrund standen da allerdings meist einzelne Tätigkeiten und kurze Arbeitsabläufe, die unter dem Gesichtspunkt der effizienteren Abwicklung bzw. Aufteilung untersucht wurden. Mit dem Konzept des Geschäftsprozesses verändert sich die Perspektive. Jetzt stehen längere zusammenhängende Folgen von Tätigkeiten, die zur Erledigung einer größeren Aufgabe nötig sind, im Mittelpunkt. Unter Umständen sogar eine Folge von Tätigkeiten, die in Bezug auf das betrachtetet Unternehmen abgeschlossen ist. Während früher der Ausgangspunkt die einzelne Tätigkeit und ihr Stelleninhaber (ÆStellen) war und die Einbettung dieser Tätigkeiten in die Abläufe, ist jetzt der gesamte (oder ein längerer) Ablauf der Ausgangspunkt, bei dem die klassischen durch die Organisationsstruktur gegebenen Grenzen erst mal keine Rolle spielen. Die weitere Diskussion bedarf einiger Grundbegriffe aus der Organisationslehre. Es wurde oben schon deutlich, dass Geschäftsprozesse mit den Tätigkeiten zu tun haben, die in Unternehmen ausgeführt werden. Diese sind in der Regel als Aufgaben definiert, die auf unterschiedlichen Ebenen betrachtet werden können. Sozusagen die unterste Ebene stellen die Elementaraufgaben dar, die Bullinger/Fähnrich als „... entweder nicht weiter zerlegbare oder auf der betreffenden Beschreibungsebene nicht weiter zerlegte Aufgaben“ bezeichnen [Bullinger und Fähnrich 1997, S. 41]. 4

Die Pfeile geben hier und im übrigen Buch an, dass der Begriff im Glossar erläutert wird.

Konzept Geschäftsprozess

Grundbegriffe

6

2 Geschäftsprozesse

Mehrere solche Elementaraufgaben werden dann in einer Aufgabe zusammengefasst. Diese kann so wie von Österle definiert werden, dessen Definition auch auf die selbstverständliche Erwartung eines Ergebnisses und auf die Durchführbarkeit durch Menschen oder Maschinen hinweist: „Eine Aufgabe ist eine betriebliche Funktion mit einem bestimmbaren Ergebnis. Sie wird von Menschen und/oder Maschinen ausgeführt.“ [Österle 1995, S. 45] Aufgaben: teilbar und zusammenfassbar

Subjektiver Faktor in der Prozessmodellierung

Subjektive Länge

Sequenzielle Aufgabenfolge

So definierte Aufgaben können ebenfalls zusammengefasst werden und dies auf mehreren Stufen, u.U. bis zu der Ebene, wo sich der gesamte Unternehmenszweck in einer einzigen Aufgabe findet (z.B. „Gewinn erzielen“). Damit wird deutlich, was dann bei der konkreten Modellierung von Geschäftsprozessen eine wichtige Rolle spielt: Die in Geschäftsprozessen zu leistenden Aufgaben können auf unterschiedlichen Aggregationsniveaus betrachtet werden. Man kann Aufgaben also aufteilen5) oder zusammenfassen. Für die Prozessmodellierung hat dies die Konsequenz, dass die Ebene, auf der die Aufgaben (und damit dann auch die Tätigkeiten) betrachtet werden, ein subjektiver Faktor ist, der durch die Modellierer oder auch durch den Zweck der Modellierung festgelegt werden kann. Darauf wird in den entsprechenden Abschnitten immer wieder eingegangen. Dieselbe Subjektivität liegt im Übrigen bezüglich der Länge von Geschäftsprozessen vor. Man kann z.B. die Auftragsabwicklung als Ganzes, als einen Geschäftsprozess betrachten (wie in Abschnitt 6.2 dieses Buches) oder seine einzelnen Abschnitte, also z.B. die Angebotserstellung, die Auftragsbearbeitung, die Materialbeschaffung, die Produktion, die Kalkulation, die Auslieferung, usw. Auch hier erfolgt die Festlegung nur durch die Modellierer oder den Zweck der Modellierung. Der erste Schritt von einzelnen Aufgaben zu einer sequenziellen Folge von Aufgaben wird mit der Definition von Vorgängen gemacht. Mit Bullinger/Fähnrich sind Vorgänge „Abfolgen von Tätigkeiten, die zur Realisierung von Aufgaben ausgeführt werden.“ [Bullinger und Fähnrich 1997, S. 19]

Definition: Funktionen

In der Prozessdiskussion wie auch in der konkreten Prozessmodellierung wird mit Funktion ein weiterer Begriff benutzt, der weitgehend mit dem Aufgabenbegriff übereinstimmt, der aber stärker auf die Modellierungsumgebung Bezug nimmt. Mertens versteht unter einer Funktion eine Tätigkeit „..., die auf die Zustands- oder Lageveränderung eines Objektes ohne Raum- und Zeitbezug abzielt. Eine Funktionsbezeichnung besteht aus zwei Komponenten, einem Verb 5

Sinnvoll bis zu den oben eingeführten Elementaraufgaben. Darunter liegt noch die „tayloristische Ebene“ der Handhabungen, die zu betrachten hier keinen Sinn macht.

2.1 Definitionen und Begriffe

7

(Verrichtung) und einem Substantiv (Objekt), auf das sich dieses Verb bezieht (z.B. „Bestellgrenze ermitteln“).“ [Mertens 1995, S. 22f] Mit Objekten sind hier betriebswirtschaftlich relevante Objekte bzw. Geschäftsobjekte (Business Objects) gemeint. Dieser Objektbegriff stimmt weitgehend (bei den meisten Autoren allerdings unausgesprochen bzw. unbewusst) mit dem allgemeinen Objektbegriff der objektorientierten Analyse überein. Es handelt sich immer um Informationsträger (z.B. eine Rechnung) mit Eigenschaften (Attributen) und einem Verhalten (bzw. zulässigen Veränderungen). Z.B. um Rechnungen mit Attributen wie Rechnungsnummer, Rechnungsdatum, Rechnungsempfänger, usw., die bezahlt oder storniert werden können. Doch nun zur Definition von Geschäftsprozessen. In der Literatur wird der Begriff intensiv diskutiert (vgl. beispielhaft [Keller und Teufel 1997, S. 153ff], >Hess 1996, S. 9ff@, >Becker und Vossen 1996@ und die dort angegebenen weiteren Verweise und die folgenden Zitate). Hess definiert, ausgehend von einer systemorientierten Organisationslehre und der Zerlegung einer Organisation in die Subsysteme Aufbauorganisation, Ablauforganisation und Informationssystem einen Prozess

Definition und Diskussion

„ ... als ein Subsystem der Ablauforganisation, dessen Elemente Aufgaben, Aufgabenträger und Sachmittel und dessen Beziehungen die Ablaufbeziehungen zwischen diesen Elementen sind.“ >Hess 1996, S. 13@ In seiner umfassenden Darstellung zahlreicher Methoden des Business Reengineering gibt er bei fast jeder die jeweils benutzte Prozessdefinition an. Eine Aktualisierung dieser Übersicht findet sich in >Hess und Brecht 1996@. Hier finden sich auch zahlreiche Hinweise auf die bei den Beratungsunternehmen benutzen Typen von Geschäftsprozessen. Zahlreiche Definitionen zu Geschäftsprozessen führt [Rump 1999, S. 18f] an. Das Gemeinsame aller Definitionen ist: x x x x x x

Geschäftsprozesse haben ein Ziel (oder auch mehrere), das sich aus den Unternehmenszielen ableitet. Die Gesamtaufgabe eines Geschäftsprozesses kann in Teilaufgaben zerlegt werden (im Extremfall kann ein Geschäftsprozess auch aus nur einer Aufgabe bestehen). Die Aufgaben werden von Aufgabenträgern wahrgenommen, die Inhaber von (Æ)Stellen sind, die wiederum in Organisationseinheiten gruppiert sind. Die Aufgaben werden entweder manuell, teil-automatisiert oder automatisiert erfüllt. Ein Geschäftsprozess liegt oft quer zur klassischen Aufbauorganisation, d.h. er tangiert u.U. mehrere Abteilungen. Für die Erfüllung der Aufgaben werden die Unternehmensressourcen benötigt.

Definition: Geschäftsprozesse

8

x

2 Geschäftsprozesse

Geschäftsprozesse benötigen zu ihrer Realisierung Informationsträger aller Art.

Nicht sinnvoll sind gelegentlich in der Literatur anzutreffende Definitionsmerkmale, die eher Wünsche an erfolgreiche Geschäftsprozesse formulieren und weniger zur Definition taugen, wie z.B. „sie erzeugen für den Kunden ein Ergebnis von Wert.“ Rump selbst definiert wie folgt: „Ein Geschäftsprozess ist eine zeitlich und sachlogisch abhängige Menge von Unternehmensaktivitäten, die ein bestimmtes, unternehmensrelevantes Ziel verfolgen und zur Bearbeitung auf Unternehmensressourcen zurückgreifen.“ [Rump 1999, S. 19] Keller und Teufel berücksichtigen neben den externen auch die internen Kunden. Für sie ... „ ... beschreibt ein Geschäftsprozess alle Aktivitäten, mit deren Durchführung eine angestrebte Leistung bzw. SollLeistung durch Aufgabenträger erstellt wird, die an externe Kunden (Hauptprozesse) oder interne Kunden (Serviceprozesse) übergeben wird und für diesen einen Wert darstellt.“ [Keller und Teufel 1997, S. 153]6 Mertens definiert, aufbauend auf seinem oben eingeführten Funktionsbegriff, Prozesse als eine Abfolge von Funktionen: „Eng verwandt mit dem Begriff Funktion ist der Begriff Prozess. Ein Prozess entsteht aus einer Folge von einzelnen Funktionen (Funktionsablauf) und weist einen definierten Anfangspunkt (Auslöser des Prozesses) sowie Endpunkt (Endzustand) auf.“ [Mertens 1995, S. 24] Ganz ähnlich Becker/Vossen7. Sie definieren einen Geschäftsprozess als "... die inhaltlich abgeschlossene zeitliche und sachlogische Abfolge von Funktionen, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objekts notwendig sind." [Becker und Vossen 1996, S. 19] Der Objektbegriff deckt sich mit dem Obigen, allerdings gehen diese Autoren von einem (betriebswirtschaftlich relevanten) Objekt aus, das den Prozess prägt. Auch in der Diskussion um Business Process Reengineering wird auf diese Weise definiert. Hammer und Champy:

6 7

Man beachte die hier gleich mit erledigte Unterscheidung von Haupt- und Serviceprozessen (vgl. auch den nächsten Abschnitt). Becker/Vossen unterscheiden im Übrigen zwischen Prozess und Geschäftsprozess (vgl. [Becker und Vossen 1996, S. 18f]).

2.1 Definitionen und Begriffe

9

„Wir definieren einen Unternehmensprozess als Bündel von Aktivitäten, für das ein oder mehrere unterschiedliche Inputs benötigt werden und das für den Kunden ein Ergebnis von Wert erzeugt.“ [Hammer und Champy 1995, S. 52] Für die Zwecke dieser Arbeit sollen nun Geschäftsprozesse in Unternehmen wie folgt definiert werden: Ein Geschäftsprozess besteht aus einer zusammenhängenden abgeschlossenen Folge von Tätigkeiten, die zur Erfüllung einer betrieblichen Aufgabe notwendig sind. Die Tätigkeiten werden von Aufgabenträgern in organisatorischen Einheiten unter Nutzung der benötigten Produktionsfaktoren geleistet. Unterstützt wird die Abwicklung der Geschäftsprozesse durch das Informations- und Kommunikationssystem IKS des Unternehmens. Geschäftsprozesse leisten somit die Transformation von beschafften Produktionsfaktoren in verkaufte Produkte bzw. Dienstleistungen (vgl. für diesen produktionstheoretischen Ansatz >Porter 1992@). In ihrem Zusammenhang beschreiben die Geschäftsprozesse die (Æ)Wertschöpfungskette des Unternehmens (vgl. hierzu auch >Ott 1995, S. 82@). Der Prozessbegriff bedeutet damit auch die Abwendung von einer zu sehr durch die Arbeitsteilung geprägten Wahrnehmung. So auch Hammer, der dies betont, wenn er nach seiner Definition eines Prozesses als einem

Definition

Arbeitsteilung und Prozess

„... Bündel zusammengehöriger Aktivitäten, die in ihrer Gesamtheit für den Kunden ein Ergebnis von Wert erzeugen“ auf die Industrielle Revolution verweist, in der man sich „... von den Prozessen abgewandt, sie in spezialisierte Arbeitsschritte zerlegt und sich dann voll und ganz auf diese Einzelaufgaben konzentriert“ hat [Hammer 1997, S. 12f]. Die Nutzung des Begriffs Geschäftsprozess geht damit von der Vorstellung einer sequenziellen Struktur der Abläufe in Unternehmen aus (so auch >Mischak 1997, S. 5@ und - unausgesprochen - die meisten einschlägigen Autoren). Aber nicht nur. Wesentlich ist auch die oben angesprochene abgeschlossene Folge von Tätigkeiten, also nicht das Schreiben des Angebots, die Erstellung der Kalkulation oder die Klärung offener Fragen mit dem Kunden, sondern z.B. die Angebotserstellung als Ganzes, weil dadurch die damit verbundene neue Sichtweise auf das Unternehmensgeschehen verdeutlicht wird. Rump unterscheidet in [Rump 1999, S. 19f] zusätzlich Geschäftsprozess von Geschäftsprozessinstanz und Geschäftsprozessschema, wohl in Anlehnung an objektorientierte Modellierungskonzepte. Dabei steht dann Geschäftsprozessinstanz für eine konkrete Realisierung eines Geschäftsprozesses und Geschäftsprozessschema meint das Modell, das von einem

Sequenzielle Grundstruktur

Geschäftsprozess, Instanz und Schema

10

Beispiele für Geschäftsprozesse

2 Geschäftsprozesse

Geschäftsprozess erstellt wurde (wie hier unten z.B. mit Ereignisgesteuerten Prozessketten) (vgl. [Rump 1999, S. 20], insbesondere Abbildung 2.1). Beispiele für Geschäftsprozesse sind Angebotserstellung, Auftragsvergabe, Beschaffung, Mahnwesen

x x x x

und, ein meist sehr langer Geschäftsprozess (vgl. das kurze textliche Beispiel in Abschnitt 2.4 und das ausführliche EPK-Beispiel in Abschnitt 6.2), x

die Auftragsabwicklung (vom Eintreffen des Auftrags beim Unternehmen bis zur Auslieferung der Ware beim Kunden).

Selbstverständlich können auch kurze Geschäftsprozesse gefunden werden, z.B. Kundenbefragung, Personaleinstellung, Zahlungsabwicklung, Fakturierung

x x x x oder x Integrierte Analyse

Kundenorientierung

Genehmigung einer Investition.

So weit die Anmerkungen zur Definition von Geschäftsprozessen. Sozusagen eingebettet ist die Prozessdiskussion in die um integrierte computergestützte Informationssysteme. Die Betrachtung von Geschäftsprozessen sollte immer mit einer umfassenden integrierten Analyse des gesamten Umfelds, in dem sie abgewickelt werden, verbunden sein: der benutzten Informationsobjekte8, der Informationsflüsse, der Einzeltätigkeiten (später Funktionen genannt), der Organisationsstrukturen, usw. Diese integrierte Sicht fasst damit früher benutzte Analyseschritte zusammen und ergänzt sie um die Prozessanalyse. Ohne dass dies direkt ausgesprochen wird (deutliche Ausnahme: [Hammer und Champy 1995, S. 52]), geht man bei der Betrachtung von Geschäftsprozessen von den Addressaten der im Geschäftsprozess erbrachten Leistungen aus. Dies sind meist die Kunden des Unternehmens. Es können aber auch andere Bereiche des Unternehmens (interne Kunden) oder andere sein. Diese Orientierung am Kunden steuert dann zum einen die Abgrenzung der einzelnen Geschäftsprozesse, sie lenkt aber vor allem die letztendlich ja geplanten Optimierungsvorhaben.

8

Der Begriff soll hier Informationen aller Art auf Informationsträgern aller Art bezeichnen.

2.2 Kernprozesse

11

Der Prozessgedanke hat viele Urheber, schließlich basiert er ja letztendlich auf den Konzepten, die bei der Analyse der Ablauforganisation entwickelt wurden. Auf einen, der mit Sicherheit dazu zählt, Porter mit seinem Wertkettenmodell, weist Franz hin:

Urheber

„Als eine wesentliche theoretische Basis des Prozessdenkens gilt das von Porter entwickelte Wertkettenmodell, welches aufgrund der Segmentierung der Unternehmensaktivitäten in primäre, direkt wertschöpfende und sekundäre, unterstützende Aktivitäten die These erlaubt, dass Unternehmen durch die geschickte Kombination und Gestaltung der Prozesse auf allen Unternehmensebenen Wettbewerbsvorteile gegenüber ihren Konkurrenten erwerben können“ >Franz 1996, S. 210@. Das Wertkettenmodell von Porter, die Wertschöpfungskette, wird im folgenden Abschnitt diskutiert.

2.2

Kernprozesse

Einige Geschäftsprozesse spielen eine besondere Rolle im Unternehmen. Es sind zentrale Prozesse, mit denen die Hauptleistung erbracht wird, in die die meisten Ressourcen einfließen und mithilfe derer die eigentliche (Æ)Wertschöpfung erfolgt. Sie werden Kernprozesse genannt. Der Begriff geht auf Porter zurück, der in seiner Diskussion der Wertschöpfungskette Kernprozesse und unterstützende Prozesse unterscheidet. Ein Kernprozess ist demnach einer, der direkt zur Wertschöpfung des Unternehmens beiträgt. Unterstützende Prozesse dagegen sind nicht wertschöpfend, aber notwendig, um die Kernprozesse ausführen zu können. Der Begriff unterstützender Prozess ist dabei nicht abwertend gemeint. Diese Prozesse sind unabdingbar, wie auch Becker und Kahn betonen:

Kernprozesse und unterstützende Prozesse

„Ohne Supportprozesse wäre die Durchführung der Kernprozesse nicht möglich“ [Becker und Kahn 2000, S. 5]. Ganz ähnlich definiert Steinbuch Kernprozesse als „kundennahe und/oder wertschöpfungsintensive Geschäftsprozesse“ [Steinbuch 1998, S. 33]. Die Nichtkerngeschäftsprozesse bezeichnet er ebenfalls als Supportprozesse und unterscheidet dann [Steinbuch 1998, S. 34f]: x x

kundennahe Kernprozesse und wertschöpfungsintensive Kernprozesse

Zu den Supportprozessen zählt er Buchführung, Kostenrechnung, Lohnund Gehaltsrechnung [Steinbuch 1998, S. 35]. Mehr auf die Bedeutung einzelner Geschäftsprozesse für den Unternehmenserfolg und weniger auf ihren Beitrag zur Wertschöpfung zielt Mertens, wenn er in Bezug auf einen Industriebetrieb zu folgenden Hauptprozessen [Mertens 1995, S. 25ff] kommt:

Hauptprozesse

12

x x x x x x x

2 Geschäftsprozesse

Forschung und Produktentwicklung Anfrage-/Angebotsabwicklung Auftragsabwicklung i.e.S. Materialbeschaffung Produktionsplanung und -steuerung Reklamationsbearbeitung Kundendienst

Vgl. hierzu auch die etwas detailliertere Untergliederung in [Mertens u.a. 1997, S. 24f]. Lohse abstrahiert noch stärker und nennt drei grundsätzliche Hauptprozesse in einem Unternehmen [Lohse 1996, S. 295]: x x x

Kernkompetenzen

Order to Delivery – Prozess: von der Angebotsabgabe bis zur Auslieferung des Produkts und der finanziellen Abwicklung der Transaktion Time to Market – Prozess: die zu Innovationen führenden Aktivitäten des Unternehmens bei Produkten, Dienstleistungen und sonst wo. Customer Service – Prozess: alle Tätigkeiten, die notwendig sind, um das Produkt (die Dienstleistung) am Markt zu unterstützen.

Im letztgenannten Punkt stecken dann wohl auch die Marketingaktivitäten, die heutzutage in ihrer Bedeutung nicht unterschätzt werden sollten und die in vielen Unternehmen zu den Haupt- oder Kernprozessen zählen dürften. Verbunden ist der Begriff der Kerngeschäftsprozesse mit dem der Kernkompetenzen, der die besonderen Fähigkeiten anspricht, die bei den einzelnen Mitarbeitern vorliegen oder die durch das Zusammenwirken von Mitarbeitern (in Abteilungen, Projekten oder sonst wie) entstehen. Becker/Meise weisen darauf hin, dass jedes Unternehmen eine Vielzahl von „...Technologien und Fähigkeiten seiner Mitarbeiter, Produkte zu entwickeln, zu produzieren und vertreiben...“ besitzt und betonen den Wert der gemeinsamen Leistung: „Erst die Integration einzelner Kompetenzen zu einer neuen, übergreifenden und schwer nachzuahmenden Fähigkeit führt zu einer echten Kernkompetenz.“ [Becker und Meise 2000, S. 101]. Kriterien für Kernkompetenzen sind: x

Es muss ein grundlegender Nutzen für den Kunden geschaffen werden, bzw. es muss ein Nutzen geschaffen werden, für den der Kunde bereit ist, Geld auszugeben.

2.2 Kernprozesse

x

x

13

Sie dürfen nicht Allgemeingut sein, sondern müssen das Unternehmen aus dem Kreis der Wettbewerber hervorheben (z.B. durch die Produktion technologisch hochwertiger und in qualitativer Hinsicht führender Bohrmaschinen oder Kraftfahrzeuge). Sie muss nicht nur kurzfristige Bedeutung besitzen9.

Für eine vertiefte Diskussion vgl. [Becker und Meise 2000, S. 102f]. Das Ableiten oder auch Festlegen von Kernprozessen muss auf der Ebene der strategischen Unternehmensanalyse erfolgen, worauf auch Becker/Meise hinweisen10:

Kernprozesse finden

„Zuerst gilt es aber, die Kernprozesse auf oberster Ebene anzuordnen. Sie ergeben sich aus der beschriebenen strategischen Unternehmensanalyse und den daraus abgeleiteten Aufgaben. Sie repräsentieren die Hauptaufgaben des Unternehmens und unterscheiden sich darin von den Supportprozessen, welche unterstützende Funktion haben.“ [Becker und Meise 2000, S. 111] An solche Hauptprozesse denken wohl Brenner und Hamm, wenn sie schreiben:

Anzahl Geschäftsprozesse

„Ein Unternehmen läßt sich mit Hilfe von fünf bis sieben zentralen Geschäftsprozessen beschreiben.“ [Brenner und Hamm 1995, S. 22] Geht man aber in der Detaillierung und in der „Länge“ der Geschäftsprozesse (vgl. unten) auch nur auf ein mittleres Niveau, kommt man zu einer wesentlich größeren Zahl von Geschäftsprozessen, die ein Unternehmen umfassend beschreiben. Die Betriebswirtschaftliche Standardsoftware SAP R/3 zum Beispiel kommt mit über tausend vorgedachten Geschäftsprozessen zum Kunden (vgl. Abschnitt 4.8 und Kapitel 8). Natürlich ist es auch möglich, Hauptprozesse für einzelne Unternehmensbereiche zu betrachten. Für den Vertrieb eines Industrieunternehmens könnten dies z.B. die Angebotserstellung und die Auftragsabwicklung sein. Im Folgenden einige konkrete Beispiele für Haupt- und Kernprozesse, mit denen auch deutlich gemacht werden soll, dass natürlich auch außerhalb von Industrieunternehmen, auf die sich die Literatur in diesem Punkt weitgehend konzentriert, diese Prozesstypen identifiziert werden können: x

Für Dienstleistungsunternehmen im Transportbereich ist die eigentliche Transportleistung von Menschen und Gütern ein Kernprozess, die Auftragsabwicklung (die richtigen Güterwagen zum richtigen Zeit-

9

Becker/Meise fordern hier eine „langfristige Bedeutung“. Dem kann angesichts der schnellen Umwälzungen in Wissenschaft und Technik nur eingeschränkt zugestimmt werden. Auch Kompetenzen können heute über Nacht wertlos werden oder ihr Profil verändern. Dort finden sich auch Hinweise zum Management von Kernkompetenzen [Becker und Meise 2000, S. 104ff].

10

Beispiele

14

x

x

x

x x

2.3 Eigenschaften: - Automatisierung

- Datenintegration

- Prozessintegration

2 Geschäftsprozesse

punkt bereitstellen) und Beratungstätigkeiten (z.B. Auskunft am Fahrkartenschalter, Informationen an den Bahnhöfen) sind Hauptprozesse. Für eine Messegesellschaft gehört die Organisation von Messeveranstaltungen, der technische Betrieb eines Messezentrums, der Einkauf von Dienstleistungen und u.U. der Verkauf von Messestandflächen an Aussteller zu den Kernprozessen. Ein unterstützender Prozess ist die Abrechnung von Messeveranstaltungen. In einem Steuerbüro gehört die Erstellung der Finanzbuchhaltungen, der Jahresabschlüsse, der Steuererklärungen und Lohnabrechnungen zu den Kernprozessen (je nach Ausrichtung der Geschäftstätigkeit). Ein Beispiel für einen unterstützenden Prozess ist die Neumandantenwerbung. In einem Handelshaus gehören die Auftragsabwicklung und die Einkaufsabwicklung (Qualität, Preis, ...) zu den Kernkompetenzen. Unterstützende Prozesse sind hier z.B. die Qualitätskontrolle, der Kundenservice, das Personalwesen, das Mahnwesen und die Kundenaquisition. In einem Softwarehaus gehört die Entwicklung (Systemanalyse, Systemdesign, Programmierung) und der adäquate Einsatz von Methoden und Werkzeugen zu den Kernkompetenzen. Bei einem Hersteller „einfacher“ Produkte, die auch von anderen leicht hergestellt werden können, gehören unter Umständen die Geschäftsprozesse des Marketing zu den Kernprozessen.

Eigenschaften und Komponenten

Geschäftsprozesse können unterschiedlich stark automatisiert sein. Mit diesem Automatisierungsgrad ist der Anteil an der Aufgabenerfüllung gemeint, der ohne menschliches Zutun durch die Informationstechnologien erledigt wird. In vielen Bereichen ist das Ziel derzeit ein möglichst hoher Automatisierungsgrad. Dieses Ziel wird dort auch schon weitgehend erreicht, wo es sich um stark standardisierte Abläufe handelt. Er ist weniger weit und wird auch nicht so weit kommen, wo nicht standardisierbare Abläufe dominieren. Eine andere wichtige Eigenschaft ist das Ausmaß der Datenintegration, d.h. der Integration der Datenbestände, die für die einzelnen Funktionen des Geschäftsprozesses benötigt werden. Auch diese ist von großer Bedeutung, da nicht-integrierte Datenbestände Reibungsverluste bedeuten. Aus dem Blickwinkel der Optimierungsbemühungen werden diesbezügliche Defizite als Medienbrüche bezeichnet. Die Prozessintegration beschreibt die Durchgängigkeit des Geschäftsprozesses über verschiedene traditionelle Organisationsbereiche wie Beschaffung, Einkauf, Produktion, Verkauf, Rechnungs- und Personalwesen hinweg. Diese Durchgängigkeit ist i.d.R. nicht voll gegeben und kann es

2.3 Eigenschaften und Komponenten

15

auch nicht sein11, die Bruchstellen werden als Organisationsbrüche bezeichnet und müssen bei der Optimierung dann auf ihre Notwendigkeit hin überprüft werden. Konkret bedeutet dies oft, dass Funktionen unterschiedlicher Organisationsbereiche aufeinander abgestimmt werden müssen. Je nach der Ausrichtung einer Untersuchung könnten sehr viele und sehr unterschiedliche Komponenten von Geschäftsprozessen identifiziert werden. Man stelle sich nur Untersuchungen vor, die auf die informellen Beziehungen der Geschäftsprozesspartizipanten abheben oder auch nur auf die informellen Informationsflüsse, ganz zu schweigen von Untersuchungen zu psychologischen oder soziologischen Aspekten (vgl. die Ausführungen zur Begrifflichkeit (formell vs. formal) im Vorwort zur 1. Auflage). All dies geschieht hier nicht. Die betriebswirtschaftlich orientierten Ansätze konzentrieren sich auf die formellen Strukturen und auf das für die Geschäftsprozesse unmittelbar bedeutsame Handeln der Partizipanten. So unterscheidet Scheer, der wohl bedeutsamste Vertreter dieser prozessorientierten Sicht, folgende Komponenten bei computergestützten Geschäftsprozessen (vgl. [Scheer 1997] sowie die knappe Darstellung seines ARIS-Konzepts in Abschnitt 2.10): x x x x x x

Vorgänge (mit denen die notwendigen Tätigkeiten erfasst werden) Ereignisse (die für den Geschäftsprozess Bedeutung besitzen, auch als betriebswirtschaftlich relevante Ereignisse definiert) Zustände (die sich jeweils nach Abschluss einer Tätigkeit, vor allem in den Daten, neu ergeben) Bearbeiter (und Bearbeiterinnen) Organisationseinheiten sowie Ressourcen der Informationstechnologie

die er dann, nochmals abstrahierend, zu folgenden Elementen seiner formalen Beschreibungssprache „Ereignisgesteuerte Prozessketten“ zusammenfasst: x x x x

Ereignisse Funktionen Organisationseinheiten Informationsobjekte

Dazu mehr in Abschnitt 2.10 und in den Kapiteln 4 bis 7.

11

Es gibt Unternehmen, die ein solches Konzept bereits weitgehend realisieren. Dies sind solche, die ihre Aktivitäten so gut wie ausschließlich in Projekten abwickeln. Z.B. kleinere Softwarehäuser oder Ingenieurunternehmen mit einer begrenzten Mitarbeiterzahl, die fast keine klassische Aufbauorganisation haben. Alle Aufträge werden als Projekte gesehen und abgewickelt, Reste der klassischen Aufbauorganisation sind Dienstleister für die Projektabwicklung.

Komponenten

16

2.4

Veränderte Perspektive

Aufwändige Medienbrüche

2 Geschäftsprozesse

Geschäftsprozesse über Unternehmensgrenzen

Unsere arbeitsteilig organisierten Wirtschaftssysteme sind durch einen intensiven und globalen Austausch von Gütern und Leistungen gekennzeichnet. Dieser Austausch verlangt die Weitergabe von Daten, Belegen, von Koordinierungsinformationen12 oder – mit anderen Worten – die Fortsetzung der Geschäftsprozesse über Unternehmensgrenzen hinweg. Anfang und Ende eines Geschäftsprozesses sind damit in den meisten Fällen nicht mehr so sehr an den Unternehmensgrenzen orientiert, sondern an der umfassenden logistischen Kette von Vorlieferanten zu Endkunden. Damit hat sich die Betrachtungsweise des wirtschaftlichen Geschehens wieder einmal deutlich verändert. Während es noch bis vor wenigen Jahren darum ging, die Effizienz der internen Geschäftsprozesse zu erhöhen (meist durch den Einsatz Betriebswirtschaftlicher Standardsoftware), müssen jetzt auch die unternehmensübergreifenden Geschäftsprozesse optimiert werden. Darauf hat Mertens schon Mitte der 60er-Jahre hingewiesen, so richtig deutlich und für jeden erkennbar wurde es in den letzten 10 Jahren durch die Entwicklung des Internet als Medium für Geschäftsbeziehungen aller Art. Die wirklich aufwändigen Medienbrüche liegen heute an den Unternehmensgrenzen. Hier werden Informations- und Kontrollflüsse unterbrochen oder gehemmt, hier wird (sozusagen) die Datenautobahn zum Feldweg. Während also zwischenbetrieblich durch den Prozessgedanken und seine Umsetzung in Betriebswirtschaftliche Standardsoftware (vgl. das folgende Kapitel) „... die steigende Intensität der Kooperationen mit vor- und nachgelagerten Wertschöpfungsstufen sowie Dienstleistern zu einer wachsenden organisatorischen Integration der Beteiligten führt“ [Scheckenbach 1997, S. 1], kann davon überbetrieblich noch keine Rede sein. Eine zentrale Rolle bei der softwaretechnischen Realisierung nimmt hierbei Betriebswirtschaftliche Standardsoftware ein, die zusätzlich zu ihren bisherigen Aufgaben noch diese übernimmt, unterstützt allerdings durch Software für die eigentliche unternehmensübergreifende Kommunikation, sei es zwischen Unternehmen (B2B), zwischen Unternehmen und Kunden (B2C) oder sonst wo.

12

Scheckenbach bezeichnet die im Rahmen der überbetrieblichen Prozessabwicklung auszutauschenden Daten als informierende und koordinierende Geschäftsdaten, die sich auf „die Spezifikation der auszutauschenden Leistungen, die Konditionen der Geschäftsbeziehung und auf die Koordination des Abwicklungsprozesses“ beziehen (vgl. [Scheckenbach 1997, S. 2]).

2.5 Ziele der Geschäftsprozessmodellierung

17

Das große Potenzial, das hier steckt, zeigt der Hinweis bei [Scheckenbach 1997, S. 1], dass (in Bezug auf den unternehmensübergreifenden Datenaustausch) „70% der manuell erfassten Daten bereits elektronisch auf anderen Systemen vorliegen“ (nach einer Studie von Cannon: [Cannon 1993, S. 13]). Dieser Wert dürfte heute, angesichts der weiten Verbreitung Betriebswirtschaftlicher Standardsoftware und der damit erhöhten Automatisierung von Geschäftsprozessen, noch höher sein. Klappt die unternehmensübergreifende Abwicklung der Geschäftsprozesse, sind die dabei entstehenden Wertschöpfungsketten gekennzeichnet durch „die x x x x x

Medienbrüche

enge Verzahnung betrieblicher und zwischenbetrieblicher Leistungsprozesse verstärkte elektronische Steuerung der Abläufe unter steigender Einbeziehung interner und externer Informationen steigende Anzahl beteiligter Partner Infragestellung traditioneller Abläufe und die sich verkürzende Zeitspanne zwischen Leistungsanforderung und Leistungserstellung (Aktions-/Reaktionsbeziehung)“ [Scheckenbach 1997, S. 3]

Die dabei erzielbaren Vorteile sind im Wesentlichen Zeitvorteile in der logistischen Kette (z.B. Wiederbeschaffungszeiten) und Rationalisierungspotenziale im administrativen Bereich [Scheckenbach 1997, S. 23]. Natürlich fordert aber eine Prozessintegration zwischen Unternehmen weitergehende Sicherheitsmaßnahmen als die unternehmensinterne Integration.

2.5

Ziele der Geschäftsprozessmodellierung

Erstes Ziel jeder Geschäftsprozessmodellierung13 ist die Bestandsaufnahme, die Feststellung, welche Geschäftsprozesse in welcher Form ablaufen. Dies kann dann auch direkt zu einer Dokumentation, z.B. im Rahmen einer ISO 9000-Zertifizierung führen oder zu einer Beschreibung, die im Rahmen der Vorbereitung der Einführung einer Betriebswirtschaftlichen Standardsoftware benötigt wird. Letzteres führt dann z.B. zu Ist-Analysen, mit denen der Vergleich der vorgedachten Geschäftsprozesse der Betriebswirtschaftlichen Standardsoftware mit den eigenen bewerkstelligt werden kann. Das zweite große Ziel ist das der Geschäftsprozessoptimierung, der Beseitigung von Schwachstellen, die bei der Beschreibung erkannt wurden. Einige der möglichen Schwachstellen wurden oben bei den Zielen schon (indirekt) angesprochen: 13

Ein Vorgehensmodell der Prozessgestaltung findet sich in [Hohmann 1999, S. 159ff]

Dokumentation und Ist-Analysen

Optimierung

18

x x Schwachstellen

2 Geschäftsprozesse

fehlende Datenintegration, d.h. Dateninseln fehlende Prozessintegration, d.h. Organisationsbrüche

Weitere Schwachstellen sind x x x x x x x x x x x x x x

zu lange Transportzeiten von Prozessobjekten (Dokumente, Rechnungen, CAD-Zeichnungen, usw.; im Bürobereich ganz allgemein von Vorgängen) zu lange Warte- und Liegezeiten von Prozessobjekten zu lange Bearbeitungszeit zu lange Rüst- und Durchlaufzeiten ganz allgemein zu lange Prozessdurchlaufzeiten redundante Tätigkeiten hohe Fehlerraten zu hohe Komplexität (konkret: zu hoher Aufwand für Disposition und Verwaltung) unzureichendes Prozessdenken (konkret: unzureichendes Verständnis für vor- und nachgelagerte Prozessabschnitte bei den Beteiligten) zu lange Kommunikations- und Entscheidungswege zu hohe Gesamtkosten der Prozesse zu wenig Transparenz, was unter Umständen auch die Veränderung von Geschäftsprozessen behindert unzulängliche Prozessverantwortlichkeit fragmentierte Verantwortlichkeiten

Vgl. zu diesem Punkt auch [Lohoff und Lohhoff 1994, S. 57], [Müller und Rupper 1994, S. 11], [Rump 1999, S. 20ff], [Amberg 1999, S. 47], für Büroarbeit [Vogler und Bodendorf 1994, S. 64].

2.6

Business Process Reengineering

In der Diskussion um Business Process Reengineering spielt das Geschäftsprozesskonzept eine zentrale Rolle. Business Process Reengineering wird als Oberbegriff für die Methoden zur prozessorientierten Umgestaltung betrieblicher Organisationsstrukturen gesehen (so auch Krallmann und Derszteler in ihrem Beitrag in >Mertens u.a. 1997, S.70)@). Ganz ähnlich Brenner und Hamm, wenn sie definieren: „Business Reengineering nach unserem Verständnis beschäftigt sich mit den einzelnen Abläufen im Unternehmen und versucht, diese für das Geschäft zu optimieren.“...„Ziel des Business Reengineering ist es, die organisatorischen Abläufe eines Unternehmens neu zu gestalten“ [Brenner und Hamm, S. 18]. Ebenso Becker und Meise mit einem Hinweis auf die Bedeutung der Prozesseffizienz:

2.7 Prozessorientierung

19

„Der Ansatz des Business Process Reengineering (BPR) ist stark prozessorientiert, die Prozesseffizienz hat also Vorrang vor allen anderen Kriterien.” [Becker und Meise 2000, S. 110]

BPR und Prozesseffizienz

Hohmann definiert genauso und gibt einen Hinweis auf die Notwendigkeit radikaler Veränderungen: „Im Kern geht es um die Optimierung der Ablauforganisation durch Implementierung von durchgängigen Unternehmensprozessen. Neben der Prozessorientierung steht die radikale Veränderung der Geschäftsprozesse (schneller, transparenter, kostengünstiger) im Mittelpunkt.“ [Hohmann 1999, S. 155] Oftmals wird der Begriff allerdings in den Veröffentlichungen dieses Bereichs einfach vorausgesetzt und nicht definitorisch hinterfragt. Für Franz geht die Übereinstimmung noch weiter. Er sieht Business Process Reengineering als Subsumierung der Begriffe Prozessorganisation, Prozessoptimierung und Prozessmanagement >Franz 1996@. Das Geschäftsprozesskonzept ist somit von grundlegender Bedeutung für die Diskussion des Business Process Reengineering. Es versteht sich, dass Business Process Reengineering damit auch in engem Zusammenhang mit den oben diskutierten Begriffen Kerngeschäftsprozesse und Kernkompetenzen steht. Um es mit Rupper zu sagen:

Radikale Veränderungen

BPR und Kernprozesse

„Process Reengineering beginnt mit der Wertschöpfungsanalyse, d.h. man analysiert je Tätigkeit resp. Prozessteil Deckungsbeiträge, akquisitorische Werte etc. ..... Im nächsten Schritt wird eine Optimierung der Wertschöpfung bewerkstelligt, ..... Im dritten Schritt werden die Prozesse neu gestaltet, z.B. durch Konzentrieren auf Kernprozesse, ...., v.a. aber durch Neugestaltung der Abläufe im Sinne der Flussorientierung.“ [Rupper 1994, S. 10] Die in der Literatur genannten Ziele des Business Process Reengineering ähneln damit denen, die bei Geschäftsprozessen genannt werden.

2.7

Prozessorientierung

Mit dem Begriff Prozessorientierung14 ist die Wahrnehmung von Geschäftsprozessen, genauer: die Perzeption der Unternehmensrealität als Sammlung miteinander kooperierender Geschäftsprozesse gemeint. Dies betrifft zum einen die im Unternehmen tätigen, von denen heute verlangt wird, in Geschäftsprozessen zu denken, die eigene Tätigkeit im Gesamtzusammenhang des Geschäftsprozesses zu sehen. Zum anderen aber auch 14

Ein leidenschaftlich vorgetragenes Pladoyer für Prozessorientierung findet sich in [Hammer 1997].

Was ist Prozessorientierung?

20

Prozessintegration

2 Geschäftsprozesse

alle Optimierungsbemühungen, z.B. von Unternehmensberatungen, die inzwischen i.d.R. ganz selbstverständlich von Geschäftsprozessen als Grundelementen heutiger Unternehmenswirklichkeit ausgehen. Wesentlich ist dabei der Integrationsgedanke. Vor allem in Hinblick auf die Prozessintegration (auch Vorgangsintegration), worunter Mertens versteht, „..., dass einzelne Prozesse oder Vorgänge miteinander verbunden werden“ [Mertens 1995, S. 1].

Daten- und Funktionsintegration

Aber auch bezüglich der Daten- und Funktionsintegration sowie der Methoden- und Programmintegration (ebenda). Als Ausgangspunkt und Leitlinie wird dabei immer der Kundennutzen genannt: “Prozessorientierung heißt im wesentlichen, die Bedürfnisse der externen und internen Kunden zu kennen, um diese auf die effizienteste Art und Weise umzusetzen.” [Gaukel und Bardelli 1994, S. 33]

Prozessorientierte Aufbauorganisation

Letztendlich bedeutet eine konsequente Hinwendung zur Prozessorientierung, dass das Unternehmen umgestaltet werden muss, hin zu einer prozessorientierten Aufbauorganisation15. Einen sehr weitgehenden Vorschlag formulieren Lohoff und Lohoff im Jahr 1994: „Eine konsequente Prozessorientierung verlangt eine Anpassung und Harmonisierung der Strukturen. Alle SubProzesse einer Wertschöpfungskette sollten organisatorisch unter einem Dach vereinigt werden, sodass funktionale und prozessuale Verantwortung in einer Hand liegen. ... Die prozessorientierte Organisation legt Aufgabe, Kompetenz und Verantwortung so aus, dass ein Geschäftsvorfall durchgängig von einer Person oder einem Team beherrscht und gesteuert werden kann. Solche Teams betreuen ihren Kunden umfassend. ... Die Mitarbeiter identifizieren sich ganzheitlich mit den Problemen ihrer Kunden .... Sie erhalten größere Verantwortungsbereiche und betreuen diese eigenständig“ [Lohoff und Lohoff 1994, S. 59f].

Ziele der Prozessorientierung

Wie wir inzwischen wissen wurden diese Ziele in vollem Umfang in kaum einem Unternehmen umgesetzt. Der Prozessgedanke fand aber dennoch Verbreitung und wurde zumindest ein Stück weit umgesetzt. Es ist auch fraglich, ob eine so umfassende Umsetzung sinnvoll wäre (vgl. unten). Ziele der Prozessorientierung sind, neben den oben angeführten konkreten Zielen der Prozessanalyse: x

Erhöhung der Kundenzufriedenheit

15

Kugeler und Vieting setzen sich intensiv mit Fragen der Gestaltung einer prozessorientierten Aufbauorganisation auseinander [Kugeler und Vieting 2000].

2.7 Prozessorientierung

x x x x x

21

Erhöhung der Lieferantenzufriedenheit Förderung des Prozessdenkens Qualitätsverbesserungen in allen Bereichen Initiierung eines permanenten Verbesserungsprozesses Erhöhung der Mitarbeiterzufriedenheit

(vgl. [Lohoff und Lohoff 1994, S. 57) Eine verstärkte Orientierung an den Geschäftsprozessen löst natürlich nicht alle Probleme. Z.B. gibt sie keine Antwort auf den Zielkonflikt zwischen der Prozess- und der Ressourceneffizienz16, worauf Kugeler und Vieting hinweisen [Kugeler und Vieting 2000, S. 197]. Ebenso betrachtet sie erst mal überhaupt nicht die Qualität der im Geschäftsprozess ausgeübten Funktionen. Ganz allgemein gilt, dass bestimmte Funktionen, die in Geschäftsprozessen benötigt werden, in einem einzelnen Prozess oftmals eine Stelle nicht ausfüllen und auch anderen nicht zugewiesen werden können. In einem solchen Fall müssen die entsprechenden Tätigkeiten von verschiedenen Geschäftsprozessen zusammengenommen werden, um eine Stelle auszufüllen (so auch [Kugeler und Vieting 2000, S. 189]). Es ist auch keineswegs sicher, dass immer ein Effizienzgewinn eintritt, wenn eine bisher unternehmensweit zusammengefasste Funktion auf einzelne Geschäftsprozesse aufgeteilt wird. Von Sicherheitsaspekten, z.B. bei Beschaffungs- oder Buchungsvorgängen ganz zu schweigen. In der Praxis ist ein Kompromiss aus Prozess- und Funktionsorientierung die optimale Lösung. Mertens bringt – bei der Betrachtung hoch aggregierter und langer Geschäftsprozesse - diesen Sachverhalt auf den Punkt, wenn er in Bezug auf die Erstellung eines Prozessmodells meint, dass dies überall dort sinnvoll ist,

Grenzen der Prozessorientierung als Methode

Grenzen der prozessorientierten Umgestaltung

„... wo logistische Prozesse ablaufen und durch entsprechende Informationsflüsse unterstützt werden. Weniger zweckmäßig ist eine Prozessbetrachtung bei Querschnittsfunktionen wie Personal, Finanzen, Rechnungswesen oder Gebäudeverwaltung.“ [Mertens 1995, S. 25] Gaukel und Bardelli weisen darauf hin, dass Prozessorientierung nur bei einer ausgeprägten Teamfähigkeit der beteiligten Personen möglich ist [Gaukel und Bardelli 1994, S. 31]. Dies kann zu Schwierigkeiten bei der Umsetzung einer verstärkten Prozessorientierung führen, denn nicht jeder Mitarbeiter ist teamfähig und viele Vorgesetzte sind hierarchiebewusst. Die Orientierung an Prozessen ist nicht so neu, wie manche glauben machen wollen, sondern wurde in der Organisationslehre, im Kontext der Ablauforganisation, schon lange thematisiert, worauf zahlreiche Autoren 16

Ressourceneffizienz thematisiert den Auslastungsgrad von Ressourcen aller Art. Sie ist hoch, wenn eine Ressource so ausgelastet wird, dass möglichst wenig Leerzeiten entstehen.

Voraussetzungen

Neu?

22

Revolution?

2 Geschäftsprozesse

hinweisen (vgl. z.B. >Franz 1996, S. 210@). Geht es mit diesem Begriff vielleicht nur um „Wissenschaftsmarketing“17, handelt es sich nur um alten Wein in neuen Schläuchen (vgl. hierzu >Kieser 1996@) oder geht es tatsächlich um eine neue Sichtweise der Unternehmensrealität? Nun, auch wenn es nicht revolutionär ist, bedeutet ein Vorgehen, bei dem ganze Geschäftsprozesse Ausgangspunkt der Analyse der Unternehmensstrukturen und –abläufe sind, doch eine Überwindung der funktionsorientierten Betrachtung18, die auf die Analyse der einzelnen zu leistenden Funktionen, ihrer eventuellen DV-Umsetzung und der dabei notwendigen Datenflüsse konzentriert war. Dies wird auch in der Literatur so gesehen (vgl. beispielhaft >Mischak 1997@, >Brenner und Hamm 1995, S. 21@). Für Hammer und Champy ist das sogar die wesentliche Botschaft ihres Buches, dass Firmen die „einzelaufgabenorientierten Arbeitsplätze“ überwinden und prozessorientiert organisieren müssen >Hammer und Champy 1995, S. 43@. Für das ja hier immer mitspielende Ziel der Optimierung der Unternehmensabläufe bedeutet dies eine Abwendung von der Optimierung einzelner Funktionen oder der Organisationsstruktur19 und eine Hinwendung zur Optimierung des gesamten Material- und Informationsflusses, wie es Abts und Mülder formulieren >Abts und Mülder 1998, S. 258@.

2.8

Unschärfen

Was für das Business Process Reengineering im allgemeinen gilt (so >Kieser 1996, S. 249@) gilt auch für die Geschäftsprozessanalyse im besonderen: die Methoden sind nicht exakt, auch nicht die Identifikation und Abgrenzung von Geschäftsprozessen. Dies können Autoren weniger gut erkennen, die Geschäftsprozesse entlang Betriebswirtschaftlicher Standardsoftware betrachten und analysieren (weil da die Software die Ausrichtung vorgibt). Analysiert man aber „frei“ erstellte Beschreibungen von Geschäftsprozessen (mit welcher Methode auch immer), erkennt man den Spielraum, der hier gegeben ist. Dies betrifft auch die theoretischen Grundlagen, worauf Hess und Brecht hinweisen, die nach einer intensiven Auseinandersetzung mit den Methoden des Business Process Redesign zu dem Ergebnis kommen: „Eine einheitliche Konstruktionslehre für Prozesse hat sich noch nicht herausgebildet“ >Hess und Brecht 1996, S. 127@.

17

18 19

Worauf Kieser unter Bezugnahme auf >Eccles und Nohria 1992, S. 182@ hinweist: Oftmals geht es gerade bei der Diskussion von Management-Fragen darum, neue Begriffe zu finden, weil alte schlicht aufgrund ihres Alters ihr Gewicht verloren haben >Kieser 1996, S. 250@. Betrachtung einzelner Tätigkeiten (vgl. zum Funktionsbegriff Kapitel 4). Vgl. [Mertens und Knolmayer 1995, S. 1] für die doch anderen Optimierungszielsetzungen in der organisationstheoretisch orientierten Diskussion.

2.8 Unschärfen

23

Die wichtigste Unschärfe betrifft den Detaillierungsgrad, mit dem der Geschäftsprozess erhoben wird. Hier ist alles möglich, von einer hoch angesiedelten Meta-Ebene bis zu einer tayloristischen Ausdifferenzierung der einzelnen Tätigkeiten. Auf diese Frage wird in den Kapiteln 4 - 7, bei der Beschreibung der Ereignisgesteuerten Prozessketten, immer wieder eingegangen. Aber auch die Länge von Geschäftsprozessen ist nicht festgelegt. Geschäftsprozesse weisen in sich eine Struktur auf, „indem sie hierarchisch in Teilprozesse (Abläufe, Vorgänge, Teilvorgänge, Einzeltätigkeiten etc.) untergliedert werden.“ So Ott, der dann fortfährt:

Detaillierungsgrad

Abgrenzung von Geschäftsprozessen

„Ein Prozess stellt nun eine Menge von Teilprozessen dar, die im Sinne eines zielorientierten Vorgehens in ganz bestimmter Reihenfolge ausgeführt werden sollen.“ >Ott 1995, S. 82@ Hiermit erklärt sich auch die unterschiedliche Auffassung bzgl. der Zahl der Geschäftsprozesse, die ein Unternehmen beschreiben (vgl. auch oben). Die Entscheidung, wo die Grenzen einzelner Geschäftsprozesse gezogen werden, ist die des Analysten und hängt nur von seiner Kompetenz und der Zielsetzung der Analyse ab20. Dies mindert aber nicht den Wert dieses Begriffs für die praktische Arbeit, im Gegenteil, es gibt die nötige Flexibilität für Optimierungsaktivitäten, die an die jeweilige spezifische Struktur eines Unternehmens angepasst sind. Einen Versuch, die Festlegung der Grenzen zu entsubjektivieren, machen Becker und Vossen, indem sie betriebswirtschaftlich relevante Objekte definieren (Informationsobjekt, Rechnung, Ware, usw.) und empfehlen, eine Prozessdefinition mit einem solchen zu verknüpfen >Becker und Vossen 1996, S. 18f@. Sie definieren einen Prozess dann als

Betriebswirtschaftlich relevante Objekte

„... die inhaltlich abgeschlossene zeitliche und sachlogische Abfolge der Funktionen, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objektes notwendig sind.“ (ebenda, S. 19), merken aber gleich an, dass u.U. mehrere solche Objekte berücksichtigt werden müssten (z.B. Rechnung und Ware). Die Definitionsproblematik ist damit nicht gelöst, sie wird nur verlagert und erweitert um die Frage einer adäquaten Definition betriebswirtschaftlicher Objekte und um die Klärung des Zusammenspiels verschiedener betriebswirtschaftlich relevanter Objekte in einem Geschäftsprozess. Etwas leichter in der Definition von Geschäftsprozessen tun sich lediglich die Anbieter Betriebswirtschaftlicher Standardsoftware. Es gehört zu 20

So auch Sinz in seinem Beitrag zum Stichwort „Modellierung“ in [Mertens u.a. 1997, S. 217], wenn er darauf hinweist, dass betriebliche Systeme reale Systeme darstellen und ihre “Modellabbildung und ihre Eigenschaften nur informal spezifierbar” sind und zum Ergebnis kommt: “Die Modellierung hängt daher in hohem Maße von den analytischen Fähigkeiten des Modellierers ab.” (ebenda)

Definition durch Software

24

2 Geschäftsprozesse

diesem Softwaretyp, dass Beschreibungen (Modelle) vorgedachter Geschäftsprozesse mitgeliefert werden (vgl. Kapitel 8). Diese Geschäftsprozesse sind entlang der Software beschrieben und damit definiert. Hier erfolgt somit die Spezifikation und die Festlegung dessen, was unten Detaillierungsgrad einer Geschäftsprozessbeschreibung genannt wird, durch die Software. So verstandene Geschäftsprozesse spiegeln also die Funktionen und Abläufe der (umfassenden) Betriebswirtschaftlichen Standardsoftware wieder.

2.9

Geschäftsprozess Angebotserstellung Vgl. Abschnitt 6.3 für eine Darstellung als Ereignisgesteuerte Prozesskette.

1. Prüfung

2. Prüfung

Erstellung

Beispiele – Angebotserstellung und Auftragsabwicklung

Hier nun ein erstes etwas konkreteres Beispiel eines Geschäftsprozesses. Betrachten wir dazu beispielhaft ein Unternehmen des Anlagenbaus. Der Prozess der Angebotserstellung könnte in einem solchen Unternehmen wie im Folgenden beschrieben ablaufen. Gestartet wird der Geschäftsprozess aufgrund einer Kundenanfrage. Diese kann mündlich, per Post, per Telefon, per Telefax, per E-Mail oder auf einem anderen akzeptierten Weg eingehen. Nach Eingang der Anfrage wird sie an den zuständigen Vertriebsbereichsleiter geleitet, der sie an einen seiner Vertriebsingenieure weitergibt. Der Vertriebsingenieur21 prüft die Angebotsrealisierbarkeit. Dies betrifft zunächst das angefragte Leistungsspektrum. Liegt dieses nicht innerhalb des Leistungsspektrums des Unternehmens, erfolgt eine Absage. Können nur Teile der angefragten Leistungen erbracht werden, werden Fremdfirmen um Unterstützung angefragt und entweder als Kooperationspartner oder Subunternehmer eingebunden. Danach folgt die Prüfung, ob die Angebotslegungsfrist realisiert werden kann. Parallel hierzu wird die für die Projektabwicklung notwendige Ingenieurgruppe auf ihre Auslastung hin überprüft. Ist die Kapazität vorhanden, die Angebotsfrist aber zu knapp, wird um Fristverlängerung nachgefragt. Wird diese nicht gewährt, erfolgt eine Absage. Ist absehbar, dass benötigte Ingenieurfachkräfte schon für längere Zeit aufgrund laufender Projekte ausgelastet sind, erfolgt ebenfalls eine Absage. Sind alle zu prüfenden Kriterien erfüllt, erfolgt die eigentliche Angebotserstellung. Dies geschieht in der Regel unter Einbeziehung der Mitarbeiter aus den relevanten Geschäftsbereichen oder der Geschäftsbereichsleiter, die z. B. bei der Stunden- und Kostenschätzung von angefragten Ingenieurstätigkeiten mitwirken und mögliche, verfügbare Ingenieure als Projektleiter und Ingenieure vorschlagen. Die Angebotsdaten werden in der EDV erfasst, ein Programm erzeugt dann die textliche Ausformulierung des Angebots für den anfragenden Kunden.

21

Es kann sich selbstverständlich auch um eine Vertriebsingenieurin handeln.

2.9 Beispiele – Angebotserstellung und Auftragsabwicklung

25

Das fertige Angebot wird dem Kunden zugeschickt oder gebracht. Danach muss die Entscheidung des Kunden abgewartet werden. Der Kunde erteilt den Auftrag entweder sofort aufgrund des Angebots oder er lädt zunächst zu einem oder mehreren Vergabegesprächen ein. Die Angebotsverhandlungen werden in der Regel vom zuständigen Vertriebsingenieur oder Vertriebsbereichsleiter und dem im Angebot genannten Projektleiter geführt. Trifft eine Absage ein, ist der zuständige Vertriebsingenieur verpflichtet, durch Nachfragen beim Kunden oder sonstigen Verbindungsleuten die Gründe für die Absage in Erfahrung zu bringen, falls dies nicht schon aus dem Absageschreiben hervorgeht. Dies dient dazu, die Informationsbasis für zukünftige Angebote bei diesem Kunden zu verbessern. So weit der Geschäftsprozess Angebotserstellung, der damit endet. Im positiven Fall stößt er den nachfolgend skizzierten Geschäftsprozess Auftragsabwicklung an. Wieder betrachten wir eine prototypische Situation bei einem Unternehmen des Anlagenbaus. Der Auftrag des Kunden geht immer schriftlich ein. Geht er doch mündlich ein, wird mit dem Kunden zusammen durch den Vertrieb eine kurze schriftliche „Auftragsfestlegung“ durchgeführt. Nach Eingang des Auftrags prüft der Vertriebsingenieur gegebenenfalls, ob der Auftrag mit sämtlichen ausgehandelten Konditionen bzw. dem Angebot übereinstimmt. Gibt es im Auftrag des Kunden Abweichungen vom Angebot werden diese in der Auftragsbestätigung durch für das Unternehmen akzeptable Konditionen ersetzt. Dies wird dem Kunden mitgeteilt und er wird gebeten, die Kenntnisnahme schriftlich zu bestätigen. Er füllt dann handschriftlich ein Auftragsstammblatt aus, wobei im Vertrieb gleichzeitig zentral die Auftragsnummer vergeben wird. Das ausgefüllte Auftragsstammblatt wird an den zuständigen Controller weitergeleitet, der die im Angebot bzw. im Auftrag festgelegte Kostenstruktur nach Honorar, Sachkosten, Reisekosten und Fremdleistungskosten auf dem Auftragsstammblatt vermerkt und mit Vorgaben für Budget, Ressourcenplanung, Reisekosten und Zahlungsplan versieht. Das Controlling erstellt eine Stundenvorgabe für den Projektleiter, die sich folgendermaßen errechnet: Vom beauftragten Honorar werden zunächst die Fremdleistungen und die geplanten Sachkosten (Reisekosten, Kopierkosten etc.) abgezogen. Nach Abzug eines Gewinns und einer Sicherheitsmarge in Höhe von ca. 17% ergeben sich die verfügbaren Personalkosten. Diese werden durch den Kostensatz der jeweiligen Mitarbeitergruppe geteilt. So ergibt sich die Stundenvorgabe je Mitarbeitergruppe. Alle Ingenieure im Haus sind nach den Jahren ihrer Berufserfahrung unterschiedlichen Gruppen zugeordnet. Jede Gruppe wird zu einem bestimmten Erlösstundensatz abgerechnet bzw. Kostenstundensatz belastet. Ebenso werden Sekretärinnen, studentische Hilfskräfte, Übersetzer, Technische Zeichner usw. mit bestimmten Kostensätzen eingerechnet.

Zustellung und Warten

Absage und Nachfragen

Geschäftsprozess Auftragsabwicklung Vgl. Abschnitt 6.4 für eine Darstellung als Ereignisgesteuerte Prozesskette

Vorgaben

26

Kostensätze

Rechnungsstellung

Auftrag in die EDV

Auftragsbestätigung

2 Geschäftsprozesse

Dabei werden drei Stufen unterschieden. Der erste Kostensatz ergibt sich aus dem jeweiligen Gehalt des Mitarbeiters. Die Hinzurechnung der direkten bereichsspezifischen Gemeinkosten ergibt den zweiten Kostensatz. Die weitere Addition des unternehmensspezifischen Gemeinkostensatzes ergibt den endgültigen dritten Kostensatz. Der Controller ermittelt die Rechnungsstellungstermine aufgrund der vertraglichen Vereinbarungen. Bei Honorar nach Aufwand wird nur der Abrechnungsmodus (wöchentlich, monatlich, vierteljährlich, usw.) vermerkt. Bei Pauschalaufträgen sind die Rechnungsstellungstermine in der Regel an den Projektfortschritt gekoppelt und fallen mit Meilensteinen der Projektabwicklung zusammen. Bei den Rechnungsstellungsterminen für diese Aufträge werden die abzurechnenden Beträge bzw. der Prozentanteil des Honorars vermerkt. Nach Ermittlung der Rechnungsstellungstermine werden dem Kunden durch den Vertrieb die Zahlungstermine mitgeteilt. Parallel hierzu erfolgt die Anlage des Auftrags im DV-System durch das Controlling. Das durch die Abteilung Auftragsabwicklung vervollständigte Auftragsstammblatt wird zur Erstellung der Auftragsmeldung an den Vertrieb zurückgegeben. Die ausgedruckte Auftragsmeldung wird mit den entsprechenden Anlagen (Angebot, Vertrag und sonstige für die Vertragsausführung erforderlichen Dokumente) archiviert. Außerdem werden vom Controlling Kopien an den für die Bearbeitung zuständigen Technikbereich weitergeleitet. Parallel zur internen Meldung über das Auftragsstammblatt hat der Vertriebsingenieur die externe Auftragsbestätigung an den Kunden zu erstellen. Erfolgte der Auftrag schriftlich und hat der Auftraggeber bereits eine Auftragsbestätigung mitgeschickt, wird diese unterschrieben zurückgesandt. Sonst wird eine kurze Auftragsbestätigung vom zuständigen Vertriebsingenieur erstellt. In dieser werden auch die zuständigen technischen Ansprechpartner und der Projektleiter vermerkt. Letzterer setzt sich dann mit dem Kunden in Verbindung, um die Arbeitsaufnahme zu besprechen. Erfolgte die Beauftragung mündlich, wird ein Auftragsbestätigungsschreiben mit sämtlichen besprochenen Konditionen verfasst und um schriftliche Bestätigung des Kunden gebeten. So weit die beiden, zugegeben kurzen Beispiele. Sie zeigen, obwohl die Geschäftsprozesse selbst nicht komplex sind, dass die textliche Beschreibung sehr schnell unübersichtlich und umfangreich wird. Das ist ein Grund, weshalb sich grafische Notationen zur Beschreibung von Geschäftsprozessen durchgesetzt haben. Die wichtigste, von Scheer begründete und von der SAP zur Blüte gebrachte, ist die der Ereignisgesteuerten Prozessketten, die im Mittelpunkt dieser Arbeit stehen.

2.10 Das ARIS-Konzept

27

2.10 Das ARIS-Konzept ARIS (Architektur integrierter Informationssysteme) bezeichnet das von Scheer entwickelte Konzept, das in >Scheer 1997@ beschrieben ist. Wegen seiner großen Bedeutung - nicht nur in theoretischer sondern auch in praktischer Hinsicht - soll es hier kurz vorgestellt werden.22 Das ARIS-Konzept ist prozessorientiert, d.h. es empfiehlt die Wahrnehmung der betrieblichen Realität als ein zielgerichtetes Miteinander von Geschäftsprozessen. Neben einer integrierten Betrachtung Computergestützter Informationssysteme unterscheidet Scheer verschiedene isoliert zu betrachtende Aspekte, die er Sichten nennt: x x x x x

Sichten

Datensicht Funktionssicht Organisationssicht Ressourcensicht Steuerungssicht

Die Datensicht erfasst die Zustände und Ereignisse, die durch Daten repräsentiert werden. Gemeint sind die Daten der Datenbank, die mithilfe eines Datenmodells erstellt wurden. Das von Scheer hierfür verwendete Werkzeug sind ER-Modelle. Die Funktionssicht meint die auszuführenden Funktionen und deren Zusammenhang. Hierzu gehört die Beschreibung der Funktion, die Aufzählung der einzelnen Teilfunktionen sowie die zwischen den Funktionen bestehenden Anordnungsbeziehungen. Sie werden z.B. durch Funktionsbäume erfasst. Bearbeiter und Organisationseinheiten machen die Organisationssicht aus. Das Darstellungsmittel sind hier z.B. Organigramme. Mit dem Begriff Ressourcensicht sind die Komponenten der Informationstechnik gemeint. Sie zielt somit auf die konkrete Hardware und Software. Den integrativen Aspekt betont wiederum die Steuerungssicht. Sie soll die Verbindung zwischen den anderen Sichten deutlich machen. Zentral ist hier die Geschäftstätigkeit, der letztendlich alle übrigen Ressourcen dienen. Die zentrale Modellierungstechnik ist hier die Ereignisgesteuerte Prozesskette. Insgesamt empfiehlt der Ansatz somit, neben der integrierten Betrachtung der Geschäftsprozesse auch den durch die Sichten spezifizierten. Diese entsprechen im Übrigen den überkommenen Vorgehensweisen, wo

22

Architektur integrierter Informationssysteme

Ansätze zur Entwicklung rechnergestützter prozessorientierter Informationssysteme sind ARIS - House of Business Engineering (vgl. [Scheer 1998b]) sowie Baan - Dynamic Enterprise Modeling (vgl. [Rodim van Es 1996]). Kurzbeschreibungen finden sich in [Amberg 1999, S. 48ff].

Datensicht

Funktionssicht

Organisationssicht Ressourcensicht

Steuerungssicht

28

2 Geschäftsprozesse

natürlich auch Datenstrukturen, Organisationsstrukturen, usw. analysiert wurden. Scheer nimmt nun bei der weiteren Entwicklung seines Ansatzes an dieser Stelle die Ressourcensicht heraus und stellt die übrigen in die genannte Beziehung zueinander. Sozusagen die grafische Repräsentation seines Ansatzes zeigt die folgende Abbildung.

Abbildung 2.10-1: Beschreibungsebenen

Eine zweite wichtige Dimension, in der jedes Informationssystem angeordnet ist, kann durch die Nähe zur Informationstechnik definiert werden. Für diese Beschreibungsebenen wählt Scheer eine „dreistufige Abschichtung“: x x x

Fachkonzept

Die „Sichten“ der ARIS-Architektur Quelle: >Scheer 1996, S. 14@

Fachkonzept (Semantische Modelle) DV-Konzept Technische Implementierung

Mit dem Begriff Fachkonzept beschreibt Scheer so etwas wie die Semantik eines Anwendungsbereichs, die natürlich umfassend beschrieben werden muss: „Deshalb wird in einem Fachkonzept das zu unterstützende betriebswirtschaftliche Anwendungskonzept in einer soweit formalisierten Sprache beschrieben, dass es Ausgangspunkt einer konsistenten Umsetzung in die Informationstechnik sein kann.“ >Scheer 1998a, S. 15@.

DV-Konzept

Das Fachkonzept ist von besonderer Bedeutung, da es „langfristiger Träger des betriebswirtschaftlichen Gedankengutes ist“ (ebenda S. 16) Im DV-Konzept wird das Fachkonzept in die „Kategorien der DVUmsetzung“ übertragen. Anstelle von Funktionen treten die sie ausführenden Modelle oder Benutzertransaktionen. Somit handelt es sich um ei-

2.10 Das ARIS-Konzept

29

ne „Anpassung der Fachbeschreibung an die generellen Schnittstellen der Informationstechnik“ (ebenda, S. 15). Mit der dritten Ebene, der Technischen Implementierung, ist die konkrete technische Implementierung der Datenverarbeitung gemeint. Scheer verknüpft nun die zwei Dimensionen (Sichten und Beschreibungsebenen) seines Ansatzes und schlägt vor, in jeder Sicht diese drei Ebenen zu unterscheiden. Die graphische Repräsentation dieser Überlegung zeigt die folgende Abbildung. Über der Abbildung ist die Realwelt, die z.B. aus den Strukturen und Abläufen eines Unternehmens besteht, als Betriebswirtschaftliche Problemstellung miteingefügt. Zusammengefasst schlägt dieser theoretische Ansatz somit vor, bei der Analyse und Gestaltung Computergestützter Informationssysteme die Sichten zu unterscheiden und in diesen jeweils die drei Ebenen der DV-Gestaltung. Damit lassen sich, wie auch die Abbildung zeigt, in der ARIS-Architektur 13 Bereiche unterscheiden, wenn man die Betriebswirtschaftliche Problemstellung mit dazu nimmt. Für jeden dieser Bereiche stellt Scheer geeignete Methoden für den Aufbau und die Analyse des Informationssystems vor. Im Rahmen dieser Arbeit sind davon nur die der Fachkonzeptsebene von Interesse, weil diese die Abbildung der betrieblichen Weltausschnitte in die Software zum Gegenstand haben. Für die Betriebswirtschaftliche Problemstellung schlägt Scheer Vorgangskettendiagramme (VKD) vor. Nach den Erfahrungen des Verfassers wird in der Praxis in dieser Phase allerdings meist nicht zu formalen Techniken, sondern zu textlichen Beschreibungen gegriffen. Vorgangskettendiagramme und Hinweise für deren Aufbau finden sich in [Scheer 1997]. Vgl. zum Beispiel die dortige Abbildung A.II.01 für ein Soll-Konzept einer Kundenauftragsbearbeitung. In [Scheer 1997] dienen Vorgangskettendiagramme auch zur überblicksartigen Einführung neuer Geschäftsprozesse.

Technische Implementierung

Methoden

Betriebswirtschaftliche Problemstellung

30

2 Geschäftsprozesse

Abbildung 2.10-2:

Beschreibungsebene Fachkonzept

Die „Sichten“ + „Beschreibungsebenen“ der ARIS-Architektur Quelle: >Scheer 1996, S. 17@

Auf Fachkonzeptsebene schlägt Scheer für die Funktionssicht Hierarchiediagramme (Funktionsbäume) vor. Die Zerlegung soll dort enden, wo Funktionen erreicht werden, die in einem Arbeitsablauf bearbeitet werden (Elementarfunktionen). Funktionsbäume sind statisch, d.h. die Reihenfolge in der die Teilfunktionen abgewickelt werden, ist nicht ersichtlich. Für die Organisationssicht empfiehlt er Organigramme. Als Verknüpfungsart zwischen Organisationseinheiten wird die Weisungsbefugnis gewählt. Für die Datensicht wählt er ER-Modelle23, mit einigen Änderungen gegenüber der Standardterminologie. Die Steuerungssicht wird u.a. durch Prozessmodelle erfasst. Die folgende Abbildung deutet in grafischer Form die Methoden für die jeweilige Komponente der ARIS-Architektur an.

23

„ER“ steht für Entity Relationship. ER-Modellierung stellt den wichtigsten Ansatz in der sog. Semantischen Datenmodellierung dar.

2.10 Das ARIS-Konzept

Abbildung 2.10-3:

31

„Sichten“ + „Beschreibungsebenen“ + „Methoden“ der ARIS-Architektur Quelle: >Scheer 1996, S. 82@

Das ARIS-Konzept wurde in eine Software umgesetzt, die es erlaubt, alle Modelle der Fachkonzeptsebene zu verwalten. Ihr Name ist ARIS-Toolset. Mit ihr können somit Ereignisgesteuerte Prozessketten und andere Modelle der Unternehmensmodellierung betrachtet, verändert und erstellt werden.

Software und Modelldatenbank(en)

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

3.1

Definition und Abgrenzung

Ein Softwaretyp, dessen Urheber eine effiziente Lösung für das DV-Problem aller Unternehmen anbieten, hat sich auf breiter Front durchgesetzt24. Er wird unterschiedlich benannt, z.B. Standardlösung, Standardsoftware, Unternehmensweite Komplettlösung, Betriebswirtschaftliche Software oder auch ERP-Software25. Hier soll er Betriebswirtschaftliche Standardsoftware genannt werden, weil diese Software (idealtypisch) folgende Eigenschaften hat: x x x

24 25

26

27

28 29

Sie ist prozessorientiert in dem Sinn, dass sie ganze Geschäftsprozesse unterstützt26 und nicht nur einzelne Funktionen27. Sie unterstützt alle Geschäftsprozesse des kaufmännischen bzw. betriebswirtschaftlichen Bereichs28 eines Unternehmens einschließlich der Produktionsplanung (1. Integrationsaspekt). Sie ist für die konkreten Strukturen und Geschäftsprozesse vieler Unternehmen geeignet (2. Integrationsaspekt)29.

“Unternehmen” steht hier für Organisationen aller Art, denn diese Problematik ist überall von Bedeutung, wo Software zur Unterstützung der Aufgabenerfüllung eingesetzt wird. Dieser Begriff scheint sich zumindest in den Presseveröffentlichungen durchzusetzen. ERP steht für Enterprise Resource Planning „und ist als Fortführung von MRP (Material Requirements Planning) und MRP II (Manufacturing Resource Planning) zu verstehen.“ [zur Mühlen 2000, S. 286] "Unterstützung" meint hier, dass die einzelnen Tätigkeiten des Geschäftsprozesses mit mehr oder weniger DV-Unterstützung realisiert werden. Der Käufer einer betriebswirtschaftlichen Standardsoftware findet also nicht nur die übliche Abdeckung einzelner betrieblicher Funktionen vor, sondern bereits fertige Programme für ganze Geschäftsprozesse, z.B. zum Controlling, zur Finanzbuchhaltung, usw. oder für den gesamten kaufmännischen Bereich. Prozessorientierung vs Funktionsorientierung: Software kann sich auf einzelne Funktionen beziehen, d.h. diese unterstützen bzw. ganz oder teilweise selbst übernehmen (funktionsorientierte Software). Zum Beispiel Textverarbeitung oder Grafikerstellung. Sie kann aber auch ganze Geschäftsprozesse (bzw. Abläufe) unterstützen. Vgl. die Diskussion dieser Abgrenzung in der Einleitung. Mit den beiden Integrationsaspekten ist dieser Softwaretyp von Textverarbeitungen, Tabellenkalkulationen, usw. abgegrenzt, die ja auch als Standardsoftware bezeichnet werden.

Viele Namen, ein Softwaretyp

34

Überbetriebliche Geschäftsprozesse

Prozessorientiert

Das Konzept

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

Inzwischen sind diese Produkte auch auf die Abwicklung zwischenund überbetrieblicher Geschäftsprozesse vorbereitet, z.B. durch die entsprechenden Schnittstellen, und darauf, mit entsprechender Software, zum Beispiel zum Supply Chain Management oder zum Customer Relationship Management zu kooperieren. Der in Kapitel 2 diskutierte Geschäftsprozessbegriff ist damit von zentraler Bedeutung für Betriebswirtschaftliche Standardsoftware, da diese prozessorientiert ist in dem Sinne, dass sie integriert die gesamten Geschäftsprozesse eines Unternehmens unterstützt und nicht nur einzelne Funktionen, wie frühere, ältere oder andere Software. Dies ist eine Anforderung, die funktionsorientierte Software wegen ihrer Beschränkung in weit geringerem Umfang zu erfüllen hat. Gleichzeitig soll sie aber auch die Geschäftsprozesse möglichst vieler Unternehmen unterstützen, was letztendlich dazu führt, dass sie, basierend auf dem Geschäftsprozesskonzept, „verallgemeinerbar“ sein muss. Damit beruht Betriebswirtschaftliche Standardsoftware auf einer Annahme, die sich wie folgt formulieren lässt: Es ist möglich, für die Anforderungen heutiger Unternehmen eine gemeinsame, integrierte und prozessorientierte Software zu erstellen. Dies beruht auf zwei Eigenschaften heutiger Geschäftsprozesse: 1) Die meisten Geschäftsprozesse sind standardisiert30, d.h. sie laufen bei Wiederholung gleich ab. 2) Es gibt so viele Gemeinsamkeiten zwischen den Geschäftsprozessen verschiedener Unternehmen, dass es möglich ist, eine gemeinsame „Software von der Stange“ zu schreiben.

„Durchschnittliche“ und vorgedachte Geschäftsprozesse

Um dies leisten zu können, hat Betriebswirtschaftliche Standardsoftware verschiedene Bedingungen zu erfüllen. Die wichtigste ist, dass sie Modelle von Geschäftsprozessen in ihrer Datenbank und in ihren Programmen realisiert haben muss und dass diese – mithilfe entsprechender Analysen realer Geschäftsprozesse - den tatsächlichen Abläufen und Strukturen in den Unternehmen möglichst ähnlich sein müssen. Denn natürlich gibt es zwischen den Geschäftsprozessen der einzelnen Unternehmen trotz aller Ähnlichkeit Unterschiede, sodass eine so konzipierte Software den realen Geschäftsprozessen immer nur mehr oder weniger ähnlich, aber nicht voll mit ihnen übereinstimmend sein kann. Die folgende Abbildung versucht dies zu visualisieren. Stellen wir uns vor, wir könnten einen Geschäftsprozess als Linie darstellen und seine Abweichungen von einem virtuellen „durchschnittlichen“ Geschäftsprozess als Ausschläge dieser Linie. Dann könnten die drei von oben nach unten verlaufenden Linien drei Geschäftsprozesse darstellen, z.B. zur

30

Im Alltagsgeschäft äußert sich dies oftmals sehr wohltuend als Routine.

3.1 Definition und Abgrenzung

35

Auftragsabwicklung, die unterschiedlich stark vom „Durchschnitt“ abweichen. Die mit unterschiedlichen Grauschattierungen angelegten Säulen sollen verschiedene Bereiche der Software darstellen (in einem im Folgenden erklärten Sinn). Betrachtet man eine große Zahl vergleichbarer Geschäftsprozesse (z.B. zur Angebotserstellung) in verschiedenen Unternehmen kann man bezüglich des Grades ihrer Übereinstimmung unterschiedliche Bereiche erkennen. Zuerst einen Kernbereich, den mehr oder weniger alle Geschäftsprozesse in den betrachteten Unternehmen gemeinsam haben. Er wird in der folgenden Abbildung durch die innerste Säule repräsentiert. Dieser Kernbereich erfasst so etwas wie den durchschnittlichen Geschäftsprozess bzw. die übereinstimmenden Teile der Geschäftsprozesse zum jeweiligen Bereich. Er sollte von der Betriebswirtschaftlichen Standardsoftware möglichst umfassend abgedeckt werden. Im Erkennen dieses Kernbereichs steckt eine große Aufgabe für die Modellierer und Programmierer der Standardsoftwareproduzenten. Sie müssen nicht nur viele vergleichbare Geschäftsprozesse kennen, sondern sie müssen in der Lage sein, die Gemeinsamkeiten festzustellen. Liegt eine Betriebswirtschaftliche Standardsoftware hier „schief“, erhöht sich der Aufwand bei der Einführung der Software in einem Unternehmen beträchtlich. Der Erfolg einer solchen Software hängt somit wesentlich von der Qualität der so „vorgedachten“ Geschäftsprozesse ab. Ein zweiter Bereich sollte durch das Verstellen von Parametern realisierbar sein. D.h., die Software sollte ohne Programmierung an die hier vorliegenden Besonderheiten angepasst werden können. Damit ist ein Teil der „Streuung“ der Geschäftsprozesse auf relativ einfache Weise in der Software abbildbar. In der Abbildung wurde dieser Bereich Parameterbereich genannt und durch eine zweite Säule repräsentiert. Auch dieser muss beim Design der Standardsoftware gut bedacht werden. Er sollte alle die Modifikationen der ausgelieferten Betriebswirtschaftlichen Standardsoftware ermöglichen, die mit einer gewissen Wahrscheinlichkeit bei den Kunden erwartet werden können. Dies beginnt bei der Änderung von Menüleisten (einige der voreingestellten Punkte kommen weg, andere dazu) bis zur Veränderung des Ablaufs. Ein dritter Bereich der Besonderheiten konkreter Geschäftsprozesse kann - idealtypisch - durch Programmierung mit einem Werkzeug erreicht werden, das mit der Standardsoftware mitgeliefert wird (interne Programmierung). Im Falle von SAP R/3 z.B. mit ABAP. Hiermit wird ein weiterer Teil der konkret vorkommenden Vielfalt realer Geschäftsprozesse in der Standardsoftware realisierbar. In der Abbildung wurde dieser Bereich Programmierbereich 1 genannt und durch eine weitere Säule visualisiert. Bei vielen Unternehmen bleibt darüber hinaus ein Rest an Besonderheiten, der nur durch Programmierung mit Werkzeugen (derzeit oft ob-

Der Kernbereich

Der Parameterbereich

Programmierbereich 1

Programmierbereich 2

36

Defizite

Warum nicht „Alles“?

Parametrisierbarkeit

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

jektorientierte) realisiert werden kann, die nicht mit der Betriebswirtschaftlichen Standardsoftware mitgeliefert werden. Diese externe Programmierung soll Programmierbereich 2 genannt werden. Natürlich werden hier oft auch fertig eingekaufte oder andere ergänzende Programme eingesetzt. Dieser Bereich müsste eigentlich für die Standardsoftwarehäuser von großem Interesse sein, spiegelt er doch am deutlichsten die aus Kundensicht bestehenden Defizite wieder. Daneben haben diese starken Abweichungen vom „durchschnittlichen“ Geschäftsprozess noch eine andere Bedeutung. Oftmals versuchen Unternehmen, sich hier zu profilieren, versuchen den Gefahren der Standardlösung zu entkommen und dem drohenden Profilverlust zu begegnen (vgl. unten). Dies betrifft dann meist die Kernprozesse und kann von der Produktionsplanung bis zur Verwaltung der Kundendaten (z.B. im Versicherungsbereich) oder einer besseren Unterstützung der Vorgangsbearbeitung (workflow) reichen. Es versteht sich, dass der Aufwand des Kunden bei der Einführung Betriebswirtschaftlicher Standardsoftware umso größer wird, je mehr Anpassungsarbeiten (außerhalb des Kernbereichs) zu leisten sind. An dieser Stelle sollte die Frage gestellt werden, warum Betriebswirtschaftliche Standardsoftware nicht einfach „alles“ (z.B. alle unterschiedlichen Variationen eines konkreten Geschäftsprozesses) realisiert. Die Antwort ist einfach. Erstens weil es schlicht nicht möglich ist, angesichts der begründeten und unbegründeten riesigen Vielfalt in den Unternehmen. Zweitens weil jeder Versuch der Ausdehnung des Kernbereichs die Komplexität der Software stark erhöht und damit die Gefahren durch die Komplexitätsfalle (vgl. unten) immer größer werden lässt. Insgesamt kann festgehalten werden, dass Betriebswirtschaftliche Standardsoftware softwaretechnisch so realisiert sein muss, dass sie in einem gewissen Umfang an die realen Strukturen des jeweiligen Unternehmens angepasst werden kann. Die Möglichkeit der Anpassung durch das Verstellen von Parametern ist konstituierend für Betriebswirtschaftliche Standardsoftware.

3.1 Definition und Abgrenzung

Abbildung 3.1-1:

37

Geschäftsprozessvarianz und ihre Konsequenzen

Aus Obigem folgt, dass Betriebswirtschaftliche Standardsoftware nicht nur, wie z.B. Datenbanksysteme, die Modellierung von Datenstrukturen erlaubt bzw. verlangt, sondern auch die von Geschäftsprozessen und das heißt konkret: von betrieblichen Abläufen wie sie zur Aufgabenerfüllung im Unternehmen anfallen. In dieser Sichtweise ist Betriebswirtschaftliche Standardsoftware eine natürliche und folgerichtige Weiterentwicklung von Datenbanksystemen. Doch nun zurück zu den oben angeführten Definitionsmerkmalen. Zumindest vom Grundprinzip her soll dieser Softwaretyp möglichst alle betriebswirtschaftlichen/kaufmännischen Bereiche einschließlich der Produktionsplanung umfassen. Etwas genauer kann die Abgrenzung mit dem Ansatz von Scheer31 bzw. Mertens32 vorgenommen werden, da diese die horizontale Integration (über die klassischen Bereiche wie Produktion, Beschaffung, Lager31 32

“Integrierte Informationssysteme”, vgl. >Scheer 1997, S. 4ff@. “Gesamtkonzeption der Integrierten Informationsverarbeitung”, vgl. >Mertens 1995, S. 5ff@.

Nicht nur Datenstrukturen

1. Integrationsaspekt

Genauere Abgrenzung

38

2. Integrationsaspekt

Branchensoftware

Individualsoftware

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

haltung, Rechnungswesen, Personal, usw.) von der vertikalen (zwischen Administrations- und Dispositionssystemen, Wertorientierten Abrechnungssystemen, Berichts- und Kontrollsystemen, usw.) unterscheiden (vgl. die Visualisierung in den “Pyramiden” in beiden Quellen). Davon ausgehend kann festgestellt werden, dass heutige Betriebswirtschaftliche Standardsoftware bei den Wertorientierten Abrechnungssystemen ihren Schwerpunkt hat, mehr oder weniger gut auch die Ebene der Mengenorientierten Operativen Systeme abdeckt (ohne Forschung/Entwicklung und die eigentliche Produktionssteuerung), sich auch zunehmend in die Berichts- und Kontrollsysteme33 hinein ausdehnt, darüber hinaus aber noch nicht viel anzubieten hat. Diese Eigenschaft von Betriebswirtschaftlicher Standardsoftware, weite Teile der betriebswirtschaftlich/kaufmännischen Geschäftsprozesse abzudecken, wurde oben schon 1. Integrationsaspekt genannt. Hintergrund davon ist der Anspruch, das gesamte Informationssystem des beschriebenen Bereichs integriert zu organisieren. Zum einen, was die Daten angeht, am besten in einer einzigen unternehmensweiten Datenbank, zum anderen bezüglich der von der Software zur Verfügung gestellten Funktionalitäten. Dieses Ziel wird heute nur von wenigen konkreten Systemen erreicht. Die meisten decken nur einen bestimmten Bereich ab, z.B. das Finanzwesen oder die Fertigungssteuerung. Dieser erste Integrationsaspekt hat auch etwas mit dem Ziel der Optimierung der innerbetrieblichen Abläufe und der schlankeren Gestaltung des Informationssystems zu tun, denn beides kann nur realisiert werden, wenn die Integration der verschiedenen betriebswirtschaftlichen Anwendungsprogramme gelingt. Der 2. Integrationsaspekt meint den Umstand, dass Betriebswirtschaftliche Standardsoftware vielen unterschiedlichen Unternehmen dienen soll. Auch diese Eigenschaft kann nur mithilfe einer fundierten Analyse der Geschäftsprozesse – über verschiedene Unternehmen hinweg – realisiert werden. Diese ist Teil des durch die beiden Integrationsaspekte erzwungenen unabdingbaren tragfähigen Modellierungskonzepts. Mit ihr verlässt das jeweilige Softwarehaus außerdem den nicht mehr besonders profitablen Bereich der „Einzelfertigung“ und geht zur lukrativeren „Serienfertigung“ über. Ist der Bereich, den eine Betriebswirtschaftliche Standardsoftware abdecken soll, auf eine bestimmte Branche begrenzt, wird sie zur Branchensoftware. Dann verlagert sich der oben angesprochene Kernbereich in Richtung der spezifischen Strukturen und Abläufe dieser Branche. Das Gegenstück zu Standardsoftware ist Software, die für ein bestimmtes Unternehmen und die dort vorliegenden Abläufe und Strukturen gefertigt wurde. Sie wird Individualsoftware genannt und kann von den eigenen Entwicklern des Unternehmens oder von einem Softwarehaus stammen. 33

Die heute unter dem Stichwort Data Warehouse diskutiert werden.

3.1 Definition und Abgrenzung

39

Bei voller Umsetzung des Standardsoftwareprinzips gehört zu Betriebswirtschaftlicher Standardsoftware eine zentrale unternehmensweite Datenbank. Diese wiederum muss auf einem unternehmensweiten Datenmodell basieren, mit dem die Geschäftsprozesse unterstützt werden. Grundlage betriebswirtschaftlicher Standardsoftware ist damit eine möglichst umfassende Analyse der in den Unternehmen konkret vorliegenden Geschäftsprozesse. Versetzen wir uns in die Position der Ersteller von Standardsoftware, besteht die zu lösende Aufgabe in Folgendem: x x x x

x x x

Grundlage

Herausfinden der Gemeinsamkeiten all der verschiedenen Realisationen eines konkreten Geschäftsprozesses (z.B. einer Auftragsabwicklung). Dabei entsteht eine Art „durchschnittlicher Geschäftsprozess.“ Festlegen von als „sinnvoll“ erachteten Abweichungen (vom „durchschnittlichen Geschäftsprozess“), die ebenfalls in der Software realisiert werden. Eventuelle Miteinbeziehung neuer Methoden für den jeweiligen Geschäftsprozess (z.B. neuer Verfahren der Absatzplanung in den entsprechenden Geschäftsprozess). Anbieten eines Instrumentariums, mit dem die Kunden dann ihre Variante der Geschäftsprozesse festlegen können (Customizing bzw. Parametrisierung).

Mit dem Begriff Customizing wird die Anpassung der Standardsoftware an die realen Prozesse beschrieben. Zumindest der größere Teil dieser Anpassung soll bei Standardsoftware so ablaufen, dass nicht programmiert werden muss, sondern dass nur die wie auch immer gestalteten Parameter der Standardsoftware verstellt werden. Ein eventueller Rest kann dann mit einer mitgelieferten Programmiersprache (bei R/3 z.B. ABAP) erledigt werden. Die Eigenschaften Betriebswirtschaftlicher Standardsoftware sind somit (idealtypisch): x

Zentrale unternehmensweite Datenbank

Sie umfasst den gesamten betriebswirtschaftlichen Bereich, evtl. einschließlich der Produktionsplanung (1. Integrationsaspekt). Sie ist geeignet für „viele“ Unternehmen (2. Integrationsaspekt). Sie beruht auf einer integrierten Datenbank mit einem integrierten Datenmodell, idealtypisch mit einem unternehmensweiten Datenmodell. Sie realisiert in Datenbank und Programmen vorgedachte Geschäftsprozesse, ist aber in einem gewissen Umfang anpassbar an die konkreten Geschäftsprozesse (Parametrisierbarkeit) in folgenden Stufen: a) durch Verstellen von Parametern b) durch „interne Programmierung“ (d.h. durch Nutzung mitgelieferter Programmierwerkzeuge, wie z.B. ABAP 4 bei R/3) c) durch „externe Programmierung“, d.h. durch Nutzung externer Werkzeuge. Die damit erstellten Programme müssen dann über die zur Verfügung stehenden Schnittstellen mit der Betriebswirtschaftli-

Customizing

Zusammenfassung.

40

x x

3.2

DV-Durchdringung

Immer mehr, immer tiefer

Ausdruck und Verstärker eines Trends

Mehr Transparenz

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

chen Standardsoftware kommunizieren. Besonders oft ist dieser Weg derzeit in den Bereichen Workflow und Data Warehouse anzutreffen. Sie ist prozessorientiert. Sie hat einen sehr großen Leistungsumfang

Begleiterscheinungen

Ein Softwaretyp, der eine so umfassend neue Sichtweise der Unternehmensrealität umsetzt, hat verschiedene Begleiterscheinungen, Folgen und auch Voraussetzungen, die im Folgenden kurz diskutiert werden. Seit dem Beginn des DV-Zeitalters ist in den Industrienationen ohne Schwierigkeit eine ständig zunehmende Durchdringung der Unternehmen mit Informationstechnologien zu beobachten. In der Sprache dieses Textes: Die Geschäftsprozesse wurden und werden immer mehr durch Datenverarbeitung gestützt bzw. gestaltet. Diese Entwicklung hat einen quantitativen und einen qualitativen Aspekt. Zum einen dehnte sich die Softwareunterstützung immer mehr aus, von der Unterstützung einzelner weniger Funktionen bis zur heutigen flächendeckenden Geschäftsprozessunterstützung. Zum anderen wurde und wird die Prozessunterstützung immer detaillierter. Wurden anfangs in den Geschäftsprozessen nur einzelne Funktionen und die Informationsflüsse zwischen ihnen unterstützt, geht es heute teilweise schon fast bis auf die tayloristische Ebene. So erlebte der Verfasser vor einiger Zeit ein Programm, das im Rahmen der Unterstützung der Versandabwicklung die Kommissionierung in Realzeit optimierte und die Kommissionierer/innen per Funk und Display bei ihrer Tätigkeit steuerte. Neuester Ausdruck dieser Entwicklung ist Betriebswirtschaftliche Standardsoftware, die im Kern von einer völligen Unterstützung aller betrieblichen Abläufe durch die Datenverarbeitung ausgeht. Betriebswirtschaftliche Standardsoftware ist Ausdruck dieses Trends der zunehmenden quantitativen (immer mehr Bereiche) und qualitativen (immer detaillierter) DV-Durchdringung, gleichzeitig verstärkt sie ihn aber auch, denn für viele Unternehmen wäre eine vergleichbar intensive Durchdringung mithilfe von Individualsoftware nicht bezahlbar. Die Einführung Betriebswirtschaftlicher Standardsoftware in einem Unternehmen ist zwangsläufig mit einer mehr oder weniger intensiven Analyse der Geschäftsprozesse verbunden. Auch wenn bei diesem Punkt in vielen Unternehmen (zu) sehr gespart wird, ist doch eine minimale Auseinandersetzung mit den konkreten Abläufen unerlässlich. Wünschenswert ist allerdings eine intensive, wenn auch nicht ausufernde Auseinandersetzung, da nur damit eine stabile Einführung und Nutzung der Betriebswirtschaftlichen Standardsoftware möglich ist. Auf jeden Fall werden aber die Abläufe und Strukturen durchleuchtet, meist auch (zumindest etwas) optimiert und damit transparenter gemacht.

3.2 Begleiterscheinungen

41

Ein großes Problem der nächsten Jahre, das nicht in erster Linie mit Betriebswirtschaftlicher Standardsoftware zu tun hat, sondern mit Software ganz allgemein und das durch Erstgenannte lediglich verstärkt und modifiziert wird, ist der Verlust an Flexibilität. Stellen wir uns für die weiteren Überlegungen vier konkrete Realisierungen eines Geschäftsprozesses vor: x x x x

Flexibilität und Zementierung

Völlig durch Menschen realisiert, ohne Programme Nur einzelne Funktionen durch EDV unterstützt, z.B. die Textverarbeitung, Datenhaltung, Datenauswertung Einzelne Abschnitte durch EDV unterstützt Völlig durch EDV realisiert, Menschen greifen nur noch bei Entscheidungen und als Informationslieferanten ein

Wenn auch die erste Variante mangels Produktivität keinerlei Chancen auf Umsetzung mehr hätte, nimmt in dieser Abfolge die Produktivität von oben nach unten ständig zu und die Flexibilität ab. Es ist angesichts der heutigen Softwaretechnologie in der Regel immer noch leichter, Menschen an einen geänderten Ablauf anzupassen als Software. Werden Geschäftsprozesse erst mal umfassend durch Software unterstützt, ist jede Veränderung der Abläufe oder der Strukturen mit einer Anpassung der Software verbunden. Da sich die Realwelt ständig verändert, ist deshalb die Anpassbarkeit Betriebswirtschaftlicher Standardsoftware an reale Strukturen ein unabdingbares Merkmal, nicht nur bei der Einführung. Trotzdem bleibt der Änderungsaufwand und der damit verbundene Verlust an Flexibilität. Nimmt man die Aussage von Chandler ernst, dass eine veränderte Strategie auch einer veränderten Organisationsstruktur bedarf (vgl. [Chandler 1962]), dann wird die Bedeutung dieser Zementierung der Geschäftsprozesse durch Betriebswirtschaftliche Standardsoftware besonders deutlich, zumindest, wenn sie bei Kernprozessen vorliegt. Denn die heutige Situation ist dadurch gekennzeichnet, dass die Zahl der Strategieanpassungen im Zeitverlauf eher zu- als abnimmt. Eine wichtige Frage bei der Einführung von Standardlösungen in einem Bereich ist, welche Geschäftsprozesse dafür geeignet sind. Prozessorientierte Software tut sich leicht bei standardisierten Abläufen, schwer dagegen in Weltausschnitten, die sich ständig verändern oder bei Prozessen, deren konkrete Einzeltätigkeiten schwer vorherbestimmbar sind („Erarbeitung eines neuen Marketingkonzepts“). Man stelle sich zur Veranschaulichung die diesbezüglich eher stabilen Strukturen im Personalwesen und dagegen die viel „lebhafteren“ Abläufe im Marketing, in der Entwicklung und Forschung vor. Hier sind Programme, mit denen lediglich einzelne Funktionen unterstützt werden (Textverarbeitung, Datenbanksystem, Tabellenkalkulation) sehr viel angemessener. Hat ein Unternehmen Betriebswirtschaftliche Standardsoftware eingeführt, erfolgen Weiterentwicklung und Wartung außerhalb des eigenen

Strategie und Struktur

In welchen Bereichen?

Fremdbestimmung?

42

Abhängigkeiten

Keine eigenen Entwickler

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

Unternehmens34. Die Innovation ist im Wesentlichen verlagert auf das Softwarehaus, das auch das volle Entwicklungsrisiko trägt. Natürlich nimmt das Standardsoftwarehaus (wenn es kompetent ist) ständig die Veränderungen der Geschäftsprozesse in den Unternehmen wahr (auch in Form von Veränderungsvorschlägen der Kunden) und versucht, seine Strukturen anzupassen, aber dies ist eine völlig andere Situation als bei einer eigenen Entwicklermannschaft im Haus. Durch Betriebswirtschaftliche Standardsoftware entsteht damit eine große Abhängigkeit vom Softwarehersteller. Sie ist mit der Abhängigkeit vergleichbar, die gegenüber dem Anbieter von Individualsoftware besteht, allerdings sind die Gewichte sehr unterschiedlich. Die großen Anbieter von Standardsoftware haben ein so großes Gewicht, dass zumindest ein einzelner Kunde (ein einzelnes Unternehmen) schwerer Gehör findet als z.B. bei einem regionalen Ersteller von Individualsoftware. Obige Abhängigkeit hat als Kehrseite die Unabhängigkeit von eigenen Entwicklern. Diese werden, wie natürlich auch beim externen Erstellen von Individualsoftware, überflüssig - mit allen Konsequenzen. Während der Bedarf an Entwicklern in diesem Bereich35 radikal sinkt, bleibt oder wächst der an Betriebswirten mit DV-Kompetenz oder Wirtschaftsinformatikern, weil betriebswirtschaftliche Kompetenz bei der Einführung und Pflege dieser Software eine große Rolle spielt. Dieser Punkt spiegelt einen wichtigen Punkt der Softwareentwicklung wieder. Betriebswirtschaftliche Standardsoftware ist alles in allem so komfortabel und so einfach einzusetzen, dass sie auch ohne Informatikkompetenz eingesetzt werden kann. Dagegen bleibt das Wissen um die betriebswirtschaftlichen Abläufe bedeutsam. Die typische Struktur in den DV-Abteilungen von Unternehmen mit Betriebswirtschaftlicher Standardsoftware ist, dass Programmierkompetenz nur noch im Rahmen der „internen Programmierung“ (vgl. oben) vorhanden ist. Also ABAP (im Falle von R/3) statt COBOL, C oder C++. Dazu kommen evtl. „externe Programmierarbeiten“ mit modernen Softwarewerkzeugen. Anmerkung: Die eigenen Entwicklermannschaften verschwanden tatsächlich aus den Unternehmen. Softwareentwicklung für Unternehmenssoftware hat sich, nach der Beobachtung des Verfassers, in großem Umfang in die (aus der Sicht der Unternehmen) externen Softwarehäuser verlagert. Dort wie-

34

35

Wenn nicht ein eigenes „Competence Center“ eingerichtet wird, das dann nicht nur hausinterne Kompetenz realisiert, sondern auch fundiert Änderungsvorschläge an das Softwarehaus macht, von dem die Standardsoftware kommt. Dies realisieren derzeit aber nur sehr wenige und sehr große Unternehmen. Und nur hier, bei der Realisierung integrierter prozessorientierter Software für die internen Geschäftsprozesse. Geht es um Software für die überbetriebliche Abwicklung von Geschäftsprozessen über’s Internet, ist der Bedarf an Entwicklern riesig.

3.2 Begleiterscheinungen

43

derum findet eine ständige Verschiebung von den „Individualfertigern“ zu den „Standardfertigern“ statt36. Oben wurde schon angesprochen, dass ein wichtiger Aspekt der Marktbeziehungen hier die ständigen und zahlreichen Änderungsvorschläge der Kunden sind. Das Softwarehaus hat dabei die Aufgabe, Spreu von Weizen zu trennen. Nicht selten kommt es vor, dass Änderungen, die von vielen Unternehmen gefordert wurden, nach Auslieferung kaum benutzt werden. Die große Aufgabe des Softwarehauses ist es, wichtige Änderungen der Realwelt und entsprechende Impulse aus der Wissenschaft zu erkennen und in die Standardsoftware umzusetzen. Werden zu viele oder die falschen Änderungen implementiert, verschärft sich noch der negative Leistungsüberhang und die Komplexitätsfalle (vgl. unten). Ganz anders stellt sich dieser Aspekt aus der Sicht der Kunden dar. Hier ist oft die Klage zu hören, dass zu spät oder gar nicht auf dringend benötigte Änderungen reagiert wird. Für viele Unternehmen gilt, dass sie durch die Wahl Betriebswirtschaftlicher Standardsoftware schnelleren Zugang zu Innovationen haben. Dazu gehören zum Beispiel x x x

Innovationen

softwaretechnische Neuerungen neue Verfahren aus der Wissenschaft (z.B. zur Produktionsplanung) neue Telekommunikationstechniken

Der Grund ist einfach. Ein Anbieter Betriebswirtschaftlicher Standardsoftware steht mit seinem Produkt „von der Stange“ einer größeren Zahl von Kunden gegenüber als die Anbieter von Individualsoftware (oder die eigenen Entwickler) und muss (sollte) sich von daher eine größere Entwicklermannschaft leisten. Denken wir zum Beispiel an die Datumsproblematik bei der Jahrtausendwende. Hier kann sich ein Anbieter Betriebswirtschaftlicher Standardsoftware keine Verzögerungen in der Umsetzung leisten, dies hätte für ihn verheerende Folgen. Diese erhöhte Innovation durch Standardsoftware gilt natürlich nicht, falls das Unternehmen eine leistungsstarke eigene Entwicklermannschaft hat oder einen entsprechenden Individualsoftwarelieferanten. Der Innovationszuwachs betrifft aber nicht nur die technologische oder methodische Seite. Mit der Einführung Betriebswirtschaftlicher Standardsoftware ist sehr oft auch ein Know How - Transfer in das Unternehmen bezüglich der optimierten Gestaltung der Geschäftsprozesse verbunden, da oftmals das Standardsoftwarehaus mehr Kompetenz bezüglich der betriebswirtschaftlichen Abläufe hat als z.B. ein mittelständischer Kunde. Betriebswirtschaftliche Standardsoftware ist - sozusagen strukturbedingt - „überausgestattet“, zumindest für das einzelne Unternehmen. Dies 36

Spreu und Weizen

Dass von letzteren in Wirklichkeit viele gar keine Standardlösung fertigen, sondern nur Individuallösungen jeweils (mehr oder weniger mühsam) an veränderte Weltausschnitte anpassen, steht auf einem anderen Blatt. Diese Standardsoftwarelüge ist, wenn ein Unternehmen ihr zum Opfer gefallen ist, dann u.U. ein großes Problem für die DV-Abteilungen dieser Häuser.

Know-How ins Unternehmen

Komplexitätsfalle

44

Datenaustausch erleichtert

Preis

Weniger Überraschungseffekte

Hardwarebedarf bestimmbar

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

muss so sein, da diese Software ja für eine Vielzahl von Strukturen und Abläufen geeignet sein muss und es softwaretechnisch nicht einfach ist, nicht benötigte Leistungen so zu verbergen, dass sie denjenigen nicht verwirren, der sie nicht nutzt. Dass es in diese Richtung aber Überlegungen bei allen Anbietern Betriebswirtschaftlicher Standardsoftware gibt, liegt auf der Hand. Trotz aller solcher Bemühungen und Anstrengungen im Customizing wird bei den meisten Anwendern zumindest in der ersten Gewöhnungsphase diesbezüglich ein Gefühl der Frustration artikuliert. Der nächste große Innovationsschub, der gerade einsetzt, wird die verstärkte Integration der Informationssysteme verschiedener Unternehmen betreffen. Was wir diesbezüglich mit EDIFACT ohne oder mit Internet beobachten können, sind nur erste Hinweise darauf. In Zukunft werden Geschäftsprozesse verstärkt über Unternehmen hinweg realisiert werden. Dabei werden sich diejenigen Unternehmen leichter tun, die Betriebswirtschaftliche Standardsoftware einsetzen. Nicht nur weil diese per Grundphilosophie in der Regel offener ist, was die Schnittstellen und Import/Export-Datenformate angeht, sondern auch, weil der Informationsfluss natürlich gewaltig erleichtert wird, wenn in den verschiedenen Unternehmen dieselbe Standardlösung eingesetzt wird. Die Anschaffung Betriebswirtschaftlicher Standardsoftware ist in der Regel billiger als Eigenentwicklung und - vor allem - eigene Wartung. Für das kaufende Unternehmen entstehen keine Entwicklungskosten, diese werden im Preis der Standardsoftware anteilsmäßig mitbezahlt. Die Wartungskosten (d.h. auch die Kosten für die Anpassung an die Veränderungen der Realwelt) werden über die Lizenzgebühren erledigt. Sehr oft wird von Betroffenen als großer Vorzug Betriebswirtschaftlicher Standardsoftware genannt, dass sie vor dem Kauf in gewissem Umfang eingesehen werden kann, z.B. in einem befreundeten Unternehmen oder an einer Hochschule. Dies kann ein unschätzbarer Vorteil sein, weil dadurch die ansonsten oft eintretenden Überraschungseffekte vermieden werden. Am deutlichsten wird dies in Unternehmen artikuliert, die mit Individuallösungen Erfahrungen sammeln mussten, die nur noch bedingte Ähnlichkeit mit dem zu Beginn der Softwareerstellung vereinbarten Pflichtenheft haben. Dieser Vorteil betrifft nicht nur die Software als solche, sondern auch die vorgedachten Modelle, wie Ereignisgesteuerte Prozessketten, Datenmodelle, usw. Insgesamt verhindert diese Möglichkeit der Einsichtnahme u.U. negative Überraschungen und nachträgliche Streitereien rund ums Pflichtenheft. Ein weiterer ansonsten vorliegender Risikofaktor kann bei Betriebswirtschaftlicher Standardsoftware ebenfalls vermieden werden, die Bestimmung des Hardwarebedarfs. Dieser ist ziemlich genau bestimmbar, ja es werden zertifizierte ausgetestete DV-Anlagen angeboten. Trotzdem hört man sehr oft Klagen über Performanceprobleme, selbst dann, wenn

3.2 Begleiterscheinungen

45

seit der Erstinstallation der Umfang der Transaktionen nicht zugenommen hat. Hier kann nur schlechte Beratung oder Fehlentscheidung die Ursache sein. Ein Unternehmen, das vor der Einführung Betriebswirtschaftlicher Standardsoftware ein hervorragendes und auf dem Stand der Technik befindliches Computergestütztes Informationssystem hatte, verliert durch die Einführung unter Umständen seine Vorteile vor den Mitbewerbern, es wird diesbezüglich „durchschnittlich“, es erleidet einen Profilverlust. Natürlich kann auch durch den mehr oder weniger geschickten Einsatz von Standardsoftware Profil gewonnen werden, allerdings nicht in dem Umfang wie bei Individuallösungen. In der Regel ist es aber so, dass ein so hervorragend ausgestattetes Unternehmen auf die Übernahme einer Standardlösung verzichten wird. Für viele Unternehmen stellt sich andererseits die Frage nach der Profilierung, nach der Gewinnung strategischer Vorteile durch Betriebswirtschaftliche Standardsoftware gar nicht. Dort erfolgt die Profilierung auf andere Weise. In der Industrie durch Forschung, Entwicklung, eine verbesserte Produktionssteuerung und evtl. durch Modifikationen der Fertigungstiefe. In der Konsumgüterindustrie zunehmend durch Marketingaktivitäten, usw. Auf den Punkt gebracht, kann dies so formuliert werden: Betriebswirtschaftliche Standardsoftware muss funktionieren, sie dient aber nicht (mehr) der Gewinnung strategischer Vorteile. Sie ist notwendige, aber nicht hinreichende Bedingung für den Unternehmenserfolg. Fällt der Bereich der Profilierung, wo ja auch evtl. die Kernprozesse angesiedelt sind, doch in den Abdeckungsbereich Betriebswirtschaftlicher Standardsoftware, besteht die Lösung oft darin, die Kernprozesse durch Individualsoftware oder durch stark an die realen Geschäftsprozesse angepasste Standardlösungen zu unterstützen, den Rest (die unterstützenden Geschäftsprozesse) durch Betriebswirtschaftliche Standardsoftware. Dies lässt dann Raum für Profilierung und vielleicht sogar für die Gewinnung strategischer Vorteile.

Anmerkung: „i.d.R.“ bzw. „u.U.“ Sehr oft werden hier die Formulierungen „in der Regel“ bzw. „unter Umständen“ verwendet. Darin äußert sich die Tatsache, dass viele der Aussagen in Beziehung zur Ausgangssituation gesetzt werden müssen. Ein Beispiel: Betriebswirtschaftliche Standardsoftware ist eben nur dann wirklich billiger, wenn die Individualsoftware des Unternehmens in die Kostenfalle gelaufen ist, d.h. wenn sie einen Bereich modellierte, der zu ständigen Anpassungen der (Individual-)Software zwang. Wer kennt andererseits nicht auch Software, die viele Jahre ohne größeren Änderungsbedarf ihre Arbeit tut, insofern die Kostensituation entlastet und das Controlling erfreut. Außerdem gibt

Profilverlust?

Bedeutungsverlust?

46

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

es auch Ersteller von Individualsoftware, die notwendige Anpassungen sehr kompetent und preiswert durchführen.

3.3 Lücken ...

... und ihre Überwindung

Überwindung der „Lücke“

Die wichtigste bei der Einführung Betriebswirtschaftlicher Standardsoftware (vgl. nächsten Abschnitt) zu klärende Frage ist die, auf welche Weise die immer existierenden Unterschiede zwischen den realen Geschäftsprozessen des Unternehmens und denen der Betriebswirtschaftlichen Standardsoftware überwunden werden sollen. Diese Lücke ist auch dann vorhanden, wenn im Auswahlprozess für die Standardsoftware dieser Punkt intensiv mitbedacht wurde. Grundsätzlich sind für Ihre Überwindung folgende Vorgehensweisen denkbar: x x x x

Umfassende Anpassung der realen Geschäftsprozesse an die der Betriebswirtschaftlichen Standardsoftware. Umfassende Anpassung der Geschäftsprozesse der Betriebswirtschaftlichen Standardsoftware an die realen. Kompromiss aus 1) und 2). Optimierung der realen Geschäftsprozesse und Kompromiss aus 1) und 2), evtl. in Kombination mit einer vorhandenen oder anstehenden ISO-Zertifizierung (vgl. unten).

Wahrscheinlich erscheinen die ersten beiden Lösungen als sehr radikal. Nichtsdestotrotz werden sie gewählt. Jede Vorgehensweise hat ihre Konsequenzen. Die erste Lösung (die im Übrigen auch nicht ohne minimales Anpassen auskommen wird) bedeutet einen tiefen Einschnitt in die bis dahin vorhandenen Unternehmensabläufe und schafft von daher u.U. Akzeptanzprobleme bei den Nutzern. Außerdem entsteht ein erhöhter Schulungsaufwand, da es nicht nur um das Gewöhnen an eine neue Programmoberfläche mit leicht veränderten Abläufen geht, sondern um meist grundsätzlich veränderte Geschäftsprozesse. Außerdem bedeutet sie u.U. einen starken Profilverlust (vgl. oben). Sie ist aber, was den Aufwand bei Einführung und Releasewechseln37 angeht, die preiswerteste Lösung. Oft wird sie in Unternehmen gewählt, die auf eine rasche Entschärfung ihrer Kostensituation angewiesen sind. In solchen Fällen erfolgt dann meist auch ein Austausch der Hardware.

37

Releasewechsel, Lieferungen einer neuen Version der Software mit wenigen oder vielen, manchmal auch grundlegenden Änderungen, erfolgen hier relativ oft (bei einzelnen Herstellern bis zu halbjährlich). Ob ein Releasewechsel im Unternehmen mitvollzogen wird, muss im Abgleich von angebotenen Verbesserungen (evtl. auch Fehlerbeseitungen) und Unternehmensinteressen abgewogen werden. Vor der Vorstellung, die einige von “früher” her kennen, “Software kaufen und fünf Jahre ist Ruhe” kann hier nur gewarnt werden.

3.3 Überwindung der „Lücke“

47

Viele Unternehmen entscheiden sich auch dafür, diese erste Lösung für die unterstützenden Geschäftsprozesse zu wählen und für die Kernprozesse eine der anderen. In allen Punkten geradezu entgegengesetzt ist die zweite Lösung. Treibt man dies weit genug, reproduziert man sich die alte Individualsoftware38 und hat großen Aufwand bei der Einführung und bei jedem Releasewechsel, wo dann z.B. „alle ABAP’s“ dahingehend überprüft werden müssen, ob sie mit der neuen Basisversion der Standardsoftware noch funktionieren. Noch aufwändiger gestaltet sich oft der Abgleich der veränderten Datenstrukturen. Natürlich gibt diese Variante aber die Möglichkeit, Profilverlusten aller Art energisch entgegenzutreten. Eine Lösung, die als Variante 1b bezeichnet werden könnte, traf der Verfasser in einem größeren mittelständischen Unternehmen an. Dieses Unternehmen lässt die Betriebswirtschaftliche Standardsoftware selbst so gut es geht unverändert, damit die neuen Versionen relativ problemlos eingespielt werden können. Die gewünschten Änderungen (deren Umfang auf das Nötigste beschränkt wird) werden über externe Programmierwerkzeuge, die über einfache Schnittstellen mit der Standardsoftware kommunizieren, realisiert. Diese Lösung wird allerdings nur für die unterstützenden Prozesse gewählt. Releasewechsel stellen tatsächlich wichtige Meilensteine im Leben einer Betriebswirtschaftlichen Standardsoftware dar. Hat ein Unternehmen Standardsoftware eingeführt, erfolgt die Veränderung und Weiterentwicklung der Software (abgesehen von den beschränkten Möglichkeiten des Customizing) nicht im Unternehmen, sondern beim Anbieter der Standardsoftware, der in regelmäßigen Abständen neue Versionen anbietet. Da die Veränderungen notwendigerweise oft weit und tief gehen, sind solche Releasewechsel u.U. aufwändig, vor allem wenn das Unternehmen ganz oder teilweise obige Lösung 2 gewählt, d.h. viele Modifikationen der Software durch Customizing oder sogar Programmierung vorgenommen hat. Sieht man von diesen Anpassungen ab, ist der vollautomatische Releasewechsel das Ziel, das immer wieder genannt wird. Meist wird bei der Überwindung der Lücke zu einem Kompromiss gegriffen, wie er oben als dritte Lösung angeführt ist. Änderungen, die unabdingbar erscheinen werden vorgenommen, ansonsten werden die Geschäftsprozesse der Betriebswirtschaftlichen Standardsoftware übernommen. Auch die vierte obige Lösung wird sehr oft gewählt. Da die Beschäftigung mit Standardsoftware meist sowieso dazu führt, sich mit den Geschäftsprozessen näher zu befassen, wird die Einführung dann gleich für Optimierungsvorhaben genutzt. Dieses Reengineering erfolgt dann unter gleichzeitiger Berücksichtigung der realen Geschäftsprozesse und denen der Standardlösung.

38

Vor allem deren Ablauflogiken, weniger deren Oberflächen.

„Zwischenlösung“

Releasewechsel

Reengineering

48

ISO-Zertifizierung

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

Seit einiger Zeit kommt in vielen Unternehmen noch ein vierter zu berücksichtigender Faktor hinzu, die ISO-Zertifizierung. Da diese natürlich auch auf die Geschäftsprozesse Einfluss nimmt, müssen dann x x x x

reale Geschäftsprozesse, die der Standardlösung, die Optimierungswünsche und die ISO-Vorgaben

zusammengebracht werden.

3.4

Vor dem Kauf

Einführung

Es liegt vor allem am umfassenden Anspruch und an der Prozessorientierung, dass die Einführung Betriebswirtschaftlicher Standardsoftware so aufwändig ist, geht es dabei doch um nicht weniger als die Neugestaltung des Computergestützten Informationssystems. Oft wird gleichzeitig auch noch eine neue Hardware eingeführt, was den Einführungsaufwand noch erhöht. Die Einführung ist auch sehr unterschiedlich, je nach der konkreten Situation des Unternehmens. Die folgenden Anmerkungen versuchen einige allgemeine Hinweise zu geben39. Grob soll dabei zwischen der Situation vor und nach dem Kauf unterschieden werden. Folgende Schritte sind vor dem Kauf zu tätigen: x

Abgrenzung und Festlegung der Ziele

Meist wird Betriebswirtschaftliche Standardsoftware nicht für das gesamte Unternehmen eingeführt, sondern nur für einzelne Bereiche. Nach deren Festlegung muss noch geklärt werden, ob für Kernprozesse und unterstützende Geschäftsprozesse gleich verfahren wird. Unter Umständen werden z.B. im Rahmen der Lückenbewältigung (vgl. den vorigen Abschnitt) unterschiedliche Vorgehensweisen gewählt. Von besonderer Bedeutung ist weiterhin, ob im Rahmen der Einführung die Geschäftsprozesse auch optimiert werden sollen. Ist dies gewünscht, erhöht sich der Zeitbedarf beträchtlich. In der Regel werden hierfür auch externe Berater benötigt. Zu diesem Schritt gehört auch die Klärung der Schnittstellen zu den übrigen Komponenten des Computergestützten Informationssystems, sei es zu „alter“ Software oder zu anderen neu zu erstellenden Programmen. Die folgenden Punkte konzentrieren sich auf die eigentliche Softwareeinführung. x

39

Istanalyse

Eine intensive Diskussion dieser Thematik findet sich in [Klockhaus und Scheruhn 1998].

3.4 Einführung

49

Der nächste Schritt muss in der gründlichen Analyse der vorhandenen Geschäftsprozesse bestehen. Dies ist ein wichtiger, oftmals aber unterschätzter Punkt, für den oft auch zu wenig Zeit eingeplant wird. Eventuell wird er noch durch eine durchgeführte oder bevorstehende ISOZertifizierung modifiziert, die ebenfalls Vorgaben für die Geschäftsprozesse macht. x

Optimierungsziele

Sind Optimierungsziele im Spiel – und meist ist dies der Fall – muss deren Ziel und Umfang definiert werden. Dies sollte unabhängig von den später betrachteten Standardsoftwareprodukten erfolgen. x

Vorherige Inaugenscheinnahme

Die Gefahr, eine „Katze im Sack“ zu kaufen ist bei verbreiterter Standardsoftware nicht sehr groß, da hier die Möglichkeit besteht, gängige bzw. infrage kommende Produkte vorher in Augenschein zu nehmen, sei es in anderen Unternehmen oder an einer Hochschule. Dies ist eine grundsätzlich andere Situation als bei Individualsoftware, wo die gewünschte Software zwar mithilfe eines Pflichtenheftes beschrieben wird, diese Beschreibung aber mit dem Endprodukt nicht immer voll übereinstimmt. x

Softwareauswahl

Schon vor der eigentlichen Softwareauswahl sollte ein Überblick über das Angebot an Betriebswirtschaftlicher Standardsoftware hergestellt und entsprechende Kompetenzen aufgebaut worden sein. Auf der Basis dieser Vorarbeiten müssen nun mehrere Produkte analysiert werden. Wesentlich bei diesem Punkt ist die Prüfung der Frage, mit welcher Betriebswirtschaftlichen Standardsoftware die eigenen Geschäftsprozesse (evtl. unter Einbeziehung der Optimierungsziele) am besten realisiert werden können. Die Phase der Softwareauswahl kann in weitere Teilschritte unterteilt werden. Ein Erster kann in der Grobauswahl der Lieferanten bestehen. Aus der hoffentlich großen Gruppe sollten die ausgewählt werden, die in die engere Wahl genommen werden. Mehr als fünf ist hierbei nicht sinnvoll. In einem zweiten Schritt können die ausgewählten Unternehmen gebeten werden, ihr System vorzustellen und vorzuführen. Danach kann die Wahl auf zwei bis drei Anbieter eingeschränkt werden. Im nächsten Schritt sollten Workshops von ein bis zwei Tagen mit den verbliebenen potenziellen Lieferanten vorgenommen werden. Dabei können deren Produkte näher kennen gelernt und getestet werden. Von zentraler Bedeutung ist auch hier die Frage, inwieweit die gewünschten Sollprozesse durch die Standardlösungen realisiert werden können. Nach diesem Schritt ist der Kreis der Unternehmen noch kleiner geworden. Falls noch Unsicherheit herrscht, kann an dieser Stelle die testweise Installation eines Produkts oder mehrerer in’s Auge gefasst werden. Dies schränkt den Kreis der Unternehmen noch mehr ein bzw. si-

Teilschritte der Softwareauswahl

50

Nach dem Kauf

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

chert eine angedachte Entscheidung ab. Bei den dann noch verbliebenen Unternehmen wird ein konkretes Angebot erbeten. Grundsätzliches Misstrauen ist angesagt, wenn von den Verkäufern versprochen wird, fehlende Funktionaliäten würden schnellstens nachprogrammiert. Dies klappt meist nicht. Ist die Software gekauft, sind folgende Schritte zu leisten: x

Vergleich der realen Geschäftsprozesse mit denen der Standardsoftware unter Mitberücksichtigung der Optimierungsziele.

Dies baut natürlich auf den vor dem Kauf erfolgten Vorarbeiten auf. Hier geht es allerdings darum, den Vergleich flächendeckend durchzuführen und festzulegen, wie die dabei auftauchenden Unterschiede überwunden werden sollen. x

Konkrete Einführung

Die konkrete Einführung stellt ein komplexes Projekt dar, das nur dann effektiv abgewickelt werden kann, wenn die Grundregeln effizienter Projektarbeit eingehalten werden (vgl. die Hinweise, insbesondere zu Erfolgsfaktoren, in >Boy, Dudek, Kuschel 1994@, >Dingle 1997@, >Litke 1996@, >Lock 1996@, >Neumann und Bredemeier 1996@, >Rudolph 1996@, >Wischnewski 1993@). Unter den vielen in der Literatur genannten Erfolgsfaktoren für Projekte dieser Art fehlen meist einige sehr grundsätzliche und banal klingende, die aber ihre Praxisrelevanz immer wieder eindrücklich beweisen: x x x x

Die Zusammensetzung der Projektteams sollte im Projektverlauf möglichst gleich bleiben. Es ist auf genügend Kompetenz bei den Projektmitgliedern zu achten. Den Projektmitgliedern ist genügend Zeit für das Einführungsprojekt zu geben. Die Projektleitung sollte genügend Machtbefugnisse haben, um Änderungen durchsetzen zu können.

Besonderen Reiz gewinnt diese Aufgabe, weil ja der operative Betrieb möglichst reibungslos weitergehen soll. Kein Unternehmen kann sich heute einen Stillstand der Datenverarbeitung auch nur von wenigen Tagen leisten. Was den konkreten Ablauf angeht, sei hier auf das Vorgehensmodell der SAP verwiesen, das aus vier Phasen besteht: x x x x

Organisation und Konzeption Detaillierung und Realisierung Produktionsvorbereitung Produktionsanlauf

3.4 Einführung

51

In der Phase Organisation und Konzeption werden das Sollkonzept und der Projektplan erarbeitet. Dazu muss zu Beginn die Projektarbeit organisiert werden. Folgende Einheiten können gebildet werden: x x x x

Phase 1: Organisation und Konzeption

Ein Lenkungsausschuss, das oberste Entscheidungs- und Koordinationsgremium. Die Projektleitung, welche die Aufgabenverteilung festlegt, die Ressourcen überwacht und das Projektcontrolling durchführt. Das Projektteam, das die eigentliche Einführungsarbeit leistet. Teil-Projektteams, die im Projektverlauf gebildet und je nach Aufgabenumfang und Unternehmensgröße bestimmte Teilaufgaben übernehmen.

Die erste Aufgabe der Projektleitung und des Projektteams besteht in der Festlegung der Projektstandards. Hier wird in der Regel eine gründliche Dokumentation gefordert, da die vorgedachten Geschäftsprozesse schrittweise durch Änderung der Parameter an das Unternehmen angepasst werden müssen. Zur Erleichterung der Dokumentation kann diese deshalb direkt im R/3 abgelegt werden. Da die wesentlichen Geschäftsprozesse vorgedacht sind, werden die Erfordernisse hinsichtlich der organisatorischen Anforderungen, die das System stellt, analysiert. Die einzuführenden Komponenten des Systems werden ausgewählt, die organisatorischen Anpassungen an das System festgelegt und die Reihenfolge der Funktionen bestimmt. Anhand der Anforderungsanalyse wird der Terminplan erstellt, dessen Einhaltung durch Projektfortschrittsberichte unterstützt wird. Die betroffenen Mitarbeiter müssen möglichst früh beteiligt werden, um eine größtmögliche Akzeptanz der neuen Software zu erzielen. Das System wird bereits in dieser Phase installiert, damit die zukünftigen Systembetreuer sich baldmöglichst mit ihm vertraut machen können. Zunächst wird ein kleines Testsystem installiert, das im Laufe des Projektfortschritts und je nach Anforderung schrittweise erweitert wird. Die Mitglieder der Projektgruppe werden mittels Schulungen in ihren künftigen Aufgaben ausgebildet. Funktionen, Abläufe und Zuständigkeiten werden festgelegt, Schnittstellen entworfen und die Systeminfrastruktur geplant. Den Abschluss der Phase Organisation und Konzeption bildet die Qualitätsprüfung des Konzepts durch das Projektteam und die Fachabteilungen. In der Phase Detaillierung und Realisierung wird das Sollkonzept verfeinert, das System parametrisiert, die einzelnen parametrisierten Anwendungen getestet und die Altsysteme in die neue Software integriert. Zunächst findet das Customizing der neuen Software statt, wobei als Erstes die Aufbauorganisation des Unternehmens in der neuen Software abgebildet wird. Innerhalb dieser Struktur werden dann die Funktionen und die Verwendung der Daten und Felder anhand der unternehmensspezifischen Erfordernisse bestimmt. Nach Abbildung der Organisationsstruktur werden die Berechtigungen der einzelnen Anwender festgelegt.

Phase 2: Detaillierung und Realisierung

52

Phase 3: Produktionsvorbereitung

Übernahme der Altdaten

Phase 4: Produktionsanlauf

Schrittweise oder Schlagartig

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

Sind die Schnittstellen innerhalb des Systems und zu externen Systemen festgelegt, können komplette Geschäftsprozesse getestet werden. Parallel hierzu müssen die Formulare und das Berichtswesen detailliert ausgestaltet werden. Dieser vollständig dokumentierte Prototyp des neuen Systems wird dann qualitativ überprüft. Die Phase der Produktionsvorbereitung beinhaltet die Planung der Produktivsetzung, die Schulung der Anwender sowie die Vorbereitung und Durchführung der Altdatenübernahme. Die Schulungen müssen so rechtzeitig durchgeführt werden, dass sie zum Produktionsanlauf abgeschlossen sind. Den Anwendern wird spätestens zu diesem Zeitpunkt eine ausreichende Dokumentation zur Verfügung gestellt. Die Produktionsumgebung wird eingerichtet, die technische Systemverwaltung organisiert sowie die Reorganisation und Archivierung der Daten festgelegt. Eine besondere Aufgabe stellt die Übernahme der Altdaten dar. Für diese wird ein Konzept erstellt, das die Integrität und Konsistenz der Daten im neuen System gewährleistet. Erschwert wird diese Aufgabe, wenn die Daten bisher in verschiedenen Datenbanken und/oder nach einem anderen Datenmodell gespeichert waren. Da die Datenbanken aktueller Betriebswirtschaftlicher Standardsoftware derzeit meist relational organisiert sind kann dies bedeuten, dass Altdaten aus Netzwerkdatenbanken zusammen mit relationalen und anderen aus einfachen Dateien in die neue Datenbank überführt werden müssen. Dies stellt nicht geringe Anforderungen an die Kompetenz der Datenbankdesigner. In der Regel erfordert eine solche Übernahme spezielle Überleitungsprogramme. Der genaue Zeitpunkt der Datenübernahme muss festgelegt werden. Das Projektteam, die Fachabteilungen und gegebenenfalls ein Wirtschaftsprüfer überprüfen die übernommenen Daten, bevor das System in die Produktion geht. Nach Abschluss des Integrationstests und der Analyse der Systembelastung sowie der Nachpflege der übernommenen Daten und der Qualitätsprüfung liegt damit das eingerichtete Produktionssystem vor. Im Produktionsanlauf wird das System im Echtbetrieb eingesetzt. Ziel ist es, ein möglichst stabiles System zu betreiben. Die Hauptaufgaben in dieser Phase sind die Fehlerkorrektur und die technische und organisatorische Optimierung des Systems. Nachdem auch für Systemwartung und Releasewechsel die Zuständigkeiten festgelegt sind, wird das System an die Fachabteilungen übergeben und das Projekt abgeschlossen. Grundsätzlich kommen hier eine schrittweise Einführung („step by step“) oder eine schlagartige („big bang“) infrage. Nicht jede Betriebswirtschaftliche Standardsoftware erlaubt allerdings die schrittweise Einführung. So weit die zugegeben knappen Anmerkungen zur Einführung Betriebswirtschaftlicher Standardsoftware. Grundsätzlich muss darauf hingewiesen werden, dass diese Aufgabe nicht unterschätzt werden darf und genügend Ressourcen aller Art zur Verfügung gestellt werden sollten.

3.5 Leidensdruck - Warum überhaupt ?

53

Dass diese Aufgabe – auch in einem vertretbaren Zeitrahmen – gelöst werden kann, zeigen die zahlreichen Beispiele erfolgreicher Implementationen.

3.5

Leidensdruck - Warum überhaupt ?

Gerade nach den Ausführungen des letzten Abschnitts stellt sich die Frage, warum Unternehmen den Aufwand der Einführung einer Betriebswirtschaftlichen Standardsoftware auf sich nehmen. Gibt es nicht doch andere Lösungen, die organisch aus den funktionsorientierten oder teilweise prozessorientierten Lösungen der Vergangenheit heraus wachsen können. Dies ist gleichzeitig die Frage nach dem Grund für den Erfolg moderner Betriebswirtschaftlicher Standardsoftware, der ja, zumindest was die Marktführer angeht, unübersehbar ist. Eine Antwort auf beide Fragen erhält man, wenn man einen kurzen Blick auf den Zustand der Datenverarbeitung in vielen Unternehmen vor der Einführung Betriebswirtschaftlicher Standardsoftware wirft. Dieser lässt sich kurz so beschreiben: x

Zersplitterung der Hardware

Jedem größeren Anwenderbereich seinen eigenen Rechner, womit nicht nur PCs gemeint sind. Wer kennt ihn nicht, diesen Wildwuchs. Hier der „Host“, dort die AS 400, in den Büros die vernetzten PCs, dazwischen einige „Apples“ und „die Technik braucht natürlich ihre UNIX-Maschinen.“ Ein Teil dieses Wildwuchses ist unvermeidbar, weil bestimmte Programmfunktionalität in einer bestimmten Qualität nur auf bestimmten Plattformen zur Verfügung steht40, der größte Teil aber nicht. Er beruht schlicht auf Fehlentscheidungen. Diese Heterogenität der Hardwareplattformen war solange kein größeres Problem, als im Wesentlichen einzelne Funktionen durch die Datenverarbeitung unterstützt wurden. Geht es aber um die Absicherung von Prozessen, liegt eine andere Situation vor. Jetzt erzwingt eine solche Struktur die sehr aufwändige Einrichtung und Pflege von Schnittstellen und Datenflüssen. x x

Zersplitterung der Daten Zersplitterung der Programme

Diese zwei Punkte ergänzen die obigen. Ganz automatisch entstehen in einer solchen Konstellation Insellösungen auch bzgl. der Programme und der Datenbestände41. Werden die Daten redundant gehalten, ist es unvermeidlich, dass sie ihre Konsistenz verlieren. Dann sind Kunden eben un-

40 41

Wildwuchs

Ein ganz einfaches Beispiel: Moderne Textverarbeitungen oder Grafikpakete, wie es sie auf PC’s gibt, sind auf den anderen Plattformen nur eingeschränkt verfügbar. Vgl. den Begriff der funktionsorientierten Dateninseln bei >Scheer 1997@.

Insellösungen

54

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

ter verschiedenen Adressen gespeichert und in der Materialwirtschaft werden demselben Teil verschiedene Kennziffern zugeordnet. Die oben angesprochenen Schnittstellen und Datenflüsse können nun konkretisiert werden als Kommunikation von Programmen auf verschiedenen oder auch nicht verschiedenen Plattformen im Rahmen der Abwicklung von Geschäftsprozessen42. Ein Problem ist dies natürlich nur wegen der fehlenden Kompatibilität der verschiedenen Plattformen und Systeme. x

Neue Anforderungen

Dies war schon immer ein Problem, vor allem bei ungenügender Dokumentation der Programme, wurde aber in jüngster Zeit besonders drängend wegen solcher Dinge wie Euro-Umstellung bzw. Umstellung auf mehrere parallel zu führende Währungseinheiten und die Jahr-2000Frage. Nicht zuletzt dies hat Ende der 90er-Jahre zu einem starken Umsatzzuwachs bei den Anbietern Betriebswirtschaftlicher Standardsoftware geführt. x

Gestiegene Anforderungen

Fehlende Möglichkeit, gestiegene Anforderungen mit der vorhandenen Ausstattung zu realisieren.

Manchmal sind es gar keine Fehlentwicklungen, die Änderungen erzwingen. Oftmals reicht schlicht die bisherige Lösung für gestiegene Anforderungen nicht mehr aus. Dies ist besonders oft dann der Fall, wenn zu lange auf notwendige Investitionen in die Datenverarbeitung verzichtet wurde. Beispiele für solche erhöhten Anforderungen betreffen die Verbesserung der Liefer- und Termintreue, die automatisierte Abwicklung unternehmensübergreifender Geschäftsprozesse, usw. x

Vom „Host“ zur MDT

Alte Software, die ständig weiterentwickelt wurde und demzufolge eine hohe Komplexität aufweist und die nur noch mit großem Aufwand neuen Anforderungen angepasst werden kann.

Kostendruck

Dieser Punkt hängt natürlich mit den obigen zusammen, denn alle diese Defizite verursachen hohe und für viele Unternehmen ab einem gewissen Punkt zu hohe Kosten. Die Kostensenkung wird dann zum einen durch die neue integrierte Lösung erreicht, zum anderen oft aber auch durch ein gleichzeitiges Auswechseln der Hardware (klassisch: Ablösung des Großrechners durch eine Mittlere Datentechnik oder Ablösung der Mittleren Datentechnik durch vernetzte PCs). So weit einige Punkte, die den Leidensdruck deutlich machen sollen, der zu der Bereitschaft führt, sich dem Aufwand und den Kosten zu stellen, die mit der Einführung von Standardsoftware verbunden sind. 42

Dies schlägt sich bis in die Diplomarbeiten der Studierenden der Wirtschaftsinformatik an der vom Verfasser geleiteten Fachrichtung nieder, wo bis vor einigen Jahren überdurchschnittlich oft Theorie und Praxis der Verknüpfung heterogener Systeme bearbeitet wurden. Inzwischen haben Internetthemen (v.a. aus dem Bereich des EBusiness) die führende Rolle übernommen.

3.6 Perspektiven

3.6

55

Perspektiven

Betriebswirtschaftliche Standardsoftware ist derzeit und auf absehbare Zeit für die Unternehmen der wichtigste Softwaretyp. Er liefert die Grundausstattung für das Computergestützte Integrierte Informationssystem und die Basis für die Abwicklung der betrieblichen Geschäftsprozesse. In den letzten Jahren gewann die Software für die überbetriebliche Geschäftsprozessabwicklung über das Internet (hier kurz: Internetsoftware) an Bedeutung. Sie wird zunehmend zu einem wichtigen Bestandteil der Informationstechnologie der Unternehmen, weil die Beziehungen zu Partnern aller Art (Kunden, Lieferanten, usw.) immer stärker auf der Basis dieser Technologie realisiert werden. Allerdings wird dadurch die Bedeutung der betrieblichen prozessorientierten Software nicht gemindert, da sie inzwischen schlicht die notwendige Vorausetzung für den Unternehmenserfolg ist. Beide Softwaretypen werden somit in der Zukunft von zentraler Bedeutung sein. Ein Grund dafür liegt in ihrer Struktur. Durch ihre Prozessorientierung unterstützen sie den Trend zu einer immer weiter gehenden DV-Durchdringung der Strukturen und Abläufe in und zwischen den Unternehmen43. Gleichzeitig verstärken sie diesen Trend aber auch. Ein zweiter Grund ist aber genauso wichtig. Beide sind sozusagen Serienprodukte, bzw. – noch besser für das produzierende Unternehmen – Kopierprodukte. Die Software ist, obwohl prozessorientiert und damit eigentlich an sehr spezifischen Strukturmerkmalen der Unternehmen orientiert, für viele Unternehmen geeignet (vgl. die Diskussion der Integrationsaspekte oben). Das hat segensreiche Wirkungen für die Einnahmen44 dieser Unternehmen (zumal eine intensive Preiskonkurrenz nicht auszumachen ist). Der trotzdem im Vergleich zu Individualsoftware niedrige Preis macht vielen ihrer Kunden diese Software erst erschwinglich. Standardsoftware wird wie jede Software einmal produziert und beliebig oft kopiert. Was wir von PC-Software inzwischen zur Genüge kennen, hat damit auch in den Bereich der betriebswirtschaftlichen Software Einzug gehalten. Wie weit man damit kommt, zeigen Microsoft und SAP. Da aber das Produkt nicht nur aus der Software besteht, sondern auch aus nicht replizierbaren Teilen wie Beratung, Anpassung und Einführung, besteht die Kunst der Standardsoftwarehäuser darin, den replizierbaren Anteil am Gesamtprodukt möglichst groß zu halten45.

43 44 45

Diese wiederum ist hauptsächlich motiviert durch den ständigen Druck zur Kostensenkung und Produktivitätssteigerung. Erhöhte DV-Durchdringung dient in unserer Wirtschaft als Rationalisierungsinstrument, was nicht immer zum Erfolg führt. Dies macht wiederum den Einzelfertigern (von Individuallösungen) das Leben in der Zukunft immer noch schwerer. Was wiederum nicht unbedingt im Sinn der die Einführung unterstützenden Softwareund Beratungsunternehmen ist.

Betriebliche prozessorientierte Software

Überbetriebliche prozessorientierte Software

Erfolgsfaktor Prozessorientierung

Kopierprodukt

56

Komplexitätsfalle 2

Je detaillierter, desto unterschiedlicher

Branchenlösungen

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

Dies alles gilt natürlich nur, wenn es sich wirklich um eine Standardlösung handelt und nicht um eine Individuallösung, die eben doch mehr oder weniger mühsam, z.B. über Veränderung des Quellcodes, an die Strukturen und Abläufe der einzelnen Kunden angepasst werden muss. Auf die Dauer werden nur Standardsoftwarehäuser überleben, die echte Standardlösungen anzubieten in der Lage sind. Weiter oben wurde schon von Komplexitätsfalle gesprochen. Dort ist die Tatsache gemeint, dass Betriebswirtschaftliche Standardsoftware angesichts ihrer Funktions- und Variantenvielfalt auf die Nutzer oft verwirrend wirkt. Ein weiteres Problem könnte entstehen, wenn sich ein Trend fortsetzt, den der Verfasser seit einigen Jahren verstärkt in den Unternehmen beobachtet: den Wunsch nach einer immer tiefergehenden DVDurchdringung, nach einer immer detaillierteren DV-Unterstützung der Geschäftsprozesse. Hier könnte sich, zumindest beim derzeitigen Stand der Softwaretechnologie, Betriebswirtschaftliche Standardsoftware als überfordert erweisen, weil (natürlich) die Unterschiede zwischen den konkreten Geschäftsprozessen der Unternehmen umso größer werden, je detaillierter man sie modelliert. Eine Lösung hierauf versucht SAP mit den Branchenlösungen (industry solutions (IS)) zu geben, die seit einiger Zeit entwickelt werden. Z.B. für die Druckindustrie, das Kreditwesen oder die Öffentliche Verwaltung. Mit ihnen wird die allgemeine „Industriefassung“ des R/3 (die Standardversion) angepasst an die spezifischen Strukturen und Abläufe dieser Branchen bzw. Sektoren. Damit verkleinert sich die oben angesprochene Lücke (und mit ihr der Einführungsaufwand) und die Komplexitätsfalle entschärft sich etwas. Vielleicht verkleinert sie sich für den Kunden aber auch nicht, trotz aller Bemühungen, dann nämlich, wenn diese Spezifizierung für eine detailliertere Modellierung der Geschäftsprozesse genutzt wird (vgl. oben). Nimmt man noch den Trend dazu, die Abdeckung der betrieblichen Geschäftsprozesse ständig auszudehnen (vgl. auch Abschnitt 3.1, Stichwort Genauere Abgrenzung), ergeben sich insgesamt die Faktoren, die in der folgenden Abbildung angegeben sind. Es wird nicht ohne Reiz sein zu beobachten, auf welche Weise die Standardsoftwarehäuser dieser Gefahr begegnen. Eine naheliegende Lösung, die Produkte mit modernen Programmiersprachen und –techniken neu zu programmieren, scheint derzeit nur von wenigen in Betracht gezogen zu werden.

3.6 Perspektiven

Abbildung 3.6-1:

57

Komplexität - Ursachen und Bewältigung

Heutige Betriebswirtschaftliche Standardsoftware treibt die Integration der Informationssysteme innerhalb der Unternehmen voran. Der nächste Schritt ist die Integration über die Unternehmensgrenzen hinweg. Dies wird weit über den Ansatz, einzelne Geschäftsprozesse über mehrere Unternehmen hinweg zu realisieren, hinausgehen und zu einer partiellen Verschmelzung der unterschiedlichen Informationssysteme führen. Auf welcher technologischen Basis dies erfolgt, ist noch nicht absehbar. Ob das offene und fehleranfällige heutige Internet dies leisten kann, ist fraglich.

Von Intra zu Inter

58

Kompetenzfalle

3 Betriebswirtschaftliche Standardsoftware / ERP-Software

Die Gestaltung der Computergestützten Informationssysteme in den Unternehmen, ob mit oder ohne Betriebswirtschaftliche Standardsoftware, leidet unter der diesbezüglichen mangelnden Kompetenz vieler Verantwortlicher. Eigentlich sollte heute in jedem BWL-Studium ein Basiswissen bzgl. der Gestaltung Computergestützter Informationssysteme vermittelt werden. Dem ist leider nicht so. Kompetenz bzgl. einer Gesamtsicht des Computergestützten Informationssystems fehlt aber auch in den Fachabteilungen, ja sogar teilweise in den DV-Abteilungen der Unternehmen. Wahrscheinlich werden durch diese Defizite und den sich daraus ergebenden Fehlentscheidungen mehr Kosten verursacht, als durch viele andere Faktoren, die im Rahmen von Optimierungsbemühungen zur Diskussion gestellt werden.

4 Ereignisgesteuerte Prozessketten Grundlagen

4.1

Einführung

Ereignisgesteuerte Prozessketten (EPKs) sind das Werkzeug für die Analyse und Beschreibung von Geschäftsprozessen46. Diese Methode und die zugehörige grafische Beschreibungstechnik (Notation) für Geschäftsprozesse wurde von Scheer und seinen Mitarbeitern im Rahmen ihres ARIS-Konzepts (vgl. Abschnitt 2.10) entwickelt (vgl. [Keller, Nüttgens und Scheer 1992], >Scheer 1997@). Sie ist auch zentraler Bestandteil des SAP-Konzepts für die Modellierung von Unternehmensstrukturen und -abläufen (Unternehmensmodellierung) und findet darüber hinaus – unabhängig von einer bestimmten Software - immer mehr Verwendung in Projekten der Geschäftsprozessoptimierung (Business Process Reengineering). Ereignisgesteuerte Prozessketten sind eine semi-formale Methode. Sie genügen nicht den Ansprüchen (wie auch im weiteren zu sehen sein wird), die an formale Methoden47 bzw. Sprachen gestellt werden müssen. So auch Rosemann in seinem Beitrag in >Mertens u.a. 1997, S. 334@, wo er unterscheidet: x x

informale, z.B. textliche Beschreibungen, semi-formale, z.B. Ereignisgesteuerte Prozessketten,

und x

formale Methoden, wie z.B. Prädikatenlogik (ebenda).

Auch die dort angeführten Forderungen an eine solche Methode, Darstellung des Kontrollflusses, Abbildung von Nebenläufigkeit, von bedingten Verzweigungen und von Schleifen, die Wiedergabe des Datenflusses sowie die Angabe der involvierten Organisationseinheiten und Informationssysteme erfüllen Ereignisgesteuerte Prozessketten ohne weiteres. 46

47

Dies sollte nicht mit dem Geschäftsprozessbegriff der UML verwechselt werden. Das dort verwendete Konzept der use cases wird von deutschen Autoren (u.a. [Balzert 1998], [Balzert 2001], [Meier und Wüst 1997]) mit Geschäftsprozess übersetzt, was nicht sinnvoll ist (vgl. hierzu Kapitel 10 undn folgende). Vgl. für eine (unkonventionelle und verständliche) Einführung in formale Systeme >Hofstadter 1985@.

Unternehmensmodellierung

semi-formal

60

Formale Darstellung

Syntax

4 Ereignisgesteuerte Prozessketten - Grundlagen

Einen Ansatz zur Formalisierung von Ereignisgesteuerten Prozessketten stellt Rump in [Rump 1999] vor. Dort finden sich auch Hinweise auf die Formalisierungsbemühungen von Chen und Scheer (vgl. [Chen und Scheer 1994]) sowie Langner, Schneider und Wehler (vgl. [Langner, Schneider und Wehler 1997a und 1997b]). Trotz des nicht voll formalen Charakters dieser Notation soll hier auch von Syntax gesprochen werden, wenn die Regeln für den korrekten Aufbau der Ereignisgesteuerten Prozessketten gemeint sind.

4.2

Elemente

In Abschnitt 2.3 wurden die Elemente von Geschäftsprozessen genannt, die >Scheer 1997@ bei der Herleitung des ARIS-Konzepts identifiziert. Diese fasst er bei der konkreten Ausformulierung des EPK-Ansatzes zu Folgenden zusammen: x x x x

Funktionen Ereignisse Organisationseinheiten und Informationsobjekte

Außerdem werden der Kontrollfluss48 und – eingeschränkt – der Datenfluss berücksichtigt. 4.2.1 Was wird geleistet?

Vorgang

Funktionen

Mit Funktionen werden die im Geschäftsprozess zu leistenden Tätigkeiten erfasst. Welchen Umfang an Tätigkeiten die einzelne ausgewiesene Funktion umfasst, bleibt dem Modellierer überlassen. Der in Kapitel 2 diesbezüglich diskutierte subjektive Faktor der Modellierung bleibt also erhalten. Funktionen beschreiben also, was gemacht werden soll. Alle Tätigkeiten, die in einem Geschäftsprozesse zu leisten sind, werden in einzelne Teilaufgaben unterteilt. Sie erfassen bei Mitarbeitern deren operative Tätigkeit, bei einem Informationssystem so etwas wie eine Transaktion bzw. einen betriebswirtschaftlichen Funktionsbaustein >Schulungsunterlagen Analyzer, S. 2-5@. Etwas genauer wird dieser Begriff durch die Festlegung gefasst, dass eine Funktion z.B. einen betriebswirtschaftlichen Vorgang kennzeichnen kann, den Scheer wie folgt definiert: „Ein Vorgang ist ein zeitverbrauchendes Geschehen, das durch ein Startereignis ausgelöst und durch ein Endereignis abgeschlossen wird. Einem Vorgang können in Abhängigkeit von Vorgangsergebnissen unterschiedliche Ablaufver48

Mögliche Abläufe des Geschäftsprozesses, vgl. unten.

4.2 Elemente

61

zweigungen, auch Rücksprünge, folgen.“ [Scheer 1998, S. 20] Bullinger und Fähnrich definieren einen Vorgang als Abfolge von Tätigkeiten, die zur Realisierung von Aufgaben ausgeführt werden. Sie weisen auf die zu berücksichtigenden organisatorischen Dimensionen hin und auf vier Kategorien, mit deren Hilfe sich Vorgänge beschreiben lassen [Bullinger und Fähnrich 1997, S. 19]: x x

x x

Ereignisflüsse steuern die Aktivierung von Aufgaben in Abhängigkeit von auftretenden Ereignissen. Daten- bzw. Objektflüsse modellieren Eingangsinformationen oder -objekte, die zur Aufgabenausführung benötigt werden. Weiterhin modellieren sie die Verwendung der Resultate in nachfolgenden Aufgaben. Dabei ist der Begriff eines Objekts als materielles oder auch immaterielles Objekt weit gefasst. Aufgabenträger repräsentieren Stellen einer Organisation und bearbeiten Aufgaben. Ressourcen sind Materialien, Betriebsmittel oder Aufgabenträger, die zur Aufgabenausführung benötigt werden.

Diese umfassende Beschreibung muss nur noch dahingehend ergänzt werden, dass Vorgänge in anderen Vorgängen bzw. in Geschäftsprozessen enthalten sein können. Funktionen können somit zerlegt bzw. aggregiert werden. Der Zerlegungsprozess sollte allerdings da enden, wo Funktionen erreicht werden, die in einem Arbeitsablauf bearbeitet werden, die also betriebswirtschaftlich nicht mehr sinnvoll zerlegt werden können. Doch kommt es durchaus vor, dass man Beschreibungen von Geschäftsprozessen sieht, bei denen die Zerlegung fast bis zur tayloristischen Ebene vorangetrieben wurde. Diese Techniken der Einteilung von Vorgängen haben Vorläufer, wie z.B. die Rasterdiagramme (auch Ereignisfolgendiagramme), die für die Darstellung der Vorgangsbearbeitung eingesetzt wurden (vgl. für eine Kurzdarstellung [Stahlknecht 1995, S. 266]). Die Abgrenzung erfolgt hier durch Arbeitsschritte bzw. Tätigkeiten im Rahmen des Vorgangs. So verstandene Funktionen verbrauchen Ressourcen und natürlich auch Zeit. Deshalb sind die Ressourcen (vgl. unten) immer mit Funktionen verknüpft. Der Zeitverbrauch für die Funktionen wird in diesem Modellierungsansatz nicht quantifiziert. Es wird also nicht angegeben, wie viel Zeit (höchstens/mindestens) benötigt wird, um die in der Funktion erfassten Tätigkeiten durchzuführen. Die grafische Darstellung von Funktionen in Ereignisgesteuerten Prozessketten ist in der folgenden Abbildung angegeben.

Aggregation von Funktionen

Vorläufer

Zeitverbrauch

62

4 Ereignisgesteuerte Prozessketten - Grundlagen

Abbildung 4.2-1: 4.2.2

Funktionen - grafische Darstellung

Ereignisse

Unter Ereignissen werden hier betriebswirtschaftlich relevante Ereignisse verstanden. Diese Ereignisse beeinflussen und steuern auf die eine oder andere Weise die Abläufe im Unternehmen. Einige Beispiele dafür sind: Steuerung durch Ereignisse

x x x x x x

Auftrag ist eingetroffen Angebot ist gültig Auftragsbestätigung ist übermittelt Überweisung ist vorbereitet Kundenanfrage ist abgelehnt Kunde ist neu (als Ergebnis einer entsprechenden Prüfung)

Zur Definition von Ereignissen können wir (glücklicherweise, es wäre sonst nicht einfach!) auf den umgangssprachlichen Ereignisbegriff zurückgreifen, allerdings mit der Ergänzung, dass es sich um betriebswirtschaftlich relevante Ereignisse handeln muss, die für den betrachteten Geschäftsprozess Bedeutung haben. Etwas enger gefasst wird diese Definition dadurch, dass in diesem Ansatz eine enge Beziehung zwischen Funktionen und Ereignissen gesehen wird. Die Durchführung einer Funktion führt zum Beispiel immer zu einem Ereignis („erledigt“) oder zu mehreren. Ähnlich Österle, wenn er definiert: „Ein Ereignis ist der Auslöser oder das Ergebnis eines Ablaufs“ [Österle 1995, S. 51] Etwas konkreter können Ereignisse so gesehen werden, dass sie die Ergebnisse oder die Bedingungen für die Ausführung von Funktionen beschreiben (vgl. hierzu auch Abschnitt 4.5). Ereignisse sind auf einen bestimmten Zeitpunkt bezogen. Dieser wird allerdings in der Regel nicht spezifiziert. Er wird in den gängigen Darstellungen nur dadurch festgelegt, dass ein Ereignis in eine Kette von Handlungen (Funktionen) und Ereignissen (ein Zweig des Kontrollflusses) eingebettet wird. Mit anderen Worten: Ereignisse lösen Funktionen aus und sind deren Ergebnis. Dies ist der Grund, weshalb Scheer schreibt: „Ein Ereignis kann als Auftreten eines Objekts oder Änderung einer bestimmten Attributsausprägung definiert werden.“ >Scheer 1998, S. 49@ Wobei er hier mit Objekten z.B. Produkte meint. In den Schulungsunterlagen von SAP wird ein Ereignis als ein „betriebswirtschaftlich relevanter Zustand“ beschrieben, der „zum Zeitpunkt

4.2 Elemente

63

seines Eingetretenseins eine oder mehrere Funktionen auslösen kann“ >Schulungsunterlagen Analyzer, S. 2-8@. Ereignisse in diesem Sinn können sich aus vorangegangenen Tätigkeiten sozusagen als Beschreibung der möglichen Ergebnisse ergeben, sie können aber auch auf die nächsten Arbeitsschritte verweisen oder – quasi aus heiterem Himmel – von außen kommen (wie das erste Beispiel am Beginn dieses Abschnitts). Die Menge aller in einem Unternehmen und seinem Umfeld möglichen Ereignisse sollen als der Ereignisraum des Unternehmens bezeichnet werden. Ein Ereignis ist immer auch eine Feststellung, die irgendwie und von irgendjemandem getroffen werden muss. Ihm gehen Handlungen voraus und meistens folgen auch welche nach. Diese werden hier mit dem oben schon eingeführten Begriff der Funktionen erfasst. Ereignisse können, wie Funktionen, zusammengefasst oder auch zerlegt werden. Nehmen wir das bewusst „hoch“ angesiedelte Ereignis „Unternehmen hat keine Gewinne erwirtschaftet.“ Dies könnte genausogut durch die „Ereignisse“ „Absatz ging um x% zurück“, „Kosten lagen bei y DM“, usw. beschrieben werden. Grundsätzlich müssen sich die Ereignisse diesbezüglich an den Funktionen (an deren Aggregationsniveau) orientieren. Zwei Ereignisse eines jeden Geschäftsprozesses verdienen hervorgehoben zu werden: das Startereignis und das Endereignis (oder Schlussereignis). Mit dem Startereignis beginnt ein Geschäftsprozess (davor liegen, bezogen auf den einzelnen Geschäftsprozess, keine Handlungen), mit dem Endereignis findet er seinen Abschluss. Die grafische Darstellung von Ereignissen in Ereignisgesteuerten Prozessketten ist in der folgenden Abbildung angegeben.

Abbildung 4.2-2: 4.2.3

Ereignisraum

Anfang und Ende

Ereignisse - grafische Darstellung

Organisationseinheiten

Mithilfe der Organisationseinheiten wird festgehalten, wo die in einer Funktion erfasste Aufgabe getätigt wird. Die Organisationseinheiten werden also den Funktionen zugeordnet. Sehr oft wird man heute, v.a. wenn der Personalbestand schon sehr niedrig ist und/oder sich das Unternehmen von der klassischen Aufbauorganisation wegbewegt, die Organisationseinheiten sehr klein fassen, evtl. sogar auf Stellenebene gehen, um genügend Aussagekraft für die Analyse der Schwachstellen zu erhalten.

Wer erfüllt die Aufgabe? In welcher Organisationseinheit wird die Aufgabe erfüllt?

64

4 Ereignisgesteuerte Prozessketten - Grundlagen

Beispiele für (klassische) Organisationseinheiten in einem Industrieunternehmen sind Vertrieb, Personalwesen, Werk, Informationsvermittlungsstelle. Die Verbindung von Funktion und Organisationseinheit ist richtungslos und bedeutet, dass die Funktion durch Mitarbeiter der angegebenen Organisationseinheit erledigt wird. Natürlich können einer Funktion auch mehrere Organisationseinheiten zugeordnet werden (vgl. dazu die Beispiele in den Kapiteln 5 und 6). Die grafische Darstellung von Organisationseinheiten in Ereignisgesteuerten Prozessketten ist in der folgenden Abbildung angegeben.

Abbildung 4.2-3:

Organisationseinheiten - grafische Darstellung

Ihre Anbindung an die Funktionen zeigt die folgende Abbildung am Beispiel einer Abteilung Produktion, die für die Funktion Prüfung der Fertigungskapazität verantwortlich ist.

Abbildung 4.2-4:

4.2.4 Welche Informationen werden bei einer Funktion gebraucht? Welche entstehen?

Informationsobjekte zur Unterstützung der Geschäftsprozesse

Anbindung von Organisationseinheiten an Funktionen

Informationsobjekte

Kein Unternehmen kommt heute ohne Datenbestände aus, die das Unternehmen selbst, seine Geschäftsobjekte und seine informationelle Umwelt ganz oder in Ausschnitten modellieren. Diese Datenbestände sind damit auch für die Abwicklung der Geschäftsprozesse von großer Bedeutung. In Ereignisgesteuerten Prozessketten schlägt sich dies so nieder, dass bei den Funktionen die jeweils benötigten oder entstehenden Informationen angegeben werden. Dies können Kundendaten, die Angaben des früher erstellten Angebots, aktuelle Marktpreise oder eine andere Information sein, die für irgendeinen Abschnitt des Geschäftsprozesses Bedeutung besitzt. In diesem Ansatz werden solche Daten als Informationsobjekte bezeichnet und in Verbindung gesetzt mit der Funktion, für die sie benötigt werden. Dann werden z.B. einer Funktion Auftragsbearbeitung Informationen zugeordnet x x

zu Kunden, zum Angebot,

4.2 Elemente

x x x x

65

zu den Materialien, zu den Konditionen, zum Kundenauftrag und zum Bedarf.

Die Beziehung zwischen Informationsobjekten und Funktionen hat eine Richtung. Funktionen benötigen Informationen aus Informationsobjekten, erzeugen aber auch welche, die dann zu den Informationsobjekten dazukommen. Die grafische Darstellung von Informationsobjekten in Ereignisgesteuerten Prozessketten ist in der folgenden Abbildung angegeben.

Abbildung 4.2-5:

Informationsobjekte - grafische Darstellung

Die Verknüpfung mit den Funktionen geschieht durch Pfeillinien. Die Pfeillinie ist wie die zugrunde liegende Beziehung gerichtet und spiegelt den Informationsfluss wider. Fließen Informationen aus dem Informationsobjekt in die Tätigkeit ein, liegt die Pfeilspitze an der Funktion. Entstehen aus der Funktion heraus Informationen, die in das Informationsobjekt einfließen, liegt die Pfeilspitze am Informationsobjekt an. Im folgenden Beispiel fließen Informationen aus einer Datei Produktionsplanung in die Funktion Prüfung Fertigungskapazität ein.

Abbildung 4.2-6:

Informationsfluss vom oder zum Informationsobjekt

Wie im Folgenden zu sehen ist, werden damit Datenflüsse (im Sinne der Datenflussdiagramme) nur erfasst, wenn dieser Teil der Modellierung sehr sorgfältig geschieht, was in der Praxis meist nicht der Fall ist. Informationsobjekte können nicht nur aus Daten von Datenbanken bestehen. Grundsätzlich kann jede Information auf jedem Informationsträger berücksichtigt werden. Der Hinweis auf nicht elektronische Träger kann sogar ein erster Hinweis auf Möglichkeiten zur Optimierung des Geschäftsprozesses sein. Grundsätzlich geben die Informationsobjekte auch Hinweise auf den Automatisierungsgrad des betrachteten Geschäftsprozesses. In nicht oder nur teilweise automatisierten Abschnitten werden die Informationsobjekte in der Regel (aber nicht immer!) nicht digital sein.

Pfeil = Informationsfluss Informationsträger aller Art

Informationsobjekte und Automatisierungsgrad

66

4 Ereignisgesteuerte Prozessketten - Grundlagen

4.2.5 Operatoren

Funktionen miteinander in Beziehung setzen. Ereignisse miteinander in Beziehung setzen.

Operatoren und Kontrollfluss

In Geschäftsprozessen müssen oft mehrere Tätigkeiten „parallel“ erledigt werden, um ein Ziel zu erreichen. Oder es gibt Alternativen: Entweder die eine oder die andere Tätigkeit führt zum Ziel. Genauso mit Ereignissen. Manchmal können alternative Ereignisse dieselbe Tätigkeit auslösen oder mehrere Ereignisse zusammen die Bedingung sein für den Beginn einer Tätigkeit. Dieses Strukturmerkmal stellt jeweils Tätigkeiten oder Ereignisse in eine Beziehung miteinander. In Ereignisgesteuerten Prozessketten also Funktionen bzw. Ereignisse. In Ereignisgesteuerten Prozessketten wird dieses „In-Beziehungsetzen“ durch drei Operatoren modelliert, wie sie in formalen Sprachen üblich sind: das exklusive ODER (auch XODER), das ODER und das UND (für eine Erläuterung vgl. unten). In der grafischen Darstellung erfolgt die Darstellung der Operatoren üblicherweise nicht textlich, sondern mithilfe grafischer Symbole: x x x

UND: ODER: exklusives ODER (auch XODER):

Für Ereignisse, es müssen mindestens zwei sein, sonst gibt es keinen Operator, haben sie folgende Bedeutung: x x x

UND: alle Ereignisse müssen eintreten, erst dann geht es weiter im Kontrollfluss ODER: mindestens eines der Ereignisse muss eintreten, erst dann geht es im Kontrollfluss weiter XODER: genau eines der Ereignisse muss eintreten, erst dann geht es im Kontrollfluss weiter

Für Funktionen, auch hier müssen es mindestens zwei sein, haben sie folgende Bedeutung: x x x

UND: alle Funktionen müssen getätigt werden, erst dann geht es im Kontrollfluss weiter ODER: mindestens eine der Funktionen muss getätigt werden, erst dann geht es im Kontrollfluss weiter XODER: genau eine der Funktionen muss getätigt werden, erst dann geht es im Kontrollfluss weiter

Eine genauere Bestimmung der Bedeutung der Operatoren hängt von der Stellung im Kontrollfluss ab. Davon, ob z.B. die verknüpften Ereignisse vor oder nach einer Funktion stehen. Vgl. hierzu die Verknüpfungsbeispiele unten. Zwei diesbezüglich wichtige Begriffe sollen aber schon hier eingeführt werden.

4.3 Aufbau

67

Hinweis Die Operatoren können nur Ereignisse mit Ereignissen und Funktionen mit Funktionen verknüpfen, nicht Ereignisse mit Funktionen.

!

In den grafischen Darstellungen geht man bei Ereignisgesteuerten Prozessketten von der Festlegung aus, dass der Kontrollfluss der Übersichtlichkeit halber von oben nach unten angeordnet wird. Deshalb werden die Operatoren in der grafischen Notation in einem zweigeteilten Kreis platziert, z.B. so (vgl. auch die folgenden Beispiele):

Die obere Hälfte gibt an, wie die durch die „ankommenden“ Kontrollflüsse repräsentierten Ereignisse oder Funktionen verknüpft sind. Die untere Hälfte leistet dasselbe für die ausgehenden Pfeile. Natürlich werden nur für diejenige Hälfte Operatoren benötigt, die mehr als ein zu verknüpfendes Element (Ereignis oder Funktion) aufweist. Kommt nur ein Pfeil an oder geht nur einer weg, wird auch kein Operator angegeben. Zwei zusätzliche Begriffe sollen bezüglich der Operatoren noch unterschieden werden: Verteiler und Verknüpfer. Kommt ein Zweig an und gehen mehrere weg, wird der Operator als Verteiler bezeichnet. Fließen umgekehrt mehrere hinein und nur einer heraus, handelt es sich um einen Verknüpfer.

4.3

Aufbau

Obige Elemente von Ereignisgesteuerten Prozessketten werden verknüpft um aussagekräftige Beschreibungen von Geschäftsprozessen zu erhalten. Die dafür gültigen Regeln werden in diesem Abschnitt vorgestellt. Um die Anschaulichkeit zu erhöhen, wird den Ausführungen ein einfaches Geschäftsprozessszenario zugrundegelegt.

Szenario Anfrageprüfung Folgendes (vereinfachtes) Geschäftsprozessszenario liegt diesem Abschnitt zugrunde: Es geht – bei einem Industrieunternehmen mit Einzelfertigung – um die Prüfung, ob die Anfrage eines Kunden nach einem bestimmten Produkt erfüllt werden kann oder nicht. Dazu wird, nach Eingang der Anfrage, eine Machbarkeitsprüfung durchgeführt. Diese führt entweder dazu, dass dem Kunden zugesagt oder dass ihm abgesagt wird.

Verteiler und Verknüpfer

68

4 Ereignisgesteuerte Prozessketten - Grundlagen

4.3.1 Funktionen

Funktionen

Beginnen wir mit dem Wichtigsten, das ein Geschäftsprozess aufweist, den Arbeiten, die in ihm geleistet werden. Hier sind ohne weiteres drei Funktionen erkennbar: x x x

die Machbarkeitsprüfung die Zusage an den Kunden die Absage an den Kunden

In der grafischen Notation

Abbildung 4.3-1:

Grafische Darstellung von Funktionen

Weitere kommen vielleicht im Folgenden noch dazu. Nun gilt ja, dass die Funktionen durch Ereignisse verknüpft sind, weshalb wir uns jetzt diesen zuwenden. Zwei sind hier sehr leicht zu finden: Das positive bzw. negative Ergebnis der Funktion Machbarkeitsprüfung: Auftrag ist machbar bzw. Auftrag ist nicht machbar. Außerdem kann als Startereignis Anfrage eingetroffen genommen werden. Dieses Startereignis aktiviert sozusagen den Geschäftsprozess. Die Schlussereignisse werden später betrachtet. Damit ergibt sich für die grafische Darstellung:

Abbildung 4.3-2: Kontrollfluss: immer schön nacheinander

Grafische Darstellung von Ereignissen

Nun müssen aber endlich Funktionen und Ereignisse in Beziehung gesetzt werden. Ganz grundsätzlich wird die Syntaxregel eingehalten, dass Funktionen und Ereignisse sich immer ablösen müssen und dass jeder Geschäftsprozess mit einem Ereignis endet und beginnt (die Ausnahme mit Prozesswegweisern wird unten betrachtet). Der sich dabei ergebende Fluss von Ereignissen und Funktionen ist dann der Kontrollfluss als Ganzes. In der grafischen Notation wird er durch eine gestrichelte Pfeillinie von Ereignis zu Funktion zu Ereignis zu Funktion usw. ausgedrückt. In unserem Beispiel haben wir damit jetzt folgende Abfolgen: Auf das Startereignis Anfrage eingetroffen folgt die Funktion Machbarkeitsprüfung. Dies wird in der grafischen Darstellung so ausgedrückt, dass vom Ereignis zur Funktion eine gestrichelte Linie gezogen wird:

4.3 Aufbau

Abbildung 4.3-3:

69

Abfolge Startereignis – erste Funktion

Nun haben wir oben festgelegt, dass die Machbarkeitsprüfung zu zwei alternativen Ergebnissen führen kann. Dies bedeutet, dass wir nach der Funktion die beiden Ereignisse anordnen und die Art ihres Verhältnisses ausdrücken, z.B. so:

Abbildung 4.3-4:

Abfolge Machbarkeitsprüfung – zwei alternative Ergebnisse als Ereignisse

Wie im vorigen Abschnitt ausgeführt, sind für genau solche Strukturen die drei Operatoren UND, ODER und exklusives ODER (XODER) vorgesehen. Da es sich hier um ein exklusives ODER handelt, kann das obige Beispiel wie in der folgenden Abbildung grafisch korrekt gezeichnet werden.

70

4 Ereignisgesteuerte Prozessketten - Grundlagen

Abbildung 4.3-5:

Abfolge Machbarkeitsprüfung – zwei alternative Ergebnisse als Ereignisse

Auch über die Operatoren wird der Kontrollfluss mit einer gestrichelten Pfeillinie geführt. Fügt man die beiden bis jetzt gefundenen Prozessfragmente zusammen, erhält man eine (zugegeben einfache) Ereignisgesteuerte Prozesskette:

Abbildung 4.3-6:

Geschäftsprozess Anfrageprüfung als Ereignisgesteuerte Prozesskette

Betrachtet man diesen Vorgang der Machbarkeitsprüfung als eigenen abgeschlossenen Geschäftsprozess, werden die beiden Ereignisse Auftrag ist machbar und Auftrag ist nicht machbar zu Schlussereignissen.

4.3 Aufbau

71

Ein klein wenig soll dieses Beispiel noch vertieft werden. Dazu wird die Machbarkeitsprüfung unterteilt in eine Prüfung Lagerbestand und eine Prüfung Fertigungskapazität. Dies führt nach dem Startereignis zu zwei verschiedenen Funktionen, die beide gestartet werden müssen. Eine solche Situation wird in Ereignisgesteuerten Prozessketten durch einen UND-Operator und entsprechende Kontrollflusszweige gelöst, wie in der folgenden Abbildung gezeigt.

Abbildung 4.3-7:

Geschäftsprozess Anfrageprüfung. Etwas vertieft

Natürlich führt jede der beiden neuen Funktionen zu Ergebnissen, die wiederum als Ereignisse modelliert werden49. Hier wurde wieder angenommen, dass es je ein positives und ein negatives gibt: x x

Kapazität reicht und Kapazität reicht nicht für die Prüfung Fertigungskapazität Lagerbestand ausreichend und Lagerbestand reicht nicht für die Prüfung Lagerbestand.

Da diese jeweils alternativ sind, muss hier in den Kontrollfluss (Positionen 1 und 2) ein XODER-Operator eingefügt werden.

49

Folgen auf eine Funktion Ereignisse, die durch ein XODER verknüpft sind, spiegeln die Ereignisse immer alternative Ergebnisse der Funktion wider. Vgl. dazu die Verknüpfungsbeispiele unten.

Vertiefung des Szenarios

Zwei Funktionen anstoßen mit dem UND-Operator

72

UND-Operator

4 Ereignisgesteuerte Prozessketten - Grundlagen

Nun wurde oben festgelegt, dass nur dann, wenn beide Prüfungen positiv ausfallen, dem Kunden die Auftragsannahme zugesagt wird. In der Ereignisgesteuerten Prozesskette bedeutet dies, dass nur dann, wenn die beiden positiven Ereignisse eintreten, die Funktion Kunde zusagen angestoßen wird. Dies wird in einer Ereignisgesteuerten Prozesskette so realisiert, dass die Kontrollflüsse der beiden „positiven“ Ereignisse zusammengeführt, mit einem UND-Operator verbunden (vgl. Position 1) und zur entsprechenden Funktion weitergeführt werden.

Abbildung 4.3-8: Bedingungen durch UND-Operator

Geschäftsprozess Anfrageprüfung. Das positive Ergebnis

Der UND-Operator bedeutet dann, dass der Kontrollfluss über ihn zu der Funktion Kunde zusagen nur weitergeht, wenn tatsächlich beide Kontrollflusszweige „oben“ ankommen. In dieser Anordnung (Ereignisse durch UND verknüpft vor einer Funktion) stellen die Ereignisse immer Bedin-

4.3 Aufbau

73

gungen dar für die Ausführung der nachfolgenden Funktion. In der obigen Abbildung ist dieser positive Fall dargestellt. Anschließend an die Funktion wird dann noch das Ereignis Kunde zugesagt angehängt, dass auch hier wieder Schlussereignis ist. Die anderen beiden (negativen) Ergebnisse führen in diesem (gegenüber der Realität natürlich vereinfachten) Modell zu Absagen. D.h., falls die Prüfung der Fertigungskapazitäten oder die des Lagerbestandes oder falls beide zu einem negativen Ergebnis führen, muss dem Kunden abgesagt werden. In einer Ereignisgesteuerten Prozesskette wird dies so modelliert, dass diese beiden „negativen“ Ereignisse zusammengeführt werden (vgl. Position 1). Der dabei verwendete Operator muss ein ODER-Operator sein, da entweder das eine Ereignis oder das andere oder beide dazu führen sollen, dass der Kontrollfluss über ihn zur Funktion Kunde absagen und zu dem nachfolgenden Ereignis Kunde abgesagt weiterführt. Insgesamt hat der Geschäftsprozess damit zwei Schlussereignisse. Die gestrichelten Pfeillinien spiegeln das wider, was als Kontrollfluss einer Ereignisgesteuerten Prozesskette bezeichnet wird: die möglichen Durchgänge durch den Geschäftsprozess bzw. die Ereignisgesteuerte Prozesskette. Um dies zu verdeutlichen, werden nun verschiedene Kontrollflussszenarien dargestellt. In der Abbildung 4.3-10 ist der Kontrollfluss für den positiven Fall durch eine verdickte durchgezogene Linie hervorgehoben. Zuerst werden vom Startereignis die beiden Prüfungen angestoßen. Dies ist in allen Durchgängen immer gleich. Die beiden Prüfungen müssen jeweils zum positiven Ergebnis führen, d.h. bei den XODER-Operatoren (vgl. Positionen 1 und 2) muss der Kontrollfluss jeweils zu dem Ereignis weiterführen, das den positiven Fall angibt. Danach wird der Kontrollfluss mithilfe eines UND-Operators wieder zusammengeführt (Position 3) und dann zur Funktion Kunde zusagen weitergeleitet. Aus der „Sicht“ der Funktion symbolisieren die beiden vorangestellten Ereignisse damit Bedingungen für den Start der Funktion. Die Erledigung der Funktion Kunde zusagen wird dann noch durch das Schlussereignis Kunde zugesagt dargestellt (Position 4 in Abbildung 4.310).

Die negativen Ergebnisse

„Mindestens ein Ereignis“ mit ODEROperator

Kontrollfluss

Kontrollfluss für den positiven Fall

74

4 Ereignisgesteuerte Prozessketten - Grundlagen

Abbildung 4.3-9:

Geschäftsprozess Anfrageprüfung. Der Kontrollfluss für die Absagen.

4.3 Aufbau

Abbildung 4.3-10:

75

Geschäftsprozess Anfrageprüfung. Der Kontrollfluss für den positiven Fall

Die folgende Abbildung zeigt einen der Kontrollflussdurchgänge, der zu einem negativen Ergebnis führt. Wiederum sind die entsprechenden Kontrollflusspfeile durchgezogen und verdickt.

76

4 Ereignisgesteuerte Prozessketten - Grundlagen

Abbildung 4.3-11:

Geschäftsprozess Anfrageprüfung. Der Kontrollfluss für einen der negativen Fälle

Hier wird zuerst wieder der obere Abschnitt nach dem Startereignis durchlaufen. Die Prüfung der Fertigungskapazität führt dann zu einem

4.3 Aufbau

77

negativen Ergebnis (vgl. Position 1 in der Abbildung), was den Kontrollfluss zum ODER-Operator und dann gleich über ihn hinweg zur Funktion Kunde absagen und zum Schlussereignis führt. Die andere Prüfung (zum Lagerbestand) war positiv (vgl. Position 2), trotzdem bleibt hier der Kontrollfluss beim folgenden UND-Operator „hängen“, da es über ihn nur weiter geht, wenn beide Zweige ankommen. In der Reihenfolge der Funktionen in einem Kontrollflusszweig drückt sich dann auch eine zeitliche Dimension aus. Die Prüfung Lagerbestand kann erst dann aktiviert werden, wenn das Ereignis Anfrage eingetroffen eingetreten ist, die Funktion Kunde absagen nur, wenn vorher das Ereignis Lagerbestand reicht nicht eintrat, usw. Obige Ereignisgesteuerte Prozesskette hat nun schon eine ansehnliche Form, aber einige wichtige Dinge fehlen noch. Beginnen wir mit den im vorigen Abschnitt ja schon angeführten Organisationseinheiten. Hier wurde angenommen, dass die Prüfung der Fertigungskapazität durch die Abteilung Produktion, die Prüfung des Lagerbestandes durch die Abteilung Lager und die Absage bzw. Zusage an den Kunden durch den Vertrieb vorgenommen wird. Abbildung 4.3-12 zeigt die Ereignisgesteuerte Prozesskette mit diesen Organisationseinheiten. Damit fehlen von den Grundelementen für Ereignisgesteuerte Prozessketten nur noch die Informationsobjekte. Abbildung 4.3-13 zeigt die in diesem Abschnitt entwickelte Ereignisgesteuerte Prozesskette ergänzt um Informationsobjekte. Für die beiden Prüfungen wurden entsprechende Datenbestände angenommen. Die Kapazitätsprüfung soll mithilfe von Daten aus der Produktionsplanung und die Prüfung des Lagerbestandes mithilfe einer Lagerdatenbank realisiert werden. Die Zusage bzw. Absage an den Kunden benötigt jeweils das Anfrageschreiben des Kunden und die Kundendatei. Aus der Kundendatei wird gelesen, es wird in ihr aber auch vermerkt, ob der Auftrag angenommen wurde oder nicht.

zeitliche Dimension

Organisationseinheiten

Informationsobjekte

78

4 Ereignisgesteuerte Prozessketten - Grundlagen

Abbildung 4.3-12:

Geschäftsprozess Anfrageprüfung. Mit Organisationseinheiten

4.3 Aufbau

Abbildung 4.3-13:

Geschäftsprozess Anfrageprüfung. Mit Informationsobjekten

79

80

4 Ereignisgesteuerte Prozessketten - Grundlagen

4.3.2 Einfach und erweitert

Varianten

Zwei Varianten von Ereignisgesteuerten Prozessketten sollen noch unterschieden werden: x x

erweiterte Ereignisgesteuerte Prozessketten (eEPK) und einfache Ereignisgesteuerte Prozessketten (EPK)

Werden in der grafischen Darstellung nur Ereignisse und Funktionen berücksichtigt und keine Organisationseinheiten und Informationsobjekte, spricht man von einfachen Ereignisgesteuerten Prozessketten. Ein Beispiel dafür ist die EPK von Abbildung 4.3-9. Werden zusätzlich auch Organisationseinheiten und Informationsobjekte berücksichtigt, entstehen erweiterte Ereignisgesteuerte Prozessketten. Ein Beispiel dafür ist die eEPK von Abbildung 4.3-13. 4.3.3

Zusammenfassung der Syntaxregeln

Zu einer semi-formalen Sprache gehören Regeln, mit denen die zulässigen Verknüpfungen der Elemente festgelegt werden. Diese wurden oben schon angedeutet und sollen hier zusammenfassend angeführt werden: x

x

x

x

x

Ereignisse werden im Kontrollfluss nur mit Funktionen verknüpft. Bis auf das Start- und Schlussereignis gilt: auf ein Ereignis folgt eine Funktion, auf eine Funktion ein Ereignis. Diese Verknüpfung von Ereignissen und Funktionen wird durch eine in der Regel gestrichelte Pfeillinie grafisch ausgedrückt. Organisationseinheiten werden nur mit Funktionen verbunden und zwar mit denen, bei denen sie mitwirken (genauer: bei denen Mitarbeiter aus der jeweiligen Organisationseinheit mitwirken). Die Verknüpfung erfolgt mittels einer durchgezogenen Linie. Informationsobjekte werden ebenfalls nur mit Funktionen verbunden und zwar mit denen, für deren Erfüllung sie benötigt werden. Wird also z.B. im Rahmen einer Auftragsabwicklung die Funktion Rechnungserstellung angesprochen, wird sie mit Sicherheit das Informationsobjekt Kundendaten benötigen. Die Verknüpfung wird durch Pfeile dargestellt. Die Operatoren verknüpfen jeweils entweder mehrere Ereignisse oder mehrere Funktionen. Mit der Regel (vgl. oben), auf Ereignisse folgen Funktionen und umgekehrt, ergibt sich somit, dass auf verknüpfte Ereignisse eine Funktion (oder mehrere) folgen muss und umgekehrt, sodass jeder Operator auch weiterführen muss. Die Abfolge von Funktionen und Ereignissen gibt den sog. Kontrollfluss einer Ereignisgesteuerte Prozesskette an.

4.4 Verknüpfungsbeispiele

4.3.4

81

Zusätzliche Operatoren

Rosemann schlug einige ergänzende Operatoren vor. Der ET-Operator (vgl. [Rosemann 1996], eine Kurzbeschreibung findet sich in [Rump 1999, S. 62f]) ist so definiert, dass ihm eine Entscheidungstabelle zugeordnet werden kann. Die Bedingungen und Regeln der Entscheidungstabelle bestimmen dann, welche der nachfolgenden Funktionen ausgelöst wird. Der SEQ-Operator (vgl. [Rosemann 1996], eine Kurzbeschreibung findet sich in [Rump 1999, S. 63]) erlaubt auszudrücken, dass Funktionen in beliebiger Reihenfolge, aber nicht parallel ausgeführt werden dürfen. Diese ausdrückliche Nichtparallelität kann mit den Standardoperatoren direkt nicht ausgedrückt werden. Der OR1-Operator (vgl. [Rosemann 1996], eine Kurzbeschreibung findet sich in [Rump 1999, S. 64f]) steuert wie der OR-Operator, allerdings kann durch eine „1“ an einem der Kontrollflusszweige angegeben werden, dass dieser immer durchlaufen wird. Für die beiden letztgenannten Operatoren gibt es entsprechende Darstellungsweisen mit den Standardoperatoren. Im Falle des SEQ-Operators werden einfach mehrere durch XOR verknüpfte Zweige gebildet, die die unterschiedlichen Abfolgen enthalten. Im Falle des OR1-Operators wird der ODER-Operator durch ein XODER ersetzt, dem ein UND-Operator folgt. Von beiden Operatoren führt der Kontrollfluss zu einem XODER und von dort zu dem Zweig, der auf jeden Fall aktiv wird. Vom UNDOperator aus geht es dann noch zu dem Zweig weiter, der nicht unbedingt aktiv werden muss.

4.4

Verknüpfungsbeispiele

In diesem Abschnitt werden die möglichen Anordnungen von Ereignissen und Funktionen bezüglich der Verknüpfungen vertieft betrachtet. Dazu wird (vgl. auch die folgende Abbildung) für jeden der drei Operatoren unterschieden, ob Ereignisse oder Funktionen verknüpft werden. Wird für diese sechs Varianten dann noch unterschieden, ob die Ereignisse im jeweiligen EPK-Fragment vorangehen oder nachfolgen, ergeben sich die zwölf Varianten. Für die Anordnung, bei der zuerst Ereignisse und dann Funktionen folgen, soll von auslösenden Ereignissen (aE) gesprochen werden. Die Bedeutung dieses Begriffs wird unten bei den inhaltlich aussagekräftigen Beispielen klarer, wenn deutlich wird, dass bei dieser Anordnung tatsächlich die Ereignisse so etwas wie Auslöser für die nachfolgenden Funktionen sind. Im umgekehrten Fall, wenn Ereignisse nach Funktionen folgen, wird von erzeugten Ereignissen (eE) gesprochen. Auch hier werden die Beispiele unten zur Verdeutlichung beitragen.

12 Varianten

Auslösende und erzeugte Ereignisse

82

4 Ereignisgesteuerte Prozessketten - Grundlagen

Abbildung 4.4-1:

Zwölf Varianten für die Anordnung von Ereignissen und Funktionen im Kontrollfluss

Denselben Sachverhalt drückt die folgende Abbildung aus, mit der im Handbuch des R/3-Analyzer die Verknüpfungsvarianten zusammengefasst werden.

Abbildung 4.4-2:

Zulässige und nicht zulässige Verknüpfungen Quelle: SAP R/3-Analyzer Release 2.1 (Handbuch), S. 2-30

Die grau unterlegten Verknüpfungen sind nicht zulässig. Dazu unten mehr. Im Folgenden werden nun, entlang der obigen Tabelle, von oben nach unten und von links nach rechts, die einzelnen Anordnungen nacheinander diskutiert, mit jeweils einem abstrakten und mindestens einem inhaltlich aussagekräftigen Beispiel.

4.4 Verknüpfungsbeispiele

83

Bei allen nachfolgenden inhaltlichen Beispielen handelt es sich um Ausschnitte aus größeren Ereignisgesteuerten Prozessketten.

Hinweis In den folgenden Beispielen wird im Operatorkreis jeweils auf einer Seite ein Operator angesetzt, auf der anderen nicht. D.h., auf einer Seite wird verknüpft, auf der anderen nicht. Aus diesen Grundkombinationen können alle zulässigen Anordnungen mit Operatoren auf beiden Seiten zusammengestellt werden. Um die Übersichtlichkeit zu erhöhen wird der Kontrollfluss immer von oben nach unten angeordnet, sodass die eine Seite des Operatorkreises oben und die andere unten ist. Außerdem werden in den abstrakten Beispielen bei Verknüpfungen immer zwei Ereignisse bzw. Funktionen angenommen. Dies steht natürlich für beliebig viele.

Dank Nicht wenige der Beispiele dieses Abschnitts verdanke ich den Teilnehmern meiner Seminare, die aus ihren „Weltausschnitten“, d.h. aus ihrem beruflichen Umfeld berichteten. Vielen Dank dafür! 4.4.1

Ereignisverknüpfung mit auslösenden Ereignissen

Ereignisverknüpfung mit auslösenden Ereignissen bedeutet immer, dass Ereignisse so etwas wie Bedingungen für die nachfolgend auszuführende Funktion (es können auch mehrere sein) sind. Bei der Verknüpfung von auslösenden Ereignissen durch ein exklusives ODER (vgl. die folgende Abbildung) handelt es sich um alternative Ereignisse für die gilt, dass genau eines eintreten muss, damit es im Kontrollfluss weiter geht, damit also die nachfolgende Funktion gestartet wird. Die auslösenden Ereignisse stellen hier somit Bedingungen dar, von denen genau eine eintreten muss (erfüllt sein muss) damit der Geschäftsprozess weiterschreiten kann. Im folgenden Beispiel ganz konkret: Ereignis 1 oder Ereignis 2 muss eintreten, damit die Funktion starten kann.

Ereignisse als Bedingungen XODER

84

4 Ereignisgesteuerte Prozessketten - Grundlagen

Abbildung 4.4-3:

Exklusives ODER / Ereignisverknüpfung / auslösende Ereignisse

Im folgenden inhaltlichen Beispiel geht es um Bestellungen. Angenommen wird, dass diese entweder per Brief oder per Fax eintreffen. Die beiden Ereignisse sind natürlich alternativ, was der Logik des exklusiven ODER entspricht. Somit gilt: Die Auftragsbearbeitung wird nur gestartet, falls eines der beiden Ereignisse zuvor eingetreten ist.

Abbildung 4.4-4: Bedingungen mit dem UND-Operator

Ereignisverknüpfung / Auslösende Ereignisse / XODER

Werden auslösende Ereignisse mit dem UND-Operator verknüpft, müssen alle durch die Ereignisse repräsentierten Ereignisse eingetreten sein, bevor der Kontrollfluss über den Operator weiter geht. In einer solchen Situation haben die Ereignisse den Charakter von gemeinsamen Bedingungen für das Starten der Funktion: Die Funktion wird erst gestartet, wenn die Ereignisse eingetreten sind. Damit gilt im folgenden Beispiel, dass Ereignis 1 und Ereignis 2 eingetreten sein müssen, erst dann startet die Funktion.

4.4 Verknüpfungsbeispiele

Abbildung 4.4-5:

85

Ereignisverknüpfung / auslösende Ereignisse / UND

Im folgenden inhaltlichen Beispiel geht es um eine Situation nach einem Auftragseingang. Hier wird mit der Produktionsplanung erst begonnen, wenn Kapazitäten frei sind und die notwendigen Rohstoffe usw. vorhanden sind.

Abbildung 4.4-6:

Ereignisverknüpfung / Auslösende Ereignisse / UND

Auf diese Weise lassen sich Regeln und Bestimmungen, die den jeweiligen Prozess betreffen, miteinbeziehen. Die Ereignisverknüpfung mit dem logischen ODER bedeutet, dass mindestens eines der parallel angeordneten Ereignisse eintreten muss, damit die nachfolgende Funktion gestartet werden kann. Wie die Formulierung aber bereits sagt, können auch mehrere oder alle Ereignisse eintreten. Im folgenden abstrakten Beispiel müssten also entweder Ereignis 1 oder Ereignis 2 oder beide eintreten.

ODER

86

4 Ereignisgesteuerte Prozessketten - Grundlagen

Abbildung 4.4-7:

ODER / Ereignisverknüpfung / auslösende Ereignisse

Im folgenden Beispiel geht es um die Frage, ob Eltern eine Ermäßigung gewährt werden kann, wenn ihr Kind eine Kindertagesstätte (KITA) besucht. Die (fiktiven) Kriterien dafür wurden als Ereignisse formuliert: x x x x

Möglichkeit einer Geschwisterermäßigung liegt vor (weil bereits Geschwister des Kindes in der Kindertagesstätte sind). Das Einkommen der Erziehungsberechtigten liegt unter 3.600,-- Euro. Der/die Erziehungsberechtigte ist allein erziehend. Der die Erziehungsberechtigte ist Sozialhilfeempfänger.

Wenn mindestens eines der Ereignisse eintritt, wenn also mindestens ein Kriterium erfüllt ist, dann kann die Ermäßigung gegeben werden. Somit kann der ODER-Operator eingesetzt werden.

4.4 Verknüpfungsbeispiele

Abbildung 4.4-8:

87

Ereignisverknüpfung / Auslösende Ereignisse / ODER 1

Bei diesem Beispiel stellt sich die Frage, warum überhaupt die verschiedenen Ereignisse (Kriterien) angegeben werden. Genügt nicht auch einfach ein Ereignis Ermäßigungsgrund liegt vor nach einer Funktion, die dieses prüft? Dies wäre ohne weiteres möglich. Sehr oft möchte man aber die verschiedenen möglichen Möglichkeiten in der Ereignisgesteuerten Prozesskette dokumentieren. Dann ist die obige Ausgestaltung sinnvoll. Das folgende Beispiel beschreibt eine ähnliche Situation bei einem Versicherungsunternehmen. Die Meldung über einen Schadensfall kann durch den Versicherten, durch den Geschädigten, durch die Servicestelle oder in seltenen Fällen auch durch die Polizei erfolgen. Sie kann aber auch durch mehrere dieser „Melder“ erfolgen, z.B. durch Versicherer und Geschädigten, usw. Damit ist auch hier das logische Oder der richtige Operator.

88

4 Ereignisgesteuerte Prozessketten - Grundlagen

Abbildung 4.4-9:

Ereignisverknüpfung / Auslösende Ereignisse / ODER 2

Auch hier ist damit das Oder erfüllt. Für den konkreten Geschäftsprozess bedeutet dies ganz praktisch, dass eine eventuelle „Mehrfachnennung“ (derselbe Schadensfall wird mehrfach gemeldet) abgefangen werden muss. Wie oben schon angemerkt, können durch ODER verknüpfte Ereignisse immer auch zusammengefasst werden, wie im folgenden Beispiel gezeigt. Alternative zu ODER

Abbildung 4.4-10:

Alternative zur ODER-Verknüpfung von Ereignissen

Spaltet man jedoch auf, will man die möglichen Alternativen und die Kombinationen dokumentieren. Vielleicht wird ja auch diese Information an einer anderen Stelle der Ereignisgesteuerten Prozesskette benötigt. So z.B. bei dem Fragment zur Gewährung der Beitragsermäßigung. Obwohl für den weiteren Ablauf nicht unbedingt nötig, könnte es in bestimmten Fällen sehr nützlich sein zu wissen, welche Kriterien der Grund für die Ermäßigung waren. Allerdings müsste dann diese Informationsspeicherung noch mithilfe von Informationsobjekten hinzumodelliert werden.

4.4 Verknüpfungsbeispiele

89

Die beiden obigen Beispiele machen deutlich, dass mit ODER verknüpfte Ereignisse nur zusammen den weiteren Verlauf des Geschäftsprozesses bestimmen, nicht einzeln. 4.4.2

Ereignisverknüpfung mit erzeugten Ereignissen

Ereignisverknüpfung mit erzeugten Ereignissen bedeutet immer, dass sich aus der Durchführung einer Funktion (oder mehrerer) Ereignisse ergeben, die entsprechend den Operatoren in einem bestimmten Verhältnis stehen. Dabei haben die Ereignisse oft den Charakter von Feststellungen, die das Ende der Tätigkeiten festlegen, die im Rahmen der Funktion (oder mehrerer) ausgelöst wurden. Beim exklusiven ODER bedeutet dies, dass die Ereignisse die möglichen alternativen Ergebnisse der vorangehenden Funktion festhalten. Das heißt, genau eines der Ereignisse muss eintreten, dann geht es im Kontrollfluss weiter. Hier also: Entweder Ereignis 1 oder Ereignis 2 muss eintreten, dann ist die Funktion abgearbeitet.

Abbildung 4.4-11:

Exklusives ODER / Ereignisverknüpfung / erzeugte Ereignisse

Dies macht auch das folgende inhaltliche Beispiel deutlich. Es soll - in einem Verlag - den Ablauf erfassen, der zum Versenden der Bücher führt. Nachdem eine Buchsendung versandfertig gemacht wurde, wird sie mit einer der Transportgesellschaften versandt. Natürlich nur mit einer, da die Sendung ja nur einmal versandt werden kann. Die Ereignisse geben hier also mögliche alternative Ergebnisse an.

Ereignisse signalisieren die Durchführung einer Funktion

Exklusives ODER

90

4 Ereignisgesteuerte Prozessketten - Grundlagen

Abbildung 4.4-12: Teilaufgaben mit UND

Ereignisverknüpfung / Erzeugte Ereignisse / XODER

Ganz anders beim logischen UND. Hier signalisieren die nachfolgenden Ereignisse Teilaufgaben, die sich aus der Abarbeitung der Funktion ergeben. Es sind die Teilergebnisse, die für so wichtig erachtet werden, dass sie in der Modellierung auftauchen sollen. Formal gesprochen: alle nachfolgenden Ereignisse müssen eintreten (alle Teilaufgaben müssen erledigt sein), dann geht es im Geschäftsprozess weiter. Im abstrakten Beispiel müssen also Ereignis 1 und Ereignis 2 eingetreten sein, bevor es im Kontrollfluss weitergeht.

Abbildung 4.4-13:

UND / Ereignisverknüpfung / erzeugte Ereignisse

4.4 Verknüpfungsbeispiele

91

Das folgende inhaltliche Beispiel stammt aus dem Krankenhausbereich und beschäftigt sich mit dem Vorgang der Entlassung von Patienten nach einem stationären Aufenthalt. Vereinfacht wurde angenommen, dass hierzu das Bezahlen der Telefonrechnung, des Eigenanteils und die Erstellung der endgültigen Abrechnung gehört.

Abbildung 4.4-14:

Ereignisverknüpfung / Erzeugte Ereignisse / UND

Der UND-Operator bedeutet hier nicht Parallelität (der Teilaufgaben), sondern nur, dass diese erledigt sein müssen, bevor die nächste Funktion gestartet werden kann. Die Syntax des ODER-Operators sagt in der Anordnung des folgenden Beispiels, dass mindestens ein Ereignis eintreten muss, damit es im Kontrollfluss weitergeht. Hier also: Ereignis 1 oder Ereignis 2 oder beide.

Abbildung 4.4-15:

ODER / Ereignisverknüpfung / erzeugte Ereignisse

ODER

92

Erledigung von Aufgaben

4 Ereignisgesteuerte Prozessketten - Grundlagen

In semantischer Hinsicht bedeutet dies, wie immer bei ausgelösten Ereignissen, dass die Ereignisse die Erledigung von Aufgaben signalisieren. Hier aber nicht von Teilaufgaben (wie beim UND) oder von alternativen Aufgaben (wie beim exklusiven ODER), sondern von Aufgaben, die einzeln oder auch zusammen (in beliebiger Kombination) anfallen können. Die Ausführung der Funktion hat somit zwar Konsequenzen (die durch die Ereignisse angegeben werden), deren genaue Ausprägung ist aber nicht vorab klar angebbar. Das inhaltliche Beispiel der folgenden Abbildung zeigt eine solche Situation. In diesem Unternehmen kann die Wareneingangsprüfung dazu führen, dass die Ware eingelagert werden muss, dass eine Umverpackung notwendig ist, dass die Qualitätskontrolle bemüht werden muss oder dass mehrere dieser Tätigkeiten in beliebiger Kombination anfallen.

Abbildung 4.4-16:

Unabhängigkeit

Strukturiertes ODER

Ereignisverknüpfung / erzeugte Ereignisse / ODER

Natürlich gibt es Kriterien dafür, welche der Tätigkeiten konkret anfallen, diese wurden aber nicht modelliert (dann würde dieses ODER wegfallen), sie sind sozusagen nur im Kopf desjenigen vorhanden, der die Funktion ausführt. Bei erzeugten Ereignissen, die durch einen ODER-Operator verknüpft sind, stellt sich immer wieder die Frage, ob die durch ein ODER verknüpften Ereignisse unabhängig voneinander sind, d.h. ob wirklich jedes unabhängig von den anderen in irgendeiner Kombination auftreten kann? Hierzu zwei Beispiele. Nimmt man im obigen Beispiel zu den Ereignissen dasjenige hinzu, das signalisiert, dass keine der anderen Aktionen nötig ist (Keine Aktion notwendig), entsteht die in der folgenden Abbildung angegebene Ereignisgesteuerte Prozesskette. Dies liegt durchaus nahe und wird auch oft so gemacht.

4.4 Verknüpfungsbeispiele

Abbildung 4.4-17:

93

Ereignisverknüpfung / erzeugte Ereignisse / ODER

Damit kommt es aber zu einer Veränderung im Verhältnis der Ereignisse untereinander. Das Ereignis Keine Aktion notwendig kann nur eintreten, wenn keines der anderen Ereignisse eintritt. Während vorher die Ereignisse in beliebiger Kombination auftreten konnten, gilt dies nicht mehr. Die Ereignisse sind nicht mehr unabhängig voneinander.

Definition Eine Gruppe von mit ODER verknüpften Ereignissen ist unabhängig voneinander, wenn die Semantik zulässt, dass die Ereignisse in beliebiger Kombination auftreten können. Dies widerspricht aber den Regeln des ODER-Operators, zumindest in der engen semantischen Auslegung, dass heißt, wenn der Bedeutungsgehalt der Ereignisse (die Semantik) berücksichtigt wird. Rein syntaktisch, wenn es nur darum geht, dass mindestens ein Ereignis eintreten muss, ist das ODER allerdings weiterhin erfüllt. Eine ähnliche Situation liegt im folgenden Beispiel aus dem Genossenschaftsbankwesen vor. Die angegebenen Ereignisse können, so wurde mir versichert, in fast beliebiger Kombination auftreten, wobei eines auf jeden Fall eintritt, da er oder sie ja bereits Kunde ist. Auch hier sind allerdings die Ereignisse nicht unbedingt voneinander unabhängig. Um nur einige Beispiele zu nennen: x x x

Für Online-Banking braucht man entweder ein Girokonto oder ein Depot. Ein Darlehen gibt‘s nur, wenn der Darlehensnehmer ein Konto hat. Im Falle eines Schließfaches muss ein Konto vorhanden sein.

Syntax vs. Semantik

94

4 Ereignisgesteuerte Prozessketten - Grundlagen

Diese innere Strukturierung wird hier nicht mitmodelliert. Sollte sie modelliert werden, würde die EPK etwas komplizierter.

Abbildung 4.4-18:

4.4.3 Ereignis startet Funktionen

Ereignisverknüpfung / erzeugte Ereignisse / ODER

Funktionsverknüpfung mit auslösenden Ereignissen

Funktionsverknüpfung mit auslösenden Ereignissen bedeutet immer, dass das Eintreten eines Ereignisses nachfolgende Funktionen startet. Entweder genau eine von mehreren (XODER), mehrere zusammen (UND) oder mindestens eine (ODER).

4.4 Verknüpfungsbeispiele

95

Mit dem ersten Beispiel kommen wir zur ersten verbotenen Struktur. Dabei geht es um Ereignisse, denen ein XODER-Operator nachfolgt, die also eine von mehreren mit dem exklusiven ODER verknüpften Funktionen auslösen.

Abbildung 4.4-19:

XODER

Exklusives ODER / Funktionsverknüpfung / auslösende Ereignisse

Betrachten wir das folgende Beispiel eines Auftragseingangs. Dem Ereignis des Auftragseingangs folgt entweder die Annahme oder die Ablehnung des Auftrags. Obwohl dieser Prozessausschnitt aufgrund seiner Schlichtheit eine gewisse Faszination ausübt, wird doch nach kurzem Nachdenken deutlich, dass hier ein wichtiger Abschnitt des realen Geschäftsprozesses nicht modelliert wurde: die Entscheidungsfindung, die Analyse der Machbarkeit, usw. Die EPK „springt“ sozusagen gleich von dem Ereignis zur Ausführung einer der Funktionen.

Fehlende Entscheidungsfunktion

XODER - verboten

Abbildung 4.4-20:

Funktionsverknüpfung / auslösendes Ereignis/ XODER ohne Entscheidungsfunktion

96

4 Ereignisgesteuerte Prozessketten - Grundlagen

Das ist der Grund, weshalb eine solche Struktur - sozusagen - verboten ist. Tritt sie auf, muss sie um eine Funktion ergänzt werden, die den Entscheidungsprozess modelliert und um Ereignisse, mit denen die möglichen Ergebnisse des Entscheidungsprozesses erfasst werden. Obiger Ausschnitt ist dann wie in der folgenden Abbildung zu modellieren. Richtige Lösung mit Entscheidungsfunktion

Abbildung 4.4-21:

UND: Ereignis startet mehrere Funktionen

Funktionsverknüpfung / auslösendes Ereignis/ XODER mit Entscheidungsfunktion

Mit der Entscheidungsfunktion (hier: Machbarkeitsprüfung) kommen dann auch die Ereignisse in die EPK, mit denen die möglichen Ergebnisse des Entscheidungsprozesses angedeutet werden. Diese Ergebnisereignisse erhöhen dann auch die Aussagekraft der Ereignisgesteuerten Prozesskette. Die Ergebnisereignisse Machbarkeit wird bejaht und Machbarkeit wird verneint sind auch aus syntaktischen Gründen notwendig, da ja auf eine Funktion nur ein Ereignis oder mehrere folgen dürfen. Bei einem UND gibt es dagegen keine Probleme. Ein Ereignis kann zum parallelen Start zweier oder mehrerer Funktionen führen. Im folgenden abstrakten Beispiel: Das Ereignis stößt Funktion 1 und Funktion 2 an.

4.4 Verknüpfungsbeispiele

Abbildung 4.4-22:

97

UND / Funktionsverknüpfung / auslösendes Ereignis

Auch hierzu ein inhaltliches Beispiel. Das Ereignis Auftrag eingegangen stößt die beiden Funktionen Machbarkeit prüfen und Auftragseingang bestätigen an.

Abbildung 4.4-23:

Funktionsverknüpfung / auslösendes Ereignis/ UND

Diese Struktur ist wohl bekannt: ein Ereignis führt zu mehreren zu erledigenden Aufgaben. Wie immer beim logischen UND bedeutet die parallele Anordnung nicht, dass die Aufgaben tatsächlich parallel erledigt werden, sondern nur, dass sie bis zum nächsten Operator erledigt sein müssen. Ein zweites inhaltliches Beispiel möge den Sachverhalt noch verdeutlichen. Ist in einer Spedition ein Transportauftrag erteilt, muss der Fahrer benachrichtigt, die Auftragsbestätigung geschrieben und es müssen die Transportpapiere erstellt werden. Hier kann mit Sicherheit von einer Rei-

98

4 Ereignisgesteuerte Prozessketten - Grundlagen

henfolge der Tätigkeiten ausgegangen werden, auf deren Modellierung aber bei Verwendung des UND verzichtet wird.

Abbildung 4.4-24: ODER – verboten

Funktionsverknüpfung / auslösendes Ereignis/ UND

Die folgende ODER-Verknüpfung ist wieder eine verbotene, ganz wie oben bei den durch XODER ausgelösten Funktionen. So wie sie im folgenden Beispiel dasteht bedeutet sie, dass das Ereignis mindestes eine der nachfolgenden Funktionen auslöst, also entweder Funktion 1 oder Funktion 2 oder beide.

Abbildung 4.4-25:

Funktionsverknüpfung / auslösende Ereignisse / ODER

4.4 Verknüpfungsbeispiele

99

Beim folgenden inhaltlichen Beispiel soll es um eine Kontoeröffnung gehen. Ist diese erfolgt, kann der Kunde verschiedene Leistungen anfordern.

Abbildung 4.4-26:

Funktionsverknüpfung / auslösendes Ereignis/ ODER ohne Entscheidungsfunktion

Auch hier fehlt wieder der Entscheidungsprozess in Form einer Funktion. In der nächsten Abbildung ist er zusammen mit den erforderlichen Ereignissen eingefügt. Die Entscheidungsfunktion kann hier mit Entscheidung im Gespräch mit dem Kunden umschrieben werden. Die Ergebnisse sind dann, in diesem vereinfachten Beispiel, die Ereignisse Geldkarte soll ausgestellt werden und Dispokredit ist gewünscht. Der genaue Ablauf wird dann durch die Semantik festgelegt, wie bei einem exklusiven ODER, wo ja auch aus der Syntax der weitere Verlauf nicht erkennbar ist.

Fehlende Entscheidungsfunktion

100

4 Ereignisgesteuerte Prozessketten - Grundlagen

Richtige Lösung mit Entscheidungsfunktion

Abbildung 4.4-27:

Funktionsverknüpfung / auslösendes Ereignis/ ODER mit Entscheidungsfunktion

Syntaxregel Nach einem Ereignis (oder nach mehreren) darf kein ODER- oder XODER-Operator (für die dann ja notwendigerweise nachfolgenden Funktionen) folgen. Mit anderen Worten: Auslösende Ereignisse mit XODER und ODER sind nicht erlaubt. 4.4.4 Erledigung von Funktionen

XODER

Funktionsverknüpfung mit erzeugten Ereignissen

Erzeugte (also nachfolgende) Ereignisse entstehen, wenn die Beendigung mehrerer Funktionen durch ein- und dasselbe Ereignis angegeben werden kann. Im Falle des exklusiven ODER sind dies alternativ auszuführende, im Falle des UND parallel zu erledigende und im Falle des ODER Funktionen, von denen mindestes eine getätigt werden muss. Betrachten wir zuerst das exklusive ODER. Im folgenden abstrakten Beispiel müssen entweder Funktion 1 oder Funktion 2 durchgeführt werden, dann tritt das Ereignis ein.

4.4 Verknüpfungsbeispiele

101

Alternative Tätigkeiten

Abbildung 4.4-28:

Exklusives ODER / Funktionsverknüpfung / erzeugte Ereignisse

Die Anordnung der Funktionen mit einer XODER-Verknüpfung deutet mögliche Alternativen bzgl. der zu erledigenden Aufgaben an, die aber alle zum selben Ergebnis führen. Dies ist eine Struktur, die in der Realität sehr oft vorkommt. Natürlich könnten statt einem einzelnen Ereignis auch mehrere folgen. Im folgenden inhaltlichen Beispiel wird ein Versand durchgeführt. Er erfolgt hier entweder mit der einen oder der anderen Transportgesellschaft. Welche auch immer gewählt wurde, danach tritt das Ereignis Versand erfolgt ein. XODER

Abbildung 4.4-29:

Funktionsverknüpfung / erzeugtes Ereignis / XODER

102

UND

4 Ereignisgesteuerte Prozessketten - Grundlagen

Das logische UND bedeutet in dieser Anordnung, dass mehrere Funktionen getätigt werden müssen, bevor das nachfolgende Ereignis eintritt. In der folgenden Abbildung müssen also Funktion 1 und Funktion 2 durchgeführt werden, erst dann tritt das Ereignis ein.

Abbildung 4.4-30:

UND / Funktionsverknüpfung / erzeugtes Ereignis

Die Funktionsverknüpfung mit dem logischen UND bedeutet also, dass mehrere Tätigkeiten „gleichzeitig“ erledigt werden müssen, bevor es mit dem Geschäftsprozess weitergeht. Ob diese Tätigkeiten in der Realität wirklich auch parallel erledigt werden, ist modelltechnisch ohne Bedeutung. Sie können genauso gut auch hintereinander abgearbeitet werden. Im folgenden inhaltlichen Beispiel stellen wir uns vor, dass in einem Unternehmen bei Neueinstellungen jeder Bewerber an einem Assessment Center teilnimmt, dass mit ihm oder ihr ein Gespräch geführt wird und dass die eingesandten Unterlagen inspiziert werden. Erst danach geht es mit dem Auswahlprozess weiter.

4.4 Verknüpfungsbeispiele

Abbildung 4.4-31:

103

Funktionsverknüpfung / erzeugtes Ereignis / UND

Auf die Modellierung einer eventuellen Reihenfolge wird bei Wahl des UND verzichtet. Ausgelöste (also nachfolgende) Ereignisse nach einem ODER bedeuten, dass mindestens eine der Funktionen durchgeführt werden muss, damit das Ereignis eintritt. Syntaktisch und im folgenden abstrakten Beispiel: Entweder Funktion 1 oder Funktion 2 oder beide müssen getätigt werden, damit das nachfolgende Ereignis eintritt.

Abbildung 4.4-32:

Funktionsverknüpfung / erzeugte Ereignisse / ODER

ODER

104

4 Ereignisgesteuerte Prozessketten - Grundlagen

Im folgenden inhaltlichen Beispiel tritt das Ereignis Kundenwünsche erfüllt ein, wenn die davor stehenden Funktionen im Sinne des ODER („mindestens eine“) durchgeführt wurden. Um dieses EPK-Fragment verstehen zu können wurden in der Abbildung die den Funktionen vorgestellten Ereignisse und Funktionen mitangegeben. Dies macht auch deutlich, wie es zu einer solchen Anordnung kommen kann.

Abbildung 4.4-33:

Funktionsverknüpfung / erzeugtes Ereignis / ODER

So weit die Betrachtung der grundsätzlich möglichen Verknüpfungen zwischen Ereignissen und Funktionen. Die folgende Abbildung fasst einige der Ergebnisse zusammen.

4.5 Mehrere Operatoren im Kreis

Ereignisverknüpfung: Ereignisse werden verknüpft.

105

XODER

UND

ODER

Genau eines der alternativen Ereignisse muss eintreten.

Alle Ereignisse müssen eintreten.

Mindestens eines der Ereignisse muss eintreten.

Die Ereignisse signalisieren die Erledigung von Aufgaben („Ergebnisereignisse“). Auslösende Ereignisse:

Die Ereignisse geben die möglichen alternativen Ergebnisse an.

Die Ereignisse geben Teilaufgaben an.

Mindestens ein Ergebnis (Ereignis) tritt ein

Nachfolgende Funktion(en).

Das Ereignis stößt genau eine Funktion an. VERBOTENE STRUKTUR.

Das Ereignis stößt mehrere Funktionen an.

Das Ereignis stößt mindestens eine Funktion an. VERBOTENE STRUKTUR.

Das Ereignis tritt ein, wenn genau eine der Funktionen durchgeführt wurde.

Das Ereignis tritt ein, wenn alle Funktionen durchgeführt wurden.

Das Ereignis tritt ein, wenn mindestens eine der Funktionen durchgeführt wurde.

Auslösende Ereignisse: Nachfolgende Funktion(en). Die Ereignisse sind Bedingungen für die nachfolgend auszuführende(n) Funktion(en). Erzeugte Ereignisse: Vorangehende Funktion(en).

Funktionsverknüpfung: Funktionen werden verknüpft.

Das Ereignis stößt Funktionen an. Erzeugte Ereignisse: Vorangehende Funktion(en). Das Ereignis signalisiert die Beendigung mehrerer Funktionen.

Abbildung 4.4-34:

4.5

Die Rolle der Ereignisse in den 12 Anordnungsvarianten

Mehrere Operatoren im Kreis

Nur aus Gründen der Darstellung und der Ausrichtung auf das Ziel, die Grundverknüpfungen zu vermitteln, kommt es oben nicht vor, dass in beiden Hälften des Operatorkreises je ein Operator vorkommt. Dies ist aber natürlich möglich.

Zwei Operatoren im Kreis

106

4 Ereignisgesteuerte Prozessketten - Grundlagen

Im folgenden abstrakten Beispiel sind „oben“ zwei auslösende Ereignisse (stellvertretend für mehrere) mit UND sowie „unten“ zwei Funktionen (wiederum stellvertretend für mehrere) ebenfalls mit UND verknüpft.

Abbildung 4.5-1:

Ereignis- und Funktionsverknüpfung mit UND

Entsprechend den Ausführungen im vorigen Abschnitt bedeutet dies, dass beide Ereignisse eintreten müssen damit die folgenden zwei Funktionen angestoßen werden können.

4.6 Definition

Aufspaltung des Kontrollflusses Syntaxregel

Zusammenführen des Kontrollflusses

Der Begriff des Kontrollflusses beruht darauf, dass ein Geschäftsprozess sozusagen eine Richtung hat, die durch die Abfolge der Tätigkeiten gegeben ist. Entsprechend hat dies auch eine Ereignisgesteuerte Prozesskette. Dabei kommt es, wie auch die Beispiele in Abschnitt 4.4 zeigten, durch die Operatoren immer zu einer Aufspaltung in mehrere Zweige, die u.U. gleich oder später wieder aufgehoben werden muss. Die Syntaxregel ist nun, dass dafür derselbe Operator wie bei der Aufspaltung verwendet wird. Die folgende Abbildung zeigt dies für ein EPKFragment aus Abschnitt 4.4. Die drei Ereignisse nach der Funktion signalisieren unterschiedliche Erledigungsvarianten. Danach geht es aber „einheitlich“ weiter (d.h. die Varianten führen nicht zu unterschiedlichen Kontrollflusszweigen, was auch möglich wäre), sodass der Kontrollfluss mit einem exklusiven ODER wieder zusammengeführt und dann die nachfolgende Funktion eingefügt wird.

4.6 Zusammenführen des Kontrollflusses

Abbildung 4.6-1:

107

Aufteilen und Zusammenführen des Kontrollflusses

Eine etwas schwierigere Situation ergibt sich oftmals bei einem ODEROperator, wenn mitmodelliert werden soll, dass u.U. auch keine der Aktionen nötig ist. Die folgende Abbildung zeigt ein Beispiel und im unteren Teil auch, wie man sich die Fortsetzung vorstellen kann. Das Ereignis Keine Aktion notwendig muss hinter das Schlussereignis der übrigen Ereignisse weitergeführt werden, da sonst gegen die Regel „Ereignisse und Funktionen lösen sich immer ab“ verstoßen würde.

108

4 Ereignisgesteuerte Prozessketten - Grundlagen

Abbildung 4.6-2:

Ereignisverknüpfung / erzeugte Ereignisse / ODER

Eine elegantere Lösung besteht hier darin auf dieses Ereignis der Nichtaktion zu verzichten und trotzdem aber einen Kontrollflusszweig (sozusagen einen Leerzweig) nach unten zu dem ODER-Operator zu führen, der den

4.6 Zusammenführen des Kontrollflusses

109

Kontrollfluss wieder zusammenführt. Die folgende Abbildung zeigt diese Lösung

Abbildung 4.6-3:

Ereignisverknüpfung / erzeugte Ereignisse / ODER

Allerdings erfüllt diese Lösung nicht in vollem Umfang den ODEROperator (vgl. dazu Abschnitt 5.6).

110

4.7

4 Ereignisgesteuerte Prozessketten - Grundlagen

Aufteilung großer Geschäftsprozesse

Drei Gründe sind es, die dazu führen, dass Ereignisgesteuerte Prozessketten (d.h. Geschäftsprozesse) miteinander verknüpft werden müssen: x x x Prozesswegweiser

Aufrufende und aufgerufene EPK

Die Unübersichtlichkeit großer Ereignisgesteuerter Prozessketten, die aus rein darstellungstechnischen Gründen eine Aufteilung in verschiedene Teilprozesse erfordert. Gewisse (kleine) Ereignisgesteuerte Prozessketten werden in vielen anderen als Teilprozesse benötigt. Werden sie separat modelliert und kann auf sie verwiesen werden, wird die Modellierung vereinfacht. Die Geschäftsprozesse eines Unternehmens hängen in der Regel zusammen und dieser Zusammenhang soll auch erfasst werden soll.

Diese Verknüpfung von Geschäftsprozessen erfolgt mithilfe sog. Prozesswegweiser, die wie folgt grafisch dargestellt werden:

Das Grafiksymbol setzt sich somit aus dem Ereignis- und dem Funktionssymbol zusammen. Prozesswegweiser setzen immer zwei Ereignisgesteuerte Prozessketten in Beziehung. Eine (die aufrufende EPK), in der ein Prozesswegweiser den Aufruf eines anderen Geschäftsprozesses signalisiert und eine andere (die aufgerufene EPK), wo ein Prozesswegweiser anzeigt, dass die jeweilige Ereignisgesteuerte Prozesskette (bzw. ein bestimmter Teil von ihr) aufgerufen wird. Die Regeln für diese Verweistechnik sind wie folgt (vgl. auch die folgende Abbildung): x

x

x

x

Der Prozesswegweiser in der aufrufenden Ereignisgesteuerten Prozesskette gibt a) die Verknüpfungsstelle an und b), durch seine Bezeichnung, welche Ereignisgesteuerte Prozesskette aufgerufen wird. Er steht anstelle einer Funktion. In der aufgerufenen Ereignisgesteuerten Prozesskette gibt ein Prozesswegweiser ebenfalls die Verknüpfungsstelle an und durch seine Bezeichnung, von welcher der Aufruf erfolgt. Auch hier steht der Prozesswegweiser anstelle einer Funktion. In der aufrufenden Ereignisgesteuerten Prozesskette steht vor dem Prozesswegweiser ein Ereignis (oder mehrere). Dieses Ereignis wird im aufgerufenen Prozess nach dem dortigen Prozesswegweiser wiederholt. Im folgenden Beispiel ist dies das Ereignis Kalkulation ist durchzuführen. Waren es mehrere Ereignisse, werden entsprechend alle wiederholt. Mithilfe dieses Ereignisses (dieser Ereignisse), es soll Verknüpfungsereignis genannt werden, kann man sich das Zusammenführen zweier

4.7 Aufteilung großer Geschäftsprozesse

111

Ereignisgesteuerter Prozessketten vorstellen. Man müsste sie nur überlappen. Hier im Beispiel50 geht es um einen Geschäftsprozess Kundenanfragebearbeitung. Irgendwo in diesem Prozess ergibt sich nach dem Ereignis Kalkulation ist durchzuführen die Notwendigkeit, den Geschäftsprozess Kalkulationsdurchführung anzustoßen. Durch den Prozesswegweiser wird auf diesen verwiesen. Im Geschäftsprozess Kalkulationsdurchführung wird das Ereignis Kalkulation ist durchzuführen wiederholt und der Prozess fortgesetzt. Davor wird noch der aufrufende Geschäftsprozess angegeben.

Abbildung 4.7-1:

Aufrufende und aufgerufene EPK mit Verknüpfungsereignis

Prozesswegweiser stehen somit typischerweise am Anfang und am Ende eines Prozesses und ersetzen dann die Start- und Endereignisse. Ein Subprozess51 wie der obige, dessen Prozesswegweiser am Ende eines Kontrollflusszweiges steht, soll angehängter Subprozess genannt werden. Von ihm aus erfolgt also kein „Rücksprung“ in den aufrufenden Geschäftsprozess. Oftmals trifft man in Ereignisgesteuerten Prozessketten allerdings auch die Situation an, dass der aufrufende Prozesswegweiser mitten im Kontrollfluss steht (vgl. die folgende Abbildung). Solche Subprozesse sollen eingefügte Subprozesse genannt werden. Diese an Unterprogrammtechniken erinnernde Struktur muss dann entsprechend dem obigen gelöst werden. Der Aufruf erfolgt genauso, aber 50 51

Die Punkte sollen andeuten, dass der Prozess weitergeht bzw. dass es vorgelagerte Prozessabschnitte gibt. Der Begriff Subprozess soll keine Unterordnung andeuten, sondern nur die Art der Verknüpfung im konkreten Fall klarstellen: der aufgerufene ist der Subprozess.

Angehängter Subprozess

Eingefügter Subprozess

112

Eingefügter Subprozess: Beispiel

Falle

Keine Schleifen oder rekursive Beziehungen

4 Ereignisgesteuerte Prozessketten - Grundlagen

am Ende des aufgerufenen Prozesszweiges muß sozusagen zurückgesprungen werden in die aufrufende Ereignisgesteuerte Prozesskette, was durch ein weiteres Einfügen eines Prozesswegweiser angedeutet wird. In der folgenden Abbildung steht in der aufrufenden Ereignisgesteuerten Prozesskette der Prozesswegweiser zum Prozess B zwischen den beiden Ereignissen X und Y. Nachdem X eingetreten ist, wird Prozess B aufgerufen. Am Ende dieses Prozesses B findet sich nach einem Ereignis, das die Beendigung des eigentlichen Geschäftsprozesses signalisiert (hier Y) – sozusagen für den Rücksprung – ein weiterer Prozesswegweiser, durch den der Rücksprung erfolgt. Das Durchlaufen des Geschäftsprozesses B wird in der Ereignisgesteuerten Prozesskette A durch Wiederholung des Ereignisses Y manifestiert. Auch wenn jetzt hier die Terminologie der Programmiersprachen verwendet wurde, darf nicht angenommen werden, dass diese semi-formale Sprache den Formalisierungsgrad von Programmiersprachen erreicht. Dies ist nicht so und dies wäre auch nicht sinnvoll. So einfach dieses Konzept erscheint, so viele Probleme kann es in der Praxis machen. Meist in Zusammenhang mit dem Versuch, die Darstellung der Ereignisgesteuerten Prozessketten grafisch zu optimieren. Dabei wird versucht, gleichartige Abschnitte in Subprozesse zu tun, damit sie nur einmal eingefügt werden müssen und von beliebig anderen aufgerufen werden können. Dies ist auch richtig, sollte aber nicht übertrieben und vor allem nicht in mehreren Ebenen gemacht werden. Dabei geht die Übersichtlichkeit schnell verloren, die Reduktion der Komplexität an der einen Stelle wird durch eine Erhöhung an anderer Stelle bezahlt. Selbstverständlich dürfen auch nicht Schleifen (Geschäftsprozess A ruft B auf, B ruft C auf und C wiederum A) bzw. rekursive Aufrufe (Geschäftsprozess A ruft A auf) auf diese Weise modelliert werden. Beides ergibt hier keinen Sinn, da Geschäftsprozesse menschliches Handeln widerspiegeln.

4.8 Erste Beispiele

Abbildung 4.7-2:

4.8

113

Prozesswegweiser im Kontrollfluss – Eingefügter Subprozess

Erste Beispiele

Das erste Beispiel in der folgenden Abbildung ist eine Ereignisgesteuerte Prozesskette aus SAP R/3. Es handelt sich um den Geschäftsprozess Grunddatenbearbeitung für Personalplanung und Management. Unter Grunddatenverwaltung wird die Datendefinition, die Datenpflege und die Auswertung von Stammdaten verstanden (vgl. für die Definition und für vertiefte Erläuterungen [Lexikon WI, S. 179ff]). Hier geht es um den Bereich der Personalplanung. Wie bei allen Ereignisgesteuerten Prozessketten von SAP R/3 werden bei der Grafik Informationsobjekte und Organisationseinheiten nicht angegeben, können allerdings mithilfe der Software (Business Navigator, Komponente des R/3) leicht aufgerufen werden. Da es in diesem Buch nur um die „Methode EPK“ geht und nicht um Inhalte wurden nur Ereignisgesteuerte Prozessketten aus thematischen Randgebieten gewählt. Außerdem wurden aus Platzgründen bis auf eine Ausnahme sehr kurze gewählt. Daraus sollte nicht auf die Gesamtheit der SAP-EPKs geschlossen werden. Diese sind inhaltlich umfassend und – den wirklichen Geschäftsprozessen entsprechend – meist sehr lang.

Grunddatenbearbeitung für Personalplanung und Management

Spezifika von SAP-EPKs

114

4 Ereignisgesteuerte Prozessketten - Grundlagen

SAP-EPKs: Grafische Bearbeitung Alle SAP-EPKs mussten grafisch bearbeitet werden, um sie in einem solchen Buch darstellen zu können. Zum einen wurden die im Original vorhandenen Farben beseitigt, zum anderen wurden sie durch Verkürzung der Linien grafisch verdichtet. Als Letztes wurden noch die im Original dünnen gestrichelten Kanten (Linien) verdickt und die Strichelung entfernt. Textliche Beschreibung der EPK

Lieferantenstammbearbeitung

Gestartet wird der Geschäftsprozess durch das Ereignis Mitarbeiterdaten sind zu bearbeiten. Als Erstes wird die Person bestimmt, dann der Bearbeitungsgrund. Dieser kann entweder eine Veränderung der persönlichen Mitarbeiterdaten, der Ausbildungsdaten, der Qualifikation eines Mitarbeiters oder von betriebsinternen Daten sein. Haben sich persönliche Mitarbeiterdaten geändert, wird anschließend die Funktion Grunddaten Person bearbeiten gestartet. Haben sich entweder die Ausbildungsdaten oder die Qualifikation des Mitarbeiters geändert, werden anschließend die Planungsdaten bearbeitet, bei einer Änderung der betriebsinternen Daten startet die entsprechende Funktion. In allen Fällen endet der Geschäftsprozess mit dem Schlussereignis Mitarbeiterdaten sind bearbeitet. Aufteilung und Zusammenführung des Kontrollflusses erfolgt durch XODER, da es sich ja um echte Alternativen handelt. Das nächste Beispiel (Abbildung 4.8-2) zeigt eine Ereignisgesteuerte Prozesskette aus SAP R/3 zum Geschäftsprozess Lieferantenstammbearbeitung. Es geht um die Bearbeitung der Stammdaten zu Lieferanten. Dieser Geschäftsprozess kann auf zweierlei Art gestartet werden. Entweder durch das Ereignis Lieferant soll angelegt werden oder durch einen anderen Geschäftsprozess Mängelrüge. Dort ist gegebenenfalls das Ereignis Q-Meldung erfordert eine Änderung im Lieferantenstammsatz eingetreten. Der aufrufende Geschäftsprozess entstammt dem Modul QM (Qualitätsmanagement). Als Erstes wird dann dem Kreditor eine Kontengruppe zugeordnet. Danach werden zwei Funktionen angestoßen: Erstens wird eine Lieferantennummer festgelegt, zweitens die Einkaufsorganisation. Bei der Festlegung der Lieferantennummer gibt es zwei durch Ereignisse angedeutete Möglichkeiten (interne oder externe Vergabe). Danach wird der Kontrollfluss wieder zusammengeführt (mithilfe eines UND, weil mit einem UND aufgespaltet wurde) und die Funktion Kreditorendaten erfassen angestoßen. Diese Funktion und der gesamte Geschäftsprozess endet mit dem Schlussereignis Lieferant ist angelegt.

4.8 Erste Beispiele

Abbildung 4.8-1:

115

Grunddatenbearbeitung für Personalplanung und –management Quelle für alle SAP-EPKs dieses Kapitels: SAP R/3, installiert an der Berufsakademie Ravensburg (bis 2001), Fachrichtung Wirtschaftsinformatik. Vom Verfasser grafisch bearbeitet.

116

4 Ereignisgesteuerte Prozessketten - Grundlagen

Abbildung 4.8-2: Konkretes Beispiel für Verknüpfung durch Prozesswegweiser

Lieferantenstammbearbeitung

4.8 Erste Beispiele

117

Das folgende Beispiel ist etwas umfangreicher. Mit ihm soll die Rolle der Prozesswegweiser deutlicher gemacht werden. Es beschreibt den Geschäftsprozess Kontaktbearbeitung. Im Geschäftsprozess Mailing-AktionBearbeitung wird nach dem Ereignis Kontakt ist zu vereinbaren dieser Prozess Kontaktbearbeitung angestoßen. Weil der Geschäftsprozess so umfangreich ist, hier zuerst eine Gesamtübersicht, die den Aufbau angeben soll. In den nachfolgenden Abbildungen wird dieser Geschäftsprozess dann Stück für Stück (von oben nach unten, von links nach rechts) detailliert vorgestellt. Übersicht gewinnen

Abbildung 4.8-3:

Kontaktbearbeitung – Strukturübersicht (für eine detaillierte Darstellung vgl. die folgenden Abbildungen)

Wie zu sehen ist hat der Geschäftsprozess zu Beginn einen Prozesswegweiser, durch den er u.U. gestartet wird. Alternativ kann er auch durch ein Ereignis gestartet werden. Am Ende finden sich dann acht Prozesswegweiser, die den jeweiligen Kontrollfluss in andere Ereignisgesteuerte Prozessketten weiterführen. Doch nun zur Detailsicht. Sie ist in den nächsten 5 Abbildungen angegeben. Wie Teil 1 zeigt, wird der Geschäftsprozess tatsächlich entweder durch einen anderen gestartet oder durch ein Ereignis.

Start durch Prozesswegweiser

118

4 Ereignisgesteuerte Prozessketten - Grundlagen

Abbildung 4.8-4:

Kontaktbearbeitung – Teil 1 (Fortsetzung in der nächsten Abbildung)

Auf eine solche Weise können verschiedene Startmöglichkeiten eines Geschäftsprozesses modelliert werden. Oftmals sieht man Ereignisgesteuerte Prozessketten, bei denen zahlreiche solche Startalternativen vorhanden sind, ähnlich wie in dieser Ereignisgesteuerten Prozesskette am Ende. Der Start durch den Prozesswegweiser entspricht dem Standardaufbau von Ereignisgesteuerten Prozessketten: Der Prozesswegweiser zeigt, wo-

4.8 Erste Beispiele

119

her der Aufruf kommt, das auf den Prozesswegweiser folgende Ereignis entspricht dem Ereignis, nach dem im aufrufenden Geschäftsprozess der Prozesswegweiser steht (vgl. Abschnitt 4.7). Etwas unübersichtlicher erscheint auf den ersten Blick der Start durch die Ereignisse. Hier kann die folgende Abbildung helfen, die dasselbe Fragment in der klassischen Notation52 darstellt. Reisebedarf?

Abbildung 4.8-5:

Start der Kontaktbearbeitung in klassischer Notation

Hier wird deutlich, dass das Startereignis Kontakt ist vorzubereiten ist. Von diesem geht der Kontrollfluss weiter zum linken XODER-Operator und zum rechten UND-Operator. Der linke Zweig führt dann auf jeden Fall zum Start der Funktion Kontaktart bestimmen. Dagegen wird der Prozess Erfassung der geplanten Reise nur gestartet, wenn zusätzlich Reisebedarf aufgetreten ist. Diese Stelle kann nur verstanden werden, wenn man von einer durch die Anordnung der Operatoren gegebenen Reihen- und Rangfolge der Ereignisse ausgeht. Dieselbe Stelle hätte auch durch eine Funktion Prüfen ob Reisebedarf mit entsprechenden Ergebnisereignissen modelliert werden können. Hier kann die Kenntnis des UND-Operators etwas vertieft werden. Ein UND-Operator (wie hier nach dem Ereignis Kontakt ist vorzubereiten ist bereits erfüllt, wenn der Kontrollfluss weitergeführt ist (hier zu den zwei Operatoren). Es müssen nicht die nachfolgenden Funktionen angestoßen werden (was ja hier zumindest auf einer Seite auch nicht sein muss). Auf diese Weise kann ein unterschiedlicher Ablauf modelliert werden, je 52

So soll die auf Scheer zurückgehende ursprüngliche Notation bezeichnet werden.

Steuerung mit UND

UND vertieft

120

4 Ereignisgesteuerte Prozessketten - Grundlagen

nachdem, ob ein weiteres Ereignis eintritt oder nicht. Tritt hier das Ereignis Kontakt ist vorzubereiten nicht ein, bleibt – sozusagen – der vom UND-Operator kommende Zweig des Kontrollflusses vor dem weiteren UND-Operator stehen. Unabhängig vom konkreten Beginn des Geschäftsprozesses wird im Anschluss die Funktion Kontaktart bestimmen angestoßen. Diese hat drei mögliche Ergebnisereignisse. Nur eines kann eintreten, der Kontakt ist also entweder persönlich, telefonisch oder schriftlich herzustellen. Nach diesen drei Ereignissen wird der Kontrollfluss wieder zusammengeführt, da es einheitlich weitergeht: Es werden gleichzeitig zwei Funktionen angestoßen, Geschäftspartner bestimmen und Ansprechpartner bestimmen.

Abbildung 4.8-6:

Kontaktbearbeitung – Teil 2 (Fortsetzung in der nächsten Abbildung)

Bevor es mit dem nächsten Teil weitergeht, hier noch ein Hinweis auf die grafische Gestaltung. Im unteren Drittel der Ereignisgesteuerten Prozesskette folgen zwei Operatoren aufeinander, XODER sowie UND. Dies ist genau die Konstellation, die in der Basisnotation durch einen Kreis mit zwei Operatoren erfasst würde, der eine oben, der andere unten.

4.8 Erste Beispiele

121

Abbildung 4.8-6 (Teil 2) oben zeigt die Fortsetzung. Nachdem die Geschäfts- und Ansprechpartner bestimmt sind, werden eine Kontaktbeschreibung und ein Kontakttext erfasst. Nachdem dies geschehen ist, steht der Geschäftsprozess, verursacht durch das UND, bis das Ereignis Kontakt ist nachzubereiten eintritt. Zwischen diesen beiden Ereignissen liegt die Durchführung des eigentlichen Kontakts. Diese etwas unglückliche Konstruktion ist durchaus üblich und zeigt die vielen Möglichkeiten, die bei der Beschreibung von Geschäftsprozessen mit Ereignisgesteuerten Prozessketten zur Verfügung stehen. Auch hier hätte – wie oben – eine entsprechende Funktion eingefügt werden können. Hier geht es jedenfalls erst dann weiter, wenn beide Ereignisse eingetreten sind. Dann wird die Funktion Kontaktergebnis erfassen angestoßen. Der nachfolgende ODER-Operator signalisiert, dass es entweder einige durch entsprechende Ereignisse feststellbare Ergebnisse gibt oder dass Spesen angefallen sind oder dass beides eintritt.

Tätigkeit zwischen zwei Ereignissen

Vgl. Abbildung 4.8-3 für eine strukturelle Gesamtübersicht

Abbildung 4.8-7:

Kontaktbearbeitung – Teil 3 (Fortsetzung in der nächsten Abbildung)

Betrachten wir zuerst die durch ein XODER als alternativ gekennzeichneten Ergebnisse: x x x x

Kontakt ist erfolglos Folgekontakt ist vereinbart Anfrage ist aus Kontakt anzulegen Angebot ist aus Kontakt anzulegen

122

x x x x

4 Ereignisgesteuerte Prozessketten - Grundlagen

Auftrag ist aus Kontakt anzulegen Servicevertrag ist aus Kontakt anzulegen Gut-/Lastschrift ist aus Kontakt anzulegen Retourenauftrag ist aus Kontakt anzulegen

Man sieht, hier ist an vieles gedacht worden. Teil 3 in Abbildung 4.8-7 zeigt die beiden Fälle Angebot ist aus Kontakt anzulegen und Auftrag ist aus Kontakt anzulegen. Hier wird dann jeweils ein entsprechender Prozess angestoßen.

Abbildung 4.8-8:

Kontaktbearbeitung – Teil 4 (Fortsetzung in der nächsten Abbildung)

Obige Abbildung 4.8-8 mit Teil 4 zeigt den linken Teil des unteren Abschlussbalkens. Die ersten beiden Ereignisse (Scheitern bzw. Folgekontakt) stoßen keine anderen Geschäftsprozesse an. Die dritte Möglichkeit (Anfrage ist aus Kontakt anzulegen) stößt den Geschäftsprozess Kundenanfragebearbeitung an. Abbildung 4.8-9 mit Teil 5 zeigt, dass im Falle der letzten drei Ereignisse aus obiger Liste jeweils ein Prozess angestoßen wird. Geht es um einen Servicevertrag, wird der Geschäftsprozess Servicevertragsabschluß u. -bearbeitung gestartet geht es um eine Gut-/Lastschrift, die Gut-/Lastschriftanforderungsbearbeitung und, falls es sich um einen Retourenauftrag handelte, die Retourenbearbeitung.

4.8 Erste Beispiele

Abbildung 4.8-9:

123

Kontaktbearbeitung – Teil 5 (Fortsetzung in der nächsten Abbildung)

Das letzte Fragment in Abbildung 4.8-10 (Teil 6) zeigt den Ablauf für den Fall, dass Spesen angefallen sind. Dieser Zweig rührt von dem ODEROperator nach der Funktion Kontaktergebnis erfassen her. Das entsprechende Ereignis stößt dann die beiden Geschäftsprozesse Erfassung der Reisekosten und Ergänzung der Reisefakten an. Dieser ODER-Operator erscheint hier nicht ganz schlüssig, denn so, wie die Ereignisgesteuerte Prozesskette jetzt verfasst ist, wäre es auch möglich, dass nur Spesen anfallen und kein Ergebnis festgehalten wird, nicht mal das Ergebnis Kontakt ist erfolglos.

Abbildung 4.8-10:

Kontaktbearbeitung – Teil 6

5 Ereignisgesteuerte Prozessketten Vertiefung

Es ist wahrscheinlich immer so, dass eine semi-formale Sprache quasi empirisch ergründet werden muss. Denn der nicht formale Charakter schafft Spielraum, der genutzt wird und werden muss, um das Instrument (die Modellierungssprache) möglichst effizient zu gestalten. Bei den Ereignisgesteuerten Prozessketten muss also auch die genaue Festlegung der Erstellungsregeln (hier der Einfachheit halber Syntax genannt) durch Analyse vorhandener Geschäftsprozesse aus den verschiedenen Quellen festgestellt werden. Dabei fällt oft die Unterscheidung zwischen Fehlern und „Dialekten“ schwer. Im Folgenden nun die Klärung anhand von Ereignisgesteuerten Prozessketten, die bei Ist-Analysen realer Geschäftsprozesse – sozusagen in empirischer Arbeit - entstanden sind, mithilfe der im R/3 hinterlegten Geschäftsprozesse, der Scheerschen Notation und anderer Veröffentlichungen.

5.1

„Sprachgebrauch“

Rückschleifen

Wie im „wirklichen Leben“ spielen Rückschleifen in formalen Beschreibungen von Geschäftsprozessen eine wichtige Rolle. Konkret bedeutet dies, dass - abhängig von einem bestimmten Ereignis - ein bestimmter Abschnitt eines Geschäftsprozesses wiederholt wird. Die folgende erweiterte Ereignisgesteuerte Prozesskette zeigt, wie dieser Vorgang modelliert wird. Die Rückschleife beginnt immer aus einem Ereignis heraus, dem Ereignis, das den Bedarf an der Wiederholung eines Abschnittes aufzeigt. Im Beispiel der folgenden Abbildung ist dies die Tatsache, dass Unterlagen nicht vollständig sind. Die Rückschleife wird dann grafisch durch eine Pfeillinie dargestellt, die mithilfe eines XODER-Operators vor einer Funktion wieder in den Kontrollfluss zurückgeführt wird. Diese Funktion muss natürlich die sein, ab der die Wiederholung des Geschäftsprozesses beginnt. Es ist wichtig, dass dieser Wiedereinstieg vor einer Funktion erfolgt, da nur damit die syntaktische Grundregel Ereignis und Funktion lösen sich ab eingehalten wird. Der XODER-Operator hat in einer solchen Konstellation eine etwas andere Bedeutung als sonst, wo er zwei sich ausschließende Alternativen beschreibt. Hier wird im ersten Durchgang auf jeden Fall der Kontroll-

Wiederholung von Geschäftsprozessabschnitten

Beginn der Rückschleife

126

5 Ereignisgesteuerte Prozessketten - Vertiefung

fluss „von oben her“ durchlaufen. Der „seitliche Einstieg“ kommt nur im Falle des Rücksprungs zum Tragen. Rücksprung 1 ohne Kontrolle

Abbildung 5.1-1: Endlos?

Pragmatische Aspekte von EPKs

Wiederholung eines Geschäftsprozessabschnitts

In diesem Beispiel, wie auch bei allen einschlägigen Beispielen wird darauf verzichtet, die Zahl der Rücksprünge zu kontrollieren. Implizit wird davon ausgegangen, dass sich die am Geschäftsprozess Beteiligten so verhalten, dass der Abschnitt nicht zu oft wiederholt wird. Rein formal könnte man sich hier auch eine Endlosschleife vorstellen. Allerdings ist ein Geschäftsprozess kein Programm, sondern eine von Menschen getragene Abfolge von Tätigkeiten.

Pragmatik Auf diesen Punkt musste schon öfters verwiesen werden, z.B. bei rekursiven Aufrufen und bei Schleifen (vgl. Abschnitt 4.7). Die Erstellungsregeln für Ereignisgesteuerte Prozessketten werden durch das Handeln der Menschen in den Geschäftsprozessen geprägt. Es ist nun mal so, dass Menschen (zumindest im Rahmen von Geschäftsprozessen) nicht in Endlosschleifen, in rekursive Strukturen und Ähnliches verfallen (wie z.B. ein Programm, im Falle rekursiver

5.1 Rückschleifen

127

Aufrufe sogar korrekterweise), weshalb solche Strukturmerkmale hier nicht per Syntax abgesichert werden müssen. Natürlich ist es aber auch möglich anzugeben, wie oft maximal die Wiederholung akzeptiert wird. Denkbar wäre z.B. die in der nächsten Abbildung gezeigte Lösung. Hier wird nach dem Ereignis Unterlagen sind nicht vollständig eine Funktion eingebaut, mit der geprüft wird, wie oft die Unterlagen schon zurückgegeben wurden. Geschah dies erst einmal, wird nochmals zurückgegeben. Erfolgte dies bereits zweimal, werden die Unterlagen (z.B. Planungsunterlagen) von der Abteilungsleitung selbst fertig gestellt. Werden die Unterlagen insgesamt höchstens einmal zurückgegeben, findet man oftmals auch die Lösung der folgenden Abbildung 5.1-3. Hier wird der Fachabteilung einmal die Gelegenheit der Überarbeitung gegeben. Klappt es dann immer noch nicht, führt die Abteilungsleitung selbst die notwendigen Korrekturen durch. In diesem Fall kann auf die Rückschleife verzichtet werden. Dieses Beispiel verdeutlicht auch nochmals das Zusammenführen eines getrennten Kontrollflusses mithilfe eines XODER-Operators (vor dem Schlussereignis). Voraussetzung dafür ist natürlich, dass es sich wirklich um Alternativen handelt, dass also bei einem Durchgang wirklich nur eine der Alternativen eintreten kann.

Schleifengrenze

Zusammenführen mit XODER

128

5 Ereignisgesteuerte Prozessketten - Vertiefung

Rücksprung 2 mit Kontrolle

Abbildung 5.1-2:

Mehrmalige Wiederholung eines Geschäftsprozessabschnitts mit Kontrolle

5.1 Rückschleifen

129

Rücksprung 3: Wiederholung ohne Rückschleife

Abbildung 5.1-3:

Einmalige Wiederholung eines Geschäftsprozessabschnitts

130

5.2

5 Ereignisgesteuerte Prozessketten - Vertiefung

Repetitive Handlungen

In realen Geschäftsprozessen müssen oft repetitive (sich wiederholende) Handlungen erledigt werden, wie in der nachfolgenden Ereignisgesteuerten Prozesskette angedeutet.

Abbildung 5.2-1:

Wiederholung wegen „Abarbeitung“

Diese weisen eine ähnliche Struktur wie Wiederholungsschleifen auf, wenn Sie mithilfe von Ereignisgesteuerten Prozessketten modelliert werden. Im Beispiel oben geht es um die Durchführung einer Erhebung bei Kunden mit Fragebogen, Interviews oder wie auch immer. Die Ereignisgesteuerte Prozesskette setzt ab der Stelle des Geschäftsprozesses ein, wo die Gesamtbefragung vorbereitet ist. Dies stößt die Funktion an, innerhalb der die einzelne Befragung, z.B. des Kunden, durchgeführt wird. Nach jeder Befragung wird geprüft, ob noch weitere Kunden zu befragen sind oder nicht. Sind noch welche zu befragen, erfolgt ein Rücksprung vor die

5.3 Warten

131

entsprechende Funktion, sodass wieder die Einzelbefragung angestoßen wird. Dies geschieht solange, bis alle Befragungen durchgeführt sind. Diese Tätigkeiten sind bewusst „detailliert“ angelegt, um das Beispiel einfach zu halten. Die Zahl der Wiederholungen wird durch die Anzahl der Teilaufgaben bestimmt, die Schleife wird abgebrochen, wenn alle erledigt sind. Es soll nicht verschwiegen werden, dass ein solcher Geschäftsprozessabschnitt oft so modelliert wird, dass die sich wiederholende Tätigkeit in eine Funktion genommen wird, wie es die folgende Abbildung zeigt. Damit werden Ereignisgesteuerte Prozessketten natürlich wesentlich einfacher. Die beiden Beispiele veranschaulichen die Problematik der Festlegung der Tätigkeitsebene, des Detaillierungsgrades. Je höher man ansetzt, desto einfacher aber auch weniger aussagekräftig werden Ereignisgesteuerte Prozessketten. Setzt man sie allerdings zu tief an, der Verfasser sah schon Ereignisgesteuerte Prozessketten auf tayloristischer Ebene, werden sie sehr komplex und am Ende undurchschaubar.

Abbildung 5.2-2:

Verzicht auf Wiederholung durch Wahl einer höheren Ebene

Letztendlich muss jeder selbst entscheiden, wie viele Tätigkeiten in einer Funktion zusammengefasst werden sollen. Diese Kapselung führt zu einfacheren Strukturen, verdeckt aber auch Abläufe (dazu mehr unten).

5.3

Warten

Ein wesentliches Element von Geschäftsprozessen ist Warten. Warten auf eine Entscheidung anderer, Warten auf Produkte, Zahlungseingang, usw. Für die korrekte Modellierung solcher Wartesituationen in Ereignisge-

Kapseln in eine Funktion

132

5 Ereignisgesteuerte Prozessketten - Vertiefung

steuerten Prozessketten gibt es grundsätzlich zwei Lösungen, die mit der folgenden Beispielsituation erläutert werden sollen: Warten auf Zuoder Absage

x x x

Eine Entscheidung ist gefallen, hier die für eine/n bestimmte Bewerber/in auf eine Stelle. Der weitere Verlauf hängt nun von der Entscheidung eines Externen ab (ob sie/er die Stelle annimmt oder nicht). Es muss also gewartet werden.

Abbildung 5.3-1:

Warten auf (externe) Entscheidungen

Eine solche Situation kann so modelliert werden, wie in der obigen Abbildung gezeigt. Nach dem Ereignis Bewerber/in ist benachrichtigt, das den Abschluss der eigentlichen Bewerberauswahl signalisiert, wird eine Wartefunktion eingefügt. Dies trägt auch der Tatsache Rechnung, dass Warten durchaus eine Tätigkeit ist. Die auf diese Funktion folgenden Ereignisse deuten die möglichen Beendigungen des Wartens an. Entweder durch eine Zu- oder eine Absage. Je nachdem werden dann die entsprechenden Funktionen angestoßen. Die Funktion Warten auf Entscheidung ist dabei unabdingbar. Ohne sie entstünde eine nicht zulässige Struktur, bei der auf ein Ereignis zwei Funktionen folgen, die durch ein exklusives ODER verknüpft sind. Falls gewünscht, könnte hier durch ein weiteres paralleles Ereignis (Zwei Wochen sind seit der Benachrichtigung vergangen) auch die Situation modelliert werden, dass das externe Ereignis nicht eintritt (dass sich

5.3 Warten

133

die Bewerberin nicht meldet), damit auch dieser Fall durch die Ereignisgesteuerte Prozesskette festgehalten ist. Auf jeden Fall aber wird hier auf ein externes Ereignis gewartet. Dies kommt durchaus vor, da Geschäftsprozesse natürlicherweise auch auf diese Weise mit der Umwelt in Kontakt treten. Dabei wird also der weitere Verlauf des Geschäftsprozesses durch das Handeln Externer bestimmt. Neben dieser sozusagen konventionellen Lösung findet man auch die in der nächsten Abbildung angegebene. Bei ihr wird auf die Wartefunktion verzichtet.

Warten auf externes Ereignis

Das logische UND als Schalter

Abbildung 5.3-2:

Warten mit dem logischen UND

Unmittelbar nach dem Benachrichtigungsereignis folgt ein logischer Operator UND. Er soll signalisieren, dass der Kontrollfluss in beide Richtungen weitergeht, obwohl semantisch nur eine der beiden Alternativen eintreten kann. Vor den beiden weiteren UND-Operatoren bleibt der Kontrollfluss dann - sozusagen – stehen (wie oben, zu Beginn der Ereignisgesteuerten Prozesskette Kontaktbearbeitung in Abschnitt 4.8). Die möglichen externen Entscheidungen sind als Ereignisse modelliert, die sich gegenseitig ausschließen. Tritt nun eines der beiden Ereignisse ein, ist auf der entsprechenden Seite das UND erfüllt und die nächste Funktion wird angestoßen. Natürlich ist es auch hier möglich, durch ein entsprechendes Ereignis die Situation abzufangen, dass die externe Entscheidung auf sich warten lässt (hier: dass der Bewerber sich nicht meldet). Das logische UND wird in diesem Beispiel auf eine etwas andere Art verwendet als im vorigen Kapitel und wie üblicherweise, wo ja das UND signalisiert, dass alle verknüpften Kontrollflüsse durchlaufen werden müssen. Hier bedeutet es, dass der Kontrollfluss bis zum nächsten Operator fortgesetzt wird.

134

Fehlende Entscheidung

5 Ereignisgesteuerte Prozessketten - Vertiefung

Nicht zulässig wäre die oben schon angesprochene Lösung, bei der auf die Modellierung der (externen) Entscheidung verzichtet wird (vgl. die nächste Abbildung).

Abbildung 5.3-3:

Modellierung parallel zu einer Software

Mehrere Operatoren hintereinander

Nicht zulässige Lösung

Hier fehlt der Entscheidungsprozess, was nicht sinnvoll und nicht zulässig ist (vgl. auch die „verbotenen“ Strukturen in Abschnitt 4.4). Unter anderem deshalb, weil ein interner Entscheidungsprozess53 sich natürlich in der zugehörigen Software als Maske niederschlagen muss (zur Anzeige und Eingabe von Informationen) und eine Parallelität zwischen EPKs und Software immer dann gegeben ist, wenn die Ereignisgesteuerten Prozessketten Geschäftsprozesse beschreiben, die durch Software abgewickelt werden (z.B. bei den SAP-EPKs und R/3). Diese Anordnung gibt aber einen Hinweis auf die Motivation, die zur obigen Lösung Warten mit dem logischen UND geführt haben könnte. Wie ja schon angemerkt, liegt allerdings in obiger Situation (Abbildung 5.3-1) die Entscheidung außerhalb des Unternehmens, bei den Bewerbern, sodass sich diese Entscheidungsfunktion gerade nicht in einer Maske der Betriebswirtschaftlichen Standardsoftware niederschlägt (sondern nur deren Ergebnis). Darin liegt wohl der tiefere Grund für diese Art der Modellierung ohne Entscheidungsfunktion. Da sich dieses Warten nicht in einer Maske des Programms niederschlägt, lässt man es weg, wenn man entlang einer Software Ereignisgesteuerte Prozessketten entwickelt. Es kommt oft vor, dass mehrere Operatoren hintereinander angeordnet sind. So ja auch im obigen Beispiel (5.3-2), wo mehrere UND-Operatoren hintereinander liegen. Ganz grundsätzlich ist dies immer dann notwendig, wenn der Kontrollfluss sich mehrfach verzweigt.

53

Ein externer nicht unbedingt. Bei diesen werden oft nur die Ergebnisse modelliert wie in der vorigen Abbildung.

5.4 Einfügen der zeitlichen Dimension

5.4

135

Einfügen der zeitlichen Dimension

Auch wenn die zeitliche Dimension in Ereignisgesteuerten Prozessketten nicht direkt angegeben wird, ist sie doch implizit immer enthalten, da eine Funktion nur begonnen wird, wenn die vorherige abgeschlossen ist. Zeitfenster

Abbildung 5.4-1:

Zeitfenster für Funktionen

Somit erfolgt eine erste fundamentale zeitliche Festlegung bei jeder Ereignisgesteuerten Prozesskette dadurch, dass die Funktionen - getrennt durch Ereignisse - nacheinander angeordnet sind. Dadurch ist ihre Reihenfolge festgelegt. Diese Festlegung ist allerdings keine absolute (mit Angabe des Zeitverbrauchs), sondern nur eine relative (zu den anderen Funktionen). Ein Sonderfall ergibt sich, wenn Funktionen wie im obigen Beispiel durch ein UND verknüpft sind. Dies bedeutet dann lediglich, dass sie ein gemeinsames Zeitfenster haben, in dem sie erledigt werden müssen. Über ihre Reihenfolge ist nichts ausgesagt, sie ist modelltechnisch belanglos. Umgekehrt gilt: Muss oder soll hier doch implizit eine Reihenfolge beachtet werden, sollte nicht so wie hier modelliert werden. Die zweite Möglichkeit, den Faktor Zeit miteinzubeziehen, besteht in der Definition eines Ereignisses, das einen bestimmten Zeitpunkt angibt

136

5 Ereignisgesteuerte Prozessketten - Vertiefung

und dem Anbinden dieses Ereignisses an den Kontrollfluss mittels eines logischen UND. Die folgende Abbildung zeigt eine solche Struktur. Zeitpunkte

Abbildung 5.4-2:

Zeitpunkte in den Kontrollfluss einbauen

Wieder wird mithilfe des logischen UND dergestalt gesteuert, dass der Kontrollfluss stehen bleibt, bis der entsprechende Zeitpunkt erreicht ist. Beispiele hierfür sind x x x

Zeitverbrauch

Monatsende erreicht Mahntermin erreicht Frist abgelaufen

Grundsätzlich geht es auch hier wieder um das Warten (vgl. oben), diesmal aber nicht auf eine externe Entscheidung, sondern auf einen Zeitpunkt. Das Eintreten eines bestimmten Zeitpunktes wird so zu einem externen Ereignis der Ereignisgesteuerten Prozesskette. In Ereignisgesteuerten Prozessketten wird der Zeitverbrauch, also eine Angabe wie, diese Funktion muss innerhalb eines Tages erledigt sein, im Regelfall nicht erfasst. Eine Ausnahme wurde oben angedeutet. Bei Wartefunktionen ist es durchaus denkbar, ein Ereignis, das die abgelaufene Zeit signalisiert, miteinzubauen. Z.B. so, dass als ein Ergebnis der Wartefunktion das Ereignis Zeit ist abgelaufen integriert wird.

5.5

Keine falschen Schlussereignisse

Ein häufig anzutreffender Fehler bei in der betrieblichen Praxis entstandenen Ereignisgesteuerten Prozessketten ist der, dass bei einer ODERbzw. XODER-Verzweigung vergessen wird, die einzelnen Zweige wieder korrekt zusammenzuführen. Meist wird dann nur mit einem Zweig der Kontrollfluss weitergeführt. Abbildung 5.5-1 zeigt ein solches fehlerhaftes Beispiel.

5.5 Keine falschen Schlussereignisse

Abbildung 5.5-1:

137

Keine falschen Enden

Hier wird, nach der Entscheidung über die Nachfassaktion (im Rahmen der Bemühungen, einen Auftrag zu erhalten) dreifach verzweigt. Danach wird nur ein Zweig weitergeführt, was die beiden anderen automatisch zu Schlussereignissen macht. Dies ist hier aber sicherlich nicht richtig. Deshalb gilt: Geht der Geschäftsprozess in einem Kontrollflusszweig weiter, müssen wirklich alle Zweige zusammengeführt werden. Oft wird an dieser Stelle argumentiert, die Weiterführung ergebe sich aus der Semantik, aus der inhaltlichen Analyse der Ereignisgesteuerten Prozesskette. Ein solches Verlagern der Syntaxfestlegung in die Semantik ist aber bei keiner semi-formalen Sprache zulässig. Die möglichen Kontrollflüsse sollten so weit es geht durch Nutzung der Syntaxregeln festgelegt werden. Welcher der zulässigen Wege dann bei einem Geschäftsprozessdurchgang konkret begangen wird entscheidet die Semantik.

Weiterführung?

Syntaktische Klarheit

138

5 Ereignisgesteuerte Prozessketten - Vertiefung

Eine andere Situation liegt bei einem UND-Operator vor. Hier wird tatsächlich sehr oft der Kontrollfluss nur bei einem Zweig fortgeführt. Dies ist möglich, da der UND-Operator ja sowieso verlangt, dass alle Zweige fortgesetzt werden (vgl. die folgende Abbildung).

Abbildung 5.5-2:

Weiterführung nach UND-Verknüpfung

Im obigen Beispiel sei an die Situation gedacht am Ende der Erstellung eines Buchmanuskripts. Die Abschlusskontrolle wird – vereinfacht – modelliert als ein Vorgang bei dem die Seitenformatierung geprüft, die Kopfzeilen kontrolliert und der Index neu erstellt wird. Der UNDOperator signalisiert, dass alle drei Ereignisse eintreten müssen. Der weitere Verlauf ist dann klar, auch wenn nur ein einziger Kontrollflusszweig weitergeführt wird.

5.6 Verknüpfungssemantik

Genauigkeit erhöhen

In Kapitel 4 wurde mehrfach auf die Situation hingewiesen, dass durch ODER verknüpfte Ereignisse oder Funktionen oftmals nicht gänzlich unabhängig voneinander sind, sondern eine innere Struktur aufweisen. Z.B. so, dass eines der Ereignisse nicht mit den anderen vorkommen kann oder dass einige der Ereignisse nur zusammen auftreten können. Ein Beispiel dafür findet sich in Abbildung 4.4-18. Hier nun ein weiteres Beispiel. Die folgende Abbildung zeigt den Beginn eines größeren Geschäftsprozesses. Es geht um Kundenanfragen nach Produkten, die in Einzelfertigung hergestellt werden. Da die Kalkulation und die Erstellung der CAD-Zeichnungen sehr aufwändig ist, erfolgt zuerst eine Prüfung, ob nicht früher schon mal etwas geliefert wur-

5.6 Genauigkeit erhöhen

139

de, sodass auf die da erstellten Kalkulationsunterlagen und CAD-Zeichnungen zurückgegriffen werden könnte. Diese Prüfung wird in der Ereignisgesteuerten Prozesskette als Funktion modelliert (Klärung, ob ähnliche Anlage schon geliefert), die zu vier Ergebnissen (modelliert als Ereignisse) führen kann: x x x x

Gleiche Anlage schon mal geliefert Ähnliche Anlage schon mal geliefert Komponente schon mal geliefert Nichts Ähnliches wurde geliefert

Dabei können auch mehrere Ereignisse gleichzeitig eintreffen (z.B. die ersten drei), weshalb für die Verknüpfung der ODER-Operator verwendet wurde. Nach den Ereignissen sind dann die entsprechenden Funktionen angeordnet, lediglich dem Ereignis Nichts Ähnliches wurde geliefert folgt keine. Danach werden die verschiedenen Kontrollflusszweige wieder zusammengeführt zu der Funktion Anlage konzipieren, kalkulieren, Skizze erstellen. Diese Modellierung ist in einem Punkt unpräzise. Das Ereignis Nichts Ähnliches wurde geliefert kann nicht zusammen mit den anderen auftreten. Es hat auch andere Wirkungen, da es gleich zur endgültigen Erstellung führt und nicht zu Funktionen, mit deren Hilfe Teilergebnisse gewonnen werden. Die Ereignisse (Ergebnisse) sind also nicht unabhängig voneinander. Trotzdem findet man eine solche Semantik sehr oft mit einem ODER modelliert. Möchte man genauer modellieren geht dies ganz einfach so, dass man zuerst mithilfe eines XODER-Operators die beiden Alternativen Nichts Ähnliches wurde geliefert/etwas Ähnliches wurde geliefert modelliert und dann die restlichen möglichen Ergebnisse mithilfe eines ODEROperators. Die beiden folgenden Abbildungen (5.6-2 und 5.6-3) zeigen die Lösung für den oben angesprochenen Fall. Die Funktion Klärung, ob ähnliche Anlage schon geliefert wird nun dazu benutzt, die Alternative zu modellieren. Damit ist zum einen das mögliche Ergebnis Nichts Ähnliches wurde geliefert aus der nachfolgenden Funktion herausgenommen, zum anderen kann diese dann eindeutig formuliert werden: Klärung, was genau geliefert wurde. Die hier möglichen Ergebnisereignisse sind nun völlig unabhängig voneinander.

Genauigkeit erhöhen

140

5 Ereignisgesteuerte Prozessketten - Vertiefung

Abbildung 5.6-1:

Unscharfe Modellierung mit ODER

5.6 Genauigkeit erhöhen

141

Zuerst die Alternative mit XODER,

dann beliebige Kombinationen mit ODER.

Abbildung 5.6-2:

Genauer modellieren mit XODER - Teil 1

Sie führen zu den im Ausgangsbeispiel schon eingeführten Funktionen: Zuschläge berücksichtigen, Veränderungen berücksichtigen und Unterlagen ergänzen, die auch in beliebiger Kombination gemeinsam auftreten können. Nach dem Zusammenführen der drei Zweige mit einem ODEROperator sind dann die Kalkulationsunterlagen ergänzt. Gegenüber dem Ausgangsbeispiel wurde hier nun die eigentliche Fertigstellung getrennt54. Sie erfolgt entweder auf der Basis von Teilinformationen oder gänzlich neu. Danach wird der Kontrollfluss mit einem XODER wieder zusammengeführt.

54

Um Missverständnisse zu vermeiden: Dies wäre auch in Abbildung 5.6-1 möglich gewesen. Damit geben die zwei unterschiedlichen Lösungen einen Hinweis auf den Spielraum, der bei der Modellierung mit Ereignisgesteuerten Prozessketten vorliegt.

142

5 Ereignisgesteuerte Prozessketten - Vertiefung

Abbildung 5.6-3:

Genauer modellieren mit XODER - Teil 2

6 Beispiele

In diesem Kapitel werden vier aus der Praxis stammende Beispiele vorgestellt. Damit ist gemeint, dass sie reale Geschäftsprozesse modellieren. Die Betonung der Praxisnähe ist wichtig, da dabei andere Ereignisgesteuerte Prozessketten entstehen, als wenn entlang einer Software modelliert oder wenn eine Ereignisgesteuerte Prozesskette einfach nur erfunden wird. Das erste Beispiel beschreibt eine Angebotserstellung bei einem Einzelfertiger, das Zweite eine Auftragsabwicklung bei einem mittelständischen Unternehmen des produzierenden Gewerbes, das Dritte eine Angebotserstellung bei einem Anlagenbauer und das Vierte die Vorbereitung der Auftragsabwicklung, ebenfalls bei einem Anlagenbauer. In der Praxis wird ein Geschäftsprozess im ersten Schritt durch eine intensive Diskussion zwischen den Prozessverantwortlichen bzw. denen, die am Geschäftsprozess teilhaben und den Modellierern erschlossen und beschrieben. Oftmals findet dies im Rahmen eines mehrtägigen Workshops statt. Dabei muss grob Folgendes geleistet werden: x x x

Abgrenzung des Geschäftsprozesses Feststellung der beteiligten Personen und ihrer Organisationseinheiten Feststellung der beteiligten Informationsobjekte

Danach folgt meist die textliche Beschreibung des Geschäftsprozesses, etwa so wie in Abschnitt 2.9 oder bei den in diesem Kapitel beschriebenen Geschäftsprozessen. Diese konzeptionelle Phase wird oft aus Zeitgründen sehr knapp angelegt oder sogar übersprungen. Es wird z.B. gleich mit dem Customizing der angeschafften Betriebswirtschaftlichen Standardsoftware begonnen. Davon ist abzuraten. Die damit eingesparte Zeit wird in der Regel später durch Schwierigkeiten bei der Einführung wieder verbraucht oder sogar mit dem Scheitern des Projekts bezahlt.

Anmerkung zu den Grafiken 1) Wenn die Organisationseinheiten bei einer nachfolgenden Funktion gleich bleiben, werden sie bei dieser nicht angegeben. Falls also bei einer Funktion keine Organisationseinheiten angegeben sind, muss der Kontrollfluss zurückverfolgt werden bis zur ersten Funktion mit einer solchen Angabe.

Erste Schritte

144

6 Beispiele

2) Die Ereignisgesteuerten Prozessketten in diesem Kapitel erstrecken sich über mehrere Seiten. Dazu werden jeweils die Kontrollflusszweige am unteren Ende auf der folgenden Seite ohne spezielle Markierung weitergeführt. Falls Rückschleifen auf eine vorangehende Seite zurückgeführt werden müssen, werden sie besonders gekennzeichnet.

6.1

Kundenanfrage und Angebotserstellung

Der folgende Geschäftsprozess ist ein realer anonymisierter und etwas abstrahierter Prozess aus einem Unternehmen der Investitionsgüterindustrie mit Einzelfertigung. Er deckt die Bearbeitung detaillierter Kundenanfragen und die Erstellung eines Angebots ab. Da es sich bei diesem Unternehmen um einen Einzelfertiger handelt, liegt der Kundenanfrage eine umfangreiche Spezifikation des gewünschten Produkts oder Teils bei. Textliche Beschreibung

Anmerkung Die folgende Ereignisgesteuerte Prozesskette wird zum einen durch die textliche Originalbeschreibung, zum anderen durch Anmerkungen des Verfassers erläutert. Dabei ist der Originaltext eingerückt. Um die Bezüge zwischen textlicher Beschreibung und Abbildungen einfacher herstellen zu können, wurden in die Abbildungen Nummern eingefügt, auf die im Text verwiesen wird.

Rechts die Grafik, links der zugehörige Text

Außerdem wurde bei dieser erweiterten Ereignisgesteuerten Prozesskette und bei der von Abschnitt 6.2 die Darstellung (fast immer) so gewählt, dass sich jeweils auf der linken Seite die Texte und auf der rechten Seite die zugehörigen Grafiken befinden.

Freier Platz für Anmerkungen, Hinweise, Tipps, usw.

Der dadurch an einigen Stellen entstehende freie Platz auf den Seiten wird für Anmerkungen, Hinweise, Tipps zum effizienten Modellieren, usw. verwendet. Der folgende Tipp ist ein erstes Beispiel.

Tipp: Gezielte Detaillierung Bei der Erstellung von Ereignisgesteuerten Prozessketten muss man sich immer sehr klar machen, welchem Zweck die Beschreibung dient. Ist der Zweck ein eher allgemeiner, muss bei den Funktionen durchgängig ein mittleres Niveau eingehalten werden.

6.1 Kundenanfrage und Angebotserstellung

145

Geht es um die Beschreibung von Geschäftsprozessen, die in einer Software vorgedacht wurden, gibt die Software den Detaillierungsgrad vor (wie bei SAP R/3). Dient die Beschreibung einem bestimmten Zweck, müssen die mit diesem Zweck zusammenhängenden Funktionen detaillierter modelliert werden. Die in Abschnitt 6.2 dargestellte Ereignisgesteuerte Prozesskette ist ein gutes Beispiel dafür. Hier stand die Frage im Vordergrund, welche Optimierungspotenziale die Einführung einer elektronischen Archivierung im CAD-Umfeld mit sich bringt. Entsprechend sind alle Funktionen, die damit zu tun haben, detaillierter erfasst als die übrigen. Weitere Tipps: siehe Stichwortverzeichnis. Doch nun zum Geschäftsprozess dieses Abschnitts. Die Beschreibung beginnt mit einer Skizze der möglichen Startereignisse:

Vgl. Abbildung 6.1-1

Die zu bearbeitenden Kundenanfragen können von zweierlei Art sein. Zum einen kann es eine neue Anfrage und zum anderen kann es eine Änderungsanfrage sein. Beide werden gleich behandelt. Die Anfragen gehen immer schriftlich ein und werden von der Abteilung „Verkauf“ entgegengenommen und bearbeitet. Zu einer Anfrage gehören i.d.R. ein Anfrageschreiben und eine oder mehrere Zeichnungen zu den Teilen, die angefragt werden. Die erweiterte Ereignisgesteuerte Prozesskette beginnt mit zwei Startereignissen. Diese müssten hier nicht unbedingt unterschieden werden, da sie nicht zu unterschiedlichen Funktionen führen. Führen sie zu unterschiedlichen Funktionen oder will man sie bewusst unterscheiden, z.B. weil dies Einfluss auf einen späteren Abschnitt des Geschäftsprozesses hat, müssen sie wie in der Abbildung rechts modelliert werden. Da die beiden möglichen Startereignisse Alternativen sind, ist der XODER-Operator der Richtige. Es ist wichtig, sich klar zu machen, dass jedes Mal, wenn eines dieser Startereignisse eintritt, der Geschäftsprozess neu gestartet wird. Oftmals wird versucht, die Durchgänge durch einen Geschäftsprozess innerhalb einer Zeitspanne integriert zu modellieren. Dies ist nicht richtig und führt zu sehr komplexen nicht mehr beherrschbaren Konstruktionen, da dann vielfältige Rückschleifen und Verzweigungen nötig werden (vgl. hierzu auch Abschnitt 7.1). Der Verkauf macht eine erste Überprüfung der Anfrageunterlagen. Dabei prüft er, ob die Anforderungen überhaupt erfüllt werden können (Machbarkeitsprüfung). Hierbei wird auf den Teilestammsatz zugegriffen. Dieser befindet sich in einem Ordner mit allen Informationen zu einem Teil. Au-

Jeweils neu!

146

6 Beispiele

ßerdem überprüft man die Anfrage mithilfe eines Kriterienkatalogs in Bezug auf die geforderte Qualität, die Menge, den Liefertermin, usw. Diese grobe Entscheidung ergibt nun entweder das Ergebnis, dass die Anfrage durchführbar ist oder nicht. Die Machbarkeitsprüfung muss als Funktion modelliert werden mit den entsprechenden Informationsobjekten und der Organisationseinheit Verkauf. Die möglichen Ergebnisse (Abbildung 6.1-1, Position 2) werden durch die nachfolgenden Ereignisse festgelegt: Anfrage ist nicht machbar und Anfrage ist machbar. Da die beiden Ergebnisse echte Alternativen sind, müssen sie mit einem XODER-Operator verknüpft werden. Ist die Anfrage nicht machbar, wird dies dem Kunden mitgeteilt (vom Verkauf) und in der Kundendatei festgehalten. Erstes mögliches Schlussereignis

Der Kontrollfluss bleibt hier verzweigt, da das Ereignis Anfrage ist nicht machbar zu einem ersten Schlussereignis Anfrage ist abgelehnt führt (Position 3). Davor wird die Mitteilung dieses Ergebnisses an den Kunden noch als Funktion eingefügt. Ist sie prinzipiell durchführbar, wird in einer Teambesprechung (Anfragebesprechung) durch die Abteilungen Verkauf, Arbeitsvorbereitung, Qualitätswesen und Verkauf Aussendienst die vorhandene Anfrage besprochen. Hier greift man auf den Teilestammsatz und wieder auf einen Kriterienkatalog zurück. Als Ergebnis werden die zur Erfüllung der Anfrage notwendigen Arbeitsschritte (Aktivitätenplan) herausgearbeitet und eventuelle Termine festgelegt, wann diese Aktivitäten spätestens beendet sein müssen. Beides wird schriftlich festgehalten. Hier liegt, in linearer Abfolge, eine Funktion und ein Ergebnisereignis vor. Bei der Funktion wird durch die Pfeilrichtung angegeben, in welche Informationsobjekte Information fließt und welche nur konsultiert werden. Da sich die Terminfestlegung und die notwendigen Arbeitsschritte aus der Anfragebesprechung heraus ergeben, müssen die Pfeile zu diesen beiden Informationsobjekten führen.

6.1 Kundenanfrage und Angebotserstellung

Abbildung 6.1-1:

Start des Geschäftsprozesses und erste Prüfungen

147

148

Weiter mit Abbildung 6.1-2

6 Beispiele

Danach werden von der Abteilung Verkauf die Kundendaten bearbeitet. Hierzu muss zuerst einmal festgestellt werden, ob der Kunde schon vorhanden ist, oder ob er neu ist. Man greift dazu auf die bestehende Kundendatei zu. Der obige Abschnitt startet die Bearbeitung der Kundendaten (Abbildung 6.1-2, Position 5), wobei die Ereignisse Kunde ist neu bzw. Kundendaten sind schon vorhanden den weiteren Prozessverlauf steuern. Bei einem Neukunden benötigt man vorab zuerst Informationen über dessen Ansprüche an das Qualitätsmanagement. Sind diese noch nicht bekannt, muss das Qualitätswesen die benötigten Informationen besorgen.

Eventuelles Nachfragen

Zusammenführen mehrerer Kontrollflusszweige

Dies erfordert das Einfügen einer entsprechenden Funktion, Prüfen ob Qualitätsanforderungen bekannt, mit den angegebenen Organisationseinheiten und Informationsobjekten. Falls erkannt wurde, dass die Qualitätsanforderungen noch nicht (hinreichend) bekannt sind, folgt die Funktion Informationen einholen bei Kunde mit der Organisationseinheit Qualitätswesen und dem Informationsobjekt Qualitätsanforderungen. Anschließend wird mithilfe einer Rückschleife der Kontrollfluss vor die Prüfung zurückgeführt. Die Wiedereinbindung geschieht, wie in Abschnitt 5.1 beschrieben, mit einem XODER-Operator. Die Syntax sieht vor, dass Rückschleifen immer von einem Ereignis ausgehen (dem „auslösenden“) und (dementsprechend) vor einer Funktion wieder angebunden werden. Es wurde hier darauf verzichtet, den Abbruch der Rückschleife nach zu vielen Wiederholungen zu modellieren (vgl. Abschnitt 5.1). Zu beachten ist der Wechsel der Organisationseinheiten in der Rückschleife. Während die Informationen vom Qualitätswesen eingeholt werden, wird die Prüfung, ob die Qualitätsanforderungen nun hinreichend bekannt sind, vom Verkauf vorgenommen. In solide modellierten Geschäftsprozessen kann eine dadurch deutlich werdende Rangordnung zwischen den Abteilungen eines Unternehmens leicht erkannt werden. Irgendwann wird – hoffentlich – die Prüfung ob Qualitätsanforderungen bekannt zu dem positiven Ergebnis Bekannt führen. Da es dann im Geschäftsprozess so weitergeht, als ob die Informationen schon vorhanden gewesen wären, wird in der erweiterten Ereignisgesteuerten Prozesskette der Kontrollfluss nach diesem positiven Ergebnis wieder mit dem anderen zusammengeführt. Dieses Zusammenführen mehrerer Zweige des Kontrollflusses muss auch mit einem Operator erfolgen. Dies gilt immer, auch wenn die Aufspaltung nicht so offensichtlich ist, wie hier, sondern weiter zurück liegt. In Frage kommen dann meist der ODER- oder XODER-Operator. Da es sich hierbei um echte alternative Abläufe handelt, ist in diesem Beispiel der XODER-Operator angemessen.

6.1 Kundenanfrage und Angebotserstellung

Abbildung 6.1-2:

149

Informationen einholen

Sind die Informationen vorhanden (entweder durch Einholen der Informationen oder dadurch, dass der Kunde sie gleich mit der Anfrage mitschickt) oder ist der Kunde ein bereits erfasster Kunde, so werden die Ergebnisse der Anfragebesprechung und die Qualitätsanforderungen als Basis für die Entscheidung genommen, ob das angefragte Teil angeboten wird oder nicht. Diese Angebotsentscheidung übernimmt der Verkauf. Dieser Absatz leitet nun über zur nächsten zu erledigenden Aufgabe, der sog. Angebotsentscheidung (Abbildung 6.2-3 oben). Deren Ergebnisse können wiederum als alternative Ereignisse modelliert werden.

Weiter mit Abbildung 6.1-3

Angebotsentscheidung

150

6 Beispiele

Wie jetzt bereits zu erkennen ist, handelt es sich hier um eine mehr- ja sogar vielstufige Prüfung, ob die Anfrage zu einem Angebot führen soll. Dies wurde auch nicht wegabstrahiert, da es sich um ein wesentliches Merkmal vieler realer Geschäftsprozesse handelt. Noch ein frühes Ende (Schlussereignis)

Wird entschieden, dass das Teil nicht angeboten wird, z.B. weil die Qualitätsanforderungen zu hoch sind oder nicht genügend Kapazitäten frei sind, um den Anforderungen der Anfrage gerecht zu werden, dann informiert der Verkauf den Kunden über die Ablehnung seiner Anfrage und vermerkt dies in der Kundendatei. Hier ist ein weiteres mögliches (frühes) Ende des Geschäftsprozesses mit dem Schlussereignis Kunde ist informiert erreicht (Position 8). Wieder wird die Tätigkeit der eigentlichen Absage als Funktion und das Endergebnis als Schlussereignis modelliert. Wenn das Teil dem Kunden angeboten wird, so wird dieser, falls er neu ist, mit umfassenden Angaben vom Verkauf in die Kundendatei der bestehenden Datenbank (mit ACCESS) aufgenommen. Im positiven Fall kommt es nun zu einer detaillierteren Überprüfung der Kundendaten (Position 9). Falls sich ergibt, dass die Kundendaten unvollständig sind, werden sie erhoben, was durch die Funktion Kundendaten in Datenbank erfassen ausgedrückt wird. Die EPK-Syntax verlangt, dass hier dann durch ein Ergebnisereignis Daten sind erfasst der Abschluss der Tätigkeit angegeben wird. Danach werden die beiden Kontrollflusszweige wieder zusammengeführt. In diesem Abschnitt ist ein Medienbruch55 angedeutet („ACCESSDatei“) und – durch die Wiederholung der Informationsbeschaffung vom Kunden (vgl. Abbildung 6.1-2, Position 6) – auch eine Optimierungsmöglichkeit. Die Anfragedaten werden ebenfalls durch die Abteilung Verkauf in eine Datenbank aufgenommen. Dies wird einfach als weitere Funktion mit einem Ergebnisereignis modelliert (Position 10).

55

Ein Medienbruch liegt vor, wenn eine Information im Verlaufe eines Geschäftsprozesses mehrfach erfasst, z.B. auf unterschiedlichen Informationsträgern.

6.1 Kundenanfrage und Angebotserstellung

Abbildung 6.1-3:

Zweite Entscheidungsstufe und weitere Informationsbeschaffung

151

152

6 Beispiele

Hier wird, mangels näherer Informationen zur Datenbank, einfach ein entsprechendes wenig spezifisches Informationsobjekt modelliert. Die Anfragedaten als Informationslieferanten hätten noch zusätzlich als eigenes Informationsobjekt modelliert werden können. Weiter mit Abbildung 6.1-4

Außerdem werden die benötigten Aktivitäten (Arbeitsschritte) mit den Endterminen erfasst und eine Liste ausgedruckt, auf der diese Termine aufgeführt sind. Zusätzlich werden die Anfrageunterlagen vom Verkauf auf Richtigkeit und Vollständigkeit überprüft, wofür man qualitätsbezogene Unterlagen, das Anfrageschreiben des Kunden sowie die Zeichnung(en) verwendet. Diese Funktionen werden hintereinander gelegt. Zuerst die Erfassung der Arbeitsschritte, dann die Überprüfung der Anfrageunterlagen (Position 11). Sie hätten auch parallel gelegt werden können, da sie nicht unbedingt hintereinander erledigt werden müssen. Dass erst jetzt die Anfrageunterlagen auf Richtigkeit geprüft werden, hängt damit zusammen, dass sich der dafür notwendige hohe Aufwand nur lohnt, wenn die Wahrscheinlichkeit, dass aus der Anfrage ein Angebot wird, hoch ist. Sind die Anfrageunterlagen nicht korrekt oder nicht komplett, so muss die Abteilung Arbeitsvorbereitung (AV) mithilfe der Zeichnung(en), dem Artikelstammsatz und dem Anfrageschreiben die Fehler in den Anfrageunterlagen beheben. Dies erfolgt so oft, bis die Prüfung der Anfrageunterlagen zu einem positiven Ergebnis führt.

Rückschleife

Obiger Text deutet die Wiederholung eines Geschäftsprozessabschnitts an, was in der Ereignisgesteuerten Prozesskette zu einer Rückschleife führt. Nach dem Ereignis, dass den Bedarf signalisiert (Nicht in Ordnung), wird die entsprechende Tätigkeit als Funktion Behebung des Fehlers modelliert. Da hier eine andere Organisationseinheit (AV) als vor der Rückschleife im Spiel ist, muss die Funktion Anfrageunterlagen überprüfen mit einer Organisationseinheit versehen werden, obwohl es sich um dieselbe handelt, wie bei ihrer direkten Vorgängerfunktion. Danach startet die Rückschleife aus dem Ereignis, das den Bedarf an Wiederholung signalisiert56 (Position 12). Die verwendeten Informationsobjekte ergeben sich unmittelbar aus der textlichen Beschreibung. Sind die Anfrageunterlagen in Ordnung, leitet sie der Verkauf mit der Terminliste an die Arbeitsvorbereitung weiter. Sind sie von Beginn an vollständig und richtig, so werden die Unterlagen direkt an die Arbeitsvorbereitung weitergeleitet. 56

Wieder wird darauf verzichtet, die maximal mögliche Zahl an Wiederholungen, bzw. ein Abbruchkriterium zu modellieren.

6.1 Kundenanfrage und Angebotserstellung

153

Damit sind wir beim linken Zweig dieses EPK-Fragments, der die Weiterführung des Geschäftsprozesses angibt (bis Position 13).

Abbildung 6.1-4:

Vertiefte Überprüfung der Anfrageunterlagen

154

6 Beispiele

Der nächste Schritt besteht nun darin, die eigentlichen Angebotsunterlagen zu erstellen. Auf der Basis des Investitionsplanes und der Kalkulationsgrundlage erstellt die Arbeitsvorbereitung nun die Angebotsunterlagen. Dieser Textabschnitt führt zu einer einfachen Funktion (Position 14), die allerdings, bedingt durch den nächsten Textabschnitt, gleich wieder modifiziert wird, denn da wird ein Überwachungsvorgang mit potenziellen Sanktionen skizziert: Der Verkauf überwacht die Arbeitsschritte bei der Erstellung der Angebotsunterlagen. Wird festgestellt, dass ein Arbeitsschritt in Verzug ist, so wird eine Mahnliste ausgedruckt, auf der das zu bearbeitende Teil, der Bearbeiter und der Solltermin festgehalten sind. Diese Mahnliste wird der Arbeitsvorbereitung weitergereicht und dem entsprechenden Bearbeiter vorgelegt, der dann seine Bearbeitung schnellstmöglich abschließen sollte, um die Angebotsunterlagen zu erstellen (Position 15). Überwachung

Defizit

Mahnliste

Ereignisraum

Die Überwachung der Arbeitsschritte läßt sich so ohne weiteres nicht mit Ereignisgesteuerten Prozessketten modellieren. Hier fehlt ein entsprechendes Element in der gängigen Notation. Um diesen Abschnitt des Geschäftsprozesses trotzdem modellieren zu können, wurde hier zu einem Trick gegriffen. Es wurden einzelne (Arbeits-)Schritte definiert (dies könnten z.B. einfach Tage oder bestimmte CAD-Zeichnungen sein) und nach jedem dieser Schritte die Überprüfung der Termintreue angesetzt, mit entsprechenden Verzweigungen (vgl. zur Modellierung von Überwachung in Ereignisgesteuerten Prozessketten auch Abschnitt 7.1). Vor dem Prüfen ob Verzug muss aber natürlich jeweils die Prüfung, ob die Angebotsunterlagen fertig sind, angesetzt werden. Sobald sich hier ein positives Ergebnis ergibt, geht der Geschäftsprozess weiter. Solange dies nicht der Fall ist, erfolgt dann jeweils die Verzugsprüfung. Zur Erstellung einer Mahnliste und ihrer Weiterleitung an die Arbeitsvorbereitung kommt es damit nur, falls die Angebotsunterlagen noch nicht fertig sind und ein Verzug festgestellt wurde. Würde die Erstellung der Angebotsunterlagen als Ganzes in eine einzige Funktion gepackt (gekapselt), wäre die Überwachung nur schwer modellierbar. Denkbar wäre dann nur eine getrennte Ereignisgesteuerte Prozesskette, wie in Abbildung 6.1-6, bei der das Ereignis Verzug ist aufgetreten als Startereignis gesetzt wird. Sie beruht auf dem Grundkonzept der Ereignissteuerung, auf der Idee eines Ereignisraumes eines Unternehmens, der alle für das Unternehmen wichtigen Ereignisse umfaßt. Im Folgenden (Abbildung 6.1-5) nun aber die Darstellung, die hier gewählt wurde. Diese Ereignisgesteuerte Prozesskette wird dann in Abbildung 6.1-7 fortgesetzt.

6.1 Kundenanfrage und Angebotserstellung

Abbildung 6.1-5:

155

Hilfskonstruktion für die Modellierung von Überwachung

156

6 Beispiele

Abbildung 6.1-6: Weiter mit Abbildung 6.1-7

Alternative Darstellung der Erstellung der Mahnliste

Im nächsten Schritt verlagert sich das Handeln von der Arbeitsvorbereitung in den Verkauf. Die fertig gestellten Unterlagen werden dann an den Verkauf geleitet.

Weiterleitung

Die Weiterleitung von Unterlagen wird nicht immer als Funktion modelliert. Schon gar nicht bei Ereignisgesteuerten Prozessketten, die zu einer Betriebswirtschaftlichen Standardsoftware erstellt wurden. Modelliert wird dies aber bei der Beschreibung konkreter Geschäftsprozesse, wenn der Transport als aufwändig empfunden wird und, vor allem, wenn die Optimierungsbemühungen auf diesen Vorgang zielen, wenn also z.B. Papierdokumente durch elektronische ersetzt werden sollen. Hier wurde dafür eine entsprechende Funktion (Position 16) und ein Ergebnisereignis eingefügt. Im Verkauf werden die Angebotsunterlagen nun auf Richtigkeit überprüft, eventuelle Fehler korrigiert und fehlende Informationen anhand der Preiskalkulation vervollständigt. Dies führt zu einer Funktion Angebotsunterlagen prüfen. Die dabei im Text angedeuteten erwarteten Ergebnisse sind durch die Ereignisse angegeben. Da gleichzeitig Fehler zu korrigieren und Informationen zu ergänzen sein können, wurde hier der ODER-Operator gewählt, auch wenn – das Fragezeichen in der Abbildung deutet es an - das dritte Ereignis Alles in Ordnung nicht zusammen mit den anderen auftreten kann (vgl. zu die-

6.1 Kundenanfrage und Angebotserstellung

157

sem Punkt und zu einer „genaueren“ Modellierung dieses Abschnitts Absatz 5.6).

Abbildung 6.1-7:

Prüfung der Angebotsunterlagen durch den Verkauf

158

6 Beispiele

Bei den beiden Ereignissen Fehler sind zu korrigieren und Informationen sind zu ergänzen müssen dann noch nachfolgend die entsprechenden Funktionen mit Ergebnisereignissen eingefügt werden. Danach werden die drei Kontrollflusszweige wieder zusammengeführt. Nachdem diese Stufen durchschritten und die Angebotsunterlagen vollständig und korrekt sind, werden die vorhandenen Daten in die ACCESS-Datenbank aufgenommen.

Rücksprünge

Weiter mit Abbildung 6.1-8

Dieser Text gibt die notwendige Funktion direkt an (Abbildung 6.1-7 unten) und deutet auch gleich noch einen Medienbruch an. Das Ergebnisereignis zu dieser Funktion folgt auf der nächsten Abbildung. Die Rücksprünge in Abbildung 6.1-7 (vor die Funktion Angebotsunterlagen prüfen) kommen von notwendigen Korrekturen im Angebot (vgl. die folgende Abbildung 6.1-8), nach denen jeweils wieder die Angebotsunterlagen geprüft werden. Außerdem wird ein schriftliches Angebot vom Verkauf mittels MS-Word erstellt. Der Nachteil hierbei ist, dass eine doppelte Erfassung stattfindet, zum einen für die Erstellung des Angebots in Word, zum anderen bei der Erfassung der Daten in die Datenbank. Der Geschäftsprozess schreitet nun voran mit der Erstellung der schriftlichen Fassung des Angebots (Position 18). Hier wird der Medienbruch gleich in der textlichen Beschreibung des Geschäftsprozesses angegeben. Nun erfolgt eine letzte Kontrolle durch Verkauf und Arbeitsvorbereitung, ob das Angebot der gewünschten Anfrage des Kunden in vollem Umfang entspricht. Ist dies der Fall, kann es an den Kunden verschickt werden. Gibt es Abweichungen vom Angebot zur Anfrage, sind drei Alternativen möglich: a) Es wird sofort eine Korrektur des Angebots veranlaßt (durch den Verkauf auf der Basis des Angebots). Die Angebotsunterlagen werden zurückgegeben, der Prozess wird ab der Prüfung der Angebotsunterlagen auf Richtigkeit (vorletzter Absatz) wiederholt. b) Es wird ein Vermerk der Abweichung im Angebot getätigt (durch den Verkauf auf der Basis des Angebots) und das Angebot dann an den Kunden geschickt. c) Das Angebot wird mit dem Kunden abgeklärt (wiederum durch den Verkauf auf der Basis des Angebots. Ist dieser mit der Abweichung einverstanden, wird das Angebot verschickt. Falls nicht, muss eine Korrektur des Angebots veranlaßt werden (siehe Punkt a)).

6.1 Kundenanfrage und Angebotserstellung

Abbildung 6.1-8:

159

„Letzte Kontrolle“ der Angebotsunterlagen

Diese drei Alternativen werden hier zusammen mit dem positiven Ergebnis mithilfe eines vierfachen exklusiven ODER’s modelliert. Bei zwei der Alternativen erfolgt der oben angesprochene Rücksprung vor die Funkti-

160

Weiter mit Abbildung 6.1-9

Nachfassen

Weiter mit Abbildung 6.1-10

6 Beispiele

on Angebotsunterlagen prüfen. Darin äußert sich die große Sorgfalt, die hier der Angebotserstellung zugrundegelegt wird. Etwas störend ist an dieser Stelle, dass die beteiligten Personen nicht genauer spezifiziert sind. Dem entspricht aber eine Schwäche der „Methode EPK“ . Hier, wie auch sonst oft bei der Beschreibung realer Geschäftsprozesse, ist es sinnvoll, über die vorgeschriebene Angabe der Organisationseinheit hinauszugehen und etwas detailliertere Angaben zu machen. Denn natürlich sind es unter Umständen verschiedene Personen aus dem Verkauf, die die Angebotsunterlagen prüfen (Abbildung 6.1-7), die das Angebot schreiben und die Letzte Kontrolle durchführen. Im obigen Originaltext ist bereits das Versenden des Angebots an die Kunden thematisiert. Dies wurde in Abbildung 6.1-9 als Funktion mit einem Ergebnisereignis eingefügt. Damit ist das Angebot an den Kunden verschickt, womit der Geschäftsprozess allerdings noch nicht endet, da man sich natürlich erhofft, dass aus dem Angebot ein Auftrag wird. Hierfür muss entweder per Brief oder telefonisch nachgefaßt werden (durch den Verkauf anhand der Angebotsunterlagen) oder bei einem Besuch des zuständigen Außendienstmitarbeiters verhandelt werden. Möglich ist außerdem, dass die Vertretung vor Ort Kontakt mit dem Kunden aufnimmt. Diese Besprechung des Angebots mit dem Kunden erfolgt nur auf eine der angeführten Arten. Aus dieser Beschreibung wird eine Funktion Entscheidung über Nachfassaktion abgeleitet mit den drei angegebenen möglichen Nachfassarten. Nach den entsprechenden Funktionen wird der Kontrollfluss wieder zusammengeführt. Angebotsliste meint eine Liste der jeweils aktuellen (offenen) Angebote, die beim Außendienst bzw. den Vertretungen hinterlegt sind. Abbildung 6.1-10 zeigt den Abschluss dieses Geschäftsprozesses. Zuerst wurde eine Wartefunktion Warten auf die Reaktion des Kunden eingefügt. Die im folgenden Originaltext angeführten möglichen Kundenreaktionen wurden als Ergebnisereignisse dieser Wartefunktion modelliert. Bei Auftragserteilung wird der Auftrag an den Verkauf weitergeleitet und entsprechend bearbeitet. Bei Unstimmigkeiten wird das Angebot überarbeitet, ein Nachtragsangebot geschrieben und an den Kunden gesandt. Dieses ersetzt dann das ursprüngliche Angebot. Als letzte Möglichkeit gibt es hier noch die, dass man den Auftrag zu einem Angebot nicht erteilt bekommt und das Angebot aufgelöst wird.

Wartefunktion

Solche Wartefunktionen sind immer dann nötig, wenn der weitere Verlauf des Geschäftsprozesses vom Handeln Außenstehender beeinflusst wird.

6.1 Kundenanfrage und Angebotserstellung

Abbildung 6.1-9:

„Nachfassen“

161

162

6 Beispiele

Tritt das Ereignis Kunde reklamiert Unstimmigkeiten ein, werden für die Überarbeitung des Angebots und das Schreiben des Nachtragsangebots jeweils entsprechende Funktionen angesetzt. Dann wird das Nachtragsangebot an den Kunden geschickt, was in der Ereignisgesteuerten Prozesskette mittels Rücksprung vor die Funktion Angebot an den Kunden schicken (Abbildung 6.1-8) modelliert wird. Dies ist sinnvoll, da auch im Falle eines Nachtragsangebots über das Nachfassen nachgedacht wird. Beides - Auftragserteilung und Auftragsauflösung - wird in der Datenbank zu den Angeboten als „Status“ des Auftrags vermerkt.

Syntaktisch bedingte Ereignisse

Dies führt dazu, dass der Kontrollflusszweig von Auftrag geht ein mit dem von Auftrag wird nicht erteilt zusammengeführt wird, sodass in beiden Fällen die Funktion Status in Datenbank vermerken angestoßen wird. Nachdem dies modelliert ist, hat der Prozess ein weiteres Schlussereignis und einen Prozesswegweiser. In dieser ersten etwas längeren Ereignisgesteuerten Prozesskette wurde deutlich, dass bestimmte Ereignisse tatsächlich nur eine syntaktische Funktion haben. Dies sind Ereignisse, die ohne Operator nach einer Funktion kommen (also im Rahmen eines einzelnen Kontrollflusszweiges). Um dies deutlich zu machen, wurde hier vereinzelt einfach die Ereignisbezeichnung fertig gewählt. Diese nicht inhaltstragenden Ereignisse werden bei der Erstellung von Ereignisgesteuerten Prozessketten tatsächlich sehr oft als lästig empfunden. Sie sollten aber trotzdem so eingefügt werden, da dadurch die Übersichtlichkeit erhalten bleibt.

Tipp: Bedingungen 1 Bestehen Bedingungen, die erfüllt sein müssen, bevor es an einer bestimmten Stelle im Kontrollfluss weitergeht, werden diese Bedingungen als Ereignisse formuliert und als auslösende Ereignisse in die Ereignisgesteuerte Prozesskette eingefügt. Dabei sind drei Fälle zu unterscheiden: Alle müssen eintreten, genau eine und mindestens eine muss eintreten. Weitere Tipps: siehe Stichwortverzeichnis.

6.1 Kundenanfrage und Angebotserstellung

Abbildung 6.1-10:

Auftragserteilung oder nicht

163

164

6.2

Start mit Abbildung 6.2-1

Suchen und finden

Kapselung kontra evtl. Optimierung

6 Beispiele

Auftragsabwicklung

Dieses Beispiel beschreibt eine Auftragsabwicklung57 in einem mittelständischen Unternehmen des Maschinenbaus. Die Produkte werden in Einzelfertigung hergestellt, jedes Produkt muss mithilfe von Computer Aided Design (CAD) entwickelt werden. Der Gesamtprozess ist aufgeteilt in zwei Teilprozesse. In die eigentliche Auftragsabwicklung und in den Prozess Montage und Versand, wobei der Erste den Hauptteil ausmacht. Die Auftragsabwicklung beginnt mit dem Startereignis Kundenanfrage ist eingetroffen. Die Bearbeitung aller Anfragen übernimmt der Vertrieb. Auch hier hat, wie im vorigen Beispiel, der Vertrieb eine starke Position im Unternehmen. Als Erstes wird geprüft, ob dieselbe oder eine ähnliche Anlage schon mal geliefert wurde. Das exklusive ODER deutet an, dass man sich für eine der drei Alternativen entscheidet, was den weiteren Ablauf angeht, auch wenn vielleicht die ersten beiden Ereignisse zusammen eingetreten sind. In Abschnitt 5.6 wird diese Situation, die in Wirklichkeit etwas komplizierter ist, näher betrachtet. Für die Prüfung werden verschiedene Informationsmaterialien verwendet: CAD-Zeichnungen, Unterlagen zu früher ausgelieferten Aufträgen und technische Daten der angefragten Anlage. Dieser Abgleichprozess ist auf konventionellem Weg sehr aufwändig. Ein optimierter Ablauf könnte hier darin bestehen, dass zum einen die Unterlagen schneller gefunden werden, zum anderen aber auch darin, dass die „bessere“ Lösung gefunden wird. Also z.B. die „ähnlichere“ Anlage oder eben wirklich die gleiche und nicht eine ähnliche, wenn es denn eine gleiche gibt. Beides würde zur Einsparung von Zeit und zur Senkung von Kosten führen (vgl. unten). Hier drängt sich eine elektronische Archivierung, wenn sie kompetent eingeführt wird, geradezu auf. Entscheidend für eine Beschleunigung dieses Suchprozesses wäre allerdings eine gründliche formale und inhaltliche Erschließung aller benötigten Dokumente. Formale Erschließung bedeutet hier die Erfassung des Anlagennamens, der Zeitangaben, des Kundennamens, usw. Zur inhaltlichen Erschließung würde hier eine datenbankgerechte Beschreibung der Anlage gehören. Diese müsste so erfolgen, dass auch eine Ähnlichkeit der Anlagen erfasst wird, da es ja darum geht, eine möglichst ähnliche Anlage zu finden. Die Prüfung, ob Anlage schon mal geliefert ist hier in einer Funktion zusammengefasst, sodass eine eventuelle Optimierung dieses Vorgangs sich nicht direkt in der Ereignisgesteuerten Prozesskette niederschlagen würde, weil sie „innerhalb“ der Funktion stattfindet (vgl. zum Problem

57

Auch in diesem Beispiel werden bei einer Funktion Organisationseinheiten nicht angegeben, wenn sie denen der vorherigen Funktion entsprechen.

6.2 Auftragsabwicklung

165

der Kapselung verschiedener Tätigkeiten in einer Funktion Abschnitt 7.2).

Abbildung 6.2-1:

Auftragsdurchgang, Teil 1 – Angebotserstellung

Abhängig vom Ergebnis der Prüfung werden dann Kalkulation und Angebot mit eventuellen Zuschlägen übernommen oder übernommen und mit mehr oder weniger großem Aufwand verändert oder völlig neu erstellt.

166

6 Beispiele

Optimierungspotenziale

Die Optimierungspotenziale sind hier mit Sicherheit sehr groß, da die Durchführung der Kalkulation und die Erstellung des Angebots sehr aufwändig sind und somit jeder „Treffer“ Einsparungen mit sich bringt und zwar um so mehr, je größer die Ähnlichkeit ist.

Modellierungsebene

In dem kurzen Abschnitt von Abbildung 6.2-1 steckt die gesamte Angebotserstellung. Man vergleiche dies mit dem Beispiel von Abschnitt 6.1, wo die einzelnen Abschnitte der Angebotserstellung detailliert herausgearbeitet wurden. Wie detailliert modelliert wird, bleibt dem Modellierer überlassen. Hinweise geben der oben erwähnte Zweck der Modellierung und die ganz allgemeine Forderung nach ausreichender Aussagekraft der Ereignisgesteuerten Prozesskette. Wenn Kalkulation und Angebot erstellt sind, wird beides zum Kunden geschickt, was durch eine entsprechende Funktion und ein Ereignis erfasst wurde. Im nächsten Abschnitt (Abbildung 6.2-2) verlagert sich – sozusagen – die Handlung aus dem Unternehmen heraus, zum Kunden. Damit wechselt der Träger des Geschäftsprozesses (vgl. hierzu Abschnitt 7.1). In einem solchen Fall bleibt der Geschäftsprozess, aus der Sicht „unseres“ Unternehmens, mit einer Wartefunktion stehen, die hier Warten auf Reaktion des Kunden genannt wurde. Dies so lange, bis eines der erwarteten externen Ereignisse eintritt. Natürlich wäre es ohne weiteres möglich, ein Nachfragen nach Ablauf einer bestimmten zeitlichen Frist, mit hineinzumodellieren (vgl. zur Modellierung des Wartevorgangs Abschnitt 5.3). Hier sind drei mögliche Ereignisse vorgedacht:

Weiter mit Abbildung 6.2.-2

Externe Ereignisse

Verhandlungen

x x x

der Kunde akzeptiert das Angebot und bestellt es trifft eine Absage ein der Kunde wünscht Änderungen, d.h. Verhandlungen

Die damit vorliegende eindeutige XODER-Situation wurde mit dem entsprechenden Operator modelliert. Falls der Kunde Verhandlungen wünscht, werden diese getätigt. Die Art der Angabe des Informationsobjekts zeigt, dass (natürlich) das Angebot informationelle Basis des Vorgangs ist, dass es aber auch verändert wird. Andere hier benötigte Informationsobjekte könnten die früheren Aufträge des Kunden sein (z.B. bei einer entsprechenden Bezugnahme). Da dies selten vorkommt, wurde es nicht mitmodelliert. Die Verhandlungen können den Preis, den Liefertermin oder aber auch die Spezifikation des Produkts betreffen. Danach muss wiederum auf die Reaktion des Kunden gewartet werden, was einfach durch einen entsprechenden Rücksprung nach dem Ereignis Neues Angebot verschickt vor die Funktion Warten auf Reaktion des Kunden modelliert wird. Falls eine Absage eintrifft, findet der Geschäftsprozess hier ein frühes Ende. Das Angebot wird abgelegt und in der Kundendatei wird der Vermerk getätigt, dass dieses Angebot bei dem Kunden nicht erfolgreich war.

6.2 Auftragsabwicklung

167

Das Informationsobjekt Kundendatei bei der Funktion Angebot ablegen und in Kundendatei vermerken muss Pfeile in beide Richtungen aufweisen, weil Daten gelesen und geändert werden.

Abbildung 6.2-2:

Auftragsdurchgang, Teil 2 – Auftragseingang oder nicht

Das Ereignis Angebot ist abgelegt stellt hier somit eines der möglichen Schlussereignisse dar. Es ist ohne weiteres möglich, dass eine Ereignisgesteuerte Prozesskette mehrere Schlussereignisse aufweist, z.B., so wie hier, bei einem mehrstufigen Entscheidungsprozess.

Schlussereignis

168

Weiter mit Abbildung 6.2-3

Noch ein Schlussereignis Defizit der „Methode EPK“

6 Beispiele

Akzeptiert der Kunde das Angebot, schickt er den Auftrag. Dieser wird dann wiederum vom Vertrieb auf Übereinstimmung mit dem Angebot geprüft. Die Übereinstimmung erfolgt bezüglich technischer und kaufmännischer Aspekte. Als Informationsobjekte werden hier das Angebot und der Auftrag benötigt. Beide werden gelesen, aber nicht verändert, weshalb der Pfeil nur zur Funktion hin weist. Der weitere Ablauf wird dann durch das Ergebnis dieser Prüfung bestimmt. Ist der Auftrag in Ordnung, wird sofort eine Auftragsbestätigung erstellt. Dazu werden die angegebenen Informationsobjekte benötigt. Das Informationsobjekt Auftragsbestätigung entsteht aus der Funktion heraus. Ist der Auftrag nicht in Ordnung werden – weiterhin vom Vertrieb – die offenen Fragen mit dem Kunden geklärt. Führt diese Klärung zu einer Beseitigung der Differenzen, wird dieser Zweig des Kontrollflusses mithilfe eines XODER-Operators ebenfalls zur Funktion Auftragsbestätigung erstellen geführt. Dies ist die gängige Technik, um zwei oder mehr Zweige wieder zusammenzuführen, allerdings nur, wenn die Aufspaltung ebenfalls durch ein XODER erfolgte. Hier ist dies auch ohne Überprüfung der Ereignisgesteuerten Prozesskette klar, da der Kontrollfluss entweder den einen oder den anderen Zweig nehmen kann. Oftmals sieht man an einer solchen Stelle aber auch den ODER-Operator. Können die Differenzen mit dem Kunden nicht beseitigt werden, wird der Auftrag abgelehnt, was durch eine entsprechende Funktion und ein Ereignis modelliert wird. Anschließend erfolgt in diesem Zweig des Kontrollflusses die Ablage des Angebots. Außerdem wird ein Vermerk in der Kundendatei vorgenommen. Damit ist dann ein weiteres frühes Ende des Geschäftsprozesses erreicht. Das Ereignis Angebot abgelegt signalisiert damit ein weiteres Schlussereignis dieser Ereignisgesteuerten Prozesskette. Doch nun zurück zur Funktion Auftragsbestätigung erstellen in Abbildung 6.2-3. Nach der Erstellung der Auftragsbestätigung wird diese an den Kunden gesandt. Außerdem wird eine Auftragsmappe angelegt, in der sich die Auftragsbestätigung, der bisherige Schriftverkehr sowie der Auftrag befindet. Diese Situation – mehrere Informationsobjekte werden zu einem neuen zusammengefasst – kann mit den üblichen Instrumentarien dieser Beschreibungssprache nicht modelliert werden. Sie muss separat festgehalten werden. Hier wurde am unteren Ende der Ereignisgesteuerten Prozesskette darauf verzichtet, den durch einen UND-Operator aufgeteilten Kontrollfluss wieder zusammenzuführen. Dies ist bei einem UND-Operator möglich, darf aber nicht bei ODER bzw. XODER gemacht werden (vgl. Abschnitt 5.5).

6.2 Auftragsabwicklung

Abbildung 6.2-3:

169

Auftragsdurchgang, Teil 3 – Klärung offener Fragen oder frühes Ende

170

Weiter mit Abbildung 6.2-4

Optimierungspotenzial

6 Beispiele

Die Auftragsmappe wird nun zur Stücklistenerstellung weitergeleitet. Hier wird geprüft, ob es sich um einen Wiederholauftrag handelt. Als Informationsquellen dienen hier das PPS-System, die Auftragsbestätigung, falls sie Vermerke enthält, und der Erfahrungs- bzw. Wissensschatz des Bearbeiters. Letzterer wird in Ereignisgesteuerten Prozessketten nicht modelliert, da sich diese auf die formellen Strukturen und Abläufe konzentriert. Bei einem Wiederholauftrag wird die entsprechende Stückliste herausgesucht und der Auftragsmappe hinzugefügt. Wenn es sich nicht um einen Wiederholauftrag handelt geschieht dasselbe mit einer möglichst ähnlichen Stückliste. Die Information, ob es sich um einen Wiederholauftrag handelt, kam aus der Prüfung in Abbildung 6.2-1. Die Weitergabe dieser Information wurde hier nicht modelliert. Dies wäre aber ohne weiteres möglich gewesen, wenn bei der Funktion Prüfung, ob Anlage schon geliefert ein entsprechender Schreibvorgang erfasst worden wäre, z.B. beim Auftrag selbst. Falls es sich um keinen Wiederholauftrag handelt, wird anschließend die Auftragsmappe an einen Konstrukteur weitergeleitet. Optimierungspotenzial zeigt hier die Suche nach einer „ähnlichen“ Stückliste, d.h. nach einem ähnlichen früher gefertigten Produkt. Gelingt es, die Stücklisten elektronisch so verfügbar zu machen, dass die Ähnlichkeit von Stücklisten gemessen werden kann, könnten hier große Einsparungen erfolgen, denn je ähnlicher die Stückliste der zu erstellenden ist, desto weniger Aufwand ist zu tätigen.

Tipp: Bedingungen 2 - Alle Bedingungen müssen eintreten. Liegen mehrere Bedingungen vor und müssen alle eintreten, damit es im Kontrollfluss weitergeht, werden die Bedingungen als Ereignisse formuliert und mit dem UNDOperator verknüpft. Dann werden sie als auslösende Ereignisse mit nachfolgender Funktion oder nachfolgenden Funktionen in die Ereignisgesteuerte Prozesskette integriert. Weitere Tipps: siehe Stichwortverzeichnis.

6.2 Auftragsabwicklung

Abbildung 6.2-4:

Auftragsdurchgang, Teil 4 – Wiederholauftrag oder nicht

171

172

Weiter mit Abbildung 6.2-5

6 Beispiele

In der Konstruktion wird die Stückliste (vgl. Anmerkung) nun geprüft und – falls notwendig - abgeändert. Anschließend wird die Auftragsmappe zur Stücklistenerstellung zurückgegeben, um diese im PPS-System zu berichtigen. Diese Stücklistenbearbeitung wird durchgeführt, um möglichst frühzeitig die Disposition der bekannten Teile zu ermöglichen. Nach der Funktion Vorgegebene Teile in Auftragsstückliste kopieren wird dieser Zweig des Kontrollflusses wieder mit dem zusammengeführt, der aus der Verzweigung herrührt, in der entschieden wurde, ob es sich um einen Wiederholauftrag handelt oder nicht. Gemeinsames Ergebnisereignis beider Zweige ist dann Stückliste erstellt. Im Anschluss werden nun zwei Funktionen angestoßen und ausgeführt, Stückliste ausdrucken und Erstellung Dispositionsvorschlag. Letzterer betrifft die bis dahin bekannten Teile.

Anmerkung: Stücklisten Stücklisten sind wichtige Objekte für die Prozessanalyse, sobald sich der Geschäftsprozess den Produkten des Unternehmens nähert. Datenbanktechnisch gesehen handelt es sich um zusammengesetzte Objekte. Hier die Auffassung und Realisierung der SAP: „Eine Stückliste wird einstufig dargestellt. Sie besteht aus einer Baugruppe als zusammenfassendem (oberen) Objekt und mehreren Komponenten als konstituierenden (unteren) Objekten. Eine Komponente einer Stückliste kann ein Material sein, welches seinerseits durch eine Stückliste beschrieben sein kann. So werden mehrstufige Stücklisten abgebildet. Die Baugruppe einer Stückliste verweist auf mindestens ein Objekt, dessen Aufbau sie beschreibt. Dieses Objekt ist - je nach Stücklistentyp - z.B. ein Werksmaterial, ein Equipment oder ein Dokument. Eine oder mehrere Baugruppen und ihre Komponenten werden in einer Stücklistengruppe zusammengefasst. Eine Stücklistengruppe, die mehrere Baugruppen umfaßt, welche diverse Aufbaumöglichkeiten eines einzigen Objektes angeben, ist eine Mehrfachstückliste. Eine Stücklistengruppe, die mehrere Baugruppen umfaßt, welche den leicht unterschiedlichen Aufbau ähnlicher Objekte angeben, ist eine Variantenstückliste.“ >SAP-PP300, S. 1-5@. Ein Datenmodell findet sich in >SAP-PP300, S. 2-18@.

6.2 Auftragsabwicklung

Abbildung 6.2-5:

Auftragsdurchgang, Teil 5 – Stückliste und Dispositionsvorschlag

173

174

Weiter mit Abbildung 6.2-6

6 Beispiele

Der obige UND-Operator erzwingt nun das Durchlaufen beider Zweige. Zum einen wird die Stückliste in der Auftragsmappe an den Konstrukteur weitergeleitet. Dieser Zweig setzt den Geschäftsprozess dann in Abbildung 6.2-7 fort. Der andere beschreibt die Tätigkeiten bezüglich der zu beschaffenden Teile. Nachdem die Stückliste aufgelöst und die Teile disponiert sind, wird die Dispositionsliste zum Einkauf gegeben. Die anschließenden Funktionen Angebote einholen und Bestellungen tätigen zusammen mit dem diesen Zweig abschließenden Ereignis Auftragsbezogene Teile sind bestellt beschreiben auf sehr hohem Niveau den Beschaffungsvorgang für Kaufteile. Das hohe Niveau wurde hier gewählt, weil diese Vorgänge bei diesem Modellierungsvorgang nicht im Mittelpunkt des Interesses standen. Wie bei einer UND-Verzweigung möglich, wurde hier auf das Zusammenführen der aufgespaltenen Äste verzichtet. Dies bedeutet aber nicht, dass das Ereignis Auftragsbezogene Teile sind bestellt ein Schlussereignis dieser Ereignisgesteuerten Prozesskette ist. Erfahrungsgemäß stecken weitere Optimierungsmöglichkeiten in einer Verkürzung der Transport- und Liegezeiten der Auftragsmappe. Dies könnte erreicht werden durch eine elektronische Fassung dieser Mappe, basierend auf der elektronischen Verwaltung der CAD-Zeichnungen und sonstiger Unterlagen und verbunden mit einem geeigneten Vorgangsbearbeitungssystem.

Exkurs: Angebotseinholung detailliert Die Einholung von Angeboten, die in der Abbildung rechts in eine Funktion gekapselt wurde, ist natürlich tatsächlich in viele einzelne Tätigkeiten unterteilt. Selbst bei einer einfachen Detaillierung lassen sich beispielhaft folgende Schritte unterscheiden: x Schrittweise Abprüfung der Dispositionsliste. x Für jedes Teil prüfen, ob ein geeigneter Lieferant auf der Lieferantenliste vorhanden ist. x Falls ja: bei diesem bestellen. x Falls nein: entsprechende Datenbanken und Unterlagen hinzuziehen. x Mindestens 10 einschlägige Lieferanten anschreiben. x Falls keine Reaktion, nachhaken. x Sobald fünf akzeptable Angebote vorliegen, Entscheidung für einen Lieferatnen fällen, dabei Qualitätskritierien vor Preiskriterien stellen. x Bei diesem bestellen.

6.2 Auftragsabwicklung

Abbildung 6.2-6:

175

Auftragsdurchgang, Teil 6 – Einkauf – „auf hohem Niveau“

176

Weiter mit Abbildung 6.2-7

Eine Funktion mit zwei Bedeutungen

Schlankheit mit Folgen

Vermeidbarer Fehler

6 Beispiele

Die Stückliste ist inzwischen in der Konstruktion eingetroffen. Dort werden nun Zeichnungen gesucht, die für den Auftrag verwendet werden können. Bei dieser Funktion Suche nach ähnlichen Zeichnungen sind auch die verwendeten Informationsquellen angegeben: Auftrag und Auftragsbestätigung, schriftlich festgehaltene Informationen zum Kunden, und die Zeichnungsverwaltung. Im günstigsten Fall wird eine Zeichnung gefunden, die alle Anforderungen abdeckt und keiner Änderung bedarf. Tritt das Ereignis Zeichnung nicht gefunden ein, wird eine mit möglichst wenig Abweichungen gewählt. Die folgende Funktion Klären ob CAD-Zeichnung hat, abhängig vom obigen Entscheidungsprozess, zwei unterschiedliche mögliche Bedeutungen. Falls eine ähnliche Zeichnung gefunden wurde, handelt es sich um die Prüfung, ob die gefundene eine CAD-Zeichnung ist oder nicht. Falls keine gefunden wurde, geht es darum, ob eine CAD-Zeichnung oder eine manuelle Zeichnung erstellt wird. Dieses Zusammenfassen zweier Tätigkeiten in einer Funktion macht die Ereignisgesteuerte Prozesskette „schlanker“, trägt aber nicht zur Übersichtlichkeit bei. Letztendlich kann diese Stelle – so wie sie hier modelliert wurde - ohne die textliche Beschreibung nicht nachvollzogen werden (vgl. die Diskussion dieser Situation und die möglichen Alternativen in Abschnitt 7.1.5). Betrachten wir den ersten Fall, bei dem eine ähnliche Zeichnung gefunden wurde. Damit bedeutet das Ereignis CAD-Zeichnung (Position 3), dass eine CAD-Zeichnung, das Ereignis Manuelle Zeichnung, dass eine manuell erstellte Zeichnung gefunden wurde. Entsprechend werden dann die jeweils nachfolgenden Funktionen angestoßen. Sie bedeuten jetzt, dass die gefundenen Zeichnungen ihrem Typ gemäß überarbeitet werden, entweder mit CAD oder von Hand. Im zweiten Fall (Nicht gefunden) geht es bei der Funktion Klären ob CAD-Zeichnung um die Entscheidung, ob die neu zu erstellende Zeichnung von Hand oder mit dem CAD-System erstellt wird. Auch hier werden dann die entsprechenden Funktionen angestoßen, jetzt allerdings mit der Bedeutung einer Neuerstellung. Dieses Strukturmerkmal wird hier so ausführlich diskutiert, weil es in praktischen Realisierungen von Ereignisgesteuerten Prozessketten sehr oft vorkommt und unbedingt vermieden werden sollte. Insgesamt werden in Abbildung 6.2-7 zwei XODER-Verzweigungen geöffnet, die eine nach der Funktion Suche nach ähnlichen Zeichnungen (Position 1), die andere nach der Funktion Klären ob CAD-Zeichnung (Position 2). Sie werden beide in Abbildung 6.2-8 wieder geschlossen. Die dadurch entstehenden drei Zweige des Kontrollflusses wurden nummeriert, um die Beziehung zur nächsten Abbildung herzustellen.

6.2 Auftragsabwicklung

Abbildung 6.2-7:

177

Auftragsdurchgang, Teil 7 – Manuelle Suche nach ähnlichen Zeichnungen

178

Weiter mit Abbildung 6.2.-8

6 Beispiele

In der folgenden Abbildung 6.2-8 wird zuerst die Aufteilung des Kontrollflusses in 1 und 2 wieder aufgehoben. Nachdem die Zeichnung im CAD erstellt worden ist, wird sie geplottet. Danach werden beide Zweige mit einem XODER (Position 1) zusammengeführt, womit das Ereignis Zeichnung(en) fertig eintritt. Dieser Zweig führt dann gleich zum alles zusammenführenden XODER an Position 1 von Abbildung 6.2-8. D.h., wenn die Zeichnungen fertig sind, können sie in den Pausraum gebracht werden. Wurde dagegen eine Zeichnung gefunden (Zweig 3 von Abbildung 6.2.-7) wird jetzt die Zeichnung (oder die Zeichnungen) mit dem Angebot verglichen. Davor ist noch ein XODER-Operator für einen Rücksprung von einer weiter hinten folgenden Stelle des Geschäftsprozesses. Entsprechen die Zeichnungen voll dem Angebot, werden sie gleich in den Pausraum gebracht. Dies wurde hier durch eine direkte Verbindung mit dem XODER-Operator an Position 1 von Abbildung 6.2-8, unmittelbar vor der Funktion Zeichnung in Pausraum bringen modelliert. Ist die Entsprechung nicht zufriedenstellend, erfolgt wieder eine Prüfung, ob es sich um CAD-Zeichnungen handelt oder nicht. Auch solche einfachen Entscheidungsprozesse müssen als Funktion modelliert werden. Falls es sich um CAD-Zeichnungen handelt, werden diese geändert und geplottet, ganz genau wie oben, falls nicht, werden sie manuell abgeändert. Die Verzweigung durch das XODER an Position 4 wird an Position 5 wieder aufgehoben, das Ereignis Fertig am Beginn von Abbildung 6.28 signalisiert den Abschluss der jeweils davor angeordneten Funktionen.

Tipp: Bedingungen 3 - Genau eine Bedingung muss eintreten. Liegen mehrere Bedingungen vor und muss genau eine eintreten, damit es im Kontrollfluss weitergeht, werden die Bedingungen als Ereignisse formuliert und mit dem exklusiven ODER-Operator verknüpft. Dann werden sie als auslösende Ereignisse mit nachfolgender Funktion oder nachfolgenden Funktionen in die Ereignisgesteuerte Prozesskette integriert. Weitere Tipps: siehe Stichwortverzeichnis.

6.2 Auftragsabwicklung

Abbildung 6.2-8:

Auftragsdurchgang, Teil 8 – Zeichnungen fertig stellen

179

180

Weiter mit Abbildung 6.2-9

Optimierung

6 Beispiele

Damit ist in allen drei Verzweigungen des Kontrollflusses die Situation erreicht, dass die Zeichnungen in den Pausraum gebracht werden können, sodass auch der Kontrollfluss wiederum durch ein XODER zusammengeführt wird (Position 1). Die Zeichnungen werden dann (nicht-elektronisch) in den Pausraum transportiert. Dort werden sie, je nach benötigter Anzahl, vervielfältigt. Anschließend werden sie geschnitten und gefaltet. Die CAD-Zeichnungen und die manuell erstellten werden am Rand beschnitten. Da für beide Zeichnungsarten der Kontrollfluss im weiteren einen identischen Verlauf hat, werden diese beiden Zweige mithilfe eines UND-Operators gleich wieder zusammengeführt. Das EPK-Fragment von Abbildung 6.2-9 endet somit mit zwei Kontrollflusszweigen und den Ereignissen Pausen geschnitten und Originale geschnitten. Am rechten Rand ist die Pfeillinie für den Rücksprung von Abbildung 6.2-12 nach Abbildung 6.2-8 angegeben. Alle diese Schritte, wie auch noch einige die im Folgenden angegeben werden, würden bei einer elektronischen Archivierung und Verwaltung wegfallen. Um dieses Optimierungspotenzial deutlich zu machen, geht die Beschreibung hier so in’s Detail.

Tipp: Bedingungen 4 - Mindestens eine Bedingungen muss eintreten. Liegen mehrere Bedingungen vor und muss mindestens eine eintreten, damit es im Kontrollfluss weitergeht, werden die Bedingungen als Ereignisse formuliert und mit dem ODER-Operator verknüpft. Dann werden sie als auslösende Ereignisse mit nachfolgender Funktion oder nachfolgenden Funktionen in die Ereignisgesteuerte Prozesskette integriert. Weitere Tipps: siehe Stichwortverzeichnis.

6.2 Auftragsabwicklung

Abbildung 6.2-9:

Auftragsdurchgang, Teil 9 – Pausen und Schneiden

181

182

Weiter mit Abbildung 6.2-10

6 Beispiele

Im nächsten Schritt werden die Originale in ein Ablagefach gelegt, von wo sie einmal täglich in zentrale Zeichnungsschränke einsortiert werden. Das hier und im anderen Zweig angegebene Informationsobjekt Formate betrifft die Zeichnungsformate. Die Zeichnungen wie auch die Pausen werden nach Formaten getrennt abgelegt. Damit endet der rechte Kontrollflusszweig, wobei es sich aber nicht um ein Schlussereignis handelt. Auf ein Zusammenführen der Zweige wurde wieder verzichtet, was bei einem UND-Operator möglich ist (vgl. Abbildung 5.5). Nun zum linken Kontrollflusszweig von Abbildung 6.2-10. Die Pausen werden ebenfalls abgelegt. Bei der eigentlichen Konstruktion und durch die Abteilung Konstruktion werden dann die benötigten Pausen aus der Ablage herausgesucht und an den Vertrieb weitergeleitet. Alle diese Tätigkeiten stehen in sequenzieller Abfolge und werden deshalb entsprechend modelliert.

Tipp: Bedingungen 5 - Neben dem eigentlichen Kontrollfluss Müssen Bedingungen eingebunden werden, die „neben“ dem eigentlichen Kontrollfluss liegen, z.B. als externe, zeitliche oder sonstige Ereignisse, werden sie mit einem UNDOperator in den Kontrollfluss eingebunden. Dies bedeutet dann, dass es hier „nur weiter geht“, wenn die Bedingungen entsprechend dem Operator, mit dem sie verknüpft sind, eingetreten sind. Weitere Tipps: siehe Stichwortverzeichnis.

6.2 Auftragsabwicklung

Abbildung 6.2-10:

183

Auftragsdurchgang, Teil 10 – Einsortieren und Weiterleiten Weiter mit Abbildung 6.2-11

184

6 Beispiele

Der nächste Schritt besteht nun darin, die Zeichnungen mit entsprechenden Begleitschreiben zum Kunden zu senden. Wenn dies geschehen ist, muss auf die Reaktion des Kunden gewartet werden. Die Reaktion des Kunden erfolgt bei diesem Unternehmen so, dass entweder der Kunde den Auftrag telefonisch erteilt (nur bei gut bekannten Kunden) oder schriftlich. Selbstverständlich kommt es auch vor, dass der Auftrag nicht erteilt wird. Da es sich hier um echte Alternativen handelt, wurden diese möglichen Ergebnisse der Wartefunktion mit einem XODER modelliert. Im Falle der telefonischen Auftragserteilung wird eine Notiz zu dem Gespräch erstellt und in die Auftragsmappe genommen. Bei einer schriftlichen Genehmigung werden die zurückgesandten Zeichnungen und der Auftrag in die Konstruktion weitergeleitet. Dort werden beide der Auftragsmappe beigefügt.

Tipp: Transport und Liegezeiten materieller Informationsobjekte Der Transport von materiellen Informationsobjekten (z.B., wie im Geschäftsprozess dieses Abschnitts, einer Unterlagenmappe zum Fertigungsauftrag) sollte immer modelliert werden, da er ja Aufwand darstellt und immer auch Optimierungspotenziale aufzeigt (durch eine Verkürzung der Liege- und Transportzeiten). Erweiterung der Notation Da es hierbei keinen Schreib- oder Lesevorgang gibt, wurde hier vorgeschlagen, die Anbindung des entsprechenden Informationsobjekts an die jeweilige Funktion, die den Transportvorgang startet, ungerichtet vorzunehmen. Liegt ein Transport immatrieller Informationsobjekte (digitalisierte Geschäftsobjekte, z.B. CAD-Zeichnungen, Computerprogramme, Tagesordnungen, usw.) vor, sollte dieser ebenfalls sorgfältig modelliert werden. Weitere Tipps: siehe Stichwortverzeichnis.

6.2 Auftragsabwicklung

Abbildung 6.2-11:

Auftragsdurchgang, Teil 11 – Warten auf Auftragseingang

185

186

Weiter mit Abbildung 6.2-12

Ein weiteres Schlussereignis

Optimierung

6 Beispiele

Wird der Auftrag nicht erteilt, versuchen Mitarbeiter aus Vertrieb und Konstruktion durch Gespräche mit dem Kunden den Auftrag doch noch zu retten. Dieses Nachhaken wurde hier nicht weiter detailliert (vgl. dazu das Beispiel in Abschnitt 6.1), sondern als eine einzelne Funktion modelliert mit den beteiligten Organisationseinheiten und den Ergebnisereignissen Keine Einigung möglich bzw. Einigung erzielt58. Meist geht es bei diesem Einigungsvorgang um das Produkt, weshalb dann auch die Zeichnungen geändert werden müssen. Konkret wird im Fall der Einigung die Auftragsbestätigung geändert (durch den Vertrieb) und in die Konstruktion geleitet. Anschließend erfolgt ein Rücksprung, der hier bis zur Abbildung 6.2.-8 führt zum XODER-Operator an der dortigen Position 2 vor die Funktion Zeichnungen(en) mit Angebot vergleichen, denn jetzt muss der ganze nachfolgende Zweig nochmals durchlaufen werden. Konnte beim Nachhaken keine Einigung erzielt werden, wird die Auftragsmappe an den Vertrieb geleitet. Dieser formuliert die Auftragsablehnung und vermerkt sie in der Kundendatei. Das Ereignis Auftrag abgelehnt signalisiert dann ein weiteres mögliches Schlussereignis dieser Ereignisgesteuerten Prozesskette. Bleibt noch der linke Zweig, der den von vorneherein positiven Fall der Auftragsvergabe beschreibt. Hier werden nun die für die Fertigung benötigten Zeichnungen (Fertigungszeichnungen) festgelegt. Anschließend wird nach vorhandenen Zeichnungen gesucht, die diesen entsprechen. Diese Suche kann sich recht aufwändig gestalten, da die Zeichnungen physisch abgelegt sind und von Hand gesucht werden müssen. Eine effizient gestaltete Archivierung könnte hier wiederum deutliche Verbesserungen mit sich bringen, nicht nur in der Geschwindigkeit des Suchvorgangs sondern auch in der Zahl und der Qualität der „Treffer“. Letzteres bedeutet, dass „ähnlichere“ Zeichnungen gefunden werden könnten.

58

Dieses Beispiel, wie auch die Angebotserstellung zu Beginn, geben einen Eindruck davon, was mit unterschiedlichem Detaillierungsgrad bei der Modellierung eines Geschäftsprozesses gemeint ist. Dies zeigt aber auch, dass bei zu wenig Detaillierung unter Umständen Optimierungspotenziale unerkannt bleiben.

6.2 Auftragsabwicklung

Abbildung 6.2-12:

Auftragsdurchgang, Teil 12 – Eventuelles Scheitern

187

188

Weiter mit Abbildung 6.2-13

6 Beispiele

Die Suche nach den benötigten Zeichnungen führt nun entweder zum Erfolg oder nicht. Abbildung 6.2-13 zeigt die Situation, falls die Zeichnungen nicht gefunden wurden. Ähnlich wie weiter oben (vgl. Abbildung 6.2-7) muss entschieden werden, welche der fehlenden Zeichnungen manuell und welche mithilfe des CAD-Systems erstellt werden. Wesentliches Kriterium für die Entscheidung ist die Auslastung des CAD-Systems. Da auf jeden Fall Zeichnungen erstellt werden, es aber nicht so ist, dass immer von Hand und mit dem CAD-System erstellt wird, sondern auch z.B. nur von Hand oder nur mit dem CAD-System, ist der ODEROperator hier berechtigt. Auf diese Weise wird hier ohne Wiederholungsschleife das Problem gelöst, dass mehrere Zeichnungen unterschiedlichen Typs erstellt werden müssen. Die manuell erstellten Zeichnungen sind dann auch gleich fertig. Bei CAD-Zeichnungen wurde der Vorgang wie oben in die eigentliche Erstellung und das Plotten aufgeteilt. Danach sind diese Zeichnungen ebenfalls fertig, weshalb der Kontrollfluss hier wieder zusammengeführt wurde.

Tipp: Informationsweitergabe in Ereignisgesteuerten Prozessketten Die Informationsweitergabe in Geschäftsprozessen erfolgt auf vielfältige Weise, z.B. beim Mittagessen in der Kantine oder beim Golfen am Wochenende. In Ereignisgesteuerten Prozessketten werden aber nur formelle Informationen erfasst, und zwar als Informationsobjekte. Die Weitergabe solcher Informationen kann nur so modelliert werden, dass an der einen Stelle in ein Informationsobjekt geschrieben (z.B. neue Ergebnisse der Lieferantenbeurteilung) und an einer anderen aus ihm gelesen wird (z.B. wenn eine Woche später wieder ein Lieferant gesucht wird). Weitere Tipps: siehe Stichwortverzeichnis.

6.2 Auftragsabwicklung

Abbildung 6.2-13:

Auftragsdurchgang, Teil 13 – Zeichnungen erstellen

189

190

Weiter mit Abbildung 6.2-14

Optimierungspotenzial

6 Beispiele

Die folgende Abbildung zeigt die Vorgehensweise, falls Zeichnungen gefunden wurden. Mit der Funktion Zeichnungen(en) auf Anforderungen prüfen wird geprüft, ob sie den Anforderungen in vollem Umfang genügen. Falls dies nicht der Fall ist, wird geprüft, ob die Arbeiten mithilfe des CAD-Systems getätigt werden müssen. Falls nein, werden sie manuell geändert, falls ja, mithilfe des CAD-Systems und anschließend geplottet. Ist dies geschehen, sind die Zeichnungen fertig, was mithilfe eines entsprechenden Ereignisses angedeutet wird. Am unteren Ende der Zeichnung werden dann alle drei Zweige, die sich aus der Suche nach den für den Auftrag benötigten Zeichnungen ergaben, wieder zusammengeführt. Ein riesiges Optimierungspotenzial steckt in der Überwindung wiederholter Prüfungen. Dies zeigen viele reale Geschäftsprozesse, wie im Übrigen auch der Geschäftsprozess von Abschnitt 6.1. Hinter diesen wiederholten Prüfungen steckt in Wirklichkeit ein stufenweises Erledigen eines Vorgangs durch dieselben oder verschiedene Personen. Dies ist eigentlich nur bei kreativen oder sehr komplexen Vorgängen vertretbar. Oftmals verbergen sich dahinter allerdings auch Kontrollmechanismen. Bei beidem muss überlegt werden, ob die stufenweise Erledigung wirklich nötig ist. Falls nicht, sollte der Vorgang an einer Stelle und zu einem Zeitpunkt erledigt werden, auch wenn dies eine andere Arbeitsteilung bzw. andere Qualifikationsprofile bei den Prozesspartizipanten nötig machen sollte. Sind – umgekehrt – Kontrollmechanismen gewünscht, muss dies natürlich auch deutlich modelliert werden. Erstaunlicherweise geschieht dies recht selten in den Beschreibungen realer Geschäftsprozesse.

Tipp: Ereignisraum Der Ereignisraum eines Unternehmens soll die Gesamtheit der für die Geschäftsprozesse eines Unternehmens bedeutsamen Ereignisse beschreiben. Er muss sorgfältig analysiert werden. Die meisten dieser Ereignisse fallen intern an, nicht wenige aber in der Unternehmensumwelt. Z.B. durch die Gesetzgebung (gesetzliche Änderung der Lohnfortzahlung), durch Vorschriften (Ausfuhrbestimmungen) oder natürlich bei Lieferanten (Preiserhöhungen, Produktänderungen) und Kunden (Lieferbedingungen, Rechnungsstellung). Weitere Tipps: siehe Stichwortverzeichnis.

6.2 Auftragsabwicklung

Abbildung 6.2-14:

191

Auftragsdurchgang, Teil 14 – Zeichnungen erstellen

Die Zeichnungen werden nun – identisch wie oben (vgl. Abbildung 6.2-9) in den Pausraum gebracht, gepaust und dann geschnitten. Auch hier erfolgte wieder eine sehr detaillierte Beschreibung, um die diesbezüglichen Optimierungspotenziale aufzudecken.

Weiter mit Abbildung 6.2-15

192

6 Beispiele

Abbildung 6.2-15: Weiter mit Abbildung 6.2-16

Auftragsdurchgang, Teil 15 – Pausen und Schneiden

Im Folgenden werden die Originale abgelegt und in die Zeichnungsschränke einsortiert. Das Ereignis Originale einsortiert ist kein Schlussereignis, sondern nur eines der Enden einer UND-Verzweigung.

6.2 Auftragsabwicklung

193

Das Schneiden der Pausen von Abbildung 6.2-15 wird hier im linken Zweig fortgesetzt. Die vervielfältigten Pausen werden in die zentralen Ablagekästen einsortiert. Dies wird noch durch Mitarbeiter der Druckerei erledigt. Im nächsten Schritt suchen Mitarbeiter der Konstruktion die im weiteren benötigten Pausen heraus und leiten sie an den Vertrieb weiter.

Abbildung 6.2-16:

Auftragsdurchgang, Teil 16 – Ablegen und Weiterleiten

Die Ereignisgesteuerte Prozesskette schreitet dann in Abbildung 6.2-17 weiter mit der Kontrolle der Stückliste durch die Konstruktion. Als Informationsgrundlage dienen hier die Auftragsbestätigung, Zeichnungen und Normen. Falls nötig, wird die Stückliste berichtigt und ergänzt. Anschließend wird die Auftragsmappe mit Stückliste und Zeichnungen weitergeleitet an die Arbeitsvorbereitung (AV).

Weiter mit Abbildung 6.2-17

194

6 Beispiele

Abbildung 6.2-17:

Auftragsdurchgang, Teil 17 – Arbeitspläne und Bedarfsauflösung

Ist dies geschehen, werden von der Stücklistenerfassung in der Abteilung Arbeitsvorbereitung die Stücklisten durch Abschreiben in das PPS-System übertragen.

6.2 Auftragsabwicklung

195

Hier tritt ein Medienbruch klar zu Tage. Bei einer Neukonzeption dieses Geschäftsprozesses müsste über ein geeignetes Integrationskonzept ein solches Defizit beseitigt werden. Danach werden zwei Funktionen angestoßen. Zum einen werden die Arbeitspläne durch die Arbeitsvorbereitung erstellt, zum anderen werden die fehlenden Teile disponiert. Die Arbeitspläne betreffen die Eigenfertigung, d.h. die Teile, die im Unternehmen selbst erstellt werden. Als informationelle Grundlage dienen die Zeichnungen, die geplanten Termine und die zur Verfügung stehenden Kapazitäten. Die Disposition wird durch die gleichnamige Abteilung auf der Basis der Auftragsunterlagen, der Liefertermine und der Teilebeschreibungen vorgenommen. Nachdem die Arbeitspläne erstellt sind, werden die Fertigungsaufträge erstellt und eingeplant, die Arbeitspapiere gedruckt und die Fertigungsaufträge den Mitarbeitern in der Fertigung zugeleitet. Dort sorgen die Vorarbeiter für ihre Verteilung. Das Ergebnis dieser Verteilung läßt sich in die zwei Ereignisse Blechteile bei Laserprogrammierung und Andere Teile in Einzelfertigung fassen. Der UND-Operator deutet an, dass in der Regel beide Teilearten vorkommen, sonst könnte mit einem ODEROperator und einem vorgeschalteten Sortiervorgang modelliert werden. Der andere Zweig in Abbildung 6.2-18 zeigt den weiteren Weg bei der Beschaffung. Die Dispositionsliste wird an den Einkauf weitergeleitet. Dort werden dann die benötigten Angebote eingeholt. Hier wurde ein Prozesswegweiser eingefügt, der auf den entsprechenden Subprozess verweist.

Tipp: Keine Zeitspanne modellieren Eine bedeutende Fehlerquelle bei der Erstellung von Ereignisgesteuerten Prozessketten ist, dass oft versucht wird, alle Durchgänge eines Geschäftsprozesses einer ganzen Zeitspanne in eine Ereignisgesteuerte Prozesskette hinein zu modellieren. Also z.B. alle Beschaffungsvorgänge eines Jahres auf einmal und nicht jeden einzeln. Dies führt zu sehr komplizierten und kaum mehr beherrschbaren Ereignisgesteuerten Prozessketten mit vielen Rücksprüngen, Verzweigungen und Verschachtelungen. Besonders oft wird dieser Fehler gemacht, wenn sich der Geschäftsprozess über eine lange Zeit hinzieht, z.B. bei Einstellungsverfahren. Doch auch hier gilt: nicht alle Einstellungsverfahren, sondern jeder Einzelne wird in einer einzelnen Ereignisgesteuerten Prozesskette modelliert. Weitere Tipps: siehe Stichwortverzeichnis.

Medienbruch

Weiter mit Abbildung 6.2-18

196

6 Beispiele

Abbildung 6.2-18:

Auftragsdurchgang, Teil 18- Verteilen der Aufträge und Beschaffung

6.2 Auftragsabwicklung

Exkurs: Prozesswegweiser in der Praxis Der eingefügte Subprozess Angebotseinholung hat als Startereignis Dispositionsliste im Einkauf und als Schlussereignis Angebote sind da. Letzteres wird dann gleich zum Startereignis des nächsten eingefügten Subprozesses. Konkret ergibt sich die Situation in den beiden Subprozessen wie folgt:

Abbildung Exkurs:

Eingefügte Subprozesse und ihre Realisierung als Ereignisgesteuerte Prozesskette

Gleiches gilt für die Lieferungsüberwachung. Durch diese Subprozesse nimmt hier der Detaillierungsgrad der Modellierung stark ab, indem durch Prozesswegweiser auf wich-

197

Syntaxhinweis

198

6 Beispiele

tige Teilgeschäftsprozesse verwiesen wird, die aber nicht angegeben werden. Die Aussparung dieser Abschnitte erfolgte hier vor allem wegen dem schon erwähnten Optimierungsschwerpunkt und auch deshalb, weil hier ein Gesamtüberblick über die Auftragsabwicklung gewonnen werden soll. Weiter mit Abbildung 6.2-19

Das Ganze und seine Teile

In Abbildung 6.2-18 teilte sich der Kontrollfluss in drei Zweige auf. Der Erste betrifft die Laserprogrammierung für die Blechteile. Hier wird nun im Folgenden geprüft, welche der Blechteile früher schon programmiert wurden und welche nicht. Die noch nicht früher programmierten werden dann mit dem Programmiersystem gezeichnet. Anschließend wird ein Prozessorlauf durchgeführt. Für die früher schon einmal gefertigten werden die Unterlagen herausgesucht. Ist dies geschehen vereinigen sich diese beiden Zweige wieder und es wird die Funktion Auftragspapiere zur Laseranlage leiten angestoßen. Der ODER-Operator ist hier angemessen, da von vorneherein nicht absehbar ist, ob es noch nie gefertigte bzw. schon mal gefertigte Teile geben wird oder ob alle Teile schon mal gefertigt wurden oder gar keine des aktuellen Auftrags. Es handelt sich hier um eine Situation wo das Ganze (der Gesamtauftrag) vorübergehend in verschiedene Teile aufgeteilt und unterschiedlich behandelt. Der zweite Zweig betrifft die Einzelfertigung (drehen, fräsen, usw.). Sie wurde in einer Funktion zusammengefasst. Ist sie durchgeführt, werden die Teile in das Lager transportiert. Im dritten Zweig ist der Transport der Kaufteile in’s Lager modelliert. Die letzten beiden Zweige werden dann wieder zusammengeführt, da die Erledigung beider Funktionen durch das Ereignis Teile im Lager signalisiert wird. Damit sind dann alle benötigten Teile im Lager und können zu den einzelnen Aufträgen sortiert werden.

6.2 Auftragsabwicklung

Abbildung 6.2-19:

Auftragsdurchgang, Teil 19 – Fertigung

199

200

Weiter mit Abbildung 6.2-20

Weiter mit Abbildung 6.2.-21

6 Beispiele

Die folgende Abbildung 6.2-20 zeigt die weitere Fertigung und die Einbindung der Kaufteile. Die Blechteile werden gelasert, anschließend gebogen, gekantet, geschweißt, gewaschen und poliert. Der danach folgende UND-Operator fügt die beiden Zweige wieder zusammen. Hier ist der UND-Operator angemessen, weil der rechte Zweig letztendlich auf die UND-Operatoren von Abbildung 6.2-17 und 6.2-18 zurückgeht. Es ist aber auch inhaltlich ableitbar. Da es auf jeden Fall einzelgefertigte Teile und/oder Kaufteile gibt, müssen an der diskutierten Verknüpfung in einem konkreten Durchgang durch den Geschäftsprozess beide Zweige aktiv werden, weshalb bei der Zusammenführung der Operator UND richtig ist. Nach diesem Operator ist der Kontrollfluss dieser Auftragsbearbeitung wieder in einem Zweig konzentriert. Die Teile werden nun zur Montage transportiert. In der Montage werden die Schweißteile zusammengesetzt, teilweise Befestigungen angebracht und verrohrt. Anschließend werden die Teile wieder demontiert und alle elektronischen Komponenten wieder entfernt. Diese Tätigkeiten werden in der Funktion Auftrag vormontieren und zerlegen erfasst. Im nächsten Schritt erfolgt der Transport der nichtelektrischen Teile zur Pulverbeschichtung und der elektrischen zur Lackiererei. Nach erfolgter Lackierung bzw. Pulverbeschichtung werden alle Teile zur Montage zurücktransportiert. Die Verzweigung durch einen UND-Operator in Abbildung 6.2-22 bedeutet nicht unbedingt, dass die Arbeiten parallel erledigt werden müssen. Sie bedeuten aber, dass die Funktionen beider Zweige erledigt sein müssen, bevor der Kontrollfluss über das untere UND weitergeht, ganz im Sinne von Abschnitt 5.4.

Tipp: Modellierung von Teilaufgaben - mit und ohne Reihenfolge Zu erledigende Teilaufgaben werden durch eine Funktion, die alle Teilaufgaben enthält, und nachfolgende Ereignisse modelliert. Die nachfolgenden Ereignisse geben je eine Teilaufgabe an und werden durch UND verknüpft. Dies gilt, wenn die Teilaufgaben nicht in einer bestimmten Reihenfolge zu erledigen sind. Liegt eine solche vor, müssen für jede Teilaufgabe Funktionen und diese nacheinander in den Kontrollfluss eingefügt werden. Weitere Tipps: siehe Stichwortverzeichnis.

6.2 Auftragsabwicklung

Abbildung 6.2-20:

201

Auftragsdurchgang, Teil 20 – Verteilen der Aufträge und Beschaffung

202

6 Beispiele

Abbildung 6.2-21: Weiter mit Abbildung 6.2-22

Auftragsdurchgang, Teil 21 – Verteilen der Aufträge und Beschaffung

Nachdem die Teile in der Montage angekommen sind, erfolgen Montage und Versand. Diese wurden modelltechnisch in einen Subprozess verlegt, der ab Abbildung 6.2-23 beschrieben wird. Die drei Ereignisse nach dem Prozesswegweiser geben, der Syntax von Ereignisgesteuerten Prozessketten entsprechend an, wie der Subprozess endet: mit dem Verpacken der Anlage, dem Hinzufügen der Versandpapiere zur Anlage und dem Kopieren der Dokumente.

6.2 Auftragsabwicklung

203

Anschließend wird zum einen die Anlage versandt, was zu einem der Schlussereignisse dieses Geschäftsprozesses führt (Anlage versandt), zum anderen wird der Subprozess Rechnungsüberwachung angestoßen, der hier allerdings nicht dargestellt wird.

Abbildung 6.2-22:

Ein Schlussereignis

Auftragsdurchgang, Teil 22 – Verteilen der Aufträge und Beschaffung

In den folgenden Abbildungen wird nun der Subprozess Montage und Versand beschrieben. Es handelt sich um einen eingefügten Subprozess (vgl. die Anmerkungen zu Prozesswegweisern in Abschnitt 4.7). Er beginnt mit einem Prozesswegweiser, der angibt, von welchem Prozess der Aufruf kommt. Danach wird, der Syntax entsprechend, das Ereignis des aufrufenden Geschäftsprozesses wiederholt, nach dem der Aufruf des Subprozesses erfolgte. Hier startet dann anschließend die Funktion Anlage fertig montieren. Bei deren Abwicklung treten entweder Probleme auf oder nicht, was durch ein XODER und entsprechende Ereignisse modelliert wurde. Probleme können z.B. Kollisionen von Bauteilen oder maßliche Differenzen sein.

Weiter mit Abbildung 6.2-23

204

6 Beispiele

Abbildung 6.2-23:

Subprozess Montage und Versand, Teil 1 – Problemlöser suchen

6.2 Auftragsabwicklung

205

Der eigentliche Montagevorgang wird nicht modelliert. Dies ist bei einer Einzelfertigung auch nicht sinnvoll und kaum möglich, da der Ablauf für jedes Produkt ein anderer ist. Bei Problemen muss der Monteur seinen vorgesetzten Meister zurate ziehen. Da sich dies in derselben Organisationseinheit abspielt, ist die Angabe der Organisationseinheit bei dieser Funktion nicht nötig. Hätten diese Interaktionen Bedeutung für das Optimierungsvorhaben, müsste an einer solchen Stelle die Beschreibung der Organisationseinheiten detaillierter erfolgen. Genauso beim nächsten Schritt. Das Handeln des zu Hilfe gerufenen Meisters führt entweder dazu, dass er die Probleme löst oder nicht. Falls nicht, wird der Konstrukteur befragt. Die Ereignisgesteuerte Prozesskette hat sich damit in drei Äste verzweigt, die in der nächsten Abbildung weitergeführt werden. Dort ist die Auflösung der Problemsituation angegeben. Der Konstrukteur definiert die notwendigen Änderungen, die der Monteur dann durchführt. Letzterer muss außerdem die Änderungen durch Vermerke in den Zeichnungen und Stücklisten dokumentieren.

Tipp: Verknüpfung über Ereignisraum Wie die Beispiele zeigen, werden verschiedene Geschäftsprozesse als Ereignisgesteuerte Prozessketten über Prozesswegweiser oder Ereignisse des Ereignisraumes verknüpft. Letztgenannte Möglichkeit schafft zwar einfachere Modelle, führt aber insgesamt zu unübersichtlicheren Darstellungen und sollte daher nur mit Vorsicht eingesetzt werden. Denn nach außen hin stehen bei diesem Vorgehen mehrere Ereignisgesteuerte Prozessketten nebeneinander, die nicht erkennbar verknüpft sind. Oft kann die von den Modellierern angedachte Verknüpfung nur über die ergänzende textliche Beschreibung entdeckt werden. Eine praktikable und pragmatische Lösung besteht darin, bei Verwendung der Ereignisverknüpfung einen Hinweis beim jeweiligen Startereignis anzubringen. Weitere Tipps: siehe Stichwortverzeichnis.

Weiter mit Abbildung 6.2.-24

206

6 Beispiele

Abbildung 6.2-24:

Weiter mit Abbildung 6.2-25

Subprozess Montage und Versand, Teil 2 – Probleme sind gelöst, Vermerke sind gemacht

Die drei Zweige Kein Problem, Problemlösung durch Meister und Problemlösung durch Konstrukteur werden dann mittels eines XODER-Operators wieder zusammengeführt. Verfolgen wir im weiteren zuerst den Zweig, der von der Problemlösung herrührt. Die Anlage wird fertig montiert und anschließend in die Elektrowerkstatt transportiert. Dort werden dann noch die elektrischen Teile montiert. Da nun die Organisationseinheit wechselt, muss dies bei der Funktion auch angegeben werden.

6.2 Auftragsabwicklung

Abbildung 6.2-25:

207

Subprozess Montage und Versand, Teil 3 – Elektrische Teile montieren und Änderungen vermerken

Der andere Zweig, bei dem zuletzt die durchgeführten Änderungen in den Zeichnungen und in der Stückliste vermerkt wurden, verzweigt wieder, weil zwei Funktionen angestoßen werden: Zum einen wird die Stückliste an die Arbeitsvorbereitung, zum anderen die Zeichnungen an den Konstrukteur weitergeleitet. Die Stückliste wird dann in der Arbeitsvorbereitung berichtigt, die Zeichnungen vom Konstrukteur auf den aktuellen Stand gebracht. Danach wird der Kontrollfluss wieder zusammengeführt. Zwischen diesen beiden UND-Operatoren liegen Abschnitte, die nicht nur im selben Zeitfenster liegen (vgl. Abschnitt 5.4), sondern die tatsächlich parallel ablaufen. Im Anschluss daran werden alle Unterlagen an die Dokumentation weitergeleitet.

208

Optimierungspotenzial

Weiter mit Abbildung 6.2-26

6 Beispiele

Dieser Ausschnitt zeigt eine auch methodisch interessante Stelle, weil hier das Weiterleiten von Unterlagen sehr ausführlich modelliert wird. Dies muss nicht so sein, sondern ist Ausdruck des hier gewünschten hohen Detaillierungsgrades, da auch diesbezüglich Optimierungspotenziale zu vermuten sind. Die nächste Abbildung zeigt den Abschluss dieses Subprozesses. Betrachten wir zuerst das Geschehen in der Dokumentation (rechter Zweig). Dort werden die Ersatzteilzeichnungen und –listen erstellt. Hierzu muss u.a. auf die Stückliste im PPS-System zugegriffen werden. Die Auftragsbestätigung wird benötigt, weil dort die Art der zu erstellenden Dokumentation festgehalten ist. Anschließend werden die erstellten Dokumente kopiert. Der andere linke Zweig betrifft die erstellte Anlage selbst. Die erste Funktion erfasst den Tatbestand, dass sie zum Versand transportiert wird. Ist dies geschehen, werden drei Funktionen angestoßen, Anlage verpacken, Versandpapiere erstellen und Rechnung schreiben. Die Erledigung von Versandpapiere erstellen stößt dann die Funktion Versandpapiere zu Anlage geben an. Sind dann alle drei Zweige abgearbeitet, wird der Kontrollfluss mittels eines UND-Operators wieder zusammengeführt. Danach erfolgt, wieder mit einem UND-Operator, das Zusammenführen der restlichen beiden Kontrollflüsse. Der UND-Operator ist auch hier richtig, wie ein Blick auf Abbildung 6.2.-24 zeigt (Aufspaltung nach der Funktion Monteur führt Änderungen durch.) Im Anschluss wird dann in den übergeordneten Prozess Auftragsabwicklung „zurückgesprungen“. Hier wird die oben schon angesprochene unterschiedliche Funktion von Prozesswegweisern deutlich. Bei einem eingefügten Subprozess59 geben beide Prozesswegweiser, am Anfang und am Ende, an, von wo der „Aufruf“ kam. Der am Ende eines Zweiges gibt dann sozusagen an, wohin der „Rücksprung“ zu erfolgen hat (vgl. Abschnitt 4.7). Dieser Subprozess zeigt nochmals die Syntax für eingefügte Subprozesse. Die in Abbildung 6.2-26 vor dem rückverweisenden Prozesswegweiser liegenden Ereignisse Anlage verpackt, Rechnung verschickt und Dokumente kopiert werden im aufrufenden Prozess (vgl. Abbildung 6.221) nach dem Prozesswegweiser wiederholt. Auf diese Weise ist die Verbindung bzw. mögliche Kopplung der beiden Ereignisgesteuerten Prozessketten präzise festgelegt.

59

Damit ist ein Subprozess gemeint, der im übergeordneten Geschäftsprozess nicht am Ende eines Kontrollflusszweiges steht, sondern mitten drin, nach dem also der Geschäftsprozess unmittelbar mit einem Ereignis fortgesetzt wird (vgl. Abschnitt 4.5).

6.2 Auftragsabwicklung

Abbildung 6.2-26:

Subprozess Montage und Versand, Teil 4 – Versenden, verpacken und dokumentieren

209

210

6.3

6 Beispiele

Angebotserstellung im Anlagenbau

Dieser Geschäftsprozess wurde bereits in Abschnitt 2.9 in textlicher Form vorgestellt. Hier soll nun gezeigt werden, wie dieser Text in eine erweiterte Ereignisgesteuerte Prozesskette umgesetzt werden kann.

Anmerkung Die folgende Ereignisgesteuerte Prozesskette wird zum einen durch die textliche Originalbeschreibung, zum anderen durch Anmerkungen des Verfassers erläutert. Dabei ist der Originaltext eingerückt. Um die Bezüge zwischen textlicher Beschreibung und Abbildungen einfacher herstellen zu können, wurden in die Abbildungen Nummern eingefügt, auf die im Text verwiesen wird. Es handelt sich um eine Angebotserstellung in einem Unternehmen des Anlagenbaus. Start

Los geht’s mit Abbildung 6.3-1

Gestartet wird der Geschäftsprozess aufgrund einer Kundenanfrage. Diese kann mündlich, per Post, per Telefon, per Telefax, per E-Mail oder auf einem anderen akzeptierten Weg eingehen. Nach Eingang der Anfrage wird sie an den zuständigen Vertriebsbereichsleiter geleitet, der sie an einen seiner Vertriebsingenieure weitergibt. Dieser Text beschreibt das Startszenario des Geschäftsprozesses. Aufgrund der meist engen Beziehungen zu den Kunden sind hier auch ansonsten für die Auftragsvergabe eher unübliche Kommunikationsformen (vgl. Position 1 in der folgenden Abbildung) möglich, z.B. E-Mail. Zwei weitere Funktionen sind im Text angedeutet und in der Grafik angelegt. Bei der Ersten, Weiterleiten an Vertriebsbereichsleiter, fehlt die Angabe der Organisationseinheit, bei der Zweiten (Position 2) ist sie dann klar. Die Weiterleitung der Anfrage (ein Transportvorgang) wurde hier explizit modelliert. Die Anfrage des Kunden stellt ein Geschäftsobjekt (Business Object) dar.

Informationsobjekte, die transportiert werden Die Situation des Informationsobjekts Anfrage ist hier so, dass es weder gelesen noch beschrieben, aber transportiert wird. Deshalb ist eine Pfeilrichtung unsinnig und wird weggelassen (Position 3). Dies ist in der klassischen Notation nicht vorgesehen, stellt also eine Erweiterung der Notation dar.

6.3 Angebotserstellung im Anlagenbau

Abbildung 6.3-1:

211

Angebotserstellung für Anlagen, Teil 1 – Klärung offener Fragen oder frühes Ende

Der Vertriebsingenieur60 prüft die Angebotsrealisierbarkeit. Dies betrifft zunächst das angefragte Leistungsspektrum. Liegt dieses nicht innerhalb des Leistungsspektrums des Unternehmens, erfolgt eine Absage. Hieraus entsteht eine Funktion mit drei Ergebnisereignissen, die durch ein exklusives ODER verknüpft sind (vgl. die folgende Abbildung). Nach dem Ereignis Nicht realisierbar (Position 3) kann dann gleich eine Funktion folgen, in der die Absage formuliert wird. Daraus ergibt sich dann ein erstes Schlussereignis Anfrage abgelehnt.

60

Es kann sich selbstverständlich auch um eine Vertriebsingenieurin handeln.

Weiter mit Abbildung 6.3-2

212

6 Beispiele

Können nur Teile der angefragten Leistungen erbracht werden, werden Partnerunternehmen um Unterstützung angefragt und entweder als Kooperationspartner oder Subunternehmer eingebunden.

Abbildung 6.3-2:

Angebotserstellung für Anlagen, Teil 2

Dies führt zum entsprechenden Ereignis (Position 1 in Abbildung 6.3-2) und zu einer Funktion Partnerunternehmen anfragen. Es wird zwar im Text nicht ausgeführt (wohl weil in der Regel der positive Fall eintritt), aber natürlich kann diese Funktion u.U. auch zu einem negativen Ergebnis führen, weshalb hier die beiden Ereignisse Partner gefunden und Kei-

6.3 Angebotserstellung im Anlagenbau

213

ne Partner gefunden eingefügt wurden (Position 4). Nach dem letztgenannten wurde dann wieder eine Schlusssequenz angefügt. Somit bleiben in der Abbildung 6.3-2 zwei weiterführende Kontrollflusszweige, die beide den erfolgreichen Fall darstellen und die deshalb zusammengeführt werden können. Danach folgt die Prüfung, ob die Angebotslegungsfrist realisiert werden kann. Parallel hierzu wird die für die Projektabwicklung notwendige Ingenieurgruppe auf ihre Auslastung hin überprüft. Ist die Kapazität vorhanden, die Angebotsfrist aber zu knapp, wird um Fristverlängerung nachgefragt. Wird diese nicht gewährt, erfolgt eine Absage. Ist absehbar, dass benötigte Ingenieurfachkräfte schon für längere Zeit aufgrund laufender Projekte ausgelastet sind, erfolgt ebenfalls eine Absage. Die Prüfung der Angebotslegungsfrist (Position 1) führt zu einer Funktion und zwei Ergebnisereignissen. Genauso die Prüfung der Kapazität der Ingenieurgruppe. Beide Funktionen werden durch ein logisches UND verknüpft, da sie gleichzeitig angestoßen werden. Die insgesamt vier möglichen Ergebnisse werden nun dadurch in Beziehung gesetzt, dass zwei davon (Angebotslegungsfrist nicht realisierbar und Kapazitäten vorhanden) zu einer bestimmten Funktion führen. Dies wird in der Ereignisgesteuerten Prozesskette dadurch realisiert, dass die beiden von diesen Ereignissen kommenden Kontrollflüsse mit einem logischen UND verknüpft werden (Position 3). Danach wird dann die entsprechende Funktion (Fristverlängerung erbitten) angefügt (vgl. Abbildung 6.3-4). In Abbildung 6.4-3 ist auch eine Schlusssequenz. Falls sich herausstellt, dass die Kapazität der Ingenieurgruppe nicht reicht, wird die Anfrage abgelehnt.

Tipp: Daten- bzw. Informationsflüsse gründlich modellieren Die Informationsobjekte in Ereignisgesteuerten Prozessketten sollten so angelegt werden, dass sie die Daten- und Informationsflüsse möglichst exakt modellieren. Dann können Medienbrüche, aber z.B. auch die Informationsweitergaben, die u.U. Hinweise auf Optimierungsmöglichkeiten geben, besser erkannt werden. Weitere Tipps: siehe Stichwortverzeichnis.

Weiter mit Abbildung 6.3-3

214

6 Beispiele

Abbildung 6.3-3: Weiter mit Abbildung 6.3-4

Angebotserstellung für Anlagen, Teil 2

Sind alle zu prüfenden Kriterien erfüllt, erfolgt die eigentliche Angebotserstellung. Dies geschieht in der Regel unter Einbeziehung der Mitarbeiter aus den relevanten Geschäftsbereichen oder der Geschäftsbereichsleiter, die z. B. bei der Stunden- und Kostenschätzung von angefragten Ingenieurstätigkeiten mitwirken und mögliche, verfügbare Ingenieure als Projektleiter und Ingenieure vorschlagen. Die Angebotsdaten werden in der Angebotsdatenbank erfasst, ein Programm erzeugt dann die textliche Ausformulierung des Angebots für den anfragenden Kunden. Die folgende Abbildung 6.4-3 wird mit zwei Kontrollflusszweigen weitergeführt. In einem befindet sich die im vorigen Teil schon angesprochene Funktion mit der Bitte um Fristverlängerung (Position 1). Obwohl im Text nicht ausgeführt, werden in der Ereignisgesteuerten Prozesskette die zwei möglichen Ergebnisse modelliert und für den Fall einer Nichtgewährung ein Schlussereignis eingefügt (Position 2). Falls die Fristverlängerung gewährt wird, wird dieser Kontrollfluss mit dem Anderen, der den von vorneherein positiven Fall vertritt, mit einem exklusiven ODER zusammengeführt.

6.3 Angebotserstellung im Anlagenbau

Abbildung 6.3-4:

215

Angebotserstellung für Anlagen, Teil 4

Es folgt dann die in der obigen Beschreibung angeführte „eigentliche“ Angebotserstellung. Die im Text etwas unklaren Angaben zu den zuständigen Personen werden an die Funktion mit einer „Organisationseinheit“ Diverse angehängt. Bei dieser Funktion entsteht dann auch ein Informationsobjekt Angebot. In der nachfolgenden Funktion Angebotsdaten erfassen wird dann dieses Informationsobjekt gelesen und ein weiteres geschrieben, ein Eintrag in eine Datenbank mit allen Angeboten, die im Unternehmen erstellt werden.

216

Weiter mit Abbildung 6.3-5

Zustellung und Warten

Informationsobjekt ohne „Pfeil“: Transportvorgang Warten

Weiter mit Abbildung 6.3-6

6 Beispiele

Der zweite Teil des letzten Satzes in der obigen Beschreibung verweist bereits auf die Abbildung 6.3-5. Abbildung 6.3-5 beginnt mit der maschinell erzeugten textlichen Ausformulierung, die im obigen Text angeführt ist. Diese Funktion wird also von einem Programm durchgeführt, aber natürlich von einem Menschen gestartet. An dieser Stelle weist der Geschäftsprozess einen hohen Automatisierungsgrad auf. Das fertige Angebot wird dem Kunden zugeschickt oder gebracht. Danach muss die Entscheidung des Kunden abgewartet werden. Der Kunde erteilt den Auftrag entweder sofort aufgrund des Angebots oder er lädt zunächst zu einem oder mehreren Vergabegesprächen ein. Die Angebotsverhandlungen werden in der Regel vom zuständigen Vertriebsingenieur oder Vertriebsbereichsleiter und dem im Angebot genannten Projektleiter geführt. Obiger Text beschreibt zuerst den Transportvorgang, der das Angebot zum Kunden bringt. Hier wurde wieder das zu transportierende Informationsobjekt ohne Richtungspfeil an die Funktion angehängt. Danach liegt eine Wartesituation vor (Position 2), die ebenfalls durch eine Funktion modelliert wird. Die möglichen Ergebnisse des Wartens sind im Text auch angegeben. Das positive Ergebnis, Auftrag erteilt, ist gleichzeitig auch ein Schlussereignis dieses Geschäftsprozesses. Die beiden anderen vorgedachten Ergebnisse, Vergabegespräche und Absage führen weiter zu Abbildung 6.3-6. Im Falle der Auftragserteilung wird ein anderer Geschäftsprozess angestoßen (vgl. Abschnitt 6.4), weshalb nach diesem Schlussereignis ein entsprechender Prozesswegweiser angefügt wurde. Trifft eine Absage ein, ist der zuständige Vertriebsingenieur verpflichtet, durch Nachfragen beim Kunden oder sonstigen Verbindungsleuten die Gründe für die Absage in Erfahrung zu bringen, falls dies nicht schon aus dem Absageschreiben hervorgeht. Dies dient dazu, die Informationsbasis für zukünftige Angebote bei diesem Kunden zu verbessern. Mit dieser Beschreibung geht der Geschäftsprozess seinem Ende entgegen. Noch vom vorhergehenden Text stammt der Hinweis, dass es u.U. zu Vergabegesprächen kommt. Diese wurden als Funktion modelliert, die lesend und schreibend auf das Informationsobjekt Angebot zugreift. Es wird im Text zwar nicht ausgeführt, wurde hier aber so interpretiert, dass nach diesen Vergabegesprächen wieder auf die Kundenreaktion gewartet werden muss. Deshalb wurde in der Ereignisgesteuerten Prozesskette nach dem Ereignis Gespräche geführt der Kontrollfluss zurückgeführt vor die Funktion Warten auf Kundenreaktion in Abbildung 6.3-5 (Position 2).

6.3 Angebotserstellung im Anlagenbau

Abbildung 6.3-5:

217

Angebotserstellung für Anlagen, Teil 4

Im Fall einer Absage des Kunden ist im obigen Text festgelegt, dass beim Kunden nach den Gründen gefragt wird. Auch dies ist in der folgenden Abbildung durch eine Funktion Nachfragen festgehalten. Das danach folgende Ereignis stellt ein weiteres mögliches Schlussereignis dar.

218

6 Beispiele

Abbildung 6.3-6:

Angebotserstellung für Anlagen, Teil 4

So weit der Geschäftsprozess Angebotserstellung, der damit endet. Im positiven Fall stößt er den nachfolgend skizzierten Geschäftsprozess Vorbereitung Auftragsabwicklung an.

6.4

Vorbereitung Auftragsabwicklung

Dieser Geschäftsprozess wurde ebenfalls in Abschnitt 2.9 in textlicher Form vorgestellt. Er stammt ebenfalls aus dem Umfeld des Anlagenbaus. Er könnte ein Prozess sein, der dem des vorigen Abschnitts nachfolgt.

Anmerkung Die folgende Ereignisgesteuerte Prozesskette wird zum einen durch die textliche Originalbeschreibung, zum anderen durch Anmerkungen des Verfassers erläutert. Dabei ist der Originaltext eingerückt. Um die Bezüge zwischen textlicher Beschreibung und Abbildungen einfacher herstellen zu können, wurden in die Abbildungen Nummern eingefügt, auf die im Text verwiesen wird. Wieder betrachten wir eine prototypische Situation bei einem Unternehmen des Anlagenbaus. Die Beschreibung des Geschäftsprozesses beginnt mit dem Auftragseingang: Der Auftrag des Kunden geht immer schriftlich ein. Geht er doch mündlich ein, wird mit dem Kunden zusammen durch den Vertrieb eine kurze schriftliche Auftragsklärung durchgeführt. Damit ist die Anfangssequenz (vgl. die folgende Abbildung) mit zwei Startereignissen festgelegt. Die Auftragsklärung wird zu einer Funktion (vgl. Position 1 in der Abbildung). Nicht festgelegt ist, was geschieht, wenn eine Klärung nicht möglich ist. Angenommen wird, dass die Auftragsklärung zu einer Modifikation des Informationsobjekts Auftrag führt.

6.4 Vorbereitung Auftragsabwicklung

219

Nach Eingang des Auftrags prüft der Vertriebsingenieur, ob der Auftrag mit sämtlichen ausgehandelten Konditionen bzw. dem Angebot übereinstimmt. Dies führt zu einer entsprechenden Funktion mit dem Informationsobjekt Auftrag und der Organisationseinheit Vertriebsingenieur (vgl. Position 2 in Abbildung 6.4-1). Es wird angenommen, dass die evtl. entstehende Auftragsfestlegung Teil des Informationsobjekts Auftrag wird. Die möglichen Ergebnisse dieser Prüfung sind im folgenden Text festgelegt. Gibt es im Auftrag des Kunden Abweichungen vom Angebot werden diese in der Auftragsbestätigung durch für das Unternehmen akzeptable Konditionen ersetzt. Dies wird dem Kunden mitgeteilt und er wird gebeten, die Kenntnisnahme schriftlich zu bestätigen. Dieser Textabschnitt betrifft nun den Fall, dass die Ersetzung durch akzeptable Konditionen tatsächlich notwendig wird. Diese wird dann als Funktion modelliert (Position 3).

Hinweis Wieder gilt für die Grafiken: Hat eine Funktion keine Organisationseinheiten gelten die der vorangehenden Funktion. Leider ist hier nicht angegeben, was geschieht, falls das Ergebnis negativ ist. Dies geschieht erst weiter unten. Das Zusenden des Angebots, das in diesem Fall nötig wird und das Warten auf die Kundenreaktion wurde als Funktion modelliert (vgl. Abbildung 6.4-2, Position 1). Ergänzt wurde in der Ereignisgesteuerten Prozesskette die Ablehnungssequenz (ab Position 2), die zu einer Ablehnung des Auftrags und damit zu einem ersten Schlussereignis führt. Falls der Kunde die Ersetzung der Konditionen akzeptiert (Ereignis an Position 3) wird der Kontrollfluss wieder mit dem positiven Ergebnis der Prüfung zusammengeführt (Position 4). Er füllt dann handschriftlich ein Auftragsstammblatt aus, wobei im Vertrieb gleichzeitig zentral die Auftragsnummer vergeben wird. Vorstehender Text signalisiert, dass zwei Tätigkeiten angestoßen werden. Entsprechend wurde dies mit einem UND-Operator und zwei Funktionen in der Ereignisgesteuerten Prozesskette modelliert (Position 5 in Abbildung 6.4-2).

Weiter mit Abbildung 6.4-2

220

6 Beispiele

Abbildung 6.4-1:

Auftragsabwicklung im Anlagenbau, Teil 1 – Auftragseingang und Prüfung

6.4 Vorbereitung Auftragsabwicklung

Abbildung 6.4-2:

221

Auftragsabwicklung im Anlagenbau, Teil 2 – Prüfungen

Das ausgefüllte Auftragsstammblatt wird an das Controlling weitergeleitet, wo die im Angebot bzw. im Auftrag festgelegte Kostenstruktur nach Honorar, Sachkosten, Reisekosten und Fremdleistungskosten auf dem Auftragsstammblatt vermerkt und mit Vorgaben für Budget, Ressourcenplanung, Reisekosten und Zahlungsplan versehen wird. Der zu Beginn des obigen Textes angeführte Transportvorgang wurde als eigene Funktion modelliert (Position 1 in Abbildung 6.4-3). Es wird angenommen, dass diese Tätigkeit ebenfalls vom Vertriebsingenieur geleistet wird, weshalb die Organisationseinheit weggelassen werden kann. Nach dem hierauf folgenden Ereignis können die beiden Kontrollflusszweige wieder zusammengeführt werden (Position 2). Anschließend folgt

Weiter mit Abbildung 6.4-3

222

6 Beispiele

die im obigen Text angeführte Vermerkung der Kostenstruktur mit der Organisationseinheit Controlling. Das Controlling erstellt eine Stundenvorgabe für den Projektleiter, die sich folgendermaßen errechnet: Vom beauftragten Honorar werden zunächst die Fremdleistungen und die geplanten Sachkosten (Reisekosten, Kopierkosten etc.) abgezogen. Nach Abzug eines Gewinns und einer Sicherheitsmarge in Höhe von ca. 17% ergeben sich die verfügbaren Personalkosten. Diese werden durch den Kostensatz der jeweiligen Mitarbeitergruppe geteilt. So ergibt sich die Stundenvorgabe je Mitarbeitergruppe. Alle Ingenieure im Haus sind nach den Jahren ihrer Berufserfahrung unterschiedlichen Gruppen zugeordnet. Jede Gruppe wird zu einem bestimmten Erlösstundensatz abgerechnet bzw. Kostenstundensatz belastet. Ebenso werden Sekretärinnen, studentische Hilfskräfte, Übersetzer, Technische Zeichner usw. mit bestimmten Kostensätzen eingerechnet. Dabei werden drei Stufen unterschieden. Der erste Kostensatz ergibt sich aus dem jeweiligen Gehalt des Mitarbeiters. Die Hinzurechnung der direkten bereichsspezifischen Gemeinkosten ergibt den zweiten Kostensatz. Die weitere Addition des unternehmensspezifischen Gemeinkostensatzes ergibt den endgültigen dritten Kostensatz. Vorgang und Regelwerk

In obigem Text ist zweierlei vermerkt. Zum einen ein betriebswirtschaftlicher Vorgang, die Erstellung der Stundenvorgabe, zum anderen ein Regelwerk zur Bestimmung der Stundenvorgabe. Letzteres eignet sich nicht für die Modellierung in einer Ereignisgesteuerten Prozesskette. Dieses Regelwerk ist ein Beispiel für Festlegungen, die innerhalb einer Funktion, bzw. innerhalb eines betriebswirtschaftlichen Vorgangs angesiedelt sind. Deshalb entsteht hieraus nur eine entsprechende Funktion mit einem Ereignis (Position 3 in Abbildung 6.4-3). Das Regelwerk wurde als Informationsobjekt modelliert.

6.4 Vorbereitung Auftragsabwicklung

Abbildung 6.4-3:

223

Auftragsabwicklung im Anlagenbau, Teil 3 – Kosten klären

Das Controlling ermittelt die Rechnungsstellungstermine aufgrund der vertraglichen Vereinbarungen. Bei Honorar nach Aufwand wird nur der Abrechnungsmodus (wöchentlich, monatlich, vierteljährlich, usw.) vermerkt. Bei Pauschalaufträgen sind die Rechnungsstellungstermine in der Regel an den Projektfortschritt gekoppelt und fallen mit Meilensteinen der Projektabwicklung zusammen. Bei den Rechnungsstellungsterminen für diese Aufträge werden die abzurechnenden Beträge bzw. der Prozentanteil des Honorars vermerkt.

Weiter mit Abbildung 6.4-4

224

6 Beispiele

Obiger Text verlangt zuerst eine Funktion, in der die Klärung der Vertragsstruktur erfolgt (Position 1 in Abbildung 6.4-4). Die beiden Möglichkeiten der Honorargestaltung werden dann als alternative Ergebnisereignisse dieser Funktion modelliert.

Abbildung 6.4-4:

Auftragsabwicklung im Anlagenbau, Teil 4 – Weitere Klärungen

Nachfolgend dann die Funktionen, die der Text verlangt: die Vermerkung des Abrechnungsmodus bei Honorar nach Aufwand und die Festlegung der Rechnungstermine einschließlich der Honoraranteile. Das Informati-

6.4 Vorbereitung Auftragsabwicklung

225

onsobjekt bei diesen beiden Funktionen ist aus dem Text nicht ersichtlich, es wurde ergänzt (Position 2 von Abbildung 6.4-4). Im Anschluss daran kann der Kontrollfluss wieder zusammengeführt werden. Nach Ermittlung der Rechnungsstellungstermine werden dem Kunden durch den Vertrieb die Zahlungstermine mitgeteilt. Parallel hierzu erfolgt die Anlage des Auftrags im DV-System durch das Controlling. Obiges führt wieder zu zwei „parallel“ anzustoßenden Funktionen (Position 3 in Abbildung 6.4-4) und ihren Ereignissen Zahlungstermine mitteilen und Anlage Auftrag im DV-System. Geht es nach einer Aufteilung des Kontrollflusses durch einen UNDOperator einheitlich weiter, können die Kontrollflusszweige wieder zusammengeführt werden (müssen aber nicht). Hier wurde darauf verzichtet, sodass nur ein Zweig zur nächsten Abbildung weiterführt. Das durch die Abteilung Auftragsabwicklung vervollständigte Auftragsstammblatt wird zur Erstellung der Auftragsmeldung an den Vertrieb zurückgegeben.

Weiter mit Abbildung 6.4-5

Hier werden durch einen Satz drei Funktionen festgelegt: die Vervollständigung des Auftragsstammblatts (Position 1 in Abbildung 6.4-5) die Weiterleitung zum Vertrieb (Position 2) und die Erstellung der Auftragsmeldung (Position 3). Die Organisationseinheiten sind ebenfalls festgelegt. Zuerst die Auftragsabwicklung, dann der Vertrieb. Die ausgedruckte Auftragsmeldung wird mit den entsprechenden Anlagen (Angebot, Vertrag und sonstige für die Vertragsausführung erforderlichen Dokumente) archiviert. Außerdem werden vom Controlling Kopien an den für die Bearbeitung zuständigen Technikbereich weitergeleitet. Dieser Text führt schon zur letzten Abbildung, wo sich diese beiden Tätigkeiten als Funktionen (Auftragsmeldung archivieren und Kopien an Technikbereich weiterleiten), die mit UND verknüpft sind, wieder finden. Parallel zur internen Meldung über die Vervollständigung des Auftragsstammblatts hat der Vertriebsingenieur die externe Auftragsbestätigung an den Kunden zu erstellen. Erfolgte der Auftrag schriftlich und hat der Auftraggeber bereits eine Auftragsbestätigung mitgeschickt, wird diese unterschrieben zurückgesandt. Sonst wird eine kurze Auftragsbestätigung vom zuständigen Vertriebsingenieur erstellt. In dieser werden auch die zuständigen technischen Ansprechpartner und der Projektleiter vermerkt. Letzterer setzt sich dann mit dem Kunden in Verbindung, um die Arbeitsaufnahme zu besprechen.

Weiter mit Abbildung 6.4-6

226

6 Beispiele

Erfolgte die Beauftragung mündlich, wird ein Auftragsbestätigungsschreiben mit sämtlichen besprochenen Konditionen verfasst und um schriftliche Bestätigung des Kunden gebeten.

Abbildung 6.4-5:

Auftragsabwicklung im Anlagenbau, Teil 5

Obiger Text führt nun zurück zum Anfang von Abbildung 6.4-5. Dort muss diese Erstellung der externen Meldung „parallel“ zur Vervollständigung des Auftragsstammblatts eingefügt werden. Dies geschieht, indem zuerst eine Prüfung der Art der Auftragserteilung eingefügt wird (Position 4 in Abbildung 6.4-5). Danach sind die entsprechenden Ereignisse eingefügt. Aus grafischen Gründen wurde dieser Teil auf die nächste Abbildung 6.4-6 gezogen.

6.4 Vorbereitung Auftragsabwicklung

Abbildung 6.4-6:

227

Auftragsabwicklung im Anlagenbau, Teil 6

Dort sind dann die drei möglichen vorgedachten Ergebnisereignisse vermerkt:

228

x x x

Weiter mit Abbildung 6.4-7

6 Beispiele

schriftlich mit Auftragsbestätigung schriftlich ohne Auftragsbestätigung mündlich

Die beiden erstgenannten führen zu entsprechenden Funktionen und dann zu einem gemeinsamem Ereignis (Erledigt). Im Falle der mündlichen Beauftragung werden die oben im letzten Absatz der Originalbeschreibung genannten Tätigkeiten als Funktionen eingefügt. Wieder finden sich im obigen Text Erläuterungen, die nicht in die Ereignisgesteuerte Prozesskette gehören, z.B. zur Gestaltung der Informationsobjekte. Der Abschluss dieser Ereignisgesteuerten Prozesskette ist in der folgenden Abbildung angegeben, die Besprechung der Arbeitsaufnahme mit dem Kunden.

Abbildung 6.4-7:

Auftragsabwicklung im Anlagenbau, Teil 7

7 Ereignisgesteuerte Prozessketten bewältigen

7.1 7.1.1

Situationen und ihre Bewältigung Aufeinanderwirken von Funktionen

Überwachung und Kontrolle sind wichtige Elemente von Geschäftsprozessen und sollten daher bei einer Methode zur Modellierung von Geschäftsprozessen mitbedacht werden. Geht es um eine einfache Tätigkeit (z.B. Erstellung von irgendwelchen Unterlagen), deren Erledigung kontrolliert werden soll, ist die Lösung einfach. Wie in den Abschnitten 5.1 und 5.2 gezeigt kann dies durch Rücksprünge bei Misserfolg bzw. durch die Wiederholung einzelner Geschäftsprozessabschnitte modelliert werden. Geht es um komplexere oder auch nur längere Arbeitsabläufe, die wirklich überwacht werden müssen, wo also der Arbeitsfortschritt kontrolliert werden soll, ist die Situation schwieriger. Ein Beispiel dafür findet sich in Abschnitt 6.1 (Abbildungen 6.1-5 und 6.1-6). Dort lag folgende Situation vor (Originalbeschreibung): Die Arbeitsvorbereitung erstellt die Angebotsunterlagen, was bei den Produkten dieses Unternehmens ein längerer und anspruchsvoller Vorgang ist. Der Verkauf überprüft regelmäßig den Fortgang der Arbeiten in der Arbeitsvorbereitung und erstellt im Falle eines Verzuges eine sog. Mahnliste, mit der sozusagen der Verzug dokumentiert wird. In der ursprünglichen EPK-Beschreibung des Geschäftsprozesses war die Erstellung der Angebotsunterlagen in eine Funktion gekapselt. Damit ergab sich ein EPK-Abschnitt wie in der folgenden Abbildung.

Kontrolle nach Erledigung

230

7 Ereignisgesteuerte Prozessketten bewältigen

Abbildung 7.1-1: Problem durch Kapselung

Verknüpfung über Ereignisse

Künstliche Sequenzialisierung

Erweiterung der Notation

Gekapselte Tätigkeiten

Wird aber auf diese Weise modelliert, werden also kontinuierlich ablaufende Tätigkeiten in einer Funktion zusammengefasst, kann auf die einzelnen Abschnitte im Rahmen der linear/sequenziellen EPK-Methode nicht mehr zugegriffen werden. Als Notlösung bleibt dann lediglich der Rückgriff auf den Ereignisraum, d.h. auf die Verknüpfung von Geschäftsprozessen bzw. Ereignisgesteuerten Prozessketten über Ereignisse. Konkret bedeutet dies, dass, wie ebenfalls in Abschnitt 6.1 gezeigt (vgl. Abbildung 6.1.6), ein eigener Geschäftsprozess (eine eigene Ereignisgesteuerte Prozesskette) angesetzt wird mit einem Startereignis, das den Verstoß angibt. In Abbildung 6.1-6 z.B. Verzug ist aufgetreten. Überwachung wird somit über ein eventuelles negatives Ergebnis der Überwachung modelliert. Ist eine direktere Verknüpfung der Tätigkeit mit ihrer Überwachung gewollt, bleibt nichts anderes übrig, als die Tätigkeit aus einer Funktion herauszunehmen und in einzelne Teilaufgaben zu zerlegen, (sie – u.U. künstlich – zu sequenzialisieren), nach denen dann jeweils kontrolliert wird. Diese Lösung ergibt sich aus der linearen und sequenziellen Grundstruktur von Ereignisgesteuerten Prozessketten. Vgl. dazu das Beispiel in Abbildung 6.1-5. Dann kann durch Abfragen nach jedem Abschnitt die Überwachung und Erstellung der Mahnliste auf einfache Weise modelliert werden. Auf diese Weise wird die Ereignisgesteuerte Prozesskette allerdings kompliziert. Außerdem wird u.U. die Semantik nicht voll getroffen, da ein eigentlich kontinuierlicher Ablauf künstlich unterteilt wurde. Besser wäre es, hier die EPK-Notation um ein Element zu ergänzen, das ganz allgemein die Zuordnung einer Funktion zu gekapselten oder kontinuierlichen Arbeitsschritten erlaubt. Damit könnten zwei Funktionen direkt in Beziehung gesetzt werden. Ergeben sich aus der Beziehung Konsequenzen, könnte dies durch entsprechende Ereignisse modelliert werden. Ein Vorschlag für die im obigen Beispiel vorliegende Situation findet sich in Abbildung 7.1-2. Eine „Funktion“ überwacht die andere und reagiert auf bestimmte Ereignisse. Auf diese Weise ist eine Verknüpfung der

7.1 Situationen und ihre Bewältigung

231

Prozesse ohne komplizierte Konstruktion möglich. Allerdings erweitert dies die Notation um ein Element. Diese Konstruktion könnte nicht nur zur Überwachung bzw. Kontrolle, sondern ganz allgemein zur Beobachtung anderer Tätigkeiten und eventuellen Reaktionen benutzt werden. Allerdings nur, wenn es sich auf der einen Seite tatsächlich um mehrere oder kontinuierliche Arbeitsschritte handelt und wenn auf der anderen Seite wirklich ein weiterer Akteur (ein Mensch oder aber – auch das ist denkbar – eine Maschine bzw. ein Programm) mit im Spiel ist.

Abbildung 7.1-2:

7.1.2

Neues Element für die Überwachung kontinuierlicher/gekapselter Arbeitsschritte

Ebenen – Detaillierungsgrad - Kapselung

Sehr oft wurde in den letzten Kapiteln von unterschiedlichen Detaillierungsebenen gesprochen. Dabei bezieht sich der Begriff auf Tätigkeiten (im Rahmen von Geschäftsprozessen), die detaillierter oder weniger detailliert betrachtet werden können. Oder aber auch darauf, dass oftmals eine Tätigkeit aus vielen Einzeltätigkeiten besteht. Betrachten wir einige Beispiele. Ist ein Angebot zu erstellen, kann entweder wie im Beispiel von Abschnitt 6.1 sehr detailliert verfahren werden oder die ganzen Tätigkeiten können wie in Abschnitt 6.2 in eine Funktion gepackt werden61. 61

Auch hier wieder der Hinweis: Diese Frage stellt sich nicht, wenn entlang einer Software modelliert wird, da dann der Geschäftsprozess auf deren Detaillierungsniveau modelliert wird.

Beobachten und Reagieren

232

Detaillierungsgrad

Kapselung

Ähnliches ergibt sich, wenn Einzeltätigkeiten modelliert werden sollen, wenn z.B. eine Aktion gestartet wird (z.B. eine Ärztebefragung in einem pharmazeutischen Unternehmen) und danach einzelne Teilaktionen durchgeführt werden (einzelne Befragung). Auch hier muss sehr bewusst das Detaillierungsniveau überlegt werden. Modelliert man tatsächlich die einzelnen Aktionen, kommt eine repetitive Schleife, wie in Abschnitt 5.2 gezeigt, infrage. Diese „Ebenenfrage“ ist schon deshalb von Bedeutung weil ja, wie in Kapitel 3 ausgeführt, die Kunden und Entwickler Betriebswirtschaftlicher Standardsoftware aus unterschiedlichen Motiven ganz grundsätzlich eine immer größere Detaillierung anstreben. Ganz grundsätzlich führt höhere Detaillierung zu komplexeren Prozessketten mit Rücksprüngen, Verzweigungen, Prozessverknüpfungen (mit Prozesswegweisern oder über Ereignisse) oder „Spagetti-Code“ (vgl. unten), was nur noch mit guten Methodenkenntnissen beherrschbar und auch nicht mehr ganz einfach zu verstehen ist. Insofern ist eine Abwägung zwischen notwendigem Detaillierungsgrad und Modellkomplexität nötig. Außerdem muss an dieser Stelle berücksichtigt werden, dass der Aufwand der Aktualisierung der Geschäftsprozessbeschreibungen mit ihrem Detaillierungsgrad steigt. Diese Abwägung sollte vom Zweck der Modellierung geleitet werden. Sie wird dann dort detaillierter, wo Optimierungspotenzial vermutet wird und dort gröber, wo dies nicht der Fall ist, wo es nur um den Zusammenhang geht. Für das Zusammenpacken von Tätigkeiten in einer Funktion wurde hier der Begriff Kapselung gewählt. Dieser eigentlich aus der Diskussion um objektorientierte Techniken stammende Begriff passt hier sehr gut, auch wenn es hier nicht um die Kapselung von Methoden und den Zugriff auf sie nur über klar definierte Schnittstellen geht. Hier geht es einfach darum, dass in einer Funktion (einem Element der formalen Sprache) verschiedene aufeinander folgende Tätigkeiten zusammengepackt werden, dass sie als Ganzes angestoßen werden und dass ihre Erledigung durch ein Ereignis (oder mehrere) signalisiert wird. 7.1.3

Kein Handeln

7 Ereignisgesteuerte Prozessketten bewältigen

Leerzweige

Oftmals ergibt sich die in der folgenden Abbildung angegebene Situation. Eine Funktion führt in einem Fall direkt zu einem erfolgreichen Ereignis, im anderen dazu, dass eine korrigierende Funktion gestartet wird.

7.1 Situationen und ihre Bewältigung

Abbildung 7.1-3:

233

Alternative ohne Handlung

Diese Konstruktion ist immer dann angebracht, wenn es bei Ergebnisereignissen eine Alternative gibt, die kein Handeln erfordert. Damit entstehen Leerzweige, die oftmals auf den ersten Blick befremdlich anmuten. Nichtsdestotrotz ist diese Lösung richtig. Dies klappt so aber nur, falls tatsächlich eine Funktion eingebaut werden kann. Ist dies nicht der Fall, muss eine andere Lösung gewählt werden, denn es muss ja die Syntaxgrundregel eingehalten werden, dass Ereignisse und Funktionen sich immer ablösen. 7.1.4

Optionale Ereignisse

Oftmals ist es notwendig, optionale Ereignisse (kann eintreten oder auch nicht) in Geschäftsprozessen zu modellieren. Ihre Optionalität sagt schon aus, dass sie auf den Kontrollfluss direkt keinen Einfluss haben, sie haben aber dokumentarischen Charakter. Diese sind nicht selten, wie die Beispiele in den vorigen Kapiteln zeigten. Betrachten wir für ein Beispiel folgende Situation. Eine Funktion 1 (F1) wurde durchgeführt. Damit die folgende Funktion 2 (F2) gestartet werden kann, müssen Ereignis 1 (E1) und Ereignis 2 (E2) eintreten. Ein weiteres Ereignis 3 (E3) kann eintreten, muss aber nicht. Probleme bei der Modellierung macht E3, der Rest ist klar. Die folgende Abbildung zeigt die Ausgangssituation.

Optionalität

234

7 Ereignisgesteuerte Prozessketten bewältigen

Abbildung 7.1-4: Negation eines Ereignisses

Modellierung optionaler Ereignisse

Ereignis 3 kann eintreten oder auch nicht. Will man dies so modellieren, z.B. um genau diesen Sachverhalt in der Ereignisgesteuerten Prozesskette zu dokumentieren oder weil das eventuelle Eintreten auf einen späteren Abschnitt Einfluss hat, dann kann dies z.B. so geschehen: Man legt zusätzlich zu Ereignis 3 dessen Negation an und modelliert dann mit einem XODER-Operator, wie in der folgenden Abbildung angegeben. Diese Vorgehensweise ist möglich, weil jedes Ereignis eine logische Aussage ist und deshalb ohne Schwierigkeit negiert werden kann.

7.1 Situationen und ihre Bewältigung

Abbildung 7.1-5:

7.1.5

235

Modellierung optionaler Ereignisse mit einer Negation

Komplexitätsbewältigung - Vervielfachung vs. Schlankheit

Oftmals hat man bei der Erstellung von Ereignisgesteuerten Prozessketten nur die Wahl, eine gegebene Komplexität der Semantik durch Vervielfachung oder durch unübersichtlichen „Spagetti-Code“ zu bewältigen. Betrachten wir als Beispiel den folgenden Ausschnitt aus Abbildung 6.2.-7 (vgl. Abbildung 7.6-1). Wie in Abschnitt 6.2 beschrieben geht es dabei darum, die Ereignisgesteuerte Prozesskette dadurch „schlank“ zu halten, dass in einer Funktion zwei ähnliche, aber verschiedene Tätigkeiten zusammengepackt werden: Klären, ob CAD-Zeichnung bedeutet im einen Fall x x

Klären, ob CAD-Zeichnung zu ändern (falls vorher eine gefunden wurde) und im anderen Klären, ob CAD-Zeichnung zu erstellen (falls vorher keine geeignete gefunden wurde).

Wie Abbildung 7.6-1 zeigt, entsteht mit diesem Zusammenpacken tatsächlich eine „schlanke“ Lösung. Dies macht auch Abbildung 7.6-2 deutlich, wo die korrekte ausführliche Lösung dargestellt ist. Jetzt entstehen

236

7 Ereignisgesteuerte Prozessketten bewältigen

zwei sich nur wenig unterscheidende Zweige. Die Übersichtlichkeit ist jetzt voll gegeben, allerdings hat der Umfang sehr zugenommen.

Abbildung 7.1-6:

„Schlankheit“ durch Zusammenlegen

Die Lösung von Abbildung 7.1-7 gibt die Möglichkeit, die Funktionen und Ereignisse so zu benennen, dass die Ereignisgesteuerte Prozesskette selbsterklärend wird: Zeichnung im CAD ändern bzw. Zeichnung im CAD erstellen). Hier wäre kein erklärender Text mehr notwendig.

7.1 Situationen und ihre Bewältigung

Abbildung 7.1-7:

Übersichtlichkeit durch Verdopplung

237

238

7 Ereignisgesteuerte Prozessketten bewältigen

Abbildung 7.1-8:

„Schlankheit“ durch „Spagetti-Code“

7.1 Situationen und ihre Bewältigung

239

Sehr oft sieht man aber für solche Situationen die Lösung von Abbildung 7.1-8, die hier mit „Spagetti-Code“ bezeichnet wurde, in Anlehnung an den Begriff für unübersichtlich erstellten Programmcode. Hier wurden die Funktionen nach den Ereignissen Gefunden und Nicht gefunden noch getrennt, danach aber die Verdopplung der Zweige vermieden. Dies wird schnell unübersichtlich (der Verfasser hat dies schon mit drei und vier Ästen und mehrstufig gesehen) und sollte unbedingt vermieden werden. Ganz grundsätzlich kann die Empfehlung gegeben werden, lieber einzelne Prozesszweige zu verdoppeln oder sogar zu vervielfachen62, als durch komplexe Konstruktionen die Übersichtlichkeit (v.a. bei großen Ereignisgesteuerten Prozessketten) zu gefährden. Umgekehrt gilt: Bekommt man eine auf den ersten Blick sehr unübersichtliche Ereignisgesteuerte Prozesskette zu Gesicht, liegt die Ursache dafür mit großer Wahrscheinlichkeit in dem hier beschriebenen Versuch der „Verschlankung“. Diese Ausführungen sollten auch nochmals deutlich machen, dass es bei dieser semi-formalen Sprache oftmals auch syntaktische Alternativen bezüglich der Modellierung konkreter Situationen gibt. 7.1.6

Struktur vs. Daten

Die Struktur einer Ereignisgesteuerten Prozesskette sollte nicht von den konkreten Ausprägungen der Daten abhängig sein. Das folgende EPKFragment zeigt ein Beispiel, in dem es um die Frage geht, wer einen Beleg bei einem Konto mit Einzelverfügung unterschrieben hat. Hier sind drei Ereignisse nötig, weil es eben drei Berechtigte sind. In einem anderen Fall sind es aber zwei oder vier. Bei einer solchen Modellierung wurde zu wenig abstrahiert. Die konkrete Anzahl sollte sich nicht in der Zahl der Ereignisse niederschlagen. Die Modellierung kann hier so erfolgen, dass eine Prüfung Unterschriften zu den Ergebnissen In Ordnung und Nicht in Ordnung führt. Möchte man festhalten, wer im konkreten Fall unterschrieben hat, müsste dies durch ein Informationsobjekt erfolgen, in das von der Prüffunktion aus reingeschrieben wird.

62

Oder zu Verknüpfungen zu greifen, durch Prozesswegweiser bzw. mithilfe von Ereignissen.

Lieber verdoppeln

Klärung von Unübersichtlichkeit

240

7 Ereignisgesteuerte Prozessketten bewältigen

Abbildung 7.1-9: 7.1.7

Träger deutlich machen

Daten als EPK-Strukturmerkmal

Intern/Extern und Warten

Oftmals verlassen Geschäftsprozesse vorübergehend das eigene Unternehmen. Damit ist nicht gemeint, dass auf Entscheidungen externer gewartet werden muss (z.B. beim Warten auf Antwort der Bewerberin, vgl. Abschnitt 5.3), sondern dass sich der aktive Part nach außen verlagert. Betrachten wir folgendes Beispiel: Im Rahmen einer durchzuführenden Befragung wurde ein Fragebogen entwickelt. Dieser wird nun zum Drucken, Binden und Verpacken in ein anderes Unternehmen gegeben und kommt nach Fertigstellung zum eigentlichen Versenden in das Unternehmen zurück. In einem solchen Fall werden die Funktionen, die außerhalb des Unternehmens realisiert werden, meist nicht modelliert, weil sie sich dem eigenen Zugriff entziehen. Ist der Blickwinkel allerdings globaler, geht es vielleicht gerade auch um das Zusammenspiel des eigenen Geschäftsprozesses mit den externen, dann sollten auch diese Abschnitte modelliert werden (falls der Geschäftspartner mitmacht). Die in obigem Beispiel im Rahmen des Unternehmens anfallenden Funktionen könnten Vergabe des Auftrags und Entgegennahme Fragebögen sein. Alles was dazwischen liegt, wird im einen Fall nicht, im anderen doch betrachtet. Dabei gilt aber, dass der jeweilige Träger des Geschäftsprozesses deutlich gemacht werden muss. Zum Beispiel der Subunternehmer in einer Projektabwicklung, der Lieferant, der Auftraggeber, usw.

7.2 Einschätzung der „Methode EPK“

241

Weitere Hinweise zur effizienten Modellierung finden sich als „Tipps“ verstreut im Text. Vgl. das Stichwortverzeichnis für eine Gesamtliste. 7.2 7.2.1

Tipps im Text

Einschätzung der „Methode EPK“ Grenzen der Prozessorientierung

Ereignisgesteuerte Prozessketten beruhen auf dem Prozessgedanken. Damit sind sie natürlich auch den ganz allgemeinen Grenzen der Prozessorientierung unterworfen. Diese bestehen in erster Linie darin, dass sich die prozessorientierten Ansätze nur um die Abläufe als solche und um keine anderen Aspekte von Geschäftsprozessen kümmern. Zum Beispiel nicht um die Effizienz des Ressourceneinsatzes, worauf Becker und Meise hinweisen: „So ist es nicht verwunderlich, dass Business Process Reengineering-Projekte dort scheitern, wo nicht Prozess-, sondern Ressourceneffizienz, wo nicht kürzeste Reaktionszeiten, sondern Auslastung von Maschinen für den Erfolg des reorganisierten Unternehmensteils verantwortlich sind.“ [Becker und Meise 2000, S. 110] Auch die Qualität, mit der die in den Funktionen modellierten Tätigkeiten umgesetzt werden, wird natürlich von Ereignisgesteuerten Prozessketten in keiner Weise thematisiert. Dazu gehört auch die effiziente Nutzung der für bestimmte Aufgaben zur Verfügung stehenden Information. Auch zu lange Durchlaufzeiten sind nicht direkt erkennbar, zumal ja der Zeitverbrauch für Funktionen nicht modelliert wird. Diese können nicht nur durch eine ineffiziente Erledigung von Tätigkeiten entstehen, sondern auch durch einen ineffizienten Kontrollfluss oder durch zu lange Transport- und Liegezeiten. Letztere sind auch nicht ohne weiteres in Ereignisgesteuerten Prozessketten zu erkennen, zumal sie meist sehr nachlässig modelliert werden. Informelle Strukturen bleiben, auch wenn sie u.U. für einen Geschäftsprozess von großer Bedeutung sind, der „Methode EPK“ völlig verborgen. Dies hat teilweise mit der Nutzung von im Unternehmen vorhandenen Wissen zu tun (z.B. in der Form: Bei Lieferungen nach Mittelamerika kann ich Frau X in der Abteilung ABC fragen, die kennt sich mit den dortigen Zollverhältnissen sehr gut aus), aber nicht nur. Die gesamte informelle Organisation, die informellen Kommunikationsbeziehungen und das informelle Beziehungsgeflecht („kleiner Dienstweg“) bleiben also unberücksichtigt. Damit stoßen Optimierungsbemühungen mithilfe von Ereignisgesteuerten Prozessketten natürlich an Gren-

Qualität von Funktionen

Zu lange Durchlaufzeiten

Informelle Strukturen

242

Wissen und Wissensmanagement

zen. Will man diesbezüglich auch den informellen Part des Geschehens berücksichtigen, sind weitere Anstrengungen, z.B. mit Methoden der Soziometrie vonnöten. Dies gilt dann auch für Betriebswirtschaftliche Standardsoftware. Auch sie ignoriert die informelle Welt zu Gunsten der formellen. Dies bringt der Trend zu einer immer weitergehenden Automatisierung der Geschäftsprozesse mit sich. Geschäftsprozesse bedürfen in Wirklichkeit nicht nur der informationellen Absicherung durch Informationsobjekte, sondern auch durch Wissen. Dieses Wissen spielt in vielfacher Weise mit, z.B. als Expertenwissen oder als Wissen über die organisationellen Strukturen. Von einer auch nur ansatzweise sinnvollen Nutzung dieses Wissens (neudeutsch: Knowledge Management) ist moderne Betriebswirtschaftliche Standardsoftware weit entfernt und Ereignisgesteuerte Prozessketten sind genauso weit davon entfernt, dieses Wissen auch nur mit zu berücksichtigen geschweige denn, es zu modellieren. Dies ist an sich nicht tragisch, würde nicht dadurch die Bedeutung eben dieses Wissens für die effiziente Abwicklung von Geschäftsprozessen oftmals nicht wahrgenommen. 7.2.2

Aufbauorganisation vs. Prozessstruktur

7 Ereignisgesteuerte Prozessketten bewältigen

Gefahren der Prozessorientierung

Gemessen an den Möglichkeiten der Prozessorientierung erscheinen die Gefahren gering. Auf eine soll jedoch hingewiesen werden. Eine prozessorientierte Sicht hat immer das Ziel, einzelne Geschäftsprozesse zu identifizieren, in den Vordergrund zu stellen und organisatorisch zu verankern. Dabei werden dann u.U. bestimmte Funktionen zu sehr von einem einzelnen Geschäftsprozess geprägt. Daraus können, worauf Kieser hinweist, Probleme entstehen, da natürlich viele Funktionen in verschiedenen Geschäftsprozessen benötigt werden und eine Ausrichtung auf den einen Geschäftsprozess evtl. Nachteile in einem anderen bringt >Kieser 1996, S. 249@. Dies kann tatsächlich in der Praxis beobachtet werden. Letztendlich müssen bei der diesbezüglichen (prozessorientierten) Konkretisierung der Aufbauorganisation immer alle Geschäftsprozesse, in denen die Funktion gebraucht wird, im Blick behalten werden. Hier spiegelt sich der Konflikt zwischen der klassischen Aufbauorganisation und einer prozessorientierten Strukturierung des Unternehmens wider. Eine vollkommen geschäftsprozessorientierte Aufbauorganisation ist, selbst bei Konzentration auf Kernprozesse, nicht denkbar, weil sich Geschäftsprozesse natürlich überlappen und ganz oder teilweise dieselben Funktionen enthalten und es – zumindest beim derzeitigen Stand der Informationstechnik – sinnvoller ist, diese Funktionen losgelöst von den einzelnen Geschäftsprozessen zu organisieren.

7.2 Einschätzung der „Methode EPK“

7.2.3

243

Möglichkeiten und Grenzen von EPKs

Ereignisgesteuerte Prozessketten eignen sich sehr gut für die Beschreibung standardisierter Abläufe. Diese lassen sich problemlos, wenn einige Regeln beachtet werden, in das lineare und sequenzielle Schema von Ereignisgesteuerten Prozessketten abbilden. Sie sind nicht geeignet für Abläufe, die nicht diesem Schema entsprechen, deren mögliche „Wege“ nur unzureichend vorherbestimmbar sind. Sie sind auch nicht geeignet für kreative oder auch nur komplexe Tätigkeiten. Um hier einsetzbar zu sein, müsste das Instrumentarium der „Methode EPK“ gewaltig erweitert werden, was dann aber ihre Einsetzbarkeit für standardisierte Abläufe wiederum einschränken würde. Vielleicht das wichtigste Ergebnis der Beschäftigung mit Geschäftsprozessen ist, dass ein Überblick über das Geschehen im Unternehmen gewonnen wird, der auf andere Weise kaum zu erreichen wäre. Dieses tiefere Verständnis für die Abläufe im Unternehmen öffnet dann auch den Blick für Optimierungsmaßnahmen. Die einzelnen Geschäftsprozesse in einem Unternehmen stehen in Beziehung zu zahlreichen Funktionen und Tätigkeiten quer durch alle traditionellen Organisationsbereiche wie Produktion, Einkauf, Verkauf, Finanzbuchhaltung, usw. Somit macht die Erstellung der Prozessmodelle auch die Interaktionen zwischen den verschiedenen Bereichen deutlich. Relativ problemlos können Strukturen erkannt werden, wo dieselbe Information nacheinander auf verschiedene Informationsträger gebracht wird. Dies bedeutet immer eine Hemmung des Informationsflusses und dadurch eine Senkung der Produktivität. Diese Medienbrüche schaffen Schnittstellen, deren Überwindung mit großem Arbeitsaufwand verbunden ist. Einige Beispiele mögen dies verdeutlichen: x x

x

x

x

Mehrfacharbeit: Informationen, z.B. zu einem Angebot, werden zum einen in einer Datenbank erfasst, zum anderen für die Ausformulierung in einem Textsystem. Informationsverluste: Werden Informationen auf unterschiedlichen und evtl. zahlreichen Trägern erfasst und nicht in einer integrierten Datenbank ist ganz grundsätzlich die Gefahr des Verlustes erhöht mit der Konsequenz erhöhter Kosten für Wiederbeschaffung. Schnittstellen: Informationen müssen über verschiedene Hardwareplattformen und Softwarepakete hinweg transponiert werden (vgl. auch die Ausführungen zum „Leidensdruck“ in Abschnitt 3.5), was einen immensen Aufwand an Arbeit und Material erfordert. Menschgestützte Rechnerkommunikation: Informationen können den Weg von einem Rechner A zu einem Rechner B nur bewältigen, indem sie am Bildschirm des Rechners A abgeschrieben und an Rechner B eingegeben werden. Menschgestützte Unterprogrammkommunikation: Informationen können den Weg von einem Unterprogramm A einer Software zu einem

Nur für standardisierte Abläufe

Gesamtüberblick

Medienbrüche

Mensch hilft Rechner

Mensch hilft Programm

244

7 Ereignisgesteuerte Prozessketten bewältigen

anderen Unterprogramm B derselben(!) Software nur bewältigen, indem sie von einer Ausgabemaske A abgeschrieben und in einer Eingabemaske B wieder eingegeben werden.

Data Warehouse

Organisationsbrüche

Die beiden letzten Fälle sind nicht so selten, wie man denkt. Selbst den eigentlich undenkbaren letzten Fall trifft der Verfasser immer wieder an. Ist diese menschgestützte Unterprogrammkommunikation63 nötig, handelt es sich natürlich um ein klares Defizit der Software, das eigentlich zwischen Ersteller und Abnehmer unstrittig sein und behoben werden sollte. Beides ist aber oft nicht der Fall. Einige der wichtigsten Schnittstellen in der derzeitigen Informatikinfrastruktur der Unternehmen ist zweifellos die zwischen PC-Welt und sonstiger EDV (mittlere Datentechnik bzw. Großrechner). Diese Schnittstellen werden wohl auf absehbare Zeit nicht vermeidbar sein. Eine andere Quelle für neue Schnittstellen dieser Art sind die Data Warehouse – Technologien. Da hier von vielen unterschiedlichen Plattformen und Datenbank- oder Dateisystemen Informationen zusammengefasst werden müssen, ergeben sich zwangsläufig sehr viele Schnittstellen. Natürlich können Medienbrüche nur bestimmt werden, wenn die Informationsobjekte in den Ereignisgesteuerten Prozessketten sorgfältig mitmodelliert werden, was oft nicht geschieht, da es aufwändig ist. Insbesondere dann, wenn die Klärung der Medienbrüche im Vordergrund steht, sollten die Informationsobjekte sehr detailliert erfasst und modelliert werden. Wenn es sich um elektronische Informationsträger handelt, z.B. mit Angaben zur Hardware und zur Software. Hilfreich können hier Software Tools wie das ARIS-Toolset sein, die allein schon aufgrund ihres Aufbaus die integrierte Beschreibung von Prozessen und Informationsobjekten nahe legen. Mit der gründlichen Erfassung der Informationsobjekte werden dann auch gleichzeitig die Informationsflüsse, wie sie im Rahmen der Prozessabwicklung entstehen, mit modelliert. Die Erfassung der Organisationseinheiten in den Ereignisgesteuerten Prozessketten erlaubt in einem gewissen Umfang das Erkennen von Organisationsbrüchen (bei [Kugeler und Vieting 2000, S. 190] aufbauorganisatorische Schnittstellen genannt). Damit ist gemeint, dass ein Geschäftsprozess unnötig oft die Organisationseinheit, bzw. die bearbeitende Person wechselt. Hier liegt ein großes Optimierungspotenzial. In der Ereignisgesteuerten Prozesskette ist dies wiederum nur erkennbar, wenn genügend genau modelliert wird. Sind wirklich nur die Organisationseinheiten angegeben und nicht die Stellen, können diese Defizite auch verborgen bleiben.

63

Mit Unterprogramm soll hier nicht der konkrete Aufbau dieser Programme angesprochen werden, sondern die Tatsache, dass an verschiedenen Stellen des Programms, die sich durch Eingabemasken und Ausgabeschirme manifestieren und die tatsächlich oft durch verschiedene Unterprogramme (bei konventioneller Programmierung) realisiert werden, die beschriebene menschgestützte Informationsweitergabe erfolgen muss.

7.2 Einschätzung der „Methode EPK“

245

Oftmals ergibt sich hier ein Widerspruch zwischen Optimierung und Kontrolle. Der Wechsel der bearbeitenden Person oder der Abteilung erfolgt ja oft, um Kontrolle und Überwachung zu gewährleisten („4-AugenPrinzip“). Ein einfaches Beispiel ist, wenn Beschaffungen über einer gewissen Grenze von der Abteilungsleitung oder sogar von der Geschäftsführung gegengezeichnet werden müssen. Hier ist somit ein Abwägen erforderlich: Welche „Brüche“ sind nötig, um die Sicherheitsstandards zu gewährleisten, welche sind überflüssig und können beseitigt werden.

Optimierung vs. Kontrolle

8 Beispiel für eine Unternehmensmodellierung

In den Neunzigern Die Unternehmensmodellierung der SAP ist in vielfacher Hinweise lehrreich. Deshalb wurde die Darstellung der vorigen Auflagen hier dringelassen, auch wenn die SAP inzwischen ein verändertes Konzept hat. Das Konzept und die verwendeten Methoden (die sich im wesentlichen nicht geändert haben) sind ein gutes Beispiel, wie eine konkrete praxisorientierte Unternehmensmodellierung aussehen kann.

Dieses Kapitel verfolgt zwei Ziele. Zum einen möchte es einen Eindruck davon geben, wie eine kompetente Modellierung der Unternehmensrealität („Unternehmensmodellierung“) in der Praxis aussehen kann (am ausgereiftesten Beispiel, dem SAP-Ansatz), zum anderen soll die Rolle Ereignisgesteuerter Prozessketten in diesem Kontext deutlich gemacht werden.

8.1

Das Konzept und die Elemente

Das Ansinnen ist sehr ambitiös: Alle Strukturen und Abläufe eines – vorgedachten/abstrahierten - Unternehmens, seine Aufbau- und Ablauforganisation sowie auch seine Einbettung in die informationelle und wirtschaftliche Umwelt, alles dies soll in einem Informationssystem so modelliert werden, dass die zu leistenden Aufgaben effizient erledigt werden können. Entsprechend umfangreich ist die Modellierungsarbeit, die hier zu leisten ist. Hinzu kommt, dass die Entwickler der SAP (und die der anderen Anbieter Betriebswirtschaftlicher Standardsoftware) – natürlich - davon ausgehen, dass Unternehmensstrukturen und -abläufe grundsätzlich und weitgehend formalisierbar sind und DV-gestützt realisiert werden können und dass die DV-Durchdringung oder –Unterstützung weiter getrieben werden muss. SAP unterscheidet seit dem Releasestand 3.1 ein (Æ)Referenzmodell (die ältere Modellinformation) und (neu) ein Prozessmodel. Beide verfol-

Das Konzept bzw. die Philosophie

Referenzmodell und Prozessmodell

248

8 Beispiel für eine Unternehmensmodellierung

gen das Ziel, den „betriebswirtschaftlichen Leistungsumfang des R/3Systems einheitlich und strukturiert zu beschreiben“ (SAP). Zum Referenzmodell gehören folgende Objekte [R/3-Referenzmodell 3.0F, S. 2.2]: x x x x x x

Funktionen Ereignisse Informationsobjekte (Entitätstypen) Systemorganisationseinheitstypen Organisationseinheiten Objektidentifizierer

und folgende Modelle: x x x x x x x x

Prozessauswahlmatrizen Szenarioprozesse Ereignisgesteuerte Prozessketten Funktionshierarchien Kommunikationsbeziehungen Systemorganigramme Informationsflussdarstellungen Informationsobjektzuordnungen

Als Grundelemente des R/3-Referenzmodells sieht die SAP [R/3-Referenzmodell 3.0F, S. 2.2]: x x x x

Funktionen (Was?) Ereignisse (Wann?) Systemorganisationseinheitstypen (Wer?) und Informationsobjekte/Entitätstypen (mit welchen Informationen?)

Das R/3-Prozessmodell besteht aus folgenden Objekten (SAP-Sichtweise in [R/3-Prozessmodell 3.1G]): x x x x x x x x

Komponenten Szenarioprozesse Prozesse Funktionen Ereignisse Organisationseinheiten Business-Objekte Entitätstypen

und folgenden Prozessmodellen: x x

Szenarioprozesse Prozesse

8.1 Das Konzept und die Elemente

249

Die Aufgabe des Referenzmodells ist es, verschiedene Modellinformationen, die insgesamt die „aufbau- und ablauforientierten Aspekte“ (SAP) eines Unternehmens konzeptionell abbilden, zur Verfügung zu stellen. Bis zum Release 3.0 lag der Schwerpunkt auf der Darlegung der Integration der Komponenten. Beginnend mit dem Stand 3.1G wird das R/3Prozessmodell, das so verstanden einen Teil des Referenzmodells ausmacht, zusätzlich um industriespezifische Strukturen ergänzt. Dies hängt mit den Bemühungen der SAP zusammen, R/3 von einem „Produkt für alle“ umzuwandeln in eines mit mehreren branchenspezifischen Varianten. Diese „Variantenbildung“ muss dann natürlich auch modelltechnisch abgesichert werden. Dies bedeutet dann, dass die jeweiligen Geschäftsprozesse auf die Strukturen und Abläufe eines bestimmten Wirtschaftssektors oder einer Branche zugeschnitten sind. Mit dem Stand 3.1 beschreibt das Prozessmodell weiterhin schwerpunktmäßig den Wirtschaftssektor Industrie. Aus welchen Elementen besteht nun ein solches Unternehmensmodell der SAP im Kern? Betrachten wir zuerst die Basiselemente, d.h. die originären, mit denen wirklich modelliert wird und die nicht nur der besseren Übersichtlichkeit wegen (Übersichtsnotationen sollen diese im weiteren genannt werden) eingefügt wurden. Im Mittelpunkt stehen die oben eingeführten Ereignisgesteuerten Prozessketten. Sie beschreiben Geschäftsprozesse bzw. Geschäftsprozessabschnitte und stellen somit die formale Fassung der Ablauforganisation dar. Ihre spezifische SAP-Ausprägung und die davon abgeleiteten Komponenten wurden oben schon kurz angeführt und werden im folgenden Abschnitt 8.2 betrachtet. Von zentraler Bedeutung bei der zielgerichteten Modellierung eines Unternehmens ist die Beschreibung der Informationsstrukturen, der informationellen Basis. Hier geht es darum, die für das Unternehmen benötigten Informationen zusammenzustellen und, gemäß den derzeit dominierenden Datenbanktechniken zu strukturieren. Letzteres geschieht in der Regel und so auch hier auf zwei Ebenen, einer sog. semantischen, die sich eher an den Strukturen, Abläufen und Regeln der Realität orientiert und diese möglichst umfassend abzubilden versucht und einer weiteren, die direkten Bezug auf die Datenstrukturen des verwendeten Datenbanksystems nimmt. Das Semantische Datenmodell wird bei SAP R/3 mithilfe einer gegenüber der Theoriediskussion leicht veränderten Entity RelationshipNotation beschrieben, den sog. SAP-SERM’s. Diese werden in Abschnitt 8.3 beschrieben. Die zweite Ebene erfolgt ganz nach dem relationalen Ansatz und endet somit in (relational) miteinander verknüpften Tabellen (Relationen). Einige weitere grafische Notationen bauen auf den oben angeführten auf und dienen v.a. der Erhöhung der Übersichtlichkeit: x

Szenarien oder Szenarioprozesse dienen der Zusammenstellung zusammengehöriger EPKs (vgl. Abschnitt 8.2.2) und helfen somit die

Referenzmodell Prozessmodell Spezifizierung der Modellinformation

Im Kern des Ansatzes

Informationsstrukturen

Übersichtsnotationen

250

x x

Hauptanteile der Modellierungsarbeit

8 Beispiel für eine Unternehmensmodellierung

Übersicht zu bewahren in der großen Menge von Prozessbeschreibungen. Wertschöpfungsketten (WSK) dienen der übersichtlicheren Darstellung der Szenarien (vgl. Abschnitt 8.2.3) Business Objekte helfen, sich in der Menge an Informationen in den Semantischen Datenmodellen zurechtzufinden. .Auf sie wird in Abschnitt 8.3.4 kurz eingegangen.

Die Hauptanteile der Modellierungsarbeit (qualitativ und auch quantitativ) liegen tatsächlich in der Beschreibung der Geschäftsprozesse und in der Modellierung der Datenbanken. Der eine Bereich beschreibt die Abläufe, die dynamischen Aspekte, der andere die informationellen Strukturen, die eher statischen Aspekte der betrachteten Realwelt64. In Anlehnung an den entsprechenden Begriff der Datenbanktheorie soll diese als Weltausschnitt bezeichnet werden.

64

Mit “eher statisch” soll ausgedrückt werden, dass sie stabil im Zeitverlauf sind, was aber nicht heißt, dass sie sich gar nicht im Zeitverlauf ändern, im Gegenteil!

8.1 Das Konzept und die Elemente

Abbildung 8.1-1:

251

Grundzüge der Unternehmensmodellierung

Dieser Gegensatz – dynamisch vs. statisch – prägt alle Ansätze heutiger Unternehmensmodellierung, von der konzeptionellen Modellierung bis zum Softwaredesign (deutlich auch, wenn, z.B. wie bei R/3, Datenbanksystem und Prozesssoftware strikt getrennt sind). Abbildung 8.1-1 fasst dies zusammen. Ausgangspunkt ist ein beliebiger Weltausschnitt. In diesem müssen zum einen die informationellen Strukturen identifiziert werden (Position 1 in der Abbildung), zum anderen die Abläufe, im weitesten Sinn (Position 2 der Abbildung). Die Analyse der Strukturen führt - wie in der Datenbanktheorie und praxis üblich - zum Semantischen Datenmodell und dann zur (heute meist) Relationalen Datenbank. In der Zukunft werden hier mit Sicherheit objektorientierte Datenbanktechniken Einzug halten.

Strukturen und Abläufe

252

Software und Modellinformation

Die Datenbanken sind damit so etwas wie das informationelle Gerüst des Weltausschnitts. In moderner Auffassung könnte bzgl. der Zielsetzung von Datenbanken gesagt werden, dass sie die Informationen erfassen, die zur Abwicklung der Geschäftsprozesse nötig sind. Auf der anderen Seite (vgl. Abbildung 8.1-1) werden die Geschäftsprozesse identifiziert (Position 2) und mithilfe der Ereignissteuerung in Prozessmodelle überführt (4). Modelltechnisch erfolgt hier die Verknüpfung zum Datenmodell über die Funktionen (5). Die daraus entstehenden Programme agieren dann im Wesentlichen mithilfe von SQL-Befehlen mit den Datenbeständen, im Falle SAP R/3 unter Nutzung eines zwischengeschalteten Datenbanksystems. Die in der Software realisierten Geschäftsprozesse und die mitgelieferten Ereignisgesteuerten Prozessketten stehen im SAP R/3 in einer unmittelbaren Verknüpfung. Die durch die grafische Notation dokumentierten Geschäftsprozesse beschreiben die R/3-Funktionen und die Reihenfolge, in der sie durchlaufen werden. Ein Prozess hat eine technische Entsprechung in den Transaktionen des R/3-Systems und kann eine oder mehrere Transaktionen beschreiben. Was den Funktionsumfang angeht entspricht ein Prozess häufig einer Transaktion des R/3-Systems, kann aber auch mehrere umfassen.

8.2 8.2.1

Grafische Notation

8 Beispiel für eine Unternehmensmodellierung

Ereignisgesteuerte Prozessketten Basis-EPKs

Mit Basis-EPKs sind die eigentlichen Ereignisgesteuerten Prozessketten gemeint, die nicht zusammengefasst sind zu Szenarien, usw. Rund 1100 beschreiben in SAP R/3 die vorgedachten Geschäftsprozesse. Die Grundversionen sind an den Strukturen und Abläufen der Industrie orientiert. Auf verschiedene Branchen bzw. Sektoren zugeschnittene Versionen wurden und werden entwickelt. Z.B. für die Druckindustrie, das Kreditwesen oder die Öffentliche Verwaltung. Diese „zugeschnittenen“ Versionen sind Teil der Maßnahmen der SAP, um das Produktspektrum auszuweiten und für die Zeit nach dem Jahr 2000 und nach der EUROUmstellung gewappnet zu sein. Die grafische Notation der SAP-EPKs orientiert sich im Kern an der Vorgabe von Scheer (vgl. z.B. [Scheer 1997]). Auf einige grafische Besonderheiten soll im Folgenden hingewiesen werden. Doppelte Operatoren wie auf der linken Seite der folgenden Abbildung werden in SAP R/3 und bei einigen Autoren so dargestellt wie hier auf der rechten Seite. Dabei werden die beiden Operatoren in eigene Kreise gestellt und durch einen Pfeil verbunden.

8.2 Ereignisgesteuerte Prozessketten

Abbildung 8.2-1:

253

Alternative Anordnung von „Doppeloperatoren“

Grundsätzlich wird in SAP-EPKs im Übrigen für den XODER-Operator die Zeichenfolge XOR verwendet und nicht das grafische Symbol. Eine zweite Besonderheit, die vorübergehend SAP-EPKs prägte, zeigt die folgende Abbildung. Gehen mehrere Zweige von einem Operator aus (wie in der Abbildung links), werden sie in SAP-EPKs teilweise nicht vom Operator weggeführt, sondern von einem der anderen Zweige, wie in der Abbildung rechts gezeigt.

Abbildung 8.2-2:

Alternative Anordnung von Mehrfachzweigen

Dies wird bei Verteilern und Verknüpfern gleichermaßen so gemacht und auch dann, wenn gleichzeitig mehrere Zweige ankommen und weggehen. Das folgende Beispiel in Abbildung 8.2-3 (etwas verkürzt aus einer SAP-EPK) soll die obigen Besonderheiten zusammenfassen und vertiefen. Gleichzeitig leitet es zum nächsten Abschnitt über, zu den semantischen Besonderheiten der SAP-EPKs, denn es zeigt den Start einer Ereignisgesteuerten Prozesskette über mehrere Prozesswegweiser. Die zweite Abbildung 8.2-4 zeigt – sozusagen – die grafische Standardnotation, wie sie in Kapitel 4 eingeführt wurde.

254

8 Beispiel für eine Unternehmensmodellierung

Abbildung 8.2-3:

Nicht erweitert!

SAP-Dialekt

Alternative Anordnung – Zusammenfassendes Beispiel, SAP-Variante Quelle: Teil einer Ereignisgesteuerten Prozesskette aus SAP R/3, installiert an der Berufsakademie Ravensburg (bis 2001), Fachrichtung Wirtschaftsinformatik. Vom Verfasser grafisch bearbeitet.

Mit diesen Hinweisen dürfte die Analyse von SAP-EPKs keine Schwierigkeiten mehr bereiten. Doch nun zur Betrachtung der Besonderheiten. SAP-EPKs sind (einfache) EPKs und keine erweiterten Ereignisgesteuerten Prozessketten, d.h. die Informationsobjekte und Organisationseinheiten sind in der Grafik nicht angegeben. Sie können allerdings problemlos bestimmt werden, indem die Navigationsmöglichkeiten des Business Navigators genutzt werden. Die SAP-EPKs sind semantisch auf einer mittleren Ebene angesiedelt. Sie spiegeln unmittelbar die Ablauflogik des Programms R/3 wider, was ja auch ihre Hauptaufgabe ist. In der Sprache von SAP wird dies so be-

8.2 Ereignisgesteuerte Prozessketten

255

schrieben, dass eine Funktion „die kleinste abgeschlossene Funktionalität des R/3-Systems“65 darstellt.

Abbildung 8.2-4:

Standard-Anordnung von Mehrfachverzweigungen und „Doppeloperatoren“

Eine Konsequenz davon ist, dass Tätigkeiten, die auf Programmseite nicht durch Transaktionen, d.h. irgendwie geartete Programmseiten reflektiert werden, nicht in der Ereignisgesteuerten Prozesskette auftauchen. Z.B. eine Funktion wie Warten auf die Entscheidung von Bewerbern oder Kundenkontakt durchführen (vgl. hierzu die Ereignisgesteuerte Prozesskette Kontaktbearbeitung). Dies macht die SAP-EPKs an einigen Stellen etwas schwer lesbar. Ganz anders wird modelliert, wenn, z.B. im Rahmen einer Einführung Betriebswirtschaftlicher Standardsoftware, einfach nur real vorliegende Geschäftsprozesse modelliert werden (vgl. die Beispiele in Kapitel 6). Weiter oben wurden schon einige SAP-EPKs angeführt: x x x

Grunddatenbearbeitung in Abbildung 4.8-1 Lieferantenstammbearbeitung in Abbildung 4.8-2 Kontaktbearbeitung in Abbildung 4.8-3 und folgende

65

R/3-Hilfe: CA - R/3-Referenzmodell, Stichwort „Die Funktion“

Ist-Analyse von Geschäftsprozessen oder Beschreibung prozessorientierter Software

256

Enge Verknüpfung

Vgl. Abbildung 8.2-5

Eingefügter Subprozess

8 Beispiel für eine Unternehmensmodellierung

Betrachten wir noch zwei Beispiele66. Zuerst einen etwas längeren Geschäftsprozess mit der Bezeichnung Stellenbeschreibung. Er ist in den Abbildungen 8.2-5 – 8.2-9 angegeben. Zusammen mit dem folgenden Geschäftsprozess Anforderungsprofilbearbeitung zeigt er auch ein Beispiel für einen eingefügten Subprozess. In Abbildung 8.2-9 ganz oben ist der Prozesswegweiser Anforderungsprofilbearbeitung in den Geschäftsprozess Stellenbeschreibung eingefügt. Der somit „aufgerufene“ Geschäftsprozess ist nachfolgend angegeben. Er startet mit einem entsprechenden Prozesswegweiser, der auf den aufrufenden verweist. Da es sich hier um einen eingefügten Subprozess handelt, muss am Schluss der Anforderungsprofilbearbeitung ein Prozesswegweiser kommen, der quasi zurückverweist in den aufrufenden Prozess (vgl. Abschnitt 4.5 für eine Diskussion der Verknüpfung durch Prozesswegweiser). Grundsätzlich gilt, dass die SAP-EPKs umfassend durch Prozesswegweiser verknüpft sind. Bei nicht wenigen SAP-EPKs finden sich am Anfang und am Ende zahlreiche Prozesswegweiser, die diese Verknüpfung repräsentieren. Doch nun die beiden Geschäftsprozesse im Einzelnen67. Damit der Geschäftsprozess Stellenbeschreibung startet, müssen gleich mehrere Bedingungen erfüllt sein. Zum einen muss, angegeben durch den Prozesswegweiser Aufbauorganisationsbearbeitung, ein Aufruf dieses Geschäftsprozesses erfolgen, zum anderen muss mindestens eines der Ereignisse Stellenbeschreibung ist zu bearbeiten und Arbeitsabläufe sind festgelegt eingetreten sein. Dem Operator ODER entsprechend können aber auch beide Ereignisse eingetreten sein. Es folgen die zwei Funktionen Stelle/Funktion bearbeiten und Stelle/Funktion verbal beschreiben mit ihren (syntaktischen) Ergebnisereignissen. Die dann folgende Funktion Notwendigkeit von Laufbahnmodellen prüfen führt entweder zur Verneinung oder Bejahung. Im letzteren Fall wird dann noch die Stelle in das Laufbahnmodell aufgenommen. Danach werden, wieder mit einem XODER, die Zweige wieder zusammengeführt. Es folgt die Funktion Planstelle aus Stelle ableiten. Ist dies geschehen, führt die nächste Funktion Relevanz des Arbeitsplatzes prüfen entweder zur Anlage (HR-Arbeitsplatz ist anzulegen) oder zur Bearbeitung eines Arbeitsplatzes (Arbeitsplatz ist für Hr zu bearbeiten). Im ersten Fall erfolgt die Anlage (HR-Arbeitsplatz anlegen: Abbildung 8.2-6 unten), dann wird der Arbeitsplatz einer Planstelle zugeordnet (Abbildung 8.2-7 oben). Im zweiten Fall folgt ein eingefügter Subprozess Arbeitsplatzbearbeitung. Das dem Prozesswegweisersymbol folgende Ereignis Arbeitsplatz ist für HR bearbeitet (Abbildung 8.2-7) ist gleichzeitig das letzte Ereignis 66 67

Weil es hier nur um die Methode geht und nicht um Inhalte (und auch aus Platzgründen) wurden für dieses Buch nur sehr einfache und inhaltlich leicht nachvollziehbare SAP-EPKs ausgewählt. Wieder sollen die Ereignisgesteuerten Prozessketten nur syntaktisch, nicht semantisch (inhaltlich) interessieren.

8.2 Ereignisgesteuerte Prozessketten

257

im Subprozess Arbeitsplatzbearbeitung vor dem „Rücksprung“ (vgl. Abschnitt 4.6). Danach werden die beiden Zweige wieder zusammengeführt und die Funktion Notwendigkeit zur Aufgabengliederung prüfen angestoßen.

Abbildung 8.2-5:

Stellenbeschreibung – Teil 1

258

8 Beispiel für eine Unternehmensmodellierung

Quelle für obiges EPK-Fragment und alle hier anschließenden Beispiele aus der SAP-Unternehmensmodellierung: SAP R/3, installiert an der Berufsakademie Ravensburg (bis 2001), Fachrichtung Wirtschaftsinformatik. Vom Verfasser grafisch bearbeitet.

Abbildung 8.2-6:

Stellenbeschreibung – Teil 2

8.2 Ereignisgesteuerte Prozessketten

Abbildung 8.2-7:

259

Stellenbeschreibung – Teil 3

Diese Funktion hat zwei mögliche Ergebnisse, angedeutet durch entsprechende Ereignisse. Entweder ist die Aufgabenbeschreibung nicht notwendig, dann geht der Kontrollfluss hier gleich weiter zum verknüpfenden XODER-Operator, oder sie ist notwendig, dann werden nacheinander drei Funktionen angestoßen: x x x

Aufgaben(-Katalog bearbeiten Stellen durch Aufgaben beschreiben Planstelle durch Stelle/Aufgabe beschreiben

Im Anschluss trifft auch dieser Zweig auf den verknüpfenden XODEROperator.

Vgl. Abbildung 8.2-8

260

8 Beispiel für eine Unternehmensmodellierung

Schlussereignis

Abbildung 8.2-8:

Stellenbeschreibung – Teil 4

Nach dem Zusammenführen der beiden Zweige wird die Funktion Anforderungsprofilbearbeitung prüfen angestoßen. Diese führte entweder zu einer rudimentären Stellenbeschreibung, womit der Geschäftsprozess beendet ist (Schlussereignis) oder zu einer Anforderungsprofilbearbeitung.

8.2 Ereignisgesteuerte Prozessketten

Abbildung 8.2-9:

261

Stellenbeschreibung – Teil 5

Der Geschäftsprozess Anforderungsprofilbearbeitung ist wieder ein eingefügter Subprozess, der durch einen Prozesswegweiser aufgerufen wird. Er ist in der nachfolgenden Abbildung 8.2-10 angegeben.

262

Bedeutung von Ereignissen

Start durch Prozesswegweiser

8 Beispiel für eine Unternehmensmodellierung

Das Ergebnis der nachfolgenden Funktion und die dabei zu leistende Arbeit ist durch mindestens eines der Ereignisse Stelle ist ausgewählt, Aufgabe ist ausgewählt und Planstelle ist ausgewählt festgelegt. Der Kontrollfluss geht danach in einem Zweig weiter. Man sieht hier sehr deutlich eine der Bedeutungen von Ereignissen in diesen Prozessketten: sie sollen das Spektrum der möglicherweise anfallenden Arbeiten beschreiben, ohne dass deren konkrete Ausprägung den weiteren Ablauf beeinflusst. Mit der Funktion Anforderungsprofile zuordnen und dem Anstoßen dreier Subprozesse findet diese Ereignisgesteuerte Prozesskette ihr Ende. Bei diesen Subprozessen handelt es sich um angehängte (vgl. zu angehängten und eingefügten Subprozessen Abschnitt 4.5). Diese intensive Verknüpfung mit Prozesswegweisern ist durchaus typisch für SAP-EPKs. Sie entspricht, wie ja die Ereignisgesteuerten Prozessketten als solche, der Ablauflogik des Programms. In der folgenden Abbildung ist nun noch die kurze Ereignisgesteuerte Prozesskette Anforderungsprofilbearbeitung angegeben. Sie wird von der oben beschriebenen Stellenbeschreibung aufgerufen, weshalb sich der entsprechende Prozesswegweiser am Beginn findet. Das ihm folgende Ereignis Anforderungsprofile sind zu bearbeiten steht auch im aufrufenden Prozess vor dem Prozesswegweiser, der dort den Aufruf angibt. Die Anforderungsprofilbearbeitung kann aber auch durch ein Startereignis Arbeitsabläufe haben sich geändert oder aber durch beides aufgerufen werden. Dies zumindest sagt der ODER-Operator aus. Danach folgen eine Reihe von Funktionen mit ihren Ergebnisereignissen bis zu dem Ereignis Anforderungsprofil ist erstellt. Dieses ist auch in der Stellenbeschreibung, nach dem aufrufenden Prozesswegweiser wiederholt. Am Schluss der Ereignisgesteuerten Prozesskette Anforderungsprofilbearbeitung wird dann noch in zwei weitere Subprozesse verwiesen, die beide aufzurufen sind. Diese beiden SAP-EPKs zeigen einige Merkmale, die auch durch die Analyse zahlreicher anderer bestätigt werden: x x x

Die Funktionen sind meist auf einem mittleren Niveau, etwa so, was einen betriebswirtschaftlichen Vorgang bzw. eine Transaktion ausmacht. Diese Ebene ist durch die Software festgelegt. Die einzelnen Prozesse sind intensiv durch Prozesswegweiser miteinander verknüpft. Es gibt keine Rückschleifen oder repetitive Schleifen. Dies kann bei einem mittleren Niveau durchaus realisiert werden.

8.2 Ereignisgesteuerte Prozessketten

Abbildung 8.2-10:

Anforderungsprofilbearbeitung

263

264

Übersichtsnotationen

8 Beispiel für eine Unternehmensmodellierung

Wie oben schon angeführt, sind bei den Modellinformationen von SAP R/3 verschiedene Übersichtsnotationen integriert. Dies ist notwendig, um den Zugang zu der großen Informationsmenge zu erleichtern. Bezüglich der Geschäftsprozesse sind dies Szenarien und WertschöpfungskettenModelle (WSK-Modelle), deren Aufbau und Funktion im Folgenden kurz erläutert werden. 8.2.2

Aufbau

Szenarien

Es ist leicht vorstellbar, dass die große Zahl von Ereignisgesteuerten Prozessketten unübersichtlich wird, vor allem beim „Erstkontakt“. Deshalb wurden von der SAP immer wieder Übersichtsnotationen eingeführt (und auch wieder abgeschafft), die den Einstieg erleichtern sollen. Hier nun die sog. Szenarien oder Szenarioprozesse. Im Grunde besteht ein Szenario aus den Ereignisgesteuerten Prozessketten eines abgegrenzten Unternehmensbereichs. Dabei werden die Einzelprozesse im Szenarioprozess durch Symbole (hier im Folgenden Prozesssymbole genannt) repräsentiert. Die diesen Prozesssymbolen zugeordneten detaillierten Prozesse können im Business Navigator aus dem Szenarioprozess heraus geöffnet werden. Im Folgenden wird das Szenario Kostenlose Lieferung-Abwicklung exemplarisch dargestellt68. Es dürfte unter den einfachsten sein, die im R/3 anzutreffen sind (Version 3.0). Die folgende Strukturübersicht in Abbildung 8.2-11 soll bei der Erschließung helfen. Die Zahlen links und unten in der Strukturübersicht sollen als Koordinatensystem dienen. Sie sind ganz im Sinne der Schulmathematik zu verstehen: in der Waagrechten die x-, in der Senkrechten die y-Koordinate. Die Gesamtheit der Modellinformation wurde hier aus darstellungstechnischen Gründen auf 10 Fragmente aufgeteilt. Abbildung 8.2-12 zeigt das Fragment 1 und damit auch mögliche Startkonstellationen für die Ereignisgesteuerten Prozessketten dieses Szenarios. Nach dem Startereignis Kunden-Mailing-Aktion ist durchzuführen folgt dieses grafische Element, das ein Prozesssymbol darstellt:

Prozesssymbol

Es steht stellvertretend für einen ganzen Geschäftsprozess (eine ganze Ereignisgesteuerte Prozesskette), hier für die Mailing-Aktion-Bearbeitung. In derselben Abbildung ist dann diese Ereignisgesteuerte Prozesskette mithilfe von Ereignissen mit der ebenfalls oben angeführten Kontaktbearbeitung verbunden. 68

Wie bei allen SAP-EPKs in dieser Arbeit steht hier der strukturelle Aspekt, die Betrachtung der Beschreibungsmethode, und nicht der inhaltliche Aspekt im Vordergrund.

8.2 Ereignisgesteuerte Prozessketten

Abbildung 8.2-11:

265

Strukturübersicht zu Szenario Kostenlose Lieferung-Abwicklung Quelle: Erstellt nach dem gleichnamigen Szenario aus SAP R/3.

Die Fragmente 2 bis 4 (Abbildungen 8.2-13 – 8.2-15) geben nun unter anderem die Kette möglicher Prozesswegweiser an, mit denen die Prozesse der Kostenlosen Lieferung-Abwicklung aufgerufen werden können. Insgesamt sieben andere Prozesse können diesen Teil des Szenarios aufrufen. Dies macht die intensive Verflechtung dieser Ereignisgesteuerten Prozessketten mit den übrigen des Prozessmodells deutlich und ist durchaus typisch für das SAP-Gesamtmodell. Ihre Verknüpfung durch einen XODER-Operator (Position 16/39) macht deutlich, dass sie alternativ auftreten. Bei einem Durchgang erfolgt der Aufruf durch einen der aufrufenden Prozesse.

Querverbindungen

266

8 Beispiel für eine Unternehmensmodellierung

Abbildung 8.2-12:

Szenario Kostenlose Lieferung-Abwicklung – Fragment 1

Der UND-Operator bei 4/39 (Fragment 1 oben) stellt außerdem klar, dass die Kontaktbearbeitung nur tangiert wird, falls die Mailing-Aktion-Bearbeitung aktiv wurde.

8.2 Ereignisgesteuerte Prozessketten

267

Die Abbildungen 8.2-13 und nachfolgend 8.2-16 zeigen, wie der Kontrollfluss zur EPK Kostenlose Lieferung-Bearbeitung, die auch wieder durch ein Prozesssymbol repräsentiert wird, weitergeht. Diese kann alternativ auch allein durch das Startereignis Kostenlose Lieferung – Grund ist eingetreten gestartet werden (Abbildung 8.2-16 links oben).

Abbildung 8.2-13:

Szenario Kostenlose Lieferung-Abwicklung – Fragment 2

Die Fragmente 5 und 7 (Abbildungen 8.2-16 und 8.2-18) geben nun unter anderem an, wiederum über eine Leiste von Prozesswegweisern, welche Prozesse aufgerufen werden können, wenn das Ereignis Vertriebsbedarfe sind erstellt eingetreten ist. Ansonsten schreitet der Geschäftsprozess in Abschnitt 8.2-16 nach dem Ereignis Kostenlose Lieferung ist erstellt weiter zum Geschäftsprozess Lieferungsbearbeitung. Abbildung 8.2-17 zeigt, dass anschließend entweder die Lieferposition abgelehnt wird oder aber, vermittelt durch mehrere Ereignisse, die Geschäftsprozesse Transportplanung und Transportabfertigung aufgerufen werden.

268

„Isolierte“ EPKs

8 Beispiel für eine Unternehmensmodellierung

Abbildung 8.2-14:

Szenario Kostenlose Lieferung-Abwicklung – Fragment 3

Abbildung 8.2-15:

Szenario Kostenlose Lieferung-Abwicklung – Fragment 4

Im Anschluss an die Tansportdurchführung erfolgt dann die Warenausgangsbearbeitung, hier wiederum angegeben durch Prozesssymbole für die Warenausgangsbearbeitung für Lagermaterial und KonsignationsWarenausgangsbearbeitung (Positionen 8/3 und 13/3). Damit ist dann eines der möglichen Schlussereignisse (Warenausgang ist gebucht) erreicht. Damit bleiben noch zwei Ereignisgesteuerte Prozessketten übrig, die nicht direkt, d.h. durch Prozesswegweiser, mit den übrigen EPKs verbunden sind: Die Abwicklung von Leihgut in Fragment 8 (Abbildung 8.2-19) und die Abwicklung von Nachbelastungen in den Fragmenten 9 und 10 (Abbildungen 8.2-20 und 8.2-21). Ihre Verknüpfung zum Gesamtkontext geschieht sozusagen über den Ereignisraum des Unternehmens, der schon in Abschnitt 4.1 eingeführt wurde. Wenn dann also Leihgut abzuholen ist, werden die entsprechenden Prozesse aufgerufen bis die Ereignisse Versandpapiere sind erstellt/übermittelt und Wareneingang ist gebucht eintreten.

8.2 Ereignisgesteuerte Prozessketten

Abbildung 8.2-16:

269

Szenario Kostenlose Lieferung-Abwicklung – Fragment 5

Abbildung 8.2-20 behandelt die Prozesse, die durch das Ereignis Nachbelastungsgrund ist eingetreten aktiviert werden. Zuerst ist die Ereignisgesteuerte Prozesskette Leihgutnachbelastungsbearbeitung eingefügt. Danach folgen zwei Geschäftsprozesse zur Warenausgangsbearbeitung und einer zur Fakturabearbeitung (durch UND verknüpft).

270

8 Beispiel für eine Unternehmensmodellierung

Abbildung 8.2-17:

Szenario Kostenlose Lieferung-Abwicklung – Fragment 6

8.2 Ereignisgesteuerte Prozessketten

271

Abbildung 8.2-18:

Szenario Kostenlose Lieferung-Abwicklung – Fragment 7

Abbildung 8.2-19:

Szenario Kostenlose Lieferung-Abwicklung – Fragment 8

272

8 Beispiel für eine Unternehmensmodellierung

Abbildung 8.2-20:

Szenario Kostenlose Lieferung-Abwicklung – Fragment 9

Abbildung 8.2-21 zeigt mit Fragment 10 die Fortsetzung. Die Fakturabearbeitung führt entweder zu dem Ergebnis, dass die Fakturaerstellung gesperrt ist (negativer Fall) oder zu den durch entsprechende Ereignisse angegebenen Ergebnissen Exportpapiere sind erstellt/übermittelt, Faktura ist übermittelt sowie zu einem der Ereignisse Faktura ist nicht für Buchung freigegeben bzw. Faktura ist für Buchung freigegeben (positiver Fall). Nach dem letztgenannten Ereignis werden dann noch drei Prozesswegweiser angestoßen. Insgesamt sind damit in diesem Szenario folgende Geschäftsprozesse integriert69: Integrierte Geschäftsprozesse

x x x x

Fakturabearbeitung für Lagermaterial Konsignations-Warenausgangsbearbeitung Kontaktbearbeitung Kostenlose Lieferung-Bearbeitung

69

Einige tauchen, in getrennten Teilen, mehrfach auf.

8.2 Ereignisgesteuerte Prozessketten

x x x x x x x x x

273

Leihgutabholungsbearbeitung Leihgutnachbelastungsbearbeitung Leihgutrücklieferungsbearbeitung Lieferungsbearbeitung Mailing-Aktion-Bearbeitung Transportabfertigung Transportplanung Warenausgangsbearbeitung für Lagermaterial Warenzugangsbearbeitung

Abbildung 8.2-21:

Szenario Kostenlose Lieferung-Abwicklung – Fragment 10

274

Verknüpfung nach außen

8 Beispiel für eine Unternehmensmodellierung

Diese sind durch die entsprechenden Ereignisse miteinander verknüpft und mithilfe folgender Prozesswegweiser in das Gesamtmodell eingebettet: Aufrufend: x x x x x x x

Kontraktabwicklung Kundenkonsignationsabwicklung Kunden-Lieferplan-Abwicklung Lieferplanabwicklung Sofortauftragsabwicklung Streckenabwicklung Terminauftragsabwicklung

Aufgerufen werden können: x x x x x x x

Debitor Filialen-Zentralenabwicklung Debitorenabwicklung Einkaufsverbundabwicklung Debitor Einzelfertigung Losfertigung Prozessfertigung Serienfertigung

Selbst ein solches Szenario ist, v.a. bei inhaltlich tragfähigeren Unternehmensbereichen, noch sehr unübersichtlich. Dies war einer der Gründe, weshalb SAP die im folgenden Abschnitt vorgestellten Wertschöpfungsketten eingeführt hat. 8.2.3 Meta-Ebene

Wertschöpfungsketten

Jedes Element einer Wertschöpfungskette repräsentiert inhaltlich zusammengehörige Ereignisgesteuerte Prozessketten aus einem Szenario. Diese Elemente sind linear angeordnet (auch mit Verzweigungen) und stellen auf diese Weise die repräsentierten Ereignisgesteuerten Prozessketten in Beziehung. In der grafischen Notation wird jedes Element durch ein Symbol wie das folgende repräsentiert (Chevronsymbol), hier mit den Pfeilen, die der Verknüpfung mit vor- und nachgeordneten Bereichen dienen:

Dieses Symbol repräsentiert einen Szenarioprozess zum Qualitätsmanagement. Die Aufgabe von Wertschöpfungsketten (WSK) ist es nun, Übersicht in der großen Zahl von Ereignisgesteuerten Prozessketten zu einem betriebswirtschaftlich abgegrenzten Bereich zu schaffen. Mit ihnen ist es möglich, sich die Prozesse eines Szenarios schrittweise zu erschließen.

8.2 Ereignisgesteuerte Prozessketten

275

Dies ist möglich, weil jedes Element eines Wertschöpfungskettendiagramms nicht nur bestimmte zusammenhängende Ereignisgesteuerte Prozessketten repräsentiert, sondern weil der Business Navigator des R/3 den direkten „Sprung“ von den Symbolen der Wertschöpfungskette auf diese Ereignisgesteuerten Prozessketten erlaubt. Der Zusammenhang der Ereignisgesteuerten Prozessketten im Szenarioprozess und in der Wertschöpfungskette wird durch Farben hergestellt, die bei den Abbildungen hier leider weggenommen werden mussten. Dies geschieht folgendermaßen: Die einzelnen Symbole des Wertschöpfungskettendiagramms haben eine bestimmte Farbe. Dieselbe Farbe ist den zugehörigen Ereignisgesteuerten Prozessketten im Szenario unterlegt. Die Abbildungen 8.2-22 und 8.2-23 zeigen ein Beispiel, die Wertschöpfungskette Lagerverkauf über Lieferplan. Sie wird zuerst in einer Strukturübersicht angegeben, danach – sozusagen umgebrochen – in lesbarer Form.

Abbildung 8.2-22:

Strukturübersicht zur Wertschöpfungskette Lagerverkauf über Lieferplan Quelle: Erstellt nach der gleichnamigen Wertschöpfungskette aus SAP R/3.

Wie bereits die Strukturübersicht zeigt, ist die Gesamtheit aller Ereignisgesteuerten Prozessketten zum Bereich Lagerverkauf über Lieferplan aufgeteilt auf 12 Unterbereiche, die jeweils durch ein Symbol repräsentiert werden. Die Darstellung verdeutlicht die grundsätzlich lineare Anordnung von Geschäftsprozessen, auch auf dieser Meta-Ebene (vgl. für die Bezeichnungen der Bereiche die nächsten Abbildungen): x x

Die Gesamtheit der Geschäftsprozesse zur Vertriebsunterstützung ist vor denen zur Auftragsabwicklung zu realisieren Bevor die Gruppe der Ereignisgesteuerten Prozessketten zu Retouren/Reklamationen in’s Spiel kommt, sind die zum Transport und (gegebenenfalls) zu Rückrufaktionen zu realisieren.

Für sich genommen, haben die Wertschöpfungskettendiagramme lediglich den Informationsgehalt, den verdichteten Ablauf anzugeben. Durch die Möglichkeit, von den einzelnen Symbolen aus auf die Szenarioprozesse zuzugreifen (und damit auf die Basis-EPKs), werden sie allerdings zu einem effizienten Instrument der Erschließung und Navigation.

Zusammenhang durch Farben

276

8 Beispiel für eine Unternehmensmodellierung

In der folgenden Abbildung muss man sich die einzelnen Stücke fortlaufend aneinandergefügt denken.

Abbildung 8.2-23:

Das gesamte Szenario

Wertschöpfungskette Lagerverkauf über Lieferplan Quelle: SAP R/3, installiert an der Berufsakademie Ravensburg (bis 2001), Fachrichtung Wirtschaftsinformatik. Vom Verfasser grafisch bearbeitet70.

Zumindest kurz soll hier der Gesamtkontext des Szenarios und der Prozesshintergund eines Symbols angedeutet werden. Die folgende Abbildung 8.2-24 zeigt eine Strukturübersicht zum gesamten Szenario. Das grafisch hervorgehobene Rechteck zeigt den Bereich, der dem Wertschöpfungskettensymbol Lagerverwaltung entspricht. Beides, WSK-Symbol und Ausschnitt sind mit einer Farbe belegt (in diesem Beispiel mittelbraun), die den Zusammenhang herstellt. Aufgerufen wurde das Szenario direkt über das entsprechende WSK-Symbol, durch Anklicken. Damit ist es problemlos möglich, den Bereich Lagerverkauf in seinem Gesamtkontext zu analysieren.

70

Die grafische Bearbeitung war hier besonders umfangreich und “schmerzlich”. Über das übliche Maß hinaus wurde die WSK “umgebrochen” und ihrer intensiven Einfärbung beraubt, was einen deutlichen Informationsverlust mit sich brachte.

8.2 Ereignisgesteuerte Prozessketten

Abbildung 8.2-24:

277

Strukturübersicht zum Szenario Lagerverkauf über Lieferplan (Version 3.1H) Quelle: Erstellt nach dem gleichnamigen Szenario aus SAP R/3.

Dieser hervorgehobene Teil wurde für die nächste Abbildung 8.2-25 aus dem Szenario herausgeschnitten und grafisch bearbeitet. Um nicht eine weitere Zerlegung vornehmen zu müssen, wurde hier etwas stärker verkleinert. Wie oben angemerkt, entspricht der in den Abbildungen 8.2-25 und 8.2-26 angegebene Ausschnitt dem Wertschöpfungskettensymbol Lagerverkauf aus der oben angeführten Wertschöpfungskette.

278

8 Beispiel für eine Unternehmensmodellierung

Abbildung 8.2-25:

Ausschnitt Lagerverwaltung aus dem Szenario Lagerverkauf über Lieferplan – Oberer Teil Quelle für alle Abbildungen des Szenarios: SAP R/3, installiert an der Berufsakademie Ravensburg (bis 2001), Fachrichtung Wirtschaftsinformatik. Vom Verfasser grafisch bearbeitet

8.2 Ereignisgesteuerte Prozessketten

Abbildung 8.2-26:

279

Ausschnitt Lagerverwaltung aus dem Szenario Lagerverkauf über Lieferplan – Unterer Teil

Die Symbolik ist wie oben in Abschnitt 8.2.2. Lediglich ein Element kommt hinzu:

Dieses Symbol zeigt an, dass es zu dem entsprechenden Geschäftsprozess Varianten gibt, sodass der Nutzer, die für seine Branche bzw. seinen Bereich am besten geeignete wählen kann. Wie in Abschnitt 8.2.2 besteht das Szenario darüberhinaus nur aus Prozesssymbolen, die durch Ereignisse verknüpft sind. Die beiden Linien, die von oben in die Grafik von Abbildung 8.2-25 führen, zeigen die Verbindungszweige der Lagerverwaltung zum übrigen Szenario.

280

8 Beispiel für eine Unternehmensmodellierung

8.3

Weltausschnitt

Informationsstrukturen

Das informationelle Gerüst eines Unternehmens wird in Datenbanken erfasst. Dem Ansatz Betriebswirtschaftlicher Standardsoftware entsprechend ist es hier eine einzige, das gesamte Unternehmen und all seine Aktivitäten beschreibende Datenbank71. Weiter oben wurde schon eine zeitgemäße und zum Kontext dieses Buches passende Auffassung von Datenbanken angeführt: Datenbanken stellen die Informationen zur Verfügung, die für die Abwicklung der Geschäftsprozesse benötigt werden. Beim Datenbankdesign hat man, ganz genau wie bei der Geschäftsprozessanalyse, ein Modell eines bestimmten Ausschnitts der Realität zu erstellen. Dieser Weltausschnitt wird in die Datenbank hinein abgebildet. Im Falle von SAP R/3 besteht der Weltausschnitt somit aus dem gesamten (vorgedachten) Unternehmen. Die hier somit anstehende Frage ist die des Datenbankdesigns. Hier hat sich in den letzten Jahrzehnten in Datenbanktheorie und (eher zögerlich) Datenbankpraxis die Auffassung durchgesetzt, dass es sinnvoll ist, im ersten Schritt ein Semantisches Datenmodell zu erstellen (ganz im Sinne der Fachkonzeptsebene und Datensicht des ARIS-Konzepts) und anschließend eines, dass näheren Bezug zum ausgewählten Datenbanksystem hat, z.B. ein relationales. Genauso geht auch die SAP vor, allerdings mit einer Besonderheit. 8.3.1

Einordnung: ERM SERM SAP-SERM

Grundkonzept

Im Kern erstellt die SAP Datenmodelle auf zwei Ebenen. Auf einer semantischen Ebene (diese werden dann SAP-SERM genannt) und auf der Ebene des Relationalen Datenmodells, im Data Dictionary72. Während der relationale Ansatz dem üblichen Vorgehen entspricht, weist der semantische Modellierungsansatz Besonderheiten auf. SAPSERM ist eine Variante des SERM-Ansatzes von Sinz (vgl. [Sinz 1993]). Dabei steht SERM für Strukturiertes Entity Relationship Modell. SERM wiederum entstammt den Modellierungsansätzen, die zu den Entity Relationship Modellen (ERM) führten. Der Entity Relationship-Ansatz wiederum ist der erfolgreichste Vertreter der Gruppe der Semantischen Datenmodelle, die in den 70er und 80er Jahren intensiv diskutiert wurden.

71 72

Die natürlich in der Praxis trotz aller Integrationsbemühungen so gut wie immer durch andere ergänzt wird. Ein Data Dictionary ist ein Verzeichnis aller Elemente einer Datenbank, sozusagen eine Meta Datenbank. Zu diesen Elementen gehören, im Fall einer Relationalen Datenbank, die eingerichteten Relationen, die Attribute, die Sichten (views), die Semantischen Integritätsbedingungen (constraints) und alles andere, was das Datenmodell festlegt. Im SAP-Ansatz spielt das Data Dictionary eine ganz besondere Rolle (vgl. unten).

8.3 Informationsstrukturen

281

Die folgende Abbildung verdeutlicht diesen Zusammenhang. Dabei bedeutet der erste Pfeil, dass ER-Modellierung ein Teilgebiet unter vielen der Semantischen Datenmodellierung war. Die beiden anderen Pfeile bedeuten jeweils eine Modifikation des Ansatzes.

Abbildung 8.3-1:

Varianten Semantischer Datenmodellierung

Im Folgenden wird der Ansatz der SAP kurz beschrieben. Dabei wird dieser auch immer wieder in Bezug gesetzt zu den Ansätzen der Datenbanktheorie. Wie in der Datenbanktheorie üblich, unterscheiden auch die SAPModellierer eine logische und eine physische Ebene des Datenbankdesigns. Mit der logischen Ebene ist (hier) das Relationale Datenmodell gemeint, die physische meint die konkreten Dateistrukturen. Die logische Ebene wird im SAP-Sprachgebrauch mit dem Data Dictionary gleichgesetzt. In der Sprache der SAP stellt sich der Zusammenhang wie folgt dar: „Im SAP-System wird die physische Organisation der Daten in der Datenbank überlagert durch eine logische Ebene, auf der alle Daten in einheitlicher Weise beschrieben werden. Diese logische Sicht der Daten wird im SAP Data Dictionary hergestellt und basiert auf dem relationalen Datenmodell.“ [SAP-BCDD, S. 2-1] Insgesamt ergeben sich damit drei Ebenen: die Semantische Ebene mit einem SAP-SERM, die logische Ebene mit einem Relationalen Datenmodell und die physische Ebene der konkreten Dateiorganisation. In diesem Abschnitt wird im Folgenden, der Zielsetzung des Kapitels entsprechend, die Erste dieser Ebenen, die semantische, in ihrer SAPspezifischen Ausprägung erläutert und – auch mithilfe konkreter Beispiele aus den SAP-Datenmodellen – dargestellt. Dies entspricht der Zielsetzung dieses Abschnitts, der zweierlei leisten möchte: Zum einen soll ein Eindruck von der Art der Unternehmens(daten)modellierung gegeben werden, die für moderne Betriebswirtschaftliche Standardsoftware vorgenommen wird. Zum anderen soll verdeutlicht werden, welche Rolle Ereignisgesteuerte Prozessketten dabei spielen.

Physische und logische Ebene

Drei Ebenen

282

8 Beispiel für eine Unternehmensmodellierung

Abbildung 8.3-2:

8.3.2 Objekt, entity, Entität

Semantische, logische und physische Ebene des Datenbankdesigns

SAP-SERM

Wie in allen Entity Relationship – Ansätzen werden auch hier im ersten Schritt Objekte und Beziehungen73 unterschieden. Oftmals werden dafür die englischen Begriffe entity und relationship verwendet, denen der theoretische Ansatz auch seinen Namen verdankt. Einige Autoren des deutschsprachigen Raumes verwenden für Objekte auch den Begriff Entität, so auch die der SAP. Der Objektbegriff wird hier im allgemeinsten Sinne verwendet: alles was für die Datenbank durch Informationen beschrieben wird. Da letzteres heute noch in der Regel74 Attribute75 sind, kann obige Definition damit so formuliert werden: 73

74

Auf eine Einschränkung bzgl. der Semantischen Datenmodelle soll hier hingewiesen werden: Die im R/3-Referenzmodell angegebenen Datenmodelle spiegeln nicht die gesamte “darunterliegende” Relationale Datenbank wider, sondern “lediglich die wichtigsten Informationsobjekte, die bei den Prozessen als Input oder Output eine Rolle spielen, ...” [R/3-Referenzmodell 3.0F, S. 2.12]. Vor allem im kaufmännischen Bereich. Der Verfasser ist sich der Bedeutung der “neuen” multimedialen Informationsarten wie Grafik, Bild, Audiosequenz, Videosequenz, usw. auch und gerade für Datenbanken im klaren. Die daraus abgeleiteten Datentypen spielen eine große Rolle und werden in der Zukunft eine noch größere

8.3 Informationsstrukturen

283

Objekt im datenbanktechnischen Sinn sind alle Phänomene der Realwelt, die für die Datenbank durch Attribute beschrieben werden. Die zentralen Begriffe für diese SAP-Variante des Datenbankdesigns (SAP-SERM) sind damit Entität, Beziehung und Attribut. Der Begriff Entität wird im Kern in den SAP-Unterlagen genauso wie ansonsten in der Datenbanktheorie üblich beschrieben. „Eine Entität ist ein Objekt, x x x

das interessiert das eindeutig identifizierbar ist für das Information zu erfassen ist“ >SAP-BC030, S. 3-7@.

Dieser Begriff geht damit einigermaßen konform mit dem des entity, wie er in der angelsächsischen Fachterminologie üblich ist und wie er ja auch von einigen deutschsprachigen Autoren übernommen wurde. Er bedeutet somit eigentlich Informationsträger und damit und nach dem Sprachgebrauch alles, was beschrieben werden kann. Im datenbanktechnischen Sinne also alles, was durch Attribute beschrieben werden kann76. Natürlich wird auch in diesem Ansatz die Klassenbildung benötigt. Die damit entstehenden Objektklassen werden mit Entitätstyp bezeichnet: „Ein Entitätstyp x x x

beschreibt eine Menge von Entitäten gleicher Eigenschaften (Attribute) besitzt einen Namen hat Bedeutung“ >SAP-BC030, S. 3-9@.

Die Definition deutet es an, zu Klassen werden die Entitäten zusammengefasst, die durch dieselben Attribute beschrieben werden. Dies entspricht der in der Datenbanktheorie üblichen Vorgehensweise. Damit ergibt sich: Entitäten werden durch Attribute beschrieben. Zum Beispiel einzelne Kunden oder die Angestellten des Unternehmens. Jeweils ein Entitätstyp umfasst alle Entitäten, die durch dieselben Attribute beschrieben werden77. Also z.B. die Kunden bzw. Angestellten insge-

75

76 77

Entität

spielen (z.B. auch im kaufmännischen Bereich). Dies ändert jedoch nichts an der Aussage, da im Kern der derzeit dominierenden Datenbankansätze Attribute stehen. Nicht umsonst werden alle diese Ansätze in der angelsächsischen Fachliteratur “attributebased” genannt. Für die Zwecke dieser Arbeit genügt folgende Definition: Ein Attribut besteht aus einer Bezeichnung und der Definition der möglichen Werte für das Attribut (Attributausprägungen). Ein einfaches Beispiel ist das Attribut Farbe mit den Ausprägungen weiß, schwarz, gelb, usw.). Attribute werden irgendwelchen Informationsträgern (sie werden unten Objekte bzw. Entitäten genannt) zugeordnet. Attribute sind somit eine formale Fassung des umgangssprachlichen Eigenschaftsbegriffs. Dass heute auch andere Informationstypen wie Bilder, Grafik, Ton, usw. in Datenbanken verwendet werden, tut dem keinen Abbruch. Diese fundamentale Regel aller attributbasierten Datenbankansätze muss natürlich auch hier gelten.

Entitätstypen

284

8 Beispiel für eine Unternehmensmodellierung

samt. Vielleicht ergeben sich aber auch zwei verschiedene Kundengruppen (z.B. wenn man Einmalkunden abtrennt), die durch teilweise unterschiedliche Attribute beschrieben werden. Dann müssen zwei Entitätstypen gebildet werden. Betrachtet man den Zusammenhang von Ereignisgesteuerten Prozessketten und Datenmodellen, können Funktionen und Entitätstypen in Beziehung gesetzt werden: „Entitätstypen sind Informationen, die zur Durchführung einer betriebswirtschaftlichen Funktion notwendig sind“ (R/3-Hilfe: CA - R/3-Referenzmodell, Stichwort „Der Entitätstyp“) Beziehungen

Allgemeine Definition

Eingehende und ausgehende Beziehungen

Wie im ER-Ansatz üblich werden hier – neben Entitäten – auch Beziehungen betrachtet. Allerdings – gemäß dem SERM-Ansatz – in einer gegenüber dem allgemeinen ER-Ansatz eingeschränkten Form. Geht es um die Beziehungen zwischen Entitätstypen, wird von Beziehungstyp gesprochen. Dabei wird, wie im klassischen Entity Relationship-Ansatz, die Klassenbildung der Entitäten für die Beziehungen nachvollzogen. Im Vergleich zur herkömmlichen ER-Modellierung (vgl. beispielhaft >Date 1990@, >Teorey 1990@) sind Beziehungen in diesem Ansatz wesentlich genauer gefasst und enger definiert. Sie bestehen ausschließlich zwischen jeweils zwei Entitätstypen, nicht zwischen drei oder mehr, wie es ansonsten auch möglich ist. Sie sind gerichtet und die Richtung drückt eine Hierarchie aus, was in der konventionellen ER-Modellierung nicht üblich ist. Demzufolge werden Beziehungen durch die beiden beteiligten Entitätstypen definiert. Den übergeordneten nennt die SAP Start-Entitätstyp bzw. existenzunabhängigen oder referierten Entitätstyp, den zweiten Ziel-Entitätstyp oder existenzabhängigen Entitätstyp. In der Komponente des R/3, mit der die Bearbeitung der Datenmodelle möglich ist, dem Data Modeler wird zwischen den eingehenden und ausgehenden Beziehungen eines Entitätstyps unterschieden: x x

Eigenschaften von Beziehungen

Kardinalitäten – Übersicht

Eingehende Beziehung (d. h., der gewählte Entitätstyp ist in diesem Fall der Ziel-Entitätstyp (abhängige Entitätstyp) und der andere der Start-Entitätstyp (der unabhängige oder referierte Entitätstyp)). Ausgehende Beziehung (d. h., der gewählte Entitätstyp ist in diesem Fall der Start-Entitätstyp (der unabhängige oder referierte Entitätstyp) und der andere der Ziel-Entitätstyp (abhängige Entitätstyp)).

Beziehungen in SERM haben zwei Eigenschaften: x x

Kardinalität Art

und eine betriebswirtschaftliche Bedeutung. Mit Kardinalität der Beziehung ist das gemeint, was auch ansonsten in den ER-Ansätzen gemeint ist, allerdings gibt es im SAP-SERM keine

8.3 Informationsstrukturen

285

n:m-Beziehungen (viele-zu-viele Beziehungen). Konkret werden folgende Kardinalitäten unterschieden: x x x x

1:M-Beziehungen78 in der üblichen Notation: Eine Entität des einen Entitätstyps steht mit mehreren des anderen in Beziehung. 1:CM-Beziehung: Eine Entität des einen Entitätstyps steht mit keinem oder mehreren des anderen in Beziehung. 1:1-Beziehung in der üblichen Notation: Eine Entität des einen Entitätstyps steht mit einem des anderen in Beziehung. 1:C-Beziehung: Eine Entität des einen Entitätstyps steht mit keinem oder einem des anderen in Beziehung.

Der Buchstabe „M“, der üblicherweise nur „mehr als eins“ bzw. „viele“ bedeutet, soll hier auch noch Pflichtfeld (mandatory), der Buchstabe „C“ Optionalität (conditional) und T temporary signalisieren. Die folgende Abbildung zeigt die grafische Darstellung der Beziehungen. Zwischen je zwei durch Rechtecke repräsentierten Entitätstypen (vgl. unten) wird jeweils einer dieser Pfeile eingefügt:

Abbildung 8.3-3:

Beziehungsarten und ihre grafische Notation in SAP-SERM

Entitätstypen werden in SAP-SERM wie üblich durch Rechtecke mit Beschriftung dargestellt. Die Attribute der Entitätstypen werden nicht angegeben. Beziehungstypen haben hier keine Attribute im modelltechnischen Sinn. Hier ein einfaches Beispiel mit der Kardinalität 1:CM.

Abbildung 8.3-4:

Grafische Darstellung von Beziehungstypen in SAP-SERM am Beispiel eines Hierarchischen Beziehungstyps.

In der Sprache des SAP-SERM ist hier der Entitätstyp Fachbereich der Start-Entitätstyp und Kurse der Ziel-Entitätstyp. Nun zu den Beziehungen. Die SAP spricht auch von Beziehungstypen, obwohl dies hier eine andere Bedeutung hat als im herkömmlichen ERAnsatz. Die Art einer Beziehung bzw. eines Beziehungstyps kann hierarchisch, aggregierend, referentiell oder extern sein. Mit dem Begriff hierarchischer Beziehungstyp ist in SAP-SERM eine Beziehung zwischen zwei Entitätstypen gemeint, bei der der Ziel-Entitäts78

Statt M wird an einigen Stellen der SAP-Dokukmentation auch N verwendet.

Art einer Beziehung

Hierarchischer Beziehungstyp

286

8 Beispiel für eine Unternehmensmodellierung

typ existenzabhängig ist vom Start-Entitätstyp. Konkret meint dies, dass die Existenz einer Entität des Ziel-Entitätstyps abhängt von einer Entität des Start-Entitätstyps. Modellierungstechnisch äußert sich dies so, dass der Schlüssel des Start-Entitätstyp zu einem Teil des Schlüssels des Ziel-Entitätstyps wird. Das obige Beispiel in Abbildung 8.3-4 zeigt einen hierarchischen Beziehungstyp zwischen den Entitätstypen Fachbereich (Start-Entitätstyp) und Kurse (Ziel-Entitätstyp). Im Universitätsbeispiel der SAP-Dokumentation besitzt der Entitätstyp Fachbereich die Attribute x

Fachbereichsnummer (dieses dient auch als Schlüsselattribut79) und Fachbereichsname.

Der Ziel-Entitätstyp Kurse besitzt die Attribute x

Fachbereichsnummer, Kursnummer, Nummer des/der KursleiterIn und Kursname. Fachbereichsnummer und Kursnummer dienen zusammen als Schlüssel dieses Entitätstyps.

Eine solche Beziehungsart gibt es im klassischen ER-Ansatz nicht. Sie ähnelt aber sehr stark dem Fremdschlüsselkonzept im relationalen Ansatz, das dort zur Realisierung von 1:n-Beziehungen zwischen zwei Relationen dient. Deshalb wird hier die übliche textliche relationale Notation80 angegeben, die den schlüsseltechnischen Sachverhalt umfassend ausdrückt: x x Existenzabhängigkeit

Aggregierender Beziehungstyp

FACHBEREICH (#Fachbereichsnummer, Fachbereichsname) KURSE (#(Fachbereichsnummer, Kursnummer), Nummer des/der KursleiterIn, Kursname)

Dieses Beispiel erlaubt auch, sich dem Begriff der Existenzabhängigkeit etwas zu nähern, der in der SAP-Terminologie eine bedeutende Rolle spielt. Hier ist die Tatsache gemeint, dass jede Ziel-Entität zu ihrer Identifikation eine Start-Entität benötigt. Im obigen Beispiel: Jeder Kurs benötigt einen Fachbereich. Die folgende Struktur wird Aggregierender Beziehungstyp genannt. Hier sind immer drei Entitätstypen im Spiel, zwei Start-Entitätstypen und ein Ziel-Entitätstyp. Wieder wird die Existenzabhängigkeit des Ziel-Entitätstyps vom Start-Entitätstyp als Definitionsmerkmal genannt. Hier besteht sie sogar bezüglich zweier Start-Entitätstypen. Der Ziel-Entitätstyp wird vom Start-Entitätstyp erzeugt, d.h. der Start-Entitätstyp hat direkten Einfluss auf die Merkmalsausprägung. In der SAP-Sprache:

79 80

Ein Attribut, das jede einzelne Entität identifiziert, dass also für jede Entität eine andere Ausprägung hat. Ganz kurz zum Aufbau: Hier entspricht eine Entität einer Relation (dies ist nicht grundsätzlich so in Entity Relationship-Modellen). Für die textliche Darstellung von Relationen gilt: die Raute gibt den Schlüssel an, der aus einem oder mehreren Attributen besteht, danach folgen die übrigen Attribute.

8.3 Informationsstrukturen

287

„Ein Entitätstyp geht aus der Begriffsverknüpfung von mindestens zwei Ausgangsentitäten hervor.“ [SAP-BC030, S. 3-14] Im folgenden Beispiel: Ein Student kann mehrere Kurse besuchen, ein Kurs hat mehrere Studierende. Zusätzlich drücken die Pfeilspitzen aus, dass die Teilnahme an den Beziehungen konditional ist.

Abbildung 8.3-5:

Grafische Darstellung Aggregierender Beziehungstypen in SAP-SERM.

In einer solchen Konstellation wird die eigentliche Beziehung, die zwischen Studenten und Kursen, durch den Schlüssel des Entitätstyps Teilnahmebescheinigungen erfasst, der die Schlüssel von Studenten und Kursen enthält. Hier wieder die Angabe der Entitätstypen in relationaler Notation (die Punkte deuten die Liste weiterer Attribute an): x x x

STUDENTEN (#Immatrikulationsnummer, ...) KURSE (#Kursnummer, ...) TEILNAHMEBESCHEINIGUNG (#(Immatrikulationsnummer, Kursnummer)) [SAP-BC030, S. 3-14]

Die Schlüssel der Start-Entitätstypen werden Teile des kanonischen Schlüssels des Ziel-Entitätstyps. Der einzige Unterschied zwischen dem aggregierenden und dem hierarchischen Beziehungstyp ist, dass bei letzterem zwei Start-Entitätstypen vorliegen. Beim sogenannten Referentiellen Beziehungstyp geht es – ohne dass dies ausgesprochen wird – um dreistellige Beziehungen. In der folgenden Abbildung soll z.B. erfasst werden, dass Professoren Kurse in Fachbereichen halten.

Abbildung 8.3-6:

Dreistellige Beziehungen – Referentieller Beziehungstyp

Referentieller Beziehungstyp:

288

8 Beispiel für eine Unternehmensmodellierung

Die dreistellige Beziehung wird in KURSE erfasst, weshalb dieser Entitätstyp einen Schlüssel hat, der aus drei Attributen besteht. Hier könnte allerdings ein Problem auftreten. Wenn in KURSE tatsächlich die einzelnen Vorlesungen und Seminare beschrieben werden, wäre dies hochgradig redundant (Verstoß gegen die 2NF der relationalen Datenbanktheorie). Dann müsste zusätzlich ein eigener Entitätstyp (eine Relation) für die Kurse angelegt werden. In der Sprache der SAP ergibt sich die Definition dieses Beziehungstyps, wenn der Ziel-Entitätstyp vom Start-Entitätstyp existenzabhängig ist. Der Start-Entitätstyp legt den Kontext des Ziel-Entitätstyps fest, d.h. eine Attributgruppe des Start-Entitätstyps ist im Ziel-Entitätstyp vorhanden, die den Ziel-Entitätstyp jedoch nicht erzeugt. Die Schlüsselattribute des Start-Entitätstyps werden als Nicht-Schlüsselattribute in den Ziel-Entitätstyp übernommen. Eine Beziehung zwischen zwei Entitäten darf geändert werden. Zwischen den Entitätstypen Professor (Start-Entitätstyp) und Kurse (Ziel-Entitätstyp) besteht die Beziehung ist Leiter von mit der Kardinalität 1:CN. Dies soll wieder mithilfe der relationalen Notation dargestellt werden: x x x Konditionalreferentieller Beziehungstyp

FACHBEREICHE (#Fachbereichs-Nr., ...) PROFESSOREN (#Professor-Nr., Name, Adresse, Besoldungsklasse) KURSE (#(Fachbereichs-Nr., Kurs-Nr., Professor-Nr.) [SAP-BC030, S. 3-15]

Der folgende Beziehungstyp des konditional-referentiellen Beziehungstyps ist wie ein referentieller Beziehungstyp definiert, jedoch mit einem anwendungsabhängigen Beziehungszusammenhang, der demzufolge nicht immer gegeben ist [SAP-BC030, S. 3-16]. Das folgende Beispiel erfasst wieder eine Beziehung zwischen Professoren und Studierenden. Hier kann, aber muss nicht ein (einzelner) Professor an der Beziehung teilhaben, umgekehrt können mehrere oder auch kein Studierender teilhaben.

Abbildung 8.3-7: Externe Beziehungen Starke und schwache Existenzabhängigkeit

Konditional – Referentieller Beziehungstyp

Eine Beziehung wird in SAP-SERM extern genannt, wenn sie zwischen einem Entitätstyp innerhalb eines Datenmodells und einem Entitätstyp außerhalb dieses Datenmodells besteht. Bei der Existenzabhängigkeit unterscheidet man zwischen starker und schwacher Existenzabhängigkeit. Bei der starken Existenzabhängigkeit wird gefordert, dass für jede Ausprägung des Ziel-Entitätstyps eine Zuordnung zu genau einer Ausprägung des Start-Entitätstyp vorhanden sein

8.3 Informationsstrukturen

289

muss. Gilt diese Bedingung nur für eine (zeitabhängige) Teilmenge des Ziel-Entitätstyps, so spricht man von schwacher Existenzabhängigkeit. Schwache Existenzabhängigkeit kann bei aggregierenden und referentiellen Beziehungstypen, nicht aber bei hierarchischen Beziehungstypen auftreten. Mit dem nun eingeführten Begriff der Abhängigkeit zwischen den Entitätstypen bzw. Entitäten können die Kardinalitäten nun neu formuliert werden. Die n:m-Beziehungen ergeben sich damit wie folgt: x x x x x x

Neuinterpretation der Kardinalitäten

n = 1, also 1:m Zu jeder abhängigen Entität gibt es genau eine unabhängige Entität. n = C, also C:m Es kann Entitäten des abhängigen Entitätstyps geben, die keine Beziehung zu einer Entität des Start-Entitätstyps besitzen. m = 1, also n:1 Zu jeder Entität des Start-Entitätstyps gibt es genau eine abhängige Entität. m = C, also n:C Zu jeder Entität des Start-Entitätstyps gibt es höchstens eine abhängige Entität. m = N, also n:N Zu jeder Entität des Start-Entitätstyps gibt es mindestens eine abhängige Entität. m = CN, also m:CN Zu jeder Entität des Start-Entitätstyps gibt es beliebig viele abhängige Entitäten.

Die Kardinalitäten x x x x

C:1 C:C C:CN C:N

sind vor allem bei referentiellen Beziehungen sinnvoll. Möglich sind sie auch bei aggregierenden Beziehungen, nicht aber bei hierarchischen, da hier verlangt ist, dass alle abhängigen Entitäten eine Entität des StartEntitätstyps referieren müssen, d.h., dass es zu jedem Entitätstyp des abhängigen Entitätstyp eines im unabhängigen Entitätstyp gibt. Alle attributbasierten Datenbankansätze (vgl. Kasten) tun sich schwer mit folgender Situation (in der Sprache des SAP-SERM-Ansatzes): Ein Entitätsyp ET1 hat bestimmte Attribute, sagen wir A1, ..., A5. Andere Entitätstypen haben dieselben Attribute aber zusätzlich noch einige mehr. ET2 z.B. A6 und A7, ET3 A8, A9, A10. Insgesamt also: x x x

ET1: A1, A2, A3, A4, A5 ET2: A1, A2, A3, A4, A5, A6 A7 ET3: A1, A2, A3, A4, A5, A8, A9, A10

Generalisierung/ Spezialisierung

290

8 Beispiel für eine Unternehmensmodellierung

Wie soll eine solche Situation modelliert werden? Sie drückt ja eigentlich Ähnlichkeit im Sinne des attributbasierten Ansatzes81 aus: Die Entitätstypen haben viele Attribute gemeinsam, einige wenige nicht. In den ER-Ansätzen wurde für diese Situation schon sehr früh das Konzept der Generalisierung/Spezialisierung entwickelt. Es gibt einen „allgemeinen“ Entitätstyp, die Generalisierung, (im obigen Beispiel ET1) und die Spezialisierungen (im obigen Beispiel ET2 und ET3). ET1 ist dann die Generalisierung der beiden Spezialisierungen. Die semantische Datenmodellierung, zu der ja auch SAP-SERM gehört, drückt sich damit um die Frage der konkreten Speicherung solcherart erfasster Daten (ist ja auch nicht ihre Aufgabe) und verlagert diese in die Frage der physischen Speicherung. Doch nun hierzu ein Beispiel aus dem Universitätsdatenmodell der SAP. Der allgemeine Entitätstyp seien alle Personen, die an einer Universität beschäftigt sind. Ihre Attribute seien eine Nummer, ihr Name und die Adresse. Eine der Spezialisierungen seien Studierende mit den Attributen Immatrikulationsnummer, Betreuender Professor und Studienbeginn. Eine andere Spezialisierung seien die Professoren mit den Attributen #Professor-Nr, Name, Adresse, Besoldungsklasse. Ein zugegeben einfaches Modell, das aber ausreicht, dieses Konzept zu verdeutlichen. Insgesamt ergeben sich damit folgende Attribute (in relationaler Notation), wenn bei den Spezialisierungen die Attribute der Generalisierung weggelassen werden: x x x

Eigenschaften einer Spezialisierung:

PERSONEN (#Nummer, Name, Adresse) STUDIERENDE (#Immatrikulationsnummer, Betreuender Professor, Studienbeginn) PROFESSOREN (#Professor-Nr., Name, Adresse, Besoldungsklasse)

Die grafische Notation ergibt sich in SAP-SERM wie in Abbildung 8.3-8. Der Schlüssel der Generalisierung wird, wie auch im obigen Beispiel, in die Spezialisierungen übernommen. Dabei kann er natürlich umbenannt werden. Spezialisierungen können unterschiedlich strukturiert sein. Liegt eine Situation vor, in der sich die Spezialisierungen nicht überlappen, keine Entität also in mehr als einer Spezialisierung vorkommt, dann spricht man 81

Man kann heutige Datenbankansätze nur dann richtig begreifen, wenn man sich klar macht, dass sie voll und ganz auf dem Attributkonzept basieren. Attribute und ihre Ausprägungen werden festgelegt, die Ausprägungen für die ausgewählten Informationsträger (SAP-ERM: Entitäten) bestimmt, die Informationsträger in Klassen (SAPERM: Enitätstypen) so zusammengefasst, dass die in einer Klasse sind, die durch dieselben Attribute beschrieben werden, usw. Diese Attributorientierung gilt für die Datenmodellierung genauso wie für die physische Speicherung. Die relationale Normalisierungstheorie ist z.B. fast gänzlich motiviert durch das Ziel, Attributsausprägungen so in Dateien (sequentielle mit ihren verschiedenen Weiterungen) zu bringen, dass möglichst wenig Redundanz entsteht.

8.3 Informationsstrukturen

291

von einer disjunkten Spezialisierung. Die obige dürfte mit Sicherheit disjunkt sein, da eine Person üblicherweise entweder Studierender oder Professor/in ist.

Abbildung 8.3-8:

Generalisierung/Spezialisierung in der SAPNotation

Eine weitere Eigenschaft von Spezialisierungen betrifft die Frage, ob alle Entitäten der Generalisierung in die Spezialisierungen eingehen. Ist dies der Fall, bezeichnet man die Spezialisierung als vollständig. Obige Spezialisierung ist mit Sicherheit nicht vollständig, da es noch andere Personen außer Studierenden und Professoren an einer Universität gibt. Generalisierungen/Spezialisierungen müssen im Übrigen weder disjunkt noch vollständig sein. Diese beiden Eigenschaften von Spezialisierungen sind keine Besonderheit des SAP-SERM, sondern entstammen dem allgemeinen ER-Ansatz. Die folgende Abbildung 8.3-9 zeigt ein Beispiel, das weitgehend dem Universitäts-Beispiel der SAP-Unterlagen entstammt und das die oben angeführten Modellfragmente enthält. Es wurde nach den Data Dictionary-Modellfragmenten in [SAP-BC030] erstellt. Die einzelnen Beziehungen wurden mit Nummern markiert. (1) und (2) stellen die Generalisierung/Spezialisierung dar. Sie bedeutet: Mitarbeiter der Universität sind (hier) entweder Professoren oder Studierende. Konkrete Bedeutung: MITARBEITER haben bestimmte Attribute gemeinsam, die im gleichnamigen Entitätstyp erfasst werden. PROFESSOREN und STUDIERENDE haben jeweils noch spezifische Attribute, die bei ihrem Entitätstyp angeordnet sind. Bei der späteren Übertragung in relationale Strukturen bedeutet ein Generalisierungs-/Spezialisierungsverhältnis, dass die Relationen durch 1:1-Beziehungen verknüpft sind, sodass die Beziehung (1) konkret bedeutet: x

Ein Universitätsangehöriger kann ein Professor sein, muss es aber nicht. Auf Datenebene: Ein Tupel der Relation MITARBEITER kann mit höchstens einem Tupel von PROFESSOREN verknüpft sein, muss es aber nicht.

Zusammenfassendes Modellierungsbeispiel

292

8 Beispiel für eine Unternehmensmodellierung

Abbildung 8.3-9:

Datenmodell Universität – Ein Semantisches Datenmodell nach SAP-SERM Quelle: Erstellt nach den Data Dictionary Modellfragmenten in [SAP-BC030].

Entsprechend bedeutet die Beziehung (2): x

Betreuung

Ein Mitarbeiter kann ein Studierender sein, muss es aber nicht. Auf Datenebene: Ein Tupel der Relation MITARBEITER kann mit höchstens einem Tupel von PROFESSOREN verknüpft sein, muss es aber nicht.

Solche 1:1-Beziehungen werden in Relationalen Datenmodellen dadurch gelöst, dass der Schlüssel der „übergeordneten“ Relation auch als Schlüsssel in der „untergeordneten“ benutzt wird. In der Sprache der relationalen Theorie wird hier sozusagen der Fremdschlüssel zum Schlüssel, was ja üblicherweise nicht der Fall ist. Doch nun zurück zur semantischen Modellierung. Die Beziehung (3) zwischen PROFESSOREN und STUDIERENDE drückt in diesem Datenmodell ein Betreuungsverhältnis aus. Ein Professor kann keinen oder mehrere Studierende betreuen. Im relationalen Sinn handelt es sich dabei um eine 1:n-Beziehung, die durch einen Fremdschlüssel (z.B. PROF_NR) in STUDIERENDE erfaßt wird. In der SAP-Notation wird allerdings die-

8.3 Informationsstrukturen

293

ser Fremdschlüssel noch näher spezifiziert. Die Angabe OPT legt ihn als optionalen Fremdschlüssel fest, was hier bedeutet, dass der Fremdschlüssel in STUDIERENDE keinen Eintrag haben muss, z.B. wenn der jeweilige Studierende noch keine Diplomand ist. Hier müssen also bewusst semantisch bedingte Leereinträge in Kauf genommen werden. Die Beziehung (4) drückt aus, dass ein Professor keinen, einen oder mehrere Kurse hält. Wieder handelt es sich um eine 1:n-Beziehung, die erfasst wird, indem in KURSE als Fremdschlüssel die PROF_NR genommen wird. Aber auch hier spezifiziert dieser Ansatz etwas genauer: OBL macht den Fremdschlüssel zu einem obligatorischen, was hier bedeutet, dass bei jedem Kurs ein Professor eingetragen sein muss. Beziehung (5) legt fest, dass Professoren Publikationen (die in der Datenbank erfasst sind) haben oder auch nicht. Diese Beziehung kann auch anders herum beschrieben werden: Eine Publikation kann dann in die Datenbank aufgenommen werden, falls sie von einem in ihr erfassten Professor stammt und dann muss dieser auch angegeben werden. Die Beziehungen (6) und (7) zeigen, wie in diesem Ansatz n:mBeziehungen (Verbindungsrelationen im relationalen Sinn) erfasst werden. Die n:m-Beziehung besteht zwischen KURSE und STUDIERENDE:

Lehre

Publikationen

n:m-Beziehungen

Ein Kurs kann mehrere Studierende haben, ein Studierender kann mehrere Kurse besuchen. Im klassischen Entity Relationship-Ansatz wird eine solche Beziehung (genauer: ein Beziehungstyp) als solcher gesehen, kann mit Attributen versehen werden und taucht in der grafischen Notation als Raute auf. Im Relationalen Modell muss eine solche Beziehung mit drei Relationen gelöst werden, wovon eine die eigentliche Verknüpfung widerspiegelt (die Verbindungsrelation). Im SAP-SERM wird die gesamte Beziehung aufgelöst in zwei 1:nBeziehungen betrachtet. KURSTEILNAHME ist die eigentliche Verknüpfung. Dieser Entitätstyp muss die Schlüssel aus KURSE (KURS_NR) und STUDIERENDE (STUD_NR) enthalten. Diese beiden sind dort zusammen Schlüssel: #(KURS_NR, STUD_NR). Dieses Beispiel sollte deutlich gemacht haben, dass SAP-SERM in gewisser Weise näher am Relationalen Ansatz ist als an der klassischen Entity Relationship-Modellierung. Doch zurück zum SAP-Sprachgebrauch: Beziehung (6) hält fest welcher Studierende an welchem Kurs teilnimmt, indem in KURSTEILNAHME der Schlüssel des Studierenden als Fremdschlüssel auftaucht. Entsprechendes gilt für Beziehung (7). Beziehung (8) beschreibt den Zusammenhang zwischen FACHBEREICHE und KURSE. Jeder Fachbereich muss bei mindestens einem Kurs auftreten. Beziehung (9) hält wiederum fest, dass es zu Kursen auch Kursbeschreibungen gibt. Ein Kurs kann keine, eine oder mehrere Kursbeschreibungen haben.

Kursbesuch

Organisation

Beschreibung

294

8 Beispiel für eine Unternehmensmodellierung

So weit die Darstellung der SAP-Technik zur Semantischen Datenmodellierung (SAP-SERM). Im folgenden Abschnitt werden einige (sehr kleine) Ausschnitte aus den konkreten Semantischen Datenmodellen von SAP R/3 angegeben. 8.3.3 Aufbau der Grafiken

Entitätstypen

Konkrete Beispiele mit Erläuterungen

Die Kennzeichnung des Ansatzes mit dem Begriff strukturiert geht auf den SERM Ansatz von Sinz (vgl. >Sinz 1993@) zurück. Die Eigenschaft „strukturiert“ bedeutet, dass die Anordnung der Entitätstypen auf der Grafik durch ihren Abhängigkeitsgrad vorgegeben ist. Sind zwei Entitätstypen über eine Beziehung oder eine Spezialisierung miteinander verbunden, so steht der Start-Entitätstyp immer links vom Ziel-Entitätstyp. Im R/3 gibt es für die Grafiken der Datenmodelle einen sog. LayoutMechanismus, der nach dem Aufruf dafür sorgt, dass die Entitätstypen entsprechend ihrem Abhängigkeitsgrad positioniert werden. Entsprechend der ER-Modellierung werden Entitätstypen durch Rechtecke dargestellt, in deren Mitte die Bezeichnung des Entitätstyps steht (vgl. die folgende Abbildung). Attribute werden in der Grafik nicht angegeben, sie können aber jederzeit durch Zugriff auf das Data Dictionary ausgegeben werden. Im Gegensatz dazu wird eine eventuelle Zeitabhängigkeit eines Entitätstyps durch ein Oval an der linken unteren Ecke des Entitätstyps direkt in der Grafik angegeben (vgl. hierzu die Abbildung 8.3-13)82. Jeder Entitätstyp hat zusätzlich noch eine identifizierende Nummer. Diese steht im linken oberen Feld des Rechtecks. Rechts oben im Rechteck befinden sich zwei kleinere Felder, die nichts direkt mit der Modellierung zu tun haben. Links steht das Customizing-Kennzeichen, das rechte gibt Auskunft über die Art der Zuordnung zum Data Dictionary. Das Feld für das Customizing-Kennzeichen83 kann die folgenden Werte annehmen: x x x

Blank C A

Entitätstyp wird nicht im Customizing verwendet Entitätstyp wird nur im Customizing verwendet Entitätstyp wird allgemein verwendet

Das Feld für die Art der Dictionary-Zuordnung (ebenda) kann die folgenden Werte annehmen: x x x

Blank T V

82

In Abbildung 8.3-13 wanderte das Oval lediglich aus Platzgründen bei der grafischen Nachbearbeitung des Datenmodells nach rechts. SAP R/3, Rel. 3.1H, Dokumentation BC – Data Modeller, Stichwort Grafik: Darstellungsmethode (SAP-ERM)).

83

Keine Tabelle/kein View zugeordnet Tabelle zugeordnet View zugeordnet

8.3 Informationsstrukturen

295

Die folgende Abbildung zeigt nun ein Beispiel, den Entitätstyp Einkaufskontrakt, nach dem auch das gesamte Datenmodell benannt ist, aus dem er stammt. Dieses ist weiter unten angegeben (vgl. Abbildung 8.3-11).

Abbildung 8.3-10

Darstellung eines Entitätstyps in SAP-SERM Quelle: Entnommen dem Datenmodell Einkaufskontrakt aus SAP R/3, Vom Verfasser grafisch bearbeitet.

Beziehungen werden auf den Grafiken als Linien angegeben, wie oben schon eingeführt. Zusätzlich wird die ebenfalls oben eingeführte Art der Beziehung durch einen Buchstaben angegeben: x x x x

Beziehungen

H für hierarchisch A für aggregierend R für referentiell und X für extern.

Zusätzlich kann die Bezeichnung der Beziehung an der Linie ausgegeben werden. Der Layout-Mechanismus bei der Ausgabe der Grafik sorgt für eine weitere Verdeutlichung der Beziehung: Hierarchische und aggregierende Beziehungen kommen von links zu dem abhängigen Entitätstyp, referentielle Beziehungen von oben oder von unten. Die grafische Darstellung von Generalisierungen/Spezialisierungen wurde oben schon beispielhaft dargestellt. Der generalisierte Entitätstyp wird immer links von den spezialisierten Entitätstypen angeordnet. Von der Generalisierung führt eine blaue Linie zu jeder der Spezialisierungen. Ein blaues Dreieck (im Original, hier wurde die Farbgebung beseitigt), sozusagen links von allen Spezialisierungen, signalisiert die Generalisierung/Spezialisierung. Vgl. hierzu die Beispiele in den Abbildungen 8.3-11 und 8.3-17. Die Datenmodelle einer umfassenden Betriebswirtschaftlichen Standardsoftware müssen naturgemäß sehr groß sein. Deshalb werden, um auch bei Ausgabe mehrerer Datenmodelle den Überblick zu bewahren, die einzelnen Datenmodelle in farbig gekennzeichnete Rechtecke gepackt. Diese musste aus grafischen Gründen bei der Nachbearbeitung der SAPSERM-Datenmodelle für diese Arbeit beseitigt werden. In diesen Rechtecken steht in der linken oberen Ecke die Kurzbeschreibung des Datenmodells (hier immer angegeben). Das erste Beispiel in Abbildung 8.3-11 zeigt ein sehr kleines Datenmodell zum Thema Einkaufskontrakt.

Generalisierung/Spezialisierung

296

8 Beispiel für eine Unternehmensmodellierung

Abbildung 8.3-11:

Datenmodell Einkaufskontrakt Quelle für alle Datenmodelle dieses Abschnitts: SAP R/3, installiert an der Berufsakademie Ravensburg (bis 2001), Fachrichtung Wirtschaftsinformatik. Vom Verfasser grafisch bearbeitet.

Es zeigt die im Datenmodell vorgedachte Strukturierung (Aufteilung der Information in Einkaufskontrakte, Einkaufskontraktpositionen und Abrufdokumentationen. Wie zu sehen ist, muss es Einkaufskontraktpositionen geben, was für die Abrufdokumentationen nicht gilt. Außerdem ist in diesem Fragment angedeutet, dass der Entitätstyp Einkaufskontraktposition Generalisierung anderer Entitätstypen ist.

Abbildung 8.3-12:

Datenmodell Einkaufsorganisation

Das Beispiel Einkaufsorganisation in der Abbildung 8.3-12 macht die datentechnische Strukturierung dieses Teils der Unternehmenswelt deutlich und die Verknüpfung konzeptioneller Strukturen mit tatsächlich vorhandenen.

8.3 Informationsstrukturen

Abbildung 8.3-13:

297

Datenmodell Qualifikation

Exkurs: Organisationsstrukturen Die Bezeichnung Werk in Abbildung 8.3-12 bezieht sich auf die Organisationsstrukturen. Diese sind im Modellierungsansatz der SAP natürlich auch vorgedacht. Jedem Geschäftsprozess sind die für ihn im Rahmen der R/3-Einführung relevanten Organisationseinheiten zugeordnet. Diese können auch zu einer Ereignisgesteuerten Prozesskette auf einfache Weise aufgerufen werden. Mandant und Mandantenfähigkeit Ein wichtiger Begriff im Organisationskonzept der SAP ist Mandant. Darunter wird eine organisatorische Einheit verstanden, die ein abgeschlossenes betriebswirtschaftliches System darstellt. Mit Mandantenfähigkeit wird dann die Fähigkeit von SAP R/3 bezeichnet, mehrere abgegrenzte Buchungsbereiche (z.B. für verschiedene Unternehmen) zu verwalten. Weitere wichtige Begriffe in diesem Kontext sind Buchungskreis84, Werk oder Verkäufergruppe. Abbildung 8.3-13 zeigt ein wiederum sehr einfaches Datenmodell zum Thema Qualifikation, bei dem der Zeitaspekt mitmodelliert wurde85. Ein erstes etwas größeres Datenmodell zeigt Abbildung 8.3-14 zum Weltausschnitt Bestellung.. Hier sind auch ganze Generalisierungen integriert. Zum einen zum Entitätstyp Bestellung selbst, der in Lieferantenbestellung und Umlagerungsbestellung spezialisiert wird. Dies ist ein gutes Beispiel, um das Konzept der Generalisierung/Spezialisierung zu verdeutlichen. Mit ihm kann aber auch der Customizing-Begriff nochmals verdeutlicht werden. Genauso wie vorgedachte und reale Geschäftsprozesse angepasst werden müssen, gilt dies auch für vorgedachte und reale Datenstrukturen. Hier könnte z.B. bei einem Unternehmen der Fall vorliegen, 84 85

Die SAP definiert den Begriff Buchungskreis als kleinste organisatorische Einheit des externen Rechnungswesens, für die eine vollständige, in sich abgeschlossene Buchhaltung gebildet werden kann. Vgl. das besonders eindrucksvolle Beispiel hierzu in >SAP-PP300, S. 0-12@.

Customizing der Datenstrukturen

298

8 Beispiel für eine Unternehmensmodellierung

dass es keine Umlagerungsbestellungen, dafür aber einen anderen Bestelltyp gibt. Entsprechend müssten dann die Entitätstypen und die Generalisierung verändert werden. Die zweite Generalisierung betrifft die Bestellpositionskondition, die in solche mit den Zusätzen mit Stamm und individuell differenziert werden. Neben den Beziehungen mit optionalem Charakter gibt es in diesen Datenmodellen durchaus auch welche, die vorliegen müssen. Wie dem Datenmodell entnommen werden kann, kann es zu einer Bestellung Gesamtkonditionen geben, während zu einer Bestellgesamtkondition einzelne Bestellpositionskonditionen vorhanden sein müssen. Außerdem muss es zu einer Bestellung Bestellpositionen geben (ist ja auch naheliegend) und zu letzteren Bestellpositions-Einteilungen.

8.3 Informationsstrukturen

Abbildung 8.3-14:

299

Datenmodell Bestellung

So weit die kurze Betrachtung der SAP-spezifischen Semantischen Modellierung. Solche Semantischen Datenmodelle beschreiben in der Regel recht gut den jeweiligen Weltausschnitt. Sie müssen aber, geht es um die Realisierung konkreter Datenbanken, in Strukturen abgebildet werden, die näher an der physischen Datenorganisation86 in Dateien liegen. Im Datenbankbereich wird dies sehr häufig mit einer Abbildung des Semantischen Datenmodells in ein Relationales Datenmodell realisiert. Der Grund ist, dass Relationale Datenmodelle etwas näher an der konkreten Dateiorgani86

Die eigentliche physische Datenorganisation folgt dem nach und klärt die Frage, welche Datei- und Indexierungstechniken Verwendung finden.

Physische Ebene

300

R/3 mit Relationalen Datenbanken

Data Dictionary

8 Beispiel für eine Unternehmensmodellierung

sation sind: Bei vielen Datenbanksystemen entspricht eine Relation einer Datei, zumindest aber sind Relationale Datenbanksysteme in der Lage, Relationen aufzunehmen und so zu verwalten, dass die Nutzer mit der konkreten physischen Datenstruktur nur noch wenig zu tun haben. Deshalb kommen auch bei SAP an dieser Stelle in der Dokumentation die relationalen Datenbanken und ihre Terminologie mit ins Spiel. Die konkrete Datenbank, auf der R/3 agiert, ist immer relational. Dies gilt natürlich unabhängig davon, welches Datenbanksystem gewählt wurde87. Konkret geht es an dieser Stelle dann immer darum, Semantische Datenmodelle in relationale abzubilden, ganz allgemein (das wird hier betrachtet) und auch zugeschnitten auf die spezifischen Besonderheiten des jeweils gewählten Datenbanksystems (dies ist nicht Gegenstand dieses Buches). Wie oben schon angemerkt, sehen die SAP-Modellierer diese physische Datenbankebene in einem engen Zusammenhang mit dem Data Dictionary der Datenbank88. Während normalerweise ein Data Dictionary hauptsächlich als Verzeichnis der Datenbankelemente dient (vgl. oben), hat es hier weitergehende Aufgaben. Es ist zum Beispiel integriert und umfassend, wie es sich für eine Betriebswirtschaftliche Standardsoftware gehört, sodass die SAP-Modellierer ihm eine besondere Rolle zuschreiben können: „Das Data Dictionary ist eine zentrale Informationsquelle über die Daten eines Unternehmens“ >SAP-BCDD, S. 1-1@. Die SAP bezeichnet ihr Data Dictionary darüber hinaus als ein integriertes, womit sie ausdrücken möchte, dass ihr Data Dictionary vollständig in die Entwicklungsumgebung eingebettet ist. Es ist weiterhin ein aktives, weil es automatisch erfasste oder geänderte Informationen bereitstellt für „aktuelle Laufzeitobjekte, Datenintegrität, Datenkonsistenz und Datensicherheit“ >SAP-BCDD, S. 1-3@. Als Funktionen des Data Dictionary werden angegeben: x x x x

87 88

Verwaltung von Datendefinitionen (Metadefinitionen). Zentrale Beschreibung der im Informationssystem verwendeten Daten. Bereitstellung von Informationen für Auswertungen. Es liefert Informationen über die Beziehungen zwischen den Datenobjekten. Unterstützung der Softwareentwicklung Performance-Optimierung >SAP-BCDD, S. 1-4@ SAP R/3 kommt ohne Datenbankfunktionalität zu den Nutzern. Diese muss in Form eines Datenbanksystems dazu gekauft werden. Zurzeit stehen unter anderem Oracle, der SQL-Server und DB/2 zur Verfügung. Dies geht so weit, dass teilweise in den Formulierungen Data Dictionary und Relationale Datenbank gleichgesetzt werden. Nur einige Beispiele: “Die zentrale Datenstruktur des ABAP/4 Dictionary ist die Tabelle.” >Dokumentation zu SAP R/3 Rel. 3.1H, BC – ABAP/4 Dictionary, Stichwort Überblick der Grundobjekte des ABAP/4 Dictionary.@ oder: „Das Datenmodell des Data Dictionary.“ [SAP-BCDD, S. 2-1].

8.3 Informationsstrukturen

301

Angesichts dieser wichtigen Rolle des Data Dictionary überrascht es nicht, dass in der SAP-Dokumentation die Grundzüge des relationalen Datenmodells, nach denen ja modelliert wird, im Kapitel zum Data Dictionary (BC - ABAP/4 Dictionary) diskutiert werden. Woher kommt diese starke Betonung der Bedeutung des Data Dictionary? Die Ursache liegt darin, dass die SAP-Modellierer ihre Datenmodelle nicht am Beispiel eines konkreten Datenbanksystems und seiner Modellierungsinstrumente entwickeln. Dies ist nicht möglich, weil, wie oben erwähnt, R/3 ohne Datenbankfunktionalität ausgeliefert wird. Trotzdem müssen aber – natürlich – die SAP-Entwickler die Datenmodelle erstellen. Dies ist bei semantischer Datenmodellierung ohne weiteres möglich. Diese nimmt ja grundsätzlich wenig Bezug auf konkrete Datenstrukturen und konkrete Datenbanksysteme. Es wird aber schwierig, wenn es um die etwas konkreteren Datenstrukturen relationaler Datenbanken geht. Hier kommt normalerweise das konkrete Datenbanksystem (bzw. die evtl. in die Betriebswirtschaftliche Standardsoftware integrierte Datenbankfunktionalität) ins Spiel. Da dies aber nicht vorliegt, muss das Data Dictionary von einem Metadatenverzeichnis in ein Werkzeug zur umfassenden Beschreibung der Datenbank umgewandelt werden. Insgesamt liegt hier somit, was die Beschreibung und Erfassung der informationellen Struktur der Unternehmen angeht, die in der folgenden Abbildung skizzierte Situation vor.

Abbildung 8.3-15:

Vom Semantischen Datenmodell zur Relationalen Datenbank

Zuerst entsteht das oben beschriebene Semantische Datenmodell. Dieses wird in relationale Strukturen abgebildet, was zu einem Meta-Datenmodell im Data Dictionary führt, das umfassend das gesamte informationelle Gerüst beschreibt. Dieses wird dann in einem konkreten Datenbanksystem in eine Datenbank umgesetzt. Die für diese Umsetzung nötigen Schnittstelleninformationen werden selbstverständlich auch von SAP mitgeliefert. Dazu gehört dann z.B. die Abklärung, wie die Felder des Data Dictionary in die Datentypen des jeweiligen Datenbanksystem umgesetzt werden.

Starke Betonung des Data Dictionary

Vom Modell zu den Daten

302

Hoher Stand

8 Beispiel für eine Unternehmensmodellierung

In diesem Abschnitt konnten die Modellierungstechniken der SAP nur skizziert werden. Insbesondere wurde auf das Data Dictionary nicht weiter eingegangen, da der Schwerpunkt dieser Arbeit auf Modellüberlegungen liegt. Trotzdem sollte deutlich geworden sein, dass es sich um sehr ausgefeilte Techniken handelt, die eine den hohen Anforderungen entsprechende Datenmodellierung erlauben. Man merkt diesen Ansätzen die wohltuende Wirkung der hohen praktischen Anforderung an. 8.3.4

Business Objekte

Genau gleich wie es bei der Modellierung der Geschäftsprozesse Übersichtsnotationen gibt, gibt es sie auch bei den Datenmodellen, als sog. Business Objekte. Über 180 sind derzeit in SAP R/3 integriert. Ein Business Objekt fasst zusammengehörende (aus der Sicht der Anwendung) Datenmodelle so zusammen, dass auch Business Objekte selbst wieder in Beziehung gesetzt werden können. Darüberhinaus werden Business Objekte von der SAP als ein grundsätzliches Gliederungsinstrument gesehen: „Ein SAP Business Objekt repräsentiert ein zentrales betriebswirtschaftliches Objekt aus der realen Welt und beschreibt einen ganzheitlichen betriebswirtschaftlichen Zusammenhang“ >SAP Datenmodell 96, S. 17@. Ihnen wird sogar eine besondere Rolle zugewiesen: „Business Objekte sind ausgezeichnete Objekte von zentraler betriebswirtschaftlicher Bedeutung“ >SAP Datenmodell 96, S. 17@. Der Begriff Objekt wird in den SAP-Unterlagen sehr unterschiedlich verwendet. Hier ist er wie folgt definiert: „Ein Objekt repräsentiert einen ganzheitlichen betriebswirtschaftlichen Zusammenhang. Es ist durch seine innere Struktur näher beschrieben“ >SAP Datenmodell 96, S. 17@. Die grafische Darstellung von Business Objekten ist wie folgt:

Hinter diesem Business Objekt steht z.B. das Datenmodell von Abbildung 8.3-13. Ein größeres Business Objekt zeigt die Abbildung 8.3-16 auf der folgenden Seite. Es handelt sich um den „betriebswirtschaftlichen Zusammenhang“ Einkauf. Hier wird deutlich, dass ganz gleich wie bei Wertschöpfungsketten die Meta-Objekte auch in Beziehung gesetzt werden können. Wieder ist es die mögliche lineare Anordnung, hier allerdings ergänzt um ein Generalisierungs-/Spezialisierungskonzept, wie das Beispiel Einkaufsrahmenvertrag (Generalisierung) mit den Spezialisierungen Einkaufskontrakt und Einkaufslieferplan zeigt. Das Konzept der

8.3 Informationsstrukturen

303

Generalisierung/Spezialisierung wird also nicht nur (wie üblich) auf der Datenmodellebene, sondern auch auf der Meta-Ebene der Business Objekte verwendet. Hinter jedem Rechteck liegt ein Ausschnitt eines Datenmodells, der auch direkt aufgerufen werden kann. In diesem Abschnitt wurden oben schon die hierzu korrespondierenden Datenmodelle Einkaufskontrakt, Einkaufsorganisation und Bestellung angegeben. Zusätzlich sind hier in Abbildung 8.3-17 die drei Datenmodelle Einkaufsrahmenvertrag, Einkaufslieferplan und Einkaufskontrakt integriert angegeben. Dies macht nicht nur deutlich, was Zusammengehörigkeit (durch hintereinander anordnen) im Business Objekt-Diagramm auf der Ebene des Semantischen Datenmodells bedeutet, sondern zeigt durch die Rechtecke (ursprünglich natürlich farbig) die Anordnung der zu Business Objekten gehörenden Datenmodelle. Verschiedentlich tauchen in den Grafiken Kurzbezeichnungen für einzelne SAP-Anwendungen und Nummern auf, die zur Identifikation einzelner Modellobjekte dienen. Letztgenannte werden von der SAP Objektidentifizierer genannt. Innerhalb des R/3-Referenzmodells gibt die Zahl vor dem ersten Punkt des Identifizierers Auskunft darüber, zu welcher Applikation das Objekt gehört. Folgende Nummernbereiche wurden bei der Modellierung für die SAP-Applikationen vergeben: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 21 22 23

= = = = = = = = = = = = = = = = =

FI Finanzwesen MM Materialwirtschaft SD Vertrieb PP Produktionsplanung - und Steuerung TR Treasury QM Qualitätsmanagement PS Projektsystem PM Instandhaltung MM-WM Lagerverwaltung HR Personalwesen FI-AA Anlagenbuchhaltung CO Kostenrechnung PP-PI Produktionsplanung Prozessindustrie IM Investitionsmanagement LO Logistik allgemein IN Internationale Entwicklung CA Anwendungsübergreifende Funktionen

Quelle für die folgende Abbildung: SAP R/3, installiert an der Berufsakademie Ravensburg (bis 2001), Fachrichtung Wirtschaftsinformatik. Vom Verfasser grafisch bearbeitet.

Vom Business Objekt zum Datenmodell

Objektidentifizierer und Anwendungen

304

Business Objekt Einkauf.

8 Beispiel für eine Unternehmensmodellierung

Abbildung 8.3-16:

8.3 Informationsstrukturen

Abbildung 8.3-17:

305

Business Objekt Einkaufsrahmenvertrag und nachfolgende Datenmodelle Einkaufslieferplan und Einkaufskontrakt Quelle: SAP R/3, installiert an der Berufsakademie Ravensburg (bis 2001), Fachrichtung Wirtschaftsinformatik. Vom Verfasser grafisch bearbeitet.

Von allen dem Verfasser bekannten Ansätzen zur Unternehmensmodellierung ist der SAP-Ansatz der gründlichste, der fundierteste und der methodisch fortgeschrittenste. Er ist so leistungsstark, dass er – nicht nur bei der Modellierung von Geschäftsprozessen, sondern gerade auch bei der Datenmodellierung – der Theoriediskussion Impulse geben kann.

Gesamteinschätzung der SAP-Modellierung

306

8 Beispiel für eine Unternehmensmodellierung

Dies allein reicht sicherlich nicht für den Erfolg aus, gerade in Deutschland hat man Erfahrungen mit hervorragenden aber schwer verkäuflichen Produkten, ist aber unabdingbar angesichts der Komplexität des erstellten Produkts. Mit anderen Worten: Eine gute methodische Fundierung ist die notwendige Bedingung für den Erfolg, nicht die hinreichende. Aber eben die notwendige. Schon heute zeichnet sich ab, dass Unternehmen, die hier weniger investieren, bei der konkreten Einführung, bei der Weiterentwicklung, usw. in Schwierigkeiten geraten.

Hinweise zu den Kapiteln 9 bis 16

ooMod – auch für Geschäftsprozesse?

Der zweite Teil des Buches beschäftigt sich mit der objektorientierten Theorie, insbesondere mit der Frage, ob sie für die Geschäftsprozessmodellierung taugt. Im folgenden Kapitel werden (kurz) die Grundlagen dargestellt. Danach (Kapitel 10 – 15) folgen (ausführlich) die Theoriebestandteile, die sich mit den dynamischen Aspekten einer Anwendung (Verhalten , Tätigkeitsfolgen) beschäftigen. Da sich in diesen Bereichen die UML durchgesetzt hat, wird auch vorrangig diese vorgestellt und diskutiert. Neben einer ganz allgemeinen Einführung in die Thematik wird – der Themenstellung des Buches entsprechend – immer auch die Frage diskutiert, ob die objektorientierte Theorie für die Modellierung von Geschäftsprozessen geeignet ist. Dies ist dann gleichzeitig auch die Frage, ob sie für eine integrierte Unternehmensmodellierung taugt. Die Kapitel wollen aber noch mehr. Sie wollen auch helfen bei der Erschließung der Originaltexte der UML, z.B. [OMG 2003a]. Aus vielen Gesprächen mit Praktikern und Studierenden weiß ich, dass die Originaltexte als sehr schwer empfunden werden. Nicht so sehr wegen der anderen Sprache und auch nicht nur wegen der Komplexität der Materie, sondern wegen der Struktur der Texte, die auf der Metamodellierung basiert. Dem Ziel, die Erschließbarkeit zu fördern, dient auch: x x x

Die intensive und transparente Erschließung der Begrifflichkeit der UML-Autoren im Text Die Erläuterung der Metamodellierung an Beispielen Ab Kapitel 10 zu Beginn eines jeden Kapitels eine Auflistung der verwendeten Begriffe der UML in Deutsch und Englisch.

9 Objektorientierte Modellierung Grundlagen

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 ansteht90. 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 genannt91. Es wird in dieser Arbeit zu prüfen sein, ob die objektorientierte Theorie auch Modelle von Geschäftsprozessen liefern kann. 89 90 91

Diese Aussage bezieht sich auf die Praxis, nicht auf die Lehre, die Forschungseinrichtungen, usw., wo die Objektorientierung schon länger breite Resonanz findet. Im weiteren wird in diesem Kapitel für die zu modellierende Realwelt der Begriff Anwendungsbereich verwendet. So auch Meier und Wüst für den Datenbankbereich, die ein Objektmodell definieren als die „Zusammenfassung aller notwendigen Klassen einer bestimmten Anwendung.“ >Meier und Wüst 1997, S. 12@

Objektmodelle

310

9 Objektorientierte Modellierung - Grundlagen

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 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 Aspekten92 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 = Systemverhalten?

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 Gegenstand und Ziel

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

Die genaue Abklärung dieser Begriffe folgt unten.

9.1 Einleitung

311

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. Eine solche Modellierungssprache ist auch immer eine formale (oder evtl. semi-formale) Sprache, was einfach bedeutet, dass es – kurz gesagt – exakt definierte Elemente und Regeln für deren Zusammenfügen gibt. Beziehungspunkte mit der Realität Die Notwendigkeit, Realität in eine formale Struktur abzubilden, erzwingt, dass im ersten Modellierungsschritt die für die Modellierung wichtigen Aspekte der Realität erfasst werden. Diese dienen als Grundbausteine der Theorie. Dies ist eine schwierige Stelle im Modellierungsprozess und auch eine, wo die formale Sprache bereits ihre Qualität zeigen muss. In den weiteren Schritten arbeitet die formale Sprache nur noch mit diesen gewonnenen Informationen. Beispiele für diese erste Abbildung: x

x

x

Bei Ereignisgesteuerten Prozessketten geschieht dies z.B. durch Tätigkeiten im Geschäftsprozess, die durch Funktionen erfasst werden. Durch Ereignisse der Realwelt, die direkt als Ereignisse in die Ereignisgesteuerte Prozesskette übernommen werden, usw. In der „statischen Modellierung“ der UML (vgl. die nächsten Abschnitte) z.B. dadurch, dass Informationsträger der Realwelt („Angestellte“, „Studierende“, „Dozenten“) mit Hilfe von Attributen durch Klassen modelliert werden, dass real existierende Beziehungen („Studierende“ besuchen „Vorlesungen“) durch Assoziationen erfasst werden, usw. In der Datenmodellierung dadurch, dass Eigenschaften und Träger von Eigenschaften gesucht werden. Diese werden dann in Theoriekonzepte abgebildet. In der relationalen Theorie in Attribute und Relationen, in der Entity Relationship – Modellierung in Attribute sowie Entitäts- und Beziehungstypen.

In vielen Modellierungsansätzen ist diese erste Abbildung auch schon der Hauptteil der zu leistenden Arbeit, z.B. in der Entity Relationship – Modellierung, in anderen wirklich erst der Anfang. Z.B in der relationalen Modellierung, wo anschließend die gewonnene Modellinformation optimiert wird (durch die Normalisierung, ....). Die Qualität dieser Grundkonzepte, die Realwelt und Modell verbinden, ist von großer Bedeutung für jede formale Sprache. Nur wenn sie gut sind, d.h. wenn auf ihrer Basis aussagekräftige und den Modellierungszielen dienliche Modelle entworfen werden können, kann die formale Sprache Erfolg haben.

Erster Schritt: Aufsetzpunkte auf der Realität

Tätigkeiten Æ Funktionen Ereignisse hier Æ Ereignisse dort

Verbindung von Realwelt und Modell

312

Das Angebot der UML

9 Objektorientierte Modellierung - Grundlagen

Welche Grundkonzepte die UML für die Struktur- und Verhaltensmodellierung jeweils anbietet, wird unten in den jeweiligen Kapiteln betrachtet. 9.1.4

Statik vs. Dynamik – Struktur vs. Verhalten

Struktur und Verhalten in Abbildungen

Auch die Urheber der UML gehen (natürlich) von der Zweiteilung Struktur vs. Verhalten aus. Dies ist nunmal ein wesentliches Strukturmerkmal von Systemen, die ja am Ausgangspunkt der Entwicklung der objektorientierten Theorie standen. Eine Modellierungssprache wie die UML stellt ihre Ergebnisse vor allem in Abbildungen dar – für Struktur- und für Verhaltensaspekte. Die folgende Abbildung zeigt die in der UML verwendeten Abbildungen für die beiden Bereiche, dort werden sie „structure and behavior diagrams“ genannt.

Abbildung 9.1-1:

9.2

Modellierung von Strukturen

9.2.1 Objekte – Attribute – Methoden

Abbildungen für die Struktur- und Verhaltensmodellierung in der UML Quelle: [OMG 2003, S. 590, Figure 464], grafisch leicht verändert.

Statische Aspekte I – Objekte und Objektklassen

Auch dieser Ansatz baut, wie die meisten anderen Modellierungsansätze auch, auf dem Attributkonzept auf93. Attribute sind das zentrale Beschrei93

Wie oben beschrieben, stehen am Anfang jeder Modellierung die Werkzeuge, mit denen wir die Realweltphänomene identifizieren und beschreiben. Dies geschieht über

9.2 Modellierung von Strukturen

313

bungsmittel, Attribute bestimmten, welche Realweltphänomene zu Objekten werden und welche dann zu Klassen zusammengefasst werden. Wir können also von folgendem Grundszenario ausgehen: Informationsträger94 irgendwelcher Art werden durch Attribute beschrieben, wodurch sie zu Objekten werden, und miteinander in Beziehung gesetzt95. So weit nichts neues. In der objektorientierten Modellierung werden aber bereits im ersten Schritt auch Methoden berücksichtigt. Was ist damit gemeint? Mit Objekten der Realwelt können bestimmte Dinge gemacht werden, bzw. sie haben ein bestimmtes Verhalten (behavior). Einiges davon ist für die im Anwendungsbereich ablaufenden Geschäftsprozesse (das System / die Datenbank) von Bedeutung. Zum Beispiel: x x x x x

PCs für ein Unternehmen können beschafft, in einer Abteilung installiert, einem Angestellten zugewiesen oder auch ausgemustert werden. Eine Abteilung in einem Unternehmen kann eingerichtet, mit Personal versehen, einen geografischen Standort mit bestimmten Räumen zugeordnet bekommen oder auch geschlossen werden. Angestellte eines Unternehmens können eingestellt, entlassen, befördert, versetzt werden und Gehälter bekommen. Datenbanksysteme (in einem Weltausschnitt zum Markt für Datenbanksysteme) können auf den Markt gebracht bzw. von ihm genommen werden. Rechnungen können entstehen sowie bezahlt, storniert oder gemahnt werden.

Beide Interpretationen, die passive ("können gemacht werden") und die aktive ("haben Verhalten") sind richtig. Es geht immer um Aktivitäten, die mit den Objekten in Zusammenhang stehen. Die UML-Autoren sprechen in [OMG 2003a] nur von behavior, wenn sie die dynamischen Aspekte eines Anwendungsbereichs thematisieren. Dazu unten mehr. Im Modell werden diese Methoden durch Operationen repräsentiert und direkt den Objekten zugeordnet. So wie die Realweltobjekte durch die Modellobjekte in der Datenbank repräsentiert werden, wird das Verhalten durch die Methoden repräsentiert. "Eingestellt werden" also durch eine Methode, die eine Personalakte in den Datenbanken des Unternehmens anlegt, usw.

94 95

die Zuweisung von Eigenschaften, die Bildung von Kategorien, usw. In allen diesbezüglichen methodischen Ansätzen wird diese Vorgehensweise in das Attributkonzept hinein abgebildet. “Entity” im angelsächsischen Sprachraum. Dies wird hier ergänzt durch mehrere weitere Konzepte, die an der Stelle, wo üblicherweise Attributsausprägungen stehen, z.B. andere Objekte zulassen (vgl. unten), weshalb einige Autoren auch etwas allgemeiner von Eigenschaften statt von Attributen sprechen.

Methoden

314

9 Objektorientierte Modellierung - Grundlagen

Die folgende Abbildung fasst diesen Zusammenhang zwischen Attributen, Objekten und Methoden zusammen.

Abbildung 9.2-1:

Methoden und Operationen

Realwelt und ihre Repräsentation in der Datenbank

Damit wird bereits der qualitative Sprung deutlich, der hier vorliegt. In der objektorientierten Modellierung werden die Objekte nicht nur informationell durch Attribute beschrieben, sondern es wird auch ihr Verhalten modelliert. Oftmals werden Methoden und Operationen so abgegrenzt, dass Operationen als die „... Dienstleistungen, die von einem Objekt angefordert werden können, ...“ und als Methoden die Implementierungen der Operationen definiert werden [Oestereich 1998, S. 236]. Welche Methoden bzw. Operationen auf ein Objekt anwendbar sind, hängt sehr stark von dessen Aufgabe im Anwendungsbereich ab. Einige Operationen sind aber natürlich von grundlegender Bedeutung und liegen immer vor. So z.B. für die Erzeugung oder die Löschung eines Modellobjektes. Insgesamt geht es also darum, die „Dreiecksbeziehung“ zwischen Attributen, Objekten und Methoden zu klären, d.h., identifizierte Objekte mit gewünschten Attributen und Methoden in eine geeignete Struktur zu bringen. Verschiedene Aspekte dieser Aufgabe werden in den nächsten Abschnitten betrachtet.

Abbildung 9.2-2:

"Dreierbeziehung" Objekte - Attribute – Methoden

9.2 Modellierung von Strukturen

315

Wie sind nun Objekte in diesem Ansatz konkret definiert? Einige Autoren (v.a. die mit einem Datenbankhintergrund) behelfen sich einfach mit einem Hinweis auf die entsprechenden Realweltobjekte, wie z.B. Bertino und Martino:

Objekte finden

„In object-oriented systems, each real world entity is represented by an object to which is associated a state and a behavior.“ >Bertino und Martino 1993, S. 14@. Damit ist das Problem – zumindest was das Finden (bzw. Festlegen) der Objekte angeht - aber nur verlagert, denn Realweltobjekte besitzen auch nicht immer die Eindeutigkeit, die für eine Lösung der Frage notwendig wäre. >Meier und Wüst 1997, S. 3@ definieren Objekte als „Grundbausteine, aus welchen objektorientierte Anwendungssysteme aufgebaut werden" und präzisieren dann: „Unter einem Objekt versteht man einen wohlunterscheidbaren Gegenstand aus der realen Welt oder einen abstrakten Begriff aus der Vorstellung.“ >Meier und Wüst 1997, S. 13@ Meyer hebt – in Bezug zur objektorientierten Systemanalyse - an dieser Stelle auf statischen Aspekte eines Weltausschnitts ab, wenn er ausführt: „Frage nicht zuerst, was das System tut: Frag, WORAN es etwas tut!“ [Meyer 1990, S. 54]. Ähnlich Hughes, wenn er als ersten Schritt nennt: „... to extract the meaningful objects and concepts from the real-world enterprise being modelled.“ (>Hughes 1991, S. 82@). Er wird dann allerdings etwas präziser, indem er auf die Eigenschaften und Methoden Bezug nimmt und – mehr oder weniger – ausführt, dass „etwas“, was eigene Eigenschaften und Methoden hat, zu einem eigenen Objekt wird. Dies entspricht, lässt man die Methoden weg, dem, wie in der relationalen Datenmodellierung und in der ER-Modellierung sinnvollerweise (im ersten Schritt) die Objektfindung erfolgt und es passt auch hier. Ausgangspunkt sind auch hier die Phänomene der Realwelt, die im Anwendungsbereich beobachtet werden: Realweltphänomene: Alles was wir bei der Analyse des Weltausschnitts als Informationsträger wahrnehmen, d.h. alles was wir mit den dort jeweils benutzen Werkzeugen und Informationsarten erkennen können.

Wohlunterscheidbarer Gegenstand

316

Objektfindung durch Attribute

Objekt oder Eigenschaft?

9 Objektorientierte Modellierung - Grundlagen

In dem Augenblick, in dem wir Realweltphänomene wahrnehmen, stellen sie Information dar. Nicht unbedingt schon Information, die für den Anwendungsbereich tauglich ist, aber immerhin96. Im Regelfall sind dies die Phänomene, von denen man annimmt oder weiß, dass sie z.B. für die Anwendung, für den Zweck der Datenbank, oder für die Abwicklung der zugehörigen Geschäftsprozesse von Bedeutung sind. Wesentlich ist nun, dass alle die Realweltphänomene, denen man eigenständige Attribute zuordnet, Objektcharakter erhalten97. Die konkrete Ausprägung der Attribute eines Objekts wird sein Zustand genannt. Die Mehrzahl bei „Attribute“ ist hier wichtig. Ein einziges Attribut (das dann nur identifizierend sein könnte) genügt noch nicht. Aber bereits das Zweite etabliert die Beschreibung von Objekten. Dies löst auch die in der Literatur immer wieder gestellte Frage, wann ein beobachtetes Phänomen Objekt oder Eigenschaft ist. Dient es dazu, etwas anderes zu beschreiben, ist es Eigenschaft und wird als Attribut bzw. Attributsausprägung modelliert. Wird es selber durch andere Informationen beschrieben, ist es Objekt. Hierzu ein Beispiel: Wenn es Geschäftsstellen eines Unternehmens in mehreren Städten gibt, sollten dann die Städte eine Eigenschaft der Objekte Geschäftsstellen sein oder sollten sie zu eigenständigen Objekten werden?

Objektfindung durch Methoden

Durch Methoden zu Attributen

Mit der oben eingeführten Regel, dass zu eigenen Objekten die Realweltphänomene werden, die nicht nur durch eine Benennung identifiziert, sondern durch weitere Attribute näher beschrieben werden, kommt man zu folgendem Ergebnis: Werden die Städte näher beschrieben, z.B. durch Einwohnerzahl, Kaufkraft, Region, usw. müssen eigene Objekte angelegt werden. Sind die Städte allein als Eigenschaften der Geschäftsstellen geführt, dann sollten sie Attribut der Geschäftsstellen sein. Methoden werden üblicherweise von Objekten abgeleitet und dann mit diesen verwaltet. Oftmals geben Methoden aber auch Hinweise auf zu identifizierende Objekte. Nehmen wir z.B. die Methode Rechnungsstellung. Sie gibt nicht nur einen eindeutigen Hinweis auf die Objekte Rechnungen, sondern auch gleich auf die Adressaten der Rechnungen (Kunden) und die Waren oder Dienstleistungen, um die es geht. Nicht vergessen werden soll an dieser Stelle, dass auch Methoden Hinweise auf zu erfassende Attribute geben. Eine Methode Gehaltszahlung erzwingt dann die Erfassung von Attributen wie Familienstand, Steuerklasse, usw.

96 97

An dieser Stelle soll davon abgesehen werden, dass natürlich ein geübter Modellierer einen zu modellierenden Weltausschnitt gleich mit den “richtigen” Informationsarten beschreibt, ja evtl. auch gleich mit höheren Modellierungskonstrukten. Dass dies in weiteren Modellierungsschritten durch das Mitberücksichtigen von Beziehungen u.U. modifiziert wird, bleibt unbenommen.

9.2 Modellierung von Strukturen

317

Zusammenfassend und mit Berücksichtigung der hier auch betrachteten Methoden können wir somit den Objektfindungsprozess wie folgt definieren: Objekte im Sinne des objektorientierten Ansatzes sind Phänomene der Realwelt, die durch Attribute beschrieben und/oder denen Methoden zugewiesen werden. Dies ist nur das Ergebnis des ersten Modellierungsschritts, das in den folgenden Schritten (vgl. unten) modifiziert wird. Betrachten wir als Beispiel die Angestellten eines Unternehmens. Sie existieren, wir nehmen sie wahr, wir weisen Informationen zu (z.B. die für die Geschäftsprozesse benötigten), z.B. x x x x x x x

Beispiel

Name Vorname Postleitzahl (PLZ) Ort Straße Einstellungsdatum Geburtstag

usw. Dann aber auch Methoden wie x x x x x

Einstellen (des Realweltobjekts, Erzeugen des Datenbankobjekts) Entlassen (des Realweltobjekts, Löschen des Datenbankobjekts) Versetzen Befördern Gehalt zahlen

usw. Berücksichtigt man, dass Methoden nur zum Einsatz kommen können, wenn Attribute mit ihren Attributsausprägungen da sind98, kann zusammenfassend festgehalten werden, dass ein Objekt als ein Informationsträger definiert werden kann, der durch die Zuweisung von Attributen und Attributsausprägungen identifiziert bzw. spezifiziert wird. Mittlerweile kann diese Definition dahingehend ergänzt werden, dass natürlich weitere Informationstypen wie Grafik, Bild, Text, usw. ebenfalls zur Identifizierung und Spezifizierung von Objekten dienen können. Der in diesem Abschnitt beschriebene Zusammenhang zwischen Objekten und Attributen wird in der gesamten Literatur so gesehen, wenngleich oftmals anders dargestellt. So schreiben Bertino und Martino einfach: „...a set of attributes (or instance variables or slots) is associated to each object;...“ >Bertino und Martino 1993, S. 13@ 98

Welche Information soll sonst verarbeitet werden?

Objektbegriff

318

1:1-Abbildung

Geschützte Attribute

Kapselung

9 Objektorientierte Modellierung - Grundlagen

Andere Autoren schreiben statt von Attributen einfach von Eigenschaften, in Anlehnung an den umgangssprachlichen Begriff. Oftmals geschieht dies, weil durch das Konzept der komplexen Objekte (vgl. unten) nicht nur einfache Attribute den Objekten zugeordnet werden. Im Bereich der objektorientierten Datenmodellierung gehen viele Autoren so weit, eine 1:1-Beziehung zwischen den Objekten der Datenbank und denen des Weltausschnitts zu fordern (So z.B. >Bertino, Martino 1993, S. 14@, [Hughes 1992, S. 75], [Albano, Ghelli, Occhiuto et al. 1986]). Diese direkte Übereinstimmung zwischen Realweltobjekten („real world entities“) und Datenbankobjekten („objects“)99 (bzw. Konstrukten des Datenmodells) wird im Datenbankbereich geradezu als zentral angesehen. Ein Grund dafür ist sicherlich der Wunsch, die Segmentierung der Information für ein Objekt in konventionellen Datenbanken zu überwinden. In relationalen Datenbanken werden zum Beispiel die Attribute zur Beschreibung eines Objekts in der Regel über eine größere Zahl von Relationen verteilt. Da üblicherweise eine Relation auch einer Datei entspricht, führt dies zu einer Segmentierung auf logischer und auf physischer Ebene, die viele Auswertungen, Abfragen, usw. sehr kompliziert macht. Es gehört zu den Grundmerkmalen objektorientierter Modelle, dass Attribute vor Direktzugriffen geschützt sind. Normalerweise kann auf ihre Ausprägungen nicht direkt zugegriffen werden, so wie z.B. in Relationalen Datenbanken, sondern nur über die Methoden, die für die Objekte definiert sind. Dies wird auch als Kapselung (encapsulation) bezeichnet, da die Attribute sozusagen vor den Anwendungen versteckt sind und nur über die Methoden verändert werden können. Ganz wird dieses Prinzip allerdings nicht durchgehalten. Objektorientierte Datenbanksysteme erlauben meist den direkten Zugriff, z.B. zum Zwecke der Abfrage.

Andere Auffassungen Es gibt Autoren, die bei der Klärung des Objektbegriffs auf den Attributsbegriff verzichten. So z.B. >Geppert 1997@, der zwar auch von der verbreiteten Objektvorstellung ausgeht, "Ein Objekt hat einen Wert (Zustand) und ein vordefiniertes Verhalten" >Geppert 1997, S. 2@, der dann aber von den möglichen "Werten" von Objekten schreibt: "Der Wert eines Objekts kann einfach oder zusammengesetzt sein. Einfache Werte werden durch die Anwendung 99

Die Klammern geben den Sprachgebrauch der internationalen englischen Fachliteratur an.

9.2 Modellierung von Strukturen

319

von Wertkonstruktoren gebildet. Typische Konstruktoren sind Menge, Liste und Tupel" (ebenda, Hervorhebungen dort). Die so gefundenen Objekte werden nun zu Objektklassen zusammengefasst. Im Unterschied z.B. zu den älteren Ansätzen in der Datenmodellierung, wo dies auch geschieht, müssen hier noch zusätzlich die Methoden berücksichtigt werden, so dass folgende Definition gilt: Objektklasse: Objekte, die durch dieselben Attribute beschrieben und auf denen dieselben Methoden eingesetzt werden, werden zu einer Objektklasse zusammengefasst. Diese Klassenbildung ist ein gängiger Abstraktionsmechanismus aller Modellierungsansätze, ein Schritt, um die Komplexität der realen Welt zu reduzieren. Die angedachte Klassenbildung sollte im Übrigen bereits bei der Objektfindung berücksichtigt werden. Realweltphänomene sollten nur dann zu Objekten gemacht werden, wenn aus diesem Schritt mehrere Objekte entstehen, die dann zu einer Objektklasse werden können. D.h., parallel zum Suchen nach den geeigneten Objekten muss bereits reflektiert werden, welche Objekte zusammen in eine Objektklasse gehören. In einer solchen Klasse finden sich Objekte mit gemeinsamer Struktur und gemeinsamem Verhalten, also Objekte, die durch dieselben Attribute und sonstige Informationstypen beschrieben werden und auf die dieselben Methoden anwendbar sind. Oftmals denkt man auch bereits an Objektklassen, wenn man über Objekte redet, da man diesen Abstraktionsschritt fast automatisch vollzieht. Im objektorientierten Ansatz wird jedes Objekt Instanz seiner Klasse genannt. So wie sie nun hier definiert sind, werden Objektklassen auch zu Verwaltern von Informationen100. Zu den Informationen, die bei der Klasse verwaltet werden, gehören x x x

die Informationen der einzelnen Instanzen, Informationen zur Klasse als Ganzes, Prozeduren, mit denen die interne Repräsentation der Datenstruktur (Beschreibung der Objekte) manipuliert wird.

Zu den Informationen für die Klasse als Ganzes gehören Attribute, die für alle Instanzen gleich sind und aggregierte Informationen wie „Anzahl Objekte“ oder der Mittelwert eines entsprechenden Attributs. Solche Attribute werden Klassenattribute genannt. Sie sind so definiert, dass eine Ausprägung die gesamte Klasse betrifft. Ein Beispiel wäre AnzahlMitarbeiter und Gehaltssumme in einer entsprechenden Objektklasse.

100 Unabhängig vom Umfeld, also in der Datenbank, im System oder im Programm.

Klassen bilden

Definition

Informationen der Objektklasse

320

Klassenmethoden

Klassen und Kategorien

Operationen auf Instanzen

Daneben gibt es auch klassenbezogene Methoden (class methods). Sie sind unabhängig von der Existenz der einzelnen Objekte >Meier und Wüst 1997, S. 18@, betreffen die Gesamtheit der Objekte der Klasse. Ein Beispiel in einer Klasse PCs könnte feststellenGesamtzahl sein, eine Methode, die die jeweilige Gesamtzahl erfasster PCs feststellt und in einem Klassenattribut Anzahl festhält. Wie in der UML vorgeschlagen (vgl. >Balzert 1999a, S. 26f@) werden in den textlichen und grafischen Darstellungen von Objektklassen Klassenattribute und -methoden durch Unterstreichung gekennzeichnet (vgl. die Abbildungen unten). Klassenmethoden und -attribute machen einen grundsätzlichen Unterschied bei der Klassenbildung im objektorientierten Ansatz und bei älteren Modellierungsansätzen, z.B. der Bildung von Entitätstypen in der ERModellierung, deutlich. Sie zeigen, dass hier auch die Klassen selbst Träger von Attributen und Methoden sein können. Der Vorgang der Klassenbildung ist ein sehr grundlegender und natürlicher. Die menschliche Wahrnehmung hängt wesentlich davon ab. Wenn wir Menschen Realität wahrnehmen, bilden wir ständig Kategorien aus Gruppen ähnlich wahrgenommener Objekte, Ereignisse, usw. Nur so können wir die aufgenommene Information verarbeiten. Mit dem Konzept der Objektklasse können nun die oben schon angeführten Operationen NEW und DELETE besser beschrieben werden: x x

Darstellung von Objektklassen

9 Objektorientierte Modellierung - Grundlagen

NEW schafft eine neue Instanz mit genau den durch die Klassendefinition gegebenen Datenstrukturen und Methoden (natürlich ohne Ausprägungen). DELETE löscht eine solche Instanz.

In der Literatur werden Objektklassen meist in Ahnlehnung an eine „durchschnittliche“ objektorientierte Programmiersprachennotation textlich so dargestellt: class Angestellte properties Name: character Vorname: character Eintrittsdatum: date Gehalt: money ..... operations create einstellen() entlassen() zahlenGehalt () ..... end Angestellte

9.2 Modellierung von Strukturen

321

Für die grafische Darstellung wird hier die Notation der UML gewählt. Bei ihr wird eine Objektklasse durch ein Rechteck dargestellt. Im obersten Teil findet sich der Name der Objektklasse, im mittleren die Attribute, darunter die Methoden. Als Klassenname wird ein Substantiv verwendet, evtl. ergänzt durch ein Adjektiv.

Abbildung 9.2-3:

Objektklassen mit Klassenmethoden und -attributen in der UML

Die wichtigste Form der Beziehung zwischen Objekten ist die (strukturelle) Gleichheit. Sie ist Basis der oben beschriebenen Klassenbildung und entspricht einer grundsätzlichen menschlichen Vorgehensweise, der Kategorisierung wahrgenommener Phänomene. Datenbanktechnisch werden also strukturell (bzgl. Attribute, weiteren Informationstypen und Methoden) gleiche Objekte zusammengefasst. Die Definitionsmerkmale dieser Objekte werden bei der Klasse hinterlegt, so dass formuliert werden kann:

Klassifikation und Instantiierung

Die Objekte einer Klasse werden durch die Klassendefinition beschrieben. Dieser Vorgang des Zusammenpackens verschiedener Objekte zu einer Klasse wird Klassifikation (classification) genannt. Der gegenteilige Schritt, von der Klasse zum Einzelobjekt, oder auch die Erzeugung neuer Objekte einer Klasse gemäß den bei der Klassendefinition hinterlegten Definitionsmerkmalen wird Instantiierung (instantiation) genannt. Das neu entstehende Objekt wird auch mit Instanz bezeichnet. Instantiierung bedeutet somit, dass ein und dieselbe Definition benutzt wird, um Objekte mit demselben Aufbau und demselben Verhalten zu erzeugen. Konkret wird Folgendes festgelegt: x x x

die Menge der Attribute der Instanzen die Menge der Operationen die Menge der Methoden, die den Operationen entsprechen

Die Instantiierung bedeutet also die Erzeugung eines neuen Objekts nach den Eigenschaften, die durch die Objektklasse vorgegeben sind. Die dazu verwendete Methode hat meist die Bezeichnung NEW oder CREATE. Die Informationen über die Objekte können nach der Klassenbildung so gespeichert werden, dass die Bezeichnungen und Festlegungen der Attribute und Methoden nur bei der Klasse gespeichert werden. Die Attri-

Klassifikation

Instantiierung

322

Methoden vertieft

9 Objektorientierte Modellierung - Grundlagen

butsausprägungen müssen natürlich weiterhin getrennt abgespeichert werden. Dies wird so realisiert, dass es zu jeder Klasse ein Klassenobjekt (class-object) gibt, das die Informationen verwaltet, die bei allen Instanzen und Methoden gleich sind. Das Klassenobjekt wird getrennt von den Informationen der Instanzen gespeichert [Bertino und Martino 1993, S. 23]. Hughes vergleicht das Verhältnis von Klassen und Instanzen mit dem einer „type definition“ und Variablendeklarationen in der konventionellen Programmierung >Hughes 1991, S. 86@. Methoden im Sinne der objektorientierten Theorie (insbesondere in seiner Ausprägung für Datenbanken) gehen zurück auf das Konzept der abstrakten Datentypen. Wie oben schon ausgeführt, werden in der objektorientierten Literatur Methoden so gesehen, dass durch sie die "Veränderungen" in die Datenbank und die Anwendung hinein abgebildet werden, die ein Objekt erfahren kann und die für die zu unterstützenden Geschäftsprozesse von Bedeutung sind101. Methoden stehen somit im Gegensatz zu den statischen Aspekten der Anwendung, die in der englischsprachigen Literatur Zustand (state) eines Objekts genannt werden: „In object-oriented systems, each real world entity is represented by an object to which is associated a state and a behavior. The state is represented by the values of the object's attributes. The behaviour is defined by the methods acting on the state of the object upon invocation of corresponding operations“ >Bertino und Martino 1993, S. 14@. Wie ebenfalls oben schon angemerkt, greift der Begriff Verhalten (behavior) etwas zu kurz, da es hier auch um Veränderungen geht, die ein Objekt von "außen" erfahren kann. Z.B. der Angestellte, der eingestellt oder entlassen wird. Erst beides zusammen, das Verhalten eines Objekts und die von außen kommenden zulässigen Veränderungen seines "Zustands" (im datenbanktechnischen Sinn) beschreibt umfassend, was damit gemeint ist:

Definition

Methoden: alle Aktionen, die mit den Objekten einer Objektklasse geschehen können - aktiv (Verhalten) oder passiv. Auch unten, in den Kapiteln zur Verhaltensmodellierung der UML, wird dieser Gegensatz (Verhalten aktiv/passiv) immer wieder angesprochen. Betrachtet man Methoden nur im Kontext der objektorientierten Programmierung und im Systemdesign (und nicht bezüglich Datenbanken), drängt sich diese Unterscheidung nicht so klar auf, auch wenn sie, z.B. in einer fundierten Systemanalyse, natürlich von Bedeutung ist. 101 Mit anderen Worten: Die Methoden einer Objektklasse legen fest, auf welche Weise die Information, durch die eine Objektklasse beschrieben wird, verarbeitet werden kann.

9.2 Modellierung von Strukturen

323

Um einen Begriff von oben wieder aufzunehmen: Methoden repräsentieren auf dieser Stufe die dynamischen Aspekte eines Weltausschnitts, im Gegensatz zu den Attributen, die die statischen repräsentieren. Die folgende Abbildung möchte dies darstellen. Statisch vs. Dynamisch

Abbildung 9.2-4:

"Statisch" vs. "Dynamisch"

Damit ist diese Vorstellung der objektorientierten Modellierungskonzepte etwas näher an den Kernbereich der Unternehmensmodellierung, die Beschreibung der Abläufe, Geschäftsprozesse, usw. herangerückt. Allerdings werden die dynamischen Aspekte auf dieser Stufe noch einzelnen Objekten bzw. Objektklassen zugeordnet. Damit stellen sie nur einen Teil des "Verhaltens" dar, das insgesamt in den Geschäftsprozessen des jeweiligen Weltausschnitts benötigt wird. Wodurch können Methoden aktiviert werden? Dies wird weiter unten präzisiert. Schon hier soll angemerkt werden, dass die typische Aktivierung durch Aufruf aus der eigenen Klasse heraus oder durch Objekte anderer Klassen geschieht. Ein Modellierungskonzept, das für die objektorientierte Unternehmensmodellierung mit Sicherheit von Bedeutung ist, wird vor allem in der Diskussion um objektorientierte Datenbanken betont: die eindeutige, beständige und von der Beschreibung durch Attribute unabhängige Identifizierbarkeit der Objekte. Bei objektorientierten Datenbanken z.B: soll jedes Datenbankobjekt eindeutig identifiziert werden durch einen Objektidentifizierer (OID) (object identifier), der vom Datenbanksystem vergeben wird. Er ist unabhängig von den Attributen der Objektklasse. Insbesondere darf dieser OID nicht mit einem Schlüssel verwechselt werden, wie es ihn z.B. bei Relationen gibt. Mit diesem Konzept kann zwischen Identität und Gleichheit von Objekten unterschieden werden. Mehrere Objekte können absolut gleich sein, gemessen an den Ausprägungen ihrer Attribute, und sind doch nicht identisch. Ein Beispiel wären die Produkte einer Serienfertigung, z.B. Fernsehapparate, die – gemessen an den beschreibenden Attributen – absolut gleich sind. >Bertino und Martino 1993, S. 15@ unterscheiden denn auch identity equality und value equality. Erstere erfasst, ob es sich um dasselbe Objekt handelt, zweiteres ob die Attribute und Attributsausprägungen gleich sind.

Verhalten im Geschäftsprozess

Aktivierung von Methoden

Identität

Identität und Gleichheit

324

9 Objektorientierte Modellierung - Grundlagen

Ansätze zur Konstruktion von OID’s finden sich bei >Bertino und Martino 1993, S. 16@. Meier und Wüst bezeichnen eine Objektidentifikation auch als Surrogat (surrogate) >Meier und Wüst 1997, S. 15@. Der Begriff soll andeuten, dass die identifizierende Information Stellvertreter für das Realweltobjekt ist. Sie definieren dann, neben der Eindeutigkeit und der Unabhängigkeit von Objekteigenschaften, folgende Eigenschaften von Surrogaten: x x

Wertbasierte Suchschlüssel

Unveränderbarkeit: Ein einmal vergebener Wert bleibt unverändert, er wird nicht neu vergeben, auch wenn das Objekt gelöscht wird. Ortsunabhängigkeit: Sie werden unabhängig vom geografischen Speicherungsort und von der Speicherungsform vergeben.

Dies macht sie geeignet für den "referenzbasierten Aufbau von Beziehungen“ zwischen Objektklassen (vgl. unten sowie >Meier und Wüst 1997, S. 16@, >Geppert 1997, S. 2@). Meier und Wüst weisen darauf hin, dass trotz der Existenz dieses Systemschlüssels andere benutzerbezogene Identifikations- oder Zugriffsschlüssel eingerichtet werden können. Dies erfolgt über die Attribute, z.B. Personalnummern, Produktnummern, Kontonummern, Artikelnummern, usw., die entstehenden Attributskombinationen werden wertbasierte Suchschlüssel genannt: "Ein wertbasierter Suchschlüssel (value-based search key) ... identifiziert ein bestimmtes Objekt aufgrund von Attributwerten oder Attributwertkombinationen." >Meier und Wüst 1997, S. 38@. Seine Spezifizierung erfolgt durch den Zusatz Key in der Klassendefinition, z.B. Key(Personalnummer).

Exkurs: Alles nur Objekte? Es gibt im objektorientierten Ansatz auch die Überlegung, alle irgendwie berücksichtigten Informationen als Objekte aufzufassen. Also auch das, was üblicherweise als Attributsausprägung bezeichnet wird. Grund ist der Versuch, mit Hilfe einer Metamodellierung, die ebenfalls auf der objektorientierten Theorie basiert, zu einem geschlossenen Theoriegebäude zu kommen (vgl. zur Metamodellierung der UML die Ausführungen unten). Mit diesem Standpunkt wird dann der Attributsname zu einer Art Zusammenfassung der Attributsausprägungen (genauer: Aggregation). Mit den Worten von Bertino und Martino: „In almost all object-oriented data models, an attribute has associated with it a domain which specifies the classes of the possible objects that can be assigned as values to that attribute.“ ... „The fact, that an attribute of a class C has a

9.2 Modellierung von Strukturen

325

Class C‘ as a domain, implies that each instance of C assumes as the value of the attribute an instance of C‘, or of a subclass of it. An aggregation relationship is established between the two classes. An aggregation relationship from class C to class C‘ specifies that C is defined in terms of C‘. since C‘ is in turn defined in terms of other classes, the set of classes in the schema is then organized in an aggregation hierarchy."“ >Bertino und Martino 1993, S. 24f@ Die hier angesprochene aggregation relationship (Aggregation) wird weiter unten diskutiert. Teilweise wird dies auch im Datenbankansatz versucht (vgl. z.B. >Bertino und Martino 1993@. Es ist aber nicht sinnvoll, schafft unnötige Komplexität und wird deshalb hier nicht nachvollzogen. Hier bleibt es bei der grundlegenden Unterscheidung von Objekten und Attributen (bzw. Attributsausprägungen (oft an den entsprechenden Stellen "Werte" (values) genannt), etwa so, wie Bertino und Martino dies formulieren: „However, there are some models in which both objects and values (often called literals) are allowed and in which not all entities are represented as objects. Informally, a value is self-identifying and has no OID associated with it. All primitive entities, such as integers or characters, are represented by values, whereas all non-primitive entities are represented by objects.“ >Bertino und Martino 1993, S. 14@ 9.2.2

Statische Aspekte II - Objekte in Beziehung setzen

Im vorigen Abschnitt wurden die Grundkonzepte Objekt und Objektklasse eingeführt. Hier geht es nun um die Techniken, mit denen Objektklassen (und damit Objekte) miteinander in Beziehung gesetzt werden können, denn natürlich stehen in Objektmodellen die einzelnen Objektklassen nicht unverbunden nebeneinander. Assoziation - Semantische Verknüpfung In Datenbanken ist eine zentrale Verknüpfungstechnik die zwischen Objekten verschiedener Objektklassen aufgrund semantischer Gegebenheiten. Diese sog. Assoziation hat auch hier in der objektorientierten Modellierung Bedeutung. Dabei wird sie in der objektorientierten Systemanalyse so gesehen, dass Assoziationen notwendig sind, damit Objekte miteinander kommunizieren können (vgl. beispielhaft [Oestereich 1998, S. 268]). Nehmen wir als Beispiele die zwei Objektklassen PERSONAL und PCs. Zwischen ihnen kann eine semantische Beziehung dergestalt existie-

Beispiel PCNutzung

326

Beispiel Abteilungszugehörigkeit

Inverse Beziehungen

9 Objektorientierte Modellierung - Grundlagen

ren, dass einem Mitarbeiter ein PC zugeordnet ist, ein PC aber verschiedenen Mitarbeitern zur Verfügung steht. Oder die übliche Abteilungszugehörigkeit, eine Beziehung zwischen den Objektklassen ABTEILUNGEN und PERSONAL. Ein Angestellter ist einer Abteilung zugeordnet, eine Abteilung hat mehrere Angestellte. Voraussetzung ist hier natürlich, dass Abteilungen und Angestellte jeweils als eigene Objektklassen im Datenmodell angelegt sind. Genau um solche Beziehungen geht es. Natürlich werden von der Vielfalt in der Realität vorkommender semantischer Beziehungen nur die betrachtet, die für die jeweilige Anwendung und für die jeweiligen Geschäftsprozesse von Bedeutung sind. Meist wird diese Beziehung in Anlehnung an die UML Assoziation genannt (z.B. auch >Meier und Wüst 1997, Abschnitt 2.3.1@, >Balzert 1999a, S. 40]), andere sprechen von Referenzen zwischen Objekten (so z.B. >Geppert 1999, S. 6f]) oder von objektwertigen Attributen. Gemeint ist immer dasselbe: die Verknüpfungen, die sich aus der Semantik des Weltausschnitts ergeben. Insbesondere in Abgrenzung zum relationalen Modell muss hier noch darauf hingewiesen werden, dass die Realisierung dieser Beziehungen zwischen Objekten modelliert wird, indem die entsprechenden Objekte mithilfe ihrer Objektidentifizierer verknüpft werden und nicht mithilfe attributbasierter Schlüssel. Andere sprechen bei der Diskussion solcher semantischer Verknüpfungen von inversen Beziehungen (so z.B. [Hughes 1992]). Auch hier ist gemeint, dass bei einem Attribut an Stelle einer Attributsausprägung eine andere Objektklasse angegeben werden kann102. Mit anderen Worten: Eine Eigenschaft selbst kann wieder eine Klasse sein [Hughes 1992]. Die Begriffswahl macht aber auf die Tatsache aufmerksam, dass eine solche Beziehung zwei Richtungen hat. Dies betonen auch >Meier und Wüst 1997@ und schlagen in Anlehnung an die UML vor, diese auch deutlich zu benennen. Jede Einzelne nennen sie Assoziation, so dass aus zwei Assoziationen eine Beziehung wird: „Allgemein werden Beziehungen zwischen Klassen durch je zwei Assoziationen ausgedrückt: Zu jeder Assoziation von einer Klasse K1 zu einer Klasse K2 existiert eine inverse Assoziation von K2 zu K1. Unter einer Assoziation von einer Klasse K1 zur Klasse K2 wird die Bedeutung und Mächtigkeit der Beziehung in diese Richtung verstanden“ >Meier und Wüst 1997, S. 20@.

Beziehungswertigkeiten

Ähnlich wie in der ER-Modellierung können, in Anlehnung an die UML, folgende Wertigkeiten103 von Beziehungen104 festgehalten werden (für jede Beziehung zweifach): 102 In [Hughes 1992, S. 83] findet sich dazu auch die Darstellung auf Datenebene. 103 Oestereich spricht hier von „Multiplizitäten einer Assoziation“ [Oestereich 1998, S. 268].

9.2 Modellierung von Strukturen

x x x x

einfach (genau ein Objekt): konditionell einfach (kein oder ein Objekt): konditionell mehrfach (null, eines oder viele): mehrfach (eines oder viele/mindestens eines):

327

1 0..1 * 1..*

Weitere Konkretisierungen bezüglich der maximalen und minimalen Anzahl von Objekten können erfolgen, so dass z.B. folgende Angaben möglich sind: x x x x x

fünf oder mehr null bis drei genau fünf drei, vier oder acht alle natürlichen Zahlen außer elf

5..* 0..3 5 3, 4, 8 1..10, 12..*

Balzert führt zusätzlich die Begriffe Kann- und Muss-Assoziationen ein. Kann-Assoziationen haben als Untergrenze die Kardinalität 0, MussAssoziationen die Kardinalität 1 oder größer >Balzert 1999a, S. 41f@. Wie auch das folgende Beispiel zeigt, können Assoziationen benannt werden. Pro Beziehung gibt es dann zwei Angaben. Im folgenden Beispiel geht es um die oben schon thematisierte Beziehung zwischen ANGESTELLTEN und PCs. Hier gilt nun, dass ein Angestellter genau einen PC nutzt und ein PC mindestens einem Angestellten zugeordnet ist. Wie die Abbildung zeigt, werden in der grafischen Notation solche Beziehungen durch eine Linie zwischen den beteiligten Objektklassen ausgedrückt. Erläuternde Texte verdeutlichen die Bedeutung der Assoziationen, die Zahlen geben die Kardinalitäten an.

Abbildung 9.2-5:

Semantische Beziehungen zwischen Objektklassen

104 >Balzert 1999a, S. 41] spricht hier von Kardinalitäten, wie bei Entity Relationship – Modellen.

Kann- und MussAssoziationen

328

Rollen

9 Objektorientierte Modellierung - Grundlagen

In der Abbildung ist auch angegeben, wie die Kardinalitäten aus der grafischen Notation heraus gelesen werden müssen. Allgemein gilt für binäre Beziehungen zwischen zwei Objektklassen A und B: Bei B wird angegeben, wie viele Objekte von A an der Beziehung teilhaben und auf der Seite von A, wie viele von B. Oft aber nicht immer wird die Aussagekraft einer grafischen Darstellung erhöht, wenn bei den Objektklassen einer Assoziation die Rolle angegeben wird, die die Objekte in der jeweiligen Beziehung spielen. Die Rollennamen werden dann an die Assoziationslinie auf die Seite der Objektklasse gesetzt, deren Rolle in der jeweiligen Beziehung geklärt werden soll. Die folgende Abbildung zeigt ein einfaches Beispiel.

Abbildung 9.2-6: Mehr als zwei in der Beziehung

Rollen in Assoziationen

Obige Beziehung ist zweistellig. Neben solchen binären Assoziationen gibt es auch höherwertigere. Man spricht dann allgemein von n-ären Assoziationen >Balzert 199a, S. 50@, im Fall von dreistelligen Beziehungen von ternären Assoziationen. Ein Beispiel dafür zeigt die folgende Abbildung. Hier wird angenommen, dass Personal Computer nicht nur Abteilungen bzw. nur Angestellten, sondern Angestellten jeweils in Abteilungen zugewiesen werden. Dann entsteht eine dreistellige Beziehung, wie sie die Abbildung andeutet. Weitere Beispiele finden sich bei >Meier und Wüst 1997, S. 23@ und >Balzert 1999a, S. 50@. Die Wertigkeiten der Beziehungen sind bei höherwertigeren Assoziation nicht ganz einfach bestimmbar. Man muss sich dabei sehr deutlich machen, was durch die Beziehung modelliert werden soll. Hier also z.B. die Dreiecksbeziehung zwischen PCs, Angestellten und Abteilungen. Die Wertigkeiten ergeben sich durch folgende Festlegungen bzw. Feststellungen: x x x x

Mindestens ein Angestellter, maximal zwei nutzen einen PC in einer bestimmten Abteilung. Es geht immer um genau eine Abteilung, d.h. jede Einzelbeziehung bezieht sich immer auf genau eine Abteilung. Es geht immer um genau einen PC. Die "Dreiecksbeziehung" hat zur Folge, dass durchaus ein Angestellter in verschiedenen Abteilungen PCs nutzen kann.

9.2 Modellierung von Strukturen

Abbildung 9.2-7:

329

Ternäre Assoziation

Beziehungen zwischen Objekten bzw. Objektklassen hatten in der bisherigen Darstellung keine eigenen Attribute und Methoden, sie stellten einfach eine auf semantischen Gegebenheiten beruhende Verknüpfung von Objekten dar. Dies ist auch oft der Fall, allerdings bei weitem nicht immer, wie ja auch die älteren Datenmodellierungsansätze zeigen. Grundsätzlich wäre auch denkbar, dass die objektorientierte (Daten)Modellierung Attribute und Methoden von Beziehungen auf andere Weise modelliert, nicht durch die Präzisierung der Beziehungen. Dies scheinen auch viele Autoren in diesem Bereich zu denken, die auf die Betrachtung dieses Sachverhalts verzichten, wodurch er - da er ja nicht verschwindet - in die zu programmierenden Anwendungen verlagert wird und das heißt, in die Systemanalyse. Dort wird dieses Strukturmerkmal diskutiert, v.a. im UML-Ansatz (vgl. beispielhaft [Balzert 1999a, S. 45], [Oestereich 1998, S. 272ff] und >Meier und Wüst 1997@). Hier werden Assoziative Klassen (Balzert), Beziehungsklassen (Meier und Wüst), bzw. Attributierte Assoziationen oder Assoziationsklassen (Oestereich) zwischen zwei oder auch mehr Objektklassen eingeführt: „Verfügen Beziehungen zwischen Klassen selbst über beschreibende Attribute oder Methoden, so muss zu diesem Zweck eine explizite Beziehungsklasse definiert werden. Eine Beziehungsklasse (association class) ist eine Klasse, die von mehr als einer Klasse abhängig ist“ >Meier und Wüst 1997, S. 22@. Sie präzisieren und begründen dann wie folgt: "Typisch bei jeder Beziehungsklasse ist, dass die Beziehungsattribute weder der einen noch der anderen Klasse

Beziehungsklassen

Entweder im Datenmodell oder im Anwendungsprogramm

330

9 Objektorientierte Modellierung - Grundlagen

zugeordnet werden können, da solche Merkmale ein Verhältnis zwischen mindestens zwei Klassen ausdrücken" >Meier und Wüst 1997, S. 22@. Im obigen Beispiel zu Angestellten und ihren PC's könnten solche Attribute z.B. die Art des "Besitzverhältnisses" sein: als Administrator, als Nutzer, als Gast (mit jeweils spezifischen Rechten); der Beginn und das Ende der Nutzung. Eine Methode darauf könnte z.B. das Erstellen einer Mitteilung bzw. Eintragung, Austragung oder Änderung an eine zentrale Nutzerverwaltung sein. Im Folgenden ein solches Beispiel unter Nutzung der in der UML vorgeschlagenen grafischen Notation (vgl. >Meier und Wüst 1997, S. 22f@ und >Balzert 1999a, S. 45 und 50@). Dabei wird die assoziative Klasse mit ihren Attributen und Methoden mittels einer gestrichelten Linie mit der zu beschreibenden Beziehung verbunden.

Abbildung 9.2-8:

Beziehungsklasse auf binärer Beziehung

Damit besitzt, wie >Balzert 1999a, S. 45@ richtig schreibt, die Assoziation die Eigenschaften einer Klasse. Solche assoziativen Klassen sind auch für höherwertige Beziehungen möglich. Die folgende Abbildung zeigt eine für die oben eingeführte dreistellige Beziehung zwischen PCs, Angestellten und Abteilungen. In der Spezifizierung der Beziehung könnte zusätzlich zum Eintragen, Austragen und Ändern noch festgehalten werden, auf welche Kombination von Abteilung und PC sich die konkrete Nutzung bezieht.

9.2 Modellierung von Strukturen

Abbildung 9.2-9:

331

Beziehungsklasse auf ternärer Beziehung

In der Literatur zur UML fehlt nicht der Hinweis, dass eine solche Beziehungsklasse im Feindesign der Systemanalyse zu einer „richtigen“ Klasse wird, wobei dann natürlich die Wertigkeiten der Beziehung entsprechend übernommen werden müssen (vgl. [Oestereich 1998, S. 274]). Die folgende Abbildung zeigt das obige Beispiel zu ANGESTELLTEN und PC’S mit der Beziehungsklasse BESITZVERHÄLTNIS entsprechend aufgelöst. Die Wertigkeiten bestehen jetzt jeweils in Bezug auf das Besitzverhältnis: Aus Ein Angestellter nutzt genau einen PC wird x x

Ein Angestellter hat genau ein Besitzverhältnis und Ein Besitzverhältnis bezieht sich auf einen Angestellten

Aus Ein PC ist mehreren Angestellten zugeordnet wird x x

Ein PC hat mehrere Besitzverhältnisse und Ein Besitzverhältnis bezieht sich auf genau einen PC.

332

9 Objektorientierte Modellierung - Grundlagen

Abbildung 9.2-10: Implementierung von Assoziationen in Datenbanken

Wie Geppert richtig ausführt, können die in diesem Abschnitt betrachteten semantischen Beziehungen, je nach Datenbanksystem, auf verschiedene Weise implementiert werden >Geppert 1997, S. 7f@: x x x

Rekursive Assoziation

Aufgelöste Beziehungsklasse

wertbasiert mit Referenzen als Unterobjekte

Wertbasiert meint, dass identifizierende Attributsausprägungen eines Attributs der einen Klasse in der anderen hinterlegt werden. Im obigen PCBeispiel würden damit bei jeder Instanz in der Objektklasse ANGESTELLTE die Inventarnummern der PC's hinterlegt, die in der Verfügungsgewalt des jeweiligen Angestellten sind. Dies entspricht dem Konzept der objektwertigen Attribute, das oben eingeführt wurde. Die Beziehung ist hier implizit (Geppert) und basiert weitgehend auf Attributen und ihren Ausprägungen. Eine Lösung mit Referenzen sieht so aus, dass es durch das System verwaltete Verweise von der einen in die andere Objektklasse gibt. Diese werden mithilfe der Objektidentifikatoren eingerichtet. Im Beispiel wäre dann bei der Objektklasse ANGESTELLTE ein Attribut InvPCs, von dem die Zeiger in die andere Objektklasse PCs verweisen. Die Lösung mit Unterobjekten sieht so aus, dass ein Objekt als Teil eines anderen definiert wird. Dies führt zu dem Konzept der komplexen Objekte, das weiter unten diskutiert wird. Liegt eine Assoziation vor, an der nur eine Objektklasse beteiligt ist, spricht man von einer rekursiven Assoziation. Es geht also um eine Beziehung zwischen den Objekten einer Klasse, bei der jedes Objekt mit einem anderen Objekt in Beziehung gesetzt wird.

9.2 Modellierung von Strukturen

333

Betrachten wir als Beispiel eine Objektklasse ANGESTELLTE mit den üblichen Hierarchiestufen (z.B. Sachbearbeiter, Abteilungsleiter, Hauptabteilungsleiter, usw.). Hier stehen tatsächlich die Angestellten untereinander in einer Beziehung. Z.B. alle Sachbearbeiter einer Abteilung mit dem Abteilungsleiter und umgekehrt. Die folgende Abbildung zeigt die grafische Notation einer solchen rekursiven Assoziation. Angegeben sind auch Lesehinweise und die unterschiedlichen Rollen, die die Angestellten bei dieser Assoziation einnehmen.

Abbildung 9.2-11:

Rekursive Assoziation

Generalisierung/Spezialisierung Ein wichtiges Konzept der Realweltmodellierung ist die Generalisierung/Spezialisierung105. Es misst Ähnlichkeit zwischen den erfassten Informationsträgern, hier in der objektorientierten Modellierung also die Ähnlichkeit von Objekten bzw. Objektklassen. Ähnlich sind Objekte aus verschiedenen Objektklassen, falls sie Attribute und/oder Methoden gemeinsam haben. Ähnlichkeit bedeutet hier also auch, dass Objekte teilweise ein „gleiches Verhalten“ haben, bzw. dass auf sie dieselben Methoden anwendbar sind. Eine andere Sichtweise betont den Vorgang der Unterscheidung von Objekten, der hier vorliegt. Die Unterscheidung in „über-„ und „untergeordnete“ Objekte und dann – genauso wichtig – die Unterscheidung der untergeordneten voneinander. Oestereich schreibt hier vom Diskriminator, der im Rahmen des Modellierungsvorgangs gewählt werden muss [Oestereich 1998, S. 261f] und meint damit das Kriterium, nach dem die 105 Das Konzept der Generalisierung/Spezialisierung geht auf >Smith und Smith 1977a,b@ zurück.

Objektorientierte Ähnlichkeit

Diskriminatoren

334

Baumstruktur

Wurzel

Grafische Notation

9 Objektorientierte Modellierung - Grundlagen

Objekte unterschieden und die Objektklassen gebildet wurde. Im unten folgenden Beispiel zu datenverwaltenden Systemen wäre dies z.B. die Speichertechnik (in eine Datei, in verknüpfte Dateien, in invertierte Listen). Dabei kann eine Spezialisierungshierarchie durchaus mehrere Diskriminatoren berücksichtigen und diese können in der grafischen Notation angegeben werden (vgl. unten). Die Generalisierung/Spezialisierung führt zu einer Baumstruktur mit über- und untergeordneten Klassen. Eine untergeordnete Klasse (Subklasse wird als eine Spezialisierung einer übergeordneten Klasse (Superklasse) (evtl. auch mehrerer, vgl. unten) definiert. An der Spitze der so entstehenden Baumstruktur ist die Wurzel (root), sozusagen die allgemeinste Objektklasse des Datenmodells, z.B. „Objekte an sich“. Die Wurzel ist Superklasse für alle anderen, die jeweils unterste Ebene der Objektklassen hat nur die Eigenschaft Subklasse zu sein, alle Objektklassen dazwischen sind gleichzeitig Super- und Subklassen. Ein solcher "Baum" wird als Klassenhierarchie bezeichnet106. Stellen wir uns die Baumstruktur so vor, dass die Wurzel oben angeordnet ist und nach unten jeweils die Verzweigungen, dann liegen von oben nach unten Spezialisierungen und von unten nach oben Generalisierungen vor. Die Beziehungen zwischen den einzelnen Klassen entsprechen, von "oben nach unten", einer „Ist_ein-Beziehung“ („is_a“). Auch hier orientiert sich die grafische Notation an der UML. In ihr wird von jeder Subklasse zur Superklasse eine Linie mit einem großen nicht ausgefüllten Pfeil geführt. Die Pfeillinien eines Diskriminators können auch zusammen in eine Pfeilspitze geführt werden. Die Diskriminatoren können in der grafischen Notation angegeben werden, entweder bei jedem Pfeil oder für mehrere Pfeile durch eine gestrichelte Linie, die diese Pfeile verbindet. Alle diese Varianten sind im folgenden Beispiel dargestellt. Die Objektklasse PERSONEN wurde zum einen nach der Art des Arbeitsverhältnisses (Diskriminator) in ARBEITER, ANGESTELLTE und BEAMTE unterteilt. Zum anderen nach dem Diskriminator Umfang der Beschäftigung in VOLLZEITBESCHÄFTIGTE und TEILZEITBESCHÄFTIGTE sowie nach der Rolle im Lehrbetrieb in PROFESSOREN und STUDIERENDE.

106 Ganz korrekt und in der Begrifflichkeit der Graphentheorie formuliert, handelt es sich um einen azyklischen, gerichteten, nicht unbedingt zusammenhängenden Graphen mit den Klassen als Knoten und der Ist_ein-Beziehung als Kanten [Geppert 1997, S. 10].

9.2 Modellierung von Strukturen

Abbildung 9.2-12:

335

Generalisierung/Spezialisierung in einer Klassenhierarchie

Für überlappende Klassen schlagen >Meier und Wüst 1997@ vor, die Schnittmenge als eigene Klasse zu verarbeiten (S. 28). Insgesamt können folgende Subklassenvarianten unterschieden werden >Meier und Wüst 1997, S. 30@: x x x x

Disjunkte und vollständige Überdeckung einer Menge durch ihre Spezialisierungsmengen. Unvollständige, gegenseitig disjunkte Überdeckung. Überlappende und vollständige Überdeckung. Unvollständige und überlappende Überdeckung.

Abstrakte Klassen Für vollständige Überdeckungen wird das Konzept der abstrakten Klasse benötigt. Dies ist definiert als eine "künstlich eingeführte Klasse, die keine Instanzen enthält" >Meier und Wüst 1997, S. 30@. Mithilfe der Baumstruktur, die eine Generalisierung/Spezialisierung darstellt, kann nun ein zentrales Element des objektorientierten Ansatzes eingeführt werden, die Vererbung. Durch sie enthält jede Superklasse die

Vererbung

336

Hintergrund

Beispiel: Fahrzeuge

9 Objektorientierte Modellierung - Grundlagen

Attribute und Methoden, die alle ihre Subklassen gemeinsam haben. Jede Subklasse wiederum ergänzt die Attribute und Methoden ihrer Superklasse um ihre spezifischen. Zur Ausstattung der Subklasse gehören aber natürlich auch die Attribute und Methoden der Superklasse. Vererbung meint also den Vorgang, dass die Subklasse die Attribute, Methoden und Nachrichten (messages) der Superklasse besitzt, sie von ihr sozusagen „bekommt“. Das ganze ist auch eine Technik, und so sieht es vor allem die objektorientierte Systemanalyse, um definierende Informationen sparsam zu verwalten. Bei den Subklassen müssen nur die Methoden, Attribute und Nachrichten verwaltet werden, die zusätzlich dazukommen. Umgekehrt wird durch diese Vorgehensweise natürlich auch die Klassenhierarchie und die Ist_ein - Beziehung geklärt. An der Spitze der Hierarchie steht die allgemeinste Klasse, mit Attributen und Methoden, die alle Klassen gemeinsam haben. Die erste Ebene der Subklassen ergänzt diese dann um ihre jeweiligen spezifischen Attribute, usw. Aus obigem folgt bereits, dass natürlich Superklassen auch Subklassen einer übergeordneten Superklasse sein können. Das folgende Beispiel möge das Konzept der Vererbung etwas veranschaulichen. Angenommen, es sollen Fahrzeuge unterschiedlichster Art erfasst werden. Dann benötigt man für jeden Fahrzeugtyp eine Klassendefinition, weil jeder Fahrzeugtyp durch jeweils (teilweise) unterschiedliche Attribute und Methoden beschrieben wird. Auf diesen Klassendefinitionen kann eine Generalisierungshierarchie angelegt werden, da sie ja alle auch Attribute und Methoden gemeinsam haben. An der Spitze dieser Hierarchie soll eine Klasse Fahrzeuge (im Sinne von "Fahrzeuge aller Art") stehen. Die Attribute und Methoden, die auf den Fahrzeugen insgesamt und auf den einzelnen Spezialisierungen (PKW, LKW, Busse, Kettenfahrzeuge, Zweiräder, usw.) definiert sind, werden nun so angeordnet, dass die Objektklasse FAHRZEUGE alle Attribute und Methoden erhält, die für alle Fahrzeuge gleich sind. Die Spezialisierungen erhalten dann nur die Attribute und Methoden, die für die jeweilige Klasse spezifisch sind. Durch die Angabe der Vererbung (INHERIT) wird dann festgelegt, dass die Subklasse von ihrer Superklasse die Attribute und Methoden „erbt“, was nichts anderes heißt, als dass die Attribute und Methoden der Superklasse ebenfalls zur Verfügung stehen. Im textlichen Beispiel unten sind eine Klasse FAHRZEUGE und eine Klasse PKW angegeben. Durch die Angabe INHERIT erhält die Klasse PKW zusätzlich die Attribute und Methoden der Klasse FAHRZEUGE. Es ist auch möglich, ein Attribut in einer Subklasse neu zu definieren, wie es hier mit Kraftstofftyp geschehen ist (unter der Annahme, dass PKW nur verbleiten oder unverbleiten Kraftstoff tanken).

9.2 Modellierung von Strukturen

337

CLASS Fahrzeug PROPERTIES Kennzeichen, Fabrikat, Modell: String; Farbe: FarbenTyp; Kilometerstand: Integer: Kraftstofftyp: (verbleit, unverbleit, Diesel); Erstzulassung: Integer; OPERATIONS Neues_Fahrzeug (...) Wert (...) Fahren (...) Verkaufen (...) END Fahrzeug CLASS Auto INHERIT Fahrzeug PROPERTIES Kraftstofftyp: (verbleit, unverbleit); >neu definiert@ >zusätzliche Eigenschaften von Autos@ Größe. (kompakt, mittel, groß) Extras. Menge(OptionsTyp): END Auto

Die Baumstruktur wird durchbrochen, wenn eine Subklasse zwei Superklassen hat. Dies ist wichtig in Bezug auf die Vererbung (vgl. die Ausführungen zu Mehrfachvererbung unten). Natürlich muss hier auch die Situation der „Ausnahmen“ berücksichtigt werden, dass - z.B. bezüglich einer Methode - bestimmte Objekte einer Objektklasse eine Methode nicht ohne Modifikation „erben“ können. Denken wir nur z.B. an die Objektklasse Vögel. Deren Instanzen haben sicherlich alle die Eigenschaft „kann fliegen“, bis auf einige Ausnahmen. Solche Ausnahmen können erfasst werden, indem für die Ausnahmeobjekte die „geerbten“ Methoden und Attribute überschrieben werden können. Die oben diskutierte Vererbung basiert auf einer Weitergabe der Attribute. Es sind aber auch Situationen denkbar, wo die Werte dieser Attribute von einem Objekt zum anderen übertragen werden. Diese „instance inheritance relationships“ oder auch „value inheritance“ wird z.B. diskutiert in [Wilkes 1988, S. 274]). Ist eine Objektklasse Subklasse mehrerer Superklassen, liegt mehrfache Vererbung (engl. multiple inheritance) vor, die von einigen Datenbanksystemen angeboten wird: „In certain systems, a class can have several superclasses, in which case one talks of multiple inheritance, whereas others impose the restriction of a single superclass, single inheritance“ >Bertino und Martino 1993, S. 29@. In einem solchen Fall erbt also eine Subklasse die Methoden und Attribute mehrerer übergeordneter Klassen. Während die „einfache“ Vererbung zwischen einer Superklasse und einer Subklasse leicht zu lösen ist, bereitet die Mehrfachvererbung größe-

Ausnahmen

Mehrfache Vererbung

338

9 Objektorientierte Modellierung - Grundlagen

re Probleme. Hier kann es zu kollidierenden Attributen und Methoden kommen, z.B. wenn ein Attribut in zwei übergeordneten Superklassen mit unterschiedlichen Wertebereichen auftritt. Aggregation und Komposition

Beispiel

Begriffe

Ein weiteres wichtiges Konzept in der Objektmodellierung ist die Aggregation. Bei der Aggregation geht es um Beziehungen107, die den Tatbestand beschreiben, dass bestimmte Objekte in anderen enthalten sind108. Diese Komponenten können wiederum andere Objekte enthalten, die Beziehung kann also mehrstufig sein. Zum Beispiel besteht ein PC (Personal Computer) typischerweise (u.a.) aus einer Hauptplatine, Festplatten und einem Bildschirm. Auf der Hauptplatine wiederum finden sich (u.a.) Prozessoren, Speicherbausteine und Bussysteme (vgl. das Beispiel unten). Beliebt in der Literatur ist auch das Beispiel moderner Flugzeuge, die natürlich – vielstufig – aus zahlreichen Komponenten bestehen. Diese Komponentenstruktur liegt sehr oft vor, vor allem aber nicht nur in technischen Bereichen. Meier und Wüst schlagen die Begriffe Aggregationsklasse für die übergeordnete und Komponentenklassen für die untergeordneten vor >Meier und Wüst 1997@. Eine Komponentenklasse kann wiederum für weitere Objekte Aggregationsklasse sein. Oftmals wird diese Beziehung auch Teil_von-Beziehung (part_of-Beziehung) genannt. Geppert weist darauf hin, dass bei einer solchen Teil_von-Beziehung weitere Konsistenzbedingungen (neben der des "Enthaltenseins") möglich sind. Z.B. kann ein Unterobjekt als teilbar definiert werden, was bedeutet, dass es Teil von mehr als einem komplexen Objekt sein kann, oder als exklusiv, wonach es nur Teil von einem komplexen Objekt109 sein kann. Eine Definition als unabhängig bzw. abhängig bedeutet, dass es auch ohne bzw. nicht ohne sein komplexes Objekt existieren kann >Geppert 1997, S. 8@. In der folgenden Abbildung ist das oben erwähnte Beispiel in der UML-Notation angegeben. Jede Verbindungslinie von einer Komponenten- zu einer Aggregationsklasse bedeutet eine Teil_von-Beziehung und wird durch eine Raute wie in der Abbildung gezeigt grafisch ausge-

107 Bei einigen Autoren, z.B. [Balzert 1999], auch als Assoziationen aufgefasst, wodurch “Assoziation” zu einem übergeordneten Begriff für Beziehungen aller Art wird. 108 Bei einigen Autoren wird hiermit auch - wie oben beschrieben - der Zusammenhang zwischen Attributsnamen und Attributsausprägungen erfasst. Bei dieser Auffassung bedeutet dann der Schritt von der Menge der Ausprägungen zum Attribut (als solchem) eine Aggregation. Auch die Vorgehensweise in der ER-Modellierung, mehrere Attribute zu einem entity type zusammenzufassen, kann als Aggregation interpretiert werden. 109 Ein Objekt, das aus anderen besteht, wird auch komplexes Objekt genannt (vgl. unten).

9.2 Modellierung von Strukturen

339

drückt110. Die Raute kennzeichnet die Aggregation. Die einzelnen Beziehungen werden auch als Assoziationen bezeichnet und können auch mit den oben eingeführten Wertigkeiten spezifiziert werden.

Abbildung 9.2-13:

Erfassung einer Komponentenstruktur durch Aggregation

Eine textliche Beschreibung der Assoziationen wurde beispielhaft angegeben. Sie sind alle gleich. Die Kardinalitäten legen die Beziehungen beispielhaft111 fest: x x x x

Ein PC hat genau eine Hauptplatine Eine Hauptplatine steckt in maximal einem PC Ein PC hat mindestens eine Festplatte Jede Festplatte gehört zu maximal einem PC

110 Einige Autoren fassen bei einer baumartigen Anordnung der Aggregationsbeziehungen die Rauten zu jeweils einer zusammen. 111 Dem Verfasser ist bewusst, dass hier teilweise auch andere Werte möglich sind.

340

x x x x x x x x Vererbung?

Rekursive Definition

9 Objektorientierte Modellierung - Grundlagen

Ein PC hat genau einen Bildschirm Ein Bildschirm gehört zu maximal einem PC Eine Hauptplatine enthält mindestens einen, maximal vier Prozessoren Jeder Prozessor gehört zu maximal einer Hauptplatine Eine Hauptplatine enthält mindestens einen Speicherbaustein Jeder Speicherbaustein gehört zu maximal einer Hauptplatine112 Eine Hauptplatine enthält mindestens ein, maximal drei Bussysteme Jedes Bussystem gehört zu einer Hauptplatine

Bei der Aggregation gibt es keine Vererbung wie bei der Generalisierung/Spezialisierung. Sie wäre nicht sinnvoll, da die Subklassen ja von den Superklassen grundsätzlich verschieden sind. Natürlich existiert hier eine Komponentenklasse nur, falls die Aggregationsklasse da ist. Es liegt also eine Existenzabhängigkeit zwischen den Objekten der über- und untergeordneten Klassen vor. Das bekannte Beispiel einer Stückliste kann auch hier zur Veranschaulichung einer rekursiven Definition einer Objektklasse benutzt werden. Geht es um die zwei Beziehungen „Teil_von“ und „Obermenge“ von, kann eine Stückliste so wie in der nächsten Abbildung grafisch dargestellt und entsprechend modelliert werden. Bis auf ein Teil (das „oberste“) ist jedes „Teil_von“ genau einem anderen, woraus sich die konditionell einfache Assoziation in diese Richtung ergibt. Umgekehrt kann jedes Teil „Obermenge_von“ vielen anderen Teilen sein, muss aber nicht (die „untersten“), woraus sich die konditionell mehrfache Assoziation in diese Richtung ergibt (vgl. auch >Meier und Wüst 1997, S. 25f@).

Abbildung 9.2-14:

Einsatz dieser Beziehungsart

Stückliste - objektorientiert: reflexive Assoziation bzw. rekursive Klasse (in Anlehnung an [Meier und Wüst 1997, S. 25]

Auch dieses Enthaltensein ist ein zentrales Strukturmerkmal unserer Welt, das demzufolge auch in Modellen dieser Welt zur Verfügung stehen sollte. Grundsätzlich ist diese Art der Modellierung aber nur dann sinnvoll, wenn alle in der Aggregationsklasse erfassten Objekte auf dieselbe Art 112 Hier wird deutlich, dass es nicht um Typen (von Speicherbausteinen), sondern um einzelne Exemplare geht.

9.2 Modellierung von Strukturen

341

zusammengesetzt sind. Z.B., wenn strukturell identische Produkte hergestellt werden. Deshalb taucht in der Literatur hierzu auch meist als Beispiel Flugzeuge auf (wobei die Autoren von gleich aufgebauten ausgehen). Dieses Modellierungskonstrukt ist nicht geeignet, wenn sich die Zusammensetzung ändert, wenn es also das eine Komponentenobjekt nur bei bestimmten Objekten der Aggregationsklasse gibt. Welchen konkreten Nutzen bringt dieses Konzept, dieses Erfassen des „Enthaltenseins“? Am Beispiel des Datenbankbereichs kann die Antwort wie folgt gegeben werden: Prinzipiell wird die Abfrage erleichtert, wenn dann entsprechend leistungsstarke Abfragesprachen vorliegen, denn bei der Frage nach einem Objekt können automatisch die Komponenten mitausgegeben werden. Ähnliches gilt für Löschvorgänge. Zusammen mit einem Objekt können (müssen aber nicht, vgl. die Ausführungen zu Kompositionen unten) automatisch seine Komponenten mit gelöscht werden. Auch das Einfügen neuer Objekte wird erleichtert, da das Datenbanksystem die Komponenten automatisch anfordern kann. Zwei weitere Begriffe aus dem Umfeld der Aggregation, die im Kontext der UML diskutiert werden, seien hier noch angeführt (vgl. [Balzert 1999, S. 47ff]): Shared aggregation bedeutet, dass ein Teilobjekt mehreren Aggregatobjekten zugeordnet werden kann. Dies ist normalerweise nicht der Fall. Komposition: Hier gilt zusätzlich zu dem, was für Aggregationen gilt, dass jedes Objekt einer Komponentenklasse (Balzert spricht von Teilklassen) zu einem bestimmten Zeitpunkt nur Komponente eines einzigen Objekts der Aggregatklasse sein darf. Es muss also bei der Aggregationsklasse eine Kardinalität von nicht größer als eins vorliegen (unshared aggregation, strong ownership). Außerdem gilt, dass bei einem Löschen eines Aggregationsobjekts die entsprechenden Komponentenobjekte ebenfalls gelöscht werden. Die Komponenten sind also existenzabhängig vom Ganzen. Das klassische Beispiel hierfür ist die Beziehung zwischen einem Rechnungskopf und den Rechnungspositionen, das in der folgenden Abbildung angegeben ist.

Abbildung 9.2-15:

Die Beziehung zwischen Rechnung(skopf) und Rechnungspositionen als Komposition

Bei Kompositionen wird die Raute eingeschwärzt, ansonsten ist die grafische Notation dieselbe wie für Aggregationen. Die Kardinalität auf der Seite der Aggregation ist immer eins, so dass sie auch oft weggelassen wird. Als wesentlich für eine Komposition wird die Existenzabhängigkeit zwischen Aggregat und Komponente gesehen, die auch dazu führt, dass

Einschätzung

shared aggregation Komposition

342

Methoden

9 Objektorientierte Modellierung - Grundlagen

bei einem Löschen des Aggregats alle Komponenten mitgelöscht werden (was bei einer einfachen Aggregation nicht verlangt ist). Methoden bei der Rechnung könnten hier z.B. die Bestimmung der Anzahl Positionen und die Bestimmung der Gesamtsumme sein. Zur konkreten Abgrenzung von Assoziationen, Aggregationen und Kompositionen vgl. [Balzert 1999, S. 48f]. Oestereich gibt einen Hinweis auf die Organisation der Methoden im Rahmen einer Aggregation. Hier übernimmt die Aggregationsklasse Aufgaben stellvertretend für ihre Komponentenklassen. Sie enthält z.B. Operationen, die keine unmittelbare Veränderung in der Aggregationsklasse bewirken, die aber Nachrichten an die Komponenten weiterleiten (Propagieren von Operationen) [Oestereich 1998, s. 284]. Komplexe Objekte Objekte werden auch im objektorientierten Ansatz in erster Linie durch Attribute beschrieben, Attribute in der ganz üblichen Auffassung wie oben beschrieben. Zusätzlich können hier allerdings die Ausprägungen eines Attributs nicht nur die üblichen einfachen Attributsausprägungen sein, sondern ganze Objekte, Mengen von Attributsausprägungen oder Mengen von Objekten. Mit den Worten von Bertino und Martino: „The values of an object’s attributes can be other objects, both primitive and non-primitive ones.“ >Bertino und Martino 1993, S. 16@

Teil_von

Mit den „primitive objects“ sind hier Attributsausprägungen gemeint. Liegen nun aber als „Attributsausprägungen“ nicht-primitive Objekte vor, spricht man von komplexen oder zusammengesetzten Objekten. Entsprechend beschreiben [Balzert 1999, S. 542] und [Meier und Wüst 1997, S. 6] komplexe Objekte als Objekte, „deren Attribute selbst wiederum Objekte sein können“. Ein komplexes Objekt besteht also (u.a.) aus einfacheren Objekten, die auch Unterobjekte [Geppert 1997, S. 7] genannt werden. Das Verhältnis von Objekten zu Unterobjekten setzt Geppert mit einer Teil_von - Beziehung bzw. Aggregation gleich. Kapselung und Information Hidding

Kapselung in Objektmodellen

Mit dem Begriff der Kapselung (encapsulation) wird im objektorientierten Ansatz die Technik benannt, Datenstrukturen (die Objekte und Beziehungen repräsentieren) und Prozeduren zur Manipulation der internen Repräsentation der Datenstruktur logisch und softwaretechnisch zusammenzufassen113. Jedes Objekt enthält und definiert die Prozeduren (Methoden) und die Schnittstelle (das Interface) durch die es angesprochen und manipuliert werden kann (durch andere Objekte). Die Schnittstelle 113 Dieses Konzept geht auf das der abstrakten Datentypen zurück.

9.2 Modellierung von Strukturen

343

eines Objekts besteht aus einer Menge von Operationen, die auf das Objekt angewandt werden können. Somit kann der Zustand eines Objekts (the state of an object), d.h. die konkreten Ausprägungen seiner Attribute, nur durch die Methoden verändert werden, die durch die entsprechenden Operationen aufgerufen werden. Damit bleibt die interne Repräsentation der Datenstruktur und der Methoden dem Nutzer verborgen. D.h. die Nutzer sehen nur die Objekte, usw., wie diese intern realisiert werden, bleibt für sie unsichtbar. Verkapselung erlaubt somit „information hidding“ und liefert einen weiteren Abstraktionsmechanismus114. Die Kapselung erlaubt somit auch, dass sich z.B. die Methoden einer Klasse ändern können, ohne dass der übrige Bereich der Anwendung tangiert wird (falls die Schnittstelle gleich bleibt). Insofern ist der objektorientierte Ansatz „weiter weg“ von den physischen Datenstrukturen und den Programmkontrollstrukturen. Er folgt damit einem Trend in der Softwareentwicklung. Er steht für eine bestimmte höhere Form logischer Datenunabhängigkeit (vgl. hierzu auch >Bertino und Martino 1993, S. 18@).

Information hidding

Exkurs: Eignung für Unternehmensmodellierung – Teilbereich Datenbanken Ein wichtiger (und klassischer) Teilbereich der Unternehmensmodellierung ist die sog. Datenmodellierung, die Entwicklung von Datenbanken für Unternehmen. Heute bedeutet dies konkret die Entwicklung von Datenbanken für die informationelle Absicherung der Geschäftsprozesse eines Unternehmens. Die klassischen Techniken sind hier die relationale Datenmodellierung und die ER-Modellierung. Für diesen Bereich ist der objektorientierte Ansatz aus mehreren Gründen fruchtbar. Zum einen, weil er erlaubt, die (halbwegs) natürliche Wahrnehmung eines Weltausschnitts als Ansammlung von Objekten mit Beziehungen direkt in das Datenmodell hinein abzubilden. Nicht wenige Autoren schreiben sogar von einer 1:1-Abbildung zwischen Objekten der Realwelt und Objekten des objektorientierten Datenmodells (vgl. unten). Ein zweiter Punkt ist aber genauso wichtig. Sieht man (statische) Datenbanken letztendlich als informationelle Grundlage von (dynamischen) Geschäftsprozessen, dann erlaubt die im objektorientierten Ansatz vorgenommene Aufhebung der Trennung von dynamischen und statischen Aspekten eines Weltausschnitts u.U. eine geeignetere Modellie114 In Bezug auf Datenbanksysteme stellt dieses Konzept eine Fortsetzung der sog. logischen und physischen Datenunabhängigkeit dar.

Spezifisch in Datenbanken

344

9 Objektorientierte Modellierung - Grundlagen

rung auch im Bereich der Geschäftsprozesse. Dies wird unten diskutiert. Die Unterscheidung von Objekten der Realwelt und der Datenbank wurde in dieser Arbeit früher schon benutzt, hier gewinnt sie nun aber besondere Bedeutung. Die Bedeutung ist dieselbe wie oben: Den Objekten der Realwelt auf der einen Seite stehen ihre Repräsentanten in der Datenbank gegenüber. In einer Personaldatenbank z.B. liegen in der Realwelt (datenbanktechnisch: dem Weltausschnitt) die Beschäftigten selbst vor. In der Datenbank finden sie sich dann als Datenbankobjekte mit einer spezifischen Datenstruktur wieder.

Realweltobjekte vs. Datenbankobjekte

Natürlich bedarf das vorgestellte Instrumentarium einiger Ergänzungen, um in vollem Umfang datenbanktauglich zu werden. Dies sind datenbankspezifische Konzepte wie z.B. Persistenz, Extensionen, Transaktionen, Konsistenzbedingungen, u.a. (vgl. [Geppert 1997, S. 26] und für eine umfassende Darstellung >Meier und Wüst 1997@). 9.2.3 Systemanalyse vs. Datenmodellierung

Dynamische Aspekte

Die Trennung von statischen und dynamischen Aspekten ist im objektorientierten Ansatz, wie oben schon andiskutiert, teilweise aufgehoben. Hauptursache ist die direkte Verknüpfung von Daten und Methoden. Dadurch ist die Trennung von Datenmodellierung und Systemanalyse nicht mehr so deutlich zu erkennen, wie dies früher115 der Fall war. Aus der Sicht der Systemanalyse geht es sogar vorwiegend um dynamische Aspekte, um das Verhalten (behavior) eines Systems, wie auch die folgende Definition der Object Management Group (OMG) zeigt: „The description of behavior involves two aspects: 1) the structural description of the participants and 2) the description of the communication patterns.“ [OMG 1999, S. 3-110]

Nachrichten

Dieser Abschnitt widmet sich nun dem zweiten Punkt. Eine wichtige Grundlage für das, was die dynamischen Aspekte einer Anwendung ausmacht, ist der gegenseitige Aufruf von Methoden durch Objekte bzw. Objektklassen mit Hilfe von Nachrichten [Booch, Rumbaugh und Jacobson 1999, S. 232]. Wie oben gezeigt, sind bei den Objektklassen Methoden hinterlegt, mit denen die Objekte der jeweiligen Klasse verarbeitet werden können. Dabei handelt es sich um Methoden, die zur Erfüllung einer Teilaufgabe in 115 Damit ist die Ära vor der objektorientierten gemeint, also ER-Modellierung und relationale Modellierung in der Datenmodellierung und die nicht-objektorientierten systemanalytischen Ansätze (z.B. die Strukturierte Analyse) in der Systemanalyse.

9.2 Modellierung von Strukturen

345

der Gesamtanwendung dienen. Für viele Aufgaben ist es aber notwendig, dass die Methoden verschiedener Objektklassen im korrekten Zusammenspiel aufgerufen werden. Dies wird so realisiert, dass Objekte der einen Objektklasse Methoden einer anderen aufrufen können. Modellierungstechnisch wird dies mit dem Konzept von Nachrichten, die zwischen den Objekten und Objektklassen ausgetauscht werden, realisiert. Dieses Konzept müsste in der Unternehmensmodellierung auf jeden Fall berücksichtigt werden. Auch in der objektorientierten Datenmodellierung. Auch hier sind die Nachrichtenkanäle explizit mit zu modellieren, was bedeutet, dass die für die Anwendung notwendigen Aufrufe von Methoden vorgedacht und im Datenmodell festgehalten werden. Definiert man, wie oben geschehen, Operationen als Dienste, die von einem Objekt angefordert werden können, und als Methoden die Implementierungen der Operationen, dann können Nachrichten so definiert werden:

Methoden – Operationen – Nachrichten

„Eine Nachricht überbringt einem Objekt die Information darüber, welche Aktivität von ihm erwartet wird und fordert es zur Ausführung einer Operation auf.“ [Oestereich 1998, S. 236] Nur unwesentlich verkürzt bei Meier und Wüst: „Unter einer Nachricht (engl. message) versteht man die Aufforderung eines Objektes an ein anderes, eine bestimmte Methode auszuführen. Die Menge aller öffentlichen Meldungsnachrichten, die einer Klasse zur Verfügung stehen, wird als Protokoll bezeichnet“ >Meier und Wüst 1997, S. 32@. Enthält ein Objekt einer Klasse eine Nachricht, führt es somit entweder seine eigenen Methoden aus oder es erzeugt selbst neue Nachrichten, die Methoden anderer Objektklassen aufrufen. Nachrichten haben einen Namen und Parameter. Nachrichten und Methodenname mit Ein- und Ausgabeparametern werden als Signatur der Methode bezeichnet (vgl. auch oben). In der grafischen Darstellung objektorientierter Datenmodelle werden Nachrichtenkanäle durch Pfeilsymbole zwischen Objektklassen kenntlich gemacht. Die Richtung der Nachricht zeigt vom sendenden zum empfangenden Objekt. Falls eine Rückantwort erfolgen soll, wird ein entsprechender Kanal modelliert. Damit, so >Meier und Wüst 1997, S. 33@, werden „werden sämtliche Interaktionen zwischen Objekten unterschiedlicher Klassen durch Nachrichten modelliert.“ Unterschieden wird dabei der Aufruf von Instanzmethoden und von Klassenmethoden. Erstere betreffen Methoden, die einzelne Instanzen, z.B. eine Preisänderung bezüglich einer Instanz einer Objektklasse zu Produkten. Zweitgenannte betreffen Methoden, durch die alle Objekte einer Objektklasse angesprochen sind, z.B. die Veränderung der Mengenangabe bei Einfügen eines neuen Produkts.

Meldungsverkehr

Instanz- und Klassenmethoden

346

9 Objektorientierte Modellierung - Grundlagen

Der Aufruf von Methoden steht bei realen Anwendungen in der Regel oft in einem größeren Zusammenhang, z.B. dann, wenn der Aufruf eine von vielen Operationen aus der Abarbeitung einer größeren Aufgabe (z.B. einem Geschäftsprozess) betrifft. Ganz besonders deutlich wird dies bei Echtzeitanwendungen, wie Meier und Wüst ausführen (Hervorhebung durch den Verfasser): „Manchmal steht dabei die Reihenfolge der einzelnen Interaktionen (Nachrichten) im Vordergrund, manchmal das zeitliche Verhalten unter Berücksichtigung von Wartezeiten und Ausführungszeiten. Bei solchen Echtzeitanwendungen müssen bereits bei der Analyse oder beim Entwurf die zeitlichen Anforderungen miteinbezogen werden. Ereignisse werden durch Nachrichten modelliert und neben der Identifikation von einzelnen Nachrichten wird die Reihenfolge der Nachrichten auch in einer zeitlichen Abhängigkeit spezifiziert. Solches Verhalten kann mittels Zustandsübergangsdiagrammen ... oder Nachrichtensequenzen ... modelliert werden.“ >Meier und Wüst 1997, S. 33@ Hier liegt ein erster Bezugspunkt zu Geschäftsprozessen vor.

In Kapitel 10 verwendete Begriffe aus der UML (in der Reihenfolge ihres Auftretens) Deutsch

Englisch

Verhalten Verhaltensmodellierung Host-Objekt

behavior behavioral modeling host object executing behavior emergent behavior token object token data token control token classifier entity construct concept

Token Objekttoken Datentoken Kontrolltoken Informationsträger, Entität Konstrukt Konzept

10 Objektorientierte Modellierung von Verhalten und Abläufen

10.1 Einführung In diesem Kapitel wird beschrieben, welche Werkzeuge die objektorientierte Theorie für die Modellierung von Vorgängen, Tätigkeiten, Tätigkeitsfolgen, kurz: für die dynamischen Aspekte der Anwendung oder des Anwendungsbereichs anbietet. In der objektorientierten Terminologie wird dabei von der Modellierung von Verhalten (behavior) gesprochen. Dies gilt auch für die UMLAutoren, die konsequent den Begriff behavior verwenden, wenn es um diese dynamischen Aspekte geht. Dies tun sie auch in Situationen, wo im deutschen Sprachgebrauch die Übersetzung Verhalten nicht passend erscheint, weil das modellierte System nicht handelt, sondern nur reagiert (dann aber natürlich handelt). Nehmen wir das hier im im folgenden öfters angeführte Beispiel eines Geldautomaten. Er handelt zwar („Geldausgabe“), er wartet aber auch oft auf Eingaben („Warten auf EC-Karte“, „Warten auf Geheimzahl“, usw.) und stellt da höchstens Verhalten zur Verfügung. Noch größer ist die begriffliche Unstimmigkeit bei Geschäftsprozessen. Geschäftsprozesse („Angebotserstellung“, „Personaleinstellung“) haben kein „Verhalten“, sondern sie beschreiben Tätigkeiten, die – von Mensch oder Maschine / Programm – erledigt werden. Auch einzelne Funktionen von Geschäftsprozessen („Kalkulation durchführen“, „Personalbogen ausfüllen“) haben kein Verhalten, sondern beschreiben kleinere, eng zusammhängende Tätigkeiten. Der Begriff Verhalten wird daher in den folgenden Abschnitten zwar benutzt, aber nicht in der Ausschließlichkeit, wie es die UML-Autoren tun. Hier wird öfters auch von Tätigkeiten, Tätigkeitsfolgen, Abläufen oder eben auch Geschäftsprozessen die Rede sein, die vom jeweiligen Modell realisiert werden.

Verhalten behavior

350

10 Objektorientierte Modellierung von Verhalten und Abläufen

Anmerkung: Wie kommen die UML-Autoren dazu, die dynamischen Aspekte eines Anwendungsbereichs ganz unter den Begriff „Verhalten“ zu packen? Die Antwort findet man, wie so oft bei der UML, wenn man sich in die Situation eines Softwareentwicklers versetzt. Bei dessen Arbeit sind die dynamischen Aspekte (Angestellte können eingestellt, entlassen, befördert und mit Gehältern versehen werden) zu Methoden von Klassen geworden, die von der Klasse zur Verfügung gestellt werden. Dann ist auch „Einstellen“ eine solche Methode, genauso wie „Kündigen“, obwohl aus der Geschäftsprozessperspektive Ersteres mit dem Angestellten geschieht und nur Zweiteres eine aktive Handlung eines „Objekts“ darstellt. Zur Verfügung gestellte Methoden können aber, egal welchen Hintergrund sie haben, durchweg als das Verhalten der Klasse (bzw. ihrer Objekte) aufgefasst werden. Insgesamt machen sie das „Gesamtverhalten“, die einzelnen Methoden Verhaltensaspekte aus. Die Antwort auf die zu Beginn dieser Anmerkung gestellte Frage ist daher, dass die UML-Autoren die Perspektive von Softwareentwicklern einnehmen und mit dieser ihr Theoriegebäude erstellen. Inhalt der folgenden Abschnitte

In den folgenden Kapiteln werden nun alle Konstrukte vorgestellt, die die objektorientierte Theorie für die Modellierung von Verhalten / Tätigkeitsfolgen anbietet. Und dies in einer solchen Tiefe, dass sie erstens verstanden werden können und dass sie zweitens auf ihre Tauglichkeit für die Modellierung von Geschäftsprozessen geprüft werden können. Damit wird dann auch geklärt, ob sie für eine integrierte Unternehmensmodellierung taugen. Betrachtet wird der objektorientierte Ansatz in seiner Ausprägung in der Unified Modeling Language (UML). Auch hier bei der Verhaltensmodellierung haben die UML-Autoren einen hohen Anspruch, wie die wesentlich ausführlichere und konsequentere Behandlung der Verhaltensmodellierung in der Version 2.0 zeigt. Dabei liegt aber natürlich der Schwerpunkt in der UML weiterhin auf der Systemanalyse, wie der Sprachgebrauch (sehr oft ist direkt von Systemen die Rede bei der Vorstellung der einzelnen Konstrukte) und auch das folgende Zitat zeigt: “The Unified Modeling Language is a visual language for specifying, constructing and documenting the artifacts of systems. It is a general-purpose modeling language that can be used with all major object and component methods, and that can be applied to all application domains (e.g., health, finance, telecom, aerospace) and implementation platforms (e.g., J2EE, .NET).” [OMG 2003b, S. 22] In der Version 1.5 war der übergeordnete Anspruch, auch für die Unternehmensmodellierung tauglich zu sein, noch wesentlich deutlicher:

10.2 Verhalten

351

“Note that UML can be used to model different kind of systems: software systems, hardware systems, and real world organizations. Business modeling models real-world organizations.” [UML 1997a, S. 1] Allerdings wird auch in der Version 2.0 dieser Anspruch wieder formuliert, im Sprachgebrauch116, in den Beispielen (vgl. unten) und auch direkt, wie das folgende Zitat aus dem Kapitel zu den Aktivitäten zeigt: “Activities may describe procedural computation. In this context, they are the methods corresponding to operations on classes. Activities may be applied to organizational modeling for business process engineering and workflow. In this context, events often originate from inside the system, such as the finishing of a task, but also from outside the system, such as a customer call.” ([OMG 2003a, S. 284], Hervorhebung durch den Verfasser). Das Zitat zeigt auch wiederum sehr schön den “Spagat” auf, den die UML-Autoren leisten wollen. Zum einen soll die klassische Aufgabe bezüglich Systemanalyse und Systemdesign erfüllt werden, zum anderen die rund um Geschäftsprozesse. Die Zahl der Begriffe, die die UML-Autoren bei den Konstrukten zur Verhaltensmodellierung benötigen, ist sehr groß. Um die Übersichtlichkeit zu erhöhen, werden daher zu Beginn eines jeden Kapitels die verwendeten Begriffe angegeben, in ihrer Originalsprache und in der gewählten Übersetzung. Bei übersetzten Begriffen wird auch im Text immer wieder der Originalbegriff angegeben, um die Verbindung zum Originaltext herzustellen. Letztendlich wird es unumgänglich sein, für einzelne Fragen den Originaltext zu konsultieren, da sollten diese Begriffe eine Hilfe sein. Handelt es sich bei einem Konstrukt um eine Klasse aus der UMLMetamodellierung, dann wurde in der Regel die dort dafür übliche Schreibweise beibehalten: Großschreibung der einzelnen Worte, falls mehrere Worte Aneinanderfügen ohne Leerzeichen. Also z.B. Action bzw. AcceptEventAction. Auch dies soll die Arbeit mit der Originaldokumentation erleichtern, denn für jede dieser Klassen gibt es dort einen eigenen Abschnitt.

Begrifflichkeit

Schreibweisen

10.2 Verhalten Im Gegensatz zum vorigen Kapitel geht es hier nicht um Informationsstrukturen, nicht um statische Aspekte eines Systems (oder auch eines Geschäftsprozesses), sondern um die dynamischen Aspekte, das System116 In vielen Erläuterungen werden Beispiele aus dem Bereich der Geschäftsprozesse gewählt wie Auftrag eingegangen, Auftragsversand, Personaleinstellung usw.

Struktur vs Verhalten

352

Definition Verhalten

10 Objektorientierte Modellierung von Verhalten und Abläufen

verhalten bzw. die Tätigkeitsfolgen in Geschäftsprozessen. Die UMLAutoren schreiben in diesem Zusammenhang auch konsequent von Verhaltensmodellierung (behavioral modeling). Sie definieren Verhalten als die beobachtbaren Wirkungen eines Vorgangs (operation) oder Ereignisses, einschließlich seiner Ergebnisse. [OMG 2003a, S. 5]. Beispiel für einen Vorgang bei einem Geldautomat: Kunde schiebt EC-Karte rein. Sie präzisieren dann dahingehend, dass Verhalten in diesem Sinne die Programmschritte (computation) festlegt, die die Effekte des Verhaltens (der Verhaltenseigenschaft (behavioral feature) erzeugen. Beispiel für Verhalten + Effekte desselben bei einem Geldautomat: Karte wird geprüft. Falls gültig, wird die Auszahlung angestoßen, falls ungültig, wird die Karte einbehalten, das Personal informiert und dem Kunden eine Nachricht angezeigt. Im dritten Teil dieser Definition [OMG 2003a, S. 5] geben sie auch gleich an, welche Formen das Beschreiben eines Verhaltens annehmen kann: „interaction, statemachine, activity, or procedure (a set of actions)“. Diese Begriffe werden unten erläutert. Verhalten bedeutet hier also in erster Linie Systemverhalten. Und zwar auf Anforderungen von außerhalb des Systems (Kunde schiebt EC-Karte in den Geldautomaten) oder von innerhalb (digitale Auszahlkomponente startet mechanische Auszahleinrichtung). Es ist also der „gute, alte“ Systembegriff, der hier wieder zugrundeliegt. Etwas anderes wäre auch nicht möglich, wenn man den Hauptzweck der UML sieht, die Systemanalyse und die Unterstützung der Softwareentwicklung. Trotzdem muss man, da ja der Anspruch der UML-Autoren auch ist, die Prozessmodellierung zu unterstützen, nach der Tauglichkeit dafür fragen. Dazu mehr in den folgenden Kapiteln. Mit dabei: die Anwender Bei jeder Verhaltensmodellierung werden automatisch auch die Anwender mit betrachtet, da ein Teil der „Dynamik“ von ihnen kommt: Unter Umständen starten sie den zum Verhalten gehörenden Vorgang, oftmals nutzen sie das entstehende System. Dieses Einbinden der Anwender geschieht stärker bei der Geschäftsprozessmodellierung, etwas weniger bei der Systemanalyse, wo ein Teil „der Dynamik“ auch vollautomatisch zwischen den Systemkomponenten abläuft. 10.2.1 Starke Verknüpfung von Objekten und Verhalten Im objektorientierten Ansatz sind Objekte und Verhalten untrennbar miteinander verknüpft: x

Verhalten = Aktion von Objekten.

10.2 Verhalten

353

Jedes Verhalten ist das direkte Ergebnis der Aktion mindestens eines Objekts [OMG 2003a, S. 369]. Beispiele dafür bei einem Geldautomaten sind „Einzug EC-Karte um sie zu lesen“, „Ausgabe Geldscheine nach erfolgter Prüfung“. Das Wort „mindestens“ deutet aber schon an, dass die UML-Autoren auch das Zusammenwirken mehrerer Objekte (bzw. des Verhaltens mehrerer) als Grundlage eines modellierten Verhaltens sehen. Die UML-Autoren prägen für das Objekt, von dem das Verhalten stammt, den Begriff Host-Objekt (host object). Der Zusammenhang zwischen Objektstruktur und Verhalten wird so gesehen, dass das Verhalten Objektzustände verändert: x

Host-Objekt

Verhalten = Änderung von Objektzuständen.

Objekte haben Zustände, die durch Struktureigenschaften fixiert sind. Diese Zustände können sich im Zeitablauf ändern. Genau diese „Zustandsveränderungen“ stellen Verhalten dar. Nehmen wir als Beispiel das Karteneinzugsgerät bei einem Geldautomaten. Zustand 1 könnte sein: Bereit Karte anzunehmen. Zustand 2: Gesperrt. Usw. Fast schon philosophisch werden die UML-Autoren, wenn sie darauf hinweisen, dass Verhalten in diesem Sinn somit nicht für sich alleine existiert und nicht kommuniziert [OMG 2003a, S. 369]. Verhalten ist somit untrennbar mit seinem Träger, dem Objekt (oder den Objekten), verbunden. Diese enge Verknüpfung bleibt natürlich auch bestehen, wenn es um die Verarbeitung von Daten geht: Hat Verhalten mit Daten zu tun, dann kommen die Daten vom „Host-Objekt“. Damit ergibt sich eine sehr enge Definition von Verhalten, deren Eignung für die Geschäftsprozessmodellierung in Kapitel 17 diskutiert wird. Eine Ausnahme gibt es von dieser stringenten Definition. Das sog. executing behavior, das gleich hier unten eingeführt wird. Dieses kann auch selbst ein Objekt sein [OMG 2003a, S. 369].

Daten vom Host-Objekt

10.2.2 Executing und Emergent Behavior Die UML-Autoren unterscheiden zwei Arten von Verhalten: executing behavior und emergent behavior. Executing Behavior Executing behavior wird durch ein Objekt ausgeführt, seinen Host. Es stellt die Beschreibung des Verhaltens dieses Objektes dar und wird direkt verursacht durch den Aufruf einer Verhaltenseigenschaft (behavioral feature) dieses Objekts oder durch dessen Erzeugung. In beiden Fällen ist es die Konsequenz der Ausführung einer Aktion durch ein Objekt. Ein Verhalten hat Zugriff auf die Strukturmerkmale seines Host-Objekts.

emergent vs executing

354

10 Objektorientierte Modellierung von Verhalten und Abläufen

Emergent Behavior

Einschränkung?

Emergent behavior entsteht aus dem Zusammenwirken von Objekten. Es stellt also das Verhalten einer Gruppe von Objekten dar. Falls die zusammenwirkenden Objekte Teil eines größeren zusammengesetzten Objektes sind, kann es auch so gesehen werden, dass es – indirekt – auch das Verhalten des Container-Objekts beschreibt. Dennoch ist ein emergent behavior schlicht die Summe der executing behaviors der zusammenwirkenden Objekte. Ein klein wenig löst sich die enge Verbindung von Objekten und Verhalten mit den folgenden Ausführungen auf: Obwohl Verhalten letztendlich mit einem Objekt verknüpft ist, kann emergent behavior auch für nicht-instanziierbare Classifier wie interfaces oder collaborations festgelegt werden. Solch ein Verhalten beschreibt die Interaktion der Objekte, die die Schnittstellen realisieren oder die Teile der collaboration [OMG 2003a, S. 369]. Beispiel Beispiele für ein emergent behavior ist die Ausführung eines Anwendungsfalles oder einer Interaktion (vgl. unten).

10.3 Konstrukte für die Verhaltensmodellierung Die Version 2.0 der UML, die nun vorliegt, enthält gegenüber den früheren Versionen verbesserte Konzepte für die Modellierung der dynamischen Aspekte eines Systems (oder eines Geschäftsprozesses). Folgende Grundkonzepte bieten die UML-Autoren nun an: x x x x x

Aktionen (actions) Aktivitäten (activities) Interaktionen (Interactions) Zustandsautomaten (state machines) Anwendungsfälle (use cases

Das hier tatsächlich teilweise Neues vorliegt sehen auch die Autoren der UML. Unter dem Titel “Changes from previous UML“ führen sie aus: „Explicitly modeled actions as part of activities are new in UML 2.0, and replace ActionState, CallState, and SubactivityState in UML 1.5. They represent a merger of activity graphs from UML 1.5 and actions from UML 1.5. Local pre and postconditions are new to UML 2.0.“ [OMG 2003a, S. 283] Den Zusammenhang zwischen diesen Konstrukten, die im Rahmen der Metamodellierung der UML als Klassen modelliert sind, deutet die folgende Abbildung an. CommonBehaviors dient als Generalisierung der

10.4 Basiskonzepte für die Verhaltensmodellierung

355

Klassen mit den eigentlichen Konstrukten. Diese werden in den folgenden Kapiteln erläutert.

Abbildung 10.3-1:

Die Konstrukte der UML für die Modellierung von Verhalten und ihr Zusammenhang. Quelle: [OMG 2003a, S. 201], grafisch verändert, Übersetzung durch den Verfasser

10.4 Basiskonzepte für die Verhaltensmodellierung 10.4.1 Token In Zusammenhang mit der Verhaltensmodellierung spielt bei den UMLAutoren der Begriff des Token eine sehr große Rolle. Bei der Ausarbeitung des Kontrollflusskonzepts (vgl. unten) dient er sogar der methodischen Fundierung. Da er auch schon sehr früh bei den folgenden Ausführungen vorkommt, wird er hier erläutert. In der Informatik taucht dieser Begriff im Zusammenhang mit formalen Sprachen auf, im engeren Bereich der Compiler bzw. Parser: „Die erste von einem Compiler zu lösende Aufgabe besteht darin, das Programm in Token zu zerlegen; Token sind Teilstrings, die logisch zusammenpassen. Beispiele sind Bezeichner, Konstanten, Schlüsselwörter wie then und Operatoren wie + oder <=. Jedes Token kann als regulärer Ausdruck spezifiziert werden;“ [Aho und Ullmann 1996, S. 751] Etwas detaillierter bei [Horn, Kerner und Forbrig 2001, S. 409] in Bezug auf das Beispiel C++:

Token in der Informatik

356

10 Objektorientierte Modellierung von Verhalten und Abläufen

„Der Eingabestrom wird ... in Abschnitte (Lexeme) zerlegt. Dabei gibt es Lexeme, die herausgefiltert werden, weil sie syntaktisch keine Bedeutung haben, wie z.B. Kommentare, und solche, die zusammen mit einigen Zusatzinformationen ... an die syntaktische Analyse weitergegeben werden. Diese werden auch Token genannt.“ Die syntaktische Analyse erzeugt „... einen Tokenstrom, der ... dem Parser übergeben wird, der die eigentliche syntaktische Analyse vornimmt. In der Sprechweise der formalen Sprachen sind die Token (in der Literatur auch Morpheme genannt) die Terminalsymbole für den Parser. Typische Token sind Wortsymbole (Schlüsselwörter, reservierte Wörter), Klammern, Operatoren, Literale (Zahlwörter, Zeichenketten) und Bezeichner (Namen für Konstanten, Variablen und Funktionen).“

Nun die UMLAutoren:

Dasselbe meinen [Gumm und Sommer 1998, S. 542], wenn sie Token als elementare Bestandteile eines Programmes definieren. Zusammengefasst kann damit festgehalten werden, dass in der Informatik Token kleinste interpretierbare Einheiten einer formalen Sprache sind. Die UML-Autoren erläutern bei der Beschreibung der Semantik von Aktivitäten, was sie unter einem Token verstehen (alle nachfolgenden Zitate stammen von [OMG 2003a, S. 286]): Ein Token enthält ein Objekt, einzelne Daten oder Kontrollinformation. Dabei geht es um Objekte von Objektklassen aus dem objektorientierten Modell, das den dynamischen Bereich umgibt, oder um etwas virtuelles, was direkt aus der Modellbildung kommt, um die Information, wo der Kontrollfluss gerade steht. Die UML kennt mittlerweile, wie unten erläutert wird, ein Kontrollflusskonzept und zu diesem gehört natürlich dann auch die Information, an welcher Stelle (typischerweise Knoten) der Kontrollfluss bei einer konkreten Realisierung wann steht. Ein Token ist im Aktivitätsdiagramm (das eine Tätigkeitsfolge beschreibt) einem bestimmten Knoten zugeordnet. Das ergänzt obiges. Die Token wandern entlang der verschiedenen Kontrollflusszweige durch “die Aktivität” bzw. durch das Aktivitätsdiagramm. Token haben Ausprägungen. So hat z.B. ein Objekt der Objektklasse Angestellte bestimmte Ausprägungen, genauso eine Ausprägung des Attributs Gehalt und auch der Token, der die Kontrollinformation enthält, ist immer an einer bestimmten Position. Alle Token sind verschieden, auch wenn sie dieselbe Ausprägung haben.

10.4 Basiskonzepte für die Verhaltensmodellierung

357

Dies zielt wohl auf die Tatsache, dass im objektorientierten Ansatz Objekte einer Objektklasse auch dann verschieden sind, wenn sie dieselben Attributsausprägungen haben. Es gibt unter anderem: x x x

Objekttoken (object token) Datentoken (data token) Kontrolltoken (control token).

Soweit eine erste Annäherung an den Token-Begriff der UML-Autoren. Wie man sehen kann, geht es auch hier – wie in der allgemeinen Definition - um elementare Informationseinheiten, wenngleich auch in drei sehr verschiedenen Varianten. Objekt- und Datentoken haben, wie in Kapitel 12 zu sehen sein wird, eine durchaus praktische Bedeutung im Kontrollfluss. Etwas abgehobener ist das Konzept der Kontrolltoken. Es kann allerdings, wenn man Kontrollflüsse modelliert, durchaus von Wert sein, ein Mittel zu haben, den konkreten Kontrollfluss zu beschreiben. V.a. wenn, wie hier, neben dem Kontrollfluss auch Daten und Objekte fließen. Dazu unten mehr. In den folgenden Abschnitten wird dieser Token-Begriff immer wieder thematisiert, da er eine der Grundlagen des Kontrollflusskonzeptes ist.

Elementare Informationseinheiten und Steuerinformation

10.4.2 Classifier In Kapitel 9 wurde auf den Begriff Classifier noch verzichtet, weil das dortige objektorientierte Instrumentarium ohne ihn erklärt werden kann. Hier ist dies aber nicht mehr möglich, weil er in den Ausführungen der UML-Autoren zur Verhaltensmodellierung eine zentrale Rolle spielt. Sie definieren einen Classifier als eine Sammlung von Instanzen, die sich ähnlich sind: “A collection of instances that have something in common. A classifier can have features that characterize its instances. Classifiers include interfaces, classes, datatypes, and components.” [OMG 2003a, S. 6]

Sammlung von (teilweise) gleich strukturierten „Dingen“

Schauen wir noch die Definition von Instanzen117 an: “An entity that has unique identity, a set of operations that can be applied to it, and state that stores the effects of the operations.” [OMG 2003a, S. 10] Damit gewinnt die Definition Konturen. Entity kann man getrost mit Informationsträger übersetzen (es existiert und hat Eigenschaften, hier typischerweise als Attribute festgehalten). Interfaces, Klassen, Datentypen und Komponenten sind Informationsträger und sie werden klassifiziert,

117

Dass eine Instanz ein Objekt einer Klasse ist, wurde ja im vorigen Kapitel schon festgestellt.

Klassifizierte Informationsträger

358

Metamodellierung

Generalisierungen

10 Objektorientierte Modellierung von Verhalten und Abläufen

nach bestimmten ihrer Eigenschaften. Das Ergebnis dieser Klassifikation sind die Classifier. Im Deutschen steht dafür eigentlich der Begriff Kategorie zur Verfügung. Hier soll trotzdem der englische Begriff benutzt werden (Klassifizierer würde doch recht seltsam klingen), auch um den Zusammenhang mit der objektorientierten Theorie gleich herzustellen. Classifier ist ein Begriff der Metamodellierung der UML, eine abstrakte Metaklasse. Vgl. zur Metamodellierung auch Abschnitt 13.11 („Metamodellierung der UML“), wo sie an einem konkreten Beispiel erläutert wird. Hier sei nur soviel angemerkt, dass Metamodellierung eine übergeordnete Theorie meint, mit der die eigentlich diskutierte Theorie fundiert und erläutert wird. Die UML-Autoren nehmen (explizit) als übergeordnete Theore nicht einschlägige philosophische Überlegungen, sondern die objektorientierte Theorie selbst. Somit erklären sie die objektorientierte Theorie mit den Mitteln der objektorientierten Theorie, womit sie auch ganz schön weit kommen. Möglich ist dies, weil die objektorientierte Theorie in weiten Teilen eine Theorie zur Strukturierung von Wissen ist. Die Metamodellierung der UML wird in den nächsten Abschnitten auch immer wieder thematisiert. Ziel ist es, sie zumindest ein Stück weit kennenzulernen, des besseren Verständnisses wegen aber auch weil dadurch erst die Originalquelle lesbar wird. Einige wenige Begriffe, die nicht aus der objektorientierten Theorie stammen, verwenden sie aber doch. Z.B. entity, wie gerade hier oben gesehen, sowie Konstrukt (construct) und Konzept (concept). Konstrukt für etwas umfangreichere Komponenten ihrer Theorie, Konzept für weniger umfangreiche. Dies wird auch in diesem Text so gehalten. Ein Classifier kann Generalisierungen besitzen, wodurch es möglich ist, Generalisierungsbeziehungen zu anderen Classifiern zu definieren. Es gibt also z.B. Spezialisierungen des abstrakten Classifier. Die wichtigsten sind Klasse, Aktivität, Anwendungsfall, Sequenz, Zustandsautomat.

In Kapitel 11 (Aktionen) verwendete Begriffe aus der UML (in der Reihenfolge des Auftretens): Deutsch

Englisch

Aktion Aktivität Aktivitätskante Kontrollkante

action activity activity edge control edge action execution input pin output pin object token primitive actions invocation actions read actions write actions object actions structural feature actions variable actions computation actions subordinate units subordinate behavior

Input-Pin Output-Pin Objekttoken Aufrufende Aktionen Lesende Aktionen Schreibende Aktionen Objekt-Aktionen Struktur-Aktionen Variablen-Aktionen Rechen-Aktionen

11 Aktionen

Die wichtigsten neuen Konzepte in der UML 2.0 zur Modellierung von Verhalten sind Aktionen und Aktivitäten. Aktionen sind sozusagen die elementaren Einheiten, die im jeweiligen System am niedrigsten aggregierten Tätigkeitsfolgen (Verhaltensabläufe). Aktivitäten dagegen enthalten Aktionen und stellen damit umfassendere Folgen von Tätigkeiten bzw. Verhaltensabläufen dar. In der Prozessanalyse sind die dynamischen Aspekte des Anwendungsbereichs mit den Begriffen Tätigkeit, Tätigkeitsfolge und Geschäftsprozess verknüpft. Die objektorientierte Wahrnehmung dieser Dynamik ist eine andere. Hier steht der Begriff Verhalten (behavior) im Vordergrund. Verhalten braucht einen Träger. Dieser ist in der objektorientierten Theorie das Objekt bzw. die Objektklasse. Vgl. dazu die Ausführungen in Kapitel 10. Es ist gut, diese beiden Konzepte Aktionen und Aktivitäten jetzt in der Version 2.0 vorzufinden, fehlten doch der UML bis dahin fundierte Instrumente zur Verhaltensmodellierung.

Neu in UML 2.0: Aktionen und Aktivitäten

Tätigkeiten vs. Verhalten

11.1 Definition Die UML-Autoren definieren eine Aktion als eine elementare Verhaltenseinheit (“the fundamental unit of behavior specification”) und fahren fort: “An action takes a set of inputs and converts them into a set of outputs, though either or both sets may be empty.” [OMG 2003a, S. 203] Dies klingt sehr datentechnisch, ja fast nach Programmmodulen, kann aber mit ein wenig Abstraktion auch auf Handeln/Tätigkeiten in Geschäftsprozessen übertragen werden. Die Beschreibung als „fundamental unit“ macht auch deutlich, dass die UML-Autoren Aktionen als Elementareinheiten sehen, wobei dies bei Programmmodulen leicht (z.B. als der Programmcode der kleinsten Module), ansonsten aber nur schwer absolut definiert werden kann. Bezogen auf die Aktivitäten (activities), in denen die Aktionen ja eingebettet sind, definieren die UML-Autoren eine Aktion als etwas, das ausführbar ist (es wird angestoßen) und das ein einzelnes Element der ausführbaren Gesamtfunktionalität einer Aktivität darstellt: “An action is an executable activity node that is the fundamental unit of executable functionality in an activity, as op-

Elementare Verhaltenseinheit

362

11 Aktionen

posed to control and data flow among actions.” [OMG 2003a, S. 280]

Aktionen als ausführbare Knoten

Aktionen verändern

Der zweite Teil des Zitats deutet schon an, dass die Aktionen auch in einen Kontroll- und Datenfluss eingebettet sind. Dazu unten mehr. Aktionen stellen also im Rahmen der Aktivitäten (vgl. den nächsten Abschnitt) „ausführbare“ Knoten dar, die mit einem Kontroll- und Datenfluss zwischen den Aktionen zusammenwirken. Ergänzend fahren die UML-Autoren dann fort, dass die Ausführung einer Aktion Veränderungen im modellierten System bewirkt: „The execution of an action represents some transformation or processing in the modeled system, be it a computer system or otherwise.” [ebenda] Damit sind die wichtigsten Merkmale von elementaren Verhaltens- oder Handlungseinheiten zusammengestellt. Die Formulierungen der UML-Autoren sind sehr von der Sichtweise der objektorientierten Systemanalyse geprägt, können aber auch auf Anwendungsbereiche außerhalb der engeren Systemanalyse angewendet werden. So hat z.B. eine Kalkulation (als Tätigkeit in einem Geschäftsprozess) einen Input und einen Output, könnte als ausführbares Element des Geschäftsprozesses aufgefasst werden und ist eingebettet in einen Kontroll- und Datenfluss in einem größeren Ganzen, dem Geschäftsprozess. Außerdem stellt sie, das wollen wir nicht vergessen (oben bei den Zitaten der UML-Autoren ist es unausgesprochen dabei) auch „Verarbeitung“ dar. Schließlich muss der Input auf kompetente Weise zu einem Output (z.B. dem Preis für ein neues Produkt) finden.

11.2 Grafische Darstellung Aktionen werden als Rechtecke mit abgerundeten Ecken dargestellt. Der Name der Aktion wird in das Rechteck eingefügt.

Abbildung 11.2-1:

Grafische Darstellung von Aktionen

Die UML-Urheber sehen vor, dass eine Aktion auch in einer formalen Sprache, z.B. einer Programmiersprache, ausgedrückt werden kann. Die folgende Abbildung zeigt ein Beispiel.

11.3 Aktionen im Kontrollfluss

Abbildung 11.2-2:

363

Grafische Darstellung von Aktionen mit einer Beschreibung in einer formalen Sprache Quelle: [OMG 2003a, S. 283]

Ebenfalls ist es möglich, bei Aktionen Vor- und Nachbedingungen für deren Ausführung zu hinterlegen. Diese lokalen Vor- und Nachbedingungen können als Anmerkungen an das grafische Symbol angehängt werden, so wie es die folgende Abbildung zeigt. Die in der Abbildung ebenfalls angegebenen Pfeillinien an der Aktion verweisen schon auf die Einbettung jeder Aktion in den übergeordneten Kontrollfluss ihrer Aktivität ( vgl. den nächsten Abschnitt).

Abbildung 11.2-3:

Eine Aktion mit lokalen Vor- und Nachbedingungen Quelle: [OMG 2003a, S. 283] Übersetzung durch den Verfasser

11.3 Aktionen im Kontrollfluss Aktionen sind also in Aktivitäten enthalten. In diesen stehen sie im Zusammenhang, werden z.B. in eine Reihenfolge gebracht. Dass hinter diesem „sequencing of actions”, wie die UML-Autoren schreiben, (natürlich) mehr als nur eine Anordnung in lineare Abfolgen steht, wird deutlich, wenn sie von Aktionen als Knoten und von „control edges“ und „object flow edges“ sprechen, also von Kanten, die den Kontrollfluss und den Fluss von Objekten modellieren. Dahinter steckt ein umfassendes Kontrollflusskonzept, das im nächsten Abschnitt vertieft vorgestellt wird. Hier wird dies nur kurz betrachtet, um Eigenschaften von Aktionen ableiten zu können.

Sequentielle Anordnung von Aktionen

364

Kanten hin, Kanten weg

11 Aktionen

Auf welche Art sind also Aktionen in Aktivitäten eingebettet? Am wichtigsten sind hierbei die Aktivitätskanten (activity edges). Eine Aktion wird durch eine solche zu ihr führende Kante aktiviert. Sie startet dann, wenn u.a. alle ankommenden Kanten mit Kontrollinformationen, die Kontroll-Kanten (control edges), aktiv wurden. Und sie hat von ihr wegführende Kanten, die z.B. andere Aktionen anstoßen. Dazwischen leistet die Aktion ihren eigenen Beitrag zur Leistungserbringung. Die UML-Autoren sprechen dabei von action execution und definieren: “An action execution represents the run-time behavior of executing an action within a specific activity execution.” [OMG 2003a, S. 280]

Laufzeitverhalten

In diesem Kontrollflusskonzept sind Aktionen also aktive Elemente, die angestoßen werden, etwas „tun“ und etwas weitergeben. Mit der Wortwahl run-time behavior sind die UML-Autoren thematisch bei der Softwareentwicklung und bei der Systemanalyse. Dies ist bei vielen Textstellen so, der Anspruch auf die anderen Bereiche (siehe oben) wird zwar erhoben, wird aber im Text nicht immer bedacht.

11.4 Pins an Aktionen Um den Input und den Output für Aktionen zu modellieren, wird in der UML das Konzept der Pins verwendet. Es sind so etwas wie Schaltstellen für die Aufnahme oder die Abgabe von Werten. Ein Pin repräsentiert jeweils entweder einen Input für eine Aktion (Input-Pin) oder einen Output (Output-Pin). Durch den Pin fließen Objekte oder Daten. Grafische Darstellung Die Pins werden in der grafischen Darstellung als kleine Rechtecke dargestellt, die mit den Recktecken der Aktion verbunden sind, wie es die folgende Abbildung zeigt. Die Bezeichnung des Pin wird neben das Rechteck gesetzt. Zumindest in der Praxis der grafischen Darstellung legen die UMLAutoren den Kontrollfluss meist von links nach rechts. Deshalb ist das Pinsymbol für den Input auf der linken Seite der Aktion angeordnet.

Abbildung 11.4-1:

Grafische Darstellung eines Input-Pin

Entsprechend ist das Pinsymbol für den Output auf der rechten Seite angefügt.

11.5 Start einer Aktion

Abbildung 11.4-2:

365

Grafische Darstellung eines Output-Pin

Soweit ein erstes Kennenlernen der Pins. Eine vertiefte Darstellung folgt im folgenden Kapitel, wenn die dafür notwendigen Voraussetzungen vorgestellt sind.

11.5 Start einer Aktion Wann kann eine Aktion starten? Eine Bedingung für den Start einer Aktion ist, dass alle Input-Pins Objekttoken haben. Die Aktion startet dann, indem sie Token von den zuführenden Kontroll-Kanten und den InputPins nimmt. Wenn die Durchführung beendet ist, bietet die Aktion den wegführenden Kontrollkanten und Output-Pins Token an, wo sie für andere Aktionen verfügbar sind bzw. andere Aktionen anstoßen [OMG 2003a, S. 280f].

11.6 Primitive Actions Mit primitive actions oder auch action primitives bezeichnen die UMLAutoren die kleinsten Einheiten der Verhaltensmodellierung. Sie werden so elementar gefasst, dass sie entweder eine Berechnung oder einen Speicherzugriff beschreiben, niemals beides auf einmal [OMG 2003a, S. 203]. Damit ist eine eindeutige Abbildung auf ein physikalisches Modell möglich. Folgende Untertypen werden u.a. unterschieden [OMG 2003a, S. 204f]: x x x x x x x

Aufrufende Aktionen (invocation actions), die Operationen aufrufen und Signale senden. Lesende Aktionen (read actions), die Ausprägungen erhalten und die in der Lage sind, diese zu erkennen. Schreibende Aktionen (write actions), die Ausprägungen verändern und Objekte erzeugen und zerstören können. Objekt-Aktionen (object actions), die Objekte erzeugen und zerstören. Struktur-Aktionen (structural feature actions), die das Lesen und Schreiben von Strukturmerkmalen unterstützen. Variablen-Aktionen (variable actions), die das Lesen und Schreiben von Variablen unterstützen. Rechen-Aktionen (computation actions), die durch Aufruf einer Funktion eine Menge von Eingabewerten in eine Menge von Ausgabewerten tranformieren.

366

11 Aktionen

11.7 Aktionen und Variable Indirekte Weitergabe von Daten

Variablen sind uns ja bekannt aus der Mathematik und der Informatik. Hier im Zusammenhang mit Aktionen sind sie Elemente, um Daten zwischen Aktionen “indirekt” weiterzugeben. Eine lokale Variable speichert Werte, die von mehreren Aktionen einer zusammenwirkenden Gruppe benötigt werden. Nach außen stehen sie nicht zur Verfügung. Die Ausgabe einer Aktion kann in eine Variable geschrieben werden und als Eingabe einer nachfolgenden Aktion dienen. Dies meinen die UML-Autoren, wenn sie von einem indirekten Datenflussweg sprechen. (für weitergehendes vgl. [OMG 2003a, Abschnitt 12.3.40 (S. 363ff)]).

11.8 Subordinate Units – zusammengefasste Aktionen

Untereinheiten

Aggregationsniveaus

Aktionen sind die Grundelemente von Aktivitäten. Neben diesen definieren die UML-Autoren noch zusätzliche Untereinheiten, die subordinate units. Dies sind Gruppen zusammengefasster Aktionen, die ebenfalls Elemente einer Aktivität sein können. Jede dieser subordinate units besteht wiederum aus einzelnen Aktionen, den primitive actions118. Mit diesem Konzept ist es möglich, wie in allen Ansätzen der Unternehmensmodellierung, die Modellbildung auf verschiedenen Aggregationsniveaus vorzunehmen. Insgesamt liegen damit in der UML bezüglich der Abläufe folgende Aggregationsniveaus vor: x x x

subordinate behavior

Aktionen Subordinate Units Aktivitäten

Das durch die subordinate unit abgedeckte Verhalten nennen die UMLAutoren dann subordinate behavior. Diese einzelnen Verhaltenskomponenten können gleich wie Aktionen in das Geschehen eingebunden werden. Gestartet werden sie z.B. dadurch dass ... x x x

118

andere Verhaltenskomponenten ihre Tätigkeit beenden Objekte und / oder Daten verfügbar werden. externe Ereignisse eintreten.

Die Darstellung ist hierzu in [OMG 2003a] nicht einheitlich. An vielen Stellen wird diese mittlere Ebene der subordinate units nicht genannt, sondern die Aktivitäten einfach als aus Aktionen bestehend definiert. An vielen anderen wird aber diese mittlere Ebene bewusst erwähnt, z.B. auf Seite 4 bei einer Kurzdefinition von activity: „A specification of parameterized behavior that is expressed as a flow of execution via a sequencing of subordinate units (whose primitive elements are individual actions).”

11.9 Hinweise zur Metamodellierung

367

11.9 Hinweise zur Metamodellierung Action ist eine abstrakte Klasse. Es gibt also keine Instanzen dieser Klasse, sondern nur Instanzen von Subklassen. Hier bedeutet dies: Es gibt keine Instanz Aktion, sondern nur Instanzen der spezifischen oben eingeführten Aktionen.

11.10 Zusammenfassung Die wichtigsten Eigenschaften von Aktionen sind wie folgt: x x x x

Sie repräsentieren Verhalten und daraus Grundeinheiten. Sie stellen im Gesamtzusammenhang (in einer Aktivität) eine ausführbare Einheit dar, einen sog. Aktivitätsknoten (vgl. den nächsten Abschnitt). Aktionen haben Input-pins und Output-Pins, die dem Transport von Objekten und Daten dienen. Sie bewirken Veränderungen im modellierten System / Anwendungsbereich.

Die Brücke schlagend zu den Aktivitäten kann hier auch noch festgehalten werden: x x x x

Zu Aktionen führen Kontrollkanten hin und welche weg. Diese betten sie in den Kontrollfluss ein. Sie nehmen Input an und stellen Output zur Verfügung. Sie verwandeln Input in Output. Der Input der einen Aktion kann der Output einer anderen sein. Aktionen können also verkettet sein, hintereinander abfolgen.

11.11 Aggregation - in Geschäftsprozessen und Systemen Das Konzept der Aktionen ist von zentraler Bedeutung, wenn es um die Modellierung von Verhalten bzw. von Geschäftsprozessen geht. Ihre Festlegung ist entscheidend für die Qualität des anschließend erstellten Modells. Dabei ist die Situation bei Geschäftsprozessen und bei Systemen durchaus unterschiedlich. Nehmen wir einen typischen Geschäftsprozess und stellen wir uns seine Ereignisgesteuerte Prozesskette vor. Der Geschäftsprozess besteht aus einer Folge von Tätigkeiten, z.B. zu einer Angebotserstellung, und kann im ersten Schritt in Funktionen für die Ereignisgesteuerte Prozesskette unterteilt werden. Diese Funktionen sind aber in sich strukturiert, können viele unterscheidbare Tätigkeiten enthalten. Zum Beispiel wäre ein Funktion Kalku-

Bei Geschäftsprozessen

368

Bei Systemen

11 Aktionen

lation durchführen ohne Schwierigkeit unterteilbar. Zu ihr könnte eine Tätigkeit Erhebung aktueller Kalkulationspreise gehören. Aber auch diese wäre weiter unterteilbar, z.B. in Anfrage bei Vorkalkulation, Erbitten neuer Werte, Abspeichern der erhaltenen Werte. Selbst da geht’s noch weiter, allerdings landen wir dann bald auf der „tayloristischen Ebene“, also z.B. Hörer abnehmen, Telefonnummer wählen, Frage formulieren, usw. Das macht außerhalb tayloristischer Betrachtungen natürlich keinen Sinn. Man wird also Elementareinheiten „über“ dieser Ebene anordnen. Etwas einfacher ist dies bei Systemen. Nehmen wir wieder den Geldautomaten. Zwar gibt es auch hier die Gesamtaufgabe, die unterteilt werden kann, z.B. in Karte entgegennehmen, Karte prüfen, gegebenenfalls Geld auszahlen, usw. Auch diese Tätigkeiten können wiederum unterteilt werden, z.B. die Entgegennahme der Karte in Karte mechanisch einziehen, Karte unter Leseeinheit platzieren, Karteninhalt lesen, usw. Und da ist auch noch kein Ende. Irgendwann wird aber die Ebene einzelner Programmschritte (bei digitalisierten Vorgängen) bzw. einzelner mechanischer Vorgänge (bei Maschinen) erreicht sein. Das ist dann eine elementare Ebene, die zu modellieren sich lohnt, weil man mit Vorgängen auf dieser Ebene Systeme sehr gut beschreiben kann. Dies ist auch die Ebene, auf deren Ebene die UML-Autoren Aktionen definieren. Trotzdem kann grundsätzlich das Konzept der Aktionen auch in der Prozessmodellierung eingesetzt werden, wobei die Elemente (Pins usw.), die sehr stark in Richtung Programmierung zeigen, bei der Prozessmodellierung nicht oder nur in abstrakter Form eingesetzt werden könnten.

In Kapitel 12 (Aktivitäten) verwendete Begriffe aus der UML (in der Reihenfolge des Auftretens) – Teil 1: Deutsch

Englisch

Aktivität Aktion Token Tokenfluss Aktivitätskante Aktivitätsknoten Fluss, Kontrollfluss Kontrollflusskante Objektflusskante Aktionsknoten Objektknoten Kontrollknoten

activity action token Token flow activity edge activity node flow control flow edge object flow edges action node object node control node DecisionNode MergeNode ForkNode JoinNode selection behavior ActivityFinal FlowFinal InitialNode Flow of objects DataStore edge weight attribute guard activity edge connectors control edges control token object flows bzw. object flow edges invocation action

Auswahlverhalten

Objektfluss Kante Gewichtung Wächter Aktivitätskante Verknüpfer, Konnektoren Kontrollkante Kontrolltoken Objektflusskanten aufrufende Aktion

370

11 Aktionen

In Kapitel 12 (Aktivitäten) verwendete Begriffe aus der UML (in der Reihenfolge des Auftretens) – Teil 2: Verhaltenseigenschaft Output-Pin Input-Pin Objektknoten-Pin Ausnahmeanmerkung Strukturierter Aktivitätsknoten Startknoten Schlussknoten AF Schlussknoten FF

behavioral feature Output pin Input pin object node pin streaming continuous behaviour exception notation structured activity node activity group decision input behavior Initial node activity final flow final call behavior event call event call invocation event change event invocation event receiving event send invocation event signal event start event termination event time event trigger event AcceptEventAction

12 Aktivitäten

12.1 Einleitung Für die UML-Autoren sind die in diesem Abschnitt vorgestellten Aktivitäten auf Petrinetzen aufbauende Graphen (petri-net like graphs) [OMG 2003a, S. 370]. Im vorigen Abschnitt wurde es schon mehrfach angesprochen, Aktionen als elementare Verhaltenseinheiten sind eingebettet in einen größeren Zusammenhang, zu dem sie ihren Beitrag leisten: x x

Graphen

die Aktion Getränkeausgabe ist Teil des Gesamtsystems Getränkeautomat eine Aktion Kalkulationsdurchführung kann Teil eines Geschäftsprozesses Angebotserstellung sein

Den „größeren Zusammenhang“ bilden hier bei der UML die Aktivitäten (activities). Sie beschreiben zusammenhängende Tätigkeitsfolgen. Aufbauend auf dem oben vorgestellten Konzept der Aktionen stellen sie somit Folgen von Aktionen dar. Umgekehrt und im Nachtrag zum vorigen Abschnitt liefern Aktivitäten somit den „Lebensraum“ von Aktionen: „Actions are contained in activities, which provide their context.“ ([OMG 2003a, S. 203], Hervorhebung durch den Verfasser) Wesentlich für das Konzept der Aktivitäten sind wiederum die Token, die durch die Aktivität fließen und den sog. Tokenfluss ausmachen: “The semantics of activities is based on token flow.” [OMG 2003a, S. 286] Das ist der Grund, weshalb in diesem Abschnitt oft von Token und Tokenfluss die Rede sein wird. Vgl. die grundsätzlichen Anmerkungen zum Token-Konzept in Abschnitt 10.4.1.

12.2 Definition Mit Aktivitäten ist es möglich, Folgen von Tätigkeiten zu modellieren, seien es nun Tätigkeiten im Sinne von Geschäftsprozessen („Auftragsbwicklung“) oder im Sinne von Systemverhalten („Karte einziehen, Karte

Zusammenhängende Tätigkeitsfolgen

372

12 Aktivitäten

prüfen, usw.). Die UML-Autoren geben im Text und in den Beispielen zahlreiche Hinweise darauf, an welche Arten von Tätigkeitsfolgen sie denken [OMG 2003a, S. 284]: x x

x

Aktivitäten können prozedurale Programmstrukturen beschreiben. Dann sind sie Methoden, die zu bestimmten Operationen von Klassen gehören. Aktivitäten können Geschäftsprozesse beschreiben, im Rahmen der Geschäftsprozessanalyse und im Rahmen der Vorgangsbearbeitung119 (workflow). Dass die UML-Autoren hier tatsächlich an Geschäftsprozesse denken, wird deutlich, wenn sie darauf hinweisen, dass Ereignisse hier oft interne sein können, z.B. die Beendigung einer Aufgabe, aber auch externe, z.B. der Anruf eines Kunden. Aktivitäten können auch bei der Modellierung von Informationssystemen benutzt werden, um unterschiedliche „system level processes“ festzulegen.

Aktivitäten vs. Aktionen Der Zusammenhang zwischen Aktionen und Aktivitäten sollte oben klar geworden sein. Die UML-Autoren fassen ihn wie folgt zusammen [OMG 2003a, S. 283]: x x x x

Eine Aktion stellt einen einzelnen Schritt in einer Aktivität dar, der in dieser Aktivität nicht stärker unterteilt wird. Eine Aktivität repräsentiert Verhalten, das aus einzelnen Elementen besteht, die Aktionen sind. Eine Aktion ist einfach aus der Sicht der Aktivität, in der sie enthalten ist. Sie kann aber komplex in ihren Auswirkungen sein. Eine Aktivität modelliert Verhalten, das an vielen Stellen wiederverwendet werden kann.

Der Kontrollfluss Knoten und Kanten für Aktivitäten

Kontrollfluss

Die Elemente einer Aktivität, die Aktionen darstellen, werden Aktivitätsknoten genannt. Eine Aktivität besteht dann aus Aktivitätsknoten (activity nodes) und Aktivitätskanten (activity edges). Die Aktivitätskanten sind gerichtet und verbinden die Knoten120. Mit diesen Knoten und Kanten werden die verschiedenen Flussmodelle dargestellt. Mit dem Begriff Fluss (flow) ist im Zusammenhang mit Aktivitäten gemeint, dass die Ausführung eines Knotens zur Ausführung anderer Knoten führt. Dies ist das, was gängigerweise mit Kontrollfluss bezeichnet wird. Wie üblich, ist auch hier die Vorstellung die, dass die Kontrolle

119 Wörtlich: “Activities may be applied to organizational modeling for business process engineering and workflow.” [OMG 2003a, S. 284] 120 Die UML-Autoren sprechen an dieser Stelle von flow of execution.

12.3 Einführendes Beispiel

373

entlang der Knoten weitergegeben wird: Wenn eine Aktion fertig ist, geht die Kontrolle an die nächste weiter, und so fort. Die Aktivitätsknoten enthalten „Verhalten“ (behavior) unterschiedlichster Art, z.B. eine Berechnung, den Aufruf einer Operation oder die Bearbeitung von Objektinhalten. Sie können auch Kontrollflusselemente enthalten für die Verzweigung bzw. das Zusammenführen von Kontrollflusszweigen, sei es nun verursacht durch Gleichzeitigkeit von Aktionen, durch Entscheidungen oder durch Parallelverarbeitung. Die UML-Autoren verstehen die Modellierung von Aktivitäten als einen Vorgang, bei dem „low-level behaviors“ in eine Reihenfolge gebracht und in Beziehung gesetzt werden. Das was dabei entsteht sind Kontrollfluss- und Objektflussmodelle.

Aktivitätsknoten etwas genauer

12.3 Einführendes Beispiel Zu Beginn ein einführendes und (hoffentlich) motivierendes Beispiel, das fast alle Elemente von Aktivitäten enthält. Es soll nur einen ersten Eindruck von Aktivitäten als Konstrukt der UML geben. Elemente und Syntax werden danach ausführlich erläutert. In der folgenden Abbildung sind einigen Elementen Kreise mit Nummern zugeordnet. Diese gehören nicht zur UML, sondern dienen der Verbindung von erläuterndem Text und Grafik. Betrachten wir die Abbildung. Wie zu erwarten war, besteht eine Aktivität aus einer Menge von Aktionen. Eine ist markiert: (3). Wie im vorigen Abschnitt schon ausgeführt, stehen die Aktionen in einem Zusammenhang, dargestellt durch die Aktivitätskanten (gerichtete Pfeile). Der einfachste solche Zusammenhang ist das „Aufeinanderfolgen“, dann führt eine Kante einfach von der einen Aktion zur nächsten. Dieses „Aufeinanderfolgen“ kann, so deutet es die Stelle (9) an, auch durch Informationen „begleitet“ sein: Beim Voranschreiten der Tätigkeitsfolge von Rechnung senden zu Zahlung durchführen spielt die Rechnung eine Rolle. Die Aktivität insgesamt ist zusammenhängend und nach „außen“ abgrenzbar. Dies wird in der Abbildung durch die Grenzlinie ausgedrückt, hier markiert durch (11). Wie es sich für die Modellierung von Tätigkeitsfolgen gehört, gibt es einen Startpunkt (1), oder auch mehrere, und einen Schlusspunkt (2), oder auch mehrere. Die Strukturierung kennt, so deutet es das Beispiel an, Entscheidungsvorgänge (vgl. (4), (5), (6)), die zu alternativen „Zweigen“ führen. Es gibt auch „Verschmelzpunkte“, wo unterschiedliche “Zweige” zusammengeführt werden (vgl. (10)). Auch das von anderen Methoden bekannte gleichzeitige Anstoßen mehrerer Aktionen ist im Beispiel erkennbar, vgl. Position (7). Nach der Ausführung des Auftrags erfolgt zum einen die Lieferung, zum anderen wird die Rechnung versandt. Sozusagen die Umkehrung zeigt das grafi-

Aktivität = Menge von Aktionen

Informationen im Fluss

Verzweigungen und Verschmelzungen

374

12 Aktivitäten

sche Element (8). Nur wenn die Lieferung erfolgte und wenn die Zahlung akzeptiert ist, geht es weiter in Richtung Auftrag schließen. Die Abbildung zeigt auch, dass für eine Aktivität Vor- und Nachbedingungen gestellt werden können. Vgl. (12) und (13). In der oberen linken Ecke ist noch der Name der Aktivität angegeben.

Abbildung 12.3-1:

Aktivität Auftragsbearbeitung – einführendes Beispiel Quelle: [OMG 2003a, S. 290, Figure 203] Übersetzt durch den Verfasser

Soweit das einführende Beispiel. Es wird in diesem Kapitel noch öfters angesprochen und vertieft erläutert. Insgesamt zeigt es – auch bei oberflächlicher Betrachtung – durchaus einen Aufbau, der für die Modellierung von Tätigkeitsfolgen sinnvoll erscheint.

12.4 Überblick - Knoten und Kanten in Aktivitätsdiagrammen Knoten und Kanten

Es gibt drei Arten von Aktivitätsknoten (Knoten in Aktivitätsdiagrammen) und zwei Arten von Aktivitätskanten (Kanten in Aktivitätsdiagrammen): (1) Aktivitätsknoten (activity nodes): x x x

Aktionsknoten (Knoten, die Aktionen repräsentieren oder sog. subordinate units, Gruppen von Aktionen) Objektknoten (Knoten, die Objekte repräsentieren), auch mit Knoten zur Datenspeicherung (DataStore) Kontrollknoten (Knoten zur Steuerung des Kontrollflusses) Die Kontrollknoten sind noch unterteilt in

12.5 Aktivitätsknoten

375

x Knoten für Alternativen: DecisionNodes und MergeNodes Knoten für „Gleichzeitigkeit“: ForkNodes und JoinNodes Schlussknoten: ActivityFinal und FlowFinal a) Startknoten: InitialNode (2) Aktivitätskanten (activity edges): x x

Kontrollflusskanten (control flow edges) Objektflusskanten (object flow edges)

Damit kann dann der Kontrollfluss (control flow) innerhalb der Aktivitäten beschrieben werden. Diese und weitere ergänzende Elemente werden im folgenden vertiefend beschrieben.

12.5 Aktivitätsknoten 12.5.1 Aktionsknoten Die Knoten in einer Aktivität, die Aktionen repräsentieren, werden Aktionsknoten genannt. Sie repräsentieren Aktionen, wie sie im vorigen Kapitel eingeführt wurden. Im obigen einführenden Beispiel sind also Auftragseingang, Auftrag ausführen, Lieferung, Auftrag schließen, Rechnung senden, Zahlung durchführen und Zahlung akzeptieren Aktionsknoten. Für die Aktivitäten stellen die Aktionen die kleinsten Einheiten für das Systemverhalten dar. Auch wenn die Definition kleinster Einheiten schwierig ist, ist doch eines klar: Das gesamte Verhalten (im Sinne von Systemen) bzw. die gesamte Tätigkeitsfolge (im Sinne von Geschäftsprozessen) von Aktivitäten wird zerlegt in sinnvolle Untereinheiten, die Aktionen – so wie dies bei jeder Modellierung von Abläufen der Fall ist. Damit stellen Aktivitäten eine Sammlung von sinnvoll in einen Kontrollfluss gepackten Aktionen dar.

Aktionen in Knoten

12.5.2 Objektknoten Objektknoten repräsentieren Objekte im Sinne des objektorientierten Ansatzes. Mit ihrer Hilfe werden die in einer Aktivität vorkommenden Objekte erfasst. Die Aufgabe der Objektknoten ist es, den Objektfluss (flow of objects) in einer Aktivität zu modellieren. Ein Objektknoten hat einen Typ und kann damit Ausprägungen annehmen. Allerdings nur solche, die dem Typ des Objektknotens entsprechen. Folgende Typen werden unterschieden: x x x x

Objektknoten für Token mit Mengen Objektknoten für Token vom Typ Signal (Signal-Token) Objektknoten für Token mit Objekten in spezifischen Zuständen Objektknoten mit einer oberen Grenze

Objekte in Knoten

376

x

12 Aktivitäten

Objektknoten mit einer von FIFO abweichenden Sortierung

Grafische Darstellung von Objektknoten Die folgende Abbildung zeigt die grafische Darstellung von Objektknoten: als Rechteck bzw. Sechseck mit einer Bezeichnung, die auch den Typ des Objektknotens angibt. Die Bezeichnung kann auch durch die Angabe des Zustandes des Objekts genauer gefasst werden. Diese Zustände werden in eckigen Klammern unter die Bezeichnung geschrieben (vgl. das Stichwortverzeichnis für Hinweise auf Beispiele). Obergrenzen (upper bounds) und eine von FIFO (Voreinstellung) abweichende Sortierung werden in geschweiften Klammern unter dem Objektknoten angegeben.

Abbildung 12.5-1:

Darstellung von Objektknoten Quelle: [OMG 2003a, S. 303] Übersetzung durch den Verfasser

Auswahlverhalten Objekte auswählen

Es ist möglich, bei Objektknoten eine Auswahl festzulegen. Dies wird Auswahlverhalten (selection behavior) genannt. Es wird in einer Notiz (note symbol) angegeben, angeführt vom Schlüsselwort <<selection>> und an den Objektknoten angefügt, wie es die folgende Abildung zeigt.

12.5 Aktivitätsknoten

Abbildung 12.5-2:

377

Angabe einer Auswahl auf einem Objektknoten Quelle: [OMG 2003a, Figure 277, S. 303] Übersetzung durch den Verfasser

DataStore Ein besonderer Objektknoten ist der sog. DataStore. Wie es der Begriff schon nahelegt, ist es die Aufgabe des DataStore, eine Art Pufferknoten für nicht-flüchtige Informationen zu sein (“central buffer node”) [OMG 2003a, S. 318]. DataStores wurden eingeführt, um ältere Formen des Datenflusses zu modellieren. Unter „älteren Formen“ verstehen die UML-Autoren, dass Daten persistent sind und bei Bedarf genutzt werden. Unter neueren Formen, dass die Daten flüchtig (transient) sind und genutzt werden, wenn sie verfügbar sind [OMG 2003a, S. 319]. Der Tokenfluss Anmerkung: vgl. Abschnitt 10.4.1 für eine Einführung in den TokenBegriff Die Rolle der DataStore wird klar, wenn der Tokenfluss betrachtet wird. Ein DataStore behält alle Token, die zu ihm kommen und kopiert sie, wenn sie weiter im Kontrollfluss gehen müssen. Kommt ein Token an, der ein Objekt enthält und gibt es im DataStore bereits einen Token mit diesem Objekt, dann ersetzt der neue Token den alten. Token, für die es also im Fluss weitergeht, werden kopiert, so dass es so aussieht, als ob die Token niemals den DataStore verlassen. Grafische Darstellung Die Darstellung ist wie bei Objektknoten, enthält aber die zusätzliche Beschriftung <>.

Abbildung 12.5-3:

Objektknoten DataStore - Grafische Darstellung

378

12 Aktivitäten

Beispiel Die folgende Abbildung zeigt ein Beispiel. Zur Bedeutung des gerichteten Pfeils, der Kante, vgl. den nächsten Abschnitt.

Abbildung 12.5-4:

DataStore – ein Beispiel

Anmerkung zur Gliederung: Bevor die Betrachtung der Knoten mit den strukturierten Aktivitätsknoten und den Kontrollknoten fortgesetzt werden kann, müssen nun erst die Kanten eingeführt werden.

12.6 Aktivitätskanten 12.6.1 Kanten für den Kontrollfluss Die Kanten und ihre Darstellung

Wie oben ausgeführt und im einführenden Beispiel gezeigt, wird der Kontrollfluss durch Kanten (edges) zwischen den Aktivitätsknoten ausgedrückt. Eine solche Aktivitätskante (activity edge) wird durch eine Pfeillinie zwischen je zwei Aktivitätsknoten dargestellt. Hat die Kante eine Gewichtung, wird diese in geschweiften Klammern angegeben. Hat sie eine Beschriftung, wird diese ebenfalls bei der Kante vermerkt. Vergleiche die folgende Abbildung für eine einfache Kante, eine mit Gewichtung und eine mit Beschriftung.

Abbildung 12.6-1: Gewichtung

Aktivitätskanten – einfach, mit Gewichtung, mit Beschriftung

Über eine Aktivitätskante kann zu einem Zeitpunkt eine beliebige Anzahl von Token passieren. Die Gewichtung (weight attribute) schreibt die Mindestanzahl von Tokens vor, die zur selben Zeit über die Kante gehen müssen. Das ist eine Festlegung, die jedesmal überprüft bzw. berechnet wird, wenn ein neuer Token für die Quelle zur Verfügung steht. Das Ergebnis der Prüfung muss eine positive ganze Zahl oder Null sein. Wenn die Mindestzahl von Token vorhanden ist, werden alle Token der Quelle dem Ziel auf einmal angeboten.

12.6 Aktivitätskanten

379

Ein eventueller Wächter (Guard, vgl. Exkurs unten) muss für alle Token den Wert wahr ergeben. Klappt dies nicht und fällt dadurch die Zahl der dem Ziel angebotenen Token unter die Gewichtung, werden gar keine Token angeboten. Eine Gewichtung von Null (null weight) bedeutet, dass alle Token der Quelle dem Ziel angeboten werden.

Wächter

Beispiele Das folgende Beispiel spiegelt den Sachverhalt wider, dass beim Zusammenstellen einer Fußballmannschaft insgesamt 11 Spieler zu finden sind.

Abbildung 12.6-2:

Aktivitätskante mit Gewichtung durch absolute Zahl

Das zweite Beispiel enthält eine Gewichtung, die durch ein Attribut angegeben wird. Damit wird der Sachverhalt erfasst, dass erst alle Teilaufgaben erledigt sein müssen, bevor die Rechnung dafür versandt wird.

Abbildung 12.6-3:

Aktivitätskante mit Gewichtung durch ein Attribut

Exkurs: Wächter (guards) Hier und im weiteren wird ein Konzept benötigt, das die UML-Autoren guard bzw. guard condition nennen und das hier mit Wächter übersetzt wird. Dabei handelt es sich um Bedingungen, die geprüft werden, bevor ein bestimmter Schritt gegangen wird. Bei Entscheidungsknoten (vgl. unten) haben z.B. die wegführenden Kanten Wächter, die festlegen, mit welcher Kante die Token „weiterziehen“. Bei Transitionen (vgl. Kapitel 15) wird durch Wächter bestimmt, ob sie „feuern“ dürfen, usw. Es handelt sich dabei i.d.R. um einfache mathematische oder andere logische Ausdrücke wie z.B. „x<10“.

Wie oben schon gezeigt, können Aktivitätskanten auch beschriftet werden. Eine solche Bezeichnung beschreibt das Ergebnis der vorangehenden Aktion. Die UML-Autoren betonen, dass diese Bezeichnung innerhalb der Aktivität nicht eindeutig sein muss.

Beschriftung von Aktivitätskanten

380

12 Aktivitäten

Beispiel Zwei Aktionen, Paket packen und Paket versenden, sind durch eine beschriftete Kante verbunden. Die Bedeutung ist wie folgt: Wenn die Aktion Paket packen erledigt ist, wird die Aktion Paket versenden angestoßen und ausgeführt. Die Kantenbeschriftung drückt dann das Ergebnis der vorangegangenen Aktion aus.

Abbildung 12.6-4: Verknüpfer

Aktivitätskante mit Beschriftung

Bei der Darstellung eines Kontrollflusszweiges ist es auch möglich, Verknüpfer (Konnektoren / connectors) einzufügen. Dies geschieht durch einen Kreis, der eindeutig bezeichnet ist (im Rahmen des jeweiligen Modells) und der die Rolle der Zielaktion auf der einen Seite und die der Ausgangsaktion auf der anderen Seite übernimmt.

Abbildung 12.6-5:

Verknüpfer im Kontrollfluss Quelle: Angelehnt an [OMG 2003a, S. 296]

Dieses Element erlaubt z.B. die grafische Aufteilung großer Aktivitäten, ähnlich wie die Prozesswegweiser bei Ereignisgesteuerten Prozessketten. Der Tokenfluss Nur Kontrolltoken

Die in den obigen Beispielen vorhandenen Kontrollkanten (control edges) bilden nur den Kontrollfluss ab, nichts anderes. Über sie können nur Kontrolltoken (control token) passieren. Sollen Objekte oder Daten transportiert werden, bedarf es der Objektflusskanten, die im nächsten Abschnitt vorgestellt werden. 12.6.2 Kanten für den Objektfluss - Objektflusskanten

Zwei „Flüsse“ auf denselben Aktionen

Objektflusskanten (object flows bzw. object flow edges) sind ebenfalls Aktivitätskanten, aber solche, über die Objekte oder Daten passieren können. Sie modellieren also den Fluss von Daten und von Objekten in einer Aktivität. Es gibt somit in Aktivitäten zwei verschiedene „Flüsse“: die Kontrollflüsse und die Objektflüsse. Diese Trennung ist unabdingbar, die beiden Flüsse stellen unterschiedliche, wenn auch zusammenhängende, Aspekte dar. Der Zusammenhang ergibt sich daraus, dass beide Flüsse auf denselben in der Aktivität erfassten Aktionen ablaufen. Die Trennung zwischen Kontroll- und Datenflüssen ist strikt: Alle Kanten, die zu Objektknoten führen oder weggehen müssen Objektflusskanten sein.

12.6 Aktivitätskanten

381

Es gibt unterschiedliche grafische Darstellungsformen für Objektflüsse und Objektflusskanten. Hier die erste. Bei dieser werden die Kanten nicht direkt zwischen den beiden Aktionen (oder subordinate behaviors) angeordnet, sondern über einen Objektknoten geführt, der das zu transportierende Objekt repräsentiert. Die erste Kante führt von der ersten Aktion zum Objekt, die zweite vom Objekt zur zweiten Aktion. Beispiel Das Beispiel zeigt einen Objektknoten Auftrag im Objektfluss, der Objekte der Klasse Aufträge enthält. Die Aktion Auftrag ausführen erzeugt ausgeführte Aufträge, Auftrag versenden „verbraucht“ diese. Der Aufruf von Auftrag ausführen muss beendet sein, dann kann Auftrag versenden beginnen. Weiter unten wird gezeigt, wie diese Situation mit Pins und ihren Symbolen dargestellt wird.

Abbildung 12.6-6:

Objektflusskanten

Das folgende Modellfragment (Fragment aus dem einführenden Beispiel) zeigt deutlich die Absichten der UML-Autoren mit diesem Konzept. Die Aktion Rechnung senden bewirkt einen Transportvorgang des Objekts Rechnung (vom Unternehmen zum Kunden!), der die Aktion Zahlung durchführen anstößt.

Abbildung 12.6-7:

Objektfluss mit Rechnung Quelle: [OMG 2003a, S. 296] Übersetzung durch den Verfasser

12.6.3 Objektflüsse und Pins Oben (in Abschnitt 10.4) wurde schon das Konzept der Pins eingeführt. Jetzt kann es vertieft werden. Ein Pin repräsentiert einen Objektknoten, der den Input und den Output von Aktionen modelliert. Er hält also fest „was“ in die Aktion hineinfließt und „was“ aus ihr herauskommt121. Ist die Aktion ein Aufruf, die UML-Autoren sprechen dann von einer aufrufenden Aktion (invocation action) (vgl. oben), dann müssen die An121

Für dieses „was“ haben die UML-Autoren das Konzept der Token.

Notation 1

382

12 Aktivitäten

zahl von Pins und deren Typen gleich sein wie die Anzahl Parameter und die Typen des aufgerufenen Verhaltens oder der Verhaltenseigenschaft (behavioral feature). Die Pins werden nach ihrer Reihenfolge auf die Parameter abgebildet. Beispiele Das folgende Beispiel zeigt denselben Vorgang wie oben, jetzt aber mit ausdrücklich ausgewiesenen Objektknoten-Pins (object node pins) und ihren Symbolen. Die Pinsymbole repräsentieren beim linken Knoten das zur Verfügung gestellte und abgehende Objekt, auf der rechten Seite das geforderte und empfangene Objekt.

Abbildung 12.6-8:

Noch ein Transportvorgang

Objektknoten mit Pinsymbolen Quelle: [OMG 2003a, S. 359, Figure 286] Übersetzung durch den Verfasser

Die Pins werden grafisch durch Rechtecke angedeutet und mit dem Namen des Objekts beschriftet. Die folgende Abbildung zeigt, wie mehrere Objektflüsse zwischen zwei Aktionen bei dieser Notation dargestellt werden. Im Beispiel geht es um einen Auftrag bzgl. einer Maschine. Zuerst werden die Teile beschafft, dann wird die Maschine zusammengebaut. Der Objektfluss besteht zum einen in der Weitergabe des Auftrags, zum anderen in der Weitergabe der Teile. Auch dieses Beispiel macht deutlich, dass die UML-Autoren mit diesem Konzept tatsächlich reale Transportvorgänge von physischen und digitalen Objekten meinen.

Abbildung 12.6-9:

Objektflusskante mit zwei Objekten Quelle: [OMG 2003a, S. 347, Figure 272] Übersetzung durch den Verfasser

Das dritte Beispiel verdeutlicht die Verwendung von mehreren Pins. Folgendes wird mit Hilfe der Pins „transportiert“: x x x Zustand (state) von Objekten

Aufträge Teile PC Designs

Die Abbildung zeigt auch anschauliche Beispiele für den Zustand (state) von Objekten und deren Änderung. Das Objekt Auftrag ändert ihn vom Anfangszustand (beim Eingang des Auftrags) in Auftrag [akzeptiert] (vgl.

12.6 Aktivitätskanten

383

zur Definition und zur grafischen Darstellung Abschnitt 9.5.2.2) und am Schluss in Auftrag [zusammengebaut]. Bleibt noch der Zusatz {stream} bei dem Pin / Objektkknoten PCDesigns. Dieses streaming-Konzept wird gleich unten erläutert. Der Ablauf Das kleine Fragment aus einem größeren Geschäftsprozess zeigt, dass die Aktion Auftrag zusammenbauen insgesamt drei Objekte über ihre drei Input-Pins erhält: Auftrag, Teile, PC-Design. In der Aktion wird dann der Zusammenbau vorgenommen und der Output-Pin trägt das Objekt Auftrag [zusammengebaut]. Tokenfluss Token sind hier dann zum einen Kontrolltoken, die das „Weitergehen“ im Kontrollfluss modellieren, zum anderen die angeführten Objekttoken.

Abbildung 12.6-10:

Objektknoten mit Pinsymbolen Quelle: [OMG 2003a, S. 359, Figure 286] Übersetzt durch den Verfasser

Kurznotation Neben obiger grafischer Darstellung führen die UML-Autoren auch eine optionale Kurznotation ein. Diese greift, wenn der Output-Pin einer Aktion mit einem gleichnamigen Input-Pin einer anderen Aktion verbunden ist. Dann kann dies unter Verwendung nur eines Symbols wie in der folgenden Abbildung ausgedrückt werden. Der „standalone pin“, so wird er genannt, steht dann gleichzeitig für einen Output-Pin und ein Input-Pin.

Abbildung 12.6-11:

Objektflusskante ohne genaue Ausweisung des Objektflusses Quelle: [OMG 2003a, S. 357, Figure 281] Übersetzung durch den Verfasser

384

12 Aktivitäten

Auch die Darstellung mit nur einem Rechteck als Symbol für das Objekt wird von den UML-Autoren als standalone pin bezeichnet. Mit streaming Ununterbrochener Fluss mit streaming

Die UML bietet über die Pins auch eine Möglichkeit an, einen ununterbrochenen regelmäßig ablaufenden Fluss von Inputs und Outputs zu modellieren. Die Vorstellung ist die, dass hier nicht – im Rahmen einer größeren Aktivität – jeweils einmal in einem „Durchgang“ die erste Aktion ausgelöst wird, diese dann einmal Input annimmt und abgibt und dann die zweite anstößt, usw., sondern dass es regelmäßig weitergeht. Eine Aktion bleibt also bzgl. In- und Output ständig weiter aktiv. Die UML-Autoren nennen dies continuous behavior. Streaming erlaubt somit einer Aktion (im Rahmen ihrer action execution) Input anzunehmen und Output abzugeben während sie bereits aktiv ist. Somit kann die Aktion während einer Ausführung mehrere Token annehmen und abgeben. Und dies auch an mehreren Pins. In der grafischen Notation wird dies durch die textliche Anmerkung {stream} in der Nähe des Pin-Symbols ausgedrückt. Die Voreinstellung ist „nonstream“. Beispiele Oben im Beispiel der Abbildung 12.6-10 war ein solches Element bereits enthalten. Die Aktion Design erstellen erstellt nicht nur ein Objekt PC Design, sondern ständig neue und bietet sie auf seinem Output-Token an. Die Aktion Auftrag zusammenbauen nimmt sich dann die Objekte PC Designs wie sie sie benötigt. Im folgenden Beispiel ist Auftrag ausführen ein ständiger Vorgang, der in regelmäßigen Abständen Objekte des Typs Auftrag [ausgeführt] erzeugt. Der Auftragsversand ist ebenfalls ein ständiger Vorgang, der regelmäßig die ausgeführten Aufträge erhält und dann den Auftragsversand realisiert.

Abbildung 12.6-12:

Objektfluss durch Streaming Quelle: In Anlehnung an [OMG 2003a, S. 360, Figure 288], Übersetzung durch den Verfasser

Die entsprechende Darstellung mit den Pinsymbolen zeigt die folgende Abbildung.

12.6 Aktivitätskanten

Abbildung 12.6-13:

385

Objektfluss durch Streaming mit Pins Quelle: In Anlehnung an [OMG 2003a, S. 360, Figure 288], Übersetzung durch den Verfasser

Es gibt auch die Möglichkeit, streaming mit der Kante grafisch auszudrücken. Dabei wird dann entweder die Pfeilspitze der Kanten schwarz eingefärbt oder die Rechtecke der Pins (vgl. [OMG 2003a, S. 358f]). Ausnahmen modellieren mit der Ausnahmeanmerkung Es stört doch sehr, dass bei den Aktionen im Regelfall nur das positive Ergebnis einer Aktion modelliert wird. Das haben wohl auch die Autoren der UML gemerkt und haben deshalb das Konzept der Ausnahmeanmerkung (exception notation) eingeführt. Sie bedeutet, dass der Fortgang mit der jeweiligen Kante eine Ausnahme darstellt. In der grafischen Darstellung wird dies beim jeweiligen Pin durch ein Dreieck vermerkt. Die zwei folgenden Abbildungen zeigen ein Beispiel in zwei verschiedenen Notationen. Die Aktion Zahlungsannahme hat die zwei Pins akzeptierte Zahlung und zurückgewiesene Zahlung. Zahlungsannahme führt normalerweise zu einer Zahlung, die akzeptiert wird und dem Konto gutgeschrieben wird. In Ausnahmefällen ist es jedoch möglich, dass die Zahlung zurückgewiesen wird, z.B. weil sie nicht korrekt ist. Dies wird dann durch das Dreieck an der jeweiligen Kante beim Pin vermerkt.

Abbildung 12.6-14:

Kennzeichnung von Ausnahmen Quelle: [OMG 2003a, S. 361, Figure 289] Übersetzung durch den Verfasser

Die folgende Darstellung ist diejenige, die die Objektknoten im Objektfluss angibt. Auch hier wird die „Ausnahmekante“ durch ein Dreieck markiert.

Abbildung 12.6-15:

Kennzeichnung von Ausnahmen Quelle: [OMG 2003a, S. 361, Figure 289] Übersetzung durch den Verfasser

Nur das positive Ergebnis

Ausnahme zurückgewiesene Zahlung

386

Exlusives Oder

12 Aktivitäten

Hier liegt somit eine Verknüpfung mit einem exklusiven Oder vor mit der zusätzlichen Information für den Leser des Modells, dass der eine Fall nur in Ausnahmefällen eintritt. Ohne Kanten Stehen inhaltlich und damit auch für die grafische Darstellung keine Kanten zur Verfügung, ist die in der folgenden Abbildung gezeigte Ersatzdarstellung möglich. Dabei werden Pfeile in das Rechteck des Pin gezeichnet. Weist der Pfeil zu der Aktion, handelt es sich um einen Input-Pin, weist der Pfeil weg von der Aktion um einen Output-Pin.

Abbildung 12.6-16:

Pins ohne Kanten – Input-Pin und Output-Pin Quelle: [OMG 2003a, S. 358, Figure 284]

Mit Klassendiagramm In der Abbildung unten wird der Objektknoten Auftrag durch einen Ausschnitt aus einem Klassendiagramm näher erläutert. Das Klassendiagramm zeigt, dass zu einer Auftragsausführung in Wirklichkieit drei Dinge gehören: x x x

ein Auftrag Auftragspositionen und die Anforderungen des Kunden an den Versand, hier kurz Abwicklung genannt.

Das eigentliche Token, das hier „fließt“, ist das Auftrags-Token zwischen Auftragsannahme und Auftragsdurchführung, das aber natürlich mit anderen Objekten verbunden sein kann. Dies wird durch die Verknüpfung mit einem Klassendiagramm deutlich.

Abbildung 12.6-17:

Verknüpfung eines Klassendiagramms mit einem Objektknoten Quelle: [OMG 2003a, S. 360, Figure 287]. Übersetzung durch den Verfasser

12.6 Aktivitätskanten

387

Mit Auswahl (Auswahlverhalten) Eine Auswahl mittels Auswahlverhalten kann nicht nur auf die Kanten gelegt werden, sondern auch auf die Pins. Dies geschieht wiederum mit dem Schlüsselwort <<selection>> in einem Anmerkungssymbol und durch Verknüpfen mit einer gestrichelten Linie.

Abbildung 12.6-18:

Objektfluss mit Auswahl (selection behavior) Quelle: [OMG 2003a, S. 346, Figure 268] Übersetzung durch den Verfasser

Beispiele Die ersten beiden Abbildungen zeigen eine Auswahl, die bei den Objektknoten vermerkt ist. Es sind zwei Darstellungen einer Situation, in der verlangt ist, dass die Aufträge nach ihrer Priorität ausgeführt und die mit derselben Priorität nach dem FIFO-Prinzip (first-in/first-out) behandelt werden.

Abbildung 12.6-19:

Objektfluss mit Auswahl – Darstellung 1 Quelle: [OMG 2003a, S. 362, Figure 290]. Übersetzung durch den Verfasser

388

12 Aktivitäten

Abbildung 12.6-20:

Objektfluss mit Auswahl – Darstellung 2 Quelle: [OMG 2003a, S. 362, Figure 290]. Übersetzung durch den Verfasser

Die folgenden Beispiele zeigen die Festlegung der Auswahl über den Objektfluss. Das erste stimmt inhaltlich mit den obigen überein.

Abbildung 12.6-21:

Objektfluss mit Auswahl an Kante Quelle: [OMG 2003a, S. 348, Figure 273] Übersetzung durch den Verfasser

Im folgenden Beispiel erfasst die linke Aktion das Beendigen der Arbeit an einem Auftrag. Daraus entstehen Objekte des Typs abgeschlossener Auftrag. Durch die Notwendigkeit, dem Kunden eine Notiz zu senden (ausgedrückt durch die entsprechende Aktion), wird ein Objekt Kunde benötigt. Die Auswahl legt nun fest, dass eine Abfrage mit Hilfe des jeweiligen Auftrags das Kundenobjekt bestimmt.

Abbildung 12.6-22:

Objektfluss mit Auswahl an Kante Quelle: [OMG 2003a, S. 348, Figure 273] Übersetzung durch den Verfasser

Das dritte Beispiel zeigt eine Spezifizierung von Objekten. Es wird ausgedrückt, dass die Aktion Auftrag erteilen Objekte des Typs Auftrag er-

12.6 Aktivitätskanten

389

zeugt und dass die Aktion Auftrag ausführen diese liest und dann ausführt.

Abbildung 12.6-23:

Objektfluss mit Auswahlverhalten Quelle: [OMG 2003a, S. 348, Figure 273] Übersetzung durch den Verfasser

12.6.4 Abgrenzung zwischen den Kantenarten Die UML-Autoren betonen die Abgrenzung von Kontroll- und Objektfluss sehr stark, ja sie haben sogar den Objektfluss als Ausgangspunkt, wenn sie ausführen, das das Konzept des Kontrollflusses eingeführt wurde, um die Abfolge von Verhalten in den Fällen modellieren zu können, wo keine Objekte fließen [OMG 2003a, S. 316]. Zusammengefasst gilt, dass Objekte und Daten nicht über eine Kontrollflusskante gelangen können (S. 315), d.h., Kontrollflüsse dürfen keinen Objektknoten an einem ihrer Enden haben. Dies greift auch bzgl. der im nächsten Abschnitt vorgestellten Kontrollknoten (Operatoren). Die Kanten, die zu einem Kontrollknoten hin- oder wegführen, sind entweder alle Objektflüsse (object flows) oder alle Kontrollflüsse (control flows). Eine Vermischung ist nicht zulässig [OMG 2003a, Seite 317]. Obiges gibt einen guten Einblick in die Philosophie der UML-Autoren. Hier war – entsprechend der Kernaufgabe Systemanalyse und Systemdesign – und entsprechend der dafür notwendigen elementaren Beschreibungsebene tatsächlich der Objektfluss “zuerst da” und sozusagen im Zentrum der Betrachtung. Der Kontrollfluss kam dann später dazu.

Am Anfang war der Objektfluss

Am Anfang: Objektflüsse

Vergleich UML / EPK Bei der Methode EPK kennen wir in der direkten Modellierung durch Kanten nur den Kontrollfluss. Der Datenfluss wird – mehr oder weniger ausführlich – nur durch Zuordnung der Informationsobjekte zu den Funktionen modelliert. Eigentliche Transportvorgänge werden bei den Urhebern der Methode EPK kaum thematisiert. In diesem Buch allerdings schon, auch mit Empfehlung einer eigenen Notation. Es gibt also bei den Ereignisgesteuerten Prozessketten keine direkte Entsprechung zu diesem Konzept der Objektflüsse, nur die Möglichkeit, die Flexibilität des Funktionskonzepts zu nutzen und den Transport als Funktion zu modellieren.

Datenflüsse bei EPKs vs Objektflüsse in der UML

390

12 Aktivitäten

12.7 Strukturierte Aktivitätsknoten Knoten mit Inhalt

Sie tragen zwar die Bezeichnung Knoten, sind aber tatsächlich auch Aktivitäten, allerdings solche, die in anderen, größeren enthalten sind und dort ähnlich wie ein Knoten wahrgenommen werden. Diese sog. strukturierten Aktivitätsknoten (als Klasse: StructuredActicityNode) stellen eine Gruppierung von zusammengehörigen und zusammenwirkenden Aktionen dar. Es sind, aus der Sicht „ihrer“ Aktivität, ausführbare Knoten, die in sich untergeordnete Knoten als ActivityGroup enthalten.

ActivityGroup Mit ActivityGroup ist eine abstrakte Klasse gemeint, mit der Mengen von Knoten und Kanten in einer Aktivität definiert werden können.

Wofür? Überblick

Bewältigung Parallelverarbeitung

Es kann Kontrollkanten (control edges) und Pins geben, die mit ihm, dem strukturierten Aktivitätsknoten, verbunden sind. Die Ausführung jeder in ihn eingebetteten Aktion kann erst beginnen, wenn der strukturierte Aktivitätsknoten seine Objekt- und Kontrolltoken erhalten hat. Die OutputToken des strukturierten Aktivitätsknotens stehen erst zur Verfügung, wenn alle eingebetteten Aktionen fertig sind. Wofür wird ein solches Konzept benötigt? Für ein allgemeines grundsätzliches Problem jeder Modellierung von Tätigkeitsfolgen, der Bewältigung unterschiedlicher Detaillierungsgrade. Durch die strukturierten Aktivitätsknoten kann, rekursiv auch in mehreren Ebenen, in einem Aktivitätsknoten eine kleinere Aktivität definiert werden, in einem Knoten dieser wieder eine, usw. Somit können verschachtelte Strukturen entstehen. Dies kann z.B. dazu benutzt werden, auf der obersten Ebene eher globale Knoten anzulegen, die dann in einem oder in mehreren Schritten verfeinert werden. Eine weitere eher auf die technische Realisierung von Software zielende Begründung führen die UML-Autoren an. Dabei geht es um Probleme mit der Parallelverarbeitung. Bei der Ausführung von Aktionen in Aktivitäten und darüber hinaus können sich Fragen bzgl. der Parallelverarbeitung stellen. Z.B. kann es schwierig sein, Zugriff und Änderung des Objektspeichers fehlerfrei zu gestalten. Um dies zu realisieren, kann es sinnvoll sein, die Effekte einer Gruppe von Aktionen von den Effekten anderer Aktionen zu isolieren. Dies wird ermöglicht durch die Gruppierungsmöglickeit als strukturierter Aktivitätsknoten und dadurch, dass ein Attribut desselbigen, mustIsolate, auf wahr gesetzt wird. Ist ein strukturierter Aktivitätsknoten auf diese Weise isoliert, dann kann auf kein Objekt, das bei einer Aktion in diesem Knoten benutzt wird, von einer Aktion von außerhalb zugegriffen werden, bis der strukturierte Aktivitätsknoten als Ganzes fertig ist.

12.7 Strukturierte Aktivitätsknoten

391

Irgendwelche parallelen Aktionen, die zu Zugriffen auf solche Objekte führen könnten, müssen ihre Ausführung verschieben, bis der Knoten fertig ist. Wie wird eine solche Isolation erreicht und wie werden damit Probleme mit der Paralellverarbeitung vermieden? Z.B. durch Sperrmechanismen (locking mechanisms) oder durch Sequentialisierung (in eine Reihenfolge bringen) der Ausführung. Ein solches Element verlangt nach der Einhaltung bestimmter Regeln. Hier die wichtigsten: x x x x x

Strukturierte Aktivitätsknoten dürfen sich nicht überlappen, die Knoten des einen dürfen nicht zu einem anderen gehören. Sie dürfen verschachtelt sein. Die Kanten eines strukturierten Aktivitätsknotens müssen ihre Quellund Zielknoten innerhalb des strukturierten Aktivitätsknotens haben. Kein Unterknoten des strukturierten Knotens darf mit der Ausführung beginnen, bevor der Knoten selbst einen Kontrolltoken verbraucht hat. Ein Kontrollfluss von einem strukturierten Aktivitätsknoten weg bedeutet: Ein Token wird nur dann produziert, wenn keine Token in dem Knoten oder in denen, die er rekursiv enthält, mehr übrig sind.

Zugriff Außerdem gilt, dass auf einen Objektknoten, der in einem strukturierten Aktivitätsknoten enthalten ist, nur innerhalb des Knotens zugegriffen werden kann. Es gelten dieselben Regeln wie für Kontrollflüsse. Ein Input-Pin auf einem strukturierten Aktivitätsknoten bedeutet, dass im Knoten keine Aktion mit der Ausführung beginnen darf, bis alle Input-Pins Token erhalten haben. Ein Output-Pin auf einem strukturierten Aktivitätsknoten macht erst dann Token nach außen verfügbar, wenn keine Token in ihm und in den Knoten, die er rekursiv enthält, zurückbleiben. Verschachtelung - Ebenen Insgesamt entstehen so z.B. drei Ebenen: Aktionen, strukturierte Aktivitätsknoten und Aktivitäten. Aktionen sind die Elementarbestandteile, strukturierte Aktivitätsknoten die erste Gruppierung von sinnvoll miteinander agierenden Aktionen, Aktivitäten dann die Gesamtheit. Die UMLAutoren sprechen hier auch von verschachtelten Knoten. Grafische Darstellung Ein strukturierter Aktivitätsknoten wird durch ein Rechteck rund um seine Knoten und Kanten dargestellt. Das Rechteck hat eine gestrichelte Linie und runde Ecken. Am oberen Rand wird das Schlüsselwort <<structured>> angefügt.

Regeln

392

12 Aktivitäten

12.8 Kontrollknoten Hinführende und wegführende Kanten Exklusives Oder

UND

Die Kontrollknoten dienen der Strukturierung des Kontrollflusses innerhalb der Aktivität. Sie haben somit immer mit Aktivitätskanten zu tun, die zu ihnen hin- oder von ihnen wegführen und die sie der Logik eines Verknüpfungsoperators unterwerfen. Auch wenn die Begrifflichkeit der UML-Autoren eine andere ist, so definieren sie doch ein exklusives ODER. Ist es verzweigend, kommt also eine Kante an und und gehen mehrere weg, wird es DecisionNode genannt. Ist es verknüpfend, kommen also mehrere Kanten und geht nur eine weg, wird es MergeNode genannt. Ebenso liegt ein logisches UND vor. Ist es verzweigend, wird es ForkNode genannt, ist es verknüpfend JoinNode. Weiter gibt es Knoten, die das Ende von Aktivitäten signalisieren (FinalNode). Für die gesamte Aktivität den Schlussknoten AF (ActivityFinal), für einzelne Kontrollflüsse den Schlussknoten FF (FlowFinal). Ein letzter Knoten, der InitialNode, gibt einen Startpunkt der Aktivität an. Die folgende Abbildung gibt eine Gesamtübersicht und zeigt die grafischen Grundelemente: x x x x x

Die Raute für DecisionNode und MergeNode Der Balken für ForkNode und JoinNode Der gefüllte Punkt für den InitialNode Der Kreis mit innerem Punkt für den Schlussknoten AF (ActivityFinal) Der Kreis mit einem Kreuz im Inneren für den Schlussknoten FF (FlowFinal)

Abbildung 12.8-1:

:::::: Kontrollknoten und ihre grafische Darstellung

12.8 Kontrollknoten

393

12.8.1 DecisionNode Ein DecisionNode repräsentiert eine exklusiv-ODER-Verknüpfung in den wegführenden Kanten, d.h., die wegführenden Kanten sind alternativ. Semantisch bedeutet dies, dass die Kanten alternative Aktionen ansteuern. Grafische Darstellung Die grafische Darstellung geht von einer Raute aus. Eine Kante führt hin, mehrere führen weg.

Abbildung 12.8-2:

DecisionNode mit Aktivitätskanten

Beispiel Im Beispiel der folgenden Abbildung kommt nach der Aktion Auftragseingang die Prüfung, ob der Auftrag angenommen oder abgelehnt wird. Diese ist durch den DecisionNode modelliert. Die alternativen Ergebnisse der Prüfung werden an die weiterführenden Kanten geschrieben. Diese stoßen dann jeweils eine entsprechende Aktion an: Auftrag ablehnen bzw. Auftrag annehmen.

Abbildung 12.8-3:

Beispiel für den Einsatz eines DecisionNode

Variante Es kann auch eine Bedingung für den Entscheidungsprozess definiert werden. Diese wird decision input behavior genannt, in einer Notiz angegeben und durch das Schlüsselwort <<decisionInput>> gekennzeichnet. Vgl. die folgende Abbildung.

Abbildung 12.8-4:

Entscheidungsknoten mit decisionInput Quelle: [OMG 2003a, S. 321, Figure 237]

Ein decision input behavior hat einen Inputparameter und einen Outputparameter. Der Inputparameter muß zu dem Objekttoken (object token)

394

12 Aktivitäten

passen, der über die hinführende Kante ankommt. D.h., er muß vom selben Typ sein. Das decision input behavior darf keine Seiteneffekte haben. In Abbildung 12.14-2 findet sich ein Beispiel. Dort ist die Bedingung für den Entscheidungsknoten, die decision condition, dass der Lagerbestand kleiner ist als die Nachbestellmarke. Der Tokenfluss Nur zu einer Kante

Restkategorie - Else

Tokenfluss bei decision input behavior

Jeder Token, der bei einem Entscheidungsknoten ankommt, kann nur zu einer der wegführenden Kanten gelangen (dies entspricht dem exklusiven Oder). In der Sprache der UML-Autoren: Die Token werden nicht vervielfältigt. Die hinführenden Kanten bieten den wegführenden Kanten die Token an. In der Regel bestimmen die Wächter der wegführenden Kanten, mit welcher von ihnen es weiter geht. Die Reihenfolge, in der die Wächter ausgewertet werden ist nicht definiert. Der Modellierer sollte es so einrichten, dass jedes Token nur für eine wegführende Kante gewählt werden kann, um eine „Wettlaufsituation“ (vgl. Abschnitt 12.14-7) zwischen den wegführenden Kanten zu vermeiden [OMG 2003a, S. 320]. Für den Fall, dass keine der wegführenden Kanten einen Token akzeptiert, sollte ein „Else-Wächter“ definiert werden (für höchstens eine Kante). Dieser kommt also dann zu Wirkung, falls der Token von allen anderen wegführenden Kanten nicht akzeptiert werden kann. Das entspricht der üblichen Restkategorie, die bei solchen Verzweigungen immer berücksichtigt werden muss. Falls Bedingungen für den Entscheidungsknoten durch ein decision input behavior definiert sind, wird jeder Token zuerst bezüglich dieser Bedingungen geprüft, bevor der Abgleich mit den Wächtern der wegführenden Kanten erfolgt. Das Ergebnis dieser Prüfung steht den Wächtern zur Verfügung. Decision input behaviors wurden eingeführt, um redundante Neuberechnungen in Wächtern zu vermeiden. 12.8.2 Merge Node

Verschmelzer

Ein MergeNode repräsentiert eine exklusive Oder-Verknüpfung in den hinführenden Kanten, d.h., die hinführenden Kanten sind alternativ. Er ist somit ein Kontrollknoten, zu dem mehrere Aktivitätskanten hinführen und von dem genau eine wegführt. Seine Aufgabe ist es, Kontrollflusszweige, die zuvor z.B. im Rahmen eines decisionNode aufgeteilt wurden, wieder zusammenzuführen. Grafische Darstellung Die grafische Darstellung geht wiederum, wie bei einem DecisionNode, von einer Raute aus. Hier kommen nun aber zuführende Aktivitätskanten und genau eine wegführende dazu.

12.8 Kontrollknoten

Abbildung 12.8-5:

395

Merge Node mit Aktivitätskanten

Beispiel Im folgenden Beispiel (vgl. dazu das EPK-Beispiel in Abbildung 4.4-29) erfolgt der Versand einer Paketsendung entweder mit DHL, mit DPS oder mit UPS. Anschließend wird die Rechnungsstellung angestoßen.

Abbildung 12.8-6:

Beispiel für den Einsatz eines MergeNode

Der Tokenfluss Alle Token der ankommenden Kanten werden den wegführenden angeboten. Da immer nur eine hinführende Kante aktiv wird, wird genau ein Token weitergereicht. Es kommt vor, dass ein MergeNode und ein DecisionNode unmittelbar hintereinander folgen. Dann können die beiden Knoten grafisch zusammengefasst werden, wie es die folgende Abbildung zeigt.

Abbildung 12.8-7:

MergeNode und DecisionNode zusammen

In Bezug auf die Semantik bedeutet dies, dass in einer konkreten Situation genau eine der ankommenden Kanten aktiv wird und dass der Kontrollfluss zu genau einer der wegführenden Kanten führt. Beispiel Die Situation im folgenden Fragment kann man sich wie folgt vorstellen: Ein Handelshaus hat einen Teil der Kunden schon auf Rechnungen umgestellt, die per E-Mail verschickt werden. Die meisten erhalten aber die Rechnung noch per Brief. Wenn dann eine Paketsendung fertig und verschickt ist, muss entschieden werden, auf welche Weise anschließend die Rechnung verschickt wird.

MergeNode + DecisionNode

396

12 Aktivitäten

Abbildung 12.8-8:

MergeNode und DecisionNode zusammen

12.8.3 ForkNode Ein ForkNode repräsentiert eine Und-Verknüpfung in den wegführenden Kanten, d.h., alle wegführenden Kanten werden aktiviert, wenn der Kontrollfluss beim Knoten ankommt. ForkNodes wurden eingeführt, um Parallelität von Kontrollflusszweigen in Aktivitäten modellieren zu können. Grafische Darstellung Die grafische Darstellung geht von einem Balken aus. Hier kommen nun aber eine zuführende und mehrere wegführende Aktivitätskanten dazu.

Abbildung 12.8-9:

ForkNode mit Aktivitätskanten

Beispiel Im folgenden Beispiel wird zuerst die Aktion Auftrag ausführen ausgelöst. Diese startet dann zwei Aktionen: Auftrag versenden und Rechnung senden.

Abbildung 12.8-10:

Beispiel für den Einsatz eines ForkNode

Der Tokenfluss Die Token kommen über die hinführende Kante bei dem Knoten an. Sie werden dann allen wegführenden Kanten angeboten. Wenn das Token von allen diesen akzeptiert wurde, werden sie vervielfältigt und jeweils eine Kopie geht weiter zu einer Kante.

12.8 Kontrollknoten

397

Auch bei diesem Knoten sind auf den wegführenden Kanten Wächter möglich. Falls dies so ist, führen die UML-Autoren aus, muss der Modellierer sicherstellen, dass keine Joins weiter vorne im Fluss (downstream joins) von den Token abhängen, die durch die kontrollierte Kante kommen. Falls dies nicht vermieden werden kann, sollte ein Entscheidungsknoten eingeführt werden, der für den Fall, dass der Wächter den einzigen Kantenfluss zum Join-Knoten blockiert, den Token flussabwärts führt. Abbildung 12.14-1 (Reparaturen) zeigt ein Beispiel. Vgl. auch die Ausführungen dort. 12.8.4 JoinNode Ein JoinNode repräsentiert eine UND-Verknüpfung bzgl. der hinführenden Kanten, d.h., alle hinführenden Kanten müssen aktiv werden, nur dann geht es über den Knoten weiter. Er ist somit ein Kontrollknoten, zu dem mehrere Aktivitätskanten hinführen und von dem genau eine wegführt. Grafische Darstellung Die grafische Darstellung geht wiederum, wie bei einem ForkNode, von einem Balken aus. Hier kommen nun aber zuführende Aktivitätskanten und genau eine wegführende dazu.

Abbildung 12.8-11:

Join Node mit Aktivitätskanten

Beispiele Im folgenden Beispiel werden zuerst Rohstoffe bereit gestellt, Fremdteile beschafft und Kapazitäten eingeplant. Erst wenn all dies geschehen ist, kann die Produktion geplant werden (vgl. dazu das EPK-Beispiel in Abbildung 4.4-6).

Abbildung 12.8-12:

Beispiel für den Einsatz eines JoinNode

Das nächste Beispiel zeigt den JoinNode in Zusammenhang mit SignalToken und mit einer Kantengewichtung.

Wächter

398

12 Aktivitäten

Abbildung 12.8-13:

JoinNode mit Signal-Token und Kantengewichtung In Anlehnung an [OMG 2003a, S. 297, Figure 213].

Hintergrund Die UML-Autoren führen aus, dass die JoinNodes eingeführt wurden, um Parallelität in Aktivitäten zu unterstützen [OMG 2003a, S. 341]. Mit Parallelität kann dann nur gemeint sein, dass der Kontrollfluss über den JoinNode erst dann weitergeht, wenn alle Aktionen vor den hinführenden Kanten ausgeführt wurden. Insofern ist auch verständlich, wenn sie ausführen, dass ein JoinNode mehrere Kontrollflüsse synchronisiert [OMG 2003a, S. 338]. Der Tokenfluss Wenn auf allen ankommenden Kanten ein Token angeboten wird, werden der wegführenden Kante Token gemäß den folgenden Regeln angeboten [OMG 2003a, S. 339]: x x

Voreinstellung: AND

Join-Spezifikation

Falls alle angebotenen Token Kontrolltoken sind, dann wird der wegführenden Kante ein Kontrolltoken angeboten. Falls einige der angebotenen Token Kontrolltoken sind und andere Datentoken, dann werden nur die Datentoken der wegführenden Kante angeboten.

Die Funktionalität eines UND-Operators erläutern die UML-Autoren mit Hilfe der Token wie folgt: Das reservierte Wort “and” als Join-Spezifikation bedeutet, dass von jeder ankommenden Kante mindestens ein Token verlangt wird. Wie sehr die Überlegungen der UML-Autoren ins Detail gehen zeigt die folgende Festlegung des Tokenflusses: Falls der wegführenden Kante Token angeboten werden, muss die Weitergabe (traversal) akzeptiert oder abgelehnt werden, bevor weitere Token der wegführenden Kante angeboten werden. Falls Token zurückgewiesen werden, werden sie der wegführenden Kante nicht länger angeboten. [OMG 2003a, S. 339] Falls eine Join-Spezifikation angegeben wird, wird sie wie in der nächsten Abbildung angegeben, zur Grafik hinzugefügt.

12.8 Kontrollknoten

Abbildung 12.8-14:

399

JoinNode mit Join-Spezifikation

Beispiel Das folgende Beispiel enthält eine solche Festlegung des Joins. Die Festlegung besagt: Erst wenn beide Aktionen abgeschlossen sind und wenn zusätzlich die eingeworfenen Münzen den Getränkepreis abdecken, dann wird das Getränk ausgegeben.

Abbildung 12.8-15:

JoinNode mit Join-Spezifikation

Vergleich UML / EPK – Join vs UND Der Join entspricht dem Und-Operator. Das Beispiel oben macht aber deutliches deutlich: Im Vergleich mit EPKs ist eine Aktion hier aber gleich „Funktion + positivem (Ergebnis-)Ereignis“ dort. D.h., die UMLAutoren fassen das eigentliche „Geschehen“ in der Aktion mit dem positiven Ergebnis zusammen. Die Methode EPK dagegen trennt dies ganz grundsätzlich. Das „Geschehen“ in der Funktion ist getrennt von allen möglichen Ergebnissen. Diese werden durch die ja zwangsweise (von der Syntax erzwungenen) nachfolgenden Ereignisse modelliert. Die Join-Spezifikation würde bei EPKs durch eine Folge von Funktionen und Ereignissen modelliert. Wobei die UML-Struktur jeweils die Aktivität mit dem positiven Ergebnisereignis zusammenfasst. Die folgende Abbildung zeigt das obige Beispiel in EPK-Notation.

Aktion=Funktion + positives Ergebnis

400

12 Aktivitäten

Abbildung 12.8-16:

Ereignisgesteuerte Prozesskette – Vorige Abfolge als EPK

Join Node und Fork Node zusammen Ähnlich wie oben für den MergeNode und den DecisionNode gezeigt, können auch JoinNode und ForkNode direkt hintereinander fallen und grafisch zu einem Element verschmelzen.

Abbildung 12.8-17:

JoinNode + ForkNode

Hier liegt zuerst ein JoinNode vor, dessen einzige wegführende Kante nicht angezeigt wird. Unmittelbar danach folgt der ForkNode, dessen einzige hinführende Kante nicht angezeigt wird. Solche Strukturen bei Operatoren sind durchaus üblich, bei EPKs entsprechen dem zwei unmittelbar aufeinanderfolgende UND-Operatoren. 12.8.5 Startknoten Ein Startknoten (InitialNode) markiert den Start der Aktivität. Er gibt an, welcher Fluss startet, wenn die Aktivität aufgerufen wird. Eine Aktivität kann mehr als einen Startknoten haben. Wird dann die Aktivität gestartet,

12.8 Kontrollknoten

401

starten mehrere Kontrollflüsse, einer bei jedem Startknoten. Ein Startknoten hat keine ankommenden Kanten und genau eine wegführende. Graphische Darstellung Startknoten werden durch einen eingefärbten schwarzen Kreis dargestellt:

Beispiel

Abbildung 12.8-18:

Startknoten

Weitere Beispiele finden sich in den folgenden Aktivitäten. Der Tokenfluss Wenn die Aktivität startet, wird ein Kontrolltoken auf dem Startknoten platziert. Die Token in einem Startknoten werden allen wegführenden Kanten angeboten. Hat eine Aktivität mehr als einen Startknoten, werden durch den Aufruf der Aktivität mehrere Kontrollflüsse gestartet, eines bei jedem Startknoten. Der Einfachheit halber sind Startknoten eine Ausnahme von der Regel, dass Kontrollknoten keine Token halten können, wenn diese daran gehindert werden, im Kontrollfluss voranzuschreiten. Dies ist gleichbedeutend damit, einen Pufferknoten zwischen dem Startknoten und seinen wegführenden Kanten zwischenzuschalten. [OMG 2003a, S. 335] Außerdem weisen die UML-Autoren darauf hin, dass Kontrollflüsse auch von anderen Knoten starten können, so dass nicht unbedingt Startknoten da sein müssen, um eine Aktivität zu starten. [ebenda]

Keine Speicherung in Kontrollknoten

12.8.6 Schlussknoten - ActivityFinal und FlowFinal Es gibt zwei Aktivitätsknoten, die eine Beendigung von Kontrollflüssen modellieren: ActivityFinal modelliert die Beendigung der gesamten Aktivität, FlowFinal die Beendigung eines einzelnen Kontrollflusses. Hier sollen diese Knoten mit Schlussknoten AF bzw Schlussknoten FF bezeichnet werden. Schlussknoten AF Ein Schlussknoten AF stoppt, sobald er erreicht wird, alle Kontrollflüsse in einer Aktivität. Eine Aktivität kann mehr als einen Schlussknoten AF haben. Ist dies so, beendet der erste, der erreicht wird, die Aktivität, einschließlich der Flüsse, die zu anderen Schlussknoten führen.

Schlussknoten AF (ActivityFinal)

402

12 Aktivitäten

Grafische Darstellung Schlussknoten AF werden wie folgt dargestellt:

Der Tokenfluss Ein Schlussknoten AF akzeptiert alle Token von ankommenden Kanten. Erreicht dann ein Token einen solchen Knoten, wird die Aktivität beendet und der Token wird zerstört. Irgendwelche Objektknoten, die als Output deklariert sind, werden aus der Aktivität rausgegeben. Beispiel Im folgenden Beispiel soll nach der Aktion Ware versenden die gesamte Aktivität beendet werden.

Abbildung 12.8-19:

Schlussknoten AF (ActivityFinal)

Während obiger Schlussknoten AF dem Üblichen entspricht, das man von Methoden der Ablaufbeschreibung kennt, zeigt der nachfolgende Schlussknoten FF (FlowFinal) neue interessante Modellierungsmöglichkeiten auf. Schlussknoten FF (FlowFinal) Ein Schlussknoten FF ist ein Schlussknoten, der nur den Kontrollfluss beendet, mit dem er verknüpft ist, alle übrigen aber bestehen lässt. Dem liegt wohl die Überlegung zugrunde, dass es sinnvoll ist, wenn nur einzelne Kontrollflusszweige abgeschaltet werden können. Mehr dazu unten. Grafische Darstellung Schlussknoten FF werden wie folgt grafisch dargestellt:

Der Tokenfluss Ein Schlussknoten FF zerstört alle Token, die bei ihm ankommen, aber nur diese. Er hat, im Gegensatz zum Schlussknoten AF, keine Wirkung auf die Token in anderen Kontrollflüssen. Vergleich UML / EPK - Prozess-Sicht Nicht in Prozessen …

Das verrät nun tatsächlich eine andere Sichtweise des Geschäftsprozesses als bei Ereignisgesteuerten Prozessketten. Zur Erinnerung: Eine Instanz

12.8 Kontrollknoten

403

eines Geschäftsprozesses wird einmal gestartet, durchlaufen und ist dann beendet. Jeder Zweig, bei dem es nicht weitergeht, ist beendet. Ein Schlussereignis, wie früh es auch kommt, beendet den Gesamtprozess. Es ist bei EPKs nicht denkbar, dass irgendein Kontrollflusszweig noch weiter aktiv ist, obwohl andere beendet wurden. Hier in der UML ist dies nun tatsächlich möglich. Ein mit einem Schlussknoten FF beendeter Zweig wird abgebrochen, der Rest der Aktivität kann noch weiter existieren. Sehr schnell erklärbar wird dieses Konzept, wenn wir an Systeme denken. Hier ist durchaus denkbar, dass ein Teil eines Systems abgeschaltet wird, auch wenn der Rest noch weiter aktiv ist. Es ist sogar eine Standardsituation. Gründe dafür können Fragen der Sicherheit (Datenleitung wird gekappt, obwohl Informationsverarbeitung noch läuft), Vermeidung von Nebeneffekten (abgeschaltete Systemteile können keinen „Unsinn“ mehr anstellen) oder einfach Solidität (des Systems, der Anwendung) sein.

… aber in Systemen

Beispiel Im folgenden Beispiel sei die Situation wie folgt: Zahlreiche Komponenten werden gebaut und installiert. Die Aktion Stelle Komponente her ist in einer Schleife. Nach jeder Komponentenproduktion wird zum einen die Aktion Baue Komponente ein aktiviert, zum anderen kommt es aber auch zu einem Entscheidungsvorgang, der in der Grafik durch den Entscheidungsknoten (DecisionNode) angegeben ist. Da wird geprüft, ob weitere Komponenten herzustellen sind oder nicht. Die beiden möglichen Ergebnisse sind [weitere Komponenten zu bauen] bzw. [keine weiteren Komponenten zu bauen]. Dieser Entscheidungsvorgang wird jedesmal, nach der Herstellung jeder Komponente, durchgeführt. Irgendwann kommt es hier zu der Entscheidung, dass keine weiteren Komponenten zu bauen sind. Dann wird dieser Kontrollfluss (diese Wiederholschleife rund um die Herstellung) durch den Schlussknoten FF (FlowFinal) abgebrochen, während andere noch weiter aktiv sein können. Z.B. auch Baue Komponente ein. [OMG 2003a, S. 333 und 332 ] Die Aktion Baue Komponente ein ist weiterhin aktiv, auch wenn der oben erwähnte Schlussknoten FF erreicht wurde. Solange die nachfolgende Entscheidung so ausfällt, dass weitere Komponenten zu installieren sind, wird dieser Kontrollfluss lokal beendet, mit einem weiteren Schlussknoten FF. Erst wenn die Situation so ist, dass keine weiteren Komponenten zu installieren sind, wird die Anlage geliefert. Danach wird dann, in der Grafik durch den Schlussknoten Anwendungsfall festgehalten, die gesamte Aktivität beendet.

Komponenten installieren und zusammenbauen

404

12 Aktivitäten

Abbildung 12.8-20:

Komponentenverarbeitung – Schlussknoten AF (ActivityFinal) und Schlussknoten FF (FlowFinal) im Einsatz Quelle: [OMG 2003a, S. 332, Figure 251] Übersetzung durch den Verfasser

ActivityFinal vs. FlowFinal

Weitere Motive

Nach der Motivation für den Schlussknoten AF muss man nicht fragen. Jeder Modellierungsansatz, der Abläufe modelliert, hat ein solches Element. Was aber ist die Motivation für den Schlussknoten FF neben dem oben schon angeführten, das sich aus den Anforderungen der Systemanalyse ergibt? Die UML-Autoren nennen zwei Situationen für seinen Einsatz: (1) Eine Aktivität beschreibt ja eine bestimmte abgegrenzte Folge von Tätigkeiten. Falls für alle Aufrufe einer solchen Tätigkeitsfolge dieselbe Aktivität benutzt wird, fließen unterschiedliche Tokenströme durch dieselbe Aktivität. In so einem Fall ist es u.U. nicht gewünscht, alle Token zu vernichten, wenn eines einen Schlussknoten erreicht. Benutzt man nun an einer solchen Stelle einen Schlussknoten FF, dann werden nur die Token zerstört, die diesen erreichen, die anderen bleiben bestehen. Das korrespondiert mit dem oben angeführten Verweis auf den Systemgedanken. Man stelle sich eine Systemkoponente vor, die von mehreren Aktivitäten benutzt wird, z.B. in einem Geldautomaten eines Parkhauses die Komponente, die Geldscheine erfasst und ihren Wert festhält. Benötigt wird Sie bei der Eingabe von Geld in den Automaten durch die Mitarbeiter, bei der Ausgabe von Geld an abhebende Kunden, evtl. bei der Rückgabe von Restgeld, usw. Dann ist durchaus vorstellbar, dass eine solche Komponente „isoliert“ abgeschaltet werden soll. (2) Für unterschiedliche Aufrufe einer Aktivität sollen Varianten derselben benutzt werden, dann können Token von unterschiedlichen Aufrufen sich gegenseitig nicht beeinträchtigen. Hintergrund: Bei der Modellierung von Abläufen hat man oft das Problem, dass man dieselbe Ablauffolge in leichter Variation benötigt. Die einfache Lösung ist, die Ablauffolge mehrfach – dupliziert – einzusetzen. Dies führt aber zu einer Vermehrung von Modelelementen, weshalb man u.U. die Variation innerhalb eines Modellelements abfängt.

12.9 Aufruf von Aktivitäten

405

Anstatt nun also eine Aktivität zu duplizieren und jeweils eine bestimmte Variante in einer Aktivität zu modellieren, fängt man die Varianten innerhalb der Aktivität ab. Dann kann es sinnvoll sein, bestimmte Kontrollflüsse bei einem Durchgang abzuschalten, die anderen aber nicht.

12.9 Aufruf von Aktivitäten Wie können Aktivitäten aufgerufen werden? Die erste Variante ist der (nicht dokumentierte) Aufruf durch externe Ereignisse. Z.B. wenn ein Kundenauftrag eintrifft, ein Angebot erstellt werden muss oder sich ein Kunde dem Geldautomaten nähert und diesen aktiviert. In Anlehnung an die Ausführungen bei den Ereignisgesteuerten Prozessketten kann da vom Ereignisraum (des Unternehmens, der Anwendung) gesprochen werden, der sich durch das Ereignis artikuliert. Die Ereignisse diese Ereignisraumes werden deutlicher, wenn das objektorientierte Modell insgesamt vorliegt. Da werden Aktivitäten üblicherweise indirekt, als Methoden, die an Operationen gebunden sind, aufgerufen. Die zweite Variante ist, dass eine Aktivität A eine Aktivität B aufruft. Dann enthält Aktivität A eine Aktion, die diesen Aufruf signalisiert. Die folgende Abbildung zeigt ein Beispiel. In Aktivität A gibt es das Aktionssymbol Angebotserstellung mit dem Symbol , das eine gleichnamige Aktivität aufruft und dort den Startknoten aktiviert.

Abbildung 12.9-1:

Aufruf aus dem Ereignisraum

Einbindung in objektorientierte Modelle Aufruf durch eine andere Aktivität

Aufruf einer Aktivität durch eine Aktion einer anderen Aktivität

Diese aufrufende Aktion ist genauso in den Kontrollfluss eingebettet wie eine normale Aktion. D.h., sie hat neben einer hinführenden auch eine wegführende Aktivitätskante. Vgl. hierzu das Beispiel in den Abbildungen 12.14-5 und 12.14-6.

12.10 Aktivitäten aufteilen – Träger zuordnen Das Problem, den Aktionen einer Aktivität die Träger (z.B. Organisationseinheiten) zuzuordnen, lösen die UML-Autoren wie folgt: Sie führen ein allgemeines Konzept ein, Ähnlichkeit zwischen Aktionen erfassen zu können und nennen dies ActivityPartition. Im Falle der Träger von Aktionen besteht dann die Ähnlichkeit darin, denselben Träger zu haben. Grafisch wird dies auf unterschiedliche Weise realisiert. Zum Beispiel über sog. Schwimmbahnen (swim lanes), wie es die folgende Abbildung zeigt.

Ähnlichkeit zwischen Aktionen

406

12 Aktivitäten

Das Beispiel der folgenden Abbildung ist bekannt: Aktivität Auftragsbearbeitung. Vgl. das Stichwortverzeichnis für die Fundorte aller Varianten dieser Aktivität.

Abbildung 12.10-1:

Träger in Bahnen

Aktivität Auftragsbearbeitung – mit Schwimmbahnen Quelle: [OMG 2003a, S. 310, Figure 226] – leicht verändert. Übersetzung durch den Verfasser

Dabei wird die gesamte Aktivität in Bahnen aufgeteilt, in denen sich jeweils die Aktionen eines Trägers befinden. Im obigen Beispiel ist die oberste Bahn der Abteilung Auftragsbearbeitung zugeordnet. Entsprechend sind in ihr die Aktionen Auftragseingang, Auftrag ausführen, Lieferung und Auftrag schließen angesiedelt. Die zweite Bahn enthält die Aktionen, die durch das Finanzwesen realisiert werden, die dritte die vom Kunden realisierte Aktion. Das ist hier – natürlich – der Zahlvorgang. Der Objektknoten, der ja jetzt nicht nur eine Wanderung von einer Aktion zur nächsten signalisiert, sondern auch den Wechsel der Bahn, wird auf die Grenzlinie gesetzt. Dieses Beispiel macht auch deutlich, dass die UML-Autoren den Geschäftsprozessen inzwischen tatsächlich näher getreten sind als früher, denn es ist inhaltlich deutlich näher an Geschäftsprozessen als an Systemen. Vergleich UML / EPK - Schwimmbahnen für Träger von Aktionen

Nur bedingt geeignet

Soweit die Schwimmbahnenlösung für das Problem, die Träger der Aktionen mit zu erfassen. Überzeugen kann sie nicht, tauglich ist sie höchstens für kleine Modelle, denn wie sollen größere Anzahlen von Trägern,

12.10 Aktivitäten aufteilen – Träger zuordnen

407

die in einer umfangreichen Geschäftsprozessanalyse leicht anfallen, auf diese Weise untergebracht werden? Die Vorgehensweise, wie wir sie bei Ereignisgesteuerten Prozessketten haben, dass bei jeder Funktion der Träger vermerkt wird, ist – falls die Modelle größer werden – die bessere Lösung. Mehrdimensionale Schwimmbahnen Die Lösung mit Schwimmbahnen gibt es auch mehrdimensional. Vgl. [OMG 2003a, S. 311] und Abbildung 228. Dabei werden die beiden Dimensionen in der horizontalen und vertikalen angeordnet (z.B. geografische Standorte und Abteilungen). Eine solche Lösung ist jedoch nur möglich, falls nicht mehr als zwei Dimensionen vorliegen und diese nur wenig Ausprägungen haben. Eine weitere von den UML-Autoren vorgeschlagene Lösung besteht darin, im Symbol für die Aktionen die Träger zu vermerken, so wie es die folgende Abbildung zeigt.

Abbildung 12.10-2:

Aktivität Auftragsbearbeitung – mit Trägern bei den Aktionen Quelle: [OMG 2003a, S. 310, Figure 227], leicht verändert. Übersetzung durch den Verfasser

Vergleich UML / EPK – Träger im Aktionssymbol Im Anschluss an die Ausführungen im obigen Vergleich kann diese Variante nur sehr begrüßt werden. Sie erlaubt auch die Modellierung größerer Modelle mit zugeordneten (zahlreichen) Trägern von Aktionen und kommt der Lösung bei Ereignisgesteuerten Prozessketten sehr nahe. Es bleibt allerdings die Frage, was getan werden muss, wenn z.B. mehrere Organisationseinheiten Träger sind oder wenn es Beziehungen zwischen diesen gibt („Das macht die Materialwirtschaft mit der Lagerhaltung oder mit der Produktionsplanung“). Letzteres liegt in der Praxis tatsächlich oft vor.

Schwimmbahnen mehrdimensional

Träger zu den Aktionen

408

12 Aktivitäten

12.11 Die zeitliche Dimension und die Ereignisse

Keine explizite Berücksichtigung der Zeit

Alle Ansätze, die Abläufe bzw. Tätigkeitsfolgen modellieren, müssen die zeitliche Dimension mitberücksichtigen. In der Version 2.0 der UML geschieht dies auch, wobei die Konzepte zur Einbeziehung von Zeitaspekten sehr eng mit dem Ereigniskonzept zusammenhängen, weshalb beide hier gemeinsam betrachtet werden. Ähnlich wie bei Ereignisgesteuerten Prozessketten ist in Aktivitäten keine explizite Berücksichtigung der Zeitachse vorgesehen. Nur in der Erfassung des Hintereinanderfolgens der einzelnen Aktionen wird zumindest die relative zeitliche Position der Aktionen erfasst. Mit den Aktivitätskanten und den verschiedenen Knoten ist dies umfassend modelliert und im Kontrollfluss festgehalten. Ähnlich sehen es auch die UMLAutoren: “The UML does not provide for the specification of a time metric, but only describes sequences of executions.” [OMG 2003a, S. 265]

Ereignisse (events)

Ereignisse lösen Verhalten aus

Liste von Ereignissen

Ganz anders mit Ereignissen. Diese müssen als Konzept bei der Modellierung von Abläufen vorhanden sein und sie sind es auch hier in vielfältiger Form. Grundsätzlich gilt hier wie bei Ereignisgesteuerten Prozessketten, dass Ereignisse entweder von außen kommen oder intern entstehen. Intern bedeutet hier: innerhalb einer Aktivität. In der UML werden Ereignisse in enger Verbindung mit Verhalten gesehen: Ereignisse lösen Verhalten aus [OMG 2003a, S. 8]. Den umgekehrten Tatbestand, dass Verhalten auch zu bestimmten Ereignissen führt, sehen/benötigen die UML-Autoren nicht, bzw. modellieren ihn auf andere Weise, durch Festlegung der jeweils folgenden Aktionen. Folgende unterschiedlichen Ereignisse werden hier u.a. unterschieden: x x x x x x x x x x x x

call behavior event call event call invocation event change event invocation event receiving event send invocation event signal event start event termination event time event trigger event

Die meisten stellen nur Bezeichnungen dar, einige der v.a. durch den Tokenfluss inhaltlich begründeten werden im folgenden erläutert.

12.11 Die zeitliche Dimension und die Ereignisse

409

EventOccurrence Um ihr Theoriegebäude lückenlos zu halten, benötigen die UML-Autoren auch ein Theorieelement für den Zeitpunkt, in dem ein Ereignis eintritt. Dies ist die Klasse EventOccurrences. Mit diesem Konzept wird auch die Beziehung zwischen Ereignissen und Aktionen hergestellt, indem die UML-Autoren definieren, dass EventOccurrences Zeitpunkte darstellen, denen Aktionen zugeordnet sind [OMG 2003a, S. 416]. Weiteres zu EventOccurrences findet sich in Abschnitt 13.4 (Interaktionen). Wie kommen nun die Ereignisse in die Aktivität? In der UML genügt es nicht, dass ein Ereignis eintritt und eine Aktion anstößt, hier ist dieser Vorgang detaillierter konzeptionell vorgedacht und wird dann detaillierter modelliert. Eine wichtige Rolle spielt dabei die AcceptEventAction. Wie die Schreibweise schon andeutet, handelt es sich auch hier um eine Klasse in der Metamodellierung der UML. Sie ist definiert als eine Aktion, die auf das Eintreten eines Ereignisses wartet, das bestimmten Bedingungen genügt. [OMG 2003a, S. 217] Die „Philosophie“ der UML an dieser Stelle kann wie folgt beschrieben werden: x x x

Verbindung von Ereignissen und Aktionen

AcceptEventAction

Eine Aktivität gehört einem Objekt (owning object). Ereignisse werden durch die Objekte unabhängig von Aktionen entdeckt. Die Ereignisse werden durch das Objekt gespeichert. D.h., sie äußern sich durch Daten in irgendeiner Form.

Damit kann dann formuliert werden: AcceptEventActions gehen mit Ereignissen um, die von dem Objekt entdeckt werden, dem die Aktivität „gehört“. Es versteht sich, dass nur Kontrollkanten zu einer AcceptEventAction führen dürfen. Es wäre nicht sinnvoll, Objekt-Token mit ihr zu konfrontieren. Wie werden Ereignisse denn nun bemerkt? Z.B. als Signal und damit als SignalEvent. Ist das Ereignis ein solches, dann enthält der ErgebnisToken ein signal object, dessen Entgegennahme durch das owning object das Ereignis auslöst. Für eine solche Aktion, die auf einem signal event beruht, nutzen die UML-Autoren auch die Bezeichnung accept signal action. Ist das Ereignis ein TimeEvent, dann enthält der sich ergebende Token den Zeitpunkt, zu dem das Ergebnis eintrat. Für die Aktion, die darauf beruht, nutzen die UML-Autoren auch die Bezeichnung wait time action. Liegt ein CallEvent oder ein ChangeEvent vor, ist das Ergebnis ein Kontrolltoken. In diesem Fall gibt es keine Output-Pins.

Signal und SignalEvent

TimeEvent

ChangeEvent oder CallEvent

410

12 Aktivitäten

Start einer AcceptEventAction Falls eine AcceptEventAction keine ankommenden Kanten hat, startet die Aktion, wenn ihre Aktivität oder ihr strukturierter Aktivitätsknoten es tun. Außerdem gilt, dass eine solche Aktion immer in der Lage ist, Ereignisse zu akzeptieren, egal wie viele. Sie hört auch nicht auf, wenn sie ein Ereignis akzeptiert hat, sondern steht weiterhin in Warteposition, ist also weiterhin aktiv. Dies weicht ab von der ansonsten üblichen Festlegung in der UML. Graphische Darstellung Eine AcceptEventAction wird durch ein Fünfeck mit Einbuchtung dargestellt, vgl. die folgende Abbildung. Eine wait time action durch ein Stundenglas.

Abbildung 12.11-1:

Modellierung von Zeitpunkten AcceptEventAction und wait time action

Beispiele Das erste Beispiel zeigt ein “Signal”, das die Stornierung eines Auftrags verlangt. Die Akzeptanz des Signals stößt dann die Aktion Auftrag stornieren an.

Abbildung 12.11-2:

SendSignalAction

AcceptEventAction im Einsatz

Vor dem nächsten Beispiel wird noch ein weiteres Element, eine weitere Aktion, benötigt, das die Aussendung eines „Signals“ modelliert. SendSignalAction ist diese Aktion, die mit ihrem Input ein einzelnes Signal (signal instance) erzeugt und zum Zielobjekt überträgt. Dort kann diese das „Feuern“ einer Transition in einem Zustandsautomaten (vgl. dazu Kapitel 15) oder die Ausführung einer Aktivität veranlassen. Eventuelle Argumentwerte werden übergeben und das angesprochene „Verhalten“ beginnt sofort mit der Ausführung. Grafische Darstellung Die grafische Darstellung erfolgt durch ein Fünfeck mit Spitze, wie es die nachfolgende Abbildung zeigt.

Abbildung 12.11-3:

SendSignalAction

12.11 Die zeitliche Dimension und die Ereignisse

411

Beispiele Das erste Beispiel ist Teil einer Auftragsverarbeitung, in der zwei Signale gesendet werden. Ein Auftrag wird erstellt, auf der Basis einer Kundenbestellung. Ein „Signal“ wird zum Lager gesendet. Dort wird der Auftrag ausgeführt und verschickt. Dann wird eine Rechnung erzeugt und dem Kunden gesandt.

Abbildung 12.11-4:

SendSignalAction im Einsatz

In der nächsten Abbildung wird folgender Ablauf modelliert: Wenn die Auftragsbearbeitung fertig ist, wird ein „Signal“ zur Zahlungsaufforderung rausgeschickt mit Hilfe einer SendSignalAction. Danach wartet die Aktivität, bis der Zahlungseingang bestätigt wird (durch das AcceptEventAction). Das Zahlungseingangssignal wird nur angenommen, wenn das Signal zur Zahlungsaufforderung vorher gesandt wurde. Wenn dann der Zahlungseingang bestätigt ist, wird der Auftrag versandt.

Abbildung 12.11-5:

SendSignalAction und AcceptEventAction im Einsatz Quelle: [OMG 2003a, S. 218, Figure 158] Übersetzung durch den Verfasser

Das nächste Beispiel zeigt die wait time action im Einsatz. Hier ist modelliert, dass an jedem Monatsende das Ereignis eintritt. Da diese Aktion keine hinführenden Kanten hat, ist sie so lange aktiv, wie ihre Aktivität oder ihr strukturierter Knoten. Sie erzeugt am Ende eines jeden Monats einen Output. Damit können dann monatliche Gehaltszahlungen wie in der folgenden Abbildung modelliert werden.

Abbildung 12.11-6:

wait time action

Das folgende Beispiel zeigt dieses Element in Kombination mit einem JoinNode. Einmal jährlich werden aus einer Personaldatenbank Daten über die Angestellten abgerufen. Danach wird die Beurteilung der Angestellten durchgeführt.

An jedem Monatsende

412

12 Aktivitäten

Abbildung 12.11-7:

Wait time action im Einsatz – repetitive time event

12.12 Kontrollfluss vertieft Es war schon etwas überraschend, dass die früheren Versionen der UML (vor der Version 2.0) für die Aktivitätsmodellierung kein ausdrückliches Kontrollflusskonzept hatten: “Explicitly modeled control flows are new to activity modeling in UML 2.0. They replace the use of (state) Transition in UML 1.5 activity modeling. They replace control flows in UML 1.5 action model.“ [OMG 2003a, S. 316] In der Version 2.0 liegt nun aber ein sehr ausgefeiltes Konzept vor, das oben bei den einzelnen Elementen der Theorie schon eingeführt wurde und das hier nun vertieft betrachtet wird. 12.12.1 Verhalten von Aktionen action execution

Der Start

Die eigentliche Arbeit

Was geschieht nun genau, wenn eine Aktion aktiviert wird? Hier haben die UML-Autoren eine sehr detaillierte Vorstellung, die im folgenden vorgestellt wird. Diese Vorstellung beruht auf dem Konzept der action execution, das in Abschnitt 11.3 schon kurz vorgestellt wurde. Die UML-Autoren definieren eine action execution als das Laufzeitverhalten einer zur Ausführung gebrachten Aktion. Da in der Metamodellierung der UML Action eine abstrakte Klasse ist, sind alle action executions Ausführungen von spezifischen Aktionen. Kommt es zur Ausführung einer Aktion, wird zuerst eine solche action execution erzeugt. Damit dies geschieht, müssen alle Voraussetzungen für die Objekt- und Kontrollflüsse erfüllt sein, d.h. allen Input-Pins müssen Token angeboten worden sein und diese müssen sie angenommen haben. Die action execution verbraucht dann die Kontroll- und Objekttoken des Input und entfernt sie von den Quellen der Kontrollknoten und von den Input-Pins. Sie ist dann in Stand gesetzt und kann mit der Ausführung beginnen. [OMG 2003a, S. 281] Eine Aktion macht so lange weiter bis sie fertig ist. Die meisten Aktionen verarbeiten nur ihren Input. Einige gehen darüber hinaus und arbeiten mit Variablen aus ihrem strukturierten Aktivitätsknoten oder dem self object. Das ist das Objekt, zu dem die Aktivität gehört, in der die execution action stattfindet.

12.12 Kontrollfluss vertieft

413

Wenn sie fertig ist, bietet eine action execution allen ihren Output-Pins Objekt-Token an. Allen ihren wegführenden Kontrollkanten werden Kontrolltoken angeboten. Danach endet sie. Die Output-Token stehen nun zur Verfügung, um die Anforderungen anderer action executions bzgl. der Kontroll- oder Objektflüsse zu erfüllen.

Das Ende

Wie lange sind Aktionen aktiv? Grundsätzlich gilt, dass jede Aktion in einer Aktivität entweder einmal, mehrmals oder auch nicht ausgeführt werden kann [OMG 2003a, S. 265]. Aktionen sind, darauf weisen die UML-Autoren an dieser Stelle ebenfalls hin, eine Angelegenheit, die Zeit verbraucht, die also eine bestimmte Zeitspanne für ihre Realisierung benötigt. Der einfache Fall, dass eine Aktion in der Abarbeitung des Kontrollflusses einmal aufgerufen und ausgeführt wird und dies in einer Wiederholschleife vielleicht auch mehrfach, ist zwar meistens gegeben, aber bei weitem nicht immer, wie die folgenden Ausführungen zeigen.

Einmal, mehrmals oder auch nicht Zeitverbrauch

Ausnahme AcceptEventAction Eine erste Ausnahme findet sich im Umfeld der AcceptEventAction. Hier wird ausgeführt, dass eine solche Aktion, wenn sie keine hinführenden Kanten hat, zusammen mit ihrer Aktivität (oder ihrem strukturierten Aktivitätsknoten) startet. Sie ist dann aber immer in der Lage, Ereignisse zu akzeptieren, egal wie viele und hört auch nicht auf, wenn sie ein Ereignis akzeptiert hat, sondern steht weiterhin in Warteposition, ist also weiterhin aktiv. Die UML-Autoren weisen dann aber darauf hin, dass dies von der ansonsten üblichen Festlegung in der UML abweicht [OMG 2003a, S. 217f]. Vergleich UML / EPK - Ereignisse Erinnern wir uns. In der Methode EPK werden Ereignisse als solche direkt in den Kontrollfluss eingebunden und beeinflussen diesen auf vielfältige Weise. Hier in der UML dagegen erfolgt die Kontaktaufnahme zwischen Ereignis und Ablaufbeschreibung über Aktionen, die in den Kontrollfluss eingebunden sind (AcceptEventAction) und die auf das entsprechende Ereignis warten. Dieses Warten könnte auch als implizite Schleife, wie es die UML-Autoren an anderer Stelle gern tun, interpretiert werden. Ein wenig erinnert dies an die Konstruktion, wenn in Ereignisgesteuerten Prozessketten eine Funktion Warten eingebaut wird. Da bleibt dann der Prozess stehen, bis eines der angedachten Ergebnisereignisse eintritt. Dieser Unterschied im Umgang mit Ereignissen hat eine tiefere Ursache. Da in der UML Tätigkeit (Verhalten) nicht von den möglichen Ergebnissen getrennt wird ist nur auf die beschriebene Weise (durch eine Aktion die auf ein Ereignis wartet) die Einbindung externer Ereignisse möglich.

Immer aktiv

414

Klärung Programmstruktur

12 Aktivitäten

Letztendlich kann man diese Lösung, Ereignisse durch auf Ereignisse wartende Aktionen einzubinden, aber nur dann verstehen, wenn man akzeptiert, dass die UML durch ihre Hauptaufgabe, Systemanalyse und Vorbereitung der Programmierung geprägt ist. Denn für einen Programmierer ist eine solche Aktion ein direkter Hinweis auf ein Programmelement. Z.B. auf das, das beim Geldautomaten „Bereitschaft“ herstellt und das Karteneinzugserät samt Lesevorrichtung aktiv hält. Ereignisraum

Ereignisse speichern im event pool

Was der Verfasser als Ereignisraum bezeichnet, die Gesamtheit aller möglichen Ereignisse um einen Geschäftsprozess herum, kennen die UML-Autoren auch und bezeichnen es als event pool. Dieser ist einem Objekt zugeordnet und wird auch dafür verwendet, Ereignisse zu speichern (ihr Erscheinen festzuhalten), die nicht unmittelbar genutzt werden können. Später können sie dann berücksichtigt werden. Ein solcher Ereignisspeicher wird auch input event pool des Objektes genannt. 12.12.2 Das streaming-Konzept

Ständiger Fluss

Das oben besprochene streaming-Konzept durchbricht das einfache Schema „Aktion wird gestartet – läuft ab – ist beendet“. Der Zusatz {stream} an einem Pin erlaubt einer Aktion, Token anzunehmen, während die Aktion bereits ausgeführt wird. M.a.W. können dann z.B. Objekte jederzeit während der Ausführung einer Aktion ankommen, nicht nur am Anfang. Dies gilt immer, wenn ein Verhalten mit streaming-Parameter aufgerufen wird. Obige Regeln gelten somit für Input, der ankommt, nachdem ein Verhalten gestartet wurde und für Output, der verschickt wird, bevor das Verhalten endet. 12.12.3 Mehrfach aktiv? Hier geht es um die Frage, ob ein Verhalten, das bereits aktiv ist, nochmals gestartet werden kann oder nicht, ob also z.B. eine Aktion nochmals aufgerufen werden kann, obwohl sie bereits aktiv ist. Die UML-Autoren definieren wie folgt: x x

Kann ein Verhalten zu ein und demselben Zeitpunkt mehrfach aktiv sein, dann wird es reentrant genannt. Kann ein Verhalten zu einem Zeitpunkt nur einmal ausgeführt werden, dann wird es non-reentrant genannt.

Ein Aufruf eines Verhaltens vom Typ non-reentrant führt somit nicht zum Start des Verhaltens, wenn das Verhalten bereits ausgeführt wird. In diesem Fall versammeln sich die Tokens an den Input-Pins der aufrufen-

12.12 Kontrollfluss vertieft

415

den Aktion (invocation action), falls ihre obere Grenze122 größer als eins ist, oder woanders stromaufwärts (weiter vorn im Fluss). Der Aufruf eines Verhaltens vom Typ reentrant, das bereits aktiv ist, startet eine neue Ausführung mit neu angekommenen Token, auch wenn das Verhalten bereits mit Token des früheren Aufrufs ausgeführt wird. reentrant und streaming Ein Verhalten vom Typ reentrant kann keine streaming-Parameter haben, da dabei grundsätzlich mehrere Ausführungen des Verhaltens zur selben Zeit stattfinden und es schwer zu klären wäre, welche Ausführung die streaming-Token erhalten sollte. [OMG 2003a, S. 353] 12.12.4 Beziehungen zwischen Flüssen Mit flow relationships bezeichnen die UML-Autoren alle Einschränkungen der relativen Ausführungsreihenfolge von zwei oder mehr Aktionen. Falls sie nicht direkt oder indirekt durch solche Beziehungen geordnet sind, können sie gleichzeitig ausgeführt werden. Dies verlangt nicht Parallelausführung/-verarbeitung. Eine spezifische Komponente (execution engine) kann die Ausführungen optimieren, egal ob sequentiell oder parallel, so lange die expliziten Festlegungen der Ausführungsreihenfolge erfüllt werden. Vergleich UML / EPK – Kontrollfluss insgesamt Obige Ausführungen zeigen, dass hier der Kontrollfluss tatsächlich sehr detailliert beschrieben und durch zahlreiche Konzepte spezifiziert wird. Am auffälligsten ist das „aktiv bleiben“ von Aktionen über einen einfachen Durchgang hinaus. Die Möglichkeiten der Modellierung von Kontrollflüssen durch Aktivitäten sind damit insgesamt sehr ausgefeilt und gehen über das, was bei Geschäftsprozessen geleistet werden muss und kann, weit hinaus. Sie sind aber eine hervorragende Grundlage der Systemanalyse und der nachfolgenden Programmierung (von Systemen). 12.12.5 Token In Abschnitt 10.4.1 wurde das Token-Konzept grundsätzlich eingeführt, danach wurde es öfters bei anderen Theorieelementen thematisiert, jetzt kann es ergänzend beschrieben werden: x x

Es gibt Interaktionen zwischen ihnen. Tokens können Engpässe erreichen, auf andere Token warten, die vor ihnen sind und die weiter flussabwärts gehen sollen.

122 Die maximale Anzahl von Token, die in einem Knoten erlaubt sind. Objekte können nur dann in einen Knoten fließen, wenn die obere Grenze (Variable: upperBound) noch nicht erreicht ist.

416

x x x x Input-Token

Output-Token

Kontrolltoken

12 Aktivitäten

Token können sich gegenseitig vernichten mit den Schlussknoten AF und FF (ActivityFinal und FlowFinal). Token werden den Input-Pins von Aktionen angeboten. Token können von Aktionen verbraucht (consumed) werden. Es gibt auf einem Knoten Input-Token und Output-Token (vgl. unten).

Ein Knoten (node) in einem Aktivitätsdiagramm ist immer etwas dynamisches, da er ja aus einer “subordinate unit” oder gleich aus Aktivitäten besteht. Ihn zu aktivieren heißt Aktionen auszulösen. Er beginnt mit der Ausführung, wenn bestimmte Bedingungen auf seinen Input-Token erfüllt sind. Die möglichen Arten von Bedingungen hängen von der Art des Knotens ab. Wenn der Knoten mit der Ausführung beginnt, werden Token von seinen Input-Kanten (von einigen oder auch allen) akzeptiert und der Token ist dem Knoten zugeordnet. Wenn dann ein Knoten die Ausführung beendet, wird ein Token von dem Knoten entfernt und einigen oder allen seinen Output-Kanten werden Token angeboten. [OMG 2003a, S. 284] In Zusammenhang mit der Semantik von JoinNode findet sich folgende Beschreibung, die den Umgang mit Kontrolltoken klärt: “If all the tokens offered on the incoming edges are control tokens, then one control token is offered on the outgoing edge.” [OMG 2003a, S. 339]

Kontrolltoken und Startknoten

Token und Schlussknoten

Token und Kontrollknoten

Tokenflussregeln

Durchqueren einer Kante

In Bezug auf die Startknoten gilt: Wenn die Aktivität gestartet wird, wird dem Startknoten ein Kontrolltoken zugeordnet. Dieser wird dann allen abgehenden Kanten angeboten [OMG 2003a, S. 335] Hat eine Aktivität mehr als einen Startknoten, dann werden beim Start der Aktivität mehrere Flüsse gestartet, für jeden Startknoten einen, mit je einem Kontrolltoken. [OMG 2003a, S. 335] Ein Schlussknoten akzeptiert alle Token der ankommenden Kanten. Kommt ein Token bei einem Schlussknoten AF an, werden alle Kontrollflüsse in der zugehörigen Aktivität abgebrochen, d.h.: die Aktivität ist beendet und der Token ist zerstört. Token können bei Kontrollknoten (Entscheidungen, Verschmelzungen) nicht verweilen, um auf das Weitergehen im Kontrollfluss zu warten. Kontrollknoten dienen nur als Steuerelemente. Sie verwalten Token auf ihrem Weg zwischen Objektknoten und Aktionen. Dort, in Objektknoten und Aktionen, können die Token für eine bestimmte Zeit verweilen. Eine Ausnahme von dieser Regel sind die Startknoten . Knoten und Kanten haben Tokenflussregeln. Knoten kontrollieren, wenn Token reinkommen oder rausgehen. Kanten haben Regeln dafür, wann ein Token vom Quellknoten genommen und zum Zielknoten transportiert werden darf. Ein Token „durchquert“ eine Kante, wenn er die Regeln für Zielknoten, Kante und Quellknoten erfüllt. Das bedeutet, dass ein Quellknoten

12.13 Metamodellierung - Aktivitäten als Klassen

417

den weggehenden Kanten nur Token anbieten kann, er kann sie nicht der Kante aufzwingen, weil die Token von der Kante oder dem Zielknoten abgewiesen werden können. Zusammengefasst kann festgehalten werden, dass Token in der Tat Informationen darstellen, entweder zum Kontrollfluss, oder Objekte, oder Daten. Es sind wohl – vgl. den Anfang dieses Abschnitts – kleinste Informationseinheiten. Die UML-Autoren stellen sich den Kontrollfluss, bzw. die Flüsse von Kontrollinformationen, Objekten und Daten als „wandernde Token“ vor.

Wandernde Token

12.13 Metamodellierung - Aktivitäten als Klassen Aktivitäten sind im Rahmen der Metamodellierung auch Klassen. Nutzt man das entsprechende grafische Symbol, muss beim Namen der Aktivität zusätzlich <> angegeben werden, wie es die folgende Abbildung zeigt.

Abbildung 12.13-1:

Darstellung von Aktivitätsklassen. Quelle: [OMG 2003a, S. 289]

Die folgende Abbildung zeigt ein Beispiel einer Aktivitätsklasse. Es geht um die Aktivität Auftrag ausführen aus dem obigen Beispiel.

Abbildung 12.13-2:

Beispiel einer Aktivitätsklasse.

12.14 Beispiele Hier nun – zur Verdeutlichung und Vertiefung - einige einfache Beispiele zu den oben eingeführten Knoten.

Klasse Aktivitäten Aktivitätsklassen

418

12 Aktivitäten

12.14.1 Fehlerbehandlung Das erste Beispiel enthält folgende Elemente: x x x

Wächter

alle vier Kontrollknoten einen „Else-Ausgang“ einen Wächter

Außerdem wird hier ein Problem von oben geklärt, der „flussabwärts wartender Join“ (vgl. Abschnitt 3.4.4.3 / Tokenfluss). Doch zuerst zur Beschreibung. Stellen wir uns einen Hersteller von mechanischen Geräten vor, dem Geräte zur Reparatur eingeschickt werden. Die erste Aktion (ganz links) beschreibt den Vorgang, dass der Fehler dokumentiert wird. Danach wird mit Hilfe eines ForkNode zum einen die Reparatur veranlasst, zum anderen zu einer Entscheidung weitergeleitet, die klärt, ob es sich um einen Fall der Priorität 1 handelt oder nicht. Die Entscheidung wird mit einem DecisionNode modelliert. Die Bedingung für die Alternative ([priority=1]) wird als Wächter (guard) bezeichnet. Ist also die Priorität so hoch, wird die Bedeutung des Fehlers eingeschätzt (für Wartung, Produktion, usw.) und die Produktionsplanung (PP) überarbeitet. Im anderen Kontrollflusszweig wird das Gerät repariert und dann getestet. Auf der rechten Seite kommt zuerst ein MergeNode, der die beiden alternativen Zweige von [priority=1] und [else] zusammenführt. Dann ein JoinNode, der die beiden durch den ForkNode entstandenen Zweige zusammenführt. Über ihn geht es erst dann zur Freigabe des Geräts weiter, wenn beide Zweige angekommen sind. In der Sprache der UML-Autoren: Beide ankommenden Aktivitätskanten müssen einen Token anbieten. Hier kann man nun erkennen, was die UML-Autoren mit ihrem Flussabwärts wartenden Join meinen. Stellen wir uns vor, beim DecisionNode gäbe es den „Else-Zweig“ nicht. Dann würde, läge keine Priorität 1 vor, der obere Zweig niemals beim JoinNode ankommen und würde niemals überwunden. Deshalb empfehlen sie in einer solchen Konstellation die Einführung eines Else-Zweiges. [OMG 2003a, S. 296f]

Abbildung 12.14-1:

Aktivität Fehlerbehandlung Quelle: In Anlehnung an [OMG 2003a, S. 297, Figure 212]

12.14 Beispiele

419

12.14.2 Lagerentnahme Das nächste Beispiel enthält folgende Elemente: x x x x

einen ForkNode einen DecisionNode einen Schlussknoten FF (FlowFinal) einen decisionInput

Die erste Aktion links modelliert eine Lagerentnahme bzgl. einer Auftragsposition des zu bearbeitenden Auftrags. Der nachfolgende ForkNode stößt zum einen die Aktion Vorbereitung Lieferung, zum anderen eine Prüfung an, ob der Lagerbestand noch ausreichend ist (vgl. decisionInput). Die Prüfung wird durch einen DecisionNode modelliert und durch Angabe des decisionInput präzisiert. Es wird geprüft, ob nach der Lagerentnahme der Lagerbestand unter die Nachbestellmarke gefallen ist. Falls dies so ist, erfolgt eine Nachbestellung, falls nicht, endet dieser Zweig.

Abbildung 12.14-2:

Aktivität Auftragsbearbeitung Quelle: [OMG 2003a, S. 322, Figure 239] Übersetzung durch den Verfasser

Der Schlussknoten FF bedeutet, dass dieser eine Kontrollflusszweig, die Aktivitätskante mit dem Ergebnis [falsch] aus der Prüfung, ob der Lagerbestand unter die Nachbestellmarke gefallen ist, beendet wird. Dieser Schlussknoten ist nur nötig durch das Token-Konzept. In anderen Methoden zur Beschreibung von Tätigkeitsfolgen würde hier einfach der Prozess nicht fortgesetzt. 12.14.3 Personaleinstellung Das nächste Beispiel enthält folgende Elemente: x x x x x

einen JoinNode einen DataStore ein wiederholtes Zeit-Ereignis einen Schlussknoten FF ein „Auswahlverhalten“ auf einer Aktivitätskante

decisionInput

420

12 Aktivitäten

Die Aktion Einstellung Angestellte führt zu einem neuen Objekt in der Personaldatenbank. Die Aktion Zuweisung Arbeitsgebiet wird nur – dank des Auswahlverhalten – für die Angestellten aktiviert, denen kein Arbeitsgebiet zugeordnet ist. Einmal jährlich wird die wait time action aktiv. Mit ihr zusammen kann dann die Aktivitätskante von der Personaldatenbank die Aktion Beurteilung Angestellte anstoßen.

Abbildung 12.14-3:

Aktivität Aspekte des Personalwesens Quelle: [OMG 2003a, S. 319, Figure 236] Übersetzung durch den Verfasser

12.14.4 Auftragsbearbeitung

Start durch ein Objekt oder durch ein externes Ereignis

Vor- und Nachbedingungen

DecisionNode

Das folgende Beispiel wurde schon zu Beginn dieses Abschnittes benutzt, um das zu erreichende Ziel zu demonstrieren. Hier nun eine vertiefte Betrachtung. Beginnen wir mit dem Startszenario. Die Aktivität startet entweder durch ein Objekt oder einfach durch einen Startknoten, was bedeutet, dass ein Auftrag einging, der zu bearbeiten ist. Es liegt also ein externes Ereignis vor, das die Aktivität startet. Die Grenzlinie rund um die grafischen Elemente drückt die Zusammengehörigkeit der grafischen Elemente zu einer Aktivität aus. Die Vorbedingung (precondion) ist, dass die Bestellung / der Auftrag vollständig ist. Die Nachbedingung, dass die Bestellung / der Auftrag formal abgeschlossen wird. Doch nun zur eigentlichen Beschreibung der Tätigkeitsfolgen. Die erste Entscheidung wird gleich nach dem Eingang des Auftrags fällig: Wird der Auftrag angenommen oder abgelehnt?

Dieser Entscheidungsvorgang wird mit einem DecisionNode modelliert, von dem die alternativen Kanten wegführen. Falls der Auftrag angenommen wird, wird die Aktion Auftrag ausführen angestoßen. Falls er abge-

12.14 Beispiele

421

lehnt wird, geht es weiter zu einem JoinNode unmittelbar vor dem Schlussknoten. Dazu später mehr. Nach der Ausführung des Auftrags werden zwei Aktionen angestoßen, was durch einen ForkNode dargestellt wird. Zum einen erfolgt die Lieferung, zum anderen der Versand der Rechnung.

ForkNode

Anschließend folgt auf der rechten Seite der Abbildung ein Zusammenführen alternativer Kanten. Wenn entweder wie beschrieben der obige JoinNode erfüllt wurde oder wenn der Auftrag abgelehnt wurde, dann wird der Auftrag geschlossen und die Aktivität hat zu ihrem Ende gefunden, was durch den Schlussknoten für die gesamte Aktivität (Schlussknoten AF) dargestellt wird.

Bleibt noch der Objektknoten Rechnung zwischen den Aktionen Rechnung senden und Zahlung durchführen. Mit ihm wird, wie oben ausgeführt, in Aktivitäten ausgedrückt, dass ein Geschäftsobjekt direkt mit dem Fortgang verbunden ist. Genau diese Stelle ist aber etwas irritierend. Wie kann es sein, dass Rechnung senden und Zahlung durchführen so einfach nebeneinanderstehen? Normalerweise sind die Träger dieser zwei Aktionen sehr verschieden und – zumindest bei der gängigen Prozessanalyse – nicht unbedingt im selben Modell. Die Irritation rührt daher, dass in dieser Darstellung die Träger der Aktionen nicht angegeben sind, was ein wirkliches Defizit dieser Darstellung ist. Das war wohl auch der Grund, weshalb die UML-Autoren in Aktivitäten Notationen eingeführt haben, die die Träger angeben. Vgl. dazu Abschnitt 12.10, wo dies vorgestellt und an diesem Beispiel einer Auftragsabwicklung veranschaulicht wird.

Irritation

Defizit

422

12 Aktivitäten

Abbildung 12.14-4:

Aktivität Auftragsbearbeitung Quelle: [OMG 2003a, S. 290, Figure 203] Übersetzung durch den Verfasser

Dieser Geschäftsprozess kommt in mehreren Beispielen vor. Die Fundstellen sind im Stichwortverzeichnis („Aktivität Auftragsbearbeitung“) angegeben) 12.14.5 Design Part und Provide Required Part Das folgende Beispiel in zwei Abbildungen liefert einige aufschlussreiche Einblicke: x x

Zusammenwirkende Aktivitäten

Es zeigt, auf welche Weise Aktionen bestimmten Akteuren zugeordnet werden können. Es zeigt den Aufruf einer Aktivität aus einer anderen heraus.

Bei diesen Aktivitäten geht es darum, Standardteile bzw. –komponenten für den Bau des Flugzeuginneren zusammenzustellen. Dabei sind zwei Gruppen von Ingenieuren tätig, diejenigen, die für das Design verantwortlich sind (airplane designers, Design Engineer) und diejenigen, die die Teile- bzw. Komponentenbeschaffung realisieren (Standard Part Engineers oder kurz Standards Engineer). Doch nun zu den zwei Aktivitäten. Ihre Bezeichnungen sind Design Part und Provide Required Part : x x

Design Part beschreibt einige Arbeitsschritte beim Design von Teilen. Von dieser Aktivität wird die andere aufgerufen. Provide Required Part beschreibt einige Aspekte des Suchvorgangs, wenn bestimmte Teile angefordert werden und gesucht werden müssen.

12.14 Beispiele

423

In der Aktivität Design Part ist durch eine Linie in der Mitte der Abbildung die Zuordnung der Personen zu den Aktivitäten angegeben. Die Aktivitäten der oberen Hälfte werden vom Flugzeugdesigner realisiert, die der unteren Hälfte vom Standards Engineer. Der Flugzeugdesigner entdeckt bei seiner Arbeit den Bedarf für ein Standardteil (Teilebedarf). Nach dem Deutlichwerden des Bedarfs (ID Part Requirement) wird die Standardsuche angestoßen. Diese führt entweder dazu, dass das Teil gefunden wird oder nicht, was durch einen DecisionNode modelliert ist. Wird es gefunden, startet die Aktion Teil verwenden. Kann er das Teil nicht selbst finden, entsteht ein Suchprozess („search process instance“) bei den „standard part engineers“. Als Aktion, die eine Aktivität aufruft. Wird es nicht gefunden, wird die Aktion Provide Required Part angestoßen, die die gleichnamige Aktivität aufruft. Letzteres ist durch das Symbol rechts unten im Aktivitätssymbol angegeben. Diese Aktion wird vom Standards Engineer wahrgenommen. Nach der Rückkehr des Kontrollflusses aus der Aktivität Provide Required Part liegt dann entweder das Ergebnis [part provided] oder [else] vor. Falls ersteres vorliegt wird ebenfalls, wie aus dem Ablauf in der oberen Hälfte von Design Part, die Aktion Use Part ausgeführt. Auch in der Aktivität Provide Required Part werden den Aktionen Personen zugeordnet (Standards Engineer und Design Engineer). Diesmal durch eine senkrechte Linie und durch Beschriftung der jeweiligen Bereiche. Dies ist eine etwas andere Lösung als sie die UML-Autoren ansonsten vorschlagen (vgl. Abschnitt 12.10), aber auch umständlich. Die Expertenteilesuche (expert part seach behavior) führt zu einem gefundenen Teil oder nicht. Wird ein Teil nicht gefunden, wird es dem Assign Standards Engineer zugewiesen. Aktivität Provide Required Part – unterteilt in Aktionen des Standards Engineer und des Design Engineer Ist die Suche erfolgreich, wird die Aktivität gleich wieder beendet. War die Suche nicht erfolgreich, führt dies dazu, dass ein Standardteil verändert werden muss. Teil dieses Prozesses ist es, die Suchbedingungen zu prüfen. Es kann sein, dass der Flugzeugdesigner die Suche wegen der großen Anzahl von Teilen und Teilegruppen, nicht korrekt formuliert hat. Falls, mit der überprüften Suchanfrage, kein Teil gefunden wird, führt dies zu einer Reihe von Alternativen: entweder zur Veränderung eines vorhandenen Teils oder zur Erzeugung eines neuen Standardteils. Falls ein Teil verändert oder ein neues geschaffen werden muss, wird dafür eine Prozessinstanz gestartet. Dabei ist zu berücksichtigen, dass nicht jeder „standard part engineer“ mit jedem Standardteil arbeiten kann, weshalb ein bestimmter zugewiesen wird. Die Verfügbarkeit eines qualifizierten Ingenieurs für die Veränderung eines vorhandenen oder die Schaffung eines neuen Teils ist ein kritischer Punkt der Prozessinstanz.

Aktivität Design Part Zuordnung von Personen

Aufruf einer anderen Aktivität

Aktivität Provide Required Part

424

12 Aktivitäten

Planung Part Mod Workflow Diese Planungsinformation (schedule) wird dem Flugzeugdesigner zur Genehmigung zurückgegeben. Kann das neue Standardteil nicht rechtzeitig entwickelt werden, wird eine Alternative gewählt. Um Zeit zu sparen, können parallele Prozesse für unterschiedliche Fragestellungen gestartet werden.

Abbildung 12.14-5:

Aktivität Design Part Quelle: [OMG 2003a, S. 291, Figure 204]

Abbildung 12.14-6:

Aktivität Provide Required Part Quelle: [OMG 2003a, S. 291, Figure 204]

12.14.6 Problembehandlung Ein Problem taucht auf, es muss festgehalten werden (Problem aufzeichnen). Die Aufzeichnung muss hinsichtlich ihrer Genauigkeit überprüft werden. Von einem einzelnen Auftreten des Problems ausgehend wird der ursächliche Fehler identifiziert. Eine Lösung wird gefunden, das Ergebnis muss mit der Problemidentifikation zurückgemeldet werden.

12.14 Beispiele

425

Dieser Prozess enthält eine potentielle Schleife. Kann die Lösung nicht als erfolgreich akzeptiert werden (Lösung prüfen), geht das Problem zurück zu denen, die die Lösung suchen (Problem ID und Lösung).

Abbildung 12.14-7:

Aktivität Problembehandlung Quelle: [OMG 2003a, Figure 205, S. 292] Übersetzung durch den Verfasser

12.14.7 Auslagenerstattung Hier geht es um die Erstattung von Auslagen, die Beschäftigte eines Unternehmens für das Unternehmen getätigt haben. Z.B. Kauf eines Fachbuches, von Büromaterial oder von Software. So etwas fällt täglich mehrere Hundert Mal an. D.h. täglich werden mehrere Hundert Instanzen dieses Prozesses erzeugt. Folgende Regeln gelten für den Prozess: x x x x x x

Beträge unter 200 Euro werden automatisch genehmigt. Beträge gleich 200 Euro oder darüber benötigen die Genehmigung des Vorgesetzten. Die Erstattung geht auf das Konto des Angestellten. Im Falle einer Ablehnung erhält der Angestellte eine Begründung per E-Mail. Falls innerhalb von 7 Tagen nichts passiert, dann muss der Angestellte eine E-Mail zum Stand des Verfahrens erhalten. Falls die Anfrage nicht innerhalb von 38 Tagen erledigt ist, wird sie ungültig. Der Angestellte erhält eine entsprechende Nachricht und muss das Ganze nochmals vorlegen.

Das folgende Beispiel zeigt zwei Flüsse, die “um die Wette” fließen, eine Struktur vor der die UML-Autoren immer wieder warnen. Der erste, der den Schlussknoten AF erreicht, bricht die ganze Aktivität und damit den

Wettlaufsituation

426

12 Aktivitäten

anderen Fluss ab. Die beiden Flüsse sind in derselben Aktivität, so dass sie Daten gemeinsam nutzen können, z.B. zur Klärung der Frage, wer im Falle der Zurückweisung informiert werden muss.

Abbildung 12.14-8:

Zeitablaufkontrolle

Aktivität Auslagenerstattung Quelle: Leicht verändert nach [OMG 2003a, S. 300, Figure 216]

Was meinen die UML-Autoren, wenn sie hier von einer Wettlaufsituation sprechen? Nun, im oberen Teil läuft ganz normal der Genehmigungsprozess ab, in zwei alternativen Flüssen. Der untere Fluss aber stellt eine Art Zeitablaufkontrolle (time check path) dar. Das Verhältnis zwischen diesem und den beiden obigen veranschaulichen die UML-Autoren mit der Klausursituation. Entweder der Studierende wird vor Ablauf der Zeit fertig oder es läuft zuerst die Zeit ab. Beides beendet den Prozess der Klausurerstellung. Das Beispiel entstammt Workflow-Modellen, daher auch dieser Timer. In der klassischen Prozessmodellierung würde man eine andere Lösung finden. 12.14.8 Vorschlagswesen

Vorschläge wahrnehmen, ändern und prüfen

Im folgenden Beispiel geht es um Abläufe rund um ein Vorschlagswesen. Die Abläufe sind wie folgt: Die erste Aktion Vorschlag verändern wird entweder durch den Start der Aktivität aufgerufen oder aber durch eine Schleife. Dazu gleich mehr. Danach wird die Aktion Vorschlag prüfen ausgeführt. Mit dieser kommt es zu einem Entscheidungsvorgang. Der Vorschlag wird entweder zurückgewiesen, geändert oder angenommen. x

Im Falle der Annahme wird die Aktivität Vorschlag annehmen ausgeführt. Danach endet die Aktivität, modelliert durch einen Schlussknoten AF (ActivityFinal).

12.14 Beispiele

x x

427

Im Falle der Ablehnung wird diese bekanntgegeben. Auch hier endet dann die Aktivität, wiederum modelliert durch einen Schlussknoten AF (ActivityFinal). Wird beschlossen, den Vorschlag zu ändern, werden mit Hilfe eines ForkNode zwei Aktionen angestoßen. Zum einen die Benachrichtigung bzgl. des Änderungswunsches, zum anderen die Aktion Vorschlag verändern am Anfang der Aktion. Es kommt also zu einem Rücksprung. Dieser benötigt vor der ersten Aktion einen MergeNode.

Man vermisst in diesem Beispiel schon sehr schmerzhaft die Angabe der Träger der Aktivitäten. Dies würde die Aussagekraft sehr erhöhen. In diesem Beispiel existieren somit zwei Wege, um die Aktivität zu beenden. Die beiden Wege stehen aber in einem exklusiven Oder zueinander, so dass keine Wettlaufsituation entsteht wie oben.

Abbildung 12.14-9:

Aktivität Vorschlagswesen Quelle: In Anlehnung an [OMG 2003a, S. 300, Figure 217]

Die beiden Schlussknoten AF (ActivityFinal) hätten auch zusammengefasst werden können.

In Kapitel 13 (Sequenzen) verwendete Begriffe aus der UML (in der Reihenfolge des Auftretens): Deutsch

Englisch

Interaktion Sequenz Sequenzdiagrammen

interaction sequence sequence diagrams Interaction Overview Interaction Overview Diagrams Communications Communication Diagrams EventOccurrence trace interleaving lifeline ConnectableElement CallAction CallEvent SendAction SignalEvent CombinedFragments interactionOperator Operator: alternatives (alt) Operator: option (opt) Operator: break (break) Operator: parallel (par) Operator: weak sequencing (seq) Operator: strict sequencing (strict) Operator: negative (neg Operator: critical region (critical) Operator: ignore / consider (ignore) Operator: assertion (assert) Operator: loop (loop) Gates InteractionFragments ExecutionOccurence Constraints InteractionFragment Behavior valid traces invalid traces Basic trace model interaction trace model execution model InteractionConstraint InteractionOccurrence StateInvariant

Fragmente

Semantische Integritätsbedingungen

Zustandseinschränkung

13 Sequenzen, Sequenzdiagramme

13.1 Einführung Sequenzen als Interaktionen Für die UML-Autoren sind die in diesem Abschnitt vorgestellten Interaktionen (zu denen die Sequenzen gehören) partiell geordnete Ereignisfolgen (partially-ordered sequences of events). [OMG 2003a, S. 370] Die UML-Autoren fassen einige ihrer Konstrukte, zu denen die Sequenzen gehören, unter dem Begriff Interaktionen zusammen. Insgesamt gehören folgende dazu: x x x

Partiell geordnete Ereignisfolgen

Sequenzen (sequences) mit Sequenzdiagrammen (sequence diagrams) Sie stellen den Nachrichtenaustausch zwischen sog. Lifelines123 dar. Interaction Overview mit Interaction Overview Diagrams. Sie sind eine Variante der Aktivitätsdiagramme und geben einen Überblick über den Kontrollfluss. Communications mit Communication Diagrams, die die Wechselwirkungen zwischen den Partnern einer Interaktion zeigen, indem an den Kanten zwischen den Lifelines die Nachrichten und ihre Abfolge vermerkt werden.

Allen ist gemeinsam, dass sie dynamische Aspekte des untersuchten Anwendungsbereichs abdecken, genauer: Wechselwirkungen zwischen den Komponenten. Typischerweise decken alle diese Arten von Interaktionen nur Teilaspekte ab, nicht die Gesamtheit des (System-)Geschehens im jeweiligen Anwendungsbereich [OMG 2003a, S. 403]. Hier verwendete Begriffe Die UML-Autoren verwenden auch hier für Interaktionen und Sequenzen und deren Diagramme eine Vielzahl von Begriffen, die sie im Rahmen ihrer Metamodellierung jeweils als Klassen auffassen und auch so definieren (vgl. Abschnitt 14.3 in [OMG 2003]). Insgesamt sind es folgende Begriffe bzw Konzepte (in alphabetischer Reihenfolge):

123 Wörtlich: Rettungsleine, fig. Lebensader im Sinne von Versorgungsweg, was hier wohl am besten passt.

Dynamische Teilaspekte

430

x x x x x x x x x x x x x x x x x x

13 Sequenzen, Sequenzdiagramme

CombinedFragment Continuation EventOccurrence ExecutionOccurrence Gate GeneralOrdering Interaction InteractionConstraint InteractionFragment InteractionOccurrence InteractionOperand InteractionOperator Lifeline Message MessageEnd PartDecomposition StateInvariant Stop

Die Gewichtung ist sehr unterschiedlich. Einige stellen nur Benennungen dar, werden aber von den UML-Autoren trotzdem in ihre Metamodellierung eingefügt, andere sind wichtige Elemente bzw. umfassendere Ergänzungen des Basiskonzepts Interaktion bzw. Sequenz.

13.2 Grundstruktur

Aufbau von Sequenzdiagrammen

Nach Aussage der UML-Autoren gehören Sequenzen zu den am meisten betrachteten Interaktionen und damit Sequenzdiagramme zu den am meisten verbreiteten Interaktionsdiagrammen. Sie geben durch die sogenannten Lifelines einen Hinweis auf die statische Struktur des Anwendungsbereichs (bzw. auf dessen Abbildung in die Klassenhierarchie des gesamten Anwendungsbereichs) und durch den Nachrichtenaustausch zwischen diesen und weiteren Modellelementen einen Einblick in wichtige dynamische Aspekte. Der Aufbau der Sequenzdiagramme ist wie folgt (vgl. auch die folgende Abbildung): x x x

Ein Sequenzdiagramm besteht aus mehreren sog. Lifelines, die miteinander Nachrichten austauschen und damit Abläufe modellieren. Eine Lifeline besteht aus einem Rechteck an der Spitze, das das handelnde Objekt angibt und einer darunter angeordneten senkrechten gestrichelten Linie. Die Lifelines eines Sequenzdiagramms stehen i.d.R. in gleicher Höhe nebeneinander.

13.3 Einführendes Beispiel

x x x

x x

431

Die Lifeline, die die Interaktion startet, wird dabei i.d.R. ganz links angeordnet. Die gestrichelte Linie symbolisiert die Existenz eines Objekts während eines Zeitraums. Typischerweise für die gesamte Interaktion, dann über die gesamte Länge, sonst nur in Teilen. Eine Säule über der Lebenslinie gibt den Zeitraum an, in dem ein Objekt eine Aktion ausführt, entweder direkt oder durch ein nachgeordnetes Objekt. Diese Säule wird Kontrollfokus (focus of control) genannt. Zwischen diesen Säulen geben Pfeillinien die versendeten Nachrichten an. Diese sind, von oben nach unten, in zeitlicher Reihenfolge angeordnet. Zu einem Sequenzdiagramm gehört eine Umrahmung mit einer Bezeichnung links oben innerhalb des Rahmens mit dem Schlüsselwort sd.

Die vertikale Achse stellt somit eine Zeitachse dar, während in der horizontalen die Objekte angeordnet sind. Insgesamt modelliert ein Sequenzdiagramm einen Ablauf (eher einen kürzeren als einen längeren, wegen der Übersichtlichkeit, die bei längeren leicht verloren ginge) über den Nachrichtenaustausch zwischen Objekten. Die Nachrichten verweisen auf die bei den Objektklassen hinterlegten Methoden. Das Konzept ist damit im Herzen des objektorientierten Ansatzes angesiedelt, mehr als die oben besprochenen Aktivitäten. Denn das „Miteinander durch gegenseitigen Methodenaufruf“ ist von zentraler Bedeutung für die Aufgabenerledigung in der objektorientierten Theorie.

13.3 Einführendes Beispiel Das folgende einfache einführende Beispiel beschreibt sehr grob einen Bestellvorgang, z.B. im Kontext einer B2B-Lösung. Ein Kunde bestellt ein Produkt mit der Methode bestellenProdukt. Danach wird vom Lieferanten der Lagerbestand abgefragt und eine Reservierung vorgenommen. Anschließend wird eine Auftragsbestätigung verschickt.

Was wird modelliert?

Im Herzen des objektorientierten Ansatzes

432

13 Sequenzen, Sequenzdiagramme

Abbildung 13.3-1:

Ein Sequenzdiagramm (einfachste Form)

Soweit die Grundstruktur. Im folgenden wird diese nun schrittweise erweitert und vertieft.

13.4 Grundbegriffe EventOccurrences in Sequenzdiagrammen

Sendend und empfangend

Im vorigen Kapitel (Abschnitt 12.11) wurde schon kurz auf EventOccurrences eingegangen. Dort wird mit diesem Konstrukt die Beziehung zwischen Ereignissen und Aktionen hergestellt, indem die UML-Autoren definieren, dass EventOccurrences Zeitpunkte darstellen, denen Aktionen zugeordnet sind. EventOccurrences repräsentieren also den Zeitpunkt, in dem ein Ereignis eintritt. Ähnlich hier bei den Sequenzen. Hier sind sie inhaltlich verknüpft mit den Nachrichten, die bei den Sequenzen eine wichtige Rolle spielen und repräsentieren den Beginn bzw. das Ende der Nachricht. Das erste wird auch sendendes EventOccurrence genannt, das zweite empfangendes EventOccurrence. Die folgende Abbildung, ein Auszug des obigen einführenden Beispiels, erläutert dies grafisch. Das Element mit der Nummer (1) repräsentiert eine Nachricht. Am Startpunkt der Nachricht (Punkt (2)) und am Endpunkt (Punkt (3)) liegt jeweils ein EventOccurrence vor, ein sendendes bzw. ein empfangendes.

Abbildung 13.4-1:

EventOccurrences in Sequenzdiagrammen Anmerkung: Die Nummern gehören nicht zur UML.

13.4 Grundbegriffe

433

Zu den Eigenschaften von EventOccurrences gehört der Zeitpunkt, zu dem sie eintreten. Eine Sequenz kann damit auch so gesehen werden, dass sie aus einer oder mehreren Folgen von EventOccurrences besteht. Dies wird nun von den UML-Autoren für ein weiteres Element in ihrem Theoriegebäude benutzt, den Traces (fig: Spuren). Als einen Trace bezeichnen sie eine Folge von EventOccurrences, natürlich zusammenhängenden, die damit einen Ablauf beschreiben. Ein Trace kann dann durch einen Ausdruck wie <eventoccurrence1, eventoccurrence2, ..., eventoccurrence-n> dargestellt werden [OMG 2003a, S. 403]. Genau diese Traces bezeichnen die UML-Autoren als Semantik der Modellelemente, die durch die Traces beschrieben werden. Dies ist auf den ersten Blick eine gewagte Reduktion dessen, was üblicherweise unter Semantik verstanden wird. Auf den zweiten Blick ist es aber konsequent. Da es ja um die Beschreibung von Abläufen geht, sind Folgen von „Ereignissen“ eine sinnvolle Technik zur Beschreibung und dies kann durchaus auch als (wenngleich inhaltlich arme) Semantik verstanden werden. Es geht noch weiter. Hat man schon mal Semantik über Folgen von Ereignissen definiert, muss man auch darüber nachdenken, solche Folgen zusammenzubringen (oder auch zu trennen), auf die eine oder andere Weise. Es geht dann ja darum, die "Semantik“ der verschiedenen Elemente zu verschmelzen. Dafür haben die UML-Autoren ein Konzept eingeführt, dass sie interleaving nennen124. Sie bezeichnen damit das Verschmelzen/Verschachteln mehrerer traces dergestalt, dass die Ereignisse verschiedener traces im neuen trace in beliebiger Reihenfolge kommen, während die Ereignisse innerhalb desselben trace ihre Reihenfolge behalten [OMG 2003a, S. 403]. Dies ist tatsächlich sinnvoll. Stellen wir uns zwei Abläufe vor, die auf diese Weise zusammengeführt werden. Jeder einzelne Ablauf behält seine Struktur (seine Abfolge von EventOccurrences), bezüglich des entstehenden neuen Trace ist aber nicht festgelegt, wie die EventOccurrences der Ausgangs-Traces zueinander stehen. Der neue Trace „leistet“ also alle Abläufe der ursprünglichen, das Verhältnis zueinander bleibt aber offen. Soweit einige Grundbegriffe, die von zentraler Bedeutung sind für Interaktionen und die deshalb hier vorab betrachtet wurden. Im folgenden nun die Vorstellung der Komponenten von Sequenzdiagrammen im Detail.

124 to interleave: verschachteln. In der Datenverarbeitung auch für Techniken benutzt, mit denen Bild und Ton in einer Datei zusammengebracht werden können (AVI = Audio video interleave).

Traces

Von EventOccurrences über Traces zur Semantik

„SemantikVerschmelzung“

interleaving

434

13 Sequenzen, Sequenzdiagramme

13.5 Lifelines Die statischen Aspekte einer Sequenz, sozusagen das Grundgerüst, wird durch die Lifelines angegeben. Eine Lifeline repräsentiert einen einzelnen Teilnehmer an der Interaktion.

Abbildung 13.5-1:

Verknüpfbare Elemente

Reihenfolge, nicht Distanz

Schlüsselwort self

Methodenaufrufe

Grafische Darstellung einer Lifeline

Normalerweise besteht der Kopf der Lifeline, so wie hier gezeigt, aus einem Rechteck, das den Namen des Classifiers enthält, den die Lifeline repräsentiert. Die Lifeline selbst repräsentiert genau ein ConnectableElement, diesem können aber mehrere Lifelines zugeordnet sein (vgl. zur Metamodellierung [OMG 2003a, S. 406, Figure 327]). Wesentlich ist nun, dass die ConnectableElements mittels Nachrichten Informationen austauschen können, um gemeinsam eine Aufgabe, einen Ablauf zu realisieren. Falls das durch die Lifeline repräsentierte ConnectableElement mehrwertig ist (d.h., eine Multiplizität größer 1 hat), dann kann die Lifeline einen Ausdruck haben (den „Selector“), der festlegt, welcher spezifische Bereich durch die Lifeline repräsentiert wird. Wird der Selector weggelassen, bedeutet dies, dass ein beliebiger Repräsentant des mehrwertigen ConnectableElement gewählt wird [OMG 2003a, S. 427]. Die Reihenfolge der EventOccurrences entlang einer Lifeline gibt die zeitliche Abfolge an, in der diese Ereignisse eintreten. Die absolute Distanz ist aber ohne Bedeutung, d.h. es gibt keine Zeitmetrik. Erfasst wird also nur das zeitliche Hintereinanderabfolgen, nicht mehr. Ist die Bezeichnung der Lifeline das Schlüsselwort self, dann repräsentiert die Lifeline das Objekt des Classifiers, das die Interaktion umfasst, zu der die Lifeline gehört [OMG 2003a, S 428]. Übersandte Nachrichten führen oft zum Aufruf einer Methode bei der angezielten Lifeline. Um Methodenaufrufe zu veranschaulichen wird ein dünnes graues oder weisses Rechteck gewählt, das die gestrichelte Linie der Lifeline bedeckt, so lange die Methode aktiv ist.

13.6 Nachrichten zwischen Lifelines In Interaktionen, zu denen die Sequenzdiagramme ja gehören, ist eine Nachricht eine Kommunikation zwischen den Lifelines einer Interaktion. Dies kann sein:

13.6 Nachrichten zwischen Lifelines

x x x

435

Senden und Empfangen eines Signals Aufruf einer Operation Erzeugung oder Zerstörung einer Instanz

Die Nachricht legt nicht nur die Art der Kommunikation fest, festgelegt durch das sendende ExecutionOccurrence125, sondern auch den Sender und den Empfänger. Wie oben schon angemerkt, gehören zu einer Nachricht üblicherweise zwei EventOccurrences, ein sendendes und ein empfangendes. Falls eine Nachricht eine Operation darstellt, sind die Argumente der Nachricht die Argumente der CallAction126 der sendenden Lifeline und die des CallEvent127 auf der empfangenden Lifeline. Stellt eine Nachricht ein Signal dar, sind die Argumente der Nachricht die der SendAction auf der sendenden Lifeline und auf der empfangenden Lifeline sind die Argumente im SignalEvent verfügbar. Falls die Nachricht eine CallAction darstellt, gibt es normalerweise eine Rückantwort (return message) von der gerufenen Lifeline zurück zur rufenden bevor die rufende Lifeline voranschreitet. Grafische Darstellung Eine Nachricht wird als Linie vom Ende der Sendernachricht zum Ende der Empfängernachricht gezeichnet. Die Gestaltung der Linie und der Pfeilspitze gibt Eigenschaften der Nachricht an: x x x x x

Asynchrone Nachrichten haben eine Pfeilspitze ohne Füllung. Synchrone Nachrichten stellen typischerweise Methodenaufrufe dar und werden mit einem gefüllten Pfeilkopf dargestellt. Die Antwortnachricht einer Methode hat eine gestrichelte Linie. Eine Nachricht zur Objekterzeugung hat eine gestrichelte Linie mit einem nicht gefüllten Pfeilkopf. Verlorene Nachrichten werden durch einen kleinen schwarzen Kreis am Pfeilende gekennzeichnet. Gefundene Nachrichten werden durch einen kleinen schwarzen Kreis am Startpunkt der Nachricht gekennzeichnet.

Beispiele Im folgenden Beispiel geht es um Nutzer eines Systems, die sich bei einem Kontrollsystem mittels einer PIN (Personal Identification Number) identifizieren müssen. Entweder ergibt diese Prüfung ein positives Ergebnis oder nicht. 125 Eine ExecutionOccurrence ist eine Instantiierung einer Verhaltenseinheit in der Lifeline. 126 Eine CallAction ist eine abstrakte Klasse für Aktionen, die Verhalten aufrufen und Rückgabewerte entgegennehmen. 127 CallEvent als Klasse ist ersetzt durch CallTrigger, wird aber im Text trotzdem noch benutzt.

Operation als Nachricht Signal als Nachricht

CallAction als Nachricht

436

Sich überholende Nachrichten

Gate: Tor zur Außenwelt

13 Sequenzen, Sequenzdiagramme

Dafür werden zwei Lifelines (und) und drei Nachrichten benötigt. Die Lifelines sind Nutzer und Zugangskontrolle. Alle Nachrichten sind asynchron. Bei diesen kann es passieren, dass eine Nachricht eine andere überholt. Auch dies zeigt das folgende Beispiel. Die Nachricht CardOut überholt die Nachricht OK. Dadurch sind die empfangenden EventOccurrences in umgekehrter Reihenfolge gegenüber den sendenden. Eine vierte Nachricht (aufschließen) wird von der Zugangskontrolle an die Umwelt geschickt. Eine solche Stelle über die der Kontakt zur Außenwelt (der Sequenz) realisiert wird, trägt die Bezeichnung Gate. Das lokale Attribut PIN von UserAccepted wird im oberen Bereich der Abbildung angegeben.

Abbildung 13.6-1:

Sequenzdiagramm Zugangskontrolle Quelle: [OMG 2003a, S. 421, Figure 337] Übersetzung durch den Verfasser

13.7 Strukturieren durch CombinedFragments

Gruppen von Nachrichten bilden und in Beziehung setzen

Der oben eingeführten Standardnotation von Sequenzdiagrammen fehlt eine wichtige Eigenschaft. Mit ihr ist es nicht möglich, den Nachrichtenverkehr zu strukturieren, um zum Beispiel aufgrund eines Ereignisses den einen oder den anderen Nachrichtenverkehr zu wählen. M.a.W.: es ist nicht möglich zu verzweigen. Dies haben wohl auch die UML-Autoren bemerkt, und deshalb bei Sequenzdiagrammen ein entsprechendes Theorieelement eingefügt, die CombinedFragments (hier im weiteren: Fragmente). Sie erlauben die Einbeziehung verschiedener Fragmente zum Nachrichtenverkehr (d.h. Gruppen von Nachrichten) und die Anwahl des einen oder anderen. Dafür sind die folgenden Operatoren definiert, die interactionOperator genannt werden (hier im weiteren Operatoren). In Klammern ist noch jeweils die

13.7 Strukturieren durch CombinedFragments

437

Kurzbezeichnung angegeben, die in den grafischen Notationen verwendet wird: x x x x x x x x x x x

alternatives (alt) option (opt) break (break) parallel (par) weak sequencing (seq) strict sequencing (strict) negative (neg) critical region (critical) ignore / consider (ignore) assertion (assert) loop (loop)

Grafische Darstellung Die grafische Darstellung dieser Fragmente ist wie in der folgenden Abbildung angegeben. Der gesamte Bereich unterhalb der Kopfelemente der Lifelines wird mithilfe eines Rechtecks umrandet. Dieses wird mit einer horizontalen gestrichelten Linie unterteilt (oder mit mehreren), womit die kombinierbaren Fragmente entstehen, und ein Operator im linken oberen Eck des Rechtecks (in einem Fünfeck) gibt die Art der Verknüpfung an. Jeder durch die Unterteilung geschaffene Bereich stellt dann einen Operanden des jeweiligen Operators dar. Liegt mehr als ein Operator vor, wird er ebenfalls bei der Beschriftung im Fünfeck links oben angegeben. Dies ist dann eine Kurzfassung für das Verschachteln von Fragmenten. Ein Eintrag von sd strict ist dann gleichbedeutend mit zwei verschachtelten Fragmenten, das äußere mit sd und das innere mit strict. Im folgenden Beispiel liegt aber ein ganz normaler Operator vor, alt für “alternatives”, d.h. für Alternativen (zur Erläuterung der Operatoren vgl. unten).

Ein Operator und seine Operanden

Mehr als ein Operator

438

13 Sequenzen, Sequenzdiagramme

Abbildung 13.7-1:

Unhandlich

Realisierung von CombinedFragments Grundstruktur

Als Operator kann einer der oben aufgelisteten dienen, mit durchaus sehr unterschiedlicher Bedeutung. Vgl. unten. Während das Konzept – strukturierte Sequenzdiagramme – sehr sinnvoll, ja sogar notwendig anmutet, ist die grafische Realisierung unhandlich. Wie soll dies bei komplexeren Abläufen funktionieren? Dass es aber zumindest bei überschaubaren Problemstellungen funktioniert, zeigen die weiteren Ausführungen und Beispiele. Im nächsten Abschnitt werden nun die oben aufgelisteten Operatoren für die CombinedFragments erläutert. Alternatives

Else-Verzweigung

Der Operator alternatives (alt) legt fest, dass das Fragment erlaubt, Verhaltensalternativen zu modellieren. Höchstens einer der Operanden wird also ausgeführt. Der Operand, der zur Ausführung kommt, muss einen Wächter haben, der an dieser Stelle der Interaktion wahr sein muss. Wie bei solchen Verzweigungen (um die handelt es sich eigentlich, wenn man vom modellierten Ablauf ausgeht) üblich, gibt es sehr oft eine Verzweigung die greift, wenn alle anderen scheitern (else). In der Sprache der UML-Autoren: „An operand guarded by else designates a guard that is the negation of the disjunction of all other guards in the enclosing CombinedFragment”. [OMG 2003a, S. 410] Option (einstellig) Der Operator option (opt) ist einstellig und legt folgende Wahlmöglichkeit fest: Entweder der einzige Operand kommt zur Ausführung oder nichts geschieht.

13.7 Strukturieren durch CombinedFragments

439

Break Das mit dem Operator break bezeichnete Fragment wird im Bedarfsfalle an Stelle des gesamten Restes des Fragments aufgerufen. Es erlaubt den Abbruch des Fragments an dieser Stelle. Damit ist der Break-Operator eine Kurzfassung für einen AlternativeOperator, bei dem ein Operand gegeben ist und wo angenommen wird, dass der andere den gesamten Rest des Fragments darstellt. Parallel merge Der Operator par legt fest, dass das Fragment eine „parallele“ Verschmelzung (parallel merge) zwischen zwei Verhaltenskomponenten der Operanden darstellt. Die EventOccurrences der Operanden können auf beliebige Weise verschachtelt werden, solange die Reihenfolge, die durch jeden Operanden festgelegt ist, erhalten bleibt. Weak Sequencing Der Operator seq legt fest, dass das Fragment die beiden Operanden auf eine bestimmte Art und Weise, dem sog. weak sequencing, verbindet. Folgende Eigenschaften gelten für dieses weak sequencing: x x x

Die Abfolge der EventOccurrences in jedem der Operanden wird im Ergebnis beibehalten. EventOccurrences auf verschiedenen Lifelines von verschiedenen Operanden können in beliebiger Reihenfolge sein. EventOccurrences auf derselben Lifeline von verschiedenen Operanden sind so sortiert, dass ein EventOccurrence des ersten Operanden vor dem des zweiten Operanden kommt.

Es handelt sich also um eine einfach sequentielle Abfolge, die auf einer Lifeline die Einhaltung der Reihenfolge erzwingt, die zwischen Elementen verschiedener Lifelines aber offen lässt. Damit wird weak sequencing zu einem parallel merge, falls die Operanden auf elementfremden (sich nicht überschneidenden) Elementen aufbauen. Es fällt auf strict sequencing (vgl. unten) zurück, falls die Operanden nur auf einer einzelnen Menge von Elementen arbeiten. Strict Sequencing Der Operator strict sequencing (strict) legt fest, dass bei einer Zusammenführung mehrerer Traces jedes EventOccurrence seine Position auf der Lifeline behält gegenüber den anderen. Alle beteiligten Lifelines werden zusammen betrachtet. Damit hat jedes EventOccurrence und jede Nachricht eine bestimmte Position, die beibehalten wird. Die senkrechte Dimension (die Zeitachse) behält also ihre Gültigkeit über das ganze CombinedFragment hinweg und nicht nur für die einzelne Lifeline.

440

13 Sequenzen, Sequenzdiagramme

Negative (einstellig) Der Operator neg legt fest, dass das Fragment traces repräsentiert, die als ungültig deklariert sind. Critical Region Der Operator critical region (critical) kennzeichnet ein einzelnes Fragment und legt fest, dass in diesem die Traces nicht verschachtelt sein dürfen. Beispiel Das folgende Beispiel veranschaulicht dies am Beispiel von Notrufen. Ein 911-call muss (in den USA) unmittelbar weitergegeben werden, vor allen anderen Anrufen. Die übrigen Anrufe können dagegen beliebig verschachtelt sein.

Abbildung 13.7-2:

Realisierung von CombinedFragments Grundstruktur

Ignore / Consider Der Operator ignore / consider legt fest, dass es Nachrichten gibt, die im jeweiligen Fragment nicht gezeigt werden. Umgekehrt legt consider fest, welche Nachrichten im jeweiligen Fragment beachtet werden sollen. Damit erhalten alle anderen Nachrichten im Fragment den Status „ignorieren“. Für ein Beispiel und die grafische Darstellung vgl. Abbildung 13.16-2.

13.8 Gates und InteractionFragments

441

Assertion Der Operator assertion (assert) legt fest, dass der im Fragment angegebene Nachrichtenverkehr auf jeden Fall stattfindet. Assertions sind oft kombiniert mit Ignore / Consider. Für ein Beispiel und die grafische Darstellung vgl. Abbildung 13.16-2. Loop (einstellig) Der Operator loop legt fest, dass das Fragment eine Schleife repräsentiert. Der Schleifenoperand wird mehrfach wiederholt. Der Wächter (guard) kann sowohl eine untere und obere Grenze für die Wiederholungen enthalten als auch einen Booleschen Ausdruck. Das loop-Konstrukt repräsentiert eine rekursive Anwendung des seqOperators, wo die Ergebnisse der einzelnen Schritte (der Iterationen) des loop-Operanden in eine sequentielle Abfolge gebracht werden. Darstellung Die Darstellung ist hier textlich. Die Syntax des loop-Operanden ist wie folgt: loop [ ‘(‘ <minint> [, <maxint> ] ‘)’ ] <minint> ::= natürliche Zahl, d.h. positive ganze Zahl <maxint> ::= natürliche Zahl größer oder gleich <minint> | ‘*’

13.8 Gates und InteractionFragments InteractionFragment Ein InteractionFragment ist einfach Teil einer Interaktion. Es kann also Teil einer Sequenz oder einer anderen Interaktion sein und wird konzeptionell wie eine solche behandelt. Es ist eine abstrakte Klasse, eine Spezialisierung von NamedElement (vgl. [OMG 2003a]) und hat selbst als Spezialisierungen die Fragmente der verschiedenen Interaktionen. Die Semantik eines InteractionFragments ist schlicht ein Paar von Trace-Mengen.

Metamodellierung

Grafische Darstellung Es gibt dafür keine grafische Darstellung. Erst die Spezialisierungen (z.B. die Fragmente einer Sequenz) sind so konkret, dass sie auch grafisch dargestellt werden. Gate Dieses Modellelement spielte schon bei den Aktivitäten eine Rolle (vgl. Kapitel 12). Genau wie dort ist ein Gate eine Verknüpfungsstelle, an der

Festlegung Nachrichtenverkehr

442

Bezeichnung

13 Sequenzen, Sequenzdiagramme

eine Nachricht von außerhalb eines InteractionFragment mit einer Nachricht innerhalb in Beziehung gebracht wird. Gates werden durch Nachrichten verknüpft. Somit repräsentiert ein Gate ein EventOccurrence, das nicht im selben Fragment ist wie das Gate. Die Gates sind entweder explizit oder implizit benannt. Sie werden durch einen Namen identifiziert (falls festgelegt) oder durch einen konstruierten Bezeichner, der durch Aneinanderhängen der Richtung der Nachricht und dem Nachrichtennamen (z.B. out_CardOut) gebildet wird. Aufgabe der Gates und der Nachrichten zwischen diesen ist es, für jede Nachricht den konkreten Sender und Empfänger klarzustellen. Darstellung Gates sind Punkte auf dem Rahmen des Sequenzdiagramms, die Endpunkte der Nachrichten. Ihnen kann eine Bezeichnung zugewiesen werden. Dasselbe Gate kann mehrfach vorkommen, in derselben Abbildung oder in verschiedenen. In der folgenden Abbildung ist an der Position (1) das Gate, hervorgerufen durch eine Nachricht, die durch ein EventOccurrences an Punkt (2) ausgelöst wird.

Abbildung 13.8-1:

Gates in Sequenzdiagrammen

13.9 ExecutionOccurence Existieren und aktiv sein

Die gestrichelte Linie unterhalt des Rechtecks bei der grafischen Darstellung einer Lifeline repräsentiert die Dauer der Existenz des Objektes in der jeweiligen Interaktion. Zusätzlich wird in dieser Darstellung auch noch festgehalten, wie lange ein Verhalten des Objekts aktiv ist, d.h., wann es aktiviert wird und wann es endet. Dieses „Aktivsein“ des Verhaltens nennen die UML-Autoren ExecutionOccurrence. In ihrer Sprache handelt es sich um die „… instantiation of a unit of behavior within the Lifeline.“ [OMG 2003a, S. 417].

13.10 Interaktionen

443

Da eine ExecutionOccurrence eine Zeit lang andauert, wird sie durch zwei EventOccurrences repräsentiert: Das zu Beginn und das am Ende (Start-EventOccurrence und Schluss-EventOccurrence). Typischerweise werden sich der Start-EventOccurrence und der Schluss-EventOccurrence auf Ereignisse beziehen wie einen receiveEventOccurrence (einer Nachricht) und den send-EventOccurrence einer Rücknachricht. Grafische Darstellung ExecutionOccurrences werden als dünne Rechtecke in grau oder weiss auf der Lifeline dargestellt. Vgl. Position (1) in der folgenden Abbildung. Dort sind auch die zwei EventOccurrences markiert (Die fett und kursiv gesetzten Elemente sind einschließlich Pfeil nicht Teil der UML-Notation).

Abbildung 13.9-1:

Ein ExecutionOccurrence und seine EventOccurrences

13.10 Interaktionen Zu Beginn dieses Kapitels wurden Interaktionen schon als abstrakte Klasse eingeführt, deren eine Subklasse Sequenzen in diesem Kapitel betrachtet wird. Inzwischen sind so viele Begriffe eingeführt, dass das abstrakte Konzept der Interaktionen vorgestellt werden kann. Zusätzlich wird an diesem Beispiel auch die Metamodellierung der UML-Autoren dargestellt.

Das abstrakte Konzept

Metamodellierung der UML Es geht hier also auch darum zu zeigen, was es mit der Metamodellierung der UML-Autoren (und anderer) auf sich hat. Das Grundproinzip ist folgendes: Man benutzt die objektorientierte Theorie (genauer: Teile davon), um die Theorie selbst zu erklären. Das wirkt auf den ersten Blick verwirrend. Wäre es zum Beispiel möglich mit der „Methode EPK“ diese selbst zu erläutern? Natürlich nicht. Doch bei der objektorientierten Theorie liegt die Sache anders. Hier liegen zum Teil Konzepte vor, die sich ganz allgemein für die Strukturierung und Darstellung von Wissen eignen (genauer: für einige einfache Merkmale von Wissen).

Die objektorientierte Theorie definiert die objektorientierte Theorie

Strukturierung von Wissen

444

Generalisierung / Spezialisierung

Assoziationen

Einschränkungen durch Constraints

13 Sequenzen, Sequenzdiagramme

Ein solches Konzept ist die Generalisierung/Spezialisierung. Mit ihr können Theorieelemente in eine Beziehung gebracht werden, die mit „ist_ein“ umschrieben werden kann: „Ein Hund ist ein Säugetier“, „Eine Sequenz ist eine Interaktion“. Da solche Strukturen in der objektorientierten Theorie vorliegen, kann dieser Aspekt schon mal erfasst werden. Das zweite Konzept, das sich für die Aufgabe der Metamodellierung eignet, ist das der Assoziation. Sie erfasst Beziehungen zwischen Theorieelementen, hier z.B. Zugehörigkeit, ausgedrückt durch „gehört dazu“, „ist Teil von“. Das dritte verwendete Konzept, die Constraints (auch: Semantische Integritätsbedingungen), spiegelt allgemein gesprochen, Einschränkungen auf formulierte Sachverhalte wider. Auch dies ist ein universelles Merkmal, das bei jeder Theorieformulierung gebraucht werden kann. Im folgenden nun die Metamodellierung der UML-Autoren am Beispiel der Interaktionen (vgl. Abschnitt 14.3.7 von [OMG 2003a]). Um das Vorgehen der UML-Autoren deutlich zu machen, hält sich die Beschreibung in diesem Abschnitt im folgenden genau an die Reihenfolge der Quelle. Beispiel Interaktionen

Die Definition

Die UML-Autoren beginnen mit einer Definition: Eine Interaktion ist eine Verhaltenskomponente (unit of behavior) die den beobachtbaren Austausch von Informationen zwischen ConnectableElements beschreibt. Übersetzungsfragen Es wurde schon mehrfach angesprochen. Wenn es um die dynamischen Aspekte des Anwendungsbereichs geht, um die den Klassen zur Verfügung stehenden Methoden, sprechen die UML-Autoren immer von behavior, dem Verhalten der zugrundeliegenden Objekte. Und dies sehr konsequent und auch hier: Es sind units of behavior, die durch eine Interaktion modelliert werden. Was gemeint ist, ist klar. Es geht um Verhalten und damit um die hinter dem Verhalten stehenden Methoden. Nicht nur um eines, auch nicht um das eines einzelnen Objekts, sondern um mehrere (im doppelten Sinn). Es geht um das Zusammenspiel von Verhalten zur Erreichung eines Zieles. Das Problem liegt darin, dass wir im Deutschen den Begriff Verhalten als etwas aktives sehen und deshalb an dieser Stelle eher von den Methoden ausgehen, die Klassen eher passiv sehen und von „zur Verfügung stehenden Methoden“ sprechen. Um diesem Gesichtspunkt gerecht zu werden, wird hier die Übersetzung Verhaltenseinheiten für units of behavior gewählt, auch wenn dies im Deutschen holpriger klingt als im Englischen.

13.10 Interaktionen

445

Mit obiger Definition ist ein weiterer Begriff eingeführt, ConnectableElement. Er wurde oben schon kurz benötigt. Auch dies ist ein Theorieelement, ein Konzept aus der Metamodellierung der UML. Im UML-Text folgt dann die Generalisierung/Spezialisierung. Diese eignet sich tatsächlich auch hervorragend für die Beschreibung bestimmter Aspekte einer Theorie, für den Zusammenhang zwischen den verschiedenen Konstrukten. In der Tat sind in der UML diese alle in eine Generalisierungs-/Spezialisierungshierarchie eingebettet. Hier gilt zum Beispiel:

Dann die Generalisierung/Spezialisierung …

Eine Interaktion ist eine Spezialisierung von InteractionFragment und von Behavior. Dass eine Interaktion auch selbst Spezialisierungen hat, wurde oben schon ausgeführt. Danach nutzen die UML-Autoren ein weiteres Konzept des objektorientierten Ansatzes, die Assoziationen. Durch dieses können alle Theorieelemente miteinbezogen werden, die mit dem Ausgangselement in Beziehung stehen. Für die Interaktionen definieren sie Assoziationen zu: x x x x x

… und die Assoziationen

Gates (formalGate: Gate[*]) Lifelines (lifeline: LifeLine[0..*]) Ereignissen (event:MessageEnd[*]) Nachrichten (message:Message[*]) Fragmenten (fragment:InteractionFragment[*])

Alle diese Assoziationen haben bei genauem Hinsehen die Bedeutung von „ist enthalten in“ bzw. „ist Teil von“. Gates Bezieht sich auf die Gates der Interaktion, die ja das “Nachrichteninterface” zwischen der jeweiligen Interaktion und den InteractionOccurrence von außerhalb, die sich darauf beziehen, darstellen (vgl. oben). Lifelines Mit dieser Assoziation wird eine Beziehung zu den Teilnehmern der Interaktion hergestellt, denn genau diese stellen die Lifelines dar. Ereignisse Damit wird die Beziehung zu EventOccurrences oder Gates der Interaktion hergestellt. Nachrichten Diese Assoziation bindet die Nachrichten der jeweiligen Interaktion mit ein.

Gates

446

13 Sequenzen, Sequenzdiagramme

Fragmente Zum Schluss noch die Assoziation, die die geordnete Menge der Fragmente der Interaktion in Beziehung zur Interaktion selbst setzt. Soweit also die Assoziationen. Wie zu sehen ist, wird hier damit Zugehörigkeit ausgedrückt, Zugehörigkeit des einen Modellelements zum anderen. Metamodellierung Bei den Assoziationen wird die Art der Beziehung jeweils im formalen Teil angegeben. Hier am Beispiel der InteractionOccurrence: x x x Auch die Semantik darf nicht fehlen

refersTo: Interaction[1]. Stellt die Beziehung zu der Interaktion her, zu der die InteractionOccurrence gehört. argument:InputPin[*]. Legt fest, dass zu der InteractionOccurrence Input-Pins gehören. actualGate:Gate[*]. Die aktuellen Gates.

Nachdem sie nun oben mit den zwei Konzepten der objektorientierten Theorie (Generalisierung/Spezialisierung und Assoziationen) Ordnung in ihre Begriffswelt gebracht haben bzw. die Konzepte, Konstrukte, usw. in Beziehung gesetzt haben, beschreiben die UML-Autoren dann das, was sie Semantik (des Konstrukts, usw.) nennen, hier also Semantik von Interaktionen. Dabei kommt wieder behavior ins Spiel, wenn sie die Definition wiederholen, dass Interactions „units of behavior“ sind (vgl. oben). Anschließend wird das Umfeld geklärt: Interaktionen sind Verhaltenseinheiten eines sie umschließenden Classifier. Der Begriff Classifier ist ebenfalls in der Metamodellierung geklärt (vgl. Abschnitt 10.4.2). Danach folgt die Präzisierung dessen, was die Interaktionen eigentlich leisten: Interaktionen konzentrieren sich auf den Informationsaustausch durch Nachrichten zwischen den ConnectableElements des Classifier. Classifier haben also Connectable Elements und der Informationsaustausch zwischen ihnen durch Nachrichten ist Gegenstand der Interaktionen. Nun die Klärung der Semantik von Interaktionen: Dies geschieht wiederum über das Konzept der Traces: Die Semantik einer Interaktion ist gegeben als ein Paar von Trace-Mengen. ([OMG 2003a, S. 419]

Gültige und ungültige Traces

Es gibt also zwei Mengen von Traces, die die Semantik einer Interaktion definieren. Dies sind die valid traces und die invalid traces. Die Vereini-

13.10 Interaktionen

447

gung dieser zwei Mengen muss nicht notwendigerweise die Gesamtheit aller Traces umfassen. Die nicht enthaltenen Traces werden in der jeweiligen Interaktion nicht beschrieben und es ist daher nicht bekannt, ob sie gültig sind oder nicht. Anschließend wird noch darauf verwiesen, dass die Semantik von Interaktionen „zusammenfügbar“ (compositional) ist in dem Sinn, dass man sie u.U. zusammensetzt aus den „Semantiken“ ihrer InteractionFragments. Man kann sich diese geordnet und zusammengefügt mit dem seqOperator (vgl. oben) denken. Da eine Interaktion Verhalten widerspiegelt, kann die so definierte Semantik generalisiert und spezialisiert werden. Spezialisierung bedeutet hier dann schlicht, dass mehr Traces zu den gegebenen hinzugefügt werden. Die durch die Spezialisierung definierten Traces werden dann mengenmäßig mit den vererbten vereinigt. Anschließend geht die Erläuterung noch ins Grundsätzliche (basic trace model). Dabei wird die Semantik einer Interaktion definiert als gegeben durch ein Paar [P, I], wo P die Menge der gültigen Traces und I die der ungültigen ist. P vereinigt mit I muss dann nicht die Gesamtheit der möglichen Traces (whole universe of traces) sein, was immer wieder betont wird. Dabei enthalten die EventOccurrences der Traces auch Informationen über die Ausprägungen aller wichtigen Objekte zum jeweiligen Zeitpunkt. Eigentlich sind wohl Elemente von Interaktionen gemeint, allerdings verwenden die UML-Autoren hier den Begriff Konstrukt (construct), um z.B. CombinedFragments unterschiedlicher Art anzusprechen. Jedenfalls führen sie aus, dass jedes solche Konstrukt oder Element darüber definiert wird, wie es sich gegenüber einem Paar von Trace-Mengen verhält. Der Einfachheit halber wird hier in der Regel nur auf die Menge der gültigen Traces verwiesen, da diese meist modelliert werden. Mit obigem kann dann auch leicht die Gleichheit zweier Interaktionen definiert werden, nämlich dann, wenn ihr Paar von Trace-Mengen gleich ist. An dieser Stelle folgt dann in der Quelle eine Betrachtung des Zusammenhangs von interaction trace model und execution model. Das execution model wird in einem Kapitel beschrieben, in dem sehr grundsätzlich (im Rahmen der Metamodellierung der UML-Autoren also auf einer abstrakten Ebene) auf Verhalten eingegangen wird. Das dort entwickelte execution model versucht aber sehr nahe an der Programmierung die Abläufe zu beschreiben. Mit diesen Vorstellungen wird nun die im Rahmen der Trace-Modellierung entwickelte Theorie verknüpft, die ja auch Abläufe beschreibt, nur auf einer praxisnäheren Ebene. Zwei Modellvorstellungen, die eine weiter weg von der konkreten programmmäßigen Umsetzung, die andere weniger weit weg, werden in Beziehung gesetzt. Soweit die Beschreibung der Interaktionen in der UML und mit dem Instrumentarium der Metamodellierung der UML-Autoren. In der Quelle

Basic trace model

interaction trace model und execution model

448

Grafische Darstellung von Interaktionen

13 Sequenzen, Sequenzdiagramme

wird dann noch die grafische Darstellung besprochen. Zuerst der allgemeine Teil, der für alle Interaktionsdiagramme gilt, dann der spezielle für die Subklassen. Für alle Interaktionsdiagramme gilt, dass sie in einem Rechteck mit durchgezogenen Linien dargestellt werden. Im linken oberen Eck wird in einem Fünfeck das Schlüsselwort sd, der Interaktionsname und die Parameter angegeben. Innerhalb des Rechteck folgt die spezifische Notation für die Untertypen. Im folgenden werden nun noch die bisher nicht besprochenen Theorieelemente zu Interaktionen/Sequenzdiagrammen vorgestellt.

13.11 InteractionConstraint Wachen für Fragmente

Der Ausgangspunkt für die InteractionConstraint sind die CombinedFragments. Dort gibt es Operatoren für die Auswahl zwischen diesen Fragmenten, die Fragmente stellen sozusagen Operanden dar. Ein InteractionConstraint ist nun ein boolescher Ausdruck, der einen Operanden in einem CombinedFragment „bewacht“. Dieses Element wird nur für diese CombinedFragments benutzt. Ein InteractionConstraint enthält zwei Ausdrücke, die die minimale und maximale Anzahl Durchgänge für eine Schleife, in der sich ein CombinedFragment befindet, festlegen. Darstellung Die Darstellung im Modell erfolgt in textlicher Form in eckigen Klammern auf der Lifeline, dort wo der erste EventOccurrence auftritt. Der InteractionConstraint wird über diesem Ereignis positioniert, in der umschließenden Interaktion oder im InteractionOperand (vgl. unten).

13.12 InteractionOccurrence

Aktuelle Gates für formale Gates

Man stelle sich vor, es gäbe einen Teil einer Interaktion, der in mehreren umfangreicheren Interaktionen genutzt werden kann. Dann kann er ausgelagert werden und an seiner Stelle kann ein Platzhalter stehen. Für dieses Konzept stehen in der UML die InteractionOccurrence. Konkret wird als InteractionOccurrence der Platzhalter bezeichnet, der in der übergeordneten Interaktion steht. Dies ist eine Standardtechnik in jeder Theorie zur Ablaufmodellierung, vgl. zum Beispiel die Prozesswegweiser in Ereignisgesteuerten Prozessketten. Die untergeordnete Interaktion kann in verschiedenen übergeordneten mit unter Umständen ungleichen Anbindungen eingesetzt werden. Da diese An- oder Einbindung hier durch Gates realisiert wird, ist es so, dass eine InteractionOccurrence eine Menge aktueller Gates hat, die den formalen Gates der Interaktion, auf die sie sich bezieht, entsprechen müssen.

13.12 InteractionOccurrence

449

Die Semantik eines InteractionOccurrence ist wiederum einfach durch die Traces der einzubindenen Interaktion gegeben. Grafische Darstellung Die InteractionOccurrence wird als CombinedFragment – Symbol dargestellt, bei dem der Operator ref genannt wird. Beispiel Im folgenden Beispiel sind zwei InteractionOccurrences enthalten: OpenDoor und EstablishAccess. Beide sind als CombinedFragments mit ref gekennzeichnet. Diese stellen jeweils eigene Interaktionen dar.

Abbildung 13.12-1:

Sequenzdiagramm mit InteractionFragment Quelle: [OMG 2003a, S. 424, Figure 338] Übersetzung durch den Verfasser

Die folgende Abbildung 9.6-10 zeigt eine etwas komplexere Sequenz: x x

x x x

Sie hat einen Rückgabewert, der über eine eigene Lifeline a_op_b realisiert ist. Sie enthält ein InteractionOccurrence, das sich auf a_util_b bezieht mit einer Rückgabe an das Attribut xc von :xx und dem Wert 9, mit Ein-/Ausgabewerten, mit dem Argument w und dem Rückgabewert 12. Zwei Lifelines bestehen aus Klassen, :xx und :yy. Eine Lifeline, w, stellt Ein-/Ausgabewerte dar. Die Lifeline a_op_b stellt den Rückgabewert der Interaktion dar.

450

13 Sequenzen, Sequenzdiagramme

Abbildung 13.12-2:

Sequenzdiagramm mit InteractionFragment Quelle: [OMG 2003a, S. 425, Figure 339]

13.13 InteractionOperand Mit dem Begriff InteractionOperand sind die Operanden in einem CombinedFragment gemeint. D.h., wenn die Aufteilung in zwei Teile erfolgte, dann stellt die untere und die obere Hälfte jeweils ein Fragment dar und jedes ist ein InteractionOperand. Ein InteractionOperand ist auch ein InteractionFragment, optional mit einem Wächter. Der Wächter kann ein InteractionConstraint sein. Nur InteractionOperands mit einem Wächter, dessen Bedingungen an dieser Stelle erfüllt sind, kommen für die Zusammenstellung der Traces für das umschließende CombinedFragment in Frage. Grafische Darstellung

Semantikbestimmung

InteractionOperands werden durch eine gestrichelte horizontale Linie getrennt (auch InteractionOperand separator genannt). Die InteractionOperands zusammen stellen das CombinedFragment dar. In Sequenzdiagrammen sind diese Fragmente senkrecht untereinander angeordnet. Die genaue Position ist festgelegt durch die oberste senkrechte Position der in ihr enthaltenen EventOccurrences oder Symbole. Der Wächter wird direkt vor das erste im jeweiligen InteractionOperand befindliche EventOccurrence platziert. Es versteht sich, dass in die Bestimmung der Semantik nur InteractionOperands miteinbezogen werden, deren Wächter-Bedingungen „wahr“ sind. Ist kein Wächter da, wird dies gleichgesetzt mit einem Wächter des-

13.14 StateInvariant

451

sen Bedingungen erfüllt sind. Die Gesamtsemantik eines InteractionOperand ist gegeben durch seine mit dem implizten seq-Operator verknüpften Semantiken der InteractionFragments.

13.14 StateInvariant Eine StateInvariant ist eine Einschränkung für den Zustand einer Lifeline. Dabei sind hier mit Zustand auch die Werte eventueller Attribute der Lifeline gemeint. Eine solche Zustandseinschränkung ist ebenfalls ein InteractionFragment. Es wird auf einer Lifeline platziert. Die Einschränkung wird zur Laufzeit(!) geprüft. Und zwar unmittelbar vor der Ausführung des nächsten EventOccurrence, so dass alle Aktionen, die nicht ausdrücklich modelliert sind, ausgeführt worden sind. Wenn die Bedingung wahr ist, ist der Trace gültig, falls die Bedingung nicht erfüllt ist, ist der Trace ein ungültiger Trace. Darstellung Die Darstellung erfolgt in Textform, in geschweiften Klammern auf der Lifeline. Die Einschränkung kann auch als Notiz bei einem EventOccurrence eingefügt werden. Vgl. Abbildung 13.16-2 für ein Beispiel.

13.15 Stop Ganz gleich wie bei den Aktivitäten gibt es hier ein Element, Stop, das etwas beendet. Hier ist Stop ein EventOccurrence, das das Ende der Existenz einer Instanz signalisiert, einer Instanz der Lifeline, auf der das Stopsymbol erscheint. Grafische Notation Die grafische Darstellung erfolgt durch ein Kreuz in Form eines X am Ende der Lifeline.

13.16 Beispiele zu Sequenzdiagrammen Beispiel 1 Das erste Beispiel ist abstrakt gehalten, um möglichst viele Elemente von Sequenzdiagrammen unterzubringen. Folgende sind u.a. enthalten: x x x

CombinedFragment (auf der Basis des InteractionOperator alt) InteractionOperator alt InteractionConstraint [x > 0]

Prüfung zur Laufzeit

452

x x x

13 Sequenzen, Sequenzdiagramme

InteractionOperand separator – gestrichelte Linie, die das Fragment in die zwei Operanden aufteilt. Stop – Beendigung der Existenz einer Instanz Mehrere ExecutionOccurrences

Außerdem wird das Erzeugen eines Objektes (ob2:C2) in der Sequenz gezeigt. Seine Existenz endet dann auch innerhalb der Sequenz, wozu das oben erwähnte Element Stop dient.

Abbildung 13.16-1:

Sequenzdiagramm Abstraktes Beispiel Quelle: [OMG 2003a, S. 414, Figure 333]

Beispiel 2 Das folgende ebenfalls abstrakte Beispiel zeigt ein Sequenzdiagramm M mit folgenden Komponenten: x InteractionOperator ignore / consider. Ignore ist bei der Bezeichnung des Sequenzdiagramms vermerkt. Dort ist auch gleich mit angegeben, dass die Nachrichtentypen t und r ignoriert werden. x InteractionFragment consider. Das Pendant zu obigem. x StateInvariant mystate. Sie wird, wie oben ausgeführt, zur Laufzeit geprüft und zwar direkt vor dem ersten EventOccurrence, das auf :Y nach der StateInvariant erscheint. x CombinedFragment assert. Dieses stellt sicher, dass die Nachricht q an dieser Stelle im Ablauf vorkommt. x InteractionFragment mit dem Operator assert. Durch dieses wird die Nachricht q sichergestellt.

13.16 Beispiele zu Sequenzdiagrammen

x

453

Zwei verschachtelte Fragmente. Das InteractionFragment mit assert ist in dem mit consider enthalten. Das bedeutet, dass erwartet wird, dass die Nachricht q vorkommt wenn vorher eine Nachricht v erschienen ist.

Entsprechend dem InteractionOperator ignore / consider liegt ein InteractionFragment mit der Bezeichnung consider vor. Dort ist auch vermerkt, dass die Nachrichtentypen q, v und w berücksichtigt werden. Jedes Auftreten einer anderen Nachricht wird somit ignoriert. So wäre das Auftreten einer Nachricht w nach der Nachricht v ein ungültiger Trace. Wozu wird so etwas benötigt? Die UML-Autoren führen aus, dass sie dabei an Testsituationen denken, wo bei einem Test der eine oder der andere Nachrichtenverkehr ausgeschaltet werden soll. [OMG 2003a, S. 442]

Abbildung 13.16-2:

Sequenzdiagramm M Quelle: [OMG 2003a, S 442, Figure 345]

Testsituationen

In Kapitel 14 (Anwendungsfälle) verwendete Begriffe aus der UML (in der Reihenfolge des Auftretens): Deutsch

Englisch

Anwendungsfall Anwendungsfalldiagramm

use case use case diagram actor subject extend extending use case extended use case extension point include actors class rectangle

Extend-Beziehung

Include-Beziehung Akteure Klassenrechteck

14 Anwendungsfälle

Für die UML-Autoren sind die in diesem Abschnitt vorgestellten Anwendungsfälle (use cases) informelle Beschreibungen von Verhalten. [OMG 2003a, S. 370]

Informelle Beschreibungen

14.1 Definition Anwendungsfälle128 (use cases) beschreiben, was ein System leisten soll. Da diese Leistung immer mit den Nutzern des Systems zu tun hat, erläutern sie damit das Zusammenwirken von Anwendern mit dem System. Die UML-Autoren definieren Anwendungsfälle wie folgt: “A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.” [OMG 2003a, S. 519] Damit ist es die Aufgabe der Anwendungsfälle, die durch ein System benötigte Funktionalität zu erfassen: “The purpose of use cases is to identify the required functionality of a system”. [OMG 2003a, S. 522] Dass die Beschreibung des Umgangs mit einem System durchaus zwei Aspekte hat, sehen auch die Urheber der UML: zum einen die von „außen“ kommenden Anforderungen an das System („specification of the (external) requirements on a subject129“ [OMG 2003a, S. 519]), zum anderen die Funktionalität, die das System anbietet („specification of the functionality offered by a subject“ [ebenda]): x x

Anforderungen an das System (Ausgangspunkt: Systemaußenwelt) Verhalten (Leistung) des Systems (Ausgangspunkt: das System als solches)

Beides kann, muss aber nicht übereinstimmen. Die praktischen Beispiele in der Literatur zeigen allerdings fast immer nur die zweite Sicht. Dabei wäre die erste, gerade wenn man an die Modellierung von Geschäftsprozessen denkt, auch wichtig. Denn die Modellierung von Geschäftsprozes128 Der Begriff geht ursprünglich auf Jacobson zurück. Er bezeichnet damit eine Folge von Aktionen, die von einem Systemnutzer im Dialog mit dem System ausgeführt werden [Booch, Rumbaugh und Jacobson 1999, S. 250]. 129 Zum Begriff subject vgl. unten.

Zwei Aspekte

456

14 Anwendungsfälle

sen ist sehr stark dadurch geprägt, dass auch Verhalten beschrieben wird, das noch nicht in der Software (die ja hier letzendlich aus dem System entstehen soll) verankert ist oder dort gar nie verankert werden kann. Sprachgebrauch: „subject“ subject

In den Texten der UML-Autoren spürt man nur selten Unsicherheit. Eine dieser Stellen findet sich bei den Ausführungen zu Anwendungsfällen (use cases). Hier ist, bei der Aufzählung der Elemente, die einen Anwendungsfall ausmachen, recht unvermittelt von „subject“ die Rede: “The key concepts associated with use cases are actors, use cases, and the subject”. [OMG 2003a, S. 503] Dies wird dann auch gleich präzisiert: “The subject is the system under consideration to which the use cases apply”. [ebenda] In früheren Texten und an anderen Stellen war und ist hier von „system“, „subsystem“ oder auch „class“ die Rede, wie das folgende Zitat zeigt: „A use case is a kind of classifier representing a coherent unit of functionality provided by a system, a subsystem, or a class as manifested ….” [OMG 1999, S. 3-91]

Teilsystem

Die Hervorhebung wurde vom Verfasser vorgenommen. Dem Sprachgebrauch kann entnommen werden, dass mit dem Begriff subject hier tatsächlich ein Teilsystem gemeint ist: der Teil des System, auf den sich die Anwendungsfälle beziehen. Es wird nicht ganz klar in den Texten der UML-Autoren, aber die Wahl des neuen Begriffs „subject“ könnte – in Bezug auf die Anwendungsfälle – eine teilweise Loslösung vom Systembegriff bedeuten, hin zu etwas, was man mit „inhaltlichem Gegenstand“ oder „Vorgang“ oder auch „Geschäftsprozess“ übersetzen kann130. Darin könnte der Versuch zum Ausdruck kommen, etwas näher an die Beschreibung von Abläufen zu kommen. Der Sprachgebrauch zeigt aber auch sehr deutlich, dass die Autoren ein subject als etwas aktives ansehen, etwas das Verhalten hat. Dies wäre dann nicht so sehr mit dem Geschäftsprozesskonzept vereinbar. Ein Geschäftsprozess ist selbst nicht aktiv (in diesem Sinne), aber in ihm sind Systeme und Menschen tätig, die für sich und für ihn (den Geschäftsprozess) aktiv sind. Um die Verwirrung nicht zu groß werden zu lassen, wird im folgenden von System die Rede sein, wenn im UML-Text subject steht. Sollte die

130 Die Entscheidung zwischen den letzten beiden würde durch den Umfang der modellierten Tätigkeiten festgelegt. Ginge es z.B. um alle Tätigkeiten rund um Personalbeschaffung, könnte durchaus von einem Geschäftsprozess gesprochen werden. Ginge es nur um die engeren Vorgänge einer Personaleinstellung, läge eher das vor, was wir in der deutschsprachigen Literatur Vorgang nennen.

14.2 Einführendes Beispiel

457

Nutzung des Begriffs subject allerdings eine Überwindung des engeren Systembegriffs andeuten wird darauf hingewiesen.

14.2 Einführendes Beispiel Auch Anwendungsfälle werden grafisch dargestellt. Ein solches Anwendungsfalldiagramm zeigt die folgende Abbildung. Es ist sehr einfach, gibt aber die Grundstruktur wieder. Dabei bedeuten die Ellipsen mit ihrer Beschriftung die einzelnen Anwendungsfälle, die mit bestimmten Objekten (hier den Angestellten eines Unternehmens) stattfinden können. Das Rechteck um die beschrifteten Ellipsen drückt die Zusammengehörigkeit aus (und grenzt somit das System oder das „subject“ ab, vgl. oben). Die ebenfalls beschrifteten Strichmännchen symbolisieren diejenigen, die mit dem System (oder was auch immer, vgl. oben) umgehen. Die Linien zwischen Strichmännchen und Ellipsen drücken aus, wer welche Anwendungsfälle nutzt, d.h. welche Tätigkeit ausführt.

Abbildung 14.2-1:

Ein Anwendungsfalldiagramm (einfachste Form)

Soweit die Grundstruktur. Im folgenden wird diese nun schrittweise erweitert und vertieft.

14.3 Anwendungsfälle Jeder Anwendungsfall repräsentiert ein Verhalten (so sehen es die UMLAutoren tatsächlich), ein einzelnes Verhalten, das ein System leisten kann in Zusammenarbeit mit einem oder mehreren Aktoren. Die interne Struktur des Verhaltens wird nicht dargestellt.

Abbildungen für Anwendungsfälle

458

Verhaltensweisen, die Änderungen bewirken Varianten

14 Anwendungsfälle

Dieses Verhalten (im Englischen können die UML-Autoren hier die Mehrzahl “behaviors” verwenden) kann zu Änderungen im Zustand des Systems führen und zur Kommunikation mit der Systemumgebung. Ein Anwendungsfall kann Variationen seines Grundverhaltens enthalten, darunter auch solche zu Sonderfällen und zur Fehlerbehandlung. Dazu unten mehr. Wechselt man die Perspektive, kann man auch definieren, dass jeder Anwendungsfall ein Stück sinnvolle Funktionalität festlegt, die das System dem Nutzer liefert. Um eine Beschreibung, die stärker das Umfeld von Geschäftsprozessen berücksichtigt, bemüht sich Oestereich. Er beschreibt den Umfang dessen, was Anwendungsfälle leisten, wie folgt: „Der Kontext eines Anwendungsfalls ist normalerweise begrenzt durch das, was ein Benutzer in einem Arbeitsgang an einem Anwendungssystem macht, um einen Geschäftsvorfall aus einem Geschäftsprozess zu bearbeiten.“ [Oestereich 1998, S. 207] „Ein Anwendungsfall beschreibt einen typischen Arbeitsablauf.“ [Oestereich 1998, S. 207]

Beispiele für Anwendungsfälle

Geschäftsvorfälle definiert er wie folgt: „...beispielsweise die schriftliche Schadensmeldung eines Hausrat-Versicherten. Der Geschäftsprozess (z.B „Schadensmeldung Hausrat“) beschreibt den gesamten Ablauf, um ein solches Ereignis zu verarbeiten. Der Geschäftsprozess enthält dabei unter Umständen auch Aktivitäten, die nicht direkt durch die zu entwickelnde Anwendung unterstützt werden (z.B. „Besichtigung des Schadenortes durch einen Sachverständigen“).“ [Oestereich 1998, S. 215] Damit sind auch wichtige Abgrenzungen gegeben. Es ist aber auch geklärt, dass Anwendungsfälle nicht Geschäftsprozesse beschreiben, sondern einzelne Aufgaben. Was kann alles Verhalten haben?

Alles was Verhalten hat

Zurück zu den UML-Autoren, die wesentlich näher am Systembegriff sind. Dies zeigt auch die Antwort auf die Frage, was alles Gegenstand eines Anwendungsfalls sein kann, was also Verhalten haben kann [OMG 2003a, S. 519]: x x x x

ein physisches System eine Komponente eines Systems ein Subsystem eine Klasse

Nun hat so ein Anwendungsfalldiagramm mit seiner Sammlung von Anwendungsfällen recht wenig Aussagekraft. Es legt lediglich die geforderte

14.3 Anwendungsfälle

459

bzw. geleistete Funktionalität fest. Deshalb weisen die UML-Autoren auf die verschiedenen Möglichkeiten hin, einen Anwendungsfall (genauer: sein Verhalten) näher zu beschreiben: x x x x

durch Interaktionen, Aktivitäten und state machines durch Vor- und Nachbedingungen durch natürlichsprachigen Text indirekt durch eine Kollaboration (collaboration), die den Anwendungsfall benutzt.

Grafische Darstellung Die grafische Darstellung wurde im einführenden Beispiel schon vorgestellt: Jeder Anwendungsfall ist in einer beschrifteten Ellipse, zusammengehörige Anwendungsfälle sind mit einem Rechteck umrandet, Strichmännchen stellen die Akteure dar, Strichmännchen und Anwendungsfälle sind durch Linien in Beziehung gesetzt. Die Kurzbezeichnung in der Ellipse oder darunter kann natürlich nur andeuten, um was es bei der jeweiligen Tätigkeit geht. Etwa so wie bei Ereignisgesteuerten Prozessketten die Bezeichnung einer Funktion. Deshalb schlagen die UML-Autoren die oben angeführten zusätzlichen Beschreibungen des „detaillierten Verhaltens“ des Anwendungsfalls vor, abhängig von der Beschreibungstechnik als Diagramm oder als Textdokument [OMG 2003a, S. 522]. Abschließend noch ein Hinweis von Fowler/Scott, wie man Anwendungsfälle findet: „Eine gute Quelle zur Identifikation von Anwendungsfällen sind externe Ereignisse. Denken sie über alle Ereignisse aus der Außenwelt nach, auf die reagiert werden soll.“ [Fowler und Scott 1998, S. 57] 14.3.1 Extend-Beziehung Zwischen Anwendungsfällen kann es Beziehungen geben. Eine davon wird benutzt, wenn zusätzliches Verhalten zum Verhalten eines anderen Anwendungsfalls hinzugefügt werden soll. Sie wird Extend - Beziehung genannt. Liegen z.B. zwei Anwendungsfälle AF1 und AF2 vor, besagt diese Beziehung, dass AF1 in AF2 eingefügt werden kann, aber nicht muss. Die UML-Autoren sprechen dann von dem extending use case und dem extended use case und definieren die Beziehung so, dass ...

Beziehung zwischen Anwendungsfällen

„… the behavior defined in the extending use case can be inserted into the behavior defined in the extended use case” [OMG 2003a, S. 515].

extending use case und extended use case

460

Standardund Nicht-StandardSituationen

14 Anwendungsfälle

Die Beziehung ist gerichtet. Man benutzt sie bei Anwendungsfällen, „die einem anderen Anwendungsfall ähnlich sind, aber noch ein wenig mehr bewerkstelligen.“ [Fowler und Scott 1998, S. 58]. Sie führen das Beispiel eines Anwendungsfalls an, der Handel durchführen modelliert. Dieser beschreibt dann den Standardfall, bei dem alles glatt geht. Modelliert man auch Nicht-Standardsituationen (z.B. die Überschreitung des Maximalbetrags oder andere mögliche Abweichungen) werden diese in den Erweiterungen des Anwendungsfalles festgehalten. Fowler/Scott empfehlen, bei der Beschreibung des „normalen“ Anwendungsfalls bei jedem Schritt zu überlegen, was schief gehen kann und diese Variationen als Erweiterungen des Anwendungsfalles zu modellieren [Fowler und Scott 1998, S. 58]. Extension Point

Gezielte Erweiterung

Grafische Darstellung der Extend-Beziehung

Ein extension point gibt die Stelle im Verhalten eines Anwendungsfalls an, bei der sein Verhalten erweitert werden soll im Sinne der oben beschriebenen Extend-Beziehung. Er wird an der Pfeillinie, die die ExtendBeziehung angibt (vgl. unten), als kleiner Kreis angebracht und mit einem Text versehen, der die Bedingung angibt, unter der es zur Weiterung kommt. Wird der erweiterte Anwendungsfall dann ausgeführt und der extension point erreicht, erfolgt die Prüfung, ob die Bedingung wahr ist. Falls ja, wird das Verhalten der Erweiterung ebenfalls ausgeführt. Die grafische Darstellung einer Extend-Beziehung erfolgt durch einen gestrichelten gerichteten Pfeil, der mit extend beschriftet ist. Die Pfeilrichtung ist von dem Anwendungsfall, der die Erweiterung liefert, zu dem, der sie erhält. [OMG 2003a, S. 516]. Beispiel Das folgende Beispiel enthält zwei Anwendungsfälle: Online-Hilfe und ausführen Geldautomat-Transaktion. Der zweitgenannte Anwendungsfall hat einen extension point „Auswahl“. Durch diesen wird der Anwendungsfall erweitert, und zwar um Online-Hilfe.

Abbildung 14.3-1:

Extend-Beziehung zwischen Anwendungsfällen Quelle: [OMG 2003a, S. 424, Figure 402] Übersetzung durch den Verfasser

14.4 Akteure

461

14.3.2 Include - Beziehung Eine Include - Beziehung (include relationship) wird verwendet, wenn ein Verhaltensanteil in verschiedenen Anwendungsfällen gleich ist. Dann wird dieser aus allen, in denen er vorkommt, ausgelagert in einen eigenen Anwendungsfall. Damit handelt es sich um eine gerichtete Beziehung, z.B. von einem Anwendungsfall AF1 zu einem Anwendungsfall AF2. Sie besagt (in diesem Beispiel), dass bei Ausführung des Falls AF1 der Anwendungsfall AF2 immer ebenfalls ausgeführt werden muss. AF1 enthält (als Aufgabe) AF2. Somit gilt:

Auslagerung von Verhalten

„An include relationship defines that a use case contains the behavior defined in another use case.” [OMG 2003a, S. 517] Die grafische Darstellung erfolgt durch einen gerichteten gestrichelten Pfeil mit der Beschriftung <>. Beispiel Ein Anwendungsfall Abhebung enthält einen unabhängig davon definierten Anwendungsfall Kartenidentifikation.

Abbildung 14.3-2:

Beispiel einer Include-Beziehung Quelle: [OMG 2003a, S. 518, Figure 403] Übersetzung durch den Verfasser

Die Include-Beziehung erlaubt somit zweierlei. Zum einen können Anwendungsfälle hierarchisch zerlegt werden, zum anderen erlaubt sie deren Mehrfachverwendung.

14.4 Akteure Als Akteure (actors) werden die bezeichnet, die mit dem System umgehen, die also die Anwendungsfälle nutzen. Dies sind (menschliche) Nutzer oder auch andere Systeme. Wichtig ist, dass beide extern, d.h. außerhalb des (Teil-)Systems, angesiedelt sind: “Actors always model entities that are outside the system” [OMG 2003a, S. 511] Die Akteure (actors) werden mithilfe der spezifischen Aufgaben, die sie im Umgang mit dem System haben (Rollen) definiert: „An actor specifies a role played by a user or any other system that interacts with the subject.” [OMG 2003a, S. 512] Damit kann ein Akteur mehrfach mit unterschiedlichen Rollen auftreten.

Nutzer der Anwendungsfälle

462

Interaktion

14 Anwendungsfälle

Die Interaktion eines Akteurs mit dem System kann z.B. darin bestehen, Signale oder Daten auszutauschen. Dies können die Eingaben eines Menschen am Geldautomaten sein oder die Daten, die eine externe Software vom Geldautomaten anfordert um den Zahlungsausgang zu überwachen. Grafische Darstellung Ein Akteur wird durch ein Strichmännchen dargestellt, dem die Bezeichnung des Akteurs zugeordnet wird.

Abbildung 14.4-1:

Strichmännchen in Anwendungsfällen

Eine alternative Darstellung für Akteuere ist die als „Klassenrechteck“ (class rectangle) mit dem Schlüsselwort <> und der Bezeichnung des Akteurs.

Abbildung 14.4-2:

Akteure in Anwendungsfalldiagrammen – grafische Darstellung

14.5 Beispiel Kunde und Lieferant Das Beispiel stammt aus [Marshall 2000]. Es wurde auch deshalb ausgewählt, weil es bewusst auf Geschäftsprozesse zielt. Die vier Anwendungsfälle x x x x

Anfrage Kalkulation Auftrag Lieferung

bedürfen sicher keiner Erläuterung. Zwei davon werden von Kunden, die anderen zwei von Lieferanten genutzt.

14.6 Einschätzung

Abbildung 14.5-1:

463

Anwendungsfalldiagramm Kunde und Lieferant Quelle: [Marshall 2000, S. 64] Übersetzung durch den Verfasser

14.6 Einschätzung Aufgabe in der Systementwicklung Anwendungsfalldiagramme gehören zu den ersten Diagrammen, die im Rahmen einer objektorientierten Systemanalyse erstellt werden. Sie stellen überblicksartig die Gesamtfunktionalität des zu entwickelnden Systems dar und beschreiben das Zusammenwirken von Anwender und System. Kein Eingehen auf die innere Struktur Sie gehen nicht auf die interne Struktur der jeweils beschreibenen Abläufe ein, sie beschreiben nicht die geplante Implementierung: „Anwendungsfälle beschreiben das externe Systemverhalten, d.h. was das System leisten soll. Wie dieses entsteht, d.h. welches Systemdesign und welche Realisierung zu diesem äußeren Systemverhalten beiträgt, darüber treffen die Anwendungsfälle keine Aussage.“ [Oestereich 1998, S. 215f] Absolute Definition möglich? Die Abgrenzung der Tätigkeiten, die zu einem Anwendungsfall gehören, ist immer subjektiv, genauso wie es in der Diskussion um Ereignisgesteuerte Prozessketten die Abgrenzung von Funktionen ist. Dasselbe gilt für den Detaillierungsgrad der Modellierung. Die Ursache liegt darin, dass hier einer der Berührungspunkte mit der zu modellierenden Realität ist und diese sich nun mal nicht formal fassen lässt.

464

14 Anwendungsfälle

Eine absolute Definition dessen, was ein Anwendungsfall ist, kann also nicht geleistet werden. Das wissen diejenigen, die mit Geschäftsprozessen umgehen, am besten. Da helfen auch keine noch so bemühten Formulierungen („etwas, was einen konkreten Nutzen bringt“, usw.). Anwendungsfall = Geschäftsprozess? Geschäftsprozesse?

Nach der Beschreibung in diesem Kapitel kann man schon verstehen, dass manche bei Anwendungsfällen an Geschäftsprozessmodellierung denken, v.a., wenn Booch, Rumbaugh und Jacobson noch betonen, dass ein Anwendungsfall ein greifbares Arbeitsergebnis liefert [Booch, Rumbaugh und Jacobson 1999, S. 249], dass dieses Konzept auf das ganze System anwendbar ist und eine Menge von Folgen beschreibt, „... in der jede Folge eine Interaktion von etwas außerhalb des Systems (seinen Akteuren) mit dem System selbst ... ist“ [Booch, Rumbaugh und Jacobson 1999, S. 248].

Zusätzliche textliche Beschreibung

Es überrascht deshalb nicht, dass einige Autoren den Begriff use case mit Geschäftsprozess gleichsetzen ([Balzert 2001, S. 126ff], [Balzert 1999, S. 63], [Meier und Wüst 1997, S. 42]). Für Meier und Wüst sind die Begriffe Anwendungsfall (sie sprechen von Anwenderfunktion) und Geschäftsprozess synonym. Den Gesamtzusammenhang sehen sie so, dass der Gesamtumfang der Anwendung durch die Systemziele und Systemgrenzen festgelegt ist und die Geschäftsprozesse oder Anwenderfunktionen zur Erfüllung der Systemziele dienen. Hinzu kommt, dass eine detailliertere (i.d.R. textliche) Beschreibung der Anwendungsfälle tatsächlich gefordert wird. Unter der Überschrift „vom Groben zum Detail“ beschreiben z.B. Meier und Wüst den Einsatz von Anwenderfunktionen durch Geschäftsprozesskarten (>Meier und Wüst 1997, S. 41f@). Dabei wird jeder spezifische Anwendungsfall durch Geschäftsprozesskarten erfasst, d.h. textlich beschrieben. Anwendungsfälle modellieren keine Geschäftsprozesse Trotzdem kann der Gleichsetzung von Geschäftsprozessen und Anwendungsfällen nicht zugestimmt werden. Anwendungsfälle beschreiben nur einige wenige Aspekte von Geschäftsprozessen. Sie benennen sie und definieren damit Anforderungen an das System. Sie zeigen evtl. Beziehungen zwischen Anwendungsfällen (vgl. oben) aus. Damit ist die Modellaussage aber schon erschöpft. Es wird nicht beschrieben, wie der Anwendungsfall, Schritt um Schritt, realisiert ist. Dies ist kein Vorwurf an „die UML“, da diese so etwas gar nicht verspricht, es ist aber ein Hinweis an die Autoren, die Anwendungsfälle mit Geschäftsprozessen gleichsetzen (in der Realwelt oder im Modell). Die evtl. angehängten textlichen Beschreibungen sind da keine zeitgemäße Antwort. Textliche Beschreibungen kommen bei weitem nicht an die Aussagekraft von Ereignisgesteuerten Prozessketten heran. Vielleicht

14.6 Einschätzung

465

wäre es ja eine gute Lösung, den Anwendungsfällen kurze EPKs anzuhängen. Eine Folge dieser fehlenden Beschreibung der einzelnen Schritte ist, dass kein Konzept wie der Kontrollfluss von Ereignisgesteuerten Prozessketten existiert, durch den das gezielte Miteinander der einzelnen Funktionen eines Geschäftsprozesses beschrieben wird. Ohne ein irgendwie geartetes Kontrollflusskonzept ist aber die Beschreibung von Abläufen nicht möglich.

Ohne Kontrollflusskonzept keine Geschäftsprozessmodellierung

In Kapitel 15 (Zustandsautomaten) verwendete Begriffe aus der UML (gruppiert und alphabetisch geordnet nach den englischen Begriffen) – Teil 1: Deutsch

Englisch

Aktivität: Eingangsaktivität Aktivität: Ausgangsaktivität Aktivität: Zustandsaktivität, DoAktivität

activity: entry activity activity: exit activity activity: state activity, Do-activity

Verhaltens-Classifier Bereich für die Zerlegungen Bereich für die internen Aktivitäten Bereich für die internen Übergänge Bereich: Namensbereich Ereignis Ereignis: Abschlussereignis Wächter Pseudozustand: Pseudozustand: Auswahlknoten Pseudozustand: Einstiegspunkt Pseudozustand: Ausstiegspunkt Pseudozustand: Gabelung Pseudozustand: Initial-Knoten Pseudozustand: Verknüpfer Pseudozustand: Verbindungspunkt Region Region: übergeordnete Region Zustand Zustandsautomat, Automat Zustandsautomat: VerhaltensZustandsautomat Zustandsautomat: Protokollzustandsautomat Zustandsautomat: enthaltender Zustandsautomat / übergeordneter Zustandsautomat Zustandsautomat: hierarchischer Zustandsautomat Zustandsautomat: untergeordneter Zustandsautomat Zustand: zusammengesetzer Zustand Zustand: eingebetteter Zustand

behavioral state machine behaviored context classifier compartment: decomposition compartment compartment: internal activities compartment compartment: internal transitions compartment compartment: name compartment event event: completion event Guard pseudostate: pseudostate: choice vertex pseudostate: entry point pseudostate: exit point pseudostate: fork vertex pseudostate: initial vertex pseudostate: join vertex pseudostate: junction vertex region region: enclosing region state state diagram state machine state machine: behavioral state machine state machine: protocol state machine state machine: containing state machine state machine: hierarchical state machine state machine: submachine state machine. state: composite state state: enclosing state

In Kapitel 15 (Zustandsautomaten) verwendete Begriffe aus der UML (gruppiert und alphabetisch geordnet nach den englischen Begriffen) – Teil 2: Zustand: Schlusszustand Zustand: History-Zustand Zustand: orthogonaler Zustand Zustand: Protokollzustand Zustand: Pseudozustand Zustand: einfacher zusammengesetzter Zustand Zustand: einfacher Zustand Zustand: Quellzustand Zustand: Zustandskonfiguration Zustand: Zielzustand Zustandsübergangsdiagramm, Zustandsdiagramm Zustandsautomat: untergeordneter Zustandsautomat Zustandsautomat: untergeordneter Zustandsautomat eines zusammengesetzten Zustandsautomaten Zustand: Zustand, der einen Zustandsautomaten enthält Zustand eines untergeordneten Zustandsautomaten Zustandsautomat: untergeordneter Automat eines Zustandsautomaten Sub-Automat eines Zustandsautomaten Sub-Zustand Zustandsautomat des SubZustandes Sub-Zustand, direkter Sub-Zustand, indirekter Zustandsübergang, Übergang / Transition Transition: Abschlusstransition Transition: Verbundtransition Transition: Gruppentransition Transition: Starttransition Transition: interne Transition Transition: Hauptquelle einer Transition Transition: Hauptziel einer Transition Transition: Protokolltransition Transition: Selbstransition Trigger

state: final state state: history state state: orthogonal state state: protocol state state: pseudostate state: simple composite state state: simple state state: source state state: state configuration state: target state statechart diagram, state diagram submachine submachine composite state machine submachine state

submachine state machine

substate substate machine substate, direct substate, indirect transition transition: completion transition transition: compound transition transition: group transition transition: initial transition transition: internal transition transition: main source of a transition transition: main target of a transition transition: protocol transition transition: self transition trigger

15 Zustandsautomaten

15.1 Einleitung Für die UML-Autoren sind die in diesem Abschnitt vorgestellten Zustandsautomaten (state machines) (endliche) Automaten. [OMG 2003a, S. 370] Bei Zustandsautomaten geht es um das interne Objektverhalten, nicht um die Interaktionen zwischen Objekten. Zustandsübergänge (Transitionen) erfassen den Lebenszyklus eines Objektes mit den verschiedenen möglichen Objektzuständen und den Zustandsübergängen. Der Lebenszyklus eines Objekts besteht aus Zuständen, in denen Objekte eine bestimmte Zeit verharren und auf Ereignisse warten. Von einem Zustand aus sind verschiedene Transitionen möglich. Ausgelöst wird die Zustandsänderung durch ein Ereignis, das zu einem bestimmten Zeitpunkt eintritt und selbst keine Zeit in Anspruch nimmt. Welche Zustandsänderung eintritt, hängt von dem Ereignis und dem Objektzustand zum Zeitpunkt des Ereignisses ab. Die UML-Autoren unterscheiden zwei Typen von Zustandsautomaten, die Behavioral State Machines und die Protocol State Machines. Sie werden hier mit Verhaltenszustandsautomat bzw. Protokollzustandsautomat übersetzt. Beide nutzen weitgehend dasselbe Instrumentarium, sind aber doch verschieden.

Automaten

Was modellieren Zustandsautomaten? Ereignisse lösen Zustandsänderungen aus Transitionen

Verhalten und Protokoll

Verhaltenszustandsautomaten Die Verhaltenszustandsautomaten drücken, wie oben beschrieben, das Verhalten von Teilen eines Systems aus. Es geht um die Modellierung von diskretem Verhalten durch endliche Automaten. Somit geht es auch um das Verhalten von Modellelementen, z.B. von einzelnen Instanzen. Näheres hierzu in den nächsten Abschnitten.

Verhaltensmodellierung

Protokollzustandsautomaten Bei Protokollzustandsautomaten geht es darum, das Nutzungsprotokoll von Teilen eins Systems festzuhalten. Sie modellierern die zulässigen Transitionen, die ein Classifier auslösen kann. Damit erlauben die Protokollzustandsautomaten, den Lebenszyklus von Objekten bzw. die Abfolge von Methodenaufrufen festzuhalten. Die Besonderheiten dieser Automaten sind in Abschnitt 15.6 zusammengestellt.

Protokollierung

470

15 Zustandsautomaten

Verhalten? Verhalten = Durchqueren eines Graphen

In beiden Versionen von Zustandsautomaten wird Verhalten als ein Durchqueren eines Graphen von Zustandsknoten modelliert, die durch eine oder mehrere Übergangskanten verbunden sind. Getriggert wird dies durch das Aktivieren einer Serie von Ereignissen. Während dieser „Durchquerung“ führt der Zustandsautomat eine Reihe von Aktivitäten aus, die mit den verschiedenen Elementen der StateMachine in Beziehung stehen. Ereignisse und Zustandsübergänge

Ereignisse

In diesem Konstrukt sind somit Ereignisse von zentraler Bedeutung. Sie lösen die Zustandsübergänge aus und ermöglichen damit die Modellierung der dynamischen Aspekte. Zustandsübergangsdiagramme Die grafische Darstellung von Zustandsautomaten (state machines) erfolgt durch Zustandsübergangsdiagramme (statechart diagrams). Sie bestehen aus folgenden Elementen: x x x x

Zustände - grafisch

Transitionspfeile

einem Startzustand Zuständen, d.h. einem Objekt in verschiedenen Zuständen Zustandsänderungen, Zustandsübergängen einem Schlusszustand

Die Zustände werden durch Rechtecke mit abgerundeten Ecken dargestellt, die Transitionen durch Pfeillinien zwischen diesen Rechtecken, wobei das Rechteck am Pfeilanfang den Zustand des Objekts vor der Transition (Ausgangszustand) und das am Ende des Pfeils den Zustand nach der Transition (Schlusszustand) darstellt. Die Beschriftung der Rechtecksymbole für Zustände kann unterschiedlich sein. Im einfachsten Fall steht die Bezeichnung des Zustandes in der Mitte des Rechtecks. Vgl. das einführende Beispiel. Die Pfeile für die Transitionen sind beschriftet mit, wobei einige der Angaben optional sind: x x x

dem auslösenden Ereignis, einer Bedingung (in eckigen Klammern), einer Aktion, die im Zuge der Transition auszuführen ist, z.B. Anfrage eingetroffen [Produkt lieferbar]/liefern

Das Zustandsübergangsdiagramm insgesamt beginnt mit einem Startsymbol und endet mit dem Endesymbol (vgl. die nächste Abbildung).

15.2 Einführende Beispiele

471

15.2 Einführende Beispiele Die beiden Beispiel sind einführend und deshalb einfach gehalten. Zuerst ein Beispiel aus dem Bereich der Systemanalyse bzw. des Software Engineerings, dann eines mit Bezug zu Geschäftsprozessen. Beispiel 1 Das Objekt, um das es geht, ist wiederum ein Geldautomat. Die Rechtecke mit abgerundeten Ecken repräsentieren Zustände, die Pfeile Transitionen (Zustandsübergänge). Falls es von einem Rechteck aus mehrere Pfeile gibt, sind diese beschriftet, wodurch festgelegt wird, welcher gewählt wird bzw. welche Transitionen zur Verfügung stehen. Der eingeschwärzte Kreis links oben symbolisiert den Start – mit dem Zustand wähleBetrag wird der Zustandsautomat aktiv. Von diesem Zustand aus gibt es drei mögliche Transitionen. Kommt es zu einem gültigen Auszahlungsbetrag ist der Automat mit seinen Aktivitäten am Ende (eingeschwärzter Kreis mit Rand), der Transitionspfeil führt zu einem Symbol, das das positive Ende signalisiert. Wird keiner der angeführten Beträge gewünscht (andererBetrag) geht es weiter zum Zustand eingebenBetrag. Die dritte Transition signalisiert, dass dem Nutzer auch die Möglichkeit des Abbruchs gegeben wird. Der Pfeil führt zu einem Grafikelement, das den Abbruch symbolisiert. Ein weiterer Zustand hat mehrere abgehende Transitionen: eingebenBetrag. Entweder klappt die Eingabe des Betrags, dann drückt der Transitionspfeil das positives Ende aus, oder es kommt zum Abbruch, dann führt der Transitionspfeil zu dem entsprechenden Element.

Abbildung 15.2-1:

Objekt Geldautomat

Ein Zustand, drei Zustandsübergänge (Transitionen)

Zustandsautomat LeseBetrag Quelle: [OMG 2003a, S. 510, Figure 398] Übersetzung durch den Verfasser

Liegt mehr als eine abgehende Transition vor (wie in der Abbildung bei wähleBetrag), dann sind die Transitionen alternativ und können daher als durch ein exklusives Oder verknüpft angesehen werden. Was an diesem Beispiel auffällt, ist der dynamische Charakter der Zustände. Tatsächlich stellen einige von ihnen Aktivitäten (im allgemeinen Sinn) dar und nicht Zustände, die – umgangssprachlich aufgefasst – fix

Zustände mit Aktivitäten

472

15 Zustandsautomaten

sind. Dies ist tatsächlich möglich, wie die genauere Beschreibung der Zustände unten zeigt. Beispiel 2 Objekt Kundenanfrage

Das zweite Beispiel ist thematisch näher bei Geschäftsprozessen angesiedelt. Es geht um eine Kundenanfrage (vereinfacht). Diese stellt also das Objekt dar, dessen Zustände betrachtet werden. Der Kunde fragt an, ob ein bestimmtes Produkt geliefert werden kann. Die Anfrage ist damit im Zustand zu bearbeiten. Sobald ein Sachbearbeiter diese Anfrage bearbeitet und die grundsätzliche Machbarkeit bejaht, wird ihr Zustand auf in Arbeit verändert. Nun wird nacheinander zuerst die Produktionskapazität und der Materialbestand geprüft, was den Zustand der Anfrage jeweils etwas verändert. Die letztere Prüfung setzt außerdem den Zustand auf erledigt. Hier entsprechen die Zustände schon eher als im obigen Beispiel dem, was man sich im allgemeinen darunter vorstellt.

Abbildung 15.2-2:

Zustandsübergangsdiagramm Kundenanfrage

Soweit die Grundstruktur. Im folgenden wird diese nun schrittweise erweitert und vertieft.

15.3 Zustände 15.3.1 Definition Zustand

Ein Zustand, so die UML-Autoren, modelliert eine Situation, in der einige (normalerweise implizite) Bedingungen stabil sind [OMG 2003a, S. 477]. Mit „implizit“ ist hier gemeint, dass es sich um Bedingungen „innerhalb“ des Zustandes handelt, nicht um die der „Umwelt“. So wie oben kann man „Zustand“ tatsächlich beschreiben. Nehmen wir wieder einen Geldautomat. Er beginnt mit einem Wartezustand: Bereit,

15.3 Zustände

473

EC-Karte zu lesen. Nach dem Einlesen der Karte (dem Ereignis) kommt er in den Zustand „Nutzer identifizieren, konkret: Geheimzahl anfordern“. Usw. Der Zustandsübergang wurde also durch das Ereignis Karte eingesteckt, Karte gelesen ausgelöst und ist mit einer Aktion verbunden, dem Einlesevorgang. Dazwischen verharrt er im jeweiligen Zustand. Tatsächlich kann es aber, wie oben einführend dargestellt, in einem Zustand auch darum gehen, eine kurze Folge von Aktionen zu realisieren. Dazu unten mehr. Anmerkung: Die Begriffe „Aktion“ und „Aktivität“ werden hier, wenn nicht ausdrücklich anders vermerkt, im umgangssprachlichen Sinn gebraucht und nicht im Sinne der Kapitel 11 und 12. 15.3.2 Zustände in Zustandsautomaten Anmerkungen: Die Ausführungen dieses Abschnitts beziehen sich nur auf Verhaltenszustandsautomaten (behavioral state machines). Bei Verhaltenszustandsautomaten (behavioral state machines) liegen statische oder dynamische Bedingungen vor. Meist eine statische Situation, z.B. so, dass ein Objekt darauf wartet, dass ein externes Ereignis eintritt. Es kann aber auch dynamische Bedingungen modellieren. Z.B. die Durchführung einer Aktivität. Letzteres bedeutet: Das betrachtete Modellelement kommt in den Zustand, wenn die Aktivität beginnt und verlässt ihn, sobald die Aktivität vollendet ist. Dies erweitert das Grundkonzept doch sehr stark, denn hier ist dann tatsächlich mit dem Zustand auch eine Aktivität verbunden. Ein erstes Beispiel dafür war schon das einführende von Abbildung 15.2-1. Liest man die Bezeichnungen der Zustände, wähleBetrag und eingebenBetrag, wird das deutlich. Die Kantenbeschriftungen, bei wähleBetrag sind dies Betrag, andererBetrag, Abbruch, verdeutlichen dies noch, geben sie doch Ergebnisse an und solche gibt nur von Tätigkeiten. Dies verwischt ein wenig den Unterschied zwischen Transitionen und Zuständen. Z.B. kann damit eine Aktivität „Karte lesen“ bei einem Geldautomaten auch als Zustand definiert werden: Objekt ist im Zustand „lesend“. Vertex = Gipfel, Zenit Die Zustände werden in Zustandsübergangsdiagrammen ja durch die Knoten repräsentiert. In ihrem Kapitel zu den Zustandsautomaten verwenden die UML-Autoren den Begriff „vertex“ bzw. in der Mehrzahl „vertices“ für die Knoten. Sie definieren ihn als Abstraktion eines Knoten und führen aus, dass er Quelle oder Ziel beliebiger Transitionen sein kann.

Statische Situation oder Dynamische Bedingung

Aktivität im Zustand!

474

Knoten (vertex)

15 Zustandsautomaten

Dieser Begriff ist notwendig weil, wie wir unten sehen werden, ein Zustand hier nicht nur ein einfacher Zustand, sondern ein tief strukturiertes Gebilde sein kann. Der sprachlichen Einfachheit halber wird in dieser Arbeit dafür der Begriff Knoten verwendet. Regionen

Grafische Darstellung von Regionen

Zustände oder Zustandsautomaten können untergliedert werden. Einen dadurch entstehenden Teil (orthogonal part) nennt man Region. Sie enthält ebenfalls Zustände und Transitionen. Der Zustand insgesamt wird durch die Bildung von Regionen zu einem zusammengesetzten Zustand (composite state). Die Aufteilung eines Zustandes oder eines Zustandsautomaten in Regionen wird grafisch durch gestrichelte Linien dargestellt. Vgl. die folgende Abbildung. Jede Region kann einen Namen haben und enthält die verschachtelten nicht überlappenden Zustände und die Übergänge zwischen diesen. Der Bereich mit der Bezeichnung des gesamten Zustandes wird, wie in der folgenden Abbildung gezeigt, angefügt.

Abbildung 15.3-1:

Darstellung eines zusammengesetzten Zustandes (eines Zustandes mit Regionen)

Zustandstypen Wie oben schon angedeutet ist ein Zustand nicht einfach ein Zustand, sondern kann Strukturen aufweisen. Folgende Zustandstypen werden in der UML unterschieden: x x x Einfacher Zustand (simple state) Zusammengesetzter Zustand

einfacher Zustand (simple state) zusammengesetzter Zustand (composite state), mit den Untertypen einfacher zusammengesetzter Zustand (simple composite state) und orthogonaler Zustand (orthogonal state) Zustand, der einen Zustandsautomaten enthält (submachine state)

Ein einfacher Zustand hat keine Sub-Zustände (substates), d.h. er hat keine Regionen und keinen untergeordneten Zustandsautomaten (vgl. unten) Ein zusammengesetzter Zustand (composite state) enthält entweder genau eine Region oder ist zerlegt in eine oder mehr orthogonale Regionen (vgl. unten). Orthogonal bedeutet: Jede Region hat eine Menge von Knoten,

15.3 Zustände

475

die sich gegenseitig nicht überschneiden und eine Menge von Transitionen. Jeder Zustand, der in einer Region eines zusammengesetzten Zustandes ist, wird Sub-Zustand (substate) dieses zusammengesetzten Zustandes genannt. Er wird direkter Sub-Zustand (direct substate) genannt, wenn er in keinem anderen Zustand enthalten ist, ansonsten indirekter Sub-Zustand (indirect substate). Jede Region eines zusammengesetzten Zustandes kann am Anfang einen Pseudozustand (vgl. unten) haben sowie einen Schlusszustand. Vgl. für einen Zustand mit zwei Zuständen Abbildung 15.3-17 und für einen orthogonalen Zustand mit Regionen Abbildung 15.3-12. Der dritte Zustandstyp, der oben aufgelistet wurde, Zustand der einen Zustandsautomaten enthält (submachine state), wird unten erläutert. Schlusszustand Bei einem Schlusszustand (FinalState) handelt es sich um eine spezielle Art von Zustand, dessen Eintreten bedeutet, dass die übergeordnete Region (enclosing region) vervollständigt ist. Falls die übergeordnete Region direkt in einem Zustandsautomaten enthalten ist und dessen andere Regionen ebenfalls vervollständigt sind, dann bedeutet es, dass der ganze Zustandsautomat vervollständigt ist. Für einen solchen Schlusszustand gelten dann folgende Bedingungen. Er hat … x x x x x x

keine wegführenden Transitionen keine Regionen keine Verweise auf einen untergeordneten Automaten keine Eingangsaktivität (entry activity) keine Ausgangsaktivität (exit activity) keine Zustandsaktivität (state activity)

Ein Schlusszustand wird als Kreis dargestellt, der einen kleineren schwarz eingefärbten Kreis umgibt. Die zugehörige Abschlusstransition des übergeordneten Zustandes wird nicht beschriftet.

Abbildung 15.3-2:

Grafische Darstellung eines Schlusszustandes Quelle: [OMG 2003a]

15.3.3 Pseudozustände Anmerkung: Pseudozustände gibt es nur in Verhaltenszustandsautomaten (behavioral state machines)

Sub-Zustände, direkt und indirekt

Beispiele

476

15 Zustandsautomaten

Ein Pseudozustand (pseudostate) ist eine Abstraktion, die verschiedene Typen von Knoten im Graphen von Zustandsautomaten umfasst. Typischerweise werden sie benutzt, um Transitionen (Zustandsübergänge) in Beziehung zu setzen. Zum Beispiel, indem eine einzelne Transition, die zu einer Gabelung (fork vertex) führt, mit einer Menge von Transitionen kombiniert wird, die von der Gabelung wegführen. Damit erhält man eine Verbundtransition (compound transition), die zu einer Menge von voneinander unabhängigen Zielzuständen führt. Folgende Pseudozustände gibt es: x x x x x x x x x x

Initialknoten (initial vertex) deepHistory (history vertex) shallowHistory (history vertex) Verknüpfer (join vertex) Gabelung (fork vertex) Verbindungsknoten (junction vertex) Auswahlknoten (choice vertex) Einstiegspunkt (entry point) Ausstiegspunkt (exit point) Beenden-Knoten (terminate)

Initialknoten Ein Initialknoten stellt einen voreingestellten Knoten dar, von dem genau eine Transition zum voreingestellten Standardzustand eines zusammengesetzten Zustandes führt. In einer Region kann höchstens ein solcher Initialknoten sein. Grafische Darstellung Ein Initialknoten wird als kleiner schwarz eingefärbter Kreis dargestellt. Für Regionen gilt: Die Transition, die von ihm wegführt, kann mit dem Trigger-Ereignis, das das Objekt erzeugt, benannt werden. Falls es keine Bezeichnung hat, repräsentiert es jede Transition des einschließenden Zustandes. Abbildung 15.3-3:

Grafische Darstellung eines Initialknoten Quelle: [OMG 2003a]

deepHistory-Pseudozustand Geschichte 1 - tief

Ein Pseudozustand des Typs deepHistory repräsentiert die letzte aktive Konfiguration des zusammengesetzten Zustandes, der diesen Pseudozustand direkt enthält. Zum Beispiel die Zustandskonfiguration, die aktiv war, als der zusammengesetzte Zustand zuletzt verlassen wurde.

15.3 Zustände

477

Hier spielt also die zeitliche Dimension eine Rolle. Es geht darum, eine bestimmte Zustandskonfiguration festzuhalten und auch verfügbar zu machen. Ein zusammengesetzter Zustand kann höchstens einen solchen Knoten haben. Höchstens eine Transition darf zum voreingestellten deepHistoryPseudozustand führen. Diese Transition wird genommen, wenn der zusammengesetzte Zustand nie vorher aktiv war. Grafische Darstellung Ein Pseudozustand des Typs deepHistory wird durch einen Kreis dargestellt, in dem sich die Zeichenfolge H* befindet. Er hat Gültigkeit für die Region des Zustandes, in der er enthalten ist.

Abbildung 15.3-4:

Grafische Darstellung eines deepHistory-Pseudozustandes Quelle: [OMG 2003a]

Die UML-Autoren betonen noch, dass in der neuesten Fassung der UML der enthaltende Zustand nicht verlassen werden muss, um deepHistory zu definieren. Dies bedeutet, dass deepHistory Ziel von Transitionen von innerhalb des enthaltenden Zustandes sein kann und nicht nur von Zuständen von außerhalb. shallowHistory-Pseudozustand Ein Pseudozustand des Typs shallowHistory repräsentiert den letzten aktiven Sub-Zustand des Zustandes, der den Pseudozustand enthält, aber nicht die Sub-Zustände dieses Subzustandes. Ein zusammengesetzter Zustand kann höchstens einen solchen Knoten haben. Eine Transition zu dem shallowHistory-Pseudozustand ist gleichbedeutend mit einer Transition, die zu dem letzten aktiven Sub-Zustand eines Zustandes führt. Höchstens eine Transition darf zu dem voreingestellten shallowHistory-Pseudozustand führen. Diese Transition wird in dem Fall genommen, dass der zusammengesetzte Zustand nie vorher aktiv war. Grafische Darstellung Ein Pseudozustand des Typs shallowHistory wird durch einen Kreis dargestellt, in dem sich der Buchstabe H befindet. Er hat Gültigkeit für die Region des Zustandes, in der er enthalten ist.

Abbildung 15.3-5:

Grafische Darstellung eines shallowHistory-Pseudozustandes Quelle: [OMG 2003a]

Geschichte 2 – flach

478

15 Zustandsautomaten

Verknüpfer Verschmelzung

Verknüpfer (join vertices) dienen dazu, mehrere Transitionen zu vereinigen, die von Knoten aus verschiedenen orthogonalen Regionen stammen. Die Transitionen, die zu einem solchen Knoten führen, dürfen keine Wächter oder Trigger haben. Zur grafische Darstellung vgl. den nächsten Abschnitt. Gabelung

Gabelung

Gabelungen (fork vertices) erlauben es, eine ankommende Transition in zwei oder mehr Transitionen aufzuteilen, die bei orthogonalen Zielknoten enden. Mit orthogonalen Knoten sind hier solche gemeint, die sich in verschiedenen Regionen eines zusammengesetzten Zustandes befinden. Die Transitionen, die von einem solchen Knoten weggehen, dürfen keine Wächter oder Trigger haben. Grafische Darstellung Die grafische Darstellung von Gabelungen und Verknüpfern ist wie oben bei den Aktivitäten gezeigt: Ein Balken, zu dem eine Transition hinführt und mehrere weg (Gabelung/fork) oder umgekehrt (Verknüpfer/join). Vgl. die folgende Abbildung für ein Beispiel.

Abbildung 15.3-6:

Grafische Darstellung von Verknüpfern und Gabelungen Quelle: [OMG 2003a, Seite 474, Figure 376]

Verbindungsknoten Semantikfreie Verbindungsknoten

Else-Bedingung

Verbindungsknoten (junction vertices) sind semantikfreie Knoten, die benutzt werden, um mehrere Transitionen zu verketten. Sie werden benutzt, um Pfade mit Verbundtransitionen zwischen Zuständen zu erstellen. Zum Beispiel kann ein Verbindungsknoten benutzt werden, um mehrere ankommende Transitionen in eine einzige wegführende Transition zusammenzuführen. Umgekehrt können sie auch benutzt werden, um eine ankommende Transition in mehrere wegführende aufzusplitten, die unterschiedliche Wächter-Bedingungen haben. Im letztgenannten Fall sind die wegführenden Transitionen, deren Wächter-Bedingungen FALSE ergeben, abgeschaltet. Ein vordefinierter Wächter, der ELSE genannt wird, kann für höchstens eine wegführende Transition definiert werden. Diese Transition wird aktiv, falls alle anderen Wächter der anderen Transitionen nicht gültig werden.

15.3 Zustände

479

Durch Verbindungspunkte wird ein statisch bedingter Zweig realisiert. Diese unterscheiden sich von dynamisch bedingten Zweigen, die durch Auswahlknoten realisiert werden. Vgl. den nächsten Abschnitt. Grafische Darstellung Ein solcher Verbindungspunkt wird durch einen kleinen schwarzen Kreis dargestellt, wie in der folgenden Abbildung gezeigt.

Abbildung 15.3-7:

Grafische Darstellung von Verbindungsknoten Quelle: [OMG 2003a, Seite 473, Figure 373] Übersetzung durch den Verfasser

Auswahlknoten Auswahlknoten führen zu einer dynamischen Überprüfung der Wächter der Trigger der wegführenden Transitionen. Dadurch wird ein dynamisch bedingter Zweig realisiert. Er erlaubt das Aufteilen von Transitionen in mehrere wegführende Pfade so, dass die Entscheidung, welcher Pfad genommen werden soll, eine Funktion des Ergebnisses früherer Aktionen sein kann, die im selben Schritt ausgeführt wurden. In dieser letztgenannten Eigenschaft steckt das Motiv für die Wahl der Bezeichnung dynamisch bedingter Zweig. Falls mehr als ein Wächter wahr ergibt, wird ein beliebiger genommen. Falls keiner wahr ergibt, ist das Modell fehlerhaft. Um dies zu vermeiden wird empfohlen bei jedem Auswahlknoten eine wegführende Else-Transition zu definieren. Grafische Darstellung Ein choice-Pseudozustand wird als rautenförmiges Symbol dargestellt, zu dem eine Transition führt und von dem mehrere wegegehen.

480

15 Zustandsautomaten

Abbildung 15.3-8:

Grafische Darstellung von Auswahlknoten Quelle: [OMG 2003a, Seite 474, Figure 377]

Alternative für die grafische Darstellung Angenommen, alle Wächter, mit Triggern von Transitionen die von einem choice-Knoten wegführen, sind binäre Ausdrücke mit einem gemeinsamen linken Operanden, dann kann die Darstellung vereinfacht werden. Dann kommt der linke Operand in das rautenförmige Symbol und der Rest des Wächter-Ausdruckes auf die wegführende Transition. Einstiegspunkte Einstiegspunkt

Ein Pseudozustand vom Typ Einstiegspunkt (entry point) stellt einen Zugang in den Zustandsautomaten dar. In jeder Region des Zustandsautomaten gibt es eine einzige Transition zu einem solchen Knoten innerhalb derselben Region. Grafische Darstellung Ein Einstiegspunkt wird als kleiner Kreis auf der Grenzlinie der Abbildung dargestellt. Die Bezeichnung wird angefügt.

Abbildung 15.3-9:

Grafische Darstellung von Einstiegspunkten Quelle: [OMG 2003a, Seite 472, Figure 371]

Ausstiegspunkte Ausgang

Ein Pseudozustand vom Typ Ausstiegspunkt (exit point) markiert einen Ausgang aus dem Zustandsautomaten. Wird ein Ausstiegspunkt in einer Region des Zustandsautomaten erreicht, die sich auf einen Zustand eines untergeordneten Zustandsautomaten bezieht, bedeutet dies, dass dieser Zustand (submachine state) verlassen wird und dass die Transition, die diesen Ausstiegspunkt als Quelle in dem übergeordneten Zustandsautomaten hat, ausgeführt wird. Vgl. hierzu Abschnitt 15.3.5, wo das Konstrukt Zustandsautomat in Zustand erläutert wird. Obige Ausführungen im dortigen Beispiel (Abbildungen 15.3-13 und 15.3-14): Wird der Ausstiegspunkt des Zustandes LeseBetragSM erreicht, wird im Zustandsautomat Geldautomat der Zustand

15.3 Zustände

481

LeseBetrag:LeseBetragSM verlassen und die Transition, die vom Ausstiegspunkt abgebrochen ausgeht, wird ausgeführt. Grafische Darstellung Ein Ausstiegspunkt wird als kleiner Kreis mit einem Kreuz dargestellt und auf der Grenzlinie der Abbildung platziert. Die Bezeichnung wird angefügt.

Abbildung 15.3-10:

Grafische Darstellung eines Ausstiegspunkts Quelle: [OMG 2003a, Seite 472]

Beenden-Knoten Das Erreichen eines Pseudozustandes vom Typ Beenden (terminate) bedeutet, dass die Ausführung des Zustandsautomaten beendet wird. Grafische Darstellung Ein solcher Pseudozustand wird als Kreuz dargestellt. Vergleiche die folgende Abbildung. Abbildung 15.3-11:

Grafische Darstellung eines Knotens vom Typ Beenden Quelle: [OMG 2003a, Seite 473]

15.3.4 Transitionen zu Zuständen Zu einem eingebetteten Zustand Eine Transition zu einem eingebetteten Zustand (enclosing state) ist gleichbedeutend mit einer Transition zum Initialknoten in jeder Region. In der folgenden Abbildung bedeutet somit der Initialknoten links oben, dass alle drei Initialknoten der Regionen aktiv werden und ihre Transitionen losschicken. Zu einem Schlusszustand Eine Transition zu einem Schlusszustand (final state) stellt den Abschluss der Aktivität in der eingebetteten Region dar. Der Abschluss der Aktivität in allen orthogonalen Regionen stellt den Abschluss der Aktivität im gesamten eingebetteten Zustand dar und löst ein Abschlussereignis bezüglich dieses eingebetteten Zustandes aus. Der Abschluss der am weitesten oben angesiedelten Regionen eines Objekts bedeutet seine Beendigung.

Abschluss in verschachtelten Strukturen

482

15 Zustandsautomaten

Im folgenden Beispiel bedeutet dies, dass das Erreichen der drei Schlusszustände in den Regionen zur Beendigung des gesamten eingebetten Zustandes führt, was die Transition zum Zustand Bestanden auslöst. Beispiel Das folgende Beispiel enthält viele der in den letzten Abschnitten besprochenen Elemente und Konstrukte: x x x x

einen orthogonalen Zustand mit Regionen einen Initialknoten, der den eingebetteten Zustand aktiviert Schlusszustände in den Regionen Initialknoten in den Regionen

Abbildung 15.3-12:

Orthogonaler Zustand mit Regionen Quelle: In Anlehnung an [OMG 2003a, S. 486, Figure 386]

Der eingebettete Zustand mit Regionen kann mit zwei verschiedenen Zuständen enden. Entweder positiv, wie oben beschrieben, oder durch Nichtbestehen der Abschlussprüfung. Tritt dies ein, wird die Transition von Abschlussprüfung nach Durchgefallen ausgelöst. 15.3.5 Zustandsautomaten im Zustand Anmerkung: Die Ausführungen dieses Abschnitts betreffen nur die Verhaltenszustandsautomaten (behavioral state machines). Automat im Zustand

Wir haben oben gesehen, dass Zustände nicht einfach Zustände sind (im umgangssprachlichen Sinn), sondern dass sie Tätigkeiten bzw. Tätigkeits-

15.3 Zustände

483

folgen enthalten können. In diesem Abschnitt gehen wir nun noch einen Schritt weiter und betrachten ein Konstrukt, das erlaubt, ganze Zustandsautomaten in einen Zustand einzubetten. Es geht also wiederum um verschachtelte Strukturen. Genauer, um die Verschachtelung von Tätigkeitsfolgen, nicht nur in zwei sondern in beliebig vielen Ebenen. Die Motivation dafür ist klar: Systeme enthalten nun mal Systeme und dies muss auch modelliert werden können. Dieses Enthaltensein wird dann hier über die Zustandsautomaten modelliert. Das zentrale Instrument dabei ist, in einem Zustand eines Zustandsautomaten einen anderen (untergeordneten) Zustandsautomaten zu platzieren. Damit sind dann bereits die ersten zwei Ebenen realisiert. Setzt man dasselbe auch mit dem eingebetteten Zustandsautomaten (auch er hat in einem Zustand wieder einen Zustandsautomaten) fort, ist die dritte Ebene realisiert. Usw. Eine Schwierigkeit hierbei stellt die Verknüpfung dar: Wie werden die beiden Zustandsautomaten, der auf der obersten Ebene und der untergeordnete, miteinander verknüpft? Wie werden die Ergebnisse des im Zustand eingebetteten Zustandsautomaten an den Zustand übergeben, so dass dieser damit mit seinen anderen Zuständen interagieren kann? Da die Erfahrung zeigt, dass diese Thema abstrakt nicht ganz einfach zu verstehen ist, werden die folgenden Ausführungen auch mit einem anschaulichen Beispiel verdeutlicht, das in den nächsten zwei Abbildungen angegeben ist. Beispiel – erste Abbildung Zuerst ein einfacher Zustandsautomat. Er wurde schon oben als einführendes Beispiel verwendet (vgl. die Beschreibung dort). Hier spielt er nun aber eine besondere Rolle, weil er in einem Zustand des nächsten Zustandsautomaten wieder auftritt.

Abbildung 15.3-13:

Zustandsautomat LeseBetragSM Quelle: [OMG 2003a, S. 488, Figure 389] Übersetzung durch den Verfasser

System im System im System im ...

Automat im Automat im Automat im ...

Verknüpfung über Ebenen

484

Zustandsautomat mit einem Zustand, der einen Zustandsautomaten enthält

Beschreibung des Zustandsautomaten

15 Zustandsautomaten

Das Beispiel der folgenden Abbildung zeigt den Zustandsautomaten Geldautomat. Dieser enthält fünf Zustände: x x x x x

PrüfeKarte AußerDienst LeseBetrag:LeseBetragSM PrüfeTransaktion FreigebenKarte

LeseBetrag:LeseBetragSM ist nun genau so ein Zustand, um den es hier geht: er verweist auf einen Zustandsautomaten und zwar auf den der vorigen Abbildung mit der Bezeichnung LeseBetragSM. Insgesamt beschreibt dieser Zustandsautomat einige Aspekte von Geldautomaten. Der Initial-Pseudozustand führt zum voreingestellten Standardzustand, hier PrüfeKarte. Die Transition akzeptiereKarte führt zu dem Zustand, der einen Zustandsautomaten enthält. Zu diesem unten mehr. Von diesem aus gibt es drei mögliche Transitionen, die zur Außerdienstsstellung, zum Abbruch oder zur Prüfung der Transaktion führen. Ein Abbruch oder die Prüfung führen zum Zustand FreigebenKarte. Beispiel – zweite Abbildung

Abbildung 15.3-14:

Zustandsautomat mit untergeordnetem Zustandsautomat und Ausstiegspunkt Quelle: [OMG 2003a, Seite 489 und 510, Figure 390 und Figure 399]

15.3 Zustände

485

Anmerkung: In diesem Abschnitt wird es begrifflich etwas „anstrengend“. Die US-Amerikaner können leichter Substantive mit tief verschachtelter Semantik bilden als wir. So können sie, von submachine ausgehend, die Begriffe submachine state, submachine state machine und submachine composite state machine bilden. Im Deutschen würde sich eine Übersetzung in Substantive merkwürdig anhören: Sub-Zustandsautomat Zustandsautomat. Deshalb wurde für die komplexen Begriffe eine „beschreibende“ Übersetzung gewählt: submachine = untergeordneter Zustandsautomat submachine state = Zustand eines untergeordneten Zustandsautomaten submachine state machine = untergeordneter Automat eines Zustandsautomaten oder auch Sub-Automat eines Zustandsautomaten Doch nun zurück zum Thema dieses Abschnitts, der Einbettung von Zustandsautomaten (die dann quasi untergeordnet sind) in Zustände. Es geht ja zum einen um den (untergeordneten) Zustandsautomaten, der in diesem Zustand enthalten ist. Im Beispiel LeseBetragSM. Zum anderen um den Zustand, der den untergeordneten Zustandsautomaten enthält. Im Beispiel LeseBetrag:LeseBetragSM.

Es ist bei dieser verschachtelten Anordnung durchaus möglich, den Zustand LeseBetrag als Zustand des Zustandsautomaten aufzufassen. Dann wäre LeseBetrag:LeseBetragSM ein Zustand des in ihm eingebetteten Zustandsautomaten LeseBetragSM. In diesem Sinne könnte also auch ein Zustandsautomat einen Zustand haben. So sehen es die UML-Autoren, zumindest deutet es deren Sprachgebrauch an, wenn sie von submachine state und von submachine state machine sprechen: “A submachine state specifies the insertion of the specification of a submachine state machine.” [OMG 2003a, S. 478] Ein Zustand, der einen Zustandsautomaten enthält (submachine state), legt somit fest, wie die Ausprägungen des untergeordneten Zustandsautomaten in den (übergeordneten) Zustandsautomaten eingefügt werden. Der Zustandsautomat (state machine), der den Zustand mit dem untergeordneten Zustandsautomaten (submachine state) enthält, wird der enthaltende Zustandsautomat genannt. Im Beispiel: Geldautomat. Derselbe Zustandsautomat kann - im Rahmen eines einzelnen enthaltenden Zustandsautomaten - mehr als einmal untergeordneter Zustandsautomat

Enthaltender Zustandsautomat

486

15 Zustandsautomaten

(submachine) sein. Im Beispiel: LeseBetrag könnte also mehr als einmal vorkommen. Ein Zustand eines untergeordneten Zustandsautomaten (submachine state) ist gleichbedeutend mit einem zusammengesetzten Zustand. Die Regionen des Zustandsautomaten, der einem anderen untergeordnet ist (submachine state machine), sind die Regionen des zusammengesetzten Zustandes (composite state). Die Eingangs-, Ausgangs- sowie Zustandsaktivitäten sowie die internen Übergänge sind als Teil des Zustandes definiert. Wichtig ist noch die Festlegung, dass ein Zustand nicht gleichzeitig einen Sub-Zustandsautomaten (submachine) und Regionen haben kann. Grafische Darstellung Wie oben schon gesehen, wird ein Zustand mit untergeordnetem Zustandsautomat (submachine state) wie ein normaler Zustand dargestellt. Die Bezeichnung setzt sich aus zwei Teilen zusammen, die durch einen Doppelpunkt getrennt sind: :

„Bezeichnung Zustandsautomat“ meint die Bezeichnung des untergeordneten Zustandsautomaten, auf den verwiesen wird. Ein weiteres Beispiel findet sich in Abbildung: Fehlerbehandlung:FehlerbehandlungSubAutomat

Verknüpfung von übergeordnetem und untergeordnetem Zustandsautomaten

Einstiegs- und Ausstiegspunkte

Verschachtelt man auf diese Weise Tätigkeitsfolgen, muss deren Verknüpfung geklärt werden. Kommt der eingebettete (untergeordnete) Zustandsautomat zu seinem „normalen“ Abschluss, muss dies „nach oben“ deutlich werden, kommt er zu einem anderen, z.B. zu einem Abbruch, ebenfalls. Und dies alles ist in vollem Umfang zu leisten, also auch bei mehreren Ebenen. Diese Verknüpfung von eingebettetem Zustandsautomat mit dem, der ihn enthält (über einen Zustand), geschieht durch Verknüpfungspunkte, die beim grafischen Element für den Zustand festgehalten werden. Im obigen Beispiel ist z.B. der Verknüpfungspunkt abgebrochen vermerkt. Diese Verknüpfungspunkte werden Einstiegs- und Ausstiegspunkte genannt (vgl. oben). Das grafische Element für den Zustand eines untergeordneten Zustandsautomaten kann dann Verweise zu einem oder mehreren solcher Punkte enthalten. Konkret handelt es sich um Pseudozustände, hier zu Ein- und Ausstieg. Sie werden auf der Grenzlinie des jeweiligen Zustandes platziert. Die Pseudozusstände, die beim Zustand angegeben werden, müssen dann natürlich auch beim untergeordneten Zustand vorkokmmen.

15.3 Zustände

487

Im obigen Beispiel: Im untergeordneten Zustandsautomaten LeseBetragSM kommt der Ausstiegspunkt abgebrochen vor. Entsprechend findet sich beim Zustand LeseBetrag:LeseBetragSM ebenfalls dieser Ausstiegspunkt, platziert auf der Grenzlinie. Er kann dann, gemäß seiner Funktion als Pseudostatus, als Quelle einer Transition dienen, so wie im obigen Beispiel. Der Standardweg vom eingebetteten Zustandsautomat (im Beispiel: LeseBetragSM) über den Zustand im übergeordneten Automat (LeseBetrag:LeseBetragSM) zum übergeordneten Zustandsautomaten (Geldautomat) und zurück ist einfacher. Er wird grafisch dadurch ausgedrückt, dass der Transitionspfeil an der Grenzlinie des Zustands mit dem untergeordnten Zustandsautomat (im Beispiel: LeseBetrag:LeseBetragSM) endet, bzw. von diesem ausgeht, ganz ohne Verknüpfungspunkte. Für diesen voreingestellten Standardweg wird der Initialknoten (auch ein Pseudozustand) wirksam. Durch diesen wird der voreingestellte Standardzustand (im Beispiel: wähleBetrag) realisiert. Die Darstellung durch Einstiegs- und Ausstiegspunkte ist auch dann nicht nötig, wenn der untergeordnete Zustandsautomat auf normalen Weg fertig wurde, d.h. über seinen ganz normalen Schlusszustand. Für den Zustand LeseBetrag:LeseBetragSM bedeutet dies, dass bei einem Standardabschluss des untergeordneten Automaten LeseBetragSM der Zustand PrüfeTransaktion angestoßen wird, während bei einem Abbruch der Weg über den Ausstiegspunkt gegangen wird. Ebenfalls keine Einstiegs- und Ausstiegspunkte sind nötig, falls die Beendigung durch eine explizite Gruppentransition (Transition, die von zusammengesetzten Zuständen herrührt. Vgl. oben) erfolgte, die (grafisch) von der Grenze eines von einem untergeordneten Zustandsautomaten herrührenden Zustandes (submachine state) herrührt, was auch bedeutet, dass dies für alle Sub-Zustände (substates) des untergeordneten Zustandsautomaten (submachine) gilt. Dieses Konstrukt, Zustände mit untergeordneten Zustandsautomaten (submachine states), bei denen durch Einstiegs- und AusstiegspunktePunkte die Verknüpfung erfolgt, ist eingeführt worden, um Skalierbarkeit von Zustandsautomaten mit untergeordneten Zustandsautomaten sicherzustellen und um Kapselung (im Sinne der objektorientierten Theorie) zu ermöglichen. Damit (durch die – evtl. rekursive – Abspaltung bestimmter Tätigkeitsfolgen) kann somit die Wiederverwendbarkeit von Modellfragmenten bzw. von Systemkoponenten (nach der Realisierung) gesichert werden.

Standardweg

Zweck

15.3.6 Die Semantik von Zuständen Ein Zustand kann während der Ausführung des Zustandsautomaten aktiv oder inaktiv sein. Er wird aktiv, wenn er als Ergebnis einer Transition eintritt und er wird inaktiv, wenn er durch eine Transition „verlassen“ wird. Ein Zustand kann beendet werden oder eintreten als Ergebnis derselben

Aktiv oder inaktiv

488

15 Zustandsautomaten

Transition. In einem solchen Fall wird die Transition Selbstransition (self transition) genannt. Anfangs- und Schlussaktivität Für jeden Zustand gibt es eine Anfangsaktivität und eine Schlussaktivität. Immer wenn ein Zustand eintritt, führt er seine Anfangsaktivität (entry activity) aus, vor allem anderen. Umgekehrt, wann immer ein Zustand verlassen wird, führt er als letzten Schritt vor dem Verlassen des Zustandes seine Schlussaktivität (exit activity) aus. Zustandsaktivität Anmerkung: Der Begriff „Aktivität“ wird hier im allgemeinen Sinn verwendet, nicht im Sinn von Abschnitt 12.

Ruhezustand und Aktivität

Zwischen der Anfangs- und der Schlussaktivität muss sich ja auch noch etwas tun. Dieser Teil der Aktivität eines Zustandes wird Zustandsaktivität genannt (Activity in state, do-activity). Sie wird ausgeführt, während der Zustandsautomat im jeweiligen Zustand ist und startet, wenn der Zustand eintritt, nach der Anfangsaktivität. Betrachten wir ein einfaches Beispiel, das auch den dynamischen Zustandsbegriff etwas erläutert: Wenn der Geldautomat in seinem Standardanfangszustand ist, z.B. Warten auf Eingabe, ist dies einerseits ein Ruhezustand. Auf einer tieferen Systemebene muss allerdings die Eingabeeinheit ständig abfragen, ob eine Karte eingesteckt wurde. Z.B. also, ob ein entsprechender Sensor durch das Reinstecken einer EC-Karte aktiviert wurde. Doch nun zurück zu den Aktivitäten zwischen Anfangs- und Schlussaktvität. Falls die Aktivität fertig wird, während der Zustand noch aktiv ist, führt dies zu einem Abschlussereignis (completion event). Für den Fall, dass es eine nach außen führende abschließende Transition gibt, wird der Zustand verlassen. Wird der Zustand als Ergebnis der Aktivierung einer nach außen gehenden Transition vor der Vervollständigung der Aktivität beendet, wird die Aktivität vor ihrer Vervollständigung abgebrochen. Aufgeschobene Ereignisse

Aufgeschobene Ereignisse und Transitionen

Ein Zustand kann eine Menge von Ereignis(typen) festlegen, die für ihn/während seinem Aktivsein aufgeschoben werden. D.h., sie werden nicht zur Wirkung gebracht, wenn der Zustand eintritt und abläuft. Ein Ereignis, das keine Transitionen im jeweiligen Zustand auslöst, wird dann nicht aktiviert, falls sein Typ zu einem der Typen passt, die in der Menge der aufgeschobenene Ereignistypen angegeben sind. Stattdessen verbleibt es im Ereignisraum (UML: event pool, event set) und ein anderes nicht verzögertes Ereignis kommt anstatt seiner zum Einsatz. Dabei bleibt es, bis ein Zustand erreicht ist, in dem entweder das Ereignis

15.3 Zustände

489

nicht mehr aufgeschoben ist oder in dem das Ereignis einen Zustandsübergang triggert. Neudefinition von Zuständen Ein Zustand kann auch neu definiert werden. Voraussetzung ist, dass der Zustand noch nicht beendet ist, d.h., das sein Attribut isFinal auf False steht. Ein einfacher Zustand kann neu definiert werden, um ein zusammengesetzter Zustand zu werden. Er wird damit erweitert und erhält eine Region. Ein zusammengesetzter Zustand kann neu definiert bzw. erweitert werden durch Hinzufügen von x x x x x

Regionen Knoten Zuständen Eingangs-, Ausgangs- und Zustandsaktivitäten (falls der allgemeine Zustand welche hat) und Transitionen zu geerbten Regionen

Die Neudefinition eines Zustandes betrifft den gesamten Zustandsautomaten. Beispiel: Falls eine Zustandsliste als Teil des erweiterten Zustandsautomaten einen Zustand beinhaltet, der neu definiert ist, dann enthält die Zustandsliste für die Erweiterung (extension state machine) den neudefinierten Zustand. Hierarchischer Zustandsautomat In einem hierarchischen Zustandsautomaten (hierarchical state machine) kann mehr als ein Zustand zu einem Zeitpunkt aktiv sein. Ist der Zustandsautomat in einem einfachen Zustand, der in einem zusammengesetzten Zustand enthalten ist, dann sind alle zusammengesetzten Zustände, die entweder direkt oder transitiv den einfachen Zustand enthalten, ebenfalls aktiv. Darüberhinaus gilt, da der Zustandsautomat als Ganzes und einige seiner zusammengesetzten Zustände in dieser Hierarchie orthogonal sein können (d.h. sie enthalten Regionen), das der aktuelle aktive „Zustand“ durch eine Menge von Zustandsbäumen repräsentiert wird, beginnend mit den obersten Zuständen der „Wurzel-Regionen“ runter zu den individuellen einfachen Zuständen auf den Blättern. Ein solcher Zustandsbaum wird als Zustandskonfiguration (state configuaration) bezeichnet. Außer bei der Ausführung eines Zustandsüberganges gelten folgende Invarianten immer für Zustandskonfigurationen: x x

Ist ein zusammengesetzter Zustand aktiv und nicht orthogonal, dann ist genau einer seiner Sub-Zustände (substates) aktiv. Ist der zusammengesetzte Zustand aktiv und orthogonal, dann sind alle seine Regionen aktiv, ein Sub-Zustand (substate) in jeder Region

Zustandskonfiguration

490

15 Zustandsautomaten

Zutritt zu einem nicht-orthogonalen zusammengesetzten Zustand

Voreinstellung

Gezielter Zutritt

Shallow history Eintritt

Deep history – Eintritt

Beim Eintritt in einen zusammengesetzten Zustand werden die folgenden Fälle unterschieden: Der voreingestellte Zugang wird grafisch durch eine ankommende Transition angezeigt, die am äußeren Rand des zusammengesetzten Zustandes endet. In diesem Fall wird die voreingestellte Transition (default transition) genommen. Gibt es einen Wächter auf dem Trigger der Transition, muss er wahr sein. Die Eingangsaktivität des zusammengesetzten Zustandes wird ausgeführt vor der Aktivität, die mit der Starttransition verknüpft ist. Geht die Transition gezielt zu einem bestimmten Sub-Zustand des zusammengesetzten Zustandes, dann wird der Sub-Zustand aktiv und seine Eintrittsaktivität wird, nach der Ausführung der Eintrittsaktivität des zusammengesetzten Zustandes, ausgeführt. Diese Regel gilt rekursiv, falls die Transition auf einem transitiv verschachtelten Sub-Zustand endet. Endet die Transition auf einem shallowHistory-Pseudozustand, wird der aktive Sub-Zustand zum letzten aktiven Sub-Zustand vor diesem Eintritt, es sei denn, der letzte aktive Sub-Zustand ist der Schlusszustand oder falls dieser Zutritt der erste in diesen Zustand ist. In den beiden letztgenannten obigen Fällen erfolgt der Zutritt zum voreingestellten History-Zustand. Das ist der Sub-Zustand, der das Ziel der Transition ist, die vom History-Pseudozustand herrührt. Falls keine solche Transition festgelegt ist, ist die Situation fehlerhaft definiert und der Umgang mit ihr ist nicht festgelegt. Falls der durch die History definierte aktive Sub-Zustand ein zusammengesetzter Zustand ist, dann geht es mit dem voreingestellten Eintritt weiter. Für einen deepHistory-Pseudozustand gilt dasselbe mit der Ausnahme, dass die Regel rekursiv auf alle darunter liegenden Ebenen in der aktiven Zustandskonfiguration angewandt wird. Zutritt zu einem orthogonalen zusammengesetzten Zustand Immer wenn ein orthogonaler zusammengesetzter Zustand betreten wird, wird jede seiner orthogonalen Regionen betreten. Endet die Transition am Rand des zusammengesetzten Zustandes, dann werden auch, mit Hilfe der Voreinstellung, alle Regionen betreten. Falls die Transition gezielt zu einer bestimmten oder zu mehreren bestimmten führt (bei einer Gabelung), dann werden diese Regionen explizit betreten und die anderen nach der Voreinstellung. Verlassen nicht-orthogonaler Zustände Wird ein zusammengesetzter Zustand verlassen, wird der aktive SubZustand rekursiv verlassen. Das bedeutet, dass die Ausgangsaktivitäten nacheinander ausgeführt werden, beginnend mit dem innersten aktiven Zustand in der aktuellen Zustandskonfiguration.

15.3 Zustände

491

Verlassen eines orthogonalen Zustandes Wird ein orthogonaler Zustand verlassen, wird jede seiner Regionen verlassen. Danach werden die Ausgangsaktivitäten des Zustandes ausgeführt. Aufgeschobene Ereignisse Zusammengesetzte Zustände können zu Problemen führen, die mit aufgeschobenen Ereignissen zusammenhängen. Jeder der Sub-Zustände kann ein Ereignis aufschieben oder verbrauchen (consume) und dabei u.U. mit dem zusammengesetzten Zustand in Konflikt geraten. Z.B. dadurch dass ein Sub-Zustand ein Ereignis verzögert, während der zusammengesetzte Zustand es verbraucht, oder umgekehrt. Im Falle eines zusammengesetzten orthogonalen Zustandes können die Sub-Zustände orthogonaler Regionen ebenfalls zu Aufschiebe-Konflikten führen. Die Konfliktbewältigung folgt den Prioritäten für das Auslösen von Transitionen. Dabei gilt, dass verschachtelte Zustände eingeschlossene Zustände überschreiben. Im Falles eines Konflikts zwischen Zuständen in verschiedenen orthogonalen Regionen überschreibt ein verbrauchender Zustand einen aufschiebenden Zustand. Zustand eines untergeordneten Zustandsautomaten Ein Zustand eines untergeordneten Zustandsautomaten (submachine state) ist semantisch gleichbedeutend mit dem zusammengesetzten Zustand, der durch den untergeordneten Zustandsautomaten definiert ist. Erreichen und verlassen des zusammengesetzten Zustandes erfolgt, im Gegensatz zu einem einfachen zusammengesetzten Zustand, mittels Einstiegs- und Ausstiegspunkten.

Hin und weg durch Einstiegs- und Ausstiegspunkte

Erreichen Ein untergeordneter Automat eines zusammengesetzten Zustandsautomaten (submachine composite state machine) kann durch seinen voreingestellten Initialknoten (Pseudozustand) oder durch einen seiner Einstiegspunkte betreten werden. Es kann also sein, dass der Zutritt zu einem nicht-orthogonalen oder einem orthogonalen zusammengesetzten Zustand mit Regionen erfolgen muss. Der Zutritt über den Initialknoten bedeutet dasselbe wie für gewöhnliche zusammengesetzte Zustände. Ein Einstiegspunkt ist gleichbedeutend mit einem Verbindungsknoten (junction vertex) oder einer Gabelung (fork vertex), für den Fall, dass der zusammengesetzte Zustand orthogonal ist. Zutritt über einen Einstiegspunkt bedeutet, dass die Eingangsaktivität des zusammengesetzten Zustandes ausgeführt wird, danach folgen die Transitionen (eine oder mehrere) vom Einsteigspunkt zu dem Zielzustand bzw. den Zielzuständen innerhalb des zusammengesetzten Zustandes. Genau wie für die voreingestellten Starttransitionen müssen die Wächter-Bedingungen der Trigger dieser Starttransitionen wahr sein, damit das Modell fehlerfrei ist.

Zutritt über Initialknoten

492

15 Zustandsautomaten

Verlassen

Verlassen durch Schlusszustand oder Gruppentransition

Auf ähnliche Weise kann es verlassen werden: als Ergebnis davon, dass der Schlusszustand erreicht wird, durch eine Gruppentransition, die für alle Sub-Zustände (des untergeordneten Automaten eines zusammengesetzten Zustandsautomaten) gilt, oder durch irgendeinen seiner Ausstiegspunkte. Das Verlassen durch einen Schlusszustand oder durch eine Gruppentransition hat hier dieselbe Bedeutung wie für einfache zusammengesetzte Zustände. Ein Ausstiegspunkt ist gleichbedeutend mit einem Verbindungsknoten (junction vertex) bzw. Verknüpfer (join vertex) für den Fall, dass der zusammengesetzte Zustand orthogonal ist): Verlassen durch einen Ausstiegspunkt bedeutet, dass die erste Aktivität (ersten Aktivitäten) der Transition (der Transitionen) mit dem Aussteigspunkt als Ziel ausgeführt wird (werden), gefolgt von der Ausgangsaktivität (exit activity) des zusammengesetzten Zustandes. 15.3.7 Grafische Darstellung von Zuständen Einfache Zustände Die Darstellung einfacher Zustände wurde oben ja schon mehrfach gezeigt. Hier nochmals die beiden Grundformen. Sie bestehen aus einem Rechteck mit abgerundeten Ecken und der Bezeichnung des Zustandes entweder in diesem oder in einem separaten Rechteck an der oberen Randlinie. Letztere Lösung wird üblicherweise für die Bezeichnung eines zusammengesetzten Zustandes (composite state) gewählt, der orthogonale Regionen hat.

Abbildung 15.3-15:

Darstellung von Zuständen. Quelle: [OMG 2003a]

Zustände mit Bereichen Auch eine Aufteilung in verschiedene Bereiche (compartments) ist möglich. Die Trennung erfolgt durch eine horizontale Linie. Die folgende Abbildung zeigt ein Beispiel.

15.3 Zustände

Abbildung 15.3-16:

493

Darstellung von Zuständen mit Bereichen Quelle: [OMG 2003a, S. 483, Figure 383]

Mögliche Bereiche eines Zustandes sind: x x x

Namensbereich - für die Bezeichnung (name compartment) Bereich für die internen Aktivitäten (internal activities compartment) Bereich für die internen Transitionen (internal transitions compartment)

Ein zusammengesetzter Zustand hat zusätzlich ein Feld für die Angabe der Zerlegungen (decomposition compartment). Im Namensbereich wird die Bezeichnung des Zustandes festgehalten. Falls es sich um den Zustand eines untergeordneten Zustandsautomaten handelt, wird der Name des entsprechenden Zustandsautomaten als Zeichenfolge angegeben mit einem Doppelpunkt nach der Bezeichnung des Zustandes, wie oben gezeigt. Im Bereich für die internen Aktivitäten steht eine Liste der Aktivitäten oder Zustandsaktivitäten, die ausgeführt werden, wenn der Zustand aktiv ist. Für jede Aktivität gibt es eine Bezeichnung und einen Ausdruck. Die Bezeichnung hält fest, unter welchen Bedingungen die Aktivität aufgerufen wird, der Ausdruck legt die Aktivität fest. Vgl. die obige Abbildung 15.3-16 für ein Beispiel. Einige Aktivitätsbezeichnungen sind reserviert, können also nicht als Ereignisbezeichnungen verwendet werden: x x x

Namensbereich

Bereich für die internen Aktivitäten

entry: Die danach angeführte Aktivität wird nach dem Eintritt in den Zustand ausgeführt (Eingangsaktivität) exit: Die danach angeführte Aktivität wird beim Verlassen des Zustandes ausgeführt (Ausgangsaktivität) do (“do activity”). Die danach angeführte Aktivität wird ausgeführt so lange das modellierte Element im jeweiligen Zustand ist oder solange bis die Berechnungen, die der Ausdruck festlegt, vollendet sind.

Im Bereich für die internen Übergänge steht eine Liste der internen Transitionen. Die Gestaltung ist wie die bei Triggern. Jede Ereignisbezeichnung kann mehr als einmal pro Zustand auftreten, wenn die WächterBedingungen verschieden sind. Die Ereignisparameter und die WächterBedingungen sind optional. Falls das Ereignis Parameter hat, können sie in dem Ausdruck, der die Aktivität festlegt, durch die aktuelle Ereignisvariable genutzt werden.

Bereich für die internen Übergänge

494

15 Zustandsautomaten

Zusammengesetzte Zustände Zerlegungsbereich

Zusammensetzung verbergen

Im Zerlegungsbereich (decomposition compartment) wird der Aufbau des Zustandes durch Regionen, andere Zustände und Transitionen angegeben. Ergänzend kann in einem eigenen Bereich eine Abbildung die Verschachtelung angeben. In einigen Fällen kann es sinnvoll sein, die Zusammensetzung des zusammengesetzten Zustandes zu verbergen. Zum Beispiel können eine große Anzahl von Zuständen in einem zusammengesetzten Zustand verschachtelt sein und einfach nicht alle in den Platz passen, der für die Abbildung zur Verfügung steht. In diesem Fall wird der zusammengesetzte Zustand durch ein einfaches grafisches Symbol repräsentiert, der das Zusammengesetztsein symbolisiert. Dieses Symbol wird üblicherweise im rechten unteren Eck (vgl. Abbildung 15.3-18 für die Darstellung) eingefügt. Die Inhalte des zusammengesetzten Zustandes werden in einer eigenen Abbildung gezeigt. Beispiele

Zustände im Zustand

Das folgende Beispiel zeigt einen zusammengesetzten Zustand mit zwei Zuständen. In den eingebetteten Zuständen sind auch die Eingangs-, Ausgangs- und eine Zustandsaktivität angegeben. Der Zustand beschreibt in einfacher Form das Wählen einer Telefonnumer in klassischen Fernsprechanlagen. Der Initialknoten führt zum ersten Zustand. Er beginnt mit dem Starten des Wähltons (Eingangsaktivität) und endet mit dessen Abstellung (Ausgangsaktivität), wenn die erste Ziffer gewählt wird. Der zweite Zustand beschreibt den Wählvorgang, der – bis die n Ziffern eingegeben sind – dank der Selbsttransition immer wieder startet und endet. Falls die Nummer gültig ist, kommt es zum Schlusszustand.

Abbildung 15.3-17:

Verborgener zusammengesetzter Zustand

Zusammengesetzter Zustand mit zwei Zuständen. Quelle: [OMG 2003a, S. 485, Figure 384] Übersetzung durch den Verfasser

Das zweite Beispiel zeigt einen verborgenen zusammengesetzten Zustand. Das Symbol in der unteren rechten Ecke signalisiert, dass der Zustand im Detail woanders beschrieben ist.

15.3 Zustände

Abbildung 15.3-18:

495

Verborgener zusammengesetzter Zustand Quelle: [OMG 2003a, S. 486, Figure 385] Übersetzung durch den Verfasser

Das nächste Beispiel zeigt ein Fragment eines Zustandsdiagramms in dem auf einen Zustandsautomaten eines Sub-Zustandes (substate machine) verwiesen wird. Entsprechend sind die Bezeichnungen: der Zustand heißt Fehlerbehandlung, es ist ein Sub-Zustand. Der untergeordnete Zustandsautomat hat die Bezeichnung FehlerbehandlungSubAutomat, er ist an anderer Stelle spezifiziert. Insgesamt hat das Element dann die Bezeichnung Fehlerbehandlung:FehlerbehandlungSubAutomat. Betrachten wir die Verknüpfung zwischen den zwei Ebenen, die ankommenden und die wegführenden Transitionen. Die ankommenden geben sozusagen den Input für den Sub-Zustandsautomaten an, die wegführenden seinen Output. Zuerst die ankommenden Transitionen. Die Transition, die durch das Ereignis „error1“ ausgelöst wird, endet bei Einstiegspunkt „Sub1“ des Zustandsautomaten FehlerbehandlungSubAutomat. Sie muss also dort vorliegen. Die Transition "error3”, die auf der Grenzlinie endet, führt dazu, dass die voreingestellte Transition dieses Sub-Zustandsautomaten benutzt wird. Bei den wegführenden zeigt das Beispiel folgendes: Die Transition, die von dem Ausstiegspunkt subEnd ausgeht, führt die Aktivität „fixed1“ aus, in Ergänzung zu dem, was in dem Sub-Zustandsautomaten ausgeführt wird. Diese Transition muß innerhalb des FehlerbehandlungSubAutomat ausgelöst worden sein. Zu guter Letzt stellt dann noch die Transition, die von der Grenzlinie des Zustandes ausgeht, ein Ergebnis des Abschlussereignisses (completion event) dar. Das Abschlussereignis wird erzeugt, wenn der Zustandsautomat FailureSubmachine seinen letzten Zustand erreicht hat. Das Symbol rechts unten gibt an, dass der Aufbau des zusammengesetzten Zustandes an dieser Stelle verborgen wird (vgl. oben).

Zustandsautomat eines Sub-Zustandes

Ankommende Transitionen

Abgehende Transitionen

Verborgener zusammengesetzter Zustand

496

15 Zustandsautomaten

Abbildung 15.3-19:

oo153 Zustandsautomat eines Sub-Zustandes Quelle: [OMG 2003a, S. 487, Figure 387]

15.4 Transitionen Hier nun, zusammengefasst und vertiefend, einige Anmerkungen zu Transitionen. Definition Von einem Zustand in den nächsten

Eine Transition ist eine gerichtete Beziehung zwischen einem Quell- und einem Zielknoten. Sie kann Teil einer Verbundtransition sein, die den Zustandsautomat von einer Zustandskonfiguration in eine andere bringt und die damit die vollständige Antwort des Zustandsautomaten auf ein bestimmtes Ereignis darstellt. Auch hier gibt es Wächter die das Aktivieren der Transition überwachen. Der Wächter kommt zum Einsatz, wenn ein Ereignis durch den Zustandsautomaten ausgelöst wird. Ergibt die Prüfung den Wahrheitswert wahr, wird die Transition aktiviert, ansonsten wird sie nicht ausgeführt. Wächter dürfen keine Seiteneffekte haben. Der Quellknoten einer Transition kann ein Zustand oder ein Pseudozustand sein. Folgende Einschränkungen gelten: x x x x x

Eine Gabelung oder eine Verknüpfung darf keine Wächter oder Trigger haben. Eine Gabelung muss immer zu einem Zustand führen. Ein Verknüpfer muss immer von einem Zustand kommen. Transitionen, die von einem Pseudozustand ausgehen, dürfen keine Trigger haben. Eine Starttransition auf der obersten Ebene (Region eines Zustandsautomaten) hat entweder keinen Trigger oder einen der Form create.

15.4 Transitionen

497

Gruppentransitionen Transitionen, die von zusammengesetzten Zuständen (composite states) herrühren, werden Gruppentransitionen (group transitions) genannt. Wenn sie ausgelöst sind, verlassen sie die Sub-Zustände des zusammengesetzten Zustandes indem sie ihre Ausgangsaktivitäten ausführen. Dies beginnt mit den innersten Zuständen der aktiven Zustandskonfiguration. Eine solche Transition mit einem Ziel außerhalb des zusammengesetzten Zustandes bedeutet, dass die Ausgangsaktivität des zusammengesetzten Zustandes ausgeführt wird. Ist das Ziel innerhalb, geschieht dies natürlich nicht. Verbundtransitionen Von únd zu einer Menge von Zuständen Eine Verbundtransition (compound transition) stellt einen semantisch vollständigen Pfad aus einer Transition oder aus mehreren dar. Er kommt von einer Menge von Zuständen (im Gegensatz zu Pseudozuständen) und zielt auf eine Menge von Zuständen. Damit stellt eine Verbundtransition eine azyklische ununterbrochene Kette von Transitionen dar, die mittels der Pseudozustände Verknüpfer, Verbindungspunkt, Auswahlknoten oder Gabelung verknüpft sind und die den Weg von einer Menge von Quellzuständen zu einer Menge von Zielzuständen angeben. Für Selbsttransitionen stellt derselbe Zustand die Quell- und die Zielmenge dar. Eine einfache Transition, die zwei Zustände verbindet, ist somit ein Sonderfall einer Verbundtransition. Interne Transitionen Eine interne Transition wird ausgeführt, ohne den Zustand, in dem sie definiert ist, zu verlassen oder wieder zu betreten. Dies gilt auch, falls der Zustandsautomat in einem verschachtelten Zustand ist. Abschlusstransitionen und Abschlussereignisse Eine Abschlusstransition (completion transition) ist eine Transition, die als Quelle einen zusammengesetzten Zustand, einen Zustand mit untergeordnetem Zustandsautomaten oder einen Ausstiegspunkt hat. Sie hat keine expliziten Trigger, obwohl ein Wächter definiert sein kann. Wenn alle Transitionen, Eingangsaktivitäten und Zustandsaktivitäten im jeweiligen aktuellen Zustand erledigt sind, wird ein Abschlussereignis (completion event) erzeugt. Dieses Ereignis ist der implizite Trigger für eine Abschlusstransition. Das Abschlussereignis tritt vor allen anderen Ereignissen im Ereignisraum ein und hat keine Parameter. Zum Beispiel wird eine Abschlusstransition, die von einem orthogonalen zusammengesetzten Zustand ausgeht, automatisch aktiviert, sobald alle orthogonalen Regionen ihren Schlusszustand erreicht haben. Sind mehrere Abschlusstransitionen für einen Zustand definiert, dann sollten sie sich gegenseitig ausschließen (über die Wächter-Bedingungen).

Transitionen von zusammengesetzten Zuständen

498

15 Zustandsautomaten

Wächter (Guard)

Mehrere Wächter

In einer einfachen Transition mit einem Wächter wird dieser ausgewertet bevor die Transition ausgelöst wird. In Verbundtransitionen mit mehreren Wächtern werden alle geprüft bevor eine Transition ausgelöst wird, es sei denn es gibt Auswahlknoten entlang einem Pfad oder entlang mehrerer. Die Abfolge, in der die Wächter ausgewertet werden, ist nicht definiert. Gibt es Auswahlknoten in einer Verbundtransition werden nur die Wächter ausgewertet, die davor liegen, gemäß obiger Regel. Wächter nach einem Auswahlknoten werden ausgewertet, falls und wenn der Knoten erreicht wird (nach der gleichen Regel wie oben). Mit anderen Worten: Für die Auswertung von Wächtern hat ein Auswhalknoten denselben Effekt wie ein Zustand. Wächter dürfen keine Ausdrücke enthalten, die Seiteneffekte verursachen. Ausführung von Transitionen

Wirkung von Transitionen

Jede Transition, mit Ausnahme von internen und lokalen Transitionen, verursacht zweierlei: Das Verlassen eines Quellzustandes und das Eingehen eines Zielzustandes. Diese zwei Zustände, die zusammengesetzt sein können, werden als die Hauptquelle und das Hauptziel einer Transition bezeichnet. Der LCA-Zustand (LCA= least common ancestor/letzter gemeinsamer Vorgänger) einer Transition ist der niedrigste zusammengesetzte Zustand der alle expliziten Quellzustände und alle expliziten Zielzustände der Verbundtransition enthält. Im Falle von Verbindungspunkten werden nur die Zustände, die in Beziehung stehen zum dynamisch ausgewählten Pfad, als explizite Ziele betrachtet, d.h., umgeleitete Zweige werden nicht betrachtet. Falls der LCA nicht ein orthogonaler Zustand ist, ist die Hauptquelle der Transition ein direkter Sub-Zustand des letzten gemeinsamen Vorgängers, der die expliziten Quellzustände enthält, und das Hauptziel ist ein Sub-Zustand des letzten gemeinsamen Vorgängers, der die expliziten Zielzustände enthält. Für den Fall, dass der LCA ein orthogonaler Zustand ist, sind Hauptquelle und Hauptziel der orthogonale Zustand selbst. Der Grund ist: Wird eine orthogonale Region verlassen, muss der gesamte orthogonale Zustand verlassen werden.

15.5 Ereignisraum und Ereignisverarbeitung In diesem Abschnitt werden zum Gesamtkonzept der Zustandsautomaten, das ja oben schon hinreichend beschrieben wurde, einige ergänzende Anmerkungen gemacht.

15.6 Protokollzustandsautomaten

499

Ereignisraum Das Konzept des Ereignisraumes wurde schon mehrfach bei den einzelnen Konstrukten erwähnt. Für einen Zustandsautomaten ist der Ereignisraum der der Instanz gemäß dem Verhaltens-Classifier (behaviored context classifier) oder dem Classifier, zu dem das Verhaltensmerkmal gehört, für das der Zustandsautomat eine Methode ist. Ereignisverarbeitung Wie werden die Ereignisse verarbeitet? Die Vorstellung der UMLAutoren ist, dass der Zustandsautomat die Ereignisse eintreten lässt. Die Reihenfolge in der sie abgearbeitet werden, ist nicht definiert, wodurch die Möglichkeit bleibt, verschiedene auf unterschiedlichen Prioritäten beruhende Abläufe zu modellieren. Die Semantik der Ereignisverarbeitung basiert auf der run-to-completion – Annahme. Diese sagt, dass ein Ereignis nur dann vom Ereignisraum genommen und realisiert werden kann, falls die Verarbeitung des vorigen aktuellen Ereignisses vollständig fertig ist. An dieser Stelle ihres Textes geben die UML-Autoren Hinweise auf die Realisierung dieser run-to-completion-Verarbeitung in Programmen. Für aktive Klassen kann sie durch eine Ereignisschleife, die in ihrem eigenen Thread läuft und dabei Ereignisse von einem Pool liest, realisiert werden. Für passive Klassen kann sies als Monitor implementiert werden. Die Verarbeitung eines einzelnen Ereignisses durch eine state machine ist bekannt als run-to-completion step. Vor dem Beginn eines run-tocompletion step ist der Zustandsautomat in einer stabilen Zustandskonfiguration bei der alle Eingangs-, Ausgangs- und internen Aktivitäten vervollständigt sind (aber nicht notwendigerweise die Zustandsaktivitäten). Die gleichen Bedingungen gelten, wenn der run-to-completion step vervollständigt ist. Auf diese Weise wird ein Ereignis nie verarbeitet, während der Zustandsautomat in einem Zwischenzustand oder in einer inkonsistenten Situation ist. Der run-to-completion step ist die Passage zwischen zwei Zustandskonfigurationen des Zustandsautomaten.

15.6 Protokollzustandsautomaten Zustände Zwei Unterschiede gibt es zwischen Zuständen in Verhaltens- und in Protokollzustandsautomaten: x

Einige Elemente von Verhaltenszustandsautomaten gibt es bei Protokollzustandsautomaten nicht: Eingangsaktivität (entry), Ausgangsaktivität (exit), Zustandsaktivität (do).

Eins nach dem anderen

500

x

15 Zustandsautomaten

Zustände in Protokollzustandsautomaten können eine Invariante haben. Deren textliche Bezeichnung wird nach oder unter der Bezeichnung des Zustandes in eckigen Klammern angegeben (vgl. die folgende Abbildung).

Abbildung 15.6-1:

Darstellung eines Zustandes in einem Protokollzustandsautomaten Quelle: [OMG 2003a, Seite 489, Figure 391] Übersetzung durch den Verfasser

Transitionen Eine Protokolltransition legt eine zulässige Transition für eine Operation fest. Transitionen von Protokollzustandsautomaten haben die folgenden Informationen: eine Vorbedingung (Wächter), einen Trigger und eine Nachbedingung. Jede Protokolltransition steht mit keiner oder einer Operation in Beziehung, die zum Kontext-Classifier (context classifier) des Protokollzustandsautomaten gehört. Zustandsautomaten Ein Protokollzustandsautomat wird immer in Zusammenhang mit einem Classifier definiert. Er legt fest, welche Operationen des Classifiers in welchem Zustand und unter welchen Bedingungen aufgerufen werden können, wodurch auch die erlaubten Aufruffolgen auf den Operationen des Classifiers festgelegt werden. Damit gibt ein Protokollzustandsautomat die möglichen und erlaubten Transitionen auf den Instanzen seines KontextClassifiers an, zusammen mit den Operationen, die die Transitionen „tragen“. Auf diese Weise kann ein Lebenszyklus einer Instanz für einen Classifier erzeugt werden, indem die Reihenfolge, in der die Operationen aktiviert werden können und die Zustände, die eine Instanz im Laufe seiner Existenz erlebt, festgehalten werden. Folgende Einschränkungen gelten: x x

Ein Protokollzustandsautomat darf nur einen Kontext-Classifier haben, keinen Verhaltens-Kontext (behavioral feature context). Den letztgenannten haben dagegen die Verhaltenszustandsautomaten. Alle Transitionen von Protokollzustandsautomaten müssen Protokolltransitionen sein.

Der Protokollzustandsautomat definiert alle erlaubten Transitionen für jede Operation. Er muss alle Operationen repräsentieren, die eine bestimmte Zustandsänderung für eine Klasse erzeugen können. Operationen, die keine Transitionen erzeugen, werden in dem Protokollzustandsautomaten nicht dargestellt.

15.7 Zustandsautomaten und Prozessmodellierung

501

Die Interpretation von Protokollzustandsautomaten kann unterschiedlich sein: x x

Deklarative Protokollzustandsautomaten, die für jede Operation die zulässigen Transitionen festlegen. Die genauen Bedingungen für das Auslösen der Transitionen werden nicht festgelegt. Ausführbare Protokollzustandsautomaten, die alle Ereignisse, auf die ein Objekt reagieren und mit denen es umgehen kann, festlegen und die auch noch die damit zusammenhängenden Transitionen angeben. In diesem Fall sind die zulässigen Transitionen für Operationen genau die ausgelösten Transitionen.

Die Darstellung für beide Interpretationen ist dieselbe. Der Unterschied besteht darin, dass die zweite die dynamischen Aspekte betont. Grafische Darstellung Die Darstellung von Protokollzustandsautomaten ist der von Verhaltenszustandsautomaten sehr ähnlich. Das Schlüsselwort {protocol} wird bei der Bezeichnung des Zustandsautomaten platziert.

Abbildung 15.6-2:

Protokollzustandsautomat Tür Quelle: [OMG 2003a, S. 466, Figure 364] Übersetzung durch den Verfasser

15.7 Zustandsautomaten und Prozessmodellierung Die Zustandsautomaten stellen, neben den Aktivitäten, das Konstrukt dar, das die größte Nähe zur Beschreibung von Geschäftsprozessen hat. Dies gilt für die Verhaltenszustandsautomaten, nicht für die Protokollzustandsautomaten. Letztere könnten bei der Geschäftsprozessmodellierung höchstens für eng begrenzte Detaillanalysen sinnvoll sein. Die Verhaltenszustandsautomaten jedoch, von denen hier im weiteren ausschließlich die Rede sein soll, modellieren über das Konzept, in den Zuständen Tätigkeitsfolgen zu erfassen, in der Tat Abläufe und damit u.U. Geschäftsprozesse. Die Ergänzung durch die Pseudozustände erleichtert dies noch, liefert sie doch wenigstens ein einfaches Instrumentarium für die Modellierung von Verzweigungen.

Abläufe in Zuständen

502

15 Zustandsautomaten

Gedämpft wird diese Hoffnung auf Tauglichkeit für die Geschäftsprozessmodellierung vor allem durch die folgenden Eigenschaften: x x Kontrollflusstauglicheit

Objektorientiertheit

Andere Ebene

Verschachtelung

die eingeschränkte Tauglichkeit, Kontrollflüsse in vollem Umfang zu modellieren die Objektzentrierung

Betrachten wir nochmals kurz das Wesentliche der Zustandsautomaten: In den Zuständen wird elementares Verhalten modelliert („Warten auf Benutzereingabe“), deren Ergebnisse führen – modelliert als Zustandsübergänge / Transitionen - zum nächsten Zustand. Alle Zustände betreffen ein und dasselbe Objekt. Damit wird eine sehr elementare Ebene modelliert, eine die sehr nahe am zu erstellenden Programm ist. Dadurch ist es – ähnlich wie bei Aktivitäten – möglich, bei den Aktivitäten auf alternative Ergebnisse (Weiterführungen) weitgehend zu verzichten. Konsequenterweise verzichten die UML-Autoren hier dann auch auf eine ausgefeilte Einbindung von Operatoren. Alles in allem gilt somit: Kontrollflüsse können nur eingeschränkt modelliert werden – nur „im kleinen“. Dies wird noch verstärkt durch die Tatsache, dass ein Zustandsautomat sich jeweils auf ein Objekt bezieht. Diese Einschränkung wäre nicht möglich in der Geschäftsprozessmodellierung. Würden wir als Ausgangspunkt Geschäftsobjekte (business objects) nehmen und das Geschehen rund um ein solches beschreiben, wäre das mit Sicherheit eine aufschlussreiche Detailanalyse (was geschieht mit dem Geschäftsobjekt Kalkulation?), mit einer Geschäftsprozessanalyse hätte es aber nur eingeschränkt zu tun. Mit den Zustandsautomaten wird ganz einfach eine andere Ebene modelliert als in der Geschäftsprozessmodellierung. Das macht im übrigen auch die Wortwahl der UML-Autoren immer wieder deutlich, die meist auf die programmnahe Systemebene ausgerichtet ist. Nur hin und wieder, v.a. auch in den Beispielen, wird Bezug auf Abläufe genommen, die für Geschäftsprozesse typisch sind. Es ist im übrigen nicht verwunderlich, dass die Verschachtelung (von Zuständen / Zustandsautomaten) so stark betont wird. Ohne diese wären Zustandsautomaten nur eine sehr eingeschränkte Angelegenheit. Mit dieser aber und mit einer bereit angelegten obersten Ebene („der ganze Geldautomat“) kann hier umfassend Systemverhalten beschrieben werden. Bis zur Programmebene, bzw. (bei technischem Gerät) bis zur technischen Realisierung.

16 Gesamteinschätzung

16.1 Kontrollflusskonzept Wie sieht es nun aus mit der Tauglichkeit der UML-Konsstrukte für die Prozessmodellierung? Ein großes Defizit früherer Versionen, die kein wirkliches Kontrollflusskonzept131 hatten, wurde in der Version 2.0 durch die Aktivitäten beseitigt. Mit ihnen ist es möglich, wenn auch inhaltlich und grafisch umständlich, Ablauffolgen zu modellieren. Dies gilt im übrigen nicht für die Zustandsautomaten. Das Konzept der Modellierung dynamischer, tief verschachtelter Aspekte taugt nur für sehr spezielle Fälle in der Prozessmodellierung. Es bleibt aber der Gesamteindruck. dass die UML in erster Linie für das Softwareengineering entwickelt worden ist, auch wenn der Anspruch ein umfassenderer ist (vgl. das Zitat am Beginn des Abschnitts 9.2). Dementsprechend beschreiben die in den Kapiteln 11 bis 15 angeführten Modellkonzepte wichtige Aspekte von Systemen und Systemverhalten und bereiten damit hervorragend die Systemrealisation durch Programmierung vor. Die Kapitel sollten aber deutlich gemacht haben, dass sie nicht Geschäftsprozesse als solche beschreiben, zumindest nicht so, wie wir es inzwischen von Ereignisgesteuerten Prozessketten gewohnt sind. Eine Ursache ist, dass das eigentlich für die Darstellung des Kontrollflusses gedachte Konzept (Aktivitäten) in der modelltechnischen Aufteilung von Tätigkeit und Ergebnis und der damit verbundenen Einbindung von Operatoren unhandlich ist. Außerdem ist es der eigentlichen objektorientierten Theorie aufgepfropft und nicht sehr mit den übrigen Konstrukten verbunden. Die hier deutlich gewordene Schwierigkeit der objektorientierten Theorie hat eine tief im objektorientierten Ansatz liegende Ursache. Objekte mit ihren Klassen können zusammenwirken, z.B. durch den Austausch von Nachrichten (wie oben gezeigt), und man kann damit auch zielgerichtetes Handeln im Kleinen (im System) modellieren. Es fehlt aber die übergeordnete Ebene, die „steuernde Hand“ des Kontrollflusses. Dafür gibt es kein im Kern des objektorientierten Ansatzes integriertes Konzept und 131 „Im kleinen“ lag natürlich schon immer etwas vor, was man als Kontrollfluss bezeichnen könnte. Wenn man den Nachrichtenverkehr zwischen gemeinsam agierenden Klassen modelliert, entsteht auch so etwas wie ein Kontrollfluss.

In erster Linie Softwareengineering

Kontrollfluss durch Nachrichten?

504

16 Gesamteinschätzung

deshalb müssen die oben beschriebenen, dem objektorientierten Ansatz zum Teil aufgepfropften Konstrukte zur Beschreibung dynamischer Aspekte hinzugefügt werden. Es kann somit ohne Einschränkung Oestereich zugestimmt werden, der in Bezug auf die Geschäftsprozessmodellierung ausführt: „Dennoch erreichen die verfügbaren UML-Mittel noch nicht die Ausdrucksstärke und Universalität wie etwa ereignisgesteuerte Prozeßketten und Werkzeuge wie ARISToolset.“ [Oestereich 1999, S. 79]

16.2 Verhaltensbegriff

Funktion außengerichtet

Verhalten innengerichtet

Deterministisch?

Wie ja oben schon mehrfach angeprochen, kann die unterschiedliche Ebene, auf der die objektorientierte Theorie in der UML-Ausprägung und die Ereignisgesteuerten Prozessketten Abläufe modellieren, auch am Verhaltensbegriff verdeutlicht werden. Wenn wir bei Ereignisgesteuerten Prozessketten von einer Funktion sprechen, dann denken wir an eine Tätigkeit, die von einer Aufgabe herrührt, und die einen Teil der Leistung des gesamten Geschäftsprozesses darstellt. Der „Methode EPK“ entsprechend beschreiben wir die konkrete Leistungserbringung „innerhalb“ der Funktion fast nicht, nur die innere Struktur (Teilaufgaben / alternative Ergebnisse / ... ) wird durch verknüpfte Ereignisse angegeben. Sprechen wir in der objektorientierten Theorie von Verhalten, denken wir an „etwas“ (Classifier, usw.), das Verhalten zeigt. Das „etwas“ ist meistens ein System, z.B. ein Geldautomat, dieses wird untersucht und modelliert. Das Verhalten ist hier Ausdruck von Handeln, von „Erledigen einer Tätigkeit“, von Aufgabenerfüllung. Ist damit Verhalten gleich Funktion? Handelt es sich vielleicht nur um unterschiedliche Sichtweisen? Verhalten vom System aus gesehen, Funktionen von der übergeordneten Tätigkeit aus gesehen, oder liegen grundsätzliche Unterschiede vor? Oben wurde schon angemerkt, dass diese unterschiedliche Ausprägung von unterschiedlichen Blickwinkeln herrührt. Bei der UML die des Softwareingenieurs bzw. des Systementwicklers, bei der EPK die des Geschäftsprozessmodellieres. Insofern liegt zwar tatsächlich eine vergleichbare Struktur vor, allerdings auf verschiedenen Ebenen. Dies äußert sich auch darin, dass die UML-Autoren grundsätzlich von der Berechenbarkeit (Programmierbarkeit) von Verhalten ausgehen. Kein Geschäftsprozessmodellierer käme aber auf die Idee, Funktionen als vollständig „berechenbar“ anzusehen. Der Unterschied kann auch so festgemacht werden: Geschäftsprozesse sind nicht deterministisch, Systeme schon, bzw. sollten es sein.

16.3 Wohltuend abgehoben

505

16.3 Wohltuend abgehoben Verglichen mit den Modellierungskonzepten der UML (für dynamische Aspekte) sind die Ereignisgesteuerten Prozessketten auf eine wohltuende Weise „abgehoben“. Sie konzentrieren sich auf die Metaebene, den Gesamtzusammenhang des jeweiligen Geschäftsprozesses und sind doch so detailliert, dass mit ihnen ohne Schwierigkeit der Bezug zu weiteren wichtigen Elementen der Unternehmensmodellierung (v.a. Datenbanken, aber auch Organisationsstrukturen u.a.) hergestellt werden kann. Sie beschäftigen sich ja auch nicht mit der konkreten Realisierung der Funktionen, stellen somit, um einen Begriff aus dem UML-Umfeld zu verwenden, diesbezüglich einen externe Sicht dar. Geschäftsprozesse bestehen nicht nur aus Systemen. In ihnen finden sich auch Tätigkeiten (Funktionen), die von Menschen realisiert werden. Z.B., aber nicht nur, aus Entscheidungsprozessen. Dies macht bei Ereignisgesteuerten Prozessketten keine Schwierigkeiten, stellt aber (natürlich) den objektorientierten Ansatz vor Probleme. Hier tauchen die beteiligten Menschen nur als Anwender, als Nutzer der Systeme auf. Damit decken die derzeitigen Vorschläge der UML nur einige, wenn auch wichtige Aspekte von Geschäftsprozessen ab und Anwendungsfälle (use cases) sind auf keinen Fall akzeptable Beschreibungen von Geschäftsprozessen. Es überrascht daher nicht, dass die Autoren aus dem Bereich der objektorientierten Theorie, die tatsächlich Geschäftsprozesse im Sinne dieses Buches im Auge haben (unter den Schlagworten Enterprise Modeling bzw. Business Modeling), Erweiterungen der UML vorschlagen und nutzen (z.B. [Eriksson und Penker 2000], [Marshall 2000]) bzw. auf einem so hohen Abstraktionsniveau beschreiben, dass die Schwächen dieser Konzepte nicht deutlich werden. Obiges ist wohl auch der Grund dafür, dass Burkhardt Objekt-ProzessModelle für die objektorientierte Prozessmodellierung vorschlägt (vgl. [Burkhardt 1999, Abschnitt 7.10]). Sie erlauben die Modellierung von Vor- und Nachbedingungen für Prozesse unter Berücksichtigung der beteiligten Objekte und ihrer Attributbelegungen. Zusammenfassend kann festgehalten werden, dass sich die Methoden (Ereignisgesteuerte Prozessketten und UML) auf hervorragende Weise ergänzen. In einer modernen Unternehmensmodellierung können die Ereignisgesteuerten Prozessketten den Gesamtzusammenhang des zielgerichteten Handelns, auch das Miteinander von Menschen und Systemen, modellieren, während die objektorientierte Systemanalyse die Konkretisierung vornimmt: bezüglich der informationellen Basis (den Datenbanken), aber auch bezüglich der mitwirkenden Systeme und damit der bereits automatisierten Geschäftsprozessabschnitte.

Nicht nur Systeme

Nicht genügend

Objekt-ProzessModelle

Skizze einer zeitgemäßen Unternehmensmodellierung

17 Glossar

Ablauforganisation „Unter Ablauforganisation versteht man die Gestaltung von Arbeitsprozessen. ... Man unterscheidet (1) die Ordnung des Arbeitsinhalts, (2) die Ordnung der Arbeitszeit, (3) die Ordnung des Arbeitsraumes, (4) die Arbeitszuordnung“ >Wöhe 1993, S. 196@. Aufbauorganisation Mit Aufbauorganisation ist die Zerlegung der Gesamtaufgabe einer Organisation in Teilaufgaben angesprochen. Die Zerlegung muss so erfolgen, dass ein effektives Zusammenwirken bei der Abwicklung konkreter Geschäftsprozesse möglich ist. Mit diesem Begriff bezeichnet man die entstehende Organisationsstruktur als solche wie auch die Tätigkeit des Organisierens selbst: „Erste Aufgabe der Aufbauorganisation (wenn wir sie als Tätigkeit des Organisierens verstehen) ist also die Analyse und Zerlegung der Gesamtaufgabe des Betriebes (Aufgabenanalyse). Die zweite Aufgabe besteht dann darin, die Einzelaufgaben zusammenzufassen, indem „Stellen“ gebildet werden (Aufgabensynthese), wobei sich aus der Aufgabenstellung Beziehungszusammenhänge zwischen diesen Stellen ergeben“ >Wöhe 1993, S. 183@. Bewegungsdaten „Die Bewegungsdaten lassen sich in Transferdaten, die Vormerkdaten und die Archivdaten untergliedern. ... Transferdatenbestände enthalten solche Daten, die von einem Programm generiert oder bearbeitet wurden und nun einem anderen geliefert werden. ..." [Mertens 1995, S. 21f] „Bewegungsdaten sind Daten mit einem zeitlichen Bezug. Sie dienen der chronologischen Speicherung aller Vorgänge und entstehen im Verlauf der Geschäftsprozesse. Typische Bewegungsdaten sind die Kundenaufträge, die Bestellungen oder die Fertigungsaufträge. Inhalte von Bewegungsdaten können Plan- oder Istdaten sein.“ [Hohmann 1999, S. 92f] Siehe auch: Stammdaten

508

17 Glossar

Graph, Graphentheorie Für die Beschreibung im Rahmen des Kontrollflusses benutzen auch die UML-Autoren Begriffe der Graphentheorie. Hier vor allem zwei: - Kanten / edges - Knoten / nodes Ein Graph besteht aus Knoten, die durch Kanten verknüpft sind. Hier in der UML sind die Kanten immer gerichtet, so dass es sich um gerichtete Graphen handelt. Nebenläufigkeit „Haben zwei Aufgaben weder eine direkte noch eine indirekte Verbindung, so sind sie nebenläufig, d.h., sie können nacheinander oder nebeneinander ablaufen.“ [Österle 1995, S. 95] „Die Ablauffolge beschreibt, ob eine Aufgabe nach einer anderen Aufgabe (Präzedenz), gleichzeitig mit ihr (Parallelität) oder unabhängig von ihr (Nebenläufigkeit) ablaufen soll.“ [Österle 1995, S. 51] Organisationseinheit Eine Organisationseinheit ist eine Zusammenfassung von einer oder mehreren Stellen zu einem selbständigen Teil der Organisationsstruktur eines Unternehmens. Referenzmodelle Im Bereich der Betriebswirtschaftlichen Standardsoftware oder ERP-Software ist damit ein abstraktes (nicht auf ein bestimmtes Unternehmen bezogenes) Modell der Unternehmensrealität gemeint. Dabei werden heute, in Anlehnung an Scheer’s Arbeiten, Modelle bzgl. der Datenbanken, der Organisationsstrukturen, der Funktionen (Tätigkeiten) und der Geschäftsprozesse unterschieden. Hier ist dann auch von Unternehmensmodellierung die Rede. Eine Diskussion des Begriffs auf dem allgemeinen Hintergrund der Gestaltung Integrierter Informationssysteme mit weiteren Literaturhinweisen findet sich bei [Hohmann 1999, S. 56ff]. Stammdaten Stammdaten sind Teil der Datenbestände (betriebswirtschaftliche und technische), die ein Unternehmen zur informationellen Absicherung benötigt, und zwar der Teil, der nur in Ausnahmefällen verändert wird. „Die wichtigsten Stammdaten einer integrierten IV sind: Kunden, Lieferanten von Erzeugnissen und Dienstleistungen ..., Teile - unter dieser Bezeichnung sollen Roh-, Hilfs- und Betriebsstoffe sowie Halb- und Fertigfabrikate zusammengefaßt werden -, Stücklisten ..., Arbeitspläne ...., Betriebsmittel, Kostenstellen und Personal.“ [Mertens 1995, S. 21] „Stammdaten unterliegen selten Veränderungen und bilden die Ba-

17 Glossar

509

sis von Integrierten Systemen. Stammdaten sind zustandsorientierte Daten, die der Identifizierung, Klassifizierung und Charakterisierung von Objekten (Sachverhalten) dienen und die über einen längeren Zeitraum hinweg unverändert zur Verfügung stehen. Typische Stammdaten sind Kundenstamm, Lieferantenstamm, Preisund Konditionenstamm, Artikelstamm, Stücklisten, Arbeitspläne, Kostenstellen usw.“ [Hohmann 1999, S. 92] s.a. Bewegungsdaten Stellen Stellen sind die kleinsten organisatorischen Einheiten im Unternehmen. Vorgehensmodelle „Vorgehensmodelle legen für die Aktivitäten, die im Rahmen der Tätigkeit softwareproduzierender Einheiten (SPEs) notwendig sind, deren wechselseitige Beziehungen fest und geben vorgeschriebene Reihenfolgen an.“ Sie bringen auch gleich ein Beispiel: „Das Wasserfallmodell ist das bekannteste Modell zur Softwareentwicklung; es bildet den gesamten Lebenszyklus einer Software durch sequentielle Unterteilung in Phasen ab.“ [Bullinger und Fähnrich 1997, S. 11]. In dieser Arbeit findet sich auch ein Vergleich unterschiedlicher Vorgehensmodelle des Software Engineerings (S. 11ff). Im Umfeld Betriebswirtschaftlicher Standardsoftware wird ebenfalls von Vorgehensmodellen gesprochen, im Sinne von Vorschlag für die Einführung. Bekanntestes Beispiel ist das Vorgehensmodell der SAP für die Einführung von R/3. Wertschöpfung Eigentlich bedeutet Wertschöpfung: „Beitrag, den ein Unternehmen zum Bruttoinlandsprodukt beiträgt“ [Schneck 1998, S. 779]. Die Betriebswirtschaftslehre versteht unter Wertschöpfung das Betriebsergebnis abzüglich externer Vorleistungen [Stahlknecht 1995, S. 235]. Steinbuch definiert wie folgt: „Wertschöpfung wird üblicherweise als Differenz von Betriebsertrag und Vorleistungen definiert.“ Er führt die Definition des Verband Deutscher Maschinenbauanstalten (VDMA) an: Wertschöpfung = Betriebsertrag – Vorleistungen [Steinbuch 1998, S. 33]. Im Zusammenhang dieser Arbeit ist der Begriff von Bedeutung für das Konzept der Wertschöpfungskette. Wertschöpfungskette Der Begriff Wertkette oder Wertschöpfungskette (value chain) geht auf Porter zurück (vgl. [Porter 1985], [Porter 1998]). Die Wertschöpfungskette besteht aus neun Firmenaktivitäten, die zur Herstellung und Wertsteigerung eines Produkts beitragen (einschließlich der Realisierung einer Gewinnspanne). Grob sind die Firmen-

510

17 Glossar

aktivitäten unterteilt in ausführende Aktivitäten (auch primäre genannt), die direkt mit Herstellung, Vertrieb, usw. verbunden sind (z.B. Beschaffung, Vertrieb, Produktion) und sekundäre, mit denen die ausführenden unterstützt werden (Finanzwesen, Controlling, Personalwesen, usw.). Es versteht sich, dass Wertschöpfungsketten auch Geschäftsprozesse sind (vgl. auch [Teufel und Keller 1997, S. 43], [Stahlknecht 1995, S. 235] sowie für eine Kurzdarstellung [Schneck 1998, S. 779]).

18 Index

1 zu 1-Beziehung 285 1 zu c-Beziehung 285 1 zu cm-Beziehung 285 1 zu m-Beziehung 285 1. Integrationsaspekt 38 2. Integrationsaspekt 38 4-Augen-Prinzip 245 Abhängigkeit vom Softwarehersteller 42 Abläufe 250 Ablauforganisation Definition 5 Ableiten von Kernprozessen 13 Abstrakte Datentypen 322 abstrakte Klasse 335 accept signal action 409 AcceptEventAction 413 Definition 409 grafische Darstellung 410 Start 410 action execution 412 Definition 364, 412 activity edge 378, Siehe Aktivitätskante ActivityFinal Definition 401 ActivityGroup 390 actors 461 Aggregation 342 aggregation relationship 325 Aggregation von Funktionen 61 Aggregationsklasse 338 Aggregierender Beziehungstyp 286 Ähnlichkeit von Entitätstypen 290 Akteure 461

grafische Darstellung 462 Aktion Definition 361 grafische Darstellung 362 Start 365 Aktionen Vor- und Nachbedingungen (lokale) 363 Aktionen und Variable 366 Aktionsknoten 374 Definition 375 aktives Data Dictionary 300 Aktivitätskante 364, 378 Aktivitätskante mit Gewichtung Beispiel 379 Aktivitätskanten 372 Aktivitätsknoten 372 Alles nur Objekte? 324 alt (InteractionOperator) Beispiel 452 Alternatives Beispiel 438 alternatives (alt) 437 Definition 438 alt-Operator Beispiel 450 Analyse der Strukturen 251 Änderungsvorschläge bzgl. Betriebswirtschaftlicher Standardsoftware 43 Angebotsentscheidung 149 angehängter Subprozess 262 Definition 111 Anwenderfunktionen 464 Anwendungsfalldiagramm Beispiel 463 Anwendungsfälle

512

18 Index

Definition 455 Architektur integrierter Informationssysteme 27 ARIS-Konzept 2, 59 Beschreibung 27 ARIS-Toolset 31, 244 assertion Definition 441 assertion (assert) 437 Assoziation 325, 326 in der Metamodellierung der UML 444 n-äre 328 rekursive 332 ternäre 328 Attribut 283 Attributbasierte Datenbankansätze 289, 290 Attribute objektwertige 326 Attributkonzept 313 Aufbauorganisation Definition 5 Aufbauorganisation vs. Prozessstruktur 242 Aufeinanderwirken von Tätigkeiten 229 Aufgabe des Referenzmodells 249 Aufgaben 5 aufgerufene EPK 110 Aufruf einer Aktivität Beispiel 423 aufrufende Aktion 415 aufrufende EPK 110 aufrufenden Aktion 381 Aufspaltung Kontrollfluss durch Operatoren 106 Auftragsabwicklung EPK 164 Auftragsabwicklung (Beispiel) 164 Auftragsabwicklung (EPK) 164 Aufwand der Aktualisierung von EPK’s 232 Ausgehende Beziehungen 284

auslösende Ereignisse 81 Ausnahmeanmerkung 385 Ausstiegspunkt (Zustandsautomat) 486 Auswahl Objektknoten grafische Darstellung 377 Auswahlverhalten Definition 376 Automatisierungsgrad Beispiel 216 Automatisierungsgrad von Geschäftsprozessen 14 Basiselemente des SAPAnsatzes 249 Bedingungen in EPK‘s 162 Bedingungen für Betriebswirtschaftliche Standardsoftware 34 Beenden einer Aktivität 401 behavioral feature 382 Beispiel Aktivitätskante mit Gewichtung 379 alt (InteractionOperator) 452 Alternatives 438 alt-Operator 450 Anwendungsfalldiagramm 463 Aufruf einer Aktivität 423 Auftragsabwicklung 164 CombinedFragment 453, 438, 452, 440 critical 440 DecisionNode 393, 404, 420, 421, 425, 426 Extend-Beziehung 460 extensioin point 460 ForkNode – Knoten 404, 396, 396, 421, 425, 426 Gewichtung (weight attribute) 398, 412, 420 ignore / consider (InteractionOperator) 453 ignore / consider 440 Include-Beziehung 461

18 Index

Initialknoten 425 Initialknoten 426 Initialknoten 494 InteractionConstraint 452 InteractionFragment mit assert 453 InteractionOccurrence 449 InteractionOccurrence 450 InteractionOperand separator 452 InteractionOperand 452 JoinNode mit JoinSpezifikation 399 JoinNode 397, 398, 412, 425, MergeNode 395, 425, 426 MergeNode+DecisionNode 396 Nachrichten in einem Sequenzdiagramm 436 Objektfluss zwischen Knoten 382 Objektfluss 381 Objektknoten mit Klassendiagramm 386 Objektknoten 384 Objektknoten 398 Objektknoten 421 opt-Operator 449 parallel (par) 440 Pins ohne Kanten 386 ref-Operator 449 ref-Operator 450 Schlussknoten AF 404, 421, 425, 426 Schlussknoten FF 404 Schlusszustand 494 Signal-Token 398 standalone pin 383 Startknoten (initial node) 401 StateInvariant 453 streaming mit Pins 385 streaming 384 Wächter 418 wait time action 411 wait time action 412 Zustand von Objekten 382

513

Zustandsautomat 471 Beispiel eines Geschäftsprozesses 24, 25 Beispiele für Haupt- und Kernprozesse 13 Bereich eines zusammengesetzten Zustandes Zerlegungsbereich 494 Bereich eines Zustandes für die internen Aktivitäten 493 für die internen Übergänge 493 Namensbereich 493 Bereiche eines Zustandes 493 Beschreibungsebenen 28 Betriebliche und überbetriebliche prozessorientierte Software 55 betriebswirtschaftlich relevante Objekte 23 Betriebswirtschaftliche Problemstellung 29 Betriebswirtschaftliche Standardsoftware 1, 38 als prozessorientierte Software 34 Definition 33 Einführung 48 Grundannahme 34 Name 1 nötige Kompetenz 42 Parametrisierbarkeit 36 Beziehung 283 externe 288 Beziehung zwischen zwei Funktionen 230 Beziehungen 284 ausgehende 284 eingehende 284 Beziehungen zwischen Flüssen (UML) 415 Beziehungsklasse (in objektorientierter Datenmodellierung) 329

514

18 Index

Beziehungsklassen in objektorientierter Datenmodellierung 329 Beziehungstyp 284 Beziehungstypen 285 big bang 52 Branchenlösungen 56 Branchensoftware Definition 38 Break Definition 439 Break (break) 437 Buchungskreis Definition 297 Business Navigator 254 Business Objects 7, 210 bei SAP 302 Business Objekt 303 bei SAP 302, 303 bei SAP - grafische Darstellung 302 Business Objekte 250 Business Process Reengineering 18, 22 CallEvent 409 ChangeEvent 409 Chevronsymbol 274 Classifier 358 Definition 357 CombinedFragment Beispiel 452 CombinedFragment assert Beispiel 453 CombinedFragments Beispiel 440 Definition 436 ConnectableElement 434 vs Lifeline 434 ConnectableElements 444 consider (InteractionFragment) Beispiel 453 Constraints in der Metamodellierung der UML 444 continuous behavior 384

control edge Siehe KontrollKante control edges 380 critical Beispiel 440 critical region Definition 440 critical region (critical) 437 Customizing Definition 39 D efinition Aufbauorganisation 5 Data Dictionary 300 aktives 300 Definition 280 integriertes 300 Data Modeler 284 Data Warehouse – Technologien 244 DataStore 377 Datenbankansätze attributbasierte 289 Datenbankdesign 280 Datenbanken zeitgemäße Auffasssung 280 Datenbankobjekte vs Realweltobjekte 344 Datenfluss 60 Datensicht 27, 30 decision input behavior 393, 394 grafische Darstellung 393 DecisionNode Beispiel 393, 404, 420, 421, 425, 426 grafische Darstellung392, 393 Definition Ablauforganisation 5 Aktionsknoten 375 alternatives (alt) 438 angehängter Subprozess 111 assertion 441 Branchensoftware 38 Break 439 Buchungskreis 297 critical region 440 Data Dictionary 280

18 Index

Eingefügter Subprozess 111 Entität 283 Entitätstyp 283 Geschäftsprozess 9 Individualsoftware 38 Kapselung 232 Kardinalität 285 Kernprozesse 11 loop 441 Mandant 297 Medienbrüche 243 Operator negative (neg) 440 option (opt) 438 Organisationsbrüche 244 par 439 Programmierbereich 1 35 Programmierbereich 2 36 strict sequencing 439 Stückliste 172 unabhängige Ereignisse 93 Vorgang 60 weak sequencing 439 Definition von Geschäftsprozessen durch BSSW 23 Definition von Geschäftsprozessen entlang Betriebswirtschaftlicher Standardsoftware 231 Definitionen von Geschäftsprozessen Gemeinsamkeiten 7 Defizit der „Methode EPK“ 168 Detaillierung 232 Detaillierungsgrad 24, 131, 186, 197, 232 Detaillierungsgrad der Modellierung 145 Detaillierungsgrad von Geschäftsprozessen 23 disjunkte Spezialisierung 291 Dokumentarische Aufgabe von EPK’s 233 Durchdringung mit Informationstechnologien 40

515

durchschnittlicher Geschäftsprozess 35, 39 DV-Durchdringung 40 DV-Konzept 28 Dynamisch vs statisch 310 dynamische Aspekte 250 dynamischer Zustandsbegriff 488 Echtzeitanwendungen 346 Effizienz des Ressourceneinsatzes 241 Eigenschaften heutiger Geschäftsprozesse 34 Eigenschaften von Geschäftsprozessen 14 Eignung prozessorientierter Software 41 Eignung von EPK’s 243 einfache Ereignisgesteuerte Prozesskette 80 Einführung Betriebswirtschaftlicher Standardsoftware 48 Eingefügter Subprozess 197, 203, 208, 256, 261 Beispiel 256 Definition 111 Eingehende Beziehungen 284 Einstellungsverfahren 195 Einstiegspunkt (Zustandsautomat) 486 Elementaraufgaben Definition 5 Elementarfunktionen 30 Elemente von Ereignisgesteuerten Prozessketten 60 encapsulation 318, 342 Endereignis 63 Enterprise Resource Planning Software 33 enthaltender Zustandsautomat Definition 485 Entität 282, 283 Definition 283 Entitäten 283

516

18 Index

Entitätstyp Definition 283 existenzabhängiger 284 existenzunabhängiger 284 referierter 284 Entitätstypen grafische Darstellung 294 entity 282, 358 Entity Relationship Modelle 280 Entscheidungsfunktion 96, 99 EPK’s 59 dokumentarische Aufgabe233 Zeitachse 135 zeitliche Dimension 77 Ereignis als Feststellung 63 Beendigung mehrerer Funktionen 100 externes 133 syntaktisch bedingtes 162 Ereignis als logische Aussage 234 Ereignis startet Funktionen 94 Ereignisgesteuerte Prozessketten 59 als semi-formale Methode 59 Elemente 60 Ereignisraum 488, 497, 499 Definition 414 eines Zustandsautomaten 499 Ereignisraum eines Unternehmen 190 Ereignisraum eines Unternehmens 63, 154, 205, 230 Ereignisse 80, 408 Abschluss von Tätigkeiten 89 auslösende 81 Definition 62 erzeugte 81 gemeinsame Bedingungen 84 Ereignisse (Unabhängige) Definition 93 Ereignisse als Bedingungen 83 Ereignisse in der UML Liste 408

Ereignisverknüpfung 205 Ereignisverknüpfung mit auslösenden Ereignissen 83 Ereignisverknüpfung mit erzeugten Ereignissen 89 Ergebnisereignis 146, 160, 186 Ergebnisereignisse 96, 139 Beispiel 211, 213, 227 ERM 280 ER-Modelle 27 ERP-Software 1, 33 erweiterte Ereignisgesteuerte Prozesskette 80 Erweiterung der EPK-Notation 210 Erweiterung der Notation 184, 230 erzeugte Ereignisse 81 EventOccurrence Definition 409 Definition (bei Sequenzen) 432 Executing behavior Beschreibung 353 ExecutionOccurrence Definition 442 existenzabhängiger Entitätstyp 284 Existenzabhängigkeit 286, 288 existenzunabhängiger Entitätstyp 284 exklusives ODER 99, 101, 114, 148, 184 Beispiel 89, 125, 139 Beispiele 83, 89, 95, 100 Extend - Beziehung zwischen Anwendungsfällen 459 Extend-Beziehung Beispiel 460 extension point Beispiel 460 Externe Beziehung 288 externes Ereignis 133, 166 Externes Ereignis Zeitpunkt 136

18 Index

Fachkonzept 28 Fehlende Entscheidungsfunktion 95 Fehlerquelle 145 Zeitspanne modellieren 195 Flexibilität Verlust durch Software 41 FlowFinal Definition 401 flussabwärts wartende Join 418 Flussmodelle in Aktivitäten 372 ForkNode Beispiel 396, 404, 421, 425, 426 grafische Darstellung 392 formal vs formell VIII formelle Strukturen 15, 170 Fremdbestimmung durch Betriebswirtschaftliche Standardsoftware 42 Funktion mit zwei Bedeutungen 176 Funktionen Aggregation 61 Definition 6, 60 durch UND verknüpft 135 Funktionsbäume 30 Funktionsbeziehungen 230 funktionsorientierte Software 33 Funktionsorientierung vs Prozessorientierung 21 Funktionssicht 27, 30 Gate 436 Gefahren der Prozessorientierung 242 Gegensatz dynamisch vs statisch 251 gemeinsames Zeitfenster 135 Generalisierung 290, 334 Generalisierung / Spezialisierung in der Metamodellierung der UML 444 Generalisierung/Spezialisierung 290

517

Geschäftsobjekt Beispiel 210 Geschäftsobjekte 7, 64 Geschäftsprozess Beispiel Angebotserstellung 24 Beispiel Auftragsabwicklung 25 Definition 8 durchschnittlicher 39 durchschnittlicher 35 Träger 240 Geschäftsprozess und Arbeitsteilung 9 Geschäftsprozessanalyse Exaktheit der Methode 22 Geschäftsprozessdefinition 9 Becker und Vossen 8 Hammer und Champy 9 Hess 7 Keller und Teufel 8 Mertens 8 Rump 8 Geschäftsprozesse 2 Automatisierungsgrad 14 Beispiele 10 Datenintegration 14 Definition durch Betriebswirtschaftliche Standardsoftware 23 Definition entlang Betriebswirtschaftlicher Standardsoftware 231 Detaillierungsgrad 23 die das Unternehmen verlassen 240 Eigenschaften 14, 34 Komponenten 15 Länge 23 Prozessintegration 14 Streuung 35 unterstützende 11 Geschäftsprozesskarten 464 Gewichtung (weight attribute) Beispiel 398, 412, 420 Gleichheit vs. Identität 323

518

18 Index

grafische Darstellung Akteure 462 Strichmännchen 462 Grenzen der Prozessorientierung 21 Grenzen von Geschäftsprozessen 23 Grundlage betriebswirtschaftlicher Standardsoftware 39 Gruppentransition 487 Definition 497 Hardwarebedarf 44 Hauptprozesse 11, 13 Beispiele 13 Hierarchiediagramme 30 hierarchischer Beziehungstyp 285 Hierarchischer Zustandsautomat 489 Hinweis Operatorkreis 83 History-Zustand, voreingestellter Definition 490 host object 353 Identität vs. Gleichheit 323 identity equality 323 ignore / consider Beispiel 440, 453 ignore / consider (ignore) 437 Immatrielle Informationsobjekte 184 Include - Beziehung use case 461 Include-Beziehung Beispiel 461 Individualsoftware Definition 38 Industry Solutions 56 information hidding 343 informationelle Strukturen 250 Informationsflüsse 244 Informationsobjekte 64, 80, 146 Definition 64 Modellierung 244

Informationsobjekte (die transportiert werden) 210 Informationsstrukturen 249 Informationsträger 65, 283 in der objektorientierten Modellierung 313 Informationsweitergabe 213 informelle Beziehungen 15 Initialknoten Beispiel 425, 426 InitialKnoten Beispiel 494 InitialNode grafische Darstellung 392 Initial-Pseudozustand 484 Innovation durch Standardsoftware 43 Innovationen durch Betriebswirtschaftliche Standardsoftware 43 Input für Aktionen 364 Input-Pin 364 Input-Pins 412 instantiation 321 Instantiierung 321 Instanz 319 Definition 321 Integration der Informationssysteme verschiedener Unternehmen 44 integriertes Data Dictionary 300 InteractionConstraint Beispiel 452 InteractionFragment mit assert Beispiel 453 InteractionOccurrence Beispiel 449, 450 InteractionOperand Beispiel 452 InteractionOperand separator Beispiel 452 interactionOperator Definition 436 Liste 436 Interaktion

18 Index

Definition 444 Interaktionen abstraktes Konzept 443 Interaktionsdiagramme grafische Darstellung 448 interleaving Definition 433 ISO-Zertifizierung 48 Ist_ein - Beziehung 334 JoinNode Beispiel 397, 398, 412, 425 grafische Darstellung392, 397 JoinNode mit Join-Spezifikation 399 Beispiel 399 Kapselung 131, 154, 229 Beispiel 131, 165 Definition 232 objektorientiert 318, 342 Probleme 230 Kapselung contra Modellierung 165 Kardinalität Definition 285 Kardinalität der Beziehung 284 Kategorien bilden 321 Kein Alternativereignis 233 Keine Zeitspanne modellieren 195 Kernbereich von Geschäftsprozessen Definition 35 Kernkompetenzen 12 Kriterien 12 Kernprozesse 11 Ableiten 13 Beispiele 13 Definition 11 Klassenattribute 319 Klassenbezogene Methoden 320 Klassenbildung 283, 321 Klassenhierarchie 334 Klassenobjekt 322 Klassifikation 321 kleiner Dienstweg 241

519

Know How - Transfer ins Unternehmen 43 Kompetenzfalle 58 komplexe Objekte 342 Komplexitätsfalle 36, 43 Komplexitätsfalle 2 56 Komponenten von Geschäftsprozessen 15 Komponentenklasse 338 Konnektor 380 Kontrolle nach Erledigung 229 von Arbeitsfortschritten 229 Kontrolle vs. Optimierung 245 Kontrollfluss 60, 62, 111, 117, 119, 120, 125, 126, 133, 134, 136, 137, 138, 146, 148, 162, 168, 180, 188, 198, 200, 207, 208, 259, 262, 267 Aufspaltung durch Operatoren 106 Beispiel 119 Beispiel für Zusammenführung 114 Beispiele 73 Definition 68, 80, 106 grafische Anordnung 67 in Aktivitäten 372 zeitliche Dimension 77 Kontrollflusskanten 375 Kontroll-Kante Definition 364 Kontrollkanten 380 Kontrollknoten 374 grafische Darstellung 392 Kontrolltoken 380, 416 Konzept der Entwickler Betriebswirtschaftliche Standardsoftware 247 Kopierprodukt 55 Kriterien für Kernkompetenzen 12 Kundennutzen 20 Länge von Geschäftsprozessen 23 Lebenszyklus eines Objekts

520

18 Index

Definition 469 Leerzweig 108 Leerzweige 233 Leidensdruck 243 Liegezeiten 174, 184 Lineare und sequenzielle Grundstruktur von Ereignisgesteuerten Prozessketten 230 logische Aussage Ereignis 234 logische Ebene 281 loop Definition 441 loop (loop) 437 Lücke Überwindung 46 Lückenbewältigung 46 Machbarkeitsprüfung 146 Mahnliste 154 Mandant Definition 297 materielle Informationsobjekte 184 Medienbruch 158 Beispiel 150, 195 Medienbrüche 14, 244 Definition 243 Mehrere Operatoren hintereinander 134 Mehrfacharbeit 243 mehrfache Vererbung 337 Mehrfachstückliste Definition 172 Mehrfachvererbung 337 menschgestützte Informationsweitergabe 244 Menschgestützte Rechnerkommunikation 243 Menschgestützte Unterprogrammkommunikati on 243 MergeNode Beispiel 395, 425, 426 Definition 394 grafische Darstellung392, 395

MergeNode+DecisionNode Beispiel 396 Metamodellierung 324 Metamodellierung der UML 358 Metamodellierung der UMLAutoren Beschreibung am Beispiel Interaktionen 443 Methode EPK 59, 113, 160, 241, 243 Defizit 168 Eignung 243 Methoden 313, 314, 345 in der objektorientierten Datenmodellierung 313 klassenbezogene 320 Methoden – Operationen Nachrichten 345 Methoden und abstrakte Datentypen 322 Methoden und Operationen 314 Modelle von Geschäftsprozessen 34 Modellierungsebene 165, 166, 231 Montage und Versand EPK 164 multiple inheritance 337 Muss-Assoziationen 327 n:m-Beziehungen 285, 293 Nachbedingung (Aktivitätsdiagramm) 420 Nachricht Definition 345 Nachrichten 345 sich überholende 436 Nachrichten in einem Sequenzdiagramm Beispiel 436 Nachrichtensequenz 346 n-äre Assoziationen 328 Negation eines Ereignisses 234 Negative (neg) 437 object flow edges 380 object flows 380 Objekt 283

18 Index

Definition 282 Zustand 343 Objekt oder Eigenschaft? 316 Objektbegriff 282, 317 Objekte Definition 315, 316 im objektorientierten Ansatz 313 komplexe 342 Objektfindung 317 Objektfluss Beispiel 381 Objektfluss zwischen Knoten Beispiel 382 Objektflusskanten 375, 380 Objektidentifizierer 323 Objektklasse Definition 319 Objektknoten 374 Beispiel 384, 398, 421 Objektknoten mit Klassendiagramm Beispiel 386 Objektmodell Definition 309 Objektorientierung 309 Objektwertige Attribute 326 ODER 89, 92, 121, 123, 148, 159, 262 Beispiel 139 Beispiele 85, 91, 98, 103 ODER-Operator Beispiel 139 OID 323 Operationen 313, 314, 345 Operator negative Definition 440 Operatoren hintereinander 134 Verknüpfer 67 Verteiler 67 Optimierung vs. Kontrolle 245 Optimierungspotenzial 190, 208 Optimierungspotenziale 186 option (opt) Definition 438

521

Option (opt) 437 Optionale Ereignisse Diskussion 233 opt-Operator Beispiel 449 Organisationsbrüche 15 Definition 244 Organisationseinheiten 80 Organisationssicht 27, 30 Organisationsstrukturen 297 Orientierung an Prozessen 21 orthogonale Regionen Definition 474 Output für Aktionen 364 Output-Pin 364 Output-Pins action execution 413 owning object 409 par Definition 439 parallel (par) Beispiel 440 Parallel (par) 437 Parallelität beim UND-Operator 97 Parallelität (beim UNDOperator?) 91 Parameterbereich von Geschäftsprozessen Definition 35 Parametrisierbarkeit 36 part_of-Beziehung 338 physische Ebene 281 Pin Definition 364 Pins ohne Kanten Beispiel 386 Pragmatik bei der Erstellung von EPK's 126 Primitive actions Definition 365 Problem durch Kapselung 230 Profilverlust 36, 45, 46 Programmierbereich 1 Definition 35

522

18 Index

Programmierbereich 2 Definition 36 Protokoll Definition 345 Protokoll-Zustandsautomat Definition 469 Prozessintegration 20 Prozessmodell 247 Prozessorientierte Aufbauorganisation 20 Prozessorientierung Definition 19 Gefahren 242 Grenzen 21 Voraussetzungen 21 Prozessorientierung und Kundennutzen 20 Prozessorientierung vs Funktionsorientierung 33 Prozessverantwortliche 143 Prozesswegweiser 110, 256, 261 Beispiel 114, 162, 203, 208 Beispiele 195 Prozesswegweiser in der Praxis 197 Realweltobjekte vs Datenbankobjekte 344 Referenzen zwischen Objekten 326 Referenzmodell 247 Referierter Entitätstyp 284 ref-Operator Beispiel 449, 450 Regeln für den Aufbau von EPK’s 80 Region Definition 474 Regionen eines Zustandsautomaten 474 Rekursive Assoziation 332 Rekursive Aufrufe 112 Relationale Datenbank 249, 251 Relationales Datenmodell 280, 281 Relationen 249 relationship 282

Releasewechsel 46, 47 Repetitive Handlungen 130 repetitive Schleife Beispiel 131 Ressourcensicht 27 Rückschleife Beispiel 148 Syntax 125 Rücksprung durch einmalige Wiederholung 127 mit Kontrolle 127 Rücksprung (UML) Beispiel 425 run-to-completion – Annahme 499 run-to-completion – Verarbeitung 499 run-to-completion step 499 SAP R/3 13, 35, 113, 145, 249, 252, 280, 294 Business Objects 302 Mandantenfähigkeit 297 Modellinformationen 264 SAP R/3-EPK Grunddatenbearbeitung 115 Kontaktbearbeitung – Teil 1 118 Kontaktbearbeitung – Teil 2 120 Kontaktbearbeitung – Teil 3 121 Kontaktbearbeitung – Teil 4 122 Kontaktbearbeitung – Teil 5 123 Kontaktbearbeitung (Übersicht) 117 Lieferantenstammbearbeitung 116 Stellenbeschreibung – Teil 1 257 Stellenbeschreibung – Teil 2 258 Stellenbeschreibung – Teil 3 259

18 Index

SAP R/3-Geschäftsprozesse 126 SAP-Dialekt 254 SAP-SERM 249, 280, 281, 283, 284, 285, 288, 289, 290, 291, 295 Schlagartige Einführung 52 Schleife (UML) 403 Schleifen in EPK‘s 112 Schlussereignis 63 Beispiel 146, 150, 162, 166, 168, 186, 197, 203 falsches 136 Schlussknoten AF Beispiel 404, 421, 425, 426 grafische Darstellung 392 Schlussknoten FF Beispiel 404 Schlussknoten FF grafische Darstellung 392 Schlussknoten FF (FlowFinal) grafische Darstellung 402 Schlusszustand Beispiel 494 Definition 475 Schnittstellen 243 Schrittweise Einführung 52 Schwache Existenzabhängigkeit 288 Schwimmbahnen 405 mehrdimensional 407 Selbstransition 488 Selbsttransition 494, 497 self (bei Lifelines) 434 self object Definition 412 Semantik 93 Definition (in der UML) 433 Semantikbestimmung bei InteractionOperand 450 Semantische Datenmodelle 280 SendSignalAction 410 grafische Darstellung 410 sequentielle Grundstruktur (bei Geschäftsprozessen) 9 sequenzialisieren 230 SERM

523

Beschreibung des Ansatzes 282 Sichten 27 signal event 409 signal object 409 SignalEvent 409 Signal-Token 375 Beispiel 398 Signatur 345 Spagetti-Code 235 Spezialisierung 290, 334 disjunkte 291 vollständige 291 standalone pin Beispiel 383 grafische Darstellung 383 Standardlösung 1, 33 Standardsoftware 33 Standardsoftwarelüge 43 Starke Existenzabhängigkeit 288 Start durch Prozesswegweiser 262 Start-Entitätstyp 284, 285 Startereignis 63, 230, 262 Beispiel 145, 164, 197 Startknoten grafische Darstellung 401 Startknoten (initial node) Beispiel 401 Startknoten (InitialNode) Definition 400 Startmöglichkeiten eines Geschäftsprozesses 118 StateInvariant Beispiel 453 statische Aspekte 250 Stellen 63 Stellenbeschreibung 256 step by step 52 Steuerung mit dem logischen UND 136 Steuerungssicht 27, 30 Strategie und Struktur 41 stream 384 streaming 385 Beispiel 384

524

18 Index

Definition 384 streaming mit Pins Beispiel 385 streaming-Konzept 414 Streuung von Geschäftsprozessen 35 Strichmännchen grafische Darstellung 462 strict sequencing Definition 439 strict sequencing (strict) 437 Struktur vs. Daten 239 Strukturierte Aktivitätsknoten Definition 390 Strukturierter Aktivitätsknoten 412 Strukturiertes Entity Relationship Modell 280 Stückliste 170, 176, 193, 207 ähnliche 170 Definition 172 Stücklisten 205 Stücklistenerstellung 170 subject Sprachgebrauch in der UML 456 Subklasse 334 subordinate units Definition 366 Subprozess 262 angehängter 262 angehängter (Definition) 111 eingefügter 197, 203, 208, 256, 261 eingefügter (Definition) 111 Subprozesse eingefügte (Beispiel) 197 Superklassen 334 Supportprozesse 11 Surrogat 324 syntaktisch bedingte Ereignisse 162 Syntaktische Klarheit 137 Syntax für eingefügte Subprozesse 208

Regeln für EPK’s 60 Syntax von EPK’s 80 Syntax vs. Semantik 93 Syntaxregel Kontrollfluss wieder zusammenführen 106 ODER bzw. XODER nach Ereignis 100 Prozesswegweiser 110 Szenarien 249 Szenario Aufbau 264 Szenario Anfrageprüfung 67 Szenarioprozess Aufbau 264 Tätigkeitsebene 131 Tayloristische Ebene 23, 40, 61, 131 Teil_von - Beziehung 342 Teil_von-Beziehung 338 Teilaufgaben Modellierung 200 ternäre Assoziationen 328 TimeEvent 409 Tipp Bedingungen 1 162 Bedingungen 2 - Alle Bedingungen müssen eintreten 170 Bedingungen 3 - Genau eine Bedingung muss eintreten 178 Bedingungen 4 - Mindestens eine Bedingung muss eintreten 180 Bedingungen 5 - Neben dem eigentlichen Kontrollfluss 182 Daten- bzw. Informationsflüsse gründlich modellieren 213 Ereignisraum 190 Gezielte Detaillierung 144 Informationsweitergabe in Ereignisgesteuerten Prozessketten 188

18 Index

Keine Zeitspanne modellieren195 Modellierung von Teilaufgaben - mit und ohne Reihenfolge 200 Transport und Liegezeiten materieller Informationsobjekte 184 Verknüpfung über Ereignisraum 205 Token 355, 415 Traces invalid 446 valid 446 Träger des Geschäftsprozesses 240 Tranportzeiten 184 Transition interne 497 Transitionen Definition 469 Erfassung 469 Transparenz durch Einführung Betriebswirtschaftlicher Standardsoftware 40 Transport Beispiel 198, 221 Transport materieller Informationsobjekte Modellierung 174, 184 Transportvorgang Beispiel 210, 216 Transportzeiten 174 Überwachung in EPK’s 154 Unabhängige Ereignisse Definition 93 UND 114 Beispiele 96, 102 Ereignis startet mehrere Funktionen 96 mit auslösendem Ereignis 96 Steuerung des Kontrollflusses 136 Teilaufgaben 90 vertieft 119

525

UND-Operator Beispiele 84, 90 Parallelität? 91 Ungenaue Modellierung 139 Unternehmensmodellierung 59, 247 Unternehmensumwelt 190 unternehmensweite Datenbank 39 Unternehmensweite Komplettlösung 1, 33 unterstützende Prozesse 11 use cases 455 value chain 509 value equality 323 Variantenstückliste Definition 172 verbotene Struktur in EPK’s 95 ODER mit auslösenden Ereignissen 99 Verbundtransition Definition 476 Vererbung Definition 335, 336 mehrfache 337 Vergleich UML / EPK Ereignisse 413 Join vs UND 399 Kontrollfluss insgesamt 415 Prozess-Sicht 402 Schwimmbahnen für Träger von Aktionen 406 Verhalten 504 Vergleich UML /EPK Träger im Aktionssymbol 407 Vergleich UML und EPK Verhalten vs. Funktion 367 Verhalten non-reentrant 414 Verhalten Definition 352 reentrant 414 von Realweltobjekten 313 Verhalten als Durchqueren eines Graphen 470

526

18 Index

Verhalten von Objekten und Geschäftsprozess 323 Verhaltens-Zustandsautomat469 Verknüpfer 67, 253, 380 Verknüpfer (Zustandsautomat) Definition 478 Verknüpfung über Ereignisse 230 Verknüpfungsereignis 110 Beispiel 111 verschachtelte Strukturen 390 Verteiler 67, 253 vertex Gebrauch des Begriffs 473 viele-zu-viele Beziehungen 285 VKD 29 vollständige Spezialisierung 291 Von Intra zu Inter 57 Voraussetzungen einer Prozessorientierung 21 Vorbedingung (Aktivitätsdiagramm) 420 Vorgang 60 Definition 6, 60 Vorgangsbearbeitung 36 Vorgangskettendiagramm 29 Wächter 394 Beispiel 418 Definition 379 mit Else 394 wait time action 409 Beispiel 412 grafische Darstellung 410 Wait time action Beispiel 411 Wartefunktion 132, 160, 166 Ersatz 133 Warten Beispiel 216 in Geschäftsprozessen 131 Warten in EPK’s 136 weak sequencing Definition 439 weak sequencing (seq) 437 Weiterleitung von Unterlagen 156

Weltausschnitt 250, 280 Weniger Überraschungseffekte 44 wertbasierte Suchschlüssel 324 Wertschöpfung Definition 509 Wertschöpfungskette Definition 274, 509 Wertschöpfungsketten Aufgabe 274 Wettlaufsituation 394, 425, 427 Wettlaufsituation (UML) Erläuterung 426 Wissen in Geschäftsprozessen 242 Wissensmanagement 242 workflow 36 Wurzel 334 Zeit in Ereignisgesteuerten Prozessketten 135 zeitgemäße Auffasssung von Datenbanken 280 Zeitliche Dimension in der UML 408 zeitliche Dimension in EPK’s 77 Zeitliche Dimension von EPK‘s 135 Zeitpunkt als externes Ereignis einer Ereignisgesteuerte Prozesskette 136 Zeitspanne vs Einzeldurchgang 195 Zeitverbrauch durch Funktionen (in EPK’s) 61 zentrale unternehmensweite Datenbank 39 Ziele der Prozessorientierung 20 Ziel-Entitätstyp 284, 285 Zielsetzung von Datenbanken 252 Zunehmende DVDurchdringung 40 Zusammenführen Kontrollfluss Beispiel 127

18 Index

Zusammenführen mehrerer Zweige 148 zusammengesetzte Objekte 342 Zusammengesetzte Zustände verbergen 494 zusammengesetzter Zustand Darstellung 474 Definition 474 Zustand Darstellung 492 Definition 472 eines Objekts 322 Zustand eines Objekts 343 grafische Darstellung 376 Zustand von Objekten Beispiel 382 Zustand, einfacher

527

Definition 474 Zustand, zusammengesetzter Definition 474 Zustandsautomat Beispiel 471 Zustandsautomaten grafische Darstellung 470 Zustandskonfiguration 489 Zustandsübergang 470 Zustandsübergänge Definition 469 Zustandsübergangsdiagramme 346 Zweck der Modellierung 232 Zwei verschachtelte Fragmente 453

19 Literatur Abts und Mülder 1998 Abts, Dietmar; Mülder, Wilhelm: Grundkurs Wirtschaftsinformatik. Eine kompakte und praxisorientierte Einführung (2. Auflage), Braunschweig, Wiesbaden 1998 Aho und Ullmann 1996 Aho, Alfred V.; Ullman, Jeffrey D.: Informatik. Datenstrukturen und Konzepte der Abstraktion. Bonn u.a. 1996 Amberg 1999 Amberg, Michael: Prozessorientierte betriebliche Informationssysteme. Methoden, Vorgehen und Werkzeuge zu ihrer effizienten Entwicklung, Berlin u.a. 1999 Balzert 1998 Balzert, Helmut: Lehrbuch der Software-Technik. Software-Management. SoftwareQualitätssicherung. Unternehmensmodellierung. Heidelberg und Berlin 1998 Balzert 1999 Balzert, Heide: Lehrbuch der Objektmodellierung. Analyse und Entwurf, Heidelberg und Berlin 1999 Balzert 2001 Balzert, Helmut: Lehrbuch der Software-Technik. Software-Entwicklung (2. Auflage). Heidelberg und Berlin 2001 Becker und Kahn 2000 Becker, Jörg; Kahn, Dieter: Der Prozess im Fokus, in: [Becker, Kugeler und Rosemann 2000, S. 1 – 13] Becker, Kugeler und Rosemann 2000 (Hrsg.) Becker, Jörg; Kugeler, Martin; Rosemann, Michael (Hrsg.): Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung (zweite, korrigierte Auflage), Berlin u.a. 2000 Becker und Meise 2000 Becker, Jörg; Meise, Volker: Von der Strategie zum Ordnungsrahmen, in [Becker und Kahn 2000, S. 91- 120] Becker und Vossen 1996 Becker, Jörg; Vossen, Gottfried: Geschäftsprozessmodellierung und WorkflowManagement. Eine Einführung, in >Vossen und Becker 1996, S. 17 – 26@ Berndt 1997 Berndt, Ralph (Hrsg.): Business Reengineering. Effizientes Neugestalten von Geschäftsprozessen. Berlin u.a. 1997 Bertino und Martino 1993 Bertino, Elisa; Martino, Lorenzo: Object-Oriented Database Systems. Concepts and Architectures. Wokingham u.a. 1993 Bogaschewsky und Rollberg 1998 Bogaschewsky, Ronald; Rollberg, Roland: Prozessorientiertes Management, Berlin u.a. 1998 Booch 1994 Booch, Grady: Objektorientierte Analyse und Design, Bonn u.a. 1994 Booch, Rumbaugh und Jacobson 1999 Booch, Grady; Rumbaugh, James; Jacobson, Ivar: Das UML-Benutzerhandbuch. Bonn u.a. 1999 Boy, Dudek, Kuschel 1994 Boy, J.; Dudek, Ch.; Kuschel, S.: Projektmanagement. Grundlagen, Methoden und Techniken. Bremen 1994

530

19 Literatur

Brenner und Hamm 1995 Brenner, Walter; Hamm, V.: Prinzipien des Business Reengineering, in: >Brenner und Keller 1995, S. 17 – 43@ Brenner und Keller 1995 Brenner, Walter; Keller, Gerhard (Hrsg.): Business Reengineering mit Standardsoftware. Frankfurt 1995 Bullinger und Fähnrich 1997 Bullinger, Hans-Jörg; Fähnrich, Klaus-Peter: Betriebliche Informationssysteme. Grundlagen und Werkzeuge der methodischen Softwareentwicklung. Berlin u.a. 1997 Bungert und Heß 1995 Bungert, Winfried; Heß, Helge: Objektorientierte Geschäftsprozessmodellierung, in: Information Management 1/95, S. 52 – 63 Burkhardt 1997 Burkhardt, Rainer: UML – Unified Modeling Language. Objektorientierte Modellierung für die Praxis, Bonn u.a. 1997 Burkhardt 1999 Burkhardt, Rainer: UML – Unified Modeling Language. Objektorientierte Modellierung für die Praxis (2., aktualisierte Auflage), Bonn u.a. 1997 Burleson 1999 Burleson, Donald K.: Inside the Database Object Model, Boca Raton u.a. 1998 Cannon 1993 Cannon, E.: EDI Guide: A Step by Step Approach. New York 1993 Cattel, R.G.G. 1996 Cattell, R.G.G. (Hrsg.): The Object Database Standard: ODMG-93. Release 1.2, San Francisco 1996 Chandler 1962 Chandler, A.D.: Strategy and Structure. Chapters in the History of Industrial Enterprise. Cambridge, MA, London 1962 Chen und Scheer 1994 Chen, R.; Scheer, A.-W.: Modellierung von Prozessketten mittels Petri-Netz-Theorie. Technischer Bericht 107, Institut für Wirtschaftsinformatik an der Universität des Saarlandes, Saarbrücken, Februar 1994 Dangel 1994 Dangel, Jürg W.: Business Process Reengineering: radikale Umgestaltung von Geschäftsprozessen, in: [Müller und Rupper 1994, S. 13 – 18] Date 1990 Date, C.J.: An Introduction to Database Systems. Volume I (5. Auflage), Reading u.a. 1990 Date und Darwen 1998 Date, C.J.; Darwen, Hugh: Foundation for Object/Relational Databases. The Third Manifesto, Reading (Mass.) u.a. 1998 DeMarco 1979 DeMarco, Tom: Structured Analysis and System Specification, New York u.a. 1979 Dingle 1997 Dingle, J.: Project Management. Orientation for Decision Makers. London 1997 Eccles und Nohria 1992 Eccles, R.G.; Nohria, N.: Beyond the Hype: Rediscovering the Essence of Management. Cambridge 1992 Eriksson und Penker 2000 Eriksson, Hans-Erik; Penker, Magnus: Business Modeling with UML. Business Pattern at Work. New York u.a. 2000 Ferstl und Sinz 1990 Ferstl, Otto K.; Sinz, Elmar J.: Objektmodellierung betrieblicher Informationssysteme im Semantischen Objektmodell (SOM), in: Wirtschaftsinformatik, 32. Jahrgang, Heft 6, Dezember 1990, S. 566 – 581

19 Literatur

531

Ferstl und Sinz 1991 Ferstl, Otto K.; Sinz, Elmar J.: Ein Vorgehensmodell zur Objektmodellierung betrieblicher Informationssysteme im Semantischen Objektmodell (SOM), in: Wirtschaftsinformatik, 33. Jahrgang, Heft 6, Dezember 1991, S. 477 – 491 Ferstl und Sinz 1993a Ferstl, Otto K.; Sinz, Elmar J.: Geschäftsprozessmodellierung, in: Wirtschaftsinformatik, 35 (1993) 6, S. 589 – 592 Ferstl und Sinz 1993b Ferstl, Otto K.; Sinz, Elmar J.: Der Modellierungsansatz des Semantischen Objektmodells (SOM). Bamberger Beiträge zur Wirtschaftsinformatik Nr. 18, September 1993 Ferstl und Sinz 1994 Ferstl, Otto K.; Sinz, Elmar J.: Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschäftsprozessen. Bamberger Beiträge zur Wirtschaftsinformatik Nr. 21, Dezember 1994 Ferstl und Sinz 1995 Ferstl, Otto K.; Sinz, Elmar J.: Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschäftsprozessen, in: Wirtschaftsinformatik 37 (1995) 3, S. 209 – 220 Ferstl und Sinz 1996 Ferstl, Otto K.; Sinz, Elmar J.: Geschäftsprozessmodellierung im Rahmen des Semantischen Objektmodells, in: [Vossen und Becker 1996], S. 47 – 61 Ferstl und Sinz 1997 Ferstl, Otto K.; Sinz, Elmar J.: Modeling of Business Systems Using the Semantic Object Model (SOM) – A Methodological Framework. Bamberger Beiträge zur Wirtschaftsinformatik Nr. 43, July 1997 Fowler und Scott 1998 Fowler, Martin; Scott, Kendall: UML – konzentriert. Die Standardobjektmodellierungssprache anwenden. Bonn u.a. 1998 Franz 1996 Franz, Klaus-Peter: Prozesskostenmanagement für ein strategisches Aktivitätencontrolling, in >Perlitz u.a. 1996@, S. 210 – 220 Franz 1996 Franz, Klaus-Peter: Prozesskostenmanagement für ein strategisches Aktivitätencontrolling, in >Perlitz u.a. 1996@, S. 210 – 220 Gaukel und Bardelli 1994 Gaukel, Fritz; Bardelli, Guido: Einführung der Prozessorientierung in einem mittelständischen Unternehmen, in [Müller und Rupper 1994, S. 28 – 33] Geppert 1997 Geppert, Franz: Objektorientierte Datenbanksysteme. Ein Praktikum. Heidelberg 1997 Giedion 1982 Giedion, Sigfried: Die Herrschaft der Mechanisierung. Ein Beitrag zur anonymen Geschichte. Frankfurt 1982 Gumm und Sommer 1998 Gumm, Heinz-Peter; Sommer, Manfred: Einführung in die Informatik. München und Wien 1998 Hammer 1997 Hammer, Michael: Das prozesszentrierte Unternehmen. Die Arbeitswelt nach dem Reengineering. München 1997 Hammer und Champy 1995 Hammer, Michael; Champy, James: Business Reengineering. Die Radikalkur für das Unternehmen, Frankfurt, New York 1995 Hammer und Stanton 1995 Hammer, Michael; Stanton, Steven A.: Die Reengineering Revolution. Handbuch für die Praxis. Frankfurt, New York 1995 Heinrich und Roithmayr 1998 Heinrich, Lutz J.; Roithmayr, Friedrich: Wirtschaftsinformatik-Lexikon, 6. Auflage, München und Wien 1998

532

19 Literatur

Hess 1996 Hess, Thomas: Entwurf betrieblicher Prozesse. Grundlagen – Bestehende Methoden – Neue Ansätze, Wiesbaden 1996 Hess und Brecht 1996 Hess, Thomas; Brecht, Leo: State of the Art des Business Process Redesign. Darstellung und Vergleich bestehender Methoden (2. Auflage). Wiesbaden 1996 Heuer 1992 Objektorientierte Datenbanken. Konzepte, Modelle, Systeme. Bonn u.a. 1992 Heym 1995 Heym, Michael: Prozess- und Methoden-Management für Informationssysteme. Überblick und Referenzmodell. Berlin u.a. 1995 Hofstadter1985 Hofstadter, Douglas R.: Gödel, Escher, Bach. Ein Endloses Geflochtenes Band, Stuttgart 1985 Hohmann 1999 Hohmann, Peter: Geschäftsprozesse und integrierte Anwendungssysteme. Prozessorientierung als Erfolgskonzept. Köln u.a. 1999 Horn, Kerner und Forbrig 2001 Horn, Christian; Kerner, Immo O.; Forbrig, Peter: Lehr- und Übungsbuch Informatik. Band 1: Grundlagen und Überblick (2. Auflage). München und Wien 2001 Hughes 1991 Hughes, J. G.: Object-Oriented Databases. New York u.a. 1991 Hughes 1992 Hughes, J. G.: Objektorientierte Datenbanken. München u.a. 1992 (Anmerkung: deutsche Übersetzung von >Hughes 1991@) Karge 1996 Karge, Reinhard: Real Objects. Konzepte und Praxis objektorientierter Datenbanken. Bonn u.a. 1996 Keller 1995 Keller, Gerhard: Business Process Reengineering mit dem R/3-Referenzmodell, in: SAP info, Mai 1995, S. 7 – 14. Keller und Teufel 1997 Keller, Gerhard; Teufel, Thomas: SAP R/3 prozessorientiert anwenden. Iteratives Prozess-Prototyping zur Bildung von Wertschöpfungsketten. Bonn u.a. 1997 Keller und Teufel 1998 Keller, Gerhard; Teufel, Thomas: SAP R/3 prozessorientiert anwenden. Iteratives Prozess-Prototyping zur Bildung von Wertschöpfungsketten (2. korrigierte Auflage). Bonn u.a. 1998 Keller, Nüttgens und Scheer 1992 Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozessmodellierung auf der Grundlage Ereignisgesteuerter Prozessketten, Veröffentlichungen des Instituts für Wirtschaftsinformatik (Iwi), Universität des Saarlandes, Heft 89, Januar 1992 Kemper und Eickler 1999 Kemper, A.; Eickler, A.: Datenbanksysteme. Eine Einführung. München und Wien 1999 Kemper, A.; Moerkotte, G.: Basiskonzepte objektorientierter Datenbanksysteme, in: Informatik-Spektrum (1993) 16, S. 69-80. Kieser 1996 Kieser, Alfred: Business Process Reengineering – neue Kleider für den Kaiser, in >Perlitz u.a. 1996@, S. 236 – 251 Klockhaus und Scheruhn 1998 Klockhaus, Eckhard; Scheruhn, Hans-Jürgen (Hrsg.): Modellbasierte Einführung betrieblicher Anwendungssysteme. Wiesbaden 1997 Kosiol 1962 Kosiol, E.: Organisation der Unternehmung, Wiesbaden 1962 Krallmann 1994 Kralmann, K.: Systemanalyse im Unternehmen. Geschäftsprozessoptimierung, Partizipative Vorgehensmodelle, Objektorientierte Analyse. München u.a. 1994

19 Literatur

533

Kueng, Bichler und Schrefl 1996 Kueng, Peter; Bichler, Peter; Schrefl, Michael: Geschäftsprozessmodellierung: ein zielbasierter Ansatz, in Information Management 2/96, S. 40 – 50 Kugeler und Vieting 2000 Kugeler, Martin; Vieting, Michael: Gestaltung einer prozessorientiert(er)en Aufbauorganisation, in: [Becker, Kugeler und Rosemann 2000, S. 187-232] Lang und Lockemann 1995 Lang, Stefan M.; Lockemann, Peter C.: Datenbankeinsatz. Berlin, Heidelberg 1995 Lexikon WI Mertens, Peter; Back, Andrea; Becker, Jörg u.a.: Lexikon der Wirtschaftsinformatik (3. Auflage), Berlin u.a. 1997 Langner, Schneider und Wehler 1997a Langner, P.; Schneider, C.; Wehler, J.: Ereignisgesteuerte Prozessketten und PetriNetze. Technischer Bericht 196, Fachbereich Informatik der Universität Hamburg, März 1997 Langner, Schneider und Wehler 1997b Langner, P.; Schneider, C.; Wehler, J.: Prozessmodellierung mit Ereignisgesteuerten Prozessketten (EPKs) und Petri-Netzen. in: Wirtschaftsinformatik, 39(5), S. 479-489, Oktober 1997 Litke 1996 Litke, H.-D.: DV-Projektmanagement. Zeit und Kosten richtig einschätzen. München, Wien 1996 Lock 1996 Lock, D.: Essentials of Project Management. Aldershot 1996 Lohoff und Lohhoff 1994 Lohoff, Petra; Lohoff, Heinz-Günther: Ganzheitliche Optimierung der Administration, in [Müller und Rupper 1994, S. 56 – 63] Lohse 1996 Lohse, Jens-Marten: Mit Wertestrategie und Business Reengineering zur Marktorientierung, in >Perlitz u.a. 1996@, S. 289 – 298 Loos und Allweyer 1998 Loos, Peter; Allweyer, Thomas: Process Orientation and Object Orientation – an Approach for Integrating UML and Event-Driven Process Chains (EPC), Publication of the Institut für Wirtschaftsinformatik (Technical Report 144), University of Saarland, Saarbrücken, March 1998 Marshall 2000 Marshall, Chris: Enterprise Modeling with UML. Designing Successful Software through Business Analysis. Reading (Mass.) u.a. 2000 Martin und Odell 1999 Martin, James; Odell, James J.: Objektorientierte Modellierung mit UML: Das Fundament. München 1999 Maurer u.a. 1998 Maurer, H.; Scherbakov, N.; Halim, Z.; Razak, Z.: From Databases to Hypermedia, Berlin u.a. 1998 McMenamin und Palmer 1988 McMeanmin, Stephen M.; Palmer, John F.: Strukturierte Systemanalyse. München u.a. 1988 Meier und Wüst 1997 Meier, Andreas; Wüst, Thomas: Objektorientierte Datenbanken. Ein Kompaß für die Praxis-. Heidelberg 1997 Mertens 1995 Mertens, Peter: Integrierte Informationsverarbeitung 1. Administrations- und Dispositionssysteme in der Industrie (10. Auflage), Wiesbaden 1995 Mertens u.a. 1997 Mertens, Peter; Becker, Jörg; König, Wolfgang u.a. (Hrsg.): Lexikon der Wirtschaftsinformatik (3. Auflage), Berlin u.a. 1997

534

19 Literatur

Mertens und Griese 1993 Mertens, Peter; Griese, Joachim: Integrierte Informationsverarbeitung 2. Planungs- und Kontrollsysteme in der Industrie (7. Auflage), Wiesbaden 1993 Mertens und Knolmayer 1995 Mertens, Peter; Knolmayer, Gerhard: Organisation der Informationsverarbeitung. Grundlagen – Aufbau – Arbeitsteilung (2. Auflage), Wiesbaden 1995 Meyer 1990 Meyer, Bertrand: Objektorientierte Softwareentwicklung. Wien u.a. 1990 Mischak 1997 Mischak, Richard F.: Business Reengineering – Der Weg vom funktions- zum prozessorientierten Denken im Unternehmen, in: >Berndt 1997@, S. 3 – 17 Müller und Rupper 1994 Müller, Roland; Rupper, Peter (Hrsg.): Process Reengineering. Prozesse optimieren und auf den Kunden ausrichten. Zürich 1994 Müller-Ettrich 1993 Müller-Ettrich, G. (Hrsg.): Fachliche Modellierung von Informationssystemen. Methoden, Vorgehen, Werkzeuge, Bonn u.a. 1993 Müri 1994 Müri, Peter: Prozessorientierung - der Schlüssel zum neuen Management, in: [Müller und Rupper 1994], S. 141 - 149 Neumaier 1989 Neumaier, H. (Hrsg.): Relationale Datenbanken. München und Wien 1989 Neumann und Bredemeier 1996 Neumann, R.; Bredemeier, K.: Projektmanagement von A-Z. Das Handbuch für den Praktiker. Frankfurt 1996 Nüttgens, Feld und Zimmermann 1998 Nüttgens, M.; Feld, T.; Zimmermann, V. : Business Process modeling with epc and uml: Transformation or integration?, in [Schader und Korthaus 1998, S. 250-261] OMG 1999 Object Management Group: OMG Unified Modeling Language Specification, Version 1.3, June 1999 OMG 2003a Object Management Group: UML 2.0 Superstructure Specification (Unified Modeling Language: Superstructure, version 2.0, final Adopted Specification, ptc/03-08-02), August 2003 OMG 2003b Object Management Group: UML 2.0 Infrastructure Specification (Unified Modeling Language (UML) Specification: Infrastructure, version 2.0, ptc/03-09-15), Dezember 2003 OMG 2003c Object Management Group: UML 2.0 OCL Specification (OCL 2.0 OMG Final Adopted Specification, ptc/03-10-14), Oktober 2003 Oestereich 1998 Oestereich, Bernd: Objektorientierte Softwareentwicklung. Analyse und Design mit der Unified Modeling Language (4. Auflage). München und Wien 1998 Österle 1995 Österle, Hubert: Business Engineering. Prozess- und Systementwicklung. Band 1: Entwurfstechniken, Berlin u.a. 1995 Ott 1995 Ott, Hans Jürgen: Betriebswirtschaftslehre für Ingenieure und Informatiker. Eine Einführung in die betriebswirtschaftliche Denkweise, München 1995 Perlitz u.a. 1996 Perlitz, Manfred; Offinger, Andreas; Reinhardt, Michael; Schug, Klaus (Hrsg.): Reengineering zwischen Anspruch und Wirklichkeit. Ein Managementansatz auf dem Prüfstand. Wiesbaden 1996

19 Literatur

535

Petri 1962 Petri, C. A.: Kommunikation mit Automaten. Dissertation Universität Bonn 1962 Porter 1985 Porter, Michael E.: Competitive Advantage – Creating and Sustaining Superior Performance. New York 1985 Porter 1992a Porter, Michael E.: Wettbewerbsstrategie (7. Auflage), Frankfurt 1992 Porter 1992b Porter, Michale E.: Wettbewerbsvorteile: Spitzenleistungen erreichen und behaupten (3. Auflage), Frankfurt 1992 Porter 1998 Porter, Michael E.: On Competition. Harvard Business Review Book 1998 Porter und Millar 1998 Porter, Michael E.; Millar, Victor E.: How Information Gives You Competitive Advantage, in: [Porter 1998, S. 75 - 98] (ursprünglich 1985 veröffentlicht) Quality und IIE 1994 Quality Resources; Institute of Industrial Engineers: Beyond the Basics of Reengineering: Survival Tactics for the 90s, White Plains, Norcross 1994 R/3-Prozessmodell 3.1G Handbuch BC – Das R/3-Prozessmodell (Release 3.1G) zu SAP-R/3, Release 3.1, SAP AG Walldorf, Mai 1997 R/3-Referenzmodell 3.0F Handbuch CA-R/3-Referenzmodell (Release 3.0F) zu SAP-R/3, Release 3.1, SAP AG Walldorf, Mai 1997 Rosemann 1996 Rosemann, Michael: Komplexitätsmanagement in Prozessmodellen: Methodenspezifische Gestaltungsempfehlungen für die Informationsmodellierung. Wiesbaden 1996 Rosemann und Schulte 1996 Rosemann, Michael; Schulte, Rainer: Effiziente Prozessgestaltung im Rechnungswesen. In: [Vossen und Becker 1996, S. 193 – 207]. Rudolph 1996 Rudolph, H.: Erfolg von Unternehmen. Plädoyer für einen kritischen Umgang mit dem Erfolgsbegriff, in: Zeitschrift für Betriebswirtschaft 1996 Rumbaugh u.a. 1993 Rumbaugh, James; Blaha, Michael; Premerlani, William; Eddy, Frederick; Lorensen, William: Objektorientiertes Modellieren und Entwerfen, München u.a. 1993 et al Rump 1999 Rump, Frank J.: Geschäftsprozessmanagement auf der Basis ereignisgesteuerter Prozeßketten. Formalisierung, Analyse und Ausführung von EPKs, Stuttgart und Leipzig 1999 Rupper 1994 Rupper, Peter: Process Reengineering - Eine Einführung, in: [Müller und Rupper 1994, S. 9 - 11] Saake, Türker und Schmitt 1997 Saake, Gunter; Schmitt, Ingo; Türker, Can: Objektdatenbanken. Konzepte, Sprachen, Architekturen. Bonn u.a. 1997 SAP Analyzer SAP R/3-Analyzer. System R/3. Release 2.1 (Handbuch), Walldorf 1994 SAP Datenmodell 96 SAP Datenmodell. Referenzmodell für Business Objekte (Michael Seubert). MaterialNr. 50011391. 1996. Schulungsunterlagen der Firma SAP. SAP-BC030 SAP Data Dictionary R/3 (R/3 System Release 2.1 Februar 1994). Schulungsunterlagen der Firma SAP. SAP-BCDD BC – SAP Data Dictionary. (R/3-System Juli 1992). Schulungsunterlagen der Firma SAP.

536

19 Literatur

SAP-PP300 SAP-Informationsmodell. Modellgestütztes Informationsmanagement im R/3-System. Das Datenmodell Produktionsplanung (Workshop PP300, März 1995). Schulungsunterlagen der Firma SAP. Schader und Korthaus 1998 Schader, M.; Korthaus, A. (Hrsg.): The Unified Modeling Language – Technical Aspects and Applications. Heidelberg 1998 Schader und Rundshagen 1994 Schader, Martin; Rundshagen, Michael: Objektorientierte Systemanalyse. Eine Einführung, Berlin u.a. 1994 Scheckenbach 1997 Scheckenbach, Rainer: Semantische Geschäftsprozessintegration, Wiesbaden 1997 Scheer 1990 Scheer, August-Wilhelm: Wirtschaftsinformatik. Informationssysteme im Industriebetrieb (3. Auflage), Berlin u.a. 1990 Scheer 1997 Scheer, August-Wilhelm: Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse (7. Auflage), Berlin u.a. 1997 Scheer 1998a Scheer, August-Wilhelm: ARIS – vom Geschäftsprozess zum Anwendungssystem (3. Auflage), Berlin u.a.1998 Scheer 1998b Scheer, August-Wilhelm: ARIS – Modellierungsmethoden, Metamodelle, Anwendungen (3. Auflage), Berlin u.a.1998 Scheer, Nüttgens und Zimmermann 1997 Scheer, A.-W., Nüttgens, M.; Zimmermann, V.: Objektorientierte Ereignisgesteuerte Prozesskette (oEPK) – Methode und Anwendung, Veröffentlichungen des Instituts für Wirtschaftsinformatik (Iwi), Universität des Saarlands, Heft 141, Mai 1997 Schmidt 1991 Schmidt, Duri: Persistente Objekte und objektorientierte Datenbanken. Konzepte, Architektur, Implementierung und Anwendung, München und Wien 1991 Schneck 1998 Schneck, Ottmar: Lexikon der Betriebswirtschaft (3. Auflage), München 1998 Scholz-Reiter 1990 Scholz-Reiter, B.: CIM - Informations- und Kommunikationssysteme. München u.a. 1990 Schulungsunterlagen Analyzer Schulungsunterlagen „SAP R/3-Analyzer“ Release 2.1 der SAP AG Schwegmann und Laske 2000 Schwegmann, Ansgar; Laske, Michael: Istmodellierung und Istanalyse, in: [Becker, Kugeler und Rosemann 2000, S. 121 – 151] Sinz 1990 Sinz, Elmar J.: Das Entity-Relationship-Modell (ERM) und seine Erweiterungen, in: HMD 152 (1990), S. 17 – 29 Sinz 1991 Sinz, Elmar J.: Objektorientierte Analyse, in: Wirtschaftsinformatik, 33. Jahrgang, Heft 5, Oktober 1991, S. 455 – 457 Sinz 1992 Sinz, Elmar J.: Datenmodellierung im Strukturierten-Entity-Relationship-Modell (SERM), in: Bamberger Beiträge zur Wirtschaftsinformatik, Nr. 10, 1992 Sinz 1993 Sinz, Elmar J.: Das Strukturierte Entity-Relationship-Modell (SERM), in: Müller-Ettrich 1993, S. 78 – 114 Sinzig und Uhr 1998 Sinzig, Werner; Uhr, Wolfgang: Management Support Systeme, in: Wirtschaftsinformatik 40 (1998) 6, S. 481 – 482

19 Literatur

537

Smith und Smith 1977a Smith, John Miles und Smith, Diane C.P.: Database Abstractions: Agregation, in: Communications of the ACM, June 1977, Volume 20, Number 6, S. 405 – 413 Smith und Smith 1977b Smith, John Miles und Smith, Diane C.P.: Database Abstractions: Agregation and Generalization, in: ACM Transactions on Database Systems, Vol. 2, No. 2, June 1977, S. 105 – 133 Stahlknecht 1995 Stahlknecht, Peter: Einführung in die Wirtschaftsinformatik (7. Auflage), Berlin, Heidelberg 1995 Staud 1999 Staud, J.L.: Geschäftsprozessanalyse mit Ereignisgesteuerten Prozessketten. Grundlagen des Business Reengineering für SAP R/3 und andere Betriebswirtschaftliche Standardsoftware. Berlin u.a. 1999 Stein 1994 Stein, Wolfgang: Objektorientierte Analysemethoden. Vergleich, Bewertung, Auswahl, Mannheim u.a. 1994 Steinbuch 1998 Steinbuch, Pitter A. (Hrsg.): Prozessorganisation - Business Reengineering – Beispiel R/3, Ludwigshafen (Rhein) 1998 Stickel 1991 Stickel, Eberhard: Datenbankdesign. Methoden und Übungen. Wiesbaden 1991 Teorey 1990 Teorey, Toby J.: Database modeling and Design: The Entity-Relationship Approach, San Mateo 1990 UML 1997a Rational Software u.a.: UML Extension for Business Modeling. Version 1.1. 1 September 1997 (www.rational.com/uml runtergeladen am 9. Juli 2000) van ES und Post 1996 van ES, Rodim; Post, Henk A.: Dynamic Enterprise Modeling. A Paradigm Shift in Software Implementation, Deventer 1996 Vogler und Bodendorf 1994 Vogler, Petra; Bodendorf, Freimut: Schnellere Büroarbeit, in: [Müller und Rupper 1994, S. 64 – 69] Vossen 1994 Vossen, Gottfried: Datenmodelle, Datenbanksprachen und Datenbank-MangementSysteme (2. Auflage). Bonn u.a. 1994 Vossen und Becker 1996 Vossen, Gottfried; Becker, Jörg (Hrsg.): Geschäftsprozessmodellierung und WorkflowManagement. Modelle, Methoden, Werkzeuge. Bonn u.a. 1996 Wischnewski 1993 Wischnewski, E.: Modernes Projektmanagement. Eine Anleitung zur effektiven Unterstützung, Durchführung und Steuerung von Projekten. Braunschweig 1993 Wöhe 1993 Wöhe, Günter: Einführung in die Allgemeine Betriebswirtschaftslehre (unter Mitarbeit von Ulrich Döring), München 1993 Womack und Jones 1997 Womack, James P.; Jones, Daniel T.: Auf dem Weg zum perfekten Unternehmen (Lean Thinking), Frankfurt, New York 1997 Yourdon 1992 Yourdon, Edward: Moderne Strukturierte Analyse: ein Standardwerk zur modernen Systemanalyse. Attenkirchen 1992 Zencke 1995 Zencke, Peter: Prozessorientierung - Wundermittel oder alter Hut?, in SAP info Thema, Mai 1995

538

19 Literatur

Zimmermann, Katzy, Plötz und Tanner 1994 Zimmermann, Hubert H.; Katzy, Bernhard R.; Plötz, Armin J.; Tanner, Hans-Rudolf: Prozessorientierte Organisationsstrukturen. Integration von Prozess- und Organisationsstrukturen durch Unternehmensmodellierung, in [Müller und Rupper 1994, S. 107 – 120]. zur Mühlen 2000 zur Mühlen, Michael: Weitere Anwendungsgebiete und Entwicklungsperspektiven – Beyond Reengineering, in [Becker, Kugeler und Rosemann 2000, S. 283 – 325]