Auszüge aus dem Text: Geschäftsprozessmanagement - Einführung und Überblick /
(Entwurf, Stand 2017/03)
©2017 Josef L. Staud
Autor: Josef L. Staud
Stand: März 2017
Dieser Text enthält Auszüge aus meinem Buch: Geschäftsprozessmanagement: Einführung und Überblick das 2018 erscheinen wird.
Aufbereitung für's Web
Diese HTML-Seiten wurden mithilfe eines von mir erstellten Programms erzeugt:
WebGenerator (Version 2017-1). Es setzt Texte in HTML-Seiten um und ist noch in
der Entwicklung. Die "maschinelle" Erstellung erlaubt es, nach jeder Änderung des
Textes diesen unmittelbar neu in HTML-Seiten umzusetzen. Da es nicht möglich
(ist, nach jeder Neuerstellung alle Seiten zu prüfen, ist es durchaus möglich, dass
irgendwo auf einer "abgelegenen" Seite Fehler auftreten. Ich bitte dafür um Verzei-
hung und um Hinweise ([email protected]).
Urheberrecht
Dieser Text ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbe-
sondere 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 die-
ses 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, Produkt-
namen, 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
2 0 Vorwort, Inhalt, Abkürzungen
Vorwort, Inhalt, Abkürzungen
Vorwort
Dieses Buch enthält eine Einführung in die Thematik Geschäftsprozessmanagement.
Es soll - sozusagen - das Wesentliche aus Sicht der Wirtschaftsinformatik dargestellt
werden. Darüberhinaus werden zahlreiche Hinweise auf vertiefende Literatur gege-
ben. Eine weitere Besonderheit des Textes ist, dass neben den betriebswirtschaftli-
chen Aspekten auch IT-technische, die der Wirtschaftsinformatik, dargestellt wer-
den. Weitere Besonderheit: Eingehen auf die Wirkungen der Automatisierung der
Geschäftsprozess für das Geschäftsprozessmanagement.
Das Buch wird voraussichtlich 2018 fertig sein und erscheinen.
Die Vorabveröffentlichung dient der Seminarunterstützung.
Prof. Dr. Josef L. Staud
Inhaltsverzeichnis
Vorwort, Inhalt, Abkürzungen 2
1 Prozessgedanke, Prozessorientierung 9
2 Geschäftsprozesse 13
2.1 Herkunft 13
2.2 Grundbegriffe 15
2.3 Definitionen 17
2.4 Art der Problemlösung 24
2.5 Art der Aufgabe 26
2.6 Wichtige Eigenschaften 30
2.7 Komponenten 32
2.8 Modell vs. Instanz 32
2.9 Kern- und Supportprozesse 33
2.10 Steuerungs- und Führungsprozesse 36
2.11 Primäre und sekundäre Geschäftsprozesse 36
2.12 Kreative / wissensintensive Prozesse 36
2.1 Herkunft 3
3 Geschäftsprozessmanagement 39
3.1 Definition 39
3.2 Rollen 44
3.3 Software für Geschäftsprozessmanagement 44
4 Geschäftsprozesse identifizieren und standardisieren 47
4.1 Identifikation 47
4.1.1 Top Down oder Bottom Up 47
4.1.2 Orientierungsrahmen für die Prozessgestaltung 50
4.2 Standardisierung 50
5 Ist- und Sollmodellierung 53
5.1 Istmodellierung 53
5.1.1 Werkzeuge 53
5.1.2 Zweck? 54
5.1.3 Mögliche Schwachstellen 55
5.2 Sollmodellierung 56
5.3 Prozessmodellierung morgen 57
6 Strategisches Geschäftsprozessmanagement 59
6.1 Prozessvision und Prozessziele 60
6.2 Kernkompetenzen 61
6.3 Ergebnisse 62
6.4 Zielsystem 62
6.5 Prozesseffektiviät und -effizienz 64
7 Controlling von Prozessen 67
7.1 Operatives Prozesscontrolling 67
7.2 Strategisches Prozesscontrolling 69
7.3 Kennzahlen 71
8 Reifegrade von Geschäftsprozessen 73
8.1 Einführung 73
8.2 Assessments 73
8.3 Reifegradmodelle 74
4 0 Vorwort, Inhalt, Abkürzungen
8.4 Capability MaturityModel Integration (CMMI) 75
8.5 SPICE/ISO 15504 78
9 Vorgehensmodelle 81
9.1 Nach Becker 81
9.2 Nach Schmelzer/Sesselmann 82
9.3 Nach Österle 82
10 Modelle, Modellierung 85
10.1 Modellierung für Komplexitätsreduzierung 85
10.2 Methoden 86
11 Prozessmodelle, Prozessmodellierung 88
11.1 Ziele der Geschäftsprozessmodellierung 88
11.2 Grundsätze ordnungsgemäßer Modellierung 88
11.3 Programmnahe Prozessmodellierung 89
11.4 Basiselemente einer jeden Prozessmodellierung 89
11.5 Grenzen der Prozessmodellierung 92
12 Methode EPK 93
12.1 Einführung 93
12.2 Elemente 94
12.2.1 Funktionen 94
12.2.2 Ereignisse 95
12.2.3 Organisationseinheiten 96
12.2.4 Informationsobjekte 97
12.2.5 Operatoren und Kontrollfluss 98
12.2.6 Zeitliche Dimension und Zeitverbrauch 100
12.3 Aufbau Ereignisgesteuerter Prozessketten 100
12.3.1 Anfrageprüfung Teil 1 101
12.3.2 Anfrageprüfung Teil 2 102
12.3.3 Anfrageprüfung Teil 3 105
12.3.4 Anfrageprüfung Teil 4 107
12.3.5 Instanzen 110
13 Methode BPMN 115
2.1 Herkunft 5
13.1 Geschäftsprozesse 115
13.2 Einführung durch Beispiele 117
13.2.1 Das erste Business Process Diagram 117
13.2.2 Jetzt mit Daten 119
13.2.3 Handelnde - Träger der Aktivitäten 120
13.2.4 Ein öffentlicher Geschäftsprozess 121
13.2.5 Aufgabentypen 123
13.2.6 Subprozesstypen 125
13.2.7 Ereignisse 126
13.2.8 Gateways 129
14 Vertikale Dimension 131
14.1 Mehrere Aggregationsniveaus 131
14.2 Prozess- vs. Funktionsmodellierung 133
14.3 Prozesslandschaft und -landkarte 133
15 Referenzprozessmodelle 135
15.1 Einführung 135
15.2 Wertkette von Porter 137
15.3 Handels-H von Becker/Meise 139
15.4 Nach Schmelzer/Sesselmann 140
15.5 SCOR-Modell 143
15.6 EFQM - Modell 146
16 IT-Unterstützung 149
16.1 IT-Landschaften, Herkunft 149
16.2 IT-Unterstützung heute / konkret 150
16.3 Automatisierung 154
16.4 Prozessunterstützung 156
16.4.1 Mit ERP-Software 156
16.4.2 Durch Workflow-Systeme 161
16.5 Serviceorientierte Architekturen 163
16.6 Cloud Computing 166
16.7 Ewiges Thema: Integration 167
16.8 Zusammenarbeit 168
6 0 Vorwort, Inhalt, Abkürzungen
17 GPM heute und morgen 171
18 Stichwortverzeichnis 173
19 Literaturverzeichnis 178
2.1 Herkunft 7
Abkürzungsverzeichnis
AD Aktivitätsdiagramm der UML
ARIS Architektur integrierter Informationssysteme
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
IS Informationssystem
IT Eigentlich Informationstechnologie, bzw. information techno-logy. Heute benutzt als Kurzbezeichnung für die gesamte EDV-Ausstattung einer Organisation.
ODER Logischer Operator ODER
RE Requirements Engineering (Anforderungsmanagement)
SPM Standardprozessmodellierung
UND Logischer Operator UND
VKD Vorgangskettendiagramm
vs. versus (im Vergleich zu, im Gegensatz zu)
WSK Wertschöpfungsketten
XODER Logischer Operator EXKLUSIVES ODER
1 Prozessgedanke, Prozessorientierung
Es ist nun schon einige Jahre her, dass der Prozessgedanke in die unternehmerische
Wirklichkeit und in die wissenschaftliche Diskussion Einzug gehalten. Man kann
den Anfang in die 1970er-Jahre positionieren. Seitdem hat er immer mehr Bedeu-
tung gewonnen und heute ist er aus der organisationellen Wirklichkeit und der theo-
retischen Diskussion nicht mehr wegzudenken. Um es mit Gaitanides zu sagen: In
der Praxis ist das Prozessmanagement mittlerweile "zum dominanten Paradigma der
Reorganisation geworden." [Gaitanides 2012, S. 6]
Der Prozessgedanke diente auch als Grundlage eines sehr erfolgreichen Software-
typs, der integrierten prozessorientierten Software, heute meist ERP-Software ge-
nannt.
Zu Beginn dieser Entwicklung hin zur Prozessorientierung in den 1970-er Jahren
(vgl. die frühen Arbeiten von Mertens und Scheer) ging es darum, die alten, auf
Stellen/Funktionen fixierten Vorstellungen zu überwinden und das Prozessdenken
zu etablieren. Dies gelang nach und nach. Schwerpunkt waren dabei einzelne Ge-
schäftsprozesse und ihre Defizite. Der Weg war die einfache Optimierung, von den
Istprozessen zu optimierten Sollprozessen, oftmals verbunden mit der Einführung
einer ERP-Software. Treiber dieser Entwicklung war die Notwendigkeit, die Wert-
schöpfung zu erhalten bzw. zu steigern, also mehr Effektivität und mehr Effizienz zu
erzielen.
Dieser Treiber zeigte weiterhin Wirkung und trieb die unternehmerische Wirk-
lichkeit und die Theoriediskussion voran. Es folgte die Betrachtung der Geschäfts-
prozesse als Ganzes, die sog. Prozesslandschaften rückten ins Blickfeld und die
Analyse der Geschäftsprozesse wurde vertieft. Reifegrade, Risiken, Controlling usw.
von Geschäftsprozessen wurden und werden betrachtet und BWL sowie Wirt-
schaftsinformatik antworteten auf diese Thematik durch ausführliche Erarbeitungen
von Methoden und Ansätzen um die Gesamtheit der Prozesse zu optimieren.
Parallel zu obiger Entwicklung gab es eine IT-technische, die auch permanent an-
hält, angetrieben durch denselben Wunsch nach Sicherung und Steigerung der Wert-
schöpfung: Die Unterstützung der Prozessabwicklung durch Software. Dies war von
Anfang an so, allerdings wurden zu Beginn nur einzelne Tätigkeiten durch die IT1
unterstützt. Nach und nach wurde dieser Anteil immer größer, unterstützt durch eine
immer detailliertere Erfassung der Geschäftsprozesse. Die entsprechende Software,
ERP-Software, deckte von ''Version zu Version" mehr ab von den Geschäftsprozes-
sen, der Detaillierungsgrad der in die Software umgesetzten Geschäftsprozesse wur-
de ständig erhöht.
Immer mehr Unterstützung bzw. Realisierung der Geschäftsprozesse durch die
IT, was bedeutet, dass Programme teilweise die Prozessabwicklung übernehmen. Da
war es nicht mehr weit bis zur vollständigen Automatisierung, wie wir sie seit eini-
1 Eigentlich Informationstechnologie, bzw. information technology. Heute benutzt als Kurzbezeich-
nung für die gesamte EDV-Ausstattung einer Organisation.
10 1 Prozessgedanke, Prozessorientierung
gen Jahren erleben. Ganz aktuell wird diese weit vorangetrieben (in den klassischen
Unternehmen) oder weitgehend erreicht (bei den Internet-Unternehmen).
Für den Erfolg einer Organisation ist - neben vielem anderen - die optimale Ge-
staltung der Geschäftsprozesse wichtig. Das beste Geschäftsmodell und die intelli-
genteste Geschäftsstrategie nützen wenig, wenn die Geschäftsprozesse nicht leis-
tungsstark gestaltet sind. Nur dann kann das Ziel, die Kundenwünsche so zu
erfüllen, dass die eigene Wertschöpfung realisiert wird, erreicht werden. Die Opti-
mierung der Geschäftsprozesse hinsichtlich Effektivität und Effizienz ist Gegen-
stand des Geschäftsprozessmanagements (GPM) oder Business Process Manage-
ments (BPM). Die beiden Begriffe werden hier synonym benutzt. Hier sind
thematisch alle Aktivitäten zusammengefasst, die dem Ziel der optimalen Gestaltung
der Geschäftsprozesse dienen.
Dass diese Thematik von hoher Aktualität ist, zeigen auch aktuelle Erhebungen.
So nannten in der Studie IT-Kompass 20162 59% der Befragten an erster Stelle die
Optimierung der Geschäftsprozesse als ein Thema, das sie beschäftigt [Herrmann
2016, S. 24].
Organisation vs. Unternehmen
Üblicherweise denkt man, wenn man von Geschäftsprozessen spricht, an Unterneh-
men 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) Gesundheitswe-
sen, politische Institutionen, usw.) erbringen ihre Leistung durch Geschäftsprozesse.
Da aber nun mal Wertschöpfung normalerweise nur in wirtschaftllich handelnden
Organisationen - sprich Unternehmen - stattfindet, wird hier von Unternehmen die
Rede sein, wenn es um den Ort geht, wo versucht wird, Wertschöpfung zu realisie-
ren. 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.
Somit gilt: Wo immer es sinnvoll ist, wird von Organisationen als Anwendungs-
bereich (Gegenstand der Ausführungen) gesprochen. Wo es um nach Wertschöpfung
zielende Organisationen geht, von Unternehmen.
Einbettung
Geschäftsprozessmanagement ist Teil des Managements einer Organisation. Wichti-
ge benachbarte Managementbereiche sind IT-Management und strategisches Mana-
gement (vgl. die folgende Abbildung). Von besonderem Interesse sind auch die
Überschneidungsbereiche. Geschäftsprozessmanagement und IT-Management (A)
haben zahlreiche Berührungspunkte mit einer durch immer mehr IT-Unterstützung
und Automatisierung dynamischen aktuellen Entwicklung. Strategisches Manage-
ment und IT-Management (B) leisten einen wichtigen Beitrag zur IT-technischen
strategischen Ausrichtung des Unternehmens, Geschäftsprozessmanagement und
strategisches Management (C) definieren das strategische Geschäftsprozessmana-
gement. Im Überschneidungsbereich aller drei Managementgebiete (D) finden sich
strategische Aufgaben des Geschäftsprozessmanagements mit IT-Bezug, z.B. die
2 Erstellt von IDC und der Computerwoche. Datenerhebung November und Dezember 2015 bei "IT-
und Business-Entscheidern" aus 364 Unternehmen. Der Anteil der "Business-Entscheider" lag bei
41%.
2.1 Herkunft 11
Klärung der Frage, welche Geschäftsprozesse langfristig in "die Cloud" verlagert
werden können. Vgl. auch die folgende Abbildung.
Abbildung 2.1-1: Geschäftsprozessmanagement und Nachbargebiete
2 Geschäftsprozesse
2.1 Herkunft
Der Prozessgedanke ist heute absolut dominant in der Wahrnehmung der Organisa-
tionswirklichkeit. Wie kam es dazu? Wie war die Betrachtung des betrieblichen
Geschehens / der Geschäftstätigkeit vor dem Aufkommen des Prozessgedankens?
Denn natürlich gab es da auch schon Geschäftsprozesse.
Ganz am Anfang war Frederick Taylor, der den Taylorismus begründete. Er be-
schreibt die Aufteilung der im Unternehmen anfallenden Aufgaben nach funktiona-
len Kriterien. Diese Form der Aufgabenteilung prägt bis heute die Gestaltung der
Aufbauorganisation vieler Organisationen. Dabei werden gleichartige Aufgaben in
Stellen zusammengefasst, die wiederum in unterschiedlichen Abteilungen organi-
siert sind. Im Mittelpunkt standen also Stellen und Abteilungen, betriebliche Abläufe
wurden nur selten strukturiert geplant und modelliert.
Die folgende Abbildung illustriert dies am Beispiel eines Industrieunternehmens
mit einer sog. Managementpyramide. Hier ist (senkrecht) die Aufteilung in typische
Funktionsbereiche angedeutet und gleich auch noch - weil wir das später benötigen -
(waagrecht) eine Einteilung nach der Art der unterstützten Managementaufgabe. Die
Abbildung fokussiert auf Industrieunterehmen. Natürlich ist sie aber auch auf jeden
anderen Wirtschaftsbereich anwendbar.
Diese Managementpyramide ist schon sehr früh in der Organisationslehre präsent.
Vgl. die frühen Ausgaben der Standardwerke von Mertens und Scheer (18. Auflage:
[Mertens 2013] und (7. Auflage: [Scheer 1997]). Mit ihr wird die typische Auftei-
lung in Funktionsbereiche angedeutet und zusätzlich die Aufteilung nach unter-
schiedlichen Managementaufgaben (vgl. die Abschnitte 2.4, 2.5). Die Pyramiden-
form kommt daher, weil "von unten nach oben" Informationen immer verdichteter
werden und weil typischerweise die Anzahl der mit der jeweiligen Aufgabe befass-
ten Personen immer mehr abnimmt.
Ein früher Hinweis auf die prozessartige Struktur des betrieblichen Geschehens
gab Nordsieck [Nordsieck 1932, 1934], der schon in den 1930-er Jahren ein pro-
zessorientierte Verständnis einer Organisation formulierte: „Der Betrieb ist in Wirk-
lichkeit ein fortwährender Prozess, eine ununterbrochene Leistungskette“
[Nordsieck 1932, S.77]. Dies erlangte damals aber keine Wirkung.
Vertreter, die dem Objekt des betrieblichen Prozesses Aufmerksamkeit haben zu-
kommen lassen finden sich dann auch in der frühen Organisationslehre (vgl. [Kosiol
1970]). Allerdings nur in der theoretischen Diskussion, nicht in der Praxis.
Von Stellen und ihren Aufgaben zu Prozessen
Dies war so in den Anfangsjahren der Organisationslehre und bis in die 1960-er
Jahre hinein. Die Optimierungsbemühungen konzentrierten sich auf einzelne Tätig-
keiten, ihre Stelleninhaber und die Einbettung der Tätigkeiten in die Abläufe. Da-
nach kam der Geschäftsprozessgedanke auf. Mit dem Konzept des Geschäftsprozes-
14 2 Geschäftsprozesse
ses veränderte sich die Perspektive. Jetzt standen längere zusammenhängende Fol-
gen von Tätigkeiten, die zur Erledigung einer größeren Aufgabe nötig sind, im Mit-
telpunkt 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 Unter-
nehmen effektiver und effizienter zu gestalten, starten mit einer Analyse der Ge-
schäftsprozesse und deren Optimierung.
In der folgenden Abbildung sind Geschäftsprozesse durch gestrichelte Pfeillinien
angedeutet. Betrachten wir zuerst die waagrechte. Hier soll die Linienführung auch
darauf hinweisen, dass die Überwindung der Abteilungsgrenzen einer der starken
Impulse in Richtung Proezssorientierung war. Während jede funktionsorientierte
Betrachtung sich automatisch an den Abteilungsgrenzen orientiert, sollte dies beim
Prozessgedanken nicht mehr der Fall sein.
Solche waagrechten Linien, die Prozesse darstellen, hätte man natürlich auch in
den Ebenen darüber einzeichnen können. Auch dort werden Geschäftsprozesse reali-
siert.
Die senkrechte gestrichelte Linie weist darauf hin, dass es natürlich auch Ge-
schäftsprozesse über die Ebenen der Managementaufgaben hinweg gibt. Diese sind,
wenn der Prozess "von unten nach oben" verläuft, oft mit Daten verbunden, die
entlang des Prozesses weitergereicht und verarbeitet werden.
Abbildung 2.1-1: Schnittstellen in die Außenwelt und ihre Bewältigung durch die
Prozessmodellierung. Quelle: Aufbauend auf [Scheer 1997, S. 5).
2.2 Grundbegriffe 15
2.2 Grundbegriffe
Das Geschäftsprozessmanagement, wie wir es heute kennen, baut auf den Vorarbei-
ten der Organisationslehre auf. In diesem Abschnitt werden einige Begriffe erläutert,
die für die weiteren Ausführungen unabdingbar sind.
Kunden werden in Geschäftsprozessen in zwei Gruppen unterteilt: in externe und
interne Kunden. Externe Kunden sind die tatsächlichen oder potenziellen Abnehmer
der angebotenen Leistungen. In vielen Fällen handelt es sich dabei um Endkunden,
welche die Produkte oder Dienstleistungen selbst nutzen bzw. anwenden, wie bei
Haushaltsgeräten, PCs oder Automobilen. Interne Kunden stammen aus dem eige-
nen Unternehmen, sie werden auch unternehmensinterne Auftraggeber (Stahlknecht
und Hasenkamp 2005, S. 206) genannt. Z.B. hat die IT einer Organisation die übri-
gen Beschäftigten als interne Kunden.
Geschäftsprozesse haben statische Elemente z.B. die benutzten Datenbestände3 und
dynamische. Letztere sind die Tätigkeiten, die in Geschäftsprozessen erledigt wer-
den. Sie werden Aufgaben oder auch Funktionen genannt. Geschäftsprozesse beste-
hen - sehr vereinfacht ausgedrückt - aus solchen zielgerichteten aneinandergereihten
Tätigkeiten, aus Tätigkeitsfolgen also. Diese Unterscheidung ist prägend für die
Betrachtung der Unternehmensrealität. So gibt es typischerweise ein Datenmodell
(oder mehrere) und ein Prozessmodell und die evtl. gekaufte ERP-Software beruht
wesentlich auf einer Datenbank und einer Prozesssoftware, jeweils mit zugrundelie-
genden Modellüberlegungen.
Detaillierungsebenen, Aggregationsniveaus
Eine wichtige Eigenschaft von Aufgaben ist, dass sie auf unterschiedlichen Detaillie-
rungsebenen betrachtet werden können. Man kann sie zusammenpacken (aggregie-
ren) oder auch detaillieren. Und dies auf mehreren Stufen, u.U. bis zu der Ebene, wo
sich der gesamte Unternehmenszweck in einer einzigen Aufgabe findet (z.B. „Wert-
schöpfung erzielen“). Im Geschäftsprozesskontext stellen die sog. Elementaraufga-
ben die unterste Ebene dar, die Bullinger/Fähnrich als
„... entweder nicht weiter zerlegbare oder auf der betreffenden Beschreibungs-
ebene nicht weiter zerlegte Aufgaben“
bezeichnen [Bullinger und Fähnrich 1997, S. 41]. Mehrere solche Elementaraufga-
ben 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):
Eine Aufgabe ist eine betriebliche Funktion mit einem bestimmbaren
Ergebnis. Sie wird von Menschen und/oder Maschinen ausgeführt.
Jede Aufgabe, z.B. eine Angebotserstellung, kann noch weiter zerlegt werden, z.B.
in aktuelle Preise ermitteln, Arbeitsschritte klären, Auftragspositionen kalkulieren,
usw. Dies kann man bis auf die tayloristische Ebene treiben, wo es dann um Hand-
habungen geht. Soll die Prozessbeschreibung in das Anforderungsmanagement der
Entwicklung einer prozessorientierten Software einfließen, kann bei den durch die
3 "Statisch" meint hier nicht, dass sich die Daten nicht verändern, das tun die natürlich. Es meint hier,
dass die Struktur der Daten (das Datenmodell) normalerweise im Zeitablauf einigermaßen stabil ist.
Externe Kunden,
interne Kunden
Statische und
dynamische Elemente
16 2 Geschäftsprozesse
IT realisierten Abschnitten noch weiter zerlegt werden, bis auf die Konstrukte, die
für die Programmierung gebraucht werden. Dies wird als Detaillierung bezeichnet.
Vorgänge
Der erste Schritt von einzelnen Aufgaben zu einer sequenziellen Folge von Aufga-
ben wird mit der Definition von Vorgängen gemacht. Mit Bullinger/Fähnrich sind
Vorgänge
„Abfolgen von Tätigkeiten, die zur Realisierung von Aufgaben ausge-
führt werden.“ [Bullinger und Fähnrich 1997, S. 19)
Ganz ähnlich Scheer, der einen betriebswirtschaftlichen Vorgang wie folgt definiert:
„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]
Workflow
Standardisierbare Vorgänge (vgl. Kapitel 6) in Unternehmen werden auch als
Workflow bezeichnet. Sie lassen sich mit [Bullinger und Fähnrich 1997, S. 19] auf
der Basis der obigen Ausführungen mit vier Kategorien beschreiben:
Ereignisflüsse steuern die Aktivierung von Aufgaben in Abhängigkeit von auf-
tretenden Ereignissen. Sie bewirken damit Zustandsänderungen im Geschäfts-
prozess.
Daten- bzw. Objektflüsse modellieren Eingangsinformationen oder -objekte, die
zur Aufgabenausführung benötigt werden. Weiterhin modellieren sie die Ver-
wendung der Resultate in nachfolgenden Aufgaben.
Aufgabenträger repräsentieren Stellen einer Organisation und bearbeiten Auf-
gaben.
Ressourcen sind Materialien oder Betriebsmittel, die zur Aufgabenausführung
benötigt werden. Dies können auch Aufgabenträger sein.
Funktion
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 ermit-
teln")." [Mertens 2013, S. 41]
Mit Objekten sind hier betriebswirtschaftlich relevante Objekte bzw. Geschäftsob-
jekte (Business Objects) gemeint. Dieser Objektbegriff stimmt weitgehend (bei den
meisten Autoren allerdings unausgesprochen bzw. unbewusst) mit dem allgemeinen
Definition
2.3 Definitionen 17
Objektbegriff der objektorientierten Analyse ü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.
2.3 Definitionen
Doch nun zur Definition von Geschäftsprozessen. In der Literatur wird der Begriff
intensiv diskutiert (vgl. beispielhaft [Keller und Teufel 1997, S. 153ff], [Hess 1996,
S. 9ff], [Becker und Vossen 1996], [Rump 1999, S. 18f], [Staud 2001/2006/2014]
und die dort angegebenen weiteren Verweise und die folgenden Zitate). Einige
wichtige Definitionen werden wir hier betrachten. Dabei wird auch deutlich, dass
die Autoren den Gegenstand unter verschiedenen Blickwinkeln betrachten, die auch
im weiteren Verlauf von Bedeutung sind.
Die meisten Autoren bauen, direkt oder indirekt, auf dem wegweisenden Buch
von Davenport auf [Davenport 1993]. Für ihn ist ein Prozess eine zeitlich und räum-
lich strukturierte Menge von Aktivitäten mit einem Anfang und einem Ende sowie
klar definierten Inputs und Outputs. Zusammenfassend formuliert er kurz und
knapp: „A structure for action." ([Davenport 1993, S. 5], zitiert nach [Gaitanides
2012, S. 54f])
Hammer und Champy, die Begründer der Reengineering-Tradition, definieren ei-
nen Geschäftsprozess "... als Bündel von Aktivitäten, für das ein oder mehrere un-
terschiedliche Inputs benötigt werden und das für den Kunden ein Ergebnis von
Wert erzeugt.“ [Hammer und Champy 1995, S. 52]
Hess definiert, ausgehend von einer systemorientierten Organisationslehre und
der Zerlegung einer Organisation in die Subsysteme Aufbauorganisation4, Ablaufor-
ganisation5 und Informationssystem einen Prozess
... als ein Subsystem der Ablauforganisation, dessen Elemente Aufga-
ben, Aufgabenträger und Sachmittel und dessen Beziehungen die Ab-
laufbeziehungen zwischen diesen Elementen sind. [Hess 1996, S. 13]
und gibt damit auch einen deutlichen Hinweis auf den Kontrollfluss. In seiner um-
fassenden Darstellung zahlreicher Methoden des Business Reengineering gibt er bei
fast jeder die jeweils benutzte Prozessdefinition an. Eine Übersicht findet sich in
[Hess und Brecht 1996]. Hier finden sich auch zahlreiche Hinweise auf die bei den
Beratungsunternehmen benutzten Begriffe und Definitionen.
4 Mit Aufbauorganisation ist die Zerlegung der Gesamtaufgabe einer Organisation in Teilaufgaben
angesprochen. Die Zerlegung muss so erfolgen, dass ein effektives Zusammenwirken bei der Ab-
wicklung konkreter Geschäftsprozesse möglich ist. Mit diesem Begriff bezeichnet man die entste-hende Organisationsstruktur als solche wie auch die Tätigkeit des Organisierens selbst: „Erste Auf-
gabe der Aufbauorganisation (wenn wir sie als Tätigkeit des Organisierens verstehen) ist also die
Analyse und Zerlegung der Gesamtaufgabe des Betriebes (Aufgabenanalyse). Die zweite Aufgabe besteht dann darin, die Einzelaufgaben zusammenzufassen, indem „Stellen“ gebildet werden (Aufga-
bensynthese), wobei sich aus der Aufgabenstellung Beziehungszusammenhänge zwischen diesen
Stellen ergeben“ [Wöhe 1993, S. 183].
5 "Unter Ablauforganisation versteht man die Gestaltung von Arbeitsprozessen. ... Man unterscheidet
(1) die Ordnung des Arbeitsinhalts, (2) die Ordnung der Arbeitszeit, (3) die Ordnung des Arbeits-
raumes, (4) die Arbeitszuordnung“ [Wöhe 1993, S. 196].
18 2 Geschäftsprozesse
Zahlreiche Definitionen zu Geschäftsprozessen führt auch [Rump 1999, S. 18f]
an. Er selbst definiert, bezugnehmend auf die Unternehmensziele, wie folgt:
Ein Geschäftsprozess ist eine zeitlich und sachlogisch abhängige
Menge von Unternehmensaktivitäten, die ein bestimmtes, unterneh-
mensrelevantes Ziel verfolgen und zur Bearbeitung auf Unterneh-
mensressourcen zurückgreifen. [Rump 1999, S. 19]
Keller und Teufel berücksichtigen neben den externen auch die internen Kunden.
Für sie ...
... beschreibt ein Geschäftsprozess alle Aktivitäten, mit deren Durch-
führung eine angestrebte Leistung bzw. Soll-Leistung durch Aufga-
benträger erstellt wird, die an externe Kunden (Hauptprozesse) oder
interne Kunden (Serviceprozesse) übergeben wird und für diesen ei-
nen Wert darstellt. [Keller und Teufel 1997, S. 153]
Sie weisen damit auf die Unterscheidung von externen und internen Kunden hin und
führen auch gleich die Unterscheidung von Haupt- und Serviceprozessen ein.
Scheer stellt die zu erbringende Leistung in den Vordergrund und definiert wie
folgt:
Ein Geschäftsprozess ist "... eine zusammengehörende Abfolge von
Unternehmungsverrichtungen zum Zweck einer Leistungserstellung.
Ausgang und Ergebnis des Geschäftsprozesses ist eine Leistung, die
von einem internen oder externen .Kunden" angefordert und abge-
nommen wird." [Scheer 1998, S. 3f]
Mertens definiert, aufbauend auf seinem oben eingeführten Funktionsbegriff, Pro-
zesse als eine Abfolge von Funktionen mit definierten Anfangs- und Endpunkten:
Eng verwandt mit dem Begriff Funktion ist der Begriff Prozess. Ein
Prozess entsteht aus einer Folge von einzelnen Funktionen (Funkti-
onsablauf) und weist einen definierten Anfangspunkt (Auslöser des
Prozesses) sowie Endpunkt (Endzustand) auf. [Mertens 2013, S43]
Ganz ähnlich Becker und Vossen. Sie definieren einen Geschäftsprozess als
... die inhaltlich abgeschlossene zeitliche und sachlogische Abfolge
von Funktionen, die zur Bearbeitung eines betriebswirtschaftlich rele-
vanten Objekts notwendig sind. [Becker und Vossen 1996, S. 19]
Der Objektbegriff deckt sich mit dem, was auch Geschäftsobjekt genannt wird. Al-
lerdings gehen diese Autoren von einem einzelnen (betriebswirtschaftlich relevan-
ten) Objekt aus, das den Prozess prägt.
Einige weitere Aspekte betont Gadatsch:
Ein Prozess ist eine sich regelmäßig wiederholende Tätigkeit mit ei-
nem definierten Beginn und Ende. Er verarbeitet Informationen (In-
put) zu zielführenden Ergebnissen (Output) und ist in der Regel ar-
beitsteilig organisiert. Er kann manuell, teilautomatisiert oder
vollautomatisiert ausgeführt werden. [Gadatsch 2015, Pos. 139]
Definition
Definition
Mertens
Definition
Becker/Vossen
Definition
2.3 Definitionen 19
Bezüglich der Regelmäßigkeit ist das "Gegenstück" ein Projekt, welches in seiner
spezifischen Ausprägung nur einmal stattfindet.
Einige Autoren unterscheiden zwischen Prozess und Geschäftsprozess (vgl. z.B.
[Becker und Vossen 1996, S. 18f], [Schmelzer und Sesselmann 2013]). Schmel-
zer/Sesselmann verstehen dann unter einem Prozess, unter Berufung auf ISO
9000:2005, eine Folge von Aktivitäten,
"... die aus definierten Inputs definierte Outputs erzeugen" [Schmelzer
und Sesselmann 2013, S. 51]
Dies lässt, so die Autoren, "Ziel, Anstoß, Reichweite, Inhalt, Struktur sowie Ergeb-
nisse und Empfänger der Ergebnisse des Prozesses offen" [ebenda].
Deshalb definieren sie Geschäftsprozesse als Prozesse, die diesbezüglich näher
festgelegt sind. Für die Eingabe setzen sie die Anforderungen von Kunden, die Ak-
tivitäten werden als wertschöpfende Aktivitäten spezifiziert und das Ergebnis wird
als Leistungen für Kunden definiert. Damit definieren sie Geschäftsprozesse als
... wertschöpfende Aktivitäten, die von Kunden erwartete Leistungen
erzeugen und die aus der Geschäftsstrategie und den Geschäftszielen
abgeleiteten Prozessziele erfüllen. [Schmelzer und Sesselmann 2013,
S. 51]
Definiert man so, kann man zu Aussagen kommen wie:
"Nicht wertschöpfende Aktivitäten stellen Verschwendung dar. Ziel
von Geschäftsprozessen ist es, alle Aktivitäten zu eliminieren, die aus
dem Blickwinkel der Kunden keinen Nutzen und Wert haben." [eben-
da, S. 53]
und
"Geschäftsprozesse beginnen und enden bei Kunden" [ebenda]
Dies ist eine sehr spezifische Sicht, die bei der Lektüre der entsprechenden Fachlite-
ratur bedacht werden muss.
Für Gaitanides besteht ein Prozess aus einer
"Abfolge voranschreitender Aktivitäten, d.h. Arbeitsschritten bzw.
Transformationen materieller oder immaterieller Art innerhalb einer
Organisation", die von Ereignissen ausgelöst und beendet werden und
die für den Adressaten ein Ergebnis von Wert darstellen [Gaitanides
2012, S. 4].
Er gibt weitere wichtige Hinweise, indem er auf den Routineaspekt von Geschäfts-
prozessen hinweist [ebenda, S. 5] und betont, dass Geschäftsprozesse sich nicht
durch individuelle, sondern durch kollektive Könnerschaft auszeichnen (S. 5).
Er weist im Übrigen auch darauf hin, dass sich die Autoren dieses Themengebie-
tes in zwei Gruppen aufteilen lassen. Die an Hammer/Champy anknüpfende
"Reengineeringtradition", deren Hauptschwachpunkt, "die Bezugnahme auf den
erfolgreichen Einzelfall" er auch gleich mitanführt [Gaitanaides 2012, S. 6] und die
Vertreter des Engineering-Ansatzes, die durch ihre ingenieurwissenschaftliche
Herangehensweise geprägt sind. Bei diesen vermutet er ein "mechanistisches Orga-
nisationsverständnis". [ebenda, S. 7]
20 2 Geschäftsprozesse
Er selbst betont, dass Prozesse "soziale Konstruktionen und subjektive Modelle
zugleich" sind [ebenda]. Damit ist für ihn Prozessorganisation "nicht ein an einer
Rezeptur oder an einem Referenzmodell festzumachendes organisatorisches Design,
sondern eine kollektiv erzeugte und mithin sozial konstruierte Realität." [ebenda].
Damit sind alle wichtigen Definitionsmerkmale von Geschäftsprozessen genannt,
Fassen wir, aufbauend auf der Liste von [Staud 2014, S. 10], zusammen:
(Ziel)
Geschäftsprozesse haben ein Ziel (oder auch mehrere), das sich aus den Unter-
nehmenszielen ableitet.
Das globale Ziel ist die Herbeiführung einer Wertschöpfung (bei Unternehmen)
bzw. die möglichst effektive und effiziente Aufgabenerledigung (bei sonstigen
Organisationen).
(Umsetzung der Ziele)
Zur Erreichung der Ziele werden u.a. betriebswirtschaftliche Objekte (Ge-
schäftsobjekte) bearbeitet. Entweder direkt oder über digitale Repräsentationen.
Geschäftsprozesse benötigen zu ihrer Realisierung Informationsträger aller Art.
Sie nutzen für die Erfüllung der Aufgaben Unternehmensressourcen.
(Aufbau)
Die Gesamtaufgabe eines Geschäftsprozesses kann in Teilaufgaben zerlegt
werden (im Extremfall kann ein Geschäftsprozess auch aus nur einer Aufgabe
bestehen).
Geschäftsprozesse bestehen aus dem strukturierten Ausführen von Aufgaben
entlang eines Kontrollflusses, mit einem Anfang und einem Ende.
Sie sind durch Ereignisse strukturiert, zu Beginn, am Ende und zwischendurch.
Sie haben klar definierte Inputs und Outputs.
Die Aufgaben werden von Aufgabenträgern wahrgenommen, die Inhaber von
Stellen sind, die wiederum in Organisationseinheiten gruppiert sind.
(Art der Erledigung)
Die Aufgaben werden entweder manuell, teil-automatisiert oder automatisiert
erfüllt. Der Trend geht in Richtung einer immer größeren Automatisierung.
(Eigenschaften)
Ein Geschäftsprozess liegt oft quer zur klassischen Aufbauorganisation, d.h. er
tangiert u.U. mehrere Abteilungen.
Geschäftsprozesse "bedienen" interne und externe Kunden. Diese fordern die zu
erbringende Leistung an.
Viele Geschäftsprozesse bestehen aus sich regelmäßig wiederholenden Tätig-
keiten.
Geschäftsprozesse sind auch soziale Konstruktionen. Menschen wirken in ihnen
zusammen.
(IT-Unterstützung)
Geschäftsprozesse werden durch die IT der Organisation unterstützt. Der Trend
geht hier in eine immer umfassendere Unterstützung.
2.3 Definitionen 21
Fasst man dies zusammen und ergänzt es um eigene Erfahrungen, kommt man zur
folgenden Definition von Geschäftsprozessen, die wir hier zugrunde legen:
Ein Geschäftsprozess besteht aus einer zusammenhängenden, abge-
schlossenen Folge von Tätigkeiten, die zur Erfüllung eines Organisa-
tionsziels 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.
Geschäftsprozesse leisten somit die Transformation von beschafften Produktionsfak-
toren in verkaufte Produkte bzw. Dienstleistungen (vgl. für diesen produktionstheo-
retischen Ansatz Porter 1992a,b). In ihrem Zusammenhang beschreiben die Ge-
schäftsprozesse die Wertschöpfungskette des Unternehmens.
Kontrollfluss, Sequenzfluss
Oben wurde ausgeführt, dass Geschäftsprozesse aus dem strukturierten Ausführen
von Aufgaben bestehen. Die dabei entstehenden Abfolgen werden Kontrollfluss
genannt. Er regelt, wie die Aufgaben aufeinder folgen, wie verzweigt wird, welche
Ergebnisse erzielt werden sollen, usw. Die Basis dafür sind Regeln:
"Regeln bilden die Grundlage für das Gestalten von Prozessen und da-
rüber hinaus für prozesskonformes Handeln. Prozesse verwirklichen
sich als regelgeleitete Aktivitäten" [Gaitanides 2012, S. 3).
Die BPMN-Autoren haben dafür den Begriff Sequenzfluss gewählt. Mehr zum Kon-
zept des Kontrollflusses findet sich in Abschnitt xxx.
Sequenzielle Struktur
Die Nutzung des Begriffs Geschäftsprozess geht damit von der Vorstellung einer
sequenziellen Struktur der Abläufe in Unternehmen aus (so auch Mischak 1997, S.
5 und - unausgesprochen - die meisten einschlägigen Autoren). Aber nicht nur.
Wesentlich ist auch die oben angesprochene abgeschlossene Folge von Tätigkeiten,
also nicht das Schreiben des Angebots, die Erstellung der Kalkulation oder die Klä-
rung offener Fragen mit dem Kunden, sondern z.B. die Angebotserstellung als Gan-
zes, weil dadurch die damit verbundene neue Sichtweise auf das Unternehmensge-
schehen verdeutlicht wird.
Die sequentielle Grundstruktur liegt allerdings nicht immer vor. Es gibt Ge-
schäftsprozesse, denen diese Eigenschaft fehlt oder bei denen man diese nicht erhe-
ben will. Z.B. kreative Prozesse. Vgl. dazu xxx.
Ereigniskonzept
Oben in der Liste der Eigenschaften wurde es schon deutlich: Ereignisse sind ein
wichtiges Element von Geschäftsprozessen. Sie steuern sozusagen den konkreten
Ablauf ("Auftrag annehmen/ablehnen"). Es herrscht auch Einigkeit darüber, dass
Geschäftsprozesse durch ein auslösendes Ereignis, wie z.B. einen erteilten Kunden-
auftrag, ausgelöst werden (Startereignis) und auch durch Ereignisse beendet werden
("Auftrag ausgeliefert"). Zwischendurch regeln Ereignisse den konkreten Fortgang,
z.B. bei der Prüfung einer Machbarkeit ("geht / geht nicht").
22 2 Geschäftsprozesse
Hier erkennen wir den Grund, weshalb Ereignisse / das Ereigniskonzept eine so
große Rolle spielen bei der Betrachtung, Analyse und Modellierung von Geschäfts-
prozessen. Eigenschaften sind nun mal bei zentraler Bestandteil von Aktivitäten
(menschlichen oder softwaregestützten) und müssen deshalb hier mit betrachtet
werden.
Routine, Standardisierbarkeit
Wir kennen es aus unserer beruflichen Erfahrung. Viele Geschäftsprozesse werden
als Routine empfunden. Sie wiederholen sich und stellen jedesmal dieselben Aufga-
ben. Sie sind manchmal lästig, wenn man sie zu oft abwickeln muss, manchmal aber
auch wohltuend, weil sie in der Regel wohlstrukturiert und beherrschbar sind. Sol-
che Geschäftsprozesse sind standardisierbar (vgl. xxx) und können auch durch die
IT unterstützt oder sogar vollautomatisch abgewickelt werden. Die anderen Prozes-
se, die "chaotischen" / kreativen (vgl. xxx) entziehen sich dieser Erfassung und Um-
setzung.
Kundenorientierung
Ein weiterer Aspekt verdient besondere Beachtung. Geschäftsprozesse sollen sich,
so wird gefordert, an den Kundenwünschen orientieren. Direkt (bei den Kernprozes-
sen) oder indirekt (bei zulieferenden Prozessen oder Supportprozessen). Dies ist erst
mal vernünftig, muss aber hinterfragt werden. Vgl. dazu Abschnitt xxx ("Potentielle
Kunden)").
Überwindung von Organisationsgrenzen
Geschäftsprozesse wurden bewusst so gesehen, dass sie die Grenzen organisatori-
scher Einheiten überschreiten. Das war einer der Motivationsfaktoren bei der Ent-
wicklung des Prozessgedankens: Die Organisationsbrüche (Probleme bei der Ab-
wicklung der Geschäftsprozesse an Abteilungsgrenzen) sollten überwunden werden.
Trotzdem gibt es in den meisten Organisationen weiterhin eine Aufbauorganisation
und diese hat ja weiterhin ihre Berechtigung. Zurückgefahren auf wenige Reste
(Zentralsekretariat, Personalwesen, ...) ist die Aufbauorganisation lediglich in Un-
ternehmen mit einer ausgeprägten Projektorganisation.
Aufgabenträger
Träger der durchzuführenden Aufgaben waren zu Beginn der Zeit intensiverer Pro-
zessbetrachtungen (1970-er Jahre) Personen auf Stellen und in Abteilungen. Das
blieb so und wurde so auch in Prozessmodellen erfasst. Nach und nach ergab es sich
aber, dass immer öfter Programme einzelne Aufgaben abwickelten, die Geschäfts-
prozesse also durch "die IT unterstützt" wurden, wie man dann sagte. Später wurden
dann viele und immer mehr Prozesse voll automatisiert (vollkommen durch Pro-
gramme realisiert)6, z.B. bei den Internet-Unternehmen. Dies muss, will man die
aktuelle Situation des Geschäftsprozessmanagements betrachten, berücksichtigt
werden.
6 Vgl. zur Automatisierung auch xxx
2.3 Definitionen 23
Subjektivität 1 - Detaillierungsgrad
Es gibt subjektive Faktoren bei der Erfassung und später auch bei der Modellierung
von Geschäftsprozessen. Der erste betrifft die Zerlegung der Gesamtaufgabe ("An-
gebot erstellen") in Teilaufgaben. Durch diese entsteht Subjektivität - es kann mehr
oder weniger zusammengefasst bzw. zerlegt werden werden. Ausgehend von
tayloristischen Handlungen bis zu Gesamttätigkeitet der Organisation.
Dies ist nicht immer ein Fehler derjenigen, die den Prozess erfassen, weil sie
nicht zwischen Funktion und Prozess unterscheiden können (vgl. xxx) oder weil sie
eine bestimmte Prozessebene nicht einhalten können. Es kann auch gewollt sein: Die
Erfassung wird da detailliert, wo man eine bestimmte nicht effiziente Prozesssituati-
on klar herausarbeiten möchte und dort weniger detailliert, wo es nur darum geht,
den Gesamtzusammenhang im Prozess aufzuzeigen. Vgl. dazu das Beispiel einer
Auftragsabwicklung in [Staud 2006, S. 164ff, Abschnitt 6.2).
Für die Prozesserfassung hat dies die Konsequenz, dass die Ebene, auf der die
Aufgaben (und damit dann auch die Tätigkeiten) betrachtet werden, ein subjektiver
Faktor ist, der durch die Modellierer oder auch durch den Zweck der Modellierung
festgelegt werden kann. Darauf wird in den entsprechenden Abschnitten immer
wieder eingegangen.
Subjektivität 2 - Länge von Geschäftsprozessen
Dieselbe Subjektivität liegt bezüglich der Länge von Geschäftsprozessen vor. Man
kann z.B. die Auftragsabwicklung als Ganzes, als einen Geschäftsprozess betrachten
- wie in [Staud 2006, Abschnitt 6.2] - oder seine einzelnen Abschnitte, also z.B. die
Angebotserstellung, die Auftragsbearbeitung, die Materialbeschaffung, die Produk-
tion, die Kalkulation, die Auslieferung, usw. Auch hier erfolgt die Festlegung nur
durch denjenigen, der den Geschäftsprozess erfassst, bei der Modellierung dann
durch die Modellierer oder den Zweck der Modellierung.
Einige Autoren versuchen diese Subjektivität zu überwinden, indem sie als
"Grenzen" der Prozesse den Kunden definieren. Jeder Prozess soll beim Kunden
beginnen und bei ihm enden (vgl. oben). Dies ist allerdings höchstens für Kernpro-
zesse sinnvoll.
Automatisierung, IT-Abdeckung
Eine wichtige Eigenschaft von Prozessen oder Prozessabschnitten ist der Automati-
sierungsgrad. 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 Entscheidungspro-
zessen handelt, hat man dieses Ziel weitgehend erreicht. Ein einfaches Schema für
diese Eigenschaft ist "voll automatisiert, teilweise automatisiert, nicht automati-
siert". Dies betrifft inzwischen auch ganze Prozesse. Das Geschäftsmodell der Inter-
netunternehmen beruht darauf, es wäre auf andere Weise auch nicht denkbar. Diese
ständig zunehmende Automatisierung hat tiefgreifende Konsequenzen für das Ge-
schäftsprozessmanagement.
Unterstützung oder Automatisierung
Geschäftsprozesse können durch die IT unterstützt werden oder sie können automa-
tisiert sein. Der Unterschied ist folgender: "Unterstützung" meint, dass einzelne
24 2 Geschäftsprozesse
Abschnitte durch Programme realisiert werden. "Automatisierung" meint, das alle
durch Programme realisiert sind, evtl. auch Entscheidungsvorgänge. D.h., um einige
einfache Beispiele zu bringen, die Nachbestellung für das Lager wird automatisch
durchgeführt, die Kaufempfehlung beim Web-Anbieter automatisch generiert (wes-
halb 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]).
Unterstützung der Abwicklung der Geschäftsprozesse durch Anwendungssoft-
ware 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 heute, v.a. seit der Etablierung prozessorien-
tierter integrierter Standardsoftware (ERP-Software), sehr hoch.
Dies wird in der Literatur zu Geschäftsprozessmanagement höchstens wahrge-
nommen, fließt aber noch nicht ausreichend in die Überlegungen ein.
Benötigte Produktionsfaktoren, Input und Output
Es wurde in der Definition angemerkt, für die Durchführung der Geschäftsprozesse
werden Materialien und Ressourcen benötigt:
materielle bzw. technische Ressourcen wie Materialien, Zwischenprodukte, die
IT, usw.
Rohstoffe
personelle Ressourcen
finanzielle Ressourcen
Diese werden für den Geschäftsprozess von externen und internen Lieferanten be-
reitgestellt.
IT-Ressourcen
Eine wichtige Ressource ist die IT-Landschaft der Organisation. Hierzu gehören:
Programme für den Kontrollfluss
Die verwendeten Daten bzw. Datenbanken. Denn die Zustandsänderungen des
Systems sind die Änderungen des Datenbestandes, die sich aus der Leistungser-
bringung ergeben.
Die technischen Grundlagen der Objektflüsse (Objekte als Gegenstände der
Leistungserbringung). Auch von Geschäftsobjekten, mit denen wir auch wieder
die Daten und Datenbanken berühren, denn natürlich werden heute Geschäfts-
objekte üblicherweise in der Unternehmensdatenbank abgespeichert.
Datenflüsse entlang der Geschäftsprozesse (z.B. Steuerungsinformationen) aber
auch in den einzelnen Tätigkeiten. Vor allem auch unternehmensübergreifend -
heute auf der Basis von Internet und XML.
2.4 Art der Problemlösung
Denken wir an Geschäftsprozesse, dann meist zuerst an Routineaufgaben, an stan-
dardisierte Vorgänge einfacherer Struktur. Dem ist aber, wie wir ja auch alle wissen,
2.4 Art der Problemlösung 25
nicht so. Es gibt unterschiedliche Schwierigkeitsgrade, unterschiedlich komplexe
Aufgaben.
In Alpar/Alt/Bensberg wird, zurückgreifend auf [Simon 1957], der Problemlö-
sungs- bzw. Entscheidungsprozess in folgende Phasen unterteilt:
1. Problemerkennung
2. Alternativengenerierung
3. Alternativenauswahl
4. Implementierung und
5. Kontrolle.
Vgl. [Alpar, Alt, Bensberg u.a. 2014, Pos. 580ff]. Dabei gibt es auch Rücksprünge,
wie in der folgenden Abbildung angedeutet.
Abbildung 2.4-1: Problemlösungsphasen nach (Simon 1957), zitiert nach [Alpar, Alt,
Bensberg u.a. 2014, Pos. 592)
In der ersten Phase wird festgestellt, dass es ein zu lösendes Problem gibt, das sich
in einer Diskrepanz zwischen dem wahrgenommenen Istzustand und dem angestreb-
ten Sollzustand zeigt. Da eine frühe Erkennung eines Problems in vielen Fällen eine
Voraussetzung für die rechtzeitige Lösung ist, kommt dieser Phase eine zentrale
Bedeutung zu.
In der zweiten Phase werden Lösungsalternativen entwickelt. In der dritten Phase
wird eine der Lösungen gewählt. Je nach Problemstruktur kann die eine oder andere
Phase durch Informations- und Kommunikationssysteme unterstützt oder sogar
automatisiert werden.Wenn ein Problem erkannt wurde, können Lösungsalternativen
entwickelt werden.
In der Praxis (von Informations- und Kommunikationssystemen) muss dann eine
getroffene Entscheidung auch umgesetzt (implementiert) werden. Danach wird ge-
prüft, ob die mit der Entscheidung verfolgten Ziele auch erreicht werden. Anschlie-
ßend ist zu kontrollieren, inwieweit die mit der Entscheidung verfolgten Ziele auch
erreicht wurden. Diese Phasen können mehrfach durchlaufen werden, auch Rück-
sprünge sind möglich.
Probleme und Problemstrukturen
Aufbauend auf diesem Phasenmodell kann man nun Probleme (Aufgaben) danach
unterscheiden, zu welchen Phasen die Aufgabenträger ein geeignetes (Lösungs-
)xxxVorgehen kennen.
26 2 Geschäftsprozesse
Als wohlstrukturiert wird ein Problem empfunden, wenn ein Entscheidungsträger
zu jeder der Phasen ein geeignetes Vorgehen kennt. In einem solchen Fall ist es oft
möglich, die Problemlösung zu automatisieren. Dies bedeutet, dass man eine Lö-
sungsvorschrift festlegt, die auch von anderen (Menschen, Programmen, Maschinen)
befolgt werden kann.
Als semistrukturiert gelten Probleme, bei denen für einige Phasen Lösungsansät-
ze bekannt sind, für andere nicht. Geschäftsprozesse mit solchen Problemen können
auf jeden Fall durch IT unterstützt werden, Automatisierung ist aber nur in einzelnen
Prozessabschnitten möglich.
Als unstrukturiert wird ein Problem empfunden, wenn zu keiner der Phasen ein
geeignetes Vorgehen bekannt ist. Solche Probleme entziehen sich der Automatisie-
rung vollkommen. Unterstützung durch IT ist denkbar.
Die Einteilung des Strukturierungsgrads ist offensichtlich subjektiv. Die Verwen-
dung von vielen Unterteilungen zwischen den genannten Extremen wäre möglich,
ist aber nicht sinnvoll. Deswegen findet sich in der Literatur da auch nur eine Klas-
se: die der semistrukturierten Probleme.
Geschäftsprozesse mit durchgängig wohlstrukturierten Problemen sind leicht
durchführbar, leicht durch Software unterstützbar und meist auch automatisierbar.
2.5 Art der Aufgabe
Probleme können danach unterschieden werden, zu welchen Phasen die Aufgaben-
träger ein geeignetes Lösungsverfahren kennen. Welche Einteilungen gibt es dabei
und wie verhalten sie sich bzgl. der Automatisierungsmöglichkeiten?
Es wurde oben schon angesprochen, in Zusammenhang mit der Automatisierbarkeit
von Geschäftsprozessen und Geschäftsprozessabschnitten. Prozesse sind, was ihre
innere Struktur angeht, unterschiedlich: mehr oder weniger "chaotisch", mit mehr
oder weniger Entscheidungen, mit der Notwendigkeit von mehr oder weniger Wis-
sensverarbeitung, usw. Dies rührt von der Unterschiedlichkeit der in einer Organisa-
tion zu lösenden Aufgaben her und hat unmittelbare Auswirkungen auf die Mög-
lichkeiten zur IT-Unterstützung und Automatisierung.
Deshalb werfen wir hier nochmals einen Blick auf die oben eingeführte Manage-
mentpyramide (Abschnitt xxx), jetzt aber mit dem Fokus auf die zu lösenden Auf-
gaben. In der Managementliteratur finden wir dazu die üblichen Einteilungen, wie
sie die folgende Abbildung zeigt. Bzgl. der Managementaufgaben werden dabei eine
oberste, mittlere und untere Führungsebene unterschieden. Führungskräfte der unte-
ren Ebene arbeiten unmittelbar mit den Personen auf Stellen ohne Führungsverant-
wortung zusammen, ihre Entscheidungen sind in der Regel detailliert, sachbezogen
und konkret. Je höher die Führungsebene, desto größer ist der Entscheidungsspiel-
raum sowie dieTragweite der zunehmend abstrakteren Entscheidungen. Wie oben
schon ausgeführt, verkleinert sich von "unten nach oben" aufgrund des hierarchi-
schen Aufbaus die Anzahl der Leitungsstellen auf einer Hierarchieebene, deshalb die
Pyramidenform.
Für uns ist diese Pyramide von Interesse, weil auf all diesen Ebenen Geschäfts-
prozesse stattfinden, allerdings von sehr unterschiedlicher Natur und weil sich Ge-
schäftsprozessmanagement um all diese Geschäftsprozesse kümmern muss.
Geschäftsprozesse verlaufen natürlich auch über Ebenen hinweg. Dies wurde
schon in Abbildung 2 angedeutet am Beispiel eines Prozesses der sozusagen senk-
2.5 Art der Aufgabe 27
recht verläuft, was aber nicht sein muss, es gibt durchaus auch Geschäftsprozesse,
die sich im Bereich von 2 oder drei dieser Ebenen bewegen.
Abbildung 2.5-1: Managementaufgaben
Wir werden nun etwas konkreter, indem wir diese Aufgaben auf konkrete Arbeitsbe-
reiche (von Industrieunternehmen) herunterbrechen. Dabei hilft ein Blick "auf die
Klassiker", die Ausführungen von Scheer und Mertens im Rahmen ihrer Texte zu
Betrieblichen Anwendungssystemen (beispielhaft [Scheer 1997], [Mertens 2013]).
Im Rahmen ihrer Analysen zu den in Unternehmen zu lösenden Aufgaben kamen sie
zu der bekannten Einteilung nach der Art der betriebswirtschaftlichen Aufgabe, die
sie für eine hierarchische Einteilung der betrieblichen Anwendungssysteme nutzten.
Folgende Ebenen haben Scheer und Mertens dabei unterschieden7 (vgl. auch die
folgende Abbildung):
Führungsaufgaben, langfristige Planung und Entscheidung
Analyseaufgaben
Kontroll-, Planungs-, Berichtsaufgaben
Wertorientierte Abrechnung
Operative Tätigkeiten (Administration, Disposition).
Damit können wir eine Einschätzung der Problemstruktur in diesen Arbeitsberei-
chen vornehmen und den möglichen Automatisierungsgrad abschätzen.
Administration
Zur Administration gehören die Verwaltung und Verarbeitung von Massendaten,
z.B. die …
Berechnung der Entlohnung im Personalwesen
Buchführungsarbeiten in der Finanzbuchhaltung
Berechnung der Monats- und Jahresabschlüsse in der Finanzbuchhaltung
Kontoführung bei Kreditinstituten
7 Dort auf die IT-Systeme bezogen, die im Rahmen der IT-Unterstützung und Automatisierung entste-
hen.
28 2 Geschäftsprozesse
Lagerbestandsführung im Handel
Prozesse können hier dahingehend optimiert werden, dass die Massendatenverarbei-
tung rationalisiert wird.
Administrationsaufgaben sollen vorhandene Abläufe und die Massendatenverar-
beitung rationalisieren und Routineaufgaben bewältigen. Die Problemstruktur ist
hier i.d.R. wohlstrukturiert.
Das Automatisierungspotential ist hier, da es sich um Routineabläufe handelt,
sehr hoch.
Disposition
Zur Disposition gehört die Steuerung kurzfristiger, gut strukturierter Abläufe inner-
halb des Betriebs und die Vorbereitung kurzfristiger dispositiver Entscheidungen,
vor allem auf der unteren und mittleren Führungsebene. Beispiele für damit zu erle-
digende Aufgaben sind die …
(Plan-)Kalkulation in der Kostenrechnung
Außendienststeuerung im Vertrieb
Tourenplanung im Vertrieb
Materialbeschaffung in der Fertigung
Werkstattsteuerung in der Fertigung
Bestellwesen im Handel
Die Disposition bereitet menschliche Entscheidungen vor. Was die Vorbereitung
angeht, ist die Problemstruktur wohlstrukturiert, die Entscheidungen sind dann zwi-
schen semistrukturiert und unstrukturiert.
Das Automatisierungspotential ist hier, da es sich um Routineabläufe handelt,
hoch. Evtl. werden auch Entscheidungsprozesse automatisch durchgeführt ("Nach-
bestellung einfacher Güter nach Lagerbestand, derzeitiger Nachfrage, usw.").
Wertorientierte Abrechnung
Wertorientierte Abrechnungsaufgaben begleiten die oben dargestellten mengenori-
entierten Prozesse. Sie machen die betriebswirtschaftlichen Konsequenzen sichtbar.
Am Beispiel des Personalwesens kann man dies gut erläutern: Die operativen Sys-
teme liefern die Daten zum täglichen Einsatz eines jeden Beschäftigten: Arbeitsbe-
ginn, Arbeitsende, Überstunden usw. Im Rahmen der wertorientierten Abrechnung
wird daraus z.B. das Monatsgehalt berechnet.
Wertorientierte Abrechnungaufgaben nehmen eine betriebswirtschaftliche Aus-
wertung der mengenorientierten Daten aus den operativen Systemen vor.
Das Automatisierungspotential ist hier, da es sich meist um stark durchstruktu-
rierte Abläufe handelt, sehr hoch. Hier liegen bereits IT-Lösungen vor.
Berichts-, Planungs- und Kontrollaufgaben
Die Informationen für diese Aufgaben stammen aus den beiden unteren Ebenen. Sie
werden hier für die entsprechenden Aufgaben verarbeitet.
Das Berichtswesen deckt den Informationsbedarf für operative Entscheidungen.
Es liefert z.B. periodische Berichte oder Signalberichte, die durch Soll/Ist-
Abweichungen automatisch ausgelöst werden. Diese Funktionalität ist in modernen
Automatisierungs-
potential
2.5 Art der Aufgabe 29
integrierten Softwarepaketen enthalten. Dazu erlauben die Berichtssysteme einfache
Auswertungen von Dateien und Datenbanken sowie die Präsentation der Ergebnisse.
Initiativ wird entweder der Nutzer oder das System (bei regelmäßig erzeugten Be-
richten).
Das Automatisierungspotential im Berichtswesen ist, nach der Festlegung der Art
der Berichte, sehr hoch.
Planungsaufgaben und -entscheidungen werden in der betrieblichen Leitungs-
ebene realisiert. Hier liegen oft schlecht strukturierte Probleme vor. Ein Beispiel ist
das Berechnen von Planalternativen und -varianten mit Hilfe von Modellrechnun-
gen. In Betracht kommen dabei die …
Planung einzelner Unternehmensbereiche (z.B. Absatzplanung)
integrierte, bereichsübergreifende Planung (z.B. Produktionsprogrammplanung
als Integration von Produktion und Vertrieb)
globale Unternehmensplanung
Das Automatisierungspotential ist hier niedrig. Planungsvorgänge können nur unter-
stützt werden (Erhebung und Verarbeitung von Informationen), die eigentliche Pla-
nung ist Sache der beteiligten Menschen8.
Mit Kontrollaufgaben sind die zur Überwachung der Einhaltung der Pläne ge-
meint. Z.B. durch Soll/Ist-Vergleiche mit Hinweisen auf notwendige Korrekturmaß-
nahmen. Sie sind das Gegenstück zu den Planungsaufgaben. Die Kontrollaufgaben
klären, wo spezielle Analysen und Abhilfemaßnahmen notwendig sind, z.B. bei der
Kontrolle des Risikoportfolios in einer Versicherung.
Typisch für diese Ebene ist, dass die zu fällenden Entscheidungen langfristige, in
der Regel schlecht strukturierte Aufgaben betreffen.
Ähnlich wie oben ist das Automatisierungspotential hier niedrig. Nur eingerichte-
te Kontrollprozesse können automatisiert ablaufen. Die eigentlichen Entscheidungen
müssen Menschen fällen.
Analyseaufgaben, Langfristige Planung und Entscheidung
Die Hierarchie geht weiter. Als nächstes folgen die Analyseaufgaben. Für diese
werden die Daten aus den operativen und den Abrechnungsaufgaben verdichtet,
verwaltet und ausgewertet. Auch Daten aus externen Quellen werden einbezogen.
Die Spitze der Hierarchie stellt die langfristige Planung und Entscheidung dar.
Hier erreichen die Daten, die von „unten“ (in dieser Hierarchie) geliefert werden, die
höchste Verdichtungsstufe. Diese Aufgaben dienen der Entscheidungsvorbereitung
für die oberste Führungsebene.
8 Mir ist die Diskussion um KI-Systeme (Systeme mit sog. künstlicher Intelligenz) und um maschinell
(programm-) gestützte Entscheidungen vertraut, noch ist es aber nicht so weit.
Automatisierungs-
potential
Automatisierungs-
potential
30 2 Geschäftsprozesse
Abbildung 2.5-2: Art der betriebswirtschaftlichen Aufgabe, Aufgaben im Unterneh-
men Quelle: inspiriert von [Scheer 1997, S. 5], [Mertens 2013, S. 19]
2.6 Wichtige Eigenschaften
Prozessintegration
Aus obigem lassen sich einige wichtige Eigenschaften von Prozessen ableiten. Zum
Beispiel das Ausmaß der Prozessintegration. Mit ihr ist die Durchgängigkeit des
Geschäftsprozesses über verschiedene traditionelle Organisationsbereiche, wie z.B.
Beschaffung, Einkauf, Produktion, Verkauf, Rechnungs- und Personalwesen ge-
meint. Daneben natürlich, wenn auch erst seit einigen Jahren, die Durchgängigkeit
über Unternehmensgrenzen hinweg.
Diese Eigenschaft lässt sich klären, wenn man den Prozess an den Schnittstellen
betrachtet. Die Abteilungsgrenzen sollten heute überhaupt keine Rolle mehr spielen,
da typischerweise alle Prozessteilnehmer dieselbe integrierte prozessorientierte
Software nutzen. An den Unternehmensgrenzen gibt es dagegen oft noch Probleme.
Rechnungen und Lieferscheine können nicht direkt übernommen werden, die se-
mantische Prozessintegration ist nicht gewährleistet, usw. Semantische Prozessin-
tegration betrifft die Weitergabe von Informationsobjekten, meist zwischen ver-
schiedenen Organisationen. Sie ist gegeben, wenn bei der Weitergabe nicht nur
keine Medienbrüche auftreten, sondern wenn die Semantik des Informationsobjekts
(Rechnung, Lieferschein, Koordinierungsinformation, …) beim Empfänger durch
IT-Systeme erkannt wird. Daran wird zur Zeit in vielen Unternehmen im Rahmen
des B2B9 gearbeitet.
9 "Business-to-Business", Geschäftstätigkeit von Unternehmen miteinander im Internet.
2.6 Wichtige Eigenschaften 31
Defizite in der Prozessintegration äußern sich auch durch Medienbrüche. Deren
Anzahl und Ausmaß ist eine weitere wichtige Eigenschaft von Geschäftsprozessen.
Gemeint ist die Situation, wenn ein Geschäftsobjekt von einem Prozessabschnitt
zum nächsten nicht einfach weitergegeben werden kann, sondern neu erfasst oder
umgearbeitet werden muss. Diese Defizite werden in der Prozesserfassung nicht
unbedingt deutlich, weil da einfach dasselbe Geschäftsobjekt im nächsten Prozess-
abschnitt auftaucht. Es muss deutlich gemacht werden, u.a. durch eine Erfassung des
Informationstransports.
Beispiele für Medienbrüche:
Ausgabe von Information in der einen Software, händische Eingabe bei der
nächsten.
Eingehende Information ("Auftragseingang") muss bearbeitet werden, um sie in
die eigene Anwendungssoftware zu bringen.
Für eine Prognoserechnung können Informationen nicht in der Form bereitge-
stellt werden, in der sie benötigt werden
Im Kern ist es so: Muss dieselbe bereits erfasste Information nochmals erfasst wer-
den, liegen Medienbrüche und damit ein Defizit in der Prozessintegration vor.
Ausmaß der Datenintegration
Eine weitere wichtige Eigenschaft ist das Ausmaß der Datenintegration, d.h. der
Integration der Datenbestände, die für die einzelnen Tätigkeiten des Geschäftspro-
zesses benötigt werden. Auch sie ist von großer Bedeutung, da nichtintegrierte Da-
tenbestände Reibungsverluste bedeuten. Konkret kann dies folgendes bedeuten:
Daten zu einem Bereich, zu einer Aufgabe, für einen Geschäftsprozess …
…liegen in verschiedenen digitalen oder auch nicht-digitalen Datenbeständen vor,
sind also zersplittert.
…liegen in verschiedenen Datenbeständen vor und sind nicht übereinstimmend
(abweichende Artikeldaten, Adressen, usw.)
Eine Quelle für solche Defizite ist neben Datenbankinkompetenz und Schlamperei
oftmals der Zusammenschluss von Organisationen ("Merging"). Dieser fordert ja
auch den Zusammenschluss der IT-Systeme und damit der Datenbanken. Beides ist
eine komplexe Aufgabe und wird oft nicht umfassend gelöst oder erst mit Verspä-
tung. So entstehen dann Beiträge zur "Stammdatenkrise" (damit werden fehlerhafte
Strukturen in den Unternehmensdatenbanken bezeichnet).
Dies ist ein ganz altes Thema, das schon Scheer in den ersten Auflagen seines
Standardwerks (in 7. Auflage: [Scheer 1997]) beschäftigte und dass auch einer der
Motivatoren für die Entwicklung der ERP-Software war, das Problem von heteroge-
nen (nicht miteinander verknüpften) Datenbeständen, damals auch Dateninseln ge-
nannt. Es ist nicht verschwunden, sondern in neuer und veränderter Gestalt immer
noch präsent, z.B. wenn Teile der IT in "die Cloud" verlagert werden (vgl. xxx).
Wie erkennt man nun in der Prozesserfassung solche Defizite in der Dateninteg-
ration? Durch eine exakte Erfassung der Informationen, die bei den einzelnen Tätig-
keiten erzeugt oder benutzt werden. Hier sollte, wenn genügend detailliert und ge-
nau untersucht wird, diese Zersplitterung aufgedeckt werden.
32 2 Geschäftsprozesse
Komplexitäts- und Automatisierungsgrad
Die oben angesprochene Art der Problemlösung im jeweiligen Geschäftsprozess
stellt eine weitere Eigenschaft dar. Wie sind die im Geschäftsprozess zu lösenden
Aufgaben strukturiert? Insgesamt wohlstrukturiert, das sind die Prozesse, für die
heute bereits IT-Systeme vorliegen. Oder weniger strukturiert. Vielleicht sogar mit
kreativen Anteilen. Oder gänzlich unstrukturiert.
Eine weitere wichtige Eigenschaft ist der Umfang der Automatisierung, der
Automatisierungsgrad, wie in Abschnitt 2.5xxx diskutiert. Er hängt mit der vorigen
Eigenschaft zusammen. Der Trend zeigt hier ganz eindeutig in Richtung Ausdeh-
nung der Automatisierung. Die Messung des Automatisierungsgrads gibt Hinweise
auf Optimierungspotential. Unter Umständen können bisher nicht automatisierte
Prozessabschnitte auch einer Automatisierung zugeführt werden.
2.7 Komponenten
In Abschnitt 2.3xxx wurde deutlich, aus welchen Komponenten Geschäftsprozesse
bestehen:
Einzelne Tätigkeiten, aus denen der Geschäftsprozess zusammengesetzt ist.
Der ablaufmäßige Zusammenhang zwischen diesen, der Kontroll- oder auch
Sequenzfluss (in der BPMN).
Die Einbettung des Geschäftsprozesses in die gesamte Geschäftstätigkeit des
Unternehmens durch Angabe seines Zieles.
Die Aufgabenträger, d.h. die die Antwort auf die Frage, "Wer erbringt die Leis-
tung?" Früher wurden hier oft Abteilungen oder Stellen angegeben, heute meist
Funktionsträger (Vertriebsleiter, usw.), zunehmend auch IT-Systeme.
Die im Rahmen des Geschäftsprozesses genutzten Daten.
Die Informations-/Datenflüsse , d.h. die Weitergabe von Informationen von
Aufgabe zu Aufgabe.
Die Produktionsfaktoren und ihr Verbrauch im Rahmen der Prozessdurchfüh-
rung.
Die Unterstützung der Prozessrealisierung durch die IT.
Alles dies muss bei der Erfassung von Geschäftsprozessen mit dem Ziel der Model-
lierung erfasst werden. Mehr dazu in xxx.
2.8 Modell vs. Instanz
Wenn wir einen Prozess erfassen, erfassen wir alle denkbaren Durchgänge, egal wie
an den einzelnen Verzweigungspunkten der Kontrollfluss bei einem konkreten
Durchgang stattfand. Dies wird Prozessmodell oder auch Geschäftsprozessschema
(Rump 1999, S. 19f] genannt. Betrachtet man dagegen einen konkreten Durchgang
durch den Geschäftsprozess, spricht man von einer Instanz des Geschäftsprozesses.
Auch sie kann modelliert werden.
Die Erfassung und Modellierung von Geschäftsprozessen muss tatsächlich beides
leisten, die Darstellung des Rahmens für alle denkbaren (vorgedachten) Kontroll-
flüsse und die Darstellung einzelner konkreter Durchgänge.
2.9 Kern- und Supportprozesse 33
2.9 Kern- und Supportprozesse
[Kategorisierung von Geschäftsprozessen]
Geschäftsprozesse werden nach unterschiedlichen Kriterien kategorisiert. Die wich-
tigsten werden wir hier betrachten. Angesichts der Bedeutung des Zieles, Wert-
schöpfung zu erreichen10
, verwundert die erste schon sehr früh in der Diskussion des
Geschäftsprozessmanagements definierte (auf Porter zurückgehende) Unterschei-
dung nicht: in Geschäftsprozesse, die unmittelbar zur Wertschöpfung beitragen und
in die übrigen. Erstere werden Kerngeschäftsprozesse, zweitere Supportprozesse
oder unterstützende Prozesse genannt. Die Wortwahl "unmittelbar" bei der Definiti-
on der Kernprozesse ist wichtig. Natürlich leisten alle Geschäftsprozesse einen Bei-
trag, auch Finanz- und Personalwesen, die in der Regel zu den Supportprozessen
gezählt werden.
Das ist wohl ein Grund, weshalb in der Literatur die Definition von Kernge-
schäftsprozessen meist noch präzisiert wird in Bezug auf folgende Punkte:
Kundenähe
Profilbildung
Wettbewerbssituation. Kernprozesse stehen sozusagen voll im Wettbewerb. Sie
sind wettbewerbskritisch [Gadatsch 2013, Position 346).
Leistungserbringung
Hauptleistung
Kundennähe
Kerngeschäftsprozesse müssen, sollen sie auf Dauer erfolgreich sein, an den Kunden
ausgerichtet werden (vgl. z.B. [Hammer und Champy 2006], [Harrington 2007, S.
248], [Gadatsch 2013, Position 346], [Schmelzer und Sesselmann 2013, S. 53]).
Schmelzer/Sesselmann gehen sogar so weit, dass sie fordern, jeder Kerngeschäfts-
prozess müsse beim Kunden beginnen (Kundenwunsch) und bei ihm enden (Liefe-
rung).
Dies kann ergänzt werden. Da ja ständig neue Leistungen und Produkte entwi-
ckelt werden, von denen man hofft, dass sie von den Kunden angenommen werden,
müssen auch die potentiellen Kunden in den Adresssatenkreis miteinbezogen wer-
den. Der Erfolg dieser Ausrichtung wird gemessen durch den Erfolg der erbrachten
Leistung. Wird das neue Smartphone von den Kunden gekauft, das selbstfahrende
Kraftfahrzeug, der neue LifeTracker, usw.? Hier wird deutlich, dass Forschung und
Entwicklung im Innovationsmanagement ebenfalls zu den Kernkompetenzen gehö-
ren.
Profilbildung
Die durch die Kerngeschäftsprozesse erbrachten Leistungen stellen so etwas wie das
Leistungsprofil der Organisation dar. Mit ihm hebt sich die Organisation von der
Konkurrenz ab (Gadatsch, 2013, S. 38f]. Deshalb wird bei der Einrichtung der IT-
Unterstützung bei Kerngeschäftsprozessen eher nicht zu Standardlösungen, sondern
zu Indivualsoftware oder stark angepasster ERP-Software gegriffen.
10 Bei Organisationen, deren Ziel nicht die Wertschöpfung ist, muss dies wieder auf das Ziel des mög-
lichst effektiven und effizienten Mitteleinsatzes abgebildet werden. Hier wird aber auch eher auf die
Unterscheidung von Haupt- und Serviceprozessen gesetzt.
34 2 Geschäftsprozesse
Leistungserbringung
In der Regel geht es bei den Kernprozessen um den Leistungserstellungsprozess.
Dies muss aber nicht sein. Wenn Leistungen nur durch inensives Marketing zum
Kunden gebracht werden können, wird auch Marketing zum Kerngeschäftsprozess.
Bei Banken und Sparkassen ist die Führung der Kundenkonten eine wichtige Auf-
gabe (vgl. auch unten), ein Teil der Leistungserbringung, die aber nur eingeschränkt
zur Wertschöpfung beiträgt. Sie dient aber der Kundenbindung und wird deshalb
beibehalten.
Änderungen
Kerngeschäftsprozesse erscheinen oftmals fixiert, fast zementiert. Dies sind sie aber
nicht, sie ändern sich im Zeitablauf. Teilweise oder auch ganz. Die Wirtschaftsge-
schichte kennt zahlreiche Beispiele dafür. Nehmen Sie nur die Kreditinstitute, bei
denen die Bereitstellung der Konten mal ein Kerngeschäftsprozess war oder große
IT-Unternehmen, die von Hardwareprodukten auf Dienstleistungsangebote um-
stell(t)en (z.B. IBM). Auch die Konsumgüterindustrie gibt hier Hinweise. Wenn die
Qualität des Produkts (z.B. des Schokoriegels) nur noch notwendige Bedingung für
den Erfolg ist, aber nicht hinreichende, weil wirksames Marketing dazu kommen
muss, dann kann Marketing als Kerngeschäftsprozess angesehen werden.
Grundsätzlich hilft folgende Überlegung: Welche Aktivitäten führen insgesamt
dazu, dass die Leistung des Unternehmens auf dem Markt angenommen wird. Dies
sind die Kernprozesse.
Beispiele
Abschließend noch einige Beispiele für Kernprozesse:
Für Unternehmen, die im E-Commerce tätig sind, ist die Qualität ihrer Plattform
von entscheidender Bedeutung. Hier ist die Automatisierung der Prozessab-
wicklung in vollem Umfang realisiert. Verlangt sind Schnelligkeit, Übersicht-
lichkeit, einfacher und sicherer Bezahlvorgang und automatisiertes Customer
Relationship Management. Alle Geschäftsprozesse, die dazu einen Beitrag leis-
ten, z.B. auch in der Softwareentwicklung, sind Kernprozesse.
Für Dienstleistungsunternehmen im Transportbereich ist die eigentliche Trans-
portleistung von Menschen und Gütern ein Kernprozess. Inzwischen aber auch
die Fähigkeit, sich mit der eigenen Leistungserbringung in die logistischen
Netzwerke einzubringen.
Für eine Messegesellschaft gehört die Organisation von Messeveranstaltungen,
der technische Betrieb eines Messezentrums, der Einkauf von Dienstleistungen
und u.U. der Verkauf von Messestandflächen an Aussteller zu den Kernprozes-
sen. Ein unterstützender Prozess ist die Abrechnung von Messeveranstaltungen.
In einem Steuerbüro gehört die Erstellung der Finanzbuchhaltungen, der Jahres-
abschlüsse, der Steuererklärungen und Lohnabrechnungen zu den Kernprozes-
sen (je nach Ausrichtung der Geschäftstätigkeit). Ein Beispiel für einen unter-
stützenden Prozess ist die Neumandantenwerbung.
In einem Handelshaus gehören die Auftragsabwicklung und die Einkaufsab-
wicklung (Qualität, Preis, ...) zu den Kernkompetenzen. Unterstützende Prozes-
se sind hier z.B. die Qualitätskontrolle, der Kundenservice, das Personalwesen,
das Mahnwesen und die Kundenaquisition.
2.9 Kern- und Supportprozesse 35
In einem Softwarehaus gehört die Entwicklung (Systemanalyse, Systemdesign,
Programmierung) und der adäquate Einsatz von Methoden und Werkzeugen zu
den Kernkompetenzen.
Automatisierungspotential bei Kernprozessen
Das Automatisierungpotential bei Kernprozessen ist sehr unterschiedlich. Geht es
dabei um kreative Vorgänge (Marketingstrategie entwerfen, neue Leistungen entwi-
ckeln, ...), ist kaum Automatisierung möglich, die Prozesse können lediglich unter-
stützt werden. Geht es um die Produktion hochwertiger Güter, ist auch die Produkti-
on ein Kernprozess, der sehr stark automatisiert ist und dessen
Automatisierungsniveau gerade durch die Angebote rund um Industrie 4.0 höher
getrieben wird.
Falls E-Commerce, also der Vertrieb über das Internet vorliegt, ist das Automati-
sierungspotential sehr hoch. Es liegen vollautomatisierite Prozesse vor, sowieso
gegenüber den Kunden, das gehört zum Geschäftsmodell, aber auch darüberhinaus
in die Supportprozesse hinein.
Hängt der Erfolg eines Unternehmens von einer hochwertigen Webpräsenz ab,
wie im E-Commerce, dann ist die Entwicklung, Wartung und ständige Optimierung
derselbigen ein Kernprozess.
Supportprozesse
Oben wurde es ausgeführt, Supportprozesse sind nicht direkt wertschöpfend, aber
notwendig, um die Kernprozesse ausführen zu können. Die Bezeichnung ist nicht
abwertend gemeint. Ohne Supportprozesse gibt es keine Kernprozesse. Sie sind im
Gegensatz zu Kernprozessen meist nicht wettbewerbskritisch. Oft werden hierunter
z.B. Prozesse im Personalwesen oder in der Finanzbuchhaltung verstanden
[Gadatsch 2013, S. 39).
Supportprozesse sind oftmals Routinevorgänge mit einfacherer Problemstruktur,
also im Sinne der obigen Ausführungen wohlstrukturiert. Sie konnten deshalb schon
früh durch Programme unterstützt, später in Programme abgebildet werden. Heute
sind sie die ersten Kandidaten für die Vollautomatisierung.
Wertschöpfungskette
Der wichtigste Geschäftsprozess ist für Unternehmen ihr Anteil an der sog. Wert-
schöpfungskette (manchmal auch Wertkette). Darunter wird die gesamte Prozessfol-
ge, die der Leistungserstellung dient und hoffentlich die Wertschöpfung realisiert,
verstanden. Dieser Begriff geht auf Porter zurück (vgl. [Porter 1985], [Porter 1998],
[Porter 1999]). Vgl. zu seinem Konzept der Wertkette xxx. Das Unternehmen ist mit
seinen wertschöpfenden Geschäftsprozessen in die gesamte Wertschöpfungskette
der Leistungserbingung eingebettet.
Bedeutung für die Gestaltung der IT
Für das Thema Geschäftsprozessmanagement ist die Unterscheidung von Kern- und
Supportprozessen von großer Bedeutung. Kernprozesse sollen durch ihr leistungs-
starkes indviduelles Profil die Existenz des Unternehmens sichern. Sie werden daher
mit mehr Aufwand gepflegt, optimiert und auch modelliert. Falls für sie Software
angeschafft wird, ist es eher Individualsoftware als Standardsoftware. Die Aktivitä-
36 2 Geschäftsprozesse
ten rund um Geschäftsprozesse sind im Überschneidungsbereich von Geschäftspro-
zessmanagement und IT-Management angesiedelt (Bereich A von Abbildung xxx).
2.10 Steuerungs- und Führungsprozesse
[Kategorisierung von Geschäftsprozessen]
Eine andere Unterscheidung hebt auf die Managementebene, die Art der Problemlö-
sung ab (vgl. Abschnitt 2.5). Führungsprozesse (Managementprozesse, Steuerungs-
prozesse) sind für die übergreifende Planung, Steuerung und Kontrolle zuständig
(obere drei Ebenen von Abbildung 4). Mit ihnen werden die Kern- und Unterstüt-
zungsprozesse geplant und gesteuert [Gadatsch 2013, S. 38). In diesen Leitungsebe-
nen sind andere Prozesse und Prozessschritte notwendig, als in der Ausführungsebe-
ne. Beispiele für Führungsprozesse sind:
strategische Planung
operative Führung
Budgetierung.
Diese Art von Prozessen tragen nicht direkt bzw. nur in geringem Umfang zur Wert-
schöpfung bei, sind aber für die Durchführung der Kernprozesse unabdingbar und
unterstützen diese in verschiedenen Unternehmensbereichen. Sie sind, um es mit
Gadatsch zu sagen, "... die unternehmerische Klammer über die leistungserstellen-
den und unterstützenden Prozesse." [Gadatsch 2013, Pos. 1430]
2.11 Primäre und sekundäre Geschäftsprozesse
[Kategorisierung von Geschäftsprozessen]
Schmelzer und Sesselmann empfehlen die Unterscheidung von primären und sekun-
dären Geschäftsprozessen [Schmelzer und Sesselmann 2013, S. 67]. Primäre Ge-
schäftsprozesse erzeugen Leistungen (Produkte und/oder Dienstleistungen) für ex-
terne Kunden, um deren Bedarf zu befriedigen. Sie stiften unmittelbaren
Kundennutzen. Die Kunden sind bereit, dafür einen Preis zu zahlen. Die Leistungen
für externe Kunden sind Umsatzträger und haben entscheidenden Einfluss auf den
Geschäftserfolg und die Wettbewerbsfähigkeit. Diese Definition entspricht weitge-
hend den oben eingeführten Kerngeschäftsprozessen.
Sekundäre Geschäftsprozesse haben die primären Geschäftsprozesse oder auch
andere Sekundärprozesse als Kunden. Sie stellen Ressourcen wie z.B. Personal,
Finanzen, technische Ressourcen und IT bereit.
Sie teilen dann die sekundären Geschäftsprozesse in Management- und Unterstüt-
zungsprozesse ein und weisen darauf hin, dass sekundäre Geschäftsprozesse in der
Regel keinen direkten Marktbezug haben und sich nur indirekt auf die Wettbewerbs-
fähigkeit ausweisen. Wichtig ist ihr Hinweis auf die Ausnahme: Der Strategiepro-
zess („Strategie planen und überwachen"), der "die Weichen für das Erzielen nach-
haltiger Wettbewerbsvorteile stellt" [Schmelzer und Sesselmann 2013, S. 67].
2.12 Kreative / wissensintensive Prozesse
[Kategorisierung von Geschäftsprozessen]
2.12 Kreative / wissensintensive Prozesse 37
Es gibt Geschäftsprozesse, die sich nur eingeschränkt erfassen und beschreiben
lassen. Ihre Leistung wird wesentlich durch die beteiligten Menschen erbracht. Die
Autoren nähern sich auf unterschiedliche Weise dieser Thematik. In der Modellie-
rung von Geschäftsprozessen (vgl. die Ad Hoc - Prozesse der BPMN) wird einfach
konstatiert, dass es sich um Tätigkeiten handelt, die nicht (mit Einzelaufgaben,
Kontrollfluss, usw.) strukturiert werden können (oder "sollen", dann verzichtet man
auf die Präzisierung).
Auf dem Hintergrund der oben diskutierten Problemlösungsstrukturen handelt es
sich dann um unstrukturierte Probleme.
Wohl aus der Erkenntnis heraus, dass in solchen Prozessen die beteiligten Men-
schen auf der Basis von Erfahrungen und Wissen Probleme lösen sowie Entschei-
dungen fällen, wird hier auch von wissensintensiven Prozessen gesprochen. Schmel-
zer/Sesselmann charakterisieren die wissensintensiven Geschäftsprozesse als Typ-I-
Geschäftsprozesse (vgl. [Schmelzer und Sesselmann 2013, S. 70f]). Ihr Ablauf ist
dabei nur grob planbar und „Entscheidungen über den Prozessverlauf sind situativ
zu treffen und können nicht vordefiniert werden." Besonders „(...) Wissen, Erfah-
rungen und Einschätzungen der Verantwortlichen sowie der Mitarbeiter(...)" sehen
sie als Kernaspekte dieser Prozesse [ebenda, S. 71].
3 Geschäftsprozessmanagement
Die Begriffe Geschäftsprozessmanagement (GPM), Prozessmanagement und Busi-
ness Process Management (BPM) werden hier synonym verwendet.
3.1 Definition
Geschäftsprozesse wie sie im vorigen Kapitel vorgestellt wurden, bedürfen der Ein-
richtung, der Pflege und evtl. auch mal der Abwicklung. Zur Pflege gehört die Op-
timierung, zur Optimierung gehören Ziele.
Eine erste Definition
Geschäftsprozessmanagement hat das Ziel, die Geschäftsprozesse einer Organisation
so zu gestalten, dass eine möglichst hohe Wertschöpfung erzielt wird (Unterneh-
men), bzw. dass ein möglichst effektiver und effizienter Einsatz der Resssourcen
erfolgt (sonstige Organisationen). Mit anderen Worten: Effektivität und Effizienz
sollen so gestaltet werden, dass die Wertschöpfung gesichert und gesteigert wird.
Dabei geht es im Rahmen des Geschäftsprozessmanagements um alle Aktivitäten,
die mit der Planung, Gestaltung, Ausführung und Überwachung von Geschäftspro-
zessen zu tun haben. Ziel ist die möglichst optimale Durchführung der Geschäfts-
prozesse, ihre Anpassung an die Veränderungen der Umwelt, ihre Weiterentwick-
lung. Diese Aufgabe wird in Zusammenarbeit zwischen Fachabteilungen und IT
gelöst.
Kundenorientierung
Im vorigen Kapitel wurde betont, dass sich Geschäftsprozesse an den Kundenwün-
schen orientieren müssen. Damit war eine wichtige Aufgabe für das Geschäftspro-
zessmanagement formuliert. Deshalb wird in vielen Definitionen der Begriff Kun-
denorientierung angeführt.
Dies ist ein aktuelles Thema, wie auch der in der Einleitung schon angeführte IT-
Kompass 2016 zeigt. Nach dem wichtigsten Thema Optimierung der Geschäftspro-
zesse (59%) kam an zweiter Stelle nit 41% Nennungen Steigerung der Kundenzu-
friedenheit/Kundenbindung [Herrmann 2016, S. 24].
Es geht aber nicht nur, wie oben schon angemerkt, um die aktuellen Wünsche.
Wir haben es immer wieder und auch sehr stark in den letzten Jahren erlebt: Unter-
nehmen entwickeln neue Produkte oder Dienstleistungen, von denen die Kunden
noch nichts wissen, die sie aber zukünftig erwerben sollen. Z.B. neue Fernseh- und
Radiotechnologien, neue Datenträger (CD – DVD – BD), Self Publishing über das
Internet. Auch neue Formen vorhandener Leistungen werden ständig entwickelt,
z.B. die dynamische Preisfindung im Tourismus, die Sommerangebote in bisherigen
Winterregionen, die Kreativität bei der Gestaltung der Tarife für die Telekommuni-
kation, usw.. Diese potentiellen Wünsche (von denen man aber nicht weiß, ob sie
40 3 Geschäftsprozessmanagement
vom potentiellen Kunden auch wirklich angenommen werden), müssen auch be-
dacht werden.
Betriebswirtschaftliches und technologisches BPM
Geschäftsprozessmanagement hat, das ist oben sicher klar geworden, zum einen mit
betriebswirtschaftlichen Themen zu tun, zum anderen mit IT-Themen. Dies wird
auch in einigen Definitionen, vor allem aus dem Umfeld der Wirtschaftsinformatik,
thematisiert. So unterscheidet Scheer zwischen betriebswirtschaftlichem BPM und
technologischem BPM [Scheer et al. 2006, S. 6]. Für betriebswirtschaftliches BPM
findet man auch die Begriffe Business-BPM und fachliches BPM.
Ebenen des Geschäftsprozessmanagements
Entsprechend den oben eingeführen Managementebenen (Abbildung xxx) wird auch
das Geschäftsprozessmanagement eingeteilt in eine operativ, fachlich-konzeptionelle
und strategische Ebene eingeteilt [Gadatsch 2013, Pos. 784]:
Fachlich-konzeptionelle Ebene. Hier ist sozusagen das betriebswirtschaftliche
Geschäftsprozessmanagement angesiedelt mit Prozessabgrenzung, -
modellierung, -führung.
Operative Ebene. Hierzu gehören neben der Prozessüberwachung auch alle
Fragen rund um die Einbettung der Geschäftsprozesse in die IT, unabhängig da-
von, wie sie erfolgt: durch das Workflow-Management, die Entwicklung von
Anwendungssystemen, Kauf von ERP-Software, usw.
Strategische Ebene. Diese umfasst strategischen Fragen rund um die Prozessge-
staltung.
Automatisierung
Andere Definitionen weisen auf Automatisierungsaspekte hin. So die Fraunhofer-
Gesellschaft: „Unter Business Process Management (BPM) versteht man alle Akti-
vitäten, um die modellbasierten automatisierten Geschäftsprozesse (samt manuellen
Aktivitäten) eines Unternehmens (und unternehmensübergreifend) stets optimal
ablaufen lassen zu können" [Weißenberg und Stemmer 2009, S. 1].
Hier haben sich die Gewichte von den "manuellen Aktivitäten" hin zu den auto-
matisierten verschoben. Dies wird in Zukunft noch viel stärker so sein.
Lebenszyklus
Nehmen wir folgende Sichtweise ein: Ein funktionierender Geschäftsprozess ist eine
erbrachte Leistung, ähnlich einem Produkt. Geschäftsprozessmanagement betrifft
dann alle Aktivitäten rund um diese Leistung/dieses Produkt. In Anlehnung an die
"Produktlebenszyklustheorie" können dann die Lebensphasen eines Geschäftspro-
zesses wie folgt definiert werden:
Prozesse identifizieren und standardisieren
Prozesse modellieren, Erstellung eines Prozessmodells
Einbettung des Prozesses in die Prozesslandschaft
Prozesse einrichten
Prozesse durchführen und lenken
Prozesse pflegen
Prozesse überwachen, Controlling der Prozesse
3.1 Definition 41
Prozesse standardisieren und optimieren
Prozesse abwickeln
Damit sind die wichtigsten Tätigkeitsbereiche zusammengestellt, die im Rahmen des
Geschäftsprozessmanagements zu lösen sind.
Softwareseitige Sicht
Eine andere Sichtweise haben Autoren, die sich auf die Software zur Unterstützung
des Geschäftsprozessmanagements konzentrieren. Hier ist dann von Business Pro-
cess Management (BPM) und von BPM-Suiten die Rede. Als Hauptfunktionalitäten
solcher Softwareprodukte führen [Weißenberg und Stemmer 2009, Seite 1] an:
Business Process Analysis (Prozessmodellierung und -Analyse)
Business Process Execution (Prozessimplementierung und -Ausführung)
Business Activity Monitoring (Prozessmonitoring)
Portalunterstützung in allen obigen Phasen.
Es geht also um die softwareseitigen Aspekte, die Softwareunterstützung, um die
Umsetzung der gewonnenen Erkenntisse bzgl. Gestaltung, Optimierung, Festlegung
usw. in IT-Unterstützung oder Automatisierung.Vgl. dazu auch Abschnitt xxx.
Business Process Reengineering
Sehr oft werden in der Literatur diese Bemühungen um die optimierte Gestaltung
der Prozesslandschaft unter dem Begriff Business Process Reengineering behandelt.
Er steht dann als Oberbegriff für die Methoden zur prozessorientierten Umgestal-
tung betrieblicher Organisationsstrukturen. So auch Krallmann und Derszteler in
ihrem Beitrag in Mertens u.a. 1997, S.70. Ganz ähnlich Brenner und Hamm, wenn
sie definieren:
„Business Reengineering nach unserem Verständnis beschäftigt sich
mit den einzelnen Abläufen im Unternehmen und versucht, diese für
das Geschäft zu optimieren.“...„Ziel des Business Reengineering ist
es, die organisatorischen Abläufe eines Unternehmens neu zu gestal-
ten.“ [Brenner und Hamm 1995, S. 18]
Ebenso Becker und Meise mit einem Hinweis auf die Bedeutung der Prozesseffi-
zienz:
„Der Ansatz des Business Process Reengineering (BPR) ist stark pro-
zessorientiert, die Prozesseffizienz hat also Vorrang vor allen anderen
Kriterien.” [Becker und Meise 2012, S. 110]
Hohmann definiert genauso und gibt einen Hinweis auf die Notwendigkeit radikaler
Veränderungen:
„Im Kern geht es um die Optimierung der Ablauforganisation durch
Implementierung von durchgängigen Unternehmensprozessen. Neben
der Prozessorientierung steht die radikale Veränderung der Geschäfts-
prozesse (schneller, transparenter, kostengünstiger) im Mittelpunkt.“
[Hohmann 1999, S. 155]
Radikale
Veränderungen
42 3 Geschäftsprozessmanagement
Für Franz geht die Übereinstimmung noch weiter. Er sieht Business Process
Reengineering als Subsumierung der Begriffe Prozessorganisation, Prozessoptimie-
rung und Prozessmanagement Franz 1996.
Es versteht sich, dass Business Process Reengineering damit auch in engem Zu-
sammenhang mit den oben diskutierten Begriffen Kerngeschäftsprozesse und Kern-
kompetenzen steht. Um es mit Rupper zu sagen:
„Process Reengineering beginnt mit der Wertschöpfungsanalyse, d.h.
man analysiert je Tätigkeit resp. Prozessteil Deckungsbeiträge, akqui-
sitorische Werte etc. ..... Im nächsten Schritt wird eine Optimierung
der Wertschöpfung bewerkstelligt, ..... Im dritten Schritt werden die
Prozesse neu gestaltet, z.B. durch Konzentrieren auf Kernprozesse,
...., v.a. aber durch Neugestaltung der Abläufe im Sinne der Flussori-
entierung.“ [Rupper 1994, S. 10]
Die in der Literatur genannten Ziele des Business Process Reengineering ähneln
damit denen, die bei Geschäftsprozessen genannt werden.
Mitarbeiter
Führt man Geschäftsprozessmanagement in einer Organisation ein, stellt dies neue
Anforderungen an die Mitarbeiter. Sie sollten sich bewusst werden über den Pro-
zess, klar sehen, wo sie im Prozss wirken und wie die "benachbarten" Prozessab-
schnitte aussehen. Diese Prozessorientierung sollte zu entsprechendem Handeln
führen. Gewünscht wird auch, dass sich die Mitarbeiter "aktiv an der Steuerung und
Verbesserung der Geschäftsprozesse" beteiligen [Schmelzer und Sesselmann 2013,
S. 11]. Erwartet wird eine "Zunahme von Selbständigkeit und Eigenverantwortung
der Mitarbeiter" und eine "Abnahme von Anordnung und Aufsicht durch die Füh-
rung" [ebenda].
Projekte in diesem Bereich verlaufen nicht immer erfolgreich. Becker/Berning/-
Kahn haben Haltungen und Verhalten festgestellt, die nach ihrere Ansicht kritische
Erfolgsfaktoren für solche Projekte sind [Becker, Berning und Kahn 2012, S. 40ff]:
"Mit mir nicht" für Beharrungsvermögen/Verweigerung
"Not invented here" für mangelnde Akzeptanz von Lösungen, die von außen
kommen
"Macht ihr mal" für den Rückzug der Leitung aus dem Projekt
"Wir fangen schon mal an" für unreflektierten Übereifer
"Mal schauen, wie weit wir kommen" für mangelnde Zeitplanung
"Keine Zeit" für Zeitmangel
"Ist mir doch egal" für mangelnde Motivation
"Analyse/Partalyse" für mangelnde Umsetzung
Subjektorientiertes Prozessmanagement
Die an den Geschäftsprozessen beteiligten Menschen werden, so die Urheber des
subjektorientierten Prozessmanagements (auch: Social Business Process Manage-
ment und S-BPM), zu wenig berücksichtigt. Dies kann dazu führen, dass Prozesse
und vor allem Prozessänderungen von den Beteiligten nur zögerlich und nicht in
vollem Umfang angenommen werden. Deshalb dieser Vorschlag für Geschäftspro-
zessmanagement im Allgemeinen und Prozessmodellierung im Besonderen. In ihm
wird die Rolle der Mitarbeiter und die Rollen anderer Beteiligter am Geschäftspro-
3.1 Definition 43
zessmanagement besonders betont. Die Prozessbeteiligten (Subjekte) und deren
Interaktion werden in den Mittelpunkt gestellt, die natürliche Sprache wird für die
Beschreibung, Modellierung, Validierung und Optimierung der Geschäftsprozesse
verwendet.
Motiv für die Entwicklung dieser Vorgehensweise ist also die unzulängliche Be-
rücksichtigung der an den Geschäftsprozessen beteiligten Menschen. Im Hinter-
grund steht dabei der Wunsch, mit den ständigen Veränderungen besser klar zu
kommen, die durch die hohe Dynamik der Geschäftstätigkeit und der damit verbun-
denen Prozessanpassungen heutzutage notwendig sind.
Ausgangspunkt des Vorschlags ist die natürliche Sprache. In einem typischen
Satz gibt es ein Subjekt (Wer tut etwas?), ein Prädikat (Was wird getan?) und Ob-
jekte (Mit wem oder was wird etwas getan?). Das ist allerdings nichts neues, die
gängigen Modellierungsmethoden beruhen auch darauf. In Ereignisgesteuerte Pro-
zessketten beantworten z.B. die Organisationseinheiten das "Wer", die Funktionen
das "Was" und die Informationsobjekte das "Mit wem". Während dort aber dann der
Kontrollfluss (oder Sequenzfluss) in den Vordergrund rückt, soll das hier nicht so
sein. Hier sollen die Menschen als Subjekte in den Mittelpunkt rücken. Und mit
ihnen die für den Geschäftsprozess relevante Kommunikation zwischen ihnen, d.h.
die ausgetauschten Nachrichten. Ein Prozessmodell besteht somit aus Subjekten und
den Nachrichtenflüssen zwischen ihnen. Für jedes Subjekt wird dann in einem eige-
nen Modell der Ablauf im Detail dargestellt. Dieser enthält die Reihenfolge der von
dem Subjekt empfangenen und gesendeten Nachrichten, die von ihm durchgeführten
Einzelaktivitäten, Verzweigungen, usw.
Die Methode kennt in der Grundstruktur nur wenige Symbole:
für Subjekte (Rechteck mit Kopfteil zur Beschriftung)
für Nachrichtenflüsse (Pfeil)
für Zustandsübergänge (Pfeile mit Beschriftung)
für Geschäftsobjekte
für Tätigkeiten der Mitarbeiter mit Angabe des Zustandes (Rechteck mit Be-
schriftung und Markern)
für Anfangs- und Endzustände (Markierung im Rechteck, linke obere bzw.
rechte untere Ecke)
Vgl. (Fleischmann et al. 2011], z.B. die Abbildungen S. 34ff
Die Vorgehensweise ist wie folgt [ebenda]: Zuerst werden die am Prozess betei-
ligten prozessspezifischen Rollen, die Subjekte und die zwischen ihnen ausgetausch-
ten Nachrichten geklärt. Zu einer Nachricht können auch die evtl. vom Empfänger
benötigten Daten hinzugefügt werden. Es entsteht eine erste grafische Darstellung.
Danach wird betrachtet, "welche Aktivitäten und Interaktionen die Subjekte bei
der Erledigung des Vorgangs in welcher Reihenfolge ausführen" [Fleischmann et al.
2011, S. 34]. Dies wird in Form von beschreibenden Sätzen oder auch grafisch dar-
gestellt. Die grafische Form zeigt dann auf, in welcher Reihenfolge der Mitarbeiter
Nachrichten sendet, empfängt oder welche internen Aktionen er ausführt. Hier ist
von Zuständen und Zustandsübergängen die Rede, etwa so wie bei den Zustandsau-
tomaten der UML. Also von Sendezustand, Empfangszustand, usw. Ein solches
Modell entsteht für jeden Partizipanten, die Modelle der einzelnen Teilnehmer müs-
sen natürlich zueinander passen.
Obige Beschreibung kann die Komplexität nur andeuten. Tatsächlich müssen, das
machen auch die Ausführungen in [Fleischmann et al. 2011] deutlich, noch weit
44 3 Geschäftsprozessmanagement
mehr Modellinformationen zusammengestellt werden, um aussagekräftige Prozess-
beschreibungen zu erhalten.
Die Autoren gehen davon aus, dass das durch ein S-BPM-Modell spezifizierte
Verhalten der Prozessbeteiligten direkt als Grundlage für die Ausführung verwendet
werden kann. Die Prozessbeteiligten können damit eng in die IT-Entwicklung ein-
gebunden werden.
3.2 Rollen
Am Geschäftsprozessmanagement sind zahlreiche Personen mit unterschiedlichen
Aufgaben beteilitigt. In der Literatur werden dazu folgende Rollen genannt, die
Praxis zieht da nicht immer mit:
Chief Process Owner (Gesamtverantwortlicher für den Prozess)
Process Owner/Prozessmanager (verantwortet die laufende operative Steue-
rung). Diese Rolle ist in Unternehmen häufig etabliert.
Prozessmitarbeiter/Prozessexperte (unterstützen die erstmalige Implementierung
des Geschäftsprozessmanagements und Weiterentwicklung bei größeren Rest-
rukturierungen)
Prozessberater (Ausführung von konzeptionellen und ausführenden Projektar-
beitspaketen)
Prozess-/Workflowmodellierer (IT-orientierte Erhebung, Modellierung und
Spezifikation von Prozessen)
Projektleiter (Leitung des Geschäftsprozessmanagementprojekts)
Prozessauditor (unabhängige Prüfung von Arbeitsabläufen und Prozessverände-
rungsprojekten)
[Gadatsch 2015, Pos. 265f]
3.3 Software für Geschäftsprozessmanagement
Geschäftsprozessmanagement als eine umfassende Aufgabe kann auf vielfältige
Weise durch Software unterstützt werden. Z.B. durch ...
Visualisierung von Strukturen, Abläufen, Ergebnissen.
Modellierung von Geschäftsprozessen.
Simulation von Geschäftsprozessen.
Ausführung von Geschäftsprozessen im Rahmen des Workflow-Managements
(im Rahmen der ganzen oder teilweisen Automatisierung).
Oder, aber da verlassen wir den Bereich des eigentlichen Geschäftsprozessmanage-
ments, durch
Werkzeuge zur Systementwicklung (Case-Tools).
Die Liste deutet schon an, dass sehr unterschiedliche Typen von Software hier ge-
nannt werden können.
Die in der Praxis wichtigste Leistung ist die Erfassung von Prozessen in textlicher
und grafischer Form. Den größten Anteil haben umfassende integrierte Softwarepa-
kete, die sog. BPM-Suiten, mit knapp 50%. Es folgen ERP- und CRM-Systeme und
Produkte auf der Basis von Microsoft Sharepoint ([Zürcher Hochschule 2014, S.
40], zitiert nach [Gadatsch 2015, Pos. 601]).
3.3 Software für Geschäftsprozessmanagement 45
Es muss also sehr genau geprüft werden, welches Produkt benötigt wird. Geht es
um die Modellierung und Darstellung von Geschäftsprozessen, stehen diese Aspekte
und die unterstützten Methoden (z.B. Ereignisgesteuerte Prozessketten, Business
Process Diagramms) im Vordergrund. Geht es um die Prozessausführung sind hier
Workflowsysteme gemeint. Da muss dann die grundsätzliche Möglichkeit der Ab-
bildung des Geschäftsprozesses und die Fähigkeit, Änderungen am Prozess leicht
einzubauen, bedacht werden.
Anbieter und Produkte
Es gibt sehr viele Anbieter mit sehr unterschiedlichen Produkten, wobei hier die
Veränderungsrate sehr hoch ist. Es empfiehlt sich auf jeden Fall, die Aktualität der
Angaben zu überprüfen. Einen Eindruck vermitteln [Gadatsch 2015, Pos. 641],
[Adam, Koch, Neffgen et al. 2014) und [Weißenberg und Stemmer 2009).
Die Produkte stehen in unterschiedlicher Form zur Verfügung. Sie können ge-
kauft und auf eigener Hardware betrieben oder als Cloud-Lösung gemietet werden.
Modellierungswerkzeuge
Hier einige ausgewählte Produkte (in Klammern jeweils das anbietende Unterneh-
men):
Adonis Community Edition (BOC). Modellierung mit BPMN und anderen
Notationen wie Prozesslandkarte. Eingeschränkte freie Version
ARIS Business Architect (Software AG). Datenbankgestützte Modellierung mit
einer sehr großen Zahl (> 100) an Notationen wie eEPK, BPMN, Prozessland-
karte, daneben auch Datenmodellierung, Funktionsmodellierung u. a.
ARIS Express (eingeschränkte Version von ARIS Business Architect)
Signavio Process Editor (Signavio). Speziell für BPMN entwickeltes Werkzeug.
Unterstützt u.a. Ereignisgesteuerte Prozessketten und Wertschöpfungsketten.
BPMN-Suiten
Oben wurden schon die typischerweise unterstützten Aufgaben angeführt, die sich
auf Business Process Analysis und Execution sowie Business Activity Monitoring
und Portalunterstützungen konzentrieren [Weißenberg und Stemmer 2009, Seite 1].
Hier nur einige ausgewählte Produkte (in Klammern das anbietende Unternehmen).
Umfassende Listen auf dem Stand 2014 finden sich in [Adam, Koch, Neffgen et al.
2014, S. 124f] und [Gadatsch 2015, Pos. 652].
Bizagi Suite (Bizagi Ltd.). Hauptsitz Großbritannien, 2014 mehrfach als „Fina-
list" für BPM ausgezeichnet.
DHC Vision (DHC Business Solutions GmbH & Co. KG). Saarbrücker Unter-
nehmen mit Fokus auf Prozessunterstützung und regulatorischen Anforderun-
gen.
HCM VDoc Process (HCM Customer Management GmbH). Stuttgarter Unter-
nehmen, seit 2000 im Markt, Produkt erhielt 2014 den "Best of Industrie-IT"
Preis.
IBM BPM (IBM Deutschland GmbH). Produkt erhielt mehrfach internationale
Auszeichnungen durch Analysten.
BPM inspire (Inspire Technologies GmbH). Seit 2008 im Markt,
Mittelstandspreis und TÜV-Zertifizierung desProdukts.
46 3 Geschäftsprozessmanagement
Metasonic®Suite (Metasonic GmbH). Unternehmen aus Pfaffenhofen, seit 2004
imMarkt.
ORACLE BPM Suite (ORACLE Deutschland B.V. & Co. KG)
Quelle: [Adam, Koch, Neffgen et al. 2014, S. 124f], zitieret nach [Gadatsch 2015,
Pos. 653ff].
Soweit eine kleine Auswahl. In den Quellen finden sich mehr. Die OMG11
listet
über 150 meist kleinere Anbieter von BPM-Produkten.
Zusammenfassung
Ziel von Geschäftsprozessmanagement ist letztendlich, Effizienz und Effek-tivität so zu gestalten, dass die Wertschöpfung des Unternehmens gesichert und gesteigert wird. Dies soll durch eine ausgeprägte Kundenorientierung geschehen. Die konkreten Aufgaben lassen sich, wie im Management übli-che, in eine fachlich-konzeptionelle, eine operative und eine strategische Ebene aufteilen. In einigen Definitionen wird auch auf die IT-Unterstützung und die Automatisierung hingewiesen, sie spielt eine Rolle und sie muss - im Zusammenspiel von IT und Fachabteilungen ebenfalls bewältigt werden. Ganz ähnlich ist, wie wir gesehen haben, der Begriff des Business Process Reengineering definiert. Kompetentes Geschäftsprozessmanagement stellt Anforderungen an die Mitarbeiter, deshalb ist dabei ein behutsames Vorge-hen bei der Einführung des Geschäftsprozessmanagements erforderlich. Ein Versuch, die nach Meinung der Autoren unzulängliche Berücksichtigung der an den Geschäftsprozessen beteiligten Menschen zu korrigieren, ist das subjektorientierte Geschäftsprozessmanagement. In ihm wird die Rolle der Mitarbeiter und die Rollen anderer Beteiligter am Geschäftsprozessmana-gement besonders betont. Geschäftsprozessmanagement wird von vielen Personen getragen, auf die dabei üblichen Rollen haben wir anschließend einen Blick geworfen. Die Unterstützung des Geschäftsprozessmanage-ments durch Software haben wir abschließend betrachtet und sind dabei auch wieder auf den in diesem Kontext üblichen Begriff Business Process Management (BPMN) und den Softwaretyp BPMN-Suite gestoßen, der das Geschäftsprozessmanagement softwareseitig unterstützt.
11 Object Management Group
4 Geschäftsprozesse identifizieren und standardisieren
4.1 Identifikation
"Identifikation der Geschäftsprozesse" klingt merkwürdig, schließlich sind die Ge-
schäftsprozesse ja meist schon da, sonst gäbe es das Unternehmen oder die Organi-
sation nicht. Da gibt es die Leistungserstellung, die Beschaffung, die monatliche
Gehaltszahlung, usw. Trotzdem gibt es in der Praxis oft Unklarheiten über die ganz
konkrete "Gestalt" eines Geschäftsprozesses. Dies kann verschiedene Ursachen
haben:
Es herrscht tatsächlich Chaos in der Ablauforganisation in dem Sinne, dass die
Geschäftsprozesse zwar realisiert werden, aber mit vielen Schwachstellen. Da
gibt es dann Mehrfacharbeiten, vielleicht auch überflüssige Tätigkeiten, usw.
Kurz: Effektivität und Effizienz sind nicht in genügendem Umfang realisiert.
Dann gibt es Bereiche, in denen die Abläufe höchstens in den Köpfen der un-
mittelbar dort Aktiven klar ist. Falls möglich, sollte dies geändert werden
Unternehmen wurden verschmolzen, Prozesse müssen angeglichen werden.
Auch hier ist im ersten Schritt die Ientifizierung der Prozesse in den beiden Un-
ternehmen nötig, bevor der An- und Abgleich erfolgt.
Im Rahmen einer Optimierung werden die alten Geschäftsprozesse abgelöst und
durch neue ersetzt. Die neuen sind anders aufgebaut und eingebettet.
Im Rahmen eines Versuchs, die Automatisierung der Geschäftsprozesse voran-
zutreiben, werden die alten Geschäftsprozesse durch neue softwarebasierte er-
setzt. Dies erfordert meist die Einrichtung völlig neuer Geschäftsprozesse.
Deshalb gehört die Identifikation und die Abklärung der Geschäftsprozesse zu den
ersten Aufgaben des Geschäftsprozessmanagements. Konkret soll diese Prozessiden-
tifizierung klären, welche Geschäftsprozesse nötig sind, um die Wertschöpfung zu
realisieren.
Dabei muss die gesamte Prozesslandschaft berücksichtigt werden, denn (fast) kein
Geschäftsprozess ist isoliert. Die Prozesse einer Organisation sind miteinander und
mit Prozessen aus der Unternehmensumwelt verknüpft. Es werden also alle Ge-
schäftsprozesse und ihre Verknüpfung festgestellt oder auch festgelegt.
4.1.1 Top Down oder Bottom Up
Geschäftsprozesse können top down oder bottom up identifiziert werden. Je nach
den oben beschriebenen Szenarien muss die eine oder die andere Strategie gewählt
werden.
Top Down
Beim Top Down - Vorgehen löst man sich völlig von der vorhandenen Prozessland-
schaft und geht von den strategischen Planungen der Organisation aus. Von dieser
leitet man Schritt für Schritt die Geschäftsprozesse ab. Es eignet sich also bei vor-
48 4 Geschäftsprozesse identifizieren und standardisieren
handener Prozesslandschaft falls ein radikaler Neuanfang gewollt ist sowie bei einer
völligen Neuentwicklung mit oder ohne Automatisierungsabsicht
Der Rahmen für die Prozessgestaltung ist bei dieser Vorgehensweise vorgegeben
durch:
die Geschäftsstrategie mit ihren Geschäftsfeldern und Kundengruppen
die Geschäftsziele, dem Kundenbedarf und den Kundenanforderungen
dem Leistungsspekktrum
den strategischen Erfolgsfaktoren
der Wettbewerbsstrategie
den Kernkompetenzen
Vgl. [Schmelzer und Sesselmann 2013, S. 140].
Diese Punkte können ergänzt werden um die folgenden, die sich aus den aktuellen
Entwicklungen und Trends ergeben:
Wunsch nach teilweiser oder vollständiger Automatisierung. In diesem Fall
sollen ja die Möglichkeiten der Automatisierung genutzt werden, was natürlich
im Prozessdesign zu berücksichtigen ist.
Eventuelle Outsourcing-Pläne. Falls geplant ist, Teile der IT-gestützten Ge-
schäftsprozesse in die Cloud zu verlegen, hat dies Konsequenzen für das Design
der Prozesse. Zum Beispiel müssen die Schnittstellen zwischen den in die Cloud
verlgerten Geschäftsprozessen und den übrigen neu gestaltet werden. Unter
Umständen muss auch der Umgang der Geschäftsprozesse mit den Datenbe-
ständen angepasst werden.
Folgende Vorgehensweise ist bei dieser Strategie sinnvoll:
Identifizierung der primären Geschäftsprozesse (Kerngeschäftsprozesse). An
deren Anfang steht der Bedarf der externen Kunden, am Ende die Bereitstellung
der geforderten Leistungen an dieselbigen. Es entstehen Kurzbeschreibungen
der primären Geschäftsprozesse.
Die so gefundenen primären Geschäftsprozesse werden zerlegt in einzelne Ar-
beitsschritte und Subprozesse. Dabei entdeckte Optimierungspotentiale werden
genutzt/umgesetzt. Hierbei entstehen Sollprozesse. Im nächsten Schritt werden
die Automatisierungsmöglichkeiten ausgelotet: Welche Prozessabschnitte kön-
nen, welche sollen in Software gefasst werden. Falls der Prozess vollständig au-
tomatisiert werden soll, muss eine Prozessmodellierung für das Anforderungs-
management der Softwareentwicklung erfolgen.
Festlegung der sekundären Geschäftsprozesse.
Vgl. auch [Schmelzer und Sesselmann 2013, S. 140], [Gaitanides 2012, Pos. 152).
Wichtig ist, dass die Top Down - Neugestaltung der Prozesslandschaft von der Auf-
bauorganisation abstrahiert, da der Prozessgedanke ja die Überwindung der Aufbau-
organisation zur Grundlage hat.
Diese Vorgehensweise birgt Risiken und Chancen. Zu den Risiken gehören:
(1) Großer Aufwand. Schon die Modellierung der Primär- und Kernprozesse ist sehr
aufwändig, wenn man wirklich auch alle Sekundärprozesse so entwickeln möchte,
wird der Aufwand riesengroß. Letzteres ist auch u.U. nicht sinnvoll, da es dafür
Referenzprozesse gibt, die man, z.B. auch über eine entsprechende ERP-Software,
einfach geliefert bekommt.
4.1 Identifikation 49
(2) Ein solches Vorgehen ist teilweise eine Illusion. Wer auf diese Art und Weise
Geschäftsprozesse entwickelt, kann dies nur tun, wenn er eine Vorstellung von den
Geschäftsprozessen hat. Es gibt also durchaus eine Vorprägung, zumindest eine
abstrakte. Die Leistung besteht darin, mit dieser "Vorprägung" kompetent umzuge-
hen.
(3) Verlorener Realitätsbezug. Prozesse nach strategischen Vorgaben (Zielen) zu
erstellen, kann auch zu nicht realisierbaren Ergebnissen führen.
Zu den Chancen gehört, dass tatsächlich eine völlig neue Fassung wichtiger Ge-
schäftsprozesse entsteht. Wird dies kompetent realisiert, kann eine Optimierung
gegenüber der vorliegenden Situation erfolgen.
Bei einer sehr unterentwickelten Prozesslandschaft kann diese Vorgehensweise
vorteilhaft sein, weil eine solche sich nicht als Ausgangspunkt eignet. Für Sekun-
därprozesse ist sie aber nicht sinnvoll, hierfür gibt es standardisierte vorgedachte
Geschäftsprozesse, z.B. auch in ERP-Software.
Bottom Up
Das Bottom Up - Vorgehen geht von der bestehenden Prozesslandschaft und der
vorhandenen Aufbauorganisation aus. Folgende Schritte werden vorgeschlagen:
Erhebung und Modellierung der Istprozesse
Schwachstellenanalyse der Istprozesse
Modellierung von Sollprozessen, die auf den von Schwachstellen bereinigten
Istprozessen basieren.
In der Literatur wird diese Vorgehensweise nicht geschätzt. Dabei wird von einer
sehr unterentwickelten Prozessarchitektur ausgegangen und folgendes kritisiert
[Schmelzer und Sesselmann 2013, S. 141f]:
der große Aufwand für die Modellierung der Istprozesse
die Orientierung der vorhandenen Prozesse an Abteilungs- bzw. Organisations-
grenzen
Redundanzen zu anderen vergleichbaren Prozessen würden nicht erkannt
Vorgehen sei eher auf die Beseitigung von Schwachstellen als auf Chancennut-
zung ausgerichtet
der Istzustand würde nicht infrage gestellt und bliebe im Prinzip erhalten
Kreativität würde gehemmt
funktionales Denken würde konserviert
der direkte Bezug zu Kunden würde nicht hergestellt
der direkte Bezug zu strategischen Aspekten würde nicht hergestellt
die Durchgängigkeit der Geschäftsprozesse über Abteilungen, Unternehmen,
usw. sei nicht gesichert
Diese Kritikpunkte befremden etwas. Sie gehen wohl von einer sehr unterentwickel-
ten Prozesskultur aus, wie man sie zu Beginn der Phase der Prozessorientierung
tatsächlich vorfand. Inzwischen ist aber, so die Erfahrung des Verfassers, der Wis-
sensstand der Beteiligten und der Reifegrad der Prozesslandschaft so, dass die meis-
ten dieser Fehler vermieden werden (können).
Trotzdem bleibt es dabei: Dem Bottom Up - Vorgehen fehlt der Reiz des Neuan-
fangs und vieleicht macht dies den Top Down - Ansatz für viele so attraktiv.
50 4 Geschäftsprozesse identifizieren und standardisieren
Vorgedachte Geschäftsprozesse
Die Realität der Prozessgestaltung in den Unternehmen ist aber heutzutage sehr oft
eine völlig andere, als es oben erscheint. Meist werden vorgedachte Geschäftspro-
zesse einer integrierten prozessorientierten Standardsoftware (z.b. ERP-Software)
eingekauft (vgl. auch xxx). Da hat dann das "Finden" und die Gestaltung der Prozes-
se und ihre Abbildung in Software im "Standardsoftwarehaus" stattgefunden und
man prüft als Unternehmen letztendlich nur, welche der angebotenen Lösungen am
besten auf die eigenen Vorstellungen passen. Dies wird lediglich für Kerngeschäfts-
prozesse durchgeführt, bei Supportprozessen wird meist die Lösung der Integrierten
prozessorientierten Software gewählt.
Genauso, wenn wirklich mal ganz vorn vorne begonnen wird, z.B. im Rahmen
einer Neugründung oder einer völligen Neudefinition der Geschäftsprozesse. Dann
greift man für das Unternehmen ("Start up") oder den Unternehmensbereich
("CRM") in der Regel auf eine entsprechende für den Bereich erstellte Anwen-
dungssoftware zurück und damit auf deren vorgedachte Geschäftsprozesse.
Wo bleibt da das Geschäftsprozessmanagement, bzw. was bleibt davon übrig?
Nun, es findet vorab statt. Vor der Einführung der prozessorientierten Software. Die
gewünschten Geschäftsprozesse werden festgelegt, dann wird die Software gesucht,
die am besten den Vorstellungen entspricht. So wird es v.a. mit Supportprozessen
geschehen. Bei Kernprozessen wird die Vorgehensweise eher auf Eigenentwicklung,
Branchensoftware oder stark angepasste ERP-Software setzen.
4.1.2 Orientierungsrahmen für die Prozessgestaltung
Unabhängig davon, welche Strategie man für die Prozessfestlegung wählt, benötigt
man Kriterien, nach denen Prozesse identifiziert werden. Dies sind:
Zielmärkte und Kundengruppen
Kundenbedürfnisse, -anforderungen und -erwartungen,
Wettbewerbsstrategie
Produkt- und Leistungsprogramm
Kernkompetenzen
Geht es dann um die Gewichtung der Geschäftsprozesse sind folgende Angaben
wichtig:
kritische Erfolgsfaktoren des Geschäftes
Wettbewerbsstrategie
Kernkompetenzen
Stärken und Schwächen des Geschäftes
Diese Daten sollten den strategischen Festlegungen entnommen werden können
(vgl. auch [Gaitanides 2012, S. 154ff], [Schmelzer und Sesselmann 2013, S. 143]).
4.2 Standardisierung
In diesem Abschnitt wird die in Abschnitt 2.8 eingeführte Unterscheidung von Pro-
zessmodell und Prozessinstanz benötigt. Das eine ist sozusagen die allgemeine Pro-
zessvorstellung, das andere die konkrete Realisierung eines Prozessdurchgangs.
4.2 Standardisierung 51
Quellen des Standardisierungsbedarfs
Wer in einem hinreichend großen Unternehmen tätig ist, kennt es. Ein Geschäfts-
prozess wird an verschiedenen Stellen im Unternehmen unterschiedlich realisiert.
Nicht die Instanzen, das ist immer so, sondern der Prozess als solcher. Die "allge-
meine Prozessvorstellung" ist also in Unternehmensbereichen oder auch Abteilun-
gen unterschiedlich. Dies ist in einer Zeit, in der schon mittelständische Unterneh-
men weltweit Tochtgesellschaften oder Vertretungen haben, ein wichtiges Thema:
In einem Unternehmen mit Tochtergesellschaften im nationalen Rahmen wer-
den u.U. dieselben Prozesse in den Tochtergesellschaften auf unterschiedliche
Weise durchgeführt.
In einem international agierenden Unternehmen sind in den jeweiligen nationa-
len Gesellschaften Geschäftsprozesse unterschiedlich realisiert. Und dies nicht
wegen kultureller Unterschiede oder wegen Unterschieden in Bezug auf rechtli-
che und gesetzliche Festlegungen.
Eine weitere Quelle für den Standardisierungsbedarf ist das Verschmelzen von Un-
ternehmen ("Merging"). Dabei treffen oft ganz unterschiedliche Prozesskulturen
aufeinander und ganz unterschiedliche Realisierungen derselben Prozesse.
Diese Vielfalt ist in der Regel nicht erwünscht und soll beseitigt werden. Sie ist
auch sinnvoll, weil ihre Beseitung die Abbildung des Prozesses in eine IT-Lösung
wesentlich erleichtert bzw. erst sinnvoll erscheinen lässt.
Eine Standardisierung ist allerdings nur sinnvoll, wenn der Geschäftsprozess vie-
le Routineanteile enthält. Sie lohnt sich auch nur, wenn der Geschäftsprozess häufig
realisiert wird. Meist treten diese beiden Merkmale auch zusammen auf. Sie ist nicht
sinnvoll, wenn es sich um kreative oder chaotische Prozesse handelt (vgl. Abschnitt
xxx).
Vorteile der Standardisierung:
Die Standardisierung bringt zahlreiche Vorteile. Sie schafft ein einheitliches Er-
scheinungsbild gegenüber den Kunden und Lieferanten, gewährleistet einheitliche
Unternehmensschnittstellen mit Kunden Lieferanten und Partnern und erleichtert die
Kommunikation.
Auch der Personaleinsatz wird erleichtert:
Schulungen sind einfacher, müssen nicht in "Varianten" durchgeführt werden.
Personal ist leichter austauschbar
einheitliche Rollenbeschreibungen und Verantwortungsregelungen werden
geschaffen
Prozesstransparenz (Prozessstrukturen, -Schnittstellen,-leistungen) wird erhöht,
was zu einer Senkung des Koordinationsaufwands führt
IT-Applikationen können harmonisiert werden
Vgl. [Schmelzer und Sesselmann 2013, S. 239], [Hammer 2010, S. 11], [Gaitanides
2012, S. 139]
Nachteile/Risiken der Standardisierung:
Obwohl die Standardisierung heute unumgänglich ist, weil ohne sie IT-Untersützung
kaum möglich ist, gibt es auch Nachteile bzw. Risiken, die aber nicht die Standardi-
sierung als solche, sondern deren Realisierung betreffen:
52 4 Geschäftsprozesse identifizieren und standardisieren
Falls Geschäftsprozesse standardisiert werden, deren Unterschiede durch Kun-
denwünsche oder regionale Besonderheiten begründet sind und die besser erhal-
ten geblieben wären. Dies kann zu Einbußen an Flexibilität, Kundennähe und
Wettbewerbsvorteilen führen. In einem solchen Fall ist es sinnvoller, Varianten
des Prozesses zu etablieren und nur die Abschnitte der Prozesse zu standardisie-
ren, die nicht diese wichtigen Besonderheiten aufweisen.
Falls in der Standardisierung nicht die beste Lösung durchgesetzt wird. Es ist
immer darauf zu achten, dass die leistungsstärkste Variante zum Standard ge-
macht wird.
Identifikation und konkrete Abklärung der Geschäftsprozesse gehören zu den ersten
Aufgaben des Geschäftsprozessmanagements. Eine wichtige Aufgabe ist dabei, die
Geschäftsprozesse zu identifizieren, mit denen die Wertschöpfung realisiert wird.
Dies kann Top Down oder Bottom Up erfolgen, je nach Situation im Unternehmen
und unter Berücksichtung der jeweiligen Chancen und Risiken. Eine wichtige Rolle
spielt in diesem Zusammenhang, dass sehr oft "fertige" Geschäftsprozesse im Rah-
men einer prozessorientierten Standardsoftware ins Unternehmen kommen. Diese
vorgedachten Geschäftsprozesse prägen schon seit einiger Zeit die Prozesswirklich-
keit und werden es in Zukunft noch stärker tun. Prozessstandardisierung meint das
Angleichen unterschiedlicher Versionen eines Geschäftsprozesses. Dies ist nötig, es
sollte allerdings die beste der Varianten zum Standard gemacht werden.
5 Ist- und Sollmodellierung
5.1 Istmodellierung
Eine Bestandsaufnahme der bestehenden Geschäftsprozesse wird Istmodellierung
genannt. Sie kann sich auf einzelne Geschäftsprozesse oder auf Teile der Prozess-
landschaft beziehen. Die Erhebung muss, soll sie aussagekräftig sein, umfassend
erfolgen. Nur dann können Defizite gefunden werden.
Sie kann auf verschieden Ebenen erfolgen, abhängig von der Zielsetzung. Geht es
darum, Defizite und Optimierungsmöglichkeiten aufzudecken, wird die Ebene der
Standardprozessmodellierung gewählt. Geht es um Überblicksgewinnung wird eine
höhere Aggregationsebene gewählt.
Erhoben werden alle Komponenten (Träger, Aufgaben, ...) und ihr Zusammen-
hang (Kontroll- und Nachrichtenflüsse, evtl. andere Flüsse), soweit sie für die Mo-
dellierungsebene notwendig sind.
Prägung durch Zielsetzung)
In Fortsetzung der "Subjektivitätsfaktoren der Prozesserfassung" von xxx hier ein
weiterer, der durch die Zielsetzung der Prozessmodellierung entsteht. Diese können
auf unterschiedliche Weise die konkrete Ausgestaltung der Istmodellierung stark
prägen. Oftmals sind diese Zielsetzungen durch tatsächliche oder vermutete Defizite
motiviert. In [Staud 2006, Abschnitt 6.2] wird ein Geschäftsprozess vorgestellt, in
dem dies sehr deutlich wird. Modelliert wird eine ganze Auftragsabwicklung eines
mittelständischen Unternehmens. Der Schwerpunkt lag aber auf der Frage, inwie-
weit die Erstellung der hierbei notwendigen CAD-Unterlagen durch die Einführung
eines leistungsstärkeren CAD-Systems verbessert werden könnte. Deshalb wird in
Prozessabschnitten, die dies thematisieren, die Modellierung sehr detailliert, wäh-
rend sie an anderen Stellen, wo es eigentlich nur darum ging, die Lücke zu schlie-
ßen, um den Prozess als Ganzes modellieren zu können, höher aggregiert, ja sogar
oberflächlich wird.
5.1.1 Werkzeuge
Werkzeuge für die Istmodellierung (für die Darstellung von Modellen) sind
die natürliche Sprache,
Formulare für die Prozessbeschreibung,
Methoden zur Prozessmodellierung wie Ereignisgesteuerte Prozessketten und
die BPMN.
Dokumentation von Geschäftsprozessen in Tabellen
Neben der Dokumentation von Geschäftsprozessen in Prozessmodellen, die wir in
den folgenden Kapiteln intensiv betrachten werden, ist meist auch eine tabellarische
54 5 Ist- und Sollmodellierung
Beschreibung von Geschäftsprozessen notwendig. Ein einfaches Formular zur Erhe-
bung von Prozessinformationen ist in der folgenden Abbildung angegeben.
Prozessbezeichnung
Datum Ersteller
Auslöser Ergebnisse Rollen
Prozessverantwortliche(r)
Beteiligte
Zu Informieren
Prozessschritt Verantwortlich Input Output IT-Einsatz DB-Zugriff
.....
Bemerkungen
Formular zur Prozessbeschreibung
Hier einige Anmerkungen zu den Feldern, soweit sie nicht selbsterklärend sind (in
Klammern jeweils die Ausprägung eines Beispiels Nachbestellung):
In der ersten Zeile werden die Bezeichnung des Prozesses (z.B. Nachbestel-
lung), das Datum der Erstellung der Beschreibung und der Name des Erstellers
angegeben.
Auslöser des Prozesses (Nachbestellanforderung aus dem Lager)
Ergebnisse: Ergebnisse des Prozessablaufs (Nachbestellung oder Ablehnung
derselbigen)
Rollen xxx
Prozessverantwortliche(r): Person oder Software, die für den Prozess verant-
wortlich ist (Lagersoftware)
Beteiligte (Lagermitarbeiter)
Zu informieren: Personen, die über die Prozessabwicklung informiert werden
müssen.
Anschließend wird zeilenweise jeder Prozessschritt dokumentiert.
Verantwortlich: verantwortliche Stelle
Input: verwendete Informationen
Output: entstehende Informationen
IT-Einsatz
DB-Zugriff: Zugriffe auf die Datenbanken des Unternehmens
In [Schwegmann und Laske 2012, S. 172f] findet sich ein umfassender Vorschlag
für einen solchen "Prozess-Steckbrief".
5.1.2 Zweck?
Die Istmodellierung erfolgt zu unterschiedlichen Zwecken. Wenn sie nicht zu Do-
kumentationszwecken erfolgt (z.B. im Rahmen einer ISO-Zertifizierung), dann
meist zur Beseitigung von Schwachstellen. Dazu mehr im nächsten Abschnitt. Wei-
tere Ziele werden, unter dem Stichwort Einsatzzwecke von Prozessmodellen in [Be-
cker, Kugeler und Rosemann 2012, S. 199f] genannt:
Organisationsdokumentation. Z.B. für aktuelle Beschreibungen der Geschäfts-
prozesse.
5.1 Istmodellierung 55
Prozessorientierte Reorganisation. Revolutionär oder evolutionär
Kontinuierliches Prozessmanagement. Auf Dauerhaftigkeit ausgerichtete Pla-
nung, 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 Unternehmensres-
source Wissen.
Modellbasiertes Customizing12. Parametrisierung der Software
Softwareentwicklung. Als Teil der Anforderungsbeschreibung.
Workflowmanagement. Prozessmodelle als Grundlage für die Erstellung von
Workflowmodellen.
Simulation. Untersuchung des Systemverhaltens im Zeitablaufmit dem Ziel der
Prozessoptimierung.
Ein wichtiges Ziel ergibt sich bei der Einführung einer prozessorientierten Standard-
software (z.B. ERP-Software). Der Vergleich der konkreten vorliegenden Ge-
schäftsprozesse mit den vorgedachten der prozessorientierten Software. Die dabei
entdeckten Unterschiede müssen dann auf die eine oder andere Weise bewältigt
werden. Es muss also eine detaillierte Istmodellierung erfolgen.
5.1.3 Mögliche Schwachstellen
Es gibt zahlreiche mögliche Schwachstellen, die man bei einer Istmodellierung ent-
decken kann. Besonders wichtig sind die in Abschnitt xxx angesprochenen Defizite
in der Daten- und Prozessintegration. Aus ihnen entstehen Medien- und Organisati-
onsbrüche. Medienbrüche sind, wenn genügend detailliert modelliert wurde, im
Prozessmodell leicht erkennbar. Die entsprechenden Informationsobjekte müssen
mehrfach erhoben werden, Übertragungs- und Transportvorgänge liegen vor. Orga-
nisationsbrüche sind ebenfalls in der Modellierung erkennbar, auf unterschiedliche
Weise. Zu übergebende Information muss angepasst werden. Zuständigkeiten wech-
seln, obwohl nicht sachlich begründet. Solche Defizite treten heute meist nur an
Unternehmensgrenzen auf, nicht mehr innerhalb der Organisationen.
Hier noch weitere Beispiele für Defizite, die bei Istanalysen entdeckt werden
können:
zu lange Transportzeiten von Prozessobjekten (Dokumente, Rechnungen, CAD-
Zeichnungen, usw.; im Bürobereich ganz allgemein von Vorgängen)
zu lange Warte- und Liegezeiten von Prozessobjekten
zu lange Bearbeitungs-, Rüst- und Prozessdurchlaufzeiten
redundante Tätigkeiten
hohe Fehlerraten
zu lange Kommunikations- und Entscheidungswege
Andere Schwachstellen erkennt man erst bei intensiver Analyse von Prozessmodell
und -instanz(en) (vgl. xxx):
12 Mit dem Begriff Customizing wird die Anpassung der Standardsoftware (z.B. der ERP-Software) an
die realen Prozesse bezeichnet. Zumindest der größere Teil dieser Anpassung soll bei Standardsoft-
ware so ablaufen, dass nicht programmiert werden muss, sondern dass nur die wie auch immer ge-
stalteten Parameter der Standardsoftware verstellt werden. Ein eventueller Rest kann dann mit einer
mitgelieferten Programmiersprache erledigt werden.
56 5 Ist- und Sollmodellierung
zu hohe Komplexität
unzureichendes Prozessdenken (konkret: unzureichendes Verständnis für vor-
und nachgelagerte Prozessabschnitte bei den Beteiligten)
zu hohe Gesamtkosten der Prozesse
zu wenig Transparenz, was u.U. auch die Veränderung von Geschäftsprozessen
behindert
Erst durch zusätzliche Analyse des Geschäftsprozessmanagements erkennt man
Defizite wie:
mangelnde Prozessorientierung
unzulängliche Prozessverantwortlichkeiten
fragmentierte Verantwortlichkeiten
5.2 Sollmodellierung
Aufbauend auf der Istmodellierung und den dabei entdeckten Schwachstellen (und
weiterer Schwachstellenanalysen) kann die Erstellung von Prozessmodellen erfol-
gen, in denen die Schwachstellen beseitigt sind. Dies wird Sollmodellierung ge-
nannt, die dabei entstehenden Geschäftsprozesse werden auch Sollprozesse genannt.
Es geht also um Geschäftsprozessoptimierung, die schrittweise Beseitigung von
Schwachstellen der vorhandenen Prozesse. Dazu im Gegensatz steht die radikale
Neugestaltung des Geschäftsprozesses, das sog. Business Process Reengineering
(vgl. xxx)
Konkrete Maßnahmen
Eine sehr umfassende Zusammenstellung von möglichen konkreten Maßnahmen bei
der Restrukturierung von Geschäftsprozessen findet sich bei Gadatsch:
Überprüfung der Notwendigkeit von Prozessen oder Teilprozessen zur Funkti-
onserfüllung, Abschaffung von Medienbrüchen, Abschaffung von nicht sinnvol-
len Genehmigungsschritten.
Vergabe von Teilprozessen oder vollständigen Prozessketten durch externe
spezialisierte Dienstleister (z. B. Buchführung und Bilanzierung durch einen
Steuerberater)
Arbeitsteilige Aufgaben werden so zusammengefasst, dass ein Bearbeiter zu-
sammengehörige Teilprozesse vollständig ohne Bearbeiterwechsel durchführt
(z. B. Kundenberatung und Auftragserfassung bis zur Erstellung der Auftrags-
bestätigung)
Erhöhung der Arbeitsteilung bei parallelisierbaren Teilschritten (z. B. Klausur-
korrektur durch mehrere Prüfer je Teilgebiet)
Verlagerung von Prozessschritten so dass Aufgaben frühzeitig durchgeführt
werden, ohne später zu einem Flaschenhals zu werden (z. B. vollständige Erfas-
sung der Kundeninformationen bei Auftragserfassung)
Einsatz von zeitsparenden Arbeitsmitteln. (Dokumentenmanagementsystem
ersetzt Papierdokumentation), Reduzierung von Warte- und Liegezeiten durch
Erhöhung von Kapazitäten
Schleifenfreie Gestaltung von Prozessen, d. h. Verzicht auf Wiederholung von
Teilschritten eines Prozesses (z. B. Onlineerfassung aller Kunden- und Bestell-
daten im Rahmen der Auftragserfassung und Freigabe des Auftrages erst nach
vollständiger Plausibilisierung der Daten)
5.3 Prozessmodellierung morgen 57
Vermeidung von nachgelagerten Prozessen zur „Schadensbeseitigung" (z. B.
Ergänzung einer Qualitätskontrolle nach der Teilemontage um einen möglichen
„Nachbearbeitungsprozess" oder eine „Rückholaktion fehlerhafter Ware" zu
vermeiden
[Bleicher 1991], zitiert nach [Gadatsch 2015, Pos. 478].
5.3 Prozessmodellierung morgen
Der Trend zur Automatisierung der Geschäftsprozesse, d.h. ihrer Abbildung in
Software, hält weiter an und ist in einigen Bereichen schon realisiert. Dies hat Kon-
sequenzen für die Prozessmodellierung. Sie wird in Zukunft so aussehen:
Die erste Prozessmodellierung muss eine Standardprozessmodellierung sein. Das
ist die Ebene auf der Geschäftsobjekte sichtbar sind und Prozesshandeln erfasst
werden kann, so dass die Modellierung des Kontrollflusses ohne Schwierigkeit mög-
lich ist. Hierfür sind die Ereignisgesteuerten Prozessketten aufgrund ihrer „wohl-
tuenden Abgehobenheit“ und ihrer für die Prozessmodellierung geeigneten Theorie-
elemente die Methode der Wahl.
„Darunter“ sollte eine programmnahe Prozessmodellierung sein – zur direkten
Vorbereitung der Systemanalyse und des Software Engineering, also als Teil des
Requirement Engineering. In der heutigen Situation sind dafür Aktivitäten und Zu-
standsautomaten der UML und die BPMN die Werkzeuge der Wahl. Für Detailana-
lysen, wenn eine bestimmte Situation programmtechnisch intensiv zu hinterfragen
ist, sind Sequenzdiagramme sehr hilfreich. Hier kommen also Prozessmodellierung
und Systemanalyse zusammen.
Für die Ebenen über der Standardprozessmodellierung (Grobmodellierungen)
können die üblichen Übersichtsnotationen erstellt werden. Z.B. mit aggregierten
Funktionen in EPKs oder BPDs. Etwa so wie in der früheren Unternehmensmodel-
lierung der SAP durch Szenarios (vgl. Kapitel 8 in [Staud 2006) für eine Kurzdar-
stellung).
Auf der obersten Eben bleiben die klassischen Wertschöpfungsketten ein sinnvol-
les Instrument. Hier sind dann meist ganze Abteilungen mit ihren Tätigkeiten in
einem Element zusammengepackt und der Kontrollfluss drückt da lediglich die
Abfolge dieser hochaggregierten Handlungseinheiten aus. Auch hierzu findet sich
eine Kurzdarstellung in oben genannter Quelle [Staud 2006, Abschnitt 8.2.3).
Damit ergeben sich sinnvolle Ebenen für die vertikale Dimension der Prozessmo-
dellierung.
58 5 Ist- und Sollmodellierung
Zusammenfassung Mit einer Istmodellierung wird ein Geschäftsprozess er-
hoben. Dies erfolgt so, dass möglichst viele Defizite ge-
funden werden. Werkzeuge dafür sind die natürliche
Sprache, Formulare und - vor allem - Methoden zur
Prozessmodellierung. Gründe für eine Istmodellierung
gibt es viele, nicht nur die Dokumentation und die Be-
seitigung von Medien- und Organisationsbrüchen. Bei
einer kompetent durchgeführten Istmodellierung können
zahlreiche weitere Defizite in Geschäftsprozessen ge-
funden werden. Aufbauend auf der Ist -Modellierung
und den dabei entdeckten Schwachstellen kann dann die
Erstellung von Prozessmodellen erfolgen, in denen die
Schwachstellen beseitigt sind. Dies wird Sollmodellie-
rung genannt.
6 Strategisches Geschäftsprozessmanagement
Das strategische Geschäftsprozessmanagement ist eingebettet in das Strategische
Management. Dieses befasst sich mit der Geschäftstätigkeit des Unternehmens und
wie dieses optimal gestaltet werden kann. Dazu gehört auch die Klärung der Er-
folgsfaktoren und der Kernkompetenzen. Ausgangspunkt ist dabei die strategische
Zielsetzung der Organisation, die Geschäftsstrategie. Strategisches Management hat
also - mit anderen Worten - die Aufgabe, das Fortbestehen des Unternehmens lang-
fristig zu sichern.
Für das gesamte Unternehmen
Die Aufgaben des strategischen Managements beziehen sich auf das gesamte Unter-
nehmen, nicht auf die einzelnen Geschäftsprozesse. Zu ihnen gehören:
Festlegung und Analyse der Geschäftsfelder
Festlegung der Geschäftsstrategien, inklusive der Wettbewerbsstrategien
Festlegung der Geschäftsziele
Bestimmung der Kernkompetenzen
Klärung der strategischen Erfolgsfaktoren
Bestimmung von Erfolgspotentialen
Entwicklung einer Unternehmensvision und eines Unternehmensleitbildes
Auch die Wahrnehmung von organisationsrelevanten Veränderungen in Technik,
Politik, Wirtschaft und Gesellschaft muss hier geleistet werden:
Erkennen von sich ändernden Rahmenbedingungen ("Dieselmotoren kaum noch
durchsetzbar im US-Markt")
Erkennen von Risiken bzw. Chancen
Erkennen von Schwächen und Stärken (IBM: "in Hardware können wir nicht
mehr mithalten"; "IT-gestützte Dienstleistungen könnten sich als tragfähig er-
weisen")
Identifizierung von zukünftigen Tätigkeitsfeldern, Geschäftsfeldern und strate-
gischen Geschäftseinheiten ("nationale Cloud-Angebote")
In Anlehnung von [Schmelzer und Sesselmann 2013, S. 18].
Zu den Aufgaben des strategischen Managements gehört auch die Klärung der Rolle
des Geschäftsprozessmanagements im Unternehmen:
Wie ist das Geschäftsprozessmanagement langfristig auszurichten (Prozessvisi-
on, strategische Prozessziele)?
Wie soll die organisatorische Verankerung des Geschäftsprozessmanagement-
systems im Unternehmen umgesetzt werden, welche Rollen werden definiert
und eingerichtet.
Teil des strategischen Managements ist das strategische Geschäftsprozessmanage-
ment. Hier bauen die Überlegungen auf obigem auf, konzentrieren sich aber auf die
60 6 Strategisches Geschäftsprozessmanagement
Geschäftsprozesse. Dabei geht es um die langfristige Ausrichtung, Ausgestaltung
und Ausstattung der Geschäftsprozesse und des Geschäftsprozessmanagementsys-
tems. Im Fokus stehen alle wettbewerbsrelevanten Geschäftsprozesse. Diese sind in
der Regel Kerngeschäftsprozesse / primäre Geschäftsprozesse.
Zu den Zielen gehören:
Planung von Prozessvision und Prozessmission. Die Prozessvision beantwortet
die Frage, was das Unternehmen in Zukunft mit Geschäftsprozessmanagement
erreichen möchte. Die Prozessmission setzt die Prozessvision um.
Klärung der Abhängigkeiten zwischen der Geschäftsstrategie und den Ge-
schäftsprozessen, denn bei konsequenter Umsetzung stellt das strategische Ge-
schäftsprozessmanagement diese Verbindung her [Schmelzer und Sesselmann
2013, S. 82).
Identifizierung, Planung und Gestaltung der Geschäftsprozesse.
Festlegung der Prozessziele anhand der strategischen Unternehmenssziele.
Einschätzung der Geschäftsprozesse hinsichtlich ihrer strategischen Bedeutung.
Klärung der Kernkompetenzen und Kerngeschäftsprozesse und Erkennen der
diesbezüglichen Veränderungen ("mit Kontoführung allein kann man nicht
mehr überleben" bzw. "mit Darlehensvergaben ist angesichts der Zinssätze
kaum mehr etwas zu verdienen")
Klärung des Zusammenhangs von Kernkompetenzen und Geschäftsprozessen
hinsichtlich des Ziels, die strategischen Prozessziele zu erreichen.
Klärung der Auswirkungen der Wettbewerbsstrategie auf die Geschäftsprozesse
Klärung der Automatisierungsmöglichkeiten, zusammen mit dem IT-
Management.
Möglichkeiten und Grenzen des Outsourcing und Cloud Computing klären
(zusammen mit dem IT-Management).
Die letzten beiden Punkte deuten wichtige Koordinierungsaufgaben an, die derzeit
auch noch an Bedeutung gewinnen. Dies betrifft insbesondere die Abstimmung von
Prozess- und IT-Strategie.
6.1 Prozessvision und Prozessziele
Zentrale Konzepte des strategischen Geschäftsprozessmanagements sind Prozessvi-
sion und Prozessziele.
Prozessvision
Eine Prozessvision sollte ...
nachvollziehbar sein
langfristigen Interessen entsprechen
realistische Ziele enthalten
ausreichend spezifisch sein
flexibel sein, indem sie auch bei veränderten Bedingungen Gültigkeit besitzt
leicht verständlich sein
Mit [Schmelzer und Sesselmann 2013, S. 83f].
6.2 Kernkompetenzen 61
Prozessziele
Die Prozessziele werden aus den Unternehmenszielen abgeleitet. Sie sind mit geeig-
neten Prozesskennzahlen verbunden und werden auf der Basis der Geschäftsziele
und unter Berücksichtigung der Erfolgsfaktoren (strategische, kritische) definiert.
An diesen Zielen wird dann auch der Erfolg gemessen (vgl. Kapitel xxx). Besteht
zum Beispiel das Prozessziel, Marktführer zu werden, müssen die Ziele für die ein-
schlägigen Geschäftsprozesse entsprechend formuliert werden, z.B. in der Entwick-
lung ("jedes Jahr ein neues Produkt"), im Vertrieb ("Auslieferung innerhalb eines
Tages") und bei der Leistungserbringung ("Fehlerquote unter 0,5%).
Während bei Kerngeschäftsprozessen die Prozessziele recht spezifischer Natur
sein können ("Neue Benutzeroberfläche für das neue Smartphone weitgehend
selbsterklärend") fallen sie bei Supportprozessen meist zurück auf das Ziel mög-
lichst großer Effektivität und Effizienz.
6.2 Kernkompetenzen
Im Zusammenhang mit strategischen Überlegungen spielen die Kernkompetenzen
des Unternehmens eine zentrale Rolle. Sie sollten so etwas wie Alleinstellungs-
merkmale darstellen. Sie müssen gefunden, gepflegt und u.U. hinzugewonnen wer-
den. Bei effektivem Einsatz (meist in Kerngeschäftsprozessen) führen sie zu dauer-
haften Wettbewerbsvorteilen, die von den Mitbewerbern nur schwer imitiert oder
substituiert werden können. Insbesondere für den langfristigen Unternehmenserfolg
sind sie von zentraler Bedeutung.
Der Begriff spricht die besonderen Fähigkeiten an, die bei den einzelnen Mitar-
beitern vorliegen oder die durch das Zusammenwirken von Mitarbeitern (in Abtei-
lungen, Projekten oder sonst wie) entstehen. Auch der Einsatz von Technologien
("Erstellung, Pflege und ständige Optimierung der Präsenz im E-Commerce") kann
eine Kernkompetenz darstellen.
Kernkompetenzen entstehen meist nicht durch das Wirken Einzelner, sondern
durch Zusammenarbeit in Gruppen oder Belegschaften. So auch Becker/Meise:
„Erst die Integration einzelner Kompetenzen zu einer neuen, übergreifenden und
schwer nachzuahmenden Fähigkeit führt zu einer echten Kernkompetenz.“ [Becker
und Meise 2012, S. 101].
Kriterien für Kernkompetenzen sind:
Es muss ein grundlegender Nutzen für den Kunden geschaffen werden, bzw. es
muss ein Nutzen geschaffen werden, für den der Kunde bereit ist, Geld auszu-
geben.
Sie dürfen nicht Allgemeingut sein, sondern müssen das Unternehmen aus dem
Kreis der Wettbewerber hervorheben (z.B. durch die Produktion technologisch
hochwertiger und qualitativ führender Bohrmaschinen oder Kraftfahrzeuge).
Sie muss nicht nur kurzfristige Bedeutung besitzen13
.
Für eine vertiefte Diskussion vgl. [Becker und Meise 2012, S. 102f].
13 Becker/Meise fordern hier eine „langfristige Bedeutung“. Dem kann angesichts der schnellen Um-
wälzungen in Wissenschaft und Technik nur eingeschränkt zugestimmt werden. Auch Kompetenzen
können heute über Nacht wertlos werden oder ihr Profil verändern.
62 6 Strategisches Geschäftsprozessmanagement
6.3 Ergebnisse
Die möglichen Ergebnisse des strategischen Geschäftsprozessmanagements sind die
Lösungen zu den oben angesprochenen Aufgaben. Zum Beispiel:
Bessere Integration der verschiedenen Managementsysteme
Outsourcing von Geschäftsprozessen bzw. Verlagerung von Prozessaufgaben in
Shared Service Center
Oualifizierungsprogramme für Prozessmitarbeiter
Einführung einheitlicher Methoden zur Prozessverbesserung wie z. B. Kaizen
Einführung der Prozesskostenrechnung
Einführung einheitlicher BPM-Tools und -Systeme in Abstimmung mit der IT-
Strategie
[Schmelzer und Sesselmann 2013, S. 86]
Prozessplanung
Während sich die operative Prozessplanung zumeist über ein bis zwei Jahre er-
streckt, liegt er bei der strategischen Prozessplanung meist zwischen drei und fünf
Jahren. Für die operative Umsetzung wird aus dem strategischen Prozessprogramm
ein Jahresprogramm für die einzelnen Geschäftsprozesse mit den Geschäftsprozess-
verantwortlichen vereinbart [Schmelzer und Sesselmann 2013, S. 87].
Methoden, Instrumente
Für diesen Bereich des Managements gibt es zahlreiche Methoden und Instrumente.
Besondere Bedeutung hat dabei die Balanced Scorecard. Sie umfasst ein Bündel
von Leistungskennzahlen, das dem Management eine strategiekonforme Steuerung
des Unternehmens ermöglicht. Dabei wird besonderes Gewicht auf die Verbindung
zwischen strategischen und operativen Zielen sowie auf die Kontrolle der Strategie-
umsetzung gelegt. Die Balanced Scorecard dient der Strategieumsetzung, nicht der
Strategiefindung. Für eine nähere Beschreibung vgl. Abschnitt xxx sowie [Schmel-
zer und Sesselmann 2013, S. 18f].
6.4 Zielsystem
Will man strategische Entscheidungen treffen, benötigt man ein Zielsystem, also
Prozessziele und Prozesskennzahlen. Diese werden auf der Basis der Geschäftsziele
und unter Berücksichtigung der strategischen und kritischen Erfolgsfaktoren defi-
niert. Vorab ist eine eindeutige Identifikation der Geschäftsprozesse (Kapitel xxx)
und eine Typisierung vorzunehmen (vgl. Abschnitt xxx und folgende).
Wichtige kritische Erfolgsfaktoren (vgl. unten) sind meist auf hohem Abstraktions-
niveau formuliert und sind daher nicht direkt messbar. Sie erfordern eine
Operationalisierung in Form eines detaillierten, konsistenten Systems von Messgrö-
ßen. Nur auf diese Weise können Geschäftsprozesse hinsichtlich der Zielerreichung
gegenüber strategischen Vorgaben gesteuert werden. Nur so kann die konkrete Pro-
zessdurchführung mit den gesetzten Zielen abgeglichen werden. Zu einem solchen
Zielsystem, wie Alpar/Alt/Bensberg es nennen, gehören
Organisationsziele,
kritische Erfolgsfaktoren und
Führungsgrößen
6.4 Zielsystem 63
[Alpar, Alt, Bensberg u.a. 2014 (E-Book), Pos. 3261]
Organisationsziele
Organisationsziele definieren die langfristige Richtung der Aktivitäten, ohne unmit-
telbar umsetzbar zu sein. Beispiele dafür sind:
Marktführer werden in einem bestimmten Segment
Attraktives Webportal einrichten
Erhöhung der Kundenzufriedenheit
Auslieferungszeiten verkürzen
Innovationskraft erhöhen
[ebenda, Pos. 3017, 3024]
Erfolgsfaktoren
Mit Erfolgsfaktoren sind die Leistungsfaktoren gemeint, die dem Erfolg der Organi-
sation dienlich sind. Einige Beispiele:
hoher Prozessreifegrad (vgl. xxx)
gute Prozessführung, hohe Prozesskulturkultur
hohe Mitarbeitermotivation
hohe Mitarbeiterqualifikation
leistungsstarke IT-Unterstützung
hohe Kunden- und Kundenprozesskenntnis
Kostenführerschaft (falls dies das Ziel ist)
Qualitätsführerschaft (falls dies das Ziel ist)
Vgl. auch [Schmelzer und Sesselmann 2013, S. 274].
Kritische Erfolgsfaktoren
Kritische Erfolgsfaktoren konkretisieren die (langfristigen) Organisationsziele z. B.
durch kürzere Fristigkeit, durch Bezug zu aktuellen Lösungen und/oder durch Quan-
tifizierung. Es sind solche, die den Erfolg eines Prozesses maßgeblich beeinflussen
[Heinrich/Lehner, 2005, S. 344]. Sie sind meist auf hohem Abstraktionsgrad formu-
liert und müssen daher auch operationalisiert werden. Beispiele sind:
Investitionen in Forschung und Entwicklung erhöhen (bzgl. Organisationsziel
"größere Innovationskraft")
Fähigkeiten der Mitarbeiter erhöhen (bzgl Organisationsziel "größere Innovati-
onskraft")
Prozessdurchlaufzeit senken (bzgl. des Organisationsziels "Auslieferungszeiten
verkürzen")
Verbesserung der Kundenbindung
Optimierung des Webportals (bzgl. des Organisationsziels "Erhöhung der Kun-
denzufriedenheit")
Führungsgrößen
Führungsgrößen (Key Performance Indicator, KPI) dienen der Operationalisierung
der kritischen Erfolgsfaktoren, um die Zielerreichung zu messen. Die Führungsgrö-
ßen der Prozesse sind, gegebenenfalls in mehreren Schritten, aus den kritischen
64 6 Strategisches Geschäftsprozessmanagement
Erfolgsfaktoren der jeweiligen Geschäftsfelder abzuleiten [Alpar, Alt, Bensberg u.a.
2014 (E-Book), Pos. 3261]. Eine Größe eignet sich dann als Prozessführungsgröße,
wenn ihre Ausprägung den Zustand einer Aktivität gut charakterisiert und sie damit
zur Steuerung der betreffenden Aktivität herangezogen werden kann. In jedem Fall
muss es möglich sein, die betreffende Größe direkt, exakt und zeitnah zu messen.
Abbildung 6.4-1: Zielsystem eines Unternehmens
Das Zielsystem kommt immer dann zum Einsatz, wenn Effektivität und Effizienz
der Prozessrealisierung gemessen werden sollen. Vgl. dazu Kapitel xxx.
6.5 Prozesseffektiviät und -effizienz
Prozessziele beziehen sich auf Prozesseffektivität und Prozesseffizienz. Nun können
wir diese beiden Begriffe genauer klären. Geschäftsprozesse sind effektiv, falls mit
ihnen die strategischen und operativen Geschäftsziele erreicht werden, falls sie also
die Bedürfnisse der Kunden so erfüllen, dass diese mit den bereitgestellten Prozess-
ergebnissen zufrieden sind. Eine wichtige Zielgröße der Prozesseffektivität ist die
Kundenzufriedenheit. Hierzu gehört dann auch Leistungsfähigkeit in Forschung und
Entwicklung ("jedes Jahr eine neues Smartphone oder ein weiterentwickeltes Pro-
dukt") und Marketing, ohne das heute kaum mehr verkauft werden kann.
Geschäftsprozesse sind effizient, wenn die Kundenleistungen mit möglichst gerin-
gem Ressourceneinsatz erzeugt werden. Davon hängt ab, wie hoch die Kosten der
Leistungserstellung sind und ob die von den Kunden akzeptierten Preise ausreichen,
den angestrebten Gewinn zu erzielen. Ferner bestimmt die Prozesseffizienz, wie
schnell, termingerecht und fehlerfrei Leistungen den Kunden bereitgestellt werden.
Zielgrößen
Es gibt zahlreiche Zielgrößen für die Effektivität und Effizienz von Geschäftspro-
zessen. Die wichtigsten sind die folgenden:
Für Effektivität:
6.5 Prozesseffektiviät und -effizienz 65
Kundenzufriedenheit mit den möglichen Zielen "Senkung der Anzahl an Re-
klamationen", "Senkung der Fehlerquote". Kennzahl könnte der Umsatz des
Kunden zum Vorjahr sein. Maßnahmen zur Erfassung z.B. Kundenbefragungen,
Analyse von Beschwerden.
Für Effizienz:
Prozessdauer mit dem möglichen Ziel "Senkung der Durchlaufzeit von Aufträ-
gen".
Termintreue
Prozessqualität mit dem möglichen Ziel "Leistungsfähigkeit besser als Wettbe-
werb", den Kennzahlen "Durchlaufzeit" und "Kapazität", den Maßnahmen zur
Erfassung "Prozessanalyse und Benchmarking mit Wettbewerbern".
Prozesskosten mit dem Ziel "positiver Deckungsbeitrag".
Schmelzer/Sesselmann nennen diese die Kernziele von Geschäftsprozessen, die
Prozesseffektivität und -Effizienz umfassend abdecken [Schmelzer und Sesselmann
2013, S. 273].
Gegenseite Abhängigkeiten
Zwischen den Zielen gibt es Abhängigkeiten. Zum Beispiel bei der Termintreue. Sie
betrifft über die Kundenzufriedenheit die Effektiviät und über die Prozessdauer die
Effizienz der Geschäftsprozesse.
Strategisches Geschäftsprozessmanagement als Teilgebiet des Strategischen Ma-
nagements konzentriert sich auf die Geschäftsprozesse. Dabei geht es um die lang-
fristige Ausrichtung, Ausgestaltung und Ausstattung der Geschäftsprozesse und des
Geschäftsprozessmanagementsystems. Im Fokus stehen alle wettbewerbsrelevanten
Geschäftsprozesse. Diese sind in der Regel Kerngeschäftsprozesse. Es baut auf den
Konzepten Prozessvision und Prozessziele auf und auf dem daraus abgeleiteten
Zielsystem des Unternehmens. Die wichtigsten Zielgrößen für die Effektivität und
Effizienz von Geschäftsprozessen sind Kundenzufriedenheit, Prozessdauer, Termin-
treue, Prozessqualität und Prozesskosten.
7 Controlling von Prozessen
Prozesscontrolling ist eine Teilaufgabe des Controlling mit dem Fokus auf Ge-
schäftsprozesse. Es umfasst also alle Aufgaben, Methoden und Techniken "zur Ziel-
planung und -kontrolle von Geschäftsprozessen sowie die damit verbundene Infor-
mationsversorgung und Koordination" [Schmelzer und Sesselmann 2013, S. 265]
und gibt so eine Antwort auf die Frage, ob die Durchführung der Prozesse erfolg-
reich ist.
Die dafür notwendig Messung der Leistung erfolgt auf Basis des Zielsystems der
Organisation (vgl. die Abschnitte xxx).
Strategisch
Das strategische Prozesscontrolling unterstützt durch Planung, Umsetzung und
Monitoring geeigneter prozessbezogener Maßnahmen die Erreichung der strategi-
schen Unternehmensziele, also die Umsetzung der Unternehmensstrategie. Der Fo-
kus liegt somit auf der Schaffung von prozessorientierten Erfolgspotenzialen bzw.
Kernkompetenzen [ebenda, S. 266].
Operativ
Dagegegen liegt der Schwerpunkt des operativen Prozesscontrollings auf der Nut-
zung der Erfolgspotentiale zur Erzielung einer hohen Prozesseffektiviät und - effizi-
enz [ebenda, S. 266]. Dazu werden Ziele gesetzt und die Zielerreichung gemessen.
Obiges macht klar, dass strategisches und operatives Prozesscontrolling vonei-
nander abhängen. Werden im strategischen Prozesscontrolling die falschen Maß-
nahmen ergriffen, sind die Erfolgspotentiale falsch gesetzt und das operative Pro-
zesscontrolling misst die falschen Werte.
7.1 Operatives Prozesscontrolling
Die Verantwortung für das operative Prozesscontrolling liegt "bei den Geschäftspro-
zessen". Folgende Aufgabenschwerpunkte gehören dazu:
1. Bestimmung und Gewichtung der Prozessziele pro Geschäftsprozess
2. Festlegung der Zielwerte für die Prozessziele
3. Definition der Prozesskennzahlen zur Kontrolle der Zielerreichung und zur
Messung der Prozessperformance
4. Festlegung des Messsystems
[Schmelzer und Sesselmann 2013, S. 271]
Zielpräzisierung
Jedes Prozessziel besteht aus drei Zieldimensionen [Schmelzer und Sesselmann
2013, S. 272ff]:
68 7 Controlling von Prozessen
Zielinhalt: Was ist zu erreichen? Zum Beispiel eine Reduzierung der
Auslieferungzeit.
Zielausmaß: Wie viel ist zu erreichen? Zum Beispiel die Reduzierung der
Auslieferungzeit auf 1 Tag.
Zieltermin: Bis wann ist das Ziel zu erreichen? Zum Beispiel die Reduzierung
der Auslieferungszeit auf 1 Tag bis Ende des Jahres.
Anforderungen an Ziele werden häufig mit der Abkürzung SMART beschrieben.
SMART ist ein Akronym für spezifisch, messbar, akzeptiert, realistisch und termi-
niert (vgl. [Schmelzer und Sesselmann 2013, S. 272]). Bezogen auf Geschäftspro-
zesse bedeuten diese Anforderungen:
Spezifisch: Prozessziele müssen sich konkret auf Geschäftsprozesse beziehen und in
Verbindung zu den übergeordneten Geschäftszielen stehen.
Messbar: Das Erreichen der Prozessziele muss über Prozesskennzahlen, die mit den
Prozesszielen korrelieren, nachweisbar sein.
Akzeptiert: Prozessziele müssen für die Mitarbeiter verständlich, nachvollziehbar
und motivierend sein sowie in Zielvereinbarungen verankert werden.
Realistisch: Prozessziele müssen unter den gegebenen Rahmenbedingungen erreich-
bar sein.
Terminiert: Prozessziele müssen den Zeitpunkt der Zielerreichung ausweisen.
Schmelzer/Sesselmann schlagen vor, die Prozessziele vertikal und horizontal zu
planen und abzustimmen. Die Ziele für die einzelnen Prozessebenen müssen dann
bis zu Zielvereinbarungen mit den Prozessmitarbeitern vertikal heruntergebrochen
werden. Die Ziele der Prozesselemente innerhalb der einzelnen Prozessebenen, z.B.
die Ziele der Teilprozesse eines Geschäftsprozesses, müssen horizontal abgestimmt
werden. Wird beides realisiert, erhoffen sich Schmelzer/Sesselmann, dass "alle Pro-
zessebenen und alle Prozessmitarbeiter das Erreichen der Geschäftsprozessziele und
damit der Geschäftsziele unterstützen" [Schmelzer und Sesselmann 2013, S. 272f].
Kosten/Nutzen
Prozessziele sind mit Kosten verbunden. Das betrifft ihre Festlegung aber vor allem
ihre Messung. Deshalb sind auch hier die Kosten in Relation zum Nutzen zu setzen.
Deshalb wird man für Kernprozesse mehr Aufwand betreiben als für Supportprozes-
se. Geschäftsprozesse, die häufig durchgeführt werden, werden u.U. mit mehr Zielen
konfrontiert als solche, die nur gelegentlich realisiert werden. Die größere Durchfüh-
rungshäufigkeit verspricht mehr Einsparung bei Zielerreichung.
Bei automatisierten Prozessen liegt eine besondere Situation vor. Der Geschäfts-
prozess ist ja in "Software gegossen", was die Messung vereinfacht. So ist es ohne
Schwierigkeit möglich, den Weg des Kunden auf dem WebPortal zu erfassen und zu
analysieren. Der Aufwand entsteht bei der Einrichtung (Programm für "den Weg des
Kunden" erstellen), d.h. bei der Programmierung oder Hinzufügung der entspre-
chenden Programmkomponente, danach müssen die Ergebnisse nur noch gelesen
werden. Deshalb sind hier die "beobachteten" Programmziele recht zahlreich.
Grundsätzlich aber, so Schmelzer/Sesselmann, ist "die Anzahl der Ziele stark zu
begrenzen und jeweils an der Prozesseffektivität und -effizienz sowie an dem strate-
gischen Gewicht eines Geschäftsprozesses auszurichten" [Schmelzer und Sessel-
mann 2013, S. 275].
7.2 Strategisches Prozesscontrolling 69
Aufgaben
Damit können nun, in Anlehnung an [Schmelzer und Sesselmann 2013, S. 270]
folgende Aufgaben für das operative Prozesscontrolling festgestellt werden:
1. Für jeden Geschäftsprozess sind Prozessziele mit Zielwerten und darauf abge-
stimmte Prozesskennzahlen (Messgrößen) festzulegen
2. Für Kernprozesse sind die Prozessziele und Zielwerte aus den Geschäftszielen
abzuleiten
3. Das Erreichen der Prozessziele und der Stand der Prozessperformance sind
laufend über Prozesskennzahlen zu messen und zu kontrollieren
4. Bei Zielabweichungen sind die Ursachen zu analysieren und Korrekturmaß-
nahmen einzuleiten
5. Zielwerte, Zielabweichungen und Prozessperformance sind in Prozessberichten
auszuweisen
6. Für jeden Geschäftsprozess sind periodisch Prozessassessments durchzuführen
7. Die Verantwortung für die Durchführung der Controllingaufgaben ist klar zu
regeln
7.2 Strategisches Prozesscontrolling
Das strategische Prozesscontrolling wird prozessübergreifend und zentral auf der
Geschäftsebene wahrgenommen. Voraussetzung für die strategische Prozesskontrol-
le ist die Kenntnis der Wechselwirkungen zwischen Geschäftsstrategie und Ge-
schäftsprozessen. Besteht zum Beispiel das strategische Ziel Innovationsführer-
schaft, dann sind Geschäftsprozesse wie Produkt planen, Produkt entwickeln
betroffen. Diese Beziehungen hat die strategische Prozessplanung aufzuzeigen und
zu berücksichtigen.
Aufgaben
[Schmelzer und Sesselmann 2013, S. 266f] stellen folgende Aufgaben im strategi-
schen Prozesscontrolling fest:
Strategische Prozessplanung:
Definition der Prozessstrategie mit Festlegung des strategischen Prozesspro-
gramms, Festlegung strategischer Prozessziele und strategischer Prozesskenn-
zahlen. Vgl. auch unten.
Strategische Prozessmessung:
Messung der strategischen Prozesskennzahlen.
Strategische Prozesskontrolle:
Ermittlung von Soll/Ist-Abweichungen bei strategischen Zielen, Maßnahmen
und Projekten.
Strategische Prozesssteuerung:
Analyse und Bewertung der strategischen Zielabweichungen, Veranlassen von
Korrekturmaßnahmen,
Strategische Prozessinformation:
Erstellen von Prozessberichten mit Ausweis von Zielabweichungen, Stand und
Fortschritt strategischer Maßnahmen und Projekte.
70 7 Controlling von Prozessen
Strategische Prozessplanung
Besondere Bedeutung hat hier die strategische Prozessplanung. Zu ihren Aufgaben
gehört u.a. [Schmelzer und Sesselmann 2013, Seite 268]:
Kritische Erfolgsfaktoren der Geschäftsprozesse klären bzw. festlegen
Strategische Bedeutung der Geschäftsprozesse klären
Kernkompetenzen der Geschäftsprozesse klären
Kerngeschäftsprozesse klären
Strategische Maßnahmen planen (Aufbau und Ausbau von Kernkompetenzen,
Ausbau von Potenzialen zur Leistungs- oder Kostendifferenzierung sowie zur
Flexibilitätssteigerung)
Geschäftsprozessmodell anpassen, wenn sich das Geschäftsmodell verändert
Entscheidungen über die Erneuerung einzelner wettbewerbskritischer Ge-
schäftsprozesse
Die strategische Prozessplanung legt auch die Kennzahlen fest, mit denen die Um-
setzung der Maßnahmen in den Geschäftsprozessen kontrolliert wird.
Koordinierungsfunktion:
Das strategische Prozesscontrolling hat auch eine Koordinierungsfunktion für das
Prozesscontrolling. Diese bezieht sich auf beide wichtigen Aspekte, die Gestaltung
und den Ablauf. Dazu zählen u.a.:
Gestaltung des strategischen und operativen Prozesscontrollings
Planung der strategischen und operativen Ziele des Geschäftsprozessmanage-
ments und der Geschäftsprozesse
Planung, Kontrolle, Steuerung und Überwachung der operativen Prozessziele
Berichtswesen im Geschäftsprozessmanagement
Einsatz von Prozessmethoden und -tools im Prozesscontrolling
Koordination von dezentralem und zentralem Prozesscontrolling sowie zwi-
schen Prozesscontrolling und Bereichscontrolling.
[Schmelzer und Sesselmann 2013, S. 266]
Instrumente
Neben dem Zielportfolio des Geschäftsprozessmanagements ist die Prozess
Balanced Scorecard ein wichtiges Instrument für das strategische Prozesscontrol-
ling. Es handelt sich um eine auf das Prozessgeschehen zugeschnittene Variante der
allgemeinen Balanced Scorecard, die ja schon in Abschnitt xxx kurz vorgestellt
wurde.
Die Balanced Scorecard ist ein kennzahlenbasiertes Führungs- und Steuerungs-
system für das allgemeine Unternehmenscontrolling. Sie stellt eine strukturierte
Sammlung von Zielen (und zugrundeliegenden Daten) dar, die eine Sicht der Unter-
nehmens- bzw. Geschäftsstrategie vermitteln. Sie kann sich auf das Unternehmen
insgesamt beziehen, dann geht es um die Vision und Strategie des Unternehmens,
auf Geschäftseinheiten oder auf Prozesse. Prozess Balanced Scorecards weisen dann
Kennzahlen für die Kontrolle der strategischen Ziele des Geschäftsprozessmanage-
ments aus.
"Balanced" bedeutet, dass die abgeleiteten Ziele unterschiedliche Sichtweisen be-
rücksichtigen und aufeinander abgestimmt sind.
7.3 Kennzahlen 71
Die Balanced Scorecard für das Geschäftsprozessmanagement leitet von der Un-
ternehmensvision und - strategie vier Perspektiven ab (vgl. [Kaplan und Norton
1996, S.7], [Kaplan und Norton 2001]), zitiert nach [Gaitanides 2012, S. 246f]):
die Finanzperspektive
die Kundenperspektive
die Geschäftsprozessperspektive
die Lern- und Entwicklungsperspektive, auch Potenzialperespektive genannt.
Die Beziehungen innerhalb und zwischen den Perspektiven werden als Rahmen
(„Map") verstanden, mit dessen Hilfe die Unternehmensstrategie in operationale
Begrifflichkeiten übersetzt und umgesetzt werden kann.
Für jede Perspektive werden zwei bis drei strategische Ziele mit zugehörigen
Zielwerten, Kennzahlen und Maßnahmen festgelegt. Beispiele für Ziele der Sicht
„Prozessfinanzen" sind Prozesswertbeitrag, Prozessumsatz, Prozesskosten. Ziele der
Sicht „Prozesskunde" können z. B. Kundenzufriedenheit und Kundenbindung sein.
Die „Prozessperformance" kann beispielsweise durch die Ziele Prozesszeiten, Pro-
zessqualität, Prozesstermintreue gesteuert werden (vgl. [Schmelzer und Sesselmann
2013]). Für ein Beispiel zum Vertriebsprozess mit den Perspektiven Kunde, Pro-
zessperformance, Ressourcen/Personal und Finanzen vgl. [Gadatsch 2015, Pos.
552].
Prozess Balanced Scorecards helfen also, die Prozessstrategie zu fixieren und zu
überwachen. Daneben sollen sie, so Gaitanides, "dazu dienen, die Organisation an
der Strategie auszurichten, die Strategie den Mitarbeitern zu vermitteln und den
Bezug zur eigenen Arbeit zu verdeutlichen sowie durch Soll/Ist-Vergleiche die Stra-
tegie als einen kontinuierlichen Wandlungsprozess zu begreifen" [Gaitanides 2012,
S. 247].
Die Daten der Balanced Scorecard werden quartalsweise oder halbjährlich über
die Istdaten aus der operativen Prozesskontrolle aktualisiert. Sie geben Auskunft
über Abweichungen von strategischen Prozesszielen und weisen auf strategische
Lücken hin. Können die Lücken nicht mit operativen Steuerungsmaßnahmen ge-
schlossen werden, sind strategische Korrekturmaßnahmen wie z.B. Reengineering
oder Outsourcing erforderlich [Schmelzer und Sesselmann 2013, S. 269].
Für eine vertiefte Darstellung der Prozess Balanced Scorecard vgl. [Schmelzer
und Sesselmann 2013, S. 90f, Abschnitt 3.1.4], [Gaitanides 2012, S. 246f, Abschnitt
6.5.3.2], [Gadatsch 2015, Pos. 554, Abschnitt 6.2]) und die dort angegebene Litera-
tur.
7.3 Kennzahlen
Sehr oft ist im Kontext von Prozessführung und -controlling von Kennzahlen die
Rede. In dem hier betrachteten Umfeld geht es um Prozesskennzahlen. Ihr Zweck ist
die Steuerung der Umsetzung der Prozessstrategie (z.B. Maßnahmen zur Verkür-
zung der Auslieferungszeit). Es sind also Maßnahmen eingeleitet worden und die
Wirksamkeit dieser Maßnahmen soll gemessen werden.
Für solche Prozesskennzahlen werden Zielwerte festgelgt ("von zwei Wochen auf
eine"). Im Controlling werden dann die Istwerte der Realität mit den Zielwerten
abgeglichen. Gibt es Diskrepanzen in die falsche Richtung muss reagiert werden,
entweder durch Veränderung der Maßnahmen (Veränderung von Ressourcen, Ter-
minen, Zielen u. a.) oder der Prozessstrategie [Gadatsch 2015, Pos. 557].
72 7 Controlling von Prozessen
Aufbau
Kennzahlen unterscheiden sich in absolute und Verhältniskennzahlen. Mit ersteren
sind z.B.
Anzahl Mitarbeiter,
Anzahl Prozesse und
Anzahl Prozessinstanzen
gemeint.
Verhältniskennzahlen werden unterschieden in Gliederungskennzahlen (Anteil
Prozesskosten an Gesamtkosten, Anzahl Prozessmitarbeiter an allen), Beziehungs-
kennzahlen (Schulungskosten je Mitarbeiter, Anteil Prozesskosten am Umsatz) und
Indexkennzahlen (Entwicklung Budget in den letzen 10 Jahren, Prognose Prozess-
kosten der nächsten 2 Jahre) [Gadatsch 2015, Pos. 557].
Kennzahlen müssen sehr gründlich geplant werden. Dies betrifft ihre Qualität
(z.B.: "Misst sie den gewünschten Effekt"), ihre Berechen- und Analysierbarkeit
(z.B.: "Können Ziel- und Sollwerte definiert werden?"), ihre Wirtschaftlichkeit (z.B.:
"Ist der Aufwand wirtschaftlich gerechtfertigt?", "Steht dem Aufwand ein angemes-
sener Nutzen gegenüber?") sowie ihre Organisierbarkeit (z.B.: "Können Verant-
wortliche für Datenbereitstellung, Berechnung, Berichterstattung benannt werden?).
Vgl. [Gadatsch 2015, Pos. 572], auch für eine vertiefte Darstellung.
Prozesscontrolling ist eine Teilaufgabe des Controlling mit dem Fokus auf Ge-
schäftsprozesse. Es umfasst alle Aufgaben, Methoden und Techniken zur Zielpla-
nung und -kontrolle von Geschäftsprozessen einschließlich der damit verbundenen
Informationsversorgung und Koordination und gibt so eine Antwort auf die Frage,
ob die Durchführung der Prozesse erfolgreich ist. Das strategische Prozesscontrol-
ling unterstützt durch Planung, Umsetzung und Monitoring geeigneter prozessbezo-
gener Maßnahmen die Erreichung der strategischen Unternehmensziele. Dagegegen
liegt der Schwerpunkt des operativen Prozesscontrollings auf der Nutzung der Er-
folgspotentiale zur Erzielung einer hohen Prozesseffektiviät und -effizienz. Ein
wichtiges Instrument für das strategische Prozesscontrolling ist die Prozess
Balanced Scorecard. Sehr oft ist im Kontext von Prozessführung und -controlling
von Kennzahlen die Rede. In dem hier betrachteten Umfeld geht es um Prozess-
kennzahlen, mit denen die Umsetzung der Prozessstrategie geleistet werden soll.
Verhältniskennzahlen
8 Reifegrade von Geschäftsprozessen
8.1 Einführung
Da hat man seine Geschäftsprozesse optimiert, in ständigem Bemühen Schwachstel-
len ausgemerzt, dann kommt plötzlich die Forderung nach der Bestimmung des
Reifegrades der Geschäftsprozesse und des Geschäftsprozessmanagements. Hinter-
grund ist die Erkenntnis, dass Geschäftsprozesse eingeführt und dann (meist) ständig
optimiert werden müssen, um die gewünschte Effektivität und Effizienz aufzuwei-
sen.
Oftmals werden die Reifegrade bei der Einführung neuer oder stark veränderter
Geschäftsprozesse gemessen, um den Einführungserfolg zu messen. Zu beachten ist,
dass sich die Messung des Reifegrades auf die Einrichtung entsprechender Struktu-
ren bezieht (entsprechend dem Reifegradmodell), nicht auf die konkrete Leistung.
Gemeint ist also die Ermittlung der bis zum Erhebungszeitpunkt erreichten Qualität
der Rahmenbedingungen der Prozesse. Der Verfasser erlebt es immer wieder, dass
Geschäftsprozesse mit niedrigem Reifegrad (nach den gängigen Modellen) hervor-
ragende Leistung erzielen.
Kriterien?
Es geht damit also um die Analyse von Geschäftsprozessen und des Geschäftspro-
zessmanagements bezüglich ihrer Stärken und Schwächen und dem Ableiten von
Maßnahmen, mit denen die Schwächen beseitigt und die Stärken befördert werden
können. Oftmals wird auch die regelmäßige Wiederholung gefordert (Reassessment)
und damit z.B. die Kontrolle des Fortschritts bei einer Prozesseinführung. Festge-
stellt wird der Reifegrad durch sog. Prozessassessments, die nur dann ihren Zweck
erfüllen, wenn aus den Ergebnissen Verbesserungsmaßnahmen abgeleitet und umge-
setzt werden [Schmelzer und Sesselmann 2013, S. 358].
Reifegrade
Was sind Reifegrade? Die in der Literatur genannten Ziele sind recht allgemein
gehalten. So heben Schmelzer/Sesselmann auf die Breite und Tiefe des Geschäfts-
prozessmanagements ab. Wie breit wird Geschäftsprozessmanagement eingesetzt?
Wie vollständig ist es umgesetzt? "Inwieweit erfüllen Geschäftsprozesse und Ge-
schäftsprozessmanagementsysteme die Voraussetzungen für eine hohe Leistungsfä-
higkeit und das Erreichen der Geschäftsziele?" [Schmelzer und Sesselmann 2013, S.
357f]. Anschaulicher wird es bei den Reifegradmodellen, wenn konkrete Anforde-
rungen für die einzelnen Grade formuliert werden. Dazu unten mehr.
8.2 Assessments
Die Projekte zur Feststellung des Reifegrades werden Assessment (CMMI:
Appraisal) genannt. Dabei wird die konkrete Situation im Unternehmen mit den
Forderungen des ausgewählten Reifegradmodells verglichen. Je besser die Überein-
74 8 Reifegrade von Geschäftsprozessen
stimmung mit diesen Forderungen ist, desto höher ist der Reifegrad. Der Erfolg
eines Prozessassessments und die Aussagekraft seiner Bewertung hängen somit sehr
stark von der Wahl des Reifegradmodells ab. Dieses muss zum Anwendungsbereich
des Unternehmens passen und die davon abgeleiteten Checklisten müssen qualitativ
hochwertig sein, d.h. zu aussagekräftigen Ergebnissen führen können. Natürlich
sollten die durchführenden Personen kompetent und mit den notwendigen Zustän-
digkeiten ausgestattet sein.
Assessments können auch in Form von Selbstbewertungen durchgeführt werden.
"Die Selbstbewertung ist eine umfassende und systematische Bewertung der Tätig-
keiten der Organisation und ihrer Leistung in Bezug auf den Reifegrad" [ISO
9004:2009, Abschnitt 8.3.4], zitiert nach [Schmelzer und Sesselmann 2013, S. 357].
Ist ein Assessment kompetent durchgeführt, können die Ergebnisse bei einer
Vielzahl von Aufgaben (des Geschäftsprozessmanagements) helfen. Sie zeigen
Möglichkeiten zur Prozessverbesserung auf, bei wiederholten Assessments Messung
der Prozessverbesserung. Bei der Einführung von Geschäftsprozessen kann damit
der Einführungsprozess begleitet und der hoffentlich erreichte Fortschritt gemessen
werden.
Schmelzer/Sesselmann sehen sogar die Möglichkeit, durch Assessments die Risi-
ken in Geschäftsprozessen besser zu beherrschen. U.a. führen sie als mögliche Er-
gebnisse von Assessments an:
Klärung von Erfolgsrisiken in Geschäftsprozessen und im Geschäftsprozessma-
nagement
Identifizierung kritischer Geschäftsprozesse
Identifizierung kritischer Komponenten des Geschäftsprozessmanagements
[Schmelzer und Sesselmann 2013, S. 358)
8.3 Reifegradmodelle
Will man "Reife" messen (im Sinne dieses Kapitels), dann muss man die reale Situa-
tion rund um den betrachteten Geschäftsprozess oder das Geschäftsprozessmanage-
ment mit einer idealisierten Situation vergleichen und dies sollte sollte gestuft erfol-
gen können. Genau dazu dienen die sog. Reifegradmodelle. Bewertet werden
können die gesetzten Rahmenbedingungen für
einzelne Geschäftsprozesse
das Geschäftsprozessmanagement
die Organisation als Ganzes
Die in der Literatur hierzu genannten Ziele bleiben, wie wir gesehen haben, recht ab-
strakt, die Verknüpfung mit konkreten Zielen erfolgt bei den einzelnen Modellen
(vgl. unten).
Es versteht sich, dass der Reifegrad umso höher ist, je besser die Voraussetzun-
gen für die Effektivität und Effizienz der Prozesse realisiert sind. Die Reifegradstu-
fen bauen aufeinander auf. Bei jeder ist angegeben, durch welche Maßnahmen die
nächst höhere erreicht werden kann.
Selbstassessments
Ergebnisse
8.4 Capability MaturityModel Integration (CMMI) 75
Abbildung 8.3-1: Vom Assessment zum Reifegrad
Konkrete Reifegradmodelle
Es gibt inzwischen sehr viele Reifegradmodelle für viele Anwendungsbereiche,
Schmelzer/Sesselmann schätzen die Zahl auf über 200. Zu den bekannteren gehören
die Folgenden:
Capability Maturity Model Integration (CMMI) für die Anwendungsbereiche
Entwicklung, Beschaffung, Service. Beurteilt wird die Organisation. Bewer-
tungsmethode ist SCAMPI. Vgl. die Beschreibung unten.
Software Process Improvement and Capability Determination (SPICE) zusam-
men mit ISO 15504 (SPICE/ISO 15504) für den Anwendungsbereich Software-
entwicklung. Beurteilt werden einzelne Prozesse. Bewertungsmethode SCAM-
PI. Vgl. die Beschreibung unten.
ITIL (IT Infrastructure Library) für den Anwendungsbereich IT-Management.
Beurteilt wird die Organisation. Bewertungsmethode Checklisten.
BPMM-Modell (Business Process Maturity Model) für den Anwendungsbereich
Industrie. Beurteilt wird das Geschäftsprozessmanagement. Als Bewertungsme-
thode dienen Checklisten.
ISO-Reifegradmodell nach ISO 9004 für alle Anwendungsbereiche. Es ist all-
gemein einsetzbar. Beurteilt wird das Geschäftsprozessmanagement.
PEM-Modell (Process and Enterprise Maturity Model) für alle Anwendungsbe-
reiche. Beurteilt werden die Organisation und einzelne Prozesse. Als Bewer-
tungsmethode dienen Checklisten.
Vgl. [Schmelzer und Sesselmann 2013, S. 360ff] und die dort angegebene Literatur.
8.4 Capability MaturityModel Integration (CMMI)
Die Methode Capability Maturity Model Integration (CMMI) wurde vom Software
Engineering Institute (SEI) der Carnegie Mellon University in Pittsburgh entwickelt.
Ziel ist die Optimierung aller Prozesse in einer Organisation, wobei von der Er-
kenntnis ausgegangen wird, dass Fortschritte nur schrittweise möglich sind. Deshalb
bietet CMMI einen schrittweisen Verbesserungsweg an. Falls die Situation es erfor-
dert, von einem unreifen Ad Hoc - Prozess zu einem optimierten und leistungsstar-
ken Geschäftsprozess.
Im Reifegradmodell CMMI wird das Projekt zur Klärung des Reifegrads
Appraisal genannt.
Das CMMI besteht aus einem Satz integrierter Modelle für unterschiedliche An-
wendungsbereiche:
76 8 Reifegrade von Geschäftsprozessen
CMMI for Aquisition (CMMI-ACQ) für Beschaffungsvorgänge (Produkte und
Leistungen)
CMMI for Development (CMMI-DEV) für die Software- und Systementwick-
lung
CMMI for Services (CMMI-SVC) für die Erbringung von Dienstleistungen
Betrachtet werden 22 Prozessgebiete, wovon 16 Kernprozessgebiete sind. Die Pro-
zessgebiete umfassen in vier Untergruppen wichtige prozessrelevante Themen:
Unterstützung (Konfigurationsmanagement, Sicherung Prozessqualität, Siche-
rung Produktqualität, ...)
Prozessmanagement (Aus- und Weiterbildung, Prozessentwicklung, Prozess-
ausrichtung, Prozessleistung, ... - alles organisationsweit.
Projektmanagement (Anforderungsmanagement, Projektplanung, Zuliefe-
rungsmanagement, Risikomanagement, ...)
spezifische anwendungsbereichsbezogene Themen (am Beispiel Entwicklung:
Anforderungsentwicklung, Technische Umsetzung, Produktintegration, ...)
Vgl. [Schmelzer und Sesselmann 2013, S. 362f]
"Fähigkeits- und Reifegrade"
CMMI sieht vor, dass einzelne Prozessgebiete verbessert werden, dies wird über
Fähigkeitsgrade (capability levels) gemessen, oder eine Gruppe zusammenhängen-
der Prozessgebiete, was über Reifegrade (maturity levels) gemessen wird.
Fähigkeitsgrade nach CMMI (vgl. CMMI-DEV 2010, S. 23)
Grad Fähigkeitsgrade Ziele (Beispiele)
0 Incomplete Unvollständiger Prozess, der nicht den Fähigkeitsgrad 1
erreicht.
1 Performed Ist erreicht, wenn ein Prozess das angestrebte Ziel er-
reicht und damit als durchgeführt (performed) bezeichnet
werden kann.
2 Managed Verlangt die Institutionalisierung eines Prozesses als
wiederholbaren (managed) Prozess.
3 Defined Verlangt die Institutionalisierung eines Prozesses als
definierten Prozess.
Anmerkung: Der Begriff der Institutionalisierung bringt eine organisatorische Verankerung
zum Ausdruck.
Die Reifegrade bauen auf den Fähigkeitsgraden auf. Um einen Reifegrad zu errei-
chen, müssen bestimmte Fähigkeitsgrade umgesetzt sein.
8.4 Capability MaturityModel Integration (CMMI) 77
Reifegrade nach CMMI (vgl. CMMI-DEV 2010, S. 23)
Grad Reifegrade Beschreibung
1 Initial Prozesse laufen "chaotisch" ab (vgl. unten)
2 Managed Alle Prozessgebiete müssen die Fähigkeitsgrade 2
oder 3 erreichen.
3 Defined Alle Prozessgebiete, die den Reifegraden 2 und 3
zugeordnet sind, müssen den Fähigkeitsgrad 3 auf-
weisen.
4 Quantitatively Managed Alle Prozessgebiete, die den Reifegraden 2, 3 und 4
zugeordnet sind, müssen den Fähigkeitsgrad 3 auf-
weisen.
5 Optimizing Alle Prozessgebiete, die den Reifegraden 2, 3, 4 und
5 zugeordnet sind, müssen den Fähigkeitsgrad 3
aufweisen
Vgl. [Schmelzer und Sesselmann 2013, S. 363ff] und die dort angegebene Literatur.
An den Merkmalen der Reifegradstufen können die Vorstellungen der Urheber bzgl.
der Qualität von Geschäftsprozessen nachvollzogen werden:
Reifegrad 1: Initial
Es gibt kein Prozessmanagement, Prozesse laufen chaotisch ab. Darunter wird hier
verstanden, dass Prozessvorgaben fehlen, der Erfolg vom Know-how einzelner Per-
sonen abhängt. Solche Prozesse liefern keine vorhersagbaren Ergebnisse (meinen
die Urheber), die Ressourcen sind stark mit der Behebung von Krisen beschäftigt.
Dieser Begriff von "chaotisch" darf nicht mit dem bei "kreativen Prozessen" ver-
wechselt werden.
Reifegrad 2: Managed
Erste Ansätze eines Prozessmanagements. Die Prozesse werden geplant, überwacht
und gesteuert und liefern kontrollierte Ergebnisse.
Reifegrad 3: Defined
Beginn des systematischen und aktiven Prozessmanagements. Standardisierte Ge-
schäftsprozesse für die gesamte Organisation wurden eingeführt. Z.B. existiert ein
standardisierter Beschaffungsprozess, von dem die unterschiedlichen Landesgesell-
schaften ihre spezifischen Beschaffungsprozesse ableiten können.
Reifegrad 4: Ouantitatively Managed
Die Leistungsfähigkeit der Prozesse wird quantitativ gemessen, analysiert und an-
hand vorgegebener Zielwerte überwacht. Damit können notwendige Korrekturen
rechtzeitig erkannt werden. Ziel ist, dass die Prozesse vorhersagbare Ergebnisse
liefern.
Reifegrad 5: Optimizing
Die Prozesse werden kontinuierlich optimiert.
Hier nochmals der Hinweis, dass auch dieses Reifegradmodell nur misst, welche
Mittel für die Prozessgestaltung eingesetzt werden, nicht die Qualität dieses Einsat-
zes. Dies sei am Beispiel des Fähigkeitsgrads 2 erläutert. Für diesen wird u.a. ver-
langt [Schmelzer und Sesselmann 2013, S. 363f]:
Etablierung organisationsweiter Leitlinien
Planung von Arbeitsabläufen
78 8 Reifegrade von Geschäftsprozessen
Bereitstellung von Ressourcen
Zuweisung von Rechten und Pflichten
Durchführung von Aus-und Weiterbildung
Überwachung und Steuerung der Arbeitsabläufe
Objektive Bewertung von Prozessinhalten
Das macht deutlich, dass die Leistungsfähigkeit auch eines Geschäftsprozesses mit
hohem Reifegrad sehr stark vom Engagement und der Kompetenz derjenigen ab-
hängt, die ihn realisieren.
Bewertungsverfahren
Als Bewertungsverfahren wird SCAMPI (Standard CMMI Appraisal Method for
Process Improvement) angewendet. Es erfüllt die Anforderungen der Norm ISO/IEC
15504. Die Appraisals werden als interne Selbstbewertungen, aber auch zur Bewer-
tung der Prozessreife von Auftragnehmern durchgeführt. "Die Begutachtung basiert
auf dem Vergleich der Prozesse einer Organisation mit den Praktiken (Best Practi-
ces) von CMMI." [Schmelzer und Sesselmann 2013, S. 366f]
8.5 SPICE/ISO 15504
"Das Reifegradmodell Software Process Improvement and Capability Determination
wurde 1993 vom britischen Institute of Electrical & Electronics Engineering als
Standard für Softwareentwicklungsprozesse veröffentlicht und in die ISO Norm
15504 übernommen" [Schmelzer und Sesselmann 2013, S. 367ff]. ISO 15504 ist ein
allgemeiner Standard zur Durchführung von Assessments in IT-Prozessen, in dem
die einzelnen Prozesse unabhängig voneinander bewertet werden. Das Modell unter-
scheidet neun Prozessattribute und sechs aufeinander aufbauende Fähigkeitsstufen.
Jeder Prozess wird anhand der Prozessattribute [1] Prozessoptimierung, [2] Pro-
zessinnovation, [3] Prozesssteuerung, [4] Prozessmessung, [5] Prozessanwendung,
[6] Prozessdefinition, [7] Management der Arbeitsprodukte, [8] Management der
Prozessdurchführung und [9] Prozessdurchführung bewertet (Kriterium: "reali-
siert"). Diese führen dann zu den Fähigkeitsstufen:
(5) Optimizing
Prozessattribute [1] und [2]. Der Geschäftsprozess ist auf die Geschäftsziele abge-
stimmt. Er wird ständig verbessert.
(4) Predictable
Prozessattribute [3] und [4]. Der Prozess ist "umfassend und konsistent eingeführt".
Er "erreicht Ergebnisse innerhalb definierter Grenzen".
(3) Established
Prozessattribute [5] und [6]. Der Prozess ist etabliert und standardisiert.
(2) Managed
Prozessattribute [7] und [8]. "Der Prozess wird geplant und überwacht, die Prozess-
verantwortlichkeiten sind definiert."
(1) Performed
8.5 SPICE/ISO 15504 79
Prozessattribut [9]. Der Prozess ist implementiert und wird durchgeführt, die Ergeb-
nisse sind erkennbar.
(0) Incomplete
[-]. Der Prozess ist nicht eingeführt, die Ergebnisse nicht erkennbar.
Soweit die Betrachtungen zu den Möglichkeiten, Reifegrade einer Organisation, des
Geschäftsprozessmanagements oder einzelner Geschäftsprozesse zu bestimmen.
Eine umfassende Darstellung dazu findet sich in [Schmelzer und Sesselmann 2913,
S. 357ff].
Zusammenfassung
Die Bestimmung der Reifegrade dient der Analyse von Geschäftsprozessen und des
Geschäftsprozessmanagements bezüglich ihrer Stärken und Schwächen und dem
Ableiten von Maßnahmen, mit denen die Schwächen beseitigt und die Stärken be-
fördert werden können. Dies auf der Basis von methodischen Vorstellungen, die
eine graduelle Einschätzung der Istsituation erlauben. Dabei wird die reale Situation
(des Prozessmanagements) mit dem Reifegradmodell verglichen und damit der er-
reichte Optimierungsstand festgestellt. Die Methoden sind anwendbar auf einzelne
Geschäftsprozesse, auf das Geschäftsprozessmanagement oder auf die Organisation
als Ganzes. Sie messen nicht die konkrete Leistungsfähigkeit, sondern die Einrich-
tung der Voraussetzungen für den Prozesserfolg, wie sie das jeweilige Reifegrad-
modell fordert.
9 Vorgehensmodelle
Es gibt in der Literatur zahlreiche Vorschläge, wie Geschäftsprozessmanagement
eingeführt werden soll. Diese Vorschläge sind meist als Vorgehensmodelle definiert,
die einem Phasenmodell folgen, ähnlich denen in der Softwareentwicklung
[Gadatsch 2013, 2.2, Pos. 1776].
9.1 Nach Becker
Becker stellt ein Vorgehensmodell vor, das sieben Phasen beinhaltet (vgl. [Becker
und Kahn 2004, S. 15 f]. und [Becker 2013]).
Abbildung 9.1-1: Vorgehensmodell von Becker
Im Rahmen der Modellierungsvorbereitung werden Gestaltungsempfehlungen zur
Informationsmodellierung entwickelt. Dies ist eine wesentliche Aufgabe, um den
Erfolg der Prozessmodellierung sicherzustellen. Als Ergebnis liegt der geeignete
Modellierungsstandard vor, der die Erreichung der gesteckten Ziele sicherstellt.
In der Strategie- und Ordnungsrahmenentwicklung werden die Prozesse und Pro-
zessziele strukturiert. Ziel ist, die wesentlichen Elemente und ihre Beziehung sche-
matisch darzustellen, um die Transparenz im weiteren Projektverlauf sicherzustellen
(für eine ausführliche Darstellung vgl. [Becker und Meise 2012]).
Die Istmodellierung und -analyse dient der Identifizierung von Verbesserungspo-
tenzialen; sie ist also Grundlage für die Sollmodellierung, da Schwachstellen identi-
fiziert werden. Daneben dient die Istmodellierung zu Protokollierungs-, Präsentati-
ons- oder Schulungszwecken.
Auf Basis der Istmodellierung erfolgt in dieser Phase die Sollmodellierung, also
der Sollzustand der Prozesslandschaft des Unternehmens. Die Sollmodellierung
bildet einerseits die Basis für die Ausrichtung der Aufbauorganisation des Unter-
nehmens und andererseits die Basis für internes Benchmarking oder Workflowma-
nagement.
Die prozessorientierte Aufbauorganisationsgestaltung geht von den Sollprozes-
sen aus. Kriterien für die Festlegung der Aufbauorganisation sind Zeit, Kosten und
Qualität.
Die Einführung der Neuorganisation umfasst die Einführung des konzeptionellen
Entwurfs (Sollmodell, prozessorientierte Aufbauorganisation) im Rahmen der neuen
Organisationsstruktur. Dafür wird eine Roll-Out-Strategie definiert, die den Ablauf
und die zeitliche Abfolge der Einführung der neuen Prozesse beinhaltet. Um den
Erfolg sicherzustellen, werden Change Management-Techniken eingesetzt.
82 9 Vorgehensmodelle
Im Anschluss an die Implementierung einer prozessorientierten Organisations-
struktur ist es notwendig, ein kontinuierliches Prozessmanagement zu etablieren, um
sich einem veränderten Umfeld anzupassen.
9.2 Nach Schmelzer/Sesselmann
Schmelzer und Sesselmann schlagen im Rahmen ihres Vorgehensmodells vier Pha-
sen vor (vgl. [Schmelzer und Sesselmann 2008, S. 414]).
Abbildung 9.2-1: Vorgehensmodell von Schmelzer und Sesselmann
Die strategische Positionierung beinhaltet die Prüfung und Neudefinition der
strategi- schen Ausrichtung der Organisation. Wesentliche Inhalte sind die Entwick-
lung der Vision, die Klärung der Ausgangssituation und die Identifikation des Hand-
lungsbedarfs für Prozessmanagement.
Die Identifizierung der Geschäftsprozesse klärt, welche Geschäftsprozesse zur
Erfül- lung der Geschäftsstrategie und der Kundenanforderungen notwendig sind.
Die Implementierung der Geschäftsprozesse legt Prozessstrukturen,
Prozessverant- wortliche und ein Prozessgremium fest. Daneben wird die Aufbauor-
ganisation an die Geschäftsprozesse angepasst. Das Prozesscontrolling definiert
Leistungsparameter mit Ziel- und Messgrößen und führt das Berichtssystem ein.
Die letzte Phase beinhaltet den operativen Ablauf und die Steuerung der Ge-
schäftspro- zesse. Hierfür werden die Prozessziele (Kundenzufriedenheit, Prozess-
zeit, Termintreue, Prozesskosten, Prozessqualität) laufend überwacht. Die Optimie-
rung der Geschäftsprozesse erfolgt entweder in Form einer Prozessverbesserung
oder in Form einer Prozesserneuerung. Die Prozessverbesserung beinhaltet die Er-
höhung der Leistungsfähigkeit der Prozesse. Die Prozesserneuerung beinhaltet hin-
gegen die völlige Neugestaltung der Prozesse.
9.3 Nach Österle
Ein Vorgehensmodell, das radikale Innovation im Prozessbereich beschreibt, ist das
Vorgehensmodell von Österle.
Abbildung 9.3-1: Vorgehensmodell von Österle
9.3 Nach Österle 83
Die Prozessvision hat radikale Innovationen zum Ziel und nimmt einen Abgleich
zwi- schen Strategie und Prozess vor. Sie ist langfristig orientiert, berücksichtigt IT-
Potenziale und bietet eine Gesamtsicht auf den Prozess. Hauptergebnis der Prozess-
vision sind die Prozessgrundsätze (vgl. [Österle 1995, S.63 und 77]).
Die Leistungsanalyse soll die notwendigen Leistungen eines Prozesses detailliert
erfassen, bewerten und dokumentieren. Ausgangspunkt ist hierbei der Kunde mit
seinen Bedürfnissen. Hauptergebnisse der Leistungsanalyse sind das Kontextdia-
gramm (Leistungsaustausch zwischen Prozessen), das Leistungsverzeichnis (grobe
Beschreibung der Leistungen) und das Qualitätsprofil (Beurteilung der Leistungen)
[ebenda, S. 78-85].
Die Ablaufplanung legt die Aufgaben des Prozesses, deren Reihenfolge und die
ausführenden Einheiten fest. Als Ergebnis liegen das Aufgabenkettendiagramm, das
Auf gabenverzeichnis und stellenbezogene Dokumente vor [S. 98].
Die Workflowplanung detailliert das Aufgabenkettendiagramm und enthält zu-
sätzlich: Ereignisse, Applikationen, Transaktionen, Datenflüsse und Bedingungen.
Zur Unterstützung wird hierbei ein Workflowmanagementsystem eingesetzt [S.
104f].
Die Prozessführung dient der Planung, Gestaltung und Beobachtung des Prozes-
ses; sie beinhaltet kritische Erfolgsfaktoren, Führungsgrößen, Zielwerte und die
Prozessorganisation. Diese Zielwerte werden einem Soll-Ist-Vergleich unterzogen,
um darauf aufbauend Verbesserungsmaßnahmen abzuleiten [S. 127].
Die Architekturplanung beinhaltet die Ableitung von Prozesskandidaten, deren
Detaillierung, Prüfung und Auswahl. Als Ergebnis liegt eine Prozessarchitektur mit
den wett- bewerbsentscheidenden Prozessen vor [S. 138].
Das IT-Assessment analysiert die wichtigsten technologischen Entwicklungen aus
Sicht eines Prozesses und erstellt eine IT-Landkarte. Somit sollen IT-Potenziale für
Prozesse genutzt werden (Enabler) [S. 139].
Die Kundenbeziehungsanalyse erhebt die Aufgaben des Kunden in Zusammen-
hang mit den angebotenen Prozessleistungen. Es werden ebenso die Aufgaben des
Anbieters in Zusammenhang mit den Kundenbedürfnissen erhoben. Auf dieser Basis
werden die Beziehungen zwischen den Aufgaben des Kunden und den Aufgaben des
Anbieters bestimmt und Möglichkeiten aus der IT geprüft. Als Ergebnis liegt das
Kundenbeziehungsdiagramm vor, das Ideen für die Prozessvision, die Architektur-
planung und die Ablaufplanung liefert [S. 160].
Aufgabenbezogene Analysen betrachten Durchlaufzeiten, Kosten und die Fehler-
häufigkeit von Prozessen; dabei werden die einzelnen Merkmale von Prozessen
untersucht, um Verbesserungspotenziale abzuleiten [S. 161-164].
Benchmarking kann unternehmensintern, branchenintern oder branchenübergrei-
fend durchgeführt werden. Als Ergebnis des Benchmarking liegen Vergleichswerte
(Soll- Werte) für die Führungsgrößen eines Prozesses und Lösungsvarianten für
einzelne Bestandteile eines Prozesses vor [S. 167-169].
Das organisatorische Monitoring erhebt Informationen zur Transaktionsnutzung,
zu Daten- und Bewegungsvolumina, zu Funktionen und zu Abläufen. Somit können
Führungsgrößen abgeleitet und Informationen für den Entwurf und die Weiterent-
wicklung des Prozesses bereitgestellt werden [ebenda, S. 170 und 179].
84 9 Vorgehensmodelle
Zusammenfassung
Es gibt in der Literatur zahlreiche Vorschläge, wie Geschäftsprozessmanagement
eingeführt werden soll. Diese Vorschläge sind meist als Vorgehensmodelle definiert,
die einem Phasenmodell folgen, ähnlich denen in der Softwareentwicklung. Wir
haben in diesem Kapitel die Vorgehensmodelle von Becker, Schmelzer/Sesselmann
und Österle betrachtet. Alle drei zeigen die Schritte auf, um Geschäftsprozessmana-
gement einzuführen. Die beiden erstgenannten gehen bezüglich der Geschäftspro-
zesse von einer schrittweisen Optimierung aus, während Österle im Rahmen der
Formulierung einer Prozessvision eine radikale Innovation vorschlägt.
10 Modelle, Modellierung
10.1 Modellierung für Komplexitätsreduzierung
Die klassische Organisationslehre14
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ög-
lich, Modellbildung wurde unabdingbar. Zwei Gründe15
sind dafür verantwortlich.
Der erste liegt in der immer mehr gestiegenen Komplexität der Unternehmensreali-
tä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 systemnahe Modelle bis zur daraus
abgeleiteten Anforderungsermittlung für die Software. Unter Umständen dann auch
noch unter Einbezug der Unternehmensmodellierung, wo das Unternehmen als Gan-
zes (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 Model-
lierung der Unternehmensrealität zeitbezogen. Derzeit ist es so, dass Geschäftspro-
zesse im Mittelpunkt dieser Anstrengungen stehen, ergänzt um das eingeführte älte-
re Instrumentarium aus der Organisationslehre.
Modellierung an sich hat natürlich noch viele weitere Aspekte, die hier nicht be-
trachtet 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 Ge-
schä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, sowie in [Staud 2014a,b] die Abschnitte 12.3 ("Automatisie-
rung") und 12.4 ("Kontrollfluss vertieft").
14 Vor dem Beginn der detaillierten formalen Erfassung von Geschäftsprozessen, also bis Anfang der
1970er-Jahre.
15 Ein dritter sei hier nicht thematisiert. Er betrifft die grundsätzliche Struktur der menschlichen Wahr-
nehmung, die ohne Modellbildung im elementaren Sinn gar nicht auskommt.
86 10 Modelle, Modellierung
10.2 Methoden
Die Modellierung erfolgt mit Nutzung einer entsprechenden Methode. Hier ist das
Angebot sehr groß. Betrachten wir nur die hier im Mittelpunkt stehenden Geschäfts-
prozesse, im weitesten Sinn also Abläufe, ergibt sich schnell eine lange Liste:
Aktivitätsdiagramme der UML16
Vgl. für eine Beschreibung [Staud 2010, Kapi-
tel 10]
Flussdiagramme (aus der Systemanalyse)
Ablaufdiagramme (aus der Systemanalyse)
Sequenzdiagramme der UML (systemnah, auf bestimmte detailliert Stellen im
Ablauf konzentriert). Vgl. für eine Beschreibung [Staud 2010, Kapitel 11]
Zustandsautomaten. Vgl. für eine Beschreibung [Staud 2010, Kapitel 13)
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).
Diese Methoden beschreiben alle den Kontrollfluss (BPMN: Sequenzfluss) der Ab-
läufe. Einige erlauben auch die Modellierung der Informationsflüsse.
16 UML: Unified Modeling Language der Object Management Group (OMG).
88 11 Prozessmodelle, Prozessmodellierung
11 Prozessmodelle, Prozessmodellierung
Prozessmodelle beschreiben Geschäftsprozesse. Sie erfassen die in Kapitel xxx
erarbeiteten Komponenten von Geschäftsprozessen. Zentral ist dabei die Beschrei-
bung der Abläufe. Dieser wird als Kontrollfluss oder auch Sequenzfluss (BPMN, vgl.
xxx) bezeichnet.
11.1 Ziele der Geschäftsprozessmodellierung
Dokumentation und Istanalysen
Erstes Ziel jeder Geschäftsprozessmodellierung ist die Bestandsaufnahme, die Fest-
stellung, welche Geschäftsprozesse in welcher Form ablaufen. Dies kann dann auch
direkt zu einer Dokumentation, z.B. im Rahmen einer ISO 9000-Zertifizierung füh-
ren oder zu einer Beschreibung, die im Rahmen der Vorbereitung der Einführung
einer ERP-Software (oder allgemein einer Integrierten Prozessorientierten Software)
benötigt wird. Dies führt dann z.B. zu Istanalysen, mit denen der Vergleich der vor-
gedachten Geschäftsprozesse der ERP-Software mit den eigenen bewerkstelligt
werden kann.
Optimierungsziele
Das zweite große Ziel ist das der Geschäftsprozessoptimierung, der Beseitigung von
Schwachstellen, die bei der Beschreibung erkannt wurden. Einige der möglichen
Schwachstellen wurden in xxx bei den Eigenschaften von Geschäftsprozessen schon
angesprochen:
fehlende Datenintegration, d.h. Dateninseln und Medienbrüche
fehlende Prozessintegration, d.h. Organisationsbrüche
Kundenorientierung
Die Prozessmodellierung soll auch die Forderung nach Kundenorientierung mit
umsetzen. Dies ist natürlich oftmals schwer möglich, weil sich Kundenorientierung
oft darin äußert, 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 Prozessreali-
sierung zeigt dann, ob Kundenkontakte auch stattfinden. Die oftmals danach ange-
forderte Bewertung durch den Kunden ("Hat Ihnen dies geholfen?") erlaubt dann die
Einschätzung des Erfolgs der Bemühungen.
11.2 Grundsätze ordnungsgemäßer Modellierung
Rosemann/Schwegmann/Delfmann stellen ganz allgemeine grundsätzliche Forde-
rungen an die Prozessmodellierung vor. Ziel ist die Reduzierung bzw. Beherrschung
11.3 Programmnahe Prozessmodellierung 89
der mit der Modellierung verbundenen Komplexität. Die sog. Grundsätze sind wie
folgt:
Grundsatz der Richtigkeit. Forderung nach der korrekten Wiedergabe des Ge-
schäftsprozesses.
Grundsatz der Relevanz. Forderung nach Konzentration auf für den Geschäfts-
prozess 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 Abstrakti-
onsgrad für Modelle derselben Modellierungsebene.
Grundsatz des systematischen Aufbaus. Forderung nach wohldefinierten
Schnittstellen zu korrespondierenden Modellen (z.B. zwischen Prozess- und Da-
tenmodellen).
[Rosemann, Schwegmann und Delfmann 2012, S. 49f]
11.3 Programmnahe Prozessmodellierung
Ist das Ziel der Prozessmodellierung die Unterstützung einer Softwareerstellung,
muss eine Standardprozessmodellierung fortgesetzt werden in eine detailliertere
Modellierung. Diese "tiefere" programmnahe Modellierungsebene wird hier pro-
grammnahe Prozessmodellierung genannt. Damit soll eine Prozessmodellierung
bezeichnet werden, die – z.B. im Rahmen des Requirement Engineerings – unmit-
telbar der Vorbereitung der Programmierung dient. Vgl. [Staud 2010] für die dann
einzusetzenden Methoden der UML.
11.4 Basiselemente einer jeden Prozessmodellierung
Geschäftsprozessmodellierung findet ja auf verschiedenen Ebenen statt, in denen
jeweils andere Ablauf- und Aufgabenstrukturen vorliegen. Deshalb wird hier eine
Ebene definiert, in der der Umgang der Handelnden mit den Geschäftsobjekten klar
erkennbar ist, die unterhalb der hoch aggregierten Überblicksnotationen und ober-
halb der programmnahen Prozessmodellierung liegt. Sie soll Standardprozessmodel-
lierung genannt werden. Darunter versteht der Verfasser diejenige Ausprägung der
Prozessmodellierung, bei der eine Handlung eines Prozessteilnehmers („Kalkulation
erstellen“, „Brief schreiben“, „an Sitzung teilnehmen“) in ein Basistheorieelement
(eine Tätigkeit) findet. Auf dieser Detaillierungsebene bleiben auch die Geschäfts-
objekte (Rechnungen, Lieferscheine, usw.) als Ganzes erhalten, verschwinden also
nicht, wie auf höheren Aggregationsniveaus oder werden zerlegt wie in der pro-
grammnahen Prozessmodellierung.
Istanalysen bewegen sich oft auf dieser Ebene.
Basiselemente
Welche Elemente benötigt eine Methode zur Modellierung von Geschäftsprozessen
im Sinne einer Standardprozessmodellierung? Eine solche Betrachtung ermöglicht
eine fundierte Einschätzung der Methoden, auch bzgl. Ihrer Tauglichkeit für be-
stimmte Anwendungen. Außerdem wird damit ein Vergleich der Methoden möglich.
Standardprozess-modellierung
90 11 Prozessmodelle, Prozessmodellierung
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 ge-
meint 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.
Hier nun die Theorieelemente, sie sind von (1) bis (11) durchnummeriert:
(1) Zentraler Gegenstand des Geschäftsprozesses
Was wird im Geschäftsprozess bearbeitet? Z.B. die „Leistung“ bei der „Leistungser-
bringung“, „Angebot“ bei Angebotserstellung, usw.
(2) Elementare Tätigkeiten
Es muss ein Theorieelement vorliegen für die Teilaufgaben, in die man die Gesamt-
aufgabe zerlegt. Bzgl. der unvermeidlichen Subjektivität dieser Zerlegung vgl. xxx.
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 Standardprozessmodellierung sind 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 2010, Kapitel 12]).
(3) Informationen auf Trägern aller Art
Dieses Element erfasst jede irgendwie genutzte Information auf allen Trägern.
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.
(4) Informationsverarbeitung
Jegliche Tätigkeit ist letztendlich mit Informationsverarbeitung in elementarer Form
verbunden. Es gibt jedoch Tätigkeiten, die massiv Information verarbeiten und dabei
auch auf die Daten (auf allen Trägern) zugreifen (Angebotserstellung, statistische
Auswertungen, ...). Der Grund ist, dass in jedem Geschäftsprozess zahlreiche und
umfangreiche Informationen verwaltet werden. Schließlich werden ja auch die meis-
ten Geschäftsobjekte (Rechnungen, Lieferscheine, ...) als Daten in den Datenbanken
repräsentiert. Dieses Erzeugen, Bearbeiten, Löschen und Transportieren von Infor-
mation ist den oben eingeführten elementaren Tätigkeiten zuzuordnen. Die dort
angegebenen Träger sind dann die informationsverarbeitende Einheit.
Die Erfassung der Informationsverarbeitung stellt den Zusammenhang zwischen
Prozess- und Funktionsmodellierung her.
(5) Träger der Tätigkeiten
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
Anstoßen – ausführen
– beenden
11.4 Basiselemente einer jeden Prozessmodellierung 91
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 Internetunternehmen vor, der den Umgang mit den Kunden beschreibt. Hier
wären neben den Kunden fast nur Programmkomponenen als Träger der Tätigkeiten
anzutreffen.
(6) Ereignisse
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 wie-
derum ein Ereignis dar, bzw. führt zu einem Ereignis – oder auch zu mehreren, ent-
sprechend der Operatoren. Dieses Konzept, Tätigkeitsfolgen und Ereignisse mitei-
nander 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").
(7) Kontrollfluss
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. Es gibt durchaus verschiedene Vorstel-
lungen 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 Vari-
ante 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.
(8) Andere Flüsse
Auch andere Flüsse, z.B. Nachrichten - und Materialflüsse sollten ausdrückbar sein.
(9) Ebenen – Kapselung
Eine Standardprozessmodellierung muss 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 Aktivi-
tätsknoten oder den Subautomaten in Zustandsautomaten (vgl. Kapitel 13 in [Staud
2010]).
Ereignisumwelt des
Unternehmens
92 11 Prozessmodelle, Prozessmodellierung
(10) Verweise, Verknüpfungen
Eher aus der Praxis der Modellierung kommt diese Theorieelement. Hier ist man oft
genötigt, lange Tätigkeitsfolgen aufzuteilen. Zum einen, weil dadurch oft genutzte
Prozessabschnitte an verschiedenen Stellen einfach per Verweis eingebaut werden
können, zum anderen schlicht wegen der Übersichtlichkeit der entstehenden Grafik.
(11) Zeitliche Dimension
Für eine Standardprozessmodellierung genügt es, wenn bzgl. der zeitlichen Dimen-
sion
die zeitliche Abfolge durch die sequentielle Anordnung,
Zeitpunkte und der
vorgesehene Zeitverbrauch (zumindest bei ausgewählten Tätigkeiten)
modelliert werden können.
Soweit, kurz und knapp, die Grundanforderungen an eine Standardprozessmodel-
lierung. Geht man weiter, insbesondere in Hinblick auf eine programmnahe Pro-
zessmodellierung, dann müssen diese Konzepte in vielerlei Hinsicht ergänzt werden,
wobei dabei die Betrachtung der „Verhaltens-Kapitel“ der objektorientierten Theorie
sehr hilfreich ist17
.
11.5 Grenzen der Prozessmodellierung
Prozessmodellierung hilft, Defizite in Geschäftsprozessen zu entdecken und zu be-
seitigen. Sie löst aber nicht alle Probleme, sie ist grundsätzlich auf die Ablauforgani-
sation konzentriert. Sie zeigt z.B. nicht Defizite auf, die bei der Abarbeitung einer
Tätigkeit auftreten. Im Prozessmodell steht z.B. Angebot erstellen, wie kompetent
dies getan wird, erfasst die Prozessbeschreibung üblicherweise nicht. Dies gilt
grundsätzlich für alle Aufgabenerfüllungen.
Prozessmodellierung gibt auch keine Antwort auf den Zielkonflikt zwischen der
Prozess- und der Ressourceneffizien18
, worauf Kugeler /Vieting hinweisen [Kugeler
und Vieting 2012, S. 197].
Zusammenfassung
Prozessmodellierung ist ein unverzichtbarer Bestandteil des Geschäftsprozessmana-
gements. Sie dient vielen Zielen, darunter der Dokumentation und Istanalyse, der
Prozessoptimierung und der Ableitung von Maßnahmen zur Steigerung der Kun-
denorientierung. Mit den Grundsätzen ordnungsgemäßer Modellierung liegt eine
Empfehlung zur Qualitätssicherung vor. Mit der Betrachtung der Basiselemente
einer jeden Prozessmodellierung liegt - bezüglich der Standardprozessmodellierung
- ein Komponentenschema vor, das bei der konkreten Gestaltung von Prozessmodel-
len hilft. Obwohl Prozessmodellierung bei vielen Aufgaben des Geschäftsprozess-
managements sehr hilfreich ist, löst sie natürlich nicht alle.
17 Vgl. die Kapitel 10 bis 13 in [Staud 2010a).
18 Ressourceneffizienz thematisiert den Auslastungsgrad von Ressourcen
aller Art. Sie ist hoch, wenn eine Ressource so ausgelastet wird, dass möglichst
wenig Leerzeiten entstehen.
12 Methode EPK
Die Ausführungen hier sind Auszüge aus dem Buch [Staud 2014], einer umfassenden Einführung in die Ereignisgesteuerten Prozessketten (vgl. für nähere Informationen www.staud.info).
12.1 Einführung
Ereignisgesteuerte Prozessketten (EPKs) beschreiben Geschäftsprozesse, ihre Tätig-
keiten (Funktionen genannt), die sie steuernden Ereignisse, die Handelnden (Orga-
nisationseinheiten genannt) und die benutzten oder erzeugten Informationen (Infor-
mationsobjekte genannt). Sie beschreiben alle möglichen Realisierungen des
Prozesses mit Hilfe von Verzweigungen und Zusammenführungen (Operatoren,
Konnektoren) und geben damit umfassend den sog. Kontrollfluss des Geschäftspro-
zesses an.
Istanalysen und Sollmodellierung
Sie sind das Werkzeug für die Analyse und Beschreibung von Geschäftsprozessen.
Dies gilt v.a. für Istanalysen von Geschäftsprozessen und für die Darstellung opti-
mierter Prozesse (Sollmodellierung), wie oben beschrieben. Nur wenn die Modellie-
rung auf eine Ebene mit höherem Detaillierungsgrad zielt, z.B. zu Vorbereitung der
Programmierung einer prozessorientierten Software, sind andere Modellierungsme-
thoden besser geeignet (vgl. die Abschnitte 12.2 und 12.5 in [Staud 2014]).
Diese Methode und die zugehörige grafische Beschreibungstechnik (Notation) für
Geschäftsprozesse wurde von Scheer und seinen Mitarbeitern im Rahmen ihres
ARIS-Konzepts (vgl. für eine Kurzdarstellung Abschnitt 13.1] entwickelt (vgl. [Kel-
ler, Nüttgens und Scheer 1992], Scheer 1997).
Ereignisgesteuerte Prozessketten sind eine semi-formale Methode. Sie genügen
nicht den Ansprüchen (wie auch im Weiteren zu sehen sein wird), die an formale
Methoden19
bzw. Sprachen gestellt werden müssen. So auch Rosemann in seinem
Beitrag in Mertens u.a. 1997, S. 334, wo er
informale, z.B. textliche Beschreibungen,
semi-formale, z.B. Ereignisgesteuerte Prozessketten, und
formale Methoden, wie z.B. die Prädikatenlogik
unterscheidet.
Auch die dort angeführten Forderungen an eine solche Methode, Darstellung des
Kontrollflusses, Abbildung von Nebenläufigkeit20
, von bedingten Verzweigungen
19 Vgl. für eine (unkonventionelle und verständliche) Einführung in formale Systeme [Hofstadter 1985.
20 Haben zwei Aufgaben weder eine direkte noch eine indirekte Verbindung, so sind sie nebenläufig,
d.h. sie können nacheinander oder nebeneinander ablaufen. „Die Ablauffolge beschreibt, ob eine
Aufgabe nach einer anderen Aufgabe (Präzedenz), gleichzeitig mit ihr (Parallelität) oder unabhängig
von ihr (Nebenläufigkeit) ablaufen soll.“ [Österle 1995, S. 51].
94 12 Methode EPK
und von Schleifen, die Wiedergabe des Datenflusses sowie die Angabe der invol-
vierten Organisationseinheiten und Informationssysteme erfüllen Ereignisgesteuerte
Prozessketten ohne weiteres.
Trotz des nicht voll formalen Charakters dieser Notation soll hier auch von Syn-
tax gesprochen werden, wenn die Regeln für den korrekten Aufbau der Ereignisge-
steuerten Prozessketten gemeint sind.
Modellelemente von Scheer
Eine immer noch tragfähige Auflistung notwendiger Modellelemente legte Scheer
schon vor vielen Jahren vor. Er unterscheidet folgende Komponenten bei IT-
gestützten Geschäftsprozessen [Scheer 1997]:
Vorgänge (mit denen die notwendigen Tätigkeiten erfasst werden, wie oben
gezeigt)
Ereignisse (die für den Geschäftsprozess Bedeutung besitzen, auch als be-
triebswirtschaftlich relevante Ereignisse definiert)
Zustände (die sich jeweils nach Abschluss einer Tätigkeit, vor allem in den
Daten, neu ergeben)21
Bearbeiter (und Bearbeiterinnen)
Organisationseinheiten sowie
Ressourcen der Informationstechnologie
die er dann, nochmals abstrahierend, zu folgenden Elementen seiner formalen Be-
schreibungssprache Ereignisgesteuerte Prozessketten zusammenfasst:
Ereignisse
Funktionen
Organisationseinheiten
Informationsobjekte
12.2 Elemente
12.2.1 Funktionen
Alle Tätigkeiten, die in einem Geschäftsprozess zu leisten sind, werden im Rahmen
der Prozessmodellierung als Funktionen in einer EPK erfasst. D.h., die Gesamtauf-
gabe des Geschäftsprozesses (z.B. Kalkulation erstellen) wird in einzelne Teilaufga-
ben unterteilt, mehr oder weniger detailliert. Die Festlegung, welchen Umfang an
elementaren Tätigkeiten die einzelne ausgewiesene Funktion hat, bleibt dem Model-
lierer überlassen. Der in xxx diesbezüglich diskutierte subjektive Faktor der Model-
lierung bleibt also erhalten.
Funktionen beschreiben bei Menschen deren operative Tätigkeit, bei einem IT-
System ein Programm, z.B. eine Transaktion oder einen betriebswirtschaftlichen
Funktionsbaustein.
21 Diese Bezeichnung sorgt oft für Verwirrung. Deshalb ganz klar: Es geht um die Zustände der Daten,
die sich im Prozessablauf ständig verändern - im Prinzip nach jeder Funktion. Also nach einem Auf-
tragseingang, nach Fertigstellung einer Kalkulation, usw.
Syntax
12.2 Elemente 95
Die grafische Darstellung von Funktionen geschieht durch ein Rechteck mit abge-
rundeten Ecken und einer Beschriftung in der Mitte des Rechtecks. Vgl. die folgen-
de Abbildung.
Abbildung 12.2-1: Grafische Darstellung von Funktionen
Die Benennung von Funktionen sollte so erfolgen, dass die Tätigkeit klar erkennbar
ist, am besten durch die Kombination von Substantiv und Verb. Also zum Beispiel:
Machbarkeit prüfen oder Machbarkeitsprüfung
Kalkulation erstellen
Auftrag ablehnen
12.2.2 Ereignisse
Unter Ereignissen werden hier betriebswirtschaftlich relevante Ereignisse verstan-
den. Diese beeinflussen und steuern auf die eine oder andere Weise die Abläufe im
Unternehmen. Einige Beispiele dafür sind:
Auftrag ist eingetroffen
Angebot ist gültig
Auftragsbestätigung ist übermittelt
Überweisung ist vorbereitet
Kundenanfrage ist abgelehnt
Kunde ist neu (als Ergebnis einer entsprechenden Prüfung)
Die Benennung von Ereignissen sollte genau so wie in diesen Beispielen erfolgen,
als aussagenlogischer Ausdruck. Das macht den Ereignischarakter klar.
Zur Definition von Ereignissen in der Prozessmodellierung können wir auf den
umgangssprachlichen Ereignisbegriff zurückgreifen, allerdings mit der Ergänzung,
dass es sich um betriebswirtschaftlich relevante Ereignisse handeln muss, die für den
betrachteten Geschäftsprozess Bedeutung haben.
Etwas enger gefasst wird diese Definition dadurch, dass in der Prozessmodellie-
rung eine enge Beziehung zwischen Funktionen und Ereignissen gesehen wird. Die
Durchführung einer Funktion führt zum Beispiel immer zu einem Ereignis („erle-
digt“) oder zu mehreren.
Ereignisse sind auf einen bestimmten Zeitpunkt bezogen. Dieser wird allerdings
in der Regel nicht spezifiziert. Er wird in den gängigen Darstellungen nur dadurch
festgelegt, dass ein Ereignis in eine Kette von Handlungen (Funktionen) und Ereig-
nissen (ein Zweig des Kontrollflusses) eingebettet wird. Mit anderen Worten: Ereig-
nisse lösen Funktionen aus und sind deren Ergebnis. Dies ist der Grund, weshalb
Scheer schreibt:
„Ein Ereignis kann als Auftreten eines Objekts oder Änderung einer
bestimmten Attributsausprägung definiert werden.“ Scheer 1998, S.
49
Wobei er hier mit Objekten z.B. Produkte meint. Ereignisse in diesem Sinn können
sich aus vorangegangenen Tätigkeiten sozusagen als Beschreibung der möglichen
Ergebnisse ergeben, sie können aber auch auf die nächsten Arbeitsschritte verweisen
Funktion - Ereignis -
…
Auf Zeitpunkte bezogen
96 12 Methode EPK
oder – quasi aus heiterem Himmel – von außen kommen („IT wurde gehackt“, „Auf-
trag ist eingegangen“).
Ereignisraum
Die Menge aller in einem Unternehmen und seinem Umfeld möglichen Ereignisse
sollen als der Ereignisraum des Unternehmens bezeichnet werden.
Ein Ereignis ist immer auch eine Feststellung, die irgendwie und von irgendje-
mandem getroffen werden muss. Ihm gehen Handlungen voraus und meistens folgen
auch welche nach. Diese werden hier mit dem oben schon eingeführten Begriff der
Funktionen erfasst.
Zwei Ereignisse eines jeden Geschäftsprozesses verdienen hervorgehoben zu
werden: das Startereignis und das Endereignis (oder Schlussereignis). Mit dem
Startereignis beginnt ein Geschäftsprozess (davor liegen, bezogen auf den einzelnen
Geschäftsprozess, keine Handlungen), mit dem Endereignis findet er seinen Ab-
schluss. Grundsätzlich können auch mehrere Start- und mehrere Endereignisse vor-
liegen.
Die grafische Darstellung von Ereignissen in Ereignisgesteuerten Prozessketten
erfolgt als ein die Breite gezogenes Sechseck mit der Benennung des Ereignisses in
der Mitte des Sechsecks.
Abbildung 12.2-2: Grafische Darstellung von Ereignissen
12.2.3 Organisationseinheiten
Mithilfe der Organisationseinheiten wird festgehalten, wer die in einer Funktion
erfasste Aufgabe tätigt. Dazu kann man die Abteilung usw. angeben (so ist die klas-
sische Lösung) oder die Anwendungssoftware, die automatisiert die Funktion reali-
siert. Geht es um durch Menschen realisierte Funktionen wird man heute, v.a. wenn
der Personalbestand schon sehr niedrig ist und/oder sich das Unternehmen von der
klassischen Aufbauorganisation wegbewegt, die Organisationseinheiten sehr klein
fassen, evtl. sogar auf Stellenebene gehen, um genügend Aussagekraft für die Ana-
lyse der Schwachstellen zu erhalten. Beispiele für (klassische) Organisationseinhei-
ten in einem Industrieunternehmen sind Vertrieb, Personalwesen, Werk, Informati-
onsvermittlungsstelle.
Die grafische Darstellung von Organisationseinheiten in Ereignisgesteuerten Pro-
zessketten erfolgte durch eine in der Mitte beschriftete Ellipse. Organisationseinhei-
ten sind immer durch eine richtungslose Verbindungslinie mit der Funktion verbun-
den, die realisiert wird.
Abbildung 12.2-3: Grafische Darstellung von Organisationseinheiten und ihre Anbin-
dung an Funktionen
Anfang und Ende
12.2 Elemente 97
Es hat sich eingebürgert, im Prozessfluss die Organisationseinheiten bei nachfolgen-
den Funktionen wegzulassen, wenn sie gleich sind wie bei der vorigen. Findet man
also bei einer Funktion keine Organisationseinheit(en), muss man flussaufwärts bis
zum letzten Vorkommen schauen.
12.2.4 Informationsobjekte
Keine Organisation kommt ohne Datenbestände aus, die die Organisation selbst,
seine Geschäftsobjekte und seine informationelle Umwelt ganz oder in Ausschnitten
modellieren. Diese Datenbestände sind damit auch für die Abwicklung der Ge-
schäftsprozesse von großer Bedeutung.
In Ereignisgesteuerten Prozessketten schlägt sich dies so nieder, dass bei den
Funktionen die jeweils geholten und benutzten bzw. entstehenden Informationen
angegeben werden. Dies können Kundendaten, die Angaben des früher erstellten
Angebots, aktuelle Marktpreise oder eine andere Information sein, die für irgendei-
nen Abschnitt des Geschäftsprozesses Bedeutung besitzt.
In der Methode EPK werden solche Daten als Informationsobjekte bezeichnet und
in Verbindung gesetzt mit der Funktion, für die sie benötigt werden. Dann werden
z.B. einer Funktion Auftragsbearbeitung folgende Informationen zugeordnet:
zu Kunden
zum Angebot
zu den Materialien
zu den Konditionen
zum Kundenauftrag
zum Bedarf an Teilen, usw.
Die grafische Darstellung von Informationsobjekten erfolgt als Rechteck mit der
Benennung in der Mitte. Jedes Informationsobjekt ist mit einer Funktion verbunden.
Bei dieser Beziehung zwischen Informationsobjekten und Funktionen wird mittels
einer Pfeilspitze unterschieden, ob die Informationen einfließen, d.h. im Rahmen der
Aufgabenerledigung benötigt werden, oder ob sie dabei entstehen. Die Pfeilspitze
drückt die Richtung des Informationsflusses aus.
Abbildung 12.2-4: Grafische Darstellung von Informationsobjekten und ihre Anbin-
dung an Funktionen
Wie im Folgenden zu sehen ist, werden damit Datenflüsse (im Sinne der Daten-
flussdiagramme) nur erfasst, wenn dieser Teil der Modellierung sehr sorgfältig ge-
schieht, was in der Praxis oft nicht der Fall ist.
Informationsträger aller Art
Informationsobjekte können nicht nur aus Daten von Datenbanken bestehen. Grund-
sätzlich kann jede Information auf jedem Informationsträger berücksichtigt werden.
98 12 Methode EPK
Der Hinweis auf nicht elektronische Träger (bei einer Istanalyse) kann sogar ein
erster Hinweis auf Möglichkeiten zur Optimierung des Geschäftsprozesses sein.
Informationsobjekte und Automatisierungsgrad
Grundsätzlich geben die Informationsobjekte auch Hinweise auf den Automatisie-
rungsgrad des betrachteten Geschäftsprozesses. In nicht oder nur teilweise automati-
sierten Abschnitten werden die Informationsobjekte oftmals (aber nicht immer!)
nicht digital sein.
Kontrollfluss: Die unsichtbare, ordnende Hand
Der oben schon eingeführte Begriff Kontrollfluss kann jetzt präzisiert werden. Die
in einem Geschäftsprozess möglichen Abfolgen von Ereignissen und Funktionen,
beginnend mit Startereignissen und endend mit Schlussereignissen, werden Kont-
rollfluss genannt.
Wie in xxx ausgeführt, wird ein einzelner konkreter Durchgang durch den Pro-
zess mit Instanz bezeichnet. Damit könnte man auch den Kontrollfluss als die Ge-
samtheit aller möglichen Instanzen des Geschäftsprozesses bezeichnen.
Beim Begriff Kontrollfluss ist also an alle möglichen Durchgänge durch den Ge-
schäftsprozess gedacht, einschließlich aller Verzweigungen, so wie sie die Semantik
des Geschäftsprozesses erfordert. Hier äußern sich die Geschäftsregeln (business
rules), aber auch der „gesunde Menschenverstand“ (ein Angebot muss erst geschrie-
ben werden, bevor es verschickt werden kann).
Kanten, Kontrollflusszweige
Die im Kontrollfluss nacheinander folgenden Ereignisse und Funktionen werden
durch Pfeillinien verbunden. Mehr dazu in den folgenden Kapiteln. Diese Pfeillinien
werden oft auch Kanten genannt, in Anlehnung an die Begrifflichkeit der
Graphentheorie. Mehrere solche Kanten mit ihren Ereignissen und Funktionen stel-
len einen Kontrollflusszweig dar. Dieser kann von einem Startereignis bis zu einem
Endereignis reichen.
Geschäftsprozesse und damit auch Ereignisgesteuerte Prozessketten haben eine
Richtung, vom Startereignis zum Schlussereignis, weshalb auch von flussaufwärts
(zurück Richtung Startereignis) und flussabwärts (Richtung Schlussereignis) ge-
sprochen werden kann.
12.2.5 Operatoren und Kontrollfluss
Der Kontrollfluss eines Geschäftsprozesses besteht nicht nur aus einfachen Abfol-
gen von Ereignissen und Funktionen, sondern auch aus Verzweigungen von Kon-
trollflusszweigen und aus Zusammenführungen. Zum Beispiel, wenn mehrere Tätig-
keiten „parallel“ erledigt werden müssen, um ein Ziel zu erreichen. Oder wenn es
Alternativen gibt: Entweder die eine oder die andere Tätigkeit führt zum Ziel. Ge-
nauso mit Ereignissen. Manchmal können alternative Ereignisse dieselbe Tätigkeit
auslösen oder mehrere Ereignisse zusammen die Bedingung sein für den Beginn
einer Tätigkeit. Für dieses Strukturmerkmal von Geschäftsprozessen und Ereignis-
gesteuerten Prozessketten werden Operatoren (manchmal auch Konnektoren ge-
nannt) benötigt.
12.2 Elemente 99
Für die Modellierung von Geschäftsprozessen durch EPKs genügen drei solche
Operatoren. Hier die Bezeichnungen mit den grafischen Symbolen:
UND:
ODER:
exklusives ODER (auch XODER):
Es sind mehrstellige logische Operatoren, d.h. es werden immer mindestens zwei
Elemente verknüpft. Dabei gilt: Entweder werden Ereignisse mit Ereignissen oder
Funktionen mit Funktionen verknüpft.
Die Operatoren können nur Ereignisse mit Ereignissen und Funktionen mit Funktionen verknüpfen, nicht Ereignisse mit Funktionen.
Für Ereignisse haben die Verknüpfungen folgende Bedeutung:
UND: alle verknüpften Ereignisse müssen eintreten, erst dann geht es im Kont-
rollfluss weiter
ODER: mindestens eines der verknüpften Ereignisse muss eintreten, erst dann
geht es im Kontrollfluss weiter
XODER: genau eines der verknüpften Ereignisse muss eintreten, erst dann geht
es im Kontrollfluss weiter
Für Funktionen haben sie folgende Bedeutung:
UND: alle verknüpften Funktionen müssen getätigt werden, erst dann geht es im
Kontrollfluss weiter
ODER: mindestens eine der verknüpften Funktionen muss getätigt werden, erst
dann geht es im Kontrollfluss weiter
XODER: genau eine der verknüpften Funktionen muss getätigt werden, erst
dann geht es im Kontrollfluss weiter
Eine genauere Bestimmung der Bedeutung der Operatoren hängt von der Stellung
im Kontrollfluss ab. Davon, ob z.B. die verknüpften Ereignisse vor oder nach einer
Funktion stehen. Vgl. hierzu die Verknüpfungsbeispiele in [Staud 2014, Kapitel
5xxx].
In den grafischen Darstellungen geht man bei Ereignisgesteuerten Prozessketten
meist von der Festlegung aus, dass der Kontrollfluss der Übersichtlichkeit halber
von oben nach unten angeordnet wird. Deshalb werden die Operatoren in der grafi-
schen Notation in einem zweigeteilten Kreis platziert, z.B. so:
Dort wo ein Operator ist, ist dann mehr als eine Kante, liegt kein Operator vor,
geht es nur eine einzige Kante. Liegen oben und unten mehr als eine Kante vor,
müssen auf beiden Seiten Operatoren vorhanden sein. Hier zwei Beispiele.
Die obere Hälfte gibt an, wie die durch die „ankommenden“ Kontrollflüsse reprä-
sentierten Ereignisse oder Funktionen verknüpft sind. Die untere Hälfte leistet das-
selbe für die weggehenden Kanten.
Syntaxregel: Das Verzweigen und Zusammenführen von Kontrollflusszwei-gen kann nur über Operatoren erfolgen.
100 12 Methode EPK
Zwei zusätzliche Begriffe sollen bezüglich der Operatoren noch unterschieden
werden: Verteiler und Verknüpfer. Kommt ein Zweig an und gehen mehrere weg,
wird der Operator als Verteiler bezeichnet. Fließen umgekehrt mehrere hinein und
nur einer heraus, handelt es sich um einen Verknüpfer.
12.2.6 Zeitliche Dimension und Zeitverbrauch
In der Abfolge der Funktionen in einem Kontrollflusszweig drückt sich dann auch
eine zeitliche Dimension aus. Die Prüfung Lagerbestand kann erst dann aktiviert
werden, wenn das Ereignis Anfrage eingetroffen eingetreten ist, die Funktion Kunde
absagen nur, wenn vorher das Ereignis Lagerbestand reicht nicht eintrat, usw. Mit
anderen Worten: Eine Funktion wird erst begonnen, wenn die vorherige abgeschlos-
sen ist.
Somit erfolgt eine erste fundamentale zeitliche Festlegung bei jeder Ereignisge-
steuerten Prozesskette dadurch, dass die Funktionen - getrennt durch Ereignisse -
nacheinander angeordnet sind. Dadurch ist ihre Reihenfolge festgelegt. Diese Fest-
legung ist allerdings keine absolute, mit Angabe des Zeitverbrauchs, sondern nur
eine relative (zu den anderen Funktionen).
In Ereignisgesteuerten Prozessketten wird der Zeitverbrauch, also eine Angabe
wie, diese Funktion muss innerhalb eines Tages erledigt sein, im Regelfall nicht
erfasst. Eine Ausnahme ergibt sich bei Funktionen, die das Warten auf die Reaktion
eines anderen ausdrücken (Wartefunktionen). Da ist es durchaus denkbar, ein Ereig-
nis, das die abgelaufene Zeit signalisiert, mit in die EPK einzubauen. Z.B. so, dass
als ein Ergebnis der Wartefunktion ein Ereignis wie Zeit ist abgelaufen oder zwei
Wochen sind vergangen eingefügt wird.
Wie „rettet“ man Informationen über die Zeit
Die Prozessmodellierung mit Ereignisgesteuerten Prozessketten kennt keine Nach-
richten, Informationskanäle, und ähnliche Elemente, die ein Kommunikationsnetz
etablieren könnten. Hier werden Informationen bei ihrer Entstehung in die Unter-
nehmensdatenbank geschrieben und später im Prozess bei Bedarf wieder gelesen.
Dies entspricht auch der Philosophie moderner ERP-Software22
mit ihrer integrierten
unternehmensweiten Datenbank.
Eher systemorientierte Modellierungsansätze wie die Dynamikkomponenten der
UML23
gehen teilweise andere Wege. Hier gibt es durchaus auch das Konzept des
Nachrichtenaustausches zwischen den Elementen des Systems. Auch die Methode
BPMN (Kapitel xxx) kennt den Nachrichtenaustausch zwischen handelnden Einhei-
ten, sogar ein "Broadcastsignal", eine Nachricht an alle übrigen Komponenten.
12.3 Aufbau Ereignisgesteuerter Prozessketten
Die im vorigen Kapitel beschriebenen Elemente von Ereignisgesteuerten Prozessket-
ten werden in der Prozessmodellierung verknüpft, um aussagekräftige Beschreibun-
gen von Geschäftsprozessen zu erhalten. Die meisten dafür gültigen Regeln werden
in diesem Abschnitt vorgestellt. Um die Anschaulichkeit zu erhöhen, wird den Aus-
führungen ein einfacher Geschäftsprozess zugrundegelegt. Dieser wird Stück für
22 Wenn sie nicht Workflow-Komponenten haben, die natürlich auf einem Informationsaustausch
aufbauen.
23 Sequenzen, Aktivitäten, Zustandsautomaten, Anwendungsfälle, …
Verteiler und Verknüpfer
Zeitliche Dimension
eines
Geschäftsprozesses bzw. einer EPK
Nicht absolut, nur relativ
Zeitverbrauch
In die Datenbank schreiben und von dort
lesen
12.3 Aufbau Ereignisgesteuerter Prozessketten 101
Stück beschrieben, danach wird die Umsetzung in die EPK erläutert. Die entstehen-
de EPK wird bei jedem Schritt fortgeschrieben, um den Gesamtzusammenhang
jeweils deutlich zu machen.
12.3.1 Anfrageprüfung Teil 1
Prozessbeschreibung
Der folgende Geschäftsprozessausschnitt liegt hier zugrunde: Es geht – bei einem
Industrieunternehmen mit Einzelfertigung – um die Prüfung, ob die Anfrage eines
Kunden nach einem bestimmten Produkt erfüllt werden kann oder nicht.
Die Anfrage kann per Mail, per Brief eintreffen oder in einem Ge-
spräch formuliert worden sein. Bei Briefanfragen wird ein Antwort-
brief verfasst und versendet. Bei Mailanfragen wird der Maileingang
bestätigt, bei im Gespräch formulierten Anfragen eine Auftragsfestle-
gung (AFL) formuliert und dem potentiellen Kunden geschickt. Alle
diese Aktivitäten übernimmt das Zentralsekretariat.
Umsetzung in die EPK
Beginnen wir mit dem Wichtigsten, das ein Geschäftsprozess aufweist, den Arbei-
ten, die in ihm geleistet werden. Hier sind ohne weiteres drei Funktionen erkennbar:
Antwortbrief verfassen und versenden
Maileingang bestätigen
AFL erstellen und dem potentiellen Kunden senden
Die folgende Abbildung zeigt die grafische Darstellung der Funktionen. Ergänzt
sind noch drei weitere, die sich im Verlauf der Modellierung ergeben.
Abbildung 12.3-1: Die ersten Funktionen der Anfrageprüfung
Die Startereignisse sind in der Prozessbeschreibung klar beschrieben:
Anfrage per Brief eingetroffen
Anfrage per Mail eingetroffen
Anfrage im Gespräch formuliert
Ansonsten gilt ja, dass sich Funktionen und Ereignisse im Kontrollfluss ablösen.
Deshalb folgen den ersten drei Funktionen jeweils Ereignisse, die so beschrieben
werden können:
Antwortbrief verschickt
Bestätigungsmail verschickt
AFL verschickt (AFL: Auftragsfestlegung)
In dieser Konstellation (klar die Erledigung ausdrückend) können sie auch Ergeb-
nisereignisse genannt werden. Alle diese sechs Ereignisse zeigt die folgende Abbil-
dung.
102 12 Methode EPK
Abbildung 12.3-2: Die ersten Ereignisse der Anfrageprüfung
Nun zum Kontrollfluss dieser Anfangssequenz. Ganz grundsätzlich wird die Syntax-
regel eingehalten, dass Funktionen und Ereignisse sich immer ablösen müssen und
dass jeder Geschäftsprozess mit einem Ereignis endet und beginnt. Die drei Starter-
eignisse stellen den Anfang von Kontrollflusszweigen dar, der aus einzelnen Kanten
besteht, wie es die folgende Abbildung zeigt. Diese stoßen jeweils eine Funktion an,
nach dieser folgen die oben schon angeführten Ergebnisereignisse. Der Fluss wird
also durch die Pfeillinien (Kanten) ausgedrückt. An den Funktionen ist die Organisa-
tionseinheit Zentralsekretariat angefügt - mit einer richtungslosen Linie.
Informationsobjekte und Organisations-einheiten
Die Informationsobjekte wurden entsprechend der Prozessbeschreibung angelegt:
Die von außen kommende Anfrage (als Brief, als Mail) mit Pfeil zur Funktion, die
entstehenden Informationsobjekte Auftragsfestlegung, Antwortbrief, Bestätigungs-
mail mit Pfeil zum Informationsobjekt. Die handelnde Organisationseinheit ist hier
immer das Zentralsekretariat.
12.3.2 Anfrageprüfung Teil 2
Prozessbeschreibung
Anschließend wird durch den Vertrieb die Anfrage in der ERP-
Software angelegt.
Danach folgen zwei Prüfungen: die der zur Verfügung stehenden Fer-
tigungskapazitäten (durch die Abteilung Produktion) und die des La-
gerbestandes (durch die Abteilung Lager). Dabei werden Daten der
Produktionsplanung bzw. die Lagerdatenbank genutzt. Beide Prüfun-
gen können zu einem positiven oder zu einem negativen Ergebnis füh-
ren.
Prozessmodellierung
Die Prozessbeschreibung macht es klar: Unabhängig davon, welches Startereignis
den Prozess startet, der Kontrollfluss geht in einem einzigen Zweig weiter. Für das
Zusammenführen der Kontrollflusszweige muss hier der XODER-Operator genom-
men werden, da die Startereignisse alternativ sind. Muss innerhalb einer EPK zu-
sammengeführt werden gilt, dass mit demselben Operator zusammengeführt wird,
mit dem aufgeteilt wurde. Damit ergibt sich das folgende EPK-Fragment.
12.3 Aufbau Ereignisgesteuerter Prozessketten 103
Abbildung 12.3-3: Geschäftsprozess Anfrageprüfung – Zusammenführung alternati-
ver Startsequenzen
Danach kommt es zur Anlage der Anfrage im ERP-System, es entsteht ein neues
Informationsobjekt: AnfrageERP, weshalb der Pfeil zum Informationsobjekt zeigt.
Dieses Beispiel zeigt anschaulich den Umgang mit Informationsobjekten in Ereig-
nisgesteuerten Prozessketten. Zuerst wird die Anfrage (B/M/AFL)24
gelesen, dann
wird die AnfrageERP geschrieben. Diese Reihenfolge wird im Modell nicht ausge-
drückt, sie muss aus der Prozessbeschreibung bzw. der Prozesssituation gefolgert
werden.
Etwas spannender wird der nächste Abschnitt des Geschäftsprozesses. Die Pro-
zessbeschreibung gibt hier ein in Geschäftsprozessen oft anzutreffendes Muster vor:
mehrere Funktionen (Tätigkeiten, Aktivitäten) werden gleichzeitig angestoßen (vgl.
zu einer umfassenden Darstellung der Muster in Geschäftsprozessen [Staud 2014a,b
Kapitel 6]). Dies kann mithilfe eines UND-Operators umgesetzt werden, wie es die
folgende Abbildung zeigt. Der UND-Operator erzwingt, dass beide Funktionen,
Prüfung Fertigungskapazität und Prüfung Lagerbestand, angestoßen werden. Die in
der Prozessbeschreibung genannten Organisationseinheiten sind angefügt. Das In-
formationsobjekt AnfrageERP dient bei beiden Funktionen als Input, ebenso die
abgefragten Datenbestände (Produktionsplanung und Lagerdatenbank).
24 In dieses Informationsobjekt wurden die drei Anfragen zusammengefasst (B=Brief, M=Mail,
AFL=Auftragsfestlegung). Ein solcher Abstraktionsschritt ist oft sehr sinnvoll, da er das Modell
übersichtlich hält, ohne die Aussagekraft zu beeinträchtigen.
104 12 Methode EPK
Abbildung 12.3-4: Geschäftsprozess Anfrageprüfung. Anstoßen zweier Funktionen
mit dem UND-Operator und Muster Entscheidungsfindung.
Natürlich führt jede der beiden neuen Funktionen zu Ergebnissen, die als Ereignisse
modelliert werden25
. Entsprechend der Prozessbeschreibung wird umgesetzt, dass es
je ein positives und ein negatives gibt:
Kapazität reicht und Kapazität reicht nicht für die Prüfung Fertigungskapazität
Lagerbestand ausreichend und Lagerbestand reicht nicht für die Prüfung Lagerbe-
stand.
25 Folgen auf eine Funktion Ereignisse, die durch ein XODER verknüpft sind, spiegeln die Ereignisse
immer alternative Ergebnisse der Funktion wider. Vgl. dazu das Muster Entscheidungsfindung in
[Staud 2014a,b, Abschnitt 6.1].
12.3 Aufbau Ereignisgesteuerter Prozessketten 105
Da diese jeweils alternativ sind, muss hier in den Kontrollfluss ein XODER-
Operator eingefügt werden.
12.3.3 Anfrageprüfung Teil 3
Prozessbeschreibung
Im positiven Fall, wenn also die Prüfungskapazität reicht und der La-
gerbestand ausreichend ist, wird dem Kunden durch den Vertrieb zu-
gesagt. Dazu wird die AnfrageERP benötigt. In ihr wird auch die Zu-
sage vermerkt. Aus der Kundendatei werden die benötigten
Informationen gelesen und in ihr wird vermerkt, dass eine Anfrage
positiv beantwortet wurde.
Anschließend wird der Geschäftsprozess Auftragsbearbeitung ange-
stoßen.
Prozessmodellierung
Diese Semantik wird in einer Ereignisgesteuerten Prozesskette so umgesetzt, dass
die Kontrollflüsse der beiden „positiven“ Ereignisse zusammengeführt, mit einem
UND-Operator verbunden und zur entsprechenden Funktion weitergeführt werden.
Hier also zur Funktion Dem Kunden zusagen. Kurzes Nachdenken macht klar, dass
diese EPK-Syntax tatsächlich die in der Prozessbeschreibung geforderte Semantik
erfasst: Zum Weiterfluss kommt es nur, wenn beim UND-Operator beide Kontroll-
flusszweige von den Ereignissen her ankommen.
Bei der Funktion Dem Kunden zusagen werden dann noch die genannte Organisa-
tionseinheit und die beiden Informationsobjekte angefügt. Beide werden gelesen und
beschrieben, weshalb die Pfeile der Verbindungslinien in beide Richtungen zeigen.
106 12 Methode EPK
Abbildung 12.3-5: Geschäftsprozess Anfrageprüfung – Positives Ergebnis und Auf-
ruf Auftragsabwicklung
Da in der Prozessbeschreibung an dieser Stelle gleich das positive Endergebnis, der
Aufruf des anschließenden Geschäftsprozesses Auftragsabwicklung angeführt wird,
kann hier durch einen Prozesswegweiser auf eine entsprechende EPK verwiesen
12.3 Aufbau Ereignisgesteuerter Prozessketten 107
werden. Dieses Methodenelement dient als Verweis auf einen anderen Prozess. Die
obige Abbildung zeigt den damit erreichten Stand im Geschäftsprozess Anfrageprü-
fung, die folgende den Beginn des Geschäftsprozesses Auftragsabwicklung.
Abbildung 12.3-6: Start des Geschäftsprozesses Auftragsabwicklung
Muster Bedingungen
Der hier nun schon mehrfach vorgekommene UND-Operator bedeutet, dass der
Kontrollfluss über ihn nur weitergeht, wenn alle Kontrollflusszweige von flussauf-
wärts ankommen. In dieser Anordnung (Ereignisse durch UND verknüpft vor einer
Funktion) stellen die Ereignisse immer Bedingungen für die Ausführung der nach-
folgenden Funktion dar. Vgl. für eine umfassende Darstellung solcher Muster in
Geschäftsprozessen [Staud 2014a,b].
12.3.4 Anfrageprüfung Teil 4
Prozessbeschreibung
Falls entweder die Kapazität oder der Lagerbestand nicht reicht, wird
dem Kunden durch den Vertrieb abgesagt. Dafür wird die
AnfrageERP benötigt, in der auch die Absage vermerkt wird. Ebenso
die Kundendatei, in der ebenfalls das Scheitern der Anfrage festgehal-
ten wird.
Prozessmodellierung
Die Prozessbeschreibung macht es klar: Wenn eine der beiden Prüfungen negativ
ausfällt, wird dem Kunden abgesagt. Diese Situation entspricht einer, die hier Mus-
ter Kombinatorik genannt wird. Der Grund ist, weil die Ergebnisereignisse der bei-
den Funktionen miteinander kombiniert werden müssen, um alle möglichen Fortfüh-
rungen des Geschäftsprozesses zu erfassen:
1. Kapazität reicht nicht – Lagerbestand ausreichend
2. Kapazität reicht nicht – Lagerbestand reicht nicht
3. Kapazität reicht – Lagerbestand ausreichend
4. Kapazität reicht – Lagerbestand reicht nicht
Die folgende Abbildung zeigt dieses grundsätzliche Vorgehen. Für alle vier Konstel-
lationen gibt es eine Weiterführung und eine entsprechende Funktion. Der UND-
Operator leistet hier - wiederum bei der Suche nach einer Syntax für diese Semantik
- sehr gute Dienste. Da es über ihn nur weiter geht im Kontrollfluss, wenn alle weg-
führenden oder ankommenden Kanten aktiviert werden (nur die Kanten(!), nicht die
nachfolgenden Funktionen), führt diese syntaktische Lösung zur gewollten Seman-
tik.
108 12 Methode EPK
Abbildung 12.3-7: Kombinatorik - in vollem Umfang realisiert
In dem konkreten Geschäftsprozess hier wurde die positive Variante (der positive
Fall) oben schon erledigt. Jetzt geht es um die drei Fälle, bei denen entweder die
eine Prüfung oder die andere oder beide negativ ausfallen. Diese können hier zu-
sammengefasst werden, da ja bei einem negativen Ergebnis bei einer der Prüfungen
auf jeden Fall abgebrochen wird.
Die Umsetzung dieser Semantik in die Syntax einer EPK zeigt die folgende Ab-
bildung. Vor die Funktion Dem Kunden absagen wird ein ODER-Operator gesetzt,
der die Kontrollflusszweige der beiden negativen Ergebnisereignisse zusammen-
führt. Es muss ein ODER-Operator sein, da entweder das eine Ereignis oder das
andere oder beide dazu führen sollen, dass der Kontrollfluss über ihn zur Funktion
Dem Kunden absagen und zu dem nachfolgenden Ereignis Dem Kunden abgesagt
weiterführt. Insgesamt hat der Geschäftsprozess damit zwei Schlussereignisse. Die
folgende Abbildung zeigt das Endergebnis.
In der Praxis kommt es recht oft vor, dass die große Zahl von Kombinationen
(man stelle sich nur auf der einen Seite 5 und auf der anderen Seite 4 Ergebnisereig-
nisse vor) durch eine entsprechende Semantik verkleinert wird.
12.3 Aufbau Ereignisgesteuerter Prozessketten 109
Abbildung 12.3-8: Geschäftsprozess Anfrageprüfung – Die finale EPK
110 12 Methode EPK
12.3.5 Instanzen
Die oben erstellte Ereignisgesteuerte Prozesskette zeigt alle möglichen Durchgänge
durch den Prozess, den gesamten Kontrollfluss also. Manchmal ist es aber sinnvoll,
einen einzelnen konkreten Durchgang mit seinem konkreten Kontrollfluss zu be-
trachten. Eine solche EPK wird als Instanz der „allgemeinen“ EPK bzw. der konkre-
te Geschäftsprozessdurchgang als Instanz des „allgemeinen“ Geschäftsprozesses
bezeichnet.
Die folgende Abbildung zeigt eine Instanz der obigen EPK, die für den positiven
Fall26
. Dieser ist durch eine verdickte Linie hervorgehoben. Das Startereignis sei
Anfrage per Mail eingetroffen. Es könnte auch jedes der beiden anderen Startereig-
nisse sein. Der folgende Ablauf ist bis zum UND-Operator und den ihm nachfolgen-
den Funktionen für alle Instanzen gleich. D.h., der UND-Operator „sendet“ immer
alle von ihm wegführenden Kanten (Kontrollflusszweige) los.
Danach beginnen die möglichen Unterschiede zwischen den Instanzen. Hier („po-
sitiver Fall“) ist es so, dass beide Prüfungen positiv ausfallen. Die anderen Kanten
werden bei dieser Instanz nicht wirksam. Entsprechend sind die Kanten, die von den
Funktionen zum positiven Ergebnis führen, dick gesetzt.
Von den beiden Ergebnisereignissen (Kapazität reicht, Lagerbestand ausrei-
chend) führen die bei dieser Instanz wirksamen Kanten zum UND-Operator und
kommen sogar – da ja beide eintreffen – über ihn hinweg zur Funktion Dem Kunden
zusagen. Danach kommt nur noch der Prozesswegweiser, der zum nächsten Ge-
schäftsprozess bzw. seiner EPK verweist.
26 Auftrag kann angenommen, Folgeprozess kann gestartet werden.
Kontrollfluss für den
positiven Fall
12.3 Aufbau Ereignisgesteuerter Prozessketten 111
Abbildung 12.3-9: Geschäftsprozess Anfrageprüfung. Die Instanz für den positiven
Ausgang.
112 12 Methode EPK
Kontrollfluss für einen der negativen Fälle
Die folgende Abbildung zeigt eine andere Instanz, einen der Kontrollflussdurchgän-
ge, der zu einem negativen Ergebnis führt. Wiederum sind die entsprechenden Kont-
rollflusspfeile verdickt.
Als Startereignis wurde hier Anfrage im Gespräch formuliert gewählt. Es folgt
die entsprechende Funktion und dann, nach dem XODER-Operator, die Anlage der
Anfrage im ERP-System. Bis zum Aufruf der beiden Funktionen nach dem UND-
Operator ist der Kontrollfluss dann gleich wie oben. Eine der anschließenden Funk-
tionen (Prüfung Fertigungskapazität) führt dann aber zum negativen Ergebnis, wes-
halb der Kontrollfluss hier gleich zur Absage weitergeht.
Die Prüfung des Lagerbestandes mit ihrem positiven Ergebnis führt zwar noch
zum nachfolgenden UND-Operator, da bleibt dieser Kontrollflusszweig aber „hän-
gen“, da es über den UND-Operator nur weiter geht, wenn beide Kontrollflusszwei-
ge oben ankommen. Die Stelle ist durch ein Ausrufungszeichen markiert. Insofern
hat auch hier wieder die Semantik die treffende EPK-Syntax gefunden.
Semantik sucht Syntax
12.3 Aufbau Ereignisgesteuerter Prozessketten 113
Abbildung 12.3-10: Geschäftsprozess Anfrageprüfung. Die Instanz für einen der nega-
tiven Fälle.
Soviel für eine Einführung in die Methode der Ereignisgesteuerten Prozessketten.
Sie sollte deutlich gemacht haben, dass mit dieser Methode Geschäftsprozesse effi-
114 12 Methode EPK
zient modelliert werden können. Dies gilt insbesondere für Istanalysen. Eine
detaillieerte Darestellung findet sich in [Staud 2014a,b].
Zusammenfassung
Ereignisgesteuerte Prozessketten erlauben auf effiziente Weise die Modellierung
von Geschäftsprozessen. Es sind nur die Elemente Funktionen, Ereignisse, Organi-
sationseinheiten und Informationsobjekte sowie ein Kontrollflusskonzept mit drei
Operatoren nötig, um aussagekräftige Prozessmodelle zu erstellen, die Hinweise auf
Stärken und Schwächen der modellierten Geschäftsprozesse geben.
13 Methode BPMN
Die Ausführungen hier sind Auszüge aus dem Buch [Staud 2017], einer umfassenden Einführung in die die Methode BPMN (vgl. für nähere Informa-tionen www.staud.info).
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.
13.1 Geschäftsprozesse
Wie definieren die BPMN-Autoren Geschäftsprozesse? Im Text finden sich
folgende Definitionsmerkmale [OMG 2011, S. 145]:
Ein Geschäftsprozess ist eine Aktivität, die in einer Organisation oder zwischen
mehreren ausgeführt wird.
Das Ziel eines Prozesses ist eine Leistungserbringung.
Ein Prozess besteht aus Aktivitäten, Ereignissen, Operatoren (hier Gateways
genannt) und einem Sequenzfluss. Er wird dann dargestellt als ein Graph für die
genannten Elemente.
Prozesse gibt es auf mehreren Hierarchieebenen. Man kann sie unternehmens-
weit definieren oder auch entlang der Aktivitäten einer Person.
Prozesse auf einem niedrigen Aggregationsniveau (low-level processes), die
zusammen eine Aufgabe erledigen, können gruppiert werden.
Jeder Prozess kann seine eigenen Subprozesse haben und kann in einem Pool
enthalten sein.
Einzelne Prozesse können voneinander unabhängig sein, was den Sequenzfluss
angeht, aber verbunden durch einen Nachrichtenfluss.
Damit sind einige Elemente zusammengestellt, die man für die Modellierung von
Geschäftsprozessen benötigt. Die Aktivitäten sind die kleinsten Einheiten (des Ge-
schäftsprozesses, der Tätigkeitsfolge), aus denen man den Gesamtprozess zusam-
menstellt. Der Sequenzfluss erlaubt die Festlegung, wie die Aktivitäten aufeinander
folgen, wie sie verzweigen und wieder zusammenkommen, ähnlich dem ansonsten
üblichen Kontrollflusskonzept. Die Ereignisse trennen die elementaren Tätigkeiten
und die Operatoren, hier mit Gateways bezeichnet, erlauben die Strukturierung des
Kontrollflusses in der üblichen Art und Weise.
Prozess vs. Geschäftsprozess
Bezüglich der Abgrenzung von Prozessen und Geschäftsprozessen führen die
BPMN-Autoren aus, dass sie den Begriff Prozess spezifisch sehen und den des Ge-
schäftsprozesses allgemeiner als eine Menge von Aktivitäten, die innerhalb einer
Organisation oder über Organisationen hinweg realisiert werden.
116 13 Methode BPMN
Im Rahmen ihrer Typisierung von Geschäftsprozessen sprechen sie von “end-to-
end BPMN model” und unterscheiden drei Basistypen [OMG 2011, S. 2]:
Interne nicht ausführbare Geschäftsprozesse (private non-executable (internal)
business processes)
Interne ausführbare Geschäftsprozesse (private executable (internal) business
processes)
Öffentliche Prozesse (public processes)
Mit Internen Geschäftsprozessen sind schlicht die gemeint, die innerhalb einer Or-
ganisation ablaufen. Da die Zuordnung von Trägern der einzelnen Tätigkeiten zu
den Geschäftsprozessen in der BPMN über die Schwimmbahnentechnik mit Becken
und Bahnen erfolgt (vgl. [Staud 2010]), können die BPMN-Autoren auch definieren,
dass die internen Prozesse in einem Becken (pool) ablaufen.
Kommt es zu einer Interaktion (i.d. Regel ist dies ein Informationsfluss, z.B. eine
Rechnung) zwischen einem internen Geschäftsprozess und anderen Prozessen oder
Partizipanten, sprechen die BPMN-Autoren von einem öffentlichen Geschäftspro-
zess. In diesen wird folgendes gepackt:
Die Aktivitäten, die benutzt werden, um mit der Umgebung des privaten Ge-
schäftsprozesses zu kommunizieren.
Die entsprechenden Sequenzflusselemente.
Alle anderen Aktivitäten des internen Prozesses werden nicht angegeben [OMG
2009, S. 13]. Somit zeigt der öffentliche Prozess der Außenwelt die Folge von Nach-
richten, die notwendig sind, um mit diesem Geschäftsprozess zu interagieren.
Ein Globaler Prozess beschreibt das Zusammenwirken von zwei oder mehr Ge-
schäftseinheiten (business entities). Die Interaktionen sind eine Folge von Aktivitä-
ten, die den Nachrichtenaustausch zwischen den handelnden Einheiten darstellen.
Gruppierung der Elemente
Die BPMN-Autoren teilen die verwendeten Elemente in vier Gruppen ein:
Flussobjekte (flow objects)
Verknüpfende Objekte (connecting objects)
Schwimmbahnen (swimlanes)
Artifakte (artifacts)
Die Flussobjekte werden noch unterteilt in:
Ereignisse
Aktivitäten
Gateways (Operatoren)
Verknüpfende Objekte
Als verknüpfende Objekte werden die bezeichnet, mit denen die Flussobjekte mitei-
nander verknüpft werden können. Dies ist möglich durch:
Sequenzfluss
Nachrichtenfluss
Assoziationen
Schwimmbahnen
13.2 Einführung durch Beispiele 117
Schwimmbahnen dienen der Gruppierung der Basismodellelemente. Hier wird un-
terschieden in
Becken (pools)
Bahnen (lanes)
Artifakte liefern zusätzliche Informationen über den Prozess. Drei werden vorgege-
ben, andere können – so die BPMN-Autoren – hinzugefügt werden:
Datenobjekte
Gruppen
Anmerkungen
13.2 Einführung durch Beispiele
13.2.1 Das erste Business Process Diagram
Wie in den Methoden zur Prozessmodellierung üblich, gibt es ein Element, das Tä-
tigkeiten erfasst. Es wird durch ein Rechteck mit abgerundeten Ecken dargestellt.
Mit ihm wird erfasst, was in dem Geschäftsprozess konkret getan wird, genauer: in
welche einzelnen Aktivitäten der Geschäftsprozess zerlegt wurde. Dieses Element
wird in der BPMN Aktivität genannt.
Abbildung 13.2-1: Darstellung einer Aktivität (Subprozess, Aufgabe).
Es gibt auch eines, das den Kontrollfluss (hier sequence flow, übersetzt mit Sequenz-
fluss) ausdrückt, gerichtete Pfeile, die die einzelnen Aktivitäten verbinden sowie
Start- und Schlussereignisse (Kreis mit dünner bzw. dicker Linie) für den Anfang
und das Endes eines Geschäftsprozesses. Damit können wir - bei Hinzunahme der
Elemente für Prozessstart und Prozessende - bereits ein erstes natürlich noch sehr
schlichtes Prozessmodell erstellen: Eine Folge von Aktivitäten, die - einmal initiiert
- nacheinander abgewickelt werden.
Abbildung 13.2-2: Auftragsabwicklung - Variante 1
Natürlich ist das wirkliche "Prozessleben" nicht so einfach und es fehlt hier auch
noch vieles, was man in der Prozessmodellierung erwartet, aber dies kommt noch.
Am meisten vermisst man in obigem Beispiel sicherlich die Entscheidung, ob der
Auftrag überhaupt angenommen wird und das Auffächern der Tätigkeiten in paralle-
le Pfade, Auftragsabwicklung auf der einen und Zahlungsabwicklung auf der ande-
ren Seite. Dies ist aber möglich, die dafür nowendigen Operatoren liegen in der
Methode vor.
Betrachten wir dazu die folgende Abbildung. In ihr ist obiges Business Process
Diagram (BPD) etwas ausgebaut. Es ist außerdem mit Nummern in Kreisen verse-
118 13 Methode BPMN
hen. Diese sind nicht Teil der Methode BPMN, sondern dienen nur der Kennzeich-
nung für die folgenden Ausführungen.
Wie in der vorigen Abbildung liegt ein Startereignis vor (1), das die Aktivität
Auftragseingang (2) anstößt. Nach diesem folgt eine erste Verzweigung mit einem
Operator (3). Konkret bedeutet dies hier, dass aus einem Sequenzfluss mehrere wer-
den. Es geht entweder mit dem Sequenzflusszweig Auftrag abgelehnt (4) oder mit
dem Zweig Auftrag akzeptiert (5) weiter.
Gateways (Operatoren)
Die Operatoren werden von den BPMN-Autoren Gateways genannt. Das grafische
Symbol ist ein auf die Spitze gestelltes Quadrat. Die Abbildung unten enthält mehre-
re. Der erste (3) stellt einen Operator des Typs exklusives Oder dar. Die BPMN-
Autoren nennen ihn Exclusive Gateway. Kurz kann er so beschrieben werden: Es
gibt mehrere weiterführende Pfade nach dem Gateway, nur einer davon kann aktiv
werden.
Der Schrägstrich bei "Akzeptiert" bedeutet in dieser Modellierungsmethode, dass
der durch ihn markierte Pfad die Voreinstellung ist, was hier nur bedeuten kann,
dass er meistens aktiv wird.
Der Pfad, der die Zurückweisung des Auftrags ausdrückt, führt direkt an das Ende
des Geschäftsprozesses, zu einem Gateway (8), das mehrere Zweige zusammenfasst.
Dazu gleich unten mehr.
Gabeln / forking
Im positiven Fall ("Akzeptiert") wird die Aktivität Auftrag ausführen angestoßen. Ist
sie ausgeführt, werden zwei Aktivitäten angestoßen, zum einen die Lieferung, zum
anderen das Versenden der Rechnung (Rechnung senden). Für eine solche Situation
(quasi paralleles Anstoßen zweier Aktivitäten) wird ein UND-Operator verwendet,
der hier Parallel Gateway genannt wird. Es gibt ihn in allen Methoden zur Prozess-
modellierung, hier wird er durch ein Pluszeichen dargestellt. Dieses UND-Gateway
bei (6) ist ein verzweigendes, weiter flussabwärts (7) folgt noch ein verknüpfendes.
Parallel?
Die Parallelität durch das UND-Gateway (6) bedeutet hier, dass beide weiterführen-
den Pfade angestoßen werden und dass die Aktivitäten der beiden Pfade durchlaufen
werden. "Parallel" bedeutet hier also nur gleichzeitiges Anstoßen, nicht echte Paral-
lelität der Abläufe. Die beiden Sequenzflüsse werden dann, da es in nur einem ein-
zigen Sequenzfluss weitergeht, zusammengefasst. Hierfür wird wieder das UND-
Gateway genommen (7), da beide Sequenzflusszweige ja durch ein UND-Gateway
entstanden sind. Dies ist eine übergeordnete Regel der Prozessmodellierung: Für das
Zusammenführen von Sequenzflüssen wird der Operator genommen, nach dem
aufgeteilt wurde.
Am Schluss des Geschäftsprozesses, am rechten Rand der Abbildung, folgt dann
die Zusammenführung der durch ein XODER-Gateway getrennten Flüsse (8). Hier-
für wird wiederum das XODER-Gateway genommen. Die BPMN-Autoren nennen
dieses Gateway exclusive merging. Dies ist hier die Variante "data based", neben der
es noch die Variante "event based" gibt. Der Prozess endet mit einem Schlussereig-
nis (9).
13.2 Einführung durch Beispiele 119
Abbildung 13.2-3: Auftragsabwicklung - Variante 2
Quelle: In Anlehnung an [OMG 2011, S. 269, Figure 10.85] Überset-zung durch den Verfasser.
Soweit der erste "vorzeigbare" Geschäftsprozess als BPD. Es fehlen ihm allerdings
noch einige wichtige Komponenten, z.B. die Angabe der Informationen, mit denen
er umgeht.
13.2.2 Jetzt mit Daten
Informationsobjekte sind alle Geschäftsobjekte wie Rechnungen, Lieferscheine,
usw., jegliche Koordinierungsinformation (Anfragen, Angebot, Liefermitteilungen)
und natürlich die ganz normale Datenbank der Organisastion mit all ihren Datenbe-
ständen. Diese sind von großer Bedeutung für jeden Geschäftsprozess, weshalb jede
Methode zur Modellierung von Geschäftsprozessen vorsehen muss, sie zu erfassen.
In der BPMN können Informationsobjekte einer Aktivität oder einem Sequenz-
fluss zugeordnet werden. Außerdem können sie in einem eigenen Fluss neben dem
Sequenzfluss dargestellt werden. In der folgenden Abbildung sind zwei Informati-
onsobjekte eingebaut. Zuerst der Auftrag, der ins Unternehmen kommt und damit
den Geschäftsprozess ja erst auslöst. Er wird ganz einfach der Aktivität Auftragsein-
gang zugewiesen. Durch die Pfeilspitze wird der Informationsfluss ausgedrückt. Das
zweite Informationsobjekt in diesem Beispiel ist die Rechnung. Sie ist der Aktivität
Rechnung senden zugeordnet.
120 13 Methode BPMN
Abbildung 13.2-4: Auftragsabwicklung - Variante 3
Quelle: In Anlehnung an [OMG 2011, S. 269, Figure 10.85]. Über-setzung durch den Verfasser.
13.2.3 Handelnde - Träger der Aktivitäten
Für eine Basisausstattung einer Methode zur Prozessmodellierung fehlen jetzt nur
noch die im Geschäftsprozess Handelnden. Diese werden zuerst einmal für die ein-
zelnen Aktivitäten bestimmt. Möglich sind hier Menschen oder auch Programme,
mit oder ohne Maschinen27
. Für die Zuordnung der Träger von Aktivitäten haben die
BPMN-Autoren die bekannte Schwimmbahnentechnik gewählt. Bei ihr werden Be-
cken (pools) und Bahnen (lanes) angelegt. Becken erfassen die übergeordneten Trä-
ger (z.B. ganze Unternehmen), Bahnen die untergeordenten (z.B. Abteilungen oder
Personen auf Stellen). Die folgende Abbildung zeigt das erweiterte einführende
Beispiel.
Das obere Becken enthält alle Aktivitäten, die durch das hier betrachtete Unter-
nehmen realisiert werden. Es ist weiter unterteilt in zwei Bahnen, eine für die Abtei-
lung Auftragsbearbeitung, eine für die Abteilung Finanzwesen. Die Aktivitäten sind
in der Bahn der Abteilung, die sie realisiert. Der Sequenzfluss geht dann entspre-
chend zwischen den Bahnen hin und her.
Der Kunde ist eine eigene handelnde Einheit und wird deshalb in der BPMN
durch ein eigenes Becken dargestellt. Zwischen verschiedenen "handelnden Einhei-
ten"28
gibt es - so der Vorschlag der BPMN-Autoren - keine Sequenzflüsse, sondern
nur Nachrichtenflüsse. Deshalb wurde hier das Verschicken der Rechnung zum
Kunden als Nachricht modelliert, ebenso die umgekehrte Information ("Zahlungs-
eingang").
27 Ein Beispiel für eine Aktivität, die evtl. durch ein Programm mit zugehörigen Maschinen erfolgt, ist
eine vollautomatische Lagerentnahme.
28 Das eigene Unternehmen und von diesem ausgehend die Kunden, die Lieferanten, Behörden, usw.
Alle, die mit dem Unternehmen im Rahmen von Geschäftsprozessen zusammenwirken.
13.2 Einführung durch Beispiele 121
Abbildung 13.2-5: Auftragsabwicklung - Variante 4
Quelle: In Anlehnung an [OMG 2011, S. 269, Figure 10.85]. Über-setzung durch den Verfasser.
13.2.4 Ein öffentlicher Geschäftsprozess
Öffentliche Geschäftsprozesse wurden oben schon kurz vorgestellt. Die BPMN-
Autoren verstehen darunter die Vorgänge, die zwischen einem internen Geschäfts-
prozess und einem anderen Prozess stattfinden.
Wie oben schon ausgeführt, wird die Kommunikation mit externen Partnern in
der BPMN nicht als Kontrollfluss, sondern durch Austausch von Nachrichten mo-
delliert. So wie im folgenden Beispiel. Dort ist der Patient als Becken ohne Aktivitä-
ten dargestellt. Dies ist in der BPMN möglich. Die Nachrichtenflüsse zu einem sol-
chen Teilnehmer am Geschäftsprozess enden und starten dann an der Grenzlinie des
Beckens. Ansonsten dürfte das Beispiel selbsterklärend sein.
122 13 Methode BPMN
Abbildung 13.2-6: Kontakt zwischen Arztpraxis und Patient - Version 1
Quelle: [OMG 2011, S. 24, Figure 7.2]; Übersetzung durch den Ver-fasser.
Zusammenarbeit
Eine Zusammenarbeit (collaboration) beschreibt die Interaktionen zwischen zwei
oder mehr Teilnehmern am Prozessgeschehen, die normalerweise durch je ein Be-
cken erfasst werden. Zwischen diesen kann es ja nur Nachrichtenverkehr geben, der
die Becken oder die Objekte im Becken verknüpft.
Liegen öffentliche Prozesse vor, können die Aktivitäten für die Kollaboration als
die Berührungspunkte zwischen den Teilnehmern aufgefasst werden. Die zugehöri-
gen internen Prozesse können viel mehr Innenleben haben, als mit dem öffentlichen
Prozess gezeigt wird. Ein Becken kann auch leer bleiben - wie oben gezeigt - als
"black box".
Die folgende Abbildung zeigt, in Anlehnung an das Beispiel oben, diesen ausge-
stalteten Prozess beim Patienten und den Nachrichtenverkehr zwischen einzelnen
Aktivitäten. Wenn dann - wie hier - zwei oder mehr öffentliche Prozesse miteinan-
der kommunizieren, sprechen die BPMN-Autoren von einem globalen Prozess. Bei
diesem verlaufen die Nachrichtenflüsse zwischen je zwei Aktivitäten - eine vom
einen, eine vom anderen Prozess [OMG 2011, S. 24f].
13.2 Einführung durch Beispiele 123
Abbildung 13.2-7: Geschäftsprozess Anfrageprüfung. Die Instanz für einen der nega-
tiven Fälle.
Damit sind die Grundzüge der Methode beschrieben. Sie erlaubt aber noch sehr viel
mehr Detaillierung in der Prozessmodellierung, mit der sehr viel mehr Aussagekraft
gewonnen werden kann. Diese sollen im Folgenden gezeigt werden.
13.2.5 Aufgabentypen
Die folgende Tabelle zeigt die Ausdifferenzierung des Elements zur Erfassung der
Aufgaben. Neben dem Grundsymbol kann nach der inneren Struktur, dem Grad der
Automatisierung und der Rolle im Nachrichtenaustausch differenziert werden. Au-
ßerdem können Aufgaben, die jedem anderen Prozess zur Verfügung stehen, ge-
kennzeichnet werden (Call Activity).
124 13 Methode BPMN
Grundsymbol
Eine Aufgabe ist eine atomare Aktivität in einem Prozessfluss. Sie wird benutzt, wenn die Tätigkeit nicht weiter detailliert werden kann (soll). Auch: abstrakte Aufgabe
Innere Struktur
Aufgaben, die parallel mehrfach aktiv werden können. Markierung: Mehrfachinstanz (multi instance), parallel oder sequentiell. Dies sind zum Beispiel - in einem entsprechenden Geschäftsprozess - die Auslieferungen von Sendungen.
Aufgaben mit sich wiederholenden Tätigkeiten, markiert mit einer Schleifenmarkierung (loop marker). Zum Beispiel die Abarbeitung des Maileingangs.
Aufgaben, die als Ersatz für andere dienen ("zur Kompensation"), markiert durch eine Kompensationsmarkierung (compensation marker). Zum Beispiel die Stornierung einer Flugbuchung, falls bei dieser Probleme auftraten.
Grad der Automatisierung
Aufgaben des Typs Handarbeit (manual task object). Sie werden von Menschen durchgeführt, ohne Anwendungsprogramm und ohne Business Process Engine. Z.B. entlang einer papiergestütz-ten Anweisung für einen Telefontechniker.
Aufgaben des Typs Nutzeraufgabe (user task object). Sie werden von Menschen mit Hilfe von Anwendungsprogrammen durchgeführt . Die Aufgabenerledigung wird durch einen task list manager ge-steuert.
Aufgaben des Typs Dienst (service task object). Sie werden durch einen WebService oder ein automatisch ablaufendes Anwen-dungsprogramm erledigt.
Aufgaben des Typs Skript (script task object). Sie werden durch eine Business Process Engine ausgeführt.
Aufgaben des Typs Geschäftsregel (business rule task). Sie dienen dazu, Input an eine Business Rules Engine zu liefern und die dort erzielten Ergebnisse zu empfangen.
Nachrichtenbasiert
Aufgaben des Typs Sender (send task object). Sie dienen dem Versenden einer Nachricht an einen externen Prozessteilnehmer.
13.2 Einführung durch Beispiele 125
Aufgaben des Typs Empfänger (receive task object). Sie dienen dazu, eine Nachricht von einem externen Prozessteilnehmer zu empfangen.
Aufgaben, mit denen Prozesse gestartet werden. Wie die Aufgabe Empfänger, aber mit einem Ereignissymbol des Typs Nachricht / Startereignis / empfangend.
Call Activity
Call Activity, die eine globale Aufgabe des Typs Handarbeit aufruft
Abbildung 13.2-8: Aufgaben in der BPMN und ihre grafische Darstellung Quelle: [Staud 2017, Kapitel 6.2].
13.2.6 Subprozesstypen
Ein Subprozess ist eine aus Aktivitäten, Gateways, Ereignissen und Sequenzflüssen
zusammengesetzte Tätigkeitsfolge, die in einem übergeordneten Prozess enthalten
ist. Letzterer wird auch als Elternprozess bezeichnet. Wesentlich ist, dass Subpro-
zesse als Ganzes aufgerufen werden und nicht einzelne ihrer Aktivitäten. Sie sind
also als solche in das übrige Prozessmodell eingebunden.
Dieses Methodenelement gibt es in jeder Methode zur Prozessmodellierung. Die
folgende Abbildung zeigt einige der hierzu möglichen Varianten. Grundsätzlich
können Subprozesse verborgen (Plussymbol) oder entfaltet angegeben werden.
Dann kann, ähnlich wie bei Aufgaben, nach der inneren Struktur unterschieden
werden.
126 13 Methode BPMN
Grundsymbole
Verborgener Subprozess (collapsed sub process)
Entfalteter Subprozess (expanded sub process)
Innere Struktur (mit Beispielen)
Verborgener Subprozess mit Kennzeichen Kompensation.
Verborgener Subprozess mit Kennzeichen parallele Mehrfachinstan-zen.
Verborgener Subprozess mit Kennzeichen sequentielle Mehrfachin-stanzen.
Verborgener Subprozess mit Kennzeichen Schleife.
Verborgener Subprozess mit Kennzeichen Ad Hoc.
Verborgener Subprozess mit mehreren Kennzeichnungen:
Abbildung 13.2-9: Subprozesse in der BPMN und ihre grafische Darstellung Quelle: [Staud 2017, Kapitel 6].
13.2.7 Ereignisse
Die Ereignisse werden von den BPMN-Autoren auf vielfältige Weise unterschieden
und alle diese Unterscheidungen werden auch in der grafischen Darstellung ausge-
drückt.
Der Ausgangspunkt der Differenzierung ist die Unterscheidung von Start-, Zwi-
schen- und Schlussereignissen. Ihre grafische Gestaltung erfolgt mit schwarzen
Linien und ist ansonsten wie folgt:
Startereignisse (A, B, C) werden mit einer einzelnen dünnen Linie gezeichnet
Zwischenereignisse (D, E, F, G) erhalten zwei dünne Linien
Schlussereignisse (H) werden mit einer dicken Linie gezeichnet
Dann wird danach unterschieden, ob der Auslöser des Ereignisses empfangend oder
abgebend ist (D, G). Zusammen mit der Festlegung, dass Startereignisse nur emp-
fangende Auslöser, Schlussereignisse nur abgebende Auslöser und Zwischenereig-
nisse beide haben, ergibt sich die Kopfzeile der folgenden Abbildung.
13.2 Einführung durch Beispiele 127
Das dritte Kriterium erfasst Sondersituationen für Subprozesse. Es geht um Er-
eignisse, die den übergeordneten Prozess / die übergeordnete Aufgabe entweder
unterbrechen oder nicht. Bei den Startereignissen sind dies "Event Sub Process,
interrupting" (B) und "Event Sub Process, Non interrupting" (C). Bei den Zwischen-
ereignissen "Boundary Interrupting" (E) und "Boundary Non-Interrupting" (F).
Die nicht unterbrechenden Varianten werden jeweils mit gestrichelter Linie ge-
kennzeichnet. Damit ergibt sich die folgende Fassung der Kopfzeile der nachfolgen-
den Tabelle.
Die vierte Ausdifferenzierung erfolgt nach den Auslösern der Ereignisse. Hier
gibt es insgesamt die folgenden:
(13) Kein bestimmter Auslöser (none).
(12) Nachricht (message): Dies bedeutet, dass von einem Teilnehmer am Prozess
eine Nachricht erwartet oder versendet wird. Grafisches Symbol: Briefum-
schlag.
(11) Fehler (error): Dieses Symbol gibt an, dass eine benannte Fehlermeldung er-
zeugt wird. Grafisches Symbol: Blitz.
(10) Zeitgeber (timer): Mit diesem Kennzeichen kann zum Ausdruck gebracht wer-
den, dass das Ereignis Zeitaspekte erfasst. Grafisches Symbol: Uhr.
(9) Eskalation (escalation): Damit wird beschrieben, dass sich eine Prozesssituation
zugespitzt hat und besondere Maßnahmen zu ergreifen sind. Grafisches Symbol:
nach oben gerichtete Pfeilspitze
(8) Signal: Gibt an, dass Signale gesendet oder empfangen werden. Grafisches Sym-
bol: Dreieck.
(7) Abbruch (cancel): Durch diese Kennzeichnung entsteht ein Ereignistyp, der den
Geschäftsprozess bzw. den jeweiligen Fluss abbricht. Grafisches Symbol:
schräg gestelltes Kreuz.
(6) Kompensation (compensation): Erhält ein Ereignis das Kennzeichen Kompensa-
tion (compensation) und wird dieses Ereignis an die Grenzlinie einer Aktivität
angefügt, muss es auch einen Sequenzflusspfeil zu einer anderen Aktivität ge-
ben. Diese andere Aktivität ist dann im Krisenfall Ersatz für die Ausgangsakti-
vität (die mit dem Kompensationsereignis). Grafisches Symbol: "Rücklauftas-
te", wie früher bei Kassettenrekordern.
(5) Bedingung (conditional): Für Ereignisse, die durch Bedingungen beschrieben
werden können, z.B. "Lagerbestand ist unter die Nachbestellmarke gefallen".
Grafisches Symbol: beschriebenes Blatt Papier.
(4) Verknüpfung (link): Ein Ereignis mit dem Kennzeichen Verknüpfung (link) zeigt
an, dass zwei Abschnitte eines Prozesses verknüpft werden. Grafisches Symbol:
nach rechts gerichteter Pfeil.
(3) Beenden (terminate): Ein Ereignis mit diesem Kennzeichen beendet den Prozess.
Grafisches Symbol: Gefüllter Punkt.
(2) Mehrfach (multiple): Dies bedeutet, dass dem Ereignis mehrere Auslöser zuge-
wiesen sind. Grafisches Symbol: Fünfeck.
(1) Parallel mehrfach (nur empfangend): Wie "Mehrfach", nur dass alle Auslöser
aktiv werden müssen. Grafisches Symbol: waagrecht stehendes Kreuz.
Alle Kennzeichen sind grafisch so gestaltet, dass eine nicht geschwärzte und eine
schwarz eingefärbte Fassung möglich ist.
128 13 Methode BPMN
Abbildung 13.2-10: Alle Ereignistypen mit ihren Kennzeichen
Quelle: [Staud 2017, Kapitel 9]
In der Abbildung ist auch zu erkennen, dass nicht alle Marker in allen Ereignistypen
vorkommen.
13.2 Einführung durch Beispiele 129
13.2.8 Gateways
Die folgende Tabelle zeigt die grafischen Symbole für die hier möglichen Operato-
ren. Sie werden Gateways genannt, beruhen aber weitgehend auch auf den logischen
Operatoren UND, ODER, EXKLUSIVES ODER.
BPMN-Bezeichnung Logischer Operator Symbol
Exclusive Gateway, datenbasiert (verzweigend und verknüpfend)
XODER
Erlaubt die Erfassung von Entscheidungssituationen "aus dem Prozess heraus". Ein Sequenzfluss wird aktiv / muss ankommen.
Exclusive Gateway, ereignisbasiert (verzweigend)
XODER
Erlaubt die Erfassung von Entscheidungssituationen durch Nachrichteneingang. Ein Sequenzfluss wird aktiv / muss ankommen.
Parallel Gateway (verzweigend und verknüpfend)
UND
Parallel bedeutet, dass die Aufgaben unabhängig voneinander gestartet und abgearbei-tet werden. Alle müssen gestartet werden bzw. ankommen, damit's "weitergeht".
Parallel Event-Based Gateway (verzweigend)
UND
Dient zum Start von Prozessen durch Ereignisse, die mit dem logischen UND verknüpft sind. Alle müssen gestartet werden, damit's "los geht".
Inclusive Gateway (verzweigend und verknüpfend)
ODER
Dient zur Verzweigung und Verknüpfung gemäß dem logischen ODER ("beliebige Teilmenge")
Complex Gateway (verzweigend und verknüpfend)
---
Geht nicht auf logische Operatoren zurück. Mit ihm sollen Situationen beherrschbar werden, die mit den anderen Gateways nicht bewältigt werden können ("... to model complex synchronisation behavior" [OMG 2011, S. 295]).
Abbildung 13.2-11: Gateways der BPMN - Kurzüberblick Quelle: [Staud 2017, Kapitel 11].
Zusammenfassung
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. Mit einem großen Vorrat an
Theorieelementen erlaubt sie eine sehr detaillierte Modellierung. Sie soll nicht nur
die Prozessmodellierung erlauben, sondern helfen, Prozessmodelle zu erstellen, die
unmittelbar einer Software zur Prozessausführung ("Engine") übergeben werden
können.
14 Vertikale Dimension
14.1 Mehrere Aggregationsniveaus
Es wurde schon mehrfach angeführt, Prozessmodellierung findet auf verschiedenen
Ebenen statt. Folgende Ebenen sind sinnvoll: "Ganz oben" die Übersichtsdarstellun-
gen, darunter auf einem mittleren Level Grobmodellierungen (mit der gesamte Pro-
zesslandschaft oder Teilen davon) mit hoch aggregierten Einzelaktivitäten, darunter
die Standardprozessmodellierung, ganz unten, nahe „an der Programmierung“ eine
systemnahe Modellierung (vgl. [Staud 2010, Kapitel 14 und 15]).
Insbesondere in der Unternehmensmodellierung ist es üblich, Übersichtsnotatio-
nen zu erstellen. Ganz oben finden sich dann oft Wertschöpfungsketten, bei der ein
Element eine ganze Abteilung oder einen ganzen Bereich umfasst. Jedes Element
einer Wertschöpfungskette repräsentiert damit inhaltlich zusammengehörige Ge-
schäftsprozesse. Die Elemente sind linear angeordnet (auch mit Verzweigungen)
und stellen auf diese Weise die repräsentierten Bereiche, wenn auch auf sehr einfa-
che Weise, in Beziehung. Die folgende Abbildung zeigt ein Beispiel. Jedes Element
wird durch ein Symbol repräsentiert (Chevronsymbol), die Pfeile drücken die Ver-
knüpfung mit vor- und nachgeordneten Bereichen aus.
Abbildung 14.1-1: Wertschöpfungskettendiagramm mit Chevron-Symbolen.
Wesentlich weniger aggregiert ist dagegen eine Grobmodellierung von Geschäfts-
prozessen. Diese beschreibt den Prozess zwar noch integriert, fasst aber ganze Pro-
zessabschnitte zusammen. Insgesamt entsteht so eine eher oberflächliche Prozessbe-
schreibung. Solche Modelle sind Bestandteil der Übersichtsnotationen, wie sie zum
Beispiel in der Unternehmensmodellierung nötig sind. Beispiele dafür sind die frü-
her genutzten Szenarien in der SAP-Unternehmensmodellierung
Ausgangspunkt der Modellierungsbemühungen ist oftmals eine Standardpro-
zessmodellierung, z.B. im Rahmen einer Istmodellierung. Bei ihr sollte eine ge-
schlossene Handlung eines Prozessteilnehmers in ein Basistheorieelement (eine
Tätigkeit: Aufgabe/Funktion) gepackt werden und die Geschäftsobjekte sollten als
Ganzes erhalten bleiben. Selbstverständlich lässt auch solch eine Definition noch
Raum für unterschiedliche Aggregationsniveaus.
Mit System ist hier IT-System gemeint. Systemnahe Prozessmodellierung meint
also eine Prozessmodellierung, die direkt in das Anforderungsmanagement
(Requirements Engineering) der Softwareentwicklung einfließt. Diese ist notwendig,
so gut wie jeder Geschäftsprozess wird durch IT unterstützt und sie wird durch den
Trend zur automatisierten Abwicklung von Geschäftsprozessen noch wichtiger.
Übersichtsnotationen
Grobmodellierung von
Geschäftsprozessen
Standardprozessmodellierung
Systemnahe
Prozessmodellierung
132 14 Vertikale Dimension
Systemnahe Prozessmodellierung muss wesentlich detaillierter sein als eine Stan-
dardprozessmodellierung. Hier müssen die einzelnen „Handlungen“ so zerlegt wer-
den, dass sie problemlos in Programmierkonstrukte abgebildet werden können.
Genauso müssen die Geschäftsobjekte, falls sie dann Informationsobjekte sind, in
ihre programmtechnischen Bestandteile zerlegt werden. Dies verdeutlicht, dass die
Art der verarbeiteten Information in den unteren zwei Ebenen sehr unterschiedlich
ist. Während in der Standardprozessmodellierung Geschäftsobjekte (also z.B. Rech-
nungen, Bestellungen, Lieferscheine, usw.) betrachtet werden, was ja auch dem
Prozessdenken entspricht, geht es in der programmnahen Prozessmodellierung um
Attribute, bzw. Variablen, usw., eben um die Information, in die das jeweilige Ge-
schäftsobjekt für die Zwecke der Speicherung und Programmierung zerlegt werden
musste. Die Semantik zu den Geschäftsobjekten ist da dann im jeweiligen Pro-
gramm hinterlegt.
Damit liegt dann eine vertikale Dimension in den Prozessmodellen vor (vgl. die
folgende Abbildung). Erst die Betrachtung dieser vertikalen Dimension erlaubt ein
umfassendes Verständnis des Prozessgeschehens und eine wirklich umfassende
Prozessoptimierung.
Abbildung 14.1-2: Vertikale Dimension der Prozessmodellierung - Mögliche Ebenen.
Sie wird meist so eingerichtet, dass ein Element der oberen Ebene in genau abge-
grenzte mehrere der unteren Ebene zerfällt. Hier also:
Zu einem Element der Wertschöpfungskette (z.B. Vertrieb) gehören bestimmte
(genau abgegrenzte) der Zwischenebene. Zum Beispiel Szenarien (z.B. Teile
des Vertriebs).
Vertikale Dimension
14.2 Prozess- vs. Funktionsmodellierung 133
Zu jedem Element der Zwischenebene gehören ganz bestimmte Geschäftspro-
zesse der Standardprozessmodellierung (einzelne Geschäftsprozesse des Ver-
triebs).
Zu jedem Geschäftsprozess der Ebene der Standardprozessmodellierung gehö-
ren Elemente der programmnahen Prozessmodellierung. Auf dieser Ebene wird
der Prozess als solcher detailliert beschrieben, außerdem wird in den Funktio-
nen weiter spezifiziert.
Die programmnahe Prozessmodellierung gibt Hinweise auf die konkreten Program-
me. Sie könnte - beim heutigen Stand der Technik - den Prozess mit Hilfe von Busi-
ness Process Diagramms beschreiben und die Funktionalitäten durch UML-
Sequenzen.
14.2 Prozess- vs. Funktionsmodellierung
Hier noch ein Hinweis auf eine kritische Stelle bei der Erfassung oder Modellierung
von Geschäftsprozessen: Die Unterscheidung von Prozess und Funktion.
Dieser Aspekt der vertikalen Dimension verdient wegen seiner Bedeutung her-
vorgehoben zu werden. In der Standardprozessmodellierung werden normalerweise
bestimmte Tätigkeiten in elementare Einheiten zusammengefasst (Kalkulation er-
stellen, Kunde zusagen, Ware versenden, …). Einige dieser zusammengefassten
Tätigkeiten weisen aber eine tiefere innere Struktur auf, die ebenfalls modelliert
werden könnte, die aber nicht auf der Prozessebene angesiedelt ist, sondern auf einer
detaillierteren Ebene. Durch diese wird die Funktion als solche erläutert. Dies wird
Funktionsmodellierung genannt.
Betrachten wir als Beispiel die textlichen Prozessbeschreibungen in [Staud 2017,
Abschnitt 14.7]. Im Geschäftsprozesses Auftragsstart ist zu sehen, dass die ganz
"normale" Prozessbeschreibung plötzlich detailliert wird. Sie beschreibt eine Funk-
tion, die Art und Weise, wie die Stundenvorgaben für den Projektleiter berechnet
werden [Abschnitt 14.7.2]. Dies muss man erkennen, wenn man einen solchen Pro-
zess modelliert. Sonst entsteht eine Prozessmodellierung, die auf sehr unterschiedli-
che Ebenen stattfindet, was nur bei gezieltem Vorgehen sinnvoll ist. Meist und auch
hier ist es sinnvoll, diesen Teil des Prozesses in eine Funktion zu packen.
Dieses Beispiel ist wohl eindeutig. Dass es nicht immer so klar ist, Prozess und
Funktion zu unterscheiden, zeigt die Aufgabe "Kostenstruktur eintragen" [ebenda].
Hier ist beides denkbar, weil die Funktion recht einfach strukturiert ist. Sie könnte
also in die Prozessmodellierung einfließen. Die Empfehlung ist: Will man detailliert
modellieren, z.B. im Rahmen einer Standardprozessmodellierung, wird man diese
Stelle im Prozess ausweisen (vgl. [Staud 2014, Abschnitt 8.2]). Geht es eher um
einen Überblick über den Prozess, wird man diese Tätigkeiten in eine Funktion
packen.
14.3 Prozesslandschaft und -landkarte
Stellt man mehrere ausgewählte Geschäftsprozesse eines Unternehmens, einer Ab-
teilung oder eines Bereichs zusammen, spricht man von Prozesslandschaft oder
Prozesslandkarte. Dies kann auch mit unterschiedlichen Ebenen, von
Wertschöpfungketten bis zu Standardprozessmodellen realisiert werden. Zahlreiche
Beispiele mit Prozesslandkarten finden sich in [Alpar, Alt, Bensberg u.a. 2014].
134 14 Vertikale Dimension
In Prozesslandkarten kann zwischen unterschiedlichen Prozesstypen unterschie-
den werden. So unterscheiden Alpar/Alt/Bensberg zwischen Führungsprozessen,
Leistungsprozessen und Infrastrukturprozessen [Alpar, Alt, Bensberg u.a. 2014, S.
141] und Gadatsch unterscheidet Steuerungsprozesse, Kernprozesse sowie Unter-
stützungsprozesse [Gadatsch 215, Pos. 354].
Zusammenfassung
Prozessesse und Prozessmodelle werden auf unterschiedlichen Detaillierungsniveaus
erstellt. Da kann eine globale Übersichtsnotation in Form von Wertschöpfungsketten
vorliegen, eine darunter liegende (detailliertere) als Grobmodellierung, darunter die
Standardprozessmodellierung und dieser (nach "unten" folgend, also detaillierter)
eine systemnahe Prozessmodellierung. Es werden die Prozesse also auf unterschied-
lichen Aggregationsniveaus modelliert. So kommt es zu einer vertikalen Dimension
im Prozessmodell des Unternehmens. Diese wird dann noch aussagekräftiger, wenn
die Zusammenhänge zwischen den Ebenen auch erfasst werden.
15 Referenzprozessmodelle
15.1 Einführung
Nach der Lektüre der ersten Kapitel liegt der Gedanke eigentlich nahe: Wenn Pro-
zesse in der Theorie so geklärt und strukturiert sind und nachdem schon sehr viele
praktische Geschäftsprozesse erhoben wurden, sollte es für alle Bereiche, in denen
dies möglich ist, vorgedachte Geschäftsprozesse geben, die man einfach kaufen
kann. Als Modell oder als eine in prozessorientierter Software realisierte Lösung
(vgl. die Abbildung unten). Dies ist inzwischen auf die eine oder andere Weise tat-
sächlich Realität:
Durch Ineinsichtnahme eines Referenzmodells mit Schwerpunkt auf Prozessar-
chitektur. Zum Beispiel bei einem Neuentwurf der Prozesslandschaft oder bei
einem radikalen Redesign. Dann ist die Grobarchitektur schon mal klar, die
zentralen Geschäftsprozesse sind angeführt (meist am Beispiel Industrie) und
man kann (z.B. bei einem Top Down-Vorgehen (vgl. xxx) fundiert an die Arbeit
gehen.
Durch Ineinsichtnahme eines Prozessmodells, in dem konkrete vorgedachte
Prozesse enthalten sind. Dies erfolgt sinnvollerweise meist auch gleich mit Ar-
chitekturfestlegungen.
Durch Kauf oder Miete ("Cloud") von Integrierter Prozessorientierter Software.
Dann sind die Geschäftsprozesse in der Software hinterlegt. Denn es gilt: Pro-
zessorientierte Software beruht immer auf vorgedachten Prozessen und Pro-
zessmodellen.
Vorgedachte Geschäftsprozesse
Jede prozessorientierte Software realisiert Geschäftsprozesse. Für diese muss eine
Modellvorstellung vorgelegen haben, sonst hätte sie nicht in Software "gegossen"
werden können. Dies kann eine individuelle Lösung sein, dann sind die Geschäfts-
prozesse vom Softwarehaus gleich auf ein bestimmtes Unternehmen zugeschnitten
worden ("Branchensoftware") oder eine "für viele" (Standardsoftware). Dann sind
die Geschäftsprozesse vom (Standard-)Softwarehaus so vorgedacht worden, dass sie
auf viele Unternehmen passen.
Dies sind in der Realität die wichtigsten "Referenzmodelle", da sie reale Pro-
zessmodelle darstellen, die zum Einsatz kommen. Ihre Basis ist a) die Erfassung
oder Festlegung der fachlichen Prozesse und b) deren Umsetzung in Software, im
Rahmen eines entsprechenden Anforderungsmanagements. Es sind immer optimier-
te Prozesse (aus der Sicht der Ersteller) und doch aber so etwas wie Produkte "von
der Stange" ohne individuellen Zuschnitt. Sie werden eher bei Supportprozessen
akzeptiert, nicht bei Kernprozessen.
Vorgedachte Geschäftsprozesse sind möglich für Geschäftsprozesse und Archi-
tekturen mit wohlstrukturierten Problemen (vgl. xxx). Dies können auch Teile von
Geschäftsprozessen sein, die unstrukturierte und strukturierte Probleme mischen.
Nehmen wir als Beispiel eine Strategieentwicklung (z.B. für eine Marketingkam-
15 Referenzprozessmodelle 136
pagne). Wohlstrukturiert sind Aufgaben wie Projekteinrichtung, Projektstart, Mittel-
bereitstellung, Meetings durchführen, usw. Die eigentlichen Aufgaben (Strategiefin-
dung, Schritte klären, usw.) sind aber unstrukturiert.
Exkurs: Integrierte prozessorientierte Standardsoftware
Es ist in diesem Text zwangsläufig sehr oft die Rede von diesem Softwaretyp. Desshalb hier eine kurze Abklärung.
Der in Organisationen aller Art meist genutzte Softwaretyp ist der in der Überschrift angeführte. Er wird
meist ERP-Software genannt, auch die Bezeichnungen Unternehmenssoftware und Betriebswirtschaftli-che Standardsoftware sind gebräuchlich.
Zerlegen wir die Bezeichnung:
Standardsoftware: Gegenstück zu Individualsoftware. Software für möglichst viele Nutzer in möglichst vielen Organisationen ("von der Stange").
Prozessorientierte Software: Eine Software, die zur Abwicklung von Geschäftsprozessen dient. Entweder indem sie die beteiligten Menschen unterstützt ("von Maske zu Maske führt") oder indem sie den Ge-
schäftsprozess gleich vollautomatisch abwickelt. Wie auch immer, sie beruht auf jeden Fall auf vorge-
dachten Geschäftsprozessen und ihren Modellen. Ein anderer bedeutender und nicht-prozessorientierter Softwaretyp ist Standardsoftware, die nicht pro-
zessorientiert ist. Sie wird auch funktionsorientierte Software genannt, weil sie einzelne Aufgaben (Funk-
tionen) abdeckt. Wichtiges Beispiel hier sind die Office-Pakete. Integriert meint hier, dass die Software vollkommen in die IT integriert ist. Dass es also zwischen ihr und
der übrigen Software des Unternehmens keine schwer zu überwindenden Schnittstellen gibt29.
Die folgende Abbildung visualisiert diese Eigenschaften und zeigt auch noch weitere mögliche Software-ausprägungen.
Abbildung 15.1-1: Softwaretypen
Vgl. Kapitel 3 in [Staud 2006) für eine detaillierte Beschreibung dieses Software-
typs.
29 Ursprünglich war damit gemeint, dass die einzelnen Komponenten der Software (Personalwesen,
Vertrieb, Lager, Beschaffung usw. integriert (keine Insellösungen) waren. Dies kann man bei moder-
nen Softwareprodukten aber voraussetzen.
15 Referenzprozessmodelle 137
15.2 Wertkette von Porter
Porter schlug eine Wahrnehmung der Geschäftsprozesse in einem typischen Indust-
rieunternehmen vor, die durchschlagenden Erfolg hatte. Sie baut auf seinen Überle-
gungen zur Wertschöpfung und zur Wertschöpfungskette auf.
Die Wertschöpfungskette besteht aus neun Firmenaktivitäten, die zur Herstellung
und Wertsteigerung eines Produkts beitragen (einschließlich der Realisierung einer
Gewinnspanne). Grob sind die Firmenaktivitäten unterteilt in ausführende Aktivitä-
ten (auch primäre genannt), die direkt mit Herstellung, Vertrieb, usw. verbunden
sind (z.B. Beschaffung, Vertrieb, Produktion) und sekundäre, mit denen die ausfüh-
renden unterstützt werden (Finanzwesen, Controlling, Personalwesen, usw.). Porter
schlägt zwar nicht eine breite Palette von Geschäftsprozessen vor, aber er identifi-
ziert zentrale Prozesse von besonderer Bedeutung und hat eine der Grundlagen für
das Business Process Management gelegt.
In Abbildung 2 ist die Wertschöpfungskette mit primären und sekundären Aktivi-
täten dargestellt. Ausgangspunkt ist der vom Kunden erhaltene und bezahlte Wert
einer Leistung; alle Aktivitäten sind auf die Erzeugung dieses Werts/der Leistung
ausgerichtet. Als Ergebnis der Erzeugung von Wert, abzüglich der entstandenen
Kosten, liegt der Gewinn des Unternehmens vor.
Abbildung 15.2-1: Wertkette eines Unternehmens (vgl. [Porter 1999, S. 66])
Die Eingangslogistik umfasst die Beschaffung und Bereitstellung von Materialien
und Betriebsmitteln. Relevante Teilschritte sind Bestellabwicklung, Wareneingang,
Lagerung, Bereitstellung und Transport. Diese Aktivität hat einen wesentlichen
Einfluss auf den wirtschaftlichen Erfolg eines Unternehmens. Z.B. hat eine optimale
Bestellmengenplanung einen wesentlichen Einfluss auf die Kapitalbindung in Roh-,
Hilfs- und Betriebsstoffe und auf die Umlaufbestände in der Fertigung. Hauptaufga-
be der Eingangslogistik ist die flexible und pünktliche Versorgung der Produktion
und die Sicherstellung der Qualität der Bezugsmaterialien.
Mit Operationen sind Produktion, Fertigungs- bzw. Produktionswirtschaft ge-
meint. Aufgaben sind hier z.B. die mechanische Bearbeitung, die Montage, die che-
misch-physikalische Umwandlung von Stoffen oder der Betrieb komplexer Anlagen
(z. B. Telekommunikationsnetzen oder Verkehrssystemen), die Instandhaltung und
Qualitätsprüfung. Diese Teilschritte stellen materielle (Sachgüter) oder immaterielle
(Dienstleistungen) Ergebnisse dar.
15 Referenzprozessmodelle 138
Ein zentraler Aspekt im Rahmen der Wertschöpfung sind Marketing und Ver-
trieb. Dazu zählt z.B. die Erschließung geeigneter Vertriebswege, um Zugang zum
Endkunden im Markt zu schaffen. Daneben ist die Kommunikation des Produktnut-
zens relevant (z. B. durch Werbung), um die erforderliche Zahlungsbereitschaft bei
der Kundengruppe zu wecken.
Die Ausgangslogistik (Distribution) hat zum Ziel, die zeitliche und räumliche
Verfügbarkeit der Erzeugnisse und Leistungen für den Kunden sicherzustellen. Teil-
prozesse sind der Unterhalt/Betrieb von zentralen/dezentralen Distributionslägern,
die Kommissionierung, der Transport und die Informationsverarbeitung. Die Aus-
gangslogistik ist relevant, da Produkte/Dienstleitungen (als Ergebnis der Operations)
durch die Verfügbarkeit (Informations-, Orts- und Zeitnutzen) zur Bedürfnisbefrie-
digung beim Kunden beitragen.
Der Kundendienst trägt ebenso zur Wertsteigerung und -erhaltung des primären
Produktes bei. Der Kundendienst kann dabei entweder kostenlos zusätzlich erbracht
oder gegen Entgelt angeboten werden. Für Softwareanbieter stellt die Installation,
Einführung, Schulung und Pflege ihrer Produkte eine wichtige Erlösquelle dar.
Die Beschaffung (Einkauf) ist darauf ausgerichtet, eine leistungsfähige Lieferan-
tenbasis zu entwickeln, die die Wettbewerbsstrategie des Unternehmens unterstützt.
Zu Teilschritten gehören die Beschaffungsmarktforschung, die Lieferantenauswahl,
die Gestaltung der Lieferantenbeziehung, die gezielte Entwicklung der Leistungsfä-
higkeit interessanter potenzieller Beschaffungsquellen, die Pflege der Lieferantenbe-
ziehung im Hinblick auf die gemeinsam verfolgten Ziele und die Durchsetzung
günstiger Konditionen zu Lasten der Wertschöpfung vorgelagerter Stufen. Die Ge-
staltungsmöglichkeiten der Beschaffung sind je nach Fremdbezugsanteil und Stel-
lung des Unternehmens im Beschaffungsmarkt (Einkaufsmacht) unterschiedlich.
Insbesondere der Fremdbezug (Outsourcing) von Sachgütern und Dienstleistungen
und die Verlagerung von Leistungsprozessen (Offshoring) in kostengünstige Wachs-
tumsregionen hat die Relevanz der Beschaffung erhöht.
Die Technologieentwicklung ist auf die Beherrschung und Verbesserung techni-
scher Prozesse gerichtet; sie betrifft daher alle primären und sekundären Aktivitäten.
Die Beherrschung wettbewerbsrelevanter Technologien ist von großer Bedeutung
für den Unternehmenserfolg, da Technologien in primären Aktivitätsbereichen wie
Produktion und Logistik zu Kosteneinsparungen führen.
Die Personalwirtschaft ist für die Qualität, Verfügbarkeit und Motivation von
Mitarbeitern zuständig.
Die Unternehmensinfrastruktur stellt den Input für alle anderen Aktivitäten be-
reit. Wesentliche Bereiche sind z. B. das Rechnungswesen, das Planungs- und Ma-
nagementsystem und Systeme der Informations- und Kommunikationstechnik.
Komplexer strukturierte Großunternehmen haben im Bereich der Unternehmensinf-
rastruktur oftmals Redundanzen, z. B. wenn Rechtsabteilungen oder IT-
Servicebereiche bei mehreren Tochtergesellschaften parallel vorhanden sind. Solche
allgemeinen Bereiche werden deshalb oft für eine ganze Unternehmensgruppe zent-
ral angeboten, an Dienstleister ausgelagert (Outsourcing) und dabei auch an kosten-
günstige Standorte verlagert (z. B. Callcenter). In diesem Zusammenhang spricht
man auch von Shared Services und Business Process Outsourcing.
Die primären und sekundären Aktivitäten unterteilen sich in die folgenden drei
Kategorien:
15 Referenzprozessmodelle 139
Direkte Aktivitäten sind unmittelbar auf die Leistungserbringung und die Wert-
schöpfung gerichtet. Sie sind an der Wertbildung für Kunden beteiligt; z.B.
Montage, Werbung.
Indirekte Aktivitäten dienen dagegen nur mittelbar der Wertschöpfung; z. B.
Instandhaltung, Terminplanung, Anlagenbetrieb, verwaltende Aktivitäten. Indi-
rekte Aktivitäten ermöglichen die direkten Aktivitäten durch vorbereitende,
ordnende oder stabilisierende Maßnahmen.
Die Qualitätssicherung ist eine weitere eigenständige Aktivitätskategorie; sie
unterstützt die Planung, Sicherung und Prüfung der Qualität in den übrigen Ak-
tivitäten. Die Kosten für diese Qualitätssicherung werden in der Regel durch
Einsparungen in den verbesserten Prozessen (z.B. verringerter Ausschuss, stär-
kere Anlagennutzung) kompensiert.
Zusammenfassung
Porters Wertkette beinhaltet primäre und sekundäre Aktivitäten. Primäre Aktivitäten
zielen direkt auf die Erstellung der Leistung und den Leistungsaustausch mit Kun-
den ab (Eingangslogistik, Operationen, Marketing/Vertrieb, Ausgangslogistik, Kun-
dendienst). Sekundäre Aktivitäten beschaffen/erzeugen die erforderlichen Inputs für
primäre Aktivitäten (Unternehmensinfrastruktur, Personalwirtschaft, Technologie-
entwicklung, Beschaffung). Alle Aktivitäten sind auf die Erzeugung eines Werts für
Kunden (einer Leistung) ausgerichtet. Als Ergebnis der Erzeugung von Wert, abzüg-
lich der entstandenen Kosten, liegt der Gewinn des Unternehmens vor. Neben der
generischen Betrachtung können Wertketten auch branchen- oder unternehmensspe-
zifisch ausgeprägt werden. Unterschiedliche Wertketten einer Branche können in
ihrem Gesamtzusammenhang als Wertsystem einer Branche dargestellt werden.
15.3 Handels-H von Becker/Meise
Eine umfassende Analyse der Informationssysteme und damit der Prozesslandschaft
im Handel stellen Becker/Meise vor. Sie verwenden den Begriff Ordnungsrahmen
für die Modellvorstellung. Dabei geht es um übergeordnete Zusammenhänge, um
vorkommende Geschäftsprozesse und ihr Zusammenwirken, nicht um einzelne kon-
krete Prozesse (vgl. [Becker und Meise 2012, Kapitel 4], [Becker und Meise 2012,
S. 114ff]). Eine umfangreichere Darstellung auch mit einer grafischen Darstellung
des Ordnungsrahmens findet sich in [Becker und Schütte 2004].
Der Ordnungsrahmen ist wie folgt aufgebaut:
Als grobe Bereiche werden Beschaffung, Produktion und Lager unterschieden.
Beschaffung (Aufgaben mit Lieferantenbezug) wird in Einkauf, Disposition,
Wareneingang, Rechnungsprüfung und Kreditorenbuchhaltung unterschieden
(in zeitlicher Abfolge)
Produktion (Aufgaben mit Kundenbezug) wird in Marketing, Verkauf, Waren-
ausgang, Fakturierung und Debitorenbuchhaltung unterschieden (in zeitlicher
Abfolge)
Lager: Die Überbrückungsfunktion wird auch grafisch ausgedrückt
Unteres Rechteck: betriebswirtschaftlich-administrative Funktionen
Leitungs- und Führungsfunktionen
Neben diesem Ordnungsrahmen für das Lagergeschäft gibt es noch Varianten für
das Strecken- und Zentralregulierungsgeschäft (vgl. [Becker und Meise 2012, S.
114]).
15 Referenzprozessmodelle 140
So wie jetzt beschrieben, stellt dieser Ordnungsrahmen eine Zusammenstellung
der Hauptaufgaben und ihren Zusammenhang dar. Also: Architektur eines Informa-
tionssystems und seiner Prozesse.
In einer zweiten Dimension sind dann die Ebenen Funktionen, Daten und Prozes-
se angedeutet. Dies drückt aus, dass für die Realisierung der jeweiligen Geschäfts-
prozesse Funktionen, Daten und Prozesse notwendig sind, bzw. dass diese drei Sich-
ten eingenommen werden sollten.
Zusammenfassung
Eine umfassende Analyse der Informationssysteme und damit der Prozesslandschaft
im Handel stellen Becker/Meise vor. Dabei geht es um übergeordnete Zusammen-
hänge, um vorkommende Geschäftsprozesse und ihr Zusammenwirken, nicht um
einzelne konkrete Prozesse.
15.4 Nach Schmelzer/Sesselmann
Das Referenzprozessmodell von Schmelzer/Sesselmann stellt, wiederum am Bei-
spiel von Industrieunternehmen, überblicksartig die zu realisierenden Prozesse zu-
sammen (vgl. [Schmelzer und Sesselmann 2013, S. 249]). Es unterscheidet primäre
und sekundäre Prozesse. Siehe auch die folgende Abbildung. Betont wird die Kun-
denorientierung: Kundenanforderungen sind der Ausgangspunkt, die Leistungser-
bringung gegenüber dem Kunden mit dem erhofften Ziel der Kundenzufriedenheit
ist der Endpunkt.
Bei den sekundären Prozessen werden die Unterstützungsprozesse (Supportpro-
zesse) und die Strategieplanungsprozesse unterschieden.
Abbildung 15.4-1: Referenzprozessmodell von Schmelzer/Sesselmann (vgl. [Schmel-
zer und Sesselmann 2008, S. 231])
Innerhalb des Innovationsprozesses erfolgt die Gewinnung, Konkretisierung und
Selektion von Ideen. Diese Ideen beziehen sich entweder auf neue Produk-
te/Prozesse, oder auf die Verbesserung bestehender Produkte/Prozesse. Im Rahmen
dieses Prozesses wird die Spanne von der Ideenfindung bis zur Machbarkeitsprüfung
technischer Innovationsideen abgedeckt. Teilprozesse sind: Technologien pla-
nen/bereitstellen, Ideen gewinnen/vorselektieren, Machbarkeit prüfen, Ideen aus-
15 Referenzprozessmodelle 141
wählen und Vorentwicklung durchführen (vgl. [Schmelzer und Sesselmann 2008, S.
200ff]).
Im Produktplanungsprozess erfolgt die Erarbeitung von Produktkonzepten. Aus-
gangspunkt sind hierbei die Ergebnisse des Innovationsprozesses. Der Prozess deckt
den Bereich der Produktidee bis zum Pflichtenheft ab. Relevante Teilprozesse sind:
Markt/Wettbewerber beobachten, Produktstrategie/-programm planen, Produktpro-
fil/-konzept planen und Produkte steuern [ebenda, S. 203ff].
Der Produktentwicklungsprozess beinhaltet die Erarbeitung von Entwicklungs-
projekten für Produkte, Produktversionen und Produktänderungen. Startpunkt des
Prozesses ist das Pflichtenheft und Endpunkt die Lieferfreigabe. Teilprozesse sind:
System entwerfen, Hardwarekomponenten entwickeln, Softwarekomponenten ent-
wickeln, System intergieren/testen und System min Fertigung überleiten [ebenda, S.
205ff].
Der Vertriebsprozess hat zum Ziel, eine langfristige Kundebindung aufzubauen.
Dafür erfolgt eine Kundenkommunikation, die die Feststellung der Kundenbedürf-
nisse, die Vermittlung des Leistungsangebots und die Abfrage der Kundenzufrie-
denheit beinhaltet. Teilprozesse sind: Kunden betreuen, Kundenbedürfnisse analy-
sieren, Angebote erstellen, Aufträge abschließen und Vertrieb unterstützen (als
zentraler Vertriebssupport) [ebenda, S. 209ff].
Im Rahmen des Auftragsabwicklungsprozesses wird der Auftragseingang bis zur
bezahlten Rechnung abgedeckt. Teilprozesse sind. Auftrag erfassen/einplanen, Ma-
terial abrufen/bereitstellen, Produkt/System fertigen, Produkt/System liefern, Auf-
trag fakturieren. Die einzelnen Teilschritte innerhalb des Auftragsabwicklungspro-
zesses sind aus Sicht des Kunden nicht von hoher Relevanz, da dieser die bestellten
Produkte pünktlich und in der korrekten Ausführung/Qualität/Menge erhalten möch-
te [ebenda, S. 211].
Der Serviceprozess beinhaltet die Betreuung des Kunden nach dem Kauf; diese
Betreuung beinhaltet die Hilfe bei Schwierigkeiten und die Behebung von Produkt-
mängeln, um den Produkteinsatz zu gewährleisten. Der Serviceprozess beeinflusst
die Kundenzufriedenheit, Kundenloyalität und Kundenbindung. Informationen, die
innerhalb dieses Prozesses gewonnen werden, dienen der Verbesserung von Produk-
ten und Prozessen. Teilprozesse sind: Kundenfragen vorklären, Problemlösung ver-
anlassen, Problem lösen, Produkte/Systeme installieren/warten und Service unter-
stützen [ebenda, S. 215f].
Die aufgeführten primären Prozesse werden zusätzlich anhand einheitlicher Krite-
rien beschrieben. In der folgenden Tabelle ist exemplarisch die Beschreibung des
Innovationsprozesses dargestellt.
Prozessname: Innovationsprozess von: Kundenproblem bis: ausgewählte Produkt-/Prozessideen
Prozessverantwortlicher: Name
Objekt: Produkt-/Prozessidee Prozessinputs: Forschungsergebnisse, Patente, Kundenproble-me, Konkurrenzprodukte
Lieferanten: Forschungsinstitute, Literatur, Kongresse, Mitar-beiter, Kunden, Wettbewerber, Zulieferer
Prozessergebnis: Technologien, Prototypen, ausgewählte Produkt-/Prozessideen, Durchführbarkeitsstudien, Basislö-sungen, (Plattformen, Systemkonzepte), Patente
Kunden: Strategieplanungsprozess, Produktplanungspro-zess, Produktentwicklungsprozess, Fertigungs-prozess
Tabelle: Beschreibung des Innovationsprozesses (vgl. [Schmelzer und Sesselmann 2008, S. 201])
15 Referenzprozessmodelle 142
Neben der Beschreibung der Prozesse sind auch die dazugehörigen Teilprozesse
detailliert beschrieben. Vgl. dazu die folgende Tabelle.
Teilpro-
zesse
Technologien
planen/ be-
reitstellen
Ideen gewin-
nen/ vorselek-
tieren
Machbarkeit
prüfen
Ideen auswäh-
len
Vorentwick-
lungen durch-
führen.
Objekte Technologie Produkt-
/Prozessidee
Produkt-
/Prozessidee
/Prozessidee Vorentwick-
lungsprojekte
Inputs Forschungsbe-
richte, Patent-
recherchen
Technologien,
Kunden-
probleme,
Konkurrenz-
produkte
vorselektierte
Produkte-
/Prozessideen
Prototypen,
Labormuster,
Machbarkeits-
studien
ausgewählte
Produkt- und
Prozessideen
Ergeb-
nisse
Technologie-
strategie,
Technologie-
projekte
vorselektierte
Produkte-
/Prozessideen
Prototypen,
Labormuster,
Machbarkeits-
studien, Paten-
te
ausgewählte
Produkt- und
Prozessideen
Plattformen,
Architekturen,
kritische Kom-
ponenten
Methode Szenarien, S-
Kurve, Techno-
logie-
Roadmap,
Technologie-
Portfolio
Kreativitäts-
techniken
Rapid
Prototyping
F&E-Portfolio Projektmana-
gement
Tabelle: Beschreibung der Teilprozesse des Innovationsprozesses (vgl. [Schmelzer und Sesselmann 2008, S. 202])
Sekundäre Prozesse (Supportprozesse)
Im Rahmen des Strategieplanungsprozesses erfolgen die Planung bzw. regelmäßige
Überarbeitung der Geschäfts- und Prozessstrategie. Folgende Teilprozesse sind
hierbei relevant: Geschäftssituation aufzeigen/analysieren, Trends aufzeigen, Ge-
schäfts-/Prozesssituation bewerten, Geschäfts-/Prozessstrategie festlegen, Ge-
schäftsplan/Prozessmodell erstellen (vgl. [Schmelzer und Sesselmann 2008, S.
219]).
Der Personalmanagementprozess soll personelle Ressourcen planen und steuern,
um somit qualifizierte/Motivierte Mitarbeiter zu gewinnen und an das Unternehmen
zu binden. Folgende Teilprozesse liegen vor: Planen des Personalbedarfs, Beschaf-
fen des Personals, Betreuen des Personals, Beraten des Personals, Qualifizie-
ren/entwickeln/fördern des Personals und Abbau von Personal [ebenda, S. 221f].
Im Rahmen des Finanzmanagementprozesses werden finanzielle Mittel geplant
und gesteuert Zielsetzung ist es dabei, eine geeignete Vermögens- und Geldmittel-
disposition vorzuhalten. Folgende Teilschritte liegen vor: Finanzbedarf pla-
nen/abdecken, Liquidität planen/realisieren/kontrollieren, Kapital beschaf-
fen/anlegen, Anlagen-/Finanzbuchhaltung durchführen, Zahlungseingänge
überwachen und Steuer-/Versicherungsfragen klären [ebenda, S. 222]).
Der Ressourcenmanagementprozess plant und steuert die notwendigen Ressour-
cen wie zum Beispiel Standorte, Gebäude, Maschinen, Werkzeuge, Transportein-
richtungen und die Energieversorgung. Teilprozesse sind: Ressourcen pla-
nen/beschaffen, Ressourcen installieren/warten/instand halten, Ressourcen
wiederverwenden/entsorgen, Lieferanten bewerten/auswählen und Nutzer beraten
[ebenda, S. 222]).
Der IT-Management-Prozess beinhaltet die Unterstützung des Unternehmens mit
IT Systemen. Zielsetzung ist es dabei, einen reibungslosen und wirtschaftlichen
15 Referenzprozessmodelle 143
Ablauf der Information und Kommunikation innerhalb des Unternehmens sicherzu-
stellen. Teilprozesse sind: IT Systeme planen/beschaffen, IT Systeme betreuen,
Rechenzentrum betreiben, Dokumente verwalten/archivieren, Daten si-
chern/schützen und Anwender beraten [ebenda, S. 222f].
Innerhalb des Qualitätsmanagementprozesses werden Rahmenbedingungen ge-
schaffen, die eine Qualität sicherstellen und sie Einhaltung relevanter Qualitätsvor-
schriften sicherstellen. Teilprozesse sind: QM-System einfüh-
ren/anpassen/auditieren/zertifizieren, Management-Reviews/Q-Assessments
koordinieren, Q-Dokumente/Berichte erstellen/lenken, QM schulen und QM beraten
[ebenda, S. 223].
Im Rahmen des Controllingprozesses erfolgt die Planung/Umsetzungskontrolle
der operativen Geschäftsziele. Teilprozesse sind: Businessplan erstellen, operative
Ziele planen/kontrollieren, Kosten-/Leistungsrechnung durchführen, Kennzahlen-
/Informationssystem entwickeln/implementieren, Compliance Management durch-
führen, Controllingmethoden/-instrumente auswählen/bereitstellen und Weiterbil-
den/Beraten.
Zusammenfassung
Das Referenzprozessmodell von Schmelzer/Sewsselmann setzt sich aus primären
und sekundären Prozessen zusammen. Primäre Prozesse nehmen Kundenanforde-
rungen auf und setzen diese in Kundenzufriedenheit um. Das Modell umfasst zahl-
reiche Prozesse und Subprozesse.
15.5 SCOR-Modell
Das SCOR-Modell (Supply Chain Operations Reference-Modell) ist für den Produk-
tionsbereich gedacht und berücksichtigt die gesamte Supply Chain (Wertschöp-
fungskette). Dabei stehen die operativen, unternehmensübergreifenden logistischen
Prozesse und die Koordination dieser Prozesse im Vordergrund. Es soll also der
gesamte Lebenszyklus eines Produkts (von der Rohstoffgewinnung bis zur Entsor-
gung) analysiert und gestaltet werden. Das SCOR-Modell wurde vom Supply-Chain
Council, einem gemeinnützigen Industrieverband mit ca. 1.000 internationalen Un-
ternehmen, entwickelt. Zielsetzung ist, ein branchenübergreifendes Referenzmodell
für Supply-Chain-Prozesse zu entwickeln, einen Standard zu setzen und damit die
Durchsetzung des Supply-Chain-Konzepts zu fördern. Seine Zielsetzungen sind:
Erfassung des Istzustands von Supply-Chain-Prozessen und Entwicklung von
Sollkonzepten
Messung der operativen Prozessleistung und Zielorientierung an „Best-in-Class-
Ergebnissen“
Identifikation erfolgreicher Managementpraktiken und Softwarelösungen.
Einführung definierter Standardprozesse ermöglichen
Bereitstellung eines Rahmens für die Beschreibung und Kommunikation der
Referenzprozesse
Unterstützung einer situationsgerechten Anpassung
Es berücksichtigt fünf Kategorien von Supply-Chain-Prozessen: Plan, Source, Make,
Deliver, Return (Planung, Beschaffung, Herstellung, Lieferung und Rücknahme). In
der folgenden Abbildung sind die Supply-Chain-Prozesse in ihrem Kontext zu Lie-
feranten und Kunden dargestellt.
15 Referenzprozessmodelle 144
Abbildung 15.5-1: Supply Chain-Prozesse nach SCOR (Quelle: [SCOR 2005, S. 5])
Die Supply-Chain-Prozesse sind wie folgt definiert (vgl. [Scor 2005, S. 6]):
Plan
Im Rahmen der Planung geht darum, das Kapazitätsangebot und die Kapazi-
tätsnachfrage abzustimmen und somit die Rahmenbedingungen für die übrigen Pro-
zesse zu schaffen. Daneben sollen Geschäftsregeln, die Leistungs der Supply Chain,
die Datengewinnung und das Inventar verwaltet werden.
Source
Die Beschaffung beinhaltet den Erwerb, den Erhalt, die Prüfung und die Bereitstel-
lung der (Vor-) Produkte und Dienstleistungen.
Make
Die Herstellung beinhaltet die Produktionsplanung, Produktionsausführung, Monta-
ge, Qualitätskontrolle und Verpackung. Es sollen End-/Zwischenprodukte herge-
stellt, die dann an Kunden geliefert werden. Hierbei ist zwischen Make-to-stock
(Lagerfertigung), Make-to-order (Auftragsfertigung) und Engineer-to-order (Pro-
jektfertigung) zu unterscheiden.
Deliver
Die Lieferung umfasst die Auftragsabwicklung, das Lager- und das Transportmana-
gement für Produkte oder Dienstleistungen.
Return
Im Rahmen der Rücknahme werden fehlerhafte, unerwünschte oder nicht mehr
benötigte Produkte angenommen und die Rücksendung von Rohstoffen an Lieferan-
ten gesteuert.
Neben diesen fünf Kategorien berücksichtigt das SCOR-Modell vier Detaillie-
rungsebenen; der Fokus des SCOR-Modells bezieht sich aber nur auf die ersten drei
Ebenen, da die vierte Ebene unternehmensindividuell auszugestalten ist (= Imple-
mentierungsebene). Die vier Ebenen sind in der folgenden Abbildung dargestellt.
15 Referenzprozessmodelle 145
Abbildung 15.5-2: Ebenen des SCOR-Modells. Quelle: [SCOR 2005, S. 6]
Die vier Ebenen sind nachfolgend kurz erläutert (vgl. [SCOR 2005, S. 6-11])
Ebene 1
Die erste Ebene (höchste Prozessebene) identifiziert die wettbewerbsrelevanten
Supply-Chain-Prozesse eines Unternehmens und legt die Leistungsziele für diese
Prozesse fest. Somit sind der Aufgabenumfang der Supply Chain, ihre Teilnehmer
und die Beziehungen der Prozesse definiert. Für ein Maschinebauunternehmen kön-
nen z.B. die Planung und die Koordination der Wertschöpfungsaktivitäten entschei-
dend sein, wohingegen für einen Lebensmittelhersteller der Wettbewerbsvorteil in
der Produktion oder der Distribution liegt.
Ebene 2
Auf der Ebene 2 (Konfigurationsebene) findet eine Konfiguration der relevanten
Kernprozesse statt; als Basis dient hierbei die verfolgte Wettbewerbsstrategie. Um
die Konfiguration vorzunehmen, werden 30 Standardprozesskategorien eingesetzt.
Hierbei werden einzelnen Prozessketten miteinander verknüpft; somit werden
Schnittstellen und Redundanzen erkannt. Die Prozesskategorien unterscheiden sich
bei den Ausführungsprozessen (Source, Make, Deliver und Return) nach der Auf-
tragsart (z.B. auftragsbezogene Produktion oder Produktion auf Lager). Die Pla-
nungsprozesse werden nach den jeweiligen Ausführungsprozessen untergliedert.
Werden z.B. vom Markt kurze Lieferzeiten und niedrige Fertigungskosten gefordert,
so kann ein Unternehmen die kundenanonyme Lagerfertigung von Komponenten
mit der kundenindividuellen Montage und Lieferung kombinieren.
Ebene 3
Auf der Ebene 3 (Gestaltungsebene) werden die Prozesskategorien mittels Prozess-
elementen konkretisiert. Die Prozesselemente beschreiben die wesentlichen Prozess-
schritte (Teilprozesse) der jeweiligen Prozesskategorie, inkl. deren In- und Output,
deren Reihenfolge und deren Ein- und Ausgangsinformationen. Die Ebene 3 enthält
15 Referenzprozessmodelle 146
ebenso Best Practices und verfügbare informationstechnische Anwendungssysteme.
Daneben schafft die Ebene 3 die Basis für Benchmarks.
Ebene 4
Auf der Ebene 4 (Implementierungsebene) findet die Beschreibung der unterneh-
mensspezifischen Aufgaben und Aktivitäten für jedes Prozesselement statt. Hierfür
liegen keine Modellierungselemente vor, da die Abbildung sehr detailliert und un-
ternehmensspezifisch ist und da Modellierungsverfahren existieren, die eingesetzt
werden können.
Zusammenfassung
Das SCOR-Modell (Supply Chain Operations Reference) ist für den Produktionsbe-
reich gültig und berücksichtigt die gesamte Supply Chain (Wertschöpfungskette).
Dabei stehen die operativen, unternehmensübergreifenden logistischen Prozesse und
die Koordination dieser Prozesse im Vordergrund. Das SCOR-Modell berücksichtigt
fünf Kategorien von Supply-Chain-Prozessen: Plan, Source, Make, Deliver, Return.
Diese fünf Kategorien werden auf vier Ebenen betrachtet: höchste Ebene, Konfigu-
rationsebene, Gestaltungsebene und Implementierungsebene.
15.6 EFQM - Modell
Neben Referenzprozessmodellen liegen auch Modelle vor, die Qualitätsmanagement
durch Prozessorientierung fordern. Ein solches Modell ist das EFQM-Modell, das
von der European Foundation for Quality Management erarbeitet wurde
(www.efqm.org). Hintergrund der Entwicklung des EFQM-Modells war das Ziel,
analog zum japanischen Deming Award und zum US-amerikanischen Malcolm
Baldrige National Quality Award, einen europäischen Qualitätsmanagementpreis (=
European Quality Award - EQA) zu initiieren. Dabei werden Organisationen ausge-
zeichnet, die das Qualitätsmanagement in beispielhafter Weise umgesetzt haben.
Das EFQM-Modell bezieht sich auf die Organisation als Ganzes und auf die Umset-
zung des Qualitätsmanagements in allen Bereichen einer Organisation. Die folgende
Abbildung stellt die Bestandteile des EFQM-Modells dar.
Abbildung 15.6-1: EFQM-Modell. Quelle: [Bou Llusar et al. 2009, S. 7]
15 Referenzprozessmodelle 147
In diesem Modell werden Befähiger (Enabler) und Ergebnisse (Results) unterschie-
den.
Die Führung ist der erste Bestandteil und unterstreicht die Rolle des Manage-
ments innerhalb der Organisation. Ihre Aufgabe ist Entwicklung der Vision, der
Mission und der Werte, um somit der Organisation eine Richtung und Handlungs-
prinzipien vorzugeben. Damit werden die Zielerreichung und der nachhaltige Erfolg
von Unternehmen sichergestellt (vgl. [Wongrassamee et al. 2003, S. 17]).
Im Rahmen der Mitarbeiter als zweiter Bestandteil des Modells werden die Aus-
schöpfung des Potenzials der Mitarbeiter durch deren Management und Entwicklung
bewertet. Daneben erfolgt an dieser Stelle auch die Bewertung des Umfelds, das
eine Integration von Mitarbeitern in Qualitätsthemen ermöglichen soll. Basis für die
Entfaltung des Potenzials der Mitarbeiter ist die Strategie der Organisation. Wichti-
ge Prinzipien innerhalb dieses Bestandteils sind die Betrachtung des systemischen
Zusammenwirkens der Mitarbeiter auf verschiedenen Ebenen, die Mitarbeiterorien-
tierung, eigenständiges Handeln der Mitarbeiter, Kommunikation der Mitarbeiter
und Anerkennung der Mitarbeiter. Die Wichtigkeit der Mitarbeiter wird dadurch
unterstrichen, dass eine eigene Kategorie vorliegt, statt Mitarbeiter in die Kategorie
Ressourcen zu integrieren.
Auf Basis der Führung und der enthaltenen Vision, Mission und Werte erfolgt die
Entwicklung entsprechender Strategien. Hierbei sollen alle Interessensgruppen, die
Branchenstruktur und das unternehmerische Umfeld berücksichtigt werden. Aus der
entwickelten Strategie werden anschließend die Politik des Unternehmens und un-
tergeordnete Ziele bzw. Pläne erstellt, die der Umsetzung der Strategie dienen (vgl.
Tummala und Tang 1994, S. 47).
Partnerschaften und Ressourcen beinhalten die Bewertung der Nutzung von tech-
nologischen, materiellen, informellen und finanziellen Möglichkeiten. Neben den
internen Ressourcen werden ebenfalls Lieferantenbeziehungen und Bindungen zu
externen Partnern betrachtet. Die Planung und Steuerung der internen und externen
Ressourcen erfolgt mittels eines integrativen strategischen Ansatzes (vgl. Bou-
Llusar et al. 2009, S. 7).
Die Prozesse einer Organisation stellen den zentralen Bestandteil des EFQM-
Modells dar. Prozesse gehören zu den Befähigern einer Organisation, stellen aber
auch die Schnittstelle zu den Ergebnissen dar. Dabei sollen Prozesse gestaltet, ge-
führt und ständig verbessert werden, um Kunden und andere Interessengruppen
zufriedenzustellen (vgl. [Bou Llusar et al. 2009, S. 7]). Im Rahmen der Prozesse
liegen folgende Anforderungen vor:
systematische Gestaltung und systematisches Management von Prozessen
kundenorientierte Prozessverbesserung und -innovation
kundenorientierte Entwicklung von Produkten und Dienstleistungen
Herstellung, Vermarktung und Betreuung der Produkte
Management der Kundenbeziehungen (Customer Relationship Management).
Mit den erläuterten Befähigern lassen sich Ergebnisse erzielen, die nachfolgend
erläutert sind (vgl. [Wongrassamee et al. 2003, S. 17], [Tummala und Tang 1994, S.
47]).
Die Mitarbeiterergebnisse werden mittels Indikatoren wie z.B. Mitarbeiterzu-
friedenheit, -motivation und -identifikation gemessen.
Die Kundenergebnisse werden mittels Indikatoren wie z.B. Kundenzufrieden-
heit und -loyalität gemessen.
Führung
Mitarbeiter
Politik und Strategie
Partnerschaften und Ressourcen
Prozesse
15 Referenzprozessmodelle 148
Innerhalb der Gesellschaftsergebnisse wird die Erfüllung gesellschaftlicher
Bedürfnisse gemessen.
Die Schlüsselergebnisse enthalten Indikatoren zur Messung der finanziellen und
nichtfinanziellen Leistung.
Zur Einschätzung von Organisationen hinsichtlich ihrer Leistung, werden die neun
Bestandteile des EFQM-Modells mittels detaillierter Fragen bewertet. Hierfür liegen
folgende Reifegrade vor: noch nicht begonnen, teilweise begonnen, beachtlicher
Fortschritt und vollständig erreicht.
Zusammenfassung
Für konkrete Geschäftsprozesse und für Prozessarchitekturen gibt es vorgedachte
Lösungen. Die wichtigsten wurden hier vorgestellt. Die Wertkette von Porter defi-
niert die typische Prozesszusammenstellung von Industrieunternehmen. Das Han-
dels-H analysiert den typischen Prozessaufbau in Handelsunternehmen. Das Refe-
renzprozessmodell von Schmelzer/Sesselmann stellt, wiederum am Beispiel von
Industrieunternehmen, überblicksartig die zu realisierenden Prozesse zusammen.
Das SCOR-Modell (Supply Chain Operations Reference-Modell) ist für den Produk-
tionsbereich gedacht und berücksichtigt die gesamte Supply Chain (Wertschöp-
fungskette). Ein Modell, bei dem die Qualitätssicherung durch Prozessorientierung
im Vordergrund steht, ist das EFQM-Modell. Außerdem wurde auf Integrierte pro-
zessorientierte Software hingewiesen, bei deren Kauf oder Miete vorgedachte Ge-
schäftsprozesse und Prozessarchitekturen mitgeliefert werden.
16 IT-Unterstützung
Es wurde schon oft thematisiert in diesem Text, Geschäftsprozesse werden heute so
gut wie immer von IT unterstützt und immer öfter automatisch, d.h. vollkommen
softwaregestützt, abgewickelt. Das hat Konsequenzen für das Geschäftsprozessma-
nagement. Es muss sich in immer größerem Umfang dieser Thematik zuwenden und
dabei mit dem IT-Management kooperieren. Wir befinden uns damit im Über-
schneidungsbereich A von Abbildung 1 (xxx). Es ist also Kooperation nötig und
diese wird erleichtert, wenn beide Seiten über den jeweils anderen Arbeitsbereich
Bescheid wissen. Deshalb werfen wir hier einen Blick auf die wichtigsten Aspekte
der IT-unterstützten Prozessabwicklung.
16.1 IT-Landschaften, Herkunft
Wie sehen sie heute aus, diese IT-Landschaften, in denen die Prozessunterstützung
erfolgt, in denen durch geeignete Soft- und Hardware die Geschäftsprozesse entwe-
der teilweise oder ganz, mit mehr oder weniger automatisierten Abschnitten, reali-
siert werden?
Sie können heute sehr vielfältig und heterogen sein. Meist liegt ein sog.
Client/Server-Netzwerk vor, aber auch Großrechner (oftmals Legacy-Systeme ge-
nannt) sind immer noch oder wieder da. Teile der benutzten IT können auch ausge-
lagert sein (Outsourcing). In den letzten Jahren kamen diesbezüglich die anonymen
Server-Rechenzentren im sog. Cloud Computing immer mehr zum Einsatz.
Herkunft der Software
Die konkrete prozessorientierte30
Software kann auf verschiedene Art entstehen. Auf
das Wesentliche zusammengefasst kann die heutige Situation anhand der wichtigs-
ten zu fällenden Entscheidungen wie folgt beschrieben werden (vgl. auch die fol-
gende Abbildung):
Klassische Programmierung oder komponentenbasierte Entwicklung, letztere
hier als Zusammenspiel von Workflows oder Services. Für das Geschäftspro-
zessmanagement bedeutet dies, dass ein Prozessmodell an die IT gegeben wer-
den muss. Bei der workflowbasierten Variante evtl. schon mit Vorschlägen zu
den gewünschten Komponenten.
Entscheidung zwischen Individualentwicklung und dem Bezug von Standard-
software. Für das Geschäftsprozessmanagement bedeutete dies entweder die
Mitwirkung an der Formulierung der Anforderungen für die zu entwickelnde
Software oder die Mitwirkung bei der Auswahl der Standardsoftware ("welche
passt am besten"), für die eine gute Kenntnis der eigenen Geschäftsprozesse nö-
tig ist.
30 Wir betrachten nur diese, sie ist auch hier (im Geschäftsprozessmanagement) die Ausschlaggebende.
Hauptvertreter ist die ERP-Software.
16 IT-Unterstützung 150
Betrachten wir die Konsequenzen für das Geschäftsprozessmanagement anhand
der folgenden Abbildung und den Varianten 1 bis 8.
Eine wichtige Unterscheidung wurde gerade oben schon eingeführt: Die Entste-
hung der Software als ein Produkt klassischer Programmierung oder als ein Zusam-
menspiel einzelner Komponenten. Falls klassische Programme erstellt werden (Pos.
1, 2), hat das Geschäftsprozessmanagement die detaillierten Prozessmodelle zu
liefern, die dann in das sog. Requirements Engineering der Softwareentwicklung
einfließen. Der Berührungspunkt ist die programmnahe Prozessmodellierung. Im
Falle von Standardsoftware (Pos. 3, 4) hat dies das (Standard)Softwarehaus getan
und "vorgedachte" Geschäftsprozesse in die Software umgesetzt. Dem Geschäfts-
prozessmanagement bleibt hier dann die Aufgabe, diejenige prozessorientierte Stan-
dardsoftware auszuwählen, die am besten zu den eigenen Geschäftsprozessen
passt31
. Also: Eine gründliche Istmodellierung und der Vergleich mit den in der
Software realisierten Geschäftsprozessen.
Entsteht die Software workflowbasiert im Auftrag des Unternehmens (Pos. 5, 6),
ist das Geschäftsprozessmanagement u.U. näher an der Realisation dran. Denn dann
geht es um die einzelnen Workflows, die fachlich determiniert sind. Gibt es ein
komfortables Werkzeug, können u.U. auch Nichtinformatiker diese Festlegungen in
lauffähige Anwendungen umsetzen. Auf jeden Fall wird auch hier, wenn es an die
endgültige Umsetzung und die Bereitstellung der Hardwarebasis geht, eine intensive
Zusammenarbeit mit dem IT-Management nötig sein.
Bezieht man hier Standardsoftware (Pos. 7, 8), geht es wieder nur um den Ver-
gleich der eigenen Vorstellungen mit denen der angebotenen Softwarevarianten,
diesmal aber in Bezug auf den Workflow. Das Geschäftsprozessmanagement ist
dabei stark beteiligt, weil es natürlich die fachliche Seite des Workflows am besten
kennt.
In allen Fällen muss das Geschäftsprozessmanagement mitentscheiden, ob die
prozessorientierte Software ausgelagert werden soll (Pos. 2, 4, 6, 8) oder nicht. Dies
ist nicht nur eine finanzielle und IT-technische Frage, sie berührt auch andere, z.B.
rechtliche Aspekte.
Abbildung 16.1-1: Quellen von Software für die Prozessabwicklung.
16.2 IT-Unterstützung heute / konkret
Nimmt man die beiden Dimensionen (Problemstruktur und Planungsebenen) zu-
sammen, kann man eine zweidimensionale Matrix erstellen und für jede Zelle be-
trachten, welche Software eingesetzt werden kann.
31 Oder gleich zu beschließen, sich einer der angebotenen Varianten anzupassen.
16 IT-Unterstützung 151
Abbildung 16.2-1: Softwareunterstützung nach Problemstruktur und Planungsebene.
Quelle: [Alpar, Grob, Weimann u.a. 2002, S. 31].
Sehen wir uns die einzelnen Zellen mit den entsprechenden betrieblichen Anwen-
dungssystemen genauer an.
Wohlstrukturierte Probleme/Ausführungsebene: Hier sind Transaktionssysteme und
Büroautomatisierungssysteme anzutreffen.
Transaktionssysteme (Transaction Processing Systems, TPS) sind Systeme zur Ab-
wicklung von Geschäftstransaktionen. Sie unterstützen Geschäftsvorgänge, die sich
ständig wiederholen. Zum Beispiel bei der Auftragsbearbeitung und Buchhaltung.
Diese Systeme helfen der Ausführungsebene, effizienter zu arbeiten. Wesentliches
Merkmal eines solchen Systems sind umfangreiche Datenbestände, die zur Bearbei-
tung der laufenden Geschäftsvorfälle durch Benutzereingaben abgefragt oder geän-
dert werden können (z.B. Lagerbestände, Platzbuchungen bei Fluggesellschaften,
o.Ä.). Die Ausgaben können einfache, kurze Auskünfte oder das Ergebnis weitrei-
chender Verarbeitungsvorgänge sein. Die von Transaktionssystemen verarbeitete
Information ist i.d.R. die „aktuelle“ (der Gegenwart bzw. kurzen Vergangenheit)
oder sie stammt aus der Vergangenheit. Sie kommt von internen Prozessen und
Datenbanken und ihr Detaillierungsgrad ist hoch.
Büroautomatisierungssysteme (Office Automation Systems, OAS) oder auch Büro-
informationssysteme (Office Information System, OIS) unterstützen bei den admi-
nistrativen Aufgaben der Ausführungsebene. Mit ihnen werden die typischen Büro-
tätigkeiten unterstützt. Beispiele sind die Funktionen der Office-Pakete. Sie werden
natürlich auch auf den Leitungsebenen eingesetzt, dort allerdings mit einer in Bezug
auf die Gesamtaufgabe geringeren Bedeutung.
Softwarebestandteile von Büroinformationssystemen sind:
Endbenutzerwerkzeuge zur Verbesserung der persönlichen Produktivität, z.B.
Textverarbeitung, Präsentationsgrafik und Datenverwaltung,
16 IT-Unterstützung 152
Kommunikationsdienste wie elektronische Post, Fax, Dateitransfer und Zugriff
auf Datenbanken,
Systeme zur Unterstützung der Teamarbeit wie Vorgangsbearbeitungssysteme
(Workflow-Systeme) und Arbeitsgruppensysteme (Workgroup-Systeme).
Wohlstrukturierte Probleme/Leitungsebene 1 (operativ): Hier setzt man Informati-
ons- und Kommunikationssysteme ein, mit denen die tägliche Planung unterstützt
wird. Diese Planungssysteme nutzen Verfahren der Unternehmensforschung (Mana-
gement Science, MS, oder Operations Research, OR).
Beispiele für hier zu lösende Probleme sind die optimale Zuteilung von zu verar-
beitenden Produkten zu Maschinen, die Berechnung der optimalen Bestellgröße oder
die Simulation des Kundenaufkommens zwecks Personaleinsatzplanung im Einzel-
handel.
Wohlstrukturierte Probleme/Leitungsebene 2 (taktisch): Auf der taktischen Lei-
tungsebene können Managementinformationssysteme (Management Information
Systems, MIS) eingesetzt werden. Ihre Aufgabe ist es, detaillierte Berichte über das
Unternehmensgeschehen zu liefern und so den Managern bei der Gewinnplanung
und -überwachung zu helfen.
Wohlstrukturierte Probleme/Leitungsebene 3 (taktisch): Die hier anzutreffenden
Führungsinformationssysteme (Executive Information Systems, EIS) dienen der
obersten Managementebene. Sie liefern interne Kennzahlen und externe Informatio-
nen. Die Daten werden oft aus operativen Daten extrahiert und verdichtet und durch
externe Daten angereichert.
Semistrukturierte Probleme/Ausführungsebene: Hier kann man Expertensysteme
(Expert Systems, XPS) einsetzen. Sie werden zur Lösung von Problemen ange-
wandt, für die es keine exakten Lösungsverfahren gibt. Grundlage ist das kodierte
Wissen erfahrener Praktiker (aus dem jeweiligen Bereich), das in Fakten und Regeln
gefasst ist.
Der typische Aufbau ist wie folgt: Eine Wissensbasis enthält die erwähnten Fak-
ten und Regeln, diese werden zur Problemlösung von einem Programm
(Inferenzmaschine) ausgewertet. Grundlage für diese Wissensverwaltungs- und -
auswertungstechnik ist die Prädikatenlogik. Programmiert wird hier mit deklarativen
Sprachen. Das bekannteste Beispiel für so eine Sprache ist Prolog.
Ein Beispiel für ein Expertensystem auf der ausführenden Ebene ist das System
von Kreditkartenanbietern für die Überprüfung fragwürdiger Kreditkartentransakti-
onen.
Semistrukturierte Probleme/Leitungsebene 1 (operational): Entscheidungsunterstüt-
zungssysteme (Decision Support Systems, DSS) sind für semistrukturierte Probleme
auf allen Leitungsebenen geeignet. Sie sollen das gemeinsame Problemlösen zwi-
schen Mensch und Maschine erleichtern. Daten werden oft aus operativen Daten
extrahiert, aggregiert und mit externen Daten angereichert. Der Methodenvorrat
besteht meist aus statistischen und mathematischen Verfahren. Schwerpunkt ist die
Planung im engeren Sinn und zwar die Untersuchung möglicher Handlungsalterna-
tiven durch mathematische Modelle und Methoden.
Die ersten DSS wurden auf individuelle Nutzer ausgerichtet, z.B. zur Unterstüt-
zung von Portfoliomanagern, die Kunden bei Vermögensanlagen beraten, oder Pro-
duktmanagern, die Marketingpläne vorbereiten. Andere Adressaten sind Produkt-
manager bei Konsumgüterherstellern, die mit Tabellenkalkulationsprogrammen
16 IT-Unterstützung 153
Absatzpläne bestimmen und dabei die Auswirkungen alternativer Marketingmaß-
nahmen mit Hilfe von Marktmodellen testen. In Banken und Börsen operieren
Wertpapierspezialisten mit Finanzmarktmodellen. Tourenplaner ermitteln optimale
Routen zur Belieferung von Kunden, Betriebs- und Verkaufsstätten. Produktions-
planer minimieren durch Simulation die notwendigen Maschinen und die Durch-
laufzeiten in der Fertigung.
Zur Entscheidungsunterstützung sind auch Expertensysteme sehr geeignet. Ein
Beispiel dafür ist ein Expertensystem der Datev e.G., das Jahresabschlussdaten von
Unternehmen analysiert.
Semistrukturierte Probleme/Leitungsebene 2 (taktisch): Neben den Entscheidungs-
unterstützungssystemen für einzelne Personen werden hier auch solche für Gruppen
(Group Decision Support Systems, GDSS) eingesetzt. Diese GDSS sind dann erwei-
tert auf die Unterstützung zusammenarbeitender Gruppen oder ganzer Organisatio-
nen (Organizational Decision Support Systems, ODSS).
Ein Beispiel für eine Aufgabe von ODSS ist die gemeinsame Erarbeitung der
jährlichen Ergebnisplanung. GDSS müssen zusätzlich (zur Ausstattung der DSS)
Komponenten für die Kommunikation und das Finden eines Gruppenkonsenses
enthalten. Bei ODSS sollte ein „institutionelles Gedächtnis“ bzgl. früherer Problem-
fälle und zugehöriger Entscheidungen vorhanden sein.
Semistrukturierte Probleme/Leitungsebene 3 (strategisch): Die Einsatzmöglichkei-
ten von Anwendungssystemen entsprechen denen der taktischen Leitungsebene.
Unstrukturierte Probleme/Ausführungsebene: Die Striche bedeuten hier „nicht vor-
handen“. Die Ausführungsebene sollte keine solchen Probleme haben. Falls sie sie
doch haben sollte, gibt es keine betrieblichen Anwendungssysteme für deren Lö-
sung.
Unstrukturierte Probleme/Leitungsebene 1 (operational) und Unstrukturierte Prob-
leme/Leitungsebene 2 (taktisch): Für die hier anfallenden Aufgaben sind die bisher
angeführten Softwareprodukte nicht geeignet. Expertensysteme z.B. liefern zwar
u.U. Ergebnisse, die nicht vorgedacht wurden, sie tun dies aber auf durchstrukturier-
ten Wissensbasen mit Fakten und Regeln. Neuere Entwicklungen in der Künstli-
chen-Intelligenz-Forschung führ(t)en aber zu Werkzeugen, die zur Lösung unstruk-
turierter Probleme beitragen können. Diese Wissensentdeckungssysteme
(Knowledge Discovery Systems, KDS) helfen, neue Lösungsansätze oder Zusam-
menhänge zu entdecken.
Konkrete Techniken sind hier derzeit z.B. Künstliche Neuronale Netze (Artificial
Neural Networks, ANN) und Genetische Algorithmen (Genetic Algorithms, GA).
Auch die Techniken des Data Mining gehören zu diesem Bereich der Wissens-
entdeckungssysteme, oftmals werden die beiden Begriffe Data Mining und Wissens-
entdeckung auch synonym gebraucht. Zu Data Mining gehören Methoden, die in
einer Datenmenge (i.d.R. aus Datenbanken) Zusammenhänge entdecken, die von
den Erstellern der Datenbank nicht vorgedacht wurden. Es geht also um die soft-
waregestützte Ermittlung bisher unbekannter Zusammenhänge, Muster und Trends
aus dem Datenbestand sehr großer Datenbanken oder eines Data Warehouses.
Softwareprodukte für Data Mining verwenden komplexe statistische Methoden,
Techniken der Künstlichen-Intelligenz-Forschung (v.a. neuronale Netze und un-
scharfe Logik) und Entscheidungsbaumtechniken.
16 IT-Unterstützung 154
Beispiele sind die Analyse von Verkaufszahlen, um Kaufverhalten zu untersu-
chen, z.B. um neue diesbezügliche Trends frühzeitig zu entdecken. Oder das Heraus-
finden von Kundencharakteristika, um dadurch gezieltere Marketingmaßnahmen
ergreifen zu können.
Unstrukturierte Probleme/Leitungsebene 3 (strategisch): Hier gibt es noch keine
Unterstützung durch betriebliche Anwendungssysteme.
16.3 Automatisierung
Es ist im Geschäftsprozessmanagement oft von Automatisierung die Rede. Natürlich
hier immer in Bezug auf Geschäftsprozesse. Neben diesen gibt es ja viele andere
Bereiche, in denen die Automatisierung ständig voranschreitet, denken wir nur an
unsere Kraftfahrzeuge.
Mit Automatisierung ist die ganze oder teilweise Abwicklung von Geschäftspro-
zessen durch Software (und natürlich die zugehörige Hardware) gemeint. Dies ist im
technischen Bereich nichts Neues, in jedem technischen System (Geldautomat usw.)
laufen automatisierte Prozesse ab. Bei der Umsetzung von Geschäftsprozessen in
Software war dies bis vor einiger Zeit nicht so. So richtig umfassend realisiert haben
dies die im Internet und mit Hilfe des Internet tätigen Unternehmen. Alle Geschäfts-
prozesse, die mit den Kunden zu tun haben, werden durch Anwendungssoftware
realisiert und darüber hinaus die nachfolgenden in Logistik und Finanzwesen.
Dies ist heute Alltag, das Geschäftsmodell der Internetunternehmen beruht da-
rauf.
Hintergrund
Wie kommt es, dass wir auch bei Geschäftsprozessen inzwischen in vielen Berei-
chen eine ganze oder teilweise Automatisierung beobachten können?
Etwa ab den 1970-er Jahren wurden Geschäftsprozesse durch IT-Systeme unter-
stützt. Zu Beginn aber nur in einzelnen Funktionen. D.h., der Geschäftsprozess war
zwar in der Software hinterlegt und wurde steuernd abtgearbeitet, aber nur einzelnen
Funktionen wurden durch Software erledigt, das meiste durch die beteiligten Men-
schen. Dies änderte sich, die Softwareunterstützung dehnte sich immer mehr aus,
von der Unterstützung einzelner weniger Funktionen bis zur heutigen flächende-
ckenden Geschäftsprozessunterstützung. Parallel wurde und wird die Prozessunter-
stützung immer detaillierter. Wurden anfangs in den Geschäftsprozessen nur einzel-
ne Funktionen und die Informationsflüsse zwischen ihnen unterstützt, geht es heute
teilweise in die Vollunterstützung, bei der nur die Entscheidungen den Menschen
überlassen bleiben. So wird z.B. bei einer Standardprozessmodellierung der Trans-
port und die Verarbeitung von Geschäftsobjekten vollumfänglich erfasst, lediglich
die Realisierung einzelner Funktionen bleibt noch außen vor.
So kommt es, dass heute die gängige Integrierte prozessorientierte Software die
Nutzer für die Interaktion von Maske zu Maske leitet und ansonsten vollautomati-
siert abläuft. Das machte es auch möglich, dass das Geschäftsmodell der Internetun-
ternehmen auf weitgehend vollautomatisierten Prozessen beruht, und dies nicht nur
im E-Commerce, sondern auch dahinter. Lediglich bei Konfliktfällen kommen hier
noch Menschen zum Einsatz.
Dies hat bei allen Vorteilen auch Schattenseiten. Jedes Abbilden von Geschäfts-
prozessen in Software führt zu einer "Zementierung" des Geschäftsprozesses in dem
16 IT-Unterstützung 155
Sinn, dass für jede auch noch so kleine Änderung des Prozesses eine Änderung der
Software nötig wird. Bei einer Automatisierung ist dies noch viel massiver der Fall.
Trotzdem ist eine Umkehr dieser Entwicklung nicht vorstellbar, höchstens ein er-
höhter Einsatz von Entwicklern. Das ist der Grund für die Wiederkehr von Indivi-
dualsoftware mit riesigen Entwicklergruppen bei den großen Internetunternehmen,
wie wir sie zuletzt in den 1960- und 1970-Jahren bei großen Unternehmen für die
Entwicklung der damaligen individuellen Anwendungssoftware sahen (die dann
durch ERP-Software abgelöst wurde).
Trends
Dieser Entwicklung liegen zwei Trends zugrunde. Schon seit dem Aufkommen
prozessorientierter integrierter Software32
der Trend zu einer immer detaillierteren
Abbildung der Geschäftsprozesse in die Software. Dies war Kundenwunsch und er
wurde erfüllt. Schon dieser Trend erzwang eine immer detailliertere Prozessmodel-
lierung. Seit Aufkommen der Internetunternehmen kam ein zweiter massiver Trend
dazu, der zu vollständig durch Programme abgewickelten Geschäftsprozessen führt
– zur Automatisierung also. Konkret bedeutet dies, dass der Kunde bei seinen Ge-
schäften und sonstigen Aktivitäten mit Internetunternehmen nur noch mit Program-
men zu tun hat. Diese Automatisierung erfasst weiterhin auch große Teile des Fi-
nanzwesens und der Logistik. Die Webunternehmen führen uns diesen Trend gerade
eindrücklich vor. Nicht nur der Kontakt zum Kunden, sondern seine Rückmeldun-
gen, das Mahnwesen, Finanzwesen, die Leistungserbringung usw. werden automati-
siert abgewickelt.
Aber auch in den Organisationen, die nicht primär im E-Commerce tätig sind,
nimmt der Grad an Automatisierung immer mehr zu. Die Integrierte prozessorien-
tierte Software wickelt immer mehr Abschnitte des Geschäftsprozesses vollautoma-
tisch ab. Automatisierung bedeutet hier dann nicht nur „Echtzeit“, das haben wir in
ERP-Software schon lange, und auch nicht nur die Unterstützung einzelner
Funktionen, sondern die weitgehend durch ein Programm realisierte Abwicklung der
Geschäftsprozesse. Für den Menschen bleiben von Unternehmensseite her nur noch
die Entscheidungen und die Ausnahmen. Für die mitwirkenden Menschen bleiben
die Aufgaben mit Entscheidungscharakter und die, die nicht automatisiert werden
können.
Nicht nur bei den Kundenkontakten
Die Automatisierung betrifft nicht nur die Kundenkontakte, sondern auch die übri-
gen Bereiche der Unternehmen, z.B. das Finanzwesen. Zumindest in der Planung
einiger Unternehmen betrifft es auch die Logistik ("Drohnen"). Wir nähern uns
damit der vollautomatisierten Abwicklung auch dieser Geschäftsprozesse, wo
menschliches Eingreifen nur noch da erfolgt, wo Entscheidungen anstehen, die nicht
automatisiert sind oder Aufgaben, die nicht automatisiert werden können. Hierzu
gehören auch die Kauf- und sonstigen Entscheidungen der Kunden.
Voraussetzungen bzgl Prozessmodellierung
Es dürfte schon klar sein, sei aber nochmals angemerkt: Automatisierung verlangt
eine programmnahe Prozessmodellierung, in Ergänzung zur Istanalyse. Damit ist
32 Heute meist ERP-Software genannt.
16 IT-Unterstützung 156
Prozessmodellierung endgültig in den Bereich des Requirements Engineering für die
Softwareentwicklung geraten.
Dieser Trend und die durch ihn geförderte Entwicklung verkürzen den Abstand
zwischen Prozessmodellierung und Systemanalyse (für die Anwendungsentwick-
lung) und führen auch dazu, dass die Zusammenhänge zwischen den Geschäftspro-
zessen wesentlich intensiver bedacht werden müssen. Ein Prozessmodell wird dann
nicht nur die Prozesse mit ihren Verknüpfungen darstellen, sondern alle Aspekte, die
für ein komplexes zusammenwirkendes Ganzes notwendig sind. Programmnahe
Prozessmodellierung, wird zu einem Bestandteil des Anforderungsmanagements
(Requirements Engineering).
Erfassung der Automatisierung in der Prozessmodellierung
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. Indem also bei einer Tätigkeit nicht nur angege-
ben wird, wer sie realisiert, sondern auch mit Hilfe welcher Anwendungssoftware.
Sie kann auch durch die modellierten Informationsobjekte erkannt werden. Bei IT-
Abdeckung sind diese Teil des Datenbestandes einer Anwendungssoftware und
(hoffentlich) als solche gekennzeichnet.
Betrachtet man z.B. die Geschäftsprozesse eines typischen Internetunternehmens
im B2C33
, 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.
Voraussetzung für eine Automatisierung ist eine detaillierte Modellierung, also
im Rahmen einer Beschaffung nicht Teile beschaffen, sondern zulässige Lieferanten
bestimmen, Lieferanten anfragen, Konditionen klären, Bestellung formulieren, Be-
stellung versenden, usw. Etwa so wie in einer Standardprozessmodellierung. Danach
können dann diese elementaren Funktionen in einer noch detaillierteren Ebene in
einer programmnahen Prozessmodellierung in Programmkonstrukte abgebildet wer-
den.
16.4 Prozessunterstützung
16.4.1 Mit ERP-Software
Ein Softwaretyp, dessen Urheber eine effiziente Lösung für das IT-Problem aller
Organisationen anbieten, hat sich auf breiter Front durchgesetzt, die oben vorgestell-
te Integrierte prozessorientierte Standardsoftware, die heute meist ERP-Software
genannt wird. Diese Software hat (idealtypisch) folgende oben schon angeführten
und hier präzisierten Eigenschaften:
Sie ist prozessorientiert in dem Sinn, dass sie ganze Geschäftsprozesse unter-
stützt und nicht nur einzelne Funktionen.
33 Abkürzung für Business to Customer, für den Bereich der Geschäftstätigkeit im Internet, der direkt
mit dem Kunden zu tun hat.
16 IT-Unterstützung 157
Sie unterstützt alle Geschäftsprozesse des kaufmännischen bzw. betriebswirt-
schaftlichen Bereichs eines Unternehmens einschließlich der Produktionspla-
nung (1. Integrationsaspekt).
Sie ist für die konkreten Strukturen und Geschäftsprozesse vieler Unternehmen
geeignet (2. Integrationsaspekt)34
.
Inzwischen sind diese Produkte auch auf die Zusammenarbeit mit zwischen- und
überbetrieblichen Geschäftsprozessen zum Beispiel zum Supply Chain Management
oder zum Customer Relationship Management vorbereitet.
Das Konzept
Damit beruht ERP-Software auf einer Grundannahme, die sich wie folgt formulieren
lässt: Es ist möglich, für die Anforderungen der Unternehmen eine gemeinsame,
integrierte und prozessorientierte Software zu erstellen. Dies beruht auf zwei Eigen-
schaften heutiger Geschäftsprozesse:
1. Die meisten Geschäftsprozesse sind standardisiert, d.h. sie laufen bei Wiederho-
lung gleich ab und es gibt nicht zu viele Varianten (vgl. xxx).
2. Es gibt so viele Gemeinsamkeiten zwischen den Geschäftsprozessen verschie-
dener Unternehmen, dass es möglich ist, für eine Aufgabe eine gemeinsame
„Software von der Stange“ zu schreiben.
„Durchschnittliche“ und vorgedachte Geschäftsprozesse
Um dies leisten zu können, hat ERP-Software verschiedene Bedingungen zu erfül-
len. Die wichtigste ist, dass sie Modelle von Geschäftsprozessen in ihrer Datenbank
und in ihren Programmen realisiert haben muss und dass diese - mithilfe entspre-
chender Analysen realer Geschäftsprozesse - den tatsächlichen Abläufen und Struk-
turen in den Unternehmen möglichst ähnlich sein müssen. Denn natürlich gibt es
zwischen den Geschäftsprozessen der einzelnen Unternehmen trotz aller Ähnlichkeit
Unterschiede, sodass eine so konzipierte Software den realen Geschäftsprozessen
immer nur mehr oder weniger ähnlich, aber nicht voll mit ihnen übereinstimmend
sein kann.
Deshalb ist es unvermeidlich, dass ERP-Software softwaretechnisch so realisiert
sein muss, dass sie in einem gewissen Umfang an die realen Strukturen des jeweili-
gen Unternehmens angepasst werden kann. Diese Möglichkeit der Anpassung durch
das Verstellen von Parametern ist konstituierend für ERP-Software.
1. Integrationsaspekt
Doch nun zurück zu den oben angeführten Definitionsmerkmalen. Zumindest vom
Grundprinzip her soll dieser Softwaretyp möglichst alle betriebswirtschaftli-
chen/kaufmännischen Bereiche einschließlich der Produktionsplanung umfassen.
Etwas genauer kann die Abgrenzung mit dem Ansatz von Scheer35
bzw. Mertens
vorgenommen werden, da diese die horizontale Integration (über die klassischen
Bereiche wie Produktion, Beschaffung, Lagerhaltung, Rechnungswesen, Personal,
usw.) von der vertikalen (zwischen Administrations- und Dispositionssystemen,
34 Mit den beiden Integrationsaspekten ist dieser Softwaretyp von Textverarbeitungen, Tabellenkalkula-
tionen, usw. abgegrenzt, die ja auch als Standardsoftware bezeichnet werden.
35 Vgl. die grundlegenden Werke von Scheer und Mertens (18. Auflage: [Mertens 2013], 7. Auflage:
[Scheer 1997]).
Genauere Abgrenzung
16 IT-Unterstützung 158
Wertorientierten Abrechnungssystemen, Berichts- und Kontrollsystemen, usw.)
unterscheiden (vgl. xxx). Davon ausgehend kann festgestellt werden, dass heutige
ERP-Software bei den Wertorientierten Abrechnungssystemen ihren Schwerpunkt
hat, mehr oder weniger gut auch die Ebene der mengenorientierten operativen Sys-
teme abdeckt (ohne Forschung/Entwicklung und die eigentliche Produktionssteue-
rung) und sich auch zunehmend in die Berichts- und Kontrollsysteme36
hinein aus-
dehnt.
Diese Eigenschaft von ERP-Software, weite Teile der betriebswirtschaftlich/kauf-
männischen Geschäftsprozesse abzudecken, wurde oben schon 1. Integrationsaspekt
genannt. Hintergrund davon ist der Anspruch, das gesamte Informationssystem des
beschriebenen Bereichs integriert zu organisieren. Zum einen, was die Daten angeht,
am besten in einer einzigen unternehmensweiten Datenbank, zum anderen bezüglich
der von der Software zur Verfügung gestellten Funktionalitäten.
Dieser erste Integrationsaspekt hat auch etwas mit dem Ziel der Optimierung der
innerbetrieblichen Abläufe und der schlankeren Gestaltung des Informationssystems
zu tun, denn beides kann nur realisiert werden, wenn die Integration der verschiede-
nen betriebswirtschaftlichen Anwendungsprogramme gelingt.
2. Integrationsaspekt
Der 2. Integrationsaspekt meint den Umstand, dass ERP-Software vielen unter-
schiedlichen Unternehmen dienen soll. Auch diese Eigenschaft kann nur mithilfe
einer fundierten Analyse der Geschäftsprozesse – über verschiedene Unternehmen
hinweg – realisiert werden. Diese ist Teil des durch die beiden Integrationsaspekte
erzwungenen unabdingbaren tragfähigen Modellierungskonzepts.
Ist der Bereich, den eine ERP-Software abdecken soll, auf eine bestimmte Bran-
che begrenzt, wird sie zur Branchensoftware.
Das Gegenstück zu Standardsoftware ist Software, die für ein bestimmtes Unter-
nehmen und die dort vorliegenden Abläufe und Strukturen gefertigt wurde. Sie wird
Individualsoftware genannt und kann von den eigenen Entwicklern des Unterneh-
mens oder von einem Softwarehaus stammen.
Grundlage
Grundlage von ERP-Software ist damit eine möglichst umfassende Analyse der in
den Unternehmen konkret vorliegenden Geschäftsprozesse. Versetzen wir uns in die
Position der Ersteller von prozessorientierter Standardsoftware, besteht die zu lösen-
de Aufgabe in Folgendem:
Herausfinden der Gemeinsamkeiten all der verschiedenen Realisationen eines
konkreten Geschäftsprozesses (z.B. einer Auftragsabwicklung). Dabei entsteht
eine Art „durchschnittlicher Geschäftsprozess.“
Festlegen von als „sinnvoll“ erachteten Abweichungen (vom „durchschnittli-
chen Geschäftsprozess“), die ebenfalls in der Software realisiert werden.
Eventuelle Miteinbeziehung neuer Methoden für den jeweiligen Geschäftspro-
zess (z.B. neuer Verfahren der Absatzplanung in den entsprechenden Ge-
schäftsprozess)
Anbieten eines Instrumentariums, mit dem die Kunden dann ihre Variante der
Geschäftsprozesse festlegen können (Customizing bzw. Parametrisierung)
36 Die heute unter dem Stichwort Data Warehouse diskutiert werden.
Branchensoftware
Individualsoftware
16 IT-Unterstützung 159
Customizing
Mit dem Begriff Customizing wird die Anpassung der Standardsoftware an die rea-
len Prozesse beschrieben. Zumindest der größere Teil dieser Anpassung soll bei
Standardsoftware so ablaufen, dass nicht programmiert werden muss, sondern dass
nur die wie auch immer gestalteten Parameter der Standardsoftware verstellt werden.
Ein eventueller Rest kann dann mit einer mitgelieferten Programmiersprache (bei
R/3 z.B. Java, früher ABAP) erledigt werden.
Überwindung der „Lücke“
Eine Aufgabe, vor das das Geschäftsprozessmanagement immer wieder steht, ist die
Bewältigung der "Lücke" zwischen den realen Geschäftsprozessen (durch
Istanalysen erhoben) und denen der zugekauften oder gemieteten prozessorientierten
Software (automatisiert oder unterstützend). Gemeint sind damit die Unterschiede
zwischen den beiden Prozessvarianten. Diese Lücke ist auch dann vorhanden, wenn
im Auswahlprozess für die prozessorientierte Standardsoftware dieser Punkt intensiv
mit bedacht wurde.
Grundsätzlich sind für Ihre Überwindung einer solchen Lücke folgende Vorge-
hensweisen denkbar:
1. Umfassende Anpassung der realen Geschäftsprozesse an die der ERP-
Software37.
2. Umfassende Anpassung der Geschäftsprozesse der ERP-Software an die realen.
3. Kompromiss aus 1) und 2).
4. Optimierung der realen Geschäftsprozesse und Kompromiss aus 1) und 2), evtl.
in Kombination mit einer vorhandenen oder anstehenden ISO-Zertifizierung.
Wahrscheinlich erscheinen die ersten beiden Lösungen als sehr radikal. Nichtsdesto-
trotz werden sie gewählt. Die erstgenannte z.B. bei Supportprozessen, die zweitge-
nannte eher nicht und wenn, dann höchstens im Bereich der Kernprozesse, falls für
diese nicht gleich eine Individuallösung gewählt wird.
Jede Vorgehensweise hat ihre Konsequenzen. Die erste Lösung (die im Übrigen
auch nicht ohne minimales Anpassen auskommen wird) bedeutet einen tiefen Ein-
schnitt in die bis dahin vorhandenen Unternehmensabläufe und schafft von daher
u.U. Akzeptanzprobleme bei den Nutzern. Außerdem entsteht ein erhöhter Schu-
lungsaufwand, da es nicht nur um das Gewöhnen an eine neue Programmoberfläche
mit leicht veränderten Abläufen geht, sondern um meist grundsätzlich veränderte
Geschäftsprozesse. Außerdem bedeutet sie u.U. einen starken Profilverlust. Sie ist
aber, was den Aufwand bei Einführung und Releasewechseln38
angeht angeht, die
preiswerteste Lösung. Oft wird sie in Unternehmen gewählt, die auf eine rasche
Entschärfung ihrer Kostensituation angewiesen sind.
Viele Unternehmen entscheiden sich auch dafür, diese erste Lösung für die unter-
stützenden Geschäftsprozesse zu wählen und für die Kernprozesse eine der anderen.
In allen Punkten geradezu entgegengesetzt ist die zweite Lösung. Treibt man dies
weit genug, reproduziert man sich die alte Individualsoftware39
und hat großen
37 Stellvertretend für jede Art von prozessorientierter Standardsoftware.
38 Mit Releasewechsel werden Lieferungen einer neuen Version der Software mit wenigen oder vielen,
manchmal auch grundlegenden Änderungen, bezeichnet. Sie erfolgen relativ oft (bei einzelnen Her-
stellern bis zu jährlich).
39 Vor allem deren Ablauflogiken, weniger deren Oberflächen.
16 IT-Unterstützung 160
Aufwand bei der Einführung und bei jedem Releasewechsel, wo dann alle früher
getätigten Änderungen dahingehend überprüft werden müssen, ob sie mit der neuen
Basisversion der Standardsoftware noch funktionieren. Noch aufwändiger gestaltet
sich oft der Abgleich der veränderten Datenstrukturen. Natürlich gibt diese Variante
aber die Möglichkeit, Profilverlusten aller Art energisch entgegenzutreten.
„Zwischenlösung“
Eine Lösung, die als Variante 1b bezeichnet werden könnte, traf der Verfasser öfters
in Unternehmen an. Dabei bleibt die ERP-Software selbst so gut es geht unverän-
dert, damit die neuen Versionen relativ problemlos eingespielt werden können. Die
gewünschten Änderungen (deren Umfang auf das Nötigste beschränkt wird) werden
über externe Programmierwerkzeuge, die über einfache Schnittstellen mit der Stan-
dardsoftware kommunizieren, realisiert. Diese Lösung wird allerdings nur für die
Supportprozesse ergriffen.
Meist wird bei der Überwindung der Lücke zu einem Kompromiss gegriffen, wie
er oben als dritte Lösung angeführt ist. Änderungen, die unabdingbar erscheinen
werden vorgenommen, ansonsten werden die Geschäftsprozesse der ERP-Software
übernommen.
Reengineering
Auch die vierte obige Lösung wird sehr oft gewählt. Da die Beschäftigung mit Stan-
dardsoftware meist sowieso dazu führt, sich mit den Geschäftsprozessen näher zu
befassen, wird die Einführung dann gleich für Optimierungsvorhaben genutzt. Die-
ses Reengineering erfolgt dann unter gleichzeitiger Berücksichtigung der realen
Geschäftsprozesse und denen der Standardlösung.
ISO-Zertifizierung
Seit einiger Zeit kommt in vielen Unternehmen noch ein vierter zu berücksichtigen-
der Faktor hinzu, die ISO-Zertifizierung. Da diese natürlich auch auf die Geschäfts-
prozesse Einfluss nimmt, müssen dann
reale Geschäftsprozesse,
die der Standardlösung,
die Optimierungswünsche und
die Zertifizierungsvorgaben
zusammengebracht werden.
Konsequenzen des Einsatzes von ERP-Software
Es gibt heute in der Regel keinen Weg mehr, der am Einsatz von ERP-Software
vorbeiführt. Zumindest für den Bereich der Supportprozesse. Trotzdem sollen einige
Konsequenzen angesprochen werden, die ja - im Überschneidungsbereich von Ge-
schäftsprozessmanagement und IT-Management bedacht werden sollten.
Hat ein Unternehmen ERP-Software eingeführt, erfolgen Weiterentwicklung und
Wartung außerhalb des eigenen Unternehmens40
. Die Innovation ist im Wesentli-
40 Wenn nicht ein eigenes „Competence Center“ eingerichtet wird, das dann nicht nur hausinterne
Kompetenz realisiert, sondern auch fundiert Änderungsvorschläge an das Softwarehaus macht, von
dem die Standardsoftware kommt. Dies realisieren derzeit aber nur sehr wenige und sehr große Un-
ternehmen.
Fremdbestimmung?
16 IT-Unterstützung 161
chen verlagert auf das Softwarehaus, das auch das volle Entwicklungsrisiko trägt.
Natürlich nimmt das Standardsoftwarehaus (wenn es kompetent ist) ständig die
Veränderungen der Geschäftsprozesse in den Unternehmen wahr (auch in Form von
Veränderungsvorschlägen der Kunden) und versucht, seine Strukturen anzupassen,
aber dies ist eine völlig andere Situation als bei einer eigenen Entwicklermannschaft
im Haus.
Durch ERP-Software entsteht damit eine große Abhängigkeit vom Softwareher-
steller. Sie ist mit der Abhängigkeit vergleichbar, die gegenüber dem Anbieter von
Individualsoftware besteht, allerdings sind die Gewichte sehr unterschiedlich. Die
großen Anbieter von Standardsoftware haben ein so großes Gewicht, dass zumindest
ein einzelner Kunde (ein einzelnes Unternehmen) schwerer Gehör findet als z.B. bei
einem regionalen Ersteller von Individualsoftware.
Ein Unternehmen, das vor der Einführung von ERP-Software ein hervorragendes
und auf dem Stand der Technik befindliches IT-System mit entsprechender Anwen-
dungssoftware hatte, verliert durch die Einführung unter Umständen seine Vorteile
vor den Mitbewerbern, es wird diesbezüglich „durchschnittlich“ und erleidet einen
Profilverlust. Natürlich kann auch durch den mehr oder weniger geschickten Einsatz
von Standardsoftware Profil gewonnen werden, allerdings nicht in dem Umfang wie
bei Individuallösungen.
In der Regel ist es aber so, dass ein so hervorragend ausgestattetes Unternehmen
auf die Übernahme einer Standardlösung verzichten wird.
16.4.2 Durch Workflow-Systeme
Workflowmanagement beruht auf dem, was früher Vorgangsbearbeitung genannt
wurde. Ein Vorgang besteht aus einer Folge von Tätigkeiten und, falls notwendig,
dem Weg des Vorgangs über mehrere Arbeitsplätze. Dazu gehörten Entscheidungs-
alternativen, die zu Verzweigungen führten. Mehrere miteinander verknüpfte Vor-
gänge können dann zu dem führen, was hier Geschäftsprozess genannt wird.
Ein Workflow ist nun ein ganz oder teilweise automatisierter Geschäftsprozess.
Hier bedeutet Automatisierung, dass die Software des Workflowmanagementsys-
tems die notwendigen Arbeitsschritte anstößt, die durch Mitarbeiter oder durch Pro-
gramme umgesetzt werden. Dieser Ansatz beruht also auf der (naheliegenden) An-
nahme, dass ein Geschäftsprozess aus einer nacheinander abzuwickelnden
Tätigkeitsfolge besteht.
Workflowmanagement war lange Zeit und ist auch heute noch im Ansatz doku-
mentenzentriert. Erfasst wurden daher die differenzierten Befugnisse von Einzelnen
oder Gruppen bzgl. der Bearbeitung der Dokumente auf dem Laufweg (lesen, än-
dern, löschen, usw.).
Seit 1993 befasst sich die Workflow Management Coalition (WfMC), eine Verei-
nigung von Forschungsinstituten, Hochschulen, Anwendern und Softwareherstel-
lern, mit Standards im Bereich des Workflow-Managements. Sie versteht den
Workflow als einen ganz oder teilweise automatisierten Geschäftsprozess, in dem
Dokumente, Informationen oder Aufgaben von einem Teilnehmer an einen anderen
zur Ausführung entsprechend einer Menge von prozeduralen Regeln übergeben
werden.
Workflowmanagementsysteme "sind somit Softwaresysteme, deren Kernaufgabe
die Unterstützung betrieblicher Prozessabläufe durch die Koordination von Aktivitä-
Abhängigkeiten
Profilverlust?
16 IT-Unterstützung 162
ten, Anwendungen, Daten und prozessbeteiligten Personen ist" [zur Mühlen und
Hansmann 2012, S. 367].
Konzeptionelle Grundlagen
Wir haben oben zwischen klassisch programmierter Software und workflowba-
sierter Software unterschieden. Diese Unterscheidung kann jetzt begründet werden.
Erstgenannte Software entsteht - auf unserer Betrachtungsebene - als ein geschlos-
senes Programm, das den entsprechenden Geschäftsprozess zur Verfügung stellt41
.
Workflowmanagementsysteme dagegen koordinieren Prozesse, indem sie die Aus-
führungsreihenfolge der Aktivitäten (des Kontrollflusses) eines Prozesses überwa-
chen, Daten für die Ausführung einzelner Aktivitäten bereitstellen, anstehende Akti-
vitäten menschlichen oder technischen Bearbeitern zur Ausführung zuordnen und
Anwendungssysteme für die Bearbeitung der Aktivitäten zur Verfügung stellen. Sie
realisieren den Prozess ("welche Aktivitäten sind mit welchen Daten und Anwen-
dungen durch welche Ressourcen zu bearbeiten") auf der Basis eines Workflowmo-
dells, das vorab erstellt worden ist.
Wenn in der einschlägigen betriebswirtschaftlichen Literatur von IT-
Unterstützung für Geschäftsprozesse die Rede ist, dann wird meist an Workflow-
Systeme gedacht (vgl. z.B. [Gadatsch 2015, Abschnitt 2.3], [Schmelzer und Sessel-
mann 2013]).
Grundidee
Die zugrundeliegende Idee ist also, einen Geschäftsprozess in kleine Abschnitte zu
zerlegen und diese einer Software zur Ausführung zu überlassen. Die eher kleinen
Abschnitte (also nicht ganze Prozesse) können automatisch oder teilweise automa-
tisch umgesetzt sein. "Automatisch" bedeutet auch hier vollkommen durch Software
realisiert, "teilweise automatisch" bedeutet, dass die Software einen menschlichen
Partner mit einplant (z.B. für Entscheidungen). Diese Abschnitte wirken dann zu-
sammen und arbeiten (mit oder ohne menschliche Unterstützung) den Geschäftspro-
zess ab. Da es ohne Kontrollfluss, Nachrichtenfluss usw. nicht geht, muss die Soft-
ware diesen realisieren. Also entlang des vorgegebenen Kontrollflusses die
einzelnen Prozessabschnitte anstoßen, Nachrichtenflüsse initiieren, usw. In diesem
Zusammenhagn spricht man - von der Serviceorientierten Theorie herkommend, von
Orchestrierung (mehrere Geschäftsprozesse zum Zusammenwirken bringen) und
Choreographie (Kontrollfuss eines Geschäftsprozesses realisieren).
Die kleinen Prozessabschnitte werden hier Workflow genannt, die ausführende
Software Workflowsystem, die Tätigkeiten bei Einrichtung und Betrieb Workflow-
management, die Überwachung des Geschäftsprozesses Workflowcontrolling.
Zuerst Geschäftsprozessmodellierung, dann Workflowmodellierung
Die Modellierung des Workflows baut auf der Prozessmodellierung auf. Ist diese
kompetent durchgeführt (mit allen Informationsweitergaben, Geschäftsobjekten), ist
die Abbildung in den Workflow nicht aufwändig. Hinzu kommt immer die Hinterle-
gung der Kontroll- und Nachrichtenflüsse im Workflowsystem.
Je nach Detaillierungsgrad der Prozessmodellierung werden die Aktivitäten des
Prozessmodells so verfeinert, dass das Workflowsystem damit umgehen kann. Wur-
41 Intern ist auch eine solche Software aus Bausteinen (Modulen) aufgebaut. Dies ist aber eine andere
Betrachtungsebene.
16 IT-Unterstützung 163
de die hier vorgestellte Standardprozessmodellierung durchgeführt, bei der ja die
Geschäftsobjekte vollumfänglich erkennbar sind, sollte nicht allzuviel Verfeinerung
nötig sein. Der Detaillierungsgrad soll einerseits die automatische Ausführung durch
das Workflowsystem und andererseits eine simulationsbasierte Analyse von
Workflows gestatten [Gadatsch 2015, Pos. 257].
Der Ablauf der Workflows kann überwacht werden. Gibt es Probleme, stimmen
also die Ergebnisse nicht mit den Erwartungen überein, werden die Workflows ver-
ändert, bzw. die Workflowabwicklung angepasst.
Dies ist i.d.R. leichter möglich, als in einer programmierten Software und da liegt
der Charme dieser Lösung. Alle diese Ansätze, die Gesamtaufgabe (den
Gesamtprozss) zu zerlegen und durch das Zusammenwirken zu realisieren, beruhen
auf dem Versuch, die Komplexität des gesamten Prozesses (der gesamten Software)
zu reduzieren, bzw. erst beherrschbar zu machen. Dies ist eine in der Informatik seit
langem vertraute Strategie, ohne die moderne Softwaresysteme nicht möglich wä-
ren. Hier also in Form von Workflows.
16.5 Serviceorientierte Architekturen
Es gibt seit einigen Jahren einen neuen Trend in der Entwicklung der IT, der sich
kurz so beschreiben lässt: Im Internet werden Softwarelösungen für einzelne (von
vielen benötigte) Aufgaben abgelegt („Services“), die von der Unternehmens-IT
genutzt und in ihre vorhandenen IT-Lösungen eingefügt werden können. Dabei
muss man zweierlei unterscheiden: Einige Unternehmen nehmen dieses Konzept im
Wesentlichen einfach als eine neue Architektur für ihre Anwendungssoftware, die in
einzelne Services zerlegt wird, die miteinander über klar definierte Schnittstellen
kommunizieren. Der eigentliche Anspruch ist aber ein anderer: Zusammenstellen
der Services von verschiedenen Anbietern aus dem Web, in Ergänzung zur vorhan-
denen Software.
Die folgende Abbildung will dies ausdrücken. Dabei gehen wir von Geschäfts-
prozessen aus. Auf der linken Seite der Abbildung ist angedeutet, dass verschiedene
Anwendungssysteme (AS1, AS2, AS3) und Services (ServA, ServB) koordiniert
werden und zusammen die Geschäftsprozessabschnitte unterstützen. Auf der rechten
Seite ist angedeutet, dass eine ERP-Software vorliegt, bei der einzelne Aufgaben
durch Webservices unterstützt werden.
Abbildung 16.5-1: Geschäftsprozesse realisieren mit Services.
Anmerkung: AS steht für Anwendungssysteme, Serv für einen Service, Web für einen Webser-
vice.
16 IT-Unterstützung 164
Grundlagen
Webservices. Ein Webservice ist eine unabhängige, in sich geschlossene Anwen-
dung, die eine genau definierte Aufgabe erfüllt. Er kapselt Daten und Anwendungs-
logik und tauscht Nachrichten über eine standardisierbare Schnittstelle aus und steht
im Web zur Nutzung zur Verfügung.
Einige Beispiele:
Transportplanung für ein Lieferfahrzeug unter Berücksichtigung der aktuellen
Verkehrslage im Rahmen der Versandlogistik [Mertens 2013, S. 16).
Umwandlung eines Textdokuments in ein PDF-Dokument (FPDF)
Durchführung von Prognoserechnungen
Eine beliebte Programmiersprache zur Erstellung von Webservices ist PHP.
Serviceorientierte Architekturen.
Wie kommt es nun zum Einsatz dieser Webservices. Stellen wir uns ein Zusammen-
spiel zwischen Dienstnachfrager, Dienstanbieter und einem Verzeichnisdienst vor.
Jetzt allerdings im Web und nicht im Intranet. Diese müssen zusammenfinden, sie
müssen, um es mit Mertens zu sagen, verteilte Softwaresysteme aus lose gekoppel-
ten Funktionsbausteinen mit klar umrissenen Aufgaben bilden [Mertens 2013, S.
16]. Dabei haben die drei Parteien folgende Aufgaben:
Der Anbieter von Diensten (service provider) erstellt den Webservice und stellt
eine Funktionsbeschreibung bereit, die mit einer Web-Service-Description-
Language (WSDL) erstellt wurde. Diese ist in einem öffentlich zugänglichen
Universal-Description-Discovery-and-Integration (UDDI)-Verzeichnis hinter-
legt.
Der Nachfrager nach Diensten (service consumer) startet für seinen Bedarf
Suchanfragen, um einen relevanten Dienst aufzuspüren.
Der Verzeichnisdienst verwaltet das UDDI-Verzeichnis.
Vgl. auch die folgende Abbildung. Die bei all dem notwendige Kommunikation
erfolgt über offene Protokolle und standardisierte Formate (in der Regel XML).
Ablauf
Grundlage des ganzen Geschehens ist, dass Diensteanbieter ihre Services veröffent-
lichen, z.B. ein neues Programm zur Absatzprognoserechnung. Hat nun ein Nach-
frager einen entsprechenden Bedarf, wird das Verzeichnis abgefragt und gegebenen-
falls die Beschreibung des Dienstes zurückgeliefert. Entsprechen die Spezifikationen
den Wünschen des Nachfragers nutzt er den Webservice des Diensteanbieters. Und
dies u.U. regelmäßig.
Ganz konkret: Ein Nutzer (normalerweise ein Programm) sucht eine Anwendung,
die in der Datenbank einer Fluggesellschaft eine Buchung vornimmt. Er stellt eine
Suchanfrage an einen Verzeichnisdienst. Dort finden sich Beschreibungen verschie-
dener einschlägiger Webservices. Nachdem ein Anbieter für die Anwendung gefun-
den wurde, können Nutzer und Anbieter eine Verbindung aufbauen und über das
Internet miteinander kommunizieren. So können sie die gemeinsame Aufgabe erfül-
len (das Nutzungsprogramm steuert die Angaben zum Passagier und zum Flugziel
bei, der Web-Service übernimmt die Buchung). Dienstsuche, Verbindungsaufbau
und Kommunikation erfolgen automatisiert auf der Basis von XML-Nachrichten.
16 IT-Unterstützung 165
Anmerkung: In der Literatur ist manchmal auch von einer völlig automatisierten Lösungen die
Rede: Die Software des Unternehmens (in ihrer Architektur dann auch serviceorientiert) sucht
selbständig den am besten geeigneten Webservice mit (zum Beispiel) Absatzprognoserechnung
oder den am besten zum Wandeln von Text in PDF-Dokumente geeigneten (um bei den oben angeführten Beispielen zu bleiben). Dies konnte der Verfasser bis heute in der Praxis allerdings
noch nicht antreffen.
Abbildung 16.5-2: Grundstruktur einer serviceorientierten Architektur
Wird ein solches Anwendungssystem realisiert spricht man einer Serviceorientierten
Architektur (SOA). Diese ist somit eine Form einer verteilten Informationsarchitek-
tur, deren Fokus auf der Ankündigung, dem Auffinden und dem dynamischen Auf-
rufen von hoch stehenden, anwendungsnahen und in sich abgeschlossenen Diensten
liegt.
Der Grundgedanke ist bestechend. Im Web werden eine Vielzahl von Services
bereitgestellt, die jeweils eine wichtige Aufgabe in unseren Geschäftsprozessen zu
lösen bereit sind. Es gibt sogar konkurrierende, so dass wir wählen können. Wir
stellen für unseren Geschäftsprozess relativ problemlos die Services zusammen,
tauschen sie auch mal aus, wenn wir – oder das System selbst – bessere entdecken,
und haben somit immer einen „bestausgestatteten“ Geschäftsprozess. Dies alles in
Zusammenarbeit von IT-Management (IT-technisch) und Geschäftsprozessmana-
gement (fachlich).
Bei den auszulagernden Abschnitten geht es nicht so sehr um Funktionen bzw.
Aktionen von Geschäftsprozessen. Beim heutigen Stand der Technik geht es eher
um kleine abgeschlossene Aufgaben, die bei einer Prozessmodellierung vielleicht in
eine Funktion gekapselt werden und die zu den vor- und nachgelagerten Prozessab-
schnitten klar definierte Schnittstellen haben. Das sollten auch die oben angeführten
Beispiele verdeutlichen.
Die Idee der Auslagerung von Services ins Web und die Vorstellung, den Ge-
schäftsprozess mit vielen solchen Webkomponenten auszustatten, ist völlig konträr
zu dem Integrationsgedanken, wie er ansonsten heute gepflegt wird (integrierte
Datenbank, integrierte prozessorientierte Software). Wer sich angesichts der Vor-
stellung einer serviceorientierten Architektur an heterogene Systemwelten erinnert
fühlt, hat nicht so ganz unrecht. Allerdings wird diese heutige heterogene Lösung
auf einer anderen technologischen Basis realisiert als früher.
Beherrschbar wird diese Technologie, wenn es um klar abgegrenzte Aufgaben
mit exakt definierten Schnittstellen zu den vor- und nachgelagerten Prozessabschnit-
ten geht und wenn das Problem der Datenhaltung geklärt ist. Der einfachste Fall
Nutzen
Stand der Technik
Integration?
16 IT-Unterstützung 166
liegt vor, wenn dem Webservice replizierte Daten übergeben werden (z.B. die mo-
natlichen Absatzzahlen der letzten fünf Jahre) und wenn er fest definierte zurücklie-
fert, die dann in die unternehmensweite integrierte Datenbank eingefügt werden (die
Prognosen des Folgejahres).
Durch Orchestrierung zum Kontrollfluss. Stellt man sich eine ganze Anwen-
dungssoftware serviceorientiert vor, ist das Problem des Kontrollflusses zu lösen.
Denn die Services allein lösen nur ihre Aufgabe, tragen zum Kontrollfluss aber
nichts bei. In konkreten Architekturen wird dabei eine Komponente vorgeschlagen,
die dies dann leistet. Der verwendete Begriff dafür ist Orchestrierung, da diese
Komponente die Services sozusagen zum korrekten Miteinander bringt.
Betrachten wir als Beispiel die Lösung von SAP, NetWeaver42
. Es ist eine Lö-
sung, die in einer serviceorientierten Architektur die benötigte Funktionalität selbst
enthält, die aber erlaubt, Webservices sowie auch die Leistungen anderer IT-
Systeme zu nutzen.
NetWeaver ist der Kern der sog. Enterprise Services Oriented Architecture
(ESOA), dem Grundlagenkonzept der SAP für Webservice-Lösungen. Sie integriert
alle Systeme, die wichtig für den jeweiligen Geschäftsprozess sind, unabhängig
davon, ob es sich um interne oder externe, um SAP- oder um Nicht-SAP-Systeme
handelt. Die ESOA ermöglicht das Design der kompletten Lösung für einen Ge-
schäftsprozess, wobei existierende IT-Systeme und Anwendungen einbezogen wer-
den. Zentrale Komponente ist dabei das Composite Application Framework, das
Werkzeuge, Methoden, Regeln und Bausteine enthält, die es SAP, deren Partnern
und Anwendern ermöglicht, komponentenbasierte Anwendungen zu entwickeln.
16.6 Cloud Computing
Zum Abschluss hier noch einige Anmerkungen zu einem schon mehrfach genutzten
Begriff, unter dem die webbasierten serviceorientierten Architekturen auch disku-
tiert werden. Werden Webservices von mehreren verteilten Servern im Internet in
skalierbarer Form angeboten, so spricht man von Cloud Computing [Hansen und
Neumann (Hrsg.) 2009, S. 268). Dabei steht der Begriff cloud (Wolke) als Metapher
für das Internet. Er drückt auch aus, dass der Nutzer des Dienstes nicht unbedingt
weiß, wo der Server steht, von dem er die Leistung bezieht.
Zu dieser Entwicklung kam es, als große Internetunternehmen im B2C bemerk-
ten, dass ihre riesigen Rechenzentren (hier auch Serverfarmen genannt), die für das
Weihnachtsgeschäft unbedingt benötigt wurden, im Rest des Jahres ziemlich wenig
ausgelastet waren. Da diese Serverfarmen ja auch auf hervorragende Weise mit dem
Internet verbunden sind, kam man auf die Idee, diese Rechnerkapazitäten außerhalb
der Weihnachtszeit anderen Unternehmen anzubieten. Der Kunde weiß dabei nicht,
in welchem der Rechenzentren seine IT-Leistungen realisiert werden. Er bezieht sie
einfach aus „der Wolke“.
Vorreiter war hier Amazon. Inzwischen haben andere Unternehmen, z.B. Micro-
soft und IBM nachgezogen und ebenfalls solche Serverfarmen aufgebaut, auch mit
anderen Rahmenbedingungen (z.B. mit regionalen Festlegungen).
42 Inzwischen Grundlage der allgemeinen ERP-Lösung von SAP: "SAP ERP is based on the architectu-
re of SAP NetWeaver. This Integration allows customers unparalleled access to the capabilities of the
SAP NetWeaver platform (SAP ERP 2004 on SAP NetWeaver'04 and SAP ERP 6.0 on SAP
NetWeaver 7.0)." (http://scn.sap.com/community/netweaver-technical-integration-with-erp, Abruf
am 29.4.2016)
16 IT-Unterstützung 167
IT in der Cloud
Es ist möglich, dass im Rahmen der Erhöhung von Effektivität und Effizienz die
Verlagerung von Geschäftsprozessen "nach außen" beschlossen wird. Das ist dann
Aufgabe der IT, aber das Geschäftsprozessmanagement muss mitreden können. In
Abbildung xxx ist bereits angedeutet, dass die Gesamtleistung eines Geschäftspro-
zesses u.U. von mehreren Anwendungssystemen und WebServices erbracht wird,
zusammen mit einem ERP-System. Dies ist heute durchaus Realität.
Auch die Verlagerung von Teilen der IT (oder der ganzen) ist möglich. Konkret
bedeutet es, dass ganze Geschäftsprozesse oder Teile von Geschäftsprozessen in die
Cloud verlegt werden.
16.7 Ewiges Thema: Integration
Ganz grundsätzlich ist jedes Unternehmen heute in eine dichte informationelle Um-
welt eingebettet. Dies bedeutet u.a., dass Geschäftsprozesse des Unternehmens mit
anderen aus der Außenwelt in Kontakt treten müssen. Sei es, dass einem Prozess
von außen "zugeliefert" wird, dass er von außen angestoßen wird ("Auftragsein-
gang"), sei es, dass er Richtung Kunde weiter geht. Gelingt hier die Anbindung,
wird dies Integration genannt in dem Sinne, dass die Geschäftsprozesse ohne Brü-
che miteinander gekoppelt werden.
Betrachten wir dazu Abbildung xxx. Der gestrichelt angedeutete Geschäftspro-
zess könnte die Leistungserbringung repräsentieren. Sie benötigt Vorleistungen von
außen und sie wirkt nach draußen weiter in Richtung Kunden, Wartung, usw. Diese
Schnittstellen werden seit einigen Jahren schon intensiv beackert und der teilweisen
Automatisierung näher gebracht. Stichworte sind hier semantische Prozessintegrati-
on und Portallösungen. Hier muss die Prozessmodellierung Klarheit schaffen und
die Grundlagen für die Automatisierungsbemühungen liefern.
WebServices
Das gleiche gilt für die unter Umständen eingefügten WebServices. Unabhängig
davon, ob sie im normalen IT-Umfeld eingefügt oder ob sie in die Leistungen der
ERP-Software eingebettet sind, es ergeben sich Schnittstellen und diese müssen
bewältigt werden. Heutzutage ist dafür auch eine entsprechende Prozessmodellie-
rung notwendig.
Cloud Computing
Genau dasselbe gilt für die moderne Form des Outsourcing, die Verlagerung von
Teilen der IT in die Cloud. Wird nicht die gesamte IT ausgelagert, gibt es Schnitt-
stellen zwischen den Geschäftsprozessen im Unternehmen und in der Cloud. Insbe-
sondere auch zu der Frage, welche Informationen hin- und welche zurückfließen.
Auch dafür ist eine umfassende Prozessmodellierung unabdingbar.
Die hier anstehenden Aufgaben löst in erster Linie das IT-Management. Das Ge-
schäftsprozessmanagement sollte aber mitentscheiden. Z.B. bei Fragen mit strategi-
scher Bedeutung: Soll (Kann) die Personalabrechnung ausgelagert werden? Kann
der Mailserver zu einem Anbieter ausgelagert werden, bei dem nicht klar ist, wo er
den Server betreibt?
16 IT-Unterstützung 168
16.8 Zusammenarbeit
"Graben"
Es ist sicherlich in diesem Kapitel deutlich geworden: Geschäftsprozesse benötigen
nicht nur die fachlich Verantwortlichen, die den Geschäftsprozess tragen (aus den
kaufmännischen Abteilungen), sondern die Computerexperten, die für die Umset-
zung der Geschäftsprozesse in die IT-Landschaft sorgen. Damit ist ein für das Ge-
schäftsprozessmanagement wichtiges Konfliktfeld angesprochen, der "Graben"
zwischen den fachlich zuständigen und der IT. Der hat mit vielem zu tun, v.a. mit
der unterschiedlichen Denkweise, der unterschiedlichen Tätigkeit der Betroffenen.
Dies führt zu den bekannten Kommunikationsproblemen zwischen Fachabteilung
und IT, die überwunden werden müssen, soll Geschäftsprozessmanagement wirklich
effektiv und effizient erfolgen.
Die konkrete Zusammenarbeit im Bereich Prozessmodellierung kann auf unter-
schiedliche Weise erfolgen. Im Kern geht es aber immer darum, dass die fachlich
Verantwortlichen den Prozess fachlich modellieren (ihre Vorstellungen festlegen),
die Ergebnisse dieser Modellierung der IT übergeben und diese dann den Prozess
IT-mäßig einrichtet.
Impulse durch die IT, strategischer Beitrag der IT
Hir wurde einiges dazu geschrieben, wie die IT die Abwicklung der Geschäftspro-
zesse unterstützt. Sie sollte aber mehr leisten, sie sollte die Fachabteilungen, die
Leitung des Geschäftsprozessmanagements und das strategische Management über
die Möglichkeiten, die die IT bietet, informieren.
Mertens sprach schon in den frühen Auflagen seines Standardwerks [Mertens
2013] von den Beiträgen der IT zur Förderung der Unternehmensmission. Die IT
soll nicht nur die IT-Landschaft stabil in Betrieb halten, sondern zu Kostensenkung,
Prozessökonomie, Ressourcenökonomie, usw. beitragen (Kategorie I), die strategi-
sche Position des Unternehmens mit absichern (Kategorie II) und zur "Führung des
Unternehmens im Netzwerkverbund" (Kategorie III) beitragen [Mertens 2013, S.
31].
Die Praxis sieht es ähnlich. In der Befragung IT-Kompass 201643
wurde zur "Rol-
le der IT-Abteilung heute und zukünftig" die sehr deutliche Erwartung formuliert,
dass die IT-Abteilungen sich zu Innovationszentren oder zu Partnern der Fachberei-
che entwickeln". Für die Innovationsthematik ist die erwartete Entwicklung beson-
ders deutlich. Während dies für 2015/2016 nur 5% bejahten, waren es für die Phase
"In 12-24 Monaten" 30% (der IT-Entscheider) und 26% der "Business-Entscheider"
[Herrmann 2016, S. 26].
Geschäftsprozesse werden heute so gut wie immer von IT unterstützt und immer
öfter automatisch, d.h. vollkommen softwaregestützt, abgewickelt. Das hat Konse-
quenzen für das Geschäftsprozessmanagement. Es muss sich in immer größerem
Umfang dieser Thematik zuwenden und dabei mit dem IT-Management kooperie-
ren. Die wichtigsten Themen hierzu wurden in diesem Kapitel betrachtet: Die typi-
sche Struktur von IT-Landschaften, wie IT-Unterstützung heute aussieht (auf dem
Hintergrund unterschiedlicher Problemstrukturen), was "Automatisierung" hier
43 Erstellt von IDC und der Computerwoche, Datenerhebung November und Dezember 2015 bei "IT-
und Business-Entscheidern" aus 364 Unternehmen. Der Anteil der "Business-Entscheider" lag bei 41
%.
16 IT-Unterstützung 169
eigentlich bedeutet, wie die IT-Unterstützung durch ERP- und Workflowsysteme
aussieht und was Cloud Computing hier für Fragen aufwirft. Abschließend werden
noch Aspekte der Zusammenarbeit von Geschäftsprozessmanagement und IT-
Management betrachtet.
17 GPM heute und morgen
Geschäftsprozessmanagement als betriebswirtschaftliche Aufgabe erlebt zur Zeit
einen dramatischen Wandel. Es muss, wegen der massiven Entwicklung zu IT-
Unterstützung und Automatisierung, die Geschäftsprozesse als Softwareprodukt
wahrnehmen, bzw. als etwas, was in Software "gegossen" wird. Es verändert sich
sozusagen der Gegenstand. Dies hat viele Auswirkungen:
Notwendigkeit zu einer immer enger werdenden Kooperation mit der IT in
diesem Punkt mit der Gefahr, dass die IT dominierend wird.
Die Änderung eines in Software gegossenen Geschäftsprozesses (zum Zwecke
der Fehlerbeseitung, Optimierung, Erweiterung, usw.) ist aufwändiger, da nicht
nur der Prozess, sondern auch die Software geändert werden muss.
Der letztgenannte Punkt verdient Beachtung. Da sich die Realwelt ständig verändert,
ist die leichte Anpassbarkeit von Integrierter prozessorientierter Software ein unab-
dingbares Merkmal, nicht nur bei der Einführung. Sei es als Customizing von ERP-
Software oder durch den komponentenbasierten Aufbau von Workflowsystemen. Er
erklärt auch die Nutzung web- und komponentenbasierter Lösungen mit zahlreichen
Entwicklern bei den Internetunternehmen.
18 Stichwortverzeichnis
1. Integrationsaspekt 158
2. Integrationsaspekt 158
Abhängigkeit vom Softwarehersteller
161
Abteilungen 13
Aktivität 117
Anbieter von Diensten 164
Appraisal 75
ARIS-Konzept 93
Assessment 73
Aufgaben 15
Eigenschaft 15 Aufgabenträger 22
Auftragsabwicklungsprozesses 141
Auslösern der Ereignisse 127
Automaten 85
Automatisierung 22, 23, 154, 155
Erklärung 154 Automatisierungsgrad 23, 32
Informationsobjekte 98 Automatisierungspotential 28, 29
Bahnen 120
Balanced Scorecard 62
Becken 120
Bedingungen 107
Beispiel
unstrukturierte Probleme 37 Benchmarking 55
Betriebswirtschaftliche
Standardsoftware 136
betriebswirtschaftliches BPM 40
BPM 41
BPM-Suiten 41
Büroautomatisierungssysteme 151
Business Objects 16
Business Process Diagram 117
Business Process Management 39,
40, 41
Business Process Outsourcing 138
Business Process Reengineering
Definition 41 Business-BPM 40
Chevronsymbol 131
Chief Process Owner 44
Client/Server-Netzwerk 149
Cloud Computing 149, 166
collaboration 122
Customer Relationship Management
157
Customizing
Definition 55, 159 Data Mining 153
Definition
Funktion 16
Geschäftsprozess 17, 18, 19, 21
Informationsobjekt 97
Kontrollfluss 21
Kontrollflusszweig 98
Objekt 16
primäre Geschäftsprozesse 36
sekundäre Geschäftsprozesse 36
Standardprozessmodellierung 89 detailliertere Abbildung von
Geschäftsprozessen 155
Dokumentation von
Geschäftsprozessen in Tabellen
53
durchschnittlicher Geschäftsprozess
158
Elementaraufgaben
Definition 15 Elementare Tätigkeiten
Definition 90 Elternprozess 125
Endereignis 96
Entscheidungsunterstützungssysteme
152
Ereignisraum eines Unternehmens
Definition 96 Ereignisse 93, 94
Benennung 95
Definition 95 Ereigniswelt des Unternehmens 91
Erfolgsfaktoren 59, 63
Ergebnisereignisse 101
ERP-Software 15, 136, 156
18 Stichwortverzeichnis 174
European Foundation for Quality
Management 146
Exclusive Gateway 118
exclusive merging 118
Expertensysteme 152
fachliches BPM 40
fachlich-konzeptionelle Ebene 40
Fähigkeitsgrade 76
Fähigkeitsstufe
Established 78
Incomplete 79
Managed 78
Optimizing 78
Performed 78
Predictable 78 Finanzmanagementprozess 142
flussabwärts
Definition 98 flussaufwärts
Definition 98 Förderung der Unternehmensmission
168
Fremdbestimmung
durch ERP-Software 160 Führungsgrößen 63
Führungsinformationssysteme 152
Führungsprozesse 36
Funktion
Definition 16 Funktionen 15, 93
Benennung 95 Funktionsmodellierung 133
funktionsorientierte Software 136
Gateway 118
Geschäftsobjekte 16, 89, 97, 119
Geschäftsprozess
Definition 17, 18, 19, 21 Geschäftsprozessdefinition
Becker und Vossen 18
Keller und Teufel 18
Mertens 18
Scheer 18 Geschäftsprozessmanagement 39
Geschäftsprozessoptimierung
Definition 56 Geschäftsprozessschema 32
Geschäftsregeln 98
globaler Prozess 122
Grobmodellierung 57
Grobmodellierung von
Geschäftsprozessen 131
Individualsoftware 136
Definition 158 Informationsobjekt
Definition 97 Informationsobjekte 93, 97, 119
Informationsträger 97
Innovationsprozess 140
Instanz 32
Definition 98 Instanz einer EPK 110
Instanz eines Geschäftsprozesses
110
Institutionalisierung 76
Integration
von Geschäftsprozessen 167 integrierte prozessorientierte
Standardsoftware 50
integrierte Software 136
Interne Geschäftsprozesse 116
ISO-Zertifizierung 160
Istmodellierung
Definition 53 IT 9
IT -Unterstützung 22
IT-Management-Prozess 142
Kante
Definition 98 Kerngeschäftsprozesse 33
Kernkompetenzen 59
Erläuterung 61 Kernprozesse 68
Beispiele 34 Kernziele von Geschäftsprozessen
65
klassisch programmierte Software vs.
workflowbasierte Software 162
Komponenten von
Geschäftsprozessen 94
Kon¬trollfluss
grafische Anordnung 99 Kon¬trollflusszweig
Definition 98 Kontinuierliches Prozessmanagement
55
Kontrollfluss 17, 88, 95
Definition 21, 93
Definition 2 98 Kontrollflusszweige 102
Kriterien für Kernkompetenzen 61
18 Stichwortverzeichnis 175
kritische Erfolgsfaktoren 42, 62, 63
Kunden
externe 15
interne 15 Kundenorientierung 22, 39
Kundenzufriedenheit 64
Lücke
Überwindung 159 Managementinformationssysteme
152
Managementprozesse 36
Managementpyramide 13
Erläuterung 13 Marketing als Kerngeschäftsprozess
34
Medienbrüche 31, 55
Messung des Reifegrades 73
Methode EPK
semi-formal 93 Modell vs. Instanz 32, 50
Modellbasiertes Customizing 55
Modelle von Geschäftsprozessen
157
Muster
Bedingungen 107
Tätigkeiten starten 103 Nachfrager nach Diensten 164
Nachrichtenflüsse
zwischen Becken 120 NetWeaver 166
Objekt
Definition 16 ODER
Beispiel 108 öffentlicher Geschäftsprozess 116
Öffentlicher Geschäftsprozess 121
operative Ebene 40
operative Prozessplanung 62
Operatoren 98
Orchestrierung 166
Ordnungsrahmen 139
Organisation vs. Unternehmen 10
Organisationsbrüche 22, 55
Organisationsdokumentation 54
Organisationseinheiten 93
in EPKs 96 Parallel Gateway 118
Personalmanagementprozess 142
Planungssysteme 152
potentielle Kunden 33
primäre Geschäftsprozesse
Definition 36 Process Owner 44
Produktentwicklungsprozess 141
Produktplanungsprozess 141
Profilverlust 159, 161
programmnahe Prozessmodellierung
57
Definition 89 Programmnahe Prozessmodellierung
156
Projektleiter 44
Prozess Balanced Scorecard 70
Prozess vs. Funktion 133
Prozess- vs. Funktionsmodellierung
133
Prozessassessments 73
Prozessauditor 44
Prozessberater 44
Prozesseffektivität
Definition 64 Prozesseffizienz
Definition 64 Prozesserneuerung 82
Prozessexperte 44
Prozessintegration 30
Prozesskennzahlen 62
Prozesslandkarte 133
Prozesslandschaft 133
Prozessmanagement 39
Prozessmanager 44
Prozessmission 60
Prozessmodell 32
Prozessmodellierer 44
Prozessmodellierung
programmnah 92 Prozessmodellierung (programmnah)
Definition 89 Prozessorientierte Reorganisation 55
prozessorientierte Software 136
Prozessorientierung 42
Prozessstart 117
Prozess-Steckbrief 54
Prozessverbesserung 82
Prozessvision 60
Prozesswegweiser
Beispiel 106 Prozessziele 62
Reifegrad
Defined 77
Initial 77
Managed 77
18 Stichwortverzeichnis 176
Optimizing 77
Ouantitatively Managed 77 Reifegrade 76, 148
Releasewechsel 159
Ressource IT-Landschaft 24
Ressourcenmanagementprozess 142
S-BPM 42
Schlussereignis 96
sekundäre Geschäftsprozesse
Definition 36 Semantik sucht Syntax
Kombinatorik mit UND 107
'mindestens' mit ODER 108
mit UND 112 semantische Prozessintegration 167
Definition 30 semistrukturiert
Definition 26 semistrukturierte Probleme 26
sequentielle Grundstruktur (bei
Geschäftsprozessen) 21
Sequenzfluss 88
service consumer 164
service provider 164
Serviceorientierte Architekturen 164
Serviceorientierten Architektur 165
Serviceprozess 141
Shared Services 138
Simulation 55
SMART 68
SOA 165
Social Business Process Management
42
Softwareentwicklung 55
Sollmodellierung
Definition 56 Standardprozessmodellierung 132,
156
Definition 89 Standardsoftware 136
Startereignis 96
Stellen 13, 22
Steuerungsprozesse 36
Strategieplanungsprozess 142
strategische Ebene 40
strategische Prozessplanung 62, 70
Strategisches Management 59
Subjektivität 3
Zielsetzung 53 subjektorientiertes
Prozessmanagement 42
Supply Chain 143
Supply Chain Management 157
Supportprozesse 33, 68
Syntaxregel
E - F - E - ... 102
Verzweigen nur durch
Operatoren 99
Zusammenführen nur durch
Operatoren 99 systemnahe Prozessmodellierung
132
tabellarische Beschreibung von
Geschäftsprozessen
Beschreibung 54 technologisches BPM 40
Transaktionssysteme 151
Typ-I-Geschäftsprozess 37
Übersichtsnotationen 131
Überwindung der „Lücke“ 159
Überwindung der Abteilungsgrenzen
14
Überwindung von
Organisationsgrenzen 22
UDDI 164
UDDI-Verzeichnis 164
Universal-Description-Discovery-
and-Integration - Verzeichnis 164
unstrukturiert
Definition 26 unstrukturierte Probleme
Beispiel 37 Unternehmenssoftware 136
unterstützende Proezsse 33
Unterstützung oder Automatisierung
23
Verknüpfer
Definition 100 Verschmelzen von Unternehmen 51
Verteiler
Definition 100 vertikale Dimension 133
vertikale Dimension dr
Prozessmodellierung 132
Vertriebsprozess 141
Verzeichnisdienst 164
Verzweigungen 98
Vorgang
Definition 16
Scheer 16 Vorgänge 94
Vorgangsbearbeitung 161
18 Stichwortverzeichnis 177
vorgedachte Geschäftsprozesse 135,
157
Vorgedachte Geschäftsprozesse 50
Erläuterung 135 Wartefunktionen 100
Web-Service-Description-Language
164
Webservices 164
Werkzeuge für die Istmodellierung
53
Wertkette 35
Wertschöpfungskette 21, 57, 131,
143
Definition 35, 131 Wertschöpfungskette von Porter 137
WfMC 161
Wissensentdeckungssysteme 153
wissensintensive Geschäftsprozesse
37
Wissensmanagement 55
wohlstrukturiert
Definition 26
Workflow
Definition 16
Grundidee 162 Workflow Management Coalition
161
Workflowcontrolling 162
Workflowmanagement 162
Workflowmodellierer 44
Workflowsystem 162
WSDL 164
zeitliche Dimension in EPK’s 100
Zertifizierung nach DIN ISO 9000ff
55
Zielsystem 62
Zusammenarbeit 122
Zusammenführen
Kontrollflusszweige
XODER 102 Zusammenführungen 98
Zustände 94
19 Literaturverzeichnis
Adam, Koch, Neffgen et al. 2014:
Adam, Sebastian; Koch, Matthias; Neffgen, Fabian; Riegel, Norman und Wei-
denbach, Justine: Business Process Management - Marktanalyse 2014, BPM
Suites im Test, Fraunhofer IESE, Kaiserslautern 2014
Alpar, Alt, Bensberg u.a. 2014
Alpar, Paul; Alt, Rainer; Bensberg, Frank; Grob, Heinz Lothar; Weimann, Peter;
Winter, Robert: Anwendungsorientierte Wirtschaftsinformatik. Strategische Pla-
nung, Entwicklung und Nutzung von Informationssystemen. (7. Auflage). Wies-
baden 2008
Alpar, Grob, Weimann et al. 2002
Alpar, Paul; Grob, Heinz Lothar; Weimann, Peter und Winter, Robert: Anwen-
dungsorientierte Wirtschaftsinformatik. Strategische Planung, Entwicklung und
Nutzung von Informations- und Kommunikationssystemen, 3. Auflage, Braun-
schweig und Wiesbaden 2002.
Alpar, Grob, Weimann u.a. 2008
Alpar, Paul; Grob, Heinz Lothar; Weimann, Peter; Winter, Robert: Anwendungs-
orientierte Wirtschaftsinformatik. Strategische Planung, Entwicklung und Nut-
zung von Informations- und Kommunikationssystemen. (5. Auflage). Wiesbaden
2008
Amberg 1999
Amberg, Michael: Prozessorientierte betriebliche Informationssysteme. Metho-
den, Vorgehen und Werkzeuge zu ihrer effizienten Entwicklung, Berlin u.a. 1999
Becker und Kahn 2012
Becker, Jörg; Kahn, Dieter: Der Prozess im Fokus. In: [Becker, Kugeler und Ro-
semann 2012, S. 3 - 16]
Becker und Meise 2012
Becker, Jörg; Meise, Volker: Strategie und Ordnungsrahmen. In: [Becker,
Kugeler und Rosemann 2012, S. 113 - 163]
Becker und Vossen 1996
Becker, Jörg; Vossen, Gottfried: Geschäftsprozessmodellierung und Workflow-
Management. Eine Einführung, in Vossen und Becker 1996, S. 17 – 26
Becker, Berning und Kahn 2012
Becker, Jörg; Berning, Wilhem und Kahn, Dieter: Projektmanagement. In: [Be-
cker, Kugeler und Rosemann 2012, S. 17 - 45]
Becker, Kugeler und Rosemann (Hrsg.) 2012
Becker, Jörg; Kugeler, Martin; Rosemann, Michael (Hrsg.): Prozessmana-
gement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung (7.
Aufl.), Berlin u.a. 2012
Berndt 1997
Berndt, Ralph (Hrsg.): Business Reengineering. Effizientes Neugestalten von Ge-
schäftsprozessen. Berlin u.a. 1997
19 Literaturverzeichnis 179
Bleicher 1991
Bleicher, K.: Organisation, 2. Aufl. Wiesbaden (1991)
Bou Llusar et al. 2009
Bou Llusar, Juan Carlos; Escrig-Tena, Ana; Roca-Puig, Vicente et al.: An empir-
ical assessment of the EFQM Excellence Model: Evaluation as a TQM frame-
work relative to the MBNQA Model. In: Journal of Operations Management 27
(1), 2009, S. 1–22.
Brecht 2002
Brecht, Leo : Process leadership. Methode des informationssystemgestützten
Prozessmanagement. Hamburg 2002.
Brenner und Hamm 1995
Brenner, Walter; Hamm, V.: Prinzipien des Business Reengineering, in: Bren-
ner und Keller 1995, S. 17 – 43
Bullinger und Fähnrich 1997
Bullinger, Hans-Jörg; Fähnrich, Klaus-Peter: Betriebliche Informationssysteme.
Grundlagen und Werkzeuge der methodischen Softwareentwicklung. Berlin u.a.
1997
CMMI 2010
http://cmmiinstitute.com/; heruntergeladen am: 01.09.2013.
Davenport 1993
Davenport, Thomas: Process innovation. Reengineering work through infor-
mation technology. Boston (Mass.) 1993.
Fleischmann et al. 2011
Fleischmann, Albert; Schmidt; Werner; Stary, Christian; Obermeier, Stefan;
Börger, Egon: Subjektorientiertes Prozessmanagement - Mitarbeiter einbinden,
Motivation und Prozessakzeptanz steigern. München 2011 (Hanser )
Franz 1996
Franz, Klaus-Peter: Prozesskostenmanagement für ein strategisches
Aktivitätencontrolling, in Perlitz u.a. 1996, S. 210 – 220
Gadatsch 2013a
Gadatsch, Andreas: Grundkurs Geschäftsprozess-Management, Methoden
und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Prakti-
ker, 7. Aufl. Springer, Wiesbaden 2013 (E-Book)
Gadatsch 2013b
Gadatsch, A., Mayer, E.: Masterkurs IT-Controlling, 5. Aufl. Springer, Wiesba-
den 2013
Gadatsch 2015
Gadatsch, Andreas: Geschäftsprozesse analysieren und optimieren. Praxis-
tools zur Analyse, Optimierung und Controlling von Arbeitsabläufen. Wiesba-
den 2015 (E-Book)
Gaitanides 2012
Gaitanides, Michael: Prozessorganisation. Entwicklung, Ansätze und Program-
me des Managements von Geschäftsprozessen (3. Aufl.), München 2012 (E-
Book)
19 Literaturverzeichnis 180
Hammer und Champy 1995
Hammer, Michael; Champy, James: Business Reengineering. Die Radikalkur für
das Unternehmen, Frankfurt, New York 1995
Hammer und Champy 2006
Hammer, Michael; Champy, James : Reengineering the corporation. A manifesto
for business revolution. New York 2006.
Hammer und Stanton 1995
Hammer, Michael; Stanton, Steven A.: Die Reengineering Revolution. Hand-
buch für die Praxis. Frankfurt, New York 1995
Hanschke, Giesinger und Goetze 2013
Hanschke, Inge; Giesinger, Gunnar; Goetze, Daniel: Business-Analyse - einfach
und effektiv. Geschäftsanforderungen verstehen und in IT-Lösungen umsetzen.
München 2013
Hansen und Neumann 2009
Hansen, Hans Robert; Neuman, Gustaf: Wirtschaftsinformatik I. Grundlagen be-
trieblicher Informationsverarbeitung, (10. Auflage), Stuttgart 2009.
Harrington 1991
Harrington, James: Business process improvement. New York 1991.
Heinrich und Lehner 2005
Heinrich, Lutz; Lehner, Franz : Informationsmanagement. Planung, Überwa-
chung und Steuerung der Informationsinfrastruktur, 8. Auflage, München und
Wien 2005.
Herrmann 2016
Herrmann, Wolfgang : Digitalisierung bringt die IT in Zugzwang. In: Compu-
terwoche 2016, 11-13, 14. März 2016, S. 22 - 27
Hess 1996
Hess, Thomas: Entwurf betrieblicher Prozesse. Grundlagen – Bestehende Me-
thoden – Neue Ansätze, Wiesbaden 1996
Hess und Brecht 1996
Hess, Thomas; Brecht, Leo: State of the Art des Business Process Redesign.
Darstellung und Vergleich bestehender Methoden (2. Auflage). Wiesbaden 1996
Hohmann 1999
Hohmann, Peter: Geschäftsprozesse und integrierte Anwendungssysteme. Pro-
zessorientierung als Erfolgskonzept. Köln u.a. 1999
Kastens und Büning 2008
Kastens, Uwe und Büning, Hans xxxKleine: Modellierung. Grundlagen und
formale Methoden (2. Auflage). Bonn 2008 (Hanser)
Keller und Teufel 1997
Keller, Gerhard; Teufel, Thomas: SAP R/3 prozessorientiert anwenden. Iterati-
ves Prozess-Prototyping zur Bildung von Wertschöpfungsketten. Bonn u.a. 1997
Keller, Nüttgens und Scheer 1992
Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozessmodellierung auf
der Grundlage Ereignisgesteuerter Prozessketten, Veröffentlichungen des Insti-
19 Literaturverzeichnis 181
tuts für Wirtschaftsinformatik (Iwi), Universität des Saarlandes, Heft 89, Januar
1992
Kosiol 1970
Kosiol, Erich: Die Unternehmung als wirtschaftliches Aktionszentrum. Reinbek
1970.
Kosiol 1976
Kosiol, Erich : Organisation der Unternehmung (2. Auflage), Wiesbaden 1976.
Kugeler und Vieting 2012
Kugeler, Martin, Vieting, Michael: Gestaltung einer prozessorientiert(er)en Auf-
bauorganisation. In: Becker, Jörg; Kugeler, Martin, Rosemann, Michael (Hrsg.),
Prozessmanagement, 5. Auflage, Berlin 2004, S. 229-276.
Mertens 2013
Mertens, Peter: Integrierte Informationsverarbeitung 1. Operative Systeme in der
Industrie (18. Auflage), Wiesbaden 2013 (Springer Gabler)
Mertens u.a. 1997
Mertens, Peter; Becker, Jörg; König, Wolfgang u.a. (Hrsg.): Lexikon der Wirt-
schaftsinformatik (3. Auflage), Berlin u.a. 1997
Mertens und Meier 2009
Mertens, Peter und Meier, Marco C.: Integrierte Informationsverarbeitung 2.
Planungs- und Kontrollsysteme in der Industrie (10. Aufl.), Wiesbaden 2009
Mischak 1997
Mischak, Richard F.: Business Reengineering – Der Weg vom funktions- zum
prozessorientierten Denken im Unternehmen, in: Berndt 1997, S. 3 – 17
Müller und Rupper 1994
Müller, Roland; Rupper, Peter (Hrsg.): Process Reengineering. Prozesse opti-
mieren und auf den Kunden ausrichten. Zürich 1994
Nordsieck 1932
Nordsieck, Fritz : Die schaubildliche Erfassung und Untersuchung der Betriebs-
organisation. Stuttgart 1932
Nordsieck 1934
Nordsieck, Fritz: Grundlagen der Organisationslehre. Stuttgart 1934
Österle 1995
Österle, Hubert: Business Engineering. Prozess- und Systementwicklung. Band
1: Entwurfstechniken, Berlin u.a. 1995
Perlitz u.a. 1996
Perlitz, Manfred; Offinger, Andreas; Reinhardt, Michael; Schug, Klaus (Hrsg.):
Reengineering zwischen Anspruch und Wirklichkeit. Ein Managementansatz auf
dem Prüfstand. Wiesbaden 1996
Picot, Dietl, Franck et al. 2012
Picot, Arnold; Dietl, Helmut; Franck, Egon; Fiedler, Marina; Royer, Susanne:
Organisation. Theorie und Praxis aus ökonomischer Sicht (6. Aufl.), Stuttgart
2012
19 Literaturverzeichnis 182
Porter 1985
Porter, Michael E.: Competitive Advantage – Creating and Sustaining Superior
Performance. New York 1985
Porter 1992a
Porter, Michael E.: Wettbewerbsstrategie (7. Auflage), Frankfurt 1992
Porter 1992b
Porter, Michale E.: Wettbewerbsvorteile: Spitzenleistungen erreichen und be-
haupten (3. Auflage), Frankfurt 1992
Porter 1998
Porter, Michael E.: On Competition. Harvard Business Review Book 1998
Porter 1999
Porter, Michael E.: Wettbewerbsvorteile. Spitzenleistungen erreichen und be-
haupten. (5. Auflage). Frankfurt 1999.
Rosemann, Schwegmann und Delfmann 2012
Rosemann, Michael; Schwegmann, Ansgar und Delfmann, Patrick: Vorbereitung
der Prozessmodellierung, in [Becker, Kugeler und Rosemann 2012, Kapitel 3, S.
47 - 111]
Rump 1999
Rump, Frank J.: Geschäftsprozessmanagement auf der Basis ereignisgesteuerter
Prozeßketten. Formalisierung, Analyse und Ausführung von EPKs. Stuttgart und
Leipzig 1999
Rupper 1994
Rupper, Peter: Process Reengineering - Eine Einführung, in: [Müller und Rupper
1994, S. 9 - 11]
Scheer 1997
Scheer, August-Wilhelm: Wirtschaftsinformatik. Referenzmodelle für industrielle
Geschäftsprozesse. (7. Auflage), Berlin u.a. 1997
Scheer 1998
Scheer, August-Wilhelm: ARIS – vom Geschäftsprozess zum Anwendungssystem
(3. Auflage), Berlin u.a.1998
Scheer, August; Nüttgens, Markus; Zimmermann, Volker: Rahmenkonzept für ein
integriertes Geschäftsprozessmanagement, in: Wirtschaftsinformatik, 37, 1995,
S. 426-434.
Schmelzer und Sesselmann 2008
Schmelzer, Hermann; Sesselmann, Wolfgang: Geschäftsprozessmanagement in
der Praxis. Kunden zufrieden stellen, Produktivität steigern, Wert erhöhen (6.
Auflage). München 2008.
Schmelzer und Sesselmann 2013
Schmelzer, Hermann J.; Sesselmann, Wolfgang: Geschäftsprozessmanage-
ment in der Praxis. Kunden zufriedenstellen, Produktivität steigern, Wert er-
höhen (8. Auflage). München 2013.
Schwegmann und Laske 2012
Schwegmann, Ansgar; Laske, Michael: Istmodellierung und Istanalyse. In: [Be-
cker, Kugeler und Rosemann 2012, S. 165 - 194]
19 Literaturverzeichnis 183
Simon 1957
Simon, H. A.: Models of Man, New York 1957.
Spath und Weisbecker 2008
Spath, D. und Weisbecker, A. (Hrsg.): Business Process Management Tools.
Fraunhofer-Institut Arbeitswirtschaft und Organisation IAO, Stuttgart 2008
Stahlknecht und Hasenkamp 2005
Stahlknecht, Peter; Hasenkamp, Ulrich: Einführung in die Wirtschaftsinformatik.
(11. Auflage), Berlin u.a. 2005
Staud 2006
Staud, Josef L.: Geschäftsprozessanalyse. Ereignisgesteuerte Prozessketten und
objektorientierte Geschäftsprozessmodellierung für Betriebswirtschaftliche
Standardsoftware (3. Auflage). Berlin u.a. 2006
Staud 2010
Staud, Josef: Unternehmensmodellierung – Objektorientierte Theorie und Praxis
mit UML 2.0. Berlin u.a. 2010 (Springer-Verlag)
Staud 2014a
Staud, Josef: Ereignisgesteuerte Prozessketten. Das Werkzeug für die
Modellierung von Geschäftsprozessen. Vilshofen 2014. ISBN 978-3-00-045298-
7
Staud 2014b
Staud, Josef: Ereignisgesteuerte Prozessketten. Das Werkzeug für die
Modellierung von Geschäftsprozessen. Vilshofen 2014. Kindle E-Book.
Staud 2017
Staud, Josef: Geschäftsprozessmodellierung mit der Methode Business Process
Model and Notation (BPMN). Vilshofen 2016.
Steinbuch 1998
Steinbuch, Pitter A. (Hrsg.): Prozessorganisation - Business Reengineering –
Beispiel R/3, Ludwigshafen (Rhein) 1998
Tummala und Tang 1994
Tummala, Rao; Tang, Catherine: Strategie Quality Management, Malcolm
Baldrige and European Quality Awards and ISO 9000 Certification: Core Con-
cepts and Comparative Analysis. Hong Kong 1994.
Vossen und Becker 1996
Vossen, Gottfried; Becker, Jörg (Hrsg.): Geschäftsprozessmodellierung und
Workflow-Management. Modelle, Methoden, Werkzeuge. Bonn u.a. 1996
Weißenberg und Stemmer 2009
Weißenberg, Norbert und Stemmer, Michael: Moderne IT-Plattformen für Ge-
schäftsprozessmanagement und Portale. Vergleichende Bewertung der Toolsui-
ten von IBM, IDS Scheer & SAP, sowie INTALIO & LIFERAY. Fraunhofer ISST
und Bücker GmbH 2009 (Abruf über: http://www.isst.fraunhofer.de/content/-
dam/isst/de/documents/Publikationen/StudienundWhitePaper/Fraunhofer-
ISST_IBM-Studie-Kurzfassung.pdf)
Wöhe 1993
Wöhe, Günter: Einführung in die Allgemeine Betriebswirtschaftslehre (unter
Mitarbeit von Ulrich Döring), München 1993
19 Literaturverzeichnis 184
zur Mühlen und Hansmann 2012
zur Mühlen, Michael und Hansmann, Holger: Workflowmanagement. In [Becker,
Kugeler und Rosemann 2012, Kapitel 11, S. 367 - 400]
Zürcher Hochschule 2014
Zürcher Hochschule für Angewandte Wissenschaften (Hrsg.): Business Process
Management 2014. Zürich 2014