Geschäftsprozesse und ihre Modellierung mit der Methode Business Process Model and Notation (BPMN 2.0)

Von Dr. Josef Ludwig Staud

Das Buch stellt eine umfassende Einführung in die Methode zur Prozessmodellierung BPMN 2.0 dar.
Der Aufbau des Textes wie folgt:
Nach der Einleitung folgt eine zusammenfassende Darstellung zum Gegenstand der Arbeit, Geschäftsprozesse. Dabei werden die Definition(en), die Eigenschaften und Komponenten vorgestellt.
In Kapitel 3 wird der aktuelle Stand der Geschäftsprozessmodellierung dargestellt und auf die erwartete zukünftige Entwicklung eingegangen.
Mit dem vierten Kapitel erfolgt der Übergang zur Methode BPMN, indem betrachtet wird, wie die Urheber der Methode Geschäftsprozesse sehen.
Das fünfte Kapitel bringt anhand einführender Beispiele eine erste Annäherung an die Methode.
Mit Kapitel 6 beginnt die Abbarbeitung der Methodenelemente. Dazu wird betrachtet, wie die BPMN-Autoren die Tätigkeiten erfassen, aus denen jeder Geschäftsprozess besteht.
Die den Prozess realisierenden Akteure werden in Kapitel 7 betrachtet.
Informationen und ihre Verarbeitung in Kapitel 8.
Geschäftsprozesse werden wesentlich durch Ereignisse gesteuert. Diese sind Gegenstand von Kapitel 9.
Eine gegenüber der Einführung in Kapitel 5 vertiefte Betrachtung des Kontrollflusskonzepts folgt in Kapitel 10.
Geschäftsprozesse benötigen zu ihrer Darstellung Verzweigungen und Verschmelzungen des Kontrollflusses. Die Elemente zu deren Darstellung werden in der BPMN Gateways genannt und in Kapitel 11 vorgestellt.
Ähnlich wie in vielen anderen irgendwie strukturierten Bereichen (Daten, Programme, menschliches Verhalten, ...) gibt es auch hier Muster. In Geschäftsprozessen und - entsprechend - in den Prozessmodellen. Einige davon werden in Kapitel 12 betrachtet.
Ein kurzer Blick auf das Thema Choreographie wird in Kapitel 13 geworfen.
Aus inzwischen schon jahrzehntelanger Erfahrung mit Modellierungsmethoden weiß ich, dass Beispiele sehr hilfreich sind beim Kennlernen der Methode. Deshalb werden in Kapitel 14 zahlreiche Beispiele von Prozessmodellen vorgestellt.

• Sprache: Deutsch
• Herausgeber: tredition
• Erscheinungsdatum: 10. Feb. 2017
• ISBN: 9783734593093

Buchvorschau

1Einleitung

1.1 Modelle, Modellierung

Es gibt zwei Gründe für die Modellbildung in dem hier betrachteten Bereich, für die Wahrnehmung der Organisationsrealität über modellhafte Vorstellungen². Der erste liegt in der immer mehr gestiegenen Komplexität der Unternehmensrealität. Diese führte dazu, dass sie gar nicht mehr beherrschbar ist ohne systematische Wahrnehmung, ohne Durchdringung mit einem Wahrnehmungswerkzeug.

Der zweite entsteht durch die Notwendigkeit der Softwareerstellung. Software basiert immer auf einem Modell der Realität, auf verschiedenen Ebenen. D.h., vor der Programmierung ist die Modellierungsarbeit zu leisten. Angefangen bei der elementaren Systemanalyse für die eingesetzten Systeme über die Geschäftsprozessmodellierung bis hin zur Unternehmensmodellierung, wo das Unternehmen als Ganzes (mit seiner Umwelt) ins Auge gefasst wird.

Modellierung bedeutet immer Abstraktion, d.h. Konzentration auf das, was zum jeweiligen Zeitpunkt als wesentlich erachtet wird. Insofern ist (natürlich) die Modellierung der Unternehmensrealität zeitbezogen. Derzeit ist es so, dass Geschäftsprozesse im Mittelpunkt dieser Anstrengungen stehen, ergänzt um das eingeführte ältere Instrumentarium aus der Organisationslehre.

Modellierung an sich hat natürlich noch viele weitere Aspekte, die hier nicht betrachtet werden können. Auf einen soll aber hingewiesen werden, weil er gerade Bedeutung gewinnt für die Prozessmodellierung. Er hat mit „Modellierung" zu tun, wie sie die Informatik sieht. Hier finden sich (beispielhaft: [Kastens und Büning 2008]) nicht nur Algorithmen, Logik, Petri-Netze usw., sondern auch die für unser Thema wichtigeren Abschnitte Modellierung mit Graphen und Modellierung von Abläufen, wobei hierbei Automaten genannt werden. Mit Automaten kommen Geschäftsprozesse inzwischen sehr eng in Kontakt, weil in Anwendungsprogramme gefasste Geschäftsprozesse so etwas wie (softwaretechnische) Automaten darstellen. Vgl. dazu Kapitel 13 und 14 in [Staud 2010] wo Zustandsautomaten der UML grundsätzlich aber auch in Hinblick auf ihre Eignung für die Prozessmodellierung betrachtet werden.

Organisation vs. Unternehmen

Üblicherweise denkt man, wenn man von Geschäftsprozessen spricht, an Unternehmen und an die Wertschöpfung, die mit ihrer Hilfe erzielt werden soll. Dies ist aber nicht ausreichend. Auch andere Organisationen aller Art und in allen Bereichen der Gesellschaft (Öffentliche Verwaltung, Hochschulen, (öffentliches) Gesundheitswesen, politische Institutionen, usw.) erbringen ihre Leistung durch Geschäftsprozesse.

Da aber nun mal Wertschöpfung normalerweise nur in wirtschaftlich handelnden Organisationen - sprich Unternehmen - stattfindet, wird hier von Unternehmen die Rede sein, wenn es um den Ort geht, wo versucht wird, Wertschöpfung zu realisieren. Bei all den anderen Organisationen muss dieses Ziel ersetzt werden durch das, die zu erbringenden Aufgaben mit einem möglichst effektiven und effizienten Einsatz von Mitteln zu erreichen.

1.2 Aufbau der Arbeit

Der Aufbau des Textes wie folgt:

•Nach der Einleitung folgt eine zusammenfassende Darstellung zum Gegenstand der Arbeit, Geschäftsprozesse . Dabei werden die Definition(en), die Eigenschaften und Komponenten vorgestellt.

•In Kapitel 3 wird der aktuelle Stand der Geschäftsprozessmodellierung dargestellt und auf die erwartete zukünftige Entwicklung eingegangen.

•Mit dem vierten Kapitel erfolgt der Übergang zur Methode BPMN, indem betrachtet wird, wie die Urheber der Methode Geschäftsprozesse sehen.

•Das fünfte Kapitel bringt anhand einführender Beispiele eine erste Annäherung an die Methode.

•Mit Kapitel 6 beginnt die Abbarbeitung der Methodenelemente. Dazu wird betrachtet, wie die BPMN-Autoren die Tätigkeiten erfassen, aus denen jeder Geschäftsprozess besteht.

•Die den Prozess realisierenden Akteure werden in Kapitel 7 betrachtet.

•Informationen und ihre Verarbeitung in Kapitel 8 .

•Geschäftsprozesse werden wesentlich durch Ereignisse gesteuert. Diese sind Gegenstand von Kapitel 9 .

•Eine gegenüber der Einführung in Kapitel 5 vertiefte Betrachtung des Kontrollflusskonzepts folgt in Kapitel 10 .

•Geschäftsprozesse benötigen zu ihrer Darstellung Verzweigungen und Verschmelzungen des Kontrollflusses. Die Elemente zu deren Darstellung werden in der BPMN Gateways genannt und in Kapitel 11 vorgestellt.

•Ähnlich wie in vielen anderen irgendwie strukturierten Bereichen (Daten, Programme, menschliches Verhalten, ...) gibt es auch hier Muster . In Geschäftsprozessen und - entsprechend - in den Prozessmodellen. Einige davon werden in Kapitel 12 betrachtet.

•Ein kurzer Blick auf das Thema Choreographie wird in Kapitel 13 geworfen.

•Aus inzwischen schon jahrzehntelanger Erfahrung mit Modellierungsmethoden weiß ich, dass Beispiele sehr hilfreich sind beim Kennlernen der Methode. Deshalb werden in Kapitel 14 zahlreiche Beispiele von Prozessmodellen vorgestellt.

•Begriffe, die zwar verwendet werden, aber nicht zum eigentlichen Themenbereich des Buches gehören, werden im Glossarium erläutert. Die Kennzeichnung im Text erfolgt durch einen Pfeil ( → ) vor dem entsprechenden Begriff.

1.3 Methode BPMN

Die Business Process Modeling Notation (BPMN) wird von ihren Autoren als DIE Methode zur Prozessmodellierung gesehen. Sie soll die Lücke zwischen einfachen Business-Anwendern und Programmnähe schließen. Überraschenderweise scheinen sie anzunehmen, dass einfache Anwender Flussdiagramme verwenden [OMG 2009, S. 11]. Dies ist schon erstaunlich. Die Methoden von außerhalb der USA scheinen die Autoren nicht zu kennen, nicht mal die doch in Deutschland und Europa weit verbreiteten Ereignisgesteuerten Prozessketten (EPK).

Bezeichnungen: BPMN: Business Process Modeling Notation. Ab Version 2.0: Business Process Model and Notation. BPD: Business Process Diagram

Eine Abgrenzung nehmen sie nur vor gegen web service-based XML execution languages for Business Process Management (BPM) systems. Sprachen wie BPEL4WS, die sie als zu formal ansehen für business people.

Ihr Standpunkt ist folgender: Business people sind sehr vertraut damit, Geschäftsprozesse in einem flow-chart format zu visualisieren - und - es gibt Tausende von business analysts, die mit Hilfe der flow charts untersuchen, wie Unternehmen arbeiten und die damit auch Geschäftsprozesse definieren [OMG 2009, S. 11].

Dadurch sehen sie eine Lücke und die Motivation für BPMN. Denn obiges führt ihrer Ansicht nach zu einer technologischen Lücke (technical gap) zwischen dem Format der ersten Entwürfe von Geschäftsprozessen und dem Format von Sprachen wie BPEL4WS, die diese Geschäftsprozesse ausführen. Und genau diese Lücke wollen sie überbrücken mit einer formalen Sprache, die die geeignete Visualisierung der Prozesse (a notation) auf ein geeignetes execution format (eine BPM execution language) abbildet [OMG 2009, S. 11].

Das mit der BPMN verfolgte Ziel ist somit, eine Standardvisualisierungsmethode für Geschäftsprozesse zu liefern, die in einer für die execution optimierten business process language definiert ist.

Vorgesehene Abdeckung

Die Business Process Modeling Notation soll sich auf Modellierungskonstrukte konzentrieren, die für Geschäftsprozesse geeignet sind [OMG 2009, S. 12]. Nicht betrachtet werden sollen insbesondere:

•Organisationsstrukturen

•Funktionen und ihr Aufbau

•Datenmodelle

•Strategiebetrachtungen

•Geschäftsregeln

1.4 Ziel

Ein Ziel der BPMN-Autoren war Einfachheit, die es aber trotzdem erlauben sollte, die Komplexität, die Geschäftsprozesse nun mal aufweisen, zu beherrschen [OMG 2009, S. 17]. Dabei ensteht für die Autoren ein Konflikt. Einerseits soll die Methode ermöglichen, komplexe Geschäftsprozesse zu modellieren, andererseits soll sie die Abbildung auf BPM execution languages erlauben. Die Lösung sehen sie wie folgt:

•Erstens durch die Definition einer Menge von Kernelementen, die den Anforderungen an eine einfache Darstellungstechnik genügen. Damit sollen die meisten Situationen in Geschäftsprozessen bewältigt werden können.

•Zweitens durch zusätzliche Elemente, mit denen anspruchsvollere Modellierungssituationen bewältigbar sein sollen.

•Drittens durch nicht-grafische Elemente. Diese sollen zusätzliche Informationen liefern, die notwendig sind für eine execution language oder andere Modellierungsvorhaben.

Dem Ziel, auch die Grundlagen einer Ausführungssemantik zu ermöglichen, dient, dass nun zusätzlich zur Notation auch ein formales Metamodell definiert wurde.

2Geschäftsprozesse

Was sind das für Abläufe die wir Geschäftsprozesse nennen und die wir mit Ereignisgesteuerten Prozessketten modellieren? Wie sind sie definiert? Was haben sie für Merkmale? Wie ist ihr Aufbau? Welche Herausforderungen bringen Gegenwart und Zukunft für die Prozessmodellierung? Diese Fragen werden hier beantwortet, damit wir den Gegenstand, den wir anschließend modellieren, besser verstehen und damit besser modellieren können.

2.1 Definition(en)

Geschäftsprozesse bestehen - sehr vereinfacht ausgedrückt - aus zielgerichteten aneinandergereihten Tätigkeiten, aus Tätigkeitsfolgen also. Bei solchen Tätigkeiten, die Menschen oder Anwendungsprogramme realisieren, um in Organisationen die gesetzten Ziele zu erreichen, werden in der Fachliteratur die Begriffe Aufgabe und Vorgang verwendet.

Aufgaben

Tätigkeiten sind in der Regel als Aufgaben definiert, die auf unterschiedlichen Ebenen betrachtet werden können. Sozusagen die unterste Ebene stellen die Elementaraufgaben dar. Dies sind nicht weiter zerlegbare oder auf der betreffenden Beschreibungsebene nicht weiter zerlegte Aufgaben. Mehrere solche Elementaraufgaben werden dann in einer Aufgabe zusammengefasst. Wir übernehmen folgende Definition, die auch auf die selbstverständliche Erwartung eines Ergebnisses und auf die Durchführbarkeit durch Menschen oder Maschinen hinweist [Österle 1995, S. 45]:

Definition Aufgabe

Eine Aufgabe ist eine betriebliche Funktion mit einem bestimmbaren Ergebnis. Sie wird von Menschen und/oder Maschinen ausgeführt.

So definierte Aufgaben können ebenfalls zusammengefasst werden und dies auf mehreren Stufen, u.U. bis zu der Ebene, wo sich der gesamte Unternehmenszweck in einer einzigen Aufgabe findet (z.B. „Gewinn erzielen"). Dies wird auch Aggregation genannt. Damit wird deutlich, was dann bei der konkreten Modellierung von Geschäftsprozessen eine wichtige Rolle spielt:

Die in Geschäftsprozessen zu leistenden Aufgaben können auf unterschiedlichen Aggregationsniveaus betrachtet werden. Man kann in der Prozessmodellierung Aufgaben also aufteilen³ oder zusammenfassen.

Für die Prozessmodellierung hat dies die Konsequenz, dass die Aggregationsebene, auf der die Aufgaben betrachtet werden, ein subjektiver Faktor ist, der durch die Modellierer oder auch durch den Zweck der Modellierung festgelegt werden kann. Meist wird eine Prozessmodellierung an den Stellen detaillierter, an denen Optimierungsbedarf vermutet wird und da weniger detailliert, wo man nur modelliert, um den Prozess als Gesamtheit modellieren zu können (vgl. hier das Beispiel in [Staud 2006, Abschnitt 6.2]). Oftmals werden aber auch ganz bewusst mehrere unterschiedliche Aggregationsniveaus modelliert, z.B. um Übersichtsdarstellungen zu erhalten. Dies führt zur (→)vertikalen Dimension der Prozessmodellierung.

Dieselbe Subjektivität liegt im Übrigen bezüglich der Länge von Geschäftsprozessen vor. Man kann z.B. eine Auftragsabwicklung als Ganzes, als einen Geschäftsprozess betrachten oder die einzelnen Abschnitte jeweils getrennt, also z.B. die Angebotserstellung, die Auftragsbearbeitung, die Materialbeschaffung, die Produktion, die Kalkulation, die Auslieferung, usw. Auch hier erfolgt die Festlegung nur durch die Modellierer oder den Zweck der Modellierung. Durch diesen subjektiven Faktor kommt man zu sehr unterschiedlichen Ergebnissen bezüglich der Zahl der Geschäftsprozesse, wenn man vergleichbare Unternehmensprozessmodelle⁴ betrachtet.

Funktionen

In der Prozessdiskussion wie auch in der konkreten Prozessmodellierung wird mit Funktion ein weiterer Begriff benutzt, der weitgehend mit dem Aufgabenbegriff übereinstimmt, der aber stärker auf die Modellierungsumgebung Bezug nimmt. Mertens versteht unter einer Funktion eine Tätigkeit

..., die auf die Zustands- oder Lageveränderung eines Objektes ohne Raum- und Zeitbezug abzielt. Eine Funktionsbezeichnung besteht aus zwei Komponenten, einem Verb (Verrichtung) und einem Substantiv (Objekt), auf das sich dieses Verb bezieht (z.B. „Bestellgrenze ermitteln)." [Mertens 2013, S. 41]

Solche Aufgaben bzw. Funktionen werden in allen Methoden zur Prozessmodellierung benötigt. Wer sich etwas tiefer mit der Prozessmodellierung beschäftigt, muss allerdings damit leben, dass sie unterschiedlich benannt werden: Funktionen in Ereignisgesteuerten Prozessketten (EPKn) Aktionen (actions) bei den Aktivitätsdiagrammen (der UML) und Aufgaben (task) in der Methode Business Process Model and Notation (BPMN).

Mit Objekten sind hier betriebswirtschaftlich relevante Objekte bzw. Geschäftsobjekte gemeint. Dieser Objektbegriff stimmt weitgehend (bei den meisten Autoren allerdings unausgesprochen bzw. unbewusst) mit dem allgemeinen Objektbegriff der objektorientierten Theorie überein. Es handelt sich immer um Informationsträger (z.B. eine Rechnung) mit Eigenschaften (Attributen) und einem Verhalten (bzw. zulässigen Veränderungen). Z.B. um Rechnungen mit Attributen wie Rechnungsnummer, Rechnungsdatum, Rechnungsempfänger, usw., die bezahlt oder storniert werden können.

Vorgänge

Der erste Schritt von einzelnen Aufgaben zu einer sequenziellen Folge von Aufgaben wird mit der Definition von Vorgängen gemacht. Mit Bullinger/Fähnrich sind Vorgänge

Abfolgen von Tätigkeiten, die zur Realisierung von Aufgaben ausgeführt werden. [Bullinger und Fähnrich 1997, S. 19]

Sie beziehen organisatorische Dimensionen (z.B. Stellen) in die Bearbeitung ein. Standardisierbare Vorgänge in Unternehmen werden auch als „Workflow" bezeichnet. Sie lassen sich auf der Basis von vier Kategorien beschreiben:

•Ereignisflüsse steuern die Aktivierung von Aufgaben in Abhängigkeit von auftretenden Ereignissen. Sie bewirken damit Zustandsänderungen des Systems [ebenda].

•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.

•Aufgabenträger repräsentieren Stellen einer Organisation und bearbeiten Aufgaben.

•Ressourcen sind Materialien oder Betriebsmittel, die zur Aufgabenausführung benötigt werden. Dies können auch Aufgabenträger sein.

Ganz ähnlich Scheer, der einen betriebswirtschaftlichen Vorgang wie folgt definiert:

Definition Vorgang

Ein Vorgang ist ein zeitverbrauchendes Geschehen, das durch ein Startereignis 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]

Vorgänge wiederum bilden Geschäftsprozesse. Damit ist schon recht viel von dem angeführt, was bei einer Modellierung von Geschäftsprozessen berücksichtigt werden muss:

•Der Kontrollfluss , denn dieser stellt die oben angeführten Ereignisflüsse dar. Ohne das Wissen um die korrekten Abläufe der einzelnen Vorgänge bzw. ohne Geschäftsregeln, die sie festlegen, gibt es keine Geschäftsprozesse.

•Die verwendeten Daten bzw. Datenbanken . Denn die Zustandsänderungen des Systems sind die Änderungen des Datenbestandes, die sich aus der Leistungserbringung ergeben.

•Datenflüsse entlang der Geschäftsprozesse aber auch in den einzelnen Tätigkeiten. Vor allem auch unternehmensübergreifend - heute auf der Basis von Internet und XML.

•Objektflüsse , Gegenstände der Leistungserbringung. Auch Geschäftsobjekte, mit denen wir auch wieder die Daten und Datenbanken berühren, denn natürlich werden heute Geschäftsobjekte üblicherweise in der Unternehmensdatenbank abgespeichert.

•Einzelne Tätigkeiten , basierend auf Aufgaben.

•Leistungserbringer als Aufgabenträger . Hier finden wir heute sehr oft auch Anwendungsprogramme.

•Die Organisationsstruktur durch das Stellenkonzept.

•Die für die Leistungserbringung benötigten Materialien und Ressourcen .

Dies und noch ein wenig mehr muss in der Prozessmodellierung berücksichtigt werden, will sie denn aussagefähig sein.

Definition Geschäftsprozesse

In [Staud 2006, S.9] wurden Geschäftsprozesse in Organisationen - basierend auf der Analyse der Definitionen in der Literatur und den eigenen praktischen Erfahrungen - wie folgt definiert:

Definition Geschäftsprozess

Ein Geschäftsprozess besteht aus einer zusammenhängenden, abgeschlossenen Folge von Tätigkeiten, die zur Erfüllung eines Organisationsziels notwendig sind.

Die Tätigkeiten werden von Aufgabenträgern in organisatorischen Einheiten oder Programmen unter Nutzung der benötigten Produktionsfaktoren geleistet. Unterstützt wird die Abwicklung der Geschäftsprozesse durch die IT der Organisation.

Ergänzt wurden die Anwendungsprogramme als Aufgabenträger. Dies ist in einer Zeit zunehmender Automatisierung von Geschäftsprozessen unabdingbar (vgl. hierzu Abschnitt 12.3 in [Staud 2014]). Geschäftsprozesse leisten somit die Transformation von beschafften Produktionsfaktoren in verkaufte Produkte bzw. Dienstleistungen. In ihrem Zusammenhang beschreiben die Geschäftsprozesse auch die (→)Wertschöpfungskette des Unternehmens.

Damit liegen wichtige Elemente für die Modellierung von Geschäftsprozessen vor:

•Einzelne Tätigkeiten , aus denen der Geschäftsprozess zusammengesetzt ist.

•Der Zusammenhang zwischen diesen, er wird später Kontrollfluss bzw. Sequenzfluss (BPMN) genannt.

•Einbettung des Geschäftsprozesses in die gesamte Geschäftstätigkeit des Unternehmens durch Angabe seines Zieles.

•Aufgabenträger, d.h. die Antwort auf die Frage, Wer erbringt die Leistung?

•Hinweis auf die Automatisierung von Geschäftsprozessen (Programme als Aufgabenträger).

•Produktionsfaktoren und ihr Verbrauch im Rahmen der Prozessdurchführung.

•Unterstützung der Prozessrealisierung durch die IT .

Alles dies muss eine Methode zur Modellierung von Geschäftsprozessen berücksichtigen.

Hier noch einige weitere Ergebnisse des Literaturstudiums. Hess definiert, ausgehend von einer systemorientierten Organisationslehre und der Zerlegung einer Organisation in die Subsysteme (→)Aufbauorganisation, (→)Ablauforganisation und Informationssystem einen Prozess

… als ein Subsystem der Ablauforganisation, dessen Elemente Aufgaben, Aufgabenträger und Sachmittel und dessen Beziehungen die Ablaufbeziehungen zwischen diesen Elementen sind. [Hess 1996, S. 13]

und gibt damit wiederum einen deutlichen Hinweis auf den Kontrollfluss.

Das Gemeinsame zahlreicher anderer Definitionen zu Geschäftsprozessen (z.B. in [Keller und Teufel 1997], [Hess 1996], [Becker und Vossen 1996], [Rump 1999]) kann so zusammengefasst werden:

•Geschäftsprozesse haben ein Ziel oder auch mehrere, abgeleitet aus den OrganisationszieleDie Gesamtaufgabe eines Geschäftsprozesses kann in Teilaufgaben zerlegt werden (im Extremfall kann ein Geschäftsprozess auch aus nur einer Aufgabe bestehen).

•Die Aufgaben werden von Aufgabenträgern wahrgenommen, die Inhaber von ( → )Stellen sind, die wiederum in Organisationseinheiten gruppiert sind. In den letzten Jahren wurden immer öfter Programme zu Aufgabenträgern.

•Die Aufgaben werden entweder manuell, teilautomatisiert oder voll automatisiert erfüllt.

•Ein Geschäftsprozess liegt in der Regel quer zur klassischen Aufbauorganisation, d.h. er tangiert meist mehrere Abteilungen.

•Für die Erfüllung der Aufgaben werden die Unternehmensressourcen benötigt.

•Geschäftsprozesse benötigen zu ihrer Realisierung Informationsträger aller Art.

Das gibt Hinweise auf weitere Elemente einer Modellierungstheorie. Zum einen den auf eine Strukturierung des Automatisierungsgeschehens in manuell, teilautomatisiert und vollautomatisiert, die hier im weiteren auch übernommen wird. Zum anderen den Hinweis auf die notwendigen Informationsträger.

Soweit die Literaturlese und die für die Modellierungsmethode gewonnenen Erkenntnisse. Nun noch einige Abklärungen.

Modell vs. Instanz

Ähnlich wie in der objektorientierten Theorie wird auch hier zwischen dem allgemeinen/abstrakten Modell und der konkreten Realisierung unterschieden: Das allgemeine Prozessmodell mit allen denkbaren Durchgängen auf der einen Seite und die konkrete Realisierung eines Durchgangs (Instanz) auf der anderen Seite (so auch [Rump 1999, S. 19f]).

Ein Prozessmodell (auch Schema genannt) gibt sämtliche möglichen Durchgänge, sämtliche vorgedachten Realisierungen eines Geschäftsprozesses an. Eine Instanz eines Geschäftsprozesses ist eine konkrete Realisierung, ein bestimmter Durchgang durch den Prozess.

Wenn also im Prozessmodell eine Entscheidungssituation dargestellt ist, mit allen möglichen Entscheidungen, wird bei einer Instanz des Geschäftsprozesses genau eine der Alternativen aktiv.

Vgl. zur Thematik Token und Instanzen Abschnitt 4.6 und Abschnitt 11.6 mit Instanzenbeispielen