Objektorientierte Geschäftsprozessmodellierung mit der UML 3898642372

Table of contents :
Geleitwort......Page 6
Vorwort......Page 7
Inhaltsüberblick......Page 10
Inhaltsverzeichnis......Page 11
1 Einleitung......Page 14
1.1 Warum Geschäftsprozessmodellierung?......Page 16
1.2 Historie der Geschäftsprozessorientierung......Page 22
1.3 Abgrenzung......Page 24
2 Überblick und Orientierung......Page 30
2.1 Vorgehensweise......Page 32
2.2 Einbettung in die Systementwicklung......Page 44
3 OOGPM-Methodik......Page 48
3.1 Modellierungsfokus festlegen und Unternehmensziele beschreiben......Page 50
3.2 Organisationseinheiten modellieren......Page 56
3.3 Ziele festlegen......Page 59
3.4 Aktive Geschäftspartner identifizieren......Page 64
3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren......Page 69
3.6 Weitere unterstützende Geschäftsanwendungsfälle identifizieren......Page 79
3.7 Geschäftsmitarbeiter identifizierenund Akteurmodell entwickeln......Page 85
3.8 Geschäftsprozesse definieren......Page 90
3.9 Geschäftsprozesse dokumentieren......Page 97
3.10 Geschäftsanwendungsfälle essenziell beschreiben......Page 100
3.11 Geschäftsanwendungsfall-Abläufe modellieren......Page 109
3.12 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren......Page 115
3.13 Geschäftsanwendungsfall-Abläufe detaillieren......Page 124
3.14 Organisatorische Einbettung und Abhängigkeiten identifizieren......Page 127
3.15 Geschäftsanwendungsfallmodell erstellen......Page 131
3.16 Geschäftsklassenmodell erstellen......Page 136
3.17 Zustandsmodelle für zustandsrelevante Geschäftsklassen erstellen......Page 140
3.18 Geschäftliche Anforderungen und Regeln beschreiben......Page 142
3.19 Systemanwendungsfälle definieren......Page 146
3.20 Glossar und Abkürzungsverzeichnis entwickeln......Page 154
4 UML – Notation und Semantik......Page 158
4.1 UML......Page 160
4.2 Akteur......Page 161
4.3 Anwendungsfallmodell......Page 168
4.4 Aktivitätsmodelle......Page 188
4.5 Geschäftsklassenmodell......Page 201
4.6 Pakete......Page 217
4.7 Organisationsplan......Page 219
4.8 Zustandsmodelle......Page 224
5 Anhang......Page 230
5.1 Abkürzungsverzeichnis......Page 232
5.2 Glossar......Page 233
5.3 Literatur......Page 242
5.4 Index......Page 246
www.dpunkt.de......Page 0

Citation preview

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

Was sind E-Books von dpunkt? Unsere E-Books sind Publikationen im PDF- oder EPUB-Format, die es Ihnen erlauben, Inhalte am Bildschirm zu lesen, gezielt nach Informationen darin zu suchen und Seiten daraus auszudrucken. Sie benötigen zum Ansehen den Acrobat Reader oder ein anderes adäquates Programm bzw. einen E-Book-Reader. E-Books können Bücher (oder Teile daraus) sein, die es auch in gedruckter Form gibt (bzw. gab und die inzwischen vergriffen sind). (Einen entsprechenden Hinweis auf eine gedruckte Ausgabe finden Sie auf der entsprechenden E-Book-Seite.) Es können aber auch Originalpublikationen sein, die es ausschließlich in E-Book-Form gibt. Diese werden mit der gleichen Sorgfalt und in der gleichen Qualität veröffentlicht, die Sie bereits von gedruckten dpunkt.büchern her kennen.

Was darf ich mit dem E-Book tun? Die Datei ist nicht kopiergeschützt, kann also für den eigenen Bedarf beliebig kopiert werden. Es ist jedoch nicht gestattet, die Datei weiterzugeben oder für andere zugänglich in Netzwerke zu stellen. Sie erwerben also eine Ein-Personen-Nutzungslizenz. Wenn Sie mehrere Exemplare des gleichen E-Books kaufen, erwerben Sie damit die Lizenz für die entsprechende Anzahl von Nutzern. Um Missbrauch zu reduzieren, haben wir die PDF-Datei mit einem Wasserzeichen (Ihrer E-MailAdresse und Ihrer Transaktionsnummer) versehen. Bitte beachten Sie, dass die Inhalte der Datei in jedem Fall dem Copyright des Verlages unterliegen.

Wie kann ich E-Books von dpunkt kaufen und bezahlen? Legen Sie die E-Books in den Warenkorb. (Aus technischen Gründen, können im Warenkorb nur gedruckte Bücher ODER E-Books enthalten sein.) Downloads und E-Books können sie bei dpunkt per Paypal bezahlen. Wenn Sie noch kein PaypalKonto haben, können Sie dieses in Minutenschnelle einrichten (den entsprechenden Link erhalten Sie während des Bezahlvorgangs) und so über Ihre Kreditkarte oder per Überweisung bezahlen.

Wie erhalte ich das E-Book von dpunkt? Sobald der Bestell- und Bezahlvorgang abgeschlossen ist, erhalten Sie an die von Ihnen angegebene Adresse eine Bestätigung von Paypal, sowie von dpunkt eine E-Mail mit den Downloadlinks für die gekauften Dokumente sowie einem Link zu einer PDF-Rechnung für die Bestellung. Die Links sind zwei Wochen lang gültig. Die Dokumente selbst sind mit Ihrer E-Mail-Adresse und Ihrer Transaktionsnummer als Wasserzeichen versehen.

Wenn es Probleme gibt? Bitte wenden Sie sich bei Problemen an den dpunkt.verlag: Frau Karin Riedinger (riedinger (at) dpunkt.de bzw. fon 06221-148350).

Dipl.-Ing. Bernd Oestereich ist geschäftsführender Gesellschafter der oose.de Dienstleistungen für innovative Informatik GmbH und Autor zahlreicher teilweise international verlegter Buch- und Zeitschriftenpublikationen. Mit seinen Arbeiten gibt er immer wieder wichtige Impulse für die objektorientierte Softwareentwicklung. Er ist Mitglied in verschiedenen regionalen und überregionalen Arbeitskreisen zu objektorientierten Themen.

Dipl.-Wirtschaftsinform. Christian Weiss ist Trainer und Berater bei der oose.de GmbH und beschäftigt sich seit 1991 mit objektorientierter Softwareentwicklung, u. a. als leitender Entwickler, Berater und Trainer für interne und öffentliche Seminare. Auch an Hochschulen referiert er regelmäßig. Seine Schwerpunkte liegen im Bereich objektorientierte Analyse- und Designtechniken, Geschäftsprozessmodellierung sowie der Unterstützung von Großunternehmen bei der Umstellung auf Objekttechnologien. Dipl.-Betriebsw. Claudia Schröder ist freiberufliche Systemanalytikerin. Sie beschäftigt sich seit 1999 mit objektorientierter Softwareentwicklung. Ihre Schwerpunkte liegen im Bereich Entwicklungsmethodik, Anforderungsanalyse und Geschäftsprozessmodellierung (www.system-analyst.de).

Dipl.-Inform. Tim Weilkiens ist Trainer und Berater bei der oose.de GmbH und beschäftigt sich seit Beginn seines Studiums 1991 mit objektorientierter Softwareentwicklung. Er verfügt über eine hohe fachliche Kompetenz in den Bereichen objektorientierte Analyse, objektorientiertes Design, UML, UML-Case-Tools, objektorientiertes Testen, C++ und Java.

Dipl.-Inform. Alexander Lenhard ist Trainer und Berater bei der oose.de GmbH und beschäftigt sich seit seinem Studium mit objektorientierter Softwareentwicklung, UML und Java. Neben der fachlichen Kompetenz in der objektorientierten Analyse und Design besitzt er durch seine langjährige Tätigkeit als Simulationsspezialist umfangreiche Kenntnisse in der Geschäftsprozessmodellierung und -analyse.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

Bernd Oestereich · Christian Weiss · Claudia Schröder · Tim Weilkiens · Alexander Lenhard

Objektorientierte Geschäftsprozessmodellierung mit der UML

Bernd Oestereich [email protected] Christian Weiss [email protected] Claudia Schröder [email protected] Tim Weilkiens [email protected] Alexander Lenhard [email protected]

Mehr über die Autoren und »the making of the book« erfahren Sie unter www.oogpm.de Für ihre Unterstützung bedanken wir uns ganz herzlich bei Prof. Dr. Heidi Heilmann, Prof. Dr. Mario Jeckle, Prof. Dr. Susanne Strahringer, Mike Leuschner, Byron Evans, Elke Schunck, Christoph Kaeder, Christa Preisendanz, o. Univ.-Prof. Dipl.-Ing. Mag. Dr. Gerti Kappel, Dipl.-Ing. Dr. Beate List, unseren Kooperationspartnern von IDS Scheer, unseren KundInnen, ProjektkollegInnen und SchulungsteilnehmerInnen sowie unseren KollegInnen von oose.de.

Fachliche Beratung und Herausgabe von dpunkt.büchern im Bereich Wirtschaftsinformatik: Prof. Dr. Heidi Heilmann · [email protected] Lektorat: Christa Preisendanz Copy-Editing: Ursula Zimpfer, Herrenberg Satz: Bernd Oestereich, Hamburg Herstellung: Birgit Bäuerlein Umschlaggestaltung: Helmut Kraus, Düsseldorf Druck und Bindung: Koninklijke Wöhrmann B.V., Zutphen, Niederlande Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. ISBN: Buch 978-3-89864-237-8 PDF 978-3-86491-215-3 ePub 978-3-86491-216-0 1. Auflage 2003 Copyright © 2003 dpunkt.verlag GmbH Ringstraße 19 69115 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen. Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen. Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen. 543210

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

v

Geleitwort Geschäftsprozessmodellierung erfreut sich seit über zehn Jahren intensiver Aufmerksamkeit in Praxis und Theorie der Wirtschaftsinformatik. Antworten auf die aktuelle wirtschaftliche Situation setzen zu einem erheblichen Teil bei der Straffung und Verbesserung bis Neugestaltung der Unternehmensprozesse an mit dem Ziel, damit einerseits die Kundenorientierung zu verstärken und andererseits unnötige Kosten zu vermeiden. Dabei gilt als selbstverständlich, dass neue bzw. verbesserte Prozesse, die effektiv und effizient arbeiten sollen, nur mit optimalem Einsatz von Informationstechnologie realisierbar sind. Im gleichen Zeitraum hat sich in der Informatik die objektorientierte Entwicklung immer weiter durchgesetzt, seit einigen Jahren zunehmend ergänzt durch neue Konzepte nach dem Paradigma der agilen Softwareentwicklung. Als breit bekannter und praktizierter Standard hat sich die seit Ende 1997 von der Object Management Group (OMG) vertretene Unified Modeling Language (UML) als Modellierungssprache für Spezifikation, Design und Dokumentation objektorientiert entwickelter Systeme etabliert. Neu modellierte bzw. verbesserte Geschäftsprozesse müssen in betriebliche Informationssysteme umgesetzt werden. An dieser Schnittstelle entstehen in der Praxis noch häufig Probleme, weil Vorgehensweise, Methoden und Werkzeuge der Geschäftsprozessmodellierung einerseits und der objektorientierten Entwicklung andererseits weitgehend unabhängig voneinander entstanden sind und sich deshalb deutlich unterscheiden. Diese zeit- und fehlerträchtige Bruchstelle zu überbrücken, ist Ziel des vorliegenden Buches „Objektorientierte Geschäftsprozessmodellierung mit der UML“. Hervorzuheben sind eine Reihe weiterer Vorzüge dieser Methodik. Sie ist im Buch, wie meine Kollegin Susanne Strahringer von der European Business School anmerkt, „didaktisch sehr gut aufbereitet und hervorragend strukturiert“. Die Buchautoren arbeiten seit Jahren in der objektorientierten Entwicklung, wie u.a. die vielen einschlägigen Publikationen des Hauptautors Bernd Oestereich belegen. Sie haben die Methode seit 2001 in engem Kontakt mit der Praxis entwickelt, dort vielfach angewandt und auf der Basis ihrer Erfahrungen sukzessive verbessert. Ein wichtiger Aspekt ihrer Methode ist größtmögliche Einfachheit und damit verbunden die Verpflichtung auf die Grundsätze agiler Softwareentwicklung. Darüber hinaus ist die im Buch an vielen Beispielen veranschaulichte Vorgehensweise anbieterneutral und lässt sich mit fast jedem gebräuchlichen UML-Tool kombinieren. Das alles spricht dafür, dass Sie als Leserin bzw. Leser das Buch nicht nur studieren (wobei Glossar und Index Sie zusätzlich unterstützen), sondern im Anschluss daran die „Objektorientierte Geschäftsprozessmodellierung mit der UML“ an einem geeigneten echten oder Studienprojekt ausprobieren und testen. Dazu wünsche ich Ihnen nicht nur viel Erfolg, sondern auch eine gehörige Portion Spaß! Prof. Dr. Heidi Heilmann Sindelfingen, im Mai 2003

vi

Vorwort Ursprünglich ist die Geschäftsprozessmodellierung eine Domäne der Betriebswirtschaft. Aus Sicht der Informatik ist Geschäftsprozessmodellierung nur ein Randbereich. Aus den Ergebnissen einer Geschäftsprozessmodellierung können aber Anforderungen und Rahmenbedingungen für Softwareentwicklungsprojekte entstehen. Die Fragen, die mit Geschäftsprozessmodellierung berührt werden, sind aber eher betriebswirtschaftlicher Natur. Es geht hier beispielsweise um Produktivitätssteigerungen, Outsourcing, Controlling, Reorganisation und eben auch, und hier kommt die Informatik ins Spiel, um Automatisierung. Methodisch beinhaltet Geschäftsprozessmodellierung die Analyse und Beschreibung von Abläufen und ihre Einbettung in eine Organisation und andere Rahmenbedingungen. Im Bereich der Ablaufmodellierung sowie der Analyse und Beschreibung von Anforderungen, wie beispielsweise Geschäftsregeln, existieren in der Informatik viele bewährte Ansätze und standardisierte Notationen. Diese sind nicht originär für Geschäftsprozessmodellierung vorgesehen – nichtsdestotrotz dafür geeignet oder prädestiniert. Die Unified Modeling Language (UML) ist ein international (bspw. durch OMG und ISO1) und durch die Praxis anerkannter Standard in der (objektorientierten) Softwareentwicklung. Die Autoren dieses Buches kommen zum einen aus diesem Umfeld, zum anderen aus einem betriebswirtschaftlichen Bereich. Sie haben erkannt, dass die aktuellen Standardverfahren und -notationen der Informatik, also beispielsweise UML, auch für Geschäftsprozessmodellierung geeignet sind und dass damit ein Bruch in der Darstellung und in der Vorgehensweise zwischen Geschäftsprozessmodellierung und Softwareentwicklung geschlossen werden kann. Die wichtigsten Vorteile der Geschäftsprozessmodellierung mit Standardverfahren der Informatik sind:  Durchgängigkeit: Die methodische Durchgängigkeit von der Geschäftsprozessanalyse bis in die informationstechnische Automatisierung dieser Geschäftsprozesse wird möglich.  Bewährte und etablierte Techniken: Objektorientierte Programmierung und Modellierung wird seit vielen Jahren erfolgreich eingesetzt und hat bewiesen, dass damit große und komplexe Systeme 1

OMG (Object Management Group) ist ein Industriekonsortium u.a. zur Entwicklung, Vereinheitlichung und Standardisierung von Informationstechnologien. ISO (International Organization for Standardization) ist eine 1947 gegründete Vereinigung der einzelnen nationalen Standardisierungsinstanzen aus über 140 Ländern.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

vii

bewältigt werden können. Entwurfsmuster und -prinzipien der Informatik lassen sich auf die Geschäftsprozessmodellierung übertragen.  Nachvollziehbarkeit: Anforderungen, die das Geschäft stellt, lassen sich bis zur Implementierung herunter (und zurück) nachvollziehbar dokumentieren.  Bessere Verständigung: So wie Objektorientierung und UML die Kluft zwischen Analyse und Design verringert haben, kann die Verwendung derselben Konzepte die Barriere zwischen Prozessmodellierern und Systemanalytikern aufweichen.  Breite Werkzeugunterstützung: Für die UML stehen eine Vielzahl ausgereifter Werkzeuge mit verschiedenen Schwerpunkten und für unterschiedliche Zielgruppen bereit. Das vorliegende Buch wendet sich also gleichermaßen an InformatikerInnen, beispielsweise in der Software-Projektleitung, Analyse und Design, als auch an MitarbeiterInnen aus den Bereichen Geschäfts- und Betriebsorganisation, Controlling, Unternehmensberatung und Betriebswirtschaft. Mit unserem hier vorgestellten Ansatz verfolgen wir außerdem das Ziel, möglichst einfache Modelle zu erstellen, die gerade ausreichend sind, die mit der Geschäftsprozessmodellierung verbundenen Ziele zu erreichen. Wir glauben, dass nicht der Umgang mit möglichst vielen und genauen Informationen zu einer erfolgreichen Geschäftsprozessmodellierung führt, sondern die klare Strukturierung und Einfachheit. „Einfachheit ist eine Tugend. Einfachheit gibt Stärke“, sagt IkeaGründer Ingvar Kamprad. Welcher Grad der Einfachheit für eine konkrete Geschäftsprozessmodellierung angemessen ist, lässt sich nicht allgemein gültig beschreiben und ist im konkreten Arbeitskontext herauszufinden und zu entscheiden. Wir möchten Sie an dieser Stelle aber ermutigen, unsere zahlreichen Hinweise auf Vereinfachungsmöglichkeiten in dem Buch ernst zu nehmen und im Zweifelsfall immer den einfacheren Weg zu gehen. Etwas einfach zu machen ist nicht einfach, es bedarf der geschickten Abstraktion vom Komplexen zum Wesentlichen. Bernd Oestereich

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

ix

Inhaltsüberblick 1

Einleitung ............................................................................. 1 In diesem Kapitel erhalten Sie eine kurze Einführung, warum Geschäftsprozessmodellierung wichtig ist, wo sie herkommt und wie sie sich abgrenzt von Objektorientierung, UML, Anforderungsanalyse u.a.

2

Überblick und Orientierung ............................................. 17 In diesem Kapitel finden Sie eine kurze Zusammenfassung unserer Methodik und Informationen zu ihrer Einbettung in die System- und Softwareentwicklung.

3

OOGPM-Methodik ............................................................. 35 Hier lernen Sie anhand eines durchgängigen praxisnahen Fallbeispiels die Methodik objektorientierter Geschäftsprozessmodellierung (OOGPM) kennen. Verteilt auf 20 Einzelschritte sehen Sie die typischen Aktivitäten und Ergebnisse einer systematischen Vorgehensweise, wie diese zusammenhängen, aufeinander aufbauen und was dabei in der Praxis zu beachten ist.

4

UML – Notation und Semantik....................................... 145 In dem Fallbeispiel und der Methodik verwenden wir die Unified Modeling Language (UML) in einer speziellen Ausprägung für Geschäftsprozessmodellierung. Die Semantik, Notation sowie besondere formale und praktische Aspekte aller wichtigen Modellelemente werden in diesem Kapitel erläutert.

5

Anhang ............................................................................. 217 Abkürzungen ..................................................................... 219 Glossar .............................................................................. 220 Literatur ............................................................................. 229 Index .................................................................................. 233

x

Inhaltsverzeichnis 1

Einleitung ........................................................................................... 1

1.1

Warum Geschäftsprozessmodellierung?................................................... 3

1.2

Historie der Geschäftsprozessorientierung............................................... 9

1.3 1.3.1 1.3.2 1.3.3

Abgrenzung .................................................................................................. 11 Objektorientierung und UML ......................................................................... 12 Andere Modellierungsansätze....................................................................... 14 Requirements Engineering ............................................................................ 16

2

Überblick und Orientierung ............................................................ 17

2.1

Vorgehensweise........................................................................................... 19

2.2

Einbettung in die Systementwicklung ...................................................... 31

3

OOGPM-Methodik............................................................................ 35

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20

Modellierungsfokus festlegen und Unternehmensziele beschreiben .......... 37 Organisationseinheiten modellieren.............................................................. 43 Ziele festlegen................................................................................................ 46 Aktive Geschäftspartner identifizieren .......................................................... 51 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren..... 56 Weitere unterstützende Geschäftsanwendungsfälle identifizieren .............. 66 Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln................ 72 Geschäftsprozesse definieren....................................................................... 77 Geschäftsprozesse dokumentieren............................................................... 84 Geschäftsanwendungsfälle essenziell beschreiben..................................... 87 Geschäftsanwendungsfall-Abläufe modellieren ........................................... 96 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren ............. 102 Geschäftsanwendungsfall-Abläufe detaillieren........................................... 111 Organisatorische Einbettung und Abhängigkeiten identifizieren ............... 114 Geschäftsanwendungsfallmodell erstellen ................................................. 118 Geschäftsklassenmodell erstellen............................................................... 123 Zustandsmodelle für zustandsrelevante Geschäftsklassen erstellen........ 127 Geschäftliche Anforderungen und Regeln beschreiben............................. 129 Systemanwendungsfälle definieren ............................................................ 133 Glossar und Abkürzungsverzeichnis entwickeln ........................................ 141

4

UML – Notation und Semantik ...................................................... 145

4.1

UML.............................................................................................................. 147

4.2 4.2.1

Akteur .......................................................................................................... 148 Aktive Geschäftspartner .............................................................................. 150

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

xi

4.2.2 4.2.3 4.2.4 4.2.5

Passive Geschäftspartner ............................................................................151 Innenorientierte Geschäftsmitarbeiter .........................................................152 Außenorientierte Geschäftsmitarbeiter........................................................153 Systemakteure..............................................................................................154

4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 4.3.8 4.3.9 4.3.10 4.3.11

Anwendungsfallmodell ..............................................................................155 Spezialisierung, Realisierung von Anwendungsfällen ................................156 Enthält-Beziehung ........................................................................................158 Assoziation in Anwendungsfalldiagrammen................................................159 Anwendungsfall (allgemein).........................................................................160 Geschäftsprozess.........................................................................................163 Geschäftsanwendungsfall ............................................................................165 Kern-Geschäftsanwendungsfall...................................................................166 Unterstützender Geschäftsanwendungsfall.................................................167 Systemanwendungsfall ................................................................................168 Sekundärer Anwendungsfall ........................................................................169 Anforderung ..................................................................................................170

4.4 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6 4.4.7 4.4.8 4.4.9

Aktivitätsmodelle........................................................................................175 Aktivitätsdiagramm .......................................................................................175 Aktivität und Transition .................................................................................177 Aktivitätsbeschreibung .................................................................................179 Funktionsbaum .............................................................................................181 Verzweigungen und Zusammenführungen .................................................182 Involvierte Geschäftsobjekte ........................................................................184 Signal ............................................................................................................185 Spezialisierung/Generalisierung von Aktivitäten und Anwendungsfällen...186 Verantwortlichkeitsbereiche .........................................................................187

4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 4.5.6 4.5.7 4.5.8

Geschäftsklassenmodell ...........................................................................188 Klasse ...........................................................................................................189 Verantwortlichkeit .........................................................................................191 Attribut...........................................................................................................192 Operation ......................................................................................................193 Assoziation ...................................................................................................194 Spezialisierung/Generalisierung von Klassen .............................................198 Abstrakte Klasse...........................................................................................200 Schnittstelle ..................................................................................................201

4.6

Pakete ..........................................................................................................204

4.7 4.7.1 4.7.2

Organisationsplan......................................................................................206 Organisationseinheit.....................................................................................207 Organisationsbeziehungen ..........................................................................209

4.8 4.8.1 4.8.2

Zustandsmodelle ........................................................................................211 Zustand .........................................................................................................213 Ereignis und Zustandsübergang..................................................................214

xii

5

Anhang ........................................................................................... 217

5.1

Abkürzungsverzeichnis ............................................................................ 219

5.2

Glossar........................................................................................................ 220

5.3

Literatur....................................................................................................... 229

5.4

Index ............................................................................................................ 233

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

1 Einleitung

Phantasie ist wichtiger als Wissen. Albert Einstein

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

1.1 Warum Geschäftsprozessmodellierung?

1.1

Warum Geschäftsprozessmodellierung?

Extrakt  Geschäftliche Abläufe entstehen in Unternehmen häufig ungeplant und willkürlich aus einer Menge einzelner Aktivitäten, die jeweils nur die begrenzte Perspektive einer einzelnen Person berücksichtigen und dadurch in ihrer Gesamtheit häufig unstrukturiert oder chaotisch sind.  Geschäftliche Abläufe entwickeln oft eine Eigendynamik, deren Stärke zunimmt, je instabiler und bewegter das geschäftliche Umfeld ist. Dadurch unterliegen auch einstmals geordnete Prozesse einem schleichenden Strukturverfall.  Prozesse sollen automatisiert und Prozesslücken durch neue Hardund Software geschlossen werden, um Kosten zu senken und die Produktivität zu erhöhen.  Die Organisationsstrukturen in Unternehmen sollen zur Produktivitätssteigerung optimiert oder Teile der Prozesskette gar aus- oder wieder eingelagert werden (Out- bzw. Insourcing).  Unternehmenszusammenschlüsse und -kooperationen sollen Synergieeffekte bewirken.  Im Hinblick auf die vorgenannten Effekte und Ziele werden Geschäftsprozesse modelliert, um sie zu verstehen, zu dokumentieren, zu analysieren und zu verbessern. Dabei ist zu berücksichtigen, wie viel Modellierung im Hinblick auf die zu erreichenden Ziele notwendig und angemessen ist.  Die Beurteilung eines Geschäftsprozesses setzt Kenntnis von Unternehmenszweck und -zielen voraus.

Unternehmen möchten wissen, wie ihre Arbeit abläuft, um daraus Erkenntnisse und Entscheidungen abzuleiten, wie der Unternehmenszweck und die Unternehmensziele optimal unterstützt werden können. Während es in der Vergangenheit eher darum ging, Produktivitätsstei- Produktivitätssteigerung, gerungen beispielsweise durch Automatisierung zu bewirken, das heißt, Automatisierung, Zeit, Kosten, Qualität und andere Faktoren zu optimieren, geht es seit Outsourcing kurzem immer mehr darum, welche Teile des Prozesskette aus dem Unternehmen ausgelagert und an Dritte übertragen werden können (sog. Outsourcing).

3

4

1.1 Warum Geschäftsprozessmodellierung?

Außerdem agieren Unternehmen immer mehr in dynamischen Umgebungen. Die Rahmenbedingungen ihres Geschäftes ändern sich stetig und die zu beachtenden Abhängigkeiten werden komplexer. Ob die existierenden Abläufe in einem Unternehmen angemessen oder optimal sind, hängt also auch von äußeren Faktoren ab, so dass sich der Grad der Zielerreichung auch ohne Verursachung durch das Unternehmen ändern kann. Ein wichtiges Mittel, um Erkenntnisse zu gewinnen, wie der Unternehmenszweck und die Unternehmensziele optimal unterstützt werden können, und um Entscheidungen zur Optimierung zu begründen oder zu überprüfen, ist die Geschäftsprozessmodellierung. Änderungen im Umfeld, bspw. im Verhalten der Geschäftspartner

Schleichende Prozessveränderungen und -erweiterungen. Angenommen, ein Unternehmen verkauft Produkte und besitzt hierfür wohldefinierte und effiziente Geschäftsprozesse. Irgendwann treten Änderungen im üblichen Verhalten oder der Kommunikation mit dem Kunden auf. Beispielsweise treffen immer weniger Bestellungen schriftlich ein, stattdessen telefonisch oder per E-Mail. Einige der vorgesehenen Mechanismen funktionieren dann vielleicht nicht mehr, beispielsweise das Ablagesystem für die Korrespondenz. Außerdem verändert sich damit eventuell die (juristische) Qualität, weil E-Mails anfechtbarer sind oder weil die sonst üblichen Korrespondenzbestandteile (Firmierung, Adresse, Handelregisterinformation, SteuerIDs etc.) unvollständig sind. Die mit der Sachbearbeitung betrauten Mitarbeiter geben ihr Bestes und erfinden und improvisieren jetzt ganz neue Mechanismen und Abläufe, um weiterhin die Kunden optimal zu bedienen. Die Entscheidungsträger oder Verantwortlichen im Unternehmen registrieren diese allmählich zunehmenden Veränderungen sehr wahrscheinlich noch nicht.

Ad-hoc-Erfindungen und Improvisationen der Prozessbeteiligten

Die einzelnen Sachbearbeiter betrachten bei ihren Ad-hoc-Erfindungen und improvisierten Prozessveränderungen mit großer Wahrscheinlichkeit nicht das Unternehmen und die Abläufe in ihrer Gesamtheit, sondern nur den für sie sichtbaren und relevanten Ausschnitt. Indirekt verändert sich in Folge davon auch die Zusammenarbeit mit anderen Abteilungen und Mitarbeitern im Unternehmen, d.h., der Impuls für Veränderungen breitet sich im Unternehmen aus. In vielen Fällen führt dies zu einem schleichenden Verlust der Effizienz, die Kosten erhöhen sich, die Qualität leidet vielleicht, die Ausnahmen, Fehler, Reklamationen, Bearbeitungszeiten, Verantwortlichkeitsgerangel und Unregelmäßigkeiten nehmen zu und so weiter. Diese Beispiele zeigen, wie Geschäftsprozesse auch in ansonsten wohlstrukturierten Unternehmen chaotisch werden können.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

1.1 Warum Geschäftsprozessmodellierung?

Willkürliche und unkontrollierte Prozessgestaltung. Es gibt natürlich auch Fälle, in denen von Anfang an Chaos herrscht. Dies betrifft in Undefinierte Geschäftsbesonderem Maße neu gegründete und sehr schnell wachsende Unter- prozesse in Start-ups nehmen mit unerfahrenen Führungskräften. Viele so genannte Start-upUnternehmen in den Dotcom-Boom-Jahren 1999 – 2001 zeigten solche Phänomene. Aufgaben und Funktionen im Unternehmen wurden grob definiert, es wurden hierfür Mitarbeiter eingestellt, die dann in der Ausgestaltung ihrer Aufgaben und Funktionen weitgehend sich selbst überlassen wurden. Durch das rasante Unternehmenswachstum konnte es passieren, dass eine Aufgabe zunächst von einer einzelnen Person und wenige Monate später bereits von 3 - 5 Mitarbeitern wahrgenommen wurde. Hier treten ähnliche Effekte auf wie bei den schleichenden Veränderungen in wohlkonstituierten Unternehmen, meistens jedoch schneller und deutlicher. Verbesserung der unternehmerischen Reaktionsfähigkeit. Ein Ver- Time to market sandhaus konnte sich früher bis zur Einführung neuer Artikel in sein Sortiment wenigstens ein halbes Jahr Zeit lassen, dem Zeitpunkt nämlich, zu dem der neue Katalog fertig sein musste. Und es konnte dabei halbwegs sicher sein, dass auch die Konkurrenz nicht eher mit einem neuen Katalog aufwarten würde. Durch die Internettechnologie hat heute derjenige einen Wettbewerbsvorteil, der als Erster mit seinen neuen Produkten den Markt beglückt. Dies bedingt, dass die Neueinführung von Produkten, Tarifen usw. heute sehr viel schneller auch in der bestehenden Software abgebildet werden muss (auch wenn den Informatikern bei der Anforderung „der Tarif muss bis zum 1.7. fertig sein“ ob der bevorstehenden massiven Modifikationen in der Software regelmäßig mulmig wird). Lückenschluss in der Automatisierung. Ein weiteres Beispiel ist die Produktivität Absicht eines Unternehmens, die Kosten zu senken bzw. die Produkti- Kostensenkung vität zu erhöhen, indem möglichst viele Teile der Prozesskette automatisiert werden. Hierbei wird untersucht, welche Arbeiten manuell durchgeführt werden und welche Alternativen es gibt, um diese Arbeiten ganz oder teilweise zu automatisieren, beispielsweise durch entsprechende Hard- und Software. Unter diesen Umständen resultieren aus einer Geschäftsprozessanalyse und -modellierung gewöhnlich unmittelbar ein oder mehrere Systementwicklungsprojekte zur Neuentwicklung oder Erweiterung von Hardund Software. Die Geschäftsprozessmodellierung mündet dann in die Anforderungsanalyse der Systementwicklungsprojekte. Organisatorische Optimierung und Outsourcing. Möglicherweise können Kosten, Produktivität oder Risiken eines Unternehmens aber auch dadurch optimiert werden, dass Aufgaben und Verantwortlichkei-

5

6

1.1 Warum Geschäftsprozessmodellierung?

ten anders verteilt werden, dass das Unternehmen also anders organisiert wird. Im Extremfall werden einzelne Abschnitte der Prozesskette an externe Unternehmen abgegeben. Hierbei werden die Geschäftsprozesse dahingehend optimiert, die Anzahl der Schnittstellen zu begrenzen und dennoch möglichst umfangreiche Teile der Prozesskette auszulagern. Insourcing

„Das machen wir immer so“

Weniger populär, aber unter Umständen dennoch zweckmäßig und erfolgversprechend ist der umgekehrte Weg, ausgelagerte Prozessketten zurückzuholen (Insourcing). Ein anderer wichtiger Aspekt hierbei ist die Beseitigung etablierter Aktivitäten und Ergebnisse, die früher einmal wichtig oder sinnvoll waren, heute aber ihre Bedeutung verloren haben und den Geschäftsprozess mehr bremsen als unterstützen. Gerade wenn in einem Unternehmen Geschäftsprozesse explizit definiert sind, entsteht diese Situation. Prozesse wurden definiert und bilden eine Art Vorgabe für die Mitarbeiter. Diese halten sich daran, ohne Sinn oder Zweck explizit zu hinterfragen. Dadurch entgeht dem Unternehmen, dass die Notwendigkeit oder Zweckmäßigkeit dieser Vorgaben längst entfallen oder geringfügig geworden ist. Das pathologische „Das machen wir immer so“-Syndrom ist weit verbreitet. Unternehmenszusammenschlüsse. In einer Zeit, in der Zukäufe und Fusionen von Unternehmen häufiger und schneller proklamiert werden, als Briefpapier und Visitenkarten neu gedruckt werden können, bilden Geschäftsprozessmodelle die Grundlage, um aus zwei unterschiedlich funktionierenden Unternehmen ein neues möglichst optimal agierendes zu entwickeln. Geschäftsprozessmodelle können aber auch eine wichtige Entscheidungsgrundlage dafür bilden, ob eine Fusion oder Kooperation überhaupt sinnvoll und zielführend ist.

Synergieeffekte und Redundanzbeseitigung

Bei Fusionen wird gewöhnlich viel von so genannten Synergien oder Synergieeffekten2 geredet, mit denen der Zusammenschluss gerechtfertigt und den Gesellschaftern und Aktionären schmackhaft gemacht werden soll. Beispielsweise indem Geschäftsstellen, Vertriebswege u.Ä. des einen Partners für die Produkte und Dienstleistungen des anderen genutzt werden können. Oder indem ähnliche Produktionsstätten und Verwaltungsbereiche zusammengelegt und Redundanzen3 beseitigt werden. In der Praxis ergeben sich Synergieeffekte selten von selbst. Im Gegenteil: Eine ungeplante und unkontrollierte Fusion kann die bestehenden 2 3

Synergieeffekt: griech.-neulat. für eine positive Wirkung, die sich aus dem Zusammenwirken mehrerer Einzelkräfte ergibt. Redundanz: lat. überreichlich, überflüssig. Bezeichnet gewöhnlich Dinge, die ohne Verlust entfallen können.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

1.1 Warum Geschäftsprozessmodellierung?

und funktionierenden Geschäftsprozesse der fusionierenden Partner durch zusätzlichen Kommunikationsbedarf und neue Fehlerquellen behindern. Durch die Ad-hoc-Erfindungen der beteiligten Akteure, mit denen sich diese den Veränderungen anpassen, werden Geschäftsprozesse zusätzlich erschwert, da übergreifende Zusammenhänge und Abhängigkeiten meistens unberücksichtigt bleiben. Eine grundlegende Geschäftsprozessmodellierung kann die Basis bil- Synergieanalyse den, um die typischen nachteiligen Effekte einer Fusion zu vermeiden und die angestrebten Synergieeffekte systematisch zu erkennen und zu entwickeln. Modellierung von Geschäftsprozessen. Die genannten Beispiele lie- Methodik, Systematik fern gute Gründe, sich mit der Modellierung von Geschäftsprozessen zu beschäftigen. Es beginnt damit anzuerkennen, dass die meisten ge- Zweck und Ziele von schäftlichen Tätigkeiten in der Praxis nach bestimmten Regeln ablau- Geschäftsprozessen fen, mit denen ein geschäftlicher Zweck verfolgt wird, und dass die Struktur und Gestaltung des Ablaufes entscheidend die Erreichung möglicher (geschäftlicher) Ziele beinflusst. Um den eben beschriebenen negativen Phänomenen entgegenzuwirken bzw. die beschriebenen Ziele zu erreichen, müssen die vorhandenen oder notwendigen geschäftlichen Abläufe zunächst überhaupt verstanden werden. Anschließend können sie analysiert und verbessert werden. Um dann herauszufinden, ob ein Geschäftsprozess gut oder schlecht funktioniert oder wie er gut oder besser funktionieren könnte, muss geklärt werden, was der geschäftliche Zweck ist und welche Ziele damit verbunden sind. Denn daran knüpft sich die Bewertung und mögliche Verbesserung der Prozesse. Agilität. Zu beachten ist allerdings, dass geschäftliche Abläufe immer Angemessenheit: nur bis zu einem gewissen Grad überhaupt planbar und regelbar sind. Agile Methodik Je konkreter und genauer sie spezifiziert sind, desto weniger flexibel sind sie, d.h., desto größer ist die Wahrscheinlichkeit, dass sie versagen, sobald die Rahmenbedingungen und die im Modell angenommenen Voraussetzungen nicht oder nicht ausreichend erfüllt sind. Dann reagieren die Beteiligten wieder mit improvisierten Änderungen, um die Abläufe weiterhin erfolgreich zu bewältigen. Oder die Kunden bleiben weg und das Geschäft läuft nicht mehr, wenn die Anpassung der Abläufe nicht gelingt oder nicht zugelassen wird. Die von uns in diesem Buch beschriebene Methodik beinhaltet daher auch, herauszuarbeiten, welche Detailtiefe, welcher Abstraktionsgrad, welche Verbindlichkeit usw. notwendig, angemessen und sinnvoll sind, damit die entstehenden Geschäftsprozessmodelle ihren Zweck optimal erfüllen und das Unternehmen in seinen Abläufen agil bleibt. Wir bezeichnen unsere Methodik daher auch als agile Methodik.

7

8

1.1 Warum Geschäftsprozessmodellierung?

Um einen Geschäftsprozess zu bewerten und möglicherweise zu verbessern, muss man ihn zuvor verstehen. Geschäftsprozessmodellierung wird also betrieben, um die geschäftlichen Abläufe zu verstehen, zu dokumentieren, zu analysieren und zu verbessern: Aufmerksamkeit lenken

ISO

Messen

Restrukturierungen

 Verstehen. Durch die Modellierung von Geschäftsprozessen wird das Verständnis der Geschäftsprozesse und die verwendete Begriffswelt vereinheitlicht. Die Modellierung von Geschäftsprozessen fördert durch simplifizierte Sichten die Diskussion komplexer Sachverhalte. Statt intensiver Detaildiskussionen wird die Aufmerksamkeit durch die Modellierung auf die wichtigen Aspekte gelenkt, beispielsweise die Kundenbedürfnisse.  Dokumentieren. Ein beschriebener Geschäftsprozess legt für alle Beteiligten unmissverständlich die Verantwortlichkeiten fest, beispielsweise von Organisationseinheiten für bestimmte Aktivitäten. Als solcher dokumentiert er nachvollziehbar getroffene Entscheidungen und erlaubt es neuen Mitarbeitern, sich schneller zurechtzufinden. Sofern der beschriebene Geschäftsprozess als Soll formuliert wurde, fungiert er gleichermaßen als Plan und sorgt dadurch für eine gewisse Zielführung. Nicht zuletzt erfordern auch einige ISO-Zertifizierungen die nachvollziehbare Dokumentation von Geschäftsprozessen.  Analysieren. Ein Bild sagt mehr als tausend Worte. Und eine grafische Darstellung eines Geschäftsprozesses kann sehr viel eindrucksvoller darstellen, warum bestimmte Abläufe unsinnig sind. Beispielsweise wird erkennbar, an welchen Stellen Organisationsbrüche oder Systembrüche existieren. Durch die Modellierung und die damit verbundene Formalisierung eines Ablaufs wird er ebenso hinsichtlich Zeit und Kosten messbar. Entsprechende Softwarewerkzeuge berechnen Durchlaufzeiten, Liegezeiten usw. und zeigen Engpässe auf.  Verbessern. Die durch die Analyse eines Geschäftsprozesses aufgedeckten Schwachstellen können systematisch angegangen und einer Lösung zugeführt werden. Insbesondere wenn man dabei die Sicht des Kunden berücksichtigt, kann eine Prozessveränderung zu einer immensen Steigerung des Kundennutzens führen und somit einen Wettbewerbsvorteil verschaffen. Das Erkennen von Out- oder Insourcing-Potenzial kann zu einer Restrukturierung von Verantwortlichkeiten führen, die dann dem Optimierungsziel des Unternehmens dient. Und schließlich enthüllt eine Analyse der Geschäftsprozesse das Automatisierungspotenzial. Modellierung hilft Verstehen. An geschäftlichen Abläufen sind gewöhnlich viele verschiedene Personen innerhalb und außerhalb des be-

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

1.2 Historie der Geschäftsprozessorientierung

trachteten Unternehmens beteiligt. Jeder Beteiligte hat dabei seine ganz eigene Perspektive und ganz eigene Interessen. Diese können sich unterstützen und ergänzen, aber auch widersprechen und gegenseitig behindern. Während ein einzelner Schritt im Ablauf für den Beteiligten vielleicht gut überschaubar und verstehbar ist, können die übergeordneten Sachverhalte, beispielsweise Abhängigkeiten, sehr komplex und unübersichtlich werden. Die verschiedenen Beteiligten haben aber vielleicht nicht nur unter- Verschiedene Sichten schiedliche Interessen, sie verwenden möglicherweise unterschiedliche zusammenführen Begriffe und haben ein sehr unterschiedliches Verständnis vom Gesamtablauf.  Was glauben die Beteiligten, wie die geschäftlichen Prozesse in unserem Unternehmen ablaufen?  Wie laufen die Prozesse in unserem Unternehmen tatsächlich ab?  Wie sollten sie ablaufen? Die Modellierung von Geschäftsprozessen hilft dabei, ein einheitliches Verständnis und eine einheitliche Begriffswelt zu schaffen, und ist der systematische Ansatz zur Beantwortung solcher Fragen.

1.2

Historie der Geschäftsprozessorientierung

Extrakt  Adam Smith und Frederick W. Taylor proklamieren am Ende des 18. Jahrhunderts die Arbeitsteilung.  Henry Ford und Alfred Sloan führen 1913 Montagebänder zur Massenproduktion ein.

Die Wurzeln des Denkens in (maschinellen) Prozessen gehen zurück auf Adam Smith und Frederick W. Taylor. Adam Smith war ein ameri- Adam Smith und Frederick W. Taylor kanischer Ökonom und Philosoph, der mit seinem 1776 veröffentlichten Buch „Der Wohlstand der Nationen“ berühmt wurde. Darin beschreibt er, welche riesigen Chancen sich dem produzierenden Gewerbe durch die industrielle Revolution eröffnen. Er zeigt, wie durch den Übergang zur maschinellen Herstellung in Großbetrieben die Produktivität der Arbeitskräfte um Größenordnungen gesteigert werden kann und sich damit beispielsweise die Warenkosten erheblich senken lassen.

9

10

Taylorismus

1.2 Historie der Geschäftsprozessorientierung

Adam Smith begründete damit den Grundsatz der Arbeitsteilung, d.h. der höchstmöglichen Fragmentierung und Spezialisierung der Arbeit. Frederick W. Taylor hat diese Ideen später weiterentwickelt. Nach ihm wurde der „Taylorismus“ benannt. In der Folge dieser Ideen wurden in vielen Unternehmen spezielle Betriebsabläufe und Strukturen geschaffen, d.h., Abläufe wurden durch allerlei Handlungs- und Ausführungsanweisungen geregelt und standardisiert, Kompetenzen und Verantwortlichkeiten wurden klar aufgeteilt und Berichtswege explizit definiert.

Henry Ford und Alfred Sloan

1938: Chester F Carlson und die Objektorientierung

Michael Hammer, James Champy und Thomas H. Davenport

Zwei andere wichtige Pioniere auf diesem Gebiet waren Henry Ford und Alfred Sloan, die ab 1913 Montagebänder einsetzten, die Werkstücke von einem Arbeiter zum nächsten transportierten, d.h., die Fließbandarbeit zur Massenfertigung erfanden. Danach war die Industrie und Geschäftswelt geprägt von einer allmählichen Verfeinerung und Perfektionierung dieser Ansätze. 1938 erfand der Physiker Chester F. Carlson die Fotokopie, die heute immer noch eine der wichtigsten Technologien zur Unterstützung von Geschäftsprozessen darstellt. 1944 griff die Firma Xerox das Patent auf und brachte Fotokopiermaschinen zur Praxisreife. Übrigens stoßen wir hier bereits auf die Keime der Objektorientierung, denn nicht zuletzt mit den Einnahmen aus den Fotokopierern entstand das Xerox PARC (Palo Alto Research Center), in dem seit Anfang der 1970er Jahre an der Mensch-Maschine-Schnittstelle gearbeitet wurde und alle wichtigen Konstrukte der Objektorientierung in Form der Programmiersprache Smalltalk entstanden. Ebenso wurden viele andere, heute selbstverständliche Konzepte wie PC, Fensteroberflächen, Maus etc. dort, wenn nicht unbedingt erfunden, so doch zur Reife gebracht oder integriert. In den 1980er Jahren wurden Themen wie Just-in-Time-Produktion, kontinuierlicher Verbesserungsprozess und Qualitätsmanagement populär und führten in die Richtung des heutigen Verständnisses von Geschäftsprozessmodellierung. Vordenker auf diesem Gebiet sind Michael Hammer, James Champy ([Hammer93], [Hammer90]) und Thomas H. Davenport ([Davenport93], [Davenport90]) die Anfang der 1990er Jahre hierzu publizierten. Hammer und Champy definieren einen Geschäftsprozess als eine Folge von Tätigkeiten, die über verschiedene betriebliche Funktionsbereiche, d.h. quer durch die Organisationseinheiten, einen Wert für Kunden und Unternehmen schaffen. Parallel dazu sind Ansätze zur Geschäftsprozessmodellierung auch im Bereich der Informatik aufgenommen und vorangetrieben worden, beispielsweise durch Ivar Jacobson ([Jacobson92], [Jacobson94]) und in Deutschland durch August-Wilhelm Scheer ([Scheer94]).

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

1.3 Abgrenzung

Weiterführende Literatur: [Davenport90] T. H. Davenport; J. E. Short: The New Industrial Engineering: Information Technology and Business Process Redesign. In: Sloan Management Review, Boston, Summer, 1990. [Davenport93] T. H. Davenport: Process Innovation: Reengineering Work through Information Technology. Harvard Business School Press, Boston, 1993. [Hammer90] M. Hammer: Reengineering Work: Don't Automate, Obliterate, Harvard Business Review July-August 1990, S. 104 – 112. [Hammer93] M. Hammer, J. Champy: Reengineering the Corporation: A Manifesto for Business Revolution. HarperBusiness, New York, 1993. [Harrington91] H. J. Harrington: Business Process Improvement: The Breakthrough Strategy for Total Quality, Productivity, and Competitiveness, McGraw-Hill, New York, 1991. [Jacobson92] I. Jacobson, M. Christerson, P. Jonsson, G. Overgaard: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, Reading, 1992. [Jacobson94] I. Jacobson, M. Ericson, A. Jacobson: Object Advantage, The: Business Process Reengineering with Object Technology. Addison-Wesley, Reading, 1994. [Scheer94] A.-W. Scheer: Business Process Engineering: Reference Models for Industrial Enterprise-Modeling. Springer, Berlin, 1994.

1.3

Abgrenzung

Extrakt  Sie erhalten hier Hinweise auf verwandte Methoden und Disziplinen.

Die in diesem Buch vorgestellte Methodik ist nicht die einzige, und es existieren außerdem Berührungspunkte zu anderen angrenzenden Disziplinen. Zugunsten eines dünneren Buches verzichten wir auf eine genauere oder gar vollständige Abgrenzung zu anderen Methoden und angrenzenden Disziplinen und geben lediglich Hinweise auf die aus unserer Sicht wichtigsten Punkte sowie die entsprechende weiterführende Literatur in diesem Zusammenhang.

11

12

1.3 Abgrenzung

1.3.1 Objektorientierung und UML Extrakt  Was ist Objektorientierung? Was ist UML (Unified Modeling Language)?  Warum Objektorientierung und UML für Geschäftsprozessmodellierung?

Was ist Objektorientierung? Bis hinein in die 90er Jahre des letzten Jahrhunderts war die Softwareentwicklung beherrscht vom Paradigma der so genannten prozeduralen Softwareentwicklung. Diese unterschied in sehr deutlicher Weise auf der einen Seite die Daten und auf der anderen Seite die Prozeduren (Operationen), welche die Daten bearbeiten. In den 70er Jahren entwickelte sich ein neues Paradigma, die so genannte objektorientierte Softwareentwicklung, die sich dann in den 90er Jahren in der Praxis durchsetzte. Die objektorientierte Softwareentwicklung stellt einen ganzheitlichen Ansatz dar, d.h., Daten und Operationen werden fachlich gruppiert jeweils als eine Einheit, so genannte Objekte, angesehen. Näheres hierzu in der Literatur, beispielsweise in [Oestereich01a]. UML 145

Klassische Methoden: SA, SD, ERM etc.

Was hat GPM mit Software zu tun?

Was ist UML? Im Zuge der Etablierung der objektorientierten Softwareentwicklung (kurz Objektorientierung genannt) wurde die Unified Modeling Language (UML) entwickelt, eine grafische Modellierungssprache zur Beschreibung von Modellen und Konstruktionsplänen für die (objektorientierte) Systementwicklung. Näheres hierzu im Kapitel 4 UML – Notation und Semantik (145). Objektorientierte Softwareentwicklungsmethodik. Aus methodischer Sicht ist die Objektorientierung u.a. dadurch gekennzeichnet, dass hier im Vergleich zu klassischen Softwareentwicklungsmethoden wie Strukturierte Analyse (SA), Strukturiertes Design (SD), Entity Relationship Modeling (ERM) etc. eine wesentlich durchgängigere Modellierung möglich ist. Objektorientierte Softwareentwicklungsmethoden erlauben es beispielsweise, von der Analyse über Design und Test bis zum laufenden Programm das Konzept der Klasse bzw. des Objektes zu verwenden. Dadurch ist der methodische Bruch zwischen diesen elementaren Aktivitäten deutlich geringer. Geschäftsprozessmodellierung (GPM) hat zunächst nicht zwangsläufig mit Objektorientierung oder allgemein Softwareentwicklung zu tun, sondern betrachtet die Abläufe in einer Geschäftseinheit bzw. eines Unternehmens insgesamt. Erst dadurch, dass gewöhnlich ein Großteil dieser Abläufe durch Software unterstützt wird, entsteht der enge Bezug der Geschäftsprozessmodellierung zur Softwareentwicklung. Hier-

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

1.3 Abgrenzung

13

bei spielt die Objektorientierung keine besonders andere Rolle als bspw. die prozedurale Softwareentwicklung, denn die Geschäftsprozessorganisatoren interessiert primär nicht, mit welcher Technologie oder Programmiersprache die Software hergestellt wurde, sondern inwieweit ihre Funktionalität die Geschäftsprozesse unterstützt. Der Auslöser, ein Buch mit dem Titel „Objektorientierte Geschäftsprozessmodellierung mit der UML“ zu schreiben, liegt hauptsächlich darin, dass Objektorientierung eine Basistechnologie zur Herstellung von Software ist und insofern der Frage nachgegangen werden soll, ob und welche Besonderheiten aus Sicht der objektorientierten Softwareentwicklung beim Thema Geschäftsprozessmodellierung bestehen. Warum Objektorientierung und UML für Geschäftsprozessmodel- Geschäftsprozesslierung? Für die objektorientierte Softwareentwicklung hat sich die modellierung und UML UML als Modellierungsstandard durchgesetzt. Die UML ist jedoch in erster Linie eine Notation zur Beschreibung objektorientierter Softwaremodelle. Der Bereich Geschäftsprozessmodellierung hat in der UML keinen besonderen Platz und wird nicht nennenswert unterstützt. Die in der UML enthaltenen Anwendungsfälle bieten allenfalls einen Ansatzpunkt, wie später noch zu sehen sein wird. Der Vorteil, Geschäftsprozessmodellierung mit der UML zu betreiben, Vorteile für GPM durch UML liegt darin, eine einheitliche Beschreibungssprache zu haben, die gleichen Werkzeuge zu benutzen, eine einheitliche Ablage-, Verwaltungsund Dokumentationsstruktur zu besitzen und vor allem die Anforderungen an die Software besser nachvollziehen und im betriebswirtschaftlichen Kontext wahrnehmen zu können. Die formale Fundierung der Modellierungssprache und die semantischen Regeln sind in der UML stärker als beispielsweise mit ereignisgesteuerten Prozessketten. Außerdem gibt es eine große formale Ähnlichkeit bei der Modellierung von Hard- und Softwaresystemen und der Modellierung von Unternehmen. Weiterführende Literatur: [Booch99] G. Booch, J. Rumbaugh, I. Jacobson: Unified Modeling Language User Guide. Addison Wesley Longman, Reading, 1999. [Hitz03] M. Hitz, G. Kappel: UML @ work: Von der Analyse zur Realisierung. 2. Auflage, dpunkt.verlag, Heidelberg, 2003. [Oestereich01a] B. Oestereich: Objektorientierte Softwareentwicklung: Analyse und Design mit der UML. 5. Auflage, Oldenbourg Wissenschaftsverlag, München, 2001.

14

1.3 Abgrenzung

1.3.2 Andere Modellierungsansätze Extrakt  Sie erhalten Hinweise auf andere Ansätze zur Geschäftsprozessmodellierung: ARIS, SOM und PROMET. ARIS

ARIS (Architektur integrierter Informationssysteme) ist eine von Prof. Dr. Dr. h.c. mult. August-Wilhelm Scheer entwickelte und Anfang der 1990er Jahre publizierte Modellierungsarchitektur für Geschäftsprozesse. Sie besteht aus einem Vorgehensmodell, Modellierungsmethoden und Metamodellen und definiert verschiedene Sichten (Daten-, Funktions-, Organisations-, Ressourcen- und Steuerungssicht). Basis für die Modellierung sind ereignisgesteuerte Prozessketten (EPK). Die ARIS-Methode und das zugehörige Werkzeug der Firma IDS Scheer sind im Bereich der Geschäftsprozessmodellierung weit verbreitet. Nach eigenen Angaben von IDS Scheer ist ARIS das weltweit meistverkaufte Werkzeug zur Prozessoptimierung. Die Kernkonzepte und -modelle von ARIS haben Gemeinsamkeiten mit dem Vorgehen der objektorientierten Analyse und Design sowie der Notation UML, aber es gibt auch wichtige Unterschiede:  In ARIS existiert eine größere Vielfalt von Diagrammtypen.  Es gibt wenig Formalismen, die Semantik ist weniger verbindlich als in der UML.  Die Notationselemente und Diagramme in ARIS sind weit verbreitet, aber proprietär und nicht als unabhängiger oder offizieller Standard anerkannt.  Eine Transformation von ARIS-Modellen in UML ist unter Beachtung bestimmter Konventionen und Einschränkungen möglich.  Die methodische Durchgängigkeit und Tiefe in Richtung Softwareentwicklung ist bei der Modellierung mit UML deutlich besser ausgeprägt.  ARIS ist ein spezielles Werkzeug, UML ist ein Modellierungsstandard, der von vielen verschiedenen Werkzeugen unterstützt wird, die Werkzeugauswahl ist größer.

SOM

SOM. Ein anderer, ebenfalls seit Anfang der 1990er Jahre existierender Ansatz ist die Methode der Semantischen Objektmodellierung (SOM). Der SOM-Ansatz umfasst die drei zentralen Modelle Unternehmensarchitektur, Vorgehensmodell und Softwarearchitektur, siehe hierzu [Ferstl91] und [SOM].

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

1.3 Abgrenzung

PROMET. Eine weitere Methode, PROMET, wurde an der Hochschule St. Gallen entwickelt und unter anderem von [Österle95] publiziert. PROMET Sie stellt ein Bindeglied zwischen (aus Geschäftsstrategie) abgeleiteten Geschäftsprozessen und der IT dar. Zur Beschreibung von Zusammenhängen und Gewichten werden Netzdarstellungen und Matrizen verwendet, beispielsweise das SWOT-Netzwerk (Strengths, Weakness, Opportunities, Threats) zur Darstellung von Wettbewerbskräften oder das Sektornetzwerk zur Darstellung der Akteure und ihrer Beziehungen am Markt. Mit so genannten Aufgabenketten werden Prozessabläufe und der Übergang zur IT dargestellt. Weiterführende Literatur: [Ferstl91] O. K. Ferstl, E. J. Sinz: Objektmodellierung betrieblicher Informationssysteme im Semantischen Objektmodell (SOM). In: Wirtschaftsinformatik, 32 (1990) 6, S. 566ff. [Nüttgens97] M. Nüttgens, T. Feld, V. Zimmermann: Business Process Modeling mit EPC and UML: Transformation or Integration? In: M. Schader, A. Korthaus (Hrsg.): The Unified Modeling Language: technical Aspects and Applications. Proceedings (Mannheim, October 1997), Heidelberg 1998, S. 250ff. [Österle95] H. Österle: Business Engineering, Prozess- und Systementwicklung. Band 1, Entwurfstechniken, Springer-Verlag, Berlin, 1995. [Scheer01] A.-W. Scheer: ARIS – Modellierungsmethoden, Metamodelle. Anwendungen, 4. Aufl., Springer-Verlag, Berlin, 2001. [Scheer94] A.-W. Scheer: Business Process Engineering: Reference Models for Industrial Enterprise-Modeling. Springer-Verlag, Berlin, 1994. [Scheer97] A.-W. Scheer, M. Nüttgens, V. Zimmermann: Objektorientierte Ereignisgesteuerte Prozeßkette (oEPK) – Methode und Anwendung. Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 141, Saarbrücken 1997, URL: http://www.iwi.unisb.de/public/iwi-hefte. [Scheer99] A.-W. Scheer: ARIS – Vom Geschäftsprozeß zum Anwendungssystem. Springer, Heidelberg, 1999. [Seidlmeier02] H. Seidlmeier: Prozessmodellierung mit ARIS. Eine beispielorientierte Einführung für Studium und Praxis. Vieweg Verlag, Wiesbaden, 2002. [SOM] SOM-Projekt am Lehrstuhl für Wirtschaftsinformatik www.seda.sowi.uni-bamberg.de/forschung/som/som.

in

Bamberg:

15

16

1.3 Abgrenzung

1.3.3 Requirements Engineering Extrakt  Wie grenzen sich Geschäftsprozessmodellierung und Requirements Engineering voneinander ab?

Requirements Engineering ist eine eigene Disziplin innerhalb der Informatik, die sich mit der Aufnahme, Analyse, Dokumentation und Management von Anforderungen für Hard- und Softwaresysteme beschäftigt. Hierzu gehören selbstverständlich auch die von der Software zu unterstützenden Abläufe und Geschäftsregeln, die ebenso Gegenstand der Geschäftsprozessmodellierung sind. Zwischen Requirements Engineering und Geschäftsprozessmodellierung gibt es also Überschneidungen. Die Unterschiede liegen jedoch in den üblichen Schwerpunkten der Analysetätigkeiten und ihrem Zweck. Beim Software Requirements Engineering geht es um Anforderungen für Softwaresysteme, die im Idealfall vollständig und objektiv nachprüfbar spezifiziert werden. Die Anforderungsanalyse geht also üblicherweise sehr weit ins Detail und umfasst unter Umständen Anforderungen an die Reaktionszeiten der Software, an die grafische Gestaltung einzelner Dialogelemente, die Gültigkeitsbereiche bestimmter Eingabefelder usw. Bei der Geschäftsprozessmodellierung geht es zunächst einmal um die Betrachtung von geschäftlichen Vorgängen, unabhängig davon, ob und wie sie mit Software unterstützt werden. Die damit implizit oder explizit definierten Anforderungen sind gewöhnlich wenig detailliert und eher abstrakt. Der Zweck ist nicht die optimale Unterstützung durch ein Softwaresystem herzustellen, sondern die geschäftlichen Vorgänge als solche zu optimieren. Weiterführende Literatur: [Robertson99] S. Robertson, J. Robertson: Mastering the Requirements Process. Addison-Wesley, Reading, 1999. [Rupp02] C. Rupp: Requirements-Engineering und -Management. 2. Aufl., Hanser, München, 2002. [Sommerville97] I. Sommerville, P. Sawyer: Requirements Engineering. A good practice guide. Wiley, 1997.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

2 Überblick und Orientierung

Ich taste mich voran. Albert Einstein

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

2.1 Vorgehensweise

2.1

19

Vorgehensweise

Extrakt  Sie erhalten hier einen Überblick dazu, welche einzelnen methodischen Schritte in welchen Situationen in der Geschäftsprozessmodellierung wichtig sind. Anders ausgedrückt: Hier wird in Kurzform der Geschäftsprozess der Geschäftsprozessmodellierung beschrieben.  Exemplarisch wird das grundsätzliche Vorgehen für folgende Zwecke beschrieben: Systementwicklung, Outsourcing, Fusionierung.

Im vorigen Kapitel 1.1 Warum Geschäftsprozessmodellierung? (3) wurden Beispiele angeführt, zu welchem Zweck Geschäftsprozesse modelliert werden können. Je nach Zweck sind andere Schwerpunkte und eine andere Vorgehensweise notwendig, und Ausgangspunkt und Ziel der Modellierung sind unter Umständen deutlich anders. Im nachfolgenden Kapitel 3 OOGPM-Methodik (35) sind detailliert die einzelnen methodischen Schritte beschrieben. Je nach Zweck der Geschäftsprozessmodellierung sind jedoch bestimmte Schritte wichtiger und andere unwichtiger. Im Folgenden zeigen wir beispielhaft verschiedene mögliche Wege. Die Modellierung von Geschäftsprozessen ist selbst wiederum ein Geschäftsprozess, dessen Inhalt die Vorgehensweise zur Geschäftsprozessmodellierung ist. Darum können wir die Vorgehensweise, die im folgenden 3. Kapitel ausführlich beschrieben wird, hier bereits in verkürzter Form als Geschäftsprozess beschreiben4, was gleichzeitig auch ein Beispiel eines modellierten Geschäftsprozesses ist. Geschäftsprozessmodellierung für die Systementwicklung. Der methodisch umfangreichste Weg ist der für die Geschäftsprozessmodellierung im Hinblick auf eine Automatisierung und Unterstützung der Geschäftsprozesse durch Software. Daher beginnen wir mit einem Überblick hierzu, denn die übrigen möglichen Wege sind im Wesentlichen nur Ausschnitte oder Variationen hiervon. In der Abb. 2.1-1 sind alle wichtigen Schritte zur Geschäftsprozessmodellierung mit dem Zweck einer Systementwicklung dargestellt. Die einzelnen Schritte (auch Geschäftsanwendungsfälle genannt, aber dazu später mehr 56) werden im Anschluss daran stichwortartig (essenziell) erläutert. 4

Wir beschreiben hier unsere Methodik der Geschäftsprozessmodellierung mit sich selbst (auch Bootstrap-Verfahren genannt, vgl. [Bürger78]).

An den eigenen Haaren aus dem Sumpf ziehen: Der Geschäftsprozess der Geschäftsprozessmodellierung

20

2.1 Vorgehensweise

Geschäftsprozesse für Systementwicklung modellieren

Modellierungsfokus festlegen

GAF = Geschäftsanwendungsfälle GPA = Geschäftspartner GMA = Geschäftsmitarbeiter

Kap. 3.1, S. 37

Aktive GPA identifizieren

Ziele festlegen Kap. 3.3, S. 46

Kap. 3.4, S. 51

Orgeinheiten modellieren Kap. 3.5, S. 56

GAF der aktiven GPA identifizieren

Kap. 3.2, S. 43

Kap. 3.20 S. 141 Fachliches Glossar entwickeln

Weitere unter- Kap. 3.6, S. 66 stützende GAF identifizieren

Kap. 3.10 S. 87 GMA und Akteurmodell definieren Kap. 3.7 S. 72

Kap. 3.8 S. 77 Geschäftsprozesse definieren

GAF essenziell beschreiben

Kap. 3.11 S. 96 GAF-Modell erstellen Kap. 3.15 S. 118

Kap. 3.9 S. 84

GAF-Abläufe modellieren

GAF-Abläufe optimieren u. konsolidieren Kap. 3.12, S. 102

Kap. 3.13 S. 111

Geschäftsprozesse dokumentieren Kap. 3.14 S. 114

GAF-Abläufe detaillieren

Organisat. Einbettung und Abhäng. reorg.

Kap. 3.16 S. 123 Kap. 3.18 S. 129 Anforderungen und Regeln beschreiben

Kap. 3.19 S. 133 Systemanwendungsfälle definieren

Geschäftsklassenmodell erstellen

Kap. 3.17 S. 127 Zustandsmodelle entwickeln

Geschäftsprozesse für Systementwicklung modelliert

Abb. 2.1-1: Vorgehensweise der Geschäftsprozessmodellierung zur Systementwicklung

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

2.1 Vorgehensweise

Das Ablaufdiagramm in Abb. 2.1-1 zeigt die Reihenfolge der im Folgenden näher beschriebenen Einzelaktivitäten, wobei sich an den dargestellten Balken der Ablauf teilt bzw. wieder synchronisiert wird. Die im Diagramm gezeigte Reihenfolge drückt die grundsätzlichen existierenden Abhängigkeiten aus. So lassen sich beispielsweise Geschäftsanwendungsfälle essenziell beschreiben, erst nachdem sie zuvor in Geschäftsanwendungsfälle für aktive Geschäftspartner identifizieren und übrige unterstützende Geschäftsanwendungsfälle identifizieren gefunden wurden. Ein solches Modell ist, wie jedes Modell, eine Vereinfachung, d.h., es Modelle sind existieren gewöhnlich weitere Abhängigkeiten, Ausnahmen und Um- Vereinfachungen stände, die Einfluss auf die möglichen und sinnvollen Vorgehensweisen haben. Beispielsweise resultieren aus der Aktivität Fachliches Glossar entwickeln wichtige Ergebnisse für die Geschäftsklassenmodellierung. Diese Abhängigkeit wurde jedoch durch keinen speziellen Ablauf (Pfeil) dargestellt, da die Aktivität Fachliches Glossar entwickeln auch für viele andere Aktivitäten ein wichtiges Ergebnis liefert und das Diagramm, würden diese alle dargestellt werden, durch ein wildes Durcheinander von Pfeilen unlesbar würde. Zumal die Entwicklung eines Glossars eine begleitende Tätigkeit ist, die nur bedingt ein definiertes Ende erreicht. Und ebenso ist es in der Praxis möglich, eine Reihe von Abhängigkei- Abhängigkeiten sind ten u.Ä. ohne großen Schaden zu ignorieren. In einer konkreten Situa- nicht starr tion kann es sogar gut möglich oder sinnvoll sein, anders vorzugehen. Beispielsweise könnte die Klassenmodellierung sehr viel früher stattfinden, wenn das Wissen über Geschäftsobjekte bereits vorhanden ist oder sich auf andere Weise als über Geschäftsanwendungsfälle erschließen ließe. Diese Besonderheiten, möglichen Ausnahmen und Varianten sind ganz typisch für Geschäftsprozesse. In den Detailbeschreibungen der einzelnen Aktivitäten im 3. Kapitel werden diese Besonderheiten auch erläutert und viele praktische Hinweise gegeben. In der Übersicht in Abb. 2.1-1 werden diese Sachverhalte ignoriert, denn das Ablaufdiagramm bezweckt nicht die vollständige und detaillierte Information, sondern soll eine erste Orientierung geben. Daher zeigt das Diagramm den Normalfall oder auch nur einen typischen einfachen Fall. Sie finden in diesem Buch also eine Anleitung zur Geschäftsprozess- Keine Ausreden modellierung, diese ist aber abstrakt und verallgemeinert und allenfalls mit zahlreichen Hinweisen, Tipps, Empfehlungen und Warnungen versehen. Wie Sie in einer konkreten Situation Geschäftsprozesse modellieren sollten und welche Aktivitäten zu welchen Zeitpunkten in welcher Form zweckmäßig sind, müssen Sie selbst entscheiden aufgrund

21

22

2.1 Vorgehensweise

der spezifischen Schwerpunkte, Ziele, Rahmenbedingungen, Möglichkeiten und Interessen. Verstehen Sie unsere Methodik also mehr als einen Baukasten und als ein Orientierungsbeispiel. Würdigen Sie gerne unsere Hinweise und Empfehlungen in diesem Buch, lassen Sie sich anregen, aber ziehen Sie sich nicht aus Ihrer Verantwortung zurück, „weil das in dem Buch so steht“. Im Übrigen würden auch wir uns über Ihre Erfahrungen, Hinweise und Ideen freuen! Schreiben Sie an [email protected]. Hier nun die Erläuterungen zu den einzelnen Schritten aus Abb. 2.1-1: GeschäftsModellierungsfokus festlegen anwendungsfall (Details Kap. 3.1 37) Kurzbeschreibung

Es wird festgelegt, welches Unternehmen überhaupt modelliert werden soll und welches die Ziele des Unternehmens sind.

Essenzieller Ablauf

1. Definiere den Fokus der Geschäftsprozessmodellierung, d.h. den zu betrachtenden Bereich, durch möglichst exakte und eindeutige Benennung der einzuschließenden Organisationseinheiten, Unternehmen o.Ä. Definiere ggf. auch explizit auszuschließende Organisationseinheiten. 2. Benenne die zu beachtenden Schwerpunkte der Geschäftsprozessmodellierung durch Unterscheidung in obligatorische (muss) und optionale (kann) Bereiche. 3. Beschreibe den Geschäftszweck, d.h., womit das Unternehmen Geld verdient. 4. Beschreibe, was das Unternehmen ausmacht und was es von anderen unterscheidet (Leitbild). 5. Beschreibe das an erster Stelle stehende Ziel des Unternehmens (Leitziel, Vision).

GeschäftsOrganisationseinheiten modellieren anwendungsfall (Details Kap. 3.2 43) Kurzbeschreibung

Es wird die vorhandene Organisationsstruktur ermittelt und beschrieben.

Essenzieller Ablauf

1. Identifiziere die Organisationseinheiten innerhalb des Modellierungsfokuss. 2. Stelle die Organisationsstruktur grafisch als UMLKlassenmodell dar.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

2.1 Vorgehensweise

GeschäftsZiele festlegen anwendungsfall (Details Kap. 3.3 46) Kurzbeschreibung

Es wird ermittelt und dokumentiert, womit das Unternehmen Geld verdient.

Essenzieller Ablauf

1. Beschreibe die wichtigsten 7 Ziele des Unternehmens (bzw. Modellierungsfokus). 2. Unterscheide operative und strategische Ziele. 3. Versehe jedes Ziel mit einer Kennzahl zur Messung der Zielerreichung. 4. Beschreibe zu jedem Ziel 1 - 3 Maßnahmen zur Zielerreichung.

GeschäftsAktive Geschäftspartner identifizieren anwendungsfall (Details Kap. 3.4 51) Kurzbeschreibung

Es wird ermittelt und dokumentiert, wer die Kunden des Unternehmens sind.

Essenzieller Ablauf

1. Identifiziere die aktiven Geschäftspartner, d.h. solche Akteure, die außerhalb des Modellierungsbereiches stehend aktiv Geschäftsprozesse initiieren. 2. Bei dieser Gelegenheit identifizierte passive Geschäftspartner, Geschäftsmitarbeiter und Anwendungsfälle werden zur späteren Verwendung festgehalten.

GeschäftsFachliches Glossar entwickeln anwendungsfall (Details Kap. 3.20 141) Kurzbeschreibung

Es werden die wichtigsten modellierungsrelevanten Fachbegriffe definiert.

Essenzieller Ablauf

1. Lege ein fachliches Glossar an und definiere dort alle wichtigen fachlichen Begriffe. 2. Stimme alle Begriffe mit den wichtigsten Stakeholdern ab.

GeschäftsGeschäftsanwendungsfälle der aktiven Geschäftspartner anwendungsfall identifizieren (Details Kap. 3.5 56) Kurzbeschreibung

Es werden die Geschäftsanwendungsfälle der Kunden in Kurzform beschrieben.

Essenzieller Ablauf

1. Befrage die aktiven Geschäftspartner oder nehme gedanklich ihre Position ein und identifiziere die aus ihrer Sicht gewünschten Geschäftsanwendungsfälle. 2. Beschreibe jeden Geschäftsanwendungsfall mit Namen, Auslöser, Ergebnis, Akteur und Kurzbeschreibung.

23

24

2.1 Vorgehensweise

GeschäftsWeitere unterstützende Geschäftsanwendungsfälle idenanwendungsfall tifizieren (Details Kap. 3.6 66) Kurzbeschreibung

Es werden die Geschäftsanwendungsfälle von Lieferanten und anderen Geschäftspartnern in Kurzform beschrieben.

Essenzieller Ablauf

1. Überlege, welche (weiteren) unterstützenden Geschäftsanwendungsfälle und Geschäftspartner notwendig sind, um die identifizierten Kern-Geschäftsanwendungsfälle zu betreiben. 2. Beschreibe jeden unterstützenden Geschäftsanwendungsfall mit Namen, Auslöser, Ergebnis, Akteur und Kurzbeschreibung.

GeschäftsGeschäftsmitarbeiter identifizieren und Akteurmodell anwendungsfall entwickeln (Details Kap. 3.7 72) Kurzbeschreibung

Es werden alle an den Geschäftsanwendungsfällen beteiligten Akteure und Organisationseinheiten beschrieben.

Essenzieller Ablauf

1. Betrachte alle Geschäftsanwendungsfälle und identifiziere für jeden die beteiligten Akteure. Begrenze dies jedoch auf maximal 7 Akteure bzw. 4 Minuten pro Geschäftsanwendungsfall. 2. Notiere die Ergebnisse je Geschäftsanwendungsfall als Geschäftsanwendungsfall-Kontext. 3. Ordne die gefundenen Geschäftsmitarbeiter einer Organisationseinheit zu. Falls keine existierende Organisationseinheit passt, hat man eine neue gefunden. 4. Unterscheide ggf. Soll- und Ist-Situation der Aufbauorganisation.

GeschäftsGeschäftsanwendungsfälle essenziell beschreiben anwendungsfall (Details Kap. 3.10 87) Kurzbeschreibung

Es werden alle Geschäftsanwendungsfälle in einem einheitlichen Detaillierungsgrad und anhand einiger formaler Kriterien näher beschrieben.

Essenzieller Ablauf

1. Beschreibe jeden Geschäftsanwendungsfall kurz mit 1 - 2 Sätzen in natürlicher Sprache. 2. Definiere Anfang und Ende der Geschäftsanwendungsfälle mit Hilfe von Auslösern und Ergebnissen. 3. Definiere zu jedem Geschäftsanwendungsfall die eingehenden Daten. 4. Benenne zu jedem Geschäftsanwendungsfall die beteiligten Akteure. 5. Beschreibe stichwortartig den essenziellen Ablauf eines jeden Geschäftsanwendungsfalles. 6. Priorisiere die Geschäftsanwendungsfälle.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

2.1 Vorgehensweise

GeschäftsGeschäftsprozesse definieren anwendungsfall (Details Kap. 3.8 77) Kurzbeschreibung

Alle zusammengehörenden Geschäftsanwendungsfälle werden zu Geschäftsprozessen zusammengefasst.

Essenzieller Ablauf

1. Fasse alle thematisch zusammengehörenden Geschäftsanwendungsfälle zu Gruppen zusammen. Die Gruppen repräsentieren Geschäftsprozesse. 2. Gebe jeder Gruppe einen Namen. 3. Klassifiziere die Gruppen nach Kern-Prozessen und unterstützenden Prozessen.

GeschäftsGeschäftsanwendungsfallmodell erstellen anwendungsfall (Details Kap. 3.15 118) Kurzbeschreibung

Die Beziehungen, Abhängigkeiten und Gemeinsamkeiten der Geschäftsanwendungsfälle werden beschrieben.

Essenzieller Ablauf

1. Stelle alle bisher vorhandenen Geschäftsanwendungsfälle in einem Anwendungsfallmodell dar. Alle Geschäftsanwendungsfälle eines Geschäftsprozesses werden in jeweils einem eigenen Anwendungsfalldiagramm dargestellt. 2. Identifiziere und beschreibe die involvierten Geschäftsmitarbeiter. 3. Identifiziere gleiche Schritte in verschiedenen Geschäftsanwendungsfällen und löse sie als sekundäre Geschäftsanwendungsfälle heraus, um ein redundanzfreies Modell herzustellen.

GeschäftsGeschäftsanwendungsfall-Abläufe modellieren anwendungsfall (Details Kap. 3.11 96) Kurzbeschreibung

Die Abläufe der Geschäftsanwendungsfälle werden inklusive aller fachlichen Ausnahmen und Varianten modelliert.

Essenzieller Ablauf

1. Beschreibe den Standardablauf eines jeden Geschäftsanwendungsfalles in Form eines UML-Aktivitätsmodelles. 2. Identifiziere zu jedem Geschäftsanwendungsfall vollständig alle fachlich relevanten Varianten und Ausnahmen und notiere sie im Aktivitätsmodell. 3. Notiere nicht sofort klärbare Fragen in einer OffenePunkte-Liste.

GeschäftsGeschäftsanwendungsfall-Abläufe optimieren und konanwendungsfall solidieren (Details Kap. 3.12 102) Kurzbeschreibung

Die in den Geschäftsanwendungsfällen verwendeten Namen und Begriffe werden überprüft und konsolidiert. Die Reihenfolgen der einzelnen Ablaufschritte werden kritisch hinterfragt und ggf. restrukturiert.

Essenzieller Ablauf

1. Überprüfe und restrukturiere ggf. die Ablaufreihenfolgen. 2. Überprüfe und konsolidiere die verwendeten Begriffe.

25

26

2.1 Vorgehensweise

GeschäftsGeschäftsanwendungsfall-Abläufe detailliert beschreianwendungsfall ben (Details Kap. 3.13 111) Kurzbeschreibung

Die einzelnen Aktivitäten eines jeden Geschäftsanwendungsfall-Ablaufmodelles werden in einer vorgegebenen Form detailliert.

Essenzieller Ablauf

1. Beschreibe die einzelnen Aktivitäten eines jeden Geschäftsanwendungsfall-Ablaufmodelles in einer vorgegebenen detaillierten Form.

GeschäftsOrganisatorische Einbettung identifizieren und Abhänanwendungsfall gigkeiten ggf. reorganisieren (Details Kap. 3.14 114) Kurzbeschreibung

Die sich aus der organisatorischen Zuordnung von Verantwortlichkeiten ergebenden Abhängigkeiten werden identifiziert und ggf. durch Reorganisation der Verantwortlichkeiten oder Organisationseinheiten optimiert.

Essenzieller Ablauf

1. Bestimme, welche einzelnen Schritte im Ablauf von welchen Organisationseinheiten verantwortet werden. 2. Ermittle die sich daraus ergebenden Abhängigkeiten. 3. Restrukturiere die Verantwortlichkeiten oder Organisationseinheiten ggf. derart, dass die Abhängigkeiten minimiert werden.

GeschäftsGeschäftsprozesse dokumentieren anwendungsfall (Details Kap. 3.9 84) Kurzbeschreibung

Die Geschäftsprozesse werden in detaillierterer Form beschrieben.

Essenzieller Ablauf

1. Beschreibe die wichtigsten Eigenschaften eines jeden Geschäftsprozesses in natürlicher Sprache: Kurzbeschreibung, Maßnahmen, Prozessverantwortliche und -beteiligte. 2. Stelle die Abläufe eines jeden Geschäftsprozesses mit Hilfe eines Diagramms grafisch dar, soweit dies zweckmäßig ist.

GeschäftsSonstige Anforderungen definieren anwendungsfall (Details Kap. 3.18 129) Kurzbeschreibung

Geschäftsregeln und andere geschäftliche Anforderungen werden definiert.

Essenzieller Ablauf

1. Beschreibe alle geschäftlichen Anforderungen und Regeln in einem zentralen Anforderungskatalog. 2. Referenziere geschäftsobjektspezifische Geschäftsregeln in den jeweiligen Geschäftsobjekten. 3. Referenziere anwendungsfallspezifische Geschäftsregeln in den jeweiligen Anwendungsfällen.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

2.1 Vorgehensweise

GeschäftsSystemanwendungsfälle definieren anwendungsfall (Details Kap. 3.19 133) Kurzbeschreibung

Es wird entschieden, welche Anwendungsfälle systemtechnisch unterstützt werden sollen. Diese werden dann als Systemanwendungsfälle weiter detailliert.

Essenzieller Ablauf

1. Entscheide für jeden vorliegenden Geschäftsanwendungsfall, ob er systemtechnisch umgesetzt werden soll. 2. Ergänze ggf. fehlende fachliche Ausnahmen und Varianten, beispielsweise fachlich sinnvolle Abbruchmöglichkeiten. 3. Zerlege diese systemtechnisch umzusetzenden Geschäftsanwendungsfälle in zeitlich kohärente Systemanwendungsfälle. 4. Erstelle ein Systemanwendungsfallmodell.

GeschäftsGeschäftsklassenmodell entwickeln anwendungsfall (Details Kap. 3.16 123) Kurzbeschreibung

Die Struktur der fachlichen Begriffe und Geschäftsobjekte wird grafisch dargestellt.

Essenzieller Ablauf

1. Entnehme den Kern-Geschäftsanwendungsfällen die wichtigsten Geschäftsobjekte. 2. Erstelle mit diesen Geschäftsobjekten ein Klassenmodell. 3. Erkenne, welche weiteren Geschäftsobjekte noch zu berücksichtigen sind, damit das Modell verständlich wird, und nehme diese ebenfalls auf.

GeschäftsZustandsmodelle entwickeln anwendungsfall (Details Kap. 3.17 127) Kurzbeschreibung

Die möglichen fachlichen Zustände von zustandsrelevanten Geschäftsklassen werden modelliert.

Essenzieller Ablauf

1. Identifiziere die möglichen fachlichen Zustände eines jeden Geschäftsobjektes. 2. Kennzeichne alle Geschäftsklassen mit signifikantem zustandsabhängigem Verhalten. 3. Entwickle für jede als zustandsabhängig gekennzeichnete Geschäftsklasse ein Zustandsmodell.

27

28

2.1 Vorgehensweise

Die folgenden beiden Abbildungen zeigen zwei weitere Möglichkeiten des Vorgehens in der Geschäftsprozessmodellierung.  Geschäftsprozessmodellierung für Outsourcing. Abb. 2.1-2 skizziert das Vorgehen, wenn die Frage geklärt werden soll, welche Teile eines Geschäftes ausgelagert werden könnten (Outsourcing), welche Implikationen und Konsequenzen damit wahrscheinlich verbunden sind usw.

Soll-Prozesse definieren

 Geschäftsprozessmodellierung für Fusionen. Abb. 2.1-3 skizziert das Vorgehen, wenn die Frage geklärt werden soll, welche Auswirkungen eine Fusion von zwei Unternehmen auf deren Geschäftsprozesse hat, d.h., wo sich die Unternehmen mit ihren bisherigen Prozessen überschneiden, ergänzen oder widersprechen. Hierzu werden die Geschäftsanwendungsfälle und Geschäftsprozesse jedes beteiligten Unternehmens nach dem gleichen Ablauf (wie in Abb. 2.1-3 dargestellt) untersucht und anschließend die Ergebnisse gegenübergestellt. Falls die Fusion zustande kommt, können auf dieser Basis SollProzesse für das fusionierte Unternehmen ausgearbeitet werden. In der Praxis werden entsprechende Untersuchungen häufig nicht oder ohne ernsthafte Ergebniswürdigung durchgeführt, da die Entscheidungen vielfach nicht Sachgründen, sondern Machtinteressen folgen. Wir zeigen in diesem Buch die prinzipielle Vorgehensweise für drei exemplarische Zwecke (Systementwicklung, Outsourcing und Fusionierung). Grundsätzlich sollten Sie bei jeder Geschäftsprozessmodellierung am Anfang festlegen, welche Vorgehensweise in Ihrem speziellen Fall sinnvoll ist. Hierzu gibt es in unserer Methodik einen entsprechenden Schritt: Kapitel 3.3 Ziele festlegen (46). Wir gehen dabei davon aus, dass Sie viele unserer methodischen Schritte gebrauchen können, einige weglassen und einige eigene Schritte hinzufügen müssen. Unsere Geschäftsprozessmodellierungs-Methodik ist also keine universelle, vollständige Beschreibung (was wir für wenig hilfreich und eher anmaßend empfinden würden), sondern ein Rahmenwerk oder ein Werkzeugkasten mit den wichtigsten methodischen Inhalten.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

2.1 Vorgehensweise

Outsourcing-Möglichkeiten untersuchen

Modellierungsfokus festlegen

GAF = Geschäftsanwendungsfälle GPA = Geschäftspartner GMA = Geschäftsmitarbeiter

Kap. 3.1, S. 37

Ziele festlegen

Aktive GPA identifizieren

Kap. 3.3, S. 46

Kap. 3.4, S. 51

Orgeinheiten modellieren Kap. 3.2, S. 43

GAF für aktive GPA identifizieren

Kap. 3.5, S. 56

Übrige unterstützende GAF identifizieren

Kap. 3.6, S. 66

Kap. 3.20 S. 141 Fachliches Glossar entwickeln

Kap. 3.8 S. 77 Kap. 3.10 S. 87 GAF essenziell beschreiben

GMA und Akteurmodell definieren Kap. 3.7 S. 72

Kap. 3.15 S. 118 GAF-Modell erstellen

Sonstige Anforderungen definieren Kap. 3.18 S. 129

Geschäftsprozesse definieren

Kap. 3.11 S. 96 GAF-Abläufe modellieren

Kap. 3.9 S. 84 Geschäftsprozesse dokumentieren

Kap. 3.14 Organisat. Einbettung und S. 114 Abhäng. reorg. Geschäfts- Kap. 3.16 klassenmodell S. 123 entwickeln

Bewertung und Empfehlung ausarbeiten Outsourcing-Untersuchung abgeschlossen

Abb. 2.1-2: Vorgehen in der Geschäftsprozessmodellierung zur Untersuchung von Outsourcing-Möglichkeiten

29

30

2.1 Vorgehensweise

Gundlagen für Fusionsentscheidung entwickeln

Modellierungsfokus festlegen

Ziele festlegen

Kap. 3.1, S. 37

Aktive GPA identifizieren

Kap. 3.3, S. 46

Kap. 3.4, S. 51

Orgeinheiten modellieren Kap. 3.2, S. 43

GAF für aktive GPA identifizieren

Kap. 3.5, S. 56

Übrige unter- Kap. 3.6, S. 66 stützende GAF identifizieren

Kap. 3.10 S. 87 GMA und Akteurmodell definieren Kap. 3.7 S. 72

Kap. 3.20 S. 141 Fachliches Glossar entwickeln

Kap. 3.8 S. 77

GAF essenziell beschreiben

Geschäftsprozesse definieren

Bewertung und Empfehlung ausarbeiten

GeschäftsprozessFusionsuntersuchung beendet

GAF = Geschäftsanwendungsfälle GPA = Geschäftspartner GMA = Geschäftsmitarbeiter

Abb. 2.1-3: Vorgehen in der Geschäftsprozessmodellierung zur Untersuchung einer möglichen Unternehmensfusion

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

2.2 Einbettung in die Systementwicklung

2.2

31

Einbettung in die Systementwicklung

Wie in der Einleitung erwähnt, ist Geschäftsprozessmodellierung häufig in einen umfassenderen Untersuchungs- und Entwicklungskontext eingebettet, in dem es um eine Automatisierung durch Hard- und Software geht. Die Geschäftsprozessmodellierung ist dann unter Umständen Teil eines Hard- oder Softwareentwicklungsprojektes. In diesen Projekten existieren neben der Geschäftsprozessmodellierung weitere Disziplinen, die von der Entwicklung einer übergreifenden Systemarchitektur, Entwicklung einzelner Systembausteine und -komponenten bis hin zu Qualitäts- und Projektmanagement reichen. Die hier beschriebene Methodik zur Geschäftsprozessmodellierung fügt sich konsistent in eine objektorientierte Softwareentwicklungsmethodik ein, was im Folgenden skizziert werden soll.

Subsystem ...

...

Meilenstein Iterations-Build

Einführung n+1

n

Betrieb -

Projektabschluss

Konstruktion 5

Produktionsfreigabe

Subsystem 1

4

Zur Abnahme bereitgestellt

Fachliche Architektur

3

ggf. Release herausgeben

Kern-Disziplinen Systemerstellung Subsysteme

Anforderungsanalyse

Projektauftrag vereinbart

Geschäftsprozessmodellierung

ggf. Vorstudie vereinbart

oose.de Dienstleistungen für innovative Informatik GmbH

Phasen Entwurf / Architektur 1 2

Architektur festgelegt

Object Engineering Vorbereitung Process 0

Subsystem n Batch

Unterstützende Disziplinen

Technische Architektur

QS, Test, Abnahmen Einsatz, Verteilung, Projektexternes Konfiguration, Build, Tools Änderungs- und Iterationsmgmt. Projektmanagement

OEP Version 2.0

© Copyright 2003 by oose.de Dienstleistungen für innovative Informatik GmbH

Infos: www.oose.de/oep

Abb. 2.2-1: Disziplinenübersicht des Object Engineering Process (OEP)

Der Object Engineering Process (OEP) ([OEP2], [Oestereich01b]) ist ein Vorgehensmodell für die objektorientierte Softwareentwicklung und ist in Aufbau und Struktur als eine Ausprägung des Unified Process zu sehen ([Jacobson99]). Die Geschäftsprozessmodellierung ist in diesem Vorgehensmodell eine von mehreren so genannten Disziplinen. Die Gebirge in der Abb. 2.2-1 skizzieren dabei grob, zu welchen Zeitpunkten (Phasen) im Projekt, mit welcher Intensität die einzelnen Dis-

32

2.2 Einbettung in die Systementwicklung

ziplinen typischerweise betrieben werden. Die Grundstruktur des Vorgehensmodells setzt sich aus folgenden Beschreibungselementen zusammen:  Phasen Phasen stellen eine zeitliche Gliederung des Entwicklungsprozesses dar. Jede Phase erfüllt einen definierten Zweck und führt zu definierten Ergebnissen (Meilenstein).  Iterationen (Timeboxen) Die Konstruktions- und ggf. auch die übrigen Phasen werden wiederum in mehrere 3 - 10 Wochen dauernde Iterationen untergliedert. Am Anfang einer Iteration steht jeweils eine Festlegung realistischer und überprüfbarer Ziele, am Ende der Iteration eine systematische Bewertung der Zielerreichung.  Meilensteine Die Verknüpfung von definierten Ergebnissen mit einem speziellen Zeitpunkt, meistens dem Ende einer Phase, nennt man Meilensteine.  Aktivitäten Mittels Aktivitäten wird beschrieben, wer wann was im Projekt zu tun hat, welche Voraussetzungen, Ergebnisse, Abhängigkeiten damit verbunden sind u.Ä. Die Granularität der Aktivitäten ist (mit Ausnahmen) so gewählt, dass damit ein oder mehrere Ergebnisse mit einem sinnvollen und definierten Zwischen- oder Endzustand entstehen, die Verantwortung für diese Ergebnisse eindeutig zu benennen ist und es sich um zeitlich zusammenhängende Tätigkeiten handelt.  Disziplinen Disziplinen stellen eine inhaltliche Gliederung der Entwicklungsaktivitäten dar.  Akteure Die Beschreibungen der an der Softwareentwicklung direkt und indirekt beteiligten Rollen, ggf. aus welchen Organisationseinheiten sie stammen und wofür sie verantwortlich sind, geschieht mittels Akteure.  Ergebnisse Die im Projekt entstehenden Ergebnisse werden in ihrer Grundstruktur und mit ihren grundlegenden Eigenschaften beschrieben. Das Vorgehensmodell stellt also einen möglichen Kontext dar, in den sich die Geschäftsprozessmodellierung einfügt. Ebenso ist das Vorgehensmodell der Rahmen für andere Disziplinen, beispielsweise Anforderungsanalyse und Softwareentwicklung. Über das Vorgehensmodell werden diese einzelnen Disziplinen zusammengefügt, wobei über alle

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

2.2 Einbettung in die Systementwicklung

Disziplinen hinweg eine einheitliche Begrifflichkeit und einheitliche Konzepte verwendet werden. Das Konzept des Anwendungsfalles findet sich beispielsweise sowohl in der Geschäftsprozessmodellierung (Geschäftsanwendungsfälle), in der Softwareanforderungsanalyse (Systemanwendungsfälle), in der Softwarearchitektur (Anwendungsfallsteuerungsklassen) bis hin zur Qualitätssicherung (Testfälle). Ähnlich sieht es im Bereich der Strukturmodellierung aus (Fachbegriffe, Geschäftsklassenmodell, Designklassenmodell, realisierte Klassen und Objekte in der Software, Testklassen). Während in der Abb. 2.2-1 das Vorgehen durch die Dimensionen Zeit (Phasen, Iterationen) und Disziplinen dargestellt werden, zeigt die folgende Abbildung das Vorgehen in Form von Sichten und Ebenen. Architektur Geschäftsebene:

Modellierungsfokus, Ziel und Zweck der GPM

Anforderungsebene:

Organisationsplan, Aktive Geschäftspartner, Fachliche Architektur

Realisierungsebene:

Rahmenwerke, Bibliotheken, Technische Architektur (Schichtenmodell), Werkzeuge

Objekte (Strukturelle Sicht)

Steuerung (Dynamische Sicht)

Verhalten (Strukturelle Sicht)

Geschäftsebene - Fachliches Glossar - Geschäftsklassenmodell - Geschäftsmitarbeiter - Geschäftsakteurmodell

Geschäftsebene - Geschäftsanwendungsfall-Abläufe - Geschäftsklassenzustände

Geschäftsebene - Geschäftsanwendungsfälle - Geschäftsprozesse - Geschäftsanwendungsfallmodell - Geschäftsprozessmodell

Anforderungsebene - Anforderungsbeitragende - Fachklassenmodell - Anforderungen, Features u.Ä. - Schnittstellenspezifikation - Berechtigungskonzept - Systemakteurmodell Realisierungssebene - Komponenten-Architektur - Entity-Designklassenmodell - Paketmodell - Datenbank-Abbildung - Entity-Klassen-Implementierung

Anforderungsebene - Zustandsmodelle - Systemanwendungsfall-Abläufe - Interaktionsmodelle - Batchprogramm-Spezifikation

Anforderungsebene - Systemanwendungsfälle - Systemanwendungsfall-Modell - Sekundäre Systemanwendungsf.

Realisierungsebene - Testfälle - Control-Klassen-Implementierung

Realisierungsebene - Einsatz- und Verteilungsmodelle - Control-Design-Klassenmodell

Management Geschäftsebene:

Ziele, Meilensteine, Projektauftrag

Anforderungsebene:

Arbeitsaufträge, Aufwandschätzungen, Terminplanung, Zulieferleistungen

Realisierungsebene:

Konfigurationen, Test- und Abnahmeprotokolle, Reviews, Berichte

Abb. 2.2-2: Sichten und Ebenen des Object Engineering Process (OEP)

Folgende Sichten werden unterschieden:  Architektursicht Die Architektursicht beschreibt, wie alle Elemente übergreifend zusammenhängen und zusammenarbeiten.

33

34

2.2 Einbettung in die Systementwicklung

 Objektsicht Die Objektschicht zeigt, welche statischen Elemente es gibt und welche Beziehungen und Abhängigkeiten sie zueinander besitzen.  Steuerungssicht Die Steuerungssicht beschreibt, welche steuernden dynamischen Elemente es gibt und welche Elemente (Objekte) damit gesteuert werden.  Verhaltensstruktursicht Die Verhaltensstruktursicht enthält die steuernden dynamischen Elemente und gibt an, welche Beziehungen und Abhängigkeiten sie zueinander besitzen.  Managementsicht Die Managementsicht zeigt, welche planerischen, steuernden und kontrollierenden Aufgaben existieren, um Entwicklungsprojekte zu managen. Jede einzelne Sicht wird wiederum in drei Ebenen untergliedert:  Geschäftsebene Die Geschäftsebene enthält die rein geschäftlichen Aspekte der jeweiligen Sicht, d.h. die grundsätzlichen Ziele und Anforderungen unabhängig von möglichen oder konkreten Umsetzungen.  Anforderungsebene Die Anforderungsebene enthält die notwendigen Aspekte, um zu beschreiben, wie die geschäftlichen Ziele und Anforderungen (aus der Geschäftsebene) auf eine mögliche konkrete Realisierungsplattform abgebildet werden können.  Realisierungsebene Die Realisierungsebene zeigt, wie die Anforderungen durch das System ganz konkret erfüllt werden, welche Realisierungselemente hierzu existieren, wie sie zusammenhängen und wie und wodurch sie die Anforderungen erfüllen. Weiterführende Literatur: [Jacobson99] I. Jacobson, G. Booch, J. Rumbaugh: The Unified Software Development Process. Addison-Wesley Longman, Reading, 1999. [OEP2] oose.de GmbH: Object Engineering Process, http://www.oose.de/oep [Oestereich01b] B. Oestereich et al.: Erfolgreich mit Objektorientierung. Vorgehensmodelle und Managementpraktiken für die objektorientierte Softwareentwicklung. 2. Aufl., Oldenbourg Wissenschaftsverlag, München, 2001.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3 OOGPM-Methodik

Macht alles so einfach wie möglich, aber nicht einfacher. Albert Einstein

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.1 Modellierungsfokus festlegen und Unternehmensziele beschreiben Warum ist die Planung unzureichend? Fehlt der Entwicklungsprozess?

3.1

37

Modellierungsfokus festlegen und Unternehmensziele beschreiben

Extrakt  Definiere den Fokus der Geschäftsprozessmodellierung, d.h. den zu betrachtenden Bereich, durch möglichst exakte und eindeutige Benennung der einzuschließenden Organisationseinheiten, Unternehmen o.Ä. Definiere ggf. auch explizit auszuschließende Organisationseinheiten.  Benenne die zu beachtenden Schwerpunkte der Geschäftsprozessmodellierung durch Unterscheidung in obligatorische (muss) und optionale (kann) Bereiche.  Beschreibe den Geschäftszweck, d.h., womit das Unternehmen Geld verdient.  Beschreibe, was das Unternehmen ausmacht und was es von anderen unterscheidet (Leitbild).  Beschreibe das an erster Stelle stehende Ziel des Unternehmens (Leitziel, Vision). Warum ist die Planung unzureichend? Fehlt der Entwicklungsprozess?

Es gibt viele Gründe, Geschäftsprozesse zu modellieren. Dies wurde Warum Geschäftsprozessbereits in Kapitel 1.1 beschrieben. Die Ziele, die mit der Modellierung modellierung? 3 von Geschäftsprozessen verfolgt werden, ordnen sich wiederum den Zielen und dem Zweck des Unternehmens unter. Dies ist zu beachten, da sonst bei der Geschäftsprozessmodellierung möglicherweise völlig falsche Schwerpunkte gesetzt werden, Nebenschauplätze zu viel und Kernanliegen zu wenig betrachtet werden. Modellierungsfokus definieren. Geschäftsprozessmodellierung be- Betrachtungsgegenstand ginnt zunächst damit, den Betrachtungsgegenstand einzugrenzen. Für eingrenzen wen oder was sollen Geschäftsprozesse modelliert werden? Dabei stehen folgende Fragen im Vordergrund: Leitfragen  Wie heißt die Organisation, deren Geschäftsprozesse modelliert werden sollen?  Welche Organisationseinheiten sind zu betrachten?  Sollen auch Bereiche außerhalb der eigenen Organisation, z.B. von Lieferanten und Kunden, einbezogen werden?

38

3.1 Modellierungsfokus festlegen und Unternehmensziele beschreiben Sind die Mitarbeiter zu wenig qualifiziert? Sind die Werkzeuge unzulänglich?

 Sind alle Teile der Organisation gleichermaßen zu betrachten oder sollen bestimmte Schwerpunkte beachtet werden? Lassen sich die einzelnen Bereiche eindeutig klassifizieren in „muss betrachtet werden“, „sollte betrachtet werden“ und „ist nicht zu betrachten“?

Manchmal sind diese Fragen sofort und eindeutig zu beantworten, beispielsweise wenn es sich genau um ein Unternehmen handelt oder eine eindeutig abgegrenzte Abteilung. Gelegentlich ist die Antwort aber auch weniger einfach zu finden, beispielsweise wenn mehrere Abteilungen betroffen sind, nur ein Organisationsausschnitt zu untersuchen ist, der nicht exakt entlang der Abteilungsgrenzen verläuft, oder Teile einer Unternehmensgruppe bzw. eine Gemeinschaft kooperierender Unternehmen untersucht werden sollen. Sind die Mitarbeiter zu wenig qualifiziert? Sind die Werkzeuge unzulänglich?

Begriff Modellierungsfokus

Wenn der Modellierungsbereich abgesteckt ist, wird es bei der Geschäftsprozessmodellierung dennoch notwendig sein, die Schnittstellen zur Umgebung des betrachteten Bereiches ebenfalls anzusehen und darzustellen, also beispielsweise die Geschäftspartner, mit denen das betrachtete Unternehmen zu tun hat. Da wir die Modellierung also nicht exakt auf den abgegrenzten Bereich beschränken, sondern die unmittelbare Umgebung ebenfalls einbeziehen, verwenden wir den Begriff Modellierungsfokus. Gelegentlich benutzen wir auch vereinfachend den Begriff Unternehmen, weil der Betrachtungsgegenstand in vielen Fällen genau ein Unternehmen ist. Gemeint ist aber jeweils der Modellierungsfokus im hier beschriebenen Sinne.

Fallbeispiel

In diesem Buch verwenden wir als durchgehendes Fallbeispiel eine Kfz-Vermietung mit dem Phantasienamen Flitz-Auto. Betrachtungsgegenstand ist ausschließlich das Unternehmen Flitz-Auto selbst. Geschäftsprozesse, in denen neben Flitz-Auto auch deren Lieferanten, Kunden und Kooperationspartner involviert sind, werden betrachtet, nicht jedoch solche Geschäftsprozesse der Geschäftspartner, an denen Flitz-Auto gar nicht beteiligt ist. Schwerpunkte der Geschäftsprozessmodellierung. Innerhalb von Flitz-Auto liegt der Schwerpunkt der Geschäftsprozessmodellierung in der Vermietung und dem Verkauf von Kraftfahrzeugen. Außerdem müssen Marketing und Beschaffung betrachtet werden. Ausgeschlossen von der Modellierung sind Lohn- und Finanzbuchhaltung.

Nur Abteilungen betrachten

Falls Sie nicht genau ein Unternehmen betrachten, sondern beispielsweise eine einzelne Abteilung, müssen Sie nun entscheiden, ob Sie die folgenden Fragen nach Unternehmenszweck, Leitbild und Leitziel auf Ihren Modellierungsfokus (z.B. eine Abteilung) oder auf das Unternehmen insgesamt beziehen möchten. Der Einfachheit halber beziehen

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.1 Modellierungsfokus festlegen und Unternehmensziele beschreiben Sind die Technologien unausgereift?

wir uns im Folgenden auf das gesamte Unternehmen, es mag jedoch unter Umständen sinnvoll sein, eine andere Perspektive einzunehmen. Zweck des Unternehmens. Der Zweck der meisten Unternehmen ist Geld verdienen das Geldverdienen5. Wir formulieren den Zweck so, das deutlich wird, womit Geld verdient werden soll, und konzentrieren uns auf die 1 - 5 wichtigsten Zwecke. Bei vielen Unternehmen ist der Unternehmenszweck unmittelbar und ohne große Erläuterungen ersichtlich. In anderen Fällen, und hierzu gehört auch unser Fallbeispiel Flitz-Auto, ist dies jedoch nicht so. Bei einer Kfz-Vermietung ist die Vermietung von Kraftfahrzeugen als Unternehmenszweck bereits aus dem Namen des Unternehmens ersichtlich. Tatsächlich verdienen Autovermietungen jedoch einen wesentlichen Teil ihres Geldes mit dem Verkauf von gebrauchten Kraftfahrzeugen. Kfz-Vermietungen erzielen durch die dauerhafte Abnahme großer Stückzahlen ungewöhnlich gute Einkaufspreise für Neufahrzeuge. Bereits nach 1 - 2 Jahren werden die Fahrzeuge als Gebrauchtwagen wieder verkauft, wobei der dabei zu erzielende Preis in der Nähe des ursprünglichen Einkaufspreises liegt. Sind die Technologien unausgereift?

Bei einem Modellierungsfokus, der sich über mehrere Organisationen Organisationsbzw. Organisationseinheiten erstreckt, sind der unternehmerische übergreifender Zweck und die geschäftlichen Ziele (die wir hier stets auf den gesamten Modellierungsfokus Modellierungsbereich beziehen) möglicherweise weniger deutlich und daher aufwändiger herauszuarbeiten. Leitfragen  Was ist der Unternehmenszweck?  Wie möchte das Unternehmen von seinen Kunden gesehen werden? Formulieren Sie dieses Leitbild mit nur einem Satz!  Was möchte das Unternehmen grundsätzlich erreichen? Formulieren Sie dieses Leitziel (oder auch die Vision) mit nur einem Satz!

5

Lediglich Nonprofit-Organisationen, beispielsweise gemeinnützige Organisationen oder einige öffentliche Körperschaften, werden hier nicht Geldverdienen als Zweck benennen, sondern das Erbringen einer bestimmten Leistung.

39

40

3.1 Modellierungsfokus festlegen und Unternehmensziele beschreiben Menschen haben persönliche, soziale und kommunikative Probleme.

Leitbild. Beschreiben Sie mit einem Satz das Leitbild des Unternehmens. Mit dem Leitbild werden die Werte ausgedrückt, die das Unternehmen von anderen unterscheidet. So gibt es Unternehmen, die wenig Angebotsvielfalt, aber niedrige Preise haben („Bei uns nur dauerhaft Niedrigpreise“), oder andere, die auf Qualität oder Angebotsvielfalt Wert legen („Wenn Sie etwas Besonderes suchen!“). Menschen haben persönliche, soziale und kommunikative Probleme.

Corporate Identity

Visionen

Kennzahlen

In vielen Unternehmen gibt es ein explizit festgelegtes Leitbild, das zur Corporate Identity6 gehört und allen Mitarbeitern und wichtigen Geschäftspartnern vermittelt wurde und bekannt ist. In anderen Unternehmen ist es vielleicht nicht explizit festgelegt, aber dennoch bekannt und spontan formulierbar. Etwas mehr Arbeit macht die Beschreibung des Leitbildes, wenn das Kreieren eines Leitbildes völlig neu für ein Unternehmen ist. Gelegentlich ist auch zu bemerken, dass es zwar ein klar formuliertes Leitbild gibt, dies jedoch nicht glaubwürdig ist und nicht gelebt wird. Leitziel. Beschreibe das Leitziel, d.h. die Vision, des Unternehmens mit einem Satz. Es ist das an erster Stelle stehende und markanteste Ziel, das das Unternehmen hat. Natürlich hat ein Unternehmen mehr als ein einzelnes Ziel und diese werden im nächsten Abschnitt auch noch betrachtet. Je mehr Ziele jedoch vorhanden sind, desto weniger Kraft besitzen sie, da die Aufmerksamkeit der beteiligten Menschen mehr gestreut wird. Deswegen konzentrieren wir uns hier zunächst auf das aller oberste Ziel. Leitbild und Leitziel müssen nicht zusammenhängen. Die Beschreibung des Ziels fällt leichter, wenn es mit einer Kennzahl verknüpft wird, mit der die Zielerreichung gemessen werden kann. Beispiel: „Wir wollen in 5 Jahren einen Marktanteil von 30 Prozent haben.“ Praktische Tipps. Wir schlagen vor, mit dem Auftraggeber und ggf. weiteren wichtigen Stakeholdern einen kurzen Workshop mit folgender Aufgabenstellung durchzuführen (Abb. 3.1-1).

6

Corporate Identity (CI), Unternehmensidentität, siehe Glossar.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.1 Modellierungsfokus festlegen und Unternehmensziele beschreiben Entwickler verstehen die Fachabteilung nicht.

Workshop

Modellierungsfokus festlegen

Ziel des Workshops:

Abgrenzung des zu modellierenden Geschäftes, Festlegung von Modellierungsschwerpunkten und Beschreibung von Zweck und Zielen des Geschäftes.

Teilnehmer:

Auftraggeber und VertreterInnen der betroffenen Geschäftseinheiten (Abteilungen, Unternehmen, Unternehmensbereiche etc.), aktive GeschäftspartnerInnen, insgesamt ca. 1 - 5 Personen. Moderationsteam (Moderator, Protokollant, Analytiker)

Rahmenbedingungen:

Konferenzraum mit Flipchart oder Tafel

Vorbereitung:

Die Auftraggeberseite stellt vorab wichtige Informationen über den Betrachtungsgegenstand bereit (z.B. Organisationspläne, Geschäftsberichte, ggf. Stellenbeschreibungen u.Ä.), die Auftragnehmerseite nimmt die bekannten Informationen vorab auf.

Agenda:

1. Abstimmung der Ziele, der Agenda, der erwarteten Ergebnisse und der geplanten Dauer. 2. Kurze Vorstellung der Teilnehmer. 3. Der Moderator erläutert kurz die erwarteten Ergebnisse des Workshops und stellt sicher, dass alle Beteiligten ein gemeinsames Verständnis darüber haben. 4. Modellierungsfokus beschreiben, Gliederung in obligatorische, optionale und auszuschließende Bereiche, Klärung der Relevanz, Redundanzfreiheit und Vollständigkeit. 5. Zweck des Unternehmens in Stichworten beschreiben. 6. Unternehmensleitbild mit einem Satz beschreiben. 7. Leitziel des Unternehmens mit einem Satz beschreiben. 8. Kurze Zusammenfassung der Ergebnisse und Verabschiedung der Teilnehmer.

Nachbereitung

Ergebnisse schriftlich protokollieren und an die Teilnehmenden verteilen.

Abb. 3.1-1: Workshop Modellierungsfokus und Unternehmensziele festlegen Entwickler verstehen die Fachabteilung nicht.

41

42

3.1 Modellierungsfokus festlegen und Unternehmensziele beschreiben Der Auftraggeber ist ungerecht. Die Projektleitung ist schwach.

Für unser Fallbeispiel Flitz-Auto könnte das Ergebnis wie folgt aussehen: Der Auftraggeber ist ungerecht. Die Projektleitung ist sch wach.

Workshop-Protokoll

GPM-Betrachtungsgegenstand festlegen

Zeit, Ort, Teilnehmer

1.7.2002, 9.00 – 10.35 Uhr, Konfi 1 Auftraggeberseite: Herr Sommer (Geschäftsführung), Frau Basch (Vertriebsleitung), Herr Schütt (Verkauf), Herr Dick (Vermietung) Auftragnehmerseite: Herr Weiss (Projektleitung), Herr Lenhard (Moderation), Frau Schröder (Analytikerin), Herr Lustig (Protokoll)

Modellierungsfokus

Betrachtungsgegenstand der Geschäftsprozessmodellierung ist das Unternehmen Flitz-Auto. Schwerpunkte der Geschäftsprozessmodellierung sollen die Bereiche Vermietung und Verkauf sein. Angrenzende Bereiche wie Marketing müssen ggf. berücksichtigt werden. Lohn- und Finanzbuchhaltung sollen ganz sicher nicht betrachtet werden.

Leitbild (Mission7)

„Wir machen alles möglich, damit Sie Ihren Weg finden.“

Leitziel (Vision) und Kennzahl

„Wir wollen die gefahrenen Kilometer in 3 Jahren verdoppeln.“ Kennzahl: Gefahrene Kilometer

Unternehmenszweck

1. Geld verdienen mit der Vermietung von Kfz. 2. Geld verdienen mit dem Verkauf von gebrauchten ehemaligen Miet-Kfz. 3. Geld verdienen mit der Bereitstellung von Kfz mit Chauffeur. 4. Ziel 2 ist von Ziel 1 abhängig. Ziel 3 soll in der Modellierung nicht betrachtet werden.

Foto-/Video-Protokoll

Nicht vorhanden

Abb. 3.1-2: Beschreibung des Betrachtungsgegenstandes für das Fallbeispiel FlitzAuto

Weiterführende Literatur: [Kaplan01] R. Kaplan, D. Norton: Die strategiefokussierte Organisation. Führen mit der Balanced Scorecard. Schäffer-Poeschel Verlag, Stuttgart, 2001. [Oetinger01] B. v. Oetinger, T. v. Ghyczy, C. Bassford: Clausewitz, Strategie denken. Hanser, München, 2001.

7

Der Begriff Mission ist im amerikanischen Sprachraum im Sinne von Aufgabe gängig und wird in übersetzter Literatur häufig unverändert übernommen, obwohl die Bedeutung im Deutschen eine andere ist.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.2 Organisationseinheiten modellieren Viele Analytiker haben ihre persönlichen Stärken typischerweise in der Erfassung,

3.2

43

Organisationseinheiten modellieren

Extrakt  Identifiziere die Organisationseinheiten innerhalb des Modellierungsfokus.  Stelle die Organisationsstruktur grafisch als UML-Klassenmodell dar.

Zur besseren Übersicht über die Verantwortlichkeiten, Berichtswege und Arbeitsteilung in oder zwischen Organisationen ist die grafische Vgl. Geschäftsmitarbeiter, Geschäftspartner 72, 51 Darstellung der Organisationsstrukturen hilfreich. Organisationseinheiten gruppieren eine Menge zusammengehörender Geschäftsmitarbeiter und je nach Modellierungsfokus auch Geschäftspartner. Viele Analytiker haben ihre persönlichen Stärken typischerweise in der Erfassung,

Geschäftspartner und Geschäftsmitarbeiter werden in der UML als Ak- UML: Akteure 148 teure (Strichfiguren) dargestellt. Organisationspläne sind zunächst Organisationsplan 206 Gruppierungen dieser Akteure. Zum anderen werden sie dazu verwendet, Beziehungsgeflechte untereinander darzustellen. Mit verschiedenen Symbolen und Linien können unterschiedliche Arten von Organisationseinheiten (Abteilungen, Stabsstellen usw.) wie auch unterschiedliche Arten von Beziehungen ausgedrückt werden (z.B. disziplinarische oder fachliche Weisungsbefugnis und Verantwortung sowie Berichtsund Kommunikationswege o.Ä.). Auch verschiedene Organisationsstrukturen lassen sich entsprechend mit Ausdrucksmitteln der UML darstellen (Einlinien- und Mehrliniensysteme, Matrixorganisationen usw.). Leitfragen  Welche Berichtswege existieren? Wer berichtet an wen?  Welche fachlichen und personellen Weisungsbefugnisse existieren?  Welche fachlichen und personellen Verantwortlichkeiten existieren?  Auf welche Standorte verteilt sich die Organisation?  Welche juristischen Grenzen (Unternehmensgrenzen) existieren?  Welche Abhängigkeiten existieren? Wer liefert wem zu?  Welche Personen oder Einheiten haben gleiche oder ähnliche Aufgaben?

44

3.2 Organisationseinheiten modellieren Analyse und Schematisierung von komplexen Zusammenhängen.

Für jede identifizierte Einheit werden folgende Informationen festgehalten:  Bezeichnung, ggf. Kürzel.  Beschreibung der Aufgaben, Verantwortlichkeiten, Kompetenzen und ggf. weiterer Besonderheiten.  Benennung der Leitung und evtl. Stellvertretungen, ggf. mit konkreten aktuellen Personennamen und weiteren Informationen zu diesen Personen.  Ggf. Auflistung aller oder wichtiger Mitglieder der Organisationseinheit und ihrer besonderen Funktionen, Verantwortungen und Kompetenzen. Analyse und Schematisierung von komplexen Zusammenhängen.

Die Abb. 3.2-1 zeigt einen Ausschnitt aus der Organisationsstruktur unseres Fallbeispiels. Geschäftsleitung

Beschaffung und Verkauf

Kundenbetreuung

Mietstationen

Region Nordost

Callcenter

{Stabsstelle} Justiziariat

Rechnungswesen

Lohnbuchhaltung

KfzInstandhaltung

Public Relations

Fahrdienst

Finanzbuchhaltung

Region West

Region Südost

Abb. 3.2-1: Organisationsstruktur von Flitz-Auto

Vgl. Notation 206

Die Abbildung zeigt exemplarisch die Darstellung eines einfachen Einliniensystems mit einem Justiziariat als Stabsstelle (sog. StabLinienorganisation). Die durchgezogenen Linien von einer Organisationseinheit zu einer anderen mit der offenen Pfeilspitze drücken dabei die in Organisationsplänen allgemein übliche disziplinarische Weisungsbefugnis und Gesamtverantwortung aus. So ist hier die KfzInstandhaltung dem Fahrdienst gegenüber weisungsbefugt, aber auch verantwortlich.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.2 Organisationseinheiten modellieren Die Arbeitsweise ist vorwiegend rational geprägt.

45

Die im Sprachgebrauch vieler Unternehmen gebräuchlichen, abstrakten Abstrakte Einheiten Zusammenfassungen von gleichartigen oder zusammengehörigen Organisationseinheiten können ebenfalls mit der UML dargestellt werden. Bei Flitz-Auto werden die konkreten Organisationseinheiten Lohnbuchhaltung und Finanzbuchhaltung zusammenfassend oft als „Rechnungswesen“ bezeichnet, obwohl es diese Einheit gar nicht wirklich gibt (sie hat zum Beispiel keine Kostenstelle und auch keinen Leiter). Der Begriff ist abstrakt, aber alle Mitarbeiter wissen, was gemeint ist. Dieser Zusammenhang (wie auch der bei den Mietstationen) wird durch die geschlossene Pfeilspitze und durch Kursivschrift des Namens ausgedrückt. In Pfeilrichtung gelesen bedeutet die Darstellung: „Lohnbuchhaltung und Finanzbuchhaltung SIND (zusammenfassend) EINE ART Rechnungswesen.“ Mit anderen Worten, wenn wir von „Rechnungswesen“ reden, meinen wir immer diese konkreten Organisationseinheiten. Die Arbeitsweise ist vorwiegend rational geprägt.

Wie häufig in der Praxis, finden wir bei Flitz-Auto keine Reinform ei- Disziplinarische und nes klassischen Einliniensystems, sondern auch eine funktionale Wei- fachliche Befugnisse bzw. sungsbefugnis mit fachlicher Verantwortung zwischen Kundenbetreu- Abhängigkeiten ung und Rechnungswesen (wie sonst bei traditionellen Matrix- bzw. Projektorganisationen üblich), hier dargestellt durch eine gestrichelte Linienform mit offener Pfeilspitze. In Pfeilrichtung gelesen drückt die Grafik aus, dass alle Organisationseinheiten des Rechnungswesens von allen Organisationseinheiten der Kundenbetreuung funktional weisungsabhängig sind. Oder anders herum: Die Kundenbetreuung ist fachlich weisungsbefugt gegenüber den Abteilungen des Rechnungswesens (jedoch nicht disziplinarisch vorgesetzt). Die Kundenbetreuung in Abb. 3.2-1 ist keine abstrakte Einheit, sie ent- Kundenbetreuung, Callhält Mitarbeiter, die den Organisationseinheiten Callcenter und den drei center und Mietstationen Mietstationen vorgesetzt sind. Eine konkrete Einheit Mietstation hingegen gibt es nicht, die drei darunter liegenden konkreten Einheiten werden zusammenfassend nur so genannt. Die Schrägstriche rechts unten in den Symbolen ergeben sich übrigens aus der UML-Notation (206).

46

3.3 Ziele festlegen Gegebene Situationen werden zerlegt, um veränderbare Faktoren zu identifizieren.

3.3

Ziele festlegen

Extrakt  Beschreibe die maximal wichtigsten 7 Ziele des Unternehmens (bzw. Modellierungsfokus).  Unterscheide operative und strategische Ziele.  Versehe jedes Ziel mit einer Kennzahl zur Messung der Zielerreichung.  Beschreibe zu jedem Ziel 1 - 3 Maßnahmen zur Zielerreichung. Sisyphus

Geschäftsprozessmodellierung in einem Unternehmen kann eine sisyphusartige Lebensaufgabe werden, wenn sie ohne Ziel als Selbstzweck betrieben wird. Sie liefert dann Ergebnisse, die eher zufällig nützlich sein können. Eine zielstrebigere Herangehensweise, also eine Ausrichtung auf klar definierte Ziele, führt schneller und sicherer zu verwendbaren Ergebnissen. Die Kunst besteht darin, die richtigen Dinge wegzulassen, um so eine Konzentration auf das Wesentliche zu ermöglichen. Die Definition von Zielen bringt uns auf diesen Weg. Gegebene Situationen werden zerlegt, um veränderbare Faktoren zu identifizieren.

Grundsätzlich sind operative und strategische Ziele zu unterscheiden. Nutzung vorhandener Möglichkeiten zur Verbesserung von Kennzahlen

Verbesserung zukünftiger Möglichkeiten

 Operative Ziele Zur Erreichung operativer Ziele werden vorhandene Potenziale und Möglichkeiten ausgenutzt, um operative Kennzahlen wie Umsatz, Gewinn u.Ä. zu steigern. Operative Maßnahmen finanzieren sich aus vorhandenen Ressourcen und werden durchgeführt unter der Annahme, dass sich die Einnahme-Kosten-Relation verbessert.  Strategische Ziele Strategische Ziele dienen gewöhnlich nicht zur unmittelbaren Verbesserung bestimmter Kennzahlen, sondern mit ihnen sollen die Möglichkeiten, Potenziale und allgemeinen Rahmenbedingungen verbessert werden. Aufgrund dieser verbesserten Möglichkeiten können dann später wiederum (noch besser) operative Ziele verfolgt werden. Strategische Ziele sind daher meistens mittel- oder langfristig ausgerichtet. Leitfragen  Welche operativen Ziele sind hilfreich, um das Unternehmensleitziel zu erreichen?  Welche strategischen Ziele sind hilfreich, um das Unternehmensleitziel zu erreichen?

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.3 Ziele festlegen Wer nimmt die Gefühle wahr? Wer nimmt ganzheitlich wahr, nicht nur die Sachebene?

 Mit welcher (einzelnen) Kennzahl lässt sich die Erreichung eines Ziels messen? Für jedes Ziel wird eine Kennzahl festgelegt.  Mit welchen Aktionen und Maßnahmen ließe sich das Ziel wahrscheinlich erreichen?  Priorisierung: Welche Ziele sind die maximal 7 wichtigsten von allen gefundenen Zielen? Wer nimmt die Gefühle wahr? Wer nimmt ganzheitlich wahr, nicht nur die Sachebene?

Beschreibungsschema für Ziele. Die Ausarbeitung der Ziele vereinfacht sich, wenn dreistufig vorgegangen wird:  Ziel benennen Suchen Sie nach einem kurzen Satz oder wenigen Worten, die das Ziel einfach, aber verwechselungsfrei (in Bezug auf andere Ziele) beschreiben, z.B. „Hohe Kundentreue“. Sammeln Sie verschiedene Formulierungen und Vorschläge und wählen Sie die beste Formulierung aus. Sie sollte von allen Mitarbeitern verstanden werden können.  Indikator bzw. Kennzahl festlegen Suchen Sie nach einer einfachen Kennzahl, mit der die Zielerreichung am besten gemessen werden kann. Maßgeblich ist nicht alleine die genaueste oder dem Ziel am weitesten gerecht werdende Zahl, sondern sie soll auch möglichst objektiv und einfach zu ermitteln sein. Bei weichen Indikatoren wie Freundlichkeit helfen gewöhnlich nur Kundenbefragungen, externe Gutachter, Testkäufer u.Ä. Je komplizierter eine Kennzahl zu ermitteln oder interpretieren ist, desto geringer ist ihr Nutzen. Häufig lassen sich Zielerreichungen nur mit mehreren Kennzahlen optimal beschreiben, wählen Sie dann eine einzige Kennzahl aus, die zwar nicht mehr optimal ist, aber die Messung der Zielerreichung vereinfacht. Beispiel: „Durchschnittliche jährliche Anzahl von Kfz-Vermietungen pro Kunde.“ Folgende Kennzahlen werden häufig genutzt:  Kosten für einen Unternehmens- oder Produktbereich  Kosten pro Stück  Für Gesamtunternehmen oder einzelne Bereiche: Ergebnis, EBIT8, ROI9, Umsatz, Deckungsbeitrag, Auslastung u.Ä., Umsatzrendite  Dauer, Geschwindigkeit pro Stück  Qualität (ggf. durch Befragungen oder Gutachten), Service, Anzahl Reklamationen u.Ä.  Mögliche Maßnahmen und Aktionen festlegen Anschließend sammeln Sie mögliche Maßnahmen und Aktionen, 8 9

EBIT = Earnings before interests and taxes (siehe Glossar) ROI = Return on Investment (siehe Glossar)

47

48

3.3 Ziele festlegen Organisationen besitzen eine soziale Dynamik. Was treibt die Menschen wirklich an?

die durchgeführt werden können, um das Ziel zu erreichen oder ihm näher zu kommen. Wenn Sie mehr als drei mögliche Maßnahmen finden, wählen Sie nur die wichtigsten aus. Vergleichen Sie die Maßnahmen beispielsweise nach ihrem Kosten-Nutzen-Verhältnis und ihren Erfolgsaussichten.

ZAK: Ziel, Aktion, Kennzahl

Beispiel 3.3-1: ZAK-Karte (Ziel, Aktion, Kennzahl) Organisationen besitzen eine soziale Dynamik. Was treibt die Menschen wirklich an?

Wenn Sie einen Workshop zur Zielfestlegung veranstalten, verwenden Sie Kartei- oder Pinnwandkarten, die Sie in drei Bereiche teilen: oben dick und fett der Name des Ziels, darunter die Kennzahl und unten etwas kleiner geschrieben die 1 - 3 wichtigsten Maßnahmen. Die übrigen Maßnahmen, Kennzahlen und Anmerkungen können Sie auf der Rückseite notieren. Hilfreich ist die Verwendung verschiedener Farben für die unterschiedlichen Zieltypen, beispielsweise  Rot für das Unternehmensleitziel,  Grün für die operativen Ziele,  Gelb für die strategischen Ziele. Fokussierung der Geschäftsprozessmodellierung mit Zielen

Gewöhnlich soll mit der Geschäftsprozessmodellierung die Zielerreichung verbessert werden. Da Geschäftsprozesse nicht in zu kurzen Abständen geändert werden sollten, folgt die Geschäftsprozessmodellierung tendenziell eher den strategischen Zielen. Sofern mit der Geschäftsprozessmodellierung einige der benannten Ziele explizit nicht forciert werden sollen (warum auch immer), sollte dies gesondert vermerkt werden. Ansonsten dienen die jetzt beschriebenen Ziele dazu, alle folgenden Aktivitäten der Geschäftsprozessmodellierung zu fokussieren. Wenn die systematische Zielverfolgung im Vordergrund der Geschäftsprozessmodellierung steht, reichen einfache ZAK-Karten ggf. nicht aus. In diesem Fall empfehlen wir Ihnen folgendes detailliertes Beschreibungsschema, das wir anhand eines Beispiels in Abb. 3.3-2 darstellen:

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.3 Ziele festlegen Ängste, Konkurrenzverhalten, Widerstand sind "Politik" und stören.

Ziel #5

Kundenkontaktdauer bei Kfz-Vermietung reduzieren

Zielart

Operatives Ziel

Erläuterung

Zeit in Minuten, die der Kunde in der Kommunikation mit Flitz-Auto für eine Kfz-Mietung verbringen muss. Enthält Dauer für Reservierung (Callcenter oder Internet) sowie Zeit am Schalter der Übergabe- und Rücknahmestation.

Kennzahl

Durchschnittliche Kundenkontaktdauer pro KfzVermietung (in Minuten)

Zielwert

Kennzahl möglichst niedrig

Zielgewicht

0,70

Rahmenbedingungen

 Es darf nur ein geringes Risiko eingegangen werden  Es dürfen nur niedrige Kosten entstehen  Es soll eine mittelfristige Wirkung eintreten

Mögliche generelle Maßnahmen

 Geschäftsprozesse vereinfachen  Geschäftsprozesse automatisieren oder automatisierte Alternativen optional bereitstellen

Schematische Zielformulierung

Durchschnittliche Kundenkontaktdauer pro KfzVermietung (in Minuten) soll möglichst niedrig sein, wobei ein geringes Risiko eingegangen werden darf und niedrige Kosten entstehen dürfen und eine mittelfristige Wirkung eintreten soll.

Potenzielle beeinflussende Anwendungsfälle

(kommt später)

Abb. 3.3-2: Zieldefinition am Beispiel Kundenkontaktdauer bei Kfz-Vermietung reduzieren Ängste, Konkurrenzverhalten, Widerstand sind "Politik" und stören.

Einige Beschreibungslemente bedürfen einer näheren Erläuterung:  Der Zielwert wird stets in Bezug zur Kennzahl formuliert, d.h., es soll (a) ein bestimmter Wert erreicht werden, (b) ein möglichst hoher oder (c) ein möglichst niedriger Wert.  Das Zielgewicht ist eine Zahl zwischen 0,0 und 1,0, die ausdrückt, wie wichtig das Ziel ist. Hier ist vor allem darauf zu achten, dass die Zielgewichte aller Ziele zueinander im gewollten Verhältnis stehen. Ein Zielgewicht von 1,0 beschreibt ein Ziel von höchster Wichtigkeit, ein Zielgewicht von 0,0 ein praktisch bedeutungsloses Ziel.  Rahmenbedingungen beschreiben die Möglichkeiten und Grenzen, innerhalb derer sich die Maßnahmen bewegen sollen. Der Aufwand, der zu Erreichung eines Ziel betrieben wird, muss in einem vertretbaren Verhältnis zum Nutzen des Ziels stehen, ebenso das dabei eingegangene Risiko. Außerdem ist wichtig festzulegen, ob eine kurz-, mittel- oder langfristige Zielerreichung geplant ist. Bestimm-

49

50

3.3 Ziele festlegen Alle haben ihre eigenen Interessen.

Alle haben ihre eigenen Interessen.

te Ziele lassen sich mittel- und langfristig vielleicht mit vertretbarem Aufwand erreichen, eine kurzfristige Zielerreichung erfordert aber möglicherweise unvertretbare hohe Anstrengungen. Ein Ziel zu erreichen, wenn die Mittel nicht begrenzt sind, ist keine Kunst. Üblicherweise sind die Mittel jedoch begrenzt und deswegen ist die Festlegung dieser Rahmenbedingungen von großer Bedeutung zur späteren Bewertung der Maßnahmen. Die Rahmenbedingungen setzen sich zumindest aus folgenden drei Aspekten zusammen:  Ein [niedriges | mittleres | hohes] Risiko darf eingegangen werden.  [Niedrige | Mittlere | Hohe] Kosten dürfen dabei entstehen.  Eine [kurz- | mittel- | lang-] fristige Wirkung soll eintreten. Falls einer der drei Aspekte in einem konkreten Fall keine sinnvolle Aussage in Bezug zum Ziel ergibt, wird dieser Aspekt nicht formuliert.

 Mögliche generelle Maßnahmen sind solche, die zunächst unabhängig von den Geschäftsprozessen und Geschäftsanwendungsfällen zu sehen sind, also eine Ideensammlung, wie das Ziel grundsätzlich erreicht werden kann.  Die Zielformulierung ist ein schematisch erzeugter Satz, der sich aus den obigen Angaben ergibt. Die Phrase lautet: soll sein, wobei und und .  Die potenziell beeinflussenden Anwendungsfälle können hier noch nicht benannt werden, dies passiert erst zu einem späteren Zeitpunkt (vgl. 3.10 Geschäftsanwendungsfälle essenziell beschreiben 87, insbesondere Abb. 3.10-1: Einfluss von Anwendungsfällen auf das Ziel Kundenkontaktdauer bei Kfz-Vermietung reduzieren 91). Weiterführende Literatur: [Friedag02] H. R. Friedag, W. Schmidt: Balanced Scorecard. Haufe Verlag, Planegg, 2002.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.4 Aktive Geschäftspartner identifizieren Interessen ergänzen, überschneiden oder widersprechen sich.

3.4

51

Aktive Geschäftspartner identifizieren

Extrakt  Identifiziere die aktiven Geschäftspartner, d.h. solche Akteure, die außerhalb des Modellierungsbereiches stehend aktiv Geschäftsprozesse initiieren.  Bei dieser Gelegenheit identifizierte passive Geschäftspartner, Geschäftsmitarbeiter und Anwendungsfälle werden zur späteren Verwendung festgehalten.  Berücksichtige ggf. auch gleich 3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren (56).

Wie in Kapitel 4.2 dargestellt, unterscheiden wir vier Arten von Akteuren, die für die Geschäftsprozessmodellierung relevant sind: aktive und passive Geschäftspartner sowie außen- und innenorientierte Geschäftsmitarbeiter. Leitfrage  Wer sind die Kunden des Unternehmens? Interessen ergänzen, überschneiden oder widersprechen sich.

In diesem ersten Schritt gilt es, die aktiven Geschäftspartner zu identifizieren. Hierzu betrachten wir die äußere Grenze des Unternehmens und suchen nach außen stehenden Beteiligten, die aus eigener Initiative mit dem Unternehmen in Kontakt treten. In den meisten Fällen sind die wichtigsten aktiven Geschäftspartner bereits mit wenig Fachwissen auffindbar. Meistens reicht die einfache Frage, wer die Kunden des Unternehmens sind. Bei einer Kfz-Vermietung sind es beispielsweise die Mieter.

Abb. 3.4-1: Wer sind die aktiven Geschäftspartner? Welche Anliegen haben sie gegenüber dem Unternehmen?

Arten von Akteuren 148 Aktiver Geschäftspartner: Definition und weitere Beispiele 150

52

3.4 Aktive Geschäftspartner identifizieren Nicht immer sind die spezifischen Interessen offensichtlich.

Auch wenn wir als Geschäftsprozessanalytiker mit rudimentärem Fachwissen und etwas gesundem Menschenverstand einige aktive Geschäftspartner finden mögen – die Frage, ob dies alle sind und ob es wirklich aktive Geschäftspartner sind, können nur die Fachexperten beantworten, d.h. vor allem die Fachabteilungen. Am besten lassen sich die aktiven Geschäftspartner in einem speziellen Workshop gemeinsam mit den Fachexperten ermitteln (Abb. 3.4-2). Workshop

Aktive Geschäftspartner identifizieren

Ziel des Workshops

Alle aktiven Geschäftspartner identifizieren.

Teilnehmer

Auftraggeber Vertretungen aller wichtigen Abteilungen Moderationsteam (Moderator, Protokollant, Analytiker)

Rahmenbedingungen

Konferenzraum mit Flipchart oder Tafel

Vorbereitung

Keine

Agenda

1. Workshop-Eröffnung (Ziele, Agenda, geplante Dauer, erwartete Ergebnisse abstimmen, Teilnehmervorstellung u.Ä.) 2. Der Moderator erläutert kurz die erwartete Form des Ergebnisses und stellt sicher, dass alle Beteiligten ein gemeinsames Verständnis darüber haben, was aktive Geschäftspartner sind (max. 5 Minuten). 3. Die Teilnehmer nennen potenzielle aktive Geschäftspartner. Diese werden vom Moderator festgehalten. Es wird jeweils überprüft, ob die genannten Akteure wirklich aktive Geschäftspartner sind. Handelt es sich um passive Geschäftspartner oder Geschäftsmitarbeiter, werden diese für die spätere Verwendung separat protokolliert. Synonyme werden als solche gekennzeichnet und ebenfalls festgehalten. Sofern Begriffsdefinitionen genannt werden, sollten diese ebenfalls festgehalten werden (insg. max. 45 Minuten). 4. Kurze Zusammenfassung der Ergebnisse und Verabschiedung der Teilnehmer.

Nachbereitung:

Ergebnisse schriftlich protokollieren und an die Teilnehmer verteilen.

Abb. 3.4-2: Workshop Aktive Geschäftspartner identifizieren Nicht immer sind die spezifischen Interessen offensichtlich.

In dem Workshop lässt es sich kaum vermeiden, dass neben aktiven Geschäftspartnern auch noch andere Akteure genannt werden, d.h. passive Geschäftspartner und Geschäftsmitarbeiter. Dafür sollten die Workshop-Teilnehmer nicht getadelt werden (in der Art „Aber das ist doch kein aktiver Geschäftspartner!“), denn früher oder später müssen

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.4 Aktive Geschäftspartner identifizieren Manchmal werden die persönlichen Interessen verschwiegen und

auch die übrigen Akteure identifiziert werden. Wir nutzen also die Gelegenheit und halten auch die übrigen genannten Akteure fest. Sofern dabei bereits eine Klassifizierung stattfindet („ ist ein Geschäftsmitarbeiter/passiver Geschäftspartner/…“), wird diese vermerkt. Wenn nicht, ist es auch gut. Neben sonstigen Akteuren werden ggf. auch synonyme, abstraktere Begriffsvielfalt oder konkretere Bezeichnungen für aktive Geschäftspartner genannt. Diese sollten ebenfalls festgehalten werden, um sie später in einem Glossar 220 Glossar mit Verweis auf den zu verwendenden Begriff zu verzeichnen. Bei mehreren gleich bedeutenden konkurrierenden Begriffen sollte man sich auf einen primär zu verwendenden Begriff einigen. Leitfragen zur Begriffskonsolidierung aktiver Geschäftspartner  Steht der identifizierte Geschäftspartner außerhalb des Unternehmens bzw. des Modellierungsbereiches? „Steht außerhalb unseres Unternehmens?“  Initiiert der Geschäftspartner einen Geschäftsprozess? Steht er am Anfang einer Geschäftsprozesskette? Welchen Prozess stößt er an? „Was stößt an?“  Ist der Begriff eine Abstraktion, eine Konkretisierung oder ein Synonym für einen anderen Begriff?  Für konkrete Begriffe: Wie lautet der abstraktere Begriff? „Wie würde man verallgemeinert nennen?“  Für abstrakte Begriffe: Welche anderen konkreten Ausprägungen existieren noch? „Welche anderen gibt es noch?“  Für synonyme Begriffe: Welcher Begriff soll als Standard verwendet werden? Manchmal werden die persönlichen Interessen verschwiegen und

In unserem Fallbeispiel Flitz-Auto werden wahrscheinlich die Begriffe Kunde und Mieter genannt. Kunde ist eine abstraktere Bezeichnung für Mieter. Es ergibt sich entsprechend der obigen Leitfragen folgende Fragemöglichkeit: „Welche anderen Kunden gibt es noch?“ Die Antwort würde in diesem Fall wahrscheinlich lauten „Es gibt auch noch Kfz-Käufer.“ Die Überprüfung der Akteur-Art (aktiver/passiver Geschäftspartner, Geschäftsmitarbeiter) verläuft in unserem Beispiel entsprechend der Leitfragen etwa folgendermaßen:  „Welchen Geschäftsvorfall stößt ein Mieter an?“ „Ein Mieter wendet sich an Flitz-Auto, um ein Kfz zu reservieren. Mieter ist also ein aktiver Geschäftspartner.“

53

54

3.4 Aktive Geschäftspartner identifizieren beeinflussen dennoch die Handlungen und Entscheidungen.

 „Welchen Geschäftsvorfall stößt die Kfz-Zulassungsstelle an?“ „Keine, wir wenden uns an die Kfz-Zulassungsstelle. KfzZulassungsstelle ist kein aktiver, sondern wahrscheinlich ein passiver Geschäftspartner.“ In unserem Fallbeispiel der Kfz-Vermietung finden wir folgende aktive Geschäftspartner: beeinflussen dennoch die Handlungen und Entscheidungen.

WorkshopProtokoll

Aktive Geschäftspartner identifizieren

Zeit, Ort, Teilnehmer

…

Identifizierte aktive Geschäftspartner

 Mieter dieser reserviert und mietet Kfz.  Miet-Interessent informiert sich über Konditionen, mietbare Kfz u.Ä.  Käufer fordern Kfz-Verkaufsangebote und kaufen ehemalige MietKfz.  Kauf-Interessent informiert sich über das Kfz-Angebot u.Ä.  Fahrer erscheinen an einer Mietstation, um ein reserviertes bzw. gemietetes Kfz abzuholen oder zurückzugeben.  Bußgeldbescheidaussteller (Ordnungsamt o.Ä.) sendet der Kfz-Vermietung Bußgeldbescheide zu, wenn beispielsweise ein Fahrer mit einem gemieteten Kfz mit überhöhter Geschwindigkeit geblitzt wurde.

Ideenspeicher und Anmerkungen

Im Workshop wurde auch Bewerber als aktiver Geschäftspartner identifiziert (siehe Fotoprotokoll). Dieser wurde jedoch nicht berücksichtigt, weil er nichts zu den Zielen und dem Zweck der Geschäftsprozessmodellierung beiträgt (siehe hierzu Kapitel 3.3 Ziele festlegen 46).

Foto-/Videoprotokoll

Abb. 3.4-3: Aktive Geschäftspartner des Fallbeispiels Flitz-Auto

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.4 Aktive Geschäftspartner identifizieren Die persönlichen Interessen der Beteiligten stimmen selten

55

Die im obigen Protokoll genannten Geschäftspartner kommen jeweils aktiv und initiativ auf das Unternehmen Flitz-Auto zu. Gegenbeispiele wären  Kfz-Versicherer (passiver Geschäftspartner)  Kfz-Zulassungsstelle (passiver Geschäftspartner)  Callcenter-Agent (Geschäftsmitarbeiter)  Kfz-Werkstatt (passiver Geschäftspartner)  Kfz-Verkäufer/Händler (passiver Geschäftspartner)  Stationsmitarbeiter (Geschäftsmitarbeiter)

Die persönlichen Interessen der Beteiligten stimmen selten

Die passiven Geschäftspartner werden erst dadurch in Geschäftsprozesse der Kfz-Vermietung involviert, dass die Kfz-Vermietung sich an sie wendet, um beispielsweise ein Kfz zu versichern oder zuzulassen. Aktive Geschäftspartner wie Mieter oder Käufer hingegen initiieren einen Geschäftsvorfall. Die genannten Geschäftsmitarbeiter, bspw. der Callcenter-Agent, sind keine Geschäftspartner, weil sie innerhalb des betrachteten Unternehmens stehen. In den meisten Fällen ist die Anzahl der aktiven Geschäftspartner überschaubar. In unserem Beispiel sind es sechs. Es gibt Unternehmen, in denen es nur einer ist. Die meisten Unternehmen (bzw. Modellierungsfoki) haben deutlich weniger als 20 aktive Geschäftspartner. Im Zeitalter des Supply Chain Management ist es üblich geworden, Supply Chain Management: dass auch Lieferanten von sich aus mit Angeboten aktiv werden. Diese aktive Lieferanten sind dann als aktive Geschäftspartner zu betrachten. Die simple Formel „Kunde = aktiver Geschäftspartner, Lieferant = passiver Geschäftspartner“ ist nicht ausreichend.

56

3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren mit ihren vordergründigen Interessen als Angestellter bzw. Rolleninhaber überein.

3.5

Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren

Extrakt  Befrage die aktiven Geschäftspartner oder nehme gedanklich ihre Position ein und identifiziere die aus ihrer Sicht gewünschten Geschäftsanwendungsfälle.  Beschreibe jeden Geschäftsanwendungsfall mit Namen, Auslöser, Ergebnis, Akteur und Kurzbeschreibung. Vgl. Abb. 3.4-3: Aktive Geschäftspartner des Fallbeispiels Flitz-Auto 54

Geschäftsanwendungsfälle identifizieren. Aus dem vorigen Arbeitsschritt liegt uns eine Liste der aktiven Geschäftspartner vor. Um die wichtigsten Geschäftsanwendungsfälle zu finden, versetzen wir uns der Reihe nach in die Position der bisher bekannten aktiven Geschäftspartner und überlegen uns, welche Anwendungsfälle aus deren Sicht existieren. Noch besser wäre eine Befragung echter aktiver Geschäftspartner, falls dies möglich ist. mit ihren vordergründigen Interessen als Angestellter bzw. Rolleninhaber überein.

Da typischerweise bereits im vorigen Arbeitsschritt zusammen mit den aktiven Geschäftspartnern auch deren wichtigste Anwendungsfälle gefunden werden, wäre es möglich, die beiden Arbeitsschritte (3.4 und 3.5) zusammenzufassen. Definition Geschäftsanwendungsfall vgl. 165

Kfz kaufen oder Kfz verkaufen?

Ein Geschäftsanwendungsfall beschreibt einen geschäftlichen Ablauf, wird ausgelöst durch ein geschäftliches Ereignis und endet mit einem Ergebnis, das für den Unternehmenszweck und die Gewinnerzielungsabsicht10 direkt oder indirekt einen geschäftlichen Wert darstellt. Geschäftsanwendungsfälle beschreiben. Während wir uns bisher noch nicht um die genaue Formulierung der Geschäftsanwendungsfälle gekümmert haben, wenden wir nun ein bestimmtes Formulierungsmuster an. Wenn wir uns in die aktiven Geschäftspartner hineinversetzen, um deren Anwendungsfälle zu finden, so formulieren wir diese wahrscheinlich aus Sicht der Geschäftspartner. Beispielsweise sagen wir „der Käufer möchte ein Kfz kaufen“. Aus Gründen der Durchgängigkeit und Vereinheitlichung empfehlen wir jedoch, die Formulierung immer aus Sicht des betrachteten Unternehmens vorzunehmen. In diesem Fall würden wir sagen, „dem Käufer 10

Gewinnerzielungsabsicht ist für gemeinnützige Organisationen u.Ä. durch etwas Entsprechendes zu ersetzen, beispielsweise „trägt direkt zum festgelegten Gemeinnutz bei“.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren Die Entwicklung und Einführung von Softwaresystemen verändert

57

wird ein Kfz verkauft“. Wir suchen also stets nach einem Verb, das die Tätigkeit des Unternehmens beschreibt und nicht die der Außenstehenden. Ein anderes Beispiel hierfür ist der Anwendungsfall „Rechnung rekla- Formulierungsregeln mieren“. Der Kunde hat eine Rechnung erhalten und möchte sie wegen eines Fehlers reklamieren. Aus Sicht des Unternehmens kommen folgende Formulierungen in Frage:  Rechnung reklamieren lassen  Rechnungsreklamation annehmen  Kunde reklamiert Rechnung Die Entwicklung und Einführung von Softwaresystemen verändert

Die Wahl fällt hierbei auf die Formulierung, die die Tätigkeit des Unternehmens am besten beschreibt. Das Unternehmen reklamiert nicht (das macht der Kunde), es nimmt eine Reklamation an – also: Rechnungsreklamation annehmen. Die Namen von Anwendungsfällen sollten möglichst immer aus einer Anwendungsfallname = einfachen Kombination von Substantiv und aktivem Verb bestehen. Substantiv + aktives Verb Wir formen daher den Satz „dem Käufer wird ein Kfz verkauft“ noch etwas um. Auf „wird“ verzichten wir, weil es ein passives Verb ist und Kfz verkaufen mit „verkaufen“ ein aktives vorhanden ist. Der Anwendungsfall heißt kurz und knapp „Kfz verkaufen“. Es gibt Verben, die bezüglich der Blickrichtung neutral sind, wie beispielsweise in dem Anwendungsfall „Kfz reservieren“, dies passt sowohl aus Sicht des Geschäftspartners als auch aus Sicht des Unternehmens. Möglicherweise gibt es Fälle, in denen die Formulierung aus Unter- Inverse Formulierungsnehmenssicht holprig klingt oder den auslösenden Sachverhalt beim perspektive aktiven Geschäftspartner verschleiert. Fügen Sie dann der Verständlichkeit wegen die eingängige geschäftspartnerorientierte Formulierung in Klammern hinter die holprige Bezeichnung. Ein Beispiel hierfür ist „Rechnung bezahlen“. Das Gegenstück aus Sicht des Unternehmens ist „Zahlungseingang registrieren“ oder allgemeiner „Zahlung annehmen“. Eine mögliche Bezeichnung für den Anwendungsfall wäre also: „Zahlung annehmen (Kunde bezahlt Rechnung).“ Die meisten Anwendungsfälle enthalten als Substantiv den Namen ei- Singular / Plural nes Geschäftsobjektes, mit dem etwas getan wird. Hierfür stellt sich die Frage, ob das Substantiv im Singular oder Plural zu nennen ist. Grundsätzlich gilt, dass die Anzahl der genannten Geschäftsobjekte der Zahl entspricht, die in dem Anwendungsfall von einem Akteur zu einem konkreten Zeitpunkt betrachtet wird. Beispielsweise reklamiert ein Kunde jeweils nur eine Rechnung, daher steht Rechnung im Singular:

58

3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren die Inhalte, Abläufe und Organisation, also die Arbeit von Menschen.

„Rechnung reklamieren.“ Anders ist es möglicherweise wenn die KfzVermietung am Monatsende eine größere Menge von Monatsrechnungen erstellt und versendet und dies durch einen einzelnen Auslöser (z.B. Monatswechsel) angestoßen wird. Dann würde es heißen „Monatsrechnungen erstellen“. Würde hingegen jede Rechnung einzeln erstellt, angestoßen durch jeweils einen eigenen Auslöser, dann würde es „Monatsrechnung erstellen“ heißen. In über 90% der Fälle werden die Objekte in Anwendungsfallnamen im Singular formuliert. die Inhalte, Abläufe und Organisation, also die Arbeit von Menschen.

Leitfragen und -phrasen  Welche für das Unternehmen (bzw. den Modellierungsfokus) relevanten Ereignisse treten außerhalb des Unternehmens auf?  Welche Anwendungsfälle sind aus Sicht des wichtig? Was erwartet ein vom Unternehmen? Worauf muss das Unternehmen aus Sicht des reagieren?  Formuliere die Namen der Geschäftsanwendungsfälle so, dass sie in die Phrase „Das Unternehmen soll “ einsetzbar sind, wobei sich möglichst aus einem Substantiv (im Singular) und einem aktiven Verb zusammensetzt (z.B. „Kfz vermieten“). Das Verb soll die Tätigkeit des Unternehmens beschreiben (z.B. „Reklamation annehmen“).

Im Falle unserer Kfz-Vermietung ist der zentrale aktive Geschäftspartner der Mieter. Die konkrete Frage lautet also: Welche Anwendungsfälle sind aus Sicht des Mieters wichtig? Etwas Fachkenntnis + gesunder Menschenverstand

Stakeholder

Diese Frage können wir uns als Geschäftsprozessanalytiker an unserem Schreibtisch stellen und wir werden dabei auch wichtige Anwendungsfälle finden. Mit etwas Fachkenntnis und gesundem Menschenverstand funktioniert dies zunächst. Es ist aber zu klären, ob die gefundenen Anwendungsfälle wirklich vorliegen und wichtig sind, ebenso muss überlegt werden, welche uns nicht einfallen und welche sich vielleicht anders darstellen als vermutet. Deswegen ist es wichtig, die Stakeholder11 selbst zu befragen, d.h. exemplarisch aktive Geschäftspartner einzubeziehen. Nicht immer sind die Stakeholder direkt greifbar, dann ist zu klären, wer ihre Position am nächstbesten einnehmen kann. Wir schlagen vor, zu jedem identifizierten aktiven Geschäftspartner einen kurzen Workshop durchzuführen, in dem gemeinsam die möglichen Anwendungsfälle gesammelt werden. Dieser Workshop kann je 11

Stakeholder: eine Person oder Organisation, die in irgendeiner Form (an dem betrachteten Geschäft) direkt oder indirekt teil hat, beteiligt oder betroffen ist. Mögliche deutsche Bezeichnungen: Interessenshalter, Anforderungsbeitragender oder Projektbetroffener.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren Veränderungen können Ängste, Zurückhaltung oder offene Sabotage auslösen.

nach fachlicher Schwierigkeit und Zielstrebigkeit der Beteiligten 0,5 – 1,5 Stunden dauern. Veränderungen können Ängste, Zurückhaltung oder offene Sabotage auslösen.

Workshop

Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren

Ziel des Workshops:

Für den aktiven Geschäftspartner alle relevanten Geschäftsanwendungsfälle identifizieren.

Teilnehmer:

 1 - 4 Personen, die die Rolle des aktiven Geschäftspartners einnehmen  Moderationsteam (Moderator, Protokollant, Analytiker)

Rahmenbedingungen:

Konferenzraum mit Flipchart oder Tafel

Vorbereitung:

 Die AnalytikerInnen versetzen sich vorab kurz (5 Minuten) in die Rolle des aktiven Geschäftspartners und versuchen die Workshop-Ergebnisse vorwegzunehmen.  Die Ergebnisse aus dem Workshop 3.4 (Aktive Geschäftspartner identifizieren 51) werden hinsichtlich Hinweisen auf Geschäftsanwendungsfälle ausgewertet.  Die so entstehende Liste der Geschäftsanwendungsfälle muss nicht vollständig oder korrekt sein.

Agenda:

1. Abstimmung der Ziele, der Agenda, der erwarteten Ergebnisse und der geplanten Dauer (2 - 5 Minuten) 2. Kurze Vorstellung der Teilnehmer (2 - 5 Minuten) 3. Der Moderator erläutert kurz die erwartete Form des Ergebnisses und stellt sicher, dass alle Beteiligten ein gemeinsames Verständnis darüber haben, was Geschäftsanwendungsfälle sind, ggf. geschieht dies anhand von Beispielen aus der Vorbereitung (max. 5 Minuten). 4. Teilnehmer nennen potenzielle Geschäftsanwendungsfälle. Diese werden vom Moderator an der Tafel festgehalten und diskutiert. Alle Beteiligten wirken daran mit sicherzustellen, dass Form, Inhalt, Relevanz, Redundanzfreiheit und Vollständigkeit stimmen. Dazu gehört die fachlich kritische Diskussion ebenso wie die Herausarbeitung passender und eindeutiger Begriffe und Formulierungen (max. 45 Minuten). 5. Kurze Zusammenfassung der Ergebnisse und Verabschiedung der Teilnehmer

Nachbereitung:

Ergebnisse schriftlich protokollieren und an die Teilnehmer verteilen. Dabei Ergebnisse ggf. entsprechend Formulierungsregeln umformulieren.

Abb. 3.5-1: Workshop Geschäftsanwendungsfälle identifizieren

In dem Workshop werden die aktiven Geschäftspartner die Anwendungsfälle wahrscheinlich aus ihrer Sicht formulieren, d.h., sie werden beispielsweise sagen: „Ich möchte eine Preisauskunft erhalten.“ Wäh-

59

60

3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren Die sozialen Probleme und Defizite beeinflussen den Erfolg der Arbeit, Termine und Kosten.

rend des Workshops besteht möglicherweise keine Zeit oder es erscheint ineffizient, gemeinsam nach alternativen Formulierungen aus Perspektive des Unternehmens zu suchen. In diesem Fall gehört die sprachliche Konsolidierung in die Nachbereitung des Workshops durch das Moderationsteam bzw. durch die AnalytikerInnen. Die sozialen Probleme und Defizite beeinflussen den Erfolg der Arbeit, Termine und Kosten.

Vgl. Checkliste 165

Soweit möglich sollten die gefundenen Anwendungsfälle mit der Checkliste aus Kapitel 4.3.6 Geschäftsanwendungsfall (165) überprüft werden, möglichst sofort während des Workshops, spätestens aber in der Nachbereitung. Die folgende Abbildung zeigt das Ergebnis eines solchen Workshops. Das Fotoprotokoll zeigt teilweise noch andere Formulierungen als im konsolidierten nachbereiteten Schriftprotokoll. WorkshopProtokoll

Geschäftsanwendungsfälle für Mieter identifizieren

Zeit, Ort, Teilnehmer

12.7.2002, 11.00 – 11.45 Uhr, Konfi 3, Moderationsteam: Herr Lenhard (Moderation), Herr Weilkiens (Protokoll), Frau Schröder (Analytikerin), als Mieter: Herr Tröster (Geschäftstelle Weidenstraße), Frau Goldfisch (Leitung Geschäftstelle Mitte), Herr Witt (Vertrieb)

Geschäftsanwendungs-  Kfz reservieren fälle  Kfz vermieten (aus Mietersicht: Kfz nutzen)  Kfz-Reservierung ändern  Kfz-Reservierung stornieren  Preisauskunft für Kfz-Vermietung erteilen  Zahlungseingang für Kfz-Vermietung registrieren  Rechnungsreklamation für Kfz-Vermietung annehmen/bearbeiten  Beschwerde annehmen  Mieterdaten erfassen (im Rahmen der ersten Reservierung)  Mieterdaten ändern  Mieterdaten löschen  Kundendaten löschen Ideenspeicher und Anmerkungen

 Es wurde nochmal über die Begriffe Kunde und Mieter diskutiert. Häufig wird Kunde gesagt, obwohl es präziser Mieter heißen müsste. Außerdem wurden zwei verschiedene Arten von Mietern bzw. Kunden genannt: solche, die nur im Rahmen einer einzelnen Reservierung und Kfz-Nutzung erfasst werden, und solche, die grundsätzlich, d.h. als „Stammkunden“, bekannt sind. Die Begriffe sind noch abzugrenzen, zu klären und unbedingt im Glossar zu definieren.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren Nicht aufgearbeitete Ängste und Widerstände seitens der Fachabteilung

61

 Es wurden stellenweise die Geschäftspartner Mieter und Fahrer verwechselt, d.h,. es wurden auch Anwendungsfälle des Geschäftspartners Fahrer genannt, beispielsweise Schadenmeldung annehmen und Fahrer in Kfz einweisen.  Da einige Anwendungsfälle mit ähnlichen Formulierungen auch beim Kfz-Verkauf vorkommen könnten, beispielsweise „Preisauskunft erteilen“, wurde der Bezug „Kfz-Vermietung“ explizit in die Anwendungsfallbezeichnungen aufgenommen, um Verwechselungen zu vermeiden (d.h. „Preisauskunft für KfzVermietung erteilen“). Fotoprotokoll

Abb. 3.5-2: Geschäftsanwendungsfälle für Mieter identifizieren Nicht aufgearbeitete Ängste und Widerstände seitens der Fachabteilung

Nachdem wir die Geschäftsanwendungsfälle der aktiven Geschäfts- Klassifizieren partner identifiziert haben, klassifizieren wir die gefundenen Geschäftsanwendungsfälle in Kern-Geschäftsanwendungsfälle und unterstützende Geschäftsanwendungsfälle. Ein Kern-Geschäftsanwendungsfall beschreibt einen geschäftlichen Definition KernAblauf, der von einem aktiven Geschäftspartner ausgelöst wird, ein Geschäftsanwendungsfall Ergebnis von geschäftlichem Wert für mindestens einen aktiven Ge- vgl. 166 schäftspartner erzeugt und direkt mit dem Unternehmenszweck und einer Gewinnerzielungsabsicht zusammenhängt. Ein unterstützender Geschäftsanwendungsfall beschreibt einen ge- Definition unterstützender schäftlichen Ablauf, der für den Unternehmenszweck und die Gewinn Geschäftsanwendungsfall vgl. 167 erzielungsabsicht keinen oder nur indirekt einen Wert darstellt. Die Anwendungsfälle der aktiven Geschäftspartner stellen für diese eine Dienstleistung dar, deren Ergebnis für sie einen geschäftlichen Nutzen bringt. Als Kern-Geschäftsanwendungsfälle bezeichnen wir solche, die direkt mit dem Unternehmenszweck zusammenhängen, während unterstützende Geschäftsanwendungsfälle nur indirekt damit zusammenhängen.

62

3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren und anderer Stakeholder machen Geschäftsprozessmodellierungs- und

Gewinnerzielungsabsicht

Mit den Kern-Geschäftsanwendungsfällen wird gewöhnlich direkt eine Gewinnerzielungsabsicht verfolgt. Als unterstützende Geschäftsanwendungsfälle werden solche bezeichnet, die nur der Unterstützung der Kern-Geschäftsanwendungsfälle dienen und nur indirekt mit dem Unternehmenszweck zusammenhängen. Der Verkauf von Produkten oder Dienstleistungen ist gewöhnlich ein Kern-Geschäftsanwendungsfall, während beispielsweise die Finanzbuchhaltung oder der Wareneinkauf einen unterstützenden Geschäftsanwendungsfall darstellt.

Im Zweifel unterstützend

Wir gehen also die Liste der gefundenen Geschäftsanwendungsfälle des Mieters durch und entscheiden für jeden einzelnen, ob es sich um einen Kern- oder unterstützenden Geschäftsanwendungsfall handelt. Hierbei gilt die Regel: Im Zweifelsfall, also wenn die Entscheidung nicht unmittelbar eindeutig ausfällt, ist es ein unterstützender Geschäftsanwendungsfall.

und anderer Stakeholder machen Geschäftsprozessmodellierungs- und

Leitfragen für Kern-Geschäftsanwendungsfälle  Wird mit dem im Geschäftsanwendungsfall beschriebenen Geschäft direkt Geld verdient?  Erhält ein aktiver Geschäftspartner aus dem Geschäftsanwendungsfall eine für ihn wertvolle Leistung?  Kommt durch den Geschäftsanwendungsfall ein impliziter oder expliziter Vertrag mit dem beteiligten Geschäftspartner zustande?  Im Zweifelsfall wird ein Geschäftsanwendungsfall unterstützender Geschäftsanwendungsfall angesehen.

als

Kfz reservieren

Kern-Geschäftsanwendungsfall Es kommt ein Vertrag (Reservierung) mit Wert für einen aktiven Geschäftspartner zustande.

Kfz vermieten (aus Mietersicht: Kfz nutzen)

Kern-Geschäftsanwendungsfall Der Geschäftspartner erhält eine wertvolle Leistung, er nutzt den Vertrag.

Kfz-Reservierung ändern

Kern-Geschäftsanwendungsfall Der Vertrag wird geändert.

Kfz-Reservierung stornieren

Kern-Geschäftsanwendungsfall Der Vertrag wird geändert.

Preisauskunft für KfzVermietung erteilen

Kern-Geschäftsanwendungsfall Dient der Vertragsanbahnung und stellt ein Angebot dar, aus dem Rechte und Pflichten (d.h. geschäftlicher Wert) für die Geschäftspartner resultieren.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren Softwareprojekte teurer, aufwändiger oder bringen sie gar zum Scheitern.

Zahlungseingang für KfzVermietung registrieren

Unterstützender Geschäftsanwendungsfall Zwar geht es hier um Geld, verdient wurde das Geld aber mit anderen Geschäftsanwendungsfällen, z.B. dem Vermieten. Dieser Anwendungsfall dient zur Unterstützung der Vermietung.

Rechnungsreklamation für Kfz-Vermietung bearbeiten

Unterstützender Geschäftsanwendungsfall Diesen Anwendungsfall gibt es nur aufgrund anderer. Andererseits impliziert bspw. eine nachträgliche Rechnungsänderung auch eine andere vertragliche Situation. Im Zweifelsfall entscheiden wir uns für den unterstützenden Geschäftsanwendungsfall.

Beschwerde annehmen

Unterstützender Geschäftsanwendungsfall Diesen Anwendungsfall gibt es nur aufgrund und zur Unterstützung anderer.

Mieterdaten erfassen (im Rahmen der ersten Reservierung)

Unterstützender Geschäftsanwendungsfall Diesen Anwendungsfall gibt es nur aufgrund und zur Unterstützung anderer.

Mieterdaten ändern

Unterstützender Geschäftsanwendungsfall Diesen Anwendungsfall gibt es nur aufgrund und zur Unterstützung anderer.

Mieterdaten löschen

Unterstützender Geschäftsanwendungsfall Diesen Anwendungsfall gibt es nur aufgrund und zur Unterstützung anderer.

Kundendaten löschen

Unterstützender Geschäftsanwendungsfall Diesen Anwendungsfall gibt es nur aufgrund und zur Unterstützung anderer.

Abb. 3.5-3: Klassifizierung der Geschäftsanwendungsfälle des Mieters in Kern- und unterstützende Geschäftsanwendungsfälle Softwareprojekte teurer, aufwändiger oder bringen sie gar zum Scheitern.

Die hier identifizierten Geschäftsanwendungsfälle werden später weiter Details kommen später bearbeitet und detailliert. Daher ist es sinnvoll, sie jetzt schon als ei- 87 genständige Dokumente zu behandeln. Die folgende Abbildung zeigt eine einfache Vorlage, die zunächst nur die Rubriken Name, Art, Auslöser, Ergebnis, Akteure und Kurzbeschreibung enthält. Später kommen weitere Details hinzu (3.10 Geschäftsanwendungsfälle essenziell beschreiben 87). Der Auslöser sollte eine konkrete Aktion des Geschäftspartners ausdrücken. Unter Umständen kann es hilfreich sein, zu unterscheiden zwischen dem geschäftlich relevanten Auslöser (Mieter wendet sich an Flitz-Auto, um ein Kfz zu reservieren) und seiner eigentlichen Motivation und seinen Gründen (Mieter möchte mit Kfz in Urlaub fahren, Mieter möchte etwas transportieren, geschäftlicher Aufenthalt abseits öf-

63

64

3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren Kommunikations- und Organisationsprobleme beim Auftraggeber,

fentlicher Verkehrsmittel etc.), weil dadurch möglicherweise neue Geschäftsanwendungsfälle entdeckt werden. Was bekommt der Geschäftspartner im Idealfall?

Auch das Ergebnis wird möglichst aus Sicht des Geschäftspartners formuliert: Was bekommt er? Welcher gewünschte Zustand ist eingetreten? Hierbei wird nur der Idealfall betrachtet, eventuelle Ausnahmen oder das Scheitern des Geschäftsanwendungsfalles werden hier ignoriert. Die Kurzbeschreibung sollte aus 1 - 3 Sätzen bestehen. Auch wenn es stupide oder banal klingt, verwenden Sie eine einfache Formulierung, die ggf. ähnlich zur Formulierung des Auslösers oder Ergebnisses ist. Verzichten Sie auf Synonyme oder besondere sprachliche Abwechselung. Beschreibung Geschäftsanwendungsfall Name

Kfz reservieren

Art

Kern-Geschäftsanwendungsfall

Kurzbeschreibung

Ein Mieter reserviert ein Kfz bei Flitz-Auto.

Auslöser, ggf. Motivation

Ein Mieter wendet sich an Flitz-Auto, um ein Kfz zu reservieren.

Ergebnis

Für den Mieter wurde ein Kfz reserviert.

Akteure

(potenzieller) Mieter

Abb. 3.5-4: Beschreibung des identifizierten Geschäftsanwendungsfalles Kfz reservieren Kommunikations - und Organisationsprobleme beim Auftraggeber,

Rollenwechsel eines Akteurs

Manchmal kommt es vor, dass ein Akteur seine Rolle im Laufe eines Anwendungsfalles verändert. Zu Beginn tritt er beispielsweise als Interessent auf und im weiteren Verlauf wird er dann zum Kunden. Welche Akteurbezeichnung soll in diesem Fall verwendet werden? Wir plädieren dafür, einfach beide Akteure anzugeben und auf den Rollenwechsel explizit hinzuweisen (z.B. „Interessent (wird Kunde)“ oder „(potenzieller) Mieter“).

Werkzeuge

Als Werkzeug kann ein normales Textverarbeitungsprogramm oder Wiki12 verwendet werden, welches erlaubt, Schablonen zu verwenden.

Paketstruktur 204

Zur Verwaltung der einzelnen Textdokumente kann ein normales UML-Modellierungswerkzeug eingesetzt werden. In diesem sollte eine entsprechende Gliederungsstruktur (Paketstruktur) definiert sein, in der sich auch ein Paket für die identifizierten Geschäftsanwendungsfälle findet. Die meisten UML-Modellierungswerkzeuge erlauben es, zu einem Anwendungsfall eine Referenz auf ein externes Textdokument zu verwalten.

12

Wiki, siehe Glossar

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren die auf einer sozialen Ebene gelöst werden müssten,

65

Eine grafische Darstellung mit UML zeigt Abb. 3.5-5. Dort ist als Akteur der aktive Geschäftspartner Mieter zu sehen und es ist angegeben, UML: Akteure 148, Geschäftsanwendungsfälle an welchen Geschäftsanwendungsfällen er beteiligt ist. 165

Im Rahmen eines solchen Workshops zur Identifikation der Geschäftsanwendungsfälle eines Akteurs kommt es regelmäßig vor, dass auch noch weitere Akteure genannt werden, die an den gefundenen Geschäftsanwendungsfällen beteiligt sind. Diese sollten dann ebenfalls mitprotokolliert werden. In Abb. 3.5-5 ist beispielsweise noch der Akteur Fahrer zu sehen. Die Angabe 1..* beim Fahrer zeigt, dass es sogar mehrere Fahrer für eine Vermietung geben kann. Die dargestellten Akteure sind grundsätzlich Rollen und keine konkre- Akteure sind Rollen, keine ten Personen. Diese Rollen können unter Umständen von denselben konkreten Personen Personen wahrgenommen werden. Beispielsweise sind Mieter und Fahrer dieselbe Person, wenn der Fahrer den Mietvertrag im Auftrag des Mieters unterschreibt – die Kfz-Vermietung unterstellt in einem solchen Fall einen Geschäftsbesorgungsvertrag zwischen Fahrer und Mieter. Kfz reservieren Kfz vermieten Mieterdaten aufnehmen

1..* Kfz-Reservierung stornieren

Mieterdaten ändern Mieter

Fahrer

Kfz-Reservierung ändern

Preisauskunft für Kfz-Vermietung erteilen

Mieterdaten löschen

Rechn.reklamation für Kfz-Vermietung bearbeiten

Zahlungseingang für Kfz-Vermietung registrieren

Beschwerde annehmen

Abb. 3.5-5: Geschäftsanwendungsfälle des Mieters die auf einer sozialen Ebene gelöst werden müssten,

Unsere Erfahrungen mit dem Einsatz grafischer UML-Mittel zeigen, Praxistipp dass Fachabteilungen, die diese Notation nicht kennen, anfangs viel Widerstand dagegen aufbauen können. Allerdings tritt meistens relativ schnell ein Gewöhnungseffekt und damit Akzeptanz ein. Es ist in der Praxis hilfreich, die im Workshop entstandenen Skizzen möglichst unverändert in den Protokollen wiederzugeben, beispielsweise als Digitalfoto. Es ist dann weniger gedankliche Übersetzungsarbeit notwendig und die Wiedererkennungseffekte erhöhen die Akzeptanz der Notation.

66

3.6 Weitere unterstützende Geschäftsanwendungsfälle identifizieren sollen fälschlicherweise auf der Sachebene, z.B. durch Software, beseitigt werden.

3.6

Weitere unterstützende Geschäftsanwendungsfälle identifizieren

Extrakt  Überlege, welche (weiteren) unterstützenden Geschäftsanwendungsfälle und Geschäftspartner notwendig sind, um die identifizierten Kern-Geschäftsanwendungsfälle zu betreiben.  Beschreibe jeden unterstützenden Geschäftsanwendungsfall mit Namen, Auslöser, Ergebnis, Akteur und Kurzbeschreibung.

Die Anzahl der Kern-Geschäftsanwendungsfälle ist in den meisten Unternehmen geringer als die Anzahl der unterstützenden. Einen viel größeren Teil machen also die unterstützenden Geschäftsanwendungsfälle aus, die den Rahmen und die Basis bilden, damit die KernGeschäftsanwendungsfälle überhaupt erst erfolgreich laufen können. sollen fälschlicherweise auf der Sachebene, z.B. durch Software , beseitigt werden.

Wenn ein Unternehmen etwas verkauft, muss es diese Produkte oder Dienstleistungen zuvor einkaufen oder herstellen. Damit eine Autovermietung Kraftfahrzeuge vermieten kann, muss es zuvor Fahrzeuge beschaffen, Mitarbeiter einstellen, den Mitarbeitern Gehälter zahlen, Fahrzeuge warten, ein Callcenter oder eine Vermietstation betreiben, Marketing machen. Und weil es gesetzlich vorgeschrieben ist, eine Buchhaltung führen. Vgl. Definition unterstützender Geschäftsanwendungsfall 167

Ein unterstützender Geschäftsanwendungsfall beschreibt einen geschäftlichen Ablauf, der für den Unternehmenszweck und die Gewinnerzielungsabsicht keinen oder nur indirekt einen Wert darstellt. Als unterstützende Geschäftsanwendungsfälle bezeichnen wir solche, die nicht direkt dem Geschäftszweck zuzuordnen sind, die von den aktiven Geschäftspartnern nicht oder nicht direkt benötigt oder verlangt werden, ohne die aber die Kern-Geschäftsanwendungsfälle nicht funktionieren würden. Leitfragen  Welche Leistungen von Lieferanten und anderen Geschäftspartnern sind notwendig, damit die Kern-Geschäftsanwendungsfälle dauerhaft funktionieren können?  Welche internen Geschäftsanwendungsfälle werden noch benötigt?  Welche Geschäftspartner (z.B. Lieferanten) sind in diese unterstützenden Geschäftsanwendungsfälle involviert?

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.6 Weitere unterstützende Geschäftsanwendungsfälle identifizieren Die Kommunikation wird dann noch unpersönlicher und

67

Es ist offensichtlich, dass die Anzahl der unterstützenden Geschäftsanwendungsfälle gewöhnlich ein Vielfaches von der Anzahl der Kern- Büroreinigung als Geschäftsanwendungsfälle ausmachen wird. So stellt sich die Frage, unterstützender Geschäftsanwendungsfall? welche notwendigen Unterstützungsleistungen sinnvollerweise zu betrachten sind. Konsequent zu Ende gedacht, gehört beispielsweise die gesamte Bereitstellung der Infrastruktur des Unternehmens dazu, also beispielsweise: Schreibtische kaufen, Strom kaufen, Telefonanlage programmieren, Papierkörbe leeren, Teppich saugen, Visitenkarten drucken lassen, Bewerbungsgespräche führen und so weiter. Die Geschäftsprozessmodellierung soweit auszudehnen und eine voll- Langeweile? ständige Beschreibung aller Unternehmensprozesse anzustreben, könnte als Arbeitsbeschaffungsmaßnahme sinnvoll sein. Das perfekte und vollständige Modell ist jedoch wahrscheinlich unerreichbar. Wenn der letzte Geschäftsanwendungsfall beschrieben ist, haben sich die ersten schon wieder geändert.

Die Kommunikation wird dann noch unpersönlicher und

Die folgenden Leitfragen helfen Ihnen, sich auf die wesentlichen unterstützenden Geschäftsanwendungsfälle zu konzentrieren, um mit geringem Aufwand dennoch einen guten Nutzen zu erzielen. Leitfragen  Tätigkeiten wie Bereitstellung und Instandhaltung von allgemeiner Infrastruktur (Strom, Wasser, Telefon, PC-Hardware, Software, Büroreinigung etc.) sollten nur dann berücksichtigt werden, wenn sie eine besondere und über das übliche Maß hinausgehende Komplexität aufweisen. Außer natürlich, wenn diese Tätigkeiten zum Kerngeschäft gehören, wie beispielsweise bei einem Stromlieferanten.  Beschreibt der Geschäftsanwendungsfall eine allgemeineTätigkeit, die ohne direkten Bezug zu den Kern-Geschäftsanwendungsfällen steht? Beschreibt der Geschäftsanwendungsfall eine Tätigkeit, die unabhängig von der konkreten Geschäftstätigkeit ist und in gleicher Weise auch in völlig anderen geschäftlichen Kontexten vorkommen könnte? Dies sind zumindest deutliche Indikatoren dafür, den Geschäftsanwendungsfall zu ignorieren.  Unterstützt der Geschäftsanwendungsfall nicht nur einen einzelnen, sondern mehrere oder alle Kern-Geschäftsanwendungsfälle? Dies ist ein schwacher Indikator, es ist abzuwägen, ob der Geschäftsanwendungsfall berücksichtigt oder ignoriert werden soll.

Unterstützende Geschäftsanwendungsfälle identifizieren. Die unter- Aktive Geschäftspartner stützenden Geschäftsanwendungsfälle finden wir am besten – Sie kön- identifizieren 51 nen es sich denken – durch einen kleinen Workshop. Teilnehmen soll-

68

3.6 Weitere unterstützende Geschäftsanwendungsfälle identifizieren die Probleme für den Auftraggeber nicht kleiner, sondern größer.

ten daran Vertretungen für die aktiven Geschäftspartner sowie (ähnlich wie am Anfang beim Identifizieren der aktiven Geschäftspartner) Vertretungen aller wichtigen Abteilungen. Workshop

Unterstützende Geschäftsanwendungsfälle identifizieren

Ziel des Workshops:

Alle unterstützenden Geschäftsanwendungsfälle und passiven Geschäftspartner identifizieren.

Teilnehmer:

 Vertretungen aller wichtigen Abteilungen  Stellvertretungen aller identifizierten aktiven Geschäftspartner  Moderationsteam (Moderator, Protokollant, Analytiker)

Rahmenbedingungen:

Konferenzraum mit Flipchart oder Tafel

Vorbereitung:

Die Ergebnisse aus den vorigen Workshops werden auf Hinweise auf unterstützende Geschäftsanwendungsfälle und passive Geschäftspartner ausgewertet. Die so entstehende Liste muss nicht vollständig oder korrekt sein.

Agenda:

1. Abstimmung der Ziele, der Agenda, der erwarteten Ergebnisse und der geplanten Dauer (2 - 5 Minuten) 2. Kurze Vorstellung der Teilnehmer (2 - 5 Minuten) 3. Der Moderator erläutert kurz die erwartete Form des Ergebnisses und stellt sicher, dass alle Beteiligten ein gemeinsames Verständnis darüber haben, was unterstützende Geschäftsanwendungsfälle sind, ggf. geschieht dies anhand von Beispielen aus der Vorbereitung (max. 5 Minuten). 4. Teilnehmer nennen potenzielle unterstützende Geschäftsanwendungsfälle und/oder passive Geschäftspartner. Diese werden vom Moderator an der Tafel festgehalten und diskutiert. Alle Beteiligten wirken daran mit sicherzustellen, dass Form, Inhalt, Relevanz, Redundanzfreiheit und Vollständigkeit stimmen. Dazu gehört die fachlich kritische Diskussion ebenso wie die Herausarbeitung passender und eindeutiger Begriffe und Formulierungen (max. 120 Minuten). 5. Kurze Zusammenfassung der Ergebnisse und Verabschiedung der Teilnehmer.

Nachbereitung:

Ergebnisse schriftlich protokollieren und an die Teilnehmer verteilen. Dabei Ergebnisse ggf. entsprechend Formulierungsregeln umformulieren.

Abb. 3.6-1: Workshop Unterstützende Geschäftsanwendungsfälle und passive Geschäftspartner identifizieren die Probleme für den Auftraggeber nicht kleiner, sondern größer.

An den unterstützenden Geschäftsanwendungsfällen sind Geschäftspartner und Geschäftsmitarbeiter beteiligt. In unserem Beispiel Autovermietung ist die Beschaffung von Kfz beispielsweise ein wichtiger unterstützender Geschäftsanwendungsfall. Daran beteiligt sind wiederum eine Reihe von Geschäftspartnern: ein Kfz-Händler, bei dem die

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.6 Weitere unterstützende Geschäftsanwendungsfälle identifizieren Soziale Risiken sind nicht weniger kritisch oder relevant als

69

Fahrzeuge gekauft werden, eine Kfz-Werkstatt, die das Fahrzeug für die Vermietung herrichtet, eine Zulassungsstelle usw. Des Weiteren sind auch zahlreiche Geschäftsmitarbeiter beteiligt, die Geschäftsmitarbeiter 152 hier aber noch nicht im Vordergrund stehen und vernachlässigt werden. Leitfragen  Ist der unterstützende Geschäftsanwendungsfall aus der Perspektive des betrachteten Unternehmens (Modellierungsfokus) formuliert? Ist der Name beispielsweise einsetzbar in die Phrase „Das Unternehmen möchte “, wobei sich möglichst aus einem Substantiv (im Singular) und einem aktiven Verb zusammensetzt (z.B. „Kfz beschaffen“). Soziale Risiken sind nicht weniger kritisch oder relevant als

Ebenso wie die Kern-Geschäftsanwendungsfälle werden auch die unterstützenden Geschäftsanwendungsfälle aus der Sicht des Unternehmens formuliert, wir sprechen also beispielsweise von „Kfz beschaffen“ und nicht von „Kfz verkaufen“ (wie es aus Sicht des Autohändlers heißen würde). Eine einheitliche Formulierungsperspektive ist notwendig, um Konflikte zu vermeiden. Beispielsweise ist „Kfz verkaufen“ bereits ein Kern-Geschäftsanwendungsfall unserer Autovermietung, da die Mietwagen nach einer gewissen Zeit als Gebrauchtwagen wieder verkauft werden. WorkshopProtokoll

Unterstützende Geschäftsanwendungsfälle identifizieren

Zeit, Ort, Teilnehmer

…

Unterstützende Geschäftsanwendungsfälle

Unterstützende Geschäftsanwendungsfälle aus dem vorherigen Workshop Geschäftsanwendungsfälle für Mieter identifizieren (vgl. Abb. 3.5-2 61):  Zahlungseingang für Kfz-Vermietung registrieren  Rechnungsreklamation für Kfz-Vermietung annehmen/bearbeiten  Beschwerde annehmen  Mieterdaten erfassen (im Rahmen der ersten Reservierung)  Mieterdaten ändern  Mieterdaten löschen  Löschung der Kundendaten beantragen Neue, in diesem Workshop identifizierte Geschäftsanwendungsfälle:  Kfz beschaffen  Tarif einrichten  Tarif ändern  Tarif schließen

Kfz beschaffen versus Kfz verkaufen vgl. 57

70

3.6 Weitere unterstützende Geschäftsanwendungsfälle identifizieren typische andere Risiken wie unzulängliche Werkzeuge und Vorgehensweisen,

       

Kfz-Schaden bearbeiten Schadenmeldung bearbeiten Kfz instand halten (inkl. reparieren) Kfz überführen Bußgeldbescheid bearbeiten Zahlungseingänge buchen Vermietungen abrechnen Kfz entsorgen

Ideenspeicher und Anmerkungen Foto-/Videoprotokoll

nicht vorhanden

Abb. 3.6-2: Unterstützende Geschäftsanwendungsfälle identifizieren typische andere Risiken wie unzulängliche Werkzeuge und Vorgehensweisen,

UML, Word, Karteikarten

Im Anschluss an den Workshop, ggf. aber auch während des Workshops, sollte jeder Geschäftsanwendungsfall kurz dokumentiert werden, zum einen mit einem UML-Modell (in der Art wie in Abb. 3.5-5 65) sowie beispielsweise mit einem kurzen Word-Dokument (wie in Abb. 3.6-3) oder in kleineren Projekten oder bei informellerer Arbeitsweise mit Hilfe von Karteikarten. Beschreibung unterstützender Geschäftsanwendungsfall Name

Kfz beschaffen

Auslöser

Die Geschäftsführung beschließt die Anschaffung neuer Kfz zur Vermietung.

Ergebnis

Ein Kfz wurde beschafft und zur Vermietung stationiert.

Beteiligte Geschäftspartner

Kfz-Händler, Kfz-Zulassung, Franchise-Nehmer

Kurzbeschreibung

Ein benötigtes Kfz wird gekauft, versichert, amtlich zugelassen und für die Vermietung hergerichtet und bereitgestellt.

Abb. 3.6-3: Beschreibung des identifizierten unterstützenden Geschäftsanwendungsfalles Kfz beschaffen

Pragmatismus

Streng genommen würde mit der oben beschriebenen Vorgehensweise der Anwendungsfall Tarif einrichten nicht gefunden werden, denn er ist nicht zwingend notwendig, um die Kern-Geschäftsanwendungsfälle zu betreiben. Die Tarife dienen der Festlegung von Preisen und Konditionen nach festgelegten Kriterien. Theoretisch (aber fragwürdig) wäre es möglich, bei jeder Kfz-Vermietung den Preis individuell auszuhandeln – ein Tarif wäre dann nicht notwendig. Geben Sie in diesen Fällen Ihrem gesunden Menschenverstand und Pragmatismus nach und berücksichtigen Sie in vergleichbaren Fällen den Anwendungsfall.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.6 Weitere unterstützende Geschäftsanwendungsfälle identifizieren mangelnde Qualifikation oder unreife Technologien.

71

An dieser Stelle taucht aber noch eine weitere Frage auf: Wann ist ein Ablauf ein eigener Geschäftsanwendungsfall und wann ein Detail in Ablaufschritt oder eigener einem anderen Geschäftsanwendungsfall? Im Rahmen einer jeden Kfz- Anwendungsfall? Reservierung wird ein Tarif zugrunde gelegt, d.h. ein Preis festgesetzt. Ebenso wird im Rahmen einer jeden Kfz-Vermietung der Mieter identifiziert. Dennoch wird Tarif einrichten als eigener Geschäftsanwendungsfall betrachtet und Mieter identifizieren nicht (nur als Schritt im Ablauf). Was ist also das Kriterium dafür, einen Sachverhalt als eigenen Geschäftsanwendungsfall aufzufassen? mangelnde Qualifikation oder unreife Technologien.

Die entscheidende Frage ist, ob der Sachverhalt bzw. Teilablauf jedes Mal individuell stattfindet oder für eine ganze Reihe von Geschäftsvorfällen gültig ist. Wird der Preis bei jeder Reservierung individuell festgelegt, ist es ein Schritt im Ablauf von Kfz reservieren. Wird einmal ein Tarif festgelegt und gilt dann eine Zeit lang für alle KfzReservierungen, ist Tarif einrichten ein eigener Geschäftsanwendungsfall. Ein anderes Beispiel: Die Prüfung der Kundenbonität wäre ein Ablaufschritt, wenn sie bei jeder Reservierung stattfinden würde, ebenso wenn sie einmal bei jeder Neuaufnahme eines Kunden ablaufen würde (als Schritt von Kunde aufnehmen). Würde hingegen festgelegt, einmal im Jahr wird die Bonität aller Kunden geprüft, wäre es ein eigener Geschäftsanwendungsfall.

72

3.7 Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln Wenn versucht wird, die sozialen Probleme wie Sachprobleme zu behandeln,

3.7

Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln

Extrakt  Betrachte alle Geschäftsanwendungsfälle und identifiziere für jeden die beteiligten Rollen. Begrenze dies jedoch auf maximal 7 Rollen bzw. 4 Minuten pro Geschäftsanwendungsfall.  Notiere die Ergebnisse je Geschäftsanwendungsfall als Geschäftsanwendungsfall-Kontext.  Ordne die gefundenen Geschäftsmitarbeiter einer Organisationseinheit zu. Falls keine existierende Organisationseinheit passt, wurde eine neue gefunden.  Unterscheide ggf. Soll- und Ist-Situation der Aufbauorganisation. Wenn versucht wird, die sozialen Probleme wie Sachprobleme zu behandeln,

Bisher haben wir vor allem die aktiven und passiven Geschäftspartner betrachtet, also die außerhalb des betrachteten Unternehmens (bzw. Modellierungsfokus) stehenden Beteiligten. Nun wenden wir uns den Beteiligten innerhalb des Unternehmens zu, den so genannten Geschäftsmitarbeitern. Die Geschäftsmitarbeiter identifizieren wir, weil sie das Unternehmen am Laufen halten. Wir möchten erkennen oder festlegen, welche Mitarbeiter wann welche Leistungen zu erbringen und zu verantworten haben, damit die Geschäftsprozesse wie vorgesehen funktionieren. Grundlagen innen- und außenorientierte Geschäftsmitarbeiter 151, 152

Abgrenzung Personen und Akteure Akteure sind Rollen

Die vorhandenen Geschäftsanwendungsfälle führen uns zu den Geschäftsmitarbeitern. Wir unterscheiden zwei verschiedene Arten von Geschäftsmitarbeitern: die innen- und die außenorientierten. Die außenorientierten, d.h. die nach außen gerichteten Mitarbeiter, haben direkten Kontakt mit den Geschäftspartnern, also vor allem Kunden und Lieferanten. Die innenorientierten haben keinen Kontakt zu außenstehenden, zumindest nicht im gewählten Modellierungsfokus. Als Oberbegriff für aktive und passive Geschäftspartner sowie außenund innenorientierte Geschäftsmitarbeiter verwenden wir den Begriff Akteur. Bei allen Arten von Akteuren meinen wir nicht die konkret existierenden Personen (wie z.B. Susanne Sonnenschein), sondern betrachten und benennen nur die Rollen, die sie im zu untersuchenden Geschäft spielen (z.B. Callcenter-Agent). Dabei kann ein Akteur durch mehrere konkrete Personen repräsentiert werden (z.B. gibt es neben Susanne Sonnenschein noch Gabi Goldfisch und Ludwig Lustig, die auch Callcenter-Agents sind) und eine Person kann unter Umständen

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.7 Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln verschärft sich die Lage.

73

mehrere Rollen spielen (z.B. ist Gabi Goldfisch gleichzeitig auch Kundin, also eine aktive Geschäftspartnerin). Betrachte alle Geschäftsanwendungsfälle. Wir nehmen alle bisher Beschreibung der erkannten Geschäftsanwendungsfälle und untersuchen sie dahingehend, Ablaufschritte welche Akteure an ihnen beteiligt sind. Bei der Untersuchung von 87ff. Kern-Geschäftsanwendungsfällen werden wir vor allem auf außenorientierte Geschäftsmitarbeiter stoßen. Die daran beteiligten innenorientierten Geschäftsmitarbeiter werden größtenteils erst bei der (in den Kapiteln 3.10 und 3.11 folgenden) detaillierteren Beschreibung der einzelnen Ablaufschritte sichtbar sowie bei der Untersuchung der unterstützenden Geschäftsanwendungsfälle. verschärft sich die Lage.

Leitfragen  Welche Personen bzw. Akteure sind in die Geschäftsanwendungsfälle involviert?  Welche Rolle spielen diese Personen?  Wie heißen diese Rollen?

Es ist an dieser Stelle nicht sinnvoll oder zwingend und wahrscheinlich Nicht nach Vollständigkeit auch kaum möglich, vollständig alle an einem Geschäftsanwendungs- streben fall beteiligten Akteure zu identifizieren. Daher begnügen wir uns mit 4 Minuten den wichtigsten. Wenn wir sieben oder mehr Akteure zu einem Geschäftsanwendungsfall gefunden haben oder schon mehrere Minuten am Suchen sind und keine weiteren Akteure mehr auftauchen, dann ist es genug und wir wenden uns dem nächsten Geschäftsanwendungsfall zu. Der Charme unserer hier beschriebenen Methodik, von außen nach in- Vorgehen: nen vorzugehen, d.h. ausgehend von aktiven Geschäftspartnern und Outside-In deren Kern-Geschäftsanwendungsfällen nach innen zu blicken zu den außen- und später schließlich auch zu den innenorientierten Geschäftsmitarbeitern, liegt in der Fokussierung auf die wesentlichen und wichtigen Sachverhalte. Sie führt uns zu den wichtigen Schnittstellen (außenorientierte Geschäftsmitarbeiter) und verhindert ein zu frühes und zu schnelles Vordringen in Details, die eher verwirren würden, solange der grundsätzliche Kontext noch unklar ist. Notiere die Ergebnisse als Geschäftsanwendungsfall-Kontext. Die Details zur Notation jeweils gefundenen Akteure notieren wir jeweils pro Geschäftsanwen- 165ff. u. 148ff. dungsfall in einem so genannten Kontextdiagramm. Dort zeichnen wir alle Beteiligten ein: außen- und innenorientierte Geschäftsmitarbeiter, aber ebenso auch aktive und passive Geschäftspartner. Die folgenden Abbildungen (Abb. 3.7-1 und folgende) zeigen einige Ergebnisse.

74

3.7 Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln Die in Geschäftsprozessmodellierungs- und Softwareprojekten beteiligten Menschen

Preisauskunft erteilen Interessent

Auskunftserteiler

Abb. 3.7-1: Geschäftsmitarbeiter im Kontext Preisauskunft erteilen

Kfz-Reservierung stornieren Mieter

Callcenter-Agent Schadenmeldung bearbeiten

Kfz nutzen lassen Fahrer

Kfz zurücknehmen Niederlassungsmitarbeiter

Abb. 3.7-2: Geschäftsmitarbeiter in den Kontexten Kfz-Reservierung stornieren, Schadenmeldung bearbeiten, Kfz nutzen lassen und Kfz zurücknehmen

Kfz-Einkäufer Kfz-Händler

Fuhrpark-Manager

Kfz beschaffen Franchise-Nehmer

Geschäftsführung

Kfz-Zulassung Kfz-Mechaniker

Jurist

Abb. 3.7-3: Geschäftsmitarbeiter im Kontext Kfz beschaffen Die in Geschäftsprozessmodellierung s- und Softwareprojekten beteiligten Menschen

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.7 Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln haben in der Handhabung sozialer und psychologischer Risiken häufig besondere Defizite.

Kfz probefahren lassen Kaufinteressent

Kfz verkaufen Kfz-Verkäufer Käufer

Abb. 3.7-4: Geschäftsmitarbeiter in den Kontexten Kfz probefahren und Kfz verkaufen

Ordne die gefundenen Geschäftsmitarbeiter einer Organisationseinheit zu. Die Organisationseinheiten wurden in Kapitel 3.2 identifiziert. Sollte keine der bekannten Organisationseinheiten passen, ist mit großer Wahrscheinlichkeit eine neue Organisationseinheit notwendig, d.h. gefunden worden.

haben in der Handhabung sozialer und psychologischer Risiken häufig besondere Defizite.

Mietstation 1

1 1

1..*

Stationsleitung Stationsmitarbeiter

Abb. 3.7-5: Beispiel Zuordnung Akteure – Organisationseinheiten

Neben der Zuordnung der Beteiligten zu Geschäftsanwendungsfällen Beziehungen zwsichen und Organisationseinheiten können auch Beziehungen zwischen den Akteuren Beteiligten dargestellt werden. Beziehungen bezüglich der Weisungs- Vgl. 155 befugnis oder Berichtswege werden zumeist auf der Ebene von Organisationseinheiten festgelegt, können aber theoretisch auch direkt zwischen einzelnen Akteuren definiert werden. Ebenso lassen sich auch Generalisierungs- und Spezialisierungsbeziehungen ausdrücken, wie dies in der folgenden Abb. 3.7-6 zu sehen ist. Kunde ist hier eine Abstraktion, ein abstrakter Beteiligter, von dem es drei unterschiedliche konkrete Ausprägungen gibt, den Mieter, den Fahrer und den Käufer.

75

76

3.7 Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln Sie akzeptieren zu wenig, dass es bei Widerständen, Ängsten und Konkurrenzkonflikten

Kunde

Mieter

Fahrer

Käufer

Abb. 3.7-6: Generalisierung bzw. Spezialisierung von Akteuren Sie akzeptieren zu wenig, dass es bei Widerständen, Ängsten und Konkurrenzkonfli kten

Getrennte Organisationsmodelle für Soll und Ist?

Unterscheide ggf. Soll- und Ist-Situation der Aufbauorganisation. Häufig soll im Rahmen einer Geschäftsprozessmodellierung auch die bestehende Aufbauorganisation kritisch hinterfragt werden, inwieweit sie für das betrachtete Geschäft noch angemessen ist. In diesem Fall kann es sinnvoll sein, die Ist- und mögliche Soll-Organisationsstruktur getrennt zu modellieren und auch die hier entwickelten Kontextdiagramme getrennt für Ist- und Soll-Situation anzufertigen, um Implikationen und Auswirkungen abzuleiten.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.8 Geschäftsprozesse definieren mehr um Gefühle, also sehr subjektive Situationen, geht.

3.8

77

Geschäftsprozesse definieren

Extrakt  Fasse alle thematisch zusammengehörenden Geschäftsanwendungsfälle zu Gruppen zusammen. Die Gruppen repräsentieren Geschäftsprozesse.  Gebe jeder Gruppe einen Namen.  Klassifiziere die Gruppen nach Kern-Prozessen und unterstützenden Prozessen.

Ein Geschäftsprozess besteht aus einer Menge fachlich zusammengehöriger Geschäftsanwendungsfälle. Ein Geschäftsprozess ist also das Warum erst Geschäftsanwendungsfälle und dann fachlich allgemeinere Element der Geschäftsprozessmodellierung und Geschäftsprozesse? so wäre es bezüglich der Vorgehensweise nahe liegend, zuerst die Geschäftsprozesse zu identifizieren und danach zu bestimmen, aus welchen Geschäftsanwendungsfällen sie bestehen. Wir gehen hier bewusst anders vor. In den vorigen Kapiteln haben wir die Geschäftsanwendungsfälle gesucht und nun fassen wir diese zu Geschäftsprozessen zusammen. Unserer Erfahrung nach vereinfacht diese Reihenfolge, bei der wir mit den konkreteren Elementen beginnen, die Geschäftsprozessmodellierung und führt zu weniger Problemen mit der Feingliedrigkeit und dem Abstraktionsniveau der Elemente. mehr um Gefühle, also sehr subjektive Situationen, geht.

Geschäftsanwendungsfälle gruppieren. Beginnend mit den Kernund fortgesetzt mit den unterstützenden Geschäftsanwendungsfällen werden thematisch zusammengehörende Geschäftsanwendungsfälle zusammengefasst. Hierzu ist es hilfreich, für jeden Geschäftsanwendungsfall eine Karte anzulegen und diese dann an einer Pinnwand zu gruppieren. Diese Gruppen nennen wir fortan Geschäftsprozesse. Wir haben hiermit die Geschäftsprozesse identifiziert. Leitfrage  Welche Geschäftsanwendungsfälle sind thematisch oder fachlich verwandt oder ähnlich?

Versuchen Sie möglichst wenig Gruppen zu bilden (aber in jedem Fall mehr als eine). Wenn alle Karten bzw. Geschäftsanwendungsfälle zugeordnet wurden, gehen Sie die Gruppen noch einmal durch und überprüfen, ob die Karten dort immer noch richtig eingeordnet sind oder vielleicht besser in eine andere Gruppe passen würden.

Geschäftsanwendungsfälle gruppieren = Geschäftsprozesse identifizieren

78

Kleingruppen ggf. auflösen

3.8 Geschäftsprozesse definieren Deren objektivste Messgröße ist vielleicht der persönliche Adrenalinpegel.

Wenn eine Gruppe nur aus einer einzelnen Karte besteht oder aus extrem viel weniger als alle anderen Gruppen, dann ist zu überlegen, ob diese Karte(n) halbwegs nachvollziehbar einer anderen Gruppe zugeordnet werden kann. Passt die einzelne Karte in alle anderen Gruppen gleichermaßen schlecht hinein, sollte die Kleingruppe bestehen bleiben. Gibt es eine Gruppe, in die die einzelne Karte zumindest deutlich besser passt als in alle anderen, sollte die Karte dieser Gruppe zugeordnet werden, da es die nachfolgende Arbeit vereinfacht. In unserem Fallbeispiel kann die Karte Preisauskunft erteilen der Gruppe Vermietung zugeordnet werden, da sich die Auskünfte auf Vermietungen beziehen.

Abb. 3.8-1: Ergebnis des Workshops Geschäftsprozesse identifizieren Deren objektivste Messgröße ist vielleicht der persönliche Adrenalinpegel.

Gruppen benennen. Danach gehen Sie die Gruppen nochmals der Reihe nach durch und versuchen der Gruppe einen Namen zu geben. Der Name sollte eine Zusammenfassung oder Abstraktion darstellen, die zu allen in der Gruppe enthaltenen Geschäftsanwendungsfällen passt. Verwenden Sie nach Möglichkeit nur ein einzelnes Substantiv als Gruppenname.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.8 Geschäftsprozesse definieren

79

Bei ansonsten erfolgreichem Risikomanagement

Beispielsweise kann die Gruppe mit den Geschäftsanwendungsfällen Prozessgruppen möglichst Kfz reservieren, Kfz vermieten, Kfz-Reservierung ändern und Kfz- mit einem einzelnen Substantiv benennen Reservierung stornieren den Namen Kfz-Vermietung tragen. Die Gruppe mit Kfz verkaufen, Kfz probefahren und Verkaufangebot erstellen kann beispielsweise Kfz-Verkauf heißen. Der Name darf große Ähnlichkeit mit dem wichtigsten Geschäftsanwendungsfall der Gruppe haben. Weitere Gruppen in unserem Fallbeispiel sind: Fuhrpark-Management, Tarifierung, Marketing, Kundenverwaltung und Rechnungswesen.

Bei ansonsten erfolgreichem Risikomanagement

Gruppen klassifizieren. So wie die Geschäftsanwendungsfälle unter- Kern-Prozesse und schieden wurden in Kern- und unterstützende Geschäftsanwendungsfäl- unterstützende Prozesse le, so werden jetzt die gebildeten Gruppen ebenfalls klassifiziert. Hierzu werden die Gruppen der Reihe nach betrachtet und für jede eine Entscheidung getroffen, ob die Gruppe einen Kern-Geschäftsprozess oder einen unterstützenden Geschäftsprozess repräsentiert. Leitfragen/Heuristik13 zur Klassifizierung von Geschäftsprozessen  Enthält die Gruppe ausschließlich unterstützende Geschäftsanwendungsfälle? Dann repräsentiert die Gruppe einen unterstützenden Prozess.  Enthält die Gruppe ausschließlich Kern-Geschäftsanwendungsfälle? Dann repräsentiert die Gruppe einen Kern-Prozess.  Enthält die Gruppe überwiegend Kern-Geschäftsanwendungsfälle und sind diese unmittelbar den Geschäftszielen und dem Geschäftszweck zuzuordnen? Dann repräsentiert die Gruppe einen Kern-Prozess.

Bei der Klassifizierung wird neben den enthaltenen Geschäftsanwendungsfällen auch der Name der Gruppe beurteilt. In vielen Fällen kann die Entscheidung relativ schnell und eindeutig getroffen werden. Die Gruppen Kfz-Vermietung und Kfz-Verkauf sind beispielsweise unstrittig Kern-Prozesse, da sie nur aus Kern-Geschäftsanwendungsfällen bestehen enthalten. Die Gruppen Fuhrpark-Management und Tarifierung sind unterstützende Prozesse, da sie keine Kern-Geschäftsanwendungsfälle enthalten. Die Prozessgruppe Rechungswesen besteht vorwiegend aus unterstützenden Geschäftsanwendungsfällen, beispielsweise Zahlungseingang buchen, Kreditorenrechnung bezahlen. Jedoch ist zum Beispiel Bußgeldbescheid bearbeiten ein Kern-Geschäftsanwendungsfall. Hier hilft uns die oben stehende Leitfrage, die für Kern-Prozesse eine unmittelba13

Eine Heuristik ist eine wahrscheinlichkeitsbehaftete Regel, also eine sog. DaumenRegel, die nicht immer, aber in vielen oder den meisten Fällen zutrifft.

80

3.8 Geschäftsprozesse definieren bleiben die sozialen Risiken dann hartnäckig übrig.

Ziele und Zweck vgl. Kapitel 3.3 46

re Unterstützung der Geschäftsziele fordert. Ziele und Zweck des Unternehmens bzw. der Geschäftsprozessmodellierung wurden weiter vorne behandelt. Der Zweck von Flitz-Auto ist u.a. das Geldverdienen mit der Vermietung von Kraftfahrzeugen. Mit dem Rechungswesen wird zwar der Geldfluss, d.h. verdientes Geld, verwaltet, aber selbst kein (weiteres) Geld erwirtschaftet. Der Bearbeitungsaufwand für Bußgeldbescheide wird den Kunden zwar in Rechung gestellt, aber der Geschäftszweck der Kfz-Vermietung ist es nicht, damit Geld zu verdienen. Die Prozessgruppe Rechnungswesen wird daher jetzt als unterstützender Prozess betrachtet.

Abb. 3.8-2: Geschäftsanwendungsfälle der Geschäftsprozesse Kfz-Vermietung und Rechnungswesen bleiben die sozialen Risiken dann hartnäckig übrig.

Jetzt sind alle Prozessgruppen eindeutig als Kern oder unterstützend klassifiziert worden. Dennoch enthalten Kernprozesse möglicherweise auch unterstützende Geschäftsanwendungsfälle und unterstützende Geschäftsprozesse möglicherweise Kern-Geschäftsanwendungsfälle. Wir belassen die Klassifizierung der Geschäftsanwendungsfälle unabhängig von der Klassifizierung der Geschäftsprozesse. Workshop

Geschäftsprozesse identifizieren

Ziel des Workshops

Geschäftsanwendungsfälle zu Geschäftsprozessen zusammenfassen

Teilnehmer

 Vertretungen der 2 - 5 wichtigsten Abteilungen  Moderationsteam (Moderator, Protokollant, Analytiker)

Rahmenbedingungen

Konferenzraum mit Flipchart oder Tafel

Vorbereitung

 Alle bisher identifizierten Geschäftsanwendungsfälle werden auf Karten geschrieben. Für Kern-Geschäftsanwendungsfälle möglichst rote, für unterstützende Geschäftsanwendungsfälle gelbe Karten verwenden.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.8 Geschäftsprozesse definieren Ängste und Widerstände sind im Rahmen von Geschäftsprozessmodellierungs- und

Agenda

1. Abstimmung der Ziele, der Agenda, der erwarteten Ergebnisse und der geplanten Dauer (2 - 5 Minuten) 2. Die roten Karten (Kern-Geschäftsanwendungsfälle) werden der Reihe nach an die Pinnwand geheftet und dabei nach kurzer Diskussion gruppiert. 3. Anschließend werden die gelben Karten (unterstützende Geschäftsanwendungsfälle) an die Pinnwand geheftet und dabei nach kurzer Diskussion gruppiert. 4. Gemeinsame Überprüfung der Karten auf richtige Gruppenzugehörigkeit 5. Benennung der Gruppen und Festlegung, ob Kernoder unterstützender Geschäftsprozess

Nachbereitung

Dokumentation des Ergebnisses

81

Abb. 3.8-3: Geschäftsprozesse identifizieren durch Gruppierung der Geschäftsanwendungsfälle

Die Geschäftsprozesse und die in ihnen enthaltenen Geschäftsanwendungsfälle können als Funktionsbaum, d.h. in einer baumartigen Glie- Funktionsbaum 181 derungsstruktur, dargestellt werden, wie dies in Abb. 3.8-4 und Abb. 3.8-5 zu sehen ist. Ängste und Widerstände sind im Rahmen von Geschäftsprozessmodellierungs- und

– Geschäftsprozesse – Kern-Geschäftsprozesse – Kfz-Vermietung

Geschäftsprozess

Kfz reservieren

enthaltene Geschäftsanwendungsfälle

Kfz-Reservierung stornieren Kfz-Reservierung ändern Kfz vermieten Preisauskunft für KfzVermietung erteilen – Marketing Anzeigen schalten Infomaterial erstellen Abb. 3.8-4: Kern-Geschäftsanwendungsfälle und -prozesse

Die einzelnen Schritte in den Geschäftsanwendungsfällen und die be- UML: Geschäftsprozesse teiligten Geschäftsmitarbeiter (interne Beteiligte) werden noch nicht 163 betrachtet, sondern später in den Kapiteln 3.9 Geschäftsprozesse doku-

82

3.8 Geschäftsprozesse definieren Softwareentwicklungsprojekten weitgehend normal.

mentieren (84) und 3.10 Geschäftsanwendungsfälle essenziell beschreiben (87) erläutert. ...

... – Unterstützende Geschäftsprozesse – Kundenverwaltung – Fuhrpark-Management Neuen Kunden registrieren Kfz reparieren Kfz überführen

Kundendaten ändern Kundendaten löschen

Schaden regulieren Kfz instandhalten

– Tarifierung

Kfz beschaffen Kfz entsorgen

Tarif einrichten Tarif schließen

– Rechnungswesen

Tarif ändern

Kfz-Vermietung abrechnen Rechnungsreklamation bearbeiten Bußgeldbescheid bearbeiten Zahlungseingänge buchen Kreditorenrechnungen bezahlen ...

– Kfz-Verkauf Verkaufsangebot erstellen Kfz probefahren Kfz verkaufen

Fortsetzung rechts

Abb. 3.8-5: Unterstützende Geschäftsanwendungsfälle und -prozesse Softwareentwicklungsprojekten weitgehend normal.

Sofern die an einem Geschäftsprozess Beteiligten dargestellt werden sollen, kann dies wie in Abb. 3.8-6 notiert werden. Ebenso können die in Abb. 3.8-4 bzw. Abb. 3.8-5 notierten Sachverhalte alternativ auch wie in Abb. 3.8-7 dargestellt werden. Herleitung der Geschäftspartner eines Geschäftsprozesses

Die an einem Geschäftsprozess beteiligten Akteure sind die Summe der Akteure, die an den Geschäftsanwendungsfällen des Geschäftsprozesses beteiligt sind, und somit bekannt und herleitbar. Im Kapitel 3.7 Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln (72) wurden Akteure den Geschäftsanwendungsfällen zugeordnet und ein Akteurmodell erstellt.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.8 Geschäftsprozesse definieren Mit neuer Software wird die Arbeit von Menschen verändert.

Callcenter

Stationsmitarbeiter

Kunde

Kundenverwaltung

Abb. 3.8-6: Der Geschäftsprozess Kundenverwaltung mit seinen Geschäftspartnern und -mitarbeitern

In Abb. 3.8-6 ist der Geschäftsprozess Kundenverwaltung zu sehen, und welche Akteure an ihm beteiligt sind. Die Akteure sind dabei herleitbar und ergeben sich daraus, welche Akteure in den Geschäftsanwendungsfällen des Geschäftsprozesses Kundenverwaltung enthalten sind. Die Abb. 3.8-7 zeigt den entsprechenden Zusammenhang am Beispiel des Geschäftsprozesses Marketing, d.h. welche Geschäftsanwendungsfälle im Geschäftsprozess Marketing enthalten sind. Mit neuer Software wird die Arbeit von Menschen verändert.

Marketing

«include»

Anzeigen schalten

«include»

Infomaterial erstellen

Abb. 3.8-7: Alternative Notation für die in einem Geschäftsprozess enthaltenen Geschäftsanwendungsfälle

83

84

3.9 Geschäftsprozesse dokumentieren Vielleicht sinkt durch die Automatisierung von Abläufen die erforderliche Qualifikation

3.9

Geschäftsprozesse dokumentieren

Extrakt  Beschreibe die wichtigsten Eigenschaften eines jeden Geschäftsprozesses in natürlicher Sprache: Kurzbeschreibung, Maßnahmen, Prozessverantwortliche und -beteiligte.  Stelle die Abläufe eines jeden Geschäftsprozesses mit Hilfe eines Diagramms grafisch dar, soweit dies zweckmäßig ist.

Nachdem die Geschäftsprozesse nun durch Gruppierung der Geschäftsanwendungsfälle identifiziert wurden, werden sie genauer untersucht und beschrieben. Zum einen versuchen wir, die Abläufe in einem Geschäftsprozess mit Hilfe von Ablaufdiagrammen grafisch darzustellen, zum anderen wichtige Eigenschaften in natürlicher Sprache zu beschreiben. Vielleicht sinkt durch die Automatisierung von Abläufen die erforderliche Qualifikation

Namensgebung 78

Vgl. 81 Geschäftsmitarbeiter, vgl. 72

Natürlichsprachliche Beschreibung. Die Beschreibung eines Geschäftsprozesses sollte aus folgenden Elementen bestehen:  Name Hierzu sollte möglichst ein Substantiv verwendet werden, mehr zur Namensgebung im vorigen Abschnitt.  Prozesstyp Der Prozesstyp ist entweder Kern-Geschäftsprozess oder unterstützender Geschäftsprozess.  Kurzbeschreibung In 1 - 10 Sätzen sollte kurz beschrieben werden, worum es in diesem Geschäftsprozess geht. Die Kurzbeschreibung sollte so abstrakt und kurz wie möglich und so detailliert und konkret wie nötig sein, so dass eine Unterscheidung von allen anderen Geschäftsprozessen möglich ist. Alle Sachverhalte in einer Kurzbeschreibung sollten möglichst auf dem gleichen Abstraktionsniveau sein.  Auflistung der enthaltenen Geschäftsanwendungsfälle Siehe voriger Abschnitt (Abb. 3.8-4, Abb. 3.8-5)  Geschäftsprozessverantwortlicher Welcher Geschäftsmitarbeiter ist für den erfolgreichen, effizienten und effektiven Betrieb des Geschäftsprozesses verantwortlich? Prozessverantwortlich ist immer genau eine Person. Wenn mehrere Personen verantwortlich sind, dann sind Verantwortungsbereiche abzugrenzen, so dass für jeweils einen Sachverhalt immer nur eine Person verantwortlich ist. Im Übrigen ist vor allem die Diskussion

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.9 Geschäftsprozesse dokumentieren und damit die Bezahlung der Fachabteilungsmitarbeiter.

85

darüber sehr fruchtbar, wer für den Prozess verantwortlich ist, da hierbei gewöhnlich eine Reihe von Details und neuen Erkenntnissen auftauchen. Auch ISO 900014 fordert Geschäftsprozessverantwortliche.  Prozessbeteiligte Welche Geschäftsmitarbeiter und Geschäftspartner sind insgesamt an dem Geschäftsprozess beteiligt? Die Verantwortlichen und Prozessbeteiligten sind direkt ableitbar aus dem Akteurmodell (vgl. 3.7 Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln 72). Die folgende Abbildung zeigt die grundsätzliche Struktur einer Geschäftsprozessbeschreibung: und damit die Bezahlung der Fachabteilungsmitarbeiter.

Beschreibung Kern-Geschäftsprozess Name

Kfz-Vermietung

Kurzbeschreibung

Dieser Geschäftsprozess beschreibt alle Sachverhalte, die in direktem Zusammenhang mit der Vermietung von Kfz stehen: von den ersten Auskünften an den Kunden, über die Reservierung und Nutzung des Kfz bis hin zur Rückgabe durch den Fahrer.

Enthaltene Geschäftsanwendungsfälle

    

Verantwortlich

Leitung Kfz-Vermietung

Beteiligt

Geschäftspartner: Mieter, Fahrer Geschäftsmitarbeiter: Callcenter-Agent, Stationsmitarbeiter

Kfz reservieren Kfz nutzen lassen Kfz-Reservierung ändern Kfz-Reservierung stornieren Auskunft zu Vermietungskonditionen erteilen

Abb. 3.9-1: Geschäftsprozess Kfz-Vermietung

Ablaufdiagramm entwickeln. Es mag an dieser Stelle etwas irritieren, dass Geschäftsprozesse lediglich eine lose Sammlung von Geschäfts- Geschäftsprozess = anwendungsfällen darstellen, wo der Begriff Geschäftsprozess zumin- lose Gruppierung von Geschäftsanwendungsfällen dest suggeriert, dass es sich dabei um einen Prozess, also einen Ablauf, handelt. In vielen Fällen ist dies auch zutreffend und es wäre beispielsweise möglich, den Ablauf eines Geschäftsprozesses mit einem einzigen Ablaufdiagramm darzustellen. Es gibt jedoch eine geringe, aber nicht zu vernachlässigende Anzahl von Geschäftsprozessen, in denen bestimmte Abläufe, d.h. Geschäftsanwendungsfälle, mehr oder weniger losgelöst von den übrigen sind. Beispielsweise dadurch, dass sie zwar fachlich und thematisch in diesen Prozess gehören, sie aber in keinem 14

ISO 9000 ist eine Norm für Qualitätsmanagement und Qualitätssicherung im Produktions- und Servicebereich mit verschiedenen Ausprägungen, z.B. für Softwareprozesse.

86

3.9 Geschäftsprozesse dokumentieren Oder sie steigt und überfordert die Mitarbeiter.

bestimmten zeitlichen Bezug zu den übrigen Geschäftsanwendungsfällen stehen. Erkenntnisgewinn beim Dokumentieren

Zusammengefasst bedeutet dies, wir bemühen uns darum, einen Geschäftsprozess als einen einzelnen geschlossenen Ablauf zu repräsentieren, erzwingen dies aber nicht dogmatisch, wenn es nicht passt. Ebenso kann das Ablaufdiagramm problemlos weggelassen werden, wenn der Ablauf trivial ist, beispielsweise eine einfache Sequenz. Insofern ist das Ablaufdiagramm optional. Die beim Dokumentieren der Geschäftsprozesse gewonnenen Erkenntnisse (bspw. über weitere Geschäftsanwendungsfälle) werden selbstverständlich berücksichtigt (z.B. Kfz zurücknehmen). Oder sie steigt und überfordert die Mitarbeiter.

Die folgende Abbildung zeigt das Ablaufdiagramm zum Geschäftsprozess Kfz-Vermietung. Kunde möchte Kfz reservieren

KfzReservierung ändern Nutzungsbeginn abwarten

Kfz reservieren [Nutzung beginnen]

[ändern]

[stornieren] KfzReservierung stornieren

Kfz vermieten Schadenmeldung bearbeiten Kfz nutzen

Reservierung wurde storniert

Kfz-Nutzung wg. Unfall abgebrochen

[Schaden melden]

[Nutzung beenden] Kfz zurücknehmen

Kfz wurde zurückgenommen

Abb. 3.9-2: Ablaufdiagramm Geschäftsprozess Kfz-Vermietung

Zieldefinitionen für Geschäftsprozesse? Es wäre denkbar, mit der Dokumentation eines Geschäftsprozesses auch zu beschreiben, welche Ziele er unterstützt. Wir verzichten hier auf die Verbindung der Geschäftsprozesse mit den definierten Zielen für die Geschäftsprozessmodellierung, da Geschäftsprozesse hier nur als Gruppierung von Geschäftsanwendungsfällen gesehen werden. Nicht alle Geschäftsanwendungsfälle eines Geschäftsprozesses müssen die gleichen Ziele unterstützen. Die Zuordnung von Zielen geschieht daher bei der essenziellen Beschreibung der Geschäftsanwendungsfälle (vgl. 3.10 87, bspw. Abb. 3.10-191).

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.10 Geschäftsanwendungsfälle essenziell beschreiben Vielleicht werden Arbeitsplätze wegrationalisiert.

3.10 Geschäftsanwendungsfälle essenziell beschreiben Extrakt  Beschreibe jeden Geschäftsanwendungsfall kurz mit 1 - 2 Sätzen in natürlicher Sprache.  Definiere Anfang und Ende der Geschäftsanwendungsfälle mit Hilfe von Auslösern und Ergebnissen.  Definiere zu jedem Geschäftsanwendungsfall die eingehenden Daten.  Benenne zu jedem Geschäftsanwendungsfall die beteiligten Akteure.  Beschreibe stichwortartig den essenziellen Ablauf eines jeden Geschäftsanwendungsfalles.  Priorisiere die Geschäftsanwendungsfälle.

Nachdem die Geschäftsanwendungsfälle identifiziert und zu Geschäftsprozessen zusammengefasst wurden, werden sie nun weiter untersucht und ihre Beschreibung detailliert. Vielleicht werden Arbeitsplätze wegrationalisiert.

Definiere bzw. überprüfe Anfang und Ende der Geschäftsanwendungsfälle mit Hilfe von Auslösern und Ergebnissen. Auslöser und Ergebnis wurden bereits schon in den vorigen Kapiteln 3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren (56) und 3.6 Weitere unterstützende Geschäftsanwendungsfälle identifizieren (66) beschrieben und werden nun noch einmal überprüft. Die klare Benennung, wo ein Anwendungsfall15 anfängt und wo er aufhört, ist von großer Bedeutung. Dazu müssen alle beteiligten Modellierer einheitliche und möglichst objektive Kriterien zur Festlegung von Anfang und Ende haben, sonst würden verschiedene Personen für den gleichen geschäftlichen Sachverhalt möglicherweise eine unterschiedliche Anzahl von Anwendungsfällen identifizieren, Sachverhalte mehrfach beschreiben, wichtige Teile vergessen oder einfach nur die übrigen Modellierer verwirren. Leitfragen  Was ist der (bzw. sind die) geschäftlich relevante(n) Auslöser?  Welche geschäftlich wertvollen Ergebnisse sind entstanden? 15

Wenn aus dem Kontext heraus deutlich ist, welche Art von Anwendungsfall gemeint ist (z.B. Geschäfts- oder Systemanwendungsfall), verwenden wir der Einfachheit halber häufig den Allgemeinbegriff Anwendungsfall.

87

88

3.10 Geschäftsanwendungsfälle essenziell beschreiben Ängste und Widerstände entstehen hier aufgrund sachlicher Umstände.

 Wird ein aus Sicht der beteiligten Akteure (Geschäftspartner und Geschäftsmitarbeiter) zeitlich und sachlogisch zusammenhängender Sachverhalt beschrieben?  Beschreibt die Summe aller Teilabläufe (Anwendungsfälle), die jeweils durch die Auslöser und Ergebnisse begrenzt sind, lückenlos den gesamten Geschäftsprozess? Welche Teile fehlen noch und in welchem Anwendungsfall sind sie zu beschreiben? Ereignisse, Nachrichten, Fristen

Auslöser. Als geschäftlich relevanter Auslöser werden zum einen alle Ereignisse bezeichnet, die von außen auf das betrachtete geschäftliche System zukommen. Beispielsweise eine Nachricht von einem Geschäftspartner. Zusätzlich werden auch alle Ereignisse betrachtet, die zwar nicht von einem Geschäftspartner kommen, aber stellvertretend oder vorwegnehmend für diesen geschehen, d.h. für den Geschäftspartner einen geschäftlich relevanten Sachverhalt darstellen. Häufig sind dies zeitliche Auslöser, beispielsweise der Beginn oder Ablauf einer Frist. Ängste und Widerstände entstehen hier aufgrund s achlicher Umstände.

Welche Ereignisse sind von geschäftlichem Wert?

Ergebnisse. Ähnlich werden die Ergebnisse bewertet. Nicht jedes Zwischen- oder Teilergebnis wird hier als geschäftlich relevant angesehen, sondern nur solche, die den Geschäftspartnern explizit zugehen und für sie einen geschäftlichen Wert darstellen. Entstehen verschiedene Detailergebnisse in einem gemeinsamen zeitlichen Kontext und sind sie inhaltlich zusammenhängend oder abhängig, werden sie zu einem Ergebnis zusammengefasst. Erhält ein Kunde beispielsweise eine Reservierungsbestätigung, werden nicht die einzelnen Attribute wie reserviertes Kfz, Zeitraum, Reservierungsnummer etc. jeweils als Ergebnis angesehen, sondern sie werden zusammengefasst als ein Ergebnis betrachtet.

Zwischenergebnisse

Wenn ein Kunde in einem Callcenter anruft und dabei nur seine Kundennummer angibt und der Callcenter-Agent aufgrund der Kundennummer den Namen des Kunden findet, ist dies wahrscheinlich nur ein Zwischenergebnis (der Kunde ist bekannt), weil es geschäftlich kaum relevant ist. Der geschäftliche Zweck des Callcenters besteht darin, dem Kunden eine Leistung zu erbringen, beispielsweise etwas zu bestellen oder zu reservieren, aber nicht, nur das pure Vorhandensein einer Kundennummer festzustellen. Die Beurteilung, ob ein Ergebnis von geschäftlichem Wert ist, ist also immer an den geschäftlichen Zweck geknüpft und in diesem Zusammenhang meistens eindeutig zu beantworten.

Systemanwendungsfälle 133

Keine zeitliche Kohärenz. Im Gegensatz zu den später noch erläuterten Systemanwendungsfällen müssen Geschäftsanwendungsfälle keine zeitliche Kohärenz aufweisen, d.h., sie dürfen Abläufe beschreiben, die zeitlich unterbrochen oder unterbrechbar sind. Wird beispielsweise ein

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.10 Geschäftsanwendungsfälle essenziell beschreiben Probleme entstehen auch auf Basis gestörter Beziehungen der Menschen untereinander.

Kfz von einem Kunden abgeholt, genutzt und irgendwann wieder zurückgegeben, so wird dies als ein Geschäftsanwendungsfall angesehen. Maßgeblich ist, wann der Geschäftspartner das geschäftlich wertvolle bzw. relevante Ergebnis erhält bzw. abgeschlossen hat. Definiere die eingehenden Daten. Jeder Geschäftsanwendungsfall verarbeitet bestimmte Informationen, d.h. Daten. Die Ergebnisse eines Anwendungsfalles und somit die ausgehenden Daten haben wir bereits definiert. Zum besseren Verständnis der Geschäftsanwendungsfälle beschreiben wir zusätzlich auch die jeweils eingehenden Daten. Dabei ist eine abstrakte und zusammenfassende Beschreibung ausreichend. Statt Kundennummer, Vorname, Nachname etc. schreiben wir einfach Kundendaten (vgl. Abb. 3.10-2). Suchen Sie stets eine möglichst abstrakte Beschreibung, die gerade noch aussagekräftig und verständlich genug ist. Probleme entstehen auch auf Basis gestörter Beziehungen der Menschen unterei nander.

Benenne die beteiligten Akteure eines jeden Geschäftsanwendungsfalles. Aus den Arbeiten und Ergebnissen der vorigen Kapitel sind bereits die beteiligten aktiven und passiven Geschäftspartner sowie innenund außenorientierten Geschäftsmitarbeiter bekannt (vgl. Kapitel 3.7 72 und Abb. 3.5-5 65). Diese können in der natürlichsprachlichen Beschreibungsstruktur eines Geschäftsanwendungsfalles ebenfalls angegeben werden (vgl. Abb. 3.10-2). In unserem Beispiel Kfz reservieren sind dies Interessent und Mieter. Essenzieller Ablauf. Der Ablauf eines Geschäftsanwendungsfalles Die richtige Abstraktion besitzt gewöhnlich bei detaillierter Betrachtung eine hohe Komplexität, finden, … die die Gefahr birgt, sich bei seiner Beschreibung zu verzetteln. Andererseits bergen einfachere Beschreibungen die Gefahr, zwar kurz und knapp, aber inhaltlich sehr einseitig zu sein, d.h. möglicherweise die „falschen“ Sachverhalte zu betonen. Unter einer essenziellen Beschreibung verstehen wir eine ganz be- …aber wie? stimmte Art der Abstraktion, die dazu führen soll, vergleichbarere und einheitlichere Überblicksbeschreibungen von Geschäftsanwendungsfällen zu erhalten. Die Kriterien für eine essenzielle Beschreibung ergeben sich aus den folgenden Heuristiken. Leitfragen/Heuristiken  Beschreibe so abstrakt wie möglich und nur so konkret wie nötig.  Konzentriere dich auf den unmittelbaren geschäftlichen Zweck, d.h., vermeide die Beschreibung konkreter technologischer Rahmenbedingungen oder Lösungen.

89

90

3.10 Geschäftsanwendungsfälle essenziell beschreiben Mitarbeiter misstrauen bestimmten Kollegen, Vorgesetzten, Abteilungen etc.,

 Unterscheide die Sachverhalte, die in Zukunft mit hoher Wahrscheinlichkeit stabil bleiben werden, von denen, die sich in absehbarer Zeit ändern könnten und beschreibe möglichst nur die stabilen Sachverhalte. Was ist eine essenzielle Beschreibung?

Eine essenzielle Beschreibung ist soweit abstrahiert, dass der geschäftliche Ablauf unabhängig von konkreten Implementierungsformen ist. Die Beschreibung des Anwendungsfalles „Geld vom Konto abheben“ wäre beispielsweise so allgemein, das damit das Abheben am Geldautomaten, am Bankschalter oder das Aufladen einer Geldkarte gemeint sein kann. Die Beschreibung des Anwendungsfalles Kfz reservieren wäre so allgemein, dass es die Reservierung übers Internet und über ein Callcenter beinhaltet. Mitarbeiter misstrauen bestimmten Kollegen, Vorgesetzten, Abteilungen etc.,

Eine essenzielle Beschreibung ist eine sehr abstrakte und komprimierte Form, deren Zweck vor allem darin besteht, einen Überblick zu geben. Abstraktion heißt, einen komplexen Sachverhalt unter bestimmten Gesichtspunkten zusammenzufassen. In Abb. 3.10-2 ist die essenzielle Beschreibung des Ablaufes von Kfz reservieren zu sehen. In einem späteren Schritt (3.11 Geschäftsanwendungsfall-Abläufe modellieren 96) wird dieser Ablauf mit Hilfe eines Ablaufdiagramms detailliert und visualisiert. Einfluss der Geschäftsanwendungsfälle auf die Ziele beschreiben

Priorisierung der Geschäftsanwendungsfälle. Wir betreiben die Geschäftsprozessmodellierung nicht zum Selbstzweck, sondern haben in 3.3 Ziele festlegen (46) spezielle Ziele definiert. Zum einen können wir nun, wenn die Geschäftsanwendungsfälle vorliegen, zu jedem Ziel eine Liste der Geschäftsanwendungsfälle aufstellen, die die Zielerreichung nennenswert beeinflussen (positiv oder negativ). Zum anderen bewerten wir nun alle Geschäftsanwendungsfälle hinsichtlich dieser Ziele: In welchem Maße trägt dieser Geschäftsanwendungsfall zur Erreichung der Geschäftsprozessziele bei? Wir bewerten die Zielerreichungs-relevanz eines jeden Geschäftsanwendungsfalles. Die in Abb. 3.3-2 (49) offen gebliebene Liste der Anwendungsfälle könnte nun also wie in Abb. 3.10-1 aussehen.

Bewertungsskala 1 – 10

Die Priorität eines Geschäftsanwendungsfalles kann entweder in vereinfachter Weise aufgrund einer subjektiven Einschätzung beispielswiese auf einer Skala von 1 - 10 vorgenommen werden (0=bedeutungslos, 10=absolut wichtig) oder systematisch zu den Zieldefinitionen in Relation gesetzt werden.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.10 Geschäftsanwendungsfälle essenziell beschreiben weil sie in der Vergangenheit von ihnen geschädigt, übergangen,

Ziel: Kundenkontaktdauer bei Kfz-Vermietung reduzieren Potenzielle beeinflussende Anwendungsfälle: Anwendungsfall

Einfluss

Erläuterung

Kfz reservieren

3,0 (viel)

vereinfachen und beschleunigen

Kfz nutzen lassen

1,0 (wenig)

vereinfachen und beschleunigen

Kfz-Reservierung ändern

2,0 (mittel)

vereinfachen und beschleunigen

Kfz-Reservierung stornieren

0,0 (kein)

Auskunft zu Vermietkonditionen erteilen

-1,0 (negativ)

hier darf nicht an Beratung gespart werden

Neuen Kunden registrieren

3,0 (viel)

vereinfachen und beschleunigen

Rechnungsreklamation bearbeiten

2,0 (mittel)

nur relevant, wenn an Station reklamiert wird - Rechnung übersichtlich und verständlich gestalten - Rechnungsänderung an Station vereinfachen

Abb. 3.10-1: Einfluss von Anwendungsfällen auf das Ziel Kundenkontaktdauer bei Kfz-Vermietung reduzieren weil sie in der Vergangenheit von ihnen geschädigt, übergangen,

Die Bewertung relativ zu den Zieldefinitionen ist deutlich aufwändiger und wird gewöhnlich nur betrieben, wenn eine systematische Zielverfolgung ein Ziel der Geschäftsprozessmodellierung ist (vgl. 3.3 Ziele festlegen 46). Hierbei wird dann folgendermaßen vorgegangen:  Jedes Ziel hat ein Gewicht zwischen 0,0 und 1,0 erhalten.  Für jeden Anwendungsfall wird der Einfluss auf jeweils ein Ziel auf einer Skala von -1,0 bis +5,0 bewertet (Einfluss: -1,0 = negativ; 0,0 = kein; 1,0 = wenig; 2,0 = mittel; 3,0 = viel; 4,0 = sehr viel; 5,0 = absolut).  Für jeden Anwendungsfall kann jetzt durch Multiplikation der gewichtete Einfluss auf ein Ziel berechnet werden: * = Gewichteter Einfluss.  Um die Bedeutung eines Anwendungsfalles insgesamt zu berechnen, wird die Summe aller gewichteten Einflüsse pro Anwendungsfall gebildet.

91

92

3.10 Geschäftsanwendungsfälle essenziell beschreiben gedemütigt, betrogen oder getäuscht wurden.

Beschreibung Geschäftsanwendungsfall Name

Kfz reservieren

Kurzbeschreibung

Für einen Mieter wird ein Kfz reserviert.

Aktive Geschäftspartner

 Interessent, Mieter (Interessent wird durch diesen Anwendungsfall zum Mieter)

Passive Geschäftspartner

 keine

Innenorientierte Geschäftsmitarbeiter

 keine

Außenorientierte Geschäftsmitarbeiter

 Callcenter-Agent

Auslöser, ggf. Motivation

 Mieter teilt den Wunsch mit, ein Kfz zu reservieren.

Ergebnis(se)

 Reservierungsbestätigung

Eingehende Daten

 Reservierungswunsch, Kundendaten

Vorbedingungen

 keine

Nachbedingungen

 Für den Mieter wurde ein Kfz eines bestimmten Kfz-Typs reserviert (es wurde kein konkretes Kfz, sondern nur mengenmäßig ein Fahrzeug eines Kfz-Typs reserviert).

Essenzieller Ablauf

    

Reservierungswunsch aufnehmen Kfz-Verfügbarkeit prüfen Mieterdaten aufnehmen Kfz-Typ reservieren Reservierung bestätigen

Unterstützte Ziele  Kundenkontaktdauer bei KfzVermietung reduzieren  Reklamationen reduzieren  Kundentreue erhöhen Priorität

Zielgewicht

Einfluss

Gew. Einfluss

0,7

2,0

1,4

0,7 0,4

1,0 2,0

0,7 0,8 2,9

Stabilität

hoch

Offene Punkte

keine

Abb. 3.10-2: Essenzielle Beschreibung des Geschäftsanwendungsfalles Kfz reservieren gedemütigt, betrogen oder getäuscht wurden.

Bei vereinfachter, nicht zielgetriebener Priorisierung kann der Bereich unterstützte Ziele durch Folgendes ersetzt werden: Essenzieller Ablauf

…

Priorität

4,0

Stabilität

…

Abb. 3.10-3: Essenzielle Beschreibung der Priorität bei vereinfachter Priorisierung

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.10 Geschäftsanwendungsfälle essenziell beschreiben Alte Rechnungen werden beglichen. Heimgezahlt.

Erläuterungen zur Geschäftsanwendungsfall-Beschreibung:  Kurzbeschreibung Halten Sie die Kurzbeschreibung wirklich kurz, aber schreiben Sie so viel, dass der Anwendungsfall nicht verwechselt werden kann. Vermeiden Sie die Aufzählung und Beschreibung von Sachverhalten, die auch aus den übrigen Punkten der Beschreibung (Ergebnisse, essenzieller Ablauf etc.) hervorgehen. Alte Rechnung en werden beglichen. Heimgezahlt.

 Akteure (aktive und passive Geschäftspartner, außen- und innenorientierte Geschäftsmitarbeiter) In dem obigen Beispiel tritt der Sonderfall auf, dass der Akteur im Laufe des Anwendungsfalles möglicherweise seine Rolle ändert. Zu Beginn ist er vielleicht nur ein Interessent, durch die Reservierung wird er dann zum Mieter. Für diesen Fall schlagen wir vor, beide Rollen aufzuführen und einen kleinen Erläuterungstext anzufügen. Ansonsten steht in der Rubrik Akteure aber nur eine einfache Aufzählung der Rollennamen. Die Akteure sind ableitbar aus dem Akteurmodell (vgl. 3.7  72).  Auslöser Vermeiden Sie beim Auslöser die Benennung von Hilfsmitteln (also nicht: „Mieter ruft an“ (Hilfsmittel Telefon) – außer wenn genau diese Rahmenbedingungen von besonderer Bedeutung sind), sondern konzentrieren Sie sich darauf, was das Unternehmen (Modellierungsfokus) von der Motivation des auslösenden Akteurs erfährt (also: Warum ruft der Mieter an? „Der Mieter möchte ein Kfz reservieren“ oder „Der Mieter teilt den Wunsch mit, ein Kfz zu reservieren“).  Ergebnisse Hier steht nur eine einfache Auflistung der Ergebnisse, die im Verlauf des Anwendungsfalles an die Akteure geliefert werden (ausgehende Objekte und Informationen).  Eingehende Daten Welche Daten, Informationen, Objekte werden im Verlauf des Anwendungsfalles von den Akteuren geliefert?  Vorbedingungen Vorbedingungen beschreiben den Zustand innerhalb des Unternehmens (Modellierungsfokus) vor dem Start des Anwendungsfalles. Die Vor- und Nachbedingungen sind hilfreich, aber weniger wichtig als Auslöser und Ergebnisse und können im Zweifelsfall weggelassen werden.

93

94

3.10 Geschäftsanwendungsfälle essenziell beschreiben Es wird nicht offen gesprochen.

 Nachbedingungen Nachbedingungen beschreiben den Zustand innerhalb des Unternehmens (Modellierungsfokus) nach Beendigung des Anwendungsfalles. Es wird nicht offen gesprochen.

 Essenzieller Ablauf Der Ablauf sollte nur stichwortartig beschrieben werden. Es wird nur der Standard- bzw. Gutfall16 berücksichtigt. Welche sind die typischen Schritte, die in dem Anwendungsfall im Gutfall durchlaufen werden? Die Leitlinie „Beschreibe so abstrakt wie möglich und nur so konkret wie nötig“ sollte hier strikt beachtet werden. Die Reihenfolge der Schritte ist nachrangig und darf im Zweifelfall vernachlässigt werden. Soweit Sie können, fassen Sie mehrere aufeinander folgende Schritte zu einer abstrakteren Bezeichnung zusammen. Vermeiden Sie die Auflistung einzelner Attribute o.Ä. (Dachgepäckträger, Anhängerkupplung, Kindersitz, Klimaanlage etc.), sondern verallgemeinern Sie diese (besondere Ausstattungsmerkmale).  Unterstützte Ziele (nur für Kern-Geschäftsanwendungsfälle) Hier werden die Ziele, die mit dem Kern-Geschäftsanwendungsfall unterstützt werden, stichwortartig aufgezählt oder es wird auf entsprechende Zielbeschreibungen verwiesen. Sofern bei der Geschäftsprozessmodellierung vor allem die systemtechnische Umsetzung im Vordergrund steht, sind die folgenden Detailaspekte ggf. weniger interessant als bei einer betriebswirtschaftlichen oder organisatorischen Motivation:  Maßnahmen Welche Aktionen und Maßnahmen sind möglich und sinnvoll, um im Rahmen dieses Geschäftsprozesses den genannten Zielen näher zu kommen?  Kennzahlen Welche Kennzahlen werden von diesem Geschäftsprozess maßgeblich beinflusst?  Risiken und Aufwände Welche Risiken, Aufwände, Nebeneffekte und Kosten sind mit diesen Maßnahmen und Aktionen verbunden?  Chancen und Nutzen Welche Chancen ergeben sich durch diese Maßnahmen? Wie hoch ist deren Nutzen (in Vergleich zu den Risiken und Aufwänden)?  Priorität Die Priorität kann in verschiedener Weise bestimmt werden. Entweder vereinfacht durch eher subjektive Vergabe einer Prioritätskennzahl (z.B. zwischen 0 – 10, wobei 0 die niedrigste Priorität dar16

auch Sonnenscheinfall genannt. Gutfall siehe Glossar 220

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.10 Geschäftsanwendungsfälle essenziell beschreiben Es werden Sachargumente vorgeschoben, um zu verdecken oder davon abzulenken,

stellt) wie in Abb. 3.10-3, oder durch Berechnung der Zielunterstützung wie in Abb. 3.10-2. Hierzu wird für jedes Ziel, das der Anwendungsfall unterstützt, eine Kennzahl angegeben, die die Einflussgröße des Anwendungsfalles auf das Ziel beschreibt. Diese wird jeweils multipliziert mit dem Gewicht des jeweiligen Zieles. So erhalten wir für jedes Ziel eine gewichtete Einflussgröße. Die Zieleinflussgrößen eines Anwendungsfalles werden addiert und ergeben zusammen die Priorität (die höchste Zahl ergibt die höchste Priorität). Die vereinfachte und die zielgetriebene Priorisierung können nicht gemischt werden, da die Aussagekraft dann fragwürdig wird.  Stabilität (hoch | mittel | niedrig) Sind die in dem Anwendungsfall beschriebenen Sachverhalte stabil? Wie groß ist die Wahrscheinlichkeit, dass sie sich bald wieder ändern? Wie sicher sind sich die Beteiligten und Verantwortlichen, dass der Anwendungsfall so laufen soll? Gibt es noch Klärungsoder Entscheidungsbedarf?  Offene Punkte Im Laufe der Erhebung der Anforderungen an den Geschäftsanwendungsfall ergeben sich Fragen, die nicht sofort geklärt werden können, sondern weitere Untersuchungen, Rückfragen o.Ä. erfordern. Um diese nicht aus den Augen zu verlieren, ist es hilfreich, für jeden Geschäftsanwendungsfall eine Liste offener Punkte zu führen. Es werden Sachargumente vorgeschoben, um zu verdecken oder davon abzulenken,

Die gesamte Beschreibung des Geschäftsanwendungsfalles bezieht sich hier zunächst auf den Standard- und Erfolgsfall. Ausnahmen und Varianten werden erst zu einem späteren Zeitpunkt betrachtet.

95

96

3.11 Geschäftsanwendungsfall-Abläufe modellieren dass es eigentlich um persönliche Verletzungen und Ängste geht.

3.11 Geschäftsanwendungsfall-Abläufe modellieren Extrakt  Beschreibe den Standardablauf eines jeden Geschäftsanwendungsfalles in Form eines UML-Aktivitätsdiagramms.  Identifiziere zu jedem Geschäftsanwendungsfall vollständig alle fachlich relevanten Varianten und Ausnahmen und notiere sie im Aktivitätsdiagramm.  Notiere nicht sofort klärbare Fragen in einer Offene-Punkte-Liste. Gutfall (vgl. Glossar 220)

In den vorigen Schritten wurden die Geschäftsanwendungsfälle identifiziert, deren Rahmenbedingungen (Auslöser, Ergebnisse etc.) beschrieben sowie der Standardablauf im Gutfall skizziert. Jetzt geht es darum, die ganzen Ausnahmen und Varianten zu finden, die für die Geschäftsanwendungsfälle relevant sind. Gewöhnlich ist die Beschreibung der Ausnahmen und Varianten um einiges aufwändiger als der Standardfall. Während der Standardfall mit natürlichsprachlichen Mitteln noch gut zu beschreiben ist, gilt dies für die Ausnahmefälle nicht mehr. Die Anzahl der Ausnahmen kann sehr schnell solche Ausmaße annehmen, dass eine reine textliche Beschreibung nicht mehr sinnvoll ist. Ein Geschäftsanwendungsfall, der 10 oder mehr Seiten Text umfasst, wird wahrscheinlich im weiteren Projektverlauf kaum noch gelesen und verstaubt. Außerdem sind die Abhängigkeiten, Bedingungen und Schleifen/Wiederholungen im Ablauf mit natürlicher Sprache kaum übersichtlich und verständlich darzustellen.

UML: Aktivitäten 175

Kfz reservieren 92

Daher verwenden wir spätestens jetzt Ablaufdiagramme als Beschreibungsmittel. Die UML enthält zu diesem Zweck Aktivitätsdiagramme. Beschreibe den Standardablauf als Aktivitätsdiagramm. Bevor die Ausnahmen und Varianten grafisch notiert werden können, benötigen wir als Basis ein Aktivitätsdiagramm für den Standardablauf. Aus dem vorigen Schritt liegt der Ablauf in natürlichsprachlicher Form vor: dass es eigentlich um persönliche Verletzungen und Ängste geht.

Essenzieller Ablauf

    

Reservierungswunsch aufnehmen Kfz-Verfügbarkeit prüfen Kundendaten aufnehmen Kfz-Typ reservieren Reservierung bestätigen

Abb. 3.11-1: Standardablauf des Geschäftsanwendungsfalles Kfz reservieren

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.11 Geschäftsanwendungsfall-Abläufe modellieren Menschen treten auf verschiedenen kommunikativen Ebenen in Kontakt:

Als UML-Aktivitätsmodell sieht der Standardablauf für den Geschäftsanwendungsfall Kfz reservieren folgendermaßen aus: Start

Reservierungswunsch aufnehmen Kfz-Verfügbarkeit prüfen Kundendaten aufnehmen Kfz-Typ reservieren Reservierung bestätigen Ende

Abb. 3.11-2: Standardablauf Geschäftsanwendungsfall Kfz reservieren Menschen treten auf verschiedenen kommunikativen Ebenen in Kontakt:

Identifiziere alle fachlich relevanten Ausnahmen und Varianten. Ausgangspunkt ist der Standardablauf. Die Untersuchung beginnt mit der Frage nach weiteren möglichen Anfangszuständen. Danach wird jeder einzelne Schritt des Standardablaufes unter die Lupe genommen und nach den möglichen Ausnahmen und Varianten gefragt, die dort auftreten können. Leitfragen  Welche weiteren Anfangszustände bzw. weiteren Auslöser des Geschäftsanwendungsfalles sind möglich?  Welche Entscheidungen und Verzweigungen treten im Ablauf auf?  Welche (weiteren) Ergebnisse können erzielt werden? Welche Geschäftsobjekte werden bearbeitet und verändert?

Als Beispiel nehmen wir den Geschäftsanwendungsfall Kfz reservieren Erster Schritt: mit dem Standardablauf aus Abb. 3.11-2 und beginnen dort mit der Un- Reservierungswunsch tersuchung des ersten Schrittes. Der Reservierungswunsch des Kunden aufnehmen wird aufgenommen. Wir fragen: Welche Ausnahmen und Varianten sind hier denkbar? Beispielsweise erhalten wir von der Fachabteilung folgende Antworten:  Der Reservierungswunsch ist möglicherweise unvollständig oder fehlerhaft, beispielsweise fehlt der Mietzeitraum oder der Fahrer ist nicht alt genug.  Der Reservierungswunsch ist möglicherweise sinnlos, beispielsweise liegt der gewünschte Reservierungszeitraum in der Vergangenheit. Immer wieder fragen wir: Gibt es noch weitere Ausnahmen und Varianten? Die Fachabteilung antwortet beispielsweise:

97

98

Kurzfristige Reservierung

3.11 Geschäftsanwendungsfall-Abläufe modellieren die Sachebene, die von sachlichen Argumenten, Rationalität, Zielen,

 Der Reservierungsbeginn ist möglicherweise kurzfristig, d.h., die Reservierung beginnt in den nächsten 24 Stunden. Für jede einzelne genannte Variante wird jetzt weiter gefragt, was in diesem Fall passiert, wie es weitergeht und welches die konkreten Entscheidungskriterien sind, anhand derer die Variante eindeutig identifiziert werden kann. Leitfragen  Was passiert in der jeweiligen Variante? Wie geht es dann im Ablauf weiter?  Was ist sonst noch in diesem Fall zu beachten?  Welche Ausnahmen und Varianten sind ähnlich und können zusammengefasst werden, ohne dass dadurch besondere Anforderungen verloren gehen? die Sachebene, die von sachlichen Argumenten, R ationalität, Zielen,

Ausnahmen und Varianten, die jeweils zum selben Ergebnis führen, d.h., dieselben Geschäftsobjekte bearbeiten, diese in denselben Zustand versetzen und deren Folgeschritte dieselben sind, können zusammengefasst werden. Beispielsweise können möglicherweise die oben genannten Varianten für unvollständige, sinnlose und inkonsistente Reservierungswünsche zusammengefasst werden zur Variante ungültiger Reservierungswunsch. Solche Zusammenfassungen sind stets kritisch zu hinterfragen. Bei Zweifeln sollten die Varianten entweder getrennt bleiben oder die Zweifel notiert werden. Beispielsweise äußert die Fachabteilung folgenden Zweifel:  Ein Reservierungszeitraum, der in der Vergangenheit liegt, erscheint zunächst sinnlos. Eventuell wird diese Möglichkeit aber benötigt, um eine nachträgliche Reservierung einer rechtzeitigen Reservierung gleichzustellen. Dies wäre relevant, wenn beispielsweise der Zeitpunkt einer Reservierung Auswirkungen auf die Konditionen hätte. Offene-Punkte-Liste führen. Der Einfachheit halber belassen wir es trotz dieses Zweifels bei der Zusammenfassung der drei Varianten, nehmen den Zweifel aber in die Liste der offenen Punkte zu diesem Geschäftsanwendungsfall auf, bis er durch die Fachabteilung abschließend geklärt wurde. Offene Punkte

1. Ist eine nachträgliche Reservierung für einen vergangenen Reservierungszeitraum zulässig?

Abb. 3.11-3: Offene Punkte des Geschäftsanwendungsfalles Kfz reservieren

Die Ergebnisse der Variantenuntersuchung werden in dem Aktivitätsdiagramm festgehalten. Dort sieht der erste Schritt wie folgt aus:

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.11 Geschäftsanwendungsfall-Abläufe modellieren Aufgaben und Verstand geprägt ist (was?),

Reservierungswunsch aufnehmen [ok]

[Wunsch ungültig]

[kurzfristige Reservierung]

Abb. 3.11-4: Mögliche Varianten beim Schritt Reservierungswunsch aufnehmen Aufgaben und Verstand geprägt ist (was?),

Ausgehende Transitionen eines Schrittes, die auf denselben Schritt zu- Rekursive Transitionen rückführen (rekursive Transitionen), wie beispielsweise die Transition Was ist eine Transition? [Wunsch ungültig] im obigen Beispiel (Abb. 3.11-4), werden in um- UML: Transition 177 fangreicheren Modellen der Einfachheit halber häufig nicht dargestellt (vgl. Abb. 3.11-5).17 Von den von der Fachabteilung genannten Ausnahmen zum ersten Schritt ist nun noch das weitere Verhalten bei einer kurzfristigen Reservierung offen. Wir fragen daher die Fachabteilung hierzu, wie es in diesem Fall weitergehen soll. Die Antwort:  Bei einer kurzfristigen Reservierung wird sofort ein konkretes Kfz reserviert. Zum Vergleich: Bei einer normalen Reservierung wird nur mengenmäßig ein Kfz des gewünschten Typs reserviert – erst bei Abholung des Fahrzeuges wird dann ermittelt, welches konkrete Fahrzeug der Kunde bekommt. Der übrige Ablauf bleibt unverändert, d.h., der Kunde bekommt die Reservierung bestätigt, wobei die Bestätigung genauso aussieht wie bei einer normalen Reservierung, d.h., es wird dort nur der Kfz-Typ genannt. Diese Antwort wird in der nächsten Version des Ablaufmodells berücksichtigt (Abb. 3.11-5 101). Nach dem Schritt Reservierungswunsch aufnehmen ist dort jetzt eine Verzweigung zu sehen, die bei einer kurzfristigen Reservierung zu dem Schritt Kfz-Sofortverfügbarkeit prüfen führt und bei einer normalen Reservierung wie gehabt zum Schritt Kfz-Verfügbarkeit prüfen führt. Danach geht es weiter mit Kundendaten aufnehmen. In gleicher Weise wie mit Reservierungswunsch aufnehmen wird mit allen Ablaufschritten verfahren, bis alle fachlich denkbaren Situationen berücksichtigt wurden. Dies können unter Umständen sehr viele Vari17

Beachte: nicht dargestellt ist nicht gleichzusetzen mit nicht vorhanden. Diese Transitionen sind im Modell vorhanden, werden aber in bestimmten Diagrammen ausgeblendet. Ein Diagramm zeigt immer einen (ggf. unvollständigen) Ausschnitt aus dem Gesamtmodell.

99

100

3.11 Geschäftsanwendungsfall-Abläufe modellieren die Geschäftsordnungsebene, bei der es um Rechte, Pflichten,

anten sein, trotzdem oder auch gerade dann sind sie alle in das Modell aufzunehmen. Es wird hier Vollständigkeit angestrebt. die Geschäftsordnungsebene, bei der es um Rechte, Pflichten,

Was ist eine fachliche Ausnahme oder Variante? Muss auch jede mögliche Fehlersituation notiert werden? Hierbei gilt es zu unterscheiden zwischen ungeplanten Problemen, technischen Fehlern und ganz allgemeinen Ausnahmen einerseits und ablaufspezifischen fachlichen Fehlern, geschäftlich gewollten oder zumindest nicht verhinderbaren Varianten u.Ä. andererseits. Nur die fachlichen und ablaufspezifischen Ausnahmen werden in das Aktivitätsmodell aufgenommen. Systemanwendungsfälle 133

Der Kunde schläft ein, der Strom fällt aus etc.

Was soll im Ausnahmefall geschehen?

Spezielle, vor allem die softwaretechnische Umsetzung betreffende Konsistenz- und Plausibilitätsregeln, wie beispielsweise ein negativer Reservierungszeitraum (Ende liegt vor dem Anfang), werden ebenfalls noch nicht berücksichtigt, sondern erst später bei den Systemanwendungsfällen. Natürlich ist es denkbar, dass die Aufnahme des Reservierungswunsches nicht erfolgreich beendet werden kann, weil der Kunde seinen Wunsch nicht zu artikulieren vermag, weil er eine Entscheidungsschwäche hat oder er während des Geschäftsanwendungsfalles einschläft. Solche Situationen können beinahe immer auftreten, haben mit dem speziellen Geschäftsanwendungsfall wenig oder nichts zu tun und sind fachlich offensichtlich nicht zu berücksichtigen. Anders ist es hingegen beim nächsten Schritt Kfz-Verfügbarkeit prüfen. Hier wird auf Basis des Reservierungswunsches ermittelt, ob für den Kunden ein entsprechendes Kfz reserviert werden kann. Sofern die entsprechenden Fahrzeuge des gewünschten Kfz-Typs ausgebucht sind, ist eine Reservierung nicht möglich. Dies ist eine fachlich zu berücksichtigende Ausnahme. Was soll in diesem Fall geschehen? Die Fachabteilung formuliert in diesem Beispiel folgende Antwort:  Ist kein zum Reservierungswunsch passendes Kfz verfügbar, kann sich der Kunde für eine Änderung des Reservierungswunsches entscheiden, beispielsweise Zeitraum oder Kfz-Typ variieren, oder die Kfz-Vermietung kann versuchen, dem Kunden ersatzweise ein anderes, gewöhnlich höherwertiges Kfz zum gleichen Tarif anzubieten.

Erweiterung und Vervollständigung des Aktivitätsmodells

Das Aktivitätsmodell wird entsprechend dieser Antwort um eine Verzweigung erweitert, die auf der einen Seite direkt zum Schritt Reservierungswunsch aufnehmen zurückführt und auf der anderen Seite zu einer neuen weiteren Aktivität Alternative Kfz-Verfügbarkeit prüfen. In Alternative Kfz-Verfügbarkeit prüfen wird nach verfügbaren höherwertigen Fahrzeugen gesucht, die dem Kunden aber zum ursprünglichen Tarif angeboten werden können.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.11 Geschäftsanwendungsfall-Abläufe modellieren Befugnisse, Regeln, Standards etc. geht (womit?),

Kfz reservieren

Reservierungswunsch aufnehmen [Kurzfristige Reservierung]

[ok]

Kfz-Sofortverfügbarkeit prüfen [nicht verfügbar]

KfzVerfügbarkeit prüfen [nicht verfügbar]

[ok]

[ok]

[alternativen Reservierungswunsch aufnehmen] Kundendaten aufnehmen

[alternativen Kfz-Typ anbieten]

[ok]

Alternative KfzVerfügbarkeit prüfen

Kfz reservieren

[ok]

[nicht verfügbar]

[ok] Kundendaten aufnehmen [ok] Reservierung bestätigen

[ok]

Kfz-Typ reservieren

[Reservierung bestätigt]

Kfz reserviert

Abb. 3.11-5: Geschäftsanwendungsfall Kfz reservieren mit Varianten zur Verfügbarkeitsprüfung und kurzfristigen Reservierung Befugnisse, Regeln, Standards etc. geht (womit?),

Die Fachabteilung erwähnt in diesem Zusammenhang, dass nur dann höherwertige Ersatz-Kfz angeboten werden, wenn hiervon deutlich mehr zur Verfügung stehen, als für diese Tarifklasse noch Reservierungen erwartet werden können. Dies ist eine Anforderung bzw. Geschäftsregel, die gesondert festgehalten werden sollte. Leider sind wir dafür im falschen Kapitel, aber wenn es Sie interessiert, lesen Sie im Kapitel 3.18 bei Abb. 3.18-4 Anforderung Wahl eines höherwertigen Alternativ-Kfz (132) weiter. In unserem aktuellen Kapitel zeigt Abb. 3.11-5 das bisherige Ergebnis.

101

102

3.12 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren die Beziehungsebene, auf der Gefühle, Erwartungen, Ängste,

3.12 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren Extrakt  Überprüfe und restrukturiere ggf. die Ablaufreihenfolgen.  Überprüfe und konsolidiere die verwendeten Begriffe. die Beziehungsebene, auf der Gefühle, Erwartungen, Ängste,

Überprüfe und restrukturiere ggf. die Ablaufreihenfolgen. Bei der Beschreibung des ursprünglichen essenziellen Ablaufes wurde eine typische Reihenfolge der einzelnen Schritte angenommen. Bisher wurde jedoch noch nicht hinterfragt und diskutiert, ob der Ablauf nicht vielleicht auch anders aussehen könnte und möglicherweise flexibler oder effizienter gestaltet werden kann. Es gibt zwei grundsätzliche Vorgehensweisen zur Restrukturierung: Einfach: Gesunder Menschenverstand

Formal: Vor- und Nachbedingungen

Formale Restrukturierung von Systemanwendungsfällen 139

 Zum einen eine erfahrungsbasierte Restrukturierung. Hierbei wird jeder Schritt scharf angeguckt und darüber nachgedacht, ob die Reihenfolge, d.h. seine Position, eine andere sein könnte. Diese Ideen werden mit der Fachabteilung besprochen und abgestimmt.  Die andere Vorgehensweise ist eine formale, systematisch herleitbare Restrukturierung. Hierbei werden für jeden einzelnen Schritt die Voraussetzungen und Ergebniszustände beschrieben (sog. Vor- und Nachbedingungen) und dann überprüft, an welcher Stelle im Ablauf die Vorbedingungen erfüllt sind. Ab dort besteht prinzipiell die Möglichkeit, den Schritt durchzuführen. Im Folgenden demonstrieren wir die erfahrungsbasierte Vorgehensweise. Die formale Untersuchung der Restrukturierungsmöglichkeiten zeigen wir später bei der Modellierung der Systemanwendungsfälle, wobei das Prinzip direkt auf die hier vorliegenden Geschäftsanwendungsfälle übertragbar ist. Für den erfahrungsbasierten Restrukturierungsansatz hinterfragen wir nun Schritt für Schritt (vgl. Abb. 3.11-5 101):  Reservierungswunsch aufnehmen steht bereits ganz am Anfang des Ablaufes und kann nicht vorgezogen werden  Kfz-Verfügbarkeit prüfen kann nicht vorgezogen werden, da hierzu der Reservierungswunsch aus dem vorigen Schritt benötigt wird.  Kfz-Sofortverfügbarkeit prüfen kann aus gleichem Grund nicht vorgezogen werden.  Kundendaten aufnehmen (das im Übrigen bereits an zwei verschiedenen Stellen auftaucht) ließe sich vorziehen und könnte sogar noch

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.12 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren Anerkennung, Offenheit und Vertrauen dominieren (wie?),









103

vor Reservierungswunsch aufnehmen stattfinden, da hierfür keine besonderen Vorbedingungen zu erfüllen sind. Alternative Kfz-Verfügbarkeit prüfen könnte grundsätzlich auch parallel zu Kfz-Verfügbarkeit prüfen stattfinden, da die gleichen Vorbedingungen gelten. Allerdings wäre dies nur begrenzt hilfreich, da immer dann, wenn Kfz-Verfügbarkeit prüfen erfolgreich war, die Ergebnisse von Alternative Kfz-Verfügbarkeit prüfen nicht mehr benötigt würden. Kfz-Typ reservieren benötigt sowohl ein positives Ergebnis von KfzVerfügbarkeit prüfen als auch die Kundendaten, damit klar ist, für wen was reserviert werden soll. Dieser Schritt lässt sich nicht vorziehen. Kfz reservieren benötigt sowohl ein positives Ergebnis von KfzSofortverfügbarkeit prüfen als auch die Kundendaten und lässt sich daher ebenfalls nicht vorziehen. Eine Reservierung zu bestätigen, bevor überhaupt reserviert wurde, macht keinen Sinn, Reservierung bestätigen kann daher ebenfalls nicht vorgezogen werden.

Anerkennung, Offenheit und Vertrauen dominieren (wie?),

Aufgrund der obigen Überlegungen wird das Modell jetzt dahingehend verändert, dass Kundendaten aufnehmen parallel zu den ersten Schritten stattfinden kann. Außerdem könnte mit Alternative Kfz-Verfügbarkeit prüfen anders um- Abb. 3.12-1, Variante a) gegangen werden. Zwar ist es kaum zweckmäßig, diesen Schritt präventiv, d.h. parallel zu Kfz-Verfügbarkeit prüfen, durchzuführen. Andererseits ist die Entscheidung, nach Kfz-Verfügbarkeit prüfen in Richtung Alternative Kfz-Verfügbarkeit prüfen weiterzugehen, sinnlos, wenn auch diese wieder mit [nicht verfügbar] enden würde. Wir könnten das Modell also auch dahingehend ändern, bei einem ne- Abb. 3.12-1, Variante b) gativen Ausgang von Kfz-Verfügbarkeit prüfen ohne weitere Entscheidung gleich mit Alternative Kfz-Verfügbarkeit prüfen weiterzumachen und nur wenn dies [ok] ist überhaupt die Möglichkeit einer AlternativReservierung anzubieten. Wenn wir uns vorstellen, diesen Ablauf softwaretechnisch zu unterstützen, würden die beiden Verfügbarkeitsprüfungen automatisch durchgeführt und die eben beschriebene Modelländerung wäre sinnvoll, da die gesamte Durchlaufzeit verbessert würde, was beispielsweise bei einer Reservierung durch ein Callcenter vorteilhaft wäre.

Durchlaufzeiten optimieren Automatisierung und softwaretechnische Unterstützung?

104

3.12 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren die unbewusste Ebene, bei der unbewusste Verhaltensmuster wirksam werden.

KfzVerfügbarkeit prüfen KfzVerfügbarkeit prüfen [ok]

Alternative KfzVerfügbarkeit prüfen

[nicht verfügbar]

[nicht verfügbar]

[nicht verfügbar]

[ok]

KfzVerfügbarkeit prüfen [ok]

[nicht verfügbar] [alternativen Reservierungswunsch aufnehmen]

Alternative KfzVerfügbarkeit prüfen [nicht verfügbar]

[ok]

[ok] [alternativen Reservierungswunsch aufnehmen] [alternativen Kfz-Typ anbieten]

Variante a)

[alternativen Kfz-Typ anbieten] [alternativen Reservierungswunsch aufnehmen]

[alternativen Kfz-Typ anbieten]

Variante b)

Alternative KfzVerfügbarkeit prüfen

[nicht verfügbar]

[ok]

Variante c)

Abb. 3.12-1: Verschiedene Varianten der Verfügbarkeitsprüfung (Variante c ist unverändert wie in Abb. 3.11-5)

Wenn wir davon ausgehen, dass dieser Ablauf nicht automatisiert wird, d.h. die Verfügbarkeitsprüfungen manuell durchgeführt werden müssten, dann würde man die alternative Verfügbarkeitsprüfung nur dann durchführen, wenn es unbedingt notwendig ist, d.h. das bisherige Modell nicht ändern. die unbewusste Ebene, bei der unbewusste Verhaltensmusterwirksam werden.

Überlegungen zur systemtechnischen Umsetzung Kap. 3.19 133

Obwohl es bei der Modellierung der Geschäftsanwendungsfälle noch nicht darum geht, Entscheidungen zur Automatisierung und systemtechnischen Unterstützung zu treffen, werden solche Überlegungen in der Praxis hier bereits auftauchen. Eigentlich geht es erst im Abschnitt 3.19 Systemanwendungsfälle um solche Entscheidungen.

Detaildiskussionen vertagen: Offene-Punkte-Liste

Es ist an dieser Stelle nur bedingt sinnvoll, solche Überlegungen komplett und vollständig auszudiskutieren. Gewöhnlich ist es besser, diese Diskussionen frühzeitig abzubrechen und die diskutierten Varianten und Annahmen einfach zur späteren Bearbeitung festzuhalten. Hierfür existiert in der Beschreibung des Geschäftsanwendungsfalles die Rubrik offene Punkte, die in unserem Beispiel bisher nur einen Punkt enthielt (vgl. 98) und nun wie folgt erweitert wird: Offene Punkte

1. … 2. Soll die Prüfung der alternativen Kfz-Verfügbarkeit a) sofort parallel zu Kfz-Verfügbarkeit prüfen laufen? b) automatisch nur bei erfolgloser KfzVerfügbarkeitsprüfung laufen? c) nur auf Nachfrage nach erfolgloser KfzVerfügbarkeitsprüfung laufen?

Abb. 3.12-2: Weitere offene Punkte des Geschäftsanwendungsfalles Kfz reservieren

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.12 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren Probleme, die sich auf einer Ebene äußern, können ihre Ursache auf einer tieferen Ebene

105

Nichtsdestotrotz müssen wir uns in dem Aktivitätsmodell für eine Variante entscheiden, nach Möglichkeit für eine einfache Variante, also eine mit möglichst wenigen Schritten, Verzweigungen und Transitionen. In unserem Beispiel ist Variante 2b einfach und führt uns zu dem Modell in Abb. 3.12-3. Kfz reservieren

Reservierungswunsch aufnehmen [Kurzfristige Reservierung] Kundendaten aufnehmen

[ok]

KfzVerfügbarkeit prüfen

[nicht verfügbar]

[ok] [nicht verfügbar]

Kfz-Sofortverfügbarkeit prüfen

Alternative KfzVerfügbarkeit prüfen

[ok]

[nicht verfügbar]

1.1 [ok] [alternativen Reservierungswunsch aufnehmen]

[alternativen Kfz-Typ anbieten] Kfz reservieren

Reservierung bestätigen

Kfz-Typ reservieren

Kfz reserviert

Abb. 3.12-3: Geschäftsanwendungsfall Kfz reservieren mit Varianten Probleme, die sich auf einer Ebene äußern, können ihre Ursache auf einer tieferen Ebene

Bei genauer Betrachtung des Ablaufes taucht noch die Frage auf, ob bei Vgl. letzte Fassung 92 einem negativen Ausgang von Kfz-Sofortverfügbarkeit prüfen auch nach alternativen Kfz-Typen gesucht werden soll, ähnlich wie bei der normalen Reservierung. Die Fachabteilung äußert in diesem Fall hierzu, dass dies möglich sein soll, jedoch ohne explizite Nachfrage beim Kunden, d.h., dieser Sachverhalt liegt komplett innerhalb des Schrittes Kfz-Sofortverfügbarkeit prüfen; weitere Schritte oder Verzweigungen sind also nicht zu modellieren.

106

3.12 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren haben und können auch nur auf dieser Ebene gelöst werden.

Vgl. Glossar 220 Restrukturierung der Terminologie

Sprachliche Konsolidierung. Es ist ein ganz normales Phänomen, dass die Begriffe, die zu Beginn der Modellierung verwendet wurden, am Ende nicht mehr optimal sind. Dadurch dass immer mehr Ausnahmen und Varianten hinzukommen, müssen immer spezifischere Begriffe verwendet werden. Die zu Beginn verwendeten Begriffe stellen sich dabei häufig als überholt und zu einfach heraus. Es ist daher zweckmäßig, alle wichtigen Begriffe des Anwendungsfalles noch einmal zu betrachten, zu überprüfen und ggf. anzupassen. Leitfragen  Betrachte der Reihe nach alle Fachbegriffe und Namen, nehme gedanklich eine destruktive Haltung ein und frage: Was wäre eine völlig falsche oder bösartige Interpretation dieses Begriffes? Suche dann nach einem besseren, unmissverständlichen Begriff.  Nehme wichtige Fachbegriffe und Namen in ein Glossar auf und verwende möglichst einheitlich die Glossarbegriffe. haben und können auch nur auf dieser Ebene gelöst werden.

Beispiel: Kfz versus Kfz-Typ

Beispielsweise wurde bisher stets von Kfz-Verfügbarkeit prüfen gesprochen, obwohl mittlerweile klar ist, dass sowohl konkrete Kfz als auch nur mengenmäßig Fahrzeuge eines Kfz-Typs reserviert werden können. Im Schritt Kfz-Verfügbarkeit prüfen wird nach Kfz-Typen gesucht, in Kfz-Sofortverfügbarkeit prüfen nach konkreten Kfz. Die Namen sind also missverständlich. Eigentlich wäre es jetzt besser, folgende Namen zu ersetzen: Kfz-Verfügbarkeit prüfen  Kfz-Typ-Verfügbarkeit prüfen Kfz-Sofortverfügbarkeit prüfen

 Kfz-Verfügbarkeit prüfen

Alternative Kfz-Verfügbarkeit prüfen

 Alternative Kfz-TypVerfügbarkeit prüfen

Die Schritte Kfz reservieren und Kfz-Typ reservieren hatten wir schon mit dieser expliziten Unterscheidung zwischen Kfz und Kfz-Typ richtig benannt, sie bleiben daher unverändert. Glossar 220

Restrukturierung der Ablaufreihenfolge

Begriffe aus dem hier beispielhaft betrachteten Geschäftsanwendungsfall Kfz reservieren, die ins Glossar aufgenommen werden sollten, sind: Reservierung, kurzfristige Reservierung, Kfz, Kfz-Typ, Kunde und Interessent. Zum Thema Glossar folgt später ein eigenes Kapitel (3.20 Glossar und Abkürzungsverzeichnis entwickeln 141). Die jetzt gewonnenen Erkenntnisse über den Geschäftsanwendungsfall werden nun abschließend auch in der natürlichsprachlichen Beschreibung berücksichtigt. Zum einen wird die Nachbedingung erweitert um den Fall der kurzfristigen Reservierung, der in der letzten Fassung noch

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.12 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren Wenn beispielsweise ein Fachabteilungsleiter auf der Geschäftsordnungsebene

nicht bekannt war. Zum anderen hat sich herausgestellt, dass die Aufnahme der Kundendaten prinzipiell bereits zu Beginn des Ablaufes möglich ist, weswegen die (typische, aber nicht zwingende) Reihenfolge im essenziellen Ablauf angepasst wird. Die Beschreibung des essenziellen Ablaufes bleibt jedoch trotz allen zwischenzeitlich erlangten Detailwissens eine abstrakte und vereinfachte Beschreibung, d.h., die Ausnahmen und Varianten werden ignoriert. Deswegen heißt es weiterhin in Schritt 4 Kfz-Typ reservieren, auch wenn in Ausnahmefällen sogar ein konkretes Kfz reserviert werden könnte. Wenn beispielsweise ein Fachabteilungsleiter auf der Geschäftsordnungsebene

Beschreibung Geschäftsanwendungsfall Name

Kfz reservieren

Kurzbeschreibung

Für einen Mieter wird ein Kfz reserviert.

Akteure

 Interessent, Mieter (Interessent wird durch diesen Anwendungsfall zum Mieter)

Auslöser

 Mieter teilt den Wunsch mit, ein Kfz zu reservieren.

Ergebnis(se)

 Reservierungsbestätigung

Eingehende Daten

 Reservierungswunsch, Kundendaten

Vorbedingungen

 keine

Nachbedingungen

 Für den Mieter wurde ein Kfz eines bestimmten KfzTyps reserviert (d.h. nur mengenmäßig ein Fahrzeug eines Kfz-Typs). Bei kurzfristigen Reservierungen wurde bereits ein konkretes Kfz reserviert.

Essenzieller Ablauf

    

Offene Punkte

1. Ist eine nachträgliche Reservierung für einen vergangenen Reservierungszeitraum möglich? 2. Soll die Prüfung der alternativen Kfz-Verfügbarkeit a) sofort parallel zu Kfz-Verfügbarkeit prüfen laufen? b) automatisch nur bei erfolgloser KfzVerfügbarkeitsprüfung laufen? c) nur auf Nachfrage nach erfolgloser KfzVerfügbarkeitsprüfung laufen?

Kundendaten aufnehmen Reservierungswunsch aufnehmen Kfz-Verfügbarkeit prüfen Kfz-Typ reservieren Reservierung bestätigen

Abb. 3.12-4: Essenzielle Beschreibung des Geschäftsanwendungsfalles Kfz reservieren

Außerdem wurde die Begrifflichkeit entsprechend des Glossars standardisiert, Begriffe aus dem Glossar sind unterstrichen dargestellt18 (oder in elektronischen Dokumenten am besten als Hyperlink). Die 18

Die Unterstreichung bzw. Referenzierung erfolgt unabhängig von der ggf. angewandten Beugung (Deklination oder Konjugation) oder dem Plural des Wortes. Wenn im Glossar beispielsweise Kunde aufgeführt ist, wird in den Anwendungsfalltexten u.Ä. auch Kunden unterstrichen.

107

108

3.12 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren durch das Herumreiten auf Formalien Entscheidungen und Fortschritt blockiert,

komplette natürlichsprachliche Beschreibung des Anwendungsfalles sieht jetzt wie in Abb. 3.12-4 aus. durch das Herumreiten auf Formalien Entscheidungen und Fortschritt blockiert,

Der Vollständigkeit halber zeigen wir in der folgenden Abbildung noch einmal das sprachlich konsolidierte Ablaufdiagramm. Kfz reservieren

Reservierungswunsch aufnehmen [Kurzfristige Reservierung]

[ok]

Kfz-TypVerfügbarkeit prüfen

Kundendaten aufnehmen

[nicht verfügbar]

[ok] [nicht verfügbar]

KfzVerfügbarkeit prüfen

Alternative KfzTyp-Verfügbarkeit prüfen

[ok]

[nicht verfügbar]

1.1 [ok] [alternativen Reservierungswunsch aufnehmen]

[alternativen Kfz-Typ anbieten] Kfz reservieren

Reservierung bestätigen

Kfz-Typ reservieren

Kfz reserviert

Abb. 3.12-5: Abschließende konsolidierte Fassung des Geschäftsanwendungsfalles Kfz reservieren

Auf den folgenden Seiten sehen Sie noch weitere Ablaufdiagramme für die Geschäftsanwendungsfälle Reservierung ändern, Reservierung stornieren und Kfz vermieten, ohne dass diese jedoch ausführlich diskutiert werden.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.12 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren wird er das wahrscheinlich sachlich und logisch nachvollziehbar begründen können.

Reservierung ändern

Reservierung identifizieren

[Reservierungsnr. unbekannt]

Kunde identifizieren

[Abbrechen]

[Reservierung identifiziert] [Kunde identifiziert]

Änderbare Reservierungen ermitteln

[Abbrechen] [Keine änderbare Reservierung vorhanden]

[Reservierungen ermittelt] [Andere Reservierung ändern] Reservierung auswählen Reservierungswunsch ändern

[Reservierung identifiziert] [Abbrechen] [Abbrechen]

[Änderung nicht möglich]

[Reservierungswunsch geändert]

Kfz-Typ reservieren [Kfz-Typ reserviert]

Reservierung bestätigen [Reservierung bestätigt]

Reservierung geändert

Reservierungsänderung abgebrochen

Abb. 3.12-6: Ablaufmodell des Geschäftsanwendungsfalles Kfz-Reservierung ändern wird er das wahrscheinlich sachlich und logisch nachvollziehbar begründen können.

109

110

3.12 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren Auch wenn er vielleicht nur aufgrund einer früheren persönlichen Verletzung Rache übt,

Reservierung stornieren

Reservierung identifizieren

[Reservierungsnr. unbekannt] Kunde identifizieren

[Abbrechen]

[Reservierung identifiziert] [Kunde identifiziert]

Änderbare Reservierungen ermitteln

[Abbrechen] [Keine änderbare Reservierung vorhanden]

[Reservierungen ermittelt] Reservierung auswählen Reservierung stornieren

[Reservierung identifiziert]

[Abbrechen]

[Reservierung storniert]

Reservierungsstornierung bestätigen [Stornierung bestätigt]

Reservierung storniert

Stornierung abgebrochen

Abb. 3.12-7: Ablaufmodell des Geschäftsanwendungsfalles Kfz-Reservierung stornieren Auch wenn er vielleicht nur aufgrund einer früheren persönlichen Verletzung Rache übt,

Ein weiteres Beispiel eines Ablaufmodelles ist auch im nächsten Kapitel 3.13 in Abb. 3.13-2 zu sehen.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.13 Geschäftsanwendungsfall-Abläufe detaillieren die er durch den jetzigen Projektleiter erfahren musste.

3.13 Geschäftsanwendungsfall-Abläufe detaillieren Extrakt  Beschreibe die einzelnen Aktivitäten eines jeden Geschäftsanwendungsfall-Ablaufmodelles in einer vorgegebenen detaillierten Form.

Als Beispiel hierfür verwenden wir den Ablauf des Geschäftsanwendungsfalles Kfz vermieten, wie er in Abb. 3.13-2 zu sehen ist. die er durch den jetzigen Projektleiter erfahren musste.

Einige ausgewählte Aktivitäten bzw. Objektknoten und ihre Aktivitäts- Womit beschreiben? übergänge aus Abb. 3.13-2 sind im Folgenden erläutert. In der Praxis sollten Ablaufmodelle mit einem UML-Modellierungswerkzeug erstellt werden. Diese Werkzeuge bieten üblicherweise die Möglichkeit, jedes einzelne Element (d.h. jede Aktivität, jeder Aktivitätsübergang etc.) weiter zu erläutern. Die folgenden Abbildungen zeigen strukturierte Erläuterungen zu ausgewählten Elementen. Alternativ könnten diese auch beispielsweise mit einem Textverarbeitungsprogramm erstellt werden. Entsprechende Muster finden Sie unter www.oose.de/oep. Aktivitätsbeschreibung ID: Name

A-1: Reservierung identifizieren

Kurzbeschreibung

Aufgrund der Reservierungsnr. oder anderer Informationen wird eine Kfz-Reservierung identifiziert.

Anmerkungen

--

Benötigte Objekte

--

Offene Punkte

Ist dies ein sekundärer Anwendungsfall?

Mögliche Ergebnisse: ID

Bedingung

Ergebnisobjekte

Beschreibung

1

Kfz reserviert

Reservierung [Kfz bestätigt]

Reservierungszeitraum steht unmittelbar bevor oder hat bereits begonnen

Die Reservierung gilt für ein konkretes Kfz. 2

Kfz-Typ reserviert

Reservierung [Kfz-Typ bestätigt]

Reservierungszeitraum steht unmittelbar bevor oder hat bereits begonnen

Die Reservierung gilt nicht für ein konkretes Kfz, sondern nur für einen KfzTyp. 3

Abbrechen

--

--

Suche nach Reservierung erfolglos beendet. Abb. 3.13-1: Detailbeschreibung der Aktivität Reservierung identifizieren

111

112

3.13 Geschäftsanwendungsfall-Abläufe detaillieren Der Versuch, auf der sachlichen und logischen Ebene mit einer Lösung zu überzeugen,

Kfz vermieten

.3 [Abbrechen]

Reservierung identifizieren

.1 [Kfz-Typ reserviert]

Externes Ersatz-Kfz organisieren

.2 [Kein Kfz verfügbar]

.2 [Kein externes Kfz organisiert] .1 [Externes Kfz organisiert]

.2 [Kfz reserviert]

Kfz festlegen

.1 [Kfz festgelegt]

Kulanzleistung organisieren KfzMietvertrag schließen

.1 [ok] Externes Kfz vermittelt

.2 [abgelehnt]

.1 [Reservierung freigegeben]

.1 [Kfz übergeben ] .2 [Restmietdauer nicht geändert]

Kulanz geleistet

.2 [Kfz-Schaden melden] .2 [Kfz nicht mehr fahrbereit]

Reservierung freigeben

Kfz-Schaden aufnehmen

.1 [Restmietdauer geändert]

Kfz wird genutzt

.1 [Kfz noch fahrbereit]

.3 [Restmietdauer ändern]

Restmietdauer ändern

.3 [Abbrechen] .1 [Kfz zurückgeben] ? Kfz zurücknehmen .1 [Kfz zurückgenommen]

Kfz wieder mietbereit machen

Kfz-Nutzung abrechnen

Kfz-Vermietung abgeschlossen

Abgebrochen

Abb. 3.13-2: Ablaufmodell des Geschäftsanwendungsfalles Kfz vermieten Der Versuch, auf der sachlichen und logischen Ebene mit einer Lösung zu überzeugen,

UML: Aktivitäten 175

In der Detailbeschreibung Abb. 3.13-1 werden neben dem Namen des möglichen Ergebnisses (auch Transition oder Aktivitätsübergang genannt) auch noch Ergebnisobjekte und Bedingungen aufgeführt. Mit den Ergebnisobjekten wird beschrieben, welche Geschäftsobjekte von der Aktivität erzeugt oder verändert wurden. Es ist grundsätzlich mög-

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.13 Geschäftsanwendungsfall-Abläufe detaillieren scheitert. Die persönliche Beziehung zwischen den Kontrahenten muss geklärt werden.

lich, diese Information auch grafisch in einem Ablaufmodell (wie Abb. 3.13-2) zu notieren. Da die Diagramme dann jedoch schnell unübersichtlich werden, haben wir hier darauf verzichtet. Wie diese Notation prinzipiell aussieht und was dabei zu beachten ist, erfahren Sie in Kapitel 4.4.6 (184). Die in Abb. 3.13-1 genannten Bedingungen zu den einzelnen mögli- Bedingungen chen Ergebnissen erlauben es, die möglichen Übergänge von einer Aktivität zu nächsten weiter einzuschränken. Grundsätzlich darf nach Abschluss einer Aktivität nur ein Übergang aktiv werden, niemals zwei oder mehrere gleichzeitig. Falls also zwei Übergänge dasselbe Ergebnis (wie in Abb. 3.13-3 Schadenmeldung [erfasst]) erzeugen, müssen sie sich zumindest durch ihre Bedingungen so unterscheiden, dass nur eine der Bedingungen jeweils erfüllt sein kann.

scheitert. Die persönliche Beziehung zwischen den Kontrahenten muss geklärt we rden.

Aktivitätsbeschreibung ID: Name

A-10: Kfz-Schaden aufnehmen

Kurzbeschreibung

Es wird eine Schadenmeldung aufgenommen, die der Mieter während der Kfz-Nutzung meldet.

Anmerkungen

--

Eingehende Objekte

Reservierung [Kfz wird genutzt]

Offene Punkte

Es ist unklar, wie es nach Ergebnis 2 weitergehen soll.

Mögliche Ergebnisse: ID

Bedingung

Ergebnisobjekte

Beschreibung

1

Kfz noch fahrbereit

Schadenmeldung [erfasst]

Das Kfz ist noch fahrbereit.

Die Schadenmeldung wurde aufgenommen, das Kfz ist noch fahrbereit und die Nutzung wird fortgesetzt. 2

Kfz fahruntüchtig

Schadenmeldung [erfasst]

Das Kfz ist nicht mehr fahrbereit.

Die Schadenmeldung wurde aufgenommen, das Kfz ist nicht mehr fahrbereit und die Nutzung kann nicht fortgesetzt werden. 3

Abbrechen

--

Es wurde keine Schadenmeldung aufgenommen.

Die Nutzung des Kfz wird fortgesetzt, ohne dass eine Schadenmeldung aufgenommen wurde. Abb. 3.13-3: Detailbeschreibung der Aktivität Kfz-Schaden aufnehmen

113

114

3.14 Organisatorische Einbettung und Abhängigkeiten identifizieren Der eine kann für das frühere Unrecht um Verzeihung bitten,

3.14 Organisatorische Einbettung und Abhängigkeiten identifizieren Extrakt  Bestimme, welche einzelnen Schritte im Ablauf von welchen Organisationseinheiten verantwortet werden.  Ermittle die sich daraus ergebenden Abhängigkeiten.  Restrukturiere die Verantwortlichkeiten oder Organisationseinheiten ggf. derart, dass die Abhängigkeiten minimiert werden. Der eine kann für das frühere Unrecht um Verzeihung bitten,

Wer ist wofür verantwortlich?

Bestimme die Verantwortlichkeiten. Gewöhnlich ist dies durch einfache Befragung der betroffenen Organisationseinheiten und Fachexperten möglich. In der folgenden Abb. 3.14-1 wird beispielhaft gezeigt, wie in den Ablaufdiagrammen die organisatorische Einbettung dargestellt werden kann. Jede Aktivität wird dabei einer Organisationseinheit zugeordnet, die für die Durchführung dieser Aktivität verantwortlich ist. Selbstverständlich können mehrere Akteure und Organisationseinheiten an einer Aktivität beteiligt sein und aktiv oder passiv mitwirken. In der folgenden Darstellung geht es lediglich um die eindeutige Zuordnung von Verantwortung. Die einzelnen Verantwortlichkeitsbereiche sind in der Abbildung ähnlich wie Schwimmbahnen dargestellt, dieses Diagramm wir daher auch Schwimmbahnendiagramm genannt.

?

Die Aktivität „?“ im Verantwortlichkeitsbereich Callcenter wurde hier übergangsweise eingefügt, da noch nicht geklärt werden konnte, was in diesem Fall (Kfz ist nach Schadenaufnahme nicht mehr fahrbereit) geschehen soll. Dies ist noch mit der Fachabteilung zu klären und dann entsprechend im Ablaufmodell zu berücksichtigen.

Abhängigkeiten erkennen

Aus dieser Verantwortlichkeitsverteilung können auch Abhängigkeiten zwischen den einzelnen Organisationseinheiten abgeleitet werden. Als Abhängigkeit bezeichnen wir hier, dass eine Aktivität auf den Abschluss einer anderen wartet. Beispielsweise kann die Aktivität KfzNutzung abrechnen von der Organisationseinheit Buchhaltung erst durchgeführt werden, wenn zuvor die Aktivität Kfz zurücknehmen von der Organisationseinheit Mietstation erfolgreich beendet wurde. Die Buchhaltung ist von der Mietstation abhängig. Die Abb. 3.14-2 zeigt die Abhängigkeiten der Organisationseinheiten, soweit sie sich aus dem Geschäftsanwendungsfall Kfz vermieten ergeben. Abhängigkeitsmodelle (auch Abhängigkeitsgraphen genannt) kön-

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.14 Organisatorische Einbettung und Abhängigkeiten identifizieren indem er sagt, dass es ihm leid tut, er ihm Anerkennung und Respekt entgegenbringt

115

nen sowohl für einen einzelnen Geschäftsanwendungsfall als auch für eine bestimmte Menge oder für alle betrachteten Geschäftsanwendungsfälle ermittelt werden. Mietstation

Zentrale Kfz-Disposition

Mieter

Callcenter

Buchhaltung

Kfz vermieten Kulanzleistung organisieren .3 [Abbrechen]

Reservierung identifizieren

.2 [Kfz reserviert]

.1 [ok]

.2 [Kein externes Kfz organisiert]

Kulanzleistung entgegennehmen

Kfz-Nutzung gescheitert

.1 [Kfz-Typ reserviert]

Kfz festlegen

.2 [Kein Kfz verfügbar]

Externes Ersatz-Kfz organisieren

.1 [Externes Kfz organisiert]

Ersatzleistung entgegennehmen

.1 [Kfz festgelegt] .1 [Restmietdauer nicht geändert] KfzMietvertrag schließen .2 [abgelehnt]

.1 [Restmietdauer geändert] Restmietdauer ändern .1 [Kfz übergeben ]

.3 [Restmietdauer ändern] Kfz wird genutzt

Reservierung freigeben .1 [Kfz zurückgeben]

.2 [Kfz-Schaden melden]

.1 [Kfz noch fahrbereit]

.1 [Reservierung freigegeben]

Kfz-Schaden aufnehmen

.2 [Kfz nicht mehr fahrbereit] Kfz zurücknehmen .1 [Kfz zurückgenommen]

?

Kfz wieder mietbereit machen

Abgebrochen

Kfz-Nutzung abrechnen

Kfz-Vermietung abgeschlossen

Abb. 3.14-1: Verantwortlichkeitsbereiche für den Geschäftsanwendungsfall Kfz vermieten indem er sagt , dass es ihm leid tut, er ihm Anerkennung und Respekt entgegenbringt

Abhängigkeitsmodelle können interessante Informationen für die Optimierung der Geschäftsanwendungsfälle und Organisationsstruktur Optimierung durch liefern. Da Abhängigkeiten (eine Abteilung wartet auf Leistungen einer Abhängigkeitsmanagement anderen) gewöhnlich negativ wirken, sollten die Abhängigkeiten zwischen den Organisationseinheiten soweit wie möglich minimiert werden. Wir nennen dies Abhängigkeitsmanagement. Zu beachten ist jedoch, dass der Grad der Abhängigkeit sehr unterschiedlich sein kann. Im Falle von Kfz vermieten (Abb. 3.14-1) existiert beispielsweise ein Übergang von der Mietstation zur Zentrale KfzDisposition (Kfz festlegen zu Externes Ersatz-Kfz organisieren). Dies

116

3.14 Organisatorische Einbettung und Abhängigkeiten identifizieren oder indem das überzogene Beziehungskonto auf andere Art wieder ausgeglichen wird,

tritt jedoch sehr selten ein, hauptsächlich dann, wenn im Vorfeld die Kfz-Disposition schlecht organisiert war oder viele Fahrzeuge unerwartet ausfallen oder später zurückkommen. Diese Abhängigkeit ist also eher unbedeutend. oder indem das überzogene Beziehungskonto auf andere Art wieder au sgeglichen wird,

Viel schwerwiegender ist die Abhängigkeit des Mieters von der zentralen Kfz-Disposition. Dies bedeutend in der Praxis, dass die zentrale Kfz-Disposition außenorientierte Geschäftsmitarbeiter für die Kommunikation mit dem Mieter benötigt. Da das Problem Kein Kfz verfügbar in der Mietstation auftritt, heißt dies, dass die zentrale Kfz-Disposition einen Vertreter in der Mietstation vorhalten muss. Und das nur für den seltenen Fall eines Verfügbarkeitsproblems. Buchhaltung

Zentrale KfzDisposition

Abhängigkeiten der Orgeinheiten aus Ablaufmodell für Geschäftsanwendungsfall Kfz vermieten

Mietstation

Mieter

Callcenter

Abb. 3.14-2: Abhängigkeiten der Organisationseinheiten durch den Geschäftsanwendungsfall Kfz vermieten

Wir heben diese Abhängigkeit auf, indem wir die Verantwortung für die Ersatz- und Kulanzleistungen der Mietstation zuordnen. Diese hätte dann mehr Aufgaben und Verantwortlichkeiten, die Zentraldisposition entsprechend weniger und zwei Abhängigkeiten fielen weg. Die Abb. 3.14-3 und Abb. 3.14-4 zeigen den reorganisierten Geschäftsanwendungsfall Kfz vermieten. Mietstation

Mieter

Callcenter

Buchhaltung

Kfz nutzen Kulanzleistung organisieren .3 [Abbrechen]

Reservierung identifizieren

.2 [Kfz reserviert]

.1 [ok]

Kulanzleistung entgegennehmen

.2 [Kein externes Kfz organisiert]

Kfz-Nutzung gescheitert

.1 [Kfz-Typ reserviert]

Kfz festlegen

.2 [Kein Kfz verfügbar]

Externes Ersatz-Kfz organisieren

.1 [Externes Kfz organisiert]

Ersatzleistung entgegennehmen

.1 [Kfz festgelegt]

KfzMietvertrag schließen

Abb. 3.14-3: Geschäftsanwendungsfall Kfz vermieten mit reorganisierten Verantwortlichkeiten (Modellausschnitt)

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.14 Organisatorische Einbettung und Abhängigkeiten identifizieren so dass die Blockade nicht mehr als Kompensationsmittel benötigt wird.

117

Buchhaltung

Mietstation

Mieter

Abhängigkeiten der reorganisierten Orgeinheiten aus Ablaufmodell für Geschäftsanwendungsfall Kfz vermieten

Callcenter

Abb. 3.14-4: Organisatorische Abhängigkeiten durch den reorganisierten Geschäftsanwendungsfall Kfz vermieten so dass die Blockade nicht mehr als Kompensationsmittel benötigt wird.

Aus der Informatik (konkreter: der Softwarearchitektur) sind verschiedene Metriken und Entwurfsmuster zum Abhängigkeitsmanagement bekannt19, die hier teilweise auch auf Geschäftsprozessmodellierung bzw. Organisationsarchitektur übertragen werden können. Im Bereich der Softwarearchitektur und des objektorientierten Designs können Abhängigkeiten aus vorhandenen Struktur- und Ablaufmodellen automatisch hergeleitet werden. Für ein systematisches Abhängigkeitsmanagement ist es zweckmäßig, Gewichtete Abhängigkeiten die einzelnen Transitionen entsprechend ihrer Nutzungshäufigkeit zu gewichten, um so die Abhängigkeiten zwischen Organisationseinheiten gewichtet zu betrachten. In Abb. 3.14-2 hätten dann die einzelnen Abhängigkeitspfeile auch eine Gewichtsangabe. Damit Geschäftspartner, d.h. außerhalb des Modellierungsfokus stehende Akteure, auch in den Verantwortlichkeitsbereichen der Aktivitätsdiagramme verwendet werden können, ist es zweckmäßig, diese auch als Organisationseinheiten aufzufassen. Beispielsweise haben wir hier Mieter auch als Organisationseinheit modelliert (implizit bestehend aus den Akteuren Mieter und Fahrer).

19

Vgl. http://www.oose.de/emsa

118

3.15 Geschäftsanwendungsfallmodell erstellen In sozialen Systemen müssen folgende Dimensionen ausbalanciert sein: Legitimationsfragen

3.15 Geschäftsanwendungsfallmodell erstellen Extrakt  Stelle alle bisher vorhandenen Geschäftsanwendungsfälle in einem Anwendungsfallmodell dar. Alle Geschäftsanwendungsfälle eines Geschäftsprozesses werden in jeweils einem eigenen Anwendungsfalldiagramm dargestellt.  Identifiziere und beschreibe die involvierten Geschäftsmitarbeiter.  Identifiziere gleiche Schritte in verschiedenen Geschäftsanwendungsfällen und löse sie als sekundäre Geschäftsanwendungsfälle heraus, um ein redundanzfreies Modell herzustellen. In sozialen Systemen müssen folgende Dimensionen ausbalanciert sein: Legitimat ionsfragen

Die bisher ermittelten und beschriebenen Geschäftsanwendungsfälle wurden mit einer entsprechenden Schablone in natürlicher Sprache wiedergeben und deren Abläufe jeweils als ein UML-Aktivitätsmodell darstellt. Zwischen den Geschäftsanwendungsfällen bestehen jedoch teilweise Abhängigkeiten und Gemeinsamkeiten, die nun systematisch erschlossen werden sollen. Die dabei erkannten Beziehungen zwischen den verschiedenen Geschäftsanwendungsfällen werden mit einem UML-Anwendungsfalldiagramm beschrieben. UML: Anwendungsfalldiagramme 155

UML: Pakete 204

Geschäftsanwendungsfallgruppen, Geschäftsprozesse 75

Stelle die vorhandenen Geschäftsanwendungsfälle als Anwendungsfallmodell dar. Anwendungsfälle werden in der UML grafisch durch Ellipsen repräsentiert, zwischen denen es verschiedene Beziehungen geben kann, insbesondere Enthält-Beziehungen («include»). In einem Schritt werden alle Geschäftsanwendungsfälle als einfache Ellipsen in einem Anwendungsfalldiagramm dargestellt. Da abgesehen von trivialen Aufgaben als Ergebnis der Geschäftsprozessmodellierung mehr Anwendungsfälle entstehen, als sich übersichtlich in einem Diagramm auf einer Seite darstellen lassen, ist es zweckmäßig, die Anwendungsfälle zu gruppieren und auf verschiedene Diagramme aufzuteilen. Die UML enthält zur Gruppierung von Modellierungselementen so genannte Pakete. Die Gruppen respektive Pakete liegen bereits vor, es handelt sich hierbei um die Geschäftsprozesse. Geschäftsprozesse werden repräsentiert durch eine Menge von Geschäftsanwendungsfällen. Zu jedem Geschäftsprozess wird jeweils ein Anwendungsfalldiagramm gezeichnet.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.15 Geschäftsanwendungsfallmodell erstellen und -konflikte zur Klärung der Organisationszugehörigkeit. Rangfragen, Machtfragen und

Identifiziere und beschreibe die involvierten Geschäftsmitarbeiter. Im Kapitel 3.7 Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln (72) wurden bereits Geschäftsmitarbeiter identifiziert. Diese können auch hier in den Geschäftsanwendungsfallmodellen berücksichtigt werden, um so die fachlichen und organisatorischen Zusammenhänge besser zu verdeutlichen. Kfz reservieren

Kfz-Reservierung stornieren Mieter Kfz-Reservierung ändern Callcenter-Agent

Schadenmeldung bearbeiten FuhrparkManager Kfz vermieten Fahrer

Buchhaltung Kfz zurücknehmen

Kfz nutzen

Niederlassungsmitarbeiter

Abb. 3.15-1: Geschäftsanwendungsfallmodell für den Geschäftsprozess KfzVermietung und -konflikte zur Klärung der Organisationszugehörigkeit. Rangfragen, Machtfragen und

Löse Redundanzen in den Geschäftsanwendungsfällen auf. Bei der Vielzahl von Geschäftsanwendungsfällen, die während der Modellierung entstehen, ergeben sich bedingt durch das systematische Vorgehen teilweise Redundanzen, d.h., bestimmte Schritte in den Abläufen werden doppelt oder mehrfach beschrieben. Beispielsweise wird ein Schritt wie Kunde identifizieren üblicherweise mehrfach vorkommen, in unserem Fall beispielsweise in den Geschäftsanwendungsfällen KfzReservierung ändern (siehe Abb. 3.12-6 109) und Kfz-Reservierung stornieren (siehe Abb. 3.12-7 110). Solche Mehrfachbeschreibungen führen früher oder später zu Problemen, da bei Änderungen und Weiterentwicklungen möglicherweise nicht alle Beschreibungen aktualisiert werden.

119

120

UML-Anwendungsfallmodell: 155

3.15 Geschäftsanwendungsfallmodell erstellen Machtkonflikte zur Klärung von Positionen, Loyalitätsfragen und -konflikte zur Klärung der

Die Lösung besteht darin, die mehrfach vorkommenden Beschreibungen aus den Anwendungsfällen herauszulösen, nur an einer Stelle als gesonderten so genannten sekundären Anwendungsfall zu beschreiben und an den ursprünglichen Stellen durch einen entsprechenden Verweis (so genannte Enthält-Beziehung) wieder einzubinden. Im Ergebnis sieht dies dann beispielsweise so aus wie in Abb. 3.15-2 dargestellt.20 Kfz-Reservierung stornieren

Kfz vermieten Reservierung bearbeiten

Kfz-Reservierung ändern

«include» «include» «secondary» Reservierung identifizieren

«include»

«secondary» Kfz-Verfügbarkeit prüfen

Schadenmeldung bearbeiten

«include»

Kfz reservieren

Kfz zurücknehmen

Kfz nutzen

Abb. 3.15-2: Geschäftsanwendungsfallmodell für Geschäftsprozess Kfz-Vermietung mit Enthält-Beziehungen Machtkonflikte zur Klärung von Positionen, Loyalitätsfragen und -konflikte zur Klärung der

Redundanzen erkennen

Die entscheidende Frage ist jedoch, wie können solche Redundanzen erkannt werden? Hierbei werden alle einzelnen Schritte in allen Geschäftsanwendungsfällen der Reihe nach durchgegangen und überprüft, ob es an anderer Stelle einen gleichlautenden oder ähnlichen Schritt gibt. Falls ja, wird untersucht, ob derselbe Sachverhalt beschrieben wird. Falls auch das zutrifft, wird ein neuer sekundärer Geschäftsanwendungsfall angelegt und anstelle der bisherigen Beschreibungen eingebunden (Enthält-Beziehung). Das Problem hierbei ist, dass im Prinzip jeder Schritt mit jedem anderen verglichen werden muss, was bei der gewöhnlich nicht geringen Zahl einzelner Schritte zu einer kombinatorischen Explosion der Vergleichsmöglichkeiten führt. Außerdem werden möglicherweise Redundanzen dennoch nicht erkannt, weil andere Begriffe, z.B. nicht erkannte Synonyme, verwendet wurden. Zum Beispiel könnte ein Schritt Kunde 20

Für UML-Spezialisten: Wir nehmen keine Extend-Beziehungen, weil die Semantik in der Praxis zu häufig missverstanden wird bzw. zu Verunsicherung führt. Wir verwenden ausschließlich Enthält-Beziehungen, mit denen die betroffenen Sachverhalte ebenfalls ausgedrückt werden können.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.15 Geschäftsanwendungsfallmodell erstellen Bindung an die Organisation, Anspruchs- und Verpflichtungsfragen zur Klärung der Leistung.

121

identifizieren und ein anderer Mieter suchen heißen, wobei vielleicht einer der Schritte unpräzise oder unglücklich formuliert wurde, da er tatsächlich denselben Sachverhalt darstellen soll. 21 Abhängigkeiten zwischen Geschäftsprozessen minimieren. Unsere Redundanzen und Geschäftsanwendungsfälle sind zu Geschäftsprozessen zusammenge- Abhängigkeiten vermeiden fasst, die modelltechnisch durch entsprechende Pakete repräsentiert werden (vgl. Abb. 3.8-4 ff. 81 ff.). Nachdem nun Gemeinsamkeiten dieser Geschäftsanwendungsfälle in Form von sekundären Geschäftsanwendungsfällen herausgelöst wurden, stellt sich die Frage, in welchem Paket bzw. in welchem Geschäftsprozess diese sekundären Geschäftsanwendungsfälle unterzubringen sind. Wenn ein Geschäftsanwendungsfall einen sekundären Geschäftsanwendungsfall eines anderen Geschäftsprozesses verwendet, dann entsteht eine Abhängigkeit zwischen den Geschäftsprozessen. Die folgende Abbildung zeigt dies beispielhaft. Kfz-Vermietung

Kundenverwaltung

Kfz-Reservierung ändern Kfz reservieren

Kundendaten ändern «include»

«include» Kfz-Reservierung stornieren

«include» «secondary» Kunde identifizieren «include»

Kundendaten löschen

«include»

Kfz-Vermietung

Kundenverwaltung

aus Include-Beziehungen der enthaltenen Anwendungsfälle resultierende Abhängigkeit

Abb. 3.15-3: Abhängigkeiten zwischen Geschäftsprozessen durch EnthältBeziehungen zu sekundären Anwendungsfällen Bindung an die Organisation , Anspruchs- und Verpflichtungsfragen zur Klärung der Leistung.

Wenn zwischen zwei Geschäftsprozessen direkt oder indirekt (d.h. über Dritte) gegenseitige Abhängigkeiten bestehen, spricht man auch von einer zyklischen Abhängigkeit. Abhängigkeiten sollten vermieden werden, da sie typischerweise zu folgenden Nachteilen führen: 21

Es existiert noch eine weitere und zwar sehr formale Möglichkeit (und damit sicherere, aber aufwändigere), Redundanzen zu erkennen. Hierbei müssen zu jedem Schritt Vorund Nachbedingungen in einer formalen Sprache (z.B. OCL) definiert werden. Anschließend können durch Vergleich der Vor- und Nachbedingungen aller Schritte solche mit identischen Vor- und Nachbedingungen systematisch erkannt werden. Diese sind dann mit großer Wahrscheinlichkeit sekundäre Anwendungsfälle.

122

3.15 Geschäftsanwendungsfallmodell erstellen Es geht um Macht, Besitzstände, Seilschaften, Status/Prestige, Tabus, Autoritätsprobleme.

 Wenn verschiedene Organisationseinheiten mit den voneinander abhängigen Geschäftsprozessen bzw. Geschäftsanwendungsfällen betraut sind oder für sie verantwortlich sind, dann sind auch die beteiligten Organisationseinheiten voneinander abhängig. Die notwendige organisationseinheitenübergreifende Kommunikation erhöht sich und eine Abteilung wartet möglicherweise öfter auf Zulieferleistungen einer anderen.  Eine Änderung in einem Geschäftsprozess kann Auswirkungen auf die umliegenden abhängigen Geschäftsprozesse haben. Bei jeder Änderung sind die möglichen Folgen zu bedenken.  Wenn verschiedene Personen oder Teams mit der Analyse und Beschreibung von Geschäftsprozessen betraut sind, die untereinander eine Abhängigkeit besitzen, sind auch diese Teams voneinander abhängig. Die notwendige Kommunikation erhöht sich und die Teams warten möglicherweise gegenseitig auf Zulieferleistungen. Es geht um Macht, Besitzstände, Seilschaften, Status/Prestige, Tabus, Autorität sprobleme.

Für die Paketzuordnung gelten folgende Regeln: Heuristiken für die Paketzuordnung der sekundären Geschäftsanwendungsfälle  Ein sekundärer Geschäftsanwendungsfall, der nur von Geschäftsanwendungsfällen eines Geschäftsprozesses verwendet wird, gehört in genau diesen Geschäftsprozess.  Wenn durch die Verwendung von sekundären Geschäftsanwendungsfällen zyklische Abhängigkeiten zwischen Geschäftsprozessen entstehen, ist zu prüfen, ob die abhängigkeitsauslösenden sekundären Geschäftsanwendungsfälle in einen anderen Geschäftsprozess verschoben werden können, so dass nur noch eine einseitige Abhängigkeit übrig bleibt.  Wenn sich zyklische Abhängigkeiten nicht durch eine solche Verschiebung auflösen lassen, sollte ggf. ein neues Paket eröffnet werden, in dem zyklenauslösende sekundäre Geschäftsanwendungsfälle gesammelt werden. Bei näherer Betrachtung der zur Vermeidung zyklischer Abhängigkeiten zusätzlich eingerichteten Pakete, ergeben sich häufig so genannte Querschnittsprozesse, beispielsweise Materialbeschaffung, Buchhaltung o.Ä.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.16 Geschäftsklassenmodell erstellen Achten Sie auf strukturelle Widersprüche in Projektorganisationen, z. B. problematische

3.16 Geschäftsklassenmodell erstellen Extrakt  Entnehme den Kern-Geschäftsanwendungsfällen die vier22 wichtigsten Geschäftsobjekte. Nehme zusätzlich alle anderen Geschäftsobjekte, die genauso wichtig23 sind wie diese vier.  Erstelle mit diesen Geschäftsobjekten ein Klassenmodell.  Erkenne, welche weiteren Geschäftsobjekte noch zu berücksichtigen sind, damit das Modell verständlich wird, und nehme diese ebenfalls auf. Achten Sie auf strukturelle Widersprüche in Projektorganisationen, z. B. problematische

Der Name Geschäftsprozessmodellierung sagt bereits, dass es dabei um die Beschäftigung mit Abläufen, also dynamischen Aspekten des Geschäftes, geht. Nichtsdestotrotz ist auch die Sicht auf die strukturellen Zusammenhänge des betroffenen Geschäftes für das Gesamtverständnis wichtig. Dieses herauszuarbeiten und darzustellen, darum geht es hier. Ein Geschäftsobjekt beschreibt einen Gegenstand, ein Konzept, einen Ort oder eine Person aus dem Geschäftsbereich aus einer fachlichen Perspektive und in einem Abstraktions- und Detaillierungsgrad, wie er vor allem von den beteiligten Fachabteilungen und Entscheidungsträgern verstanden werden kann. In dem ersten Schritt der Entwicklung eines Geschäftsklassenmodells geht es nicht darum, alle möglichen Geschäftsobjekte zu identifizieren, sondern einen Überblick über die wichtigsten zu geben. Es sollten dies je nach Umfang des Geschäftsprozessmodellierungsbereiches 5 - 15 Geschäftsobjekte sein. Wenn Sie sich unsicher sind, welche noch zu den „wichtigsten“ gehören und welche nicht mehr, hilft eine einfache Regel: Schreiben Sie zunächst die auf, die unstrittig sehr wichtig sind, begrenzen Sie deren Zahl aber auf ca. 4 Stück. Dann vergleichen Sie alle weiteren Kandidaten, ob diese mindestens ebenso wichtig sind, wie einer der gewählten vier. Vier Geschäftsobjekte. Welche sind die vier wichtigsten Geschäftsobjekte in unserem Fallbeispiel?  Kfz, Reservierung, Mietvertrag, Verkaufsvertrag. Welche anderen Geschäftsobjekte sind genauso wichtig? 22 23

Streiten Sie nicht über die Zahl vier – sie ist willkürlich! „Wichtig“ ist subjektiv! Eine gewisse Unschärfe ist hier unproblematisch.

123

124

3.16 Geschäftsklassenmodell erstellen Zuordnung und Abgrenzung von Aufgaben, Rollen und Kompetenzbereichen.

 Mieter, Käufer, Fahrer.24 Nicht mit in diese Liste aufgenommen wurden Kandidaten wie Rechnung oder Zahlungseingang, weil sie als weniger wichtig erachtet wurden. Erstelle ein erstes Klassenmodell. Diese wichtigen Geschäftsobjekte werden nun in einem UML-Klassendiagramm dargestellt. Dabei werden die Beziehungen dieser Geschäftsobjekte untereinander berücksichtigt. Das Diagramm sieht dann wie folgt aus: * 1

Reservierung

*

1

1

Kfz

1

1

Mieter 1

0, 1 Mietvertrag

*

*

* *

*

Fahrer

Verkaufsvertrag * 1 Käufer

Abb. 3.16-1: Erstes einfaches Klassenmodell Zuordnung und Abgrenzung von Aufgaben, Rollen und Kompetenzbereichen.

Jeder Mieter hat eine Menge von Reservierungen und Mietverträgen. Ein Mietvertrag bezieht sich immer auf genau ein Kfz. Ähnlich ist es mit Käufer und Verkaufsvertrag. Ein Käufer kann eine beliebige Menge von Kaufverträgen haben. Ein Verkaufsvertrag gilt immer genau für ein Kfz. Äh, wirklich? Kann es nicht auch vorkommen, dass mit einem Vertrag gleich mehrere Kfz verkauft werden? Hier müssen wir die Fachabteilung fragen, die uns in diesem Fall sagt, dass mehrere Kfz mit einem Vertrag verkauft werden können. Welche wichtigen Klassen fehlen noch?

Bis zur Verständlichkeit expandieren. Allerdings fehlen in dem Diagramm noch weitere Klassen, um die dargestellten strukturellen Zusammenhänge vollständig und verständlich zu beschreiben. Beispielsweise ist es wichtig, darzustellen:  dass sich eine Reservierung gewöhnlich auf einen Kfz-Typ bezieht, ein Mietvertrag aber immer genau auf ein konkretes Kfz,

24

Zu beachten ist, dass die Klassen Mieter und Fahrer hier Geschäftsobjekte repräsentieren, die beispielsweise auch in Datenbanken gespeichert werden, während die gleichnamigen Geschäftspartner (vgl. Kapitel 3.4 51) Akteure repräsentieren.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.16 Geschäftsklassenmodell erstellen Mangelhafte Kommunikation und Koordination im Projekt oder Projektumfeld.

125

 dass bei der Vermietung jeweils ein Fahrer beteiligt ist, der nicht mit dem Mieter (ist ggf. der Arbeitgeber des Fahrers) identisch sein muss,  dass ein zu vermietendes Kfz einer Station zugeordnet ist  und dass vor dem Verkauf gewöhnlich ein Verkaufsangebot an Interessenten gestellt wird. Zusammen mit diesen weiteren Geschäftsobjekten sieht das Diagramm dann wie folgt aus: 1

Mieter

*

Reservierung

1

1

Kfz-Typ 1

1

1..*

*

*

0, 1

* Fahrer

*

Mietvertrag

1

*

1..*

Kaufinteressent

1

*

Verkaufsangebot

*

Kfz 1

1

1..* 0,1

*

Verkaufsvertrag * Käufer 1

Abb. 3.16-2: Erweitertes Klassenmodell Mangelhafte Kommunikation und Koordination im Projekt oder Projektumfeld.

Unterschied Objekt und Klasse. Die Informatiker kennen aus der so genannten objektorientierten Softwareentwicklung die Begriffe Objekt und Klasse. Als Objekt wird ein zur Laufzeit der Software konkret vorhandenes und repräsentiertes Objekt bezeichnet, beispielsweise der Kunde Susi Schnüffelzinken mit der Kundennummer 0815. Als Klasse wird die Art dieses Objektes bezeichnet, beispielsweise Mieter. Susi ist also ein Objekt der Klasse Mieter. Die Informatiker nehmen es mit der Verwendung dieser Begriffe allerdings nicht so genau und sagen schon mal Objekt, wenn sie eigentlich eine Klasse meinen.25 Vergleich Klassenmodell und Datenmodell. Vereinfacht betrachtet ist ein Klassenmodell auch eine Art Datenmodell (oder ERM – EntityRelationship-Modell). Die Klassen sind dann die Tabellen bzw. Entities und die Objekte wären dann die Spalten bzw. Einträge in diesen Tabellen. Allerdings beschreiben Klassenmodelle nicht nur die Datenstruktur von Objekten, sondern auch deren Verhalten (z.B. ändere Vorname). 25

… oder sagen statt Objekt zur allgemeinen Verwirrung synonym auch Exemplar oder Instanz.

Station

126

3.16 Geschäftsklassenmodell erstellen Die Qualität der Beziehungen zu Lieferanten, Kunden, Fachabteilungen

Außerdem kennen die Informatiker noch eine ganze Reihe anderer Arten von Klassen neben den sog. Entitätsklassen, z.B. Steuerungsklassen und Schnittstellen. Daher sind Klassenmodell und Datenmodell trotz gewisser Ähnlichkeiten nicht gleichzusetzen. 1

Mieter

*

Reservierung

0, 1

* 1..*

*

Mietvertrag

1

*

*

Kaufinteressent

1

*

Verkaufsangebot

*

1

1

*

* *

Kfz 1 1..*

Rolle

Station

Kfz-Typ

1

1

Fahrer

1

*

1

Stationierungszeitraum

1..* 0,1 Verkaufsvertrag

1

*

Partner Käufer 1

Abb. 3.16-3: Semantisch erweitertes Klassenmodell (Ausblick)

Das Klassenmodell kann später noch weiter verfeinert werden, indem die Assoziationen zwischen den Klassen benannt werden, Mengenverhältnisse (Multiplizitäten) und Assoziationsrichtungen konkretisiert werden, Gemeinsamkeiten abstrahiert werden, Entwurfsmuster für zusätzliche Semantik (z.B. Historisierung, Partner-Rollen-Muster) u.Ä. zugefügt werden. Das Klassenmodell in Abb. 3.16-3 gibt hier einen Ausblick. Weiter gehende Erläuterungen hierzu finden Sie in der genannten weiterführenden Literatur. Die Qualität der Beziehungen zu Lieferanten, Kunden, Fachabteilungen

Weiterführende Literatur: [Oestereich01a] B. Oestereich: Objektorientierte Softwareentwicklung, Analyse und Design mit der UML. 5. Auflage, Oldenbourg Wissenschaftsverlag, München, 2001.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.17 Zustandsmodelle für zustandsrelevante Geschäftsklassen erstellen Über- und Unterforderungen, Fehlbesetzungen im Unternehmen.

127

3.17 Zustandsmodelle für zustandsrelevante Geschäftsklassen erstellen Extrakt  Identifiziere die möglichen fachlichen Zustände jeder Geschäftsklasse.  Kennzeichne alle Geschäftsklassen mit signifikantem zustandsabhängigem Verhalten.  Entwickle für jede als zustandsabhängig gekennzeichnete Geschäftsklasse ein Zustandsmodell. Über- und Unterforderungen, Fehlbesetzungen im Unternehmen.

Geschäftsobjekte enthalten eine Menge von Attributen (Datenwerten); Was ist ein Zustand? ein Geschäftsobjekt Kunde beinhaltet beispielsweise die Attribute Kundennummer, Name und Anschrift. Ein Zustand ist eine Abstraktion und stellt eine fachlich motivierte Zusammenfassung einer Menge möglicher Attributwerte dar. Abläufe und Geschäftsregeln bedingen oder beziehen sich häufig auf UML: Zustandsmodelle bestimmte Zustände der beteiligten Geschäftsobjekte. Beispielsweise 211 kann eine Rechnung nicht mehr geändert werden, wenn sie gebucht wurde. Gebucht ist ein möglicher Zustand der Rechnung, der sich beispielsweise dadurch manifestiert, dass das Buchungsdatum gesetzt wurde. Mit Zustandsdiagrammen werden vor allem folgende fachliche Aspekte beschrieben:  In welchen Zuständen kann sich ein Objekt befinden?  Welche äußeren Ereignisse bewirken einen Zustandswechsel?  Welche besonderen Anforderungen sind in den jeweiligen Zuständen zu beachten? Identifiziere die möglichen fachlichen Zustände eines jeden Geschäfts- Vgl. Kfz reservieren 108 objektes. Als Beispiel nehmen wir das Geschäftsobjekt Reservierung. Hinweise auf mögliche Zustände können wir den Geschäftsanwendungsfällen entnehmen, beispielsweise Kfz reservieren, KfzReservierung ändern und Kfz-Reservierung stornieren. In welchen Zuständen kann sich eine Reservierung befinden? Zu Beginn enthält die Reservierung den Reservierungswunsch, dieser wird dann überprüft und falls der Wunsch erfüllt werden kann, wird ein KfzTyp reserviert. Bei einer kurzfristigen Reservierung wird ein konkretes

128

3.17 Zustandsmodelle für zustandsrelevante Geschäftsklassen erstellen Energieniveau, Mitarbeitermotivation, Team-Zusammenhalt

Kfz reserviert. Dann wird die Reservierung irgendwann genutzt, d.h., der Mieter möchte das Kfz abholen und nutzen. Möglicherweise wurde die Reservierung aber auch storniert. Grafisch als UML-Zustandsdiagramm ausgedrückt sieht das so aus: Reservierung gewünscht

Start

Reservierungsmöglichkeit prüfen()

Kfz-Typ reserviert

Stornieren()

Reservierungsmöglichkeit prüfen() [kurzfristige Reservierung] storniert

Kfz zuordnen()

Kfz reserviert Mietvertrag abschließen()

Abb. 3.17-1: Zustandsmodell für Vermietung eines Kfz Energieniveau, Mitarbeitermotivation, Team -Zusammenhalt

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

Stornieren()

genutzt

3.18 Geschäftliche Anforderungen und Regeln beschreiben sowie mögliche Gründe für hohe Fluktuation und Krankenstand.

3.18 Geschäftliche Anforderungen und Regeln beschreiben Extrakt  Beschreibe alle geschäftlichen Anforderungen und Regeln in einem zentralen Anforderungskatalog.  Detailliere die Anforderungen nach einem gegebenen Beschreibungsschema.  Referenziere geschäftsobjektspezifische Geschäftsregeln in den jeweiligen Geschäftsobjekten.  Referenziere anwendungsfallspezifische Geschäftsregeln in den jeweiligen Anwendungsfällen. sowie mögliche Gründe für hohe Fluktuation und Krankenstand.

Anforderungen und Geschäftsregeln. Es werden verschiedene Arten von Anforderungen unterschieden, siehe hierzu Kapitel 4.3.11 (170). Für Geschäftregeln sind die so genannten funktionalen Anforderungen am wichtigsten. Im Rahmen von Softwareentwicklungsprojekten werden zusätzlich auch noch die nichtfunktionalen Anforderungen wichtig. Anforderungen beschreiben Eigenschaften und Verhaltensweisen, die stets erfüllt sein sollen. Anforderungen können in verschiedenen Modellierungskontexten auftreten. Solche Anforderungen, die sich auf Abläufe und Verhaltensweisen beziehen, sind in Anwendungsfällen zunächst gut aufgehoben. Anwendungsfälle sind letztendlich fachlich motivierte Zusammenfassungen vor allem funktionaler und ablauforientierter Anforderungen. Anforderungen, die sich auf statische Eigenschaften von Personen, Gegenständen und sonstigen Geschäftsobjekten beziehen, passen zunächst gut in die Beschreibungen von Geschäftsobjekten. Viele Anforderungen beziehen sich jedoch nicht nur auf einen einzelnen Anwendungsfall oder ein einzelnes Geschäftsobjekt, sondern auf mehrere, so dass sie mehrfach in identischer Weise zu beschreiben wäre, was wir natürlich wegen der Mehrarbeit und Konsistenzprobleme vermeiden möchten. Außerdem gäbe es dann verschiedene Orte, an denen Anforderungen abgelegt sind. Beschreibe alle geschäftlichen Anforderungen und Regeln in einem zentralen Anforderungskatalog. Wir gehen daher so vor, dass Geschäftsregeln und übergreifende Anforderungen zentral an einem Ort, dem Anforderungskatalog, abgelegt werden. In den Anwendungsfällen

129

130

3.18 Geschäftliche Anforderungen und Regeln beschreiben Antizipieren Sie mögliche Auswirkungen von Zielfindungs-, Planungs-,

und Geschäftsobjekten, für die bestimmte Anforderungen gelten, nehmen wir nur Verweise auf die entsprechenden Anforderungen des zentralen Kataloges auf. Der zentrale Anforderungskatalog kann in der Praxis ein einfaches Word-Dokument oder eine Excel-Liste sein, ebenso können Anforderungen alternativ in speziellen Anforderungsmanagement-Werkzeugen oder in gewöhnlichen UML-Modellierungswerkzeugen abgelegt sein. Antizipieren Sie mögliche Auswirkungen von Zielfindungs -, Planungs-,

Die einfachen Word- oder Excel-Listen sind in größeren Projekten nicht mehr handhabbar. Spezielle AnforderungsmanagementWerkzeuge wiederum sind in den meisten Fällen eher zu umständlich, wir präferieren daher die Notation und Spezifikation von Anforderungen mit einfachen UML-Mitteln, wie dies in Kapitel 4.3.11 (170) beschrieben ist. Leitfragen zur Identifikation funktionaler Anforderungen  Welche Allgemeinfakte liegen vor? Beispiel: „Der erste Kundenkontakt erfolgt immer über einen Vertriebsmitarbeiter.“  Welche besonderen Handlungseinschränkungen existieren? Beispiel: „Kunden der Bonitätsklasse C erhalten keinen Kredit.“  Welche Handlungsauslöser existieren? Beispiel: „Wenn der gewünschte Kfz-Typ nicht verfügbar ist, erhält der Kunde ohne Aufpreis den nächstbesseren Kfz-Typ.“  Welche Schlussfolgerungen sind generell zu beachten? Beispiel: „Kunden, die mehr als 10.000 Statuskilometer haben, erhalten 10% Rabatt.“  Welche Berechnungsvorschriften sind zu beachten? Beispiel: „Der Nettobestellwert errechnet sich als die Summe der Werte der einzelnen Bestellpositionen ohne Mehrwertsteuer.“

Detailliere die Anforderungen nach einem gegebenen Beschreibungsschema. Für die detaillierte Spezifikation einer Anforderung verwenden wir die in Kapitel 4.3.11 (170) beschriebene Schablone. Ein Beispiel einer Anforderungsspezifikation aus unserem Flitz-AutoFallbeispiel ist in Abb. 3.18-1 zu sehen. Nicht jede Anforderung muss als einzelnes Element notiert werden, dies hängt von dem gewünschten und zweckmäßigen Detaillierungsgrad ab. Für eine weniger detaillierte Darstellung bieten sich Features an, die eine fachlich zusammenhängende Menge von Anforderungen darstellen. Ein Feature ist also einfach eine Liste elementarer Anforderungen.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.18 Geschäftliche Anforderungen und Regeln beschreiben Restrukturierungsprozessen und Verhandlungen.

Anforderung

Mindestmietdauer und -zeiteinheit

Art

Funktionale Anforderung

Beschreibung

Die Mindestmietdauer beträgt normalerweise 6 Stunden. Die Mietdauer beträgt mindestens ganze Stunden. Kleinere Einheiten (Minuten) sind nicht möglich. Für spezielle KfzTypen gelten ggf. andere Mindestzeiten.

Stabilität

instabil

Verbindlichkeit

Pflicht

Priorität

niedrig

Details

Ergibt sich aus den aktuell gültigen Tarifen. Ansprechpartner und verantwortlich ist die Abteilung Mietstationen.

Involvierte andere Modellelemente

 Kfz reservieren  Kfz-Reservierung ändern

Verweise auf andere Geschäftsregeln Änderungen

19.10.2002

Bernd Oestereich

final

erstellt und abgestimmt

Abb. 3.18-1: Spezifikation der Anforderung Mindestmietdauer und -zeiteinheit (nähere Erläuterungen zu der Schablone in Kapitel 4.3.11 170). Restrukturierungsprozessen und Verhandlungen.

Die in einem Feature enthaltenen einzelnen Anforderungen können entweder nur als stichwortartige Beschreibung angegeben werden oder wiederum auf eine detaillierte Anforderungsspezifikation oder andere Features verweisen. Die Verweise auf Detailbeschreibungen werden durch einen vorangestellten Pfeil () angedeutet. Anforderung

Kfz-Reservierungsanforderungen

Art

Feature

Beschreibung

Alle im Rahmen einer Kfz-Reservierung zu beachtenden Geschäftsregeln

Enthaltene Anforderungen

     

Änderungen

12.2.2003

Mindestmietdauer und -zeiteinheit (Fkt. Anforderung) Mindestalter eines Fahrers Wahl eines höherwertigen Alternativ-Kfz Maximale Reservierungsvorlaufzeit Kfz-Reservierungs-Stornierungsregeln (Feature) Zulässige Zeitüberschreitungen bei Kfz-Reservierungen Bernd Oestereich

final

erstellt und abgestimmt

Abb. 3.18-2: Spezifikation des Features Kfz-Reservierungsanforderungen

In der folgenden Abb. 3.18-3 ist zu sehen, wie die Anforderungen von anderen Modellelementen, beispielsweise Geschäftsanwendungsfällen, referenziert werden können. Das Beispiel in der Abbildung bedeutet, dass die Geschäftsanwendungsfälle Kfz reservieren und Kfz-

131

132

3.18 Geschäftliche Anforderungen und Regeln beschreiben Wer sind die vergessenen Beteiligten und Stakeholder?

Reservierung ändern alle in Kfz-Reservierungsanforderungen beschriebenen Anforderungen erfüllen müssen.

«Requirement» Kfz-Reservierungsanforderungen

Kfz reservieren

«include»

«include» Kfz-Reservierung ändern

Abb. 3.18-3: Beziehungen zwischen Geschäftsanwendungsfällen und allgemeinen Anforderungen Wer sind die vergessenen Beteiligten und Stakeholder?

Weil hier noch etwas Platz ist und wir es im Kapitel 3.11 (101) versprochen hatten, detaillieren wir hier noch die Anforderung Wahl eines höherwertigen Alternativ-Kfz. Anforderung

Wahl eines höherwertigen Alternativ-Kfz

Art

Funktionale Anforderung

Beschreibung

Kann ein Reservierungswunsch nicht erfüllt werden, kann unter bestimmten Bedingungen alternativ ein höherwertiges Kfz zu gleichen Konditionen reserviert werden.

Stabilität

instabil

Verbindlichkeit

Pflicht

Priorität

niedrig

Details

Ein höherwertiges Kfz darf nur dann alternativ zu gleichen Konditionen reserviert werden, wenn noch mindestens 25 Prozent der Kfz der höheren Kfz-Klassen für den gewünschten Zeitraum verfügbar sind oder der Mieter in den letzten 18 Monaten mehr als 5-mal ein Kfz gemietet hatte.

Involvierte andere Modellelemente

 Kfz reservieren

Verweise auf andere Geschäftsregeln Änderungen

19.10.2002

Bernd Oestereich

final

erstellt und abgestimmt

Abb. 3.18-4: Anforderung Wahl eines höherwertigen Alternativ-Kfz

Wenn Sie wissen möchten, wie Sie von unausgegorenen Sätzen zu juristisch verbindlichen Anforderungen kommen, lesen Sie [Rupp02], [Oestereich01a] oder [Robertson99].

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.19 Systemanwendungsfälle definieren Stärken Sie die Bereitschaft zur Übernahme von Führungsverantwortung.

133

3.19 Systemanwendungsfälle definieren Extrakt  Entscheide für jeden vorliegenden Geschäftsanwendungsfall, ob er ganz oder teilweise systemtechnisch unterstützt werden soll.  Ergänze ggf. fehlende fachliche Ausnahmen und Varianten, beispielsweise fachlich sinnvolle Abbruchmöglichkeiten.  Zerlege die systemtechnisch umzusetzenden Geschäftsanwendungsfälle in zeitlich kohärente Systemanwendungsfälle.  Erstelle ein Systemanwendungsfallmodell. Stärken Sie die Bereitschaft zur Übernahme von Führungsverantwortung.

In vielen Fällen wird Geschäftsprozessmodellierung mit dem Zweck betrieben, die Automatisierung zu verbessern. Hierbei können die Ergebnisse der Geschäftsprozessmodellierung wichtige Rahmenbedingungen und Anforderungen für die Softwareentwicklung darstellen. Die bisher in diesem Buch beschriebene Art der Geschäftsprozessmo- UML dellierung basiert unter anderem auf der Unified Modeling Language (UML), einer Modellierungssprache für die Softwareentwicklung. Dadurch ist nun ein bruchloser Übergang von der Geschäftsprozessmodellierung zur Softwareentwicklung möglich. In den vorigen Kapiteln wurde gezeigt, wie Geschäftsprozesse und Geschäftsanwendungsfälle identifiziert und detailliert wurden. Sofern eine neue oder bessere softwaretechnische Unterstützung der Geschäftsprozesse beabsichtigt ist, sind auf dieser Grundlage Anforderungen für die Software abzuleiten, weiter zu verfeinern und umzusetzen. Entscheide für jeden vorliegenden Geschäftsanwendungsfall, ob UML: Systemanwendungsund wie er systemtechnisch umgesetzt werden soll. Sofern ein Ge- fälle 168 schäftsanwendungsfall im Softwaresystem zu berücksichtigen ist, definieren wir hierfür entsprechende Systemanwendungsfälle. Das Konzept der Anwendungsfälle bleibt also weiterhin erhalten, für die technische Implementierung jedoch in der etwas restriktiveren und formaleren Form der so genannten Systemanwendungsfälle. Es ist nicht nur zu entscheiden, dass ein Geschäftsanwendungsfall systemtechnisch umzusetzen ist, wir müssen auch bestimmen, wie dies geschehen soll, beispielsweise auf welcher technischen Plattform. Nehmen wir an, der Geschäftsanwendungsfall Kfz reservieren soll softwaretechnisch unterstützt werden. Hier gäbe es die Möglichkeit,

134

3.19 Systemanwendungsfälle definieren Fordern Sie Führungskompetenz.

diesen Anwendungsfall in folgenden Softwaresystemen zu berücksichtigen:  Onlinebuchungssystem im Internet Die Mieter reservieren ihre Kfz selbst.  Buchungssystem im Callcenter Die Mieter rufen im Callcenter an, der Callcenter-Agent reserviert für den Mieter im Buchungssystem.  Buchungssystem an der Mietstation Der Mieter kommt direkt an den Schalter einer Vermietstation. Der dortige Stationsmitarbeiter reserviert für den Mieter ein Kfz.  Buchungssystem eines Agenten Der Mieter wendet sich an eine Agentur, beispielsweise ein Reisebüro. Der Agent bucht für den Mieter ein Kfz. Fordern Sie Führungskompetenz.

In jedem einzelnen dieser möglichen Systemanwendungsfälle sind spezifische Anforderungen und ggf. auch spezifische Abläufe zu berücksichtigen:  Bei einer Onlinebuchung im Internet muss der Mieter wahrscheinlich eine Kundennummer und ein Zugangskennwort eingeben.  Im Callcenter und an der Mietstation reicht es wahrscheinlich, wenn der Mieter seinen Namen und seine Kundennummer nennt, wobei für die Reservierung übers Callcenter vielleicht ein Bearbeitungsaufschlag erhoben wird.  Bei der Buchung über eine Agentur sind wahrscheinlich eine Agenturnummer, ein Agenturzugangskennwort, besondere Rabatte und Tarife sowie Provisionen zu berücksichtigen. Leitfragen  Welche konkreten Implementierungsvarianten sind möglich?  Welche Plattformen und Medien kommen für die Implementierung in Frage?  Welche dieser Möglichkeiten sollen umgesetzt werden?  Welche speziellen Sachverhalte sind in Systemanwendungsfällen zu berücksichtigen?

den

einzelnen

 Was muss in den verschiedenen Plattformen oder Medien anders ausgeprägt sein? Worin bestehen die Unterschiede im Detail?  Welche speziellen fachlich zu berücksichtigenden Abbruch- und Fehlermöglichkeiten existieren?

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.19 Systemanwendungsfälle definieren Erkennen Sie Ängste bei Mitarbeitern und bauen sie diese Ängste ab.

Wir können diese Möglichkeiten auch grafisch in einem UML- UML: RealisierungsAnwendungsfalldiagramm darstellen. In Abb. 3.19-1 ist der Geschäfts- beziehung 156 anwendungsfall Kfz reservieren zu sehen und darunter die vier möglichen Realisierungen. Der Pfeil dazwischen ist eine so genannte Realisierungsbeziehung. Dies bedeutet, dass das Element, von dem der Pfeil wegführt, die Sachverhalte umsetzt und realisiert, die in dem Element beschrieben sind, auf das der Pfeil zeigt. Kfz reservieren

Kfz online reservieren

Kfz telefonisch reservieren

Kfz an Station reservieren

Kfz über Agentur reservieren

Abb. 3.19-1: Mögliche Systemanwendungsfälle für Kfz reservieren Erkennen Sie Ängste bei Mitarbeitern und bauen sie diese Ängste ab.

Im folgenden Text gehen wir davon aus, dass der Anwendungsfall Kfz online reservieren systemtechnisch implementiert werden soll. Der Geschäftsanwendungsfall Kfz reservieren wurde zuletzt in Kapitel Vgl. Kfz reservieren 3.11 Geschäftsanwendungsfall-Abläufe modellieren verfeinert. Der Abb. 3.12-5 (108) letzte detaillierte Ablauf war in Abb. 3.12-5 (108) zu sehen. Im Gegensatz zu dem in Abb. 3.12-5 beschriebenen Ablauf macht es bei der Onlinereservierung laut Fachabteilung keinen Sinn, die Kundendaten im Rahmen der Kfz-Reservierung aufzunehmen. Eine Möglichkeit zur Onlinereservierung erhalten nur registrierte Kunden, die bereits über eine Kundennummer und ein Zugangskennwort verfügen. Hierfür muss es demnach einen eigenen Systemanwendungsfall Benutzer registrieren o.Ä. geben. Außerdem wurden bereits für Abb. 3.12-1 (104) verschiedene Varianten der Kfz-Verfügbarkeitsprüfung diskutiert, wobei bereits dort deutlich geworden ist, dass ein Vergleich der Varianten teilweise nur unter Einbeziehung systemtechnischer Umsetzungen möglich ist. Im Gegensatz zur Lösung in Abb. 3.12-5 (108) wählen wir nun die in Abb. 3.12-1 (104) beschriebene Variante a, bei der die Kfz-TypVerfügbarkeit und die Alternative Kfz-Typ-Verfügbarkeit parallel geprüft werden. Unser Systemanwendungsfall sieht demnach wie in Abb. 3.19-2 dargestellt aus.

135

136

3.19 Systemanwendungsfälle definieren Gewinnen Sie weitere Handlungs- und Veränderungsoptionen.

Kfz online reservieren

[Abbrechen]

Kunde identifizieren

[nicht verfügbar]

[Abbrechen]

Reservierungswunsch aufnehmen [Kurzfristige Reservierung]

KfzVerfügbarkeit prüfen

[ok]

Kfz-TypVerfügbarkeit prüfen

[ok]

Alternative KfzTyp-Verfügbarkeit prüfen

[nicht verfügbar]

[ok] [nicht verfügbar]

[ok]

[alternativen Reservierungswunsch aufnehmen]

[alternativen Kfz-Typ anbieten]

Kfz reservieren [Abbrechen] [ok]

Reservierung bestätigen

[ok]

Kfz-Typ reservieren

[Abbrechen]

Kfz online reserviert

Abgebrochen

Abb. 3.19-2: Systemanwendungsfall Kfz online reservieren Gewinnen Sie weitere Handlungs- und Veränderungsoptionen.

Unterschied Geschäfts- und Systemanwendungsfall

Ergänze ggf. fehlende fachliche Ausnahmen und Varianten, beispielsweise fachlich sinnvolle Abbruchmöglichkeiten. Sobald eine konkrete technische Umsetzung betrachtet wird, ergeben sich weitere umsetzungsspezifische Ausnahmen und Varianten, beispielsweise fachlich sinnvolle Abbruchmöglichkeiten. In unserem Beispiel sind folgende Abbruchmöglichkeiten sinnvoll (vgl. Abb. 3.19-2):  Beim Identifizieren des Kunden muss die Kundennummer und ein Zugangskennwort eingegeben werden. Wenn dies mehrmals hinter-

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.19 Systemanwendungsfälle definieren Gestalten Sie Kompetenzen, Aufgaben- und Verantwortungsbereiche um,

137

einander scheitert, wird der Kunde wahrscheinlich abbrechen wollen.  Beim Aufnehmen des Reservierungswunsches ist es ähnlich. Sofern keine oder keine passenden Kfz zu dem genannten Reservierungswunsch gefunden werden, kann dieser geändert bzw. neu eingegeben werden. Wenn auch dies nach mehreren Versuchen erfolglos bleibt, wird der Benutzer abbrechen wollen.  Beim Reservieren eines Kfz oder Kfz-Typs besteht die letzte Möglichkeit für den Benutzer, es sich noch mal anders zu überlegen und abzubrechen. Alle anderen Aktivitäten in dem Ablaufdiagramm sind demnach nicht vom Benutzer abbrechbar. Gestalten Sie Kompetenzen, Aufgaben- und Verantwortungsbereiche um,

Zerlege die systemtechnisch umzusetzenden Geschäftsanwendungsfälle in zeitlich kohärente Systemanwendungsfälle. Ein wichtiger Unterschied zwischen Geschäfts- und Systemanwendungsfällen ist ihr Zweck. Beim Geschäftsanwendungsfall werden Aspekte der konkreten technischen Umsetzung außen vor gelassen. Beim Systemanwendungsfall wird genau dies detailliert berücksichtigt. Zusätzlich besteht an die Systemanwendungsfälle die Forderung, dass Zeitliche Kohärenz sie eine zeitliche Kohärenz aufweisen, d.h., Systemanwendungsfälle Was heißt das? sollen Abläufe beschreiben, die zeitlich zusammenhängend und ununterbrochen sind. Ein Ablauf sollte ggf. in einzelne Systemanwendungsfälle zerlegt werden, wenn er unterbrochen werden kann. Dabei sind jedoch nur solche Unterbrechungsmöglichkeiten interessant, bei denen der aktuelle Zustand bzw. Kontext gesichert wird. Nicht jede mögliche kleinste zeitliche Unterbrechung, beispielsweise wenn ein Telefongespräch durch ein Störgeräusch für einige Sekunden inhaltlich unterbrochen wird, wird hier betrachtet, sondern nur solche, bei denen auch die bis dahin erzielten Zwischenergebnisse explizit gesichert wurden und wieder herstellbar sind. Ruft beispielsweise ein Kunde im Callcenter an und die Telefonleitung Zustandsgesicherte Unterwird vor Abschluss der Reservierung oder Bestellung unterbrochen und brechungsmöglichkeit der Kunde ruft anschließend noch mal an, stellt sich die Frage, ob das Gespräch beim letzten Stand wieder aufsetzen kann. Dazu wäre es notwendig, das abgebrochene Gespräch wieder zu identifizieren. In den meisten Fällen ist dies nicht möglich, weshalb beispielsweise Callcenter-Gespräche gewöhnlich als zeitlich kohärent angesehen werden. Statt von zeitlicher Kohärenz kann hier auch von einer fachlichen Fachliche Transaktion gesprochen werden. Eine Transaktion ist ein Vorgang, der Transaktion entweder vollständig oder gar nicht vollzogen werden kann. Das heißt, wenn der Vorgang mittendrin aufhört oder abgebrochen wird, ist dies

138

3.19 Systemanwendungsfälle definieren so dass die gemeinsamen Ziele besser erreicht werden können.

so, als hätte der Vorgang nie stattgefunden, der Zustand ist derselbe wie vorher. Technische Transaktionen

Transaktionen gibt es auch auf rein technischer Ebene, beispielsweise Datenbanktransaktionen. Dies sind Operationen (Datenspeicherung, Datenänderung) auf einer Datenbank, die stets ganz oder gar nicht vollzogen werden, so dass der Datenbankinhalt niemals in einen ungeplanten oder inkonsistenten Zustand geraten kann. Aus einem Geschäftsanwendungsfall können also je nach gewünschter fachlicher Transaktionalität ein oder mehrere Systemanwendungsfälle resultieren.

Transaktion Kunde identifizieren

In unserem Beispiel stellt Kunde identifizieren eine eigene Transaktion dar. Sobald Kundennummer und Zugangskennwort richtig eingegeben wurden, ist und bleibt der aktuelle Kunde bekannt. Dieses Ergebnis (d.h. dieser Systemzustand) bleibt erhalten, auch für die nachfolgenden Aktivitäten. Kunde online identifizieren

Kunde identifizieren

Kunde identifiziert

[Abbrechen]

Abgebrochen

Abb. 3.19-3: Systemanwendungsfall Kunde online identifizieren so dass die gemeinsamen Ziele besser erreicht werden können.

Alle übrigen Aktivitäten von Reservierungswunsch aufnehmen bis einschließlich Kfz-Reservierung bestätigen stellen ebenfalls eine Transaktion dar. Die einzelnen Zwischenschritte hinterlassen im Abbruchfall kein andauerndes Ergebnis, das heißt keine bestehen bleibende Änderung des Systemzustandes. Wenn der Reservierungswunsch aufgenommen wurde und anschließend bricht beispielsweise die Onlineverbindung zusammen, dann ist der eingegebene Reservierungswunsch verloren. Der Benutzer müsste mit der Reservierung wieder von vorne anfangen. Ebenso wenn der Benutzer sich für Abbrechen entschieden hat. Die drei verschiedenen Aktivitäten zur Verfügbarkeitsprüfung liefern jeweils eine Ergebnismenge (freie Kfz), ohne dass diese Kfz aber reserviert würden oder andere Änderungen in der Datenbank vorgenommen würden. Im Abbruchfalle gingen die Ergebnismengen verloren.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.19 Systemanwendungsfälle definieren Erkennen Sie persönliche Verstrickungen.

Kfz reservieren und Kfz-Typ reservieren verändern den Systemzustand, sie speichern nämlich eine Reservierung in der Datenbank und erzeugen wahrscheinlich eine eindeutige Reservierungsnummer. Hier findet eine Veränderung des Systemzustandes statt. Da diese beiden Aktivitäten aber immer nur alternativ zueinander laufen, also nie gleichzeitig ein Kfz und ein Kfz-Typ innerhalb einer Onlinereservierung reserviert werden, wird nur eine einzelne Transaktion begründet. Erkennen Sie persönliche Verstrickungen.

Kfz-Reservierung bestätigen verändert auch den Systemzustand, dadurch dass eine Bestätigung erzeugt und wahrscheinlich per E-Mail versendet wird. Dies ist dann auch nicht mehr rückgängig zu machen. Kfz online reservieren

[nicht verfügbar]

[Abbrechen]

Reservierungswunsch aufnehmen [Kurzfristige Reservierung]

KfzVerfügbarkeit prüfen

[ok]

Kfz-TypVerfügbarkeit prüfen

[ok]

Alternative KfzTyp-Verfügbarkeit prüfen

[nicht verfügbar]

[ok] [nicht verfügbar]

[ok]

[alternativen Reservierungswunsch aufnehmen]

[alternativen Kfz-Typ anbieten]

Kfz reservieren [Abbrechen] [ok]

Reservierung bestätigen

[ok]

Kfz-Typ reservieren

[Abbrechen]

Kfz online reserviert

Abgebrochen

Abb. 3.19-4: Systemanwendungsfall Kfz online reservieren (konsolidiert) (Bezugnahme zu dieser Abbildung auf der nächsten Seite…)

Um Transaktionsgrenzen zu bestimmen, werden die Aktivitäten also zunächst dahingehend bewertet, ob sie eine Veränderung des Systemzustandes bewirken (Ergebnisse nach außen gegeben oder in Datenbank gespeichert). Anschließend ist zu entscheiden, welche dieser zu-

139

140

3.19 Systemanwendungsfälle definieren Erweitern Sie den Blick und lassen Sie mehr aufs Ganze schauen.

standsändernden Aktivitäten unabhängig laufen dürfen und welche immer nur gemeinsam, d.h. entweder alle oder keine. In unserem Fall gibt es keinen sinnvollen Grund, warum die Reservierungsbestätigung losgelöst von Kfz(-Typ) reservieren laufen sollte. Wenn ein Kfz (oder Kfz-Typ) reserviert wurde, dann soll dies auch immer bestätigt werden. Ohne Reservierungsbestätigung könnte der Benutzer denken, die Reservierung wäre gescheitert. Daher wird der Block von Reservierungswunsch aufnehmen bis Reservierung bestätigen als eine Transaktion gesehen. Der in Abb. 3.19-2 gezeigte Systemanwendungsfall muss also in zwei einzelne Systemanwendungsfälle aufgeteilt werden: Kunde online identifizieren (Abb. 3.19-3) und Kfz online reservieren (Abb. 3.19-4). Erweitern Sie den Blick und lassen Sie mehr aufs Ganze schauen.

Erstelle ein Systemanwendungsfallmodell. In gleicher Art und Weise, wie dies bereits im Kapitel 3.15 Geschäftsanwendungsfallmodell erstellen (118) gezeigt wurde, können wir nun ein Systemanwendungsfallmodell entwickeln. Damit werden die Zusammenhänge zwischen den einzelnen Systemanwendungsfällen grafisch dargestellt. Kunde online identifizieren

«include» Kunde

«secondary» Kfz online reservieren

Abb. 3.19-5: Systemanwendungsfallmodell Kfz online reservieren

Weiterführende Literatur: Wenn Sie erfahren möchten, wie es in der Softwareentwicklung mit Analyse, Entwurf, Test und Implementiertung weitergeht, empfehlen wir Ihnen das Buch Objektorientierte Softwareentwicklung, Analyse und Design mit der UML von Bernd Oestereich. Es ist ähnlich strukturiert wie dieses Buch über Geschäftsprozessmodellierung und beruht auf dem gleichen Fallbeispiel. Oder Sie schauen in den OEP (www.oose.de/oep). [Oestereich01a] B. Oestereich: Objektorientierte Softwareentwicklung: Analyse und Design mit der UML. 5. Auflage, Oldenbourg, München, 2001.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.20 Glossar und Abkürzungsverzeichnis entwickeln

141

Geben Sie Anerkennung.

3.20 Glossar und Abkürzungsverzeichnis entwickeln Extrakt  Lege ein fachliches Glossar an und definiere dort alle wichtigen fachlichen Begriffe.  Stimme alle Begriffe mit den wichtigsten Stakeholdern ab.  Lege ein Abkürzungsverzeichnis an. Geben Sie Anerkennung.

Während der Geschäftsprozessmodellierung begegnen wir permanent Verstehen wir uns richtig? den Fachbegriffen des untersuchten Unternehmens bzw. Modellierungsfokus. Hierbei kommt es immer wieder vor, dass verschiedene Parteien sehr selbstverständlich Fachbegriffe gebrauchen und dabei fahrlässig unterstellen, dass die jeweils andere Partei das Gleiche darunter versteht. Wenn dies aber nicht der Fall ist, was regelmäßig vorkommt, kann dies zu Fehlentwicklungen, mindestens jedoch zu einer ineffizienten Geschäftsprozessmodellierung führen. Warum ein Glossar? Gerade scheinbar einfache Basisbegriffe wie etwa Kunde werden häufig von verschiedenen Personen unterschiedlich interpretiert. Der eine versteht unter Kunden nur Firmenkunden, ein anderer selbstverständlich auch einzelne Abteilungen beim Kunden, noch ein anderer alle natürlichen und juristischen Personen, die eine Kundennummer haben, und jemand aus dem Marketing versteht unter Kunde vielleicht alle Personen, deren Adresse man hat. Verschiedene Personen im Modellierungsfokus betrachten die mit den Unterschiedliche Blickwinkel Begriffen bezeichneten Objekte aus teilweise sehr unterschiedlichen und Definitionen Blickwinkeln und sehen ganz unterschiedliche Ausprägungen, Verantwortlichkeiten, Eigenschaften, Rollen etc. Ein gemeinsames Glossar trägt dazu bei, die Fehlkommunikation zu reduzieren, bislang unerkannte Missverständnisse aufzudecken und die verwendeten Begriffe zu vereinheitlichen. Manchmal existieren mehrere widersprüchliche Definitionen eines Umgang mit widersprüchliBegriffes, die jeweils für sich genommen sinnvoll und richtig sind, und chen Definitionen es keinen Sinn ergibt, den verschiedenen Beteiligten zur Widerspruchsvermeidung einen fremden Alternativbegriff aufzuzwingen. In solchen Fällen ist es nicht nur akzeptabel, sondern wünschenswert, unterschiedliche, vielleicht sogar widersprüchliche Definitionen gleichberechtigt gelten zu lassen und gemeinsam in das Glossar aufzunehmen.

142

3.20 Glossar und Abkürzungsverzeichnis entwickeln Bauen Sie bei anderen Selbstvertrauen auf.

In der Definition dieser Begriffe wird dann einfach darauf hingewiesen, in welchem Kontext die jeweilige Variante verwendet wird. Wenn solche Abweichungen nicht aufgelöst werden können, werden diese Fälle somit zumindest dokumentiert. Untersuchungen (z.B. von [Irion95]) belegen, dass der unrealistische Versuch, unikate Begriffe zu erzwingen, eher teurer ist. Leitfragen  Ist die Begriffsdefinition so kurz und knapp wie möglich formuliert? Der Zweck unseres Glossars ist nicht die erschöpfende Erklärung oder Anforderungsdefinition, sondern die Vermeidung von Missverständnissen, Verwechselungen und Fehlinterpretationen.  Hinterfrage für jeden Begriff: In welcher Weise könnte die Definition falsch verstanden werden? Welche Informationen müssen hinzugefügt werden, um dies auszuschließen?  Hinterfrage für jeden Begriff: Welche Informationen können aus der Definition gestrichen werden, ohne dass Fehlinterpretationen wahrscheinlich werden?

Struktur des Glossars. Wir schlagen für das Glossar folgende Beschreibungsstruktur vor:  Begriff  Mögliche Synonyme  Definition (ca. 1 - 5 Sätze)  Eventuelle ähnliche oder gegensätzliche Begriffe oder Definitionen. Falls notwendig Beschreibung des speziellen Verwendungsbereiches oder Kontextes und Abgrenzung zu anderen Bereichen bzw. Definitionen. Ggf. nähere Erläuterungen oder Anwendungsbeispiele  Einschränkungen, auf bestimmte Anwendungsbereiche, Mandanten o.Ä.  Definitionsverantwortlicher, Ansprechpartner, Grundlagen, Herkunft, Begriffshistorie o.Ä.  Status (draft/Entwurf, final/Endgültig )  Änderungshistorie, d.h. Datum und Autoren der letzten Bearbeitung. Bauen Sie bei anderen Selbstvertrauen auf.

Ein Beispiel sehen Sie in Abb. 3.20-1. Lege ein Abkürzungsverzeichnis an. Häufig sind die am meisten zu benutzenden Fachbegriffe nicht die kürzesten, so dass die an der Geschäftsprozessmodellierung beteiligten Personen früher oder später Abkürzungen verwenden. Nicht immer benutzen verschiedene Perso-

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

3.20 Glossar und Abkürzungsverzeichnis entwickeln (Bernd Oestereich)

nen dabei die gleichen Abkürzungen, was dann wiederum bald zur Fehlkommunikation führt. Um diesem möglichen Problem entgegenzuwirken und um die Verwendung von Abkürzungen einfacher zu gestalten, legen wir ein Abkürzungsverzeichnis an. Etwa so wie das Abkürzungsverzeichnis in diesem Buch (219). Es ist dabei völlig ausreichend, nur die Abkürzungen aufzunehmen, bei denen eine Fehlkommunikation wahrscheinlich ist oder die häufig verwendet werden. Begriff

Fahrer

Synonyme Definition

Ein Mensch, der ein Kfz fährt, fahren soll oder gefahren hat.

Abgrenzung

Mieter und Kunde (können im Gegensatz zum Fahrer auch Firmen sein).

Einschränkungen Ansprechpartner Status

final

Änderungen

10.10.2002 17.10.2002

Abb. 3.20-1: Glossareintrag Fahrer (Bernd Oestereich)

Bernd Oestereich Claudia Schröder

Definition erstellt (Entwurf) Definition abgestimmt (final)

143

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4 UML – Notation und Semantik

Kontinuierliche Verbesserungen sind besser als hinausgezögerte Vervollkommnung. Mark Twain

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.1 UML

4.1

UML

Im Kapitel 3 OOGPM-Methodik wurde die Methodik der Geschäftsprozessmodellierung anhand eines Fallbeispiels vorgeführt. Dabei wurden verschiedene Diagrammtypen und Modellierungselemente verwendet, die größtenteils aus der UML (Unified Modeling Language) stammen. Die UML ist ursprünglich eine Notation zur Spezifikation, Konstruktion, Visualisierung und Dokumentation von Modellen für Softwaresysteme, die sich aber auch, wie wir hier zeigen, für die Modellierung von Geschäftsprozessen eignet. Während in den vorigen Kapiteln die Diagramm- und Modellelemente der UML einfach angewendet wurden, ohne sie jeweils detailliert zu beschreiben, finden Sie in diesem Kapitel nun die ausführliche Erläuterung aller verwendeten UML-Elemente. Die UML ist eine flexible und erweiterbare Notation. In ihrem Ur- UML-Standard, sprung ist sie für die Modellierung von Software ausgelegt und enthält UML-Profil nicht alle Elemente, die für die Modellierung von Geschäftsprozessen notwendig sind. Nach festgelegten formalen Regeln können jedoch Erweiterungen vorgenommen werden (so genannte Profile). Im Folgenden finden sich neben Standard-UML-Elementen auch die für die Geschäftsprozessmodellierung notwendigen Erweiterungen. Die UML ist durch die OMG (Object Management Group) standardisiert worden und gilt daher als Industriestandard. Alle Firmen, die Rang und Namen haben, unterstützen die UML oder sind an ihrer (Weiter-) Entwicklung beteiligt: IBM, Microsoft, Sun, Hewlett-Packard, Oracle, Rational (mittlerweile zu IBM gehörend), um nur einige zu nennen. Das vorliegende Buch bezieht sich auf die in Arbeit befindliche Version 2.0 der UML, die zum Redaktionsschluss des Buches noch nicht offiziell verabschiedet war. Sofern die endgültige und offizielle Version 2.0 der UML jedoch von den hier im Buch verwendeten Konstrukten abweichen sollte, finden Sie entsprechende Hinweise auf unseren Internetseiten http://www.oogpm.de. Nähere und aktuelle Informationen zur UML finden Sie unter www.oose.de/uml. Viele der Texte und Abbildungen in diesem Kapitel 4 UML – Notation und Semantik stammen von der Firma oose.de Dienstleistungen für innovative Informatik GmbH und wurden von dieser freundlicherweise zur Verfügung gestellt.

147

148

4.2 Akteur

4.2

Akteur

Stereotyp, Teil des OOGPM-Profils. Verwandte Begriffe: actor, Beteiligter, Stakeholder, Anwender, Ereignis, externes System, Klasse. Definition Ein Akteur ist eine Person oder ein externes System, das mit dem modellierten System interagiert. System kann hierbei ein Geschäfts-, Hardware- oder Softwaresystem sein. Bei der Modellierung von Softwaresystemen können dies also die Benutzer oder andere externe Systeme, z.B. SAP, sein. Bei der Modellierung von Geschäftsprozessen können dies Geschäftspartner, wie Kunden oder Lieferanten, sein. Wir repräsentieren aber auch die innerhalb des betrachteten Systems beteiligten Akteure, beispielsweise Geschäftsmitarbeiter. Außerdem ist es möglich, auch Ereignisse, wie Zeitereignisse (z.B. Monatswechsel), als Akteure zu modellieren. Notation Akteure werden in der UML als Rechtecke dargestellt, die textuell oder grafisch weiter klassifiziert („stereotypisiert“) werden, wie in Abb. 4.2-1 gezeigt. «actor» Akteur

Abb. 4.2-1: Grundsätzliche Akteur-Notationen der UML

Akteure, die üblicherweise Menschen repräsentieren, werden als Strichfiguren dargestellt. Solche, die andere technische Systeme oder Ereignisse repräsentieren, werden als Würfel oder beispielsweise Uhr notiert. 11

12

1 2

10

3

9 8

4 7

Menschlicher Akteur

Fremdsystem als Akteur

6

5

Zeitereignis

Abb. 4.2-2: Übliche grafische Symbole („Stereotypen“) zur Unterscheidung von Menschen, Systemen und Zeitereignissen

Semantik Grundsätzlich repräsentieren Akteure, keine konkreten Personen (bspw. Gabi Goldfisch oder Elch-Reise-GmbH), sondern Rollen (d.h. Kunde,

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.2 Akteur

Reisebüro etc.). Ausnahmen sind ggf. Akteure, die es per Definition oder durch Monopolstellung nur als eine einzelne konkrete Ausprägung gibt (bspw. Kraftfahrzeugbundesamt oder Deutsche Bahn). Formal sind alle hier von uns verwendeten Arten von Akteuren stereotypisierte Klassen, so wie es auch einige UML-Modellierungswerkzeuge handhaben (z.B. Rational Rose). Das heißt, es handelt sich nicht um das gleichnamige Standard-UML-Element Akteur (actor), da dies nicht akzeptablen semantischen Einschränkungen unterliegt und beispielsweise keine Geschäftsmitarbeiter zuließe. Erläuterung In Kombination mit anderen UML-üblichen Symbolen können die Akteure weiter differenziert werden, beispielsweise in folgende (Abb. 4.2-3) für die Geschäftsprozessmodellierung relevante menschliche Akteur-Arten. Modellierungsfokus / betrachtetes Unternehmen z.B. Kunde Aktiver Geschäftspartner

z.B. Lieferant Passiver Geschäftspartner

z.B. Kundenbetreuer

Außenorientierter Geschäftsmitarbeiter

z.B. Lohnbuchhalter

Innenorientierter Geschäftsmitarbeiter Kontaktrichtung (wer wendet sich anfangs an wen?)

Abb. 4.2-3: Für die Geschäftsprozessmodellierung relevante Arten von Akteuren

Für die Geschäftsprozessmodellierung werden verschiedene Arten von Akteuren eingesetzt, die in den folgenden Abschnitten näher erläutert werden. Akteure werden verwendet, um grafisch darzustellen, wer an welchen Geschäftsprozessen oder Anwendungsfällen beteiligt ist. Hierzu werden innerhalb von Anwendungsfalldiagrammen Akteure und Geschäftsprozesse bzw. Anwendungsfälle mit einer Linie verbunden. Checkliste für Akteure  Repräsentiert der Akteur eine Rolle und keine konkrete Person?  Trägt der Akteur einen unverwechselbaren Namen? Womit könnte man den Akteur verwechseln, wenn man wollte?  Hat der Akteur mindestens eine Beziehung zu einem Anwendungsfall oder einem anderen Akteur?

149

150

4.2 Akteur

4.2.1 Aktive Geschäftspartner Stereotyp, Teil des OOGPM-Profils. Definition Als aktive Geschäftspartner werden (natürliche oder juristische) Personen bezeichnet, die außerhalb des betrachteten Unternehmens (Modellierungsfokus) stehen und ein Geschäft aktiv initiieren. Aktive Geschäftspartner kommen aus eigener Initiative auf das Unternehmen zu und haben ein geschäftliches Anliegen. Aktive Geschäftspartner sind beispielsweise Kunden. Notation

Abb. 4.2-4: Notation Aktiver Geschäftspartner

Aktive Geschäftspartner werden als Strichfiguren dargestellt, die einen Schrägstrich am Kopf tragen und deren Arme (Aktivität symbolisierend) nach oben gerichtet sind. Erläuterungen, Beispiele Weitere Erläuterungen finden Sie im Methodikteil unter  3.4 Aktive Geschäftspartner identifizieren 51  3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren 56 Ein weiteres Notationsbeispiel ist in Abb. 3.5-5 65 zu sehen. Checkliste für aktive Geschäftspartner  Repräsentiert der Akteur eine Rolle und keine konkrete Person?  Trägt der Akteur einen unverwechselbaren Namen? Womit könnte man den Akteur verwechseln, wenn man wollte?  Hat der Akteur mindestens eine Beziehung zu einem Anwendungsfall oder einem anderen Akteur?  Welcher Sachverhalt begründet die Entscheidung, dass der Akteur ein aktiver Geschäftspartner ist?

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.2 Akteur

4.2.2 Passive Geschäftspartner Stereotyp, Teil des OOGPM-Profils. Definition Als passive Geschäftspartner werden (natürliche oder juristische) Personen bezeichnet, die außerhalb des betrachteten Unternehmens (Modellierungsfokus) stehen und von diesem angesprochen werden. Passive Geschäftspartner reagieren auf ein geschäftliches Anliegen des betrachteten Unternehmens. Passive Geschäftspartner sind beispielsweise Lieferanten. Notation

Abb. 4.2-5: Notation Passiver Geschäftspartner

Passive Geschäftspartner werden als Strichfiguren dargestellt, die einen Schrägstrich am Kopf tragen und deren Arme (Passivität symbolisierend) nach unten gerichtet sind. Erläuterungen, Beispiele Weitere Erläuterungen finden Sie im Methodikteil unter  3.4 Aktive Geschäftspartner identifizieren 51  3.6 Weitere unterstützende Geschäftsanwendungsfälle identifizieren 66 Checkliste für passive Geschäftspartner  Repräsentiert der Akteur eine Rolle und keine konkrete Person?  Trägt der Akteur einen unverwechselbaren Namen? Womit könnte man den Akteur verwechseln, wenn man wollte?  Hat der Akteur mindestens eine Beziehung zu einem Anwendungsfall oder einem anderen Akteur?  Welcher Sachverhalt begründet die Entscheidung, dass der Akteur ein passiver Geschäftspartner ist?

151

152

4.2 Akteur

4.2.3 Innenorientierte Geschäftsmitarbeiter Stereotyp, Teil des OOGPM-Profils. Definition Innenorientierte Geschäftsmitarbeiter nennen wir solche Akteure, die sich innerhalb des zu modellierenden Unternehmens befinden und die keinen direkten Kontakt zu Geschäftspartnern haben, die also beispielsweise für Kunden und Lieferanten nicht direkt sichtbar sind. Innenorientierte Geschäftsmitarbeiter arbeiten für andere (innen- und außenorientierte) Geschäftsmitarbeiter. Notation Innenorientierte Geschäftsmitarbeiter werden als Strichfiguren dargestellt, die von einem kreisförmigen Pfeil umgeben sind.

Abb. 4.2-6: Notation Innenorientierter Geschäftsmitarbeiter

Erläuterung Mit innen- bzw. außenorientiert ist nicht gemeint, dass die konkreten Menschen im psychologischen Sinne vom persönlichen Charakter her nach innen oder außen gerichtet sind, sondern dass sie bezogen auf das betrachtete Unternehmen nach innen oder außen gerichtet arbeiten. Weitere Erläuterungen und Beispiele in 3.7 Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln 72, speziell Abb. 3.7-3 74 sowie in Abb. 3.15-1 119. Checkliste für innenorientierte Geschäftsmitarbeiter  Repräsentiert der Akteur eine Rolle und keine konkrete Person?  Trägt der Akteur einen unverwechselbaren Namen? Womit könnte man den Akteur verwechseln, wenn man wollte?  Hat der Akteur mindestens eine Beziehung zu einem Anwendungsfall oder einem anderen Akteur?  Welcher Sachverhalt begründet die Entscheidung, dass der Akteur ein innenorientierter Geschäftsmitarbeiter ist?

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.2 Akteur

4.2.4 Außenorientierte Geschäftsmitarbeiter Stereotyp, Teil des OOGPM-Profils. Definition Außenorientierte Geschäftsmitarbeiter nennen wir solche Akteure, die sich innerhalb des zu modellierenden Unternehmens befinden und die Kontakt zu Geschäftspartnern pflegen, die also beispielsweise mit Kunden und Lieferanten zu tun haben und für diese sichtbar sind. Notation Außenorientierte Geschäftsmitarbeiter werden als Strichfiguren dargestellt, umgeben von einem Kreis, der auf einer Seite mit einer Geraden verbunden ist

Abb. 4.2-7: Notation Außenorientierter Geschäftsmitarbeiter

Erläuterung Mit innen- bzw. außenorientiert ist nicht gemeint, dass die konkreten Menschen im psychologischen Sinne vom persönlichen Charakter her nach innen oder außen gerichtet sind, sondern dass sie bezogen auf das betrachtete Unternehmen nach innen oder außen gerichtet arbeiten. Weitere Erläuterungen und Beispiele in 3.7 Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln 72, Abb. 3.7-1 74 ff. Checkliste für außenorientierte Geschäftsmitarbeiter  Repräsentiert der Akteur eine Rolle und keine konkrete Person?  Trägt der Akteur einen unverwechselbaren Namen? Womit könnte man den Akteur verwechseln, wenn man wollte?  Hat der Akteur mindestens eine Beziehung zu einem Anwendungsfall oder einem anderen Akteur?  Welcher Sachverhalt begründet die Entscheidung, dass der Akteur ein außenorientierter Geschäftsmitarbeiter ist?

153

154

4.2 Akteur

4.2.5 Systemakteure Standard-UML-Element. Definition Ein Systemakteur ist eine Person oder ein externes System das mit einem technischen System (Hard- oder Software) interagiert. Dies können also die Benutzer oder andere externe Systeme, z.B. SAP, sein. Außerdem ist es möglich, auch Ereignisse, wie Zeitereignisse (z.B. Monatswechsel), als Akteure zu modellieren. Notation Systemakteure werden als einfache Strichfiguren oder andere spezielle grafische Symbole dargestellt. 11

12

1

10

2 3

9 8

4 7

Menschlicher Akteur

Fremdsystem als Akteur

6

5

Zeitereignis

Abb. 4.2-8: Symbole für Systemakteure (vgl. Abb. 4.2-2)

Erläuterung Siehe allgemeine Erläuterungen unter 4.2 Akteur 148 sowie im Methodikteil in 3.19 Systemanwendungsfälle 133, speziell Abb. 3.19-5 140. Checkliste für Systemakteure  Repräsentiert der Akteur eine Rolle und keine konkrete Person?  Trägt der Akteur einen unverwechselbaren Namen? Womit könnte man den Akteur verwechseln, wenn man wollte?  Hat der Akteur mindestens eine Beziehung zu einem Anwendungsfall oder einem anderen Akteur?  Welcher Sachverhalt begründet die Entscheidung, dass der Akteur ein Systemakteur ist?

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.3 Anwendungsfallmodell

4.3

Anwendungsfallmodell

Standard-UML-Element. Verwandte Begriffe: use case model, use case diagram, Anwendungsfalldiagramm, Nutzungsfalldiagramm. Definition Ein Anwendungsfallmodell zeigt Beziehungen zwischen Akteuren und Anwendungsfällen. Notation Ein Anwendungsfalldiagramm besteht aus verschiedenen Arten von Akteuren und Anwendungsfällen sowie ihren Beziehungen untereinander. Die einzelnen Elemente werden in den folgenden Abschnitten erläutert.

Geld auszahlen Kontoauszug drucken

Verfügungsberechtigter «include» Filial-KassenMitarbeiter

«include» «secondary» Verfügungsberechtigten identifizieren

Geld am Schalter auszahlen Geld am GAA auszahlen

Abb. 4.3-1: Anwendungsfalldiagramm an einem Bank-Beispiel (GAA = Geldausgabeautomat)

Erläuterungen, Beispiele Weitere Erläuterungen und Beispiele im Geschäftsanwendungsfallmodell erstellen 118.

Methodikteil

3.15

155

156

4.3 Anwendungsfallmodell

4.3.1 Spezialisierung, Realisierung von Anwendungsfällen Standard-UML-Elemente. Verwandte Begriffe: Generalisierung, Spezialisierung, Vererbung, inheritance, realize. Definition Spezialisierung und Generalisierung sind Abstraktionsprinzipien zur hierarchischen Strukturierung der Semantik eines Modells. Eine Spezialisierung (bzw. Generalisierung) ist eine taxonomische26 Beziehung zwischen einem allgemeinen und einem speziellen Element (bzw. umgekehrt), wobei das speziellere Element weitere Eigenschaften hinzufügt und sich kompatibel zum allgemeinen verhält. Eine Realisierung ist eine Beziehung zwischen einem Element, das eine Anforderung beschreibt, und einem Element, das diese Anforderungen umsetzt. Notation Die Spezialisierungsbeziehung wird mit einem großen, nicht ausgefüllten Pfeil dargestellt, wobei der Pfeil von dem speziellen Element zum allgemeinen Element zeigt. Wahlweise werden die Pfeile direkt von den Unterklassen zur Oberklasse gezogen oder zu einer gemeinsamen Linie zusammengefasst. Bei der Realisierung ist die Linie gestrichelt. Reservierung bearbeiten

Kfz reservieren

Kfz online reservieren

Reservierung stornieren

Kfz telefonisch reservieren

Reservierer

Reservierung ändern

Mieter Callcenter Agent

Abb. 4.3-2: Realisierung und Spezialisierung von Anwendungsfällen und Akteuren

Erläuterung Die Spezialisierungsbeziehung kann auf Anwendungsfälle und Akteure angewendet werden. Dabei werden Eigenschaften hierarchisch gegliedert, d.h., Abläufe und Anforderungen allgemeinerer Bedeutung wer26

Griech., taxis: „Anordnung“; Taxonomie: „Einordnung in ein System“.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.3 Anwendungsfallmodell

den allgemeineren Anwendungsfällen oder Akteuren zugeordnet (Oberelement bzw. Superelement, Superakteur) und speziellere Aspekte werden Anwendungsfällen oder Akteuren zugeordnet, die den allgemeineren untergeordnet sind (Unterelement, Subelement). Die Eigenschaften des allgemeineren Elementes werden an die entsprechenden spezielleren weitergegeben, d.h. vererbt. Ein spezialisierter Anwendungsfall verfügt demnach über alle spezifizierten Anforderungen und Eigenschaften seines Ober-Anwendungsfalles. Die Subelemente erben alle Eigenschaften ihrer Oberelemente, können diese überschreiben und erweitern, jedoch nicht elimieren bzw. unterdrücken. Für Anwendungsfälle bedeutet dies beispielsweise, dass ein Schritt in einem Ober-Anwendungsfall auf jeden Fall auch in einem UnterAnwendungsfall enthalten ist. Umgekehrt können im UnterAnwendungsfall zusätzliche Schritte und Anforderungen enthalten sein. Ist einem Anwendungsfall ein Akteur zugeordnet, so wird diese Akteur-Beziehung automatisch auch an alle spezialisierten Anwendungsfälle vererbt, wie dies in der Abb. 4.3-2 am Beispiel des Reservierers zu sehen ist. In dem Unter-Anwendungsfall können Akteure aber spezieller ausgeprägt sein. Eine Realisierungsbeziehung ist statt der Spezialisierung anzuwenden, wenn sich die beteiligten Modellelemente in verschiedenen Modellen befinden, beispielsweise ein Geschäftsanwendungsfall (in einem Geschäftsanwendungsfallmodell) und ein Systemanwendungsfall (in einem Systemanwendungsfallmodell). Weitere Erläuterungen und Beispiele:  3.15 Geschäftsanwendungsfallmodell erstellen 118, speziell Abb. 3.15-2 120  3.19 Systemanwendungsfälle 133, speziell Abb. 3.19-1 135

157

158

4.3 Anwendungsfallmodell

4.3.2 Enthält-Beziehung Standard-UML-Element. Definition Teile von Anwendungsfällen, die in mehreren Anwendungsfällen in identischer Weise vorkommen, können in einen eigenen Anwendungsfall ausgelagert werden und per Enthält-Beziehung wieder eingebunden werden, um so eine redundante Beschreibung der identischen Teile zu vermeiden. Durch die Enthält-Beziehung werden anders als bei der Spezialisierungsbeziehung keine Eigenschaften weitervererbt. Notation Die Enthält-Beziehung wird dargestellt durch einen gestrichelten Pfeil mit offener Pfeilspitze, der in Richtung auf den enthaltenen Anwendungsfall zeigt. Geld auszahlen Geld auszahlen

1. Include: Verfügungsberechtigten identifizieren 2. Auszahlunsbetrag bestimmen 3. Auszahlungsmöglichkeit prüfen 4. Geld auszahlen

«include» Verfügungsberechtigten identifizieren «secondary» Verfügungsberechtigten identifizieren

1. Karte lesen 2. Kartensperre prüfen 3. PIN abfragen 4. PIN prüfen

Abb. 4.3-3: Die Enthält-Beziehung im Anwendungsfalldiagramm und ihre Bedeutung in der Anwendungsfallbeschreibung

Praxis Vgl. sekundärer Anwendungsfall 169

Weitere Erläuterungen und Beispiele in 3.15 118, Abb. 3.15-2 120

Die Enthält-Beziehung sollte nur dann verwendet werden, wenn der eingebundene Teil in mindestens zwei Anwendungsfällen vorkommt, sonst könnte jeder einzelne Schritt ausgelagert werden, wodurch nichts gewonnen würde. Die Enthält-Beziehung wird gewöhnlich sekundäre Anwendungsfälle einbinden, also solche, die einen unvollständigen Ablaufteil enthalten. Theoretisch ist es jedoch auch möglich, andere primäre Anwendungsfälle einzubinden. Über Enthält-Beziehungen eingebundene sekundäre Anwendungsfälle können ihrerseits auch wieder weitere Anwendungsfälle einbinden.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.3 Anwendungsfallmodell

4.3.3 Assoziation in Anwendungsfalldiagrammen Standard-UML-Element. Verwandte Begriffe: Include-Beziehung, Assoziation in Klassendiagrammen. Definition Eine Assoziation beschreibt die Relation zwischen zwei Akteuren oder einem Akteur und einem Anwendungsfall in einem Anwendungsfallmodell. Wenn es eine gerichtete Assoziation ist, wird damit die Initiativrichtung beschrieben, d.h., wer die Interaktion beginnt. Notation Beziehungen werden durch eine Linie zwischen den beteiligten Elementen dargestellt. An den jeweiligen Enden kann die Multiplizität (Mengenwertigkeit) der Beziehung angegeben werden. Wenn eine Richtung angegeben wird, zeigt der Pfeil von dem initiierenden Element auf das initiierte. Anwendungsfall 1 Initiierender Akteur

* Akteur

Abb. 4.3-4: Assoziation zwischen Akteur und Anwendungsfall

Einige weitere Beispiele sind in Abb. 3.7-1 ff. (74 ff.) zu sehen.

159

160

4.3 Anwendungsfallmodell

4.3.4 Anwendungsfall (allgemein) Standard-UML-Element. Verwandte Begriffe: Use Case, Nutzungsfall, Szenario. Definition Ein Anwendungsfall beschreibt einen Arbeitsablauf aus der Sicht seiner Akteure. Ein Anwendungsfall wird stets durch einen Akteur initiiert und führt zu einem für die Akteure wahrnehmbaren Ergebnis. Es werden verschiedene Arten von Anwendungsfällen unterschieden, die in den folgenden Abschnitten näher erläutert werden: Geschäftsprozess (163), Geschäftsanwendungsfall (165), Kern-Geschäftsanwendungsfall (166), unterstützender Geschäftsanwendungsfall (167) und Systemanwendungsfall (168). Notation Ein Anwendungsfall wird grafisch dargestellt durch eine Ellipse, in (oder unter) der der Name des Anwendungsfalles steht. Anwendungsfälle sind durch Linien mit den an ihnen beteiligten Akteuren verbunden. Anwendungsfälle können untereinander Beziehungen haben (Spezialisierungs-, Enthält- und Erweitert-Beziehung). Anwendungsfall

«include» Akteur Spezialisierter Anwendungsfall

«secondary» Anwendungsfall

Abb. 4.3-5: Notation von Anwendungsfällen

UML: Aktivitätsdiagramm 175

Kern eines Anwendungsfalles ist aber nicht seine grafische Darstellung, sondern die Beschreibung eines Arbeitsablaufes. Dieser kann in natürlicher Sprache formuliert sein oder in formaler Form als Aktivitätsdiagramm. Die natürlichsprachliche Beschreibung ist nicht zwingend an eine bestimmte Form gebunden, jedoch hat sich die in Abb. 4.3-6 verwendete Struktur bewährt.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.3 Anwendungsfallmodell

Beschreibung Anwendungsfall Name Kurzbeschreibung Akteure Auslöser Ergebnis(se) Eingehende Daten Vorbedingungen Nachbedingungen Essenzieller Ablauf

 …  …  usw.

Offene Punkte Änderungshistorie

wann wer

neuer Status was

Sonstiges, Anmerkungen Abb. 4.3-6: Typische Struktur einer natürlichsprachlichen Anwendungsfallbeschreibung

Praxis Viele geschäftliche und technische Abläufe und Sachverhalte lassen sich sehr gut mit speziellen Diagrammtechniken beschreiben, wie sie auch in diesem Buch zu finden sind, z.B. Aktivitätsdiagramme oder Klassendiagramme. Problematisch hierbei ist jedoch, dass diese Diagramme nur von Spezialisten erstellt und gelesen werden können und Anwender, Fachabteilungsmitarbeiter, Geschäftsmitarbeiter und Geschäftspartner diese nicht oder nur unzureichend verstehen. Dieser Personenkreis muss die dargestellten Sachverhalte aber verstehen und sogar kritisch beurteilen können, da nur sie letztendlich befähigt oder autorisiert sind, die Richtigkeit festzustellen. Die Grundidee bei Anwendungsfällen ist es daher, Abläufe möglichst in der Sprache der Anwender und Fachabteilungen zu beschreiben, also in Deutsch oder Englisch, und nicht in der speziellen Form oder Sprache der Informatiker oder Betriebsorganisatoren. Andererseits finden natürlichsprachliche Beschreibungen schnell ihre Grenzen. Natürliche Sprache ist deutlich unschärfer, kann vieldeutig interpretiert werden und komplexe Abläufe lassen sich grafisch viel übersichtlicher darstellen. Seitenlange Textdokumente verstauben eher in Regalen oder auf Festplatten, als dass sie noch sinnvoll genutzt werden. Daher sind natürlichsprachliche Anwendungsfallbeschreibungen kein vollständiger Ersatz für grafische Darstellungen, sondern lediglich eine wichtige Ergänzung.

161

162

4.3 Anwendungsfallmodell

Bei natürlichsprachlichen Dokumenten besteht auch stets das Problem, dass verschiedene Personen dieselben Sachverhalte sehr unterschiedlich beschreiben. Die Ergebnisse unterscheiden sich dann hinsichtlich des Abstraktionsgrades, der Detailtiefe, des Blickwinkels (von innen, von außen), des Sprachstils, der Verbindlichkeit und Vollständigkeit. Daher ist es sehr wichtig, dass alle Autor(inn)en von Anwendungsfallbeschreibungen sich um Einheitlichkeit bemühen. Hierbei helfen die oben dargestellte Standard-Beschreibungsstruktur sowie folgende Regeln:  An jedem Anwendungsfall ist mindestens ein Akteur beteiligt.  Jeder Anwendungsfall hat einen fachlichen Auslöser und ein fachlich relevantes und wertvolles Ergebnis.  Die Beschreibung wird stets aus Sicht des Systems bzw. Modellierungsfokus formuliert, inhaltlich jedoch das Verhalten beschrieben, das für den (außenstehenden) Akteur wahrnehmbar ist.  Die Beschreibung sollte so kurz und abstrakt wie möglich sein und so ausführlich und konkret, wie zum eindeutigen Verständnis nötig ist. Kap. 3.10 87

Weitere wichtige Regeln und Hinweise entnehmen Sie bitte dem Kapitel 3.10 Geschäftsanwendungsfälle essenziell beschreiben. Weitere Beispiele finden Sie in Abb. 3.5-4 (64) und Abb. 3.6-3 70). Checkliste für Anwendungsfälle  Ist mindestens ein Akteur beteiligt?  Enthält die Anwendungsfallbezeichnung mindestens ein Substantiv und ein aktives Verb?  Sind Auslöser und Ergebnis des Anwendungsfalles benannt?

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.3 Anwendungsfallmodell

4.3.5 Geschäftsprozess Stereotyp, Teil des OOGPM-Profils. Verwandte Begriffe: Business Process, Workflow, Geschäftsvorfall. Definition Ein Geschäftsprozess ist eine Zusammenfassung einer Menge fachlich verwandter Geschäftsanwendungsfälle. Notation Ein Geschäftsprozess wird dargestellt als Anwendungsfall mit dem Klassifikationszusatz (UML-Jargon: Stereotyp) «business process» (für undefinierte oder unterstützende Geschäftsprozesse) bzw. «core business process» (für Kern-Geschäftsprozesse) oder als Einbahnstraßenschild-ähnliches Symbol (mit einem weiteren Schrägstrich rechts unten für die Kernprozesse). «core business process» Kfz-Vermietung

Kfz-Vermietung

«business process» Rechnungswesen

Rechnungswesen

Abb. 4.3-7: Notationsvarianten eines Geschäftsprozesses

Zu jedem Geschäftsprozess existiert eine natürlichsprachliche Beschreibung nach folgendem Beschreibungsschema: Beschreibung Geschäftsprozess Name Kurzbeschreibung Enthaltene Geschäftsanwendungsfälle Ziele (inkl. Maßnahmen, Kennzahlen, Risiken/Aufwände, Chancen/Nutzen) Verantwortlich Beteiligt Abb. 4.3-8: Natürlichsprachliches Beschreibungsschema eines Geschäftsprozesses

Beispiele hierzu finden Sie in den Kapiteln 3.8 Geschäftsprozesse definieren (77) und 3.9 Geschäftsprozesse dokumentieren (84).

163

164

4.3 Anwendungsfallmodell

Praxis UML: Geschäftsanwendungsfälle 165

Die eigentlichen Beschreibungen der geschäftlichen Abläufe erfolgen mit Geschäftsanwendungsfällen. Geschäftsprozesse sind lediglich Gruppierungen fachlich zusammengehöriger Geschäftsanwendungsfälle. So gehören zum Geschäftsprozess Kfz-Vermietung beispielsweise die Geschäftsanwendungsfälle Kfz reservieren, Kfz vermieten, KfzReservierung ändern, Kfz-Reservierung stornieren und Preisauskunft für Kfz-Vermietung erteilen. Der Name eines Geschäftsprozesses sollte möglichst ein substantiviertes Verb sein (also häufig ein Gerundium mit Endung -ung): KfzVermietung, Buchhaltung etc. Im Gegensatz hierzu werden die Namen von Geschäftsanwendungsfällen immer aus Substantiv und Verb gebildet: Kfz reservieren. Es werden zwei verschiedene Arten von Geschäftsprozessen unterschieden:  Kern-Geschäftsprozesse  Unterstützende Geschäftsprozesse Die Art ergibt sich daraus, ob die Mehrheit der enthaltenen Geschäftsanwendungsfälle Kern- oder unterstützende Geschäftsanwendungsfälle sind. Ein weiteres Beispiel finden Sie in Abb. 3.9-1 (85) Checkliste für Geschäftsprozesse  Enthält die Geschäftsprozessbezeichnung ein substantiviertes Verb (Gerundium mit der Endung -ung)?  Enthält der Geschäftsprozess mindestens einen Geschäftsanwendungsfall?  Kann der Geschäftsprozess aufgrund der in ihm enthaltenen Geschäftsanwendungsfälle als Kern-Geschäftsprozess oder unterstützender Geschäftsprozess klassifiziert werden?

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.3 Anwendungsfallmodell

4.3.6 Geschäftsanwendungsfall Stereotyp, Teil des OOGPM-Profils. Verwandte Begriffe: Use Case, business use case. Definition Ein Geschäftsanwendungsfall beschreibt einen geschäftlichen Ablauf, wird von einem geschäftlichen Ereignis ausgelöst und endet mit einem Ergebnis, das für den Unternehmenszweck und die Gewinnerzielungsabsicht direkt oder indirekt einen geschäftlichen Wert darstellt. Notation Geschäftsanwendungsfälle werden wie Anwendungsfälle dargestellt, jedoch mit einem Schrägstrich rechts unten an der Seite. Tarif einrichten Abb. 4.3-9: Notation von Geschäftsanwendungsfällen

Praxis Es können zwei Arten von Geschäftsanwendungsfällen unterschieden werden: unterstützende Geschäftsanwendungsfälle und KernGeschäftsanwendungsfälle, die im Folgenden näher definiert werden. Beispiele, Hinweise zur Vorgehensweise und weitere Erläuterungen finden Sie im Kapitel 3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren (56). Checkliste für Geschäftsanwendungsfälle  Ist der geschäftliche Auslöser benannt? Ist das Ergebnis benannt?  Trägt das Ergebnis direkt oder indirekt zum Unternehmenszweck und einer Gewinnerzielungsabsicht bei?  Beschreibt der Name des Geschäftsanwendungsfalles eine Tätigkeit des im Modellierungsfokus liegenden Unternehmens? Welches Verb im Namen des Geschäftsanwendungsfalles beschreibt diese Tätigkeit?  Sind die im Geschäftsanwendungsfall vorkommenden Geschäftsobjekte im Singular beschrieben bzw. entspricht die Anzahl der im Namen des Geschäftsanwendungsfalles genannten Geschäftsobjekte genau der Anzahl, die ein Akteur in diesem Geschäftsanwendungsfall zu einem Zeitpunkt betrachtet?

165

166

4.3 Anwendungsfallmodell

4.3.7 Kern-Geschäftsanwendungsfall Stereotyp, Teil des OOGPM-Profils. Verwandte Begriffe: Use Case, business use case, core business use case. Definition Ein Kern-Geschäftsanwendungsfall beschreibt einen geschäftlichen Ablauf, der von einem aktiven Geschäftspartner ausgelöst wird, ein Ergebnis von geschäftlichem Wert für mindestens einen aktiven Geschäftspartner erzeugt und direkt mit dem Unternehmenszweck und einer Gewinnerzielungsabsicht (bei gemeinnützigen Organisationen mit dem beabsichtigten Gemeinnutz) zusammenhängt. Notation Kfz reservieren

Abb. 4.3-10: Notation von Kern-Geschäftsanwendungsfällen

Kern-Geschäftsanwendungsfälle werden wie Anwendungsfälle dargestellt, jedoch mit zwei Schrägstrichen an der Seite. Erläuterung Im Kontrast hierzu sind die unterstützenden Geschäftsanwendungsfälle zu sehen. In einem Handelsunternehmen ist der Verkauf von Waren gewöhnlich ein Kern-Geschäftsanwendungsfall, während beispielsweise die Finanzbuchhaltung oder der Wareneinkauf unterstützende Geschäftsanwendungsfälle darstellen. Beispiele, Hinweise zur Vorgehensweise und weitere Erläuterungen finden Sie im Kapitel 3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren (56). Checkliste für Kern-Geschäftsanwendungsfälle  Ist der geschäftliche Auslöser benannt? Ist das Ergebnis benannt und von geschäftlichem Wert für einen aktiven Geschäftspartner?  Trägt der Geschäftsanwendungsfall direkt zum Unternehmenszweck und einer Gewinnerzielungsabsicht bei?  Beschreibt der Name des Geschäftsanwendungsfalles eine Tätigkeit des im Modellierungsfokus liegenden Unternehmens? Welches Verb im Namen des Geschäftsanwendungsfalles beschreibt diese Tätigkeit?  Sind die im Geschäftsanwendungsfall vorkommenden Geschäftsobjekte im Singular beschrieben bzw. entspricht die Anzahl der im Namen des Geschäftsanwendungsfalles genannten Geschäftsobjekte genau der Anzahl, die ein Akteur in diesem Geschäftsanwendungsfall zu einem Zeitpunkt betrachtet?

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.3 Anwendungsfallmodell

4.3.8 Unterstützender Geschäftsanwendungsfall Stereotyp, Teil des OOGPM-Profils. Verwandte Begriffe: Use Case. Definition Ein unterstützender Geschäftsanwendungsfall beschreibt einen geschäftlichen Ablauf, der für den Unternehmenszweck und die Gewinnerzielungsabsicht keinen oder nur indirekt einen Wert darstellt. Notation Unterstützende Geschäftsanwendungsfälle werden wie Anwendungsfälle dargestellt, jedoch mit einem Schrägstrich an der Seite. Tarif einrichten Abb. 4.3-11: Notation von unterstützenden Geschäftsanwendungsfällen

Erläuterung In einem Handelsunternehmen bestehen die Finanzbuchhaltung oder der Wareneinkauf gewöhnlich aus unterstützenden Geschäftsanwendungsfällen, während im Kontrast hierzu beispielsweise der Verkauf von Waren gewöhnlich Kern-Geschäftsanwendungsfälle enthält. Weitere Erläuterungen und Beispiele finden Sie im Kapitel 3.6 Weitere unterstützende Geschäftsanwendungsfälle identifizieren (66). Checkliste für unterstützende Geschäftsanwendungsfälle  Ist der geschäftliche Auslöser benannt?  Welcher Geschäftsanwendungsfall oder Geschäftsprozess wird damit unterstützt?  Trägt der Geschäftsanwendungsfall nur indirekt zum Unternehmenszweck und einer Gewinnerzielungsabsicht bei?  Beschreibt der Name des Geschäftsanwendungsfalles eine Tätigkeit des im Modellierungsfokus liegenden Unternehmens? Welches Verb im Namen des Geschäftsanwendungsfalles beschreibt diese Tätigkeit?  Sind die im Geschäftsanwendungsfall vorkommenden Geschäftsobjekte im Singular beschrieben bzw. entspricht die Anzahl der im Namen des Geschäftsanwendungsfalles genannten Geschäftsobjekte genau der Anzahl, die ein Akteur in diesem Geschäftsanwendungsfall zu einem Zeitpunkt betrachtet?

167

168

4.3 Anwendungsfallmodell

4.3.9 Systemanwendungsfall Standard-UML-Element. Verwandte Begriffe: Use Case, Anwendungsfall. Definition Ein Systemanwendungsfall ist ein Anwendungsfall, der speziell das für die außen stehenden Akteure (Benutzer) wahrnehmbare Verhalten eines Systems beschreibt. Notation Ein Systemanwendungsfall ist die Normalform eines Anwendungsfalles und wird grafisch dargestellt durch eine Ellipse, in (oder unter) der der Name des Anwendungsfalles steht. Systemanwendungsfall Abb. 4.3-12: Notation eines Systemanwendungsfalles

Erläuterung Aus UML- und Softwareentwicklungssicht ist der Systemanwendungsfall die normale Form eines Anwendungsfalles. In Abgrenzung zu den verschiedenen Arten von Geschäftsanwendungsfällen beschreibt ein Systemanwendungsfall konkret das Verhalten bzw. den Arbeitsablauf, wie er durch ein System (z.B. Software) unterstützt wird. Dabei wird das äußerlich wahrnehmbare Verhalten beschrieben, also was das System macht, aber nicht wie es dies tut. Ein Beispiel befindet sich in Abb. 3.19-1 (135). Checkliste für Systemanwendungsfälle  Ist mindestens ein Akteur beteiligt?  Enthält die Anwendungsfallbezeichnung mindestens ein Substantiv und ein aktives Verb?  Sind Auslöser und Ergebnis des Anwendungsfalles benannt?  Welcher Systembenutzer ist an dem Systemanwendungsfall beteiligt?

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.3 Anwendungsfallmodell

4.3.10

Sekundärer Anwendungsfall

Stereotyp, Teil des OOGPM-Profils. Verwandte Begriffe: Use Case. Definition Ein sekundärer Anwendungsfall ist ein Anwendungsfall, der einen unvollständigen Teilablauf beschreibt, der in gleichartiger Weise Teil mehrerer anderer Anwendungsfälle ist und deren jeweilige Vollständigkeits- und Abgrenzungskriterien ggf. nicht erfüllt. Notation Sekundäre Anwendungsfälle werden mit dem Stereotyp «secondary» Siehe auch Abb. 4.3-3 gekennzeichnet. 158 Geld auszahlen Geld auszahlen

1. Include: Verfügungsberechtigten identifizieren 2. Auszahlunsbetrag bestimmen 3. Auszahlungsmöglichkeit prüfen 4. Geld auszahlen

«include» Verfügungsberechtigten identifizieren «secondary» Verfügungsberechtigten identifizieren

1. Karte lesen 2. Kartensperre prüfen 3. PIN abfragen 4. PIN prüfen

Abb. 4.3-13: Sekundärer Anwendungsfall

Erläuterung Teile von Abläufen die in mehreren Anwendungsfällen in identischer Weise vorkommen, können in eigene sekundäre Anwendungsfälle ausgelagert werden und mittels Enthält-Beziehung wieder eingebunden werden. Somit lassen sich redundante Beschreibungen in Anwendungsfällen vermeiden. Die ausgelagerten Teile sind jedoch gewöhnlich unvollständig und erfüllen die an die jeweilige Anwendungsfallart gestellten Bedingungen bezüglich Auslöser, Ergebnis, zeitlicher Kohärenz u.a. nicht. Um diese unvollständigen Anwendungsfälle von anderen zu unterscheiden, werden sie als explizit sekundäre Anwendungsfälle gekennzeichnet. Alle anderen sind demnach (implizit, d.h. wenn nichts weiter angegeben ist) primäre Anwendungsfälle. Sekundäre Anwendungsfälle können Teile von allen anderen Arten von (Kern-, Geschäfts-, unterstützende etc.) Anwendungsfällen beschreiben. In der Praxis werden sekundäre Anwendungsfälle aber vor allem in Systemanwendungsfallmodellen benötigt.

169

170

4.3 Anwendungsfallmodell

4.3.11

Anforderung

Stereotyp, Teil des OOGPM-Profils. Verwandte Begriffe: Requirement, Use Case. Definition Eine Anforderung beschreibt eine oder mehrere Eigenschaften oder Verhaltensweisen, die stets erfüllt sein sollen. Es werden allgemein funktionale und nichtfunktionale Anforderungen unterschieden. Ein Feature ist eine Sammlung von Anforderungen. Auch Probleme und Ziele werden häufig als eine spezielle Form der Anforderung betrachtet. Notation Anforderungen werden grundsätzlich wie Anwendungsfälle in Form von Ellipsen notiert, wobei durch ein entsprechendes Stereotyp («Requirement», «Feature» etc.) die Art der Anforderung angegeben werden kann. «Requirement» Eine Anforderung

«include»

«Feature» Ein Feature

«Aim» Ein Ziel

«Problem» Ein Problem

Ein Feature

Ein Ziel

Ein Problem

Abb. 4.3-14: Notation der verschiedenen Anforderungstypen

Die für Anwendungsfälle möglichen Beziehungsformen Spezialisierung und Enthält (Include) sind auch für Anforderungen verwendbar, ebenso können diese Beziehungen von Anwendungsfällen zu Anforderungen oder umgekehrt definiert werden. So kann beispielsweise ein Feature oder ein Anwendungsfall eine Menge von Anforderungen enthalten, wobei die entsprechenden «include»-Beziehungen dann auf die enthaltene Anforderung zeigt. In der Abb. 3.18-3 im Kapitel 3.18 Geschäftliche Anforderungen und Regeln beschreiben (132) ist zu sehen, wie die Anforderungen von anderen Modellelementen, beispielsweise Geschäftsanwendungsfällen, referenziert werden können.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.3 Anwendungsfallmodell

Erläuterung Es werden verschiedene Arten von Anforderungen unterschieden, wie in Abb. 4.3-15 dargestellt. Für Geschäftregeln am wichtigsten sind die so genannten funktionalen Anforderungen. Im Rahmen von Softwareentwicklungsprojekten werden zusätzlich auch noch die nichtfunktionalen Anforderungen wichtig. enthält

* Anforderung

enthält

enthält

*

*

Funktionale Anforderung

Nichtfunktionale Anforderung

Allgemeine Anforderung

Benutzbarkeitsanforderung

Problem

Performanceanforderung

Ziel

Zuverlässigkeitsanforderung

Feature

Anwendungsfall

Dialogspezifikation

Wartbarkeitsanforderung Administrierbarkeitsanforderung Rahmenbedingung

Abb. 4.3-15: Verschiedene Arten von Anforderungen

Nichtfunktionale Anforderungen werden wie folgt unterteilt:  Benutzbarkeit  Performance  Zuverlässigkeit  Wartbarkeit  Administrierbarkeit  Rahmenbedingungen Sind in einem abstrakteren Sinne ebenfalls Anforderungen:  Probleme  Ziele  Features

171

172

4.3 Anwendungsfallmodell

Features sind Zusammenfassungen einer Menge von (gewöhnlich elementaren) fachlich zusammenhängenden Anforderungen. Während funktionale und nichtfunktionale Anforderungen gewöhnlich elementare, d.h. sehr detaillierte Anforderungen darstellen und damit jeweils auf einem ähnlichen Abstraktions- und Detaillierungsniveau beschrieben sind, ist dies bei Features nicht der Fall. Ein Feature kann eine kleine Detailanforderung sein („die Bankleitzahl ist 8-stellig“) oder ebenso ein ganzes (Sub-)System umfassen („Es wird eine Kundenverwaltung benötigt“). Features sind zu konkretisierende Anforderungen

Diese möglicherweise große Unterschiedlichkeit in der Granularität von Features ist beabsichtigt! Versuchen Sie nicht, sie krampfhaft zu vereinheitlichen. Feature ist der Sammelbegriff für alle Anforderungen, die (noch) nicht in eine der anderen Kategorien hineinpassen. Dadurch sind die Möglichkeiten, aufbauend auf Features zu planen (Projektplanung, Aufwandschätzungen etc.), natürlicherweise sehr eingeschränkt. Früher oder später sind Features daher zu detaillieren und zu untergliedern, so dass elementare und besser handhabbare Anforderungen daraus entstehen, die einer der anderen Anforderungskategorien zugeordnet werden können. Ohne Features zu arbeiten ist jedoch auch umständlich, da nicht alle Anforderungen, die genannt und identifiziert werden, sofort eindeutig verfeinert werden können.

Anforderung

Name der Anforderung

Art

z.B. Funktionale Anforderung

Beschreibung

Kurze Beschreibung der Anforderung mit 1 - 4 Sätzen.

Stabilität Verbindlichkeit Priorität Details Involvierte andere Modellelemente Verweise auf andere Geschäftsregeln Änderungen

Datum

Mitarbeiter

Status

Kommentar

Abb. 4.3-16: Spezifikationsschablone einer Anforderung (ausgefülltes Beispiel siehe Abb. 3.18-4 132)

Anwendungsfälle und Dialogspezifikationen

Zwei besondere Arten funktionaler Anforderungen sind Anwendungsfälle und Dialogspezifikationen. Anwendungsfälle sind im Abschnitt 4.3.4 separat und ausführlich beschrieben und in der Abb. 4.3-15 enthalten, weil sie selbstverständlich auch Anforderungen beschreiben. Anwendungsfälle sind formal gesehen eine Sammlung von Einzelanforderungen und können prinzipiell auch nichtfunktionale und andere

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.3 Anwendungsfallmodell

Arten von Anforderungen enthalten. Wir betrachten sie dennoch als eine Art funktionale Anforderung, da sie vorwiegend Abläufe und Verhaltensweisen, also funktionale Anforderungen, beschreiben. Ähnlich verhält es sich mit den Dialogspezifikationen, die vor allem im Rahmen der Softwareentwicklung wichtig sind und daher in diesem Buch nicht weiter behandelt werden. Während die grafische Notation in Form von Ellipsen bzw. Anwendungsfällen nur die Existenz einer Anforderung und ihre Abhängigkeiten und Beziehungen ausdrückt, wird die detaillierte Spezifikation einer Anforderung in natürlicher Sprache vorgenommen, wobei jede Anforderung durch folgende Einzelpunkte beschrieben wird:  Eindeutige Nummer, ggf. zusätzlich Kurzbezeichnung  Art der Anforderung  Beschreibung der Anforderung Die Beschreibung erfolgt gewöhnlich in natürlicher Sprache und wird grundsätzlich in Form einer Bedingung formuliert, die stets erfüllt sein muss. Nur sofern alle an der Geschäftsprozessmodellierung Beteiligten entsprechend qualifiziert sind, können auch formale Sprachen wie OCL (Object Constraint Language) oder Prädikatenlogik27 verwendet werden.  Klassifizierung der Stabilität absolut stabil Die Anforderung wird/kann sich mit großer Wahrscheinlichkeit nie/nicht ändern. Beispiel: Die Fahrer von Kfz müssen eine geeignete Fahrerlaubnis besitzen. stabil Die Anforderung ändert sich ganz selten. Beispiel: das gesetzlich vorgegebene Volljährigkeitsalter (zzt. 18 Jahre). instabil Die Anforderung wird gelegentlich oder regelmäßig geändert. Beispiel: Die Mindestmietdauer beträgt 6 Stunden. flüchtig Die Anforderung ist ständigen Änderungen unterworfen. Die Klassifizierung der Stabilität ist hilfreich, um Geschäftsprozesse mit vertretbaren Aufwänden flexibel ändern zu können. Je dynamischer das Geschäft und das geschäftliche Umfeld, desto wichtiger wird es, stabile Elemente zu identifizieren, um nicht bei jeder Änderung den kompletten Modellierungsbereich betrachten zu müssen.

27

Die Prädikatenlogik ist ein Teilgebiet der Logik und beschäftigt sich mit formalen Systemen für Aussagen und Schlussfolgerungen.

173

174

4.3 Anwendungsfallmodell

 Verbindlichkeit der Anforderung (Pflicht, Wunsch, Absicht, Vorschlag) Pflichtanforderungen enthalten das Wort „muss“ („... muss ... erfüllen“), optionale Anforderungen (Wünsche) enthalten das Wort „sollte“. Absichten sind Anforderungen, die wahrscheinlich zukünftig zu erfüllen sind, sie beginnen mit der Phrase „Es ist beabsichtigt, dass ...“. Vorschläge sind keine Anforderungen, sondern Ideen von Modellierungsbeteiligten, wie bestehende Anforderungen (besser) gelöst werden könnten.  Priorität der Anforderung (hoch, mittel, niedrig) Bei der Umgestaltung von Geschäftsprozessen müssen regelmäßig Kompromisse gemacht werden und nicht alle Ziele können in gleicher Weise erreicht oder verfolgt werden. Die Priorität ergibt sich beispielsweise aus der Abwägung von Risiken, Chancen, Kosten, Nutzen, Umsetzbarkeit u.Ä.  Detailbeschreibung, d.h. Motivation, Ursache, Hintergrund, Ansprechpartner, Unterlagen, Testbarkeit, Beispiele, Randbedingungen (Gesetze, Standards etc.)  Involvierte andere Modellelemente: Aufzählung/Referenzierung beteiligter bzw. betroffener Geschäftsobjekte, Organisationseinheiten und Anwendungsfälle  Verweise auf andere abhängige oder zu beachtende Anforderungen  Änderungshistorie und Status Ein Feature als eine Menge fachlich zusammenhängender Anforderungen kann folgendermaßen spezifiziert werden: Anforderung

Name des Features

Art

Feature

Beschreibung

….

Enthaltene Anforderungen

 Anforderung 1  Anforderung 2  …

Änderungen

Datum

Mitarbeiter

Status

Kommentar

Abb. 4.3-17: Spezifikationsschablone eines Features

Checkliste für Anforderungen  Trägt die Anforderung eine eindeutige Nummer (ID)?  Wurde die Art der Anforderung festgelegt?

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.4 Aktivitätsmodelle

4.4

Aktivitätsmodelle

4.4.1 Aktivitätsdiagramm Standard-UML-Element. Verwandte Begriffe: activity diagram, Ablaufdiagramm; flow chart, Programmablaufplan, Objektflussdiagramm. Definition Ein Aktivitätsdiagramm beschreibt einen Ablauf mit Hilfe von Aktivitäten und Transitionen (Aktivitätsübergängen). Notation Ein Aktivitätsdiagramm besteht aus Anfangs- und Endzuständen, einer Reihe von Aktivitäten sowie Transitionen, mit denen diese Elemente verbunden sind. Kfz reservieren

[Kunde aufnehmen]

Kunde aufnehmen

[Abbrechen]

Kunde identifizieren [Kunde identifiziert]

Reservierungswunsch aufnehmen

Kfz reservieren abgebrochen

[Abbrechen]

[Reservierungswunsch aufgenommen]

[Kein Kfz verfügbar]

Kfz reservieren [Kfz reserviert]

Reservierung bestätigen

[Reservierung bestätigt]

Abb. 4.4-1: Beispiel eines Aktivitätsdiagramms

Kfz reserviert

175

176

4.4 Aktivitätsmodelle

Praxis Mit Aktivitätsdiagrammen können Abläufe, wie sie beispielsweise in Anwendungsfällen in natürlicher Sprache beschrieben sind, grafisch dargestellt werden. Mit natürlicher Sprache können gewöhnlich nur sehr einfache Abläufe verständlich beschrieben werden, mit Aktivitätsdiagrammen hingegen ist es möglich, auch sehr komplexe Abläufe mit vielen Ausnahmen, Varianten, Sprüngen und Wiederholungen noch übersichtlich und verständlich darzustellen. Sofern nur einfache Diagrammelemente wie Aktivitäten und Transitionen verwendet werden, sind solche Diagramme weitgehend allgemein verständlich. Bei Verwendung spezieller Konstrukte wie beispielsweise Signale, Objektknoten etc. sind hingegen grundlegende UMLKenntnisse notwendig. Die einzelnen möglichen Elemente werden in den folgenden Abschnitten ausführlich dargestellt und erläutert. Ein- oder ausgehende Objekte in einem Aktivitätsmodell werden als Parameter der Aktivität bezeichnet. Diese Objekte werden auf dem Rahmen platziert und zusätzlich unterhalb des Namens der Aktivität mit Typangabe aufgelistet. Kfz mietbereit machen Kfz : Fahrzeug Protokoll : Übergabeprotokoll

Kfz

Kfz-Zustand aufnehmen

...

Abb. 4.4-2: Notation von Aktivitätsparametern

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

Kfz übergeben

Protokoll

4.4 Aktivitätsmodelle

4.4.2 Aktivität und Transition Standard-UML-Element. Verwandte Begriffe: Aktivität, Schritt, Ablaufschritt, Aktivitätsaufruf, activity, Startknoten, Endknoten, Ablaufende, Anfangsknoten, Anfangszustand, Endzustand. Definition Eine Aktivität ist ein einzelner Schritt in einem Verarbeitungsablauf. Transitionen beschreiben den Übergang von einer Aktivität zur nächsten und somit den möglichen Kontroll- und Objektfluss. Ein Startknoten ist ein Startpunkt eines Ablaufes in einem Aktivitätsdiagramm. Der Begriff Anfangsknoten ist synonym zu verwenden. Ein Endknoten beendet den in einem Aktivitätsdiagramm beschriebenen Ablauf, d.h. alle Aktivitäten und Transitionen. Ein Ablaufende beendet einen einzelnen Kontrollfluss nach einer Transition. Notation Eine Aktivität wird dargestellt durch ein grafisches Element mit gerader Ober- und Unterseite und konvex geformten Seiten, in dessen Mitte der Name der Aktivität steht. Die Transitionen werden als durchgehende Linien notiert, an deren Ende eine einfache Pfeilspitze steht, die auf die Folgeaktivität zeigt. Transition [Bed.1]

Start

Schritt 2

Schritt 1 [Bed. 2] Schritt 3 Ende [stopp] Ablaufende [weiter]

Abb. 4.4-3: Aktivitäten, Transitionen, Startknoten, Endknoten und Ablaufende

An den Transitionen stehen in eckigen Klammern die Bedingungen. Start- und Endknoten werden durch einen ausgefüllten Kreis darge- Vgl. Zustände 213 stellt, wobei ein Endknoten noch zusätzlich einen Ring enthält. Ein Ablaufende ist ein nicht ausgefüllter Kreis mit einem Kreuz darin.

177

178

4.4 Aktivitätsmodelle

Eine Aktivität ist entweder eine elementare Aktivität oder besitzt wiederum Unteraktivitäten, d.h., eine Aktivität kann verschachtelt sein. Aktivitäten mit Unteraktivitätsmodellen können durch ein kleines Aktivitätsdiagrammsymbol innerhalb der Aktivität gekennzeichnet werden (kein Standard in UML 2.0). Schritt 1

Schritt 1 Schritt 1.2 Schritt 1.1

Schritt 1.4

Schritt 1.3

Abb. 4.4-4: Verschachtelung von Aktivitäten

Semantik Eine Aktivität hat mindestens eine eingehende und eine ausgehende Transition. Eingehende Transitionen lösen eine Aktivität aus. Sofern zu einer Aktivität mehrere eingehende Transitionen existieren, löst jede dieser Transitionen unabhängig von den anderen die Aktivität aus. Bei Beendigung einer Aktivität wird stets nur eine Transition aktiv („gefeuert“). Hat eine Aktivität mehrere ausgehende Aktivitäten, so sind diese mit Bedingungen zu versehen, von denen stets nur eine wahr sein darf. Verzweigungen etc. 182

Streng genommen sind die einzelnen Schritte im Ablauf nur Aktivitätsaufrufe, d.h., die UML unterscheidet zwischen einer Aktivität und einem Aktivitätsaufruf. Somit wird es beispielsweise möglich, eine Aktivität in mehreren Aktivitätsdiagrammen zu verwenden, d.h. von mehreren Ablaufkontexten her aufzurufen. Ebenso kann damit ein verschachtelter Unterablauf aufgerufen werden.

Startknoten, Endknoten

Ein Startknoten hat eine ausgehende, aber keine eingehenden Transitionen. Ein Ablaufende oder Endknoten hat mindestens eine eingehende, aber keine ausgehenden Transitionen. Ein Aktivitätsdiagramm besitzt mindestens einen Start- und einen Endknoten. Existieren mehrere Startknoten, lösen sie jeweils eigene, d.h. nebenläufige Transitionen aus. Existieren mehrere Endknoten, führt jeder Endknoten zur sofortigen Beendigung aller nebenläufigen Aktivitäten im gesamten Diagramm. Bei Erreichen eines Ablaufendes wird nur der Kontrollfluss der zum Ablaufende führenden Transition gestoppt, alle übrigen laufen weiter.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.4 Aktivitätsmodelle

4.4.3 Aktivitätsbeschreibung Stereotyp, Teil des OOGPM-Profils. Verwandte Begriffe: activity description. Definition Eine Aktivitätsbeschreibung spezifiziert die Vor- und Nachbedingungen sowie das Verhalten einer Aktivität. Notation Die Spezifikation enthält in natürlicher Sprache den Aktivitätsnamen, eine Kurzbeschreibung, Anmerkungen, vorhandene benötigte Objekte, offene Punkte sowie eine nummerierte Liste der ausgehenden Transitionen jeweils mit Transitionsnamen, Ergebnisobjekten, Bedingungen und transitionsspezifischen Anmerkungen. Die folgende Abb. 4.4-5 zeigt ein Beispiel einer Aktivitätsbeschreibung. Abb. 4.4-6 stellt dazu den Ausschnitt des zugehörigen Aktivitätsdiagramms dar. Aktivitätsbeschreibung ID: Name

A-1: Reservierung identifizieren

Kurzbeschreibung

Aufgrund der Reservierungsnr. oder anderer Informationen wird eine Kfz-Reservierung identifiziert.

Anmerkungen

--

Benötigte Objekte

--

Offene Punkte

--

Mögliche Ergebnisse: ID

Bedingung

Ergebnisobjekte

Beschreibung

1

Kfz reserviert

Reservierung [Kfz bestätigt]

Reservierungszeitraum steht unmittelbar bevor oder hat bereits begonnen

2

Kfz-Typ reserviert

3

Abbrechen

Die Reservierung gilt für ein konkretes Kfz. Reservierung [Kfz-Typ bestätigt]

Die Reservierung gilt nicht für ein konkretes Kfz, sondern nur für ein Kfz-Typ. --

--

Suche nach Reservierung erfolglos beendet. Abb. 4.4-5: Notationsbeispiel einer Aktivitätsbeschreibung

179

180

4.4 Aktivitätsmodelle

.3 [Abbrechen]

Reservierung identifizieren

.1 [Kfz reserviert]

.2 [Kfz-Typ reserviert]

Abb. 4.4-6: Aktivitätsdiagrammausschnitt zu Abb. 4.4-8

Praxis Wesentlich bei der Aktivitätsbeschreibung ist die eindeutige Nummer (ID) der Aktivität und die Nummerierung der ausgehenden Transitionen. Damit kann auch jede einzelne Transition eindeutig benannt werden, z.B. A-1.3. Die eindeutige Identifizierbarkeit von Aktivitäten und Transitionen ist wichtig, um in anderen Dokumenten eindeutige Verweise und Bezüge darauf verwenden zu können. Die Aktivitätsbeschreibung kann entweder in dem UML-Modellierungswerkzeug erfolgen, separat in einem Textdokument oder Wiki.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.4 Aktivitätsmodelle

4.4.4 Funktionsbaum Für UML 2.0 vorgesehen. Verwandte Begriffe: Aktivitätsbaum. Definition Ein Funktions- bzw. Aktivitätsbaum beschreibt, aus welchen einzelnen Schritten sich eine Aktivität zusammensetzt, ohne deren dynamischen Zusammenhänge (Reihenfolge etc.) festzulegen. Notation Ein Aktivitätsbaum besteht aus nicht ausgefüllten Rechtecken, die jeweils eine Aktivität bzw. einen Schritt darstellen, wobei ein Schritt bzw. eine Aktivität mit mehreren Unterschritten über Linien verbunden sein kann. Aktivitäten, deren Unterschritte auch grafisch dargestellt sind, enthalten im Rechteck ein „-“, solche, die Unterschritte haben, die grafisch nicht dargestellt sind, enthalten im Rechteck ein „+“, die übrigen sind leer. – Aktivität 1 – Aktivität 1.1

enthält eingeblendete Unterschritte

Schritt 1.1.1 + Aktivität 1.1.2 Schritt 1.1.3

enthält ausgeblendete Unterschritte elementare Aktivität (ohne Unterschritte)

Abb. 4.4-7: Funktionsbaum

Praxis Eine Aktivität kann auch durch einen Baum repräsentiert werden. Die Baumdarstellung zeigt ebenso wie ein Aktivitätsdiagramm die Schritte in einer Aktivität. Sie ist jedoch eine statische Sicht, denn die Transitionen zwischen den Schritten und die Ablaufreihenfolge sind nicht definiert. Beispiele befinden sich in Abb. 3.8-4 (81) und Abb. 3.8-5 (82).

181

182

4.4 Aktivitätsmodelle

4.4.5 Verzweigungen und Zusammenführungen Standard-UML-Element. Verwandte Begriffe: Splitting; Synchronisation, Teilung. Definition Eine Verzweigung ist ein Schritt im Ablauf, an dem aufgrund von Bedingungen entschieden wird, mit welcher von mehreren Transitionen der Kontrollfluss fortgesetzt werden soll. Eine Synchronisation (Konjunktion, UND-Verknüpfung) ist ein Schritt im Ablauf, an dem auf alle eingehenden Transitionen gewartet wird, bevor der Kontrollfluss fortgesetzt wird. Eine Teilung (Splitting) ist ein Schritt im Ablauf, an dem eine eingehende Transition sich ohne Bedingungen sofort in mehrere ausgehende nebenläufige Transitionen teilt. Eine Zusammenführung (Disjunktion, ODER-Verknüpfung) ist ein Schritt im Ablauf, an dem jede von mehreren eingehenden Transitionen sofort zu einer gemeinsamen ausgehenden Transition führt. Notation Eine Verzweigung wird durch eine nicht ausgefüllte Raute dargestellt, die eine eingehende und mehrere ausgehende Transitionen hat. Eine Synchronisation wird durch einen Balken repräsentiert, der mehrere eingehende und eine ausgehende Transition hat. Eine Teilung wird ebenfalls durch einen Balken dargestellt, der aber eine eingehende und mehrere ausgehende Transitionen hat. Eine Zusammenführung wird dargestellt durch eine nicht ausgefüllte Raute mit mehreren eingehenden und einer ausgehenden Transition. Verzweigung und Zusammenführung können ebenfalls kombiniert werden, die Raute hat dann mehrere eingehende und mehrere ausgehende Transitionen. Synchronisation und Teilung können ebenfalls kombiniert werden, der Balken hat dann mehrere eingehende und mehrere ausgehende Transitionen.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.4 Aktivitätsmodelle

Teilung (Splitting)

[x0] [x0]

[x0]

[x=0] Kombination von Verzweigung und Zusammenführung

Abb. 4.4-8: Notation von Verzweigung, Synchronisation, Teilung und Zusammenführung

Erläuterung Verzweigung und Zusammenführung (d.h. Rauten) sind im Grunde gewöhnliche Aktivitäten, die jedoch keinen Namen tragen, durch eine Raute dargestellt werden und nichts weiter tun, als den Kontrollfluss zu bündeln oder zu verzweigen. Prinzipiell kann auch jede gewöhnliche Aktivität mehrere eingehende Transitionen haben (die jeweils die Aktivität starten) und mehrere ausgehende. Wobei jede ausgehende Transition eine Bedingung tragen muss und die Bedingungen sich gegenseitig ausschließen müssen, so dass stets nur eine ausgehende Transition den Kontrollfluss erhalten (d.h. feuern) kann.

183

184

4.4 Aktivitätsmodelle

4.4.6 Involvierte Geschäftsobjekte Standard-UML-Element. Verwandte Begriffe: Objektknoten, Objekt, Objektzustand. Definition Ein Objektknoten repräsentiert ein Objekt oder eine Menge von Objekten innerhalb eines Aktivitätsmodells. Notation Objektknoten werden durch Rechtecke dargestellt, die den Namen des Objektes und optional in eckigen Klammern den Objektzustand enthalten. Reservierungswunsch aufnehmen

Reservierung [Wunsch]

KfzVerfügbarkeit prüfen

Objekt A [Zustand x] Schritt 1 Objekt B [Zustand y]

Abb. 4.4-9: Notation und Beispiele Objektknoten

Praxis Häufig bewirken Aktivitäten Änderungen an Objekten. Objekte sind Knoten in einem Aktivitätsdiagramm. Führt eine Transition von einem Objektknoten zu einem Verhaltensaufruf, bedeutet dies, dass der Aufruf ein Objekt voraussetzt bzw. fordert. Führt eine Transition von einem Verhaltensaufruf zu einem Objektknoten, zeigt dieser aus der Aktivität resultierende Objekte. Wenn ausgedrückt werden soll, dass in Folge einer Aktivität mehrere Objekte erzeugt oder verändert wurden, ist die aus der Aktivität herausführende Transition zu splitten, wie in Abb. 4.4-9 gezeigt. Jeder ausgehende Pfeil einer Aktivität ist eine Transition, da stets nur eine Transition nach Abschluss der Aktivität den Kontrollfluss erhält (vgl. Kap. 4.4.2 und Kap. 4.4.5), kommen direkte Pfeile von der Aktivität zu den Objekten nicht in Frage, da die Objekte immer nur alternativ, aber nie gemeinsam das Resultat wären. Zustände von Objekten müssen nicht modelliert werden, die Notation von Objektzuständen ist lediglich eine Möglichkeit, solche Sachverhalte hervorzuheben, soweit dies von besonderer Bedeutung ist.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.4 Aktivitätsmodelle

4.4.7 Signal Standard-UML-Element. Verwandte Begriffe: signal, event. Definition Ein Signal ist die Benachrichtigung über ein zu beachtendes Vorkommnis, das unmittelbar eine Transition auslöst. Notation Ein Signal wird dargestellt durch ein Rechteck, das auf einer Seite spitz ist. Alternativ wird besonders für Zeitereignisse ein Sanduhrsymbol verwendet. Bei Signalen, die empfangen werden, zeigt die Transition auf die Aktivität, die das Signal empfängt. Bei Signalen, die gesendet werden, führt die Transition von der sendenden Aktivität weg.

Monatsende

Nutzung bezahlen

Monatsabrechnungen erstellen

Zahlungseingang

Abb. 4.4-10: Notation Signale

Erläuterung Eine Aktivität kann Signale senden bzw. empfangen. Notationselement ist ein Objektknoten, der hier vom Typ Signal bzw. speziell Zeitsignal ist. Mit nur ausgehenden Transitionen wird ein Signalempfang der Aktivität dargestellt (Abb. 4.4-10 oben). Nur eingehende Transitionen stellen das Senden eines Signals dar (Abb. 4.4-10 unten). Für Signale haben wir in diesem Buch kein Fallbeispiel.

185

186

4.4 Aktivitätsmodelle

4.4.8 Spezialisierung/Generalisierung von Aktivitäten und Anwendungsfällen Standard-UML-Element. Verwandte Begriffe: Vererbung, inheritance, Konkretisierung, Generalisierung. Definition Spezialisierung und Generalisierung sind Abstraktionsprinzipien zur hierarchischen Strukturierung der Semantik eines Modells. Eine Spezialisierung (bzw. Generalisierung) ist eine taxonomische28 Beziehung zwischen einem allgemeinen und einem speziellen Element (bzw. umgekehrt), wobei das speziellere Element weitere Eigenschaften hinzufügt und sich kompatibel zum allgemeinen verhält. Notation Die Vererbungsbeziehung wird mit einem großen, nicht ausgefüllten Pfeil dargestellt, wobei der Pfeil von der Unteraktivität (spezielles Element) zur Oberaktivität (allgemeines Element) zeigt. Kfz reservieren

Kfz online reservieren

Kfz telefonisch reservieren

Anwendungsfall-Generalisierung

Kfz reservieren

Kfz online reservieren

Kfz telefonisch reservieren

Aktivitäts-Generalisierung

Abb. 4.4-11: Generalisierung von Anwendungsfällen und Aktivitäten

Erläuterung Vgl. Klassenspezialisierung 198

So wie Generalisierungen von Klassen und Anwendungsfällen modelliert werden, können auch die zugehörigen Aktivitäten in einer Generalisierungsbeziehung zueinander stehen.

28

Griech., taxis: „Anordnung“; Taxonomie: „Einordnung in ein System“.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.4 Aktivitätsmodelle

4.4.9 Verantwortlichkeitsbereiche Verwandte Begriffe: swimlane. Definition Ein Verantwortlichkeitsbereich beschreibt innerhalb eines Aktivitätsmodells, wer oder was für eine Aktivität verantwortlich ist. Notation Verantwortlichkeitsbereiche werden durch senkrechte Linien in einzelnen Bahnen aufgeteilt, die aussehen wie Schwimmbahnen. Die Elemente eines Aktivitätsdiagramms (Aktivitäten, Objektknoten) befinden sich stets genau innerhalb einer Bahn. Bereich 1

Bereich 2

Bereich 3

Start

A1 Aktivität

A2 Aktivität

A3 Aktivität

A4 Aktivität

Ende

Abb. 4.4-12: Notation von Verantwortlichkeitsbereichen

Erläuterung Aktivitätsdiagramme können in Verantwortlichkeitsbereiche unterteilt werden, mit denen die Knoten und Transitionen anderen Elementen oder Strukturen zugeordnet werden können. Nach welchen Sachverhalten die Verantwortlichkeiten unterschieden werden, ist frei wählbar. Beispielsweise lässt sich damit ausdrücken, zu welcher Organisationsstruktur ein Teil eines Aktivitätsablaufes gehört.

187

188

4.5 Geschäftsklassenmodell

4.5

Geschäftsklassenmodell

Verwandte Begriffe: Objektmodell, Begriffsmodell, Strukturmodell. Definition Ein Geschäftsklassenmodell beschreibt, welche geschäftlichen Konzepte und Gegenstände existieren und in welchen Beziehungen sie zueinander stehen. Notation Die einzelnen Notationselemente werden in den folgenden Abschnitten detailliert erläutert. 1

Kunde

*

hat

Anschrift

1

1

1

Lieferanschrift

Rechnungsanschrift

bestellt *

Bestellung

1

führt zu

*

Rechnung

1

besteht aus *

Bestellposition

besteht aus

*

Artikel

Abb. 4.5-1: Beispiel eines Geschäftsklassenmodells

Praxis Vgl. 3.16 Geschäftsklassenmodell erstellen 123

Klassenmodelle werden aus Klassen, Assoziationen u.Ä. gebildet, wie dies in den folgenden Abschnitten erläutert wird. Ein Klassenmodell beschreibt die statische Begriffs- und Konzeptstruktur, auf deren Basis die Geschäftsprozessmodellierung stattfindet. Diese Strukturen ändern sich gelegentlich im Detail (einige zusätzliche Attribute/Daten), sind aber in ihrer grundsätzlichen Beziehungsstruktur gewöhnlich wesentlich stabiler als Geschäftsprozesse bzw. Geschäftsanwendungsfälle. Klassenmodelle eignen sich zur Abstimmung dieser statischen Grundkonzepte mit den Fachexperten und anderen Anforderungsbeitragenden.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.5 Geschäftsklassenmodell

189

4.5.1 Klasse Standard UML-Element. Verwandte Begriffe: class, Typ, Objekt. Definition In der objektorientierten Softwareentwicklung ist eine Klasse die Defi- 4.5.3 Attribut 192 nition der Attribute, Operationen und der Semantik für eine Menge von 4.5.4 Operation 193 Objekten. Alle Objekte einer Klasse entsprechen dieser Definition. Notation Klassen werden durch Rechtecke dargestellt, die entweder nur den 4.5.2 Verantwortlichkeit Namen der Klasse tragen oder in zusätzlichen Rubriken auch Attribute, 191 Operationen und ggf. weitere Informationen (z.B. Verantwortlichkeiten). Die Rubriken werden jeweils durch eine horizontale Linie getrennt. Klassennamen beginnen mit einem Großbuchstaben und sind gewöhnlich Substantive im Singular (Sammlungsklassen u.Ä. ggf. im Plural, Steuerungsklassen ggf. substantivierte Verben). «Stereotyp» Paket::Klasse {Eigenschaftswerte}

Klasse

Abstrakte Klasse

attribut operation() Boundary Control

Entity

Abb. 4.5-2: Notationsvarianten einer Klasse

In der obersten Rubrik (Klassenname) können oberhalb des Klassennamens in doppelten spitzen Klammern die so genannten Stereotypen stehen (z.B. «entity») und unterhalb des Klassennamens in geschweiften Klammern ggf. Eigenschaftswerte. Dem Klassennamen kann der Name eines Paketes vorangestellt werden, wobei zwei Doppelpunkte den Paket- und den Klassennamen trennen. Statt der Notation der Stereotypen in doppelten spitzen Klammern, können Stereotypen auch durch grafische Symbole dargestellt werden, wie dies in der Abbildung an den Beispielen Boundary, Control und Entity zu sehen ist. Im Rahmen der Geschäftsprozessmodellierung werden hauptsächlich so genannte Entitätsklassen («entity») verwendet. Entitäten sind Klassen, die einen fachlichen Gegenstand oder ein fachliches Konzept repräsentieren, beispielsweise Vertrag oder Konto.

Siehe auch abstrakte Klasse 200

190

4.5 Geschäftsklassenmodell

Person name vorname gebDatum

1

*

Reservierung

gibStandardadresse() berechneAlter()

Abb. 4.5-3: Beispiel eines Klassendiagramms

Erläuterung Eine Klasse enthält die Beschreibung der Struktur und des Verhaltens von Objekten, die mit ihr erzeugt werden können. Objekte werden von Klassen zur Programmlaufzeit erzeugt und sind die in einer Anwendung zur Programmlaufzeit agierenden Einheiten. Die Definition einer Klasse setzt sich aus Attributen und Operationen zusammen. Das Verhalten eines Objektes wird beschrieben durch die möglichen Nachrichten, die es verstehen kann. Zu jeder Nachricht benötigt das Objekt entsprechende Operationen. Nachricht und Operation werden oft synonym verwendet, obwohl dies streng genommen nicht richtig ist. Häufig wird anstelle von Klasse auch der Begriff Typ verwendet, wobei zu beachten ist, dass Typ die allgemeinere Bezeichnung ist. Klassen vs. Objekt Objekt = Instanz = Exemplar

Klassen sind die Baupläne bzw. Definitionen (z.B. Person) für eine Menge gleichartiger konkreter Objekte (Gabi Goldfisch, Theo Tröster etc.). Statt Objekt wird auch synonym Exemplar oder Instanz verwendet. Je nach Modellierungszweck werden verschiedene Arten von Klassen unterschieden:  Geschäftsklassen umfassen geschäftliche relevante Fachbegriffe, Konzepte und Gegenstände.  Fachklassen sind in der Praxis gleichzusetzen mit Geschäftsklassen. Streng genommen sind Fachklassen aber nur diejenigen Geschäftsklassen, die eine fachliche Anforderung für eine systemtechnische Umsetzung darstellen, also ein fachliches Problem beschreiben.  Designklassen repräsentieren Klassen, die in der softwaretechnischen Umsetzung enthalten sind, also ein Lösungskonzept darstellen. Es existieren in der UML noch weitere Beschreibungsdetails für Klassen (siehe [Oestereich01a]), die im Rahmen der Geschäftsprozessmodellierung jedoch weniger wichtig sind.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.5 Geschäftsklassenmodell

4.5.2 Verantwortlichkeit Stereotyp, Teil des OOGPM-Profils. Verwandte Begriffe: responsibility, Aufgabe, Zweck. Definition Verantwortlichkeit beschreibt, für welche fachlichen Aufgaben eine 4.5.1 Klasse 189 Klasse verantwortlich ist. Notation Verantwortlichkeiten werden in einer separaten Rubrik als einfache Aufzählungsliste notiert. Lieferung  beschreibt und verwaltet die Menge und Art der zu liefernden Gegenstände  dokumentiert den akt. Status und bisherigen Verlauf der Lieferung

Abb. 4.5-4: Notation von Verantwortlichkeiten in einer Klasse

Erläuterung Bevor Klassen im Detail modelliert werden, ist es sinnvoll, die Verantwortlichkeit der Klasse zu definieren. Zwar handelt es sich hier um verhältnismäßig unscharfe und abstrakte natürlichsprachige Beschreibungen, aber sie betreffen eines der wichtigsten objektorientierten Prinzipien, das Verantwortlichkeitsprinzip. Alle in objektorientierten Modellen repräsentierten fachlichen Sachverhalte sind letztendlich genau einer Klasse zuzuordnen. Operationen, Attribute, Geschäftsregeln, Zusicherungen, Assoziationen etc. gehören spätestens in der Realisierung in den Verantwortungsbereich genau einer Klasse. Eine Klasse sollte möglichst nur für einen fachlichen Zusammenhang verantwortlich sein, weil sonst mehr Abhängigkeiten und somit ein instabileres Gesamtdesign entstehen würde.

191

192

4.5 Geschäftsklassenmodell

4.5.3 Attribut Standard-UML-Element. Verwandte Begriffe: attribute, Variable, Instanzvariable, member, Datenelement. Definition 4.5.1 Klasse 189

Ein Attribut ist ein (Daten-)Element, das in jedem Objekt einer Klasse gleichermaßen enthalten ist und von jedem Objekt mit einem individuellen Wert repräsentiert wird. Im Gegensatz zu Objekten haben Attribute außerhalb des Objektes, von dem sie ein Teil sind, keine eigene Identität. Attribute sind vollständig unter der Kontrolle der Objekte, zu denen sie gehören. Notation Innerhalb von Klassen werden Attribute in einer eigenen Rubrik notiert, wie in Abb. 4.5-3 zu sehen. Attribute werden entweder nur mit ihrem Namen genannt oder detaillierter in folgender Syntax: Attributname : Paket::Klasse = Initialwert

Beispiele: name : String = ´Unbekannt´ gebDatum : Date time : DateTime::Time

Attributnamen beginnen mit Kleinbuchstaben, Klassennamen mit Großbuchstaben. Erläuterung Es existieren in der UML noch weitere Beschreibungsdetails für Attribute (siehe [Oestereich01a]), die im Rahmen der Geschäftsprozessmodellierung jedoch weniger wichtig sind.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.5 Geschäftsklassenmodell

4.5.4 Operation Standard-UML-Element. Verwandte Begriffe: Methode, Service, Prozedur, Routine, Funktion, Botschaft, Nachricht, message, Dienstleistung. Definition Operationen sind Dienstleistungen, die von einem Objekt angefordert 4.5.1 Klasse 189 werden können, sie werden beschrieben durch ihre Signatur (Operationsname, Parameter, ggf. Rückgabetyp). Eine Methode29 implementiert eine Operation, sie ist eine Sequenz von Anweisungen. Eine Nachricht überbringt einem Objekt die Information darüber, welche Aktivität von ihm erwartet wird, und fordert es so zur Ausführung einer Operation auf. Notation Die Signatur einer Operation hat folgende Syntax: Operationsname (argument : Argumenttyp, ...): Rückgabetyp

Beispiel: pruefeBonitaet(betrag : Euro): boolean

Der Name der Operation beginnt mit einem Kleinbuchstaben. Ein Argument trägt einen mit einem Kleinbuchstaben beginnenden Namen und wird eventuell durch die Nennung eines Datentyps bzw. einer Klasse näher beschrieben. Zwischen Argumentname und -typ steht in diesem Fall ein Doppelpunkt. Die Methode enthält den Code zur Implementierung und ist deswegen programmiersprachenspezifisch. Erläuterung Es existieren in der UML noch weitere Beschreibungsdetails für Operationen (siehe [Oestereich01a]), die im Rahmen der Geschäftsprozessmodellierung jedoch weniger wichtig sind.

29

Abweichend von diesen Definitionen werden die Begriffe Operation und Methode häufig synonym oder entsprechend der Definition der verwendeten Programmiersprache gebraucht.

193

194

4.5 Geschäftsklassenmodell

4.5.5 Assoziation Standard-UML-Element. Verwandte Begriffe: Aggregation, Komposition, link, Objektverbindung, Relation. Definition 4.5.1 Klasse 189

Eine Assoziation beschreibt als Relation zwischen Klassen die gemeinsame Semantik und Struktur einer Menge von Objektverbindungen. Eine gerichtete Assoziation ist eine Assoziation, bei der von der einen beteiligten Assoziationsrolle zur anderen direkt navigiert werden kann, nicht aber umgekehrt. Eine Aggregation ist eine Assoziation, erweitert um den semantisch unverbindlichen Kommentar, dass die beteiligten Klassen keine gleichwertige Beziehung führen, sondern eine Ganze-Teile-Hierarchie darstellen. Eine Aggregation soll beschreiben, wie sich etwas Ganzes aus seinen Teilen logisch zusammensetzt. Notation Beziehungen werden durch eine Linie zwischen den beteiligten Klassen dargestellt. An den jeweiligen Enden kann die Multiplizität (Mengenwertigkeit) der Beziehung angegeben werden. Jede Beziehung sollte mit einem Namen versehen werden (wird kursiv gesetzt), der beschreibt, worin oder warum diese Beziehung besteht. Damit die Klassennamen und die Bezeichnung der Beziehung in richtiger Richtung lesbar sind, kann neben dem Beziehungsnamen ein kleines ausgefülltes Dreieck gezeichnet werden, dessen Spitze in die Leserichtung zeigt. An jedem Ende einer Beziehung können zusätzlich Rollennamen angegeben werden (Namenskonvention wie bei Attributen). Ein Rollenname beschreibt, wie das Objekt durch das in der Assoziation gegenüberliegende Objekt gesehen wird.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.5 Geschäftsklassenmodell

Klasse A

1..*

0..*

Assoziationsname

Rolle A

Rolle B

Klasse B

Klasse A

Gerichtete Assoziation

Klasse B

Ganzes

Aggregation

Teil

Abb. 4.5-5: Notationsformen von Assoziationen

Die Multiplizität wird als einzelne Zahl oder Wertebereich auf jeder Seite der Assoziation notiert. Ein Wertebereich wird durch Angabe des Minimums und des Maximums, getrennt durch zwei Punkte, notiert (z.B. 1..5). Ein * ist ein Joker (engl. wildcard) und bedeutet „viele“. Mit einem Komma werden unterschiedliche Möglichkeiten aufgezählt. Beispiele für Multiplizitätsangaben: 1 genau eins 0, 1 null oder eins 0..4 zwischen null und vier 3, 7 genau drei oder sieben 0..* größer oder gleich null * dto. 1..* größer oder gleich eins 0..3, 7, 9..* zwischen null und drei oder genau sieben oder größer oder gleich neun Gerichtete Assoziation. Eine gerichtete Assoziation wird wie eine gewöhnliche Assoziation notiert, jedoch hat sie auf der Seite der Klasse, zu der navigiert werden kann, also in Navigationsrichtung, eine geöffnete Pfeilspitze. Multiplizität und Rollenname sind nur auf der Seite der Assoziation relevant, zu der navigiert werden kann. Aggregation. Eine Aggregation wird wie eine Assoziation als Linie zwischen zwei Klassen dargestellt und zusätzlich mit einer kleinen Raute versehen. Die Raute steht auf der Seite des Aggregats, also des Ganzen. Sie symbolisiert gewissermaßen das Behälterobjekt, in dem die Einzelteile gesammelt sind. Im Übrigen gelten alle Notationskonventionen der Assoziation. Die Kardinalitätsangabe auf der Seite des Aggregats ist häufig 1, so dass ein Fehlen der Angabe standardmäßig als 1 interpretiert werden kann. Ein Teil kann gleichzeitig zu mehreren Aggregationen gehören.

195

196

4.5 Geschäftsklassenmodell

Erläuterung Eine Assoziation beschreibt eine Verbindung zwischen Klassen. Die konkrete Beziehung zwischen zwei Objekten dieser Klassen wird Objektverbindung (engl. link) genannt. Objektverbindungen sind also die Instanzen einer Assoziation. Aggregationen sind gewöhnlich 1-zu-viele-Beziehungen. Bei 1-zu-1Beziehungen fehlen meistens die Indikatoren für eine Aggregation. Die Multiplizität einer Assoziation gibt an, mit wie vielen Objekten der gegenüberliegenden Klasse ein Objekt assoziiert sein kann. Wenn diese Zahl variabel ist, wird die Bandbreite, d.h. Minimum und Maximum angegeben. Liegt das Minimum bei 0, bedeutet dies, dass die Beziehung optional ist. Eine Bandbreite drückt auch immer einen zeitlichen Aspekt aus, d.h., die Anzahl der assoziierten Objekte verändert sich im Laufe der Zeit. Jede Assoziation kann mit einem Namen versehen werden, der die Beziehung näher beschreiben sollte. Auf jeder Seite der Assoziation lässt sich mittels Rollennamen genauer angeben, welche Rolle die jeweiligen Objekte in der Beziehung einnehmen. Außerdem können Zusicherungen verwendet werden, um die Beziehung speziell einzuschränken. In der folgenden Abbildung wird eine Beziehung zwischen einer Firma und ihren Mitarbeitern gezeigt. Die Beziehung wird wie folgt gelesen: „1 Firma (in der Rolle Arbeitgeber) beschäftigt * Mitarbeiter (in der Rolle Arbeitnehmer)“. Der * steht für beliebig viele Exemplare. Firma

1

0..*

beschäftigt

Arbeitgeber

Arbeitnehmer

Mitarbeiter

Abb. 4.5-6: Beispiel Assoziation

Aggregation. Unter einer Aggregation versteht man die Zusammensetzung eines Objektes aus einer Menge von Einzelteilen. Es handelt sich um eine Ganze-Teile-Hierarchie. Kennzeichnend für alle Aggregationen ist, dass das Ganze Aufgaben stellvertretend für seine Teile wahrnimmt. Die Aggregatklasse enthält beispielsweise Operationen, die keine unmittelbare Veränderung im Aggregat selbst bewirken, sondern die die Nachricht an seine Einzelteile weiterleiten. Man nennt dies Propagieren von Operationen. Im Gegensatz zur Assoziation führen die beteiligten Klassen also keine gleichberechtigte Beziehung, sondern eine Klasse (das Aggregat) bekommt eine besondere Rolle und übernimmt stellvertretend die Verantwortung und Führung. In einer Aggregationsbeziehung zwischen zwei Klassen muss genau ein Ende der Beziehung das Aggregat sein und das andere für die Einzel-

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.5 Geschäftsklassenmodell

teile stehen. Würde auf keiner Seite ein Aggregat stehen, wäre es eine normale Assoziation; würden beide Seiten ein Aggregat verzeichnen, wäre dies ein Widerspruch, sie würden sich gegenseitig ihre Führungsrolle streitig machen. Zu beachten ist, dass der hier beschriebene Unterschied zwischen einer Assoziation und einer Aggregation lediglich Kommentarcharakter hat. Streng genommen sind Assoziation und Aggregation semantisch gleichwertig; so sind sie beispielsweise auch im resultierenden Programmcode nicht unbedingt zu unterscheiden. Rumbaugh spricht deshalb in seinem UML-Buch von einem „Placebo“ ([Rumbaugh99, S. 148]).

197

198

4.5 Geschäftsklassenmodell

4.5.6 Spezialisierung/Generalisierung von Klassen Standard-UML-Element. Verwandte Begriffe: Vererbung, inheritance, Konkretisierung, Generalisierung. Definition Spezialisierung und Generalisierung sind Abstraktionsprinzipien zur hierarchischen Strukturierung der Semantik eines Modells. Eine Spezialisierung (bzw. Generalisierung) ist eine taxonomische30 Beziehung zwischen einem allgemeinen und einem speziellen Element (bzw. umgekehrt), wobei das speziellere Element weitere Eigenschaften hinzufügt und sich kompatibel zum allgemeinen verhält. Notation Die folgende Abbildung zeigt drei baumartig zusammengefasste Spezialisierungsbeziehungen. Mieter, Fahrer und Käufer sind verschiedene Spezialisierungen von Kunde. Die Vererbungsbeziehung wird mit einem großen, nicht ausgefüllten Pfeil dargestellt, wobei der Pfeil von der Unterklasse (spezielles Element) zur Oberklasse (allgemeines Element) zeigt. Wahlweise werden die Pfeile direkt von den Unterklassen zur Oberklasse gezogen oder wie in der Abbildung zu einer gemeinsamen Linie zusammengefasst. Die direkten Pfeile erlauben ein flexibleres Layout und sind auch mit freier Hand gut zu zeichnen. Die zusammengefassten Pfeile betonen stärker die Gemeinsamkeit der Unterklassen, nämlich dass sie Spezialisierungen einer Oberklasse aufgrund eines gemeinsamen Diskriminators sind. Kunde

Kundenrolle

Mieter

Fahrer

Käufer

Abb. 4.5-7: Beispiel einer Spezialisierungsbeziehung

30

Griech., taxis: „Anordnung“; Taxonomie: „Einordnung in ein System“.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.5 Geschäftsklassenmodell

Erläuterung Bei der Generalisierung bzw. Spezialisierung werden Eigenschaften hierarchisch gegliedert, d.h. Eigenschaften allgemeinerer Bedeutung werden allgemeineren Klassen (Oberklassen) zugeordnet und speziellere Eigenschaften werden Klassen zugeordnet, die den allgemeineren untergeordnet sind (Unterklassen). Die Eigenschaften der Oberklassen werden an die entsprechenden Unterklassen weitergegeben, d.h. vererbt. Eine Unterklasse verfügt demnach über die in ihr spezifizierten Eigenschaften sowie über die Eigenschaften ihrer Oberklasse(n). Unterklassen erben alle Eigenschaften ihrer Oberklassen, können diese überschreiben und erweitern, jedoch nicht elimieren bzw. unterdrücken. Die Unterscheidung in Ober- und Unterklassen erfolgt häufig aufgrund eines Diskriminator genannten Unterscheidungsmerkmales, d.h. eines Charakteristikums. Der Diskriminator bezeichnet den für die hierarchi- Diskriminator sche Strukturierung der Eigenschaften maßgeblichen Aspekt. Dieser ist nicht von selbst gegeben, sondern das Ergebnis einer Modellierungsentscheidung. Beispielsweise könnte man Fahrzeuge aufgrund des Diskriminators Antriebsart untergliedern (Verbrennungsmaschine, Elektrisch, Pferdekraft), ebenso aber auch aufgrund des Fortbewegungsmediums (Luft, Wasser, Schiene, Straße). Ob und welcher Diskriminator gewählt wird, hängt vom semantischen Gehalt der Generalisierungsrelation ab. Sofern die erstellten Unterklassen als Elemente einer definierten Aufzählungsmenge betrachtet werden können (Luft, Wasser, ...), ist der Diskriminator meistens nahe liegend. Es ist hilfreich, sich den Diskriminator während des Modellierens explizit zu vergegenwärtigen und ihn auch in die grafische oder textuelle Modellbeschreibung aufzunehmen. Die Wahl des Diskriminators ist dann eine dokumentierte Entwurfsentscheidung.

199

200

4.5 Geschäftsklassenmodell

4.5.7 Abstrakte Klasse Standard-UML-Element. Verwandte Begriffe: abstract class, virtuelle Klasse. Definition 4.5.1 Klasse 189

Von einer abstrakten Klasse existieren niemals konkrete Exemplare; sie ist bewusst unvollständig definiert und bildet somit die Basis für weitere Unterklassen, für die es dann konkrete Exemplare geben kann. Notation Eine abstrakte Klasse wird wie eine normale Klasse dargestellt, der Klassenname wird jedoch kursiv gesetzt. Alternativ kann unter dem Klassennamen auch {abstrakt} geschrieben werden. Ansonsten können Attribute, Operationen usw. Bestandteil der Klasse sein. Kunde {abstract}

Kunde

Abb. 4.5-8: Notationsvarianten einer abstrakten Klasse

Erläuterung Abstrakte Klassen repräsentieren häufig einen Allgemeinbegriff, einen Oberbegriff für eine Menge konkreter Begriffe. So kann Fahrzeug ein abstrakter Oberbegriff von Fahrrad, Pkw, Lkw, Bahn und Flugzeug sein. Von den konkreten Begriffen Fahrrad, Pkw etc. gibt es reale Exemplare. Ein Ding, das jedoch einfach nur Fahrzeug ist, gibt es nicht. Fahrzeug ist lediglich eine Abstraktion, eine Verallgemeinerung. Oberklasse Spezialisierung 198

Eine abstrakte Klasse ist immer eine Oberklasse. Eine abstrakte Klasse, die keine Unterklassen hat, ist sinnlos. Entweder ist sie überflüssig oder es fehlt eine konkrete Klasse als Unterklasse.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.5 Geschäftsklassenmodell

4.5.8 Schnittstelle Standard-UML-Element. Verwandte Begriffe: Schnittstellenklasse, interface, interface class. Definition Schnittstellen beschreiben einen ausgewählten Teil des extern sichtba- 4.5.1 Klasse 189 ren Verhaltens von Modellelementen (hauptsächlich von Klassen und Komponenten). Notation Schnittstellenklassen sind abstrakte Klassen (genauer: Typen), die ausschließlich abstrakte Operationen definieren. Es können auch Attribute angegeben werden, dies hat aber nur kommentierenden Charakter, denn das Objekt muss dieses Attribut nicht tatsächlich implementieren, es reicht, wenn es sich (mit seinen Operationen) so verhält, als hätte es das Attribut. Schnittstellenklassen werden wie gewöhnliche Klassen notiert, sie tragen jedoch das Stereotyp «interface». Der Sachverhalt, dass eine Klasse eine Schnittstelle implementiert, kann auf zwei unterschiedliche Weisen deutlich gemacht werden. Zum einen kann eine Realisierungsbeziehung notiert werden, wie das in Abb. 4.5-9 zu sehen ist. Die Realisierungsbeziehung sieht aus wie eine Vererbungsbeziehung, die Linie ist jedoch gestrichelt. Wenn Ihr Modellierungswerkzeug dies nicht unterstützt, nehmen Sie einfach eine normale Vererbungsbeziehung und kennzeichnen diese mit dem Stereotyp «realize». Die andere Möglichkeit, die Implementierung einer Schnittstelle darzustellen, ist das Hinzufügen des „Lolli“-Symbols an die bereitstellende Klasse. Daneben wird der Name der Schnittstelle genannt; er entspricht dem Namen der zugehörigen Schnittstellenklasse. Die beiden Varianten sind gleichbedeutend. Bei der Schreibweise mit der Realisierungsbeziehung besteht die Möglichkeit, die durch die Schnittstellenklasse geforderten Operationen abzulesen. Die LolliVariante ist eine Kurzschreibweise, man sieht die von der Schnittstelle geforderten Operationen jedoch nicht direkt, sondern nur den Namen der Schnittstellenklasse. Siehe hierzu Abb. 4.5-9.

201

202

4.5 Geschäftsklassenmodell

«interface» Schnittstelle Anforderung bzw. Nutzung einer Schnittstelle

Implementierung bzw. Bereitstellung einer Schnittstelle Implementierende Klasse

Bereitgestellte Schnittstelle

Klasse Benötigte Schnittstelle

Abb. 4.5-9: Notationselemente und -varianten für Schnittstellen

Die Nutzung einer Schnittstelle durch andere Klassen kann durch eine Abhängigkeitsbeziehung (gestrichelter Pfeil) notiert werden. Die Nutzung einer Schnittstelle setzt voraus, dass der Nutzer den Schnittstellenanbieter kennt, d.h. gewöhnlich liegt außerdem eine Assoziation vor. Die Abhängigkeitsbeziehung ist jedoch kein Notationsersatz hierfür. Wenn eine Klasse eine Schnittstelle (einer anderen Klasse) benötigt, kann es mit einem abgeschnittenen Lolli-Symbol dargestellt werden. Erläuterung Mit einer Schnittstelle kann das nach außen sichtbare und verfügbare Verhalten eines Systems (Subsystem, Klasse, Komponente, externes System etc.) formal spezifiziert werden. Wenn verschiedene Systeme zusammenarbeiten, dann kommunizieren diese idealerweise über eine definierte Schnittstelle. Systeme können Schnittstellen nach außen bereitstellen und sie können bestimmte Schnittstellen anderer Systeme benötigen. Schnittstellen in Software haben konzeptionell eine Ähnlichkeit mit Steckern und Buchsen in der Elektrotechnik oder Elektronik. Schnittstellen werden dabei durch ihre Funktionalität beschrieben, d.h. welche Operationen sie anbieten (sozusagen das Format). Passen die Schnittstellen zweier Systeme nicht zueinander, muss ein Adapter dazwischen gesetzt werden. Auch dies gibt es in der Softwaretechnik. Die Beschreibung von Schnittstellen ist interessant, wenn  ein System mit einer festen, unabänderlichen Schnittstelle gegeben ist, beispielsweise ein Altsystem,  eine bestimmte von außen vorgegebene Schnittstellenform (ein gegebene Format) einzuhalten ist, beispielsweise ein Standard oder eine Norm,

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.5 Geschäftsklassenmodell

 verschiedene Parteien, beispielsweise zwei Abteilungen, Teams o.Ä., über eine vorgegebene Schnittstelle, d.h. in einer bestimmten Form zusammenarbeiten sollen,  verschiedene Parteien sich untereinander auf eine gemeinsame Schnittstelle, d.h. ein gemeinsames Protokoll, für ihre künftige Zusammenarbeit verständigen. Die Definition von Schnittstellen ist hilfreich, um die Kopplung und Abhängigkeit zwischen zwei Systemen (Klassen) zu explizieren und zu reduzieren. Verschiedene Klassen, die eine Assoziation zueinander besitzen, vereinbaren über Schnittstellen, welche ihrer Eigenschaften für die jeweils andere Klasse sichtbar und zugänglich sein soll. Mit Hilfe von Schnittstellen können verschiedene Entwickler Verträge schließen (design/programming by contract): Der eine hat die Schnittstelle in seiner Klasse zu implementieren, der oder die anderen können nur die Eigenschaften nutzen, die in der Schnittstelle vereinbart sind. Moderne Programmiersprachen wie Java unterstützen Schnittstellen explizit, d.h., die Verträge können vom Compiler überprüft werden. Schnittstellen sind Spezifikationen des externen Verhaltens von Klassen (oder anderer Elemente) und beinhalten eine Menge von Signaturen für Operationen, die Klassen (o.a.), die diese Schnittstelle bereitstellen wollen, implementieren müssen. Gewöhnliche Klassen, die eine Schnittstelle implementieren wollen, müssen alle in der zugehörigen Schnittstellenklasse definierten Operationen bereitstellen. Eine gewöhnliche Klasse kann mehrere Schnittstellen implementieren und darüber hinaus weitere Eigenschaften enthalten. Anders ausgedrückt: Eine Schnittstelle beschreibt in der Regel eine Untermenge der Operationen einer Klasse.

203

204

4.6 Pakete

4.6

Pakete

Standard-UML-Element. Verwandte Begriffe: package. Definition Ein Paket ist eine Ansammlung von Modellelementen beliebigen Typs, mit denen das Gesamtmodell in Namensräume, d.h. kleinere überschaubare Einheiten, gegliedert wird. Innerhalb eines Paketes müssen die enthaltenen Elemente einen eindeutigen Namen haben. Jedes Modellelement kann in anderen Paketen referenziert werden, gehört aber stets zu genau einem Heimatpaket. Notation Ein Paket wird in Form eines Aktenregisters dargestellt. Innerhalb dieses Symbols steht der Paketname. Die in einem Paket enthaltenen Elemente können ebenfalls innerhalb des Symbols dargestellt werden. Pakete können Spezialisierungs- und Abhängigkeitsbeziehungen haben. Alternativ kann eine Paketstruktur als Baum dargestellt werden.

Paket

Paket

Paket

Anwendungsfall Anwendungsfall

Abb. 4.6-1: Notation von Paketen

Praxis Die folgende Abb. 4.6-2 zeigt eine typische Paketstruktur. Auf oberster Ebene werden zunächst Kern- und unterstützende Prozesse unterschieden, darunter liegen dann verschiedene Arten von Anwendungsfällen und Anforderungen. Pakete können auch verwendet werden, um fachliche Subsysteme zu bilden, d.h. Einheiten, die eine Menge von fachlich zusammengehörenden Klassen darstellen.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.6 Pakete

Wurzel Kern-Geschäftsprozesse

-

Geschäftsanwendungsfälle

-

GAF 1 ... Sekundäre Anwendungsfälle

+

Systemanwendungsfälle

+

Sonstige Anforderungen +

Ziele

+

Features

+

Probleme

+

Funktionale Anforderungen

+

Nichtfunktionale Anforderungen

Unterstützende Geschäftsprozesse

-

Geschäftsanwendungsfälle

-

GAF 1 ... +

Sekundäre Anwendungsfälle

+

Systemanwendungsfälle Sonstige Anforderungen +

Ziele

+

Features

+

Probleme

+

Funktionale Anforderungen

+

Nichtfunktionale Anforderungen

Abb. 4.6-2: Beispiel einer Paketstruktur

205

206

4.7 Organisationsplan

4.7

Organisationsplan

Stereotyp, Teil des OOGPM-Profils. Verwandte Begriffe: Organisationsmodell, Organisationsstruktur, Organigramm. Definition Ein Organisationsplan ist die grafische Darstellung struktureller Beziehungen zwischen Organisationseinheiten eines betrachteten Unternehmens. Notation Ein Organisationsplan wird mit Hilfe des UML-Klassendiagramms dargestellt, das Organisationseinheiten und Organisationsbeziehungen enthält, die in den folgenden Abschnitten näher erläutert werden. Geschäftsleitung

Verkauf

Produktion

Inland

Hannover

Ausland

Stuttgart

Entwicklung

Verwaltung

Abb. 4.7-1: Organisationsplan-Beispiel

Praxis Organisationspläne veranschaulichen Verantwortlichkeitsbereiche, Berichtswege, disziplinarische und fachliche Weisungsbefugnisse bzw. -abhängigkeiten. Sie geben Auskunft darüber, wie diese Einheiten heißen, welche konkreten Personen sie leiten usw.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.7 Organisationsplan

4.7.1 Organisationseinheit Stereotyp, Teil des OOGPM-Profils. Verwandte Begriffe: OrgaEinheit, Orgeinheit, Abteilung, Fachabteilung, Fachbereich. Definition Eine Organisationseinheit ist ein Teil einer ganzen Organisationsstruktur (i.d.R. eines Unternehmens) und dient der Aufteilung von betriebswirtschaftlichen Verantwortlichkeiten. Als solche erfüllt sie einen bestimmten Zweck, bündelt fachliche zugeteilte Aufgaben und grenzt sich dadurch von anderen Organisationseinheiten ab. In der Regel wird jeder Geschäftsmitarbeiter disziplinarisch genau einer Organisationseinheit zugeordnet. Notation Eine Organisationseinheit wird als Klasse31 dargestellt und mit dem entsprechenden Zusatz (UML-Jargon: Stereotyp) «organization unit» (für gewöhnliche Organisationseinheiten) versehen oder mit einem Schrägstrich rechts unten gezeichnet. Orgeinheit

«organization unit» Orgeinheit

Abstrakte Orgeinheit

Orgeinheit {Stabsstelle}

Orgeinheit kürzel leitung stellvertretung kostenstelle

Abb. 4.7-2: Notationsvarianten von Organisationseinheiten

Die für eine Organisationseinheit festzuhaltenden beschreibenden Elemente, wie Kürzel, Leitung, Kostenstelle usw., können als Attribute der Organisationseinheit modelliert werden. Die Verantwortlichkeiten der Organisationseinheit indes können im Abschnitt darunter stichpunktartig notiert werden. Eine besondere Organisationseinheit ist die abstrakte Organisationseinheit, die mit der Eigenschaft {abstrakt} gekennzeichnet wird. Mit ihr lässt sich darstellen, dass ein Begriff für eine Organisationseinheit im Sprachgebrauch des Unternehmens nur als abstrakter Oberbegriff existiert und zusammenfassend für eine Menge von konkreten Organisationseinheiten mit ähnlichen Verantwortlichkeiten verwendet wird (z.B. „Rechnungswesen“ als abstrakter Oberbegriff für die konkreten Orga31

Pakete kommen nicht in Frage, weil Pakete keine Semantik haben, eine Orgeinheit aber ein semantisches Konstrukt ist.

207

208

4.7 Organisationsplan

nisationseinheiten „Finanzbuchhaltung“ und „Lohnbuchhaltung“). Abstrakte Organisationseinheiten haben in der Regel selbst keine beschreibenden Eigenschaften, wie Kürzel, Kostenstelle oder Leiter. Erläuterung Die Aufteilung einer Organisation in Einheiten erfolgt häufig entweder nach betriebswirtschaftlichen Funktionen wie Forschung, Produktion, Vertrieb, Verwaltung (sog. funktionale Aufteilung) und/oder nach Produkten oder Sparten wie Farben, Pharma, Kunststoffe (sog. divisionale Aufteilung). Beispiele für Organisationseinheiten bzw. Organisationspläne befinden sich in Abb. 3.7-5 (75), Abb. 3.14-2 (116) und Abb. 3.14-4 (117).

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.7 Organisationsplan

4.7.2 Organisationsbeziehungen Stereotyp, Teil des OOGPM-Profils Definition Es werden folgende Arten von Beziehungen unterschieden: disziplinarische Weisungsbefugnis, fachliche bzw. funktionale Weisungsabhängigkeit, Berichtswege und Spezialisierungen/Generalisierungen. Notation Ein Organisationsplan wird mit Hilfe des UML-Klassendiagramms aufgestellt. Die verschiedenen Arten von Organisationseinheiten werden dabei als Klassen mit entsprechendem Klassifikationszusatz (UML-Jargon: Stereotyp) dargestellt. Die unterschiedlichen Beziehungen zwischen den angegebenen Organisationseinheiten werden durch verschiedenartige Linienformen (durchgezogen, gestrichelt) und Pfeilspitzen (offen, geschlossenes Dreieck) repräsentiert. Folgende Abbildung zeigt die verschiedenen Darstellungsmöglichkeiten: B

Disziplinarische Weisungsbefugnis (A weist B an) und Verantwortung (A ist für B verantwortlich)

B

Berichtsweg (B berichtet an A)

A

B

Spezialisierung (B ist eine Art A)

A

B

Funktionale Weisungsabhängigkeit mit fachlicher Verantwortung (B ist funktional weisungsabhängig von A)

A

A

«reporting»

Abb. 4.7-3: Notationsvarianten von Beziehungen zwischen Organisationseinheiten

Die gebräuchlichste Bedeutung von Beziehungen zwischen Organisationseinheiten ist die disziplinarische Weisungsbefugnis und Gesamtverantwortung. Sie wird als durchgezogene Linie mit offener Pfeilspitze zur unterstellten Organisationseinheit dargestellt und bedarf keiner besonderen Kennzeichnung. Die ebenfalls oft verwendete funktionale Weisungsabhängigkeit mit fachlicher Verantwortung (zum Beispiel bei matrixartigen Projektorganisationen) wird als gestrichelte Linie mit offener Pfeilspitze dargestellt.

209

210

4.7 Organisationsplan

Andere Arten von Beziehungen zwischen Organisationseinheiten können als entsprechend klassifizierte gestrichelte Pfeile angegeben werden (z.B. Berichtswege). Der Pfeil zeigt grundsätzlich vom abhängigen Element zum unabhängigen Element. Bei einer Weisungsabhängigkeit zeigt der Pfeil von der angewiesenen auf die anweisende Organisationseinheit. Eine besondere strukturelle Beziehung ist die Generalisierung. Mit ihr lässt sich der Zusammenhang zwischen abstrakten (vgl. 4.5.6 Spezialisierung 198) und den dazugehörigen konkreten Organisationseinheiten abbilden. Diese Beziehung wird als durchgezogene Linie mit einem geschlossenen Dreieck als Pfeilspitze dargestellt, wobei die Pfeilspitze stets vom speziellen zum allgemeinen Begriff gezeichnet wird. Sie wird (in Pfeilrichtung gelesen) interpretiert als: „… ist eine Art …“, zum Beispiel „die Finanzbuchhaltung-Orgeinheit ist eine Art Rechnungswesen-Orgeinheit“. Erläuterung Mit dem Konzept der abstrakten Organisationseinheit lassen sich auch Matrixorganisationen sehr effizient und erhellend darstellen: Funktionale Struktur (Funktionsbereiche)

Leitung

Divisionale Struktur (Sparten)

Forschung

Produktion

Absatz

Verwaltung

Farben

Pharma

Produktionsnahe Orgeinheit

Kunststoffe

Abb. 4.7-4: Beispiel einer Matrixstruktur

Die Organisationseinheiten sind bei Matrixorganisationen typischerweise nach zwei unterschiedlichen Kriterien aufgeteilt, so dass daraus orthogonal zueinander stehende Abteilungen resultieren, deren disziplinarische Weisungsbefugnis bewusst gleichwertig gestaltet wurde. Die Zusammenarbeit ergibt sich allenfalls aus einer funktionalen Weisungsbefugnis mit fachlicher Verantwortung. Im dargestellten Beispiel sind alle divisionalen Organisationseinheiten allen produktionsnahen Einheiten fachlich weisungsbefugt (bzw. Forschung, Produktion und Absatz sind weisungsabhängig), nicht jedoch gegenüber der Verwaltung.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.8 Zustandsmodelle

4.8

Zustandsmodelle

Standard-UML-Element. Verwandte Begriffe: state diagram, state transition diagram, state machine, Zustandübergangsdiagramm, endlicher Automat. Definition Ein Zustandsmodell zeigt eine Folge von Zuständen, die ein Objekt im Laufe seines Lebens einnehmen kann, und beschreibt, aufgrund welcher Stimuli Zustandsänderungen stattfinden. Ein Zustandsmodell beschreibt eine hypothetische Maschine (endlicher Automat), die sich zu jedem Zeitpunkt in einer Menge endlicher Zustände befindet und aus folgenden Komponenten besteht:  einer endlichen, nicht leeren Menge von Zuständen,  einer endlichen, nicht leeren Menge von Ereignissen,  Zustandsübergängen,  einem Anfangszustand  und einer Menge von Endzuständen. Notation Die einzelnen Bestandteile werden in den folgenden Abschnitten näher erläutert. reservieren() [freiePlaetze>1]

stornieren() [reserviertePlaetze>1] Flug einrichten()

Ohne Reservierung

reservieren()

Teilweise reserviert

stornieren() [reserviertePlaetze=1]

stornieren()

Flug streichen() Ende

schliessen()

reservieren() [freiePlaetze=1]

Ausgebucht

Start Geschlossen schliessen()

Abb. 4.8-1: Zustandsmodell am Beispiel Flug-Reservierung

Erläuterung Das Beispiel in Abb. 4.8-1 zeigt die Zustandsübergänge für eine Flugreservierung. Sofern die Namen des Ereignisses und der Aktionsoperation übereinstimmen, ist nur die Operation angegeben. Der Startzustand

211

212

4.8 Zustandsmodelle

führt bei Einrichtung des Fluges in den Zustand OhneReservierung. Wird nun eine Reservierung für diesen Flug vorgenommen, wechselt das Objekt in den Zustand TeilweiseReserviert. Mit dem Ereignis Reservieren ist die gleichnamige Aktion Reservieren (realisiert durch eine Operation) verbunden. In dieser Operation findet die eigentliche Reservierung statt und der interne Reservierungszähler wird aktualisiert. Nach Abschluss dieser Aktion befindet sich das Objekt im Zustand TeilweiseReserviert. Jede weitere Reservierung führt zur selben Aktion. Solange noch freie Plätze vorhanden sind, bleibt das Objekt im Zustand TeilweiseReserviert. Ist nur noch ein Platz frei, wird in den Zustand Ausgebucht gewechselt. Die Stornierung von reservierten Plätzen erfolgt in ähnlicher Weise. Das Zustandsdiagramm beschreibt also, durch welche Ereignisse welche Aktivitäten ausgelöst werden und wann diese (und damit der Aufruf der entsprechenden Operationen) zulässig sind. Ein weiteres Beispiel befindet sich in Abb. 3.17-1 (128).

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.8 Zustandsmodelle

4.8.1 Zustand Verwandte Begriffe: state, Startzustand, Endzustand. Definition Ein Zustand gehört zu genau einer Klasse und stellt eine fachlich motivierte Abstraktion bzw. Zusammenfassung einer Menge von möglichen Attributwerten dar, die die Objekte dieser Klasse einnehmen können. Zustandsdiagramme beschreiben das innere Zustandsmodell eines Objektes. Notation Zustände werden durch abgerundete Rechtecke dargestellt, in denen der Name des Zustandes steht. Um Diagramme übersichtlicher zu gestalten, können Zustände mehrfach in einem Diagramm vorhanden sein. Start

Ende

Zustand

Abb. 4.8-2: Notation eines gewöhnliches Zustandes sowie Start- und Endzustand

Erläuterung Nicht jede Änderung eines Attributwertes des Objektes wird hier als Zustandsänderung angesehen. Die Abstraktion besteht darin, nur solche Ereignisse zu berücksichtigen, die das Verhalten des Objektes maßgeblich beeinflussen. Ein Zustand kann demnach auch als Zeitspanne zwischen zwei Ereignissen angesehen werden. Zwei besondere Zustandstypen sind Start- und Endzustände (siehe auch Start- und Endzustand 177). Zu einem Startzustand kann kein Übergang stattfinden, von einem Endzustand führt kein Ereignis mehr weg. Nicht jede Klasse muss über Zustände verfügen, sie muss dazu entsprechendes signifikantes Verhalten zeigen. Können alle Operationen eines Objektes unabhängig von seinem inneren Zustand in beliebiger Reihenfolge aufgerufen werden, ist eine Zustandsmodellierung nicht erforderlich.

213

214

4.8 Zustandsmodelle

4.8.2 Ereignis und Zustandsübergang Standard-UML-Element. Verwandte Begriffe: event, transition. Definition Ein Ereignis ist ein zu beachtendes Vorkommnis, das in einem gegebenen Kontext eine Bedeutung hat, sich räumlich und zeitlich lokalisieren lässt und einen Zustandsübergang (Transition) auslöst. Notation Ereignisse werden durch Pfeile von einem Zustand zum nächsten notiert. Ein Pfeil kann auch auf den gleichen Zustand zurückführen. Zustand

Transitionsbeschreibung

Zustand

Abb. 4.8-3: Notation von Zustandübergängen

Auf den Pfeilen werden die Transitionsbeschreibungen in folgender Form aufgetragen: ereignis(argumente) [bedingung] /operation(argumente) ^zielobjekte.gesendetesEreignis(argumente)

Erläuterung Übergänge von einem Zustand zum nächsten werden durch Ereignisse ausgelöst. Ein Ereignis besteht aus einem Namen und einer Liste möglicher Argumente. Ein Ereignis kann folgende Ursachen haben:  Eine (für eine Transition definierte) Bedingung wird erfüllt.  Das Objekt erhält eine Nachricht. Aus Zuständen und Ereignissen lassen sich Zustandsdiagramme bilden, die beschreiben, wann ein Objekt bestimmte Ereignisse erhalten darf und welche Folgen das für den Status des Objektes hat. Bestimmte Ereignisse können nur dann sinnvoll verarbeitet werden, wenn sich das Objekt in einem dafür geeigneten Zustand befindet. Ebenso kann ausgedrückt werden, dass ein Ereignis zu unterschiedlichen Aktionen führen kann, je nachdem, in welchem Zustand sich das Objekt befindet und welche Bedingungen an das Ereignis geknüpft sind.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

4.8 Zustandsmodelle

Zustandsübergänge werden gewöhnlich durch Ereignisse ausgelöst, die auf den Pfeilen zwischen den Zuständen notiert werden. Übergänge ε-Übergang ohne Ereignisbeschriftung werden automatisch ausgelöst, sobald die mit einem Zustand verbundenen Aktionen abgeschlossen sind (so genannte ε-Übergänge (Epsilon-Übergänge)). Ereignisse können mit Bedingungen versehen werden. Die an ein Er- Bedingung eignis geknüpften Bedingungen müssen erfüllt sein, damit der Zustandswechsel stattfinden kann. Die Bedingung kann unabhängig von dem Ereignis definiert werden. Beim Übergang von einem Zustand zum anderen kann des Weiteren einem anderen Objekt (Zielobjekt) ein Ereignis gesendet werden. Auf diese Weise lassen sich Zustandsautomaten verschiedener Klassen miteinander verknüpfen.

215

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

5 Anhang

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

5.1 Abkürzungsverzeichnis

5.1

Abkürzungsverzeichnis

Hier finden Sie die wichtigsten in diesem Buch verwendeten Abkürzungen. Einige Abkürzungen sind auch im Glossar mit entsprechenden Erläuterungen enthalten.

Allgemeine Begriffe ARIS Architektur integrierter Informationssysteme CI Corporate Identity EBIT Earnings Before Interest and Taxes EPK Ereignisgesteuerte Prozesskette ISO International Organization for Standardization OEP Object Engineering Process OMG Object Management Group ROCE Return on Capital Employed ROI Return on Investment SCM Supply Chain Management UML Unified Modeling Language

Modellelemente GAF GMA GP GPA GPM SAF

Geschäftsanwendungsfall Geschäftsmitarbeiter Geschäftsprozess Geschäftspartner Geschäftsprozessmodellierung Systemanwendungsfall

219

220

5.2

5.2 Glossar

Glossar

Das Glossar wurde freundlicherweise von der Firma oose.de Dienstleistungen für innovative Informatik GmbH zur Verfügung gestellt und befindet sich in aktueller Version unter http://www.oose.de/glossar. Sie können dort übrigens auch zu jedem Begriff persönliche Anmerkungen oder Vorschläge öffentlich sichtbar hinterlegen bzw. die Kommentare anderer lesen. Ablaufmodell Aktivitätsmodell Ein Modell oder Diagramm, das einen Ablauf beschreibt, beispielsweise ein UMLAktivitätsdiagramm. Ablauforganisation Ablauforganisation ist die zeitliche und räumliche Ordnung betrieblicher Prozesse innerhalb des durch die Aufbauorganisation geschaffenen Rahmens. Abstrakte Klasse Von einer abstrakten Klasse werden niemals Objektexemplare erzeugt; sie ist bewusst unvollständig und bildet somit die Basis für weitere Unterklassen, die Exemplare haben können. Abstraktion Abstraktion ist eine Methode, bei der unter einem bestimmten Gesichtspunkt die wesentlichen Merkmale eines Gegenstandes oder Begriffes hervorgestellt werden. Aggregation Assoziation Eine Aggregation ist eine Assoziation, bei der die beteiligten Klassen keine gleichwertige Beziehung führen, sondern eine GanzeTeile-Hierarchie darstellen. Eine Aggregation beschreibt, wie sich etwas Ganzes aus seinen Teilen zusammensetzt. Formal ist eine Assoziation der Aggregation gleichwertig, die Besonderheit der Ganze-Teile-Beziehung hat keine formale Semantik, sondern lediglich hilfreichen Kommentarcharakter. Akteur (UML) Akteur (OOGPM) Englisch Actor. Ein Akteur ist ein außerhalb des Systems agierender Beteiligter, der an der in einem Anwendungsfall beschriebenen Interaktion beteiligt ist. Akteur (OOGPM) Akteur (UML) Ein Akteur ist eine an der von einem Anwendungsfall beschriebenen Interaktion beteiligte Rolle. Diese kann außerhalb des be-

schriebenen Systems liegen (z.B. ein Benutzer in einem Systemanwendungsfall oder ein Geschäftspartner in einem Geschäftsanwendungsfall) oder innerhalb (z.B. ein Geschäftsmitarbeiter in einem Geschäftsanwendungsfall). Formal ist ein Akteur eine stereotypisierte Klasse. Im Gegensatz hierzu ist Akteur (UML) ein formal eigenständiges Modellelement. Aktiver Geschäftspartner Geschäftspartner, Akteur, Passiver Geschäftspartner Als aktive Geschäftspartner werden (natürliche oder juristische) Personen bezeichnet, die außerhalb des betrachteten Unternehmens (Modellierungsfokus) stehen und ein Geschäft aktiv initiieren. Aktive Geschäftspartner kommen aus eigener Initiative auf das Unternehmen zu und haben ein geschäftliches Anliegen. Aktive Geschäftspartner sind beispielsweise Kunden. Aktivität Eine Aktivität ist ein einzelner Schritt in einem Verarbeitungsablauf. Aktivitätsdiagramm Ein Aktivitätsdiagramm ist ein Ablaufdiagramm, das Aktivitäten und Transitionen enthält. Aktivitätsmodell Aktivitätsdiagramm, Modell, Diagramm Ein Aktivitätsmodell ist die Gesamtheit aller durch Aktivitäten und Transitionen beschriebenen Abläufe. Aktivitätsübergang Transition Ein Wechsel von einer Aktivität zur nächsten innerhalb eines Ablaufmodells. Analyse Die systematische Untersuchung eines Sachverhaltes oder Gegenstandes hinsichtlich bestimmter Aspekte, Faktoren oder Eigenschaften, die ihn bestimmen.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

5.2 Glossar

Anforderung Eine Anforderung beschreibt eine oder mehrere Eigenschaften oder Verhaltensweisen, die stets erfüllt sein sollen. Anwendungsfall Geschäftsanwendungsfall, Systemanwendungsfall Ein Anwendungsfall beschreibt einen zusammenhängenden Arbeitsablauf aus der Sicht seiner Akteure. Ein Anwendungsfall wird stets durch einen Akteur bzw. Ereignis initiiert und führt zu einem für die Akteure wahrnehmbaren Ergebnis. Ein Anwendungsfall beschreibt das gewünschte externe Systemverhalten aus der Sicht und in der Sprache der Anwender (d.h. in natürlicher Sprache) und somit Anforderungen, die das System zu erfüllen hat. Beschrieben wird, was es leisten muss, aber nicht, wie es dies leisten soll. Es werden verschiedene Arten von Anwendungsfällen unterschieden: Geschäftsanwendungsfall, Systemanwendungsfall. ARIS Die Architektur integrierter Informationssysteme ist eine von Prof. Dr. Dr. h.c. mult. August-Wilhelm Scheer entwickelte Modellierungsarchitektur für Geschäftsprozesse. Sie besteht aus einem Vorgehensmodell, Modellierungsmethoden (vgl. EPK) und Metamodellen und definiert verschiedene Sichten (Daten-, Funktions-, Organisations-, Ressourcen- und Steuerungssicht). Assoziation Eine Assoziation beschreibt eine Relation zwischen Klassen, d.h. die gemeinsame Semantik und Struktur einer Menge von Objektbeziehungen. Es werden gerichtete Assoziationen (nur einseitig direkt navigierbar) und bidirektionale Assoziationen (beidseitig direkt navigierbar) unterschieden. Aufbauorganisation Die Aufbauorganisation beschreibt die Zuständigkeiten für die arbeitsteilige Aufgabenerfüllung im Unternehmen. Sie legt Organisationseinheiten und deren hierarchische Beziehungen untereinander fest. Außenorientierter Geschäftsmitarbeiter Geschäftsmitarbeiter, Geschäftspartner Außenorientierte Geschäftsmitarbeiter nennen wir solche, die sich innerhalb des zu modellierenden Unternehmens bzw. Modellierungsfokus befinden und die Kontakt zu Ge-

221

schäftspartnern haben, die also beispielsweise mit Kunden und Lieferanten zu tun haben und für diese sichtbar sind. Balanced Scorecard Strategiekarte Die Balanced Scorecard ist ein Instrument der Unternehmensführung und ein systemischer Ansatz, der hilft, zielgerichtetes strategisches Denken und Handeln auf allen Ebenen im Unternehmen zu fördern. Die Grundidee nach [Kaplan01] besteht darin, strategische Führungsziele durch die Messung von Kennzahlen in den vier Bereichen Finanzperspektive, Kundenperspektive, Interne Prozessperspektive sowie Lern- und Entwicklungsperspektive in operative Maßnahmen umzusetzen. Betrachtungsgegenstand Modellierungsfokus Cash Flow Diese Kennzahl dient der Beurteilung des Innenfinanzierungspotenzials und der Ertragskraft des Unternehmens. Sie errechnet sich wie folgt: Cash Flow = Jahresüberschuss bzw. -fehlbetrag - Erträge aus Verlustübernahme + abgeführte Gewinne + Abschreibungen und Wertberichtigungen auf Sachanlagen und immaterielle Anlagenwerte + Abschreibungen und Wertberichtigungen auf Finanzanlagen mit Ausnahme des Betrages, der in die Pauschalwertberichtigung zu Forderungen eingestellt ist, + Zuführung zu Pensionsrückstellungen. Chance Risiko Die Chance ist die Aussicht auf Erfolg. Eine Chance kann ausgedrückt werden durch die Wahrscheinlichkeit ihres Auftretens und eines Gewinns im Eintrittfalls. CI Corporate Identity Corporate Identity Die Corporate Identity stellt die anzustrebende Einmaligkeit bzw. Persönlichkeit eines Unternehmens dar und hat den Zweck, das Unternehmen für seine relevanten Bezugsgruppen unverwechselbar zu machen. Sie wird explizit definiert und niedergeschrieben und trägt dadurch zu einem einheitlichen Auftreten, einheitlicher Haltung und gemeinsamen Werteverständnis bei. Mit den Mitteln der Corporate Communications, des Corporate Designs, der Corporate Culture sowie des Corporate Behaviours wird versucht, ein

222

5.2 Glossar

ganz bestimmtes Image betriebsintern und -extern aufzubauen. Diagramm Modell Ein Diagramm ist die grafische Repräsentation eines Modells oder Modellausschnitts. Domänenexperte Fachexperte EBIT Abkürzung für Earnings before Interests and Taxes. Die Ertragskennzahl EBIT wird berechnet aus dem Jahresüberschuss vor Zinsergebnis, Steuern und außerordentlichem Ergebnis. Sie macht eine von der individuellen Kapitalstruktur unabhängige Aussage zur operativen Ertragskraft eines Unternehmens. EBIT wird auch als betriebliches Ergebnis bezeichnet. effektiv effizient Die Effektivität bezeichnet die Wirksamkeit im Hinblick darauf, ob man das Richtige getan hat. Etwas ist ineffektiv, wenn das Ergebnis wenig wirksam ist. effizient effektiv Die Effizienz bezeichnet die Wirksamkeit im Hinblick darauf, wie man etwas macht. Etwas ist ineffizient, wenn man das richtige beispielsweise umständlich ausführt. Entwurfsmuster Entwurfsmuster sind generalisierte und bewährte Lösungsansätze zu immer wiederkehrenden Entwurfsproblemen. Sie sind keine fertig kodierten Lösungen, sie beschreiben lediglich den Lösungsweg bzw. die Lösungsidee. Enthält-Beziehung Teile von Anwendungsfällen, die in mehreren Anwendungsfällen in identischer Weise vorkommen, können in einen eigenen Anwendungsfall ausgelagert werden und per Enthält-Beziehung wieder eingebunden werden, um so eine redundante Beschreibung der identischen Teile zu vermeiden. Durch die Enthält-Beziehung werden anders als bei der Spezialisierungsbeziehung keine Eigenschaften weitervererbt. EPK Ereignisgesteuerte Prozesskette Ereignis Ein Geschehen, das in einem gegebenen Kontext eine Bedeutung hat und sich räumlich und zeitlich lokalisieren lässt.

Ergebnis, betriebswirtschaftliches EBIT Dieser Begriff wird meist synonym für eine Vielzahl von Ergebniskennzahlen verwendet. Je nach Erfolgsrechnung fällt das Ergebnis jedoch unterschiedlich aus und heißt auch anders. So wird das Ergebnis der Gewinnund Verlustrechnung der Handelsbilanz Jahresüberschuss bzw. -fehlbetrag oder Bilanzgewinn bzw. -verlust genannt, bei der Steuerbilanz spricht man vom steuerlichen Gewinn bzw. Verlust und bei einer EinnahmenAusgabenrechnung heißt das Ergebnis Einzahlungs- bzw. Auszahlungsüberschuss. Ergebnis eines Geschäftsprozesses Nutzen, der im Rahmen eines Geschäftsprozesses für einen Geschäftspartner entsteht, beispielsweise der Erhalt einer Leistung, Ware oder Wertes. Ergebnisgesteuerte Prozesskette (EPK) Semiformale grafische Beschreibungstechnik für Geschäftsprozessabläufe. Exemplar Ein Exemplar ist in der objektorientierten Softwareentwicklung eine konkret vorhandene und agierende Einheit mit eigener Identität und definierten Grenzen, die Zustand und Verhalten kapselt. Der Zustand wird repräsentiert durch die Attribute und Beziehungen, das Verhalten durch Operationen bzw. Methoden. Jedes Exemplar ist ein Objekt (Synonym: Instanz) einer Klasse. Das definierte Verhalten gilt für alle Exemplare einer Klasse gleichermaßen, ebenso die Struktur ihrer Attribute. Die Werte der Attribute sind jedoch individuell für jedes Exemplar. Jedes Exemplar hat eine eigene, von seinen Attributwerten unabhängige, nicht veränderbare Identität. Fachabteilung Eine Fachabteilung ist eine aus Sicht der Softwareentwicklung, der Betriebsorganisation oder eines Projektes andere Organisationseinheit. Eine Fachabteilung kann ein möglicher Auftraggeber für Software- oder Organisationsprojekte sein. Fachexperte Domänenexperte Ein Experte in einem bestimmten Fachgebiet (einer Domäne). Fachklasse Geschäftsklasse Fachlich motivierte Klasse, die einen Begriff aus dem Problembereich des zu entwickeln-

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

5.2 Glossar

den Systems repräsentiert. Sie ist Bestandteil der Analysemodelle zur Systementwicklung. Fachklasse und Geschäftsklasse werden oft synonym verwendet. Feature Ein Feature ist eine Sammlung von (häufig noch zu konkretisierenden) Anforderungen. GAF  Geschäftsanwendungsfall, KernGeschäftsanwendungsfall, Unterstützender Geschäftsanwendungsfall Generalisierung Eine Generalisierung (bzw. Spezialisierung) ist eine taxonomische Beziehung zwischen einem allgemeinen und einem speziellen Element (bzw. umgekehrt), wobei das speziellere weitere Eigenschaften hinzufügt, die Semantik erweitert und sich kompatibel zum allgemeinen verhält. Generalisierung und Spezialisierung sind Abstraktionsprinzipien zur hierarchischen Strukturierung der Modellsemantik unter einem diskriminierenden Aspekt. Die Generalisierung bzw. Spezialisierung wird vor allem auf Klassen, Anwendungsfälle und Aktivitätsaufrufe angewendet. Geschäftsanfall Wahrnehmbare körperliche Muskelkontraktion, die mit einer exorbitanten Zunahme an Gewaltbereitschaft gepaart ist. Geschäftsanwendungsfall KernGeschäftsanwendungsfall, Unterstützender Geschäftsanwendungsfall Ein Geschäftsanwendungsfall beschreibt einen geschäftlichen Ablauf, wird von einem geschäftlichen Ereignis ausgelöst und endet mit einem Ergebnis, das für den Unternehmenszweck und die Gewinnerzielungsabsicht direkt oder indirekt einen geschäftlichen Wert darstellt. Geschäftsklasse Fachklasse Fachlich motivierte Klasse, die einen Begriff aus dem Problembereich des Geschäftes repräsentiert. Sie ist Bestandteil der Geschäftsprozessmodellierung. Fachklasse und Geschäftsklasse werden oft synonym verwendet. Geschäftsmitarbeiter Innenorientierter Geschäftsmitarbeiter, Außenorientierter Geschäftsmitarbeiter Person die innerhalb des Modellierungsfokus arbeitet, also gewöhnlich die Mitarbei-

223

ter des betrachteten Unternehmens. Es werden innenorientierte und außenorientierte Geschäftsmitarbeiter unterschieden. Geschäftspartner Aktiver Geschäftspartner, Passiver Geschäftspartner Ein Geschäftspartner ist ein Akteur. Es werden aktive und passive Geschäftspartner unterschieden. Sie stehen außerhalb des Modellierungsfokus. Aktive Geschäftspartner stoßen Geschäftsvorfälle an, die zum Kerngeschäft des Unternehmens gehören und dem eigentlichen Geschäftszweck dienen, während die passiven Geschäftspartner solche Geschäftsvorfälle initiieren, die nicht direkt dem Geschäftszweck des Unternehmens zuzuordnen sind, jedoch unabdingbar sind, um das Kerngeschäft zu gewährleisten. Das heißt, die Geschäftsvorfälle des Kerngeschäfts würden ohne die unterstützenden Geschäftsvorfälle nicht funktionieren. Geschäftsprozess Ein Geschäftsprozess ist eine Zusammenfassung einer Menge fachlich verwandter Geschäftsanwendungsfälle. Dadurch bildet ein Geschäftsprozess gewöhnlich eine Zusammenfassung von organisatorisch evtl. verteilten, fachlich jedoch zusammenhängenden Aktivitäten, die notwendig sind, um einen Geschäftsvorfall (z.B. einen konkreten Antrag) ergebnisorientiert zu bearbeiten. Die Aktivitäten eines Geschäftsprozesses stehen gewöhnlich in zeitlichen und logischen Abhängigkeiten zueinander. Geschäftsprozesskette Geschäftsprozess Geschäftsprozessmodellierung Bei der Geschäftsprozessmodellierung werden Geschäftsprozesse analysiert und in abstrakter Form zur Veranschaulichung bildhaft oder textuell dargestellt. Geschäftsregel Anforderung, Zusicherung Eine Geschäftsregel ist die Beschreibung möglicher fachlicher Eigenschaften und Verhaltensweisen, die stets erfüllt sein sollen. Eine Geschäftsregel definiert Anforderungen an das modellierte Geschäft. Geschäftsvorfall Geschäftsvorgang Ein Geschäftsvorfall bezeichnet das von einem konkreten, aktiven Geschäftspartner initiierte Ereignis, z.B. „Gabi Goldfisch beantragt eine Mitgliedschaft“. Ein Auslöser kann mehrere Geschäftsvorfälle nach sich ziehen.

224

5.2 Glossar

Ereignisse, die innerhalb des Geschäftssystems entstehen, sind keine Geschäftsvorfälle. Geschäftsvorgang Geschäftsvorfall Ein Geschäftsvorgang wird durch einen Geschäftsvorfall (z.B. Antragseingang) ausgelöst und dann durch die definierten Aktivitäten eines Geschäftsanwendungsfalles bearbeitet. Während der Geschäftsanwendungsfall eine abstrakte Beschreibung darstellt, ist ein Geschäftsvorgang eine konkrete Ausprägung (Instanz) davon. Gewinnerzielungsabsicht Womit beabsichtigt das Unternehmen bzw. die im Modellierungsfokus stehende Organisation Geld zu verdienen? Für gemeinnützige Organisationen ist die Gewinnerzielungsabsicht durch etwas Entsprechendes zu ersetzen, beispielsweise „Beitrag zum festgelegten Gemeinnutz“ o.Ä. GP Geschäftsprozess GPM Geschäftsprozessmodellierung GPM-Betrachtungsgegenstand  Modellierungsfokus Gutfall Ein Gutfall beschreibt einen Ablauf, in dem alles gut bzw. optimal läuft. Dies ist meistens, aber nicht immer der Normal- bzw. Standardfall in einem Ablauf. Beispiel: Beim Buchen einer Pauschalreise im Reisebüro ist es normal, eine Menge von in Frage kommenden Hotels zu diskutieren. Im Gutfall wird sofort das eine richtige Hotel gefunden. Statt Gutfall kann man auch Sonnenscheinfall sagen. Heuristik Eine Heuristik ist eine wahrscheinlichkeitsbehaftete Regel, also eine sog. DaumenRegeln, die nicht immer, aber in vielen oder den meisten Fällen zutrifft. identifizieren Identifizieren bedeutet im Rahmen der Geschäftsprozessmodellierung, dass etwas eindeutig und unverwechselbar benennbar und von allen anderen gleichartigen Dingen unterschieden werden kann. Innenfinanzierungspotenzial Cash Flow

Innenorientierter Geschäftsmitarbeiter Geschäftsmitarbeiter, Außenorientierter Geschäftsmitarbeiter Innenorientierte Geschäftsmitarbeiter nennen wir solche, die sich innerhalb des zu modellierenden Unternehmens befinden und die keinen direkten Kontakt zu Geschäftspartnern haben, die also beispielsweise für Kunden und Lieferanten nicht direkt sichtbar sind. Innenorientierte Geschäftsmitarbeiter arbeiten für andere (innen- und außenorientierte) Geschäftsmitarbeiter. Instanz Exemplar ISO Die International Organization for Standardization (ISO) ist eine 1947 gegründete Vereinigung der einzelnen nationalen Standardisierungsinstanzen aus über 140 Ländern. Kern-Geschäftsanwendungsfall Geschäftsanwendungsfall, Unterstützender Geschäftsanwendungsfall Ein Kern-Geschäftsanwendungsfall beschreibt einen geschäftlichen Ablauf, der von einem aktiven Geschäftspartner ausgelöst wird, ein Ergebnis von geschäftlichem Wert für mindestens einen aktiven Geschäftspartner erzeugt und direkt mit dem Unternehmenszweck und einer Gewinnerzielungsabsicht (bei gemeinnützigen Organisationen mit dem beabsichtigten Gemeinnutz) zusammenhängt. Eine zeitliche Kohärenz des Ablaufes wie bei einem Systemanwendungsfall ist nicht gefordert. In Kontrast zu den KernGeschäftsanwendungsfällen sind die unterstützenden Geschäftsanwendungsfälle zu sehen. In einem Handelsunternehmen ist der Verkauf von Waren gewöhnlich ein KernGeschäftsanwendungsfall, während beispielsweise die Finanzbuchhaltung oder der Wareneinkauf unterstützende Geschäftsanwendungsfälle darstellen. Klassenmodell Ein Modell, das ausschließlich oder vorwiegend Klassen (auch Schnittstellen und Typen) enthält und die Beziehungen dieser Elemente untereinander beschreibt. Meistens wird es durch ein oder mehrere Klassendiagramme dargestellt. Kohärenz Zusammenhang, Zusammengehörigkeit.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

5.2 Glossar

225

Konsolidierung (auch Konsolidation) Festigung, Sicherung. Sichert bzw. festigt etwas Bestehendes. Schließt häufig auch eine abschließende Überarbeitung und Bereinigung von offenen Punkten ein.

dellierenden Unternehmen gesprochen. Zum Modellierungsfokus gehören alle direkt betrachteten Teile einer Organisation und deren unmittelbar angrenzende (außerhalb stehende) Akteure.

Leitbild eines Unternehmens Leitziel Mit dem Leitbild werden die Werte und Haltungen ausgedrückt, die das Unternehmen von anderen unterscheiden.

Nachbedingung Vorbedingung Eine Nachbedingung beschreibt einen Zustand, der nach Abschluss einer Tätigkeit, Aktivität, Operation o.Ä. gegeben sein muss.

Leitziel eines Unternehmens Leitbild Das Leitziel des Unternehmens beschreibt mit einem Satz die Vision des Unternehmens. Es ist das an erster Stelle stehende und markanteste Ziel, das das Unternehmen hat. Gewöhnlich ist es mit einer Kennzahl, d.h. einer messbaren Größe, verknüpft.

Nebenläufigkeit Zwei oder mehr Aktivitäten können zeitgleich (parallel) ausgeführt werden.

Methodik, Methode Eine Methode ist eine Handlungsvorschrift, die beschreibt, wie ein Ziel bzw. Ergebnis unter gegebenen Bedingungen erreicht werden kann. Methode und Methodik sind synonym zu verwenden. Methodik klingt bedeutsamer. Mission Leitbild Modell Diagramm Ein Modell ist ein Abbild einer konkreten Sache in vereinfachter Form, mit dem Ziel, etwas zu veranschaulichen und zu einem besseren Verständnis beizutragen. Innerhalb eines Modellierungswerkzeuges (z.B. für UML) wird als Modell die Summe aller gespeicherten Informationen angesehen. Einzelne Diagramme repräsentieren grafisch einen bestimmten Ausschnitt dieses Modells. Nicht jede Modellinformation muss dabei in einem Diagramm wiedergegeben werden. Eine Modellinformation kann jedoch in verschiedenen Diagrammen enthalten sein. Modellierungsbereich Modellierungsfokus Modellierungsfokus Mit dem Modellierungsfokus wird abgegrenzt, welche Teile einer Organisation oder einer Gemeinschaft von Organisationen in der Geschäftsprozessmodellierung betrachtet werden sollen und welche nicht. Daher wird dieser Bereich auch Betrachtungsgegenstand genannt. Da in vielen Fällen der Modellierungsbereich auf ein einzelnes Unternehmen beschränkt ist, wird vereinfachend auch vom betrachteten Unternehmen oder vom zu mo-

Nutzungsfall Anwendungsfall Object Engineering Process (OEP) Der OEP ist ein Vorgehensmodell und Leitfaden zur agilen objektorientierten Softwareentwicklung, basierend auf UML und Unified Process. Siehe http://www.oose.de/oep. Object Management Group (OMG) Die Object Management Group ist ein Industriekonsortium u.a. zur Entwicklung, Vereinheitlichung und Standardisierung von Informationstechnologien. Siehe http://www. omg.org. Objekt Exemplar OEP Object Engineering Process OMG Object Management Group OOSE Abkürzung steht für objektorientierte Softwareentwicklung oder Object Oriented Software Engineering. Operativ, Operatives Ziel Zur Erreichung operativer Ziele werden vorhandene Potenziale und Möglichkeiten ausgenutzt, um operative Kennzahlen wie Umsatz, Gewinn u.Ä. zu steigern. Operative Maßnahmen finanzieren sich aus vorhandenen Ressourcen und werden durchgeführt unter der Annahme, dass sich die EinnahmeKosten-Relation verbessert. Organigramm Organisationsplan Organisation Organisationseinheit Eine Organisation besteht aus Organisationseinheiten und strukturiert diese zielorientiert. Sie kann aufgabenbezogen als Ablauf- oder strukturbezogen als Aufbauorganisation in Form eines bildhaften Organisationsplanes dargestellt werden.

226

5.2 Glossar

Organisationseinheit Organisation Eine Organisationseinheit ist Teil einer Organisation oder einer anderen Organisationseinheit und erfüllt einen bestimmten Zweck. Sie definiert sich durch einen abgegrenzten Aufgabenbereich, der dem Zweck der Organisation dient. In der Regel wird ein Mitarbeiter einer Organisationseinheit zugeordnet. Organisationsplan Organisation, Organigramm Ein Organisationsplan ist die grafische Darstellung struktureller Beziehungen zwischen Organisationseinheiten eines betrachteten Unternehmens. Passiver Geschäftspartner Geschäftspartner, Aktiver Geschäftspartner Als passive Geschäftspartner werden (natürliche oder juristische) Personen bezeichnet, die außerhalb des betrachteten Unternehmens (Modellierungsfokus) stehen und von diesem angesprochen werden. Passive Geschäftspartner reagieren auf ein geschäftliches Anliegen des betrachteten Unternehmens. Passive Geschäftspartner sind beispielsweise Lieferanten. Prozesskette Geschäftsprozesskette Realisierungsbeziehung Eine Realisierung ist eine Beziehung zwischen einem Element, das eine Anforderung beschreibt, und einem Element, das diese Anforderungen umsetzt. Redundanz Lat. überreichlich, überflüssig. Bezeichnet gewöhnlich Dinge, die ohne Verlust entfallen können. Als redundanzfrei wird etwas bezeichnet, wenn jeder Sachverhalt (z.B. eine Anwendungsfallbeschreibung) nur genau einmal (im gesamten Anwendungsfallmodell) vorhanden ist. rekursiv Selbstbezüglich, zurückgehend bis zu einem bekannten Punkt. Risiko Chance Ein Risiko ist ein möglicher Verlust. Ein Risiko kann ausgedrückt werden durch die Wahrscheinlichkeit seines Auftretens und einer Schadenhöhe im Eintrittfall. Ein Risiko ist eine negative Chance.

ROCE ROI Gesamtkapitalrentabilität (Return on Capital Employed) ROI ROCE Abkürzung für Return on Investment. Der Return on Investment ist das, was aus dem Investment "zurückkehren" soll. Er drückt somit das Gewinnziel aus. Der Gewinn wird auf das investierte, betriebsnotwendige Vermögen bezogen. Rolle Akteur Wird hier als Allgemeinbegriff verwendet. Eine Rolle drückt eine Aufgabe oder Funktion aus, die von jemandem oder etwas übernommen wird. SAFSystemanwendungsfall SCMSupply Chain Management Spezialisierung Generalisierung Eine Generalisierung (bzw. Spezialisierung) ist eine taxonomische Beziehung zwischen einem allgemeinen und einem speziellen Element (bzw. umgekehrt), wobei das speziellere weitere Eigenschaften hinzufügt, die Semantik erweitert und sich kompatibel zum allgemeinen verhält. Generalisierung und Spezialisierung sind Abstraktionsprinzipien zur hierarchischen Strukturierung der Modellsemantik unter einem diskriminierenden Aspekt. Stakeholder Person, die in irgendeiner Form ‚teil hat’ bzw. betroffen ist (engl. für Teilhaber). Mögliche deutsche Bezeichnungen: Interessenshalter, Anforderungsbeitragender oder Projektbetroffener. Mit Stakeholder werden also die verschiedenen an einem Unternehmen, einer Organisation oder einem Projekt interessierten Gruppen wie Mitarbeiter, Lieferanten, Kapitalgeber, Gesellschaft, Gesetzgeber bezeichnet. Stereotyp Das Konzept der Stereotypen ist ein Erweiterungsmechanismus in der UML, mit dem neue eigene Modellierungselemente auf Basis bestehender definiert werden können. Dieser Definitionsvorgang wird auch stereotypisieren genannt. Strategiekarte Balanced Scorecard

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

5.2 Glossar

Strategisch, Strategisches Ziel Eine Strategie ist ein Vorgehensplan zur Erreichung eines Ziels, bei dem von vornherein versucht wird, diejenigen Faktoren einzukalkulieren, die in die geplanten Handlungen hineinspielen könnten. Ein strategisches Ziel besteht gewöhnlich im Erreichen einer zukünftig besseren Ausgangsposition. Es dient normalerweise nicht zur unmittelbaren Verbesserung bestimmter Kennzahlen, sondern mit ihm sollen die Möglichkeiten, Potenziale und allgemeinen Rahmenbedingungen verbessert werden. Aufgrund dieser verbesserten Möglichkeiten können dann später wiederum (noch besser) operative Ziele verfolgt werden. Strategische Ziele sind daher meistens mittel- oder langfristig ausgerichtet. Supply Chain Management Supply Chain bezeichnet ein Netzwerk verschiedener Unternehmen, die zusammenarbeiten, um ein Produkt herzustellen und es zum Endkunden zu bringen. Als deutsche Begriffe sind Lieferkette und Logistikkette üblich. Ziele sind dabei häufig die Schaffung von Transparenz, der Abbau von Informationshindernissen, eine ganzheitliche Geschäftsprozessperspektive und die Etablierung kontinuierlicher Material-, Informations- und Geldmittelflüsse. Synergie Synergie ist der Effekt, dass bei optimaler Kombination von Einzelelementen die sich daraus ergebende Gesamtheit mehr ist als die Summe der Einzelteile. Insbesondere in der strategischen Planung ist die Diskussion von Synergien durch die optimale Kombination von Geschäftsfeldern von Bedeutung. Systemanwendungsfall Ein Systemanwendungsfall ist ein Anwendungsfall, der speziell das für die außen stehenden Akteure (Benutzer) wahrnehmbare Verhalten eines Systems beschreibt. Systemakteur Ein Systemakteur ist eine Person oder ein externes System, das mit einem technischen System (Hard- oder Software) interagiert. Dies können also die Benutzer oder andere externe Systeme, z.B. SAP, sein. Außerdem können auch Ereignisse, wie Zeitereignisse (z.B. Monatswechsel), als Systemakteure aufgefasst werden.

227

Szenario Das Szenario beschreibt einen möglichen konkreten Ablauf von etwas. In der Praxis werden Szenarien durchgespielt, um aus der hypothetischen Aufeinanderfolge von Ereignissen Erkenntnisse über kausale Zusammenhänge zu gewinnen. Ein Szenario ist eine konkrete mögliche Ausprägung eines Anwendungsfalles. Transaktion Eine Transaktion ist ein Vorgang, der entweder vollständig oder gar nicht vollzogen werden kann. Wenn der Vorgang mittendrin aufhört oder abgebrochen wird, ist dies im Ergebnis so, als hätte der Vorgang nie stattgefunden, der Zustand ist derselbe wie vorher. Eventuelle Zwischenergebnisse gehen im Falle eines vorzeitigen Abbruches verloren. Unter Umständen sind hierfür auch inverse Operationen notwendig, um den ursprünglichen Zustand wieder herzustellen. Transition Eine Transition ist innerhalb eines Zustandsdiagrammes ein Zustandsübergang, häufig ausgelöst durch ein Ereignis. Der Begriff Transition wird auch als Übergang von einer Aktivität zur nächsten innerhalb von Aktivitätsdiagrammen verwendet. UML UML ist die Abkürzung für Unified Modeling Language. Die UML ist eine von der Object Management Group (OMG) standardisierte Notation und Semantik zur Visualisierung, Konstruktion und Dokumentation von Modellen für die objektorientierte Softwareentwicklung. Unified Modeling Language UML Unified Process Der Unified Process ist ein Vorgehensmodell zur objektorientierten Softwareentwicklung auf Basis der UML und wird in dem Buch The Unified Software Development Process beschrieben [Jacobson99]. Unternehmensidentität Corporate Identity Unterstützender Geschäftsanwendungsfall Geschäftsanwendungsfall, KernGeschäftsanwendungsfall Ein unterstützender Geschäftsanwendungsfall beschreibt einen geschäftlichen Ablauf, der für den Unternehmenszweck und die

228

5.2

Gewinnerzielungsabsicht keinen oder nur indirekt einen Wert darstellt. Im Kontrast hierzu sind die Kern-Geschäftsanwendungsfälle zu sehen. In einem Handelsunternehmen ist die Finanzbuchhaltung oder der Wareneinkauf gewöhnlich ein unterstützender Geschäftsanwendungsfall, während beispielsweise der Verkauf von Waren hier ein KernGeschäftsanwendungsfall wäre. Use Case Anwendungsfall Vererbung Generalisierung, Spezialisierung Vererbung ist ein Programmiersprachenkonzept für die Umsetzung einer Relation zwischen einer Ober- und einer Unterklasse, wodurch Unterklassen die Eigenschaften ihrer Oberklassen mitbenutzen können. Vererbung implementiert normalerweise Generalisierungs- und Spezialisierungsbeziehungen. Alternativen sind Delegation, Aggregation, generisches Design, generische Programmierung. Vorbedingung Nachbedingung Eine Vorbedingung beschreibt einen Zustand, der vor dem Ablauf einer Tätigkeit, Aktivität, Operation o.Ä. gegeben sein muss. Wiki Ein Wiki ist eine von Ward Cunningham initiierte Open-Source-Technologie zum kooperativen Erstellen von Internet- und Intranetseiten, d.h., jeder Benutzer darf jederzeit alles lesen, ändern und neue Seiten hinzufügen. Die Benutzung ist extrem einfach. Wiki-Wiki kommt aus dem Hawaianischen und heißt schnell. Auch die Taxis heißen dort so. Einfach ausprobieren unter http://c2.com/cgi/ wiki?WikiWiki oder das Wiki zu diesem Glossar unter http://www.oose.de/oep-wiki. Workflow Ein Workflow ist die computergestützte Automatisierung und Unterstützung eines Geschäftsprozesses oder eines Teils davon.

Zusicherung Eine Zusicherung ist ein Ausdruck, der die möglichen Inhalte, Zustände oder die Semantik eines Modellelementes einschränkt und der stets erfüllt sein muss. Bei dem Ausdruck kann es sich um einen Stereotyp oder Eigenschaftswert handeln, um eine freie Formulierung oder einen OCL-Ausdruck. Zusicherungen in Form reiner boolescher Ausdrücke werden auch Assertions genannt. Zustand Ein Zustand ist eine benannte Abstraktion (Zusammenfassung) der möglichen Attributwerte eines Objektes. Ein Zustand gehört zu genau einer Klasse, einer Komponente oder einem Anwendungsfall und stellt eine Abstraktion bzw. Zusammenfassung einer Menge von möglichen Attributwerten dar, welche die Objekte dieser Klasse einnehmen können. In der UML ist ein Zustand eine Situation im Leben eines Objektes, während der eine bestimmte Bedingung erfüllt ist, Aktivitäten ausgeführt werden oder auf ein Ereignis gewartet wird. Zustandsdiagramm, Zustandsmodell Ein Zustandsmodell wird dargestellt durch Zustandsdiagramme. Ein Zustandsmodell zeigt eine Folge von Zuständen, die ein Objekt im Laufe seines Lebens einnehmen kann, und gibt an, aufgrund welcher Stimuli Zustandsänderungen stattfinden. Ein Zustandsmodell beschreibt eine hypothetische Maschine (endlicher Automat), die sich zu jedem Zeitpunkt in einer Menge endlicher Zustände befindet. Sie besteht aus einer endlichen, nicht leeren Menge von Zuständen, einer endlichen, nicht leeren Menge von Eingabesymbolen (Ereignissen), Funktionen, die den Übergang von einem Zustand in den nächsten beschreiben, einem Anfangszustand und einer Menge von Endzuständen.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

5.3 Literatur

5.3

Literatur

Eine aktuelle und ggf. ausführlichere Bibliographie finden Sie unter http://www.oose.de/bibliographie. Die fett hervorgehobenen Titel empfehlen wir zur Vertiefung oder Ergänzung.

[Alexander77] C. Alexander et al.: A Pattern Language. Oxford University Press, New York, 1977. [Amberg99] M. Amberg: Prozessorientierte betriebliche Informationssysteme. Springer-Verlag, Berlin, 1999. [Booch99] G. Booch, J. Rumbaugh, I. Jacobson: Unified Modeling Language User Guide. Addison Wesley Longman, 1999. [Bürger78] Bürger, Gottfried August: Wunderbare Reisen zu Wasser und Lande, Feldzüge und Lustige Abenteuer des Freiherrn von Münchhausen. Manesse Verlag, Zürich, 1978. [Davenport90] T. H. Davenport, J. E. Short: The New Industrial Engineering: Information Technology and Business Process Redesign. In: Sloan Management Review, Boston, Summer, 1990. [Davenport93] T. H. Davenport: Process Innovation: Reengineering Work through Information Technology. Harvard Business School Press, Boston, 1993. [Ferstl91] O. K. Ferstl, E. J. Sinz: Objektmodellierung betrieblicher Informationssysteme im Semantischen Objektmodell (SOM). In: Wirtschaftsinformatik, 32 (1990) 6, S. 566ff. [Friedag02] H. R. Friedag, W. Schmidt: Balanced Scorecard. Haufe Verlag, Planegg, 2002. [Hammer90] M. Hammer: Reengineering Work: Don't Automate, Obliterate. Harvard Business Review July-August 1990, S. 104 – 112.

229

230

5.3 Literatur

[Hammer93] M. Hammer, J. Champy: Reengineering the Corporation: A Manifesto for Business Revolution. HarperBusiness, New York, 1993. [Harrington91] H. J. Harrington: Business Process Improvement: The Breakthrough Strategy for Total Quality, Productivity, and Competitiveness. McGraw-Hill, New York, 1991. [Hitz03] M. Hitz, G. Kappel: UML @ work: Von der Analyse zur Realisierung, 2. Auflage, dpunkt.verlag, Heidelberg, 2003. [Irion95] A. M. Irion: Regelwerk und Qualitätscheckliste zur Bildung von Fachbegriffen bei der Entwicklung und Administration einer normierten Unternehmensfachsprache. Diplomarbeit, Universität Konstanz, 1995. [Jacobson92] I. Jacobson, M. Christerson, P. Jonsson, G. Overgaard: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1992. [Jacobson94] I. Jacobson, M. Ericson, A. Jacobson: Object Advantage, The: Business Process Reengineering with Object Technology. Addison-Wesley, 1994. [Jacobson99] I. Jacobson, G. Booch, J. Rumbaugh: The Unified Software Development Process. Addison Wesley Longman, 1999. [Jeckle.de] M. Jeckle: UML-Informationen und Neuigkeiten, http://www.jeckle.de/ unified.htm [Kaplan01] R. Kaplan, D. Norton: Die strategiefokussierte Organisation. Führen mit der Balanced Scorecard. Schäffer-Poeschel Verlag, Stuttgart, 2001. [Langer97] P. Langer, C. Schneider, J. Wehler: Prozeßmodellierung mit ereignisgesteuerten Prozeßketten (EPKs) und Petri-Netzen. In: Wirtschaftsinformatik, Heft 39, S. 479-489, 1997. [Nüttgens97] M. Nüttgens, T. Feld, V. Zimmermann: Business Process Modeling mit EPC and UML: Transformation or Integration? In: M. Schader, A. Korthaus (Hrsg.): The Unified Modeling Language: technical Aspects and Applications, Proceedings (Mannheim, October 1997), Heidelberg 1998, S. 250ff.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

5.3 Literatur

[OEP2] oose.de GmbH: Object Engineering Process, http://www.oose. de/oep [Oestereich01a] B. Oestereich: Objektorientierte Softwareentwicklung: Analyse und Design mit der UML. 5. Auflage, Oldenbourg Wissenschaftsverlag, München, 2001. [Oestereich01b] B. Oestereich et al.: Erfolgreich mit Objektorientierung.- Vorgehensmodelle und Managementpraktiken für die objektorientierte Softwareentwicklung. 2. Aufl., Oldenbourg Wissenschaftsverlag, München, 2001. [Oestereich98] B. Oestereich: Objektorientierte Geschäftsprozeßmodellierung mit der UML. In: Objekt-Spektrum, 2/1998, S. 48. [Oetinger01] B. v. Oetinger, T. v. Ghyczy, C. Bassford: Clausewitz, Strategie denken, Hanser. München, 2001. [OOGPM] Verschiedene Informationen zur objektorientierten Geschäftsprozessmodellierung, http://www.oogpm.de. [Österle95] H. Österle: Business Engineering, Prozess- und Systementwicklung, Band 1, Entwurfstechniken, Springer-Verlag, Berlin 1995. [Robertson99] S. Robertson, J. Robertson: Mastering the Requirements Process. Addison-Wesley, Reading, 1999. [Rumbaugh99] J. Rumbaugh, I. Jacobson, G. Booch: Unified Modeling Language Reference Manual. Addison Wesley Longman, Reading, 1999. [Rupp02] C. Rupp: Requirements-Engineering und -Management. 2. Aufl., Hanser, München, 2002. [Scheer01] A.-W. Scheer: ARIS – Modellierungsmethoden, Metamodelle, Anwendungen. 4. Aufl., Springer-Verlag, Berlin, 2001. [Scheer94] A.-W. Scheer: Business Process Engineering: Reference Models for Industrial Enterprise-Modeling. Springer-Verlag, Berlin, 1994. [Scheer97] A.-W. Scheer, M. Nüttgens, V. Zimmermann: Objektorientierte Ereig-

231

232

5.3 Literatur

nisgesteuerte Prozeßkette (oEPK) – Methode und Anwendung. Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 141, Saarbrücken 1997, URL: http://www.iwi.uni-sb.de/public/iwi-hefte. [Scheer99] A.-W. Scheer: ARIS – Vom Geschäftsprozeß zum Anwendungssystem. Springer-Verlag, Heidelberg, 1999. [Seidlmeier02] H. Seidlmeier: Prozessmodellierung mit ARIS. Eine beispielorientierte Einführung für Studium und Praxis. Vieweg Verlag, 2002. [SOM] SOM-Projekt am Lehrstuhl für Wirtschaftsinformatik in Bamberg: www.seda.sowi.uni-bamberg.de/forschung/som/som. [Sommerville97] I. Sommerville, P. Sawyer: Requirements Engineering. A good practice guide. Wiley, 1997. [UML2a] Object Management Group, Unified Modeling Language: Superstructure, Version 2 beta R1, Revised submission, ad/2002-09-02. [UML2b] Object Management Group, Unified Modeling Language: Infrastructure, Version 2.0, Updated submission, ad/2002-09-01. [UML-oose] Verschiedene Informationen zur UML: www.oose.de/uml. [Weilkiens03] T. Weilkiens, B. Oestereich: UML 2.0: Jetzt wird alles gut? ObjektSpektrum 01/2003. [WFMC] Workflow Management Coalition: www.wfmc.org. [Zimmermann99] V. Zimmermann: Objektorientiertes Geschäftsprozessmanagement, Gabler, Wiesbaden, 1999.

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

5.4 Index

5.4

Index

[Alexander77] 229 [Amberg99] 229 [Booch99] 13, 229 [Bürger78] 19, 229 [Davenport90] 11, 229 [Davenport93] 11, 229 [Ferstl91] 14, 15, 229 [Friedag02] 50, 229 [Hammer90] 11, 229 [Hammer93] 11, 230 [Harrington91] 11, 230 [Hitz03] 13, 230 [Jacobson92] 11, 230 [Jacobson94] 11, 230 [Jacobson99] 31, 227, 230 [Jeckle.de] 230 [Kaplan01] 42, 230 [Langer97] 230 [Nüttgens97] 15, 230 [OEP2] 31, 231 [Oestereich01a] 12, 13, 31, 126, 132, 140, 190, 192, 193, 231 [Oestereich01b] 34, 231 [Oestereich98] 231 [Oetinger01] 42, 231 [OOGPM] 231 [Österle95] 15, 231 [Robertson99] 16, 132, 231 [Rumbaugh99] 231 [Rupp02] 16, 132, 231 [Scheer01] 15, 231 [Scheer94] 11, 15, 231 [Scheer97] 15, 231 [Scheer99] 15, 232 [Seidlmeier02] 15, 232 [SOM] 14, 15, 232 [Sommerville97] 16, 232 [UML2a] 232 [UML2b] 232 [UML-oose] 232 [Weilkiens03] 232 [WFMC] 232 [Zimmermann99] 232 Abhängigkeit Geschäftsprozess- 121 Paket- 121 zyklische 121 Abhängigkeiten 21 Abhängigkeitsbeziehung 118, 202 Abhängigkeitsgraph 114 Abhängigkeitsmanagement 115, 117 Abhängigkeitsmodell 114 Abkürzungsverzeichnis 142

Ablauf essenzieller 94 Ablaufdiagramm 96, 175 Ablaufende 177 Ablaufmodell 220 Ablauforganisation 220 Ablaufschritt 177 Abstrakte Klasse 200, 201, 220 Abstrakte Operation 201 Abstrakte Organisationseinheit 45 Abstraktion 220 Abteilung 207 activity 177 activity description 179 Activity diagram 175 actor 148 Adam Smith 9 Ad-hoc-Erfindung 4, 7 Administrierbarkeit 171 Aggregation 194, 195, 196, 220 Agilität 7 Akteur 148, 220 Aktiver Geschäftspartner 51, 72, 150, 220 Aktivität 177, 220 Aktivitätsaufruf 177 Aktivitätsbaum 181 Aktivitätsbeschreibung 111, 180 Aktivitätsdiagramm 96, 175, 220 Aktivitätsmodell 96, 220 Aktivitätsübergang 112, 220 Alfred Sloan 10 Altlast 6 Analyse 220 Anfangsknoten 177 Anfangszustand 177 Anforderung 170, 221 funktionale 170 nichtfunktionale 170 Anforderungsbeitragender 188 Anwender 148 Anwendungsfall 160, 172, 221 sekundärer 169 Anwendungsfalldiagramm 118, 155 Arbeitsteilung 10 Architektur integrierter Informationssysteme 14, 221 ARIS 14, 221 Assoziation 159, 194, 221 gerichtete 159, 194, 195 Attribut 192 Aufbauorganisation 221 Aufgabenkette 15

233

234

5.4 Index

Aufwand eines Geschäftsprozesses 94 Auslastung 47 Auslöser 87, 93 Ausnahme 21, 96 Außenorientierter Geschäftsmitarbeiter 51, 72, 153, 221 Automatisierung 5, 103, 133 Balanced Scorecard 221 Bedingung 215 Begriffsmodell 188 Benutzbarkeit 171 Benutzer 148, 154, 227 Berichtsweg 209 Beschreibung einer Aktivität 111 Beteiligter 148 Betrachtungsgegenstand 221, Siehe Modellierungsfokus Bootstrap 19 Botschaft 193 Boundary 189 Buchhaltung 122 Business Process 163 business use case 165, 166 Carlson Chester F. 10 Cash Flow 221 Champy, James 10 Chance 221 eines Geschäftsprozesses 94 Chaotische Prozesse 5 Chester F. Carlson 10 CI 221 class 189 Control 189 core business use case 166 Corporate Identity 40, 221 Das machen wir immer so-Syndrom 6 Datenelement 192 Datenmodell Unterschied zu Klassenmodell 125 Deckungsbeitrag 47 Delegation 203 design by contract 203 Designklasse 190 Diagramm 222 Dialogspezifikation 172 Dienstleistung 193 Disjunktion 182 Diskriminator 199 Disziplinarische Weisungsbefugnis 44 Domänenexperte 222 Durchlaufzeit optimieren 103 EBIT 47, 222 effektiv 222 effizient 222 Eigenschaftswert 189 Einbettung, organisatorische 114

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

Endknoten 177 Endlicher Automat 211 Endzustand 177, 213 Enthält-Beziehung 118, 159, 160, 169, 170, 222 Entitätsklasse 189 Entity 189 Entity Relationship Modeling 12, 125 Entwurfsmuster 222 EPK 14, 222 Ereignis 148, 213, 214, 222 Ereignisgesteuerte Prozesskette 14 Erfolgsrechnungsergebnistypen 222 Ergebnis 47, 87, 93 betriebswirtschaftliches 222 eines Geschäftsprozesses 222 Ergebnisgesteuerte Prozesskette 222 Ergebniskennzahlen 222 Ergebnisobjekt 112 ERM 12, 125 Essenz, geschäftliche 89 Essenzielle Beschreibung 89 Essenzieller Ablauf 89, 94 event 185 Event 214 Exemplar 190, 222, Siehe Objekt Externes System 148 Fachabteilung 207, 222 Fachbereich 207 Fachexperte 188, 222 Fachklasse 190, 222 Fachliche Weisungsbefugnis 44 Feature 170, 171, 174, 223 Fließbandarbeit 10 Flow chart 175 Fokus der Geschäftsprozessmodellierung 37 Ford, Henry 10 Formulierungsmuster 56 Fotokopie 10 Frederick W. Taylor 9 Funktion 193 funktionale Anforderung 170 Fusion 6, 28 GAF 223 Gemeinnützige Organisation 56, 224 Generalisierung 156, 186, 198, 209, 223 Gerichtete Assoziation 159, 194, 195 Geschäftsanfall 223 Geschäftsanwendungsfall 56, 165, 223 gruppieren 77 Kern- 61, 62 sekundärer 121 unterstützender 61, 62, 66, 167 Geschäftsklasse 190, 223 Geschäftsklassenmodell 123, 188 Geschäftsmitarbeiter 223 außenorientierter 51, 72, 153, 221 innenorientierter 51, 72, 152, 224

5.4 Index

Geschäftsobjekt 57, 123, 184 Geschäftspartner 72, 88, 223 aktiver 51, 72, 150 passiver 51, 72, 151, 226 geschäftspartnerorientiert 57 Geschäftsprozess 77, 84, 163, 223 Aufwand 94 Beschreibung 84 Beteiligter 85 Chance 94 Kennzahl 94 Kern- 79 Risiko 94 unterstützender 79 Verantwortlicher 84 Ziel 94 Geschäftsprozesskette 223 Geschäftsprozessmodellierung 223 Geschäftsregel 223 Geschäftsvorfall 163, 223 Geschäftsvorgang 224 Gewichtsangabe 117 Gewinnerzielungsabsicht 56, 61, 66, 165, 167, 224, 228 Glossar 106 GP 224 GPM 224 GPM-Betrachtungsgegenstand 224 Granularität 172 Gutfall 16, 94, 96, 224 Heimatpaket 204 Henry Ford 10 Heuristik 224 Idealfall 16 identifizieren 224 Identität 192 Include-Beziehung 118, 159, 160, 170 Indikator Siehe Kennzahl Inheritance 156, 186, 198 Innenfinanzierungspotenzial Siehe Cash Flow Innenorientierter Geschäftsmitarbeiter 51, 72, 152, 224 Inside-Out 73 Insourcing 6 Instanz 190, 224, Siehe Objekt Instanzvariable 192 Interface 201 International Organization for Standardization 224 ISO vi, 224 James Champy 10 Just-in-Time-Produktion 10 Kardinalität 196 Kennzahl 46, 49 zu einem Geschäftsprozess 94 zur Zielerreichungsmessung 47 Kern-Geschäftsanwendungsfall 61, 62, 166, 224

Kern-Prozess 79 Klasse 148, 189 abstrakte 200, 201 Schnittstellen- 201 Unterschied zu Objekt 125 Klassendiagramm 124, 206, 209 Klassenmodell 188, 224 Unterschied zu Datenmodell 125 Kohärenz 224 zeitliche 88, 137 Komposition 194 Konjunktion 182 Konkretisierung 186, 198 Konsolidierung 225 sprachliche 106 Kontextdiagramm 73 Kontinuierlicher Verbesserungsprozess 10 Kontrollfluss 182 Kosten 47 Kurzbeschreibung Geschäftsprozess 84 Leitbild 40, 225 Leitbild des Unternehmens 39 Leitziel 40, 225 Leitziel des Unternehmens 39 Link 194 Lolli 201 Lückenschluss 5 Machtinteressen 28 Massenfertigung 10 Maßnahme 50 zu einem Geschäftsprozess 94 zur Zielerreichung 47 Materialbeschaffung 122 Matrixorganisation 210 Maus 10 Member 192 Message 193 Methode 193, 225 Methodik 7, 225 Metrik 117 Mission 225 Mission des Unternehmens 39 Modell 225 Modellierungsbereich 37, 225 Modellierungsfokus 69, 72, 225 Multiplizität 196 Münchhausen 19 Nachbedingung 94, 225 Nachricht 193 Namensraum 204 Nebenläufigkeit 225 nichtfunktionale Anforderung 170 Nutzen eines Geschäftsprozesses 94 Nutzungsfall 160, 225 Nutzungsfalldiagramm 155 Oberelement 157

235

236

5.4 Index

Object Constraint Language 173 Object Engineering Process 31, 225 Objekt 184, 189, 225 Identität 192 Unterschied zu Klasse 125 Objektflussdiagramm 175 Objektknoten 111, 184 Objektmodell 188 Objektorientierung 10, 12 Objektverbindung 194 Objektzustand 175, 184 OCL 173 ODER-Verknüpfung 182 OEP 31, 140, 225 Muster Aktivitätsbeschreibung 111 Offene-Punkte-Liste 98 Offener Punkt 95 OMG vi, 147, 225 OOSE 225 Operation 193, 201 abstrakte 201 propagieren 196 Operativ 225 Operatives Ziel 46, 48, 225 Optimierung 5 Durchlaufzeit 103 Organigramm 206, 225 Organisation 225 gemeinnützige 56, 224 Matrix- 210 Organisationsbeziehung 209 Organisationseinheit 207, 226 Reorganisation 116 Verantwortung einer 114 Organisationsmodell 206 Organisationsplan 206, 209, 226 Organisationsstruktur 206 Organisatorische Einbettung 114 Outside-In 73 Outsourcing 3, 5, 28 package 204 Paket 118, 189, 204 Paketstruktur 64 Paketzuordnung von sekundären Geschäftsanwendungsfällen 122 Palo Alto Research Center 10 Passiver Geschäftspartner 51, 72, 151, 226 Performance 171 Placebo 197 Prädikatenlogik 173 Priorisierung 90 vereinfachte 49, 91, 95 zielgetriebene 49, 91, 95 Priorität 94 einer Anforderung 174 Problem 170, 171 Produktivitätssteigerung 5

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

Profil UML- 147 Programmablaufplan 175 programming by contract 203 PROMET 15 Propagierung 196 Prozedur 193 prozedurale Softwareentwicklung 13 Prozess Siehe Geschäftsprozess Prozessbeteiligter 85 Prozesskette 226 Prozesstyp 84 Prozessverantwortlicher 85 Punkt offener 95 Qualität 47 Qualitätsmanagement 10 Querschnittsprozess 122 Rahmenbedingungen 49, 171 Realisierung 201 Realisierungsbeziehung 135, 226 realize 156 Redundanz 226 Redundanzbeseitigung 6 rekursiv 226 Rekursive Transition 99 Relation 159, 194 Reorganisation der Organisationseinheiten 116 Requirement 170 Requirements Engineering 16 Responsibility 191 Restrukturierung der Terminologie 106 Risiko 49, 226 eines Geschäftsprozesses 94 ROCE 226 ROI 47, 226 Rolle 194, 226 Routine 193 RUP 227 SAF 226 Scheer 14, 221 Schleichende Prozessveränderung 4 Schnittstelle 201, 203 Schnittstellenklasse 201 Schritt 177 Schwimmbahn 187 Schwimmbahnendiagramm 114 SCM 226 Sektornetzwerk 15 Sekundärer Anwendungsfall 169 Sekundärer Geschäftsanwendungsfall 121 Semantische Objektmodellierung 14 Semantischen Objektmodell 15, 229 Service 193 Signal 185 Signatur 193, 203 Sloan, Alfred 10

5.4 Index

Smalltalk 10 Smith, Adam 9 Software Requirements Engineering 16 Softwarearchitektur 117 Softwareentwicklung 140 Soll-Prozesse 28 SOM 14, 15, 229, 232 Sonnenscheinfall 224 Spezialisierung 156, 160, 186, 198, 209, 226 von Anforderungen 170 Splitting 182 Sprachliche Konsolidierung 106 Stabilität 95, 173 Stakeholder 58, 148, 226 Startknoten 177 Start-up-Unternehmen 5 Startzustand 213 State 213 State diagram 211 state machine 211 state transition diagram 211 Stereotyp 189, 226 stereotypisieren 226 Strategiekarte 226 Strategisch 227 Strategisches Ziel 46, 48, 227 Strukturierte Analyse 12 Strukturiertes Design 12 Strukturmodell 188 Subakteure 157 Subanwendungsfälle 157 Subelement 157 Substantiv 57 Subsystem 204 Superakteur 157 Super-Anwendungsfall 157 Superelement 157 Supply Chain Management 55, 227 swimlane 187 SWOT-Netzwerk 15 Synchronisation 182 Syndrom Das machen wir immer so 6 Synergie 227 Synergieanalyse 7 Synergieeffekt 6 Systemakteur 154, 227 Systemanwendungsfall 133, 168, 227 Systemanwendungsfallmodell 169 Systementwicklung 19 Szenario 160, 227 Taxonomie 156, 186, 198 Taylor, Frederick W. 9 Taylorismus 10 Teilung 182 Transaktion 227 Datenbank- 138 fachliche 138

Transaktionalität 88, 137 Transition 112, 214, 227 rekursive 99 Transitionsbeschreibung 214 Typ 189 UML 12, 133, 227 UML-Klassendiagramm 206 UML-Profil 147 Umsatz 47 Umsatzrendite 47 UND-Verknüpfung 182 Unified Modeling Language 227 Unified Process 31, 227 Unterelement 157 Unternehmensidentität 227 Unternehmensleitziel 48 Unternehmenswachstum 5 Unternehmenszusammenschluss 6 Unternehmenszweck 56, 61, 66, 165, 167, 227 Unterstützender Geschäftsanwendungsfall 61, 62, 66, 167, 227 Unterstützender Geschäftsprozess 79 Use Case 160, 165, 166, 167, 228 Use Case Diagram 155 Use Case Model 155 Variable 192 Variante 21, 96 Verantwortlicher 85 eines Geschäftsprozesses 84 Verantwortlichkeit 191 Verantwortlichkeitsbereich 187 Verantwortlichkeitsprinzip 191 Verantwortlichkeitsverteilung 114 Verb 57 Verbindlichkeit 174 Vereinfachte Priorisierung 49, 91, 95 Vererbung 156, 186, 198, 228 Verzweigung 182 Virtuelle Klasse 200 Vision des Unternehmens 39 Vorbedingung 93, 228 Vorkommnis 185 Wachstum Siehe Unternehmenswachstum Wartbarkeit 171 Weisungsbefugnis disziplinarisch 209 fachlich 209 Wiki 64, 180, 228 Workflow 163, 228 Workflow Management Coalition 232 Xerox 10 ZAK-Karte 48 Zeitereignis 148, 154, 227 Zeitliche Kohärenz 88, 137 Ziel 90, 170, 171 Beschreibungsschema 47

237

238

5.4 Index

der Geschäftsprozessmodellierung 46 eines Geschäftsprozesses 94 operatives 46, 225 strategisches 46, 227 Zielart 49 Zielerreichung 90 Zielformulierung 50 Zielgetriebene Priorisierung 49, 91, 95 Zielgewicht 49, 91 Zielwert 49

[email protected] - e0bc665aadbcb98e5d09-79441-10619-1

Zusammenführung 182 Zusammenschluss Siehe Fusion Zusicherung 228 Zustand 213, 228 Zustandsdiagramm 228 Zustandsübergang 214 Zustandübergangsdiagramm 211 Zuverlässigkeit 171 Zweck der GPM 133