In Abschnitt 2.3 wurden die Elemente von Geschäftsprozessen genannt, die [Scheer 1997] bei der Herleitung des ARIS-Konzepts identifiziert. Diese fasst er bei der konkreten Ausformulierung des EPK-Ansatzes zu Folgenden zusammen:

• Funktionen
• Ereignisse
• Organisationseinheiten und
• Informationsobjekte

Außerdem werden der Kontrollfluss  und – eingeschränkt – der Datenfluss berücksichtigt.

2.1 Funktionen

Mit Funktionen werden die im Geschäftsprozess zu leistenden Tätigkeiten erfasst. Welchen Umfang an Tätigkeiten die einzelne ausgewiesene Funktion umfasst, bleibt dem Modellierer überlassen. Der in Kapitel 2 diesbezüglich diskutierte subjektive Faktor der Modellierung bleibt also erhalten.

Was wird geleistet?

Funktionen beschreiben also, was gemacht werden soll. Alle Tätigkeiten, die in einem Geschäftsprozesse zu leisten sind, werden in einzelne Teilaufgaben unterteilt. Sie erfassen bei Mitarbeitern deren operative Tätigkeit, bei einem Informationssystem so etwas wie eine Transaktion bzw. einen betriebswirtschaftlichen Funktionsbaustein [Schulungsunterlagen Analyzer, S. 2-5].

Etwas genauer wird dieser Begriff durch die Festlegung gefasst, dass eine Funktion z.B. einen betriebswirtschaftlichen Vorgang kennzeichnen kann, den Scheer wie folgt definiert:

Vorgang

„Ein Vorgang ist ein zeitverbrauchendes Geschehen, das durch ein Start­ereignis ausgelöst und durch ein Endereignis abgeschlossen wird. Einem Vorgang können in Abhängigkeit von Vorgangsergebnissen unterschiedliche Ablaufverzweigungen, auch Rücksprünge, folgen.“ [Scheer 1998, S. 20]

Bullinger und Fähnrich definieren einen Vorgang als Abfolge von Tätigkeiten, die zur Realisierung von Aufgaben ausgeführt werden. Sie weisen auf die zu berücksichtigenden organisatorischen Dimensionen hin und auf vier Kategorien, mit deren Hilfe sich Vorgänge beschreiben lassen [Bullinger und Fähnrich 1997, S. 19]:

• Ereignisflüsse steuern die Aktivierung von Aufgaben in Abhängigkeit von auftretenden Ereignissen.
• Daten- bzw. Objektflüsse modellieren Eingangsinformationen oder -objekte, die zur Aufgabenausführung benötigt werden. Weiterhin modellieren sie die Verwendung der Resultate in nachfolgenden Aufgaben. Dabei ist der Begriff eines Objekts als materielles oder auch immaterielles Objekt weit gefasst.
• Aufgabenträger repräsentieren Stellen einer Organisation und bearbeiten Aufgaben.
• Ressourcen sind Materialien, Betriebsmittel oder Aufgabenträger, die zur Aufgabenausführung benötigt werden.

Diese umfassende Beschreibung muss nur noch dahingehend ergänzt werden, dass Vorgänge in anderen Vorgängen bzw. in Geschäftsprozessen enthalten sein können.

Funktionen können somit zerlegt bzw. aggregiert werden. Der Zerlegungsprozess sollte allerdings da enden, wo Funktionen erreicht werden, die in einem Arbeitsablauf bearbeitet werden, die also betriebswirtschaftlich nicht mehr sinnvoll zerlegt werden können. Doch kommt es durchaus vor, dass man Beschreibungen von Geschäftsprozessen sieht, bei denen die Zerlegung fast bis zur tayloristischen Ebene vorangetrieben wurde.

Aggregation von Funktionen

Diese Techniken der Einteilung von Vorgängen haben Vorläufer, wie z.B. die Rasterdiagramme (auch Ereignisfolgendiagramme), die für die Darstellung der Vorgangsbearbeitung eingesetzt wurden (vgl. für eine Kurzdarstellung [Stahlknecht 1995, S. 266]). Die Abgrenzung erfolgt hier durch Arbeitsschritte bzw. Tätigkeiten im Rahmen des Vorgangs.

Vorläufer

So verstandene Funktionen verbrauchen Ressourcen und natürlich auch Zeit. Deshalb sind die Ressourcen (vgl. unten) immer mit Funktionen verknüpft.

Der Zeitverbrauch für die Funktionen wird in diesem Modellierungsansatz nicht quantifiziert. Es wird also nicht angegeben, wie viel Zeit (höchstens/mindestens) benötigt wird, um die in der Funktion erfassten Tätigkeiten durchzuführen.

Zeitverbrauch

Die grafische Darstellung von Funktionen in Ereignisgesteuerten Prozessketten ist in der folgenden Abbildung angegeben.

2.2 Ereignisse

Unter Ereignissen werden hier betriebswirtschaftlich relevante Ereignisse verstanden. Diese Ereignisse beeinflussen und steuern auf die eine oder andere Weise die Abläufe im Unternehmen. Einige Beispiele dafür sind:

• Auftrag ist eingetroffen
• Angebot ist gültig
• Auftragsbestätigung ist übermittelt
• Überweisung ist vorbereitet
• Kundenanfrage ist abgelehnt
• Kunde ist neu (als Ergebnis einer entsprechenden Prüfung)

Zur Definition von Ereignissen können wir (glücklicherweise, es wäre sonst nicht einfach!) auf den umgangssprachlichen Ereignisbegriff zurückgreifen, allerdings mit der Ergänzung, dass es sich um betriebswirtschaftlich relevante Ereignisse handeln muss, die für den betrachteten Geschäftsprozess Bedeutung haben.

Steuerung durch Ereignisse

Etwas enger gefasst wird diese Definition dadurch, dass in diesem Ansatz eine enge Beziehung zwischen Funktionen und Ereignissen gesehen wird. Die Durchführung einer Funktion führt zum Beispiel immer zu einem Ereignis („erledigt“) oder zu mehreren. Ähnlich Österle, wenn er definiert:

„Ein Ereignis ist der Auslöser oder das Ergebnis eines Ablaufs“ [Österle 1995, S. 51]

Etwas konkreter können Ereignisse so gesehen werden, dass sie die Ergebnisse oder die Bedingungen für die Ausführung von Funktionen beschreiben.

Ereignisse sind auf einen bestimmten Zeitpunkt bezogen. Dieser wird allerdings in der Regel nicht spezifiziert. Er wird in den gängigen Darstellungen nur dadurch festgelegt, dass ein Ereignis in eine Kette von Handlungen (Funktionen) und Ereignissen (ein Zweig des Kontrollflusses) eingebettet wird. Mit anderen Worten: Ereignisse lösen Funktionen aus und sind deren Ergebnis. Dies ist der Grund, weshalb Scheer schreibt:

„Ein Ereignis kann als Auftreten eines Objekts oder Änderung einer bestimmten Attributsausprägung definiert werden.“ [Scheer 1998, S. 49]

Wobei er hier mit Objekten z.B. Produkte meint.

In den Schulungsunterlagen von SAP wird ein Ereignis als ein „betriebswirtschaftlich relevanter Zustand“ beschrieben, der „zum Zeitpunkt seines Eingetretenseins eine oder mehrere Funktionen auslösen kann“ [Schulungsunterlagen Analyzer, S. 2-8].

Ereignisse in diesem Sinn können sich aus vorangegangenen Tätigkeiten sozusagen als Beschreibung der möglichen Ergebnisse ergeben, sie können aber auch auf die nächsten Arbeitsschritte verweisen oder – quasi aus heiterem Himmel – von außen kommen (wie das erste Beispiel am Beginn dieses Abschnitts).

Die Menge aller in einem Unternehmen und seinem Umfeld möglichen Ereignisse sollen als der Ereignisraum des Unternehmens bezeichnet werden.

Ereignisraum

Ein Ereignis ist immer auch eine Feststellung, die irgendwie und von irgendjemandem getroffen werden muss. Ihm gehen Handlungen voraus und meistens folgen auch welche nach. Diese werden hier mit dem oben schon eingeführten Begriff der Funktionen erfasst.

Ereignisse können, wie Funktionen, zusammengefasst oder auch zerlegt werden. Nehmen wir das bewusst „hoch“ angesiedelte Ereignis „Unternehmen hat keine Gewinne erwirtschaftet.“ Dies könnte genausogut durch die „Ereignisse“ „Absatz ging um x% zurück“, „Kosten lagen bei y DM“, usw. beschrieben werden. Grundsätzlich müssen sich die Ereignisse diesbezüglich an den Funktionen (an deren Aggregationsniveau) orientieren.

Zwei Ereignisse eines jeden Geschäftsprozesses verdienen hervorgeho­ben zu werden: das Startereignis und das Endereignis (oder Schlussereignis). Mit dem Startereignis beginnt ein Geschäftsprozess (davor liegen, bezogen auf den einzelnen Geschäftsprozess, keine Handlungen), mit dem Endereignis findet er seinen Abschluss.

Anfang und Ende

Die grafische Darstellung von Ereignissen in Ereignisgesteuerten Prozessketten ist in der folgenden Abbildung angegeben.

2.3 Organisationseinheiten

Mithilfe der Organisationseinheiten wird festgehalten, wo die in einer Funktion erfasste Aufgabe getätigt wird. Die Organisationseinheiten werden also den Funktionen zugeordnet.

Wer erfüllt die Aufgabe?

Sehr oft wird man heute, v.a. wenn der Personalbestand schon sehr niedrig ist und/oder sich das Unternehmen von der klassischen Aufbauorganisation wegbewegt, die Organisationseinheiten sehr klein fassen, evtl. sogar auf Stellenebene gehen, um genügend Aussagekraft für die Analyse der Schwachstellen zu erhalten.

Beispiele für (klassische) Organisationseinheiten in einem Industrieunternehmen sind Vertrieb, Personalwesen, Werk, Informationsvermittlungsstelle.

Die Verbindung von Funktion und Organisationseinheit ist richtungslos und bedeutet, dass die Funktion durch Mitarbeiter der angegebenen Organisationseinheit erledigt wird. Natürlich können einer Funktion auch mehrere Organisationseinheiten zugeordnet werden (vgl. dazu die Beispiele in den Kapiteln 5 und 6).

Die grafische Darstellung von Organisationseinheiten in Ereignisgesteuerten Prozessketten ist in der folgenden Abbildung angegeben.

Ihre Anbindung an die Funktionen zeigt die folgende Abbildung am Beispiel einer Abteilung Produktion, die für die Funktion Prüfung der Fertigungskapazität verantwortlich ist.

2.4 Informationsobjekte

Kein Unternehmen kommt heute ohne Datenbestände aus, die das Unternehmen selbst, seine Geschäftsobjekte und seine informationelle Umwelt ganz oder in Ausschnitten modellieren. Diese Datenbestände sind damit auch für die Abwicklung der Geschäftsprozesse von großer Bedeutung.

Welche Informationen werden bei einer Funktion gebraucht?

In Ereignisgesteuerten Prozessketten schlägt sich dies so nieder, dass bei den Funktionen die jeweils benötigten oder entstehenden Informationen angegeben werden. Dies können Kundendaten, die Angaben des früher erstellten Angebots, aktuelle Marktpreise oder eine andere Information sein, die für irgendeinen Abschnitt des Geschäftsprozesses Bedeutung besitzt.

In diesem Ansatz werden solche Daten als Informationsobjekte bezeichnet und in Verbindung gesetzt mit der Funktion, für die sie benötigt werden. Dann werden z.B. einer Funktion Auftragsbearbeitung Informationen zugeordnet

Informationsobjekte zur Unterstützung der Geschäftsprozesse

• zu Kunden,
• zum Angebot,
• zu den Materialien,
• zu den Konditionen,
• zum Kundenauftrag und zum
• Bedarf.

Die Beziehung zwischen Informationsobjekten und Funktionen hat eine Richtung. Funktionen benötigen Informationen aus Informationsobjekten, erzeugen aber auch welche, die dann zu den Informationsobjekten dazukommen.

Die grafische Darstellung von Informationsobjekten in Ereignisgesteuerten Prozessketten ist in der folgenden Abbildung angegeben.

Die Verknüpfung mit den Funktionen geschieht durch Pfeillinien. Die Pfeillinie ist wie die zugrunde liegende Beziehung gerichtet und spiegelt den Informationsfluss wider. Fließen Informationen aus dem Informationsobjekt in die Tätigkeit ein, liegt die Pfeilspitze an der Funktion. Entstehen aus der Funktion heraus Informationen, die in das Informationsobjekt einfließen, liegt die Pfeilspitze am Informationsobjekt an.

Im folgenden Beispiel fließen Informationen aus einer Datei Produk­tionsplanung in die Funktion Prüfung Fertigungskapazität ein.

Wie im Folgenden zu sehen ist, werden damit Datenflüsse (im Sinne der Datenflussdiagramme) nur erfasst, wenn dieser Teil der Modellierung sehr sorgfältig geschieht, was in der Praxis meist nicht der Fall ist.

Pfeil = Informationsfluss

Informationsobjekte können nicht nur aus Daten von Datenbanken bestehen. Grundsätzlich kann jede Information auf jedem Informationsträger berücksichtigt werden. Der Hinweis auf nicht elektronische Träger kann sogar ein erster Hinweis auf Möglichkeiten zur Optimierung des Geschäftsprozesses sein.

Informationsträger aller Art

Grundsätzlich geben die Informationsobjekte auch Hinweise auf den Automatisierungsgrad des betrachteten Geschäftsprozesses. In nicht oder nur teilweise automatisierten Abschnitten werden die Informationsobjekte in der Regel (aber nicht immer!) nicht digital sein.

Informationsobjekte und Automatisierungsgrad

2.5 Operatoren und Kontrollfluss

In Geschäftsprozessen müssen oft mehrere Tätigkeiten „parallel“ erledigt werden, um ein Ziel zu erreichen. Oder es gibt Alternativen: Entweder die eine oder die andere Tätigkeit führt zum Ziel. Genauso mit Ereignissen. Manchmal können alternative Ereignisse dieselbe Tätigkeit auslösen oder mehrere Ereignisse zusammen die Bedingung sein für den Beginn einer Tätigkeit.

Operatoren

Dieses Strukturmerkmal stellt jeweils Tätigkeiten oder Ereignisse in eine Beziehung miteinander. In Ereignisgesteuerten Prozessketten also Funktionen bzw. Ereignisse.

Funktionen miteinander in Beziehung setzen.

In Ereignisgesteuerten Prozessketten wird dieses „In-Beziehung-setzen“ durch drei Operatoren modelliert, wie sie in formalen Sprachen üblich sind: das exklusive ODER (auch XODER), das ODER und das UND (für eine Erläuterung vgl. unten).

In der grafischen Darstellung erfolgt die Darstellung der Operatoren üblicherweise nicht textlich, sondern mithilfe grafischer Symbole:

• UND:
• ODER:
• exklusives ODER (auch XODER):

Für Ereignisse, es müssen mindestens zwei sein, sonst gibt es keinen Operator, haben sie folgende Bedeutung:

• UND: alle Ereignisse müssen eintreten, erst dann geht es weiter im Kontrollfluss
• ODER: mindestens eines der Ereignisse muss eintreten, erst dann geht es im Kontrollfluss weiter
• XODER: genau eines der Ereignisse muss eintreten, erst dann geht es im Kontrollfluss weiter

Für Funktionen, auch hier müssen es mindestens zwei sein, haben sie folgende Bedeutung:

• UND: alle Funktionen müssen getätigt werden, erst dann geht es im Kon­trollfluss weiter
• ODER: mindestens eine der Funktionen muss getätigt werden, erst dann geht es im Kontrollfluss weiter
• XODER: genau eine der Funktionen muss getätigt werden, erst dann geht es im Kontrollfluss weiter

Eine genauere Bestimmung der Bedeutung der Operatoren hängt von der Stellung im Kontrollfluss ab. Davon, ob z.B. die verknüpften Ereignisse vor oder nach einer Funktion stehen. Vgl. hierzu die Verknüpfungsbeispiele unten. Zwei diesbezüglich wichtige Begriffe sollen aber schon hier eingeführt werden.

Hinweis

Die Operatoren können nur Ereignisse mit Ereignissen und Funktionen mit Funktionen verknüpfen, nicht Ereignisse mit Funktionen.

In den grafischen Darstellungen geht man bei Ereignisgesteuerten Prozessketten von der Festlegung aus, dass der Kontrollfluss der Übersichtlichkeit halber von oben nach unten angeordnet wird. Deshalb werden die Operatoren in der grafischen Notation in einem zweigeteilten Kreis platziert, z.B. so wie in der folgenden Abbildung (vgl. auch die folgenden Beispiele).

Die obere Hälfte gibt an, wie die durch die „ankommenden“ Kontrollflüsse repräsentierten Ereignisse oder Funktionen verknüpft sind. Die untere Hälfte leistet dasselbe für die ausgehenden Pfeile. Natürlich werden nur für diejenige Hälfte Operatoren benötigt, die mehr als ein zu verknüpfendes Element (Ereignis oder Funktion) aufweist. Kommt nur ein Pfeil an oder geht nur einer weg, wird auch kein Operator angegeben.

Zwei zusätzliche Begriffe sollen bezüglich der Operatoren noch unterschieden werden: Verteiler und Verknüpfer. Kommt ein Zweig an und gehen mehrere weg, wird der Operator als Verteiler bezeichnet. Fließen umgekehrt mehrere hinein und nur einer heraus, handelt es sich um einen Verknüpfer.

Verteiler und Verknüpfer