(

Transkript

1

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 ( 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.

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

4 Bernd Oestereich Christian Weiss Claudia Schröder Tim Weilkiens Alexander Lenhard Mehr über die Autoren und»the making of the book«erfahren Sie unter 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 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 PDF epub Auflage 2003 Copyright 2003 dpunkt.verlag GmbH Ringstraße 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 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

6 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.

7 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

8

9 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 In diesem Kapitel finden Sie eine kurze Zusammenfassung unserer Methodik und Informationen zu ihrer Einbettung in die System- und Softwareentwicklung. 3 OOGPM-Methodik 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 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 Abkürzungen Glossar Literatur Index

10 x Inhaltsverzeichnis 1 Einleitung Warum Geschäftsprozessmodellierung? Historie der Geschäftsprozessorientierung Abgrenzung Objektorientierung und UML Andere Modellierungsansätze Requirements Engineering Überblick und Orientierung Vorgehensweise Einbettung in die Systementwicklung OOGPM-Methodik Modellierungsfokus festlegen und Unternehmensziele beschreiben Organisationseinheiten modellieren Ziele festlegen Aktive Geschäftspartner identifizieren Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren Weitere unterstützende Geschäftsanwendungsfälle identifizieren Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln Geschäftsprozesse definieren Geschäftsprozesse dokumentieren Geschäftsanwendungsfälle essenziell beschreiben Geschäftsanwendungsfall-Abläufe modellieren Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren Geschäftsanwendungsfall-Abläufe detaillieren Organisatorische Einbettung und Abhängigkeiten identifizieren Geschäftsanwendungsfallmodell erstellen Geschäftsklassenmodell erstellen Zustandsmodelle für zustandsrelevante Geschäftsklassen erstellen Geschäftliche Anforderungen und Regeln beschreiben Systemanwendungsfälle definieren Glossar und Abkürzungsverzeichnis entwickeln UML Notation und Semantik UML Akteur Aktive Geschäftspartner

11 xi Passive Geschäftspartner Innenorientierte Geschäftsmitarbeiter Außenorientierte Geschäftsmitarbeiter Systemakteure Anwendungsfallmodell Spezialisierung, Realisierung von Anwendungsfällen Enthält-Beziehung Assoziation in Anwendungsfalldiagrammen Anwendungsfall (allgemein) Geschäftsprozess Geschäftsanwendungsfall Kern-Geschäftsanwendungsfall Unterstützender Geschäftsanwendungsfall Systemanwendungsfall Sekundärer Anwendungsfall Anforderung Aktivitätsmodelle Aktivitätsdiagramm Aktivität und Transition Aktivitätsbeschreibung Funktionsbaum Verzweigungen und Zusammenführungen Involvierte Geschäftsobjekte Signal Spezialisierung/Generalisierung von Aktivitäten und Anwendungsfällen Verantwortlichkeitsbereiche Geschäftsklassenmodell Klasse Verantwortlichkeit Attribut Operation Assoziation Spezialisierung/Generalisierung von Klassen Abstrakte Klasse Schnittstelle Pakete Organisationsplan Organisationseinheit Organisationsbeziehungen Zustandsmodelle Zustand Ereignis und Zustandsübergang...214

12 xii 5 Anhang Abkürzungsverzeichnis Glossar Literatur Index

13 1 Einleitung Phantasie ist wichtiger als Wissen. Albert Einstein

14

15 1.1 Warum Geschäftsprozessmodellierung? 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

16 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 . 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 s 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.

17 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 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

18 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.

19 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

20 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-

21 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

22 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 erfand der Physiker Chester F. Carlson die Fotokopie, die heute immer noch eine der wichtigsten Technologien zur Unterstützung von Geschäftsprozessen darstellt 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]).

23 1.3 Abgrenzung 11 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, [Davenport93] T. H. Davenport: Process Innovation: Reengineering Work through Information Technology. Harvard Business School Press, Boston, [Hammer90] M. Hammer: Reengineering Work: Don't Automate, Obliterate, Harvard Business Review July-August 1990, S [Hammer93] M. Hammer, J. Champy: Reengineering the Corporation: A Manifesto for Business Revolution. HarperBusiness, New York, [Harrington91] H. J. Harrington: Business Process Improvement: The Breakthrough Strategy for Total Quality, Productivity, and Competitiveness, McGraw-Hill, New York, [Jacobson92] I. Jacobson, M. Christerson, P. Jonsson, G. Overgaard: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, Reading, [Jacobson94] I. Jacobson, M. Ericson, A. Jacobson: Object Advantage, The: Business Process Reengineering with Object Technology. Addison-Wesley, Reading, [Scheer94] A.-W. Scheer: Business Process Engineering: Reference Models for Industrial Enterprise-Modeling. Springer, Berlin, 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.

24 Abgrenzung Extrakt Objektorientierung und UML Was ist Objektorientierung? Was ist UML (Unified Modeling Language)? Warum Objektorientierung und UML für Geschäftsprozessmodellierung? UML 145 Klassische Methoden: SA, SD, ERM etc. Was hat GPM mit Software zu tun? 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]. 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-

25 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äftsprozessmodellierung? Für die objektorientierte Softwareentwicklung hat sich die 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, 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. Geschäftsprozessmodellierung und UML Vorteile für GPM durch UML Weiterführende Literatur: [Booch99] G. Booch, J. Rumbaugh, I. Jacobson: Unified Modeling Language User Guide. Addison Wesley Longman, Reading, [Hitz03] M. Hitz, G. Kappel: work: Von der Analyse zur Realisierung. 2. Auflage, dpunkt.verlag, Heidelberg, [Oestereich01a] B. Oestereich: Objektorientierte Softwareentwicklung: Analyse und Design mit der UML. 5. Auflage, Oldenbourg Wissenschaftsverlag, München, 2001.