Grundkurs Geschäftsprozess-Management || Prozessmodellierung

2Prozessmodellierung

2.1 Ebenen der Prozessmodellierung

Die Unterscheidung von Geschäftsprozess und Workflow führt zu einer Differenzierungnach Modellierungsebenen (vgl. Gehring 1998). Wegen der Komplexität des Modellie-rungsgegenstandes ist es sinnvoll, eine Bildung von Modellierungssichten vorzunehmenund in Phasen zu gliedern. Für die Modellierung sind zwei Ebenen relevant, die Ebene derfachlich-konzeptionellen Prozessmodellierung und die operative Ebene der Workflowmo-dellierung (vgl. Abb. 2.1).

Zu den vorgestellten Zusammenhängen des Rahmenkonzeptes kommen die Ergebnis-se der Gestaltungs- und Modellierungstätigkeit hinzu. Das Repository stellt ein Wörter-buch dar, das zur Beschreibung der Modellbausteine und der zwischen den Bausteinenbestehenden Beziehungen dient. Es erfasstGeschäftsprozesseund Verbindungen zwischenGeschäftsprozessen und Workflows. Beschrieben werden außerdem die Schnittstellen zurModellumwelt. Letztere besteht vor allem aus der jeweiligen Geschäftsfeldstrategie, denunterstützenden Informationssystemen und den involvierten Organisationseinheiten. DasRepository ist nicht nur ein Dokumentations- und Auskunftsinstrument. Sofern in ihmauch dasMeta-Modell abgelegt wird, das der verwendetenModellierungsmethode zugrun-de liegt, gestattet es eine automatische Konsistenzprüfung der Modelle und Teilmodelle.

2.2 Phasen der Prozessmodellierung

Phasen- bzw. Life-Cycle-Modelle werden zur Strukturierung komplexer Entwicklungsvor-haben eingesetzt (z. B. im Software-Engineering) und auch im Rahmen der Prozessmodel-lierung vorgeschlagen. Dabei lassen sich ein- und zweistufige Modellansätze unterschei-den.

57A. Gadatsch,Grundkurs Geschäftsprozess-Management, DOI 10.1007/978-3-8348-2428-8_2,© Vieweg+Teubner Verlag | Springer Fachmedien Wiesbaden 2012

58 2 Prozessmodellierung

Ebene Tätigkeit Ergebnis Akteur

strategischeEbene

fachlich-konzeptionelleEbene

operativeEbene

Strategie-entwicklungStrategie-entwicklung

Workflow-modellierungWorkfloww-modellierung

Prozess-modellierungProzess-modellierung

Geschäftsfeld-strategieGeschäftsfeld-strategie

Workflow-modellWorkfloww-modell

Prozess-modellProzess-modell

StrategischesManagementStrategischesManagement

Workflow-ManagementWorkfloww-Management

Geschäftsprozess-ManagementGeschäftsprozesss-Management

Repository

Abb. 2.1 Ebenenkonzept (Gehring 1998)

Bei der einstufigen Modellierung wird das Workflow-Modell direkt erstellt, ohne einGeschäftsprozessmodell vorauszusetzen. Bei der zweistufigen Vorgehensweise wird einWorkflow-Modell aus einem zuvor erstellten Geschäftsprozessmodell abgeleitet. Die zwei-stufige Workflowmodellierung trägt der Tatsache Rechnung, dass Geschäftsprozesse undWorkflows unterschiedlichen Zwecken dienen, wenn auch eine Abgrenzung nicht in jedemEinzelfall exakt möglich ist.

In der Praxis wird oft der zweistufige Ansatz bevorzugt, da es neben den unterschiedli-chen Einsatzzwecken der Modelle kaum Softwaretools gibt, die den einstufigen Ansatz sounterstützen, dass die Anforderungen aller beteiligten Personengruppen voll unterstütztwerden.

In Abb. 2.2 wird ein zweistufiger Workflow Life-Cycle dargestellt, der drei teils ver-maschte Teilzyklen beinhaltet (Gadatsch 1999, S. 173).

Der Teilzyklus (1) umfasst die Geschäftsprozessmodellierung, -analyse und -restruk-turierung sowie die Geschäftsstrategieentwicklung und lässt sich in die strategische bzw.fachlich-konzeptionelle Ebene des integrierten Gesamtkonzeptes einordnen. Ausgangs-punkt für den Teilzyklus (1) ist die Erhebung und Modellierung der Ist-Geschäftsprozess-modelle. Diese werden anschließend einer Geschäftsprozessanalyse hinsichtlich ihresBeitrages zur Erfüllung der aus der Geschäftsstrategie abgeleiteten Geschäftsprozesszieleunterzogen. Hierbei werden unproduktive oder überflüssige Geschäftsprozesse und Orga-nisationsstrukturen identifiziert. Die Geschäftsprozessanalyse kann auch Rückwirkungenauf die zunächst vorgegebene Geschäftsstrategie des Unternehmens haben, was wiederumdie nachfolgende Gestaltung und Restrukturierung der Geschäftsprozesse beeinflusst. Dieneu gestalteten und hinsichtlich der Zielvorgaben der Geschäftsstrategien restrukturier-ten Geschäftsprozesse werden als Soll-Geschäftsprozessmodelle formal beschrieben. Einenachfolgende Analyse der Soll-Geschäftsprozessmodelle kann zu weiteren Restrukturie-

2.2 Phasen der Prozessmodellierung 59

Geschäftsprozess-modellierung

Geschäftsprozess-analyse

Workflow-modellierung

Ausfführung

Monitoring

Workflow-Optimierung

Geschäfts-strategie-

entwicklungGeschäftsprozess-

restrukturierung

Simulation und Analyse

1. TeilzyklusStrategisch orientierte

Gestaltung vonGeschäftsprozessen

2. TeilzyklusOrganisatorisch-

technische Umsetzungdurch Workflows

3. TeilzyklusAusführung und Überwachung der Workfloww-

Instanzen

Abb. 2.2 Workflow-Life-Cycle-Modell (Gadatsch 1999, S. 173)

rungszyklen führen, bis die Gestaltung der Geschäftsprozesse mit den vorgegebenen oderggf. angepassten Geschäftszielen konform ist.

Mit demAbschluss von Teilzyklus (1) ist die fachlich-konzeptionelle Gestaltung derGe-schäftsprozesse abgeschlossen. Im anschließenden Teilzyklus (2) werden die Geschäftspro-zessmodelle bis auf die operative Workflow-Ebene verfeinert. Der angestrebte Detaillie-rungsgrad soll einerseits eine automatische Ausführung und andererseits eine simulations-basierte Analyse vonWorkflows gestatten. Die der Analyse folgendeWorkflowoptimierungvervollständigt den zweiten, gegebenenfalls iterierten Teilzyklus.

Die Ausführung von Workflows und deren laufende Überwachung bilden den Anfangdes Teilzyklus (3), der ebenfalls der operativen Ebene zuzuordnen ist. Abhängig vomGradder bei dem Monitoring festgestellten Abweichungen der Prozessergebnisse von den er-warteten Ergebnissen erfolgt eine Rückkopplung auf den Teilzyklus (1) oder (2). KleinereAbweichungen führen zu inkrementellen Änderungen in Form des erneuten Durchlau-fes von Teilzyklus (2), d. h. zu Optimierungen der Workflow-Modelle. Größere Abwei-chungen von Referenzwerten deuten auf Modellierungsdefizite hin und können eine Re-Modellierung bzw. einen Rücksprung zu Teilzyklus (1) erforderlich machen. Aktivitäts-auslösende Schwellwerte für dasMonitoring derWorkflow-Instanzen sind im Rahmen derGeschäftsprozessmodellierung als Toleranzbereiche für Prozessführungsgrößen vorzuge-ben. Die Ergebnisse des Workflow-Monitoring können bei gravierenden Abweichungenauch Auswirkungen auf die Geschäftsstrategie des Unternehmens haben.


1. TeilzyklusStrategisch orientierte

Gestaltung vonGeschäftsprozessen

2. TeilzyklusOrganisatorisch

technische Umsetzungdurch Workflows

Geschäftsprozess-modellierung

Geschäftsprozess-analyse

Workflow-modellierung

Ausführung

Monitoring

Workflow--Optimierung

Geschäfts-strategie-

entwicklungGeschäftsprozess-

restrukturierung

Simulation und Analyse

-w

WF-modellierer

SW-Entwickler

-

Process-owner Prozess-

modellierer

Process-owner

Prozess-berater

Prozess-mitarbeiter

CPO

3. TeilzyklusAusführung und Überwachung der Workflow

Instanzen

Prozessmitarbeiter

-

Abb. 2.3 Idealtypische Rollenzuordnung

Fallbeispiel PerformanceMonitoring DAKDie hohe Bedeutung der Prozessüberwachung wurde von der DeutscheAngestellten-Krankenkasse (DAK) erkannt und in eine Lösung umgesetzt(vgl. Röwekamp 2006). Sie misst die Antwortzeiten einzelner Prozessschritte underkennt Performance-Engpässe in ihren IT-Systemen. Nach internen Untersu-chungen liegt die Toleranzzeit der Kundenberater bei ca. 5 Sekunden. Dauerteine für die Beratungstätigkeit notwendige Anwendung länger, werden die Mit-arbeiter ungeduldig. Dauern die Beratungsgespräche insgesamt zu lange, fordernDienststellenleiter mehr Personal an, was zu höheren Kosten führt. Aus diesemGrund erfolgt eine Messung der Prozessschritte mit einem Software-Werkzeug.Anhand der ausgewerteten Prozessdaten sind Änderungen im Prozess oder denInformationssystemen möglich.

In Abb. 1.2 wurden die zentralen Rollen und Akteure des Geschäftsprozess- undWorkflow-Managements vorgestellt. Ordnet man diese in das Life-Cycle-Modell ein, soergibt sich das in Abb. 2.3 dargestellte Idealbild einer Rollen-Tätigkeitszuordnung.

Der Chief-Process-Officer ist für dieMitentwicklung der Unternehmensstrategie in Zu-sammenarbeit mit der Unternehmensleitung und den Abgleich mit dem Geschäftspro-zessmodell verantwortlich. Prozessmitarbeiter mit besonderer Erfahrung analysieren undüberarbeiten die Prozesse. Sie werden hierbei durch interne oder externe Berater unter-stützt. Prozessmodellierer überführen die Resultate in ein Prozessmodell. Der Prozessowner

2.3 Sichten der Prozessmodellierung 61

hat die Verantwortung für das entwickelte Prozessmodell. Die Rollen können je nach Un-ternehmensgröße auch in Personalunion wahrgenommen werden.

Die Workflow-Modellierung ist eine Aufgabe von Workflow-Modellierern bzw. vonSoftwareentwicklern. Sie überführen das betriebswirtschaftliche Geschäftsprozessmodellin ein ausführbares Workflowmodell. Sie führen auch die Simulation der Modelle durch,da hierfür meist spezifische Kenntnisse des Workflow-Management-Systems bzw. Model-lierungstools notwendig sind.

DieAusführung der Prozesse liegt in derVerantwortung der Prozessowner.Wahrgenom-men wird die Aufgabe von Prozessmitarbeitern im Unternehmen.

In der Praxis wird der vorgestellte Life-Cycle häufig nicht vollständig realisiert. Prozessesind oftnur teilweise oder gar nichtmit derUnternehmensstrategie verankert. Nur 35 %derim Rahmen einer Studie zum Prozessmanagement befragten Unternehmen gaben an, dieUnternehmensstrategie mit ihren Prozessen vernetzt zu haben (vgl. Gadatsch et al. 2007).Die Gründe sind meist eine fehlende Unternehmensstrategie (28%) und die fehlende Un-terstützung der Unternehmensleitung (38%). Relativ selten mangelt es am Know-how fürdie Durchführung (16%).

2.3 Sichten der Prozessmodellierung

Bei der Prozessmodellierung ist es nicht sinnvoll, alle modellierungsrelevanten Sachver-halte in einer einzigen Darstellung abzubilden. Zur Reduktion der Komplexität und zurVerbesserung der Verständlichkeit und Transparenz der Modelle empfiehlt sich die An-wendung eines Sichtenkonzeptes (vgl. Sinz 1996). Die Abb. 2.4 gibt eine Übersicht überdie in einigen Modellierungsansätzen verwendeten Sichten (erweiterte Darstellung in An-lehnung an Gehring 1998).

Gadatsch

Prozess-Sicht

Organisations-struktursicht

Aktivitäts -struktursicht

Applikations-Struktursicht

Informations-struktursicht

Gadatsch

Prozessss-Sicht

Organisationss-struktursicht

Aktivitäts -struktursicht

Applikations-Struktursicht


Gehring

Organisations-Sicht

Funktions-sicht

Datensicht

Gehring

Organisationss-Sicht

Funktionss-sicht

Datensicht

Ferstl/Sinz

Leistungssicht

Lenkungssicht

Ablaufsicht

Ferstl/Sinz

Leistungssicht

Lenkungssicht

Ablaufsicht

Österle

Organisation

Funktionen

Daten

[Personal]

[...]

Österle

Organisation

Funktionen

Daten

[Personal]

[...]

Scheer

Organisations-Sicht

Funktionssicht

Datensicht

Leistungssicht

Becker

Organisation

Geschäfts-objekt

Prozess

Ressource

Sichtenkonzepte der Geschäftsprozessmodellierung

Weske

Function Modeling

InformationModeling

OrganizationModeling

IT LandscapeModeling

Weske

Function Modeling

InformationModeling

OrganizationModeling

IT LandscapeModeling

Scheer

Organisations-Sicht

Funktionssicht

Datensicht

Leistungssicht

Scheer

Organisations -Sicht

Funktionssicht

Datensicht

Steuerungssicht

Leistungssicht

Abb. 2.4 Sichtenkonzepte Geschäftsprozessmodellierung



Aktivitäts-struktursicht

Applikations-struktursicht


Prozesssicht


Aktivitäts-struktursicht

Applikations-struktursicht


Prozesssicht

Wer?(Abt., Person)Wer?(Abt., Person)

Was?(Aufgabe)Was?(Aufgabe)

Womit? (Werkzeug)Womit? (Werkzeug)

Womit?(Information)Womit?(Information)

Wie?(Ablauf)Wie?(Ablauf)

Abb. 2.5 Prozess- und Struktursichten (Gadatsch 1999)

Der PICTURE-Ansatz von Becker et al. (2007, 2008) hat das Ziel, einen Überblick überdie Prozesslandschaftzu vermitteln undMaßnahmen für die Reorganisation zu unterstütz-ten. Zur Unterstützung dieser betriebswirtschaftlichen Ziele werden vier Sichten vorge-schlagen: Organisationssicht (Wer führt etwas aus?), Geschäftsobjektsicht (Waswird verar-beitet/produziert?), Prozesssicht (Was wird wie ausgeführt?) und Ressourcensicht (Womitwird etwas ausgeführt?). Diese Sichten werden in vier Modelltypen realisiert: Geschäftsob-jektmodell, Organisationsmodell, Prozessbaustein und Ressourcenmodell.

Der in Abb. 2.5 dargestellte Ansatz untergliedert im Hinblick auf die Berücksichtigungder Belange der Workflow-Modellierung in eine zentrale Prozess-Sicht und vier ergänzen-de Struktursichten (vgl. Gadatsch 2000, S. 179 f.). Die Prozesssicht beschreibt die an einemProzess beteiligten Modellierungsobjekte aus ablauforientierter Sicht. Die Struktursichtenbeschreiben die Struktur der Modellierungsobjekte, die in der Prozess-Sicht zusammenge-führt werden.

Gehring orientiert sich bei der Sichtenbildung an den Grundelementen der Prozessmo-dellierung, dem Prozess, den organisatorischen Strukturen und den Daten (vgl. Gehring1998).

Österle spricht bei seinem Konzept nicht von Sichten, sondern von Gestaltungsdimen-sionen (vgl. Österle 1995). Er nennt zwar Organisation, Daten, Funktionen und Personalals Dimensionen des Business Engineering, bezieht aber die Personaldimension nicht indas Konzept ein. Eine separat ausgewiesene „dynamische“ Dimension existiert nicht. Wohlwerden aber dynamische Aspekte bei der Darstellung von Prozessen mit Aufgabenketten-diagrammen berücksichtigt (vgl. Abb. 2.6).

Scheer nimmt eine Zerlegung nach fünf Sichten vor. Dabei werden die primär stati-schen Beschreibungsobjekte von Geschäftsprozessen in der Organisations-, der Daten-,der Funktions- und der Leistungssicht abgebildet. Die dynamischen Aspekte werden inder Steuerungssicht zusammengefasst (vgl. Scheer 1998a,b).

2.4 Methoden der Prozessmodellierung 63

Sichten

Eben

enOrganisation

z. B.Datenz. B.

Funktionenz. B.

Personalz. B.

...

Geschäfts-strategie

Prozeß

Informations-system

Geschäfts-felder

Daten-banken

Applika-tionen

Karriere-plan

Aufgaben Entitätstypen Trans-aktionen

Team-bildung

Verantwort-lichkeiten

Attribute Dialog-flüsse

Mitarbeiter-bewertungen

Abb. 2.6 Sichten nach Österle (1995)

Weske gliedert in die Modellierungsdomänen Function Modeling, Information Mode-ling, Organization Modeling und in IT-Landscape Modeling (vgl. Weske 2007, S. 77). Erträgt damit der besonderen Bedeutung der Informationstechnik Rechnung.

Prozessurale Konzepte (Gadatsch, Gehring, Scheer, Österle) betrachten den Prozessbzw. die Funktion als zentrales Element, welches Daten mit Hilfe von Organisationsein-heiten transferiert. Objektorientierte Konzepte (hier Ferstl und Sinz 1990) betrachten denProzess als Ganzes und verzichten auf Detailsichten zur Darstellung von Daten und Orga-nisationseinheiten.

2.4 Methoden der Prozessmodellierung

2.4.1 Klassifizierung

Mittlerweile wurden zahlreiche Methoden zur Modellierung von Geschäftsprozessen undWorkflows entwickelt, die hier nicht im Einzelnen vorgestellt werden können. Im Rahmendes Business Reengineering und der Geschäftsprozessoptimierung erfolgt eine Analyse derIst- und Soll-Geschäftsprozesse sowie deren Gestaltung und Dokumentation. Hierzu wer-den Geschäftsprozessmodelle erstellt, welche die Geschäftsprozesse formal beschreiben.Workflow-Modelle dienen der detaillierten Spezifikation der Geschäftsprozesse mit demZiel einer Ausführung durch ein WFMS. Sie werden aus Geschäftsprozessmodellen durchVerfeinerung abgeleitet.

Formale Methoden zur Modellierung von Prozessen lassen sich in Skriptbasierte Me-thoden (Skriptsprachen) und grafischeMethoden (Diagrammsprachen) unterteilen. Skript-sprachen erlauben die Beschreibung von Prozessmodellen mit einer an Programmierspra-


DiagrammbasierteMethoden

Datenfluss-orientiert

IDEF-Diagramme Petri-Netze

StruktoprogrammeDatenfluss-diagramme (SSA)

Use Case Diagram(UML)

Statechart-Diagramm

Activitychart-Diagramm

Interaktions-diagramm (SOM)

Swimlane-Diagramme

Folgestrukturund Folgeplan

Wertsachöpfungs-kettendiagramm

(WKD)PICTURE

ObjektorientierteEPK

Business ProcessModeling Notation

(BPMN)

Flussdiagramme(SADT) GPM-Diagramme

Aufgabenketten-diagramm(PROMET)

ErweiterteEPK

Activity Diagram(UML)

Vorgangsereignis-schema (SOM)

Kontrollfluss-orientiert Objektorientiert

Abb. 2.7 Übersicht über ausgewählte Diagrammsprachen

chen angelehnten formalen Notation. Hierdurch ist eine sehr hohe Präzision der Modell-spezifikation erzielbar. Allerdings ist die Anschaulichkeit der Prozessskripts gering undderen Interpretation setzt detaillierte Methodenkenntnisse voraus, was den Einsatz in derPraxis erschwert.

Diagrammsprachen lassen sich in datenfluss-, kontrollfluss- und objektorientierte An-sätze differenzieren (vgl. Abb. 2.7).

Datenflussorientierte Methoden werden immer seltener eingesetzt. Aus der Softwa-reentwicklung übernommene Darstellungstechniken wie die Struktogrammtechnik (vgl.Nollau und Schambeck 2004) haben in der Praxis für die Geschäftsprozessmodellierungkeine nennenswerte Bedeutung erlangt undwerden daher hier nicht weiter behandelt. Sehrstarke Verbreitung hat die von Keller, Nüttgens und Scheer entwickelte ereignisgesteuerteProzesskette gefunden, die zur Gruppe der kontrollflussorientierten Ansätze gezählt wird.Deshalb wird sie in einem späteren Kapitel sehr ausführlich behandelt. Objektorientier-te Konzepte finden in der Praxis zunehmend in Form von Acivity-Diagrammen (grobeBeschreibung der Prozesse auf hohem Abstraktionsniveau) und Use Case-Diagrammen(Zusammenhang zwischen Funktion und Organisationseinheit) Verbreitung.

Im Rahmen einer Umfrage zum Prozessmanagement wurde festgestellt, dass die eEPK-Methode sowie die Swimlane-Diagramme die am meisten genutzten Methoden sind. Die

2.4 Methoden der Prozessmodellierung 65

Nutzungshäufigkeit ausgewählter Methoden (Mehrfachangaben möglich) war wie folgt(vgl. Gadatsch et al. 2007):

• eEPK (43,1%),• Swimlane (38,8%),• UML (21,6%),• BPMN (16,4%),• Petri-Netze (3,4%),• SADT (44,0%),• IDEF-Diagramme (2,6%),• SOM (9,5%).

2.4.2 Begriffssystem

Die Aufgabe eines Begriffssystems besteht in der Abgrenzung und Kategorisierung vonmodellierungsrelevanten Sachverhalten und deren Benennung durch Begriffe (vgl. Geh-ring 1998). Beispiele sind die Benennung von Informationen, Tätigkeiten, Ablaufbeziehun-gen oder Zuordnungsbeziehungen. Sie spiegeln sich in der Notation derModellierungsme-thode wieder.

Geschäftsprozessmodelle bilden in der Regel folgende Aspekte ab (vgl. Kurbel et al.1997):

Prozess-Schritte, die zur Erstellung von Prozessleistungen erforderliche Tätigkeiten re-präsentieren. Synonyme Begriffe sind Vorgang, Aufgabe, Funktion und Arbeitsschritt.

Objekte werden in Prozessschritten bearbeitet und zwischen Prozessschritten ausge-tauscht. Beispiele sind Aufträge, Reklamationen oder Angebote. Objekte werden durchInformationsträger unterschiedlicher Darstellungsformwie z. B. E-Mail, Fax, Beleg, Doku-ment usw. repräsentiert. Die Weiterleitung von Objekten wird als Objektfluss bezeichnet.Bedeutungsgleiche Begriffe sind Informationsfluss, Datenfluss und Dokumentenfluss.

Abhängigkeiten zwischen Prozessschritten, die zeitlich, logisch oder technologisch be-dingt sind, definieren die Ablauflogik eines Geschäftsprozesses. Analoge Begriffe sind z. B.Steuerfluss und Kontrollfluss.

Aufgabenträger führen in Prozessschritten Tätigkeiten aus. Aufgabenträger sind z. B.Bearbeiter, Maschinen oder Programme. Alternative Begriffe sind Abteilung, Organisati-onseinheit, Funktionsträger usw.

2.4.3 Meta-Modell

Modelle dienen der Analyse und Gestaltung realer Systeme. Sie bilden ein Original- oderObjektsystem in ein Modellsystem ab. Da ein Modell die Struktur und das Verhalten einesObjektsystems möglichst originalgetreu widerspiegeln soll, sind an die Abbildung beson-


Abb. 2.8 Modellbildung(Gehring 1998)

dere Anforderungen zu stellen. Die Möglichkeit der formalen Beschreibung von Modell-systemen gestattet es, die übergeordnete Modellierungsebene der Meta-Modellierung (vgl.Gehring 1998) einzuführen (vgl. Abb. 2.8).

Ein Meta-Modell repräsentiert eine ganze Klasse von Modellsystemen; jedes Klassen-element stellt eine Instanz desMeta-Modells dar. Es stelltNotationsregeln für die Erstellungdes Modellsystems bereit. Es erlaubt die Überprüfung des Modellsystems auf Vollständig-keit und Konsistenz zum Objektsystem.

2.5 Datenflussorientierte Methoden

Die Bedeutung der datenflussorientierte Methoden der Prozessmodellierung hat in denletzten Jahren deutlich abgenommen. Allerdings ist es nach wie vor notwendig, Daten-aspekte angemessen in Prozessmodellen zu berücksichtigen. Prozessmodelle, welche dieDatenmodellierung vernachlässigen, sind nicht ausreichend (Meyer et al. 2011, S. 5). Da-her werden nachfolgend die wichtigsten datenflussorientierten Methoden vorgestellt, dasie aus historischer Sicht einen wichtigen Stellenwert haben.

2.5.1 IDEF (Integration Definition for Function Modeling)

Ende der 1970er Jahre wurde von der US Air Force die grafische Methode IDEF0 (Inte-gration Definition for Funktion Modeling) für die Geschäftsprozessmodellierung auf Basisder „Structured Analysis and Design Technology“ (SADT) entwickelt (vgl. National Insti-tute of Standards and Technology 1993, S. V). Das Modellierungsschema ist in Abb. 2.9dargestellt.

Weiterentwicklungen führten zur IDEF3-Methode, die eine Modellierung von Work-flows erlaubt. IDEF0 beschränkt sich auf zwei Grundelemente (Tätigkeitsbox und Pfeil).Eine Tätigkeitsbox repräsentiert eine Tätigkeit (Aktivität, Vorgang oder Prozess). Ein Pfeilbeschreibt Geschäftsobjekte (z. B. Karosserieteile für die Fahrzeugproduktion) oder Infor-mationen. Die Anordnung und Flussrichtung des Pfeils im Verhältnis zur Tätigkeitsboxbestimmt die Bedeutung des modellierten Sachverhaltes.

2.5 DatenflussorientierteMethoden 67

Fahrzeug fertigen

EingabeobjektInput

AusgabeobjektOutput

VorgabeobjektVorgaben fürdie Durchführung

ReferenzobjektAufruf von weiteren Modellen(Verfeinerung)

Betriebsmittel, Werkzeugeund Personal für die Durchführung

Fahrzeug fertigen

EingabeobjektEingabeobjektInputInput

AusgabeobjektAusgabeobjektOutputOutput

VorgabeobjektVorgabeobjektVorgaben fürVorgaben fürdie Durchführungdie Durchführung

ReferenzobjektReferenzobjektAufruf von weiteren ModellenAufruf von weiteren Modellen(Verfeinerung)(Verfeinerung)

Betriebsmittel, WerkzeugeBetriebsmittel, Werkzeugeund Personal für die und Personal für die DurchführungDurchführung

Abb. 2.9 Grundprinzip IDEF0-Diagramm

Tätigkeitsbox Beschreibung einer Tätigkeit (Aktivität,Vorgang oder Prozess), # = Knoten-Nrrr.

Pfeil(von links zur Box hinführend)

Benötigter Input für eine Tätigkeit. Beschreibung des Eingabeobjektes, das durch die Tätigkeit zu einem Ausgabeobjekt transformiert wird.

Symbol Benennung Bedeutung

Betriebsmittel, Werkzeuge und Personal für die Durchführung einer Tätigkeit. Es geht unverändert aus der Tätigkeit hervor.

Ausgabeobjekt einer Tätigkeit.

Tätigkeits-bezeichnung

Pfeil(von oben zur Box hinführend)

Pfeil(von unten zur Box hinführend)

Pfeil(nach rechts von der Box wegführend)

Pfeil(von oben von der Box wegführend)

Vorgabeobjekt, d. h. Vorgaben für die Durchführung der Tätigkeit, die durch die Tätigkeit nicht verändert werden (z. B. Verfahrensvorschriften, Pläne, Gesetze).

Referenzobjekt, Verweis bzw. Aufruf eines weiteren Modells, das in der nächsten Ebene verfeinert wird.

g#

Abb. 2.10 Notation IDEF0-Diagramm

IDEF0-Prozessmodelle werden stufenweise verfeinert. Hierzu werden detaillierte Pro-zessdarstellungen erstellt. Das Konstrukt des Referenzobjektes (senkrechter Pfeil von derBox wegführend) dient zum Verweis auf die Verfeinerung des Prozesses (vgl. die Notationin Abb. 2.10).

Die Abb. 2.11 zeigt ein IDEF0-Diagramm, das mit dem Modellierungswerkzeug BP-WIN erzeugt wurde (vgl. LogicWorks 1996).


1

ErfassenAnfrage

2

PrüfenVerfügbarkeit

3

AnlegenAngebotsauftrag

4

PrüfenKreditlimit

5

ErteilenAngebot

6

ErteilenAbsage

T

Anfrage

Anfragedaten

verfügbarer Bestand

Fehlteile

ungeprüfte Angebote

KundenimLimit

KundenaußerhalbLimit

Artikelbestand

Textverarbeitung

SAP R/3VertriebsmodulSD

SAP R/3FinanzmodulFI

KundendatenSAP R/3LogistikmodulMM

Artikeldaten

angefragteArtikel

Bestellanforderungan Einkauf

Abb. 2.11 IDEF0-Diagramm

Die Erweiterungen der IDEF3-Methode betreffen dieDarstellung der zeitlich-logischenAbhängigkeiten der Tätigkeiten, d. h. die präzise Modellierung des Kontrollflusses. DieIDEF3-Methode verwendet weitgehend eigene Symbole für die Darstellung von Aktivi-täten und des Kontrollflusses. Sie greift jedoch auf das Repository von IDEF0 zurück, d. h.sie kann die mit IDEF0 modellierten Objekte referenzieren. Hierdurch erfolgt eine strikteTrennung zwischenGeschäftsprozessmodell (IDEF0) undWorkflowmodell (IDEF3). Kernder IDEF3-Notation ist die aus IDEF0 übernommene Tätigkeitsbox (vgl. Abb. 2.12). DieTätigkeiten werden im Repository spezifiziert. Ein wichtiges Element ist die Verbindungs-box, die die für die Verknüpfung der Tätigkeiten notwendigen Bedingungen spezifiziert.

Die Abb. 2.13 zeigt ein IDEF3-Diagramm auf Basis des in Abb. 2.11 vorgestelltenIDEF0-Diagramms.

IDEF-Diagramme bieten eineNotation für die Geschäftsprozess-undWorkflowmodel-lierung an. Der Übergang von der Geschäftsprozess- zur Workflowmodellierung bewirktjedoch einenBruch in derDarstellung, da die Symbolik derNotationwechselt. Der Schwer-punkt der IDEF-Diagramme liegt auf der Darstellung von Aktivitäten und des Datenflus-ses. OrganisatorischeEinheiten können rudimentär als Betriebsmittelobjekte eingebundenwerden.

2.5.2 Datenflussdiagramme (SSA)

Die Methode Structured Systems Analysis (SSA) wurde von C. Gane und T. Sarson in densiebziger Jahren entwickelt und gehört zu den klassischen Softwareentwicklungsmethoden


Tätigkeitsbox Beschreibung einer TTätigkeit (Aktivittät,Vorgang oder Prozess)

Link Kontrollfluss zwischen TTätigkeiten bzw. Verbindungsboxen


Logischer Verknüpfungsoperator fffür asynchronen Kontrollfluß (nebenläufige, zeitlich unabhängige Aktivitäten)

Verbindungs-BoxSynchron

Verbindungs-BoxAsynchron

Logischer Verknüpfungsoperator fffürsynchronen Kontrollfluß (nebenläufige, gleichzeitig ablaufende Aktivittäten) Verbindungstypen: AND / OR / XOR

Tätigkeits-bezeichnungTTäätigkeitstigkeits--

bezeichnungbezeichnung

Knoten#

Verbin-dungs-

typ

VerbinVVerbin--dungsddungs--

typtyp

Verbin-dungs-

typ

VerbinVVerbin---dungsddungs---

typtyp

Relationaler Link Relationale Beziehung zwischen zwei TTTätigkeitsboxen

Abb. 2.12 Notation IDEF3-Diagramme

0.1.6

ErfassenAnfrage

0.1.7

PrüfenVerfügbarkeit

0.1.8

AnlegenAngebotsauftrag

0.1.9

PrüfenKreditlimit

0.1.10

ErteilenAbsage

0.1.11

ErteilenAngebot

J1

J2

Anfragedaten

KundenaußerhalbLimit

KundenimLimit

Fehlteile

verfügbarerBestand

ungeprüfteAngebote

Bestellanforderungan Einkauf

Abb. 2.13 IDEF3-Diagramm (Workflow-Modell)

(vgl. Gane und Sarson 1979). Sie erlaubt es, Informationssysteme unter Verwendung einesHierarchisierungskonzeptes auf der logischen Ebene in unterschiedlichen Detaillierungs-stufen auf der Grundlage einer grafischen Beschreibungssprache zu spezifizieren, ohneauf technische Implementierungsdetails einzugehen. SSA wird neben weiteren Entwurfs-methoden (vgl. z. B. de Marco 1979) unter dem Oberbegriff der Strukturierten Analysezusammengefasst. Structured Systems Analysis unterstützt mit dem Datenflussdiagrammauch die Modellierung von Arbeitsabläufen. Es stellt in grafischer Form den logischen Da-tenfluss und dessen Transformation durch Prozesse innerhalb von Informationssystemendar (vgl. Gane und Sarson 1979, S. 25 f. und die Notation in Abb. 2.14).



Datenfluß Datenfluß von einer Quelle zu einem Prozeß oder von einem Prozeß zu einem Prozeß oder einer SenkeName: Identifizierender Name desDatenflusses im Data Dictionary

Quelle oder Senke vonDaten

Ursprung oder Ziel von Datenflüssen a: Identifikation der Datenquelle bzw. DatensenkeName: Beschreibung der Datenquelle bzw. Datensenke

Prozeß: Transformation des Datenflusses Identifikation: Identifikation des Prozesses im Data DictionaryProzeßbeschreibung: Textuelle Beschreibung des ProzessesOrt: Physischer Ort der Durchführung des Prozesses

ProzeßProzeß-

beschreibung

Identifikation

Ort

ProzeßProzeß--beschreibungbeschreibung

IdentifikationIdentifikation

OrtOrt

NameNameName

DatenspeicherID NameIDID NameName DatenspeicherName: Identifizierender Name des Datenspeichers im Data Dictionary

Namea

NameNameNameNameaa

Abb. 2.14 Notationselemente Datenflussdiagramm (SSA)

Der Schwerpunkt von Structured Systems Analysis liegt auf der Beschreibung von In-formationssystemen unter besonderer Berücksichtigung des Datenflusses zwischen deneinzelnen Prozessen. Es fehlt jedoch eine explizite Darstellung der Prozesslogik, d. h. derKontrollfluss wird nicht transparent.

In Abb. 2.15 ist ein Datenflussdiagramm in der Notation der Structured Systems Ana-lysis nach Gane und Sarson dargestellt.

2.5.3 Flussdiagramme (SADT)

Die Strukturierte Analyse (Structured Analysis Design Technic, SADT) beschreibt ver-wandte Softwareentwicklungsmethoden, die aufbauend auf den Arbeiten von de Marco(1978) entwickelt wurden. In diesem Abschnitt wird die Ausgangsmethode beschrie-ben, nachdem zuvor bereits die Weiterentwicklung von Gane und Sarson behandeltwurde.

Ein Flussdiagramm beschreibt den Informations- und Datenfluss, der zwischen Funk-tionen, Daten- und Informationsspeichern und Schnittstellen ausgetauscht wird. Es be-schreibt das System aus der Sicht der Daten bzw. Informationen.Der Kontrollfluss wird da-her nicht beschrieben. Ein Flussdiagramm enthält vier Symbole: Funktion (Kreis), Schnitt-stelle zur Umwelt (Rechteck), Datenfluss (Pfeil) und Datenspeicher (2 parallel verlaufendeLinien), die in der Abb. 2.16 dokumentiert sind.

Ausgangspunkt der Modellierung ist die Erstellung eines Kontextdiagramms (vgl. Bal-zert 1997a, S. 398). Hierbei handelt es sich um eine minimale Form eines Flussdiagramms,die keine Speicher enthält und das zu modellierende System im Gesamtüberblick darstellt.Es enthält nur eine Funktion, welche die Gesamtfunktionalität des Systems repräsentiert.Funktionen werden anschließend stufenweise verfeinert.


Abb. 2.15 Datenflussdiagramm (SSA)


Datenfluss Datenfluß von einer Quelle zu einem Prozeß oder von einem Prozeß zu einem Prozess oder einer SenkeDatenflussname: Identifizierender Name des Datenflusses im Data DictionaryPfeilrichtung zum Datenspeicher hinführend: SchreibzugriffPfeilrichtung vom Datenspeicher wegführend: LesezugriffDoppelpfeil: Schreib-/Lesezugriff

Schnittstelle zur Umwelt(Quelle oder Senke vonDaten)

Ursprung oder Ziel von Datenflüssen Schnittstellenname: Beschreibung der Datenquelle bzw. Datensenke

Funktion oder Prozeß, der einen Datenfluß transformiertFunktionsname: Identifizierender Name der Funktion im Data Dictionary

Funktion bzw. Prozess

Datenflussname

DatenspeicherSpeichernameSpeichername Speicher von Informationen oder DatenSpeichername: Identifizierender Name des Datenspeichers im Data Dictionary

Schnitt-stellen-name

Schnitttt-stellen-name

Funktions-name

Abb. 2.16 Notation Flussdiagramm (SADT)


Kunde Einkauf0.

Angebots-bear-

beitung

Anfrage

Angebot

Absage

Fehlteiledaten

Debitoren-buchhaltung

Kre

ditli

mits

KundeKunde EinkaufEinkauf0.

Angebots-bear-

beitung

AnfrageAnfrage

AngebotAngebot

AbsageAbsage

FehlteiledatenFehlteiledaten

Debitoren-buchhaltungDebitoren-

buchhaltung

Kre

ditli

mits

Kre

ditli

mits

Abb. 2.17 Kontextdiagramm (SADT)

Abb. 2.18 Flussdiagramm (SADT)

Eine Funktion, die nichtmehr verfeinert werden kann, wird durch eineMinispezifikati-on (Mini-Spec) beschrieben. Beschreibungsgegenstand ist der Transformationsprozess dervon eingehenden Daten- bzw. Informationen zu ausgehenden Daten- bzw. Informationenführt. Hierzu werden die Einzelmethoden Pseudocode, Entscheidungstabelle oder Hierar-chiebaum eingesetzt. Datenflüsse und -speicher werden im Data Dictionary beschrieben.Die Abb. 2.17 zeigt ein Kontextdiagramm. Anschließend wird in Abb. 2.18 dessen Verfei-nerung als Flussdiagramm dargestellt.

2.6 KontrollflussorientierteMethoden 73

2.6 Kontrollflussorientierte Methoden

2.6.1 Petri-Netze

Petri-Netze werden häufig zur Modellierung von Geschäftsprozessen und Workflows ein-gesetzt. Sie beruhen auf den grundlegenden Arbeiten von C. A. Petri (vgl. hierzu den Ori-ginalbeitrag von Petri 1962 sowie den Artikel über sein Lebenswerk von Brauer 2006). EinPetri-Netz ist ein gerichteter Graph, der aus zwei Arten von Knoten besteht. Stellen (Krei-se) repräsentieren statische Zustände von Prozessen (z. B. Dokumente, Daten, Ressour-cen). Transitionen (Rechtecke) repräsentieren die Umformung von Informationen (z. B.Funktionen, Prozesse, Aktivitäten). Kanten verbinden unterschiedliche Arten von Kno-ten und stellen den Kontrollfluss dar. Im Gegensatz zu EPK-Modellen werden in Petri-Netzen keine Verknüpfungsoperatoren verwendet. Verknüpfungen werden implizit darge-stellt (Koschmider 2007, S. 235). Zur Darstellung des dynamischen Netzverhaltens werdendie Stellen mitMarken belegt, die sich aufgrund von Schaltregeln im Netz bewegen. Petri-Netze haben sich neben der Modellierung vor allem auch als geeignetes Instrument zurSimulation von Prozessen herausgestellt (vgl. z. B. Balzert 1997a, S. 298).

Aus den elementaren Petri-Netzen (Kanal/Instanzen-Netze, Bedingungs/Ereignis-Netze und Stellen/Transitionen-Netze)wurden höhere Petri-Netze (Prädikat/Transaktions-Netze, Zeitbewertete Netze, Hierarchische Petri-Netze) entwickelt, da einfache Petri-Netzefür Anwendungen in der Praxis nicht ausreichten (vgl. Desel und Oberweis 1996, S. 359).Die Anzahl der Varianten erlaubt es nicht, eine vollständige Aufzählung oder gar Beschrei-bung zu präsentieren. Daher wird eine Auswahl der gebräuchlichsten Petri-Netz-Variantenbehandelt.

Kanal/Instanzen-Netze (K/I-Netze) stellen eine einfache Formder Petri-Netze dar. Stel-len (Kreise) werden als Kanäle bezeichnet, Transitionen (Rechtecke) als Instanzen (vgl.Abb. 2.19). Die Elemente eines K/I-Netzes werden umgangssprachlich beschriftet und ha-ben eine Aussagekraft ähnlich der von einfachen Datenflussdiagrammen (vgl. Oberweis1996, S. 100).

Abb. 2.19 Einfaches Kanal/Instanzen-Netz



Kante Flussrelation als Verbindung zwischen Stellen und Transitionenw: Gewicht einer Kante, entspricht der Anzahl der Marken, die von einer Stelle zu einer Transition bzw. umgekehrt überführt werdenkönnen

Stelle Repräsentation statischer Zustände von Prozessen (z. B. Dokumente, Daten, Ressourcen)k: Kapazität einer Stelle, entspricht der Anzahl der Marken, dieaufgenommen werden können. Keine Angabe = unendliche Kapazität

Marke bildet dynamisch aktuellen Zustand des Kontrollflusses ab

Repräsentation dynamischer Umformungen von Informationen (z. B. Funktionen, Prozesse, Aktivitäten)k: Kapazität einer Transition, entspricht der Anzahl der Marken, die während eines Schaltvorgangs von den Eingabestellen entnommen werden.

Transition

www

1

k

Beschriftung

kk

BeschriftungBeschriftung

k

Beschriftung

kk

BeschriftungBeschriftung

Abb. 2.20 Notation Petri-Netze (Stellen/Transitionen-Netze)

In Bedingungs/Ereignis-Netzen (B/E-Netze) werden Stellen als Bedingungen undTransitionen als Ereignisse bezeichnet. Stellen bilden nur zwei Zustände ab (Enthält Mar-ke/leer). Eine Transition kann schalten, wenn alle Eingangsstellen eine Marke enthaltenund die Ausgangsstellen leer sind.

Die geringeModellierungsmächtigkeit führte zur Entwicklung von Stellen/Transitions-Netzen (S/T-Netze), deren Stellen mehrere Marken enthalten können. Zusätzlich könnendie Kanten mit Gewichten versehen werden, d. h. eine oder mehrere Marken zwischen denStellen transportieren. Ein Schaltvorgang in S/T-Netzen ist dann möglich, wenn in denEingangsstellen ausreichend Marken und in den Ausgangsstellen unter Berücksichtigungder Kantengewichte ausreichende Kapazitäten zur Aufnahme vonMarken vorhanden sind.

Prädikat/Transitionen-Netze (Pr/T-Netze) unterscheiden sich durch die Art der Mar-ken. Während die Marken einfacher Petri-Netze identisch sind („Schwarze Marken“), un-terscheiden sich die Marken von Prädikat/Transaktionen-Netzen („Farbige Marken“), d. h.die Marken können Informationen tragen. Sie werden daher auch als farbige Petri-Netzebezeichnet.

Die Durchführung von Prozessen bedingt einen Verbrauch an Zeit. Die Abbildung desZeitphänomens führte zur Entwicklung zeitbewerteter Petri-Netze, d. h. der Transitionwird ein Zeitverbrauch zugeordnet, der die Verzögerung zwischen Entnahme vonMarkenin den Eingangsstellen und Ausgabe der Marken repräsentiert.

Hierarchische Petri-Netze erlauben die sukzessive Verfeinerung der Netze durch De-taillierung von Stellen oder Transitionen.

Die Tab. 2.1 fasst wesentliche Aussagen zusammen.Anhand von Stellen/Transitionen-Netzen wird nun diskutiert, welche grundsätzlichen

Möglichkeiten der Prozessmodellierung mittels Petri-Netzen bestehen. In Abb. 2.20 wirddie Notation von Stellen/Transitionen-Netzen dargestellt.

Die Abb. 2.21 zeigt ein Beispiel für ein Stellen/Transitionen-Netz. Vor dem Schalten derTransition T1 liegen in der Eingangsstelle S1 3 Marken. Die Eingangskante zu T1 trans-


Tab. 2.1 Merkmale gebräuchlicher Petri-Netz-Varianten

Grundtyp Name Stelle Transition Kante MarkeEinfachePetri-Netze

Kanal/Instan-zen-Netz (K/I-Netz)

Kanal Instanz Ungewichtet Nicht vor-handen

Bedingung/Ereignis-Netz(B/E-Netz)

Bedingung(eine Mar-ke)

Ereignis(eine Mar-ke)

Ungewichtet(Transporteiner Marke)

IdentischerInformati-onsgehalt(schwarzeMarken)

Stellen/Transitionen-Netze (S/T-Netz)

Stelle (kannmehrereMarkenenthalten)

Transition(mehrereMarken)

Ganzzahliggewichtet

IdentischerInformati-onsgehalt(schwarzeMarken)

HöherePetri-Netze

Prädikat/Transitionen-Netz (Pr/T-Netz)

Prädikat(kann meh-rere Markenenthalten)

Transiti-on (kannmehrereMarkenenthalten)

Ganzzahliggewichtet

Unter-schiedlicherInformati-onsgehalt(farbige Mar-ken)

ZeitbewerteteNetze

Abhängigvom Netz-typ

Abhän-gig vomNetztyp

Mit demZeitverbrauchgewichtet

Abhängigvom Netztyp

HierarchischeNetze

Abhängigvom Netz-typ

Abhän-gig vomNetztyp



Abb. 2.21 Beispiel für Schaltvorgänge von Petri-Netzen

portiert je Schaltvorgang zwei Marken. Die Ausgangskanten transportieren ebenfalls jezwei Marken zu den Stellen S2 und S3, die für einen Schaltvorgang noch ausreichend freieKapazitäten zur Verfügung haben. Nach dem Schaltvorgang ist die Stelle S2 mit der Ma-ximalkapazität bestückt. Die Eingangsstelle S1 hat für einen weiteren Schaltvorgang keineausreichenden Marken.


Die Darstellung in Abb. 2.22 zeigt ein Stellen/Transitionen-Netz, wobei auf die Einfär-bung mit Marken verzichtet wurde, um die Darstellung übersichtlich zu halten.

Der Hauptvorteil von Petri-Netzen gegenüber anderen Konzepten, ist der einfache An-satz. Sie bestehen aus nur wenigen Modellelementen. Reale Sachverhalte lassen sich jedochhäufig nur mit höheren Petri-Netzen abbilden.

Petri-Netze werden von Anwendern teilweise als zu komplex und schwer verständ-lich angesehen. Die Vielzahl der entwickelten Varianten führte zudem zu uneinheitlichenNotationen. Petri-Netze sind daher wenig für die Entwicklung betriebswirtschaftlich ori-entierter Geschäftsprozessmodelle und deren Diskussion mit Anwendern im Rahmen derIst-Analyse und Sollkonzeption von Prozessen geeignet.

2.6.2 Swimlane-Diagramme

Der Begriff „Swimlane“ wurde zum Namensgeber für ein ursprünglich Anfang der 1990erJahre unter dem Terminus „Organisationsprozessdarstellung (OPD)“ vonH. F. Binner ent-wickeltes Ablaufdiagramm (vgl. Binner 2004). Swimlanes sind analog einer SchwimmbahnVerantwortungsbereiche für Akteure, zwischen denen die zugeordnete Verantwortung füreinen Prozessabschnitt hin und her pendelt, bis der Ablauf abgeschlossen ist. Sie weiseneine gewisse Ähnlichkeit mit den Aktivitätendiagrammen der UML-Notation oder denAufgabenkettendiagrammen von Österle auf.

Die Notation (vgl. Abb. 2.23) wurde verschiedentlich weiterentwickelt und kann je nachEinsatzzweck (grobes Prozessmodell, detailliertes Workflow-Modell) unterschiedlich aus-geprägt werden (vgl. z. B. Sharp und McDermott 2001, S. 144 f. und 158 f.).

Sie kommt in der einfachsten Form mit sehr wenigen Elementen aus und ist dahereinfach zu erlernen. Für die Workflow-Modellierung stehen präzisierende Elemente (u. a.Kontrollflussoperatoren, Wahrscheinlichkeiten) zur Verfügung.

Die Abb. 2.24 zeigt ein Beispiel mit der minimalen Notation für einen Auftragsbearbei-tungsprozess.

Swimlane-Diagramme sind einfach zu erlernen und anschaulich gestaltet. Sie benötigenjedoch sehr viel Platz für die Darstellung komplexer Prozesse.

Nach Auskunft eines erfahrenen Modellierungspraktikers1 wurden in seinem Unter-nehmenmit der Swimlane-Methode schlechte Erfahrungen gesammelt. Viele Modelle wa-ren nur im DIN A3-Ausdruck darstellbar und fanden wenig Akzeptanz bei den Mitarbei-tern der Fachabteilungen.

1 Interview mit einem Modellierungsberater eines großen Unternehmens (DAX30 notiert), geführtam 20.09.2007 im Rahmen eines Erfahrungsaustausches


Abb. 2.22 Beispiel für ein Petri-Netz (S/T-Netz)



XORXORXOR Logischer Operator “exclusives oder”Logischer Operator “oder”

Logischer Operator “und”

Ergänzend können für Workflowmodellelogische Verknüpfungsoperatoren genutztwerden

Prozess-Schritt Abbildung von Gegenständen der realen Welt

Kontrollfluss Zeitlich-logischer Ablauf der Prozess-SchritteErgänzung um Verzweigungen (Ja, Nein) und Wahrscheinlichkeiten in %

Swimlane Zuständigkeitsbereich von Akteuren / Handlungsträgern(Personen, Abteilungen, Unternehmen

Akteur 1

Akteur …

Akteur n

Text Verzweigung Verzweigung im Ablauf

Name Dokument Ablaufbezogenes Dokument, Datenbank oder Informationsobjekt

Abb. 2.23 Notation Swimlane-Diagramm

Abb. 2.24 Swimlane-Diagramm (Beispiel)

2.6.3 Ereignisgesteuerte Prozesskette (eEPK)

Die Methode der Ereignisgesteuerten Prozesskette (EPK) wurde Anfang der 1990er Jah-re von Keller, Nüttgens und Scheer auf der Grundlage von Petri-Netzen entwickelt (vgl.


Symbol Benennung BedeutungEreignis Beschreibung eines eingetretenen Zustandes, von dem der weitere

Verlauf des Prozesses abhängt

Funktion Beschreibung der Transformation von einem Inputzustand zu einem Outputzustand.

XORXORXOR Logischer Operator “exclusives oder”Logischer Operator “oder”

Logischer Operator “und”

Logische Verknüpfungsoperatoren beschreiben die logische Verknüpfung von Ereignissen und Funktionen.

Organisatorische Einheit Beschreibung der Gliederungsstruktur eines Unternehmens

Informationsobjekt Abbildung von Gegenständen der realen Welt

Datenfluß Beschreibung, ob von einer Funktion gelesen, geschrieben oder geändert wird.

Zuordnung Zuordnung von Ressourcen/ Organisatorischen Einheiten

Prozeßwegweiser Horizontale Prozeßverknüpfung

Kontrollfluß Zeitlich-logischer Zusammenhang von Ereignissen und Funktionen

Abb. 2.25 Basisnotation der EPK

Keller et al. 1992). Sie hat sich in der Unternehmenspraxis als federführende Methode zurgrafischen Modellierung von Geschäftsprozessen etabliert.

Wegen der großen Praxisrelevanz der EPK wird die Methode ab S. 205 ausführlich be-handelt. Die Abb. 2.26 zeigt im Vorgriff auf detailliertere Betrachtungen die Basisnotationder EPK (in Anlehnung an Keller und Teufel 1997, S. 166 ff.).

DieMethode ist vergleichsweise leicht erlernbar und eignet sich deshalb gut für die Dis-kussion zwischen IT-Spezialisten und Mitarbeitern in der Fachabteilung, z. B. im Rahmender Ist-Erhebung von Prozessen sowie deren Restrukturierung. Die Abb. 2.26 zeigt ein sehreinfaches EPK-Beispiel aus der Vertriebslogistik.

2.6.4 Aufgabenkettendiagramm (PROMET)

Die Methode PROMET wurde von Österle zur Prozess- und Systementwicklung konzi-piert (vgl. Österle 1995). Sie verbindet die Geschäftsstrategie, die daraus abgeleiteten Pro-zesse und die prozessunterstützenden Informationssysteme. Die Prozessmodellierung er-folgt mit dem Aufgabenkettendiagramm als gerichteter Graph, der durch unterschiedlicheKnoten- und Kantentypen auf einem in Spalten gegliederten Arbeitsformular dargestelltwird. Knoten beschreiben Aufgaben, Bedingungen, Datenobjekte und Ereignisse. Kan-ten beschreiben zeitliche Abhängigkeiten zwischen den Aufgaben (vgl. die Notation inAbb. 2.27). Die Spalten des Arbeitsformulars repräsentieren Organisationseinheiten oderApplikationen und gehen daher über den Ansatz der Swimlane-Diagramme etwas hinaus.


Auftragangelegt

Kreditlimitprüfen

XORXORRXXOR

Kredit-limit im Rahmen

Kredit-limit über-schritten

Angeboterstellt

Angeboterstellen

Kunden-stamm

Buch-haltung

Vertrieb

SAP R/3 FI

SAP R/3 SD

Kunden-stamm

Auftrags-gdaten

Anbebot-daten

Schrifttt-wechsel

Auftrags-gbearbeitung

Kunden-stamm

Auftrags-gdaten

Abb. 2.26 Beispiel zur EPK

Der Bedingungsknoten (Raute) stellt nur den logischen Operator „Exklusives Oder“zur Verfügung.

Die spaltenorientierte Darstellung erschwert die übersichtliche Darstellung komplexerModelle und führt leicht zuÜberschneidungen der Kanten (vgl. dasModellierungsbeispielin Abb. 2.28).

2.6.5 PICTURE-Methode

Die von Becker et al. (2007, 2008) am European Research Center for Information Sys-tems primär für den öffentlichen Bereich entwickelte PICTURE-Methode wurde konzi-piert, um einen Überblick über die Prozesslandschaft einer Verwaltung zu vermitteln unddieGrundlage für Prozessveränderungen zu schaffen.Hierzu stehen derzeit 24 Prozessbau-steine und andere Modellierungsobjekte zur Verfügung. Prozessbausteine bilden typischein Prozessen auftretende Tätigkeiten ab, z. B. Formelle Prüfung durchführen, Auszahlungdurchführen, Dokument vervielfältigen/kopieren, Dateneingabe in die EDV, Informati-



Kontrollfluss(mit Verzögerung)

Aufgabensequenz mit Zeitverzug, d. h. die nachfolgende Aufgabe kann erst zeitlich verzögert nach Abschluß der vorangegangenen Aufgabe starten

Kontrollfluss(parallele Ausführung)

Die mit einer doppelten Line verbundenen Aufgaben können parallel ausgeführt werden

Kontrollfluss(ohne Verzögerung)

Sequenz ohne Zeitverzug, d. h. die nachfolgende Aufgabe kann nach Abschluß der vorangehenden Aufgabe starten

entfällt Aufgaben die nicht miteinander verbunden sind, sind nebenläufig, d. h. sie können unabhängig voneinander (nach- oder nebeneinander) ausgeführt werden

entfällt

DDBB-IID

Datenbankzugriff Zugriff von Applikationen auf DatenbankenDB-ID: Datenbank-Identifikation

Ereignis Auslöser oder Ergebnis eines AblaufesBez.: Bezeichnung des Ereignisses

Bez.Bez.Bez.

ProzessübergangProzess-

Bez.ProzessProzess--

Bez.Bez.

Übergang von und zu einem Prozess oder Sub-Prozess (Prozessschnittstelle)Prozess-Bez.: Bezeichnung des Übergangsprozesses

Abb. 2.27 Notation Aufgabenkettendiagramm (Promet)

KundeAnfragen-/Angebots-

bearbeitungVertrieb Einkauf Debitoren-

buchhaltung DB’s

(1)Prüfen Material-

verfügbarkeitSAP R/3 MM

Ver-fügbar

?

(2)Anlegen

AngebotsauftragSAP R/3 SD

Absage

Applikationen

KUNDE

(7)Erstellen Be-

stellanforderungSAP R/3 MM

(5)ErteilenAngebot

SAP R/3 SD

Nein

Ja

MATERIAL

ANFRAGE

ANGEBOT

ABSAGE

über-schritten?

Angebot

Kunde er-hält Absage

Ja

Nein

Kunde er-hält Angebot

(6)Erteilen Absage

PC Textverarb.

(6)Prüfen

KreditlimitSAP R/3 FI

Kunde-

Angebots-bearbeitung

Vertrieb Einkauf Debitoren-buchhaltung DB’s

(1)Prüfen Material-

verfügbarkeitSAP R/3 MM

Verrr-fügbar

?

(2)Anlegen

AngebotsauftragSAP R/3 SD

AbsageAbsage

Applikationen

KUNDE

KUNDE

(7)Erstellen Be-

stellanforderunggggSAP R/3 MM

(5)ErteilenAngebotg

SAP R/3 SD

Nein

????Ja

MATERIAALLLL

ANFRAGE

ANFRAGEEEEE

ANGEBOT

ANGEBOTTTTT

ABSAGE

ABSAGE

über-schritten?

AngebotAngebot

Kunde erKunde er-r-hält Absagegehhält Absage

Ja

Nein

Kunde erKunde er-r-hält Angebotothhält Angebot

(6)Erteilen Absage

PC Textverarb.

(6)ErteilenAbsageg

PCgg

bbbbbbbbbbTextverarTextverarb...

(6)Prüfen


Anfragen /

Anfrageist erfaßt

(6)Prüfen


(6)Erteilen Absage

PC

Abb. 2.28 Beispiel Aufgabenkettendiagramm (Promet)


Abb. 2.29 PICTURE Prozessbaustein (Becker et al. 2008)

on/Dokument versenden. Wenn möglich, wird die Fachsprache der jeweiligen Domäneverwendet, um die Verständlichkeit derModelle imHinblick auf die Verwaltungsmitarbei-ter zu erhöhen. Im Vergleich zu anderen kontrollflussorientierten Modellierungssprachenwird die Anzahl der Modellkonstrukte deutlich reduziert, u. a. dadurch dass Modellie-rungsinhalte in Attributen der Prozessbausteine integriert werden.

In Abb. 2.29 ist die grafische Repräsentation eines Prozessbausteins mit einigen Merk-malen dargestellt.

In der Abb. 2.30 wird ein mit der PICTURE-Methode modellierter Verwaltungspro-zess (Wohngeldbearbeitung) dargestellt. Die Darstellung zeigt deutlich die Ähnlichkeitmit dem von Scheer bzw. Österle verwendeten Vorgangsketten- bzw. Aufgabenketten-diagrammen.

2.6.6 GPM-Diagramme

Hinter der Ganzheitlichen Prozessmodellierung (GPM) steht ein durchgängiges KonzeptzurModellierung vonGeschäftsprozessen undWorkflows einschließlich deren SimulationundAnalyse (vgl. Gadatsch 2000). GPM-Diagramme basieren auf einemMeta-Modell undbeschreiben repositorygestützt Prozesse auf der Ebene von Geschäftsprozessen. Sie lassensich medienbruchfrei zu Workflowmodellen verfeinern.

Da das Konzept in Gadatsch (2000) detailliert vorgestellt wird, soll an dieser Stelle nurkurz die Notation (Abb. 2.31) und ein einfaches Beispiel (Abb. 2.32) vorgestellt werden.


Abb. 2.30 PICTURE ModellierungsbeispielWohngeldbearbeitung (Becker et al. 2008)


Organisation (z. B. Unternehmen, Tochtergesellschaft) oder Organisationseinheit(z. B. Bereich, Abteilung, Projekt)

Organisations-einheit

Organisation

OrganisationsOrganisations--einheiteinheit

OrganisationOrganisationAktivitätsträger

GP-ID: Identifikation des Geschäftsprozesses im RepositoryGeschäftsprozessbezeichnung: Bezeichnung des Geschäftsprozesses im RepositoryIS: Bezeichnung des InformationssystemsApplikation: Bezeichnung der ApplikationGPD: Geschäftsprozess//-schritt der ggf. weiter verfeinert wirdWFD: Geschäftsprozess-Schritt der als Workflow verfeinert wird.

Geschäftsprozess oderGeschäftsprozess-schritt

GPD|WFD

Geschäftsprozess-bezeichnung

GP-ID

ISApplikationGPD|WFDGPD|WFD

Geschäftsprozess-bezeichnung

GP-ID

ISApplikation

GeschäftsprozessGeschäftsprozessGeschäftsprozess---ggbezeichnungbezeichnungbezeichnung

GPGPGP---IDIDID

ISISISApplikationApplikationApplikation

OrganisatorischerZuordnung

Aktivitätsträger steuert den zugeordneten Geschäftsprozess. Er ist Prozesseigner

Verknüpfung der Objekte Ereignis, Geschäftsprozess und Verknüpfungsoperator hinsichtlich der zeitlich-logischen Abfolge

Kontrollfluss

XORXORXOR Verknüpfungs-operatoren

Exklusives Oder, Und, Oder

Datenspeichername Datenspeicher Maschinell zu verarbeitender Informationsträger Datenspeichername: Identifizierender Name im Repository

Abb. 2.31 Notation Geschäftsprozessdiagramm


Abb. 2.32 Beispiel Geschäftsprozessdiagramm (Gadatsch 2000)

2.6.7 Folgestruktur und Folgeplan

Ende der 1970er Jahre wurden von Schmidt u. a. die Darstellungsmethoden „Folgestruk-tur“ und „Folgeplan“ sowie die aus der strukturierten Programmierung abgewandeltenStruktogramme als „Geblockter Text“ entwickelt (vgl. zur Historie und Methode Fischer-manns 2006). Sie dienen der Dokumentation und Analyse von Prozessen und toolgestütztauch zur Simulation. Ein auf die Methode zugeschnittenes Werkzeug wurde unter demProduktnamen „Ablauf Profi“ bzw. später „Prometheus“ von der IBO GmbH Anfang der1980er Jahre entwickelt.

Die Darstellungsform „Folgestruktur“ beschreibt in Spaltenformmit zahlreichen grafi-schen Elementen die Ablauffolge und organisatorische Zuordnung der Tätigkeiten, alsoden Kontrollfluss. Im linken Teil der Darstellung wird der Geschäftsprozess dargestelltund im rechten Teil detailliert beschrieben. Sie benötigt daher vergleichsweise viel Platzund richtet sich eher an den Organisationsberater, als an den Mitarbeiter in der Fach-abteilung.

Die Darstellungsform „Folgeplan“ (vgl. Fischermanns 2006) verzichtet auf die Spalten-struktur und beinhaltet andererseits zur Verbesserung der Verständlichkeit weitere Detailsmit der Folge eines erhöhten Platzbedarfs. Der Folgeplan leitet sich direkt aus der Folge-struktur ab und ist weitgehend selbsterklärend. Die Trennung von Ablauf und Erläuterungwird aufgehoben, stattdessen werden die Prozesselemente stärker beschriftet. Daher eignetsich der Folgeplan besser für Präsentationen, z. B. vor Mitgliedern der Fachabteilung.



Aufgaben oder Aufgabenträger innerhalb des Unternehmens, z.B. Personen oder Abteilungen

Internes Element

Externe Aufgaben oder Aufgabenträger, z.B. Kunde, Lieferant, BeraterExternes Element

Computerprogramme, Telefone, FahrzeugeSachmittel

Prozessbeginn und -endeQuelle / Senke

Sonderfälle im ProzessablaufZeitliche Unter-brechung

Elektronische Datenbestände, z. B. Kundendatenbanken, Dateien

Konventionelle Datenbestände, z. B. Kartei, Liste, KonventionelleDateien

Verzweigungen im KontrollflussVerzweigung

Kontrollfluss Zeitlich-logischer Zusammenhang der Ablaufstruktur

Unterprozess/Teilprozess

Ausgliederung eines selbständigen Teilprozesses in ein separatesDiagramm

Abb. 2.33 Notation Folgestruktur und -plan

Die hier nicht weiter behandelte Darstellung „Geblockter Text“ entspricht weitgehendden aus der strukturierten Programmierung bekannten Struktogrammen, die hier aller-dings für die Beschreibung des Prozesses und nicht der inneren Logik eines Programmsverwendet werden.

In der Abb. 2.33 ist auszugsweise die Notation der Darstellungsformen Folgestrukturund Folgeplan dargestellt. Die vollständige Notation wird in Fischermanns (2006) behan-delt.

Ein Beispiel für eine Folgestruktur zeigt Abb. 2.34. Die Abb. 2.35 beschreibt den aus derFolgestruktur abgeleiteten Folgeplan.

2.6.8 Business Process Modeling and Notation (BPMN)

Die Business Process Model and Notation (BPMN) ist eine international standardisiertegrafischeMethode zur grafischen Prozessmodellierung. Sie unterstützt die Darstellung vonArbeitsabläufen (Prozessen) im Rahmen des Geschäftsprozessmanagements und die rech-nergestützte Ausführung (Workflow-Management) der Prozesse. In der Schweiz gilt siebereits als Standard, der für Unternehmen und Behörden bevorzugt zum Einsatz kommt(vgl. eCH 2011). Sie stellt zahlreiche normierte Symbole zur Verfügung, mit denen fachli-che und technische Aspekte abgebildet werden können. Als erste standardisierte Methodeverbindet sie die betriebswirtschaftliche und technische Sicht auf Prozesse.

BPMN wurde von Stephen A. White (IBM-Mitarbeiter) zur graphischen Darstellungvon Geschäftsprozessen entwickelt (vgl. White 2004). Die Weiterentwicklung der Metho-de wird derzeit durch die Object Management Group (OMG, vgl. www.omg.org) verant-wortet, einem Konsortium, das sich u. a. mit der herstellerunabhängigen Entwicklung von

http://www.omg.org


MM M

1

LI

2

M M

A

A2 A1

M M

TP1

M M

3

M M

4

M M

5

V

6

Text

aLA

7

LA

B

B2 B1

LA

8

ALMM

TP2

ALMM

C

C2 C1

M M

9

M M

10

LA

11

LA

12

B H

13

M M

14

LI

15

B H

16

B H

D

D2 D1

B H

17

B H

18

WWS

19

M M

20

FRM AT SM BD AG Beschreibender TextM M M A TE R IA LM A N A G E R

1 Bestellvorschlag erstellenL I L IE FE R A N TE N

2 Auftragsbestätigung sendenA Auftragsbestätigung o.k.?

A1 NeinA2 Ja

TP1 Auftragsbestätigung klären3 Liefertermin bestätigen4 Vertrieb informieren5 Auftragsbestätigung weitergeben

V V E R TR IE B6 Kunden informieren

a 4-6 WochenLA LA G E R

7 Wareneingang überprüfenB Wareneingang o.k.?

B1 NeinB2 Ja

8 MM informierenALM AL MATERIAL MANAGEMENT

TP2 falscher Wareneingang klärenC Rücksendung

C1 jaC2 nein

9 Lager informieren10 Gutschrift anfordern11 Rücksenden an Lieferant12 Wareneingang verbuchen

B H B U C H H A LTU N G13 Rechnung prüfen14 BH informieren15 Gutschrift senden16 Gegenbuchung durchführen

D Rechnung o. k.?D1 neinD2 ja

17 Rechnung verbuchen18 MM über Differenzen informieren

WW WARENWIRTSCHAFTSSYSTEM19 Daten an SAP übermitteln20 Differenzen klären

Abb. 2.34 Beispiel Folgestruktur (Fischermanns 2006)

Standards beschäftigt. Im Jahr 2010 wurde die derzeit aktuelle Version BPMN 2.0 vorge-stellt, welche eine deutliche Erweiterung des Sprachumfangs erfahren hat. Das zentraleDarstellungselement der BPMN ist das Business Process Diagramm (BPD), das u. a. Ele-mente des Swimlane-Diagramms beinhaltet. Neben der fachlichen Modellierung wurdemit dieser Version auch das Workflow-Management, also die Unterstützung ausführbarer


Anfragedaten

PreisdatenMengendatenArtikeldatenLieferdatum

MATERIALMANAGERBestellvorschlag erstellenModul BestellabwicklungWarenwirtschaftssystem

LIEFERANTENAuftragsbestätigunggsendenFax

MATERIALMANAGERAuftragsbesttätigungo.kk.?

Ja

MATERIALMANAGERLiefertermin bestätigenModul BestellabwicklungWarenwirtschaftssystem

MATERIALMANAGERAuftragsbestätigung weiterr-ggebenModul BestellabwicklungWarenwirtschaftssystem

PreisdatenMengendatengArtikeldaten

PreisdatenMengendatengArtikeldatenLieferdatum

Nein

Kopie Auftrags-bestä

gtigung

Lieferdatum neu

Kopie Auftrags-pbestä

gtigung

4-6 Wochen

Bestellung Brief/FaxgModul

Bestellabwicklung

AuftragsbestätigunggBrief/Fax

MATERIALL-MANAGERAuftragsbestäti-gung

gklären

MATERIALL-MANAGERVertrieb informieren

Modul EmailMS-Outlook

VERTRIEBKunden informierenTelefon

Abb. 2.35 Beispiel Folgeplan (Fischermanns 2006)

Modelle unterstützt. Sie konzentriert sich allerdings ausschließlich auf die Prozessmodel-lierung. Prozesslandkarten, die Aufbauorganisation, Datenstrukturen sind nicht Gegen-stand der BPMN-Notation.

Die BPMN-Methode gehört zur Klasse der kontrollflussorientierten Sprachen, weil derArbeitsablauf im Mittelpunkt des Modellierungskonzeptes steht. Darüber hinaus berück-sichtigt sie organisatorische und datenorientierte Aspekte. Die wesentlichen Symbole sindin Abb. 2.36 dargestellt. Rechtecke beschreiben Aktivitäten, Kreise unterschiedliche Ereig-nistypen, Rauten spezifizieren Entscheidungen und Kanten den Kontroll- und Nachrich-tenfluss. Die Unterscheidung von Nachrichten- und Kontrollfluss erlaubt es, zusammen-



Eine Aktivität (Activity) beschreibt einen Vorgang, der durch daas Unternehmen ausgeführt wird. Sie kann atomar (task) oder zusammengesetzt sein, also Unterprozesse ((subprocesses) enthalten.

Aktivität (atomar)

Aktivität (mit Unterrr-prozessen)

Ereignisse (Events) sind Geschehnisse, die während eines Prozessses auftreten. Sie können auslösend sein oder das Ergebnis einer Akttivität. Es gibt drei grundlegende Typen (start, intermediate und end) und Spezialfälle.

Start-Ereignis ZwischenereignisEnd-Ereigniss

Entscheidung (Gateway)

Gateways sind Synchronisationspunkte im Prozessverlauf. Sie entscheiden über den weiteren Verlauf des Prozesses. Es gibt mehhrere Gateway-Typen: XOR, OR, AND und Eventbasierte Entscheidung.

+++

Kontrollfluss(Sequence floww)

Der Kontrollfluss beschreibt den zeitlichen Ablauf der Aktivitätten im Prozess

Nachrichtenfluss(Message floww)

Der Nachrichtenfluss beschreibt den Austausch von Nachrichten zwischen zwei Objekten (Aktivitäten, Ereignisse oder Entscheidunngen).

Verbindung(Association)

Die Verbindung zeigt an, dass Daten, Texte oder andere Objekte ddem Kontrollfluss verbunden sind, z.B. Input oder Output einer Aktivvität.

Datenobjekt(Data Object)

Das Datenobjekt zeigt an, welche Informationen/Daten als Input bbenötigt bzw. Output einer Aktivität sind

Name

Abb. 2.36 Notation BPMN (in Anlehnung an White 2010)

Abb. 2.37 Einfaches BPMN-Modellierungsbeispiel

hängende Prozesse darzustellen und zusätzlich den Nachrichtenfluss bei ÜberschreitungvonOrganisationsgrenzen zu modellieren (vgl. Decker 2008, S. 162). Daneben stehen Spe-zialsymbole für Gateways (Entscheidungen), Events (Ereignisse), textuelle Erläuterungenu. a. Detailinformationen zur Verfügung. Weitere Informationen sind über die Object Ma-nagement Group erhältlich (http://www.bpmn.org/).

Das Modellierungsbeispiel in Abb. 2.37 zeigt einen einfachen Logistikprozess.Die „Semantics of Business Vocabulary and Business Rules (SBVR)“ stellen ein zen-

trales Unternehmensglossar in Verbindung mit Geschäftsregeln dar. SBVR repräsentiert

http://www.bpmn.org/

2.7 ObjektorientierteMethoden 89

Tab. 2.2 Ordnungsrahmen zur Prozessmodellierung nachThomas et al. (2007, S. 38)

Prozess Modell SpracheGestaltung Informationsmodell EPKKonfiguration Anwendungsmodell BPMNAusführung Ausführungsmodell BPEL

die Datensicht auf das Unternehmen. Das „Business Motivation Model (BMM)“ bildet dieUnternehmensstrategie ab und soll als Standard für die strategische Planung positioniertwerden. Das „Organizational Structure Metamodel (OSM)“ repräsentiert die Organisati-onssicht und stellt ein Instrument zur Beschreibung der Unternehmensstrukturen dar.

Thomas et al. (2007) entwickeln einen Ordnungsrahmen, der auf den drei Ebenen Ge-staltung, Konfiguration und Ausführung von Prozessen unterschiedliche Modellierungs-sprachen nutzt (vgl. Tab. 2.2) und sehr gut die unterschiedlichen Einsatzschwerpunkte derModellierungskonzepte betont.

In der Praxis stellt sich häufig die Frage, große Bestände an EPK-Modellen in die neuereBPMN-Notation zu überführen (vgl. Slama und Nelius 2010, S. 91). Die BPMN-Notationbietet grundsätzlich mehr Freiheitsgrade, als die EPK, was zu unterschiedlichen möglichenBPMN-Modellen führen kann vgl. Slama undNelius 2010, S. 91.). Daher ist zu berücksich-tigen, dass dies neben den reinen Transformationsproblemen (Überführung Modellele-mente der EPK in „passende“Modellelemente der BPMN) zu konzeptionellen Überlegun-gen führen kann, die nicht oder nur schwer automatisierbar sind. Daher ist eine generelleÜberführung größerer Bestände an EPK-Modellen in die BPMN-Notation sorgfältig hin-sichtlich Aufwand und Nutzen abzuwägen. Möglicherweise bietet sich eine Suksessivstra-tegie an, bei der anstehenden Modellaktualisierungen von EPK-Modellen durch Neumo-dellierungen in der BPMN-Notation ersetzt werden.

2.7 Objektorientierte Methoden

Objektorientierte Programmiersprachen sind seit langem etabliert (vgl. z. B. Pomberger1993, S. 6). Die der Softwareentwicklung zugrunde liegenden Fachkonzepte einschließlichder hierbei eingesetzten Methoden der Prozessmodellierung basierenmeist auf klassischenModellierungsansätzen. Die Prozesse neuer Anwendungssystemewerden getrennt von denDatenmodellen entwickelt. Hieraus ergibt sich eine wesentliche Schwachstelle: Daten- undProzessmodelle sind im Nachhinein nur schwer abzustimmen mit der Folge, dass beimspäteren Einsatz Inkonsistenzen sichtbar werden (vgl. Sinz 1991, S. 457). Es stellt sich da-her die Frage, ob objektorientierte Konzepte auch auf die Prozessmodellierung übertragbarsind.

Die Unified Modeling Language (UML) geht zurück auf drei Vorgängermethoden (Au-tor in Klammern): OOSE (Jacobsen), OMT (Rumbaugh) und Booch (Booch).Die Autoren



Akteur (Mensch) Menschlicher Akteur (Person oder Rolle, z. B. „Buchhalter“)

Verbindung Beziehung zwischen einem Akteur und einem Anwendungsfall

Anwendungsfall

Extend-Verbindung Erweiterungsbeziehung zwischen zwei Anwendungsfällen. Der Anwendungsfall, auf den der Pfeil zeigt, wird um den vom Pfeil ausgehenden Anwendungsfall erweitert.

<<extend>>

Include-Verbindung Einschließende Beziehung zwischen zwei Anwendungsfällen. Der Anwendungsfall, von dem der Pfeil ausgeht, ist Teil des Anwendungsfalls, auf den der Pfeil zeigt.

<<inclcude>>

Geschäftsvorfall, z. B. „Rechnung buchen“

Akteur (System) Maschineller Akteur (z. B. Fremdsystem eines Lieferanten)

Akteur (Zeitereignis) Zeitereignis, z. B. „Zahlungsfrist ist abgelaufen“12

6

12

6

Abb. 2.38 Notation UML Use Case-Diagramm

wurden späterMitarbeiter der FirmaRational undhaben 1996 die ersteVersion der aus die-sen Methoden entwickelten UML vorgestellt. 1997 wurde eine Weiterentwicklung bei derObjectManagementGroup (OMG), einem internationalen Standardisierungsgremium, alsStandard eingereicht und veröffentlicht. Mittlerweile erfolgt die Weiterentwicklung durchdie OMG (vgl. Müller 2005, S. 99).

2.7.1 Use Case Diagram (UML)

Ursprünglich wurden Use Case-Diagramme (Anwendungsfalldiagramme) zur Beschrei-bung funktionaler Anforderungen im Rahmen der Anforderungsanalyse für Softwaresys-teme vorgeschlagen. Sie dienten primär der Softwareentwicklung. Seit einiger Zeit werdenSie auch für die Geschäftsprozessanalyse eingesetzt (vgl. Umbach und Metz 2006, S. 424).Use Case-Diagramme beschreiben aus fachlicher Sicht grundlegende Beziehungen zwi-schen Akteuren und dem Informationssystem in Form von Geschäftsvorfällen.

Akteure können Personen, Ereignisse oder Prozesse sein, welche die Geschäftsvorfäl-le anstoßen. Anwendungsfalldiagramme unterstützen die Kommunikation zwischen derFachabteilung und Softwareentwicklern und damit die Systementwicklung. In Abb. 2.38ist die Notation für Use Case-Diagramme dargestellt (für weitere Details vgl. Oestereichet al. 2003, S. 148 ff.).

Abbildung 2.39 zeigt ein einfaches Beispiel für ein Anwendungsfalldiagramm. SowohlAngebote, als auch Aufträge müssen sich dem Anwendungsfall „Kreditlimit“ unterziehen,d. h. der Verkäufer darf nur ein verbindliches Angebot unterbreiten bzw. einen Auftragerfassen und freigeben, wenn der Kunde noch im Rahmen des mit ihm vereinbarten Kre-ditlimits liegt.


Kunde

Anfrage prüfen

Angebot erstellen Verkäufer

Kreditlimit

Auftrag bearbeiten

<<include>>

<<include>>

Buchhalter

Abb. 2.39 Beispiel Use Case Diagramm (Kundenauftrag)


Start Start einer Aktivität (maximal ein Startpunkt ist erlaubt)

Synchronisierung(und)

Zusammenführung des Kontrollflusses von zuvor gesplitteten Aktivitäten(und)

Teilung (Parallelisierung)

Kontrollfluss Richtung des Kontrollflusses

Parallelisierung bzw. Splittung einer Aktivität

Aktivität Aktivität in einem Anwendungsfall

Verzweigung /Zusammenführung(oder)

Verzweigung oder Zusammenführung des Kontrollflusses, ggf. aufgrund einer Bedingung (oder)

Ende Ende einer Aktivität (mehrere Endpunkte sind erlaubt)

Abb. 2.40 Notation UML Activity Diagram

2.7.2 Activity Diagram (UML)

Einzelne Verarbeitungsschritte eines Geschäftsvorfalls bzw. der Algorithmus mit seinenvielfältigen Verzweigungen eines Anwendungsprogrammes können mit einem ActivityDiagram dargestellt werden. Activity Diagrams ähneln den seit Jahrzehnten bekanntenProgrammablaufplänen oder auch den bereits in diesem Buch vorgestellten kontrollfluss-orientierten Methoden. Abbildung 2.40 zeigt die wichtigsten Notationselemente (für eineausführliche Beschreibung vgl. Oestereich et al. 2003, S. 175 ff.).

Start und Ende eines Anwendungsfalls werden durch Marken dargestellt. Eine Ver-zweigung bzw. Zusammenführung stellt eine „Oder-Bedingung“ dar, die durch eine Rautesymbolisiert wird. Die Raute kann ggf. mit Bedingungen (z. B. Umsatz > 100) spezifiziertwerden. Die Teilung bzw. Synchronisation repräsentieren „UND-Bedingungen“, die keineweiteren Beschriftungen erfordern.


Kundenauftrag prüfen

Mindestlagerbestand unterschritten

Lagerbestand ausreichend

Artikel bestellen

Auftrag bestätigen

Ware versenden

Rechnungerstellen

Auftrag bearbeitet

Bestellung eingetroffen

Abb. 2.41 Beispiel UML Activity Diagramm (Kundenauftrag)

Abbildung 2.41 zeigt ein einfaches Modellierungsbeispiel unter Verwendung der UML-Notation.

2.7.3 Semantische Objektmodell (SOM)

Das semantischeObjektmodell (SOM)wurde von Ferstl und Sinz zur Beschreibung von In-formationssystemen auf der Grundlage des objektorientierten Paradigmas entwickelt (vgl.Ferstl und Sinz 1990, 1991, 1995). Der Ansatz basiert auf einer Unternehmensarchitek-tur mit den Modellierungsebenen Unternehmensplan, Geschäftsprozessmodell und An-wendungssystem bzw. Aufbauorganisation. Die Modellierung von Geschäftsprozessen er-folgt mit Interaktionsdiagrammen und Vorgangs-Ereignisschemata (vgl. die Notation inAbb. 2.42 und das Modellierungsbeispiel in Abb. 2.43).

Abbildung 2.43 zeigt ein Interaktionsdiagramm zur Angebotsbearbeitung. Die Anbah-nungsphase wird durch die betriebliche Transaktion Anfrage repräsentiert. Der Prozesskennt mehrere Vereinbarungstransaktionen, die je nach Ausgang der Bestands- und Kre-ditlimitprüfung ausgeführt und durch Steuerungs- und Kontrolltransaktionen dargestelltwerden.


Symbol Benennung BedeutungBetriebliches Objektder Diskurswelt

Komponenten zur Übernahme, Erstellung und Übergabe von Leistungspaketen und / oder Lenkungsnachrichten

Betriebliche Transaktion Betriebliche TransaktionTyp: A Anbahnungstransaktion

V VereinbarungstransaktionD DurchführungstransaktionS SteuertransaktionK Kontrolltransaktion

Name: Bezeichnung der Transaktion

Objekttt-Name

Betriebliches Objektder Umwelt

Typ: Name

Interaktionskanäle zum Austausch von Leistungspaketen oder Lenkungsnachrichten

Objekttt-Name

Abb. 2.42 Notation SOM-Interaktionsdiagramm

Abb. 2.43 Beispiel Interaktionsdiagramm

In Abb. 2.44 wird die Notation für das Vorgangs-Ereignisschema vorgestellt, welchesdas Interaktionsdiagramm ergänzt.

Die Abb. 2.45 zeigt ein Vorgang-Ereignisschema, das mit dem vorgestellten Interakti-onsdiagramm in Abb. 2.43 korrespondiert.

Die Stärke des SOM-Ansatzes liegt in der ganzheitlichen Betrachtung der Geschäftspro-zessmodellierung, die in ein umfassendes Rahmenkonzept eingebettet ist. Die Interakti-onsdiagramme geben einen ersten Überblick über die Struktur des Geschäftsprozesses,während die Vorgangs-Ereignisschemata die Ablaufsicht weiter präzisieren.

2.7.4 Objektorientierte EPK (oEPK)

Scheer entwickelte die EPK-Methode zur objektorientierten Ereignisgesteuerten Prozess-kette weiter (oEPK, vgl. Scheer et al. 1997 und die Notation in Abb. 2.46). Damit solltenzwei Ziele verfolgt werden.



Vorgang Vorgang, der ausgeführt wird, wenn die zugehörigen Vorereignisse vorr-liegen.

Ein Vorgang kann folgende Ereignisse erzeugen oder auslösen

1. Transport von Leistungspaketen oder Lenkungsnachrichten2. Erzeugung eines objektinternen Ereignisses3. Erzeugung eines Umweltereignisses

Leistungspaket oder LeistungsnachrichtName> Leistungspaket oder Leistungsnachricht für einen

Folgevorgang

>Name Leistungspaket oder Leistungsnachricht einesvorangehenden Vorgangs

Betriebliche Transaktion vgl. Interaktionsdiagramm

Ereignis

Typ: Name

Objektinterne Ereignisse zur Kopplung von Aufgaben innerhalb eines Objektes oder Umweltereignisse außerhalb des Objektes

Name >bzw.

> Name

betr. Objekt

Name >Name >bzw.bzw.

> Name> Name

betr. Objektbetr. Objekt

Transaktionskanal Verknüpfung von Vorgang und Ereignis

Abb. 2.44 Notation Vorgang-Ereignisschema

• Übertragung des Konzeptes der Ereignisgesteuerten Interaktion von Objekten in ob-jektorientierten komponentenbasierten Informationssystemen auf die der Softwareent-wicklung vorgelagerte betriebswirtschaftliche Fachkonzepterstellung,

• Integrierte Beschreibung von Prozessen und ihren Objekten.

Das objektorientierte Paradigma erfordert eine Veränderung des Geschäftsprozessbe-griffs, unter dem eine ereignisgesteuerte Bearbeitung von Geschäftsobjekten zum Zweckeder Leistungserstellung verstanden wird. Geschäftsobjekte kapseln die Funktionen (Me-thoden) und Daten (Instanzvariablen), die zur Erstellung einer betriebswirtschaftlichenLeistung erforderlich sind. Ereignisse lösen im Vergleich zur „klassischen“ EPK keineFunktionen, sondern den Aufruf von Methoden der angesprochenen Objekte aus. DieNotation ist an die der EPK angelehnt. Neue Symbole werden für das Geschäftsobjekt(Objektklasse), Daten (Instanzvariable) und Funktionen (Methoden) eingeführt.

Die Modellierung des Kontrollflusses erfolgt nachrichtengesteuert mit Ereignissen zwi-schen den Objekten. Für die Darstellung von assoziierten Objekten, die nicht im Mit-telpunkt der betriebswirtschaftlichen Entscheidungslogik stehen, werden Nachrichten inForm einer Auftraggeber-/Leistungserbringer-Beziehung modelliert.

Abbildung 2.47 zeigt die Prinzipdarstellung einer oEPK. Dargestellt ist die Objektklas-se A, die vom Ereignis 1 ausgelöst wird. Sie transformiert mittels der Methoden M1, M2undM3 die Instanzvariablen 1, 2 und 3. Die Objektklasse A verarbeitet Informationen derObjektklasse B und löst eines der Ereignisse 2, 3 oder 4 aus.

Die objektorientierte Darstellungsform der oEPK erfordert zunächst die Identifikati-on der Geschäftsobjekte des Anwendungsbeispiels, da Funktionen als Objektmethoden


Abb. 2.45 Beispiel Vorgang-Ereignisschema



Ereignis/Nachricht Beschreibung eines eingetretenen Zustandes, von dem der weitere Verlauf des Prozesses abhängt

Objektklasse Betriebswirtschaftliche Leistung (Geschäftsobjekt), die zur Bearbeitung relevante Funktionen (Methoden) und Daten (Instanzvariablen) kapselt

Konnektor Logische Verknüpfungsoperatoren der EPK-Methode (AND, OR, XOR) beschreiben die logische Verknüpfung von Geschäftsobjekten und Ereignissen

Organisatorische Einheit Beschreibung der Gliederungsstruktur eines Unternehmens

Methode/Funktion Funktion (Methode) eines Objektes zur Manipulation von Daten (Instanzvariable). Private Methoden sind im Gegensatz zu öffentlichen Methoden außerhalb des Objektes nicht sichtbar

Auftrags-/Leistungs-beziehung

Ereignisgesteuerter Nachrichtenaustausch zwischen Geschäftsobjekten

Kante Zuordnung von Methoden, Instanz-variablen und organisatorischen Einheiten zu Objekten

Kontrollfluss Zeitlich-logischer Zusammenhang von Ereignissen und Geschäftsobjekten

Instanzvariable/Attribut Daten (Instanzvariable) die durch Methoden eines Objektes manipuliert werden

Abb. 2.46 Notation der oEPK

Ereignis1

Ereignis2

Ereignis4

Ereignis3

Org.-Einheit

ObjektklasseA

Methode M1Instanzvariable 2

Methode M1Instanzvariable 3

Methode M1Objektklasse

B

Instanzvariable 1

XOR

Abb. 2.47 Prinzipdarstellung einer oEPK

nunmehr nicht im Vordergrund der Prozessdarstellung stehen. Identifiziert wurden dieObjekte Anfrage, Kunde, Material, Angebot und Absage.

Der Vergleich des oEPK-Modells (vgl. Abb. 2.48)mit demEPK-Modell (vgl. Abb. 3.110)zeigt, dass die Transformation relativ einfach vorgenommen werden konnte, da sich dieGrundstruktur der EPK kaum geändert hat. Die Objektklasse tritt neben dem Ereignis andie Stelle der Funktion, die der Objektklasse als Methode zugeordnet wird. Die Aussage-kraft der oEPK im Vergleich zur EPK besteht in der integrierten Beschreibung von Objektund Prozess. Die Anzahl der notwendigen Objekttypen hat sich im Fallbeispiel durch dasneue Objektklassensymbol erhöht, das diese Aufgabe wahrnimmt.


Anfrageist erfaßt

XOR

Materialist ver-fügbar

Materialist nicht

verfügbar

Anfragen-Angebots-

bearbeitung

Angebots-auftrag istangelegt

XOR

Kredit-limit ist im

Rahmen

Kreditlimitist überschritten

Angebotist erstellt

Absageist erteilt

Anfragen-Angebots-

bearbeitung

Debitoren-buchhaltung

Vertrieb Vertrieb

MaterialAnfrage

verfügbare Menge

Prüfen

Angebot

Kunde

Material

Anfrage

Angebotsnummer

anlegen

KundePrüfen

Angebot

Angebotsnummer

Kundennummer

Kreditlimit

Anfragenummer

Material ErzeugenBestell-anforderung

Angebot

ErstellenKunde

Angebotstext

Kunde

Absagetext

Erstellen

Absage

Anfrage

Anforderung

ÜbermittelnÜbermitteln

Kredit-limit ist über-

schritten

Abb. 2.48 oEPK-Modell des Fallbeispiels

An den großenErfolg der „klassischen“ kontrollflussorientierten eEPK imEinsatz in derPraxis vieler Unternehmen konnte die objektorientierte Version jedoch nicht anknüpfen.

2.7.5 Statechart- und Activitychart-Diagramm

Statechart-Diagramme wurden von D. Harel entwickelt, um die Konzepte zur Modellie-rung komplexer Zusammenhänge zu verbessern (vgl. Balzert 1997a, S. 277). Sie beschrei-ben den Kontrollfluss zwischen den Aktivitäten eines Prozesses in Form eines gerichtetenGraphen. Das zugehörige Activitychart beschreibt den Datenfluss.

Der Kontrollfluss wird als Transition zwischen Zuständen von Aktivitäten definiert.Statecharts greifen auf Event-Condition-Action-Regeln (kurz ECA-Regeln) zurück (vgl.Weikum et al. 1997, S. 64). Eine Transition mit der Bezeichnung „E[C]/A“ führt dann,



Aktivität Einzelaktivität innerhalb einesWorkflows

Kontrollfluß Kontrollfluß zwischen AktivitätenE[C]/A = ECA-Regel zurSpezifikation des Kontrollflusses

Kanten-/Knotentyp

Aktivitätsknoten

KontrollflußkanteE[C]/A

Aktivitäts-name

Abb. 2.49 Notation Statechart-Diagramm

ANG_BEARB_ST

ERF_ANFRAGE

ERT_ABSAGE

ERT_ANGEBOT

PRF_KLIMIT

ANLEG_ANGAUFT

[ERF_ANFRAGE_DONE /st!(PRF_MATVERF)]

[PRF_MATVERF_DONE and (MAT_MENG < ANF_MENG )/st!(ERT_ABSAGE)]

[PRF_MATVERF_DONE and (MAT_MENG >= ANF_MENG)/st!(ANLEG_ANGAUFT)]

[PRF_KLIMIT_DONE and (ANF_WERT > K_LIMIT)/st!(ERT_ABSAGE)]

[PRF_KLIMIT_DONE and (ANF_WERT <= K_LIMIT)/st!(ERT_ANGEBOT)]

[ANLEG_ANGAUFT_DONE )/st!(PRF_KLIMIT)]

PRF_MATVERF

Abb. 2.50 Beispiel Statechart-Diagramm

wenn das Ereignis „E“ eingetreten ist und die Bedingung „C“ erfüllt ist, die Aktion „A“aus. Eine Aktion kann z. B. der Start einer weiteren Aktivität sein oder die Erzeugung einesEreignisses, welches wiederum Aktivitäten auslösen kann.

Die für Statecharts verwendete Notation (vgl. Abb. 2.49) besteht aus einem abgerun-deten Rechteck zur Beschreibung der Aktivitäten bzw. Transitionen, dem Pfeil zur Be-schreibung des Kontrollflusses und der Beschriftung des Kontrollflusses in der E[C]/A-Schreibweise.



Aktivität Einzelaktivität innerhalb eines Workflows

Datenfluß Datenfluss zwischen Aktivitäten

Aktivitäts-name

Datenflussname

Abb. 2.51 Notation Activitychart

ANG_BEARB_AC

ANF_DAT

VERF_BEST_DAT

ANF_DAT

ERF_ANFRAGE

PRF_MATVERF

ÁNLEG_ANGAUFT

ERT_ABSAGE

ERT_ANGEBOT

UNGEPR_ANG LIMIT_OK

LIMIT_NOT_OK

FEHLTEILE

PRF_KLIMIT

Abb. 2.52 Beispiel Activitychart-Diagramm

Das Beispiel in Abb. 2.50 zeigt einen Prozess aus demUmfeld der Angebotsbearbeitungim Vertrieb. Nach Eingang der Kundenanfrage erfolgt die Materialverfügbarkeitsprüfung(PRF_MATVERF). Je nach Ergebnis wird noch eine Kreditlimitprüfung (PRF_KLIMIT)durchgeführt. Bei positivem Ausgang erfolgt die Angebotserstellung (ERT_ANGEBOT).

Die Notationselemente des Activitychart-Diagramms beschränken sich auf ein Recht-eck zur Aktivitätsbeschreibung, einen Pfeil als Symbol für den Datenfluss und einer Be-schriftung (vgl. Abb. 2.51).

DasModellierungsbeispiel inAbb. 2.52 stellt den Prozess ausAbb. 2.50 als Activitychart-Diagramm dar.

Die Besonderheit der Activity- und Statecharts liegt in der Ablaufmodellierung unterBerücksichtigung des Datenflusses.


2.8 Methodenvergleich

Die Auswahl einer Modellierungsmethode bindet ein Unternehmen für eine längere Zeit.Ein Wechsel ist zwar möglich, verursacht aber Kosten und andere Aktivitäten. Der Leserwird sich angesichts zuvor zahlreichen Modellierungsmethoden fragen, welche Methodeer für seine Zwecke einsetzen kann. Die Entscheidung ist unternehmensindividuell undfallbezogen zu klären. Vor allem in größeren Unternehmen kommen parallel mehrereMethoden jeweils für unterschiedliche Zielgruppen undAnwendungsfälle zum Einsatz. Inder Abb. 2.53 werden anhand in der Praxis häufig genutzter Methoden (Wertschöpfungs-kettendiagramm, ereignisgesteuerte Prozesskette, Swimlane, BPMN und UML ActivityDiagramm) die Unterschiede in der Modellierungsmächtigkeit dargestellt. Die Anzahlder Modellelemente ist bei der BPMN-Methode und der eEPK-Methode sehr hoch.Die Wertschöpfungskette, Swimlane-Diagramme und das UML Activity Diagram de-cken dagegen nur Teile der Modellierungsaspekte ab, was deren Einsatzfokus deutlicheinschränkt.

Der Vergleich wird in der Abb. 2.54 mit der Gegenüberstellung weiterer Merkmalefortgesetzt. Hierzu gehören die Kriterien Hauptzielgruppe, Modellierungstiefe, Standar-disierung der Notation, Verbreitung in der Praxis, Verfügbarkeit von speziellen Model-lierungstools, Komplexität der Notation und der Schulungsbedarf im Rahmen der erst-maligen Nutzung der Sprache. Die Unterschiede sind ebenfalls sehr deutlich und zeigen,dass die Auswahl der Methode ein relevantes Entscheidungsproblem darstellt. Das Wert-schöpfungskettendiagramm (WKD) und Swimlane-Diagramme sind lediglich für grobeDarstellungen geeignet. Das Wertschöpfungskettendiagramm eignet sich sehr gut für dasManagement. Bei beiden Methoden ist der Schulungsaufwand denkbar gering. Die erwei-terte ereignisgesteuerte Prozesskette (eEPK) und die BPMN-Notation sind beide für kom-plexere Modelle geeignet. Aufgrund der Vielzahl der Notationselemente ist der Schulungs-aufwand für die BPMN-Notation etwas höher anzusetzen. Die UML-Notation nimmt eineSonderrolle unter den genanntenMethoden ein. Sie wird meist im Zusammenhangmit derErstellung von Softwaredokumentationen eingesetzt, weniger stark in reinen Prozessma-nagementprojekten. Standardisiert und damit einheitlich in der Anwendung sind lediglichdie BPMN-Notation und das Activity Diagram der UML. Die Standardisierung wird indiesem Fall von der international ausgerichteten Object Management Group (OMG, www.omg.org) verantwortet. Dies bedeutet, dass bei den anderen aufgeführten Methoden mitzahlreichen Varianten in der Praxis zu rechnen ist.

2.9 Prozessmodellierung in der Praxis

Viele Unternehmen stehen vor komplexen, historisch gewachsenen und undokumentier-ten IT-Systemen. Schwerfällige Arbeitsabläufe und ineffiziente Organisationen zwingen siezur Reorganisation der Geschäftsprozesse.Die Einführung von Standardsoftware zur Kos-tenreduktion kann nur in Verbindungmit einer Analyse undNeugestaltung der Arbeitsab-

http://www.omg.org

http://www.omg.org

2.9 Prozessmodellierung in der Praxis 101

Met

hode

WKD

eEPK

Swim

-lane

BPMN

UML

Activity

Diagram

Erei

gnis

/Zu

stan

dFu

nktio

n /

Proz

ess

Org

ani-

satio

nSo

ftw

are

Dat

enVe

rzw

eigu

ng /

Konn

ekto

rKo

ntro

ll-, D

aten

-,N

achr

icht

enflu

ss

Star

tpro

zess

Proz

ess

Kont

rollfl

uss

Kont

rollfl

uss

Kont

rollfl

uss

Kont

rollfl

uss

Kont

rollfl

uss

Erei

gnis

Funk

tion

und

wei

tere

Anw

endu

ngs-

syst

em

Info

r-m

atio

nun

d

xor

Dat

enflu

ss

Nac

hric

hten

-flu

ss

Proz

esss

chrit

tLa

nes

Dok

u-m

ent

Dok

umen

tun

dxo

rod

erEv

ent

Kom

plex

xor

oder

Lane

Lane

Akt

ivitä

t

Akt

ivitä

t

Star

t-,

Zwis

chen

-,

Ende

reig

nis

Star

tEn

de

Pool

Abb

.2.53

ZentraleMod

ellelementeausgew

ählterM

odellierung

smetho

den(Basisn

otationen)


Met

hode

Hau

pt-Z

iel-

Gru

ppe

Mod

ellie

-ru

ngst

iefe

Stan

dard

i-si

erun

gVe

r-br

eitu

ngTo

ols

Kom

plex

ität

Schu

lung

sbed

arf

WKD

eEPK

Swim

-lane

BPMN

UML

Activity

Diagram

Man

a-ga

men

t

IT /

Fach

-ab

teilu

ng

IT /

Fach

-ab

teilu

ng

IT /

Fach

-ab

teilu

ng

IT

Gro

b-m

odel

le

Gro

b-m

odel

le

Det

eil-

mod

elle

Det

eil-

mod

elle

Det

eil-

mod

elle

nein

nein

nein

OM

G

OM

G

Inte

r-na

tiona

l

Inte

r-na

tiona

l

Inte

r-na

tiona

l

Inte

r-na

tiona

l

DAC

H-

Länd

er

ja ja ja ja ja

sehr

ger

ing

sehr

ger

ing

sehr

hoc

h

hoch

hoch

min

imal

min

imal

hoch

sehr

hoc

h

mitt

el

Abb

.2.54

Merkm

aleausgew

ählterM

odellierung

smetho

den(Basisn

otationen)

2.10 Werkzeuge für das Prozessmanagement 103

läufe einen Rationalisierungserfolg nach sich ziehen. Insbesondere größereOrganisationenerwägen daher den Aufbau eines Unternehmensprozessmodells.

Einsatzschwerpunkte in Unternehmen:

• Erfassung und Dokumentation der Geschäftsprozesse• Schwachstellenanalyse der Gesamtorganisation• Anforderungsdefinition neuer Informationssysteme• Auswahl und Einführung von Standardsoftware• Aufbau eines Unternehmensprozessmodells

Die Kunden von Standardsoftware-Anbietern benötigen bei der Produktauswahl In-formationen über den Funktionsumfang der Produkte. Prozessmodelle können als Pro-duktbestandteil der Software betrachtet werden und dienen als Verkaufsargument. DieDurchführung von Einsatzanalysen beim Kunden wird durch vorliegende Daten- und Ab-laufbeschreibungen bedarfsgerecht dokumentiert.

Einsatzschwerpunkte bei Softwareanbietern:

• Daten- und Prozessmodelle als Produktbeschreibung• Unterstützung von Einsatzanalysen beim Kunden• Basis für individuelle Weiterentwicklungen (Modifikationen)• Vergleichsbasis beim Softwareauswahlprozess• Einarbeitungshilfe und Nachschlagewerk für den Anwender

Für Berater steht die Unterstützung des Kunden bei der Reorganisation seiner Arbeits-abläufe und Strukturen imVordergrund. Ein weiterer Schwerpunkt ist die Einführungsun-terstützung bei der Implementierung von Standardsoftware oderWorkflow-Management-Systemen. Vielfach besteht auch die Notwendigkeit, fehlendes Know-how beim Kundenauszugleichen.

Einsatzschwerpunkte in Beratungsunternehmen:

• Einführung von IT-Systemen bei Kunden• Durchführung von Schwachstellenanalysen• Unterstützung der Beratung bei Organisationsprojekten• Durchführung von Business Reengineering-Projekten

2.10 Werkzeuge für das Prozessmanagement

Der Einsatz vonModellierungs- und Analysewerkzeugen (vgl. Abb. 2.55) stieß in den letz-ten Jahren gelegentlich auf Vorbehalte. So wurde vorgetragen, dass umfangreiche Prozess-diagramme zu unübersichtlich und die bis dahin selbst erstellten Ablaufübersichten undDiagramme dagegen wesentlich praxisnäher und lesbarer seien.


Visualisierungs-werkzeuge

Visualisierungs-werkzeuge

Modellierungs-werkzeuge

Modellierungs-werkzeuge

Simulations-werkzeuge

Simulations-werkzeuge

Workflow-Management-

systeme

Workflow-Management-

systemeCASE-

werkzeugeCASE-

werkzeuge

Darstellung

Optimierung

Simulation

Automati-sierung

Informations-TechnischeRealisierung

Zunehmender Grad der werkzeugbezogenen informationstechnischen Unterstützung

Zune

hmen

der G

rad

der w

erkz

eugs

pezi

fisch

be

reitg

este

llten

IT-F

unkt

iona

lität

Abb. 2.55 Prozessmanagement-Werkzeuge (Nägele und Schreiner 2002)

Mittlerweile ist aber der Unterschied zwischen einem „Prozessmodell“ und einer miteinem Präsentationsprogramm erstellten „Prozess-Grafik“ in der Praxis bekannt und auchakzeptiert. Ein Modell ist kein Bild, es ist eine formale Darstellung und folgt einer Me-thode (vgl. z. B. Davis 2001, S. 28). Die Methode ist personenneutral, das Modell kannauch noch verwertet werden, wenn der Ersteller das Unternehmen verlassen hat. Modellekönnen auch von Dritten verstanden werden, wenn ihnen die zugrunde liegende Methodegeläufig ist. Eine Grafik dagegen erfordert entweder Hintergrundwissen oder umfassendeErläuterungen. Änderungen insb. von komplexen Darstellungen sind zeitaufwändig undmanuell durchzuführen.

Werkzeuge für das Prozessmanagement können in die Kategorien Visualisierung, Mo-dellierung, Simulation, Workflow-Management und Computer Aided Software Enginee-ring (CASE) untergliedert werden (vgl. z. B. Nägele und Schreiner 2002, S. 202–203). Zu-nehmend gewinnen Werkzeuge an Bedeutung, die nicht nur die Modellierung, sondernauch die Ausführung von Prozessen mit der Business Proces Modeling Language (BPMN)unterstützten. Eine Produktübersicht über aktuelle Produkte ist in Spath et al. (2010) zufinden.

Die Spanne der Unterstützung dieser Funktionen durch verschiedene am Markt ange-botene Produkte ist sehr groß. Die graphische Visualisierung wird von allen Produktenunterstützt. Die Modellierung und Simulation ist eine Domäne von hierauf spezialisier-ten Produkten, wie z. B. ARIS (Hersteller: IDS Scheer, Saarbrücken) oder Bonapart (Her-steller: Emprise Process Management, Bonn). Die Automatisierung von Prozessen obliegtausschließlich den hierauf spezialisierten Workflow-Management-Systemen. CASE-Toolsunterstützen die Entwicklung und den Test von Informationssystemen, d. h. den Prozessder Informationssystembereitstellung.

Am Softwaremarkt gibt es seit Jahren eine Reihe von PC-Werkzeugen, die den Orga-nisator bei der Organisations- und Prozessgestaltung und den Softwareentwickler beim


Entwurf und dem Design von Anwendungen unterstützen. Im Folgenden werden einigeausgewählte Werkzeuge für die Modellierung von Geschäftsprozessen und Workflows be-trachtet.

Das Haupteinsatzgebiet vieler Produkte ist die Unterstützung der Modellierung. EinigeWerkzeuge bieten Simulationsmöglichkeiten, um die Modelle hinsichtlich ihrer Ablauffä-higkeit und ihres Beitrages zur Erreichung der Unternehmensziele zu überprüfen. Meistwerden überschaubare Daten- und Prozessmodelle erstellt, obgleich eine vollständigeMo-dellierung des Unternehmens oder eines größeren Bereiches denkbar ist. Dies ist in denmeisten Fällen sehr aufwändig oder aus wirtschaftlichen Gründen und auch aus Gründender Aktualität der Modelle undurchführbar. Eine Beschränkung auf zeitkritische Abläufeoder Engpassbereiche kann dieses Problem lösen.

Vielfach werden BPM-Tools zur fachlichen Modellierung und deren interner Publika-tion im Unternehmen genutzt. Eine im deutschen Sprachraum durchgeführte Erhebungim ergab folgende Funktionen, die durch die Softwarewerkzeuge unterstützt wurden (vgl.Gadatsch et al. 2007):

• Fachliche Prozessmodellierung (80,3%),• Prozesspublikation (69,7%),• Prozesssimulation (48,7%),• Technische Prozessmodellierung (40,8%),• Prozesssteuerung/Workflowsteuerung (48,7%)• Prozessmonitoring (46,1%),• Prozesscontrolling (40,85).

Die Auswahl an Werkzeugen ist in den vergangenen Jahren stark gewachsen. Aus die-sem Grund besteht für die meisten Unternehmen im Regelfall die Notwendigkeit, vorAnschaffung eines Werkzeuges eineMarktuntersuchung durchzuführen. Ausnahmen sinddann anzutreffen, wenn durch Vorgaben eines Mutterkonzerns bestimmte Produkte ver-bindlich vorgeschrieben werden oder das Produkt des Marktführers ohne aufwändigenAuswahlprozess eingesetzt werden soll.

Bei der Produktauswahl ist zu bedenken, dass ohne Modellierungskenntnisse derarti-ge Werkzeuge nicht einzusetzen sind. Bei der Entscheidung für ein derartiges Tool geht esdaher auch um die Wahl der zum Einsatz kommenden Modellierungsmethode. Ein Bei-spiel für eine pragmatische Auswahl aus Sicht der Praxis findet sich in Hirzel et al. (2008,S. 151). Nägele und Schreiner (2002) haben eine umfangreiche Markterhebung mit einemProduktvergleich durchgeführt, dem der in Abb. 2.56 dargestellte Kriterienkatalog zugrun-de lag.

Ein weiteres Konzept zur Werkzeugauswahl wurde von Schmietendorf (2008) vorge-stellt. Es stellt insbesondere die Unterstützung der BPMN-Notation durch die Modellie-rungswerkzeuge in den Vordergrund. Die Ergebnisse der Marktanalyse, die auf Grundlageder in Abb. 2.56 aufgeführten Auswahlkriterien vonNägele und Schreiner (2002) durchge-


Kriterienkatalog

Architektur und Konfigurierbarkeit Einsatzfelder

Sichtenkonzept Methodenangebot

Modellierung Integritätssicherung

Bedienerunterstützung Analyse, Simulation und Optimierung

Import/Export und Schnittstellen Internet-Modellierungsfunktionalität

Kriterienkatalog

Architektur und Konfigurierbarkeit Einsatzfelder

Sichtenkonzept Methodenangebot

Modellierung Integritätssicherung

Bedienerunterstützung Analyse, Simulation und Optimierung

Import/Export und Schnittstellen Internett--Modellierungsfunktionalität

Abb. 2.56 Auswahl von Werkzeugen für das Prozessmanagement (Nägele und Schreiner 2002)

78

69,58 67,17 64,95 64,73

0

10

20

30

40

50

60

70

80

90

100

ARIS Bonapart ProVision MEGA Income

Punkte

Abb. 2.57 Marktanalyse (Nägele und Schreiner 2002)

führt wurde, sind in Abb. 2.57 zu sehen. Demnach führt das Produkt ARIS der IDS ScheerAG, da es in der Mehrheit der Kriteriengruppen als Klassenbester abschnitt.

Zu einem anderen Ergebnis kommt eine Studie jüngeren Datums, bei denen Mitglie-der der Gesellschaft für Informatik (GI e. V.) nach der Häufigkeit des Einsatzes bestimm-ter Tools befragt wurden (vgl. Fettke und Loos 2007). Demnach wird bei den antworten-den Mitgliedern (73% Praktiker) sehr häufig das Produkt MS Visio (48%) eingesetzt (vgl.Abb. 2.58). Erst mit Abstand folgen das Entwicklerwerkzeug Rational Rose (23%) und dasspezifischeModellierungstool ARIS Toolset (22%).

Nüttgens (2002) hat ein Rahmenkonzept zur Auswahl von Modellierungswerkzeugenfür das Geschäftsprozessmanagement entwickelt (vgl. Abb. 2.59). Es dient mit mehr als350 Einzelmerkmalen alsGrundlage für einen elektronischen Produktkatalog, der zur Vor-auswahl vonWerkzeugen eingesetzt werden kann.


Modellierungs-Werkzeuge die von mindestens10% der Befragten verwendet werden

Befragung von Mitgliedern der GI e.V. (13.000)

N=440 Antwortendavon 72,8% Praktiker

48

23

22

15

11

0 20 40 60 80 100

MS Visio

Rational Rose

ARIS Toolset

Oracle9iDeveloper Suite

Together

Nennung in %

Abb. 2.58 Verwendungshäufigkeit ausgewählter Tools in Deutschland (Fettke und Loos 2007)

Rahmenkonzept zur Evaluierung von Modellierungswerkzeugen zum Geschäftsprozessmanagement

Produkt & Preismodell

Hersteller & Kundenbasis

Technologie &Schnittstellen

Methodik & Modellierung

Anwendung & Integration

Rahmenkonzept zur Evaluierung von Modellierungswerkzeugen zum Geschäftsprozessmanagement

Produkt & Preismodell

Hersteller & Kundenbasis

Technologie &Schnittstellen

Methodik & Modellierung

Anwendung & Integration

•Produkt•Markteinführung•Version•Preisliste•Lizenzierungsmodell•Kosten / Arbeitsplatz•Kosten / Forschung•Reader•Wartungsvertrag•Update•Testversion•Schulung•Beratung•Referenzmodell•Service & Support

•Hersteller / Anbieter•Gründungsjahr•Zertifizierung•Mitarbeiter•Umsatz•Installationen•Kunden•Kernmarkt•Branchen

•Installation•Hardware•Betriebssystem•Datenhaltung•Frontend•Client/Serverrr-Konzept

•Multi-Userr-Konzept•Zugriffsrechte•Sprachunterstützung•Hilfefunktion•Schnittstellen-technologie

•Methodenangebot•Methodendefinition•Methoden-transformation

•Methodenfilter•Modellverwaltung•Modellerstellung•Modellkonsistenz•Layout•Varianten-management

•Versions-management

•Vorgehensmodell•Projektmanagement

•Navigation•Animation•Analyse•Kennzahlen-ermittlung

•Prozesskosten-rechnung

•Qualitäts-management

•Risikomanagement•Simulation•Datenbank Reengineering

•Codegenerierung•Integration Fremdsysteme

Abb. 2.59 Auswahlkriterien für Modellierungswerkzeuge (Nüttgens 2002)

Die folgenden Tab. 2.4 und 2.5 listen wichtige Kriterien auf, die bei der Auswahl einesGPO-Tools üblicherweise betrachtet werden. Sie sind als Denkanstöße zu verstehen, abernicht als vollständige Checkliste für eine Nutzwertanalyse im Rahmen eines Produktver-gleiches.

In Tab. 2.3 sind ausgewählte Aspekte zur Einordnung des Herstellers zu finden. In die-sem Spezialmarkt kommen und gehen vieleHersteller. Es ist für denKunden daher wichtig,einen langfristigen Partner zu wählen, der ihn neben technischen Fragen auch in den be-triebswirtschaftlichen Aufgaben der Ist-Analyse und Restrukturierung von Geschäftspro-zessen unterstützt.


Tab. 2.3 Herstellerbezogene Auswahlkriterien

Merkmal Hinweise für die ProduktauswahlErfahrung Das Alter des Unternehmens gibt in diesem dynamischen Markt Hinwei-

se auf die Erfahrung des Unternehmens.AnzahlMitarbeiter

Die Anzahl der Mitarbeiter in Vertrieb und Entwicklung gibt Auskunftüber das Potenzial im Rahmen der Produktweiterentwicklung, Wartungund Betreuung.

Installationsbasis Die Anzahl der Installationen zeigt die bisherigen Markterfolge auf. Ist dieRelation „Kunde zu Installation“ groß, gehören vorwiegend Großunter-nehmen zur Kundschaft. Bei einer ausgewogenen Relation wird das Tooleher in kleineren und mittleren Unternehmen zum Einsatz kommen.

Schulung undBeratung

Die Nutzung von Modellierungswerkzeugen erfordert neben der techni-schen Bedienung des Produktes auch umfassendeMethodenkenntnisse.Hier sollte der Hersteller über entsprechende Angebote verfügen und ne-ben der technischen Schulung auch die betriebswirtschaftliche Analyseund Neugestaltung von Geschäftsprozessen (Business Reengineering)unterstützen.

Die Tab. 2.4 beschreibt technologische Aspekte, die bei der Produktauswahl zu beden-ken sind. Hier ist insbesondere die Frage der Datenhaltung, Import und Export von Mo-delldaten unddieMöglichkeit derModellverwaltung einschließlich derNutzung vonView-ern zur reinen Betrachtung der Modelle in den Fachabteilungen von Interesse.

Entscheidend für die Auswahl eines GPO-Tools ist die Frage, ob die im Unternehmenzur Anwendung kommendeMethode unterstützt wird (vgl. Tab. 2.5).Weitere Aspekte sindin diesem Zusammenhang, ob ggf. eigene Symbole oder Notationen hinterlegt und genutztwerden können. Da in der Regel arbeitsteilig modelliert wird, sollten GPO-Tools Funktio-nen zur Überprüfung der Syntax, der korrekten Verwendung der Modellierungsmethodebereitstellen. Darüber hinaus ist es sinnvoll, semantische Überprüfungen der Modelle zuunterstützen, um z. B. Prozess-Schleifen und ähnliche Fehler zu identifizieren. Auch solltedie Frage der zielgruppenorientierten Präsentation Berücksichtigung finden, denn Pro-zessmodelle müssen für Arbeits- und Entscheidungssitzungen in eine präsentationsfähigeForm gebracht werden können.

Nachfolgend ausgewählte Werkzeuge vorgestellt, die auf einem vom Verfasser mode-rierten Tool-Assessment präsentiert wurden (GfO 2005, Teilnehmer siehe Tab. 2.6).

Das Modellierungswerkzeug ADONIS® von BOC unterstützt die Erhebung, Modellie-rung, Analyse und Simulation von Prozessen. Das Produkt ist in der Lage, jede beliebigeNotation abzubilden. Ein Unternehmen hat hierdurch die Möglichkeit, eigene grafischeDarstellungsformen mit dem Tool abzubilden. Ein Forscher kann die von ihm entwickelteNotation ebenfalls sehr leicht mit demWerkzeug darstellen.

Das Werkzeug AENIS 5 wurde von der Dr. Schniz GmbH vorgestellt. Es bietet nebenden üblichen Funktionalitäten (Modellierung, Analyse, Simulation) u. a. die Möglichkeit,Shapes selbst zu definieren und unterstützt die noch relativ junge StandardnotationBPMN,


Tab. 2.4 Technologiebezogene Auswahlkriterien

Merkmal Hinweise für die ProduktauswahlRessourcen-bedarf

Die Anforderungen an Hardware, Plattenplatz und Hauptspeicher infor-mieren über die erforderlichen Ressourcen. Unterstützt werden auf derClient-Seite meist alle gängigen Betriebssysteme. Zu klären ist, ob für einenevtl. erforderlichen Server ein spezielles Betriebssystem notwendig ist.

Benutzer-schnittstelle

Für die Client-Seite sind webbasierte Technologien sinnvoll, so dass miteinem Browser gearbeitet werden kann.

Datenhaltung Üblich sind Dateisysteme oder Datenbanken zur Verwaltung der Modell-daten. Zu klären ist, ob ggf. Datenbanksoftware mitgeliefert wird oder vomKäufer separat zu erwerben ist.

Import/Export Wird das Werkzeug nicht nur von einer Arbeitsgruppe genutzt, ist es not-wendig, über Funktionen zum Import und Export von Modelldaten ausbzw. in verschiedene Formate zu verfügen. Zusätzlich sollte der Abgleichder Modelle hinsichtlich ähnlicher/gleicher Modellobjekte möglich sein.

Sprache Wird das Werkzeug in verschiedenen Teilen des Unternehmens eingesetzt,kann es sinnvoll sein, verschiedene Sprachen zu nutzen. Dies betrifft die Be-dienung des Tools (Menütexte, Hilfetexte usw.) und die Inhalte der Modelleselbst.

Benutzeradmi-nistration

Da in der Regel mehrere Benutzer mit demWerkzeug arbeiten, ist eineBenutzeradministration mit der Möglichkeit zur Vergabe unterschiedlicherRechte (Lesen, Ändern, Löschen) auf Modellebene erforderlich.

Einbindung vonDokumenten

Prozessmodelle sagen zwar viel über den Arbeitsablauf aus, manchmal ist esaber notwendig, ergänzende Unterlagen (zusätzliche Erläuterungen in Text-form, Beispieldokumente, Videofilme etc.) für das Verständnis beizufügen.Daher sollte das GPO-Tool die Einbindung beliebiger Dokumente in dasProzessmodell unterstützen.

Viewer Nicht alle Mitarbeiter im Unternehmen nutzen die GPO-Tools als Modellie-rungswerkzeug. Die Mehrheit nutzt Modelle zur Information und benötigtdaher nicht die vollständige (teure) Modellierungsumgebung. Hier sindViewer nützlich, mit denen die Modelle betrachtet werden können. Diesesollten möglichst kostenlos zur Verfügung stehen.

die für den Modelldatenaustausch wichtig ist. Letzteres dürfte vor allem in größeren Kon-zernen, die mehrere Tools parallel einsetzen, erforderlich sein.

Ein weiteres VISIO-basiertes Produkt ist DHC Vision von DHC Dr. Herterich & Con-sultants. Es bietet neben den reinenModellierungs- und Analysefunktionen eine gute Ver-bindung von Strategie, Modellierung und der Umsetzung, die über einen Web-Client miteinfacher Administration realisiert wurde. Eine weitere Besonderheit ist die Übersetzungs-funktion und Mehrsprachigkeit.

Die Firma ibo Software bietet mit dem Werkzeug ibo Prometheus ein seit langem imMarkt eingeführtes Produkt an, das sich vor allem durch seine speziellen Modellierungs-methodenmit sehr vielen Notations-Details auszeichnet. Hierdurch kann der Organisator


Tab. 2.5 Methodenorientierte Auswahlkriterien

Merkmal Hinweise für die ProduktauswahlMethodenangebot Üblicherweise werden mehrere Methoden unterstützt. Neben den

Standardmethoden (z. B. EPK) werden auch herstellerspezifischeMe-thoden angeboten. Zum Teil sind Methoden nur gegen einen Aufpreisauf den Lizenzpreis erhältlich.

Nutzung/Einbindungeigener Methoden

In machen Fällen kann es sinnvoll sein, eigene Modellelemente zuverwenden. Hier ist zu prüfen, ob das Werkzeug in der Lage ist, dieDefinition eigener Modellierungsmethoden zu unterstützen

Überprüfung vonSyntax und Semantik

Leistungsfähige Produkte können die Einhaltung der Syntax(Anordnung der Modellierungsobjekte entsprechend der Model-lierungsregeln) und der Semantik (z. B. Erkennung von Schleifen)überprüfen.

Navigation Für die praktische Modellierungsarbeit ist es wichtig, ob die Modellein Form von Baumstrukturen mit Hilfe eines Explorers übersichtlichverwaltet werden können (z. B. Ablage der Modelle auf dem Servernach Abteilungen oder Projekten).

Layout/Gestaltung Die übersichtliche grafische Gestaltung von Modellen dient nebender Präsentation auch der späteren Navigation und der Einarbeitungin die Modellinhalte durch Dritte. GPO-Tools sollten leistungsfähigeGrafikalgorithmen zur automatisiertenModellanordnung enthalten,die auch Möglichkeiten zur Druckaufbereitung umfassen.

Tab. 2.6 Teilnehmer des GfO-Prozess-Assessments

Produktname Hersteller/Vertrieb InternetADONIS® BOC Information Technologies GmbH www.boc-eu.comAENEIS 5 Dr. Schniz GmbH www.schniz.deDHC Vision DHC Dr. Herterich & Consultants GmbH www.dhc-gmbh.comibo Prometheus ibo Software GmbH www.ibo.deiGrafx 2005 iGrafx, www.iGrafx.deLP ProCeed® Lohoff & Partner Consulting & Software

GmbHwww.lohoff-partner.com

Nautilus Agresso GmbH www.agresso.deProcess4.biz 2005 Process4.biz GmbH www.process4.bizSYCAT ProcessDesigner

Dr. Binner Consulting & Software www.sycat.de

auch feine Details mit grafischen Modellen präzise abbilden, ohne auf verbale Texte zu-rückgreifen zu müssen.

Das Produkt iGrafx2005 der Firma iGrafx zeichnet sich vor allem durch eine übersicht-liche Darstellung der Simulationsergebnisse aus. Der Benutzer ist in der Lage, mehrere Si-

http://www.boc-eu.com

http://www.schniz.de

http://www.dhc-gmbh.com

http://www.ibo.de

http://www.iGrafx.de

http://www.lohoff-partner.com

http://www.agresso.de

http://www.process4.biz

http://www.sycat.de

2.11 Wiederholungsfragen zum 2. Kapitel 111

mulationsläufe durchzuführen und die Resultate in Tabellenform gegenüberzustellen undkann so sehr einfach kosten- oder zeitoptimale Prozesse identifizieren.

Sehr anschaulich wirkt die hierarchische Navigation in den Prozessmodellen mit demWerkzeug LP ProCeed® von der Firma Lohoff& Partner. Daneben bietet der Hersteller einHosting-Angebot speziell für KMU-Unternehmen an, was durchaus als sinnvoll angesehenwerden kann.

DasWerkzeug Nautilus, von der Berliner FirmaGedilan Consulting entwickelt und vonder Münchner Agresso GmbH gekauft, basiert ebenfalls auf MS Visio. Es bietet als Beson-derheit eine Übersichtsdarstellung über die Prozesse (Prozesslandkarte), die bottom up ausden Detailmodellen generiert wird und hierdurch die Darstellung von Modellierungszu-sammenhängen erleichtert.

Die Firma Process4.biz bietet ein gleichnamiges Modellierungswerkzeug an. Es basiert,wie auch andere Produkte, auf Microsoft Visio und ist frei in der Darstellung von Notatio-nen. Der Hersteller bietet für verschiedene Einsatzzwecke Referenzmodelle an (z. B. ITIL),die in der Praxis zeitsparend für die Prozessoptimierung eingesetzt werden können.

Das VISIO-basierte Werkzeug SYCAT Process Designer von der Dr. Binner Consulting& Software bietet eine Workflow-Integration. Dies bedeutet, das neben der Built-Time(Modellierung, Simulation) auch die Run-Time (Ausführung und Überwachung) imProcess-Life-Cycle unterstützt wird. Einen weitergehenden Überblick über Werkzeuge fürdas Geschäftsprozessmanagement wird vom Portal „BPM-Guide“ unter der URL http://www.bpm-guide.de/software.html laufend aktualisiert.

2.11 Wiederholungsfragen zum 2. Kapitel

1. Skizzieren Sie die Phasen der Prozessmodellierung.2. Weshalb sind Metamodelle zur Konzeption vonModellsystemen sinnvoll?3. Skizzieren Sie das Grundprinzip von IDEF-Diagrammen.4. Vergleichen Sie Datenflussdiagramme der Strukturierten Analyse (SSA)mit den Fluss-

diagrammen der Structured Systems Analysis (SADT).5. Skizzieren Sie den Zustand eines einfachen Petri-Netzes vor bzw. nach dem Schalten.6. Erstellen Sie ein einfaches Swimlane-Diagramm für einen selbst gewählten Prozess.7. Welche bekannte Modellierungsmethode wurde aus Petri-Netzen entwickelt?8. Vergleichen Sie Swimlane- und Aufgabenkettendiagramme (Promet) hinsichtlich der

Zeilen- bzw. Spalteninhalte.9. Skizzieren Sie die wesentlichen Einsatzbereiche für Prozessmodelle.10.Worin unterscheiden sich mit Modellierungswerkzeugen erzeugte Prozessmodelle von

solchen, die mit Grafiktools erstellt wurden?11. Strukturieren Sie Auswahlkriterien für Modellierungswerkzeuge.

http://www.bpm-guide.de/software.html

http://www.bpm-guide.de/software.html


2.12 Übungen zum 2. Kapitel

Übung 6: Life-Cycle-Modelle in der PraxisAufgabenstellung: Weshalb ist ein einstufiges Life-Cycle-Modell für die Prozessmodellie-rung in der Praxis selten anzutreffen?

Lösungshinweis: Im einstufigen Phasen- bzw. Life-Cycle-Modell wird nur ein einzi-ges Prozessmodell erstellt, das betriebswirtschaftliche Fragen und Ausführungsaspekteberücksichtigenmuss. Es enthält daher ein gemeinsamesGeschäftsprozess- undWorkflow-Modell.

Beide Modelltypen sprechen verschiedene Zielgruppen (Prozessexperten, Prozessmit-arbeiter, Prozessberater versusWorkflow-Modellierer und Softwareentwickler) an und die-nen unterschiedlichen Zwecken. Geschäftsprozessmodelle dienen dem Reengineering derProzesse. Workflow-Modelle unterstützen die Laufzeit von Prozessen, d. h. die reale Aus-führung der Prozesse.

Die am Markt verfügbaren Softwaretools (Modellierungswerkzeuge und Workflow-Management-Systeme) decken oft schwerpunktmäßig nur einen der genannten Model-lierungsaspekte ab. Entweder liegt der Fokus auf der betriebswirtschaftlich geprägtenModellbildung, d. h. der Ist-Analyse und der Restrukturierung der Geschäftsprozesse.Oder aber, der Fokus liegt auf der Ausführung der Modelle, d. h. der Geschäftspro-zessunterstützung im täglichen Betrieb. Werkzeuge, die beide Sichten abbilden, müssenzwangsläufig Kompromisse hinsichtlich der Abdeckung aller Anforderungen eingehen.

2.13 Literaturempfehlungen zum 2. Kapitel

Literaturhinweis BemerkungBrauer (2006) Sehr lesenswerter Artikel über das Leben undWerk vonC.

A. Petri.Gehring (1998) Beschreibung des Rahmenkonzeptes des integrierten

Geschäftsprozess- undWorkflow-ManagementsGehring und Gadatsch (1999a) Ausführliche Beschreibung des Workflow-Life-Cycle-

ModellsHanschke und Lorenz (2012) Praxisnahe Beschreibung von Methoden zur Unterstüt-

zung des strategischen Prozessmanagements.Krüger und Uhlig (2010) Praxisbuch zur Modellierung mit dem ARIS-Werkzeugen

der Firma IDS Scheer, Saarbrücken. Enthält zahlreicheModellierungsbeispiele.

Nüttgens (2002) Struktur und Beschreibung von Auswahlkriterien fürModellierungs- und Analysewerkzeuge

2.13 Literaturempfehlungen zum 2. Kapitel 113

Oestereich et al. (2003) Umfassende und leicht verständliche Einführung mit vie-len Beispielen zur Nutzung der UML für die Geschäftspro-zessmodellierung

Spath et al. (2010) Umfangreicher Produktvergleich der Fraunhofer Gesell-schaft zu BPMN-unterstützenden Softwaretools.

Weilkiens et al. (2010) Praxisbuch zur Vorbereitung auf die Zertifizierung zuGrundlagen der Prozessmodellierung (OMG CertifiedExpert in Business Process Management)

Documents

Grundkurs Geschäftsprozess-Management || Prozessmodellierung