Sie sind auf Seite 1von 19

Hauptstudium

Geschftsprozessmodellierung mit der Ereignisgesteuerten Prozesskette


Prof. Dr. Dr. h.c. mult. August-Wilhelm Scheer / Dipl.-Kfm. Oliver Thomas, Saarbrcken Geschftsprozessmodelle dienen zur Vermittlung zwischen den Mitarbeitern einer Organisation, die ber das fachliche Wissen verfgen, und denjenigen, die ber methodisches oder technisches Wissen verfgen, wie etwa Berater oder Entwickler von Anwendungssystemen. Das Problem der Unschrfe der natrlichen Sprache einerseits und der vielen Problemstellungen inhrenten Unbrauchbarkeit mathematischer Formulierungen andererseits umgehen sie durch semiformale Beschreibungsmglichkeiten. Diese sind eng an betriebswirtschaftliche Fachtermini angelehnt, aber doch exakt genug, dass die Modelle als Ausgangspunkt zur Umsetzung computeruntersttzter Informationssysteme dienen knnen. Hierzu haben sich grafische Darstellungsformen etabliert. Mit der Ereignisgesteuerten Prozesskette (EPK) wird eine Modellierungssprache zur Konstruktion von Prozessmodellen vorgestellt, die in Wissenschaft und Praxis seit mehr als einem Jahrzehnt breite Akzeptanz findet.

1 Geschftsprozessmanagement und -modellierung


RN Aufbauorganisation

Die Organisationslehre betonte lange Zeit die Aufbauorganisation. Diese Betrachtung lediglich zeitlich unabhngiger, statischer Regelungen, wie Hierarchien und Unternehmungstopologien, erfasst nur die Kommunikationsbeziehungen zwischen den Unternehmungsteilen. Bis in die 1990er-Jahre gestaltete sich die Koordination ber knstlich erzeugte Abteilungsmauern hinweg als uerst schwierig. Lediglich das persnliche Engagement und die Abstimmung der Mitarbeiter untereinander konnten die auf diesem Wege erzeugte Sichtweise isolierter betrieblicher Aktivitten ausgleichen. Die Automatisierung interner Verfahren, indem z. B. Informationen nicht mehr papierbasiert, sondern elektronisch bermittelt wurden, blieb hufig einziges Verbesserungspotenzial.
RN Ablauforganisation und Geschftsprozesse

Erst gegen Mitte der letzten Dekade vernderten Begriffe wie Continuous Process Improvement oder Business Process Reengineering die Sichtweise. Die Ablauforganisation, d. h. das 1

zeitlich-logische, dynamische Verhalten von Vorgngen zur Aufgabenerfllung der Unternehmungen, rckte in den Vordergrund. Man versuchte, effiziente Automationsmodelle unternehmungsweit zu implementieren. Die Kommunikation zwischen den Abteilungen und die daraus resultierende Orientierung an der Logik von Geschftsprozessen rckten in den Mittelpunkt. Ein Geschftsprozess ist eine zusammengehrende Abfolge von Verrichtungen zum Zweck der Leistungserstellung. Ausgang und Ergebnis eines Geschftsprozesses ist eine Leistung, die von einem internen oder externen Kunden angefordert und abgenommen wird.
RN Geschftsprozessmanagement und -modellierung

Ziel von Business-Engineering-Projekten ist die Gestaltung der Geschftsprozesse und die Analyse der Anforderungen an deren IT-Untersttzung unter Bercksichtigung von Unternehmungsstrategien. Die Gestaltung der Geschftsprozesse muss einem umfassenden Ansatz folgen, der sowohl die Planung und Kontrolle als auch die Steuerung, d. h. das Management, der betrieblichen Ablufe umfasst. Zur Untersttzung eines systematischen Vorgehens bei der Prozessgestaltung hat sich die Modellierung als hilfreich erwiesen. Modellierungssprachen, wie z. B. die Ereignisgesteuerte Prozesskette (EPK), dienen als operationalisierter Ansatz zur Modellkonstruktion. Softwarewerkzeuge zur Geschftsprozessmodellierung, wie z. B. das ARISToolset der IDS Scheer AG (2003), knnen den Business Engineer durch Systemkomponenten zur Erhebung, Erstellung, Analyse und Simulation von Geschftsprozessmodellen untersttzen. Frage 1: Was versteht man unter einem Geschftsprozess?

Einordnung und Historie der EPK

RN Prozessmodellierungssprachen

Seit Ende der 1970er-Jahre wurde eine Vielzahl von Modellierungssprachen zur Beschreibung von Geschftsprozessen entwickelt z.B.: Flussdiagramme in Form von Struktogrammen, Programmablauf- oder Datenflussplnen, Datenflussdiagramme im Rahmen der Structured Analysis (SA)-Methode, der Netzplan,

das Vorgangskettendiagramm (VKD), das Petri-Netz, die Ereignisgesteuerte Prozesskette (EPK) sowie Anstze zur Prozessmodellierung im Rahmen objektorientierter Modellierungsmethoden.

RN Verbreitung der EPK im deutsprachigen Raum

Zur Konstruktion von Geschftsprozessmodellen auf fachkonzeptioneller Ebene hat sich aufgrund ihrer Anwendungsorientierung und umfassenden Werkzeuguntersttzung insbesondere im deutschsprachigen Raum die Ereignisgesteuerte Prozesskette etabliert (Nttgens, Rump 2002, S. 64). Sie wurde am Institut fr Wirtschaftsinformatik (IWi), Saarbrcken, in Zusammenarbeit mit der SAP AG entwickelt (Keller, Nttgens, Scheer 1992) und ist Bestandteil des ARIS-Toolset der IDS SCHEER AG (2003) sowie des Business Engineering und Customizing des SAP R/3-Systems (Keller, Teufel 1999). Sie gehrt neben dem VKD zu den wichtigsten an diesem Institut entwickelten Prozessbeschreibungssprachen und gilt als zentrale Modellierungssprache der Architektur integrierter Informationssysteme (ARIS) (Scheer 2001; 2002).
RN GI-Arbeitskreis zur EPK

Da die EPK in Forschung und Praxis als Beschreibungssprache fr betriebliche Ablufe weit verbreitet ist, grndeten NTTGENS und RUMP 2002 den Arbeitskreis der Gesellschaft fr Informatik Geschftsprozessmanagement mit Ereignisgesteuerten Prozessketten (WI-EPK) innerhalb des Fachbereichs Wirtschaftsinformatik (FB-WI). Unter der URL http://epk.etinf.fho-emden.de/literatur.php ist eine umfangreiche Literaturliste zur EPK ffentlich zugnglich.

Graphentheoretische Charakterisierung und Terminologie der EPK

RN Graphentheoretische Grundlagen

Ein Graph besteht in der Graphentheorie aus Knoten und Kanten, wobei jede Kante (z. B. Strae) genau zwei Knoten (z. B. Stdte) verbindet und je zwei Knoten durch keine, eine oder mehrere Kanten verbunden sein knnen. Ein Graph wird gerichtet genannt, wenn die Menge der Knotenpaare (also der Kanten) eine Menge von geordneten Paaren ist. In gerichteten Graphen 3

werden die Kanten durch Pfeile statt durch Linien dargestellt, wobei der Pfeil vom Anfangszum Endknoten zeigt. Ein Graph heit zusammenhngend, wenn man von jedem Knoten zu jedem anderen Knoten ber eine Folge von Kanten gelangt, d. h. der Graph nicht in mehrere Teile zerfllt.
RN EPK im Kontext der Graphentheorie

In dieser graphentheoretischen Terminologie ist ein EPK-Modell ein gerichteter und zusammenhngender Graph, dessen Knoten Ereignisse, Funktionen und Verknpfungsoperatoren sind. Diese graphentheoretische Charakterisierung entspricht der Interpretation von RUMP (1999), in der neben Ereignissen und Funktionen auch Verknpfungsoperatoren als Knoten eines EPK-Modells interpretiert werden. In der Literatur werden EPK-Modelle gelegentlich auch als bipartite Graphen eingestuft (Schtte 1998, S. 100), wobei ein Graph bipartit ist, falls es eine Partition der Knotenmenge in zwei Mengen gibt, so dass jede Kante zwischen einem Knoten der ersten Menge und einem Knoten der zweiten Menge verluft. Eine Partition einer gegebenen Menge ist eine Menge paarweise disjunkter nichtleerer Teilmengen der gegebenen Menge, deren Vereinigung gleich der ursprnglich gegebenen Menge ist. Diese Einstufung beschrnkt folglich die Knotenmenge eines EPK-Modells auf zwei Mengen eine Ereignisund eine Funktionenmenge.
RN EPK-Terminologie

Aus Grnden der sprachlichen Klarheit wird nachfolgend die Modellierungssprache Ereignisgesteuerte Prozesskette EPK genannt, whrend ein unter Verwendung dieser Sprache expliziertes Modell als EPK-Modell bezeichnet wird. Analog kann dann auch von einem EPKInformationsmodell oder einem EPK-Referenzmodell gesprochen werden. Gelegentlich findet sich in der Literatur statt EPK-Modell in gleicher Bedeutung auch die Bezeichnung EPKSchema (Nttgens, Rump 2002, S. 65 ff.). Frage 2: Wie knnen EPK-Modelle graphentheoretisch charakterisiert werden?

Grundlegende Sprachkonstrukte der EPK

Abbildung 1 zeigt ein EPK-Modell der Kundenauftragsbearbeitung. Es beschreibt den Ablauf zur Definition und Durchfhrung von Prffunktionen eines Kundenauftrags. Jedes der Negativergebnisse fhrt zur unmittelbaren Ablehnung des Kundenauftrags, unabhngig von den 4

Prfergebnissen der anderen Funktionen. Die grundlegenden Sprachkonstrukte der EPK sowie ihre Reprsentationsformen werden nachfolgend anhand dieses Beispiels erlutert.

Kunde ruft an

Kundenauftrag definieren

Kundenauftrag definiert

Kundenauftrag auf technische Machbarkeit prfen

Kundenauftrag kaufmnnisch prfen

Kundenbonitt prfen

Produktverfgbarkeit prfen

Kundenauftrag technisch machbar

Kundenauftrag nicht technisch machber

Kundenauftrag kaufmnnisch OK

Kundenauftrag kaufmnnisch nicht OK

Kundenbonitt gegeben

Kundenbonitt nicht gegeben

Produkt verfgber

Produkt nicht verfgbar

Kundenauftrag annehmen

Kundenauftrag ablehnen

Kundenauftrag angenommen

Kundenauftrag abgelehnt

Abbildung 1: EPK-Modell einer Kundenauftragsbearbeitung


RN EPK-Sprachkonstrukte

Die Grundelemente der Modellierungssprache EPK sind Ereignisse, Funktionen, Kontrollflusskanten und Verknpfungsoperatoren. Ereignisse sind die passiven Elemente der EPK. Sie beschreiben Zustnde und werden durch Sechsecke dargestellt. Funktionen, die durch an den Ecken abgerundete Rechtecke reprsentiert werden, sind die aktiven Elemente der EPK. Der Funktionsbegriff wird in der EPK mit dem der Aufgabe gleichgesetzt (Keller, Nttgens, Scheer 1992, S. 8). Im Gegensatz zu einer Funktion, die ein zeitverbrauchendes Geschehen ist, ist ein Ereignis auf einen Zeitpunkt bezogen.
RN Namenskonventionen

Whrend zur Bezeichnung der Funktionen in der Literatur (z. B. Hoffmann, Kirsch, Scheer 1992, S. 5) vorgeschlagen wird, das jeweilige Objekt der Bearbeitung und ein Verb im Infinitiv zur Kennzeichnung der zu verrichtenden Ttigkeit zu verwenden (z. B. Kundenauftrag definieren, vgl. Abbildung 1), wird fr Ereignisse empfohlen, das Objekt, das eine Zustandsnderung erfhrt, mit einem Verb im Partizip Perfekt zu verbinden, das die Art der nderung beschreibt (z. B. Kundenauftrag (ist) definiert, vgl. Abbildung 1). Bezeichnungen und Namen von Sprachkonstrukten in Prozessmodellen werden auch im Folgenden bei Erluterungen im Text durch eine serifenlose Schriftart hervorgehoben.
RN Kontrollfluss

Ereignisse lsen Funktionen aus und sind deren Ergebnis. Diese beiden Beziehungen zwischen Funktionen und Ereignissen werden durch Kontrollflusskanten, die durch Pfeile reprsentiert werden, dargestellt. Um auszudrcken, dass eine Funktion durch ein oder mehrere Ereignisse gestartet werden bzw. eine Funktion ein oder mehrere Ereignisse als Ergebnis erzeugen kann, werden Verknpfungsoperatoren (Konnektoren) eingefhrt. Dabei wird in Anlehnung an die Terminologie der Aussagenlogik zwischen konjunktiven , adjunktiven und disjunktiven Verknpfungen unterschieden (vgl. Abbildung 1). Die entsprechenden Konnektoren werden vereinfacht als AND-, OR- bzw. XOR-Operatoren bezeichnet.
RN Syntaxregeln

NTTGENS und RUMP (2002, S. 67 ff.) definieren eine EPK-Syntax, in welcher der Kontrollfluss betrachtet wird und als Knoten Ereignisse, Funktionen, Verknpfungsoperatoren und Prozesswegweiser, die in Abschnitt 5.4 als Erweiterung der EPK eingefhrt werden, zugelassen sind. Auf Basis dieser Syntax formulieren die Autoren Regeln, die der Konstruktion syntaktisch richtiger EPK-Modelle dienen: 1. Ein EPK-Modell ist ein gerichteter und zusammenhngender Graph. 2. Ein EPK-Modell ist in graphentheoretischer Terminologie einfach, wobei einfach bedeutet, dass das EPK-Modell als Graph keine Schlinge (Kante mit gleichen Anfangs- und Endknoten) und keine Mehrfachkanten (mehrere Kanten zwischen Knoten) enthlt. 3. Funktionen besitzen genau eine eingehende und genau eine ausgehende Kontrollflusskante. 4. Ereignisse haben genau eine eingehende und/oder genau eine ausgehende Kontrollflusskante (d. h. falls ein Ereignis nur eine Kontrollflusskante aufweist, handelt es sich um ein Startoder Endereignis). 6

5. Prozesswegweiser haben genau eine eingehende oder eine ausgehende Kontrollflusskante. 6. Verknpfungsoperatoren haben entweder eine eingehende und mehrere ausgehende (SplitOperator) oder mehrere eingehende und eine ausgehende Kontrollflusskante (JoinOperator). 7. Es gibt keinen gerichteten Kreis im EPK-Schema, der nur aus Verknpfungsoperatoren besteht. 8. Ereignisse sind nur mit Funktionen und Prozesswegweisern (mglicherweise ber Verknpfungsoperatoren) verbunden. 9. Funktionen und Prozesswegweiser sind nur mit Ereignissen (mglicherweise ber Verknpfungsoperatoren) verbunden. 10. Nach Ereignissen folgt kein XOR- oder OR-Split-Operator im Kontrollfluss. 11. Es gibt mindestens ein Start- und mindestens ein Endereignis. Frage 3: Aus welchen grundlegenden Sprachkonstrukten besteht die Modellierungssprache EPK?

Modellierungssprachliche Erweiterungen der EPK

RN Erweiterte EPK

In Forschung und Praxis existieren Erweiterungen der Modellierungssprache EPK, die unter anderem darauf abzielen, den Umfang der mglichen Sprachaussagen zu vergrern oder die Handhabbarkeit umfangreicher Modelle zu verbessern. In der Literatur wird dementsprechend in vielen Fllen von der erweiterten EPK (kurz: eEPK) gesprochen (z. B. Rump 1999, S. 51). Dieser Sprachgebrauch wird hier jedoch nicht empfohlen, da keine einheitliche Meinung darber existiert, welche Sprachkonstrukte zu einer Grundform und welche zu einer erweiterten Form der EPK gehren. Auch in der Modellierungspraxis wird diese Bezeichnung uneinheitlich verwendet. 5.1 ARIS-Sprachkonstrukte

RN Erweiterung der Sprachaussagen

Aus der Ableitung der EPK als zentrale Modellierungssprache der Architektur integrierter Informationssysteme (ARIS) (Scheer 2001; 2002) resultieren erweiterte Aussagen, die auf dem ARIS-Sichtenkonzept aufbauen. Diese werden durch Annotation von zustzlichen Sprachkon7

strukten an EPK-Funktionen getroffen. So werden beispielsweise Sprachkonstrukte vorgeschlagen, die Umfelddaten, Nachrichten, menschliche Arbeitsleistung, maschinelle Ressourcen und Computer-Hardware, Anwendungssoftware, Leistungen in Form von Sach-, Dienst- und Informationsdienstleistungen, Finanzmittel, Organisationseinheiten oder Unternehmungsziele reprsentieren (vgl. Abbildung 2). Die Verbindung der Konstrukte, die nur mit Funktionen der EPK erfolgen kann, wird ber Kanten hergestellt, die neben dem bereits eingefhrten Kontrollfluss in Organisations-/Ressourcen-, Informations-, Informationsdienstleistungs- und Sachleistungssowie Finanzmittelfluss unterschieden werden (Scheer 2002, S. 31).
Informationsdienstleistung Umfelddaten Informationsdienstleistung

Ziel

Sonstige Dienstleistung

Sonstige Dienstleistung

wird ver-/bearbeitet Sachleistung wird ver-/bearbeitet

transformiert

steuert

wird erstellt Sachleistung wird erstellt

Finanzmittel

wird ver-/bearbeitet geht ein

wird erstellt geht aus

Finanzmittel

StartEreignis

Funktion

EndEreignis

verantwortlich

bearbeitet

nutzt

nutzt

fhrt aus, steuert

Organisationseinheit

Menschliche Arbeitsleistung

Maschinenressource

ComputerHardware

Software

Legende
Organisations-/ Ressourcenfluss Kontrollfluss Informationsfluss Informationsdienstleistungsfluss Sachleistungsfluss Finanzmittelfluss

Abbildung 2: Erweiterung der EPK um ARIS-Sprachkonstrukte (Quelle: Scheer 2002, S. 31) 5.2 Geteilte Operatoren

RN Ein- und Ausgangsverknpfungen

Die Verknpfungsoperatoren knnen dahingehend unterschieden werden, ob sie eine eingehende und mehrere ausgehende (Split-Operator) oder mehrere eingehende und eine ausgehende 8

Kontrollflusskante (Join-Operator) besitzen. Eine Erweiterung des in der EPK verfolgten Operatorenkonzepts besteht darin, diese Unterscheidung durch geteilte Operatoren, die sowohl eine Eingangs- als auch eine Ausgangsverknpfung unterscheiden, aufzulsen (Scheer 1997, S. 49). Im oberen Bereich des Operators wird das logische Zeichen der Eingangs- und im unteren Bereich das der Ausgangsverknpfung eingetragen. Sofern nur ein Ein- bzw. Ausgang auftritt, entfllt ein entsprechendes logisches Symbol. Falls genau eine Eingangs- und eine Ausgangsverknpfung bestehen, entfllt der Knoten. Mgliche EPK-Modelle und entsprechende Interpretationen der reprsentierten Ablaufstrukturen sind in Abbildung 3 dargestellt.

E1

E2

E1

E2

E1

E2

E1

E2

F1

F1

F1

F2

F1

F2

(a) Wenn Ereignisse E1 und E2 eingetreten sind, startet Funktion F1

(b) Wenn Ereignis E1 oder E2 eingetreten ist, startet Funktion F1

(c) Wenn Ereignisse E1 und E2 eingetreten sind, starten Funktionen F1 und F2

(d) Wenn Ereignis E1 oder E2 eingetreten ist, startet entweder Funktion F1 oder F2

E1

E2

E1

E2

E3

F1

F2

F1

E1

E2

F1

F2

(g) Wenn Funktion F1 oder F2 abgeschlossen ist, tritt entweder Ereignis E1 oder E2 ein

E3

E4

(f) Wenn Ereignis E1 oder E2 eingetreten ist, startet Funktion F1; wenn Ereignis (E1 oder E2) und Ereignis E3 eingetreten sind, startet Funktion F2

F2

F3

(e) Wenn Ereignis E1 oder E2 eingetreten ist, startet Funktion F1, in der entschieden wird, ob entweder Ereignis E3 oder E4 eintritt

Abbildung 3: EPK-Modelle unter Bercksichtigung geteilter Operatoren (in Anlehnung an Scheer 1997, S. 5052) Frage 4: Welcher Unterschied besteht zwischen Split- und Join-Operatoren? 5.3 Modellierung sequenzieller Ablufe

RN Sequenz-Operator

Des Weiteren finden sich in der Literatur Verknpfungsoperatoren, welche auf die Verbesserung der Handhabbarkeit umfangreicher Modelle abzielen, z. B. der Sequenz (SEQ)- (Priemer 1995, S. 269271) oder der Entscheidungstabellen (ET)-Operator (Rosemann 1996, S. 140 ff.). Exemplarisch wird hier der SEQ-Operator vorgestellt. Die Grundidee des SEQ-Operators liegt in der kompakten Darstellung wahlfreier Sequenzen. Beispielsweise ist denkbar, dass an einem Rohteil in der industriellen Fertigung die Arbeitsgnge Bohren, Frsen und Schweien in beliebiger Reihenfolge durchgefhrt werden knnen, das Ergebnis jeder der Funktionen durch keines der beiden anderen beeinflusst wird und eine simultane Durchfhrung von zwei oder gar drei der Arbeitsgnge an dem Rohteil nicht mglich ist. Wrde die bestehende EPK-Syntax verwendet werden, so mssten, um die Flexibilitt bei der Wahl der Reihenfolge der Arbeitsgnge durch das EPK-Modell zu reprsentieren, alle sechs Mglichkeiten, die sich fr die Reihenfolge der Arbeitsgnge ergeben, modelliert werden. Dies ist durch Verwendung einer Prffunktion zweier XOR-Operatoren in Abbildung 4 links dargestellt.
RN Beispiel

Eine wesentlich kompaktere Darstellung ergibt sich durch die Verwendung des SEQ-Operators in Abbildung 4 rechts. Die Darstellung ist so zu interpretieren, dass alle Funktionen die auf den SEQ-Operator folgen, genau einmal und nacheinander auszufhren sind. Dies sind in dem Beispiel die Funktionen Teil bohren, Teil frsen und Teil schweien, die Reihenfolge ihrer Bearbeitung jedoch keine Rolle spielt. Eine Funktion, die dem SEQ-Operator vorgeschaltet ist, prft, welche der sechs mglichen Reihenfolgen auszuwhlen ist. Um zu gewhrleisten, dass das Ende der wahlfreien Sequenz eindeutig zu erkennen ist, werden die durch den SEQ-Operator getrennten Prozessstrnge wieder durch diesen zusammengefhrt.

10

Reihenfolge der Bearbeitung prfen

Reihenfolge der Bearbeitung prfen

SEQ

Teil ist zu bohren

Teil ist zu bohren

Teil ist zu frsen

Teil ist zu frsen

Teil ist zu schweien

Teil ist zu schweien

Teil ist zu bohren

Teil ist zu frsen

Teil ist zu schweien

Teil bohren

Teil bohren

Teil frsen

Teil frsen

Teil schweien

Teil schweien

Teil bohren

Teil frsen

Teil schweien

SEQ

Teil ist gebohrt

Teil ist gebohrt

Teil ist gefrst

Teil ist gefrst

Teil ist geschweit

Teil ist geschweit Aufgaben sind erledigt

Teil frsen

Teil schweien

Teil bohren

Teil schweien

Teil bohren

Teil frsen

Teil ist gefrst

Teil ist geschweit

Teil ist gebohrt

Teil ist geschweit

Teil ist gebohrt

Teil ist gefrst

Teil schweien

Teil frsen

Teil schweien

Teil bohren

Teil frsen

Teil bohren

Teil ist geschweit

Teil ist gefrst

Teil ist geschweit

Teil ist gebohrt

Teil ist gefrst

Teil ist gebohrt

Abbildung 4: Erweiterung der EPK-Syntax um den Sequenz-Operator 5.4 Prozesswegweiser und Funktionsverfeinerung

RN Handhabung umfangreicher EPK-Modelle

Ablauflogische Aspekte von Informationssystemen werden in der Praxis aus Grnden der bersichtlichkeit gemeinhin nicht durch ein einziges EPK-Modell reprsentiert, sondern durch mehrere miteinander verbundene und dekomponierte Teilmodelle. Mehrere EPK-Modelle werden durch so genannte Prozesswegweiser miteinander verknpft. Funktionsverfeinerungen, in der Modellierungspraxis hufig als Hinterlegungen bezeichnet, dienen der Hierarchisierung von EPK-Modellen. In Forschung und Praxis sind unterschiedliche Notationsformen fr diese Erweiterungen zu finden. Abbildung 5 enthlt einen Notationsvorschlag, bei dem die EPKTeilmodelle durch einen Rahmen und einen Namen gekennzeichnet sind. Bei der Dekomposition einer Funktion wird deren Name an das entsprechende Detailmodell vererbt. In Abbildung 5 ist eine solche Dekomposition fr die Funktion F2 vollzogen, wobei diese lediglich darin besteht, zustzliche Sprachkonstrukte an diese EPK-Funktion zu annotieren, um die Aussage um organisatorische und leistungsbezogene Aspekte zu erweitern. Der in Abbildung 5 verwendete 11

Prozesswegweiser verknpft die beiden EPK-Teilmodelle EPK1 und EPK2. Die Bezeichnung des Prozesswegweisers ist jeweils so gewhlt, dass dieser namentlich auf das entsprechende Modell verweist. So zeigt beispielsweise der Prozesswegweiser EPK2 im EPK-Modell EPK1 auf das EPK-Modell EPK2.
EPK1

Ereignis E1

Funktion F1

Funktion F2

Ereignis E2

Ereignis E3

Ereignis E3

Funktion F2

Organisationseinheit O1

Funktion F2

Informationsdienstleistung I1

Ereignis E4

Ereignis E4

EPK2

EPK2

EPK1

Legende
Informationsdienstleistung

Ereignis

Ereignis E4 Funktion Verknpfungsoperatoren

Funktion F3

Prozesswegweiser

Kontrollfluss Organisations-/ Ressourcenfluss

Ereignis E5

Organisationseinheit

Informationsdienstleistungsfluss

Abbildung 5: Erweiterung der EPK um Prozesswegweiser und Funktionsverfeinerungen


RN Navigationsuntersttzung

12

Wie bedeutungsvoll insbesondere das Konstrukt der Funktionsverfeinerung in der Modellierungspraxis ist, lsst sich anhand des in Abbildung 6 dargestellten Ausschnitts des SAP R/3Referenzmodells veranschaulichen. Da dieses Modell aus mehr als 1000 Geschftsprozessen besteht, wird eine berblicksartige grafische Reprsentation erschwert. Durch die Verwendung der Funktionsverfeinerung entsteht eine Hierarchisierung der Teilprozesse. Computergesttzte Modellierungswerkzeuge, wie z. B. das ARIS-Toolset, nutzen diese Hierarchisierung, um den Benutzern eine Navigation der Prozessmodelle zu ermglichen.
(1)
Produktdatenmanagement Produktionsund Beschaffung...

(2)
Presalesabwicklung
Kontrakt ist anzulegen

(3)
Lieferplan ist anzulegen Gruppenkontrakt ist anzulegen Angebotsgrund ist eingetreten

(4)
Angebot ist aus Anfrage anzulegen Folgebeleg ist aus Kontakt anzulegen

Kundenauftragsabwicklu...
Kundenrahmenvertrag Kundenangebotsbearbeitung

Beschaffung

Kundenauftrag sabwicklun...

Produktion

Barverkaufs / Sofortauftragsabwicklung

Vertrieb

Streckenabwicklung
Bestandsfhru ng, Lagerverwal...
Vertriebsbedarfe sind erstellt Positionen sind abgesagt

Konsignationsabwicklung

Lieferplan ist erstellt

Kontrakt ist erstellt

Angebot ist gltig

Angebot ist erstellt

Angebotspositionen sind abgesagt

Beleg ist wegen gesetzlich...

Beleg ist wegen unzureichen...

Kundenservice

IntercompanyAbwicklung
Instandhaltung
Angebotsgrund ist eingetreten Angebot ist aus Anfrage anzulegen Folgebeleg ist aus Kontakt anzulegen Auftrag ist eingetroffen Lieferplanabruf ist erstellt Kundenabruf ist eingetroffen Folgebeleg ist aus Kontakt anzulegen Lieferplanabruf ist erstellt

Qualittsmanagement

Abgabe von Mustern und Werbemitteln

Auftrag ist eingetroffen

Kundenabruf ist eingetroffen

Environment, Health and Safety

Leih- / Leergutabwicklung
Kundenauftragsbearbeitung

Projektmanagement

Reklamationsabwicklung
Kundenauftrag

Externes Rechnungswesen

Bonusabwicklung

Treasury

Auenhandelsabwicklung

Erls- und Kostencontrolling Unternehmenscontrolling


Auftrag ist erstellt Auftrag ist erstellt Lieferung ist zu erstellen Vertriebsbedarfe sind erstellt Erzeugniskalkulation zum Materi... Einzelkalkulation zum Materi... BANF ohne Bezugsquelle ist angelegt Positionen sind abgesagt Beleg ist wegen gesetzlich... Beleg ist wegen unzureichen...

Vertriebsbedarfe sind erstellt

Lieferung ist zu erstellen

BANF ohne Bezugsquelle ist angelegt

Einzelkalkulation zum Materi...

Erzeugniskalkulation zum Materi...

Beleg ist wegen gesetzlich...

Beleg ist wegen unzureichen...

Positionen sind abgesagt

Anlagenmanagement

Immobilienmanagement
Versand Kalkulation Risiko / Kreditmanagement

Organisationsmanagement

Personaladministration
Verkaufsbeleg wurde ber Einzelkalkula... Verkaufsbeleg wurde ber Erzeugnis... Kreditbedingungen sind gendert nderung der Kreditbedingung...

Personalbeschaffung
Lieferungen sind zu disponieren Lieferung ist transportrelevant Warenausgang ist gebucht Transportauftragserstellu... Transportauftragserstellu... Material ist ausgegeben

Personalentwicklung

Vergtungsmanagement

Arbeitgeberleistungsadministration

Transport

Lagerverwaltung

Personalzeitwirtschaft

Frachtkosten pro Position sin...

Personalabrechnung

Warenbewegung ist gebucht

Transportauftragspositio . . .

Legende (1) Unternehmungsprozesse (2) Vertrieb (3) Kundenauftragsabwicklung (4) Kundenauftrag

Veranstaltungsmanagement

Stellenwirtschaft

Fakturierung

Reisemanagement

Warenwirtschaft

Faktura ist fr Buchung freigegeben

Rechnungsliste ist erzeugt

Abbildung 6: SAP R/3-Referenzmodell (Ausschnitt), (Quelle: IDS Scheer AG 2003) Frage 5: Welche Bedeutung hat das EPK-Konstrukt der Funktionsverfeinerung? 5.5 Variantenmanagement

RN EPK-Referenzmodelle und Varianten

Eine andere Erweiterung der EPK resultiert aus dem Arbeitsgebiet der Referenzmodellierung, das bereits in WISU Das Wirtschaftsstudium behandelt wurde (Becker et al. 2002). Ver 13

steht man Referenzmodelle generell als Informationsmodelle zur Untersttzung der Konstruktion anderer Modelle, dann besteht die bei der Anwendung eines Referenzmodells von einem Modellierer zu vollziehende Aufgabe in der Referenzmodelladaption. Die mit diesem Begriff charakterisierte Ableitung spezifischer Modelle aus einem Referenzmodell entspricht im bertragenen Sinne der Bildung von Varianten des Referenzmodells (Schtte 1998, S. 207209). So knnten beispielsweise aus einem Referenzmodell Fertigung die unternehmungsspezifischen Modelle Informationsmodell stckorientierte Fertigung Unternehmung U1 oder Informationsmodell prozessorientierte Fertigung Unternehmung U2 als Varianten abgeleitet sein. Um eine solche Ableitung zu gewhrleisten, mssen alternative Bausteine in den Referenzmodellen vorgehalten werden, die der Modellnutzer whrend der Adaption beispielsweise unter Angabe unternehmungsspezifischer Gegebenheiten beibehlt, ergnzt oder entfernt.
RN Buildtime- und Runtime-Modelle

Diese Bercksichtigung von Alternativen in den Referenzmodellen geht jedoch zu Lasten der Lauffhigkeit der Modelle und impliziert die fr die Referenzmodellierung charakteristische Unterscheidung von Informationsmodellen auf Buildtime- und Runtime-Ebene. Whrend Modelle auf Buildtime-Ebene nicht ablauffhig sein mssen, enthalten Modelle auf RuntimeEbene nur ablauffhige Konstrukte (Schtte 1998, S. 244, Fn. 154).
RN Operatoren zur Referenzmodelladaption

Whrend die Bercksichtigung von ablauflogischen Alternativen auf Ebene der Runtime bereits durch die Verknpfungsoperatoren OR und XOR gewhrleistet ist, muss die EPK zur Darstellung von Alternativen auf Buildtime-Ebene um Konstrukte erweitert werden. Zur Darstellung dieser Alternativen werden so genannte Buildtime-Operatoren eingefhrt (Schtte 1998, S. 244 ff.). Zur Veranschaulichung dieser Operatoren greift Abbildung 7 das EPK-Modell der Kundenauftragsbearbeitung aus Abbildung 1 erneut auf.

14

Referenzmodell (Buildtime)

Unternehmungsspezifische Modelle (Runtime)

Kundenauftrag (KA) definiert

Prfverfahren fr KA festlegen

Kundenauftrag (KA) definiert

Kundenauftrag (KA) definiert

Kundenauftrag (KA) definiert

KA ist auf technische Machbarkeit zu prfen KA auf technische Machbarkeit prfen

KA ist auf Produktverfgbarkeit zu prfen Produktverfgbarkeit prfen

KA auf technische Machbarkeit prfen

Produktverfgbarkeit prfen

KA auf technische Machbarkeit prfen

Produktverfgbarkeit prfen

KA technisch machbar

KA nicht technisch machber

Produkt verfgber

Produkt nicht verfgbar

KA technisch machbar

KA nicht technisch machber

Produkt verfgber

Produkt nicht verfgbar

KA technisch machbar

KA nicht technisch machber

Produkt verfgber

Produkt nicht verfgbar

KA annehmen

KA ablehnen

KA annehmen

KA ablehnen

KA annehmen

KA ablehnen

KA annehmen

KA ablehnen

KA angenommen

KA abgelehnt

KA angenommen

KA abgelehnt

KA angenommen

KA abgelehnt

KA angenommen

KA abgelehnt

Vorhalten der abzuleitenden Varianten durch Verwendung des XORB-Operators

Auswahl des linken Prozessstrangs

Auswahl des rechten Prozessstrangs

Transformation der XORB- zu XOROperatoren und Einfgen einer Prffunktion

Abbildung 7: Ableitung unternehmungsspezifischer EPK-Modelle aus einem EPKReferenzmodell mit Hilfe von Buildtime-Operatoren Whrend die Funktionen zur Prfung des Kundenauftrags auf zwei reduziert sind, ist das Modell um die Verwendung des Buildtime-Operators XORB ergnzt (Schtte 1998, S. 246). Zur Verdeutlichung, dass dieser Operator nur auf Buildtime-Ebene agiert, ist er im Gegensatz zu den Runtime-Operatoren zweifach umrandet.
RN Auflsung von Buildtime-Operatoren

Bei der Ableitung unternehmungsspezifischer Modelle aus dem Referenzmodell ergeben sich drei mgliche Varianten: Entweder wird die Disjunktion auf Buildtime-Ebene zu einer Disjunktion auf Ebene der Runtime oder sie fhrt zur Auswahl eines der beiden Prozessstrnge (vgl. Abbildung 7). Neben dem disjunktiven Buildtime-Operator XORB existieren weitere Operatoren, mit deren Hilfe Varianten aus Referenzmodellen abgeleitet werden knnen (Schtte 1998, S. 251). Fr jeden dieser Buildtime-Operatoren ist festzuhalten, welche Runtime-Operatoren oder Prozessstrnge sich aus ihm deduzieren lassen. Frage 6: Welcher Sachverhalt begrndet die Unterscheidung von EPK-Modellen auf Buildtimeund Runtime-Ebene?

15

Fazit und Ausblick

Die Ereignisgesteuerte Prozesskette ist eine in Wissenschaft und Praxis weit verbreitete Modellierungssprache zur Reprsentation von Geschftsprozessen. Sie ist darber hinaus Gegenstand aktueller Forschungsbemhungen. Die vorliegenden Arbeiten widmen sich einerseits der Konstruktion von Prozessmodellen fr bestimmte Anwendungsdomnen, womit insbesondere auf den Mangel branchenspezifischer Ausrichtungen von Referenzmodellen reagiert wird. Andererseits werden modellierungssprachliche und -methodische Aspekte der Konstruktion von EPKModellen untersucht. Hierbei werden vor allem die Mglichkeiten einer formalen Spezifikation der EPK-Syntax und -Semantik geprft sowie der Bezug zu verwandten Modellierungsanstzen wie Petri-Netzen und UML-Objektmodellen analysiert. Zur Lektre entsprechender Arbeiten wird auf die umfangreiche Literaturliste der EPK-Community verwiesen (vgl. URL http://epk.et-inf.fho-emden.de/literatur.php).

Literatur
Becker, J. / Algermissen, L. / Delfmann, P. / Knackstedt, R.: Referenzmodellierung, in: Das Wirtschaftsstudium 31, Nr. 11 (2002), S. 13921395. Hoffmann, W. / Kirsch, J. / Scheer, A.-W.: Modellierung mit Ereignisgesteuerten Prozeketten, Methodenhandbuch, in: Scheer, A.-W. (Hrsg.): Verffentlichungen des Instituts fr Wirtschaftsinformatik, Nr. 101. Saarbrcken Dezember 1992. IDS Scheer AG (Hrsg.): ARIS Toolset, ARIS Version 6.2.1.31203. Saarbrcken 2003. Keller, G. / Nttgens, M. / Scheer, A.-W.: Semantische Prozemodellierung auf der Grundlage Ereignisgesteuerter Prozeketten (EPK), in: Scheer, A.-W. (Hrsg.): Verffentlichungen des Instituts fr Wirtschaftsinformatik, Nr. 89. Saarbrcken 1992. Keller, G. / Teufel, T.: SAP R/3 prozeorientiert anwenden. Iteratives Prozess-Prototyping mit Ereignisgesteuerten Prozessketten und Knowledge Maps. 3. Aufl., Bonn usw. 1999. Nttgens, M. / Rump, F. J.: Syntax und Semantik Ereignisgesteuerter Prozessketten (EPK), in: Desel, J. / Weske, M. (Hrsg.): Prozessorientierte Methoden und Werkzeuge fr die Entwicklung

16

von Informationssystemen (Promise '2002). Hasso-Plattner-Institut fr Softwaresystemtechnik an der Universitt Potsdam, 9.11. Oktober 2002. Bonn 2002, S. 64 77. Priemer, J. (1995): Entscheidungen ber die Einsetzbarkeit von Software anhand formaler Modelle. Sinzheim 1995, zugl.: Mnster (Westfalen), Univ., Diss. Rosemann, M.: Komplexittsmanagement in Prozessmodellen. Methodenspezifische Gestaltungsempfehlungen fr die Informationsmodellierung. Wiesbaden 1996, zugl.: Mnster (Westfalen), Univ., Diss., 1995. Rump, F. J.: Geschftsprozemanagement auf der Basis ereignisgesteuerter Prozeketten: Formalisierung, Analyse und Ausfhrung von EPKs. Stuttgart usw. 1999, zugl.: Oldenburg, Univ., Diss., u.d.T.: Durchgngiges Management von Geschftsprozesen auf Basis ereignisgesteuerter Prozessketten. Scheer, A.-W.: Wirtschaftsinformatik: Referenzmodelle fr industrielle Geschftsprozesse. 7. Aufl., Berlin usw. 1997. Scheer, A.-W.: ARIS Modellierungsmethoden, Metamodelle, Anwendungen. 4. Aufl., Berlin usw. 2001. Scheer, A.-W.: ARIS Vom Geschftsprozess zum Anwendungssystem. 4. Aufl., Berlin usw. 2002. Schtte, R.: Grundstze ordnungsmiger Referenzmodellierung: Konstruktion konfigurationsund anpassungsorientierter Modelle. Wiesbaden 1998, zugl. Mnster (Westfalen), Univ., Diss., 1997.

17

Antworten auf die Kontrollfragen Frage 1: Was versteht man unter einem Geschftsprozess? Unter einem Geschftsprozess wird eine zusammengehrende Abfolge von Unternehmungsverrichtungen zum Zweck einer Leistungserstellung verstanden. Ausgang und Ergebnis eines Geschftsprozesses ist eine Leistung, die von einem internen oder externen Kunden angefordert und abgenommen wird. Frage 2: Wie knnen EPK-Modelle graphentheoretisch charakterisiert werden? Ein EPK-Modell kann graphentheoretisch als gerichteter und zusammenhngender Graph charakterisiert werden, dessen Knoten Ereignisse, Funktionen und Verknpfungsoperatoren sind. Gerichtet heit hierbei, dass die Menge der Knotenpaare eine Menge von geordneten Paaren ist, zusammenhngend heit, dass man von jedem Knoten zu jedem anderen Knoten des EPK-Modells ber eine Folge von Kanten gelangt. Frage 3: Aus welchen grundlegenden Sprachkonstrukten besteht die Modellierungssprache EPK? Die Grundelemente der Modellierungssprache EPK sind Ereignisse, Funktionen, Kontrollflusskanten und Verknpfungsoperatoren. Ereignisse sind die passiven Elemente der EPK. Sie beschreiben Zustnde und werden durch Sechsecke dargestellt. Im Gegensatz zu einer Funktion, die ein zeitverbrauchendes Geschehen ist, ist ein Ereignis auf einen Zeitpunkt bezogen. Funktionen, die durch an den Ecken abgerundete Rechtecke reprsentiert werden, sind die aktiven Elemente der EPK. Kontrollflusskanten, die durch Pfeile reprsentiert werden, stellen Beziehungen zwischen Funktionen und Ereignissen dar: Ereignisse lsen Funktionen aus und sind deren Ergebnis. Verknpfungsoperatoren drcken aus, dass eine Funktion durch ein oder mehrere Ereignisse gestartet werden kann bzw. eine Funktion ein oder mehrere Ereignisse als Ergebnis erzeugen kann. Dabei wird zwischen konjunktiven, adjunktiven und disjunktiven Verknpfungen unterschieden. Frage 4: Welcher Unterschied besteht zwischen Split- und Join-Operatoren? Split-Operatoren besitzen eine eingehende und mehrere ausgehende Kontrollflusskanten. JoinOperatoren besitzen mehrere eingehende und eine ausgehende Kontrollflusskante. 18

Frage 5: Welche Bedeutung hat das EPK-Konstrukt der Funktionsverfeinerung? Umfangreiche Prozesse sollten aus Grnden der bersichtlichkeit in der Regel nicht durch ein einziges EPK-Modell reprsentiert werden, sondern durch mehrere miteinander verbundene und dekomponierte Teilmodelle. ber so genannte Funktionsverfeinerungen wird eine Hierarchisierung von EPK-Modellen erreicht, mit deren Hilfe groe Modelle handhabbar werden. Computergesttzte Modellierungswerkzeuge nutzen diese Hierarchisierung, um den Benutzern eine Navigation in den Prozessmodellen zu ermglichen. Frage 6: Welcher Sachverhalt begrndet die Unterscheidung von EPK-Modellen auf Buildtimeund Runtime-Ebene? Die Ableitung spezifischer EPK-Modelle kann aus bereits vorhandenen EPK-Modellen erfolgen. Liegen diese EPK-Modelle als Referenzmodelle vor, knnen alternative Bausteine in den Modellen vorgehalten werden, deren Auswahl zum Zeitpunkt der Modellkonstruktion durch den Modellierer erfolgt. Diese Bercksichtigung von Alternativen liefert die Unterscheidung von Informationsmodellen auf Buildtime- und Runtime-Ebene. Whrend Modelle auf Buildtime-Ebene zustzliche Konstrukte zur Bercksichtigung von Alternativen zum Zeitpunkt der Konstruktion enthalten und nicht ablauffhig sein mssen, enthalten Modelle auf RuntimeEbene nur ablauflogische Alternativen und sind daher ablauffhig.

19

Das könnte Ihnen auch gefallen