Benutzer:Birkenkrahe/HWR-MBA-BIS-INTM/BPM modelling

MBA – International Management (Dual Award)
Business Information Systems
Prof. Birkenkrahe
LV-Nr.: 810003

Gruppenhausarbeit
„Modellierung und Optimierung eines Software-Release-Prozesses unter der Verwendung von BPMN 2.0“

Einleitung

Motivation und Zielsetzung der Arbeit

Einflussfaktoren, wie zum Beispiel Konkurrenzdruck durch Open Source Bewegungen, sorgen dafür, dass die Bedeutung der Geschäftsmodelle in den Softwareunternehmen stetig ansteigt [Quelle - selber]. Um auf lange Sicht Konkurrenzfähig zu bleiben, sind die Unternehmen deshalb dazu angehalten, die Effektivität und Effizienz ihrer Prozesse stetig zu überprüfen und zu steigern sowie ihre Kosten zu senken [Quelle - selber ]. Aus diesem Grund werden effektive Geschäftsprozesse und das damit verbundene Geschäftsprozessmanagement (im Folgenden auch als Business Process Management bezeichnet) zunehmend als Schlüsselfunktionen für Wettbewerbsfähigkeit gesehen und nehmen in der unternehmerischen Praxis einen immer höheren Stellenwert ein [Seethamraju, 2012]. Zu den wichtigsten Geschäftsprozessen eines Softwareunternehmens gehört das Releasemanagement. "Das Releasemanagement ist ein Prozess, der sich ursprünglich aus den Erfahrungen des Produktmanagements der Software-Industrie entwickelte, welches die Bündelung von Konfigurations-Änderungen zu einem Release oder Versionspaket und deren ordnungsgemäße Eingliederung in der Infrastruktur sicherstellt" [wikipedia.org, 2013]. Lapidar ausgedrückt ist das Release-Management ein Prozess, durch den Software ihren Benutzern zur Verfügung gestellt wird. Folglich ist das Releasemanagement die Planung, Durchführung und Qualitätssicherung der Veröffentlichung, von der Idee bzw. den ersten Anforderungen bis zum Erreichen des Endbenutzers [...]. Für Softwareunternehmen ist es deshalb von essentieller Bedeutung ein gutes Releasemanagement in seine Geschäftsprozesse zu integrieren, da in diesem Prozess nicht nur die Aktualität, somit die Wettbewerbsfähigkeit des Produkts generiert wird, sondern auch die Qualität der Software überprüft wird. [quelle?]
Ziel der vorliegenden Arbeit ist es, zu untersuchen, ob durch die Modellierung des Release-Prozesses eines ausgewählten mittelständischen Softwareunternehmens Schwächen, bzw. Einsparungspotentiale identifiziert werden können.

Aufbau der Arbeit (Vorgehensweise)

Entsprechend der oben formulierten Zielstellung ist die Arbeit in zwei Teile gegliedert. Zur Erfüllung der gesetzten Ziele der Studienarbeit werden im ersten Abschnitt zunächst die notwendigen Grundlagen vermittelt. In diesem Teil werden die Begrifflichkeiten zu BPMN näher beschrieben, die Argumente für den Einsatz der BMPN-Modellierung im Gegensatz zu anderen Notationen kurz aufgezeigt und anschließend die wichtigsten Modellierungsbausteine von BPMN vorgestellt.
Ausgehend von diesen Kenntnissen wird im zweiten, praktischen Teil der Arbeit die Modellierung eines Software-Release-Prozesses beschrieben und anschließend auf Optimierungsmöglichkeiten überprüft. Basis für die Modellierung des Release-Prozesses ist das "Product-Release-Sheet für Major- und Minor-Releases" eines mittelständischen Softwareunternehmens. Das Product-Release-Sheet (siehe Anhang) organisiert den gesamten Release-Prozess von der Build-Fertigstellung bis zur Release-Auslieferung. Das abschließende Fazit beurteilt die bearbeitete Thematik und gibt Aufschluss darüber ob die Forschungsfrage auch beantwortet wurde.

Was ist Business Process Model and Notation (BPMN)

Definition und Ziele von BPMN

BPMN wurde seitens der Business Process Management Initiative (BPMI) mit dem Ziel einer grafischen Notation zur Darstellung von Prozessbeschreibungen entworfen [Objekt Management Group (OMG), 2011]. Da BPMI in der Object Management Group (OMG) aufgegangen ist, liegt die BPMN-Weiterentwicklung heute in ihrem Verantwortungsbereich. Die erste Version wurde 2004 veröffentlicht. Die derzeit gültige Version 2.0 ist seit Januar 2011 gültig. BPMN ist eine sogenannte Spezifikation, die in Form eines ca. 500 Seiten umfassenden englischsprachigen Dokuments (Open Source) von der Webseite der OMG heruntergeladen werden kann. BPMN ermöglicht das grafische Modellieren von Geschäftsprozessen in einer standardisierten und nahezu vollständigen Notation aus betriebswirtschaftlicher Sicht [Dr. Becker, Mathas, & Winkelmann, 2009]. Die Notation hat den Anspruch, zum einen Prozessmodelle unabhängig vom verwendeten Modellierungswerkzeug für Geschäftsanalytiker leicht lesbar und verständlich zu machen, wie auch aufgrund seiner Mächtigkeit sehr komplexe Geschäftsprozesse abzubilden. Die Spezifikation zur BPMN definiert alle Symbole sowie die Regeln, nach denen sie kombiniert werden dürfen, um graphische Prozessmodelle zu erstellen. Sie regelt damit die Syntax und auch die Semantik. Die Syntax ist das System an Regeln, wie die Symbole kombiniert werden dürfen. Die Semantik legt die Bedeutung von Symbolen und ihren Beziehungen fest [vgl. Mertens, 2010]. Das Hauptziel der BPMN ist folglich die Bereitstellung einer Notation, die für sämtliche Nutzer sofort verständlich ist [Kocian, 2011]. Damit stellt BPMN eine standardisierte Brücke zwischen dem Geschäftsprozessdesign und der Prozessimplementierung dar [Trambo, 2010].
Im Original: „The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.” [Object Management Group (OMG), 2008]

Warum BPMN?

Immer mehr Organisationen und Unternehmen setzen BPMN ein. BPMN ist ein sogenannter Newcomer in der Community der Prozessmodellierung. Für Außenstehende stellt sich die legitime Frage, weshalb eine zusätzliche Notation, neben der Unified Modelling Language (UML) und der Ereignisgesteuerten Prozesskette (EPK) für die Modellierung von Geschäftsprozessen benötigt wird. Diese Frage lässt sich ohne tiefergehende technische Analyse anhand von drei festgelegten Parametern relativ einfach erklären:

1. Zielgruppen der Notationen:
Das primäre Ziel der BPMN ist es laut Spezifikation eine Notation bereitzustellen, die ohne weiteres verständlich ist für alle Teilnehmer im Geschäftsprozessmanagement. Während manche Fachabteilungen einfache Flussdiagramme verwenden, nutzen zumeist Informatiker UML. Im Bereich der fachlichen Modellierung ist hingegen EPK relativ weit verbreitet. Allerdings ist zu beachten, dass es sich hierbei um keinen Standard handelt und die Akzeptanz auf der IT-Seite oft nicht gegeben ist. BPMN bietet im Gegensatz zu den Notationen UML und EPK eine durchgängige Modellierung in einer Notation, die ausreichend verständlich für die Fachabteilung und auch ausreichend präzise für die technische Umsetzung ist. Somit ist BPMN sowohl für Fachabteilungen wie für IT-Abteilungen geeignet.

2. Eignung als Standard:
BPMN gehört keinem bestimmten Unternehmen, sondern wie im vorherigen Punkt bereits kurz erwähnt einer Institution (OMG), die bereits andere Standards wie UML weltweit etabliert hat. EPK wurde 1992 von einer Arbeitsgruppe unter Leitung von Prof. August-WIlhelm Scheer von der Universität des Saarlandes im Auftrag für die SAP AG entwickelt. Gegenüber der BPMN-Modellierung fehlt der EPK-Methode dadurch die weltweite Standardisierung durch eine entsprechende Organisation, wodurch der Bekanntheitsgrad außerhalb des deutschsprachigen Raumes geringer ausfällt.

3. Einfachheit und Übersichtlichkeit:
Auch wenn sich ohne vorherige BPMN-Kenntnisse noch nicht gleich ein BPMN-Diagramm modellieren lässt, so kann ein Benutzer ohne Vorkenntnisse ein einfaches Diagramm ohne Probleme verstehen. Die BPMN-Modellierung besitzt weiterhin den Vorteil, dass die Grundelemente (siehe Kapitel 2.3) weitgehend den Flussdiagrammen entsprechen, die bereits viele Benutzer von anderen Softwareprogrammen kennen. Die Anzahl der Bausteine, als Indiz der Übersichtlichkeit, sind in BPMN und EPK annähernd gleich viel. Eine große Abweichung besteht hingegen im Vergleich zu UML. In UML gibt es viel mehr Arten der Modellierung, die Sprache ist aus diesem Grunde relativ komplex und ist auf objekt-orientierte Programmiersprachen ausgerichtet.

Modellierungsbausteine

Um einen Prozess in BPMN lesen und verstehen zu können, muss man die Modellierungsbausteine eines Geschäftsprozessdiagramms kennen. Eine Übersicht über die Auswahl von Modellierungsbausteinen, ihre Wirkungsweisen und Auswirkungen auf den Prozessfluss, wird in diesem Abschnitt kurz beschrieben. Zu beachten ist, dass in dieser Arbeit eine eingeschränkte Symbolpalette vorgestellt wird, die sich aber trotz Kürze für die Erstellung von fachlichen Modellen eignet. Im Kern der BPMN-Modellierung stehen Prozessdiagramme [Stiehl, 2013]. Sie werden auch als Business Process Diagrams bezeichnet. Sie legen grafisch fest, in welcher Reihenfolge, unter welchen bestimmten Bedingungen und zu welchem Zeitpunkt eine Tätigkeit auszuführen sind, wobei es stets zu Ausnahmen kommen kann, deren Behandlung bei der Modellierung ebenfalls zu berücksichtigen sind.

Zur grafischen Umsetzung der genannten Eigenschaften von Business Process Diagrams sieht die BPMN fünf Kategorein von Kernelementen vor:

Flow Objects (Flussbausteine): Sie stellen die grafischen Hauptelemente von BPMN dar und definieren das Verhalten eines Prozesses. Hierbei lassen sich drei Flussobjekte gegeneinandere abgrenzen:
Activities (Aktivitäten) sind dargestellt als Rechtecke mit abgerundeten Ecken. Activities sind Aufgaben oder Teil- und Unterprozesse (Subprocesses), die in einem Geschäftsprozess zu erledigen sind. Tasks (Aufgaben) sind die elementaren Activities, komplexere Activities werden als Subprocess bezeichnet. Sie unterscheiden sich in der Notation durch das +-Symbol (siehe Abbildung 1). Subprocesses können in kollabiertem und expandiertem Zustand modelliert werden.

• 

Abbildung 1: Beispielprozess in Signavio

Gateways (Entscheidungspunkte) sind Verzweigungen, Gabelungen, Zusammenführungen und Verbindungen von Prozessflüssen. BPMN unterscheidet fünf Gateways, die innerhalb von Prozessen und zwei Gateways, die zum Start von Prozessen eingesetzt werden.

• 

Abbildung 2: Beispiele für Gateways

Events (Ereignisse) beziehen sich auf alles, was sich in einem Geschäftsprozess ereignen kann. BPMN besitzt eine Vielzahl von unterschiedlichen Ereignissen und ist damit bestens geeignet, um auf unterschiedliche Situationen mithilfe von Ereignissen reagieren zu können. Die wichtigsten Ereignisse sind das Start-, Intermediate- und End-Event (siehe Abbildung 3). Daneben gibt es Events, die zum Beispiel das Eintreffen einer Nachricht, das Erreichen eines bestimmten Datums oder das Auftreten einer Ausnahmesituation aufzeigen.

• 

Abbildung 3: Beispiele für Events

Data (Daten): Hier handelt es sich um Informationen, die innerhalb eines Prozesses verarbeitet oder zwischen verschiedenen Prozessen ausgetauscht werden. Hierunter findet man folgenden fünf Elemente:

Data Objects (Datenobjekte) repräsentieren Informationen, die durch den Prozess laufen, z.B. Dokumente, Briefe oder E-Mails. Datenobjekte liefern Informationen darüber, was Aktivitäten benötigen um ausgeführt zu werden und/oder was sie produzieren. Datenobjekte können einzelne Objekte oder Sammelobjekte darstellen. Dateninput und Datenoutput liefern dieselben Informationen für Prozesse.

Connection Objects (Verbindungsobjekte): Sie erlauben die Verbindung der Flussobjekte miteinander. Die folgenden vier verbindenden Objekte sind hier zu unterscheiden:

Sequence Flows (Sequenzfluss) bestimmen die Reihenfolge, in welcher die Aktivitäten in einem Prozess ausgeführt werden. Sie verbinden Activities, Gateways und Events.

Message Flows (Nachrichtenfluss) dient der Darstellung des Informationsaustausches zwischen zwei Teilnehmern z.B. Pools oder Lanes. Message Flows verbinden Lanes, Pools oder Flow Objects nur temporär miteinander.

Associations (Assoziationen) verbinden Informationen und Artefakte mit den graphischen BPMN-Elementen. Textanmerkungen und Artefakte können mit den graphischen Elementen verknüpft werden. Eine Pfeilspitze an einer Assoziation deutet z.B. die Flussrichtung von Daten an.

Swim Lanes (Schwimmbahnen): Durch Sie werden die zuvor genannten primären Modellierungselemente gruppiert. Dazu gibt es zwei Arten der Gruppierung:

Pools (Becken) repräsentieren Rollen. Ein Pool repräsentiert eine Organisation oder einen Teilnehmer in einem Workflow, das heißt einen Benutzer bzw. eine Benutzerrolle oder ein System. Lanes (Bahnen) repräsentieren Verantwortlichkeiten, wie z.B. Organisations-einheiten, Stellen oder sogar IT-Systeme. Lanes können hierarchisch untergliedert sein. Eine Lane ist eine Unterteilung eines Pools, die sich über die komplette Länge des Pools erstreckt.

Artifacts (Artefakte): Artefakte werden verwendet um zusätzliche Informationen über den Prozess zu geben. Es gibt zwei standardisierte Arten von Artefakten. Die Modellierer oder die Modellierungstools haben aber die Freiheit so viele Artefakte hinzuzufügen wie notwendig. Es gibt derzeit folgende Artefakte:

Groups (Gruppe) unterstützen den Modellierer bei der visuellen Zusammenfassung von Elementen eines Geschäftsprozesses. Eine Gruppierung hat dabei keinerlei Einfluss auf den Prozessfluss in der jeweiligen Gruppe.

Text Annotations (Textanmerkungen) sind Kommentarmöglichkeiten, die Elementen von Geschäftsprozessen zugeordnet werden können. Sie geben dem Modellierer die Möglichkeit dem Leser des BPMN-Diagramms zusätzliche Informationen bereitzustellen.

Geschäftsprozessmodellierung

In diesem Abschnitt wird der in der Einleitung bereits erwähnte Release-Prozess erklärt und anschließend modelliert. Vorab wird kurz das betriebliche Umfeld beschrieben.

Ermittlung der Ist-Situation

Betriebliches Umfeld

Der in dieser Arbeit beschriebene Release-Prozess gehört einem mittelständischen Software-Hersteller. Das Unternehmen existiert seit 9 Jahren und beschäftigt derzeit ca. 43 Mitarbeiter, die sich auf folgende Bereiche aufteilen:

• Research & Development (RND)
• Product Related Services (PRS)
• Product Management (PMA)
• Quality Management (QM)
• Marketing (MC)
• Sales (SL)
• Online Services (ONL)
• Back Office (BOF)
• Corporate Center (CC)

Die Produkte richten sich momentan ausschließlich an Geschäftskunden und werden direkt, als auch über Geschäftspartner vertrieben. Der inzwischen über 400 Installationen umfassende internationale Kundenstamm setzt sich aus Kunden sämtlicher Unternehmensgrößen und Branchen zusammen.

Beschreibung des Release-Prozesses

Der Release-Prozess ist die Phase zwischen Fertigstellung und Veröffentlichung von neuen Softwareversionen. Vor der Herausgabe neuer Software müssen verschiedene Prozessschritte durchlaufen werden. Diese Schritte werden in einem "Product-Release-Sheet" dokumentiert. Das "Product-Release-Sheet" ist eine Excel-basierte Checkliste, die dazu beiträgt, dass der Release-Prozess akkurat durchgeführt wird, also keine Schritte übersprungen werden.

Initialisierungsphase Die Initialisierungsphase beginnt mit dem Codefreeze, also dem Zeitpunkt, an dem ein Entwickler (RND) ein Softwarepaket fertiggestellt hat und folglich keine weiteren Funktionen einarbeiten wird. Ein Entwickler startet diese Phase selbständig, in dem er damit beginnt, die erste Seite des "Product-Release-Sheets" auszufüllen. Neben allgemeinen Daten zu der produzierten Softwareversion muss er bestätigen, für den weiteren Prozess notwendige Vorarbeiten erledigt zu haben. Sollten diese Arbeiten noch nicht getan sein, gilt es dies nachzuholen und dies entsprechend in der Checkliste zu vermerken. Nachdem alle notwendigen Tätigkeiten erfolgt sind, schickt der Entwickler eine BenachrichtungsE-Mail an PMA, den für den Gesamtprozess organisatorisch verantwortlichen Bereich (Process Owner).

GUI-Usability Testphase Nachdem PMA von RND informiert wurde, dass eine neue Softwareversion zur Veröffentlichung bereitsteht, muss eine Abnahme möglicher GUI- (Graphical User Interface) Änderungen durch PRS erfolgen. PMA beauftragt diesen Test via E-Mail. Zusammen mit dem jeweiligen Entwickler werden mögliche Unzulänglichkeiten in der GUI beseitigt. Anschließend installiert PRS die neue Software auf dem eigenen Online-Demosystem und erteilt die Freigabe für die GUI. PMA kann daraufhin den finalen Qualitätstest bei QM in Auftrag geben.

Finaler Quality Test Nachdem PRS die Freigabe für die GUI erteilt hat, findet ein finaler Qualitätstest statt. In Interaktion mit dem jeweiligen Entwickler werden mögliche Fehler behoben. Anschließend wird die Software von QM für die Veröffentlichung freigegeben. QM versendet dazu eine Benachrichtigung an PMA.

Interne Organisationsphase In der abschließenden Organisationsphase führt PMA interne Trainings für die Bereiche MC, SL und PRS durch. Neuigkeiten in den Produkten müssen schließlich vor der Veröffentlichung der Bereiche, die mit ihnen in Berührung kommen, vermittelt werden. Ausserdem wird die sogenannte Release-History, eine von RND geführte Datei, die Änderungen in den Produkten dokumentiert und im Produkt hinterlegt ist, von PMA inhaltlich und sprachlich überarbeitet, bzw. freigegeben. Desweiteren werden von PMA Kunden- und Partnerinfoletter vorbereitet und für die Weiterverarbeitung und den Versand an MC geschickt. MC hat dann die Verantwortung die Neuigkeiten der Software nach außen zu kommunizieren. Dazu gehören ggf. auch Anpassungen der Website. Abschließend kann die Software von PRS im eigenen Produktivsystem installiert und den Kunden auf Download-Servern zur Verfügung gestellt werden. Auch dieser letzte Schritt wird von PMA beauftragt.

Nachfassen PMA kontrolliert anschließend noch, ob alle Tätigkeiten wie gewünscht ausgeführt wurden und kommuniziert intern, ob das Release erfolgreich war oder z.B. aufgrund von mangelhafter Qualität gestoppt werden musste.

Der gesamte Release-Prozess kann bis zu 4 Wochen dauern. Ein genauer zeitlicher Ablauf ist nicht vorherzusagen. Die Durchführungsdauer hängt stark von variierenden Faktoren ab, wie z.B. dem Softwareumfang, der Anzahl gefundenener Fehler durch QM, den zu kommunizierenden Themen in Infolettern, etc..

Modellierung des Release-Prozesses mit Signavio

Der Release-Prozess wird mit dem Signavio Process Editor modelliert. Der Web-basierte Editor wurde von der gleichnamigen Softwarefirma Signavio aus Berlin für die Modellierung von Geschäftsprozessen entwickelt. Der Editor ermöglicht es Prozessdiagramme in BPMN zu erstellen. Als Vorlage für die Modellierung dient das Product-Release-Sheet. Der modellierte Prozess findet sich im Anhang bzw. im Diskussionsforum des BIS-Kurses in Moodle.

Schwachstellenanalyse der Ist-Situation und Optimierungsansätze

Im Folgenden wird der Release-Prozess auf mögliche Schwachstellen untersucht. Es wird unter anderem überprüft, ob Vereinfachungen von Prozessschritten möglich sind und ob es Optimierungspotential, zum Beispiel in der Interaktion zwischen den beteiligten Bereichen, gibt. [Quelle-vorhanden]. Die Modellierung des Release-Prozesses zeigt einige Schwachstellen und Optimierungsansätze auf: Zum einen scheint es schwierig, genaue Release-Termine zu planen, da die genaue Dauer des Prozesses aus den weiter oben beschriebenen Gründen nicht vorherzusagen ist. Einzig der Codefreeze-Zeitpunkt scheint akkurat planbar zu sein. Oftmals warten Kunden auf die Veröffentlichung neuer Softwareversionen. Es werden dann unter Umständen Termine nach außen kommuniziert, die aufgrund von Verzögerungen im Release-Prozess nicht gehalten werden können. Ein verschlankter Release-Prozess könnte an dieser Stelle für bessere Planbarkeit und damit zufriedenere Kunden sorgen. Eine Möglichkeit den Release-Prozess zu verkürzen, wäre die Eliminierung von unnötigen Schnittstellenaktionen. Diese gibt es insbesondere im Bereich PMA. Dieser ist als Process Owner zwar für das Gelingen des Releases verantwortlich, schaltet sich aber teilweise scheinbar unnötig in die Kommunikation ein. So werden in einigen Phasen Nachrichten im Prinzip weitergeleitet. Die direkte Kommunikation zwischen den aktiv beteiligten Bereichen würde hier eine deutliche Zeitersparnis bedeuten. Allerdings müsste sichergestellt sein, dass die Kommunikation stattfindet, damit der Prozess nicht ins Stocken gerät. Eine weitere Schwachstelle im derzeitigen Prozess sind sogenannte Feedbackschleifen. Nach der Ausführung bestimmter Aufgaben, müssen die ausführenden Bereiche ein Feedback an den Auftraggeber (PMA) zurücksenden. Dieses Feedback könnte man unter Umständen aufsparen, unter der Voraussetzung, dass die verteilten Aufgaben gewissenhaft erledigt werden. Weiterhin werden teilweise einzelne Mails mit Arbeitsaufträgen an denselben Bereich versendet. Hier wäre zu klären, ob eine Zusammenfassung möglich ist. Dies betrifft unter anderem Nr. 500-520 des Product-Release-Sheets.
Ferner ist zu klären, ob der Bereich MC Partner-Infoletter selbst versenden kann. Eine Schnittstelle zu ONL und damit ein Fehlerrisiko könnte dadurch wegfallen. Teilweise scheinen Prozesschritte entstanden zu sein, die man heute anders gestalten würde. So ist es zum Beispiel historisch bedingt, dass ONL sämtliche Infoletter versendet. Dies entwickelte sich dadurch, dass MC zeitweise unterbesetzt war. Es wird an dieser Stelle bereits deutlich, dass durch die Modellierung Schwachstellen und damit auch Optimierungspotentiale aufgedeckt werden und dass Ziel der Studienarbeit demnach erreicht wurde. Die Analyse ergibt, dass in der aktuellen Situation einige Prozesse durch unnötige Arbeit verzögert, bzw. verkompliziert werden. Allerdings muss man auch berücksichtigen, dass man sich selten so intensiv und vor allem ganzheitlich mit Prozessen beschäftigt, wie während der Modellierung. Diese zwingt einen quasi dazu, sich intensiv mit dem Prozess auseinanderzusetzen. Wahrscheinlich würden sich Schwachstellen ebenso offenbaren, wenn man Prozesse nicht modellieren, sondern ausschließlich gedanklich durchdringen würde.

Fazit

In vielen Firmen wachsen Prozesse mit der Zeit. Sie werden in ihrer Gesamtheit selten kritisch hinterfragt. Dabei bietet die Modellierung von Prozessen einige Vorteile. Durch die ganzheitliche Auseinandersetzung können Schwachstellen und Optimierungspotentiale identifiziert werden. Allerdings gilt es, die Prozesse kontinuierlich zu verbessern und das Ergebnis der Modellierung ständig zu hinterfragen.
Wie weiter oben bereits erwähnt, konnten durch die Modellierung auch in unserem Release-Prozess Schwachstellen entdeckt werden. Offen bleibt, wieviel Zeit durch eine Optimierung eingespart werden kann. Ausserdem ist zu klären, ob die unter 3.3 genannten Maßnahmen in der Realität funktionieren würden. Da die Software unterstützte Geschäftsprozessmodellierung jedoch relativ einfach ist und wenig Zeit in Anspruch nimmt , sollte man den Versuch, damit Schwachstellen zu identifizieren, nicht auslassen. Für diese Studienarbeit haben sich dafür die Notation BPMN und der Signavio-Editor bewährt. Bereits nach einer kurzen Einarbeitung in die BPMN Notationselemente konnte mit der Modellierung begonnen werden. Die Bedienung in Signavios Webeditor ist weitestgehend intuitiv und Fehler werden einem gegebenenfalls angezeigt, sofern sie vom System erkannt wurden. Modellierte Prozesse sind in verschiedenen Formaten exportierbar und somit auch ausserhalb von Signavio verwendbar. Durch den Browser-basierten Editor eignet sich Signavio ausserdem für Prozesse, bei denen mehrere Personen an der Modellierung beteiligt sind Neben der Prozess-Modellierung bieten sogenannte Workflow-Management-Systeme (WfMS) enorme Optimierungspotentiale. WfMS sind Software-Produkte, die die Spezifikation, die Ausführung und die Kontrolle von Geschäftsprozessen unterstützen (Ellis and Nutt, 1993; Georgakopoulos et al., 1995; Jablonski and Bussler, 1996). Kürzere Bearbeitungszeiten und weniger Fehler bei Übergaben sind die größten Vorteile. [Quelle - How to increase....] Die Implementierung von WfMS's scheint also die logische Konsequenz einer Modellierung zu sein.

---

Anhang - Reflektion Gruppenarbeit

Die folgende Reflektion beschreibt in Kürze eine vergleichende und prüfende Auseinandersetzung zu den Inhalten und zur Organisation der geschriebenen Studienarbeit. Weiterhin werden die eingesetzten Instrumente zur Erstellung der Studienarbeit kritisch hinterfragt. Die Studienarbeit wurde im Rahmen der Lehrveranstaltung "Business Information Systems" bei Prof. Dr. Birkenkrahe geschrieben. Das Thema der Studienarbeit lautet "Modellierung und Optimierung eines Software-Release-Prozesses unter der Verwendung von BPMN 2.0". Das Thema beschäftigt sich mit der grafischen Abbildung des Release-Prozesses eines mittelständischen Softwareunternehmens in einer modernen Notation. Die Arbeit wurde in einer Kleingruppe geschrieben. Herr Mehmet Özten war für den theoretischen Teil der Arbeit zuständig, Herr Alexander Fechner modellierte den dazugehörigen Geschäftsprozess und schrieb den praktischen Teil.

Kritische Auseinandersetzung mit dem Inhalt und Organisation der Studienarbeit
Eine theoretische sowohl praktische Auseinandersetzung mit dem Thema Geschäftsprozessmanagement war in dieser Tiefe für beide Autoren neu. Bereits im Vorfeld der Auseinandersetzung mit dem Thema wurde den Autoren schnell deutlich, das Geschäftsprozessmanagement und -analyse ein wissenschaftlich ausgereiftes Feld ist. Es wurde auch bewusst, dass das Thema Geschäftsprozessmanagement eigentlich immer ein aktuelles Thema sein wird.
Ziel der Studienarbeit war es durch die Modellierung des Release-Prozesses Schwachstellen aufzudecken und gleichzeitig Optimierungvorschläge zu unterbreiten. Dieses Ziel wurde erreicht. Es wurden bereits beim Modellieren des Geschäftsprozesses Schwachstellen entdeckt und Optimierungsvorschläge gegeben. Jedoch machte die Größe des Release-Prozesses und die limitierte Zeit es leider unmöglich sich tiefer mit dem Geschäftsprozess zu beschäftigen. Erschwerend kam die Limitierung des Umfangs der Studienarbeit auf ca. 3000 Wörter durch die Hochschule hinzu. Für eine Kleingruppe von zwei Personen war das Thema gut geeignet. Die Aufteilung der Studienarbeit fiel den Autoren leicht. Es konnte parallel an dem Thema gearbeitet werden.

Schwer war es für Herr Özten sich in den praktischen Teil von Herr Fechner einzuarbeiten, da wie bereits zuvor erwähnt, der Release-Prozess relativ umfangreich ist. An der Schwachstellenanalyse und den Optimierungsvorschlägen konnte sich Herr Özten dadurch kaum beteiligen. Hier erkannte das Autorenteam relativ schnell, dass das Modellieren seine Grenzen hat. Das alleinige Modellieren, zumindest von großen Prozessen, deckt nicht von selber die Schwachstellen auf.

Die Kommunikation während der Bearbeitung der Thematik zwischen den Autoren war sehr gut. Bei mehr als drei Teilnehmern wäre dies sicherlich mit größerem Aufwand verbunden. Neben dem Chat in Titanpad wurden auch klassische Kommunikationsinstrumente wie Telefon und E-Mail benutzt. Die Autoren telefonierten im Durchschnitt jeden zweiten Tag miteinander um Inhalte zu besprechen. Es wurde festgestellt das Wiki für die Bearbeitung eines gemeinsamen Themas nicht sehr komfortabel ist. So entschloss sich das Autorenteam Titanpad für das Schreiben der Arbeit zu verwenden. Durch Features wie die farbliche Abgrenzung der Inhalte und den Chat eignete sich das Programm gut für die gemeinsame Studienarbeit. Jedoch hat es auch Schwächen, es hat z.B. eine eingeschränkte Formatierung und keine Rechtschreibkorrektur. Titanpad hat sich bewährt, ist gut geeignet für kleinere Gruppenarbeiten, insbesondere bei Zeitdruck und zeitgleicher Bearbeitung. Wiki ist nach Ansicht der Autoren gut geeignet für Knowledge-Sharing, weniger für die abschließende Präsentation der Arbeitsergebnisse oder für das Verfassen von Arbeiten in einer Gruppe. Abschließend lässt sich sagen dass die agile Projektarbeit mit kurzen Sprints und Sprint-Reviews Sinn macht, ob eine Erfassung in einem für das Autorenteam eher für statische Inhalte gedachten Wiki sinnvoll ist, wird offen gelassen.

Abschließende Erkenntnis

Abschließend lässt sich sagen, das für beide Autoren die inhaltliche Auseinandersetzung mit dem Thema sehr viel für die Praxis gebracht hat. Beide Autoren verfassten zum erstenmal eine Studienarbeit in einer Gruppe. Die Tatsache dass Herr Fechner in Berlin und Herr Özten in Schweinfurt leben, behinderte die Zusammenarbeit in keinster Weise. Dank der bereits erwähnten Technologien war das Schreiben der Studienarbeit im Team unkompliziert.

Auch konnte das Autorenteam bereits erste praktische Erfahrung durch die Auseinandersetzung mit dem Thema sammeln. Der modellierte Geschäftsprozess von Herr Fechner dient in Zukunft als Grundlage für weitere Optimierungsmöglichkeiten in seiner Firma. Erste Erfolge konnte Herr Özten auch verbuchen. Nach einer kurzen Einarbeitung in Flussdiagramme, hat Herr Özten den Prozess des Urlaubsantrags bei seinem jetzigen Arbeitgeber in MS Visio modelliert. Es wurde ein Softwareangebot eingeholt, die den Urlaubsantrags-Prozess als Workflow völlig papierlos abwickelt. Die Geschäftsführung wurde von der Dringlichkeit überzeugt.

---

Literaturverzeichnis

Becker J., Mathas C., & Winkelmann,A., Geschäftsprozessmanagement, 2009

Vanderfeesten, Irene und Reijers, Hajo in Management Research News, 2006. "How to increase work autonomy in workflow management systems?"

Gadatsch, A., Grundkurs Geschäftsprozessmanagement, 5. Auflage, 2008

Jacob F., Götzer K,. Vom Geschäftsprozess zum Workflow, 1. Auflage, 2008

Kocian, C., Geschäftsprozessmodellierung mit BPMN 2.0, Business Process Model and Notation im Methodenvergleich (Working Paper), 2011

Mertens, P., Grundzüge der Wirtschaftsinformatik, 2012

Object Management Group (OMG): Business Process Model and Notation. Version 2.0. URL: http://www.omg.org/spec/BPMN/2.0/PDF, März 2013, Abruf am 01.03.2013

Seethamraju R., Business process management: a missing link in business education. Business Process Management Journal, 2012

Stiehl, V., Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN, 1. Auflage, 2013

Trambo, Identifikation und Analyse von Prozessrisiken, 2010

Wikipedia.de: Releasemanagement, http://de.wikipedia.org/wiki/Releasemanagement, März 2013, Abruf 01.03.2013