Bernd Oestereich Christian Weiss Claudia Schröder Tim Weilkiens Alexander Lenhard. Objektorientierte Geschäftsprozessmodellierung mit der UML

Bernd Oestereich Christian Weiss Claudia Schröder Tim Weilkiens Alexander Lenhard Objektorientierte Geschäftsprozessmodellierung mit der UML

Bernd Oestereich Bernd.Oestereich@oose.de Christian Weiss Christian.Weiss@oose.de Claudia Schröder Claudia.Schroeder@system-analyst.de Tim Weilkiens tim.weilkiens@oose.de Alexander Lenhard Alexander.Lenhard@oose.de 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 Heidi.Heilmann@t-online.de 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 <http://dnb.ddb.de> abrufbar. ISBN 3-89864-237-2 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. 5 4 3 2 1 0

Der Geschäftsprozess der Geschäftsprozessmodellierung im Überblick (Essenzbeschreibung) Modellierungsfokus festlegen Es wird festgelegt, welches Unternehmen überhaupt modelliert werden soll und welches die Ziele des Unternehmens sind. 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). Organisationseinheiten modellieren Es wird die vorhandene Organisationsstruktur ermittelt und beschrieben. 1. Identifiziere die Organisationseinheiten innerhalb des Modellierungsfokus. 2. Stelle die Organisationsstruktur grafisch als UML- Klassenmodell dar. Ziele festlegen Es wird ermittelt und dokumentiert, womit das Unternehmen Geld verdient. 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. Aktive Geschäftspartner identifizieren Es wird ermittelt und dokumentiert, wer die Kunden des Unternehmens sind. 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äftsanwendungsfälle der aktiven Geschäftspartner identifizieren Es werden die Geschäftsanwendungsfälle der Kunden in Kurzform beschrieben. 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. Weitere unterstützende Geschäftsanwendungsfälle identifizieren Es werden die Geschäftsanwendungsfälle von Lieferanten und anderen Geschäftspartnern in Kurzform beschrieben. Geschäftsprozesse für Systementwicklung modellieren Orgeinheiten modellieren GMA und Akteurmodell definieren Kap. 3.7 S. 72 GAF-Modell erstellen Kap. 3.15 S. 118 Sonstige Anforderungen definieren Kap. 3.18 S. 129 Kap. 3.2, S. 43 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. Modellierungsfokus festlegen Kap. 3.3, S. 46 GAF essenziell beschreiben Ziele festlegen GAF-Abläufe modellieren GAF-Abläufe optimieren u. konsolidieren Kap. 3.12, S. 102 Systemanwendungsfälle definieren Kap. 3.1, S. 37 Kap. 3.10 S. 87 Fachliches Glossar entwickeln GAF der aktiven GPA identifizieren Weitere unterstützende GAF identifizieren Kap. 3.11 S. 96 GAF-Abläufe detaillieren Kap. 3.19 S. 133 Aktive GPA identifizieren Kap. 3.8 S. 77 Geschäftsprozesse definieren Kap. 3.13 S. 111 Geschäftsklassenmodell entwickeln Organisat. Einbettung und Abhäng. reorg. Geschäftsprozesse für Systementwicklung modelliert GAF = Geschäftsanwendungsfälle GPA = Geschäftspartner GMA = Geschäftsmitarbeiter Kap. 3.16 S. 123 Kap. 3.4 S. 51 Kap. 3.5, S. 56 Kap. 3.6, S. 66 Fachliches Glossar entwickeln Geschäftsprozesse dokumentieren Kap. 3.14 S. 114 Zustandsmodelle entwickeln Kap. 3.20 S. 141 Kap. 3.9 S. 84 Kap. 3.17 S. 127 Es werden die wichtigsten modellierungsrelevanten Fachbegriffe definiert. 1. Lege ein fachliches Glossar an und definiere dort alle wichtigen fachlichen Begriffe. 2. Stimme alle Begriffe mit den wichtigsten Stakeholdern ab. 2003 by oose.de GmbH Aktuelle Fassung, Info und Download: http://www.oogpm.de OOGPM-Methodikübersicht Teil 1/2

Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln Es werden alle an den Geschäftsanwendungsfällen beteiligten Akteure und Organisationseinheiten beschrieben. 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äftsanwendungsfälle essenziell beschreiben Es werden alle Geschäftsanwendungsfälle in einem einheitlichen Detaillierungsgrad und anhand einiger formaler Kriterien näher beschrieben. 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. Geschäftsprozesse definieren Alle zusammengehörenden Geschäftsanwendungsfälle werden zu Geschäftsprozessen zusammengefasst. 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äftsanwendungsfallmodell erstellen Die Beziehungen, Abhängigkeiten und Gemeinsamkeiten der Geschäftsanwendungsfälle werden beschrieben. 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äftsanwendungsfall-Abläufe modellieren Die Abläufe der Geschäftsanwendungsfälle werden inklusive aller fachlichen Ausnahmen und Varianten modelliert. 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 Offene-Punkte- Liste. Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren 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. 1. Überprüfe und restrukturiere ggf. die Ablaufreihenfolgen. 2. Überprüfe und konsolidiere die verwendeten Begriffe. Geschäftsanwendungsfall-Abläufe detaillieren Die einzelnen Aktivitäten eines jeden Geschäftsanwendungsfall- Ablaufmodelles werden in einer vorgegebenen Form detailliert. 1. Beschreibe die einzelnen Aktivitäten eines jeden Geschäftsanwendungsfall-Ablaufmodelles in einer vorgegebenen detaillierten Form. Organisatorische Einbettung identifizieren und Abhängigkeiten ggf. reorganisieren Die sich aus der organisatorischen Zuordnung von Verantwortlichkeiten ergebenden Abhängigkeiten werden identifiziert und ggf. durch Reorganisation der Verantwortlichkeiten oder Organisationseinheiten optimiert. 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äftsprozesse dokumentieren Die Geschäftsprozesse werden in detaillierterer Form beschrieben. 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. Sonstige Anforderungen definieren Geschäftsregeln und andere geschäftliche Anforderungen werden definiert. 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. Systemanwendungsfälle definieren Es wird entschieden, welche Anwendungsfälle systemtechnisch unterstützt werden sollen. Diese werden dann als Systemanwendungsfälle weiter detailliert. 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äftsklassenmodell entwickeln Die Struktur der fachlichen Begriffe und Geschäftsobjekte wird grafisch dargestellt. 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. Zustandsmodelle entwickeln Die möglichen fachlichen Zustände von zustandsrelevanten Geschäftsklassen werden modelliert. 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. 2003 by oose.de GmbH Aktuelle Fassung, Info und Download: http://www.oogpm.de OOGPM-Methodikübersicht Teil 2/2

Anwendungsfalldiagramm Passiver Geschäftspartner Abstrakter aktiver Geschäftspartner Spezialisierter Anwendungsfall Anwendungsfall «include» «secondary» Sekundärer Anwendungsfall Systemakteur Fremdsystem als Akteur Konkreter aktiver Geschäftspartner Innenorientierter Geschäftsmitarbeiter Zeitereignis Außenorientierter Geschäftsmitarbeiter Geschäftsprozesse Anforderungen «core business process» Kern-Geschäftsprozess Kern-Geschäftsprozess «Requirement» Anforderung «include» «Feature» Ein Feature «Aim» Ein Ziel «Problem» Ein Problem «business process» Geschäftsprozess Systemanwendungsfall Systemanwendungsfall Kern-Geschäftsanwendungsfall Geschäftsanwendungsfall Geschäftsprozess Ein Feature Ein Ziel Ein Problem Aktivitätsdiagramme Parameter Aktivität Parameter : Typ Schritt 1 [Bed. 1] [Bed. 2] Schritt 2 Ende Objektknoten [Zustand] Schritt 3 Signal Schritt 4 Parameter Start [weiter] [stopp] Ablaufende Schritt 4 Schritt 4.1 Schritt 4.3 Schritt 4.2 Schritt 4.4 Generalisierte Aktivität Partition 1 Partition 2 Start Teilung Synchronisation Teilung und (Splitting) (Und) Synchronisation Spezialisierte Aktivität Spezialisierte Aktivität Aktivitäts-Generalisierung Schritt 1 Schritt 2 [x<0] [x>0] [x=0] Verzweigung Zusammenführung (Oder) [x<0] [x>0] [x<0] [x=0] [x=0] Verzweigung und Zusammenführung [x>0] Schritt 4 Schritt 3 Ende 2003 by oose.de GmbH Aktuelle Fassung, Info und Download: http://www.oogpm.de OOGPM-Notationsübersicht Teil 1/2

Klassen «Stereotyp» Paket::Klasse {Eigenschaftswerte} attribut operation() Paket::Klasse... Verantwortlichkeiten... Klasse Boundary Abstrakte Klasse Control Abstrakte Klasse {abstract} Entity Generalisierung (Vererbung) Assoziationen Oberklasse Klasse A 1..* Assoziationsname 0..* Rolle A Rolle B Klasse B Diskriminator Klasse A Gerichtete Assoziation Klasse B Unterklasse1 Unterklasse2 Unterklasse3 Ganzes Aggregation Teil Pakete Schnittstellen «interface» Schnittstelle «interface» Schnittstelle Paket Paket Paket Anwendungsfall Anwendungsfall Implementierende Klasse Implementierung bzw. Bereitstellung einer Schnittstelle Bereitgestellte Schnittstelle Klasse Anforderung bzw. Nutzung einer Schnittstelle Benötigte Schnittstelle Organisationseinheiten Abstrakte Orgeinheit «organization unit» Orgeinheit Orgeinheit Orgeinheit {Stabsstelle} Orgeinheit kürzel leitung stellvertretung kostenstelle A A A A «reporting» B B B B Disziplinarische Weisungsbefugnis (A weist B an) und Verantwortung (A ist für B verantwortlich) Berichtsweg (B berichtet an A) Spezialisierung (B ist eine Art A) Funktionale Weisungsabhängigkeit mit fachlicher Verantwortung (B ist funktional weisungsabhängig von A) Zustandsdiagramme Zustand Zustand Startzustand Unterzustand Ereignis Unterzustand [Bedingung] Endzustand Ereignis 2003 by oose.de GmbH Aktuelle Fassung, Info und Download: http://www.oogpm.de OOGPM-Notationsübersicht Teil 2/2

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.

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 ISO 1 ) 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.

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 Informatiker- Innen, 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 Ikea- Grü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

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

viii Inhaltsverzeichnis 1 Einleitung... 1 1.1 Warum Geschäftsprozessmodellierung?...3 1.2 Historie der Geschäftsprozessorientierung...9 1.3 Abgrenzung...11 1.3.1 Objektorientierung und UML...12 1.3.2 Andere Modellierungsansätze...14 1.3.3 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 Modellierungsfokus festlegen und Unternehmensziele beschreiben...37 3.2 Organisationseinheiten modellieren...43 3.3 Ziele festlegen...46 3.4 Aktive Geschäftspartner identifizieren...51 3.5 Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren...56 3.6 Weitere unterstützende Geschäftsanwendungsfälle identifizieren...66 3.7 Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln...72 3.8 Geschäftsprozesse definieren...77 3.9 Geschäftsprozesse dokumentieren...84 3.10 Geschäftsanwendungsfälle essenziell beschreiben...87 3.11 Geschäftsanwendungsfall-Abläufe modellieren...96 3.12 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren...102 3.13 Geschäftsanwendungsfall-Abläufe detaillieren...111 3.14 Organisatorische Einbettung und Abhängigkeiten identifizieren...114 3.15 Geschäftsanwendungsfall-Modell erstellen...118 3.16 Geschäftsklassenmodell erstellen...123 3.17 Zustandsmodelle für zustandsrelevante Geschäftsklassen erstellen...127 3.18 Geschäftliche Anforderungen und Regeln beschreiben...129 3.19 Systemanwendungsfälle definieren...133 3.20 Glossar und Abkürzungsverzeichnis entwickeln...141 4 UML Notation und Semantik... 145 4.1 UML...147 4.2 Akteur...148 4.2.1 Aktive Geschäftspartner...150

ix 4.2.2 Passive Geschäftspartner...151 4.2.3 Innenorientierte Geschäftsmitarbeiter...152 4.2.4 Außenorientierte Geschäftsmitarbeiter...153 4.2.5 Systemakteure...154 4.3 Anwendungsfallmodell...155 4.3.1 Spezialisierung, Realisierung von Anwendungsfällen...156 4.3.2 Enthält-Beziehung...158 4.3.3 Assoziation in Anwendungsfalldiagrammen...159 4.3.4 Anwendungsfall (allgemein)...160 4.3.5 Geschäftsprozess...163 4.3.6 Geschäftsanwendungsfall...165 4.3.7 Kern-Geschäftsanwendungsfall...166 4.3.8 Unterstützender Geschäftsanwendungsfall...167 4.3.9 Systemanwendungsfall...168 4.3.10 Sekundärer Anwendungsfall...169 4.3.11 Anforderung...170 4.4 Aktivitätsmodelle...175 4.4.1 Aktivitätsdiagramm...175 4.4.2 Aktivität und Transition...177 4.4.3 Aktivitätsbeschreibung...179 4.4.4 Funktionsbaum...181 4.4.5 Verzweigungen und Zusammenführungen...182 4.4.6 Involvierte Geschäftsobjekte...184 4.4.7 Signal...185 4.4.8 Spezialisierung/Generalisierung von Aktivitäten und Anwendungsfällen...186 4.4.9 Verantwortlichkeitsbereiche...187 4.5 Geschäftsklassenmodell...188 4.5.1 Klasse...189 4.5.2 Verantwortlichkeit...191 4.5.3 Attribut...192 4.5.4 Operation...193 4.5.5 Assoziation...194 4.5.6 Spezialisierung/Generalisierung von Klassen...198 4.5.7 Abstrakte Klasse...200 4.5.8 Schnittstelle...201 4.6 Pakete...204 4.7 Organisationsplan...206 4.7.1 Organisationseinheit...207 4.7.2 Organisationsbeziehungen...209 4.8 Zustandsmodelle...211 4.8.1 Zustand...213 4.8.2 Ereignis und Zustandsübergang...214

x 5 Anhang... 217 5.1 Abkürzungsverzeichnis...219 5.2 Glossar...220 5.3 Literatur...228 5.4 Index...233

1 Einleitung Phantasie ist wichtiger als Wissen. Albert Einstein

1.1 Warum Geschäftsprozessmodellierung? 3 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ätssteigerungen beispielsweise durch Automatisierung zu bewirken, das heißt, Zeit, Kosten, Qualität und andere Faktoren zu optimieren, geht es seit kurzem immer mehr darum, welche Teile des Prozesskette aus dem Unternehmen ausgelagert und an Dritte übertragen werden können (sog. Outsourcing). Produktivitätssteigerung, Automatisierung, Outsourcing

4 1.1 Warum Geschäftsprozessmodellierung? Änderungen im Umfeld, bspw. im Verhalten der Geschäftspartner Ad-hoc-Erfindungen und Improvisationen der Prozessbeteiligten 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. 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, Steuer- IDs 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. 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.

1.1 Warum Geschäftsprozessmodellierung? 5 Willkürliche und unkontrollierte Prozessgestaltung. Es gibt natürlich auch Fälle, in denen von Anfang an Chaos herrscht. Dies betrifft in besonderem Maße neu gegründete und sehr schnell wachsende Unternehmen mit unerfahrenen Führungskräften. Viele so genannte Start-up- Unternehmen 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 Versandhaus 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 Absicht eines Unternehmens, die Kosten zu senken bzw. die Produktivitä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- Undefinierte Geschäftsprozesse in Start-ups Time to market Produktivität Kostensenkung

6 1.1 Warum Geschäftsprozessmodellierung? Insourcing Das machen wir immer so Synergieeffekte und Redundanzbeseitigung 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. 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. Bei Fusionen wird gewöhnlich viel von so genannten Synergien oder Synergieeffekten 2 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 Redundanzen 3 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.

1.1 Warum Geschäftsprozessmodellierung? 7 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 bilden, 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 liefern gute Gründe, sich mit der Modellierung von Geschäftsprozessen zu beschäftigen. Es beginnt damit anzuerkennen, dass die meisten geschäftlichen Tätigkeiten in der Praxis nach bestimmten Regeln ablaufen, 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 nur bis zu einem gewissen Grad überhaupt planbar und regelbar sind. 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. Synergieanalyse Methodik, Systematik Zweck und Ziele von Geschäftsprozessen Angemessenheit: Agile Methodik

8 1.1 Warum Geschäftsprozessmodellierung? Aufmerksamkeit lenken ISO Messen Restrukturierungen 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: 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-

1.2 Historie der Geschäftsprozessorientierung 9 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 unterschiedliche Interessen, sie verwenden möglicherweise unterschiedliche 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. Verschiedene Sichten zusammenführen 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 amerikanischer Ö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. Adam Smith und Frederick W. Taylor

10 1.2 Historie der Geschäftsprozessorientierung Taylorismus Henry Ford und Alfred Sloan 1938: Chester F Carlson und die Objektorientierung Michael Hammer, James Champy und Thomas H. Davenport 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. 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]).