Marc-Oliver Herrmann. Konzeptionelle Weiterentwicklung eines Modellierungswerkzeuges zur kollaborativen Geschäftsprozessmodellierung

Transkript

1 Marc-Oliver Herrmann Konzeptionelle Weiterentwicklung eines Modellierungswerkzeuges zur kollaborativen Geschäftsprozessmodellierung

2 Erklärung: Ich versichere, die beiliegende Bachelorthesis selbständig verfasst, keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie alle wörtlich oder sinngemäß übernommenen Stellen in der Arbeit gekennzeichnet zu haben. Pforzheim, den Marc-Oliver Herrmann

3 Marc-Oliver Herrmann Abgabedatum: Konzeptionelle Weiterentwicklung eines Modellierungswerkzeuges zur Unterstützung kollaborativer Geschäftsprozessmodellierung Bachelorarbeit vorgelegt zur Erlangung des Bachelorgrades der Hochschule Pforzheim Betreuer: Prof. Dr. Heiko Thimm Zweitkorrektor: Prof. Alfred Schätter

4 Inhaltsverzeichnis Inhaltsverzeichnis... I Abkürzungsverzeichnis... V Abbildungsverzeichnis... VI Tabellenverzeichnis... VIII 1 Einleitung PROMATIS software GmbH Thematik Zielsetzung Vorgehensweise Geschäftsprozessmodellierung Geschäftsprozesse Geschichte der GPM Grundlegende Aspekte der GPM Prozessmodellierungssprachen Überblick (e)epk BPMN Petri-Netze Referenzmodelle Ansätze, Konzepte und Methoden Aktuelle Rolle der GPM im Rahmen der Softwareentwicklung Kollaborative GPM Der Kollaborationsbegriff I

5 3.1.1 Ursprung des Begriffs Kollaboration Kooperation Koordination Kommunikation Kontext Zusammenfassung Kollaborative Softwareentwicklung im Allgemeinen Bedeutung der kollaborativen Softwareentwicklung Betrachtung konkreter Ansätze Gruppenorientierte Ansätze Prozessorientierte Ansätze Werkzeugorientierte Ansätze Anforderungen an GPM-Werkzeuge Interaktion gruppen-, prozess- und werkzeugorientierter Ansätze Allgemeine funktionale Anforderungen Zugriffskontrolle Informationsmanagement Projektmanagement Wissensmanagement Konfigurationsmanagement Die fünf zentralen Komponenten im Zusammenspiel Szenarien Szenario A: Informationsrückfluss aus der Business Community in die Knowledge Base II

6 Szenario B: Modellieren unter Einbeziehung der Business Community Spezifische funktionale Anforderungen Evaluierung am Markt erhältlicher Modellierungstools Definition eines Modellierungstools Auswahl der Tools Vorgehen Evaluierungskriterien ADONIS Community Edition ARIS Business Architect Dia Horus Business Modeler Oryx ViFlow Fazit Fachkonzept Informationsrückfluss und-austausch mit Hilfe von Tickets abwickeln Wichtige Bestandteile des Konzepts Ticket-Systeme Definition Zielsetzung und Funktionsweise Trac Horus Business Modeler Notwendige Anpassungen III

7 5.3.1 Anpassungen am Horus Business Modeler Anpassungen am Ticket-System Fachliche Umsetzung Technisches Konzept Technische Konkretisierung wichtiger Begrifflichkeiten Hinterlegen der Eigenschaften eines Workspaces Link auf ein Element im Repository Technische Realisierung der Kopplung des Horus Business Modeler mit einem Ticket-System Architektur des Horus Business Modeler Das Framework Mylyn für Eclipse Konzept von Mylyn Interaktion von Eclipse, Mylyn und Ticket-System Integration von Mylyn-Plug-ins in den Horus Business Modeler Zusammenfassung und Ausblick Quellenverzeichnis IV

8 Abkürzungsverzeichnis ADONIS: CE BPEL BPMN BSD CAIS CSCW DisIRE (e)epk ERP GPL GPM IDE KB RCP RUP Social BPM OMG OSGi SWT UML UI XML ADONIS: Community Edition Business Process Execution Language Business Process Modeling Notation (2004), Business Process Model and Notation (2010) Berkeley Software Distribution Collaborative Asynchronous Inspection of Software Computer Supported Cooperative Work Distributed Internet-Based Requirements Engineering (erweiterte) Ereignisgesteuerte Prozesskette Enterprise Ressource Planning General Public Licence Geschäftsprozessmodellierung Integrated Development Environment Knowledge Base Rich Client Platform Rational Unified Process Social Business Process Management Object Management Group Open Service Gateway Initiative Standard Widget Toolkit Unified Modeling Language User Interface Extensible Markup Language V

9 Abbildungsverzeichnis Abbildung 1: Lebenszyklus von Geschäftsprozessen Abbildung 2: Einfaches Ablaufdiagramm Abbildung 3: Objektmodell des Auftragsprozesses Abbildung 4: Organisationsstruktur und Prozessabläufe Abbildung 5: EPK Symbolik Abbildung 6: Bestellabwicklungsprozesses mit einer (e)epk Abbildung 7: Bestellabwicklungsprozess mit BPMN Abbildung 8: Bestellabwicklungsprozesses mit einem Petri-Netz Abbildung 9: Petri-Netze und Matrizen Abbildung 10: IT-Projekte Zeitplan und Budget Abbildung 11: Iterative Softwareentwicklung Abbildung 12: Elemente der kollaborativen Softwareentwicklung Abbildung 13: Entwicklung des Umfangs von Software Abbildung 14: Microsoft Sharepoint Abbildung 15: System zur Unterstützung von Kollaboration Abbildung 16: ADONIS Messages Abbildung 17: ARIS Versionierungs-Assistent Abbildung 18: Dia Markierung Abbildung 19: Horus Social BPM Abbildung 20: Repository von Oryx Abbildung 21: Sketchdarstellung in Oryx Abbildung 22: ViFlow Abbildung 23: Funktionsweise eines Ticket-Systems VI

10 Abbildung 24: Erstellen eines Tickets in Trac Abbildung 25: Ansicht eines Tickets in Trac Abbildung 26. Horus Business Modeler Abbildung 27: Objektdiagramm der strukturellen Aspekte des Horus Business Modeler Abbildung 28: Objektdiagramm Horus Business Modeler Abbildung 29: Trac neue Felder Abbildung 30: Ticketerstellungsprozess Abbildung 31: Erstellung eines elementbezogenen Tickets aus dem Horus Business Modeler heraus Abbildung 32: Eingabemaske Ticket im Horus Business Modeler Abbildung 33: "Horus-Ticket" im Trac Abbildung 34: Ablauf Workspace erstellen Abbildung 35: Eigenschaftsfenster des Horus Business Modeler Abbildung 36: Erweitertes Eigenschaftsfenster Abbildung 37: Horus-URL-Aufruf Abbildung 38: Komponentenarchitektur des Horus Business Modeler Abbildung 39: Mylyn Abbildung 40: Plug-ins von Mylyn Abbildung 41: Horus Business Modeler mit Ticket-Erweiterung VII

11 Tabellenverzeichnis Tabelle 1: Modellierungssprachen Tabelle 2: Klassifikationskriterien für Kooperationsformen Tabelle 3: Funktionaler Vergleich kommerzieller Kollaborationsplattformen Tabelle 4: Ergebnis der Evaluation VIII

12 1 Einleitung Dieses Kapitel soll die Basis für das Verständnis und die Einordnung der vorliegenden Arbeit legen. In diesem Sinne wird zunächst die Firma, die diese Ausarbeitung unterstützte, die PROMATIS software GmbH, vorgestellt. Daraufhin erfolgt die Erläuterung der Thematik und Zielsetzung der Abschlussarbeit. Abschließend wird das weitere Vorgehen im Rahmen der Thesis beschrieben. 1.1 PROMATIS software GmbH Die vorliegende Bachelorarbeit entstand in Zusammenarbeit mit der PROMATIS software GmbH. Sie wurde 1994 von Absolventen der Universität Karlsruhe gegründet und hat ihren Stammsitz in Ettlingen sowie weitere Standorte in Hamburg und Berlin. Von hier aus bietet die PROMATIS software GmbH ( ) qualifizierte Beratungsleistungen an, die von der Planung über die Umsetzung bis hin zur Führung und Monitoring der Geschäftsprozesse reichen (vgl. PROMATIS, URL). Dabei arbeitet PROMATIS in seiner Funktion als Platinum Partner eng mit Oracle zusammen. Ausgehend von einer tiefgehenden Analyse der Geschäftsprozesse führt PROMATIS bei seinen Kunden Module des ERP- Systems (Enterprise Ressource Planning) von Oracle, der Oracle E-Business Suite, ein und passt sie den spezifischen Gegebenheiten an. Namhafte Kunden sind unter anderem Porsche, MLP oder auch Hellmann Worldwide Logistics. 1.2 Thematik Seit Adam Smith und seiner Idee der Arbeitsteilung sind mittlerweile 235 Jahre vergangen (Smith, 1776). Doch ist sein Gedanke präsenter als je zuvor. In einer durch moderne Informations- und Kommunikationstechnologie global vernetzten Wirtschaftswelt ist Arbeitsteilung allgegenwärtig und so leicht wie nie zuvor realisierbar (vgl. Koopmann, Franzmeyer, 2008). Beispielsweise stammen die Teile eines deutschen Autos aus vielen verschiedenen Ländern unterschiedlichster Zulieferer und lassen Unternehmen wie NVIDEA ihre Produkte vollständig durch Partner fertigen (vgl. Greive, 2009; vgl. Manners, 2010). In diesem 3

13 1.2 Thematik globalisierten Informationszeitalter ist das Angebot an Gütern größer als die Nachfrage und sinkt die Produktlebensdauer stetig (vgl. Dürmüller, 2008). Daher sind perfekt abgestimmte, auf die Kundenwünsche ausgerichtete und agile Geschäftsprozesse für Unternehmen überlebenswichtig, um sich zum einen von Wettbewerbern abzuheben und zum anderen schnell auf Änderungen reagieren zu können (vgl. Schönthaler et al., 2010, S. 3). In einer verzahnten Wirtschaftswelt betreffen Prozesse also, wie gerade geschildert, nicht mehr nur das Unternehmen selbst oder gar lediglich bestimmte Firmenteile, sondern auch seine Lieferanten und Kunden (vgl. Künne, 2010, S. 21). Daher ist es zunehmend wichtig, die Prozesse unter Einbeziehung aller zuvor genannter Gruppen sowie aller Stakeholder, kurz der Business Community, zu gestalten, also kollaborativ zu designen bzw. re-designen (vgl. Schönthaler et al., 2010, S ). Im Rahmen der Entwicklung von Businesssoftware, welche die Prozesse unterstützen bzw. abbilden soll, rückt daher eine gemeinschaftliche Erstellung von Geschäftsprozessmodellen immer mehr in den Focus. Verstärkt wird dieser Trend dadurch, dass auch die Entwicklung von Software selbst zunehmend arbeitsteilig durchgeführt wird und somit ggf. mehrere Entwicklerteams in die kollaborative GPM einbezogen werden müssen. Für die Erzeugung der Modelle werden Computerprogramme, sogenannte Modellierungswerkzeuge, eingesetzt. Im Bereich der IT-Beratung und Implementierung von Unternehmenssoftware, in dem die PROMATIS software GmbH tätig ist, bedeutet kollaborative Geschäftsprozessmodellierung (GPM) einerseits die gemeinschaftliche Erstellung von Geschäftsprozessmodellen durch die Prozess-Ingenieure. Andererseits beschreibt es aber auch die kollaborative Modellierung mit Experten der einzelnen Fachbereiche des zu beratenden Unternehmens und mit dessen Partnern sowie ggf. sogar mit anderen externen Wissensträgern. Externe Wissensträger sind dabei nicht nur professionelle Modellierer, sondern auch fachliche Experten, Studenten, oder andere, die Interesse an Geschäftsprozessen zeigen letztendlich jeder, der einen Beitrag zur 4

14 1.3 Zielsetzung Modellierung eines bestimmten Prozesses liefern möchte. Durch den Einsatz von Web2.0-Technologien wie Social Networks (z. B. Facebook), Microbloggs (z. B. Twitter), oder Wikis (z. B. Wikipedia) können diese Wissensträger erreicht und Netzwerke gebildet werden. Man spricht in diesem Zusammenhang von Social BPM (Business Process Management). Dabei ist zwischen private Communities, die nur einem gewissen Personenkreis zugänglichen sind, und für jeden offenen public Communities zu unterscheiden. Werden Mitglieder dieser Netzwerke im Rahmen von Projekten zur Modellierung von Geschäftsprozessen herangezogen, sind sie Teil der projektbezogenen Business Community (vgl. Schönthaler et al., 2010, S ). Doch steht die Frage im Raum, wie Business Communities effizient eingebunden werden können. Hier sind neben möglichen technischen Lösungen auch Aspekte der Gruppenarbeit und der Arbeitsabläufe zu betrachten. Dabei weist die Vielzahl der existierenden Ansätze darauf hin, dass noch keine klare Antwort gefunden wurde (vgl. Künne, 2010). 1.3 Zielsetzung In den beschriebenen Communities werden Modelle getauscht, diskutiert und überprüft. Allerdings hängt die Qualität der resultierenden Geschäftsprozessmodelle davon ab, inwiefern die Software zur GPM die Freisetzung der Gestaltungskraft und Kreativität solcher Netzwerke fördert (vgl. Schönthaler et al., 2010, S. 190). Ziel dieser Arbeit ist es daher, ausgehend von realen Kollaborationsszenarien, ein generisches Konzept zu entwickeln das Werkzeuge zur GPM um Funktionalitäten erweitert, die kollaboratives Modellieren im oben skizierten Sinne fördern. 1.4 Vorgehensweise Zu diesem Zweck wird im 2. Kapitel zunächst der Begriff Geschäftsprozess definiert und die Entwicklung der Disziplin GPM erläutert. Danach folgt eine kurze 5

15 1.4 Vorgehensweise Analyse existierender Modellierungssprachen sowie der Bedeutung der GPM im Rahmen der Softwareentwicklung. Im 3. Kapitel schließt sich dann eine nähere Auseinandersetzung mit der kollaborativen GPM an. Dafür erfolgt zunächst die Definition des Begriffs Kollaboration sowie die Betrachtung der Kollaboration in der Softwareentwicklung im Allgemeinen. Weiterhin werden grundsätzliche, funktionale Anforderungen an GPM- Werkzeuge beschrieben und anschließend anhand von, in persönlichen Gesprächen mit Prozess-Ingenieuren ermittelten, Kollaborationsszenarien konkretisiert. Im 4. Kapitel werden am Markt erhältliche Modellierungstools evaluiert. Hierbei werden sie auf ihre Eignung hin untersucht, Kollaboration im Rahmen der dargestellten Szenarien zu unterstützen. Kapitel 5 beschreibt zunächst die zentralen Gedanken des zu erarbeitenden Konzepts. Hier schließt sich eine allgemeine Betrachtung von Ticket-Systemen an, bevor das Ticket-System Trac, welches im Rahmen dieser Ausarbeitung exemplarisch Verwendung findet, näher vorgestellt wird. Darauf folgt eine genauere Analyse des strukturellen Aufbaus des Modellierungstools Horus Business Modeler. Dieses Werkzeug wurde als Basis des in der vorliegenden Arbeit entwickelten Konzepts gewählt. Anschließend werden notwendige, programmspezifische Änderungen an Trac bzw. dem Horus Business Modeler beschrieben und am Ende des Kapitels der Ablauf bei der Nutzung der neue bereitgestellten Funktionalitäten skizziert. Kapitel 6 beschäftigt sich mit der technischen Umsetzung des zuvor beschriebenen, fachlichen Konzepts. Hierzu wird die Architektur des Horus Business Modelers sowie das Eclipse-Framework Mylyn betrachtet, bevor eine Erläuterung des technischen Zusammenspiels beider Anwendungen erfolgt. 6

16 1.4 Vorgehensweise Diese Thesis schließt in Kapitel 7 mit einer Zusammenfassung der erarbeiteten Ergebnisse sowie einem Ausblick auf die weiteren Entwicklungen rund um das vorgestellte Konzept. Zur Verbesserung der Lesbarkeit wird in dieser Arbeit ausschließlich die männliche Form verwendet. Diese impliziert aber immer auch die weibliche. 7

17 2 Geschäftsprozessmodellierung Dieses Kapitel widmet sich der genaueren Erläuterung der GPM. Dazu wird zunächst der Begriff Geschäftsprozess hergeleitet, um dann die Entstehung der Disziplin GPM zu skizzieren. Es folgen eine Einführung in die grundlegenden Aspekte der GPM, eine Analyse von Modellierungssprachen, sowie ein kurzer Ausblick auf Ansätze zur effizienten und systematischen Verwendung von Geschäftsprozessmodellen. Das Kapitel schließt mit der Einordnung der GPM in den Kontext des Softwareentwicklungsprozesses. 2.1 Geschäftsprozesse Geschäftsprozesse sind keine Erfindung unserer Zeit, sondern so alt wie die Gedanken von Adam Smith (1776) und später Frederick Winlow Taylor (1903, 1911) zur Arbeitsteilung (vgl. Smith, 1776; vgl. Taylor 1903, 1911). Aus den in Kapitel 1 erläuterten Gründen, wie zunehmende globale Vernetzung und immer kürzer werdende Produktlebenszyklen, sind sie aber zunehmend in den Fokus der Betriebswirte und Unternehmensberater gerückt, weshalb der Begriff an dieser Stelle kurz definiert werden soll. Geschäftsprozesse können als Ablauf entlang einer direkt auf den Markterfolg ausgerichteten Wertschöpfungskette des Unternehmens verstanden werden. Kernelement sind ein messbarer Input und Output sowie eine Wertschöpfungskette (vgl. Gierhake, 1998, S. 14). Stahlknecht und Hasenkamp (Stahlknecht und Hasenkamp, 2004, S. 2) erweitern bzw. verfeinern diesen Ansatz noch wie folgt: Es handelt sich um Routinevorgänge und nicht um kurzfristige Projekte. Es existiert ein Auslöser, z. B. Beschwerde eines Kunden. Es ist ein Ergebnis vorhanden, z. B. Sendung der reparierten Ware. Die Aktivitäten werden parallel, sequentiell, alternativ oder wiederholt ausgeführt 8

18 2.2 Geschichte der GPM Die Abläufe sind organisationseinheits- oder ggf. gar unternehmensübergreifend. Dabei sind Geschäftsprozesse oft in Teilprozesse unterteilbar, welche wiederum aus mehreren Prozessen bestehen. Sind diese nicht sinnvoll weiter zerlegbar, spricht man von Elementarprozessen (vgl. Pohanka, 2009, S. 5). 2.2 Geschichte der GPM Die Entwicklung der GPM aufzuzeigen, bedeutet die Geschichte des Geschäftsprozessmanagements genauer zu analysieren. Idee hierbei ist die effiziente Steuerung und Kontrolle der Unternehmensprozesse. Dieser Wunsch hat seinen Ursprung in den Gedanken und Theorien von Frederick Winlow Taylor (vgl. Taylor, 1903, 1911). Nach Taylor ist die Grundlage effektiver Arbeit eine präzise Führung durch das Management. Daraus leitete er ab, dass Arbeitsschritte klein und übersichtlich sein müssen. Dieser Gedanke ist die Basis für die Disziplin der GPM (vgl. Heuermann, 2005, S. 13). Seit jenen Anfängen der GPM bzw. des Geschäftsprozessmanagements sind nach Christian Heuermann (vgl. Heuermann, 2005, S ) drei große Entwicklungswellen zu erkennen: I. Aus den oben geschilderten Anfängen entstanden in den 1920er Jahren Methoden und Prozeduren für die Analyse von Arbeitsabläufen und Prozessen im Unternehmen. Die er Jahre waren gekennzeichnet durch die Einführung eines Qualitätsmanagements sowie von Datenbankmanagementsystemen. II. Die zweite, viel kürzere Welle erstreckte sich von ungefähr Anfang der 1990er bis zum Beginn der 2000er Jahre. Sie war geprägt durch den Gedanken des Reengineerings als Managementansatz (vgl. Hammer, Champy, 2003), das Aufkommen des Enterprise Ressource Plannings, unterstützt durch Software wie dem SAP R/3, und der Entstehung des IT- Konzepts verteilter Rechner und Anwendungen. 9

19 2.3 Grundlegende Aspektee der GPM III. Aktuell befinden wir uns in der dritten Welle. In ihr ist seit Anfang der 2000er Jahre eine merkliche Fokussierung auf die Agilität von Geschäftsprozessenn sowie deren gesamtenn Lebenszyklus festzustellen. Der Lebenszyklus erstreckt sich dabei vom GeschäftsprG rozessmodell, über die Steuerung der neuen/geänderten Prozesse, bis hin zur Analyse der Ergebnisse (vgl. Loos et al., 2010, S. 3). Abbildungg 1: Lebenszyklus von Geschäftsprozessen (vgl. Schmidt er al., 2009, S.. 53) 2.3 Grundlegende Aspekte der GPM Wie der Begriff GPM schon impliziert, geht es in dieser Disziplin um die Modellierung von Geschäftsprozessen. Da sie, wie w in Abschnitt 2.1 erläutert, aus Input, Output und organisationseinheitsübergreifenden Aktivitäten bestehen, sind bei der Modellierung mehrere Aspekte zu berücksichtigen. Eine Möglichkeit dies zu tun, ist die GPM in die Teilbereiche Prozessmodellierung, Objektmodellierung und Organisationsmodellierung zu untergliedernn (vgl. Schönthaler et al., 2010, S ). 10

20 2.3 Grundlegende Aspektee der GPM Im Rahmen derr Prozessmodellierung, auch Ablaufmodellierung genannt, werden die unterschiedlichen Prozesse eines Unternehmens abgebildet und den Aktivitä- ten Ressourcen (menschliche oder maschinelle) zugeordnet. Dabei steht die Pro- zessmodellierung im Zentrum der GPM (vgl. Schönthaler S et al., 2010, S. 29 u. 32). Dies unterstreicht auch eine 2009 durchgeführte Marktrecherche zum Thema Modellierungswerkzeuge: In der vorliegendenn Recherchee liegt der Fokus der Tools überwiegend auf derr Prozessmodellierung (vgl. Eggert, Meier, 2009). Ab- bildung 2 zeigtt den starkk vereinfachten Ablauff einer Bestellabwicklung. Dabei werden Input und Output durch rot ausgefüllte Kreise K und Aktivitäten durch blau hinterlegte Rechtecke repräsentiert (vgl. Abschnitt 2.4.4). Abbildung 2: Einfaches Ablaufdiagramm (Eigene Darstellungg mit dem Horus Business Modeler) Die Objektmodellierung beschäftigt sich mit der Darstellungg der in den Prozessen beteiligten Objekte. Bezogen auf unser obiges, sehr s einfaches Beispiell wären das Auftrag, Ware und Packet,, aber auch der Kunde,, der den Auftrag erteilt. Die Dar- stellung kann, wie in Abbildung 3 geschehen, in einem Objektdiagrammm erfolgen. Abbildung 3: Objektmodell des Auftragsprozesses (Eigene Darstellung mit Horus Business Modeler) 11

21 2.4 Prozessmodellierungssprachen Die Organisationsmodellierung bildet die Organisation des Unternehmens ab. Dabei ist die Geschäftsführung die höchste Ebene, unter der Bereiche wie Produktion oder Logistikk folgen. Zur Darstellung bietett sich ein klassischess Organigramm an. Abbildung 4 zeigt den Zusammenhang zwischen ablaufenden n Prozessen und der Organisation. Abbildung 4: Organisationsstruktur und Prozessabläufe (vgl.. Schönthaler et al., 2010, S. 31) 2.4 Prozessmodellierungssprachen Wie bereits erläutert, kommt Geschäftsprozessen sowiee ihrer kollaborativen Gestaltung, insbesondere in Form von Prozessmodellen,, eine immer größeree Bedeutung zu. Hier soll die Prozessmodellierungssprache die Basis darstellen, auf der sich alle Herangehens- beteiligten Fachbereiche, mitt ihrer ansonsten spezifischen und Ausdrucksweise, verständigen. So können einee unmissverständliche Kommunikation undd die Abstraktion von gruppenspezifischen Herangehensweisen gelingen (vgl. Schönthaler et al., 2010, S. 3-4). Im Folgenden wird der Begriff Prozessmodellierungssprache näher erläutert. Dazu erfolgt zunächst ein Überblick über die verfügbaren Sprachen, bevor anschließend mit ereignisgesteuerten Prozessketten, der Business Processs Model and Notation, sowie Petri-Netzen die wohl w wichtigsten Vertreter näher vorgestellt werden. 12

22 2.4 Prozessmodellierungssprachen Überblick Bis heute existiert kein einheitlicher Standard, weder in Form von Normen noch de facto, sondern finden sich am Markt zahlreiche Prozessmodellierungssprachen unterschiedlicher Formalisierungsgrade (vgl. Mehnert, 2010, S. 12). Nach Mendlin und Nüttgens (2003) sind ereignisgesteuerte Prozessketten ((e)epk), Petri-Netze und UML-Aktivitätsdiagramme (Unified Modeling Language) dabei die am weitesten verbreiteten Sprachen (vgl. Mendlin, Nüttgens, 2003) kam dann mit der Business Process Modeling Notation (BPMN; seit 2010 steht BPMN für Business Process Model and Notation) eine weitere Sprache auf den Markt, die große Akzeptanz fand (vgl. Schmelzer, Sesselmann, 2007, S. 234; vgl. Heuermann, 2005, S. 16). Dahinter steht die Object Management Group (OMG), ein Konsortium zur Entwicklung von Standards für die herstellerunabhängige, systemübergreifende, objektorientierte Programmierung und Urheber der UML- Aktivitätsdiagramme. Der BPMN wird von einigen Autoren zugetraut in Zukunft auf Grund ihrer weiten Verbreitung zum de facto Standard zu werden (beispielsweise: vgl. Allweyer, 2009, S.9; vgl. Mehnert, 2010, S. 12). 13

23 2.4 Prozessmodellierungssprachen Tabelle 1 strukturiert die Fülle an Prozessmodellierungssprachen nach dem Formalisierungsgrad und gibt die grundsätzlichenn Eigenschaften wieder. Tabelle 1: Modellierungssprachenn (vgl. Stub, 2008, S.34; Eigene Darstellung) 14

24 2.4 Prozessmodellierungssprachen (e)epk Die (e)epk entstand unter Leitung von Prof.. Scheer ann der Universität des Saarlandes in Saarbrücken n und ist Teil des ARIS-Konzepts zur GPM (Scheer, 1998). Kernelemente sind Ereignisse und Funktionen sowie die logischen Konnektoren UND, ODER, XOR (entweder oder) mittels derer parallele sowie alternative Abläufe modelliert werden können. Abbildung 5: EPK Symbolik (gemäß ARIS Express) Funktionen werden dabei als Aktivitäten verstanden, die ausgeführt werden müssen, um einen gewissen Zustand zu erreichen. Ein Ereignis ist in Anlehnung an die DIN das Eintreten eines gewissen Zustands, wodurch weiteree Aktivitäten notwendig werden (vgl. Wehrmaker, 2007, S ). Daher folgen in (e)epks auf Funktionen immer Ereignisse und umgekehrt. Dieser Zwang führt allerdings dazu, dass viele Ereignisse modelliert werden müssen, die nicht zur Erläuterung derr Geschäftsprozesse beitragen (vgl. Palluch, Wentzel, 2008, S. 2). Andererseits erhöht die so erzwungene klaree Struktur die Übersichtlichkeit, weshalb (e)epks sehr einfach auf Vollständigkeit geprüft werden können. Dabei sind die Abläufe trotzdem sehr genau und präzise darstellbar (vgl. Bundesinstitutt für Berufsbildung, 2005). Der Zusatz erweitert beschreibt die Möglichkeit für jedee Funktion die involvierten Informationsobjekte und Organisationseinheiten zu modellieren (vgl. Palluch,, Wentzel, 2008, S. 3). Abbildungg 6 zeigt eine (e)epk am Beispiel eines (vereinfachten) Bestellabwicklungsprozesses. 15

25 2.4 Prozessmodellierungssprachen Abbildung 6: Bestellabwicklungsprozesses mit einer (e)epk (Eigene( Darstellung mit ARIS Express) BPMN BPMN wurde von einem Konsortium, vorwiegend zusammengesetzt aus Vertretern von Softwareherstellern der Business Process Management Initiative (BPMI), entwickelt. Diesee ging in der OMG auf. Die erste Version von BPMN erschien dann unter Leitung von IBM im Jahre 2004 (vgl. Allweyer, 2009, S. 10). BPMN ist ursprünglich eine rein grafische, semi-formale Modellierungssprache mit vier Elementkategorienn (vgl. Palluch, Wentzel, 2008, S.. 3; vgl. Stub, 2008, S. 34): Ablaufobjekte (Ereignisse, Aktivitäten, VerzweigungV gen) Verbindungsobjekte (Ablauffluss, Nachrichtenfluss, Verbindungen) Artefakte (Datenobjekt, Gruppe, Anmerkung) Schwimmbecken, Schwimmbahnen (Trennlinien) BPMN bestichtt dabei besonders durch seine Übersichtlichkeit und die klare Zu- ordnung von Verantwortli ichkeiten für Prozesse, nicht zuletzt aufgrund der Nut- zung von Schwimmbeckenn (Pools) und Schwimmbahnen (Swimlanes) (vgl. Meh- nert, 2010, S. 11). Ein Pool ist als ein Behälter anzusehen, in dem ein gesamter Prozess abgebildet wird (vgl. Allweyer, 2009, S. S 17). Swimlanes unterteilen den 16

26 2.4 Prozessmodellierungssprachen Pool in mehreree Bahnen, wobei jede den Verantwortungsbereich eines Beteiligten (Abteilung, Posten, Service) repräsentiert (vgl. Wehrmaker r, 2007, S. 14). In Ab- bildung 7 wurde das schon bekannte Beispiel einer Bestellabwicklung mit der BPMN modelliert. Abbildung 7: Bestellabwicklungsprozess mit BPMN (Eigene Darstellung D mit Aris Express) Aufgrund des grafischen Fokus erweist sich die rechnergestür tützte Verarbeitung der Modelle grundsätzlich als schwierig. Helfenn können hier jedoch weiteree Metasprachen, wie die Business Process Execution Language (BPEL), auf die BPMN, mit einigem Aufwand, abgebildet werden kann (vgl. Allweyer, 2009, S. 14; vgl. Palluch, Wentzel, 2008, S. 3) ). Außerdemm ist an dieser Stelle anzumerken, dasss mit der jüngsten Version, BPMN 2.0, zumm einen die Abbildung auf BPEL erleichtert wird und zum anderen die Möglichkeit besteht, BPMN-Modelle bzw. die dort abgebildeten Prozesse direkt auszuführenn (vgl. Allweyer, 2009, S.14). Ein weiterer Kritikpunkt ist zuweilen die begrenzte Abstraktionsmöglichkeit. Daraus leitet sich derr Vorwurf ab, dass der Nutzer zu sehr in Implementierungsdimensionen denken muss und u daher in seiner Kreativitätt eingeschränkt wird (vgl. Schönthaler et al, 2010, S. 6). 17

27 2.4 Prozessmodellierungssprachen Petri-Netze Petri-Netze verdanken ihren Namen dem Mathematiker Prof. Carl Adam Petri. Schon 1962 legte er mit seiner Dissertation Kommunikation mit Automaten den Grundstein (vgl. Moldt, 2010, S.1; vgl. Petri, 1962). Während seiner Zeit als Leiter des Forschungs instituts der Gesellschaft für Mathematik und Datenverarbeitung in Bonn-Birlinghoven entwickelte er dann zusammen mit seinem Team die Idee der Petri-Netzee weiter (vgl. Grude, 2005, S.3). Petri-Netze sind klar strukturiert und einfach aufgebaut (vgl. Moldt, 2010). Gibt es bei BPMN mehr als 600 unterschiedliche Elemente, so sind es bei Petri-Netzen lediglich drei (vgl. Berliner BPM-Offensive, URL; vgl. Schönthaler et al. 2010, S. 32; vgl. Grude, 2005, S. 8) ): Aktivitäten (auch Transitionenn genannt), verkörpert v durch Rechtecke. Objektspeicher (auch Stellen genannt), repräsentiert durch Kreise. Verbindungen zwischen Objektspeichern und Aktivitäten, durch Pfeile (gerichtete Kanten). abgebildet So stellt sich das schon oben genutztee Beispiel eines Bestellabwicklungsprozessess mit Petri-Netzen wie folgt dar: Abbildung 8: Bestellabwicklungsprozesses mit einem Petri-Netz (Eigenes Darstellung mit dem Horus Business Modeler) 18

28 2.4 Prozessmodellierungssprachen Es fällt die einfache, übersichtliche Struktur, bestehend aus den drei oben beschriebenen Elementen, auf. Des Weiteren bemerkt man schnell, dass eine Aktivität und zwei Objektspeicher mit Hilfsaktivität bzw. Hilfsobjekt 1 und 2 bezeichnet sind. Dies ist dem strengen Formalismus von Petri-Netzen geschuldet. Denn die intuitive Darstellung einer Nebenläufigkeit, indem man von einer Stelle zwei Pfeile (gerichtete Kanten) auf je eine Transition zeigen lässt, repräsentiert gemäß der Netztheorie eine Entweder-oder-Beziehung (vgl. Grude, 2005, S. 18). Daher werden die Hilfsaktivität und die daraus hervorgehenden Hilfsobjekte benötigt, um eine Struktur gemäß dem Beispiel zu erzeugen. In der Praxis würde man diesen Elementen natürlich (mehr oder weniger) sinnvolle Namen geben, also Aktivitäten oder Objektspeicher kreieren. Eine andere Lösung wäre, aus der Transition Lagerbestand prüfen zwei Aktivitäten mit den Namen Lagerbestand erfolgreich prüfen bzw. Lagerbestand nicht erfolgreich prüfen zu erzeugen, um so das Problem zu umgehen. Bei beiden Ansätzen fallen die formalen Vorgaben der Sprache dem Betrachter nicht auf, müssen vom Modellierer jedoch trotzdem berücksichtigt werden. Andererseits führt aber eben gerade diese Betonung auf das Formale und die damit verbundene Abstraktion dazu, dass der Nutzer nicht in implementierungstechnischen oder anderen Bahnen denkt (wie einige z. B. bei BPMN befürchten, siehe Abschnitt 2.4.3). Vielmehr nähert er sich dem Problem sozusagen von oben, also mit der größtmöglichen Fokussierung auf die Prozesse selbst. Im Unterschied zu den semi-formalen Sprachen BPMN und EPK repräsentieren Petri-Netze eine formale Sprache (vgl. Abschnitt 2.4.1). Daher kann jedes Netz rein mathematisch beschrieben werden. Abbildung 9 soll dies verdeutlichen. Sie zeigt, wie ein Petri-Netz als Matrix dargestellt werden kann. Jede gerichtete Kante (Pfeil) von einer Aktivität (Rechteck) zu einem Objektspeicher (Kreis) ist (in diesem einfachen Beispiel) mit einer 1, im umgekehrten Fall mit einer -1 wiedergegeben. 19