Dokumentvorlage f黵 wissenschaftl by wuyunyi

VIEWS: 65 PAGES: 33

									                        Westfälische Wilhelms-Universität Münster




                                     Thema:
            Prozessmodellierung mit der Ereignisgesteuerten Prozesskette




                                  Ausarbeitung
                    im Rahmen des Projektseminars eGovernment

                        im Fachgebiet Wirtschaftsinformatik
        am Lehrstuhl für Wirtschaftsinformatik und Informationsmanagement




Themensteller:   Prof. Dr. Jörg Becker
Betreuer:        Dipl.-Wirt.Inform. Patrick Delfmann

vorgelegt von:   Sebastian Drawe
                 Rudolf-Harbig Weg 34
                 48149 Münster
                 0251-83815370


Abgabetermin:    2004-04-14
                                                                                                                            – II –




Inhaltsverzeichnis

Inhaltsverzeichnis ............................................................................................................. II
Abbildungsverzeichnis ....................................................................................................III
Abkürzungsverzeichnis .................................................................................................. IV
1 Aufbau und Ziel der Arbeit ...........................................................................................1
2 Begriffliche Grundlagen und deren systematischen Einordnung .................................2
  2.1 Definitionen und Darstellung von Prozessen ........................................................2
  2.2 Architektur integrierter Informationssysteme ........................................................5
3 Ereignisgesteuerte Prozesskette ....................................................................................7
  3.1 Einführung .............................................................................................................7
  3.2 Erweiterte Ereignisgesteuerte Prozesskette .........................................................10
  3.3 Zusätzliche Verknüpfungsoperatoren ..................................................................12
  3.4 Modellierungskonventionen der Ereignisgesteuerten Prozesskette .....................15
  3.5 Prozessmetamodell .............................................................................................. 19
4 Erweiterungen der Ereignisgesteuerten Prozesskette .................................................21
  4.1 Erweiterung der EPK um das Prozessobjekt .......................................................21
  4.2 Verbindung objektorientierter Modellierung mit EPKs ......................................22
  4.3 Erweiterungen der eEPK im eGovernment .........................................................23
5 Fazit und Ausblick ......................................................................................................25
Literaturverzeichnis .........................................................................................................26
                                                                                                                    – III –




Abbildungsverzeichnis

Abb. 2.1:   Modelle als Konstruktionsleistung .................................................................4
Abb. 3.1:   Verknüpfungsarten .......................................................................................10
Abb. 3.2:   Erweiterte Ereignisgesteuerte Prozesskette ..................................................11
Abb. 3.3:   ET-Operator und Entscheidungstabelle ........................................................13
Abb. 3.4:   SEQ-Operator ............................................................................................... 14
Abb. 3.5:   OR1-Operator ................................................................................................ 15
Abb. 3.6:   Beispiel einer eEPK in Spaltendarstellung ...................................................18
Abb. 3.7:   Metamodell der Modellierungstechnik der eEPK ........................................20
Abb. 4.1:   Beispiel eines Prozessobjektmodell .............................................................. 21
Abb. 4.2:   Grundmodell einer oEPK .............................................................................23
Abb. 4.3:   Beispiel einer Erweiterung der eEPK im eGovernment ............................... 24
                                                                  – IV –




Abkürzungsverzeichnis

Abb.          Abbildung
ARIS          Architektur intergrieter Informationsysteme
DIN           Deutsches Institut für Normung
eEPK          erweiterte Ereignisgesteuerte Prozesskette
eGovernment   Electronic Government
EPK           Ereignisgesteuerte Prozesskette
ERM           Entity-Relationship-Model
et al.        et alii
GoM           Grundsätze ordnungsmäßiger Modellierung
ISO           International Organisation for Standardisation
oEPK          objektorientierte Ereignisgesteuerte Prozesskette
PE            Prozesselement
PF            Prozessfunktion
                                                                                  –1–




1        Aufbau und Ziel der Arbeit

In den vergangenen Jahrzehnten orientierten sich die Unternehmen an der effizienten
Ausführung von Einzelfunktionen. Dies hatte zur Folge, dass einzelne
Funktionsbereiche optimiert und perfektioniert wurden. Um die Gesamtheit eine
Organisation zu stärken, ist es notwendig sich auf die Prozesse zu fokussieren.1 Damit
Prozesse transparent für Analysen aufbereitet werden können, bedarf es deren
Modellierung.

Das Thema dieser Arbeit ist die Prozessmodellierung mit der Ereignisgesteuerten
Prozesskette (EPK). Die Methode der EPK wurde am Institut der Wirtschaftsinformatik
der Universität des Saarlandes, Anfang der 90er Jahre in Zusammenarbeit mit der SAP
AG entwickelt.2 Durch umfangreiche Toolunterstützung hat diese Methode Zugang in
die Praxis gefunden.

Ziel dieser Arbeit ist eine umfangreiche Darstellung der EPK und eine
Zusammenstellung von ausgewählten Erweiterungsmöglichkeiten. In Kapitel 2.1 wird
das terminologische Grundgerüst definiert. Es wird ein kurzer Überblick über die
Definitionsvielfalt des Prozessbegriffs gegeben, um danach auf den Modell- und
Prozessmodellbegriff näher einzugehen. In Kapitel 2.2 wird die Architektur integrierter
Informationsmodelle vorgestellt und hier die Methode der EPK eingeordnet. Nachdem
sich das Kapitel 3 mit den konzeptionellen Grundlagen der EPK befasst, werden in
Kapitel 4 ausgewählte Erweiterungen der EPK vorgestellt. Abschließend folgt in
Kapitel 5 eine Diskussion über die Bedeutsamkeit des Konzepts und eine
Zusammenfassung der Ergebnisse der Untersuchung.




1
    Vgl. Becker, Kahn (2004), S. 4f.
2
    Vgl. Scheer (2001), S. 125.
                                                                                          –2–




2         Begriffliche Grundlagen und deren systematischen Einordnung


2.1       Definitionen und Darstellung von Prozessen

Im folgenden werden die Begriffe Prozess, Geschäftsprozess,                     Modell und
Prozessmodell definiert.


Der Prozessbegriff

In der Literatur hat sich bisher keine allgemeingültige Definition für den Begriff Prozess
herausgebildet. Nach DIN 66201 wird ein Prozess definiert als Umformung und/oder
Transport von Materie oder/und Energie oder/und Information.

In der Informatik wird der Prozessbegriff nach der DIN 66201 weiter eingeschränkt,
dort wird der Prozess als der Vorgang einer algorithmisch ablaufenden
Informationsverarbeitung verstanden wird.3

Der Prozessbegriff wird in der Betriebswirtschaftslehre oft in Zusammenhang mit der
Ablauforganisation gebracht. Die Aufbauorganisation nimmt die Gliederung der
Unternehmung in Teilssysteme vor (z. B. Abteilung, Divisionen, Stellen) und ordnet
den Teilsystemen Aufgaben zu,4 während sich die Ablauforganisation mit der
Durchführung und Koordination der zeitlichen und räumlichen Aspekte der Aufgaben
befasst.5 Grundbestandteile eines (Arbeits-)Prozesses sind die Aktivitäten, welche die
elementaren Bestandteile einer Aufgabe sind.6

Daraus leiten BECKER und KAHN folgende Definition ab: Unter einem Prozess wird „die
inhaltliche abgeschlossene, zeitlich und sachlogische Folge von Aktivitäten
[verstanden], die zur Bearbeitung eines prozessprägenden betriebswirtschaftlichen
Objekts7 notwendig sind“8.

Als besondere Untermenge dieser Prozesse werden Geschäftsprozesse abgegrenzt.9 In
der Literatur wird häufig nicht zwischen Prozess und Geschäftsprozess unterschieden,
„dennoch legt der Begriff Geschäftsprozess nahe, dass es sich um einen speziellen

3
      Vgl. o. V. (1993), S. 559.
4
      Vgl. Lehmann (1974), S. 290.
5
      Vgl. Schweitzer (1974), S. 1; Esswein, (1993), S. 551.
6
      Vgl. Becker, Kahn (2002), S. 6.
7
      „Ein solches prozessprägendes Objekt kann z. B. eine Rechnung, ein Kundenauftrag oder ein
      Werkstück sein.“ Becker, Kahn (2002), S. 6.
8
      Vgl. Becker, Kahn (2002), S. 6.
9
      Vgl. Rosemann (1996), S. 11.
                                                                                                 –3–




Prozess handelt“10. Ein Geschäftsprozess ist durch die obersten Ziele der Unternehmung
(Geschäftsziele) und das zentrale Geschäftsfeld geprägt.11 Nach VON EIFF besteht ein
Geschäftsprozess grundsätzlich in der „ablauforganisatorischen Verbindung vom
Lieferanten bis zum Kunden“12. Demzufolge sind die wesentlichen Merkmale eines
Geschäftsprozesses die Schnittestellen zu seinen externen Geschäftspartnern.13

Eine weitere Klassifikation von Prozessen ist die Trennung in Kernprozesse und
Supportprozesse. Die Aktivitäten eines Kernprozesses haben direkten Bezug zum
Produkt eines Unternehmens und leisten einen Beitrag zur Wertschöpfung im
Unternehmen. Supportprozesse sind Prozesse, deren Aktivitäten aus Kundensicht nicht
wertschöpfend sind, jedoch notwendig sind, um einen Kernprozess ausführen zu
können.14


Der Modellbegriff

Notwendige Vorraussetzung jeglicher Auseinandersetzung mit Modellen ist zunächst
die Konkretisierung des zugrunde liegenden Modellverständnisses.

„Ein Modell ist die Repräsentation eines Objektsystems (eines Originals) für Zwecke
eines Subjekts. Es ist das Ergebnis einer Konstruktion eines Subjekts (des Modellierers),
das für eine bestimmte Adressatengruppe (Modellnutzer) eine Repräsentation eines
Originals zu einer Zeit als relevant mit Hilfe einer Sprache deklariert“15 (vgl. Abb. 2.1).
Ein Modell ist somit zusammengesetzt aus der Konstruktion des Modellierers, dem
Modellnutzer, einem Original16, der Zeit17 und einer Sprache. Unter einem Subjekt
verstehen BECKER und SCHÜTTE ein Individuum, welches wie in der Philosophie als ein
„mit Bewusstsein begabtes, erkennendes, handelndes Wesen, Ich, Individuum“
verstanden wird.18

Das modellierende bzw. modellnutzende Subjekt treten in der Definition nur im
Singular auf, dies soll aber nicht die Situation ausschließen, dass mehrere Subjekte für
die Erstellung bzw. Nutzung eines Modells verantwortlich sind. Modellierer bzw.

10
     Becker, Vossen (1996), S. 18.
11
     Vgl. Becker, Kahn (2002), S. 6.
12
     v. Eiff (1991), S. 60.
13
     Vgl. Becker, Kahn (2002), S. 7.
14
     Vgl. Becker, Kahn (2002), S. 7.
15
     Becker, Schütte (2004), S. 65.
16
     „Bei dem Original kann es um ein beliebiges Problem handeln, das modelliert werden soll.“ Becker,
     Schütte (2004), S. 67.
17
     Die Zeit zeigt auf, wann das Modell erstellt wurde und wie lange es Gültigkeit besitzt. Vgl. dazu
     ausführlich Becker, Schütte (2004), S. 67.
18
     Vgl. Becker, Schütte (2004), S. 65.
                                                                                                                                        –4–




Modellnutzer können nicht nur konkrete Subjekte sein, sondern auch ein abstraktes
Subjekt (z. B. ein Unternehmen) oder ein Menge von mehreren abstrakten Subjekten
(z. B. Buchhalter und Anwendungsprogrammierer Finanzbuchhaltung) darstellen. Bei
komplexen Problemstellungen stellt sich die Frage, was es zu modellieren gilt. In der
Frage nach dem „Was“ zeigt sich die subjektive Deutung durch den Modellierer. Das
Ergebnis des Modelliervorgangs ist das explizite Modell als sprachlich formuliertes
Artefakt.19

                                                      internes
                                                       (men-
                                                 es
                                            on d rs     tales)
                                     trukti      e
                                 Kons ellerstell       Modell
                                  Mod
                                                      Ersteller     Ex
                                                                       p   lik
                                                                                 ati                                   Modell
                                                                                       on
                                                                                                                        der
                                                                                            explizites
                                                                                                                      Modellie-
                                                                        ng                   Modell-                   rungs-     ...
                                                                    rk u
                                 Ko                                                          system                   sprache
                                 Monstru
                                                                      i
                                                                   tw


                                    de ktio                             Subjekte                                       eines
                                                                   Mi



                                      llnu n                                                                          Modells
                                          tze des     internes
                                             rs
                                                       (men-
                                                        tales)
                                                       Modell
                                                       Nutzer


                    beliebiges                        interne(s)                                         externe(s)
                     Original                         Modell(e)                                          Modell(e)


                                                                                                              Quelle: Schütte (1998), S.61.
Abb. 2.1:       Modelle als Konstruktionsleistung

„Modelle, bei denen das Objektsystem ein Informationssystem darstellt, werden als
Informationsmodelle bezeichnet.“20 Ein Informationssystem wiederum als das gesamte
informationsverarbeitende Teilssystem des jeweiligen Gegenstandsbereiches.21

Um die Komplexität von Informationsmodellen zu beherrschen, wurden die Grundsätze
ordnungsmäßiger Modellierung entwickelt. Sechs Grundsätze stellen die wesentlichen
Qualitätskriterien im Rahmen der Informationsmodellierung dar:22 Grundsatz der
Richtigkeit, Relevanz, Wirtschaftlichkeit, Klarheit, Vergleichbarkeit und des
systematischen Aufbaus.


Prozessmodelle

Prozessmodelle stellen eine abstrahierte und formale Darstellung der in einem
Betrachtungsbereich ablaufenden Prozesse dar. Die Haupteinsatzzwecke der
Prozessmodellierung sind die Organisations- und die Anwendungssystemgestaltung.23

19
     Vgl. Schütte (1997), S. 60; Becker, Schütte (2004), S. 66.
20
     Rosemann (1996), S. 20.
21
     Ferstl, Sinz (1994), S. 2f.
22
     Ausführlich zu den GoM vgl. Rosemann, Schwegmann (2002), S. 49f.
23
     Vgl. Rosemann, Schwegmann (2004), S. 58.
                                                                                    –5–




KRUSE und SCHEER unterscheiden hierbei drei Arten der Prozessmodellierung:24

         Die betriebliche Prozessmodellierung orientiert sich an der betrieblichen
          Ablauforganisation. Es wird untersucht, wie der Arbeitsablauf als räumliche und
          zeitliche Folge des Zusammenwirkens von Mensch, Betriebsmitteln und
          Arbeitssystemen gestaltet werden kann.

         Die informationstechnische Prozessmodellierung dient der prozessorientierten
          Softwareerstellung.    Ziel    ist   die    Umsetzung    einer    gegebenen
          Anforderungsdefinition in eine Modul- und Systemsspezifikation, wobei
          verifizierbare und syntaktisch korrekte Programmbestandteile erzeugt werden
          sollen.

         Die semantische Prozessmodellierung versteht sich als Bindeglied zwischen
          betriebswirtschaftlicher und informationstechnischer Prozessmodellierung. Sie
          dient der Modellierung betriebswirtschaftlicher Informationssysteme. Dabei
          steht die Abbildungstreue der Anforderungsdefinition gegenüber dem
          betriebswirtschaftlichen Sachverhalt im Vordergrund.


2.2        Architektur integrierter Informationssysteme

Die von SCHEER entwickelte Architektur integrierter Informationssysteme (ARIS)25 „ist
eine umfassende Methodologie zur Beschreibung von Informationssystemen zur
Unterstützung von Geschäftsprozessen“26. Zur Bewältigung der Komplexität wird das
Unternehmen in vier Beschreibungssichten unterteilt:27

         Die Datensicht dokumentiert die Beziehungen und möglichen Zustände der
          Informationsobjekte (z. B. Kunde, Artikel).

         In der Funktionssicht werden die betriebswirtschaftlich relevanten Funktionen
          eines Unternehmens und deren Anordnungsbeziehungen abgebildet (z. B.
          Auftragsannahme), sowie die Aufzählung der einzelnen Teilfunktionen.

         Die Strukturen der Aufbauorganisation legt die Organisationssicht fest, dabei
          werden die Organisationseinheiten und deren Beziehungen untereinander
          dargestellt.

24
      Vgl. Kruse, Scheer (1992), S. 5f.
25
      Vgl. beispielsweise Scheer (1997).
26
      Rump (1998), S. 55.
27
      Vgl. Scheer (1997), S. 10ff.
                                                                                               –6–




        „Die Prozesssicht28 stellt eine Beschreibungssicht dar, die die Zusammenhänge
         zwischen Daten-, Funktions- und Organisationssicht objektbezogen abbildet und
         zusätzlich den Kontrollfluss aufzeigt. […] Somit kann in der Prozesssicht die
         Frage beantwortet werden, wie die zeitsachlogische Abfolge einzelner
         betrieblicher   Funktionen       (Funktionssicht)   zur     Bearbeitung  eines
         betriebswirtschaftlich relevanten Objekts (Datensicht) ist und welche
         Organisationseinheiten (Organisationssicht) für diesen Ablauf verantwortlich
         sind.“29

SCHEER unterscheidet weiterhin in seiner Architektur drei Beschreibungsebenen:30

        Beim      dem    Fachkonzept      dominieren     die    betriebswirtschaftlichen-
         organisatorischen Inhalte, deren Darstellung auf Basis der semantischen Modelle
         erfolgt. Diese werden in einer soweit formalisierten Sprache beschrieben, dass
         sie Ausgangspunkt einer konsistenten Umsetzung in die Informationstechnik
         sein können.

        In der Ebene des DV-Konzepts werden die Fachmodelle an die Anforderungen
         der Schnittstellen von Implementierungswerkzeugen angepasst, ohne auf
         konkrete Implementierungstechniken einzugehen.

        Im Rahmen des Implementierungskonzepts wird das DV-Konzept auf konkrete
         hardware- und softwaretechnische Komponenten übertragen.

Auf der Fachkonzeptebene werden gemeinhin gerichtete Graphen zur Modellierung von
Prozessen verwendet. Abhängig von der verfolgten Zielsetzung der
Prozessmodellierung, können beispielsweise Petri-Netze,31 Ereignisgesteuerte
Prozessketten,32 Kunden-Lieferanten-Protokolle33 oder objektorientierte Ansätze34
eingesetzt werden.35




28
     SCHEER bezeichnet sie als Steuerungssicht.
29
     Becker, Schütte (2004), S. 108.
30
     Vgl. Scheer (1997), S. 14ff.
31
     Vgl. zu Petri-Netzen u a. Rosenstengel, Winand (1991); Rozenberg (1989); Reisig (1986).
32
     Vgl. hierzu Kapitel 3 und 4.
33
     Vgl. Scherr (1991).
34
     Vgl. Martin, Odell (1992).
35
     Vgl. Becker, Schütte (2004), S. 108.
                                                                              –7–




3          Ereignisgesteuerte Prozesskette


3.1        Einführung

EPKs verbinden den Formalismus der Petri-Netze mit den Konstrukten stochastischer
Netzpläne36 und erlauben „eine anschauliche Modellierung von Kontrollflüssen, die
auch für Modellnutzer ohne fundiertes modelltechnisches Vorwissen geeignet ist“37.
Gegenüber     den      Petri-Netzen      unterstützen    EPKs     nicht  nur   den
Informationssystemgestalter,     sondern     sie   haben   auch      das Ziel, den
                                                                     38
Organisationsgestalter bei entsprechenden Fragestellungen zu helfen.

Die EPK beschreibt, welche Ereignisse welche Funktionen auslösen und welche
Ereignisse von welchen Funktionen erzeugt werden. Die drei Basiselemente der EPK
sind:39

         Funktion

         Ereignis

         Verknüpfungsoperatoren

EPKs sind gerichtete, bipartite Graphen. Es dürfen demnach nur unterschiedliche
Knotentypen (hier: Ereignisse und Funktionen) über gerichtete Kanten verbunden
werden.40

Funktionen transformieren Input- in Outputvariablen, indem sie Objekte lesen,
verändern, löschen oder erzeugen. Sie besitzen Entscheidungskompetenz über den
weiteren Prozessverlauf und stellen die aktive Komponente des EPK-Modells dar.41.
Funktionen verbrauchen, im Gegensatz zu Ereignissen, Zeit und Kosten. Je nach
Detaillierungsgrad können Funktionen selbst wiederum als Prozesse identifiziert
werden. Graphisch werden sie, in der gängigsten EPK-Notation, durch abgerundete
Rechtecke wiedergeben.42




36
      Vgl. Rosemann (1996), S. 64.
37
      Rosemann, Schwegmann (2002), S. 65.
38
      Vgl. Becker, Schütte (2004), S. 110.
39
      Vgl. Keller, Nüttgens, Scheer (1992), S. 7-16.
40
      Vgl. Rosemann (1996), S. 68
41
      Vgl. Rosemann, Schwegmann (2002), S. 66.
42
      Vgl. Scheer, Jost (1996), S. 35.
                                                                                     –8–




„Ereignisse repräsentieren ablaufrelevante Zustandsausprägungen“43, die notwendig
sind, um logische und zeitliche Abhängigkeiten zwischen den Funktionen transparent
abbilden zu können.44 Sie stellen den eingetretenen betriebwirtschaftlichen Zustand dar
und dienen zur Spezifikation betriebwirtschaftlicher Bedingungen. Ereignisse sind
zeitpunktbezogen und bilden die passive Komponente der EPK, da sie keine
Entscheidungskompetenz besitzen.45 I. d. R. können einem Ereignis mehrere Funktionen
folgen, anderseits kann erst der Abschluss mehrerer Funktionen ein Ereignis auslösen46
(außer Start- und Endereignisse, die einen Prozess beginnen bzw. beenden). In der EPK
werden Ereignisse als Sechsecke dargestellt. Sie erfüllen potenziell zwei Aufgaben:
Zum einen lösen sie Funktionen aus, zum anderen dokumentieren sie einen durch die
Abarbeitung einer oder mehrerer Funktionen erreichten Zustand. Dabei lassen sich vier
Ereignisarten unterscheiden:47

        Das Ereignis kennzeichnet ein neues Prozessobjekt bzw. den finalen Status eines
         bestehenden Prozessobjekts. Dabei handelt es sich oftmals um die Start- bzw.
         Endereignisse eines Prozesses (z. B. „Zahlung ist eingegangen“ bzw. „“Projekt
         ist abgeschlossen“).

        Das Ereignis betrifft eine Attributänderung des Prozessobjekts, die aber nicht
         zwingend dem Informationssystem bekannt gemacht werden muss (z. B. „Kunde
         hat angerufen“).

        Das Ereignis beschreibt das Eintreffen eines bestimmten Zeitpunktes (z. B.
         „Kreditlimit ist erreicht“).

        Das Ereignis steht für eine Bestandsveränderung, die einen Prozess auslöst (z. B.
         „Kreditlimit ist überschritten“).

Dadurch, dass jede EPK mit einem oder mehreren Ereignissen beginnen und enden
muss, wird sichergestellt, dass Anfangs- und Endbedingungen des Prozesses benannt
werden und jede Funktion zu einer Zustandsveränderung führt.48

Durch die Aufeinanderfolge von Funktionen und Ereignissen lassen sich komplexe
Vorgänge abbilden. Bei nicht sequentiellen Abläufen legen Verknüpfungsoperatoren die



43
     Rosemann (1996), S. 65.
44
     Vgl. Scheer, Jost (1996), S. 35.
45
     Vgl. Keller, Nüttgens, Scheer (1992), S. 10.
46
     Vgl. Scheer (2001), S. 125.
47
     Vgl. Rosemann (1996), S.65.
48
     Vgl. Rosemann (1996), S. 65.
                                                                                  –9–




Ablauflogik fest. Es können bei der Modellierung von EPKs drei Grundformen
auftreten:49

        Die Konjunktion von zwei Aussagen besagt, dass die Gesamtaussage wahr ist,
         wenn beide Aussagen gleichzeitig war sind („logische UND“). In der EPK wird
         diese Verknüpfung mit dem Symbol                 wiedergegeben.

        Die Disjunktion von zwei Aussagen besagt, dass die Gesamtaussage wahr ist,
         wenn genau eine Aussage wahr ist („exklusives ODER“). Diese Art der
                                                    XOR
         Verknüpfung wird durch das Symbol                ausgedrückt.

        Die Adjunktion von zwei Aussagen besagt, dass die Gesamtaussage wahr ist,
         wenn mindestens eine Aussage wahr ist („inklusives ODER“). Sie wird durch
         das Symbol        wiedergegeben.

Es können gleiche oder verschiedene Verknüpfungsoperatoren aufeinander folgen.
Hierbei müssen die Eingangsverknüpfungen und die korrespondierenden
Ausgangsverknüpfungen vom gleichen Typ sein.50

Wird eine Prozesskette in einzelne Teilprozess aufgespaltet, so handelt es sich um eine
Ausgangverknüpfung; laufen mehrere Teilprozesse an einer Stelle zusammen, so liegt
eine Eingangverknüpfung vor.51

Mit der Verknüpfungsart wird angegeben, welche Elemente in den Modellen verknüpft
werden. Werden mehrere Ereignisse mit einer Funktion verknüpft, so handelt es sich um
eine Ereignisverknüpfung. Sind mehrere Funktionen mit einem Ereignis verknüpft, so
handelt es sich um eine Funktionsverknüpfung.52

Mögliche Verknüpfungsarten von Funktionen und Ereignissen sind in Abb. 3.1
dargestellt. Die in Abb. 3.1 gewählte Darstellungsform der Verknüpfungsoperatoren
stellt in der oberen Hälfte des Kreises die Eingangsverknüpfung dar, die untere Hälfte
repräsentiert die Ausgangverknüpfung. Durch diese Art der Darstellung kann den
Prozessmodellen unmittelbar entnommen werden, ob es sich um einen Eingangs- und
Ausgangsoperator handelt.53



49
     Vgl. Keller, Nüttgens, Scheer (1992), S. 13.
50
     Vgl. dazu ausführlich Rosemann (1996), S. 110-116.
51
     Vgl. Rosemann (1996), S. 68.
52
     Vgl. Keller, Nüttgens, Scheer (1992), S. 13.
53
     Vgl. Becker, Schütte (2004), S. 112f.
                                                                                                      – 10 –




                        Verknüpfungs-
                           operatoren         Disjunktion            Konjunktion         Adjunktion
     Verknüpfungsart




                        Auslösende                XOR

                        Ereignisse



        Ereignis-
       verknüpfung



                          Erzeugte
                                                  XOR
                         Ereignisse




                        Auslösendes
                                                  XOR
                          Ereignis



        Funktions-
       verknüpfung



                         Erzeugtes                XOR

                          Ereignis




                              nicht erlaubt



                                                            Quelle: in Anlehnung an Scheer (1992), S.15.
Abb. 3.1:              Verknüpfungsarten

Da einem Ereignis die notwendige Entscheidungskompetenz über den weiteren
Prozessverlauf fehlt, dürfen weder eine disjunktive noch eine adjunktive
Ausgangsverknüpfung einem Ereignis folgen (vgl. Abb. 3.1).54


3.2           Erweiterte Ereignisgesteuerte Prozesskette

Die Ereignisgesteuerte Prozesskette kann durch eine Vielzahl von Symbolen
angereichert werden. Besondere Relevanz besitzen dabei Daten, Organisationseinheiten
und Informationssysteme.55 Durch diese Erweiterungen kann die semantische

54
        Vgl. Rosemann (1996), S. 68.
55
        Vgl. Becker, Schütte (2004), S. 113.
                                                                                                 – 11 –




Aussagekraft von Prozessmodellen wesentlich erhöht werden.56 Werden
Informationsobjekte oder Organisationsobjekte57 innerhalb einer EPK verwendet, so
spricht man von der erweiterten Ereignisgesteuerten Prozesskette (eEPK) (s. Abb. 3.2).

                                                               Legende
                          Startereignis

     Inputdaten
                                           Organisations-          Ereignis       Funktion
                                              einheit

                               F1
                                           Anwendungs
                                                               Organisation-      Prozess-
                                             - system             stelle
     Outputdaten                                                                 schnittstelle


                             XOR

                                                               Organisations-
                                                                                    Daten
                                                                  einheit
                   E1                     E2


                                                               Anwendungs
                                                                 - system

                   F2                     F3                     Kontrollfluss   Konnektoren



                             XOR                                 Datenfluss
                                                                                 XOR


                               E4




                             F4



                             Quelle: in Anlehnung an Rosemann, Schwegmann (2004), S.69.
Abb. 3.2:           Erweiterte Ereignisgesteuerte Prozesskette

Durch die Berücksichtigung der Organisationseinheiten kann die Frage beantwortet
werden, welche Organisationseinheit für die Funktion verantwortlich ist. Sie wird dabei
mit einer ungerichteten Kante mit der Funktion verknüpft.58 Zur Beschreibung des
Beziehungstyps können die Kanten beschriftet werden, z. B. „führt aus“, „ist
verantwortlich für“, „wird informiert über“.



56
     Vgl. Scheer, Jost (1996), S. 35.
57
     Eine detaillierte Liste der Modellobjekte, welche zu Zwecken der Aufbauorganisationsgestaltung
     innerhalb der EPK-Modellierung einsetzbar sind, findet sich in Kugeler (2000), S. 162ff.
58
     Vgl. Scheer, Jost (1996), S. 35.
                                                                                  – 12 –




Daten werden durch einen Pfeil mit Funktionen verbunden und beschreiben je nach
Richtung des Pfeils, welche Daten bei der Funktionsführung benötigt bzw. produziert
werden.59 Werden Funktionen automatisch abgewickelt, wird dies durch die Angabe des
Anwendungssystems deutlich gemacht.60

Über Prozessschnittstellen können vor- oder nachgelagerte Prozesse über ein einziges
Modellobjekt visualisiert werden. Sie bieten die konzeptionelle Möglichkeit, Teile eines
Modells mehrfach zu verwenden und dadurch die Repräsentation eines umfangreichen
Prozesses zu verbessern. 61


3.3       Zusätzliche Verknüpfungsoperatoren


ET-Operator

SCHEER schlug vor, „wenn zwischen den abgeschlossenen und startenden Funktionen
komplexere Beziehungen wie unterschiedliche logische Beziehungen zwischen
Gruppen von Funktionen bestehen, so können einem Ereignis Entscheidungstabellen für
Ein- und Ausgänge hinterlegt werden“62. Für diesen Sachverhalt führte ROSEMANN den
ET-Operator ein. Es handelt sich hierbei nicht um eine semantische Erweiterung des
EPK-Modells, sondern um ein syntaktisches Element, dessen Verwendung zu einer
Reduktion der Schemakomplexität führt. Der ET-Operator erlaubt Situationen
komprimiert zu erfassen und darstellen zu können, in denen verschiedene
Bedingungskonstellationen jeweils unterschiedliche Aktionen zur Folge haben63.




59
      Vgl. Rump (1999), S. 58.
60
      Vgl. Rosemann, Schwegemann (2002), S. 68.
61
      Vgl. Speck (2001), S. 120.
62
      Scheer (2001), S. 127.
63
      Vgl. Rosemann (1996), S. 140ff.
                                                                                                – 13 –




                                                                     R1    R2     R3     R4    ELSE

                                                              B1     J      J      J     N
                                                              B2     J      J      N      J
                            Auslöse-
                            ereignis                          B3     J      N      N     N
                                                              A1     X      X            X
                                                              A2            X      X
                                                              A3                   X
                              ET                              A4                                X



     A1               A2               A3               A4




                                                                     Quelle: Rump (1999), S. 63.
Abb. 3.3:       ET-Operator und Entscheidungstabelle

In Abb. 3.3 ist einem ET-Operator eine Entscheidungstabelle zugeordnet. In den Spalten
der Entscheidungstabelle sind die Regeln formuliert, bei welcher Kombination der
Bedingungen welche Aktionen durchgeführt werden. Diese Regeln sind durch ein
XOR-Verknüpfer verbunden. Der Bedingungsteil enthält die ablaufrelevanten
Bedingungen, die durch ein logisches UND miteinander verknüpft sind. Die Regeln
müssen sich im Bedingungsteil gegenseitig ausschließen. Die in der ELSE-Regel64
gekennzeichneten Aktionen werden ausgeführt, wenn keine andere Regel ausgeführt
werden kann.65


SEQ-Operator

PRIEMER führte den Sequenz-Operator (SEQ-Operator) ein, um sequentielle, aber
wahlfreie Funktionsabfolgen kompakt modellieren zu können. Der SEQ-Operator stellt
eine spezielle XOR-Verknüpfung66 dar (vgl. Abb. 3.4). Er dient zur Verdichtung der
Ablauflogik und der Vermeidung von Redundanzen in Prozessmodellen.67 „Der
Sequenzoperator bringt in diesen Fällen zum Ausdruck, dass die nachfolgenden
Prozessstränge (bis zum nächsten Sequenzoperator) sequentiell, aber in beliebiger
Reihenfolge und jeder genau einmal zu durchlaufen sind.“68 Es ist zu beachten, dass die
Reihenfolge der Funktionen in der sie abgearbeitet werden sollen, zu Beginn der
64
     Das ELSE-Ereignis ist „stellvertretend für alle anderen nicht explizierten Ereignisausprägungen“.
     Rosemann (1996), S. 141.
65
     Vgl. Rump (1999), S. 63; Rosemann (1996), S. 140f.
66
     PRIEMER sieht in als eine spezielle UND-Verknüpfung, vgl. Priemer (1998), S. 270.
67
     Vgl. Becker, Schütte (2004), S. 156.
68
     Rosemann (1996), S. 243.
                                                                                     – 14 –




Abarbeitung festgelegt wird.69 Die Verwendung des SEQ-Operators ist nur nach
Funktionen möglich, da Ereignissen die nötige Entscheidungskompetenz fehlt. Falls
nach jeder Abarbeitung einer Teilsequenz die Reihenfolge neu bestimmt werden kann,
ist in Anlehnung an ROSEMANN ein dynamischer Sequenz-Operator zu verwenden.



                 XOR                                       SEQ




     E1           E2            E3        E1                E2                 E3




     F1           F2            F3        F1                F2                 F3




                                                           SEQ
     E2           E3            E1




     F2           F3            F1




                                               Darstellung des Operators bei
                                                                               d
     E3           E2            E2                      dynamischer
                                                                               SEQ
                                                 Reihenfolgebestimmung:




     F3           F2            F2



                 XOR




                                     Quelle: in Anlehnung an Rosemann (1996), S. 244.
Abb. 3.4:       SEQ-Operator


OR1-Operator

Der OR1-Operator stellt eine spezielle Art des OR-Verknüpfungsoperators dar. Die mit
der Durchlaufwahrscheinlichkeit von „1“ gekennzeichnete Kante, zeigt den Teilprozess
der immer durchlaufen wird. Der andere Teilprozess wird nur optional durchgeführt.70
Der OR1-Operator wird nur nach Funktionen verwendet, da sie die benötige

69
     Vgl. Rump (1999), S. 63.
70
     Vgl. Rump (1999), S. 64.
                                                                                     – 15 –




Entscheidungskompetenz besitzen. Die in Abb. 3.5 rechts dargestellte Form ist eine
äquivalente Darstellung des OR1-Operators mit den üblichen Verknüpfungsoperatoren.



                          1
                                                                XOR




                                                          XOR




                   E1                  E2                  E1           E2




                   F1                  F2                  F1           F2




                   E3                  E4                  E3           E4




                          1




                                                                Quelle: Rump (1999), S.65.
Abb. 3.5:        OR1-Operator


3.4       Modellierungskonventionen der Ereignisgesteuerten Prozesskette


Namenskonventionen

„Unter Namenskonventionen werden die syntaktischen Regeln zur Benennung der
Modellierungskonstrukte der einzelnen Beschreibungssprachen verstanden.“71

Aus drei Gründen werden imperative Aktivbezeichnungen für Funktionsbezeichnungen
empfohlen:72


71
      Becker, Schütte (2004), S. 153.
72
      Vgl. im Folgendem ausführlich Rosemann (1996), S. 205f.
                                                                                  – 16 –




        Der Imperativ hebt den normativen Charakter eines Prozessmodells hervor. Auf
         das Benennen des Ausführenden kann verzichtet werden.

        Die Funktionsbezeichnung kann an den Anfang des Syntagmas gesetzt werden.
         Eine Prozessoptimierung kann durch einfache Identifikation von Redundanzen
         möglich sein, wenn darüber hinaus Namenskonventionen für die Klassifikation
         von Funktionen verwendet werden.

        Die Aktivverwendung erhöht die intuitive Zugänglichkeit zum Modell, da sie
         die vorherrschende Sprachform ist.

Die Ereignisbezeichnung hängt davon ab, ob es sich um ein Bereitstellungsereignis oder
ein Auslöseereignis handelt. „Bereitstellungsereignisse dokumentieren den Abschluss
einer Funktion und werden als solche in der Form „Prozessobjekt + sein + Verb im
Partizip Perfekt“ beschrieben (z.B. „Beleg ist gebucht“). […] Auslöseereignisse werden
in der Form „Prozessobjekt + sein + Verb im zu-Infinitiv“ gebildet (z.B. „Unterkonto ist
einzurichten“).“73


Generelle Layoutkonventionen

Nach dem Grundsatz der Klarheit lassen sich für die Layoutgestaltung vier Richtlinien
zusammenfassen:74

        Die EPK wird entsprechend ihrer Ablauflogik von oben nach unten modelliert,
         so dass das Startereignis oben, die folgenden Informationsobjekte in der
         Reihenfolge ihres zeitlichen Auftretens und abschließend unten das Endereignis
         grafisch angeordnet werden.

        Kanten sollten möglichst waagerecht und senkrecht verlaufen und die
         Kantenüberschneidungen sind zu minimieren, damit die Modelle übersichtlich
         und leicht verständlich bleiben.

        Bei Verknüpfungen sollte der am häufigsten durchlaufende Teilprozess auf der
         linken Seite dargestellt werden, so dass, je weiter rechts ein Teilprozess
         dargestellt, die Häufigkeit des Durchlaufs tendenziell abnimmt.

        Die Datensicht mit den Input- und Outputdaten wird links von der Funktion
         dargestellt, die Anwendungssysteme und die Organisationssicht mit

73
     Rosemann (1996), S. 206.
74
     Vgl. Kugeler (2000), S. 180f.
                                                                                       – 17 –




         Stellentypen, Organisationseinheiten etc. werden rechts von der Funktion
         angeordnet.   Bei    der    Anordnung     der   Stellentypen     sollte der
         Durchführungsverantwortliche über den Mitwirkenden positioniert werden.


Spaltendarstellung

Zur Steigerung der Übersichtlichkeit wurde die eEPK in Spaltendarstellung entwickelt.
Die Symbole werden in spezifische Spalten eingeordnet Hierdurch wird die
Kantenanzahl minimiert, ohne dass das Modell an Semantik verliert. Folgende Spalten
können beispielsweise verwendet werden:75

        Prozessablauf-Spalte:  Hier    werden              Funktionen,   Ereignisse    und
         Verknüpfungsoperatoren aufgeführt.

        Spalten für Input-/Outputobjekte: Die jeweils in die Bearbeitung einer Funktion
         eingehenden bzw. ausgehenden Objekte werden in einer Spalte positioniert.

        Spalten für beteiligte Organisationseinheiten: Diese Spalte differenziert nach der
         Art der Beteiligung (z. B. „führt aus“, „wirkt mit“, „wird informiert“).

Die zu einer Funktion gehörenden Informationsobjekte werden immer auf der gleichen
Höhe im Modell modelliert,76 dabei kann die Anzahl der Spalten und Definitionen
beliebig variiert werden.77 In Abb. 3.6 ist ein Beispiel aufgeführt.




75
     Vgl. Rosemann, Schwegemann (2004), S.69 f.; Speck (2002), S. 130.
76
     Vgl. Speck (2002), S. 130.
77
     Vgl. Rosemann, Schwegemann (2004), S. 70.
                                                                                                                   – 18 –




                                                                                           Organisation
          Prozessablauf                         Input         Output
                                                                              führt aus      wirkt mit    wird informiert


   Produkt-                 Angebot
   planung                 verhandeln




    Leistungs-
                            Angebot ist zu
    umfang ist
                              erstellen
   festzulegen

                     XOR




                  Leistungs-
                 beschreibung                                Leistungs-       Auftrags-
                  erarbeiten                                beschreibung      manager




               Angebot ist zu
                kalkullieren



               Wirtschaftlich-                Leistungs-    Wirtschaftlich-
               keitsrechnung                                                  Controller
                                             beschreibung   keitsrechnung
                durchführen




                     XOR

                            Vertrag zur
                            Anmietung/
                           Ankauf ist ab-
                            zuschließen


                            Anmietung         Leistungs-                      Auftrags-                     Gebäude-
                           und Ankauf                        Mietvertrag                       Jurist
                                             beschreibung                     manager                       verwaltung
                           durchführen

                     XOR




                     XOR


    Leistungs-
                            Angebot ist
    umfang ist
                              erstellt
    festgelegt



    Produkt             Angebot nach-
   einführen             verhandeln




                                                            Quelle: in Anlehnung an Speck (2002), S.131.
Abb. 3.6:              Beispiel einer eEPK in Spaltendarstellung


Hierarchisierung von Prozessen und Eliminierung von Trivialereignissen

Die Hierarchisierung von Prozessen erfolgt in Form von Funktionskonkretisierungen.
Wird eine Funktion hierarchisiert, so ist darauf zu achten, dass das vorangehende bzw.
                                                                                                  – 19 –




nachfolgende Ereignis der zu konkretisierenden Funktion im untergeordneten Modell
als Start- bzw. Endereignis erscheint.78

In einer sequenziellen Folge von Funktionen treten oft Ereignisse auf, die nur die
Auslösung der Funktion bzw. Bereitstellung des Ergebnisses signalisieren. Diese
Ereignisse sind Trivialereignisse und werden als redundant angesehen. Zu Gunsten der
Klarheit wird die streng bipartite Definition der EPK aufgehoben und die
Trivialereignisse können ausgeblendet werden. 79


3.5        Prozessmetamodell

“Ein Meta-Modell stellt eine Typdefinition für eine Klasse von Modellsystemen dar.
Jedes Modellsystem ist eine Instanz eines zugehörigen Meta-Modells.“80

Der konzeptionelle Aspekt Modellierungstechnik eEPK wird zusammenfassend in
Abb. 3.7 mit Hilfe eines Metamodells in ERM-Notation81 veranschaulicht.

Das Prozesselement (PE) ist das zentrale Element des Prozessmodells und stellt die
Generalisierung aller an der Prozesslogik beteiligten Knoten (Prozessereignis,
Operator, Prozessfunktion) des Prozessgraphen dar. Die Prozesselemente können
zueinander in Beziehung stehen, was durch den Relationshiptyp Vorgänger/Nachfolger
beschrieben wird. Jede Prozessfunktion (PF) ist eindeutig einer Funktion zugeordnet. 82
„Das Konstrukt der Funktion wurde eingeführt, um semantisch identische Aktivitäten in
mehreren Prozessen wieder verwenden zu können, ohne prozessspezifische
Abhängigkeiten übernehmen zu müssen“83. Je nach Detaillierungsgrad können
Funktionen selbst wieder als Prozesse identifiziert werden, dies wird durch den
Relationshiptyp Prozess detailliert Funktion dargestellt. Prozesse enthalten wiederum
Prozesselemente (vgl. Prozess enthält Prozesselement), die in Beziehung mit Ressource
und Prozess-Ressource-Beziehungstyp stehen. (vgl. PE-Ressource-Zuordnung).
Ressource beschreibt die möglichen Informationsobjekte bzw. Organisationsobjekte, die
einen Prozess unterstützen können.84 Der Entitytyp Prozess-Ressource-Beziehungstyp
enthält die verschiedenen Beziehungen die in Prozesselement und in Ressource

78
      Vgl. Becker, Schütte (2004), S. 160.
79
      Vgl. Speck (2002), S. 125f.
80
      Sinz (1996), S. 128.
81
      Vgl. dazu Becker, Schütte (2004), S. 87ff.
82
      Vgl. Becker, u. a. (2002), S. 83.
83
      Becker, u. a. (2002), S. 84.
84
      Die Spezialisierung des Entitytyps Ressource ist partiell. Dadurch bietet das Prozessmetamodell der
      eEPK Erweiterungsmöglichkeiten für weitere Informationsobjekte, die beispielsweise zur
      Integration neuer Modellierungstechnik verwendet werden kann, vgl. Becker, u. a. (2003).
                                                                                                                                                   – 20 –




eingehen können, wobei Prozess-Ressource-Beziehungstyp mit sich selbst in Beziehung
steht und eine Hierarchie bildet (vgl. PR-Beziehungstyp-Hierarchie).85

                              PR
                         Beziehungstyp                       Beziehungstypen wie z.B. „führt aus“, „ist Input für“ o.ä.
                           Hierarchie                         Es muss festgelegt werden, welche Kombination aus
                                                                 Beziehungstyp, PE und Ressource erlaubt ist


                             (0,n)           (0,1)

                           Prozess-                                                PE-
                                                     (0,n)                                                  (0,n)                           Organisations-
                          Ressourcen-                                           Ressourcen                                Ressource   D,P
                                                                                                                                               objekt
                         Beziehungstyp                                             ZuO




             Nicht zwei Funktionen / Ereignisse aufeinanderfolgend
                     Nach Ereignissen kein OR oder XOR
                                                                                                                                                Daten
                 Prozesse beginnen und enden mit Ereignissen                                                        Prozessereignis
 Auseinander- und zusammenführende Konnektoren müssen vom selben Typ sein



                          Vorgänger /
                          Nachfolger                                                                                                        Anwendungs-
                                                                                                                                              system
                                                                                                                          Operator

                             (0,n)           (0,n)
                                                     (0,n)

                        Prozesselement
                                                                                            D,T                     Prozessfunktion

                                     (1,1)
                                                                                                                              (1,1)



                            Prozess
                             enthält                                                                                PF referenziert
                          Prozesselem                                                                                 Funktion
                              ent




                                     (1,n)                                                                                    (1,n)

                                                                            Prozess
                                                     (0,1)                                                 (0,1)
                            Prozess                                         detailiert                                    Funktion
                                                                            Funktion




                                                                                Quelle: In Anlehnung an Becker, et al (2002), S. 87
Abb. 3.7:                  Metamodell der Modellierungstechnik der eEPK




85
        Becker, u. a. (2002), S. 84.
                                                                                                                   – 21 –




4               Erweiterungen der Ereignisgesteuerten Prozesskette


4.1             Erweiterung der EPK um das Prozessobjekt

Ausgehend von der zugrunde liegenden Prozessdefinition, besitzt jeder Prozess ein
prägendes Prozessobjekt. Das Prozessobjekt wird in das EPK-Modell integriert und
stellt den Objektstatus des Modells dar, als semantische Relation zwischen Ereignis und
Prozessobjekt. Es ist ein neues Informationsobjekt, das graphisch durch eine gestrichelte
Ellipse neben einem Ereignis dargestellt wird. Die Zuordnung zum Ereignis erfolgt nach
Definition des Ereignisses, als eine Ausprägung des Zustandes eines
Informationsobjekts. Im Modell wird das Prozessobjekt nur an den Stellen aufgeführt,
an denen das Prozessobjekt zum ersten Mal auftritt oder an denen es detailliert wird. 86

ROSEMANN macht innerhalb eines Prozesses kenntlich, wo sich Generalisierungen 87 des
Prozessobjektes wieder finden. Hieraus wird das Prozessobjektmodell erzeugt, das
zusätzlich zur Generalisierung der Prozessobjekte Kompositionen88 und
Migrationsbeziehungen89 aufweisen kann (vgl. Abb. 4.1).
                                                 Migrations-
                                                 beziehung     Zahlung
                                  Rechnung
                                             G




                                    D, T
                                             Generalisierung



                Inländische                  Ausländische
                 Rechnung                     Rechnung
                              K




                        Komposition



     Orginal-                 Rechnungs-
     rechung                    kopie



                                                                         Quelle: in Anlehnung an Rosemann (1996), S.79f.
Abb. 4.1:                     Beispiel eines Prozessobjektmodell




86
         Vgl. Rosemann (1996), S. 76.
87
         Gekennzeichnet durch ein „G“ an der Ellipse., vgl. Rosemann (1996), S. 77.
88
         Wird durch ein „K“ an der Ellipse gekennzeichnet, vgl. Rosemann (1996), S. 78.
89
         Migrationsbeziehungen existieren, wenn Abfolgen von Prozessobjekten entlang eines Prozesses
         bestehen. Beispielsweise hat das Prozessobjekt Rechnung eine Zahlung zur folge, vgl. Rosemann
         (1996), S. 78f.
                                                                                – 22 –




4.2       Verbindung objektorientierter Modellierung mit EPKs

Die Geschäftsprozessmodellierung und die objektorientierte Modellierung verfolgen
unterschiedliche Paradigmen, es gibt jedoch Versuche, sie miteinander zu
kombinieren.90

SCHEER, NÜTTGENS und ZIMMERMANN entwickelten die objektorientierte
Ereignisgesteuerte Prozesskette (oEPK), die prozessorientierte Ereignissteuerung mit
Elementen der objektorientierten Modellierung verbindet.91 Die Darstellungsform ist
eine Kombination aus ERM, statischem Klassenmodell und eEPK. Ziel ist es eine
gleichzeitige Darstellung von EPK und Interaktion zwischen Geschäftsobjekten zu
erreichen. Funktionen werden durch Geschäftobjektklassen ersetzt, in denen die
betrieblichen Funktionen gekapselt sind, und über Ereignisse miteinander verbunden
werden.92

Geschäftsobjekte sind die für die Leistungserstellung einer Unternehmung relevante,
diskrete, unterscheidbare Entitäten und stellen in ihrer Struktur eine Komposition von
Daten, Funktionen und Schnittstellen verschiedener Objektklassen dar. Beispiele für
Geschäftsobjekte sind Aufträge, Produkte und Lieferscheine. Diese komplexen Objekte
werden durch mehrere komponierte Objektklassen repräsentiert z. B. das
Geschäftsobjekt ‚Auftrag’ wird durch die Klassen Auftragskopf und Auftragsposition
repräsentiert. Die graphische Darstellung der Objektklasse erfolgt durch ein Rechteck
mit Kopfteil. Die Instanzvariablen werden links und die Methoden rechts vom
Geschäftsobjekt eingetragen, dadurch wird die zusammengefasste Daten- und
Funktionssicht des Objektes verdeutlicht. Damit der Leistungsfluss über verschiedene
Organisationsbereiche abgebildet werden kann, werden Organisationseinheiten und
Ressourcen in Anlehnung an die eEPK modelliert.93 Abb. 4.2 stellt diesen Sachverhalt
dar.




90
      Vgl. Scheer (2001), S. 133.
91
      Vgl. Scheer (2001), S. 136.
92
      Vgl. Scheer, Nüttgens, Zimmermann (1997), S. 16ff.
93
      Vgl. Scheer, Nüttgens, Zimmermann (1997), S. 29-35.
                                                                                       – 23 –




                             Ereignisklasse
                                  A1

     Instanzvariable
           B1                                  Organisations-
                                                 einheit O1
     Instanzvariable         Objektklasse
           B2                     B
                                                Methode B1
     Instanzvariable
           B3                                   Methode B2


                             Ereignisklasse
                                  B1


                                  Quelle: in Anlehnung an Nüttgens, Zimmermann (1998), S.35.
Abb. 4.2:              Grundmodell einer oEPK


4.3          Erweiterungen der eEPK im eGovernment

Unter Electronic Government (eGovernment) wird die Modernisierung der öffentlichen
Verwaltung verstanden mittels Nutzung von elektronischer Informations- und
Kommunikationstechnik.94

Der Hauptzweck der Prozessmodellierung von öffentlichen Verwaltungen ist die
Organisationsgestaltung, insbesondere die prozessorientierte Reorganisation von
Verwaltungsprozessen. Die EPK-Methode ermöglicht dabei eine ganzheitliche und
integrierte Sicht der Betriebssituation und weist trotz der Einfachheit und Klarheit der
Darstellung einen entsprechenden Formalisierungsgrad auf, welcher eine anschließende
Anwendungssystemgestaltung zulässt.95

Um die Bilateralität zwischen Kunde und Verwaltung und die Dezentralität des
Verwaltungshandelns hinreichend abzubilden, wurde die EPK um folgende Konstrukte
erweitert:96

          Spaltendarstellung (vgl. dazu Kap. 3.7) und

          Interaktionspunkte

Die Spalteneinteilung orientiert sich dabei an Organisationseinheiten respektive
Fachdiensten. Diesen Einheiten können eindeutig auf Prozessebene Wissensressourcen
(Dokumente),     Mitarbeiterressourcen   (Stellen)    und    Technologieressourcen

94
       Vgl. o. V. (2004).
95
       Vgl. Becker, Algermissen, Niehaves (2003), S. 32ff.
96
       Vgl. Becker, Algermissen, Niehaves (2003), S. 41f.
                                                                                                                                   – 24 –




(Anwendungssysteme) zugewiesen werden. Die Interaktionspunkte verbinden die
externe Perspektive der Kunden mit der internen Perspektive der Verwaltung.97
             Externe                                                       Interne Perspektive:
        Perspektive Bürger                                                      Verwaltung
         & Unternehmen



                                                      Antrag ist auf                                         FD63        FD63
                                                      Vollständigkeit
                                                        zu prüfen



                                                       Vollständig-
                                                                                                           Ingenieur
                                                       keitsprüfung




                                                           XOR




                                    Unterlagen sind                     Unterlagen sind
                                     unvollständig                        vollständig




                                     Eingangsbe-                                             Benach-
                                                        Eingangs-
                                     stätigung mit                                          richtigung
                                                       bestätigung                                         Ingenieur
                                     Nachforderun                                          Stadtwerke
                                                         erstellen
                                      g erstellen                                            erstellen


                                                                                                             Gekos




                                      Eingangs-                                              Benach-
                                                        Eingangs-
               Interaktion:         bestätigungmit                                          richtigung
                                                       bestätigung                                         Vorzimmer
                                    Nachforderun                                           Stadtwerke
             Erfolgt bspw.                             versenden
                                     g versenden                                           versenden
        über den Postweg,
              E-Mail oder
           ein Web-Portal




         Eingangs-                    Eingangs-                                              Benach-
                                                        Eingangs-
       bestätigungmit               bestätigungmit                                          richtigung
       Nachforderung          <i>   Nachforderung
                                                      bestätigung ist
                                                                                          Stadtwerke ist
                                                        versendet
        eingegangen                   versendet                                             versendet



           Nachzu-
          reichende
         Unterlagen
        identifizieren                                                                                                 Prüfbogen
                                                                          Prüfboden
                                                                           erstellen
          Nachzu-
         reichende                                                                                                     Ingenieur
        Unterlagen
        zusammen-
           stellen                                                       Prüfbogen ist
                                                                            erstellt
                                                                                                                        Gekos

         Unterlagen
         versenden
                                                                          Internen
                                                                           Umlauf
                                                                         durchführen


                                    Nachgeforderte
       Unterlagen sind
         versendet            <i>   Unterlagen sind
                                     eingetroffen




                                    Unterlagen mit
                                      Bauantrag
                                     zusammen-
                                       führen



                               Quelle: in Anlehnung an Becker, Algermissen, Niehaves (2003), S.41.
Abb. 4.3:                Beispiel einer Erweiterung der eEPK im eGovernment

97
     Vgl. Becker, Algermissen, Niehaves (2003), S. 42.
                                                                                 – 25 –




5         Fazit und Ausblick

Mit der EPK wurde eine anschauliche Methode für die Modellierung von Prozessen
vorgestellt. Sie setzt für den Nutzer kein tiefes modelltechnisches Wissen voraus. Es
wurde vorgestellt, dass sich diese Methode flexibel anpassen und erweitern lässt.

Die Methode der EPK kann in komplexen Entscheidungssituationen durch die
Ergänzung syntaktischer Elemente, wie der Entscheidungstabelle, die Komplexität von
Modelle reduzieren. Komplexe Sachverhalte können durch die Erweiterung von
zusätzlichen Verknüpfungsoperatoren, z. B. des SEQ-Operators, weiter vereinfacht
werden. Es ist gezeigt worden, dass sich objektorientierte Modellierungsansätze mit der
EPK verknüpfen lassen. Eine gleichzeitige Darstellung der EPK und einer Interaktion
von Geschäftsobjekten, ist durch das Ersetzen von Funktionen durch
Geschäftsobjektklassen möglich.

Die EPK hat sich in der Praxis als Modellierungstechnik für betriebliche Abläufe
etabliert. Sie bietet die Möglichkeit Prozesse im Unternehmen allgemein verständlich zu
beschreiben. Wie am Beispiel des eGovernment gezeigt wurde, lässt sich die EPK
erweitern, um branchenspezifische Anforderungen zu erfüllen

In der Forschung gibt es vielseitige Erweiterungsansätze, beispielsweise die
Einbeziehung   der   Fuzzy-Logik,    um    unscharfe     Daten     bei   der
Geschäftsprozessmodellierung mit der EPK abzubilden. Die EPK muss auch kritisch
hinterfragt werden. Ontologische Evaluierungen98 der EPK haben gezeigt, dass die
Konstrukte der EPK ontologisch unklar und mehrdeutig interpretierbar sind. Es ist
somit genau zu überlegen, welche Anpassungen und Erweiterungen der EPK
vorzunehmen sind, um sie in konkreten Problemstellungen einsetzten zu können.




98
     Vgl. dazu Fettke, Loos (2003).
                                                                                   – 26 –




Literaturverzeichnis

Becker, J. u. a.: Methodische und technische Integration von Daten- und
         Prozessmodellierungstechniken für Zwecke der Informationsanalyse. In:
         Arbeitsberichte des Instituts für Wirtschaftsinformatik. Arbeitsbericht Nr. 103.
         Hrsg.: J. Becker u. a.. Münster 2003.
Becker, J. u. a.: Konfigurative Referenzmodellierung. In: Wissensmanagement mit
         Referenzmodellen. Hrsg.: J. Becker, : Becker, R. Knackstedt. Heidelberg,
         2002, S. 25-140.
Becker, J.; Algermissen, L.; Niehaves, B.: Prozessmodellierung in eGovernment-
         Projekten mit der eEPK. In: EPK 2003. Geschäftsprozessmanagement mit
         Ereignisgesteuerten Prozessketten. Hrsg.: M. Nüttgens, F. Rump. Bamberg
         2003. S. 31-43.
Becker, J.; Kahn, D.: Der Prozess im Fokus. In: Prozessmanagement. Ein Leitfaden zur
         prozessorientierten Organisationsgestaltung. Hrsg.: J. Becker, M. Kugeler,
         M. Rosemann. 3. Aufl., Berlin et al. 2002. S. 17-46.
Becker, J.; Schütte, R.: Handelsinformationssysteme. 2. Aufl., Frankfurt/Main 2004.
Becker, J.; Vossen, G.: Geschäftsprozessmodellierung und Workflow-Management:
         Eine Einführung. In: Geschäftsprozessmodellierung und Workflow-
         Management. Hrsg.: B. Mahr, A. Schill, G. Vossen. 1. Aufl., Bonn 1996, S. 17-
         26.
Eiff, W. von: Organisation – Unternehmerische Gestaltungsaufgaben im
         gesellschaftlichen und marktwirtschaftlichen Spannungsfeldern. In:
         Organisation – Erfolgsfaktoren der Unternehmensführung. Hrsg.: W. von Eiff.
         1. Aufl., Landsberg/Lech, S. 19-78.
Esswein, W.: Das Rollenmodell der Organisation. In: Wirtschaftsinformatik, 35, 1993,
         6, S. 551-561.
Ferstl, O. K.; Sinz, E. J.: Grundlagen der Wirtschaftsinformatik. Band 1. 2. Aufl.,
         München, Wien 1994.
Fettke, P.; Loos, P.: Ontologische Evaluierung von Ereignisgesteuerten Prozessketten.
         In: EPK 2003. Geschäftsprozessmanagement mit Ereignisgesteuerten
         Prozessketten. Hrsg: M. Nüttgens, F. Rump. Bamberg 2003. S. 61-78.
Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozeßmodellierung auf der
         Grundlage „Ereignisgesteuerter Prozeßketten“. In: Veröffentlichungen des
         Instituts für Wirtschaftsinformatik. Heft 89. Hrsg.: A.-W. Scheer. Saarbrücken
         1992.
Kruse, C.; Scheer, A.-W.: Modellierung und Analyse dynamischen Systemverhaltens.
         In: Veröffentlichungen des Instituts für Wirtschaftsinformatik. Heft 89. Hrsg.:
         A.-W- Scheer. Saarbrücken 1992.
Kugeler, M.: Informationsmodellbasierte Organisationsgestaltung.
         Modellierungskonventionen und Referenzvorgehensmodell zur
         prozessorientierten Reorganisation. Dissertation, Universität Münster, Berlin
         2000.
                                                                                  – 27 –




Lehmann, H.: Aufbauorganisation. In: Handwörterbuch der Betriebswirtschaftslehre.
         Hrsg.: E. Grochla, W. Wittmann. 4. Aufl., Stuttgart 1974, Sp. 290-298.
Martin, J.; Odell, J. J.: Object-oriented Analysis and Design. Englewood Cliffs, New
         Jersey 1992.
o. V.: Politik-digital 3.0. 2004. http://www.politik-digital.de/egovernment/index.shtml.
         Abrufdatum 2004-04-10.
o. V.: Prozeß. In: Informatik.Ein Sachlexikon für Studium und Praxis. Hrsg.: H.
         Engesser. 2. Aufl., Mannheim u. a. 1993. S. 559.
Priemer, J.: Entscheidung über die Einsetzbarkeit von Software anhand formaler
         Modelle. Dissertation, Universität Münster, Sinzheim 1998.
Reisig, W.: Petri-Netze. 2. Aufl., Berlin u. a. 1986.
Rosemann, M.; Schwegmann, A.: Vorbereitung der Prozessmodellierung. In:
         Prozessmanagement. Ein Leitfaden zur prozessorientierten
         Organisationsgestaltung. Hrsg.: J. Becker, M. Kugeler, M. Rosemann. 3. Aufl.,
         Berlin et al. 2002. S. 47-94.
Rosenmann, M.: Komplexitätsmanagement in Prozessmodellen. Wiesbaden 1996.
Rosenstengel, B.; Winand, U.: Petri-Netze – Eine anwendungsorientierte Einführung.
         4. Aufl., Braunschweig-Wiesbaden 1991.
Rozenberg, G. (Ed.): Advances in Petri Nets 1989. Heidelberg et al. 1989 (Lectures
         Notes in Computer, 424).
Rump, F.: Durchgängiges Management von Geschäftsprozessen auf Basis
         ereignisgesteuerter Prozessketten. Dissertation, Universität Oldenburg,
         Oldenburg 1998.
Scheer, A.-W.: ARIS. Modellierungsmethoden, Metamodelle, Anwendungen. 4. Aufl.,
         Berlin et al. 2001.
Scheer, A.-W.: Wirtschaftsinformatik. Referenzmodelle für industrielle
         Geschäftsprozesse. 7. Aufl., Berlin et al. 1997.
Scheer, A.-W.; Jost, W.: Geschäftsprozessmodellierung innerhalb einer
         Unternehmensarchitektur. In: Geschäftsprozessmodellierung und Workflow-
         Management. Hrsg.: B. Mahr, A. Schill, G. Vossen. 1. Aufl., Bonn 1996, S. 29-
         46.
Scheer, A.-W.; Nüttgens, M.; Zimmermann, V.: Objektorientierte Ereignisgesteuerte
         Prozesskette (oEPK) – Methode und Anwendung. In: Veröffentlichung des
         Institutes für Wirtschaftsinformatik. Heft 141. Hrsg.: A.-W. Scheer. Saar-
         brücken 1997.
Scherr, A. L.: A new approach to business processes. IBM Systems Jounal, 32 (1991) 1,
         S. 80-98.
Schütte, R.: Grundsätze ordnungsgemäßiger Referenzmodellierung, Konstruktions- und
         anpassungsorientierter Modelle. Wiesbaden 1998.
Schütte, R.: Grundsätze ordnungsmäßiger Referenzmodellierung. Konstruktion
         konfigurations- und anpassungsorientierter Modelle. Dissertation, Universität
         Münster, Wiesbaden 1998.
                                                                                  – 28 –




Schwegmann, A.; Schlagheck, B.: Integration der Prozeßorientierung in das
         objektorientierte Paradigma: Klassenzuordnungsansatz vs.
         Prozeßklassenansatz. In: Arbeitsberichte des Instituts für
         Wirtschaftsinformatik. Arbeitsbericht Nr. 60. Hrsg.: J. Becker u. a. . Münster
         1997.
Schweitzer, M.: Ablauforganisation. In: Handwörterbuch der Betriebswirtschaftslehre.
         Hrsg.: E. Grochla, W. Wittmann.4. Aufl., Stuttgart 1974, Sp. 1-8.
Sinz, E. J.: Ansätze zur fachlichen Modellierung betrieblicher Informationssysteme.
         Entwicklung, aktueller Stand und Trends. In: Information Engineering. Hrsg.:
         H. Heilmann, H. J. Heinrich, F. Roithmayr. Oldenbourg. München 1996,
         S. 123-143.
Speck, M. C.: Geschäftsorientierte Datenmodellierung. Ein Referenz-Vorgehensmodell
         zur fachkonzeptionellen Modellierung von Informationsstrukturen.
         Dissertation, Universität Münster, Berlin 2001.
                                                                                – 29 –




Abschließende Erklärung



Ich versichere hiermit, dass ich meine Ausarbeitung Prozessmodellierung mit der
Ereignisgesteuerten Prozesskette selbstständig und ohne fremde Hilfe angefertigt habe,
und dass ich alle von anderen Autoren wörtlich übernommenen Stellen wie auch die
sich an die Gedankengänge anderer Autoren eng anlegenden Ausführungen meiner
Arbeit besonders gekennzeichnet und die Quellen zitiert habe.

Münster, den 14. April 2004

...(Unterschrift)...

								
To top