Prozessmanagement von der Unternehmensstrategie bis zur IT-Infrastruktur

INHALTSVERZEICHNIS

1 EINLEITUNG
1.1 Ausgangssituation
1.2 Aufgabenstellung und Zielsetzung
1.3 Vorgehensweise
1.4 Aufbau der Arbeit
1.5 Verwandte Arbeiten

2 GESCHÄFTSPROZESSE UND GESCHÄFTSPROZESSMANAGEMENT
2.1 Einordnung in Unternehmen
2.2 Begriffsdefinition für Geschäftsprozess
2.3 Geschäftsprozessmanagement
2.4 Prozessoptimierung

3 WORKFLOWS
3.1 Begriffsdefinition
3.2 Workflowmanagement
3.3 Workflowmanagementsysteme
3.4 Service Orientierte Architekturen
3.4.1 Services
3.4.2 Architekturprinzip SOA
3.4.3 Zukunft von SOA

4 PROZESSMODELLIERUNG
4.1 Aufbau von Geschäftsprozessmodellen
4.2 Zweck fachlicher Prozessmodelle
4.3 Workflowmodellierung
4.4 Notationen

5 ABLEITUNG VON TECHNISCHEN PROZESSMODELLEN
5.1 Ziele
5.2 Herausforderungen
5.3 Unterscheidungsmerkmale für Ableitungsmethoden
5.4 Lösungsansätze
5.4.1 Keine Ableitung
5.4.2 Manuelle Transformation
5.4.3 Halbautomatische Transformation
5.4.4 Automatische Transformation

6 BEWERTUNGSKRITERIEN

7 IMPLEMENTIERUNG DER LÖSUNGSANSÄTZE
7.1 Manuelle Transformation
7.1.1 Verwendete Tools
7.1.2 Verwendetes Beispiel
7.1.3 Beschreibung
7.2 Halbautomatische und Automatische Transformation
7.2.1 Verwendete Tools
7.2.2 Verwendetes Beispiel
7.2.3 Beschreibung der Erstellung des fachlichen Modells
7.2.4 Ablauf bei der Generierung des technischen Modells
7.2.5 Überprüfung und Nachbearbeitung des technischen Modells
7.2.6 Vorgehen bei Änderungen
7.3 Weitere Transformationstools

8 BEWERTUNGSMATRIX

9 FAZIT DER BEWERTUNG

10 ZUSAMMENFASSUNG UND AUSBLICK

ANHANG A: BEISPIEL ZUR MANUELLEN TRANSFORMATION
(A) MODELLIERUNG DES EPK-MODELLS
(B) ERSTELLUNG DES WORKFLOWS

ANHANG B: BEISPIEL ZUR AUTOMATIONSUNTERSTÜTZTEN TRANSFORMATION
(A) MODELLIERUNG DES BPMN-MODELLS
(B) ABLEITUNG DES WORKFLOWS
(C) ÜBERPRÜFUNG UND NACHBEARBEITUNG DES TECHNISCHEN MODELLS
(D) VORGEHEN BEI ÄNDERUNGEN

ABKÜRZUNGSVERZEICHNIS

ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS

LITERATURVERZEICHNIS

1 EINLEITUNG

„Der liebe Gott schenkte die Logik, den Algorithmus. Da setzte der Teufel den Programmierer hinzu und das irdische Gleichgewicht war wieder hergestellt.“

Heinz Zemanek wiener Nachrichtentechniker

Die Unterschiede zwischen Fachbereichen und IT eines Unternehmens werden von vielen wie jene zwischen zwei absolut konträren Welten empfunden. Dies liegt vor allem an unterschiedlichen Begriffen und Ausdrucksweisen der jeweiligen Vertreter. Der Techniker sieht seine Implementierung und all die Herausforderungen die damit verbunden sind, während der Mitarbeiter in der Fachabteilung rein den Beitrag der IT zu seiner Tätigkeit sieht.

Im folgenden Kapitel wird erläutert wo die Unterschiede zwischen Fachabteilungen und der IT bei der Darstellung von Geschäftsprozessen zu tragen kommen. Aus dieser Ausgangssituation stellt sich die Aufgabe diese Unterschiede zu überbrücken. Die in diesem Kapitel beschriebene Vorgehensweise zur Erreichung der Zielsetzung und der grobe Aufbau der Arbeit dienen dazu einen Überblick über die Arbeit zu geben. Ein kurzer Überblick über verwandte Arbeiten zeigt, wo die Arbeit in ihrem Umfeld eingebettet ist.

1.1 Ausgangssituation

Moderne Unternehmen begnügen sich nicht mehr mit einer Aufbauorganisation, sondern legen zunehmend Wert auf eine gut durchdachte Ablauforganisation und im Besonderen auf optimierte Geschäftsprozesse. Die daraus resultierende neue Sichtweise auf das Unternehmen wirkt sich auch auf die IT aus. Mit dem Aufkommen der Geschäftsprozessmodellierung wurden Workflow-Management Systeme eingeführt und in letzter Zeit entwickelt sich zunehmend ein Trend zu Service Orientierten Architekturen (SOA), welche ebenfalls Workflows verwenden.

Workflows basieren teilweise auf Geschäftsprozessen. Die IT benötigt Prozessmodelle jedoch in einer anderen Form als diese vom Management erstellt werden. Aus diesem Grund müssen die Geschäftsprozesse der Fachbereiche für die IT aufbereitet werden. Zwar existieren bereits verschiedene Ansätze zur Lösung des Problems, allerdings gestaltet sich die Überleitung der fachlichen Modelle in technische Prozesse in der Praxis auch heute noch schwierig.

1.2 Aufgabenstellung und Zielsetzung

In dieser Arbeit werden aktuelle Ansätze zur Ableitung technischer Prozessmodelle (Workflows) aus fachlichen Geschäftsprozessmodellen verglichen. Einzelne Ableitungsmethoden werden durch Referenz- Werkzeuge bewertet um die Vor- und Nachteile der Methoden aufzuzeigen und herauszufinden welche derzeit die zweckmäßigste Lösung für die Praxis darstellt. Die Beschreibung der Vor- und Nachteile einzelner Werkzeuge ist allerdings nicht Teil dieser Arbeit.

In diesem Zusammenhang sollen folgende Fragen beantwortet werden:

- Welche Möglichkeiten zur Ableitung eines IT-Prozessmodells aus Geschäftsprozessen gibt es?
- Welche ist die für die Praxis Geeignetste?
- Müssen Prozessverantwortliche die Bedürfnisse der IT kennen oder kann sich die IT anpassen?

Die Beschreibung Service Orientierter Architekturen dient der Erläuterung des Praxisbezuges der Arbeit und der Anforderungen an die Modelle. Die Arbeit befasst sich jedoch nicht mit der Darstellung des Gesamtkonzeptes der Service Orientierten Architekturen.

1.3 Vorgehensweise

Die Arbeit basiert auf der deduktiven Methode. Auf Basis der allgemeinen Beschreibungen des Geschäftsprozessmanagements und der Workflow-Management-Systeme werden detaillierte Informationen über die Modellierung von Geschäftsprozessen auf unterschiedlichen Ebenen gesammelt. Es wird beschrieben warum formale Modelle aus Geschäftsprozessmodellen erstellt werden und welche Probleme hierbei auftreten.

Basierend auf diesen Grundlagen werden Kriterien zur Bewertung der einzelnen Ableitungsmöglichkeiten ermittelt. Im nächsten Schritt werden Beispiele für verschiedene Ansätze erstellt, um die Abläufe vergleichen zu können. Im Anschluss wird aus diesen Beispielen eine Vergleichsmatrix erstellt, in der die einzelnen Methoden miteinander verglichen und bewertet werden.

1.4 Aufbau der Arbeit

Die ersten beiden Kapitel beschreiben Geschäftsprozesse, Workflows und damit verbundene Tätigkeiten in einem Unternehmen. Im dritten Kapitel wird darauf eingegangen wie Workflows und Geschäftsprozesse festgehalten werden, und zwar in Form von Modellen. Weiters wird der Zweck solcher Modelle näher erklärt. Durch diese drei Kapitel soll ein Verständnis für die Thematik geschaffen werden.

Das vierte Kapitel beinhaltet die theoretischen Grundlagen für die Ableitung von Workflowmodellen. In diesem Kapitel ist beschrieben warum Workflowmodelle abgeleitet werden sollten, was die Probleme dabei sind und wie es grundsätzlich bewerkstelligt werden kann. Im Kapitel „Bewertungskriterien“ wird definiert, woran man die Praxistauglichkeit einer Ableitungsmethode messen kann. Diese Bewertungskriterien werden auf die im Kapitel sieben gezeigten Implementierungen angewandt und das Ergebnis wird im Kapitel acht in Form einer Bewertungsmatrix dargestellt.

Im letzten Kapitel wird aus der Bewertungsmatrix ein Fazit gezogen und es gibt einen Ausblick was auf diesem Gebiet noch getan werden muss.

1.5 Verwandte Arbeiten

Es existieren zahlreiche Arbeiten zu diesem Thema, die eine Transformation von Geschäftsprozessmodellen zu Workflows behandeln, wobei jedoch alle hier aufgeführten Arbeiten jeweils einen Ansatz vorstellen.

(Stein, et al., 2007) beschreibt in seiner Arbeit einen Ansatz wie ereignisgesteuere Prozessketten (EPKs) zu Business Process Execution Language (BPEL)-Workflows transformiert werden können. Hierbei wird das Geschäftsprozessmodell vor der Transformation daraufhin geprüft, ob es transformiert werden kann. Ebenfalls eine Transformation von EPKs zu Workflow-Modellen wird in (Kopp, 2005) und (Beer, et al., 2007) beschrieben, wobei hier jeweils ein eigenes Werkzeug beschrieben wird. In (Kurbel, et al., 1997) wird eine Ableitung eines Workflows aus einem Geschäftsprozessmodell erläutert. Die Ableitung erfolgt hier manuell, das Workflow-Modell wird also neu modelliert. Eine Variante bei der ein EPK-Modell zuerst manuell in ein eher technisches BPMN-Modell überführt wird, aus dem halbautomatisch ein BPEL-Modell generiert wird, wird in (Thomas, et al., 2007) beschrieben. (Nissen, et al., 2007) beschreibt einen Ansatz in dem UML-Diagramme solange verfeinert werden bis sie zu einem BPEL-Workflow transformiert und im Anschluss daran nachbearbeitet werden können.

2 GESCHÄFTSPROZESSE UND GESCHÄFTSPROZESSMANAGEMENT

„Organisation ist ein Mittel, die Kräfte des einzelnen zu vervielfältigen.“

Peter F. Drucker (*1909) amerikanischer Managementlehrer, -berater u. -publizist österreichischer. Herkunft

Geschäftsprozessmanagement ist ein aktuelles Thema in vielen Unternehmen die versuchen, aus unterschiedlichsten Gründen, wie zum Beispiel der zunehmenden Globalisierung und den dadurch gestiegen Druck zur Kostenreduktion, ihre Abläufe zu optimieren.

In diesem Kapitel wird darauf eingegangen wo Geschäftsprozessmanagement im Unternehmen einzuordnen ist. Weiters wird definiert was in dieser Arbeit unter einem Geschäftsprozess verstanden wird. Im letzten Teil wird beschrieben aus welchen Aktivitäten in einer Organisation sich das Geschäftsprozessmanagement zusammensetzt.

2.1 Einordnung in Unternehmen

Geschäftsprozesse und Geschäftsprozessmanagement sind Teil der Ablauforganisation eines Unternehmens, welche die Tätigkeiten in einem Unternehmen und deren zeitliche und logische Abfolge behandelt. Im Gegensatz dazu befasst sich die Aufbauorganisation mit der Struktur in einem Unternehmen und definiert über diese Struktur Zuständigkeiten und Weisungsbefugnisse.¹

2.2 Begriffsdefinition für Geschäftsprozess

Im Geschäftsprozessmanagement unterscheidet man zwischen den Begriffen „Prozess“ und „Geschäftsprozess“. Ein Prozess ist eine Abfolge von einzelnen Aktivitäten in einer zeitlichen und logischen Abarbeitungsreihenfolge mit einem bestimmten Zweck, beispielsweise der Durchführung einer Rechnungsprüfung.²

Geschäftsprozesse stellen eine spezielle Form von Prozessen dar. Die Abgrenzung eines Geschäftsprozesses ist nicht eindeutig definiert. Als die drei wichtigsten Eigenschaften gelten jedoch: Ein Geschäftsprozess ist ein wertschöpfender Prozess. Dieser erzeugt beim Kunden einen Nutzen, welcher der Kernaktivität des jeweiligen Unternehmens entspricht. Ein Geschäftsprozess ist funktionsübergreifend, d.h. er wird von mehreren Einheiten – im Sinne der Aufbauorganisation – eines Unternehmens behandelt.

Ein Geschäftsprozess ist ebenso kundenorientiert, er nimmt seinen Ausgang beim Kunden (Bsp.: Bestellung) und endet auch beim Kunden (Bsp.: Lieferung, Zahlungsbestätigung).³

2.3 Geschäftsprozessmanagement

Geschäftsprozessmanagement beinhaltet folgende drei Aspekte:⁴

- Prozessabgrenzung
- Prozessmodellierung
- Prozessführung

Die Prozessabgrenzung umfasst die Ableitung und Erstellung neuer Geschäftsprozesse aus der Unternehmensstrategie und dem Produktsortiment. Für eine zu lösende Aufgabe werden hierbei mehrere Prozessvarianten verglichen und modelliert, worauf eine Prozessvariante zur Implementierung ausgewählt wird. Die Geschäftsprozessmodellierung beschäftigt sich mit der Abbildung bestehender Prozesse eines Unternehmens aus fachlicher Sicht. Die Aufgabe der Prozessführung ist festzustellen, ob die Geschäftsprozesse den strategischen Zielen eines Unternehmens genügen. Hierzu müssen aus den strategischen Zielen Kennzahlen abgeleitet werden, anhand welcher die Prozesse kontrolliert werden können. Gegebenenfalls müssen Prozesse nachmodelliert oder verändert werden.⁵

2.4 Prozessoptimierung

Geschäftsprozesse sind nichts Statisches. Zum einen sind Prozesse nicht zwangsläufig von Anfang an tatsächlich ausgereift, zum anderen ergeben sich durch geänderte Rahmenbedingungen auch neue Möglichkeiten der Prozessdefinition. Es gibt zwei Möglichkeiten Prozesse eines bestehenden Unternehmens zu verbessern: Business Process Reengineering ist ein radikaler Ansatz, bei dem die Geschäftsprozesse völlig neu erdacht werden. Dadurch entsteht ein hoher Aufwand zur Umstellung auf die neuen Prozesse und ein entsprechend hohes Risiko, jedoch ist das Potential höher. Ein weniger radikaler Ansatz ist das kontinuierliche Prozessmanagement. Hierbei werden bereits bestehende Prozesse auf Verbesserungsmöglichkeiten geprüft und schrittweise angepasst.⁶

3 WORKFLOWS

„Im Zeitalter des Computers haben wir es mit der Überwindung geistiger Entfernungen mittels der Elektronik zu tun, statt daß wir, wie im Zeitalter der Industrieproduktion, physikalische Entfernungen mit Hilfe des Automobils überwinden mußten.“

John Naisbitt (*1930), amerikanischer Prognostiker

Das vorherige Kapitel beschrieb was unter Geschäftsprozessen aus der Sicht des Managements und der Fachbereiche zu verstehen ist. Dieses Kapitel erläutert den technischen Blickwinkel.

Schon aus der Definition des Begriffs „Workflow“ am Anfang dieses Kapitels ist ersichtlich, dass dieser zwar direkt mit dem Begriff Geschäftsprozess zusammen hängt, aber diesen noch um Aspekte der IT erweitert. Anschließend an die Definition des Begriffes wird gezeigt, wo Workflows in der IT zum Einsatz kommen. Mit der Beschreibung von serviceorientierten Architekturen wird ein Einsatzgebiet für Workflows näher erläutert.

3.1 Begriffsdefinition

Es existiert keine allgemein gültige einheitliche Definition für den Begriff „Workflow“. Tabelle 3-1gibt einen kurzen Überblick über verschiedene Definitionen:^{7 8 9 10}

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3-1: Definitionen für Workflow

Für diese Arbeit gilt folgende Definition in Anlehnung an (Gadatsch, 2008) und (Fischer, et al., 2006):

Ein Workflow ist ein formal beschriebener, ganz oder teilweise durch ein IT-System automatisierter Geschäftsprozess. Er beinhaltet die zeitlichen, fachlichen und ressourcenbezogenen Spezifikationen, die für eine automatische Steuerung des Arbeitsablaufes durch ein Workflowmanagementsystem erforderlich sind. Die hierbei anzustoßenden Arbeitsschritte sind zur Ausführung durch Mitarbeiter oder durch Anwendungsprogramme vorgesehen.

3.2 Workflowmanagement

Für Geschäftsprozesse gibt es das Geschäftsprozessmanagement, welches sich mit allen Tätigkeiten rund um Geschäftsprozesse befasst.

Analog dazu gibt es bei Workflows das Workflow-Management, das alle Tätigkeiten und Methoden zur Analyse, Planung, Simulation, Steuerung und Überwachung von Arbeitsabläufen beinhaltet.¹¹

Da die Vorgänge des Workflowmanagement im Detail diese Arbeit nicht beeinflussen, werden sie hier nicht näher behandelt. Über die Ziele des Workflowmanagements kann mehr in (Gadatsch, 2008) in Erfahrung gebracht werden.

3.3 Workflowmanagementsysteme

Workflowmanagementsysteme sind Software-Systeme zur Ausführung und Überwachung von Workflows. Sie können auch als Business Process Management Systeme bezeichnet werden.¹²

Der genaue Funktionsumfang eines Workflowmanagementsystems ist nicht genau definiert, ferner hat sich das Verständnis darüber im Lauf der Zeit verändert. Häufig wird ein Workflowmanagement mit einem Dokumentenmanagementsystem in Zusammenhang gebracht, oder es wird als Groupware-System verstanden, das Aktivitäten einzelner Mitarbeiter anhand eines Ablaufschemas steuert.¹³ Diese Auffassungen beschreiben einzelne Einsatzmöglichkeiten für Workflowmanagementsysteme, es existieren jedoch noch weitere.

Gadatsch unterscheidet zwischen fünf Stufen von Workflowmanagementsystemen. In der ersten Stufe sind es einfach Applikationen, die Prozesse abwickeln und welche direkt in den Code der Applikation geschrieben sind. Diese Systeme wurden zum Beispiel in Versicherungen eingesetzt. Sie wurden zwar noch nicht als Workflowmanagementsysteme bezeichnet, stellen aber eine Vorstufe dar. Die zweite Stufe besteht darin die Prozesse von der Applikation zu trennen. In der dritten Stufe werden die Prozesse in eigenen Datenbanken gespeichert. Die vierte Stufe ermöglicht den Austausch von Prozessausführungsdaten zwischen verschiedenen Anwendungen verschiedener Hersteller. Möglich wird dies durch den Einsatz von Client-Server-Architekturen. Als fünfte Stufe nennt Gadatsch den Wechsel von Client-Server-Architekturen hin zu serviceorientierten Architekturen.¹⁴

Ein Workflowmanagementsystem ist also eine Middleware, welche die Ausführung und das Überwachen von Prozessen in einer Anwendung bzw. Workflows unterstützt.

Weitere Funktionalitäten des Systems können Beispielsweise die Modellierung, die Simulation oder die Analyse von Workflows sein¹⁵. Workflowmanagementsysteme interpretieren Workflow-Beschreibungen und führen die einzelnen Aktivitäten aus indem sie die Tätigkeiten an Mitarbeiter oder andere Anwendungen weiterleiteten und hierbei gegebenenfalls vorhandene Informationen bereitstellen¹⁶.

3.4 Service Orientierte Architekturen

Serviceorientierte Architekturen (SOA) sind ein Paradigma, das nicht auf die IT abgrenzbar ist.¹⁷ In dieser Arbeit wird SOA aus einer technischen Sicht beschrieben. Wie bereits unter Abschnitt 3.3 erwähnt sind serviceorientierte Architekturen ein mögliches Einsatzgebiet für Workflowmanagementsysteme.

Dieses Kapitel beschreibt welche Rolle Workflows bei SOA spielen. Dazu werden zunächst die Grundelemente einer SOA, die so genannten „Services“ kurz beschrieben, welche im Architekturprinzip Verwendung finden. Am Ende findet sich noch ein Ausblick über die Zukunft von SOA, der die Aktualität des Themas zum Inhalt hat.

3.4.1 Services

Services sind aus technischer Sicht fachlich orientierte Softwarekomponenten, von denen derjenige der Sie verwendet in der Regel nicht mehr als eine Beschreibung des Inhalts und der Schnittstelle hat.

Informationen über die Implementierung und über die Plattform werden abstrahiert. Web-Services sind eine gängige Implementierung für Services in der IT, sie sind jedoch keine Voraussetzung für eine SOA.¹⁸

3.4.2 Architekturprinzip SOA

SOA bezeichnet nun eine Architektur die vollständig aus Services aufgebaut ist. Die Kommunikation und der Aufruf der Services werden an einer zentralen Stelle koordiniert.¹⁹

Die Services werden in der sogenannten Komposition zu Geschäftsprozessen zusammengefügt.²⁰ Hierzu können Workflowmanagementsysteme eingesetzt werden. Diese koordinieren die Ausführung der einzelnen Services. Für serviceorientierte Architekturen werden bei Workflow-Engines Sprachen eingesetzt, die speziell für die Komposition von Services entwickelt wurden, zum Beispiel BPEL.²¹

3.4.3 Zukunft von SOA

Auch wenn der Hype um serviceorientierte Architekturen bereits abgeklungen ist, wird SOA laut Ansicht von Beratungsunternehmen wie Gartner und IT-Verantwortlicher großer Unternehmen auch in Zukunft nicht verschwinden. Gerade wegen ihrer Prozessorientierung dürften serviceorientierte Strukturen in Zukunft weiter ausgebaut werden.²²

4 PROZESSMODELLIERUNG

Einmal sehen ist besser als zehnmal hören.

Deutsches Sprichwort

Geschäftsprozesse können zwar verbal beschrieben werden, wesentlich häufiger ist jedoch eine grafische Darstellung. Das folgende Kapitel erläutert, wie Prozessmodelle grundsätzlich aufgebaut und gegliedert sind. Es beschreibt welche Eigenschaften und welchen Verwendungszweck fachliche Prozessmodelle im Unternehmen haben können.

In Folge werden Workflow-Modelle anhand ihrer Unterschiede zu Geschäftsprozessmodellen erklärt. Weiters wird darauf eingegangen, wo sich die beiden Modellarten schneiden und wo grundsätzliche Unterschiede bestehen.

Im letzten Teil des Kapitels werden kurz einige häufig verwendete Notationen genannt und nach ihrer Verwendung eingeteilt.

4.1 Aufbau von Geschäftsprozessmodellen

Zur Erfassung von Geschäftsprozessen haben sich graphische Darstellungsformen bewehrt. Diese Modelle bestehen aus einzelnen Elementen, deren Bedeutung durch eine Semantik definiert ist. Die Elemente sind mit so genannten Kanten verbunden, welche entweder einen Fluss, eine Reihenfolge oder eine Zugehörigkeit darstellen.²³

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-1: Beispiel Prozessmodell²⁴

Abbildung 4-1 zeigt ein EPK-Modell. Die Elemente in dieser Abbildung sind so genannte Ereignisse – in Rot dargestellt - und Funktionen – hier in Grün -, welche durch Kanten, die den Kontrollfluss darstellen, verbunden sind.

Geschäftsprozessmodelle im Unternehmen lassen sich nach Detaillierungs-Grad unterscheiden in strategische und fachliche Geschäftsprozessmodelle. Während strategische Geschäftsprozessmodelle abstrakt beschreiben wie das Unternehmen grundsätzlich einen Mehrwert erzeugt, beschreiben fachliche Prozessmodelle jeden einzelnen Arbeitsschritt, der benötigt wird um das Ergebnis zu erreichen.²⁵

Prozessmodelle können jedoch noch weiter abgestuft werden. Eine Sub-Ebene entspricht dabei einer genaueren Beschreibung eines Elements der übergeordneten Ebene.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-2: Prozessdetailierung²⁶

Abbildung 4-2 zeigt ein typisches Beispiel für eine solche Verfeinerung. Bei den Prozessen Einkauf, Wareneingang, Lagerhaltung, Auftragsbearbeitung und Versand handelt es sich um übergeordnete Prozesse, welche jedoch in einem weiteren Diagramm noch genauer detailliert sind. Dies bietet den Vorteil, dass das Management einerseits den Überblick behält, aber andererseits dennoch weiß wo im Unternehmen ein Prozess einzuordnen ist. Für das Management ist es nicht von Bedeutung wie ein Prozess operativ ausgeführt wird. Es reicht wenn der grundlegende Weg der Wertschöpfung im Unternehmen insgesamt erkennbar ist. Besonders wichtig wird die Detaillierung wenn Prozesse unternehmensübergreifend modelliert werden, um auch Lieferanten, Outsourcing-Unternehmen, Kooperationspartner oder andere Akteure in das Modell einzubeziehen.²⁷

4.2 Zweck fachlicher Prozessmodelle

Prozessmodelle können aus unterschiedlichen Gründen modelliert werden. Die folgende Tabelle gibt einen Einblick in die vielfältigen Gründe für die Modellierung von Prozessen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4-1: Zweck fachlicher Prozessmodelle²⁸²⁹

4.3 Workflowmodellierung

Ein Modell ist eine Abstraktion eines komplexen Gegenstands. Doch während das fachliche Prozessmodell viele Details der Ausführung abstrahiert, enthält das Workflowmodell Spezifikationen, die für die Ausführung auf einem Workflow-Management-System erforderlich sind³⁰.

Jedoch kann das Geschäftsprozessmodell auch Daten enthalten, die nicht für ein Workflowmodell interessant sind. Aus Tabelle 4-1 ist ersichtlich, dass der Einsatzbereich von Geschäftsprozessmodellen umfangreicher ist als jener von technischen Prozessmodellen. Dies führt dazu, dass nicht immer alle Teile eines fachlichen Prozessmodells in ein technisches Prozessmodell überführt werden, da das fachliche Modell auch Vorgänge außerhalb des Einflussbereichs der IT beschreiben kann.

Darüber hinaus wird nicht immer ein gesamter Geschäftsprozess in einem Workflow abgebildet, sondern lediglich der Teil der IT-unterstützt ablaufen soll.³¹ Ein Workflow kann also als ein Ausschnitt aus einem Geschäftsprozessmodell gesehen werden, der um Details erweitert wurde, womit er einer Sub-Ebene des Geschäftsprozessmodells entspricht.

Für Workflow-Modelle gibt es jedoch eine wichtige Einschränkung, die Geschäftsprozessmodelle so nicht kennen: Es gibt grafische und textuelle Beschreibungen für Workflows, wirklich ausgeführt werden können auf Workflow-Engines jedoch ausschließlich textuelle Beschreibungen. Grafische Modelle müssen also in eine textuelle Beschreibung umgewandelt werden können.³²

4.4 Notationen

Es existieren viele unterschiedliche Notationen für Geschäftsprozesse und Workflows. Teilweise haben Hersteller für Workflow-Management-System sogar eigene Modellierungs-Sprachen entwickelt. Die aktuell wichtigsten seien hier kurz beschrieben, wobei diese Liste keinesfalls Anspruch auf Vollständigkeit erhebt.

Zur Beschreibung von Geschäftsprozessen haben sich Ereignisgesteuere Prozessketten (EPK) durchgesetzt.³³ Die Unified Modelling Languague (UML) wurde zur Beschreibung von Geschäftsprozessen um das Aktivitätsdiagramm erweitert und kann somit ebenfalls zur Geschäftsprozessmodellierung verwendet werden.³⁴

Die Business Process Modelling Notation (BPMN) ist ein Zwischenschritt zwischen Geschäftsprozessen und Workflows. Mit ihr können abstrakte als auch formale Prozesse beschrieben werden³⁵. Es gibt Transformationsregeln um aus BPMN-Diagrammen formale Workflowbeschreibungen zu erzeugen. Das Mapping von BPMN auf BPEL ist im Standard zur BPMN (Object Management Group, 2008) direkt enthalten.

Die folgenden drei Sprachen sind formale, textuelle Sprachen und werden zur Ausführung von Workflows in Workflow-Engines verwendet:

- Business Process Execution Languague (BPEL)³⁶
- Business Process Modelling Languague (BPML)
- XML Process Definition Language (XPDL)

[...]

---

¹ Vgl. (Becker, et al., 2006) S. 6f

² Vgl. (Becker, et al., 2006) S. 6f

³ Vgl. (Gadatsch, 2008) S. 45ff

⁴ Vgl. (Langner, 2007) S. 23f

⁵ Vgl. (Gadatsch, 2008) S. 2f

⁶ Vgl. (Becker, et al., 2006) S. 299f

⁷ (Gadatsch, 2008) S. 53

⁸ (Becker, et al., 2006) S. 56

⁹ (Fischer, et al., 2006) S. 104

¹⁰ (Gadatsch, 2008) S. 52

¹¹ Vgl. (Becker, et al., 2006) S. 377f

¹² Vgl. (Strohmeier, 2008) S. 305

¹³ Vgl. (Gadatsch, 2008) S. 265f

¹⁴ Vgl. (Gadatsch, 2008) S. 268f

¹⁵ Vgl. (Strohmeier, 2008) S. 305 ff

¹⁶ Vgl. (Becker, et al., 2006) S. 191

¹⁷ Vgl. (Masak, 2007) S. 4

¹⁸ Vgl. (Nissen, et al., 2007) S. 77 f

¹⁹ Vgl. (Masak, 2007) S. 92

²⁰ Vgl. (Masak, 2007) S. 104

²¹ Vgl. (Masak, 2007) S. 212

²² Vgl. (Herrmann, 2008) S. 3

²³ Vgl. (Rosenkranz, 2006) S. 1f

²⁴ Quelle; in Anlehnung an (Staud, 2006) S. 70

²⁵ Vgl. (Rosenkranz, 2006) S. 15f

²⁶ Quell: in Anlehnung an (Fischer, et al., 2006) S 9

²⁷ Vgl. (Fischer, et al., 2006) S. 10f

²⁸ Vgl. (Becker, et al., 2006) S. 51-56, S. 190-193

²⁹ Vgl. (Andres, 2006) S. 233

³⁰ Vgl. (Nissen, et al., 2007) S. 86

³¹ Vgl. (Fischer, et al., 2006) S. 140 f

³² Vgl. (Nissen, et al., 2007) S. 62

³³ Vgl. (Staud, 2006) S. 59

³⁴ Vgl. (Seemann, et al., 2006) S. 27

³⁵ Vgl. (Masak, 2007) S. 256 f

³⁶ Spezifikation siehe (OASIS, 2007)