12.1 Gründe, Ziele, Realisierung

Gründe für Modellbildung

Die klassische Organisationslehre [Anmerkung] konnte sich, wenn es um die Durchdringung und Verbesserung der Abläufe in den Organisationen ging, im Wesentlichen auf die Analyse menschlicher Handlungen konzentrieren. Dies ist heute nicht mehr möglich, Modellbildung wurde unabdingbar. Zwei Gründe [Anmerkung] sind dafür verantwortlich. 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 Modellierungswerkzeug. Der zweite entsteht durch die Notwendigkeit der Softwareerstellung. Geschäftsprozesse werden heute teilweise oder ganz in Software abgebildet, durch IT unterstützt. Software basiert immer auf einem Modell der Realität, auf verschiedenen Ebenen. D.h., vor der Programmierung ist auch hier Modellierungsarbeit zu leisten. Von der Istanalyse der Geschäftsprozesse, der Umsetzung dieser in programmnahe Modelle bis zur daraus abgeleiteten Anforderungsermittlung für die Software. Unter Umständen dann auch noch unter Einbezug der Unternehmensmodellierung, wo das Unternehmen als Ganzes (mit seiner Umwelt) ins Auge gefasst wird.

Komplexität

Softwareerstellung

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.

Abstraktion

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 Kleine 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 2019] wo Zustandsautomaten der UML grundsätzlich aber auch in Hinblick auf ihre Eignung für die Prozessmodellierung betrachtet werden, sowie in [Staud 2014a,b] die Abschnitte 12.3 ("Automatisierung") und 12.4 ("Kontrollfluss vertieft").

Automaten

Ziele der Prozessmodellierung

Erstes Ziel jeder Geschäftsprozessmodellierung ist die Bestandsaufnahme, also die Feststellung, welche Geschäftsprozesse in welcher Form ablaufen. Sie kann direkt zu einer Dokumentation (z.B. im Rahmen einer ISO 9000-Zertifizierung) führen oder zu einer Beschreibung, die man zur Vorbereitung der Einführung einer ERP-Software benötigt. In diesem Fall vergleicht man im Rahmen von Istanalysen (vgl. Abschnitt 6.1) die vorgedachten Geschäftsprozesse der ERP-Software mit den eigenen beschriebenen betrieblichen Abläufen.

Dokumentation und Istanalyse

Das zweite große Ziel ist das der Geschäftsprozessoptimierung, also der Beseitigung von Schwachstellen, die bei der Erhebung der Prozesse erkannt wurden. Beispiele für solche Schwachstellen finden sich in Abschnitt 5.1.3.

Schwachstellen beseitigen durch Optimierung

Diese Schwachstellenanalyse führt im einfachsten Fall zu Defiziten, die mit fehlender Datenintegration und fehlender Prozessintegration bezeichnet werden. Ersteres führt zu Dateninseln und Medienbrüchen, zweiteres zu Organisationsbrüchen.Vgl. Abschnitt 2.6.

Natürlich ist das zentrale Ziel jeder Prozessoptimierung die Förderung der Wertschöpfung. Der Weg dorthin geht, da ist sich die Literatur einig, über eine möglichst ausgeprägte Kundenorientierung (am realen und am "potentiellen Kunden", vgl. Stichwortverzeichnis). Vgl. dazu [Schmelzer und Sesselmann 2013, Abschnitt 2.2]. Dies ist nicht so einfach, wie es sich anhört. Kundenorientierung äußert sich oft darin, wie gut eine bestimmte Aufgabe ausgeführt wird. Dies wird aber in Prozessmodellen nicht erfasst. Das Prozessmodell macht aber deutlich, ob überhaupt Aufgaben und Systeme für den Kundenkontakt ausgewiesen sind. Die Prozessrealisierung zeigt dann, ob Kundenkontakte auch stattfinden. Die oftmals danach angeforderte Bewertung durch den Kunden ("Hat Ihnen dies geholfen?") erlaubt dann die Einschätzung des Erfolgs der Bemühungen.

Kundenorientierung

Ein weiteres wichtiges Ziel ist die Entwicklung von Software. Zum einen im Rahmen der IT-Unterstützung, zum anderen für die Automatisierung, die automatisierte Abwicklung der Geschäftsprozesse. Requirements Engineering (die Entwicklung der Anforderugnen an die zu erstellende Software; auch Anforderungsmanagement) benötigt, wenn es um Geschäftsprozesse geht, zuerst eine detaillierte Erfassung derselben. Dazu mehr in den Kapiteln 20 - 22.

Requirements Engineering

Weitere eher konkrete Ziele werden, unter dem Stichwort „Einsatzzwecke von Prozessmodellen“ in [Becker, Kugeler und Rosemann 2012, S. 199f] genannt:

Einsatzzwecke Becker

• Organisationsdokumentation. Z.B. für aktuelle Beschreibungen der Geschäftsprozesse.
• Prozessorientierte Reorganisation. Revolutionär oder evolutionär
• Kontinuierliches Prozessmanagement. Auf Dauerhaftigkeit ausgerichtete Planung, Durchführung und Kontrolle der Prozesse.
• Zertifizierung nach DIN ISO 9000ff. Nur mit Dokumentation der Modelle.
• Benchmarking. Die eigenen Geschäftsprozesse mit denen anderer Unternehmen vergleichen.
• Wissensmanagement. Um Transparenz zu schaffen über die Unternehmensressource Wissen.
• Auswahl von ERP-Software. Vergleich des eigenen Prozessmodells mit dem des ERP-Anbieters.
• Modellbasiertes Customizing. Parametrisierung der Software
• Softwareentwicklung. Als Teil der Anforderungsbeschreibung.
• Workflow-Management. Prozessmodelle als Grundlage für die Erstellung von Workflowmodellen.
• Simulation. Untersuchung des Systemverhaltens im Zeitablaufmit dem Ziel der Prozessoptimierung.

Auf einen Beitrag zur effizienten Gestaltung des Geschäftsprozessmanagements zielen die von Gaitanides angeführten Zwecke der Prozessmodellierung [Gaitanides 2012, S. 160]:

Zwecke Gaitanides

• Schaffung von Wertschöpfungstransparenz, indem die Prozessmodellierugn erlaubt, "kritische Bereiche aufzuspüren und in den Prozessablauf zur Eliminierung von Schwachstellen gezielt einzugreifen."
• Bestimmung der Prozessverantwortlichkeiten (CPOs). Erst die Prozessmodellierung erlaubt, "eine Verantwortungszuordnung nach prozessualen Aspekten" zu realisieren.
• Definition eines strukturierten Mess- und Steuerungssystems. Dies sollte zu relevanten Prozesskennzahlen führen, "mit denen die Prozessleistung bezüglich Zeit, Qualität, Prozesskosten und Kundenzufriedenheit zu überprüfen ist."
• Basis für die Ausarbeitung von Leistungsvereinbarungen, die durch visualisierte Abläufe leichter zu definieren sind.
• Schulung und Einarbeitung von Mitarbeitern, die eine transparente Prozessarchitektur erleichtert wird.
• Erstellung von Richtlinien. "Die häufig in Richtlinien vorhandene Beschrei- bung von Prozessabläufen ist in Verbindung mit einer transparenten Prozessdarstellung deutlich reduzierbar". "Der Nachweis eines Qualitätssicherungssystems nach DIN ISO 9000 ff. ist mit Hilfe der Prozessdarstellung stark zu vereinfachen, da ein zusätzliches Verfassen von Verfahrens- und Arbeitsanweisungen entfallen kann."

12.2 Grundsätze ordnungsgemäßer Modellierung

Rosemann/Schwegmann/Delfmann stellen ganz allgemeine grundsätzliche Forderungen an die Prozessmodellierung vor. Ziel ist die Reduzierung bzw. Beherrschung der mit der Modellierung verbundenen Komplexität. Die sog. Grundsätze sind wie folgt:

• Grundsatz der Richtigkeit. Forderung nach der syntaktisch und semantisch korrekten Wiedergabe des Geschäftsprozesses.
• Grundsatz der Relevanz. Forderung nach Konzentration auf für den Geschäftsprozess bedeutsame Sachverhalte.
• Grundsatz der Wirtschaftlichkeit. Forderung nach einem angemessenen Kosten-Nutzen-Verhältnis.
• Grundsatz der Klarheit. Forderung nach Verständlichkeit bzgl. der Adressaten.
• Grundsatz der Vergleichbarkeit. Forderung nach einem einheitlichen Abstraktionsgrad für Modelle derselben Modellierungsebene.
• Grundsatz des systematischen Aufbaus. Forderung nach wohldefinierten Schnittstellen zu korrespondierenden Modellen (z.B. zwischen Prozess- und Datenmodellen).

[Rosemann, Schwegmann und Delfmann 2012, S. 49f]

12.2.1 Fachliche und technische Prozessmodelle

In der betriebswirtschaftlichen Literatur wird zwischen fachlichen und technischen Prozessmodellen unterschieden. Bei [Schmelzer und Sesselmann 2013, S. 240] findet sich dazu folgende Ausprägung in

• betriebswirtschaftliche Referenzmodelle (BW-Referenzmodelle)
• Software-Referenzmodelle (SW-Referenzmodelle)
• Unternehmensprozessmodelle bzw. Geschäftsprozessmodelle

Unter BW-Referenzmodellen verstehen sie "allgemeine, auf bestimmte Anwendungsbereiche (Punktionen, Branchen etc.) zugeschnittene Informationsmodelle, die als Orientierung und Empfehlung (Bauplan) für die Konstruktion von unternehmensspezifischen Prozessmodellen sowie für die Definition und Strukturierung von Geschäftsprozessen dienen." [ebenda] Vgl. Abschnitt 18.10 für eine Beschreibung und Beispiele.

BW-Referenzmodelle

Mit SW-Referenzmodellen meinen sie Prozessmodelle, die von "Softwareherstellern in Verbindung mit Standardsoftware angeboten" werden. "Sie enthalten Referenzprozesse, die von der Standardsoftware unterstützt werden. Die Referenzprozesse werden als Soll-Prozesseempfohlen, um den Aufwand für die Adaption der Standardsoftware möglichst gering zu halten." [ebenda] Vgl. Abschnitt 18.1, Stichwort vorgedachte Geschäftsprozesse, sowie [Staud 2006, Kapitel 8] mit der Beschreibung des (damaligen) Beispiels einer Unternehmensmodellierung (SAP).

SW-Referenzmodelle

Unternehmensprozessmodelle bzw. Geschäftsprozessmodelle sind "spezifisch auf Ziele, Anforderungen und Gegebenheiten eines Unternehmens zugeschnitten. Es enthält Vorlagen und Regeln zur Definition und Strukturierung von Prozessmodellen für die Geschäftseinheiten (hier Geschäftsprozessmodelle genannt) und für geschäftsspezifische Geschäftsprozesse." [ebenda]

Unternehmens­prozessmodelle

12.3 Basiselemente einer jeden Prozessmodellierung

Geschäftsprozesse können auf verschiedenen Aggregationsebenen betrachtet und modelliert werden. Dabei werden die Aufgaben und Handlungen unterschiedlich stark detailliert oder zusammengefasst. Im einfachsten Fall können folgende Ebenen unterschieden werden:

Ebenen

• Überblicksnotationen: Hier sind in den Elementen, die Tätigkeiten/Aufgaben erfassen, viele Aktivitäten zusammengefasst, evtl. ganze Geschäftsprozesse oder Prozessabschnitte.
• Standardprozessmodellierung: Hier werden - unzerlegt, nicht aggregiert - Geschäftsobjekte, einzelne Handlungen, dazu passende Kontrollflüsse, usw. erfasst.
• Programmnahe Modellierung: Hier sind Handlungen und Geschäftsobjekte zerlegt in Elemente, die der programmtechnischen Umsetzung dienlich sind.

Die Betrachtung der Basiselemente einer jeden Prozessmodellierung hängt dann natürlich davon ab, auf welcher Ebene man die Prozesse betrachtet. Hier wird die Ebene der Standardprozessmodellierung gewählt.

Gewählte Ebene

Standardprozessmodellierung

Die Standardprozessmodellierung ist unterhalb der hoch aggregierten Überblicksnotationen und oberhalb der programmnahen Prozessmodellierung angesiedelt. Sie soll die Geschäftsobjekte (unzerlegt und nicht zusammengefasst) und den Umgang der Handelnden mit den Geschäftsobjekten klar darstellen. Es ist damit diejenige Ausprägung der Prozessmodellierung, bei der eine Handlung eines Prozessteilnehmers („Kalkulation erstellen“, „Brief schreiben“, „an Sitzung teilnehmen“) in ein Basistheorieelement (eine Tätigkeit mit verbundenen Ereignissen) findet. Auf dieser Detaillierungsebene bleiben die Geschäftsobjekte (Rechnungen, Lieferscheine, usw.) als Ganzes erhalten, verschwinden also nicht, wie auf höheren Aggregationsniveaus oder werden zerlegt wie in der programmnahen Prozessmodellierung. Istanalysen bewegen sich oft auf dieser Ebene.

Basiselemente

Es geht hier also um die Basiselemente von Geschäftsprozessen und Prozessmodellen, die in der heutigen Prozessmodellierung verwendet werden. Zusätzlich soll betrachtet werden, wie sich diese gerade durch die Digitalisierung verändern.

Etwas genauer: Welche Elemente verwenden die Methoden zur Modellierung von Geschäftsprozessen im Sinne einer Standardprozessmodellierung heute und welche kommen, durch die Digitalisierung / Automatisierung und die damit verbundene programmnahe Prozessmodellierung dazu? Eine solche Betrachtung ermöglicht eine fundierte Einschätzung der Methoden, auch bzgl. ihrer Tauglichkeit für bestimmte Anwendungen. Außerdem wird damit ein Vergleich der Methoden möglich.

Heute und morgen

Hier wird der Begriff Tätigkeit verwendet, wenn es um die einzelnen zu lösenden Aufgaben in einem Geschäftsprozess geht, und Tätigkeitsfolge, wenn Prozesse oder Prozessabschnitte gemeint sind. Der Grund ist einfach der, dass die Begriffe Aktion, Aktivität und auch Funktion durch die Methoden (Ereignisgesteuerte Prozessketten, Business Process Model and Notation) belegt sind.

Im Folgenden die Modellierungselemente, sie sind von (1) bis (12) durchnummeriert:

(1) Zentraler Gegenstand und Aufgabe des Geschäftsprozesses

Gegenstand und Aufgabe

Was wird im Geschäftsprozess bearbeitet, was ist die Aufgabe? Z.B. die „Leistung“ (Produkt, Dienstleistung) bei der Leistungserbringung des Unternehmens, das „Angebot“ bei der Angebotserstellung, usw.

"Neu" im Zeitalter der Digitalisierung:

• Neue Geschäftsprozesse auf der Basis der gewonnenen Daten (v.a. zur Umsatzgenerierung). D.h., aus den über das Käuferverhalten gewonnenen Daten werden neue Geschäftsprozesse, v.a. im Marketing, generiert.
• Neue Geschäftsprozesse aufgrund der Beobachtung von Nutzerverhalten ("… gibt's billiger bei …")
• auf mehreren Ebenen: Daten gewinnen, um sie zu verkaufen. D.h.: neues Geschäftsfeld mit neuen Geschäftsprozessen.

<<mehr dazu im Seminar/in der Vorlesung>>

(2) Elementare Tätigkeiten

Tätigkeiten

Jedes Prozessmodell braucht ein Theorieelement für die Teilaufgaben, in die man die Gesamtaufgabe zerlegt. Bzgl. der unvermeidlichen Subjektivität dieser Zerlegung vgl. Abschnitt 2.3.

Liegt eine vertikale Dimension vor, wird also die Standardprozessmodellierung nach "oben" und "unten" erweitert, werden die Tätigkeiten entweder zusammengefasst oder zerlegt. Eine einzelne Tätigkeit auf hoher Ebene, nahe den Wertschöpfungsketten, umfasst sehr viel mehr Tätigkeiten als eine auf der Ebene von Istanalysen. Eine in Systemnähe sehr viel weniger.

In der Standardprozessmodellierungsind Tätigkeiten solche, die einmal angestoßen, dann ausgeführt und zuletzt beendet werden. Es sind also keine impliziten Schleifen („bleibt aktiv“) vorgesehen, wie bei einigen Theorieelementen der UML (vgl. [Staud 2019, Kapitel 12]).

Anstoßen – ausführen – beenden

"Neu" im Zeitalter der Digitalisierung:

• „Elementare Tätigkeiten“, Geschäftsobjekte, Kontrollflüsse werden zerlegt (entsprechend den Möglichkeiten bzw. Notwendigkeiten der Programmiersprache / Entwicklungsumgebung).

<<mehr dazu im Seminar/in der Vorlesung>>

(3) Informationen auf Trägern aller Art

Informationen 1

Dieses Element erfasst jede irgendwie genutzte Information auf allen Trägern (digital oder nicht). Zentral ist dabei das Konzept der Geschäftsobjekte. Aber auch alle sonstigen Informationen gehören dazu (Koordinierungsinformationen, Nachrichtenverkehr, …). Diese werden erzeugt, verändert und gelöscht.

Dazu gehören auch die Informationsflüsse. Insgesamt also Information, die einfach nur genutzt wird, Information, die erzeugt wird und solche, die nur transportiert wird. Dies ist grundsätzlich notwendig, weil dadurch die Datenflüsse deutlich werden, die ja oft Hinweise auf Optimierungspotential liefern. Außerdem stellt es die Verbindung zu den Datenbanken her.

Flüsse

Der Grund ist, dass in jedem Geschäftsprozess zahlreiche und umfangreiche Informationen verwaltet werden. Schließlich werden ja auch die meisten Geschäftsobjekte (Rechnungen, Lieferscheine, ...) als Daten in den Datenbanken repräsentiert. Dieses Erzeugen, Bearbeiten, Löschen und Transportieren von Information ist den oben eingeführten elementaren Tätigkeiten zuzuordnen. Die dort angegebenen Träger sind dann die informationsverarbeitenden Einheiten.

"Neu" im Zeitalter der Digitalisierung:

• Intensive Informationsgewinnung über die Geschäftsprozesse, z.B. im CRM.
• Klassische relationale Datenbanken werden ergänzt durch Datenbanken, die das Geschäftsmedium Internet verlangt – NoSQL …
• Globaler Rahmen des Umgangs mit den Daten („horizontal verteilt / skaliert“).

<<mehr dazu im Seminar/in der Vorlesung>>

(4) Informationsverarbeitung

Informationen 2

Dabei soll es nicht um Lesen, Schreiben, Verändern und Löschen von Information gehen, sondern um weitergehende Informationsverabeitung. Z.B. Erstellen eines Angebots, Durchführen einer Kalkulation, usw. Dies sind allgegenwärtige Tätigkeiten in Geschäftsprozessen.

„Neu“ im Zeitalter der Digitalisierung:

• „Neu“ hinzugekommene Prozesse, v.a. im Marketing, die massive Informationsverarbeitung verlangen.
• Bestimmung von Kaufempfehlungen
• Erfassung von Daten über die im Web Handelnden: Profile erfassen, Profile auswerten.
• Noch mehr Informationsverarbeitung wegen der Automatisierungsbemühungen. Dies geht bis zur jeweiligen KI-Grenze. Hierbei erfolgt auch verstärkt die Verarbeitung „unstrukturierter“ Informationen, wie sie sich z.B. in den NoSQL-Techniken äußert.

(5) Informationstransport

Informationen 3

Hiermit ist nicht der elementare Datenzugriff gemeint, sondern der Transport von Geschäftsobjekten, usw. Auch hier gilt: Dies war schon immer ein Thema, dass durch die aktuellen Entwicklungen aber intensiviert wird. Während vor noch nicht allzulanger Zeit der Informationstransport rundum Geschäftsprozesse weitgehend innerhalb der Anwendungssoftware (z.B. ERP-Software) ablief, ist dies heute deutlich anders.

„Neu“ im Zeitalter der Digitalisierung:

• Bedingt durch die Nutzung des Internet als Geschäftsmedium neue Übertragungstechniken (z.B. für NoSQL-Datenbanken).

(6) Träger der Tätigkeiten

Träger

Dieses Element benennt, wer die jeweilige Tätigkeit realisiert: Organisationseinheiten, Stellen, Personen, Programme (z.B. auch WebServices). Diese „Zuständigen“ werden den elementaren Tätigkeiten zugeordnet. Es sollte möglich sein, mehrere Träger darzustellen, auch Beziehungen zwischen den Trägern („Dies erledigt der Verkauf entweder mit der Produktion oder mit dem Controling“).

Je weitgehender ein Geschäftsprozess automatisiert ist, desto mehr liegen Programme als Aufgabenträger vor. Man stelle sich dazu einen Geschäftsprozess in einem Internet-Unternehmen vor, der den Umgang mit den Kunden beschreibt. Hier sind neben den Kunden fast nur Programmkomponenen als Träger der Tätigkeiten anzutreffen.

Heute sind dies neben den beteiligten Menschen Programme unterschiedlichster Art:

• ERP-Software
• Sonstige Anwendungsprogramme
• „KI“-Programme

„Neu“ im Zeitalter der Digitalisierung:

• IT-Unterstützung wird immer mehr ausgebaut. Automatisierung wohlstrukturierter Probleme. Teilweise Automatisierung semistrukturierter Probleme.
• Evtl. bald Automatisierung unstrukturierter Probleme (vgl. zu Problemstrukturen Abschnitt 2.4 sowie [Staud 2017, Kapitel 3]).

(7) Ereignisse

Ereignissteuerung

Gedacht ist hier an die für den Geschäftsprozess wichtigen Ereignisse. Ereignisse in diesem Sinne sind ein Bestandteil des Kontrollflusses. In der Ablaufmodellierung werden schon lange Ereignisse und Aktionen miteinander verknüpft. Die einfache Tatsache, dass eine Tätigkeit startet, ist ein Ereignis bzw. bedingt ein Ereignis (die Ursache für die Tätigkeit). Die Tatsache, dass eine Tätigkeitsfolge endet, stellt wiederum ein Ereignis dar, bzw. führt zu einem Ereignis – oder auch zu mehreren, entsprechend der Operatoren. Dieses Konzept, Tätigkeitsfolgen und Ereignisse miteinander zu verknüpfen, ist elementar und aus der Standardprozessmodellierung nicht wegzudenken.

Die Ereignisse kommen aus der Ereigniswelt des Unternehmens. Zu dieser gehört das Unternehmen selbst, seine Geschäftspartner, staatliche Einrichtungen, das politische System ("Energiewende jetzt") und die Gesellschaft als solche ("Wir wollen keine Stromtrassen").

Ereignisumwelt des Unternehmens

„Neu“ im Zeitalter der Digitalisierung:

• Detaillierung der Ereignisse, entsprechend der Detaillierung der Aufgaben („programmnah“; „event driven programming“)
• Ereignisse rund um Geschäftsprozesse (Ereignisumwelt) werden aber weiter benötigt, schließlich legen sie den Prozessablauf fest.

(8) Kontrollfluss

Tätigkeitsfolge

Der Kontrollfluss regelt die Abfolge der elementaren Tätigkeiten. Ihre sequenzielle Anordnung (hintereinander) und die Verzweigungen. Beides wird von der Semantik des jeweiligen Geschäftsprozesses bestimmt. Damit ist der Kontrollfluss ein Strukturmerkmal von Geschäftsprozessen.

Es gibt verschiedene Vorstellungen von Kontrollfluss. Der einfachste Fall: Geschäftsprozesse und elementare Tätigkeiten werden angestoßen, abgearbeitet und beendet. Ein Geschäftsprozess wird erst wieder gestartet, wenn die vorige Instanz beendet ist. Die erweiterte Variante ist, dass mehrere Instanzen parallel gestartet werden können.

Ein Kontrollfluss hat Verzweigungen. Im einfachsten Fall drei, die der Struktur der logischen Operatoren ODER, exklusives ODER (XODER) sowie UND entsprechen.

Nicht neu, aber mit höherer Intensität im Zeitalter der Digitalisierung:

• Der Kontrollfluss des Geschäftsprozesses muss in Programmen „umgesetzt“ werden. Er wird abgebildet in Ablaufstrukturen des Programms.

(9) Andere Flüsse

Viele Flüsse

Oben wurden schon Nachrichten- und Informationsflüsse angeführt. Neben diesen sollten auch andere ausdrückbar sein, z.B. Dokumentenflüsse, Materialflüsse, Fluss von sonstigen Dingen (z.B. bei logistischen Vorgängen).

„Neu“ im Zeitalter der Digitalisierung:

• Sehr viel mehr digitale Geschäftsobjekte
• Alle digitalen Geschäftsobjekte können auch über das Internet transportiert werden

(10) Ebenen, Kapselung

Rauf und runter

Eine Standardprozessmodellierungmuss Detaillierungsebenen ermöglichen. Es muss also möglich sein, Tätigkeiten zu zerlegen oder zusammenzufassen. Wird bewusst in mehreren Ebenen modelliert, sollte man zwischen den in den einzelnen Ebenen gekapselten Tätigkeitsfolgen Beziehungen anlegen können, so dass klar ist, wie die Beziehungen zwischen den Tätigkeitsfolgen "oben" und "unten" aussehen (Aufruf, Rückkehr, Weitergabe und Rückgabe von Information, usw.). Zum Beispiel mit exakten Verweisen zwischen den Ebenen, so wie bei den Strukturierten Aktivitätsknoten oder den Subautomaten in Zustandsautomaten (vgl. Kapitel 13 in [Staud 2019]).

Treibt man die Zerlegung sehr weit, wird die programmnahe Modellierung erreicht. Fasst man sehr weit zusammen, landet man bei einer Überblicksnotation. Die Abgrenzung entlang dieser vertikalen Dimension der Prozessmodellierung ist weitgehend subjektiv.

(11) Verweise, Verknüpfungen

Hin und her

Eher aus der Praxis der grafischen Modellierung kommt dieses Methodenelement. Hier ist man oft genötigt, lange Tätigkeitsfolgen aufzuteilen. Zum einen, weil dadurch mehrfach genutzte Prozessabschnitte an verschiedenen Stellen einfach per Verweis eingebaut werden können, zum anderen schlicht wegen der Übersichtlichkeit der entstehenden Grafik.

Grundlage ist eine klare und sinnvole Identifikation der einzelnen Geschäftsprozesse (vgl. Kapitel 4).

Semantisch betrifft dies den Zusammenhang zwischen den Geschäftsprozessen einer Organisation („folgen aufeinander“, …), methodisch den Zusammenhang zwischen Prozessmodellen.

Seinen Höhepunkt findet dies bei der Darstellung von Prozesslandschaften.

„Neu“ im Zeitalter der Digitalisierung:

• Eindeutige Klärung der Schnittstellen auf programmnaher Ebene

(12) Zeitliche Dimension

Zeitachse

Für eine Standardprozessmodellierung genügt es, wenn bzgl. der zeitlichen Dimension

• die zeitliche Abfolge durch die sequentielle Anordnung,
• Zeitpunkte und der
• vorgesehene Zeitverbrauch (zumindest bei ausgewählten Tätigkeiten)

modelliert werden können.

„Neu“ im Zeitalter der Digitalisierung:

• Umsetzung der Zeitaspekte im Programm
• Vorbereitung in der programmnahen Modellierung
• Steuerung des Kontrollflusses in Realzeit. Beispiel: Nutzerverhalten / Preisanpassung – „neue“ Prozesse

Soweit, kurz und knapp die Betrachtung der Basiselemente von Geschäftsprozessen und deren Prozessmodellen. Auch die weitere Entwicklung wurden angedeutet: Für eine programmnahe Prozessmodellierung müssen diese Konzepte in vielerlei Hinsicht ergänzt werden, wobei dabei die Betrachtung der „Verhaltens-Kapitel“ der objektorientierten Theorie sehr hilfreich ist (vgl. die Kapitel 10 bis 13 in [Staud 2019]).

12.4 Methoden für Abläufe

Modellierungskonzepte

Betrachtet man alle Methoden, die "irgendwie" Abläufe (Tätigkeitsfolgen) beschreiben, kommt man auf eine große Zahl. Vgl. [Gadatsch 2013, Abb. 4-1, Pos. 326]. Dann kommt man auch zu der klassischen Unterteilung in datenorientierte, kontrollflussorientierte und objektorientierte Konzepte [ebenda]:

„Flusskonzepte“

• Datenflussorientierte Methoden beschreiben nur die Datenflüsse, die im Geschäftsprozess auftreten. Solche Diagramme waren in den 1960er-Jahren verbreitet, vor den kontrollflussorientierten Methoden. Seitdem dienen sie nur noch der Ergänzung der eigentlichen Prozessmodellierung und dies meist nur in abgegrenzten Bereichen.
• Die wirklich objektorientierten Methoden ("rund um das Klassendiagramm") der UML sind nicht oder nur sehr eingeschränkt für die Prozessmodellierung geeignet. Vgl. [Staud 2019, Abschnitt 7.8, Kapitel 14]. Geeignet sind die "Dynamik-Komponenten" der UML, in erster Linie Aktivitätsdiagramme[Staud 2019, Kapitel 10], aber auch (für bestimmte Aufgaben) Sequenzen [Staud 2019, Kapitel 11] , Anwendungsfälle [Staud 2019, Kapitel 12] und Zustandsautomaten [Staud 2019, Kapitel 13] .

Bedeutung für die Prozessmodellierung haben allerdings nur kontrollflussorientierte Methoden. Sie sind geeignet, weil sie die zentrale Eigenschaft von Geschäftsprozessen, einem Kontrollfluss zu unterliegen, zu modellieren erlauben. Hier ist das Angebot sehr groß. Genutzt werden:

• Ereignisgesteuerte Prozessketten. Vgl. für eine umfassende Beschreibung [Staud 2014a,b].
• Business Process Diagrams der Business Process Model and Notation (BPMN). Vgl. für eine Beschreibung [Staud 2017].
• Aktivitätsdiagramme der UML. Vgl. für eine Beschreibung [Staud 2019, Kapitel 10].
• Sequenzdiagramme der UML, programmnah, auf bestimmte detailliert Stellen im Ablauf konzentriert. Vgl. für eine Beschreibung [Staud 2019, Kapitel 11].
• Zustandsautomaten der UML. Vgl. für eine Beschreibung [Staud 2019, Kapitel 13].
• Flussdiagramme (aus der Systemanalyse).
• Ablaufdiagramme (aus der Systemanalyse).

“UML” meint die Unified Modeling Language der Object Management Group.

Diese Methoden beschreiben alle (mehr oder weniger) den Kontrollfluss (BPMN: Sequenzfluss) der Abläufe. Einige erlauben auch die Modellierung der Informationsflüsse.

Prozesslandkarten

Sehr oft werden nicht nur einzelne Geschäftsprozesse betrachtet, sondern die Gesamtheit der Prozesse, z.B. eines Unternehmens (Unternehmensprozessmodell), einer Abteilung oder eines Tochterunternehmens. Dies erlaubt dann auch die Erfassung der Zusammenhänge zwischen den Geschäftsprozessen. Ein (historisches) Beispiel findet sich hierzu in [Staud 2006, Kapitel 8].

Prozesse im Zusammenspiel

Darstellung der Prozessmodelle

Prozessmodelle werden immer in Form von einfachen Graphen/Netzwerken dargestellt (vgl. für eine Einführung in Graphen/Netzwerke [Diestel 2017]). Es gibt Knoten (hier die elementaren Tätigkeiten), gerichtete Kanten (die einzelnen Kontrollfüsse) und weitere beschreibende Elemente für Ereignisse, Daten, Träger von Tätigkeiten (Stellen, Abteilungen, Software), Nachrichtenflüsse, usw.

Graphen und Netzwerke

Ein wichtiger Ausgangspunkt für alle prozessbeschreibenden Methoden waren Petri-Netze. Vgl. dazu beispielhaft [Chen und Scheer 1994], [Langner, Schneider und Wehler 1997], [Oberweis 1996].

Petri-Netze

Kurzbeschreibungen der Methoden mit der üblichen Darstellung von Prozessmodellen finden sich in den Kapiteln 14 (Methode EPK) und 15 (Methode BPMN) dieses Textes, außerdem für Aktivitätsdiagramme in [Staud 2019, Kapitel 10]. Ausführliche Darstellungen der Methoden in [Staud 2017] (BPMN) und [Staud 2014a,b] (Ereignisgesteuerte Prozessketten).

Vgl. www.staud.info

Ein wichtiges Differenzierungsmerkmal bei der grafischen Notation ist die Darstellung der Träger von Tätigkeiten. Sie können direkt den elementaren Tätigkeiten zugeordnet werden, wie es z.B. bei Ereignisgesteuerten Prozessketten meist üblich ist: Jeder Funktion wird durch eine Ellipse eine Stelle, Abteilung oder eine Software zugeordnet. Vgl. die Beispiele in Kapitel 14.

Mit und ohne Schwimmbahnen (swim lanes)

Oder sie werden in Schwimmbahnen geordnet. Dies geschieht so, dass alle Tätigkeiten eines Prozessträgers in einer Bahn dargestellt werden. Da gibt es dann für jeden Prozessträger eine Bahn, mehrere Bahnen werden in einem Becken zusammengefasst. Auch hierarchische Strukturen sind hier möglich, indem eine Bahn unterteilt wird in Subbahnen.

Becken und Bahnen, pools und lanes

Grundsätzlich können alle Prozessmodelle, die Zuständigkeiten erfassen, mit oder ohne Schwimmbahnen dargestellt werden.

Insgesamt gilt in der Praxis heute:

• Ereignisgesteuerte Prozessketten werden meist ohne Schwimmbahnen, dafür mit Organisationseinheiten an den Tätigkeiten dargestellt.
• Mit der BPM werden meist Schwimmbahnen benutzt.
• Die Aktivitätsdiagramme erlauben beides, meist sieht man sie aber mit Schwimmbahnen.

Oftmals werden Formulare für die Prozesserfassung genutzt. Vgl. Abschnitt 6.1 für ein Beispiel. Ein weiteres findet sich in [Gadatsch 2015, Pos. 390, Abb. 4.6, Abb. 4.7].

Tabellarische Prozesserhebung

Prozessformulare erfassen deskriptive Aspekte des Prozesses, der eigentliche Kontrollfluss kann (für nicht-triviale Geschäftsprozesse) so aber nicht umfassend beschrieben werden, auch wenn Prozessschritte mitaufgenommen werden. Dies wird schnell unübersichtlich.

Ihre Stärke liegt darin, Informationen zu erfassen, die nicht im Prozessmodell ausgedrückt werden, z.B. Verantwortliche, konkret eingesetzte Software oder Nahtstellen im Prozess.

Modell vs. Instanz

Wenn wir einen Prozess modellieren, erfassen wir alle denkbaren Durchgänge, egal wie an den einzelnen Verzweigungspunkten der Kontrollfluss bei einem konkreten Durchgang stattfindet. Dies wird Prozessmodell oder auch Geschäftsprozessschema [Rump 1999, S. 19f] genannt. Betrachtet man dagegen einen konkreten Durchgang durch den Geschäftsprozess (eine konkrete Realisierung), spricht man von einer Instanz des Geschäftsprozesses. Auch sie kann – mit leichten Spefikationen - modelliert werden. Vgl., auch für ein Beispiel, für ein Beispiel Abschnitt 13.3.5.

Allgemein und spezifisch

12.5 Ergänzende Modellierung

Aus der Erkenntnis heraus, dass Prozessmodelle nur einen Teil des Prozessgeschehens abdecken, gibt es Vorschläge, weitere Methoden hinzuzuziehen. Stähler (Head of Strategy amp; Operations bei der GBTEC Software +Consulting) schlägt z.B. die Verbindung von Software für Prozessmodellierung mit Notationen zur Modellierung von Entscheidungsprozessen (DMN) und IT-Architekturen (ArchiMate) vor. Vgl. [Stähler 2017, S. 33].

Die Decision Model and Notation (DMN) soll die Modellierung von Entscheidungen ermöglichen. Vgl. für eine Einführung [Freund und Rücker 2017, Kapitel 6].

DMN für Entscheidungs­prozesse

<<mehr dazu in Kürze>>

"ArchiMate ist eine grafische Notation zur Darstellung von Unternehmensarchitekturen mit einem primären Fokus auf IT-Architekturen. Eingesetzt wird sie unter anderem für die Dokumentation von Transformations- und Migrationsplanungen im IT-Umfeld. Die Notation ermöglicht die Beschreibung von Geschäftsprozessen, Organisationsstrukturen, Informationsflüssen, IT-Systemen und technischer Infrastruktur." [Stähler 2017, 21-22, S. 32-34].

ArchiMate zur Modellierung der IT-Architektur

<<mehr dazu in Kürze>>

12.6 Grenzen der Prozessmodellierung

Ist man mit der Modellierung nicht-trivialer Geschäftsprozesse befasst, bemerkt man sehr bald, dass jede Methode Stärken und Schwächen hat. Hier sollen die Schwächen näher betrachtet werden.

Da gibt es zum einen Grenzen bzgl. der Ausagekraft der Methode als solcher. Wie gut ist ihr Instrumentarium geeignet, Geschäftsprozesse zu erfassen und zu modellieren? Diese Einschränkungen sollen Methodengrenzen genannt werden. Zum anderen gibt es Grenzen bzgl. der Aussagekraft der mit der Methode erarbeiteten Prozessmodelle. Diese sollen Analysegrenzen genannt werden. Drittens gibt es Grenzen bzgl. der grafischen Aussagefähigkeit der erstellten Prozessmodelle. Diese sollen Grafikdefizite genannt werden.

Grenzen, Einschränkungen, Defizite

Die Methoden der Prozessmodellierung als solche stoßen an Grenzen, wenn es um die Erfassung sehr komplexer Geschäftsprozesse geht. Diese Komplexität kann so hoch werden, dass die Methode und auch die grafische Gestaltung der Modelle überfordert sind. Es gibt auch Prozessstrukturen, die mit den gängigen Methoden nicht (sinnvoll) abbildbar sind. Ein Beispiel ist das Beobachten einer Tätigkeit und das Reagieren darauf. Vgl. [Staud 2006] für ein Beispiel („… der Verkauf überwacht die Erstellung der CAD-Unterlagen …“). Grundsätzlich lässt sich alles, was auf das sequentielle Kontrollflusskonzept abbildbar ist, gut modellieren. Was darüber hinaus geht, nicht.

Methodengrenzen

Auf weitere Methodengrenzen stößt man, wenn man diese Methoden mit einigen der UML vergleicht. Dort sind ablaufbeschreibende Methoden vorhanden, die – weil von der Systemanalyse motiviert – sehr ins Detail der Ablaufbeschreibung gehen. Nicht so sehr die Aktivitätsdiagramme, sondern die Sequenzdiagramme und die Zustandsautomaten (vgl. dazu [Staud 2019]). Letztere gewinnen seit einigen Jahren Bedeutung, weil (natürlich) Anwendungssoftware, vor allem wenn sie weitgehend automatisiert ist, durchaus als Automat interpretiert werden kann (vgl. [Staud 2019]).

UML

Auch bzgl. der in einem Geschäftsprozess notwendigen Verarbeitung von Daten sind die Methoden nur eingeschränkt leistungsfähig. Zwar werden in einer kompetenten (Standard-)Prozessmodellierung die Zugriffe auf die Daten („Kundendaten erfassen“) und die wichtigsten Verarbeitungsschritte („Rechnung erstellen“) ausgedrückt, dies geschieht aber eher kursorische und nur soweit, wie es die Prozessbeschreibung erfordert. Alles, was „tiefer geht“, ist mit dem Standardinstrumentarium nicht ausdrückbar.

Verarbeitung von Daten

Prozessmodelle liefern eine genaue Beschreibung der möglichen (gewollten) Abläufe in einem Geschäftsprozess. Ein Ist-Prozessmodell kann alle diesbezüglichen möglichen Defizite aufzeigen, es gibt aber z.B. keine Auskunft über die Qualität der durchgeführten Arbeiten („Kalkulation durchführen, …). Dies muss auf andere Weise geklärt werden.

Analysegrenzen

In einem Prozessmodell können Rahmenbedingungen für Aufgaben nur beschränkt ausgedrückt werden. Zum Beispiel rechtliche, aber auch technische. Natürlich können einfache Rahmenbedingungen, die den Kontrollfluss festlegen, problemlos ausgedrückt werden („Lagerbestand ausreichend?“, „Ingenieurkapazitäten vorhanden?“), es wird aber schnell unübersichtlich, wenn es ins Detail geht. Ganz grundsätzlich gilt: Rahmenbedingungen, die sich nicht im Kontrollfluss niederschlagen, sind im Prozessmodell nur als textliche Anhänge erfassbar (z.B. als Artefakte in der BPMN). In der Praxis kann man manchmal den Versuch beobachten, diese Art Rahmenbedingungen im Prozessmodell unterzubringen. Dies führt dann aber zu großer Unübersichtlichkeit und zu einer Detaillierung, die mit dem übrigen Modell nicht harmoniert. Vgl. zur Frage gleichmäßiger Detaillierung in Prozessmodellen [Staud 2006] und [Staud 2014].

Rahmenbedingungen

Prozessmodelle werden üblichweise grafisch ausgedrückt. Dies führt bei nicht-trivialen Geschäftsprozessen schnell zu Unübersichtlichkeit. Ein Beispiel sind die Schwimmbahnen und Becken für die Darstellung der Prozessträger. Ihre Nutzung wird, wenn der Geschäftsprozess lang ist und wenn viele und wechselnde Prozessträger vorhanden sind, schnell unübersichtlich.

Grafikdefizite

<<mehr zu allen diesen Punkten im Seminar / in der Lehrveranstaltung>>

12.7 Software für die Prozessmodellierung

Software für die eigentliche Prozessmodellierung gibt es in großer Zahl. Einige Beispiele:

• Webtool BIC DESIGN
• ARIS Express (Download über www.ariscommunity.com/aris-express). Informationsstand: Juli 2019.
• VISIO von Microsoft
• Camunda (https://camunda.com/download/)

<<Diese Liste wird fortlaufend ergänzt und aktualisiert>>