Prof. Dr. Josef L. Staud
Geschäftsprozesse und ihre Modellierung mit der Methode Business Process Model and Notation (BPMN 2.0)
Josef Ludwig Staud
Prof. Dr. Josef L. Staud
www.staud.info
staud@staud.info
Bibliographische Information der Deutschen Nationalbibliothek: Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliographie. Detaillierte bibliographische Angaben sind im Internet über http://dnb.d-nb.de abrufbar.
Urheberrecht
Dieser Text ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Textes oder von Teilen dieses Textes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.
Warenzeichen und Markenschutz
Alle in diesem Text genannten Gebrauchsnamen, Handelsnamen, Marken, Produktnamen, usw. unterliegen warenzeichen-, marken- oder patentrechtlichem Schutz bzw. sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Inhaber. Die Wiedergabe solcher Namen und Bezeichnungen in diesem Text berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Gesetzgebung zu Warenzeichen und Markenschutz als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
Prof. Dr. Josef L. Staud
© 2017 Dr. Josef L. Staud
Verlag: tredition GmbH, Hamburg
978-3-7345-9228-7 (Paperback)
978-3-7345-9229-4 (Hardcover)
978-3-7345-9309-3 (e-Book)
Es ist nicht mehr die Zeit, wie bei Erscheinen meines ersten Buches zu Geschäftsprozessen und Ereignisgesteuerten Prozessketten ([Staud 2006]), in der Organisationen ihre Prozesse nicht kennen und Prozessanalysen durchführen, um wenigstens ein Stück weit diesbezügliche Kenntnis zu erlangen. Nein, die Phase, in der die Prozesslandschaft weiße Flecken aufwies, ist vorbei - oder sollte zumindest vorbei sein.
Nicht vorbei ist dagegen das Thema Prozessoptimierung. Es ist so bedeutsam, dass man kaum eine Beilage zur Tageszeitung aufschlagen kann, ohne in einem Interview von einem Geschäftsführer zu hören, dass viele Aufgaben gelöst sind, Prozessoptimierung aber bleibt. Es ist wohl wie so vieles eine ständige Aufgabe. Prozessoptimierung aber bedarf der Erfassung der Prozesse, ihrer Beschreibung durch Prozessmodelle. Erst nach dieser Erfassung können viele Schwachstellen erkannt und beseitigt werden.
Befeuert wird diese Entwicklung durch den starken Trend zu einer immer detaillierteren Abbildung der Geschäftsprozesse in „die Software“, zu immer mehr Automatisierung und schließlich zur Vollautomatisierung, wie es uns die Internetunternehmen vorleben. Zum ersten Mal in der Geschichte des kaufmännischen Miteinander gehen wir Menschen in wichtigen Bereichen mit weitgehend vollständig in Software gegossenen Geschäftsprozessen um.
Dass diese Thematik von hoher Aktualität ist, zeigen auch aktuelle Erhebungen. So nannten in der Studie IT-Kompass 20161 59% der Befragten an erster Stelle die Optimierung der Geschäftsprozesse als ein Thema, das sie beschäftigt [Herrmann 2016, S. 24].
Das hat unter anderem die Konsequenz, dass die Prozessmodellierung auf verschiedenen Ebenen stattfinden muss. Früher geschah dies der Übersichtlichkeit wegen, vor allem in der Unternehmensmodellierung, heute aus der Notwendigkeit heraus, denn eine Prozessmodellierung zur Vorbereitung der Programmierung einer Anwendungssoftware muss wesentlich detaillierter sein als eine Prozessmodellierung für eine Istanalyse.
Josef L. Staud
| AD | Aktivitätsdiagramm der UML |
| ARIS | Architektur integrierter Informationssysteme |
| B2B | Business to Business, Geschäftstätigkeit von Unternehmen miteinander im Internet. |
| B2C | Business to Customer, Geschäftstätigkeit im Internet, der direkt mit dem Endkunden zu tun hat. |
| BPD | Business Process Diagram |
| BPMN | Business Process Modeling Notation. Ab Version 2.0: Business Process Model and Notation |
| BPR | Business Process Reengineering |
| DV | Datenverarbeitung |
| EDV | Elektronische Datenverarbeitung |
| EPK | Ereignisgesteuerte Prozesskette |
| GP | Geschäftsprozess |
| IT | Eigentlich Informationstechnologie, bzw. information technology. Heute benutzt als Kurzbezeichnung für die gesamte EDV-Ausstattung einer Organisation. |
| ODER | Logischer Operator ODER |
| SPM | Standardprozessmodellierung |
| UND | Logischer Operator UND |
| vs. | versus (im Vergleich zu, im Gegensatz zu) |
| WSK | Wertschöpfungsketten |
| XODER | Logischer Operator Exklusives ODER |
Die Abkürzungen in den Business Process Diagrams (BPDs) werden beim jeweiligen Prozessmodell erläutert.
Es gibt zwei Gründe für die Modellbildung in dem hier betrachteten Bereich, für die Wahrnehmung der Organisationsrealität über modellhafte Vorstellungen2. 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.
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.
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
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.
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.
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 aufteilen3 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 Unternehmensprozessmodelle4 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].
• Datenbzw. 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 zum Inclusive Gateway.
In den Anfangsjahren der Organisationslehre und bis in die 1960-er Jahre hinein konzentrierte man sich bei Optimierungsbemühungen auf einzelne Tätigkeiten, ihre Stelleninhaber (→Stellen) und die Einbettung der Tätigkeiten in die Abläufe. Danach kam der Geschäftsprozessgedanke auf. Mit dem Konzept des Geschäftsprozesses verändert sich die Perspektive. Jetzt standen längere zusammenhängende Folgen von Tätigkeiten, die zur Erledigung einer größeren Aufgabe nötig sind, im Mittelpunkt der Betrachtungen. Unter Umständen sogar eine Folge von Tätigkeiten, die in Bezug auf das betrachtetet Unternehmen abgeschlossen ist. Das ist auch heute noch der Stand der Technik. Die meisten Bemühungen, die Abläufe in den Unternehmen effektiver und effizienter zu gestalten, starten mit einer Analyse der Geschäftsprozesse und deren Optimierung.
Beispiele
Hier nun noch einige Beispiele für Geschäftsprozesse, angelehnt an die typische Struktur in Industrieunternehmen:
• Angebotserstellung (Erstellung eines Angebots, nachdem eine Anfrage einging)
• Auftragsvergabe (Vergabe eines Auftrags an einen Lieferanten)
• Beschaffung (z.B. von Teilen für die Produktion)
• Mahnwesen (z.B. als regelmäßiger Abgleich von offenen Posten und Zahlungseingängen).
und, ein meist sehr langer Geschäftsprozess,
• die Auftragsabwicklung bzw. Leistungserbringung (vom Eintreffen des Auftrags beim Unternehmen bis zur Auslieferung der Ware beim Kunden).
Selbstverständlich gibt es auch kurze Geschäftsprozesse in dem Sinn, dass sie nicht viele Einzeltätigkeiten umfassen, z.B.
• Kundenbefragung (z.B. im Rahmen des Customer Relationship Managements (CRM)).
• Personaleinstellung
• Zahlungsabwicklung
• Genehmigung einer Investition oder
• Fakturierung
Es gibt natürlich sehr viele betrachtenswerte Eigenschaften von Geschäftsprozessen und Prozessmodellen, vgl. dazu die einschlägige Literatur (z.B. [Schmelzer und Sesselmann 2013] oder [Becker, Kugeler und Rosemann 2012]). Hier konzentrieren wir uns auf die wichtigsten, das sind auch diejenigen, die am meisten Bedeutung für die Prozessmodellierung haben.
Detaillierungsgrad der Prozessmodellierung.
Mit diesem Merkmal erfasst man, wie detailliert ein Geschäftsprozess modelliert ist. Wurden, wie in den Anfangsjahren der Prozessmodellierung (den 1970er-Jahren), nur einige Meilensteine des Prozesses erfasst? Oder alle wichtigen Abschnitte in grober Detaillierung? Oder ist der Gesamtprozess detailliert modelliert? Letzteres bedeutet, dass alle von den Beteiligten zu lösenden Aufgaben detailliert erfasst und modelliert sind.
Eine detaillierte Modellierung ist Voraussetzung für die Umsetzung in Software, denn nur dann können die Modelle im Anforderungsmanagement für die Softwareerstellung dienen. Sie ist natürlich auch Voraussetzung für die vollständige Umsetzung in Software und damit die Automatisierung.
Sie ist aber nicht immer möglich. Detaillierung ist umso leichter realisierbar, je standardisierter die entsprechenden Prozessabschnitte sind, weil man dann die einzelnen Abschnitte kennt. Je weniger Standardisierung, z.B. im Bereich kreativer Vorgänge (Strategien entwickeln, Forschung, Entwicklung), desto weniger detailliert kann die Prozessmodellierung sein. Wir sehen aber alle täglich bei unseren Kontakten mit gegenüber den Kunden (fast) voll automatisierten Geschäftsprozessen im Internet, dass zumindest Komplexität kein Hindernis für eine detaillierte Modellierung und Umsetzung in Software ist.
Im Prozessmodell sichtbar wird der Detaillierungsgrad ganz einfach durch die Aufteilung der Tätigkeiten. Stellen diese Elementartätigkeiten dar, ist die Detaillierung hoch. Wurde oft aggregiert, u.U. so, dass konkrete einzelne Handlungen nicht mehr darstellbar sind, ist der Detaillierungsgrad niedrig.
IT-Abdeckung
Mit dieser Eigenschaft wird erfasst, welcher Anteil des Prozesses durch IT unterstützt wird, d.h. durch Computerprogramme und die zugehörige Hardware. Die Betonung liegt hier auf Unterstützung, in Abgrenzung zu Automatisierung, d.h. vollständiger Realisierung des Geschäftsprozesses durch Software. Unterstützung der Abwicklung der Geschäftsprozesse durch Anwendungssoftware ist heute Standard, nur das Ausmaß ist unterschiedlich. Sind wirklich nur noch die Funktionen im Geschäftsprozess nicht IT-gestützt realisiert, die Entscheidungen darstellen, oder gibt es Abschnitte, die trotz der Möglichkeit der IT-Unterstützung diese nicht bekommen haben.
Alles in allem ist die IT-Abdeckung inzwischen, v.a. seit der Etablierung prozessorientierter integrierter Standardsoftware (ERP-Software), sehr hoch. Heute werden meist fast alle Abschnitte der Geschäftsprozesse IT-gestützt realisiert.
In einer Prozessmodellierung kann die IT-Unterstützung erfasst werden, indem bei den einzelnen Tätigkeiten vermerkt wird, ob sie mit Softwareunterstützung realisiert werden oder nicht. Indem also bei einer Tätigkeit nicht nur angegeben wird, wer sie realisiert, sondern auch mit Hilfe welcher Anwendungssoftware. Sie kann auch durch die modellierten Datenobjekte erkannt werden. Bei IT-Abdeckung sind diese Teil des Datenbestandes einer Anwendungssoftware und (hoffentlich) als solche gekennzeichnet.
Voraussetzung für eine IT-Abdeckung ist allerdings die oben angemerkte detaillierte Modellierung, also im Rahmen einer Beschaffung nicht Teile beschaffen, sondern zulässige Lieferanten bestimmen, Lieferanten anfragen, Konditionen klären, Bestellung formulieren, Bestellung versenden, usw. Etwa so wie in einer Standardprozessmodellierung (SPM) (vgl. Abschnitt 3.1 und das Stichwortverzeichnis). Danach können dann diese elementaren Funktionen in einer noch detaillierteren Ebene in Programmkonstrukte abgebildet werden.
Erfolgt eine solche Prozessmodellierung zur Vorbereitung der Programmierung einer integrierten prozessorientierten Software ist sie Teil des Anforderungsmanagements (Requirements Engineering) im Entwicklungsprojekt.
Automatisierungsgrad
Eine weitere wichtige Eigenschaft von Prozessen oder Prozessabschnitten ist der Automatisierungsgrad. Damit ist der Anteil an der Aufgabenerfüllung gemeint, der ohne menschliches Zutun allein durch die Informationstechnologien erledigt wird. In vielen Bereichen strebt man nach einem möglichst hohen Automatisierungsgrad. Dort, wo es sich um stark standardisierte Abläufe mit einfachen Entscheidungsprozessen handelt, hat man dieses Ziel weitgehend erreicht. Ein einfaches Schema ist "voll automatisiert, teilweise automatisiert, nicht automatisiert".
Bei Internetunternehmen liegen inzwischen gegenüber den Kunden solche voll automatisierten Geschäftsprozesse vor. Auf andere Weise wäre auch das Geschäftsmodell nicht denkbar.
Voraussetzung für eine Automatisierung ist die oben angesprochene detaillierte Modellierung der Geschäftsprozesse, d.h., sie ist (natürlich) nur möglich bei standardisierbaren Prozessen. Der Unterschied zur Unterstützung im obigen Sinn liegt darin, dass jetzt auch die Entscheidungsvorgänge "in Software gegossen" sind. D.h., um einige einfache Beispiele zu bringen, die Nachbestellung für das Lager wird automatisch durchgeführt, die Kaufempfehlung automatisch generiert (weshalb sie uns oft zum Schmunzeln bringt) und auch der Umgang mit anscheinend zahlungsunwilligen Kunden wird ein ganzes Stück weit durch die Software gesteuert (vgl. hierzu das "Prozessbeispiel" Rechnung in [Staud 2010, Kapitel 13]).
Die Erfassung der durch Software realisierten Geschäftsprozessabschnitte geschieht über die Angabe der Träger der durchgeführten Tätigkeiten. Dort wo üblicherweise eine Organisationseinheit steht, wird dann die Anwendungssoftware vermerkt - ohne (direktes) menschliches Mitwirken.
Betrachtet man z.B. die Geschäftsprozesse eines typischen Internetunternehmens im B2C, ist in wichtigen Abschnitten neben dem Kunden nur noch Software aktiv (Ware anbieten, Vorschläge machen, Auftrag festhalten, (virtuellen) Warenkorb befüllen, usw.). Dieser Bereich reicht weit in die automatisierbaren Abschnitte des Finanzwesens und die Logistik hinein und wird ständig ausgedehnt.
Beim Anforderungsmanagement für die entsprechende Software muss nach einer Standardprozessmodellierung die nächste "tiefere" Modellierungsebene programmnah gewählt werden. Sie wird in diesem Buch programmnahe Prozessmodellierung genannt. Damit soll eine Prozessmodellierung bezeichnet werden, die - z.B. im Rahmen des Requirement Engineerings - unmittelbar der Vorbereitung der Programmierung dient. Vgl. dazu Abschnitt 12.5 in [Staud 2014] sowie [Staud 2010] für die dann einzusetzenden Methoden der UML.
Prozessintegration
Eine weitere wichtige Eigenschaft von Geschäftsprozessen stellt das Ausmaß der Prozessintegration