Dieser Text enthält Auszüge aus meinem Buch...

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


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


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


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


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]


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").


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


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.


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-


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.


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


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


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.


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

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


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.


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ä-


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


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


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


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


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


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.


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.


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:


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.


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.


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.


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


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


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.


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.


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


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


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:


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.


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


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

strategischen 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

zwischen 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


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


(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


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.


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.


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


Da diese jeweils alternativ sind, muss hier in den Kontrollfluss ein XODER-

Operator eingefügt werden.


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


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


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.


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


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


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


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



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


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.



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


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.


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.


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


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


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:


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]).


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-


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])


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


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.


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.

http://www.wirtschaftslexikon24.com/d/nachfrage/nachfrage.htm

http://www.wirtschaftslexikon24.com/d/rahmenbedingungen/rahmenbedingungen.htm

http://www.wirtschaftslexikon24.com/d/prüfung/prüfung.htm

http://www.wirtschaftslexikon24.com/d/produktionsplanung/produktionsplanung.htm

http://www.wirtschaftslexikon24.com/d/montage/montage.htm

http://www.wirtschaftslexikon24.com/d/montage/montage.htm

http://www.wirtschaftslexikon24.com/d/qualitätskontrolle/qualitätskontrolle.htm

http://www.wirtschaftslexikon24.com/d/verpackung/verpackung.htm

http://www.wirtschaftslexikon24.com/d/auftragsabwicklung/auftragsabwicklung.htm


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


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]


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


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.


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.


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,


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


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.


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


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.


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.


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


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


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.


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?


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?


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.


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.


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.


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?


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)


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

%.


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


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


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


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


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


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


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


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)

http://cmmiinstitute.com/


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-


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


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]


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


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

Dieser Text enthält Auszüge aus meinem Buch...

Documents

Transcript of Dieser Text enthält Auszüge aus meinem Buch...